Spolehlivost AI začíná mimo modelu

Za poslední týden se opakovaně objevilo jedno téma, pokaždé ale v jiném obalu. Model MIT simuloval extrémní bouři, která dosud neměla historický záznam. Chatboty odpovídaly na citlivou zdravotní otázku, ale uživateli neoznačily zaujaté zdroje. Roboti překonali lidský sprint, ale po doběhu potřebovali pomoc. AI při programování urychlila tvorbu kódu a zároveň zvýšila tlak na jeho kontrolu.

Na první pohled jde o nesouvisející zprávy. Všechny ale řeší stejnou praktickou otázku: dokážeme zjistit, kdy je výstup systému použitelný a kdy jen vypadá přesvědčivě?

Výzkum MIT ukazuje, že AI může vytvářet pravděpodobné scénáře i mimo historická data. To je užitečné, ale jen tehdy, když firma rozumí tomu, jaká data model potřebuje a kde jsou jeho hranice. Analýza AlgorithmWatch zase ukázala, že chatbot může podat formálně relevantní odpověď a současně selhat v transparentnosti.

To je rozdíl mezi schopností a spolehlivostí. Schopnost znamená, že systém něco dokáže. Spolehlivost znamená, že firma ví, kdy to dokáže, kdy ne, co se stane při chybě a kdo ji zachytí.

Veřejný benchmark na firemní otázku neodpoví

Benchmark, tedy standardizovaný testovací soubor, je užitečný při porovnávání modelů. Bez něj by se výběr technologie změnil v soutěž marketingových prezentací. Benchmark ale měří průměrný výkon v připravených podmínkách. Firma potřebuje vědět, co se stane s jejím konkrétním dokumentem, zákazníkem nebo pracovním postupem.

Výzkum No Universal Signal Predicts Sample-Level LLM Regression under Version Updates porovnával aktualizované verze modelů na několika typech úloh. Autoři sledovali otázky s výběrem odpovědi, matematiku a generování kódu. Zjistili, že neexistuje jediný univerzální signál, který by spolehlivě předpověděl, zda nová verze zlepší, nebo zhorší každý konkrétní případ.

Nešlo o drobný technický detail. Nový model může mít lepší celkové skóre, a přitom hůř odpovídat na otázku, která je pro firmu kritická. Může přesněji řešit obecnou matematiku, ale nesprávně vypočítat slevu podle interního ceníku. Může lépe psát kód, ale změnit chování starého integračního rozhraní.

To je důvod, proč žebříček modelů není nákupní rozhodnutí. Je jen prvním sítem. Při rozhodování je třeba oddělit nejméně čtyři věci: obecnou schopnost modelu, chování na vlastních datech, cenu za zpracování a riziko chyby.

Výzkum PerceptionBench podobně rozlišuje mezi viděním a uvažováním. Multimodální model může působit inteligentně při popisu obrázku, ale selhat u základní vizuální úlohy. Pro sklad, výrobu nebo kontrolu dokladů je takový rozdíl praktický, nikoli akademický.

Vlastní eval set, tedy testovací soubor reálných případů, proto patří mezi základní vybavení každého pravidelně používaného AI systému. Na začátek stačí 50 až 200 anonymizovaných příkladů. Měly by obsahovat běžné úkoly, hraniční situace, neúplné vstupy a případy, u nichž je chybná odpověď drahá nebo nebezpečná.

Důležité je i správné rozdělení příkladů. Pokud firma testuje jen běžné požadavky, měří ideální provoz. Do souboru je třeba zařadit také dokument s chybějící stranou, zákazníka s nejasným dotazem, starou verzi ceníku nebo text, který obsahuje pokyn určený modelu. Poslední případ je forma prompt injection (podvržení pokynu do vstupních dat), nikoli běžný požadavek uživatele.

Testovací soubor nesmí zůstat navždy stejný. Každá nová chyba z provozu se má stát novým testovacím případem. Jinak firma opakuje stejnou chybu s čím dál větší důvěrou v graf, který už dávno neodpovídá realitě.

Největší riziko vzniká mezi výstupem a rozhodnutím

Odpověď ještě není rozhodnutí

Chatbot může najít zdroj, robot může provést pohyb a agent může odeslat zprávu. Žádný z těchto výkonů ale automaticky neznamená, že systém může rozhodovat místo člověka.

U zdravotní otázky je problémem zamlčená zaujatost zdroje. U obsahového marketingu je problémem text bez vlastní hodnoty. U automatizovaného rozhodování o řidičích může být problémem vypnutí účtu bez vysvětlení. Zpráva Engadgetu o pokutě pro Uber ukazuje, že automatické rozhodnutí má právní i lidské důsledky, i když vzniklo v softwaru.

Při rozhodování o úrovni automatizace pomáhá rozdělit proces do tří stupňů. Prvním je návrh. AI připraví podklad a člověk rozhodne. Druhým je asistované provedení. Systém udělá část práce, ale před zápisem nebo odesláním potřebuje schválení. Třetím je automatické provedení bez kontroly každého případu.

Většina firem by měla začít na první nebo druhé úrovni. Automatické provedení patří jen tam, kde je proces dobře popsaný, chyba má omezený dopad a existuje jednoduchá cesta zpět. Pokud systém posílá návrhy odpovědí, oprava je levná. Pokud mění ceny, ruší objednávky nebo rozhoduje o nároku zákazníka, stejný model potřebuje mnohem přísnější hranice.

Námitka zní rozumně: lidská kontrola snižuje úsporu. Pokud má zaměstnanec číst každý výstup, proč AI vůbec používat? Odpověď závisí na procesu. Kontrola návrhu může být podstatně rychlejší než psaní od začátku. Zároveň je ale třeba měřit skutečný čas po kontrole. Pokud pracovník opravuje každý druhý výstup, systém nevytvořil automatizaci. Vytvořil nový redakční úkol.

Tiché selhání je horší než výpadek

Systému, který přestane fungovat a ohlásí chybu, si někdo všimne. Horší je systém, který dál vytváří odpovědi, ale jejich kvalita se potichu zhoršila.

Takový problém může vzniknout změnou modelu, úpravou promptu, změnou dokumentů, novým formátem dat nebo aktualizací rozhraní dodavatele. U agentů přibývá další riziko. Agent může mít přístup k nástrojům, které mu umožní upravit objednávku, poslat e-mail nebo změnit záznam v systému.

Každá automatizace proto potřebuje monitoring. Firma má sledovat počet zpracovaných případů, chybovost, podíl zásahů člověka, čas do opravy a náklady na jeden případ. U generativního systému je navíc třeba náhodně kontrolovat výstupy, ne pouze měřit počet úspěšně dokončených úloh.

Smysl má i jednoduchý alerting (upozorňování na problém). Pokud podíl ručních oprav překročí dohodnutý limit, systém má zastavit automatické odesílání a oznámit to vlastníkovi procesu. Pokud integrace nevrátí odpověď nebo začne vracet prázdná data, nemá se pokračovat s předpokladem, že je vše v pořádku.

Systém musí mít také kill switch, tedy způsob rychlého vypnutí. Nemusí jít o složitou bezpečnostní platformu. V malé firmě může být řešením vypnutí automatického kroku v nástroji, přesměrování úloh do schvalovacího seznamu a jasné určení člověka, který to smí udělat.

Dobré skóre na začátku projektu nestačí. Provozní systém musí umět říct, že se zhoršil. Jinak měří jen sebevědomí vlastníka projektu.

Data určují, co může AI předpovídat

Metoda MIT Extreme Event Aware, označovaná také jako η-learning, je dobrým příkladem toho, co AI umí a co neumí. Výzkumníci Kai Chang a Themis Sapsis pracovali s 25 lety hodinových údajů o dešti, které seskupili do denních map. Pro prostorovou část modelu ale použili pouze prvních šest měsíců záznamu, tedy období s malým počtem silných dešťů.

Model dokázal vytvořit pravděpodobnou mapu události s denním úhrnem 300 milimetrů, ačkoli nejvyšší zaznamenaný úhrn v New Yorku činil 200 milimetrů. Simulace obsahovala také odhad trvání, intenzity, velikosti a zasažené oblasti.

Hodnota této metody nespočívá v tom, že „uhádne budoucnost“. Model využívá existující statistické a prostorové vztahy k vytvoření scénáře, který se dosud nestal. Autoři zároveň upozorňují, že potřebuje relevantní bodové statistiky a prostorová data. Demonstrace se týkala amerických srážek, nikoli povodí Dunaje nebo Moravy.

To je dobrá odpověď i na častou námitku, že AI přece neumí předpovídat něco, co nikdy neviděla. Nemusí kopírovat konkrétní historickou událost. Může kombinovat vzorce, které v datech existují, a vytvořit nový pravděpodobný scénář. Zároveň ale nedokáže spolehlivě odhadnout proměnnou, kterou firma vůbec nesbírá.

Pokud chce například předpovídat výpadky dodávek, potřebuje nejen historii objednávek. Potřebuje také údaje o dodacích lhůtách, reklamacích, sezonnosti, závislosti na konkrétních dodavatelích a případně počasí. Pokud tyto proměnné chybějí, systém může vytvořit přesvědčivou simulaci, ale ne spolehlivý plán.

Data mají tři vrstvy. První je pokrytí, tedy zda firma vůbec eviduje potřebné události. Druhou je kvalita, tedy zda jsou údaje úplné, konzistentní a správně označené. Třetí je časová platnost. Starý ceník nebo změněná logistická trasa mohou být technicky dostupné, ale pro dnešní rozhodnutí nesprávné.

Při zavádění AI se proto vyplatí vést katalog dat. U každého procesu má být jasné, odkud vstupy pocházejí, jak často se aktualizují, kdo je vlastní, jaká mají omezení a co v nich chybí. Tato práce je méně atraktivní než výběr modelu. Je však blíž výsledku.

Pokud firma používá externí model, přibývá otázka, kam data odcházejí. Při nákupu je třeba zjistit, zda dodavatel používá vstupy k trénování, jak dlouho uchovává konverzace, v jaké zemi je zpracovává a zda poskytuje auditní stopu. Smlouva má řešit také export dat a ukončení služby. Uzavřenost je náklad, který se projeví až později.

Modely se mění, proto se musí měnit i testování

Aktualizace modelu je ve firmě často vnímána jako technické zlepšení. Ve skutečnosti může jít o změnu pracovního nástroje. Jinak se může chovat při stejném promptu, stejném dokumentu i stejném požadavku.

Při každé změně je třeba zopakovat regresní test (ověření, zda se nezhoršily existující funkce). Nemusí pokrývat celý internet ani všechny schopnosti modelu. Musí pokrývat úkoly, za které firma ručí. Pokud AI třídí poptávky, test má ověřit kategorie, chybějící údaje, duplicitní požadavky a nesprávné zařazení. Pokud připravuje shrnutí smlouvy, test má obsahovat také výjimky, lhůty a finanční závazky.

Praktické je rozdělit výsledky do tří skupin. Pass znamená, že výstup splňuje pravidla. Review znamená, že odpověď může pokračovat jen po kontrole člověkem. Fail znamená, že systém nesmí výstup použít a případ se má vrátit do ručního procesu.

Takové označení je užitečnější než jedno celkové procento. U kritické úlohy může být průměr 95 % přijatelný, ale zbývajících 5 % může obsahovat chybu v platbě nebo právní lhůtě. Firma potřebuje vědět, jaké chyby se v průměru skrývají.

Důležitý je také denominator, tedy jmenovatel výpočtu. „AI zpracovala 1 000 případů“ neříká, kolik jich bylo správných. „90 % automatizace“ nemusí znamenat, že 90 % práce zmizelo. Může to znamenat jen to, že systém vytvořil 900 návrhů, které někdo musel zkontrolovat.

Stejně tak je třeba odlišit přesnost od úplnosti. Odpověď může být fakticky správná, ale vynechat důležitou výjimku. Chatboty v analýze AlgorithmWatch nebyly problematické jen proto, že odkazovaly na konkrétní stránky. Selhání spočívalo také v tom, že uživateli neřekly, z jaké pozice zdroj mluví.

U firemního obsahu je podobné riziko běžné. Text může být gramaticky bezchybný, ale nemusí obsahovat vlastní zkušenost firmy, ověřitelný zdroj ani rozhodnutí, které má pro čtenáře hodnotu. Výzkum Pew Research Center ukázal, že přibližně 35 % novějších anglických stránek neslo významné znaky autorství nebo úprav pomocí AI. Samotná přítomnost AI však není důkazem nízké kvality. Rozhodující je redakční proces.

Jak to použít: kontrola před nasazením

Běžná firma s dvaceti lidmi nepotřebuje oddělení datových vědců. Potřebuje člověka, který vlastní proces, člověka, který rozumí datům, a jednoduchý záznam výsledků. Postup může vypadat takto:

1. Vyberte jeden opakovaný úkol. Ne „zaveďme AI do marketingu“, ale například třídění příchozích poptávek, kontrola úplnosti faktur nebo příprava návrhu odpovědi zákazníkovi.
2. Popište dnešní ruční postup. Uveďte vstup, jednotlivé kroky, výjimky, odpovědného člověka a čas zpracování. Pokud proces nikdo neumí popsat, ještě není připravený na automatizaci.
3. Sestavte vlastní testovací soubor. Použijte anonymizované reálné případy. Rozdělte je na běžné, hraniční a kritické.
4. Přidejte negativní případy. Zahrňte neúplný dokument, protichůdné údaje, neplatný formát a vstup s pokynem, který nemá patřit do pracovního procesu.
5. Definujte toleranci chyby. U návrhu předmětu e-mailu může být přijatelné, že člověk upraví každou pátou verzi. U výpočtu ceny nebo právního stanoviska nikoli.
6. Určete úroveň oprávnění. Na začátku nechte AI číst a navrhovat. Odesílání, mazání a zápis do klíčových systémů by měly vyžadovat schválení.
7. Změřte výchozí stav. Zapište čas na jeden případ, počet chyb, počet zásahů člověka a cenu práce. Bez toho nelze vypočítat návratnost.
8. Spusťte zkušební provoz. AI může připravovat výsledky paralelně s člověkem. Porovnávejte je alespoň jeden pracovní týden nebo během 50 až 100 případů.
9. Zaveďte monitoring. Kontrolujte náhodný vzorek výstupů a nastavte upozornění při růstu chybovosti, neobvyklém počtu výjimek nebo výpadku integrace.
10. Po aktualizaci test zopakujte. Změna modelu, promptu nebo zdrojových dat je změna systému. Neberte ji jako technický detail.
11. Rozhodněte podle výsledku. Systém buď rozšiřte, upravte, nebo vypněte. Pilot bez rozhodnutí je jen déle trvající prezentace.

Jak počítat cenu

Cena AI systému není jen měsíční předplatné. Je třeba připočítat nastavení, integraci, čas na přípravu dat, kontrolu výstupů, údržbu a náklady na chyby.

Jednoduchý výpočet může vypadat takto:

čistá úspora = ušetřený čas × interní hodinová cena - cena nástroje - kontrola - údržba - náklady na chyby

Pokud pracovník dnes stráví zpracováním jednoho dotazu 12 minut a AI zkrátí přípravu na 4 minuty, automaticky to neznamená osm minut úspory. Pokud musí každou odpověď dalších 4 minuty ověřovat, čistý zisk je menší. Pokud se ušetřený čas nevyužije na jinou hodnotnou práci, finanční úspora nemusí vzniknout vůbec.

U agenta je třeba do kalkulace zahrnout také údržbu integrací. Cena nasazení může být nízká, ale změna API nebo oprávnění na straně dodavatele vytvoří opakovanou práci. Automatizace, která funguje jen do chvíle, než se změní obrazovka v cizí aplikaci, není levná. Jen zatím nevystavila účet.

U agenta přidejte zkoušku s nepřátelskými vstupy. Ověřte, zda ignoruje pokyn vložený do cizího dokumentu, zda nepřekročí oprávnění a zda lze jeho krok zrušit. U citlivých dat sepište, co může dodavatel ukládat, kde se data zpracovávají a jak firma službu opustí.

Co to znamená pro slovenskou a českou firmu

Pro firmu na Slovensku nebo v Česku je prvním důsledkem změna vlastníka AI projektu. Nemělo by ho vlastnit jen IT oddělení. IT umí připojit nástroj, nastavit přístup a řešit bezpečnost. O tom, zda je odpověď správná, však musí rozhodovat člověk, který zná proces a odpovídá za jeho výsledek.

V malé firmě může tuto úlohu zastávat jeden vlastník procesu. Musí mít čas jednou týdně projít vzorek výstupů, zapsat chyby a rozhodnout, zda se změnil pracovní postup. Pokud to nikdo nemá v pracovní náplni, kontrola po prvním nadšení zmizí.

Druhým důsledkem je změna výpočtu návratnosti. Firma nemá počítat jen počet vygenerovaných odpovědí. Má porovnat čas do dokončení, počet oprav, počet eskalací, reklamace a hodnotu práce, kterou zaměstnanec využil jinde.

Rozdíl mezi slovenským a českým trhem zde není technologický. Běžná firma v obou zemích řeší stejný problém, má omezený počet lidí a často nemá vlastní datový tým. Rozdíl může vzniknout v právním detailu, jazyce nebo konkrétním regulovaném odvětví. Zdravotnictví, finance a pracovněprávní rozhodnutí je proto třeba posuzovat podle místních pravidel a podle toho, kde firma působí.

U slovenského a českého jazyka je navíc třeba testovat lokální formulace. Model může mít dobré skóre v angličtině a hůře rozlišovat odborné zkratky, obchodní podmínky nebo právní výrazy ve slovenštině a češtině. U zákaznické podpory je třeba sledovat také tón, vykání, diakritiku a schopnost pracovat se smíšeným jazykem. Není to kosmetika. Nesprávné oslovení neohrozí sklad, ale může snížit důvěru ve značku.

Třetí důsledek se týká nákupu. U dodavatele se ptejte na export dat, změnu modelu, uchovávání konverzací, auditní log, dostupnost oprávnění a cenu při růstu objemu. Cena pilotu může být nízká. Nákladem se stane až údržba, když dodavatel změní API, model nebo podmínky zpracování.

Do rozhodnutí patří také otázka, co se stane při výpadku. Pokud je AI jen pomocníkem při návrhu odpovědi, firma může pokračovat ručně. Pokud systém řídí příjem objednávek, musí existovat manuální režim. Provoz bez záložního postupu je závislost, nikoli efektivita.

V horizontu jednoho týdne lze zavést testovací soubor a manuální porovnání. V horizontu jednoho měsíce lze přidat dashboard s chybami, náklady a zásahy člověka. Do jednoho čtvrtletí by firma měla vědět, které případy může automatizovat, u kterých má pouze asistovat a které má zcela ponechat člověku.

Největší výhodou malé firmy není rozpočet. Je to kratší rozhodovací řetězec. Zatímco velká organizace schvaluje rámec AI governance, tedy řízení používání AI, menší firma může mít vlastní test, pravidla přístupu a odpovědného vlastníka hotové během několika dní.

Co si o tom myslím a co z toho plyne pro firmy

Názor

Za největší chybu považuji otázku, který model je nejlepší. Výzkum regrese po aktualizaci ukazuje, že neexistuje jednoduchý signál, který by ochránil každý konkrétní firemní případ. MIT dokázal vytvářet scénáře mimo historické záznamy, ale výsledek stále závisí na kvalitě vstupních dat a správné interpretaci. U analýzy chatbotů jsme viděli opačný problém: systém dokázal najít relevantní zdroj, ale nepojmenoval jeho zaujatost. Schopnost bez kontextu není spolehlivost.

Firmám bych proto nedoporučoval začínat velkým AI projektem. Začal bych jedním úkolem, vlastním testovacím souborem a měřením před nasazením. Pokud dodavatel neumí ukázat, jak se systém chová při chybě, nenabízí hotový produkt, ale jen demonstraci. A prezentace není výsledek. Výsledkem je proces, který běží každý den a firma ho dokáže sama kontrolovat.

Stejně tak odmítám představu, že lidská kontrola je jen dočasná berlička, kterou je třeba co nejdříve odstranit. U některých jednoduchých procesů se její rozsah může zmenšit. U rozhodnutí s právním, finančním nebo bezpečnostním dopadem však zůstane součástí systému. Automatizovat lze jen to, co někdo umí popsat, otestovat a v případě chyby vrátit zpět.

Důsledek pro firmy

Praktická změna se týká tří lidí. Vlastník procesu musí pojmenovat, jak vypadá správný výstup. IT nebo externí dodavatel musí omezit přístupy a nastavit logování. Uživatel musí mít jednoduchý způsob, jak označit chybu a vrátit případ člověku.

To nevyžaduje drahý datový tým. Vyžaduje to disciplínu. Pomocí testovacího souboru firma rychle zjistí, zda AI šetří čas, nebo jen přesouvá práci do kontroly. Pokud systém vytvoří více oprav, než kolik ušetří, nemá se škálovat jen proto, že je nový.

Rozhodování by mělo mít tři brány. Nejprve kvalitu, tedy zda odpověď splňuje pravidla. Poté ekonomiku, tedy zda se po započtení kontroly vyplatí. Nakonec riziko, tedy co se stane při nejhorším rozumně předvídatelném selhání. Teprve když projdou všechny tři, může automatizace získat širší oprávnění.

Tento přístup se hodí pro slovenskou i českou firmu, která nemá velký rozpočet ani datové vědce. Menší tým si nemůže dovolit deset paralelních pilotů bez vlastníka. Může si ale dovolit jeden test, týden měření a rozhodnutí založené na vlastních případech. Právě to je často rychlejší než další výběr nástroje.

U každé automatizace bych trval také na odpovědi na tři nepříjemné otázky: Kdo si všimne zhoršení? Kdo systém vypne? Kdo rozhodne, zda se má opravit, nebo odstranit? Pokud na ně firma neumí odpovědět, problémem není nedostatek AI. Problémem je, že proces nemá vlastníka.

Výzva k AI implementaci dne

Během jednoho týdne nasaďte jednoduchý firemní eval set pro jeden AI úkol. Vyberte 50 anonymizovaných případů z e-mailů, dokumentů nebo zákaznické podpory. Ke každému napište správný výsledek, označte kritickou chybu a doplňte alespoň pět hraničních případů, u nichž má systém raději požádat o kontrolu člověka.

Nástrojem může být obyčejná tabulka s výstupy používaného modelu. Nemusí jít o nový software. Tento krok ušetří vlastníkovi procesu část ručního hádání a člověku z IT pozdější hašení problémů. Za jeden pracovní den ho dokáže připravit dvojice lidí. Vyhodnocení 50 případů zabere přibližně 3 až 5 hodin.

Nejčastěji to ztroskotá na tom, že firma testuje umělé otázky místo reálných případů nebo si předem nedefinuje, co znamená správná odpověď. Vyberte dnes jeden úkol a zítra změřte prvních 50 výsledků, než se z AI stane další projekt bez vlastníka.