Jak sestavit AI panel pro konkrétní doménu: od právní analýzy po audit

Generický AI panel dává generické odpovědi. To je v pořádku u obecných dotazů. U doménové práce to ale začne bolet.

Právní analýza, interní audit nebo marketingový audit nevyžadují jen „lepší model“. Vyžadují správné perspektivy, správná pravidla a správné pořadí kroků. Jinak dostanete hezký text, který mine to podstatné.

Tenhle návod není o tom, která značka modelu je nejlepší. Je o tom, jak složit panel podle domény tak, aby workflow odpovídal typu rozhodnutí a ceně chyby.

Rámec tvrzení

• Co článek tvrdí: Generický AI panel nedává dostatečné výsledky u doménové práce. Správný postup je začít definicí domény a rolí, nikoli výběrem modelů. Pravidla workflow a ověřovací kroky odlišují skutečný proces od pouhého přidání modelů.
• Na čem to stojí: NIST AI RMF 1.0 (řízení rizik AI), Mitchell et al. (2019) Model Cards, Liang et al. (2022) HELM, Zheng et al. (2023) MT-Bench, Dhuliawala et al. (2023) Chain-of-Verification.
• Kde je to zjednodušení: Příklady workflow (právní analýza, marketing, audit) jsou ilustrativní šablony, ne ověřené postupy. Článek nepředkládá empirická srovnání generického vs. doménového panelu.

Problém: proč generický panel selhává v doménové práci

Nejčastější chyba je začít otázkou: “Které modely tam dáme?” To je obráceně.

Doménová úloha má obvykle:

• specifická rizika,
• povinné omezení,
• typické způsoby selhání (failure modes),
• a jiný standard “dost dobré” odpovědi.

Právní workflow například potřebuje pracovat s přesností formulace, zdrojovou oporou a nejistotou. Marketing audit často potřebuje hypotézy, segmentaci, argumentaci a priorizaci. Interní audit řeší traceability, výjimky a kontrolní body.

Když všechny tyto úlohy pošlete do stejného generického panelu bez role designu, panel často produkuje totéž: rozumně znějící, ale málo specializovanou syntézu.

Co se naučíš (výsledek článku)

Po přečtení byste měli umět:

• rozložit doménovou úlohu na role a perspektivy,
• převést rizika domény do pravidel workflow,
• vybrat kandidáty modelů podle vhodnosti pro roli (role-fit), ne podle „globálního rankingu“,
• a otestovat panel na takovém zadání, které odhalí slabiny dřív než produkce.

1) Začni doménou, ne modelem

První krok není shortlist modelů. Je definice úkolu.

Použijte krátkou strukturu:

• Jaké rozhodnutí má výstup podpořit?
• Jaká je cena chyby?
• Co je povinné omezení (constraint)? (právo, bezpečnost, značka, interní politika, termín)
• Co musí být auditovatelné?

Tohle okamžitě mění design panelu. Pokud je cena chyby vysoká a výstup musí být obhajitelný, panel potřebuje silnější oponenturu a ověření. Pokud jde o rychlý explorativní brainstorming, panel může být lehčí.

Jinými slovy: panel je funkcí domény a cíle, ne seznamem „oblíbených modelů“.

2) Definuj role panelu dřív než kandidáty modelů

Jakmile je jasné zadání, definujte role. Role znamená funkci v procesu, ne jméno modelu.

Častý minimální panel pro doménovou práci:

• Generátor / analytik: navrhne první rámec, varianty nebo hypotézy.
• Kritik: hledá chybějící předpoklady, slabiny argumentu a okrajové případy (edge cases).
• Kontrolor faktů / zdrojů: vyžaduje oporu pro faktická tvrzení nebo navrhuje ověřovací krok.
• Doménový “compliance” hlas: hlídá specifický constraint (např. právní opatrnost, interní policy, citlivá data).
• Syntéza / editor: spojí výstupy bez smazání důležitých námitek.

Tohle rozdělení je cenné i mimo CrossChat. Ve skutečnosti kopíruje dobré lidské revizní procesy: autor, oponent, fact-check, gatekeeper, editor.

Bez rolí se stane typická věc: všechny modely generují podobnou odpověď a panel jen simuluje diverzitu.

3) Přelož doménová rizika do pravidel workflow

Doménový panel není „specializovaný“ jen tím, že má jiné modely. Je specializovaný tím, že má jiná pravidla.

Převod vypadá takto:

• Riziko: chybné faktické tvrzení v reportu.

• Pravidlo: tvrzení se zdrojem / nebo explicitně označená nejistota.

• Riziko: ignorovaný regulatorní constraint.

• Pravidlo: compliance role musí potvrdit, že návrh constraint adresuje.

• Riziko: příliš rychlá syntéza zamaskuje neshodu.

• Pravidlo: před syntézou povinný seznam námitek / minority report.

Tady vzniká rozdíl mezi „více modely“ a skutečným workflow. Více modelů bez pravidel je jen víc textu. Více modelů s pravidly je proces.

4) Vyber kandidáty modelů podle role-fit, ne podle absolutního pořadí

Teprve teď dává smysl vybírat modely.

Neexistuje jeden nejlepší model pro všechny role. Prakticky vybíráte kandidáty podle toho, co role potřebuje:

• Rychlost a cena: hodí se pro scouting, prvotní varianty, opakované kroky.
• Práce s delším kontextem: hodí se pro syntézu delších dokumentů.
• Stabilita a opatrnost formulace: hodí se pro kritika nebo compliance roli.
• Schopnost držet strukturu: hodí se pro editora a finální výstup.

Tohle navazuje na D03 (výběr modelu podle role) a D05 (srovnání cena/výkon). Tento článek řeší ještě o patro výš: jak role a pravidla navrhnout dřív, než shortlist vůbec vznikne.

Praktický tip: nevybírejte modely “naslepo do panelu”. Pro každou roli si připravte 2-3 kandidáty a testujte je na stejné roli, ne na různých úlohách.

5) Navrhni minimální workflow pro doménu (3 příklady)

Největší přínos získáte, když panel není abstraktní. Musí být navržený pro typickou úlohu.

Příklad A: Právní analýza (interní, ne náhrada právní služby)

Cíl: zhodnotit varianty postupu a identifikovat právní rizika.

Minimální workflow:

1. Scope parser: co je jurisdikce, kontext, rozhodnutí, co už víme.
2. Analytik: navrhne rámec a hlavní varianty.
3. Kritik: hledá chybějící předpoklady, konfliktní interpretace.
4. Zdrojový checker: vyžádá citace / označí neověřené body.
5. Syntéza s nejistotou: závěr oddělí jisté body od bodů k ověření právníkem.

Tady je doménová hodnota hlavně v tom, že workflow vynucuje nejistotu a zdroje, ne jen “sebejistý právní tón”.

Příklad B: Marketingový audit

Cíl: zhodnotit messaging, cílové segmenty a slabá místa kampaně.

Minimální workflow:

1. Segmentační analytik: navrhne segmenty a hypotézy.
2. Kritik relevance: hledá vágní tvrzení a nesoulad s cílem kampaně.
3. Evidence gap checker: označí, co je názor vs. co vyžaduje data.
4. Priorizační syntéza: rozdělí doporučení na quick wins / testy / strategické změny.

Zde je klíčové nezaměnit plynulost copy za kvalitu auditu. Panel musí umět vracet i nepříjemné “nevíme bez dat”.

Příklad C: Interní audit / compliance workflow

Cíl: zkontrolovat proces nebo dokument proti checklistu a najít výjimky.

Minimální workflow:

1. Checklist parser: přeloží požadavky do kontrolních bodů.
2. Exception finder: hledá nesoulady a chybějící položky.
3. Traceability checker: spojí tvrzení s konkrétním místem v dokumentu / podkladu.
4. Final summary: oddělí kritické nálezy, doporučení a body k doplnění.

Tady se doménový panel pozná podle traceability. Bez ní je “audit” jen komentář.

