Vyberte jeden pracovní úkon
Začněte činností, která má známý vstup, výsledek a osobu odpovědnou za správnost. Může jít o návrh odpovědi na interní dotaz, třídění dokumentů nebo přípravu podkladů pro schvalovatele. Zmapujte, kolik času dnes úkon zabere, jak často nastává a co stojí chyba. Vhodný pilot lze srovnat s dnešním postupem. Obecný cíl zavést AI do firmy neposkytuje kritérium, podle něhož poznáte, zda systém někomu opravdu pomohl.
Rozlište návrh, doporučení a vykonanou akci. Generování konceptu zprávy má jiné riziko než změna záznamu v CRM nebo schválení platby. Při prvním pilotu je bezpečnější ponechat rozhodující zápis člověku a měřit, zda návrhy práci usnadňují. NIST AI RMF popisuje řízení rizik jako průběžný cyklus govern, map, measure a manage. Pro malý pilot to znamená určit vlastníka, mapovat dopad, měřit chyby a pravidelně rozhodovat o úpravě postupu.
Data a oprávnění určují hranici
Zjistěte, které dokumenty a záznamy AI skutečně potřebuje. Každý zdroj má vlastníka, klasifikaci, dobu platnosti a přístupová práva. To, že má zaměstnanec přístup k jednomu souboru, neznamená, že model smí dostat celý archiv. Při vyhledávání nebo RAG se oprávnění musí prosadit ještě před předáním výsledků do modelu. U odpovědi uložte odkaz na zdroj a jeho verzi, aby šlo později ověřit, z čeho systém vycházel.
Texty dodané uživatelem a načtené z webu považujte za nedůvěryhodný vstup. OWASP vysvětluje prompt injection jako pokus změnit chování modelu instrukcemi vloženými do obsahu. Dokument je datový zdroj, nikoli autorita měnící oprávnění workflow. Nástroje, které AI smí volat, mají mít minimální potřebný rozsah. Čtení a zápis oddělte, citlivé akce vyžadují další kontrolu a tajné klíče nepatří do modelového promptu. Samotná formulace instrukcí není systém řízení přístupu.
Schválení je stav procesu
Určete, které akce se provedou automaticky a které čekají na člověka. Kritéria vycházejí z dopadu: komu výsledek odejde, zda mění trvalá data a zda jej lze snadno vrátit. Microsoft v návrhových vzorech agentů rozlišuje povinné schválení od zpětné vazby, která vrací návrh k úpravě. Systém musí uchovat stav čekající úlohy, aby po hodinách navázal na stejný podklad, nikoli spustil proces znovu a vytvořil druhou akci.
Schvalovatel potřebuje vidět původní vstup, navržený výstup, zdroje a upozornění na nejistotu. Jedním kliknutím nemá potvrzovat stovky skrytých změn. U zamítnutí se uloží přiměřeně stručný důvod a úloha se vrátí do bezpečného stavu. Práva schvalovatele kontrolujte v okamžiku akce, ne jen při vytvoření požadavku. Pokud je člověk nedostupný, úloha čeká nebo se eskaluje podle předem určeného pravidla; nesmí tiše získat automatické povolení.
Auditní stopa vysvětlí konkrétní operaci
U každého běhu zachovejte identifikátor případu, verzi instrukcí, model, použité zdroje, navržené kroky, schválení a skutečně provedené změny. Záznam má stačit k vysvětlení incidentu, ale nemá zbytečně kopírovat plné osobní údaje nebo tajné dokumenty. Doba uchování se určí podle právního a provozního kontextu firmy. Pokud workflow volá více systémů, použijte korelační identifikátor napříč jejich logy. Jinak nebude možné poznat, kde se návrh změnil v akci.
Výstup modelu může být v pořádku, zatímco následný konektor selže. Logujte odděleně rozhodnutí AI, lidské potvrzení a stav nástroje. Při timeoutu nevíte vždy, zda cílový systém zápis provedl; opakování potřebuje idempotentní identifikátor nebo bezpečné ověření stavu. Audit není jen seznam textů, které model vygeneroval. Musí spojit návrh s důsledkem v reálném systému a ukázat, kdo za který přechod odpovídal. Takový záznam pomáhá řešit i stížnost uživatele.
Měřte kvalitu na výjimkách
Před pilotem připravte případy z běžné práce: snadné, neúplné, zastaralé, citlivé a záměrně matoucí vstupy. U každého určete očekávaný postup, ne pouze jednu správnou větu. Měřte přesnost návrhu, počet oprav člověkem, čas do dokončení a druhy chyb. U vyhledávacího kroku oddělte problém nalezení zdroje od problému formulace odpovědi. Pokud se zlepší průměrná rychlost, ale kritické výjimky se zhorší, pilot nelze označit za úspěšný.
Vyhodnocení opakujte při změně modelu, promptu, zdrojů i oprávnění. Uživatelé začnou nástroj často používat jinak, než bylo zamýšleno; sledujte nové scénáře a zpětnou vazbu, nejen technickou dostupnost. Zapište náklady na zpracování, čas schvalovatele a práci na údržbě. Úspora několika sekund v jednom kroku nemusí převážit čas věnovaný kontrolám. Metrika proto musí zahrnovat celý proces od vstupu po konečné rozhodnutí, včetně případů, které model neumí zpracovat.
Fallback a přijetí uživateli
Když je model nebo zdroj nedostupný, práce potřebuje jasnou alternativu: ruční postup, vyhledání dokumentu bez generování nebo odložení úlohy. Uživateli zobrazte, co se stalo a zda se něco provedlo; falešný dojem dokončení je horší než přiznaný výpadek. Vypnutí AI části nemá zablokovat přístup k původním datům. Předem určete, kdo může workflow zastavit a jak se došetří rozpracované případy. Při obnově provozu je nutné zabránit dvojímu provedení čekajících akcí.
Lidé musí vědět, kdy nástroj pomáhá a kdy je odpovědnost stále na nich. Krátké školení s konkrétními příklady je užitečnější než obecný seznam schopností modelu. Sbírejte chyby, které lze reprodukovat, a upravujte podle nich vstupy nebo postup. EXCOIN zde netvrdí vlastní měřenou úsporu času u zákazníků ani bezchybnost. Dobrý první výstup je mapa úkolu, povolené zdroje a akce, evaluační sada a plán lidského schválení. Na jejich základě lze rozhodnout, zda je vhodná AI, jednodušší pravidlo nebo změna procesu.
Pilot uzavřete rozhodnutím, co pokračuje a co se ruší. Stanovte, kdo udržuje zdroje, kdo reviduje chybné návrhy a jak změna modelu spouští nový test. Pokud se nikdo k těmto povinnostem nehlásí, technicky funkční demonstrace se nemá považovat za připravený interní produkt.
Před rozšířením na další tým ověřte i cenu chyb, které se neprojevily jako okamžité selhání. Neúplná odpověď může vést k delšímu ručnímu došetření až o několik dní později. Měřte tedy nejen počet přijatých návrhů, ale také následné opravy, reklamace interních uživatelů a situace, kdy se člověk rozhodl výstup vůbec nepoužít. Podobně sledujte, zda pracovníci nezačínají modelu přisuzovat větší jistotu, než skutečně má. Na obrazovce proto odlište ověřený zdroj, modelovou formulaci a finální lidské rozhodnutí. Pokud nelze tuto hranici čtenáři srozumitelně ukázat, je vhodné zmenšit rozsah automatizace. Rozhodnutí o dalším kroku potom stojí na skutečném chování lidí, ne na počtu vygenerovaných odpovědí. Vlastník procesu by měl znát také postup pro opravu již provedené akce a způsob informování dotčených lidí při zjištění pozdější chyby.