Jak sbírat chyby AI a proměnit je v lepší pracovní postup?

Jeden zaznamenaný omyl, jedna změna postupu

Sbírání chyb AI má smysl teprve tehdy, když z jednoho zaznamenaného případu vznikne konkrétní změna: úprava zadání, oprava vstupních podkladů, přidaný krok kontroly, nebo rozhodnutí úlohu tomuto nástroji dále nesvěřovat. Cesta od chyby ke změně vede přes tři kroky: přesný záznam toho, co se stalo, seskupení podobných případů podle společné příčiny a přiřazení příčiny k typu opravy. Bez tohoto postupu zůstávají chyby jen sbírkou historek, které si lidé pamatují různě a řeší nahodile, podle toho, kdo si na ně zrovna vzpomene.

Co si zapsat, když někdo chybu odhalí

Záznam vzniká v okamžiku, kdy je omyl skutečně odhalen; zpětná rekonstrukce o týden později, kdy si detaily nikdo přesně nepamatuje, už spolehlivý podklad nedává. Zapište čtyři věci: přesné zadání, které nástroj dostal, doslovnou nebo věrně parafrázovanou odpověď, konkrétní popis toho, co je na odpovědi špatně, a co by se stalo, kdyby chybu nikdo neodhalil a výstup prošel dál. Poslední bod je snadné vynechat, přitom právě on určuje naléhavost opravy: chyba v interním pracovním návrhu má jiný důsledek než chyba, kterou by později četl zákazník nebo úřad. Popis nesprávnosti pište konkrétně, tedy jaké tvrzení je vymyšlené (viz proč si AI vymýšlí halucinace), jaké skupině je odpověď nespravedlivě nakloněná, nebo jaký krok postupu chybí, místo obecného hodnocení jako „nekvalitní odpověď“. Zapisujte i chyby odhalené náhodou mimo běžnou kontrolu; takové případy často odhalí místo, kde kontrola úplně chybí, což je jiný typ problému než ojedinělé selhání kontroly, která jinak funguje.

Jak seskupit opakující se chyby do příčin

Jednotlivý záznam řekne, co se pokazilo jednou. Teprve když se v listu objeví víc případů se stejným rysem, ukazuje se, jestli jde o ojedinělou náhodu, nebo o opakující se vzorec, který zaslouží systémovou opravu. Seskupujte podle společné příčiny; povrchní podobnost tématu bývá zavádějící, protože dvě chyby v odpovědích o fakturaci mohou mít úplně jiný původ, pokud jedna vznikla z chybějícího podkladu a druhá z nejasně formulovaného zadání. Praktický způsob je projít poslední záznamy jednou za dohodnuté období a u každého si položit otázku, zda list už podobný případ obsahuje. Pokud ano, přidejte odkaz na předchozí záznam místo založení nového izolovaného řádku; tak vzniká viditelný počet výskytů dané příčiny, aniž je potřeba počítat jakékoli procento z celkového provozu.

Artefakt: záznamový list chyby a třídicí pravidlo

List má dvě části. První zachycuje jednotlivý případ, druhá určuje, jaký typ opravy odpovídá jaké příčině.

A. Záznam jednoho případu

Pole	Co se zapisuje
Datum a kdo odhalil	kdy a kým byla chyba zjištěna
Zadání	přesné znění dotazu nebo pokynu pro nástroj
Odpověď nástroje	doslovný nebo věrně parafrázovaný výstup
Co je špatně	konkrétní popis nesprávnosti místo obecného hodnocení kvality
Možný důsledek	co by nastalo, kdyby chyba prošla bez povšimnutí
Kde v postupu vznikla	zadání, vstupní podklad, samotná odpověď, nebo chybějící kontrola
Odkaz na podobné případy	číslo dřívějšího záznamu se stejnou příčinou, pokud existuje

B. Třídicí pravidlo