6) Otestuj panel na selhávacím případu (failure case), ne na demo promptu

Mnoho panelů vypadá dobře v ukázce, protože demo prompt je příliš snadný.

Pilot má smysl teprve tehdy, když obsahuje:

• hraniční případ,
• nejednoznačné zadání,
• konflikt mezi dvěma constrainty,
• nebo vstup, kde část dat chybí.

Právě tehdy uvidíte, jestli panel:

• přizná nejistotu,
• přepne do ověřování,
• udrží role,
• a nesjede do generického textu.

Testovat jen „hladký scénář“ (happy path) je nejrychlejší cesta k falešné důvěře v panel, který selže v první reálné situaci.

Dobrá praxe je zapisovat selhání jako změnu procesu, ne jen jako dojem z jedné relace (session). Věta typu „kritik nehlídal constraint X“ by se měla proměnit v nové pravidlo, novou roli nebo nový checkpoint. Tím se panel zlepšuje systematicky.

Časté chyby

• Skládat panel podle sympatie ke značce modelu.
• Nechat všechny role dělat totéž.
• Vynechat ověřovací krok u domény s vysokými důsledky.
• Hodnotit výstup jen podle stylu a ne podle traceability nebo práce s nejistotou.

Rychlý přehled: Doménový panel za 15 minut

1. Definuj rozhodnutí a cenu chyby.
2. Sepiš 2-4 doménové constrainty.
3. Navrhni role (ne modely).
4. Přelož rizika do pravidel workflow.
5. Vyber 2-3 kandidáty modelů na roli.
6. Přidej ověřovací / traceability krok.
7. Otestuj na selhávacím případu (failure case).
8. Uprav panel podle konkrétního selhání, ne podle dojmu.
9. Ulož finální verzi panelu a u změn pravidel krátce napiš důvod.

Ten poslední bod bývá podceňovaný. Jakmile nevíte, proč bylo pravidlo přidáno, panel se po pár úpravách začne chovat nepředvídatelně a tým ztratí jistotu, co je “záměr” a co historická náhoda.

To platí dvojnásob u domén, kde se pravidla mění kvůli incidentu nebo novému compliance požadavku. Bez krátké poznámky k důvodu změny se z panelu rychle stane černá skříňka i pro vlastní tým. A pak se ztrácí i schopnost rozlišit zlepšení od nahodilé komplikace.

Závěr

Doménový AI panel není o tom “přidat víc modelů”. Je o tom navrhnout správné role, pravidla a ověřovací body pro konkrétní typ práce.

Jakmile začnete doménou místo modelu, panel přestane být generický chat s více hlasy a začne připomínat skutečný revizní proces. A právě tam obvykle vzniká největší praktická hodnota.

Praktický závěr: Pokud chcete takový panel skládat opakovaně, CrossChat dává smysl ve chvíli, kdy role, pravidla a kroky uložíte jako workflow místo improvizace v každé nové relaci. Právě opakovatelnost je v doménové práci rozdíl mezi jedním povedeným experimentem a procesem, který jde obhájit i před týmem nebo klientem.

Zdroje

• NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://www.nist.gov/itl/ai-risk-management-framework
• Mitchell et al. (2019). Model Cards for Model Reporting. FAT* 2019. DOI: 10.1145/3287560.3287596
• Liang et al. (2022). Holistic Evaluation of Language Models. arXiv:2211.09110 DOI: 10.48550/arXiv.2211.09110
• Zheng et al. (2023). Judging LLM-as-a-judge with MT-Bench and Chatbot Arena. arXiv:2306.05685 DOI: 10.48550/arXiv.2306.05685
• Dhuliawala et al. (2023). Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495 DOI: 10.48550/arXiv.2309.11495

Historie úprav

Koncept: Codex CLI + GPT-5.2 Verze 1: Codex CLI + GPT-5.2

Jazyková revize (2026-02-25, Codex + GPT-5): upravena stylistika, zpřesněny formulace a omezeny anglicismy; návrh workflow a role panelu zůstávají zachovány. Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.