AI pilot nezačíná výběrem modelu, ale měřením procesu, skutečnými daty a předem určenou stopkou.
Než zapojím vývojáře, chci znát konkrétní proces, jeho současný výkon a hranici přijatelné chyby. Potřebuji také vzorek skutečných vstupů. Bez něj lze postavit působivé demo, které funguje se třemi ukázkovými dokumenty a v reálném provozu selže.
Cílem přípravy není vytvořit padesátistránkovou specifikaci. U malého pilotu mi obvykle stačí dvě až čtyři strany a sada reálných dat. Musí z nich být jasné, co má řešení dělat a podle čeho poznáme, že to dělá dost dobře.
Dobrým kandidátem je opakovaná práce s textem, dokumenty nebo firemními znalostmi. Třeba třídění příchozích požadavků, vytahování údajů z objednávek, příprava návrhů odpovědí nebo dohledávání informací ve směrnicích.
Proces by měl probíhat alespoň několikrát týdně. Člověk musí umět výsledek zkontrolovat a opravit. Vstupy už mají být dostupné digitálně, případně je musí jít rozumně převést. Když dokument přijde jako fotografie účtenky pořízená v autě za deště, problém není jen v AI.
Pilot naopak není vhodný pro jednorázový úkol nebo proces, který pokaždé probíhá jinak. Nezačínal bych ani rozhodováním o přijetí zaměstnance, poskytnutí úvěru nebo jiným krokem s vážným dopadem na člověka. Tam nestačí rychlý experiment ani dobrý úmysl.
Vývoj také nedává smysl, pokud stejnou věc umí hotový nástroj za několik stovek nebo tisíc korun měsíčně. Rozhodnutí mezi nákupem a vývojem je dobré udělat ještě před pilotem. Podrobněji jsem ho popsal v článku o tom, kdy vlastní AI stavět a kdy koupit hotové řešení.
Přípravu držím v jednom pracovním dokumentu. Technickou architekturu do něj zatím nekreslím. Tu má smysl řešit až ve chvíli, kdy víme, co skutečně ověřujeme.
Podklad | Co má obsahovat |
|---|---|
Popis procesu | Začátek, konec, jednotlivé činnosti, výjimky a člověka odpovědného za výsledek |
Výchozí měření | Počet případů, čas na jeden případ, chybovost a náklady za běžné období |
Testovací data | Ideálně 50 až 200 anonymizovaných skutečných případů včetně neobvyklých vstupů |
Cílový výsledek | Jednu hlavní metriku a nejvýše dvě vedlejší metriky |
Pravidla provozu | Povolená data, zakázaná data, oprávnění, doba uchování a povinná lidská kontrola |
Stopka | Termín, rozpočtový strop a podmínku, při které pilot ukončíme |
Pokud proces zatím nikdo pořádně nezná, nejdřív ho zmapuji. AI může zrychlit postup, který jí předložíme. U dobře nastaveného procesu to může pomoci. U nejasného procesu jen rychleji vznikají nejasné výsledky. Použitelný postup nabízí i návod na první tři kroky před automatizací procesu.
Pilot nesmí řešit „zákaznickou podporu“. To je několik různých činností, systémů a odpovědností.
Přesnější zadání zní například takto: AI přečte příchozí e-mail, přiřadí jeden z osmi typů požadavku a připraví návrh odpovědi z interní znalostní báze. Odeslání vždy schválí pracovník podpory.
Současně sepíšu, co pilot dělat nebude. Nebude řešit reklamace nad 10 000 Kč, slibovat termín dodání ani měnit údaje v objednávce.
Ověřitelný výsledek: Jedna věta popisuje vstup, činnost, výstup a odpovědnost člověka. Další odstavec stanovuje výjimky.
Bez výchozího měření vznikne na konci jen dojem. „Působí to rychleji“ nestačí k obhajobě nákladů.
U procesu se 100 případy týdně změřím alespoň 20 běžných případů. Zapíšu čas od otevření vstupu po hotový výsledek. Vedle toho zaznamenám opravy, vrácení a chyby.
Pokud jeden případ zabere v průměru 12 minut, týdenní objem představuje 20 hodin. Pilot může mít cíl dostat lidskou práci na 7 minut při stejné nebo nižší chybovosti. To už lze ověřit.
Ověřitelný výsledek: Tabulka obsahuje alespoň počet případů, průměrný čas, rozsah naměřených časů a počet oprav.
Vývojář nemá testovací data vyrábět podle vlastní fantazie. Potřebuje skutečné případy, protože v nich bývají překlepy, chybějící přílohy a názvy produktů, které firma za deset let pojmenovala čtyřmi způsoby.
Pro první ověření obvykle vybírám 50 až 200 případů. Zahrnu běžné vstupy, hraniční situace i známé průšvihy. Každý případ doplním očekávaným výsledkem, který schválí člověk znalý procesu.
Citlivé údaje odstraním nebo nahradím ještě před předáním. Vývojář nepotřebuje skutečná rodná čísla k ověření, zda model správně rozpozná typ dokumentu.
Ověřitelný výsledek: Každý testovací případ má vstup, očekávaný výstup a označení, zda jde o běžný případ, výjimku nebo chybný vstup.
Přesnost 90 procent může být výborná i nepoužitelná. Záleží na tom, kterých 10 procent je špatně.
U třídění e-mailů lze tolerovat, že část zpráv skončí ve složce „ruční kontrola“. U částky na faktuře nechci, aby model sebevědomě hádal. Bezpečnější je, když nízkou jistotu přizná a případ předá člověku.
Stanovím proto hlavní metriku, například správné zařazení alespoň 92 ze 100 případů. Doplním provozní podmínku: žádný případ s nízkou jistotou se nesmí zpracovat automaticky. Pilot zastavím, pokud po dvou úpravách zůstane výsledek pod 80 procenty nebo náklady překročí předem určený strop.
Ověřitelný výsledek: Zadání obsahuje cílovou hodnotu, minimální přijatelnou hodnotu a přesnou podmínku ukončení.
Vývojáři předám proces, měření, testovací sadu, pravidla a rozpočet. Na úvodní schůzce nechci seznam modelů. Chci návrh nejmenšího řešení, které ověří hlavní předpoklad.
Součástí návrhu musí být způsob napojení, protokolování výsledků, řízení přístupů a možnost model později vyměnit. Závislost na jediném dodavateli může zdražit provoz nebo zablokovat další změny. Proto si předem ujasním, co se stane s řešením a daty při změně poskytovatele.
Ověřitelný výsledek: Vývojář dokáže odhadnout cenu a termín, aniž by si musel domýšlet firemní pravidla nebo očekávané odpovědi.
První týden nechám AI zpracovávat skutečné vstupy, ale její výstup nepoužiji v provozu. Porovnám ho s rozhodnutím zaměstnance. Teprve potom povolím omezené použití s povinným schválením.
Na konci porovnám stejný počet případů před pilotem a během něj. Zajímá mě čas člověka včetně kontroly a oprav, ne jen rychlost modelu. Sleduji také cenu za jeden případ. Samotné volání modelu může být levné, účet ale může růst s objemem, dlouhými vstupy a opakovanými pokusy. Proto se vyplatí náklady na AI měřit od prvního dne.
Ověřitelný výsledek: Závěrečné vyhodnocení říká pokračovat, upravit nebo zastavit. Obsahuje naměřený čas, chybovost, cenu za případ a seznam typických selhání.
První zádrhel bývá u vlastníka procesu. Všichni řešení chtějí, ale nikdo nemá dvě hodiny týdně na kontrolu testů. Bez člověka, který umí rozhodnout, co je správně, se pilot mění v technické hádání.
Druhý problém jsou data. Firma tvrdí, že jich má hodně. Pak se ukáže, že leží v osobních schránkách, ve skenech nebo v systému bez použitelného exportu. V takové situaci nejdřív řeším dostupnost dat. Model může počkat.
Třetí zádrhel přichází po hezké ukázce. Demo funguje, a tak se začne přidávat deset dalších funkcí. Tím pilot přijde o termín i možnost jednoznačného vyhodnocení. Nové nápady zapisuji bokem. Do první verze je nepouštím.
Obtížné bývá pilot zastavit. Člověk už do něj vložil čas a nerad připouští, že výsledek nestačí. Právě proto stanovuji stopku předem. Pokud pilot nesplní stanovené podmínky, ukončím ho a zapíšu zjištění pro další rozhodnutí. Pokračovat v řešení jen proto, že už stálo čas a peníze, problém nevyřeší.
Automatizace firemních procesů se posouvá od přepisování dat a odesílání notifikací k rozhodování. Systémy dnes třídí uchazeče, určují pořadí zákaznických požadavků, doporučují úvěrové limity nebo vyhodnocují podezřelé objednávky. Právě u těchto úloh se mění odpovědnost firmy.
Datovky mají od konce června novou adresu datovka.gov.cz a od dubna běží nové jednotné měsíční hlášení zaměstnavatelů (JMHZ). Obě změny se týkají prakticky každé firmy. Tady je postup krok za krokem, ať vám nepropadne termín.
Rok 2026 nasypal českým firmám nové povinnosti na jednu hromadu. Registrace zaměstnance před nástupem, tlačítko pro odstoupení na e-shopech, transparentní odměňování, elektronické hlášení úrazů, NIS2. U každé změny datum, pokuta a jedna věta, co s ní udělat, ať vás kontrola nezaskočí.
Napište nám, co u vás řešíte. Ozveme se do jednoho pracovního dne.