Třída chyby	Typický příznak	Odpovídající typ opravy
Nejasné zadání	na stejnou otázku vznikají různě použitelné odpovědi	úprava a ustálení formulace zadání
Chybějící nebo zastaralý podklad	odpověď je věcně nesprávná i při jasném zadání	doplnění či oprava vstupních podkladů
Chybějící krok kontroly	chyba projde dál, protože ji nikdo systematicky neověří	přidání bodu kontroly před předáním výstupu
Úloha přesahuje vhodné použití nástroje	selhání se opakuje i po opravě zadání i podkladů	vrácení úlohy do běžného lidského postupu

Od příčiny ke změně: zadání, podklady, kontrola, nebo konec použití

Když příčina ukazuje na zadání, oprava bývá nejlevnější: přeformulujte pokyn, přidejte příklad správné odpovědi nebo omezte rozsah otázky, a nový záznam v listu ukáže, zda se chyba opakuje i s upraveným zněním. Když příčina leží ve vstupních podkladech, samotná lepší formulace zadání nepomůže; nástroj odpovídá přesně na to, co dostal, a pokud byl podklad neaktuální nebo neúplný, dá i při dokonalém zadání chybnou odpověď. Tady se sběr chyb propojuje se správou platnosti zdrojových dokumentů: opakovaná chyba téhož typu často ukazuje na dokument, který měl být dávno označen jako nahrazený. Když příčina leží v chybějící kontrole, oprava spočívá v přidání konkrétního kontrolního kroku před předáním výstupu dál; úprava samotného zadání by tuto mezeru sama o sobě nezacelila, protože k prověřovanému riziku patří například i nakloněnost odpovědi vůči určité skupině lidí, jak popisuje článek o AI předsudcích. Poslední případ je nejtěžší přiznat: pokud stejná třída úlohy chybuje opakovaně i po opravě zadání, podkladů i kontroly, je namístě úlohu tomuto nástroji přestat svěřovat a vrátit ji do běžného lidského postupu. Trvání na použití AI u úlohy, která se opakovaně nedaří, jen prodlužuje dobu, po kterou vznikají další záznamy do listu chyb.

Kdy chybu nezobecňovat

Ne každý zaznamenaný případ zaslouží změnu postupu. Jediný ojedinělý omyl, u kterého se v listu nenajde žádný druhý podobný záznam, může být shoda okolností a nemusí ukazovat na skrytou systémovou chybu. Předčasná změna postupu po jediném případu má vlastní cenu: nový krok kontroly zpomaluje celý postup, a pokud se ukáže jako zbytečný, tým jej po čase přestane dodržovat, což oslabuje i ostatní, skutečně potřebné kontroly. Rozumným pravidlem je počkat na druhý nezávislý výskyt stejné příčiny, pokud důsledek prvního případu nebyl natolik závažný, aby vyžadoval okamžitou reakci bez čekání na potvrzení vzorcem. Souhrn tříd chyb a přijatých oprav se hodí probírat v pravidelném rytmu, podobně jako to popisuje audit AI systémů; pokud oprava spočívá v proškolení lidí, kteří zadání připravují, navazuje na to jak proškolit zaměstnance v AI.

Stav zdrojů a omezení

Tři citované zdroje NIST, ověřené 5. 8. 2026, popisují obecný rámec řízení rizik AI systémů; konkrétní pole záznamového listu a tabulku tříd chyb uvedenou výše si žádný z nich nenárokuje, jde o návrh CIAD. Funkce Measure a Manage v jádru NIST AI RMF podporují myšlenku průběžného sledování výkonu a nápravných kroků, aniž by předepisovaly jejich přesnou podobu. Playbook NIST AI RMF sám sebe označuje za soubor dobrovolných návrhů, nikoli za závazný kontrolní seznam; ve stejném duchu berte i tento článek, tedy jako výchozí bod k úpravě podle vlastního provozu. Číselné vyjádření četnosti chyb v textu záměrně chybí, protože bez řízeného vzorku a jasné definice závažnosti by jakékoli procento bylo zavádějící; návrh systematického vzorkování výstupů řeší samostatný text CIAD, tento článek začíná až u chyby, které si už někdo všiml.