Jak připravit pilot

Když si koupíš nové kolo, nejdřív se na něm projedeš po parkovišti. Pak ho vezmeš na cestu do práce a zjistíš, jestli se vejde do výtahu, jestli tě nebolí záda a jestli ho máš kde zamknout. Teprve potom prodáš auto. Zavádění AI ve firmě má stejné tři kroky, jen se jim říká proof of concept, pilot a provoz. A stejně jako u kola se nejvíc peněz ztratí tam, kde někdo přeskočí ten prostřední.

V předchozím modulu jsi vybral případy použití (Od cílů k případům použití) a seřadil je do roadmapy. Tahle lekce řeší, jak z prvního řádku roadmapy udělat pilot, který na konci dá jasnou odpověď. Ne „lidem se to celkem líbilo“, ale „ušetřili jsme tolik a tolik, chyb bylo tolik, doporučujeme pokračovat“.

Tři různé otázky: PoC, pilot, provoz

Ty tři pojmy se ve firmách pletou a z toho vzniká spousta zmatku. Každý z nich odpovídá na jinou otázku.

Proof of concept (PoC)(proof of concept)

Krátký technický pokus, který ověřuje, jestli řešení v principu funguje: zvládne model úlohu na vzorku skutečných dat? Dělá ho obvykle jeden nebo dva lidé, mimo běžný provoz, bez skutečných uživatelů.

Pilot(pilot)

Omezené nasazení u skutečných uživatelů ve skutečném procesu, na předem danou dobu a s předem daným měřením. Ověřuje, jestli řešení funguje v praxi: jestli ho lidé používají, jestli šetří čas a jestli nepřináší nové chyby.

	Proof of concept	Pilot	Provoz
Otázka	Dá se to technicky udělat?	Funguje to pro lidi v reálné práci?	Jak to udržet, rozšířit a hlídat?
Kdo	Jeden až dva lidé, často IT nebo dodavatel	Malý tým skutečných uživatelů	Všichni, kdo proces dělají
Data	Vzorek, často ručně vybraný	Skutečný provoz, ale omezený rozsah	Všechno
Výsledek	„Ano, model to zvládne v 8 z 10 případů“	Čísla proti výchozímu stavu a rozhodnutí	Měřený a řízený proces
Typické selhání	Ukázka na vybraných příkladech	Žádná kritéria, takže žádné rozhodnutí	Nikdo nehlídá kvalitu a náklady

PoC můžeš někdy přeskočit. Když nasazuješ hotový nástroj, který už jinde funguje (třeba asistenta v kancelářském balíku), technická otázka je zodpovězená a začínáš rovnou pilotem. Když stavíš vlastní řešení nad firemními daty (viz RAG v praxi), PoC ti levně řekne, jestli vůbec má smysl pokračovat.

Pilot ale nepřeskakuj nikdy. PoC ukáže, že model umí napsat dobrou odpověď. Neukáže, že ji agent podpory stihne zkontrolovat, že ho nástroj nezdržuje přepínáním oken a že zákazníci nezačnou dostávat odpovědi, které „zní jako robot“. To se dozvíš jen od lidí v reálné práci.

Jak vybrat proces na pilot

První pilot má jediný hlavní úkol: dát jasnou odpověď a naučit firmu, jak se piloty dělají. Proto nevybírej nejdůležitější ani nejzajímavější proces, ale ten, na kterém se dá nejlíp poznat výsledek. Dobrý kandidát splňuje pět podmínek:

1. Je skutečný a častý. Úloha, která se děje desítkykrát týdně, ne jednou za kvartál. Jen tak za pár týdnů nasbíráš dost dat na rozumné závěry.
2. Je ohraničený. Jasný začátek a konec („přijde dotaz, odejde odpověď“), jeden tým, jeden systém. Pilot, který zasahuje do pěti oddělení, se rozpadne na koordinaci.
3. Má motivovaný tým. Lidé, kteří úlohu dělají, ji chtějí zlepšit a mají na pilot čas. Vedoucí, který jim ten čas dá. Pilot vnucený týmu, který je zavalený prací, změří hlavně odpor.
4. Výsledek jde změřit. Čas, počet, kvalita podle jasných pravidel. Pokud nedokážeš říct, jak by vypadal úspěch v číslech, proces zatím na pilot není.
5. Chyba je zachytitelná. Na první pilot volíš proces, kde výstup před odchodem zkontroluje člověk. Úlohy, kde se chyba projeví až za měsíc u zákazníka, nech na později.

Tyhle body se z velké části překrývají s hodnocením případů použití z kurzu AI ve firmě. Rozdíl je v tom, že teď nehledáš největší přínos, ale nejčistší test.

Zadání pilotu: jedna stránka, která rozhodne o úspěchu

Většina pilotů, které skončí v nejistotě, neselhala na technice. Selhala na tom, že na začátku nikdo nenapsal, co přesně se zkouší a jak se pozná výsledek. Proto každý pilot začíná dokumentem, kterému se říká zadání nebo charta pilotu.

Zadání pilotu(pilot charter)

Krátký dokument (ideálně jedna až dvě strany), který před startem pilotu určí problém, hypotézu, rozsah, uživatele, kritéria úspěchu, výchozí měření, rizika, termíny, rozpočet a datum rozhodnutí. Podepíše ho ten, kdo bude o pokračování rozhodovat.

Projdeme jeho části jednu po druhé. Na konci najdeš vyplněnou šablonu.

Problém a hypotéza

Problém popiš řečí byznysu, ne technologie. Ne „chceme vyzkoušet AI v podpoře“, ale „odpověď na e-mailový dotaz trvá průměrně dva pracovní dny a zákazníci si stěžují“. Hypotéza pak říká, co si myslíš, že AI změní, a proč: „Když agent dostane návrh odpovědi, který jen zkontroluje a upraví, zkrátí se čas na odpověď, aniž by klesla kvalita.“

Dobrá hypotéza se dá vyvrátit. „AI nám pomůže“ vyvrátit nejde, a proto z ní nic nevyplyne.

Rozsah a uživatelé

Napiš, co do pilotu patří a co ne. Které typy dotazů, který jazyk, který kanál, kolik lidí, jak dlouho. Stejně důležité je, co výslovně nepatří: reklamace s právními nároky, VIP zákazníci, cokoli, kde by chyba stála víc, než pilot unese.

U uživatelů uveď jména nebo aspoň role a počet. A rozmysli, jestli bude mít pilot srovnávací skupinu: část týmu nebo část dotazů bez AI ve stejném období. Je to nejsilnější způsob, jak oddělit vliv AI od všeho ostatního, co se mezitím změní (sezóna, nový produkt, nemoc v týmu). Víc o tom v lekci Jak pilot vyhodnotit.

Výchozí měření

Tohle je část, kterou firmy vynechávají nejčastěji, a bez ní nedokážeš nic. Pokud nevíš, jak dlouho úloha trvá a jak dobře se dělá dnes, nemůžeš na konci říct, jestli ji AI zlepšila. Zbude ti jen pocit.

Výchozí měření(baseline)

Změřený stav procesu bez AI, se kterým pak srovnáváš výsledky pilotu. Měří se stejnými metrikami a stejným způsobem jako pilot, ideálně na srovnatelném vzorku práce.

Výchozí měření naplánuj na dobu před startem, nebo ho veď souběžně ve srovnávací skupině. Zdroje bývají tři:

• Data ze systémů. Helpdesk, CRM nebo tiketový systém často zná čas od přijetí po odpověď, počet znovuotevřených tiketů, hodnocení zákazníků. Je to nejlevnější a nejpoctivější zdroj.
• Měření vzorku. Pokud systém čas práce nezná, nech pár lidí týden zapisovat, kdy úlohu začali a skončili. Je to otravné, ale stačí to na jeden týden.
• Hodnocení kvality. Vezmi náhodný vzorek dnešních výstupů (třeba 50 odpovědí) a nech je ohodnotit podle stejných pravidel, podle kterých budeš hodnotit výstupy s AI. Jak se taková pravidla stavějí, popisuje lekce Měření kvality.

Kritéria úspěchu: rozhodni předem, s čísly

Kritéria úspěchu píšeš před startem a s konkrétními prahy. Ne „čas se zkrátí“, ale „medián času na odpověď klesne aspoň o 25 % proti výchozímu měření“. Ne „kvalita neklesne“, ale „průměrné hodnocení kvality od kontrolora neklesne o víc než 0,2 bodu na pětibodové škále“.

Proč předem? Protože po skončení pilotu má každý důvod vidět výsledek příznivě. Tým, který na pilotu pracoval, chce, aby se povedl. Dodavatel chce prodat. A když čísla vyjdou jinak, než se čekalo, vždycky se najde jiná metrika, která vypadá líp. Předem napsané prahy tohle pokušení vypnou. Dokumentace Anthropicu k hodnocení modelů to shrnuje dobře: kritérium má být konkrétní, měřitelné, dosažitelné a relevantní pro účel, a obvykle jich potřebuješ víc najednou.

Užitečné je rozlišit tři pásma:

• Úspěch (pokračujeme): všechna kritéria splněna.
• Šedá zóna (iterujeme): hlavní přínos je vidět, ale něco chybí. Předem si napiš, co by se muselo změnit a kolik dalšího času na to dáš.
• Neúspěch (končíme): hlavní metrika se nepohnula nebo „brzda“ překročila limit, třeba chybovost.

Odkud vzít rozumné prahy? Z toho, kolik musí řešení přinést, aby se vyplatilo (náklady a přínosy jsi odhadoval v lekci Náklady, přínosy a rizika), a z toho, co se dá realisticky čekat. Pro představu: velká studie Brynjolfssona, Li a Raymondové sledovala přes pět tisíc agentů zákaznické podpory jedné firmy a naměřila v průměru zhruba o 14 % víc vyřešených dotazů za hodinu, u začínajících agentů víc, u zkušených skoro nic. Je to jedna firma, jeden nástroj a jedna doba, takže to není číslo, které máš čekat ty. Ukazuje ale, že realistické zlepšení bývá v desítkách procent, ne v násobcích, a že se může mezi lidmi hodně lišit.

Data a přístupy

Vypiš, k jakým datům bude AI mít přístup (historie tiketů, znalostní báze, ceník), odkud a v jaké podobě. A kdo ty přístupy schválí. U pilotu platí pravidlo nejmenšího nutného přístupu: model dostane jen to, co úloha opravdu potřebuje. Je to otázka bezpečnosti i práva. Proč a jak, rozebírá lekce Oprávnění a lidská kontrola.

Rizika a pojistky

Sepiš, co se může pokazit, a ke každému riziku pojistku. Typicky:

• Chybná nebo smyšlená informace v odpovědi. Pojistka: žádná odpověď neodejde bez schválení agentem.
• Únik osobních údajů nebo interních informací. Pojistka: smluvně ošetřený nástroj, omezený přístup k datům.
• Zneužití přes obsah zprávy (zákazník do e-mailu napíše pokyny pro model). Pojistka: model nemá oprávnění nic provést, jen navrhuje text. Viz Prompt injection.
• Lidé přestanou kontrolovat. Pojistka: namátková kontrola vzorku schválených odpovědí druhým člověkem.

Ke každé pojistce patří i „stop tlačítko“: kdo a při čem může pilot okamžitě zastavit.

Právní kontrola

Před startem si ověř tři věci, a pokud si nejsi jistý, přizvi někoho, kdo se v tom vyzná. Zpracovávají se osobní údaje, a pokud ano, na jakém základě a s jakou smlouvou s dodavatelem (Osobní údaje, Smlouvy s dodavateli)? Do jaké kategorie podle AI Actu použití spadá (Kategorie rizika)? A víš, že lidé komunikují s AI tam, kde to mají vědět? Pilot na skutečných zákaznících je skutečné zpracování dat, ne „jen test“.

Termíny, rozpočet a datum rozhodnutí

Pilot by měl být krátký. Jako vodítko: počítej spíš na týdny než na měsíce. Typicky jeden až dva týdny přípravy a výchozího měření, několik týdnů ostrého běhu (aby odezněla počáteční novost a lidé si nástroj osvojili) a týden na vyhodnocení. Pilot, který trvá půl roku, přestane být testem a stane se z něj provoz bez rozhodnutí.

Rozpočet zahrnuje licence nebo cenu za použití modelu, čas lidí (i ten na měření a hodnocení), případně dodavatele. A hlavně: do zadání napiš konkrétní datum, kdy padne rozhodnutí, a jméno toho, kdo rozhoduje. Bez toho pilot skoro jistě skončí v nekonečném „ještě to chvíli zkusíme“.

Do hloubkyProč tolik pilotů nikdy neskončí rozhodnutím+

Analytická firma Gartner v červenci 2024 předpověděla, že nejméně 30 % projektů generativní AI bude do konce roku 2025 opuštěno po fázi proof of concept. Jako důvody uvedla špatnou kvalitu dat, nedostatečnou kontrolu rizik, rostoucí náklady a nejasnou obchodní hodnotu. Je to předpověď, ne změřený výsledek, ale ty čtyři důvody dobře sedí na to, co se v praxi děje.

Všimni si, že tři ze čtyř se dají odhalit už při psaní zadání. Kvalitu dat prověříš v sekci „data a přístupy“. Rizika v sekci „rizika a pojistky“. A „nejasná obchodní hodnota“ je přesně to, co vzniká, když chybí výchozí měření a předem dané prahy. Projekt pak nemůže prokázat přínos, i když nějaký má.

Opuštěný projekt přitom nemusí být špatně. Pokud skončil levně a rychle a víš proč, je to dobrý výsledek. Špatné je, když skončí po roce, bez čísel a bez poučení. O tom víc v další lekci.

Vyplněná šablona: návrhy odpovědí v zákaznické podpoře

Následující příklad je vymyšlený, včetně čísel. Ukazuje, jak konkrétní má zadání být. Zkopíruj si ho a přepiš na svůj proces.

Vlastník pilotu: Jana N., vedoucí zákaznické podpory. Rozhoduje: Petr K., provozní ředitel.

Problém: Odpověď na e-mailový dotaz trvá v mediánu 26 pracovních hodin. Agenti tráví většinu času dohledáváním informací ve znalostní bázi a psaním opakujících se odpovědí.

Hypotéza: Pokud agent dostane návrh odpovědi postavený na znalostní bázi a historii objednávky, který zkontroluje, upraví a sám odešle, zkrátí se čas práce na jeden dotaz a tím i doba odezvy, aniž by klesla kvalita odpovědí.

Rozsah: E-mailové dotazy v češtině, kategorie „stav objednávky“, „doprava“, „vrácení zboží“. Mimo rozsah: reklamace s nárokem na náhradu škody, firemní zákazníci, sociální sítě. Model nemá přístup k platebním údajům a nemůže nic odeslat sám.

Uživatelé: 4 agenti v pilotní skupině, 4 agenti ve srovnávací skupině bez AI. Dotazy se mezi skupiny rozdělují náhodně, jak je dnes rozděluje helpdesk.

Výchozí měření (2 týdny před startem): čas práce na dotaz z helpdesku, doba odezvy, podíl znovuotevřených tiketů, hodnocení kvality 50 náhodných odpovědí dvěma hodnotiteli podle pětibodové stupnice (správnost, úplnost, tón).

Kritéria úspěchu (porovnání se srovnávací skupinou za týdny 3–6):

Metrika	Práh pro „pokračujeme“	Práh pro „končíme“
Medián času práce na dotaz	pokles aspoň o 25 %	pokles pod 10 %
Hodnocení kvality (1–5)	pokles nejvýš o 0,2	pokles o víc než 0,5
Věcné chyby v odeslaných odpovědích (namátková kontrola)	nejvýš na úrovni výchozího měření	výrazně nad výchozím měřením
Podíl dotazů, kde agent návrh použil	aspoň 60 %	pod 30 %
Náklad na jeden dotaz (model + licence)	do 5 Kč	nad 15 Kč

Mezi prahy je šedá zóna: jedno kolo úprav, nejvýš 3 týdny, pak nové rozhodnutí.

Data a přístupy: znalostní báze (export, jen čtení), historie objednávky přes API helpdesku (jen čtení). Přístupy schvaluje IT, smlouvu s dodavatelem a zpracování osobních údajů posoudí pověřenec pro ochranu osobních údajů.

Rizika a pojistky: každá odpověď jde ven jen po schválení agentem; 10 % schválených odpovědí týdně zkontroluje vedoucí; model nemá oprávnění nic provádět; agent může návrh jedním kliknutím zahodit a nahlásit. Pilot okamžitě zastaví vlastník při úniku dat nebo opakované závažné chybě.

Právo: zpracování osobních údajů zákazníků v rámci vyřizování jejich dotazu, smlouva o zpracování s dodavatelem; podle prvního posouzení nejde o vysoce rizikové použití podle AI Actu, potvrdí právník. Agenti projdou krátkým školením.

Harmonogram: týden 1–2 příprava a výchozí měření, týden 3–8 ostrý běh (týdny 1–2 ostrého běhu se do výsledků nepočítají jako zaučení), týden 9 vyhodnocení.

Rozpočet: licence a použití modelu na 8 týdnů, 10 % času vlastníka, 2 hodiny týdně hodnotitelů kvality, nastavení od dodavatele. Datum rozhodnutí: pátek 9. týdne, porada vedení.

Všimni si, co v zadání není: žádné „zlepšíme zákaznickou zkušenost“, žádné „zvýšíme efektivitu“. Každá věta se dá na konci ověřit. To je celé tajemství.

Před startem: krátký kontrolní seznam

Než pilot spustíš, zkontroluj:

• Je zadání podepsané tím, kdo bude rozhodovat?
• Máš výchozí měření hotové, nebo naplánované souběžně?
• Ví každý uživatel, co se zkouší, proč a jak nahlásit problém?
• Je jasné, kdo a jak hodnotí kvalitu, a hodnotí podle stejných pravidel jako u výchozího měření?
• Máš v kalendáři datum rozhodnutí?

Lidé v pilotu nejsou pokusní králíci, ale spoluautoři. Řekni jim, že poctivá zpětná vazba „tohle mi nepomáhá“ je pro pilot stejně cenná jako nadšení. Jak lidi na změnu připravit, rozebírá lekce Školení a podpora.

Co si odnést

• Proof of concept ověřuje, jestli to technicky jde. Pilot ověřuje, jestli to funguje skutečným lidem ve skutečném procesu. Pilot nikdy nepřeskakuj.
• Na první pilot vyber častý, ohraničený a měřitelný proces s motivovaným týmem, kde chybu zachytí člověk dřív, než odejde ven.
• Bez výchozího měření nedokážeš nic. Změř dnešní stav stejnými metrikami, jako budeš měřit pilot, ideálně i se srovnávací skupinou.
• Kritéria úspěchu napiš předem a s prahy: kdy pokračovat, kdy iterovat, kdy skončit. Jinak výsledek „ohne“ přání všech zúčastněných.
• Zadání pilotu má jednu až dvě strany, jméno toho, kdo rozhoduje, a pevné datum rozhodnutí. Pilot by měl trvat týdny, ne měsíce.

Zdroje a další čtení

• Brynjolfsson, Li, Raymond: Generative AI at Work (NBER, 2023) – studie AI asistenta u více než pěti tisíc agentů zákaznické podpory; dobrý příklad poctivého měření proti výchozímu stavu.
• Anthropic: Define success criteria and build evaluations – jak psát konkrétní a měřitelná kritéria úspěchu, s příklady.
• THE Journal: Gartner: 30% of Gen AI Projects Will Be Abandoned (2024) – shrnutí předpovědi Gartneru a důvodů, proč projekty po PoC končí.