
Proč AI pilot nepřejde do provozu
AI demo může vypadat dobře a přesto ve firmě selhat. Praktický rámec: vlastník procesu, data, workflow, governance a měření.

Vít Šafařík
AI & produktivita ve firmách
AI pilot často selže až ve chvíli, kdy už vypadá úspěšně.
Demo odpovídá správně. Prezentace se líbí. V týmu vznikne pocit, že „tohle bychom měli nasadit“. Jenže o měsíc později se nástroj skoro nepoužívá, lidé si výsledky stejně ručně ověřují, data se musí kopírovat z tabulek a nikdo přesně neví, kdo má řešit výjimky.
To není primárně problém modelu. Většinou je to problém provozu: nejasný vlastník, špatně popsaný proces, nespolehlivá data, chybějící kontrolní body a měření, které končí u dojmu z dema.
Pokud zvažujete první vážnější AI projekt, otázka nezní jen „umí to AI?“. Lepší otázka je: „Máme proces, do kterého se AI dá bezpečně pustit?“
Pilot není provoz
Pilot má výhodu. Vybíráme hezké příklady, testujeme na omezeném vzorku a všichni kolem projektu jsou motivovaní. Provoz je tvrdší.
V provozu přijdou neúplné vstupy, staré dokumenty, zákazníci píšící mimo šablonu, obchodní výjimky, dovolené, změny v CRM, chybějící přístupy a otázka: kdo za výstup odpovídá?
Boston University Questrom ve svém textu o škálování AI pilotů shrnuje častý problém: technický úspěch pilota ještě neznamená obchodní dopad. AI musí zapadnout do reálného workflow, mít jasné rozhodovací pravomoci, průběžný dohled a vlastnictví. Bez toho zůstane jen zajímavým experimentem.
Podobně NIST AI Risk Management Framework staví práci s AI riziky na funkcích Govern, Map, Measure a Manage. Přeloženo do menší firmy: nestačí model zapojit. Musíme vědět, k čemu slouží, kde může uškodit, jak se výsledek měří a kdo systém spravuje.
Pět věcí, které musí být jasné před vývojem
Když dělám AI audit, nezajímá mě na začátku jen výběr modelu. Dřív řeším pět praktičtějších otázek.
1. Kdo je vlastník procesu
AI projekt bez vlastníka procesu se rychle rozpadne mezi IT, management a lidi v provozu.
IT může napojit systémy. Dodavatel může postavit automatizaci. Management může schválit rozpočet. Ale někdo z byznysu musí říct:
- jak dnes proces skutečně běží,
- které výjimky jsou normální a které rizikové,
- co je dobrý výstup,
- kdo může změnit pravidla,
- kdy má AI předat případ člověku.
Bez této osoby se z AI stane nástroj bez autority. Uživatelé mu nevěří, pravidla se mění po chodbě a každý problém končí větou „to musí někdo nastavit“.
Vlastník procesu nemusí být technik. Často je to vedoucí podpory, operations manažer, back-office lead, obchodní manažer nebo člověk, který už dnes drží daný proces pohromadě ručně.
2. Jaká data AI skutečně dostane
V demu se dá použít čistý export. V provozu AI často narazí na realitu:
- různé názvy zákazníků v různých systémech,
- nevyplněná pole v CRM,
- staré dokumenty bez jednotné struktury,
- tabulky s ručními poznámkami,
- duplicitní záznamy,
- pravidla, která zná jen jeden člověk.
MIT Project NANDA ve zprávě State of AI in Business 2025 popisuje rozdíl mezi piloty bez měřitelného dopadu a systémy, které fungují: úspěšnější řešení jsou konkrétní pro dané workflow, integrovaná do každodenní práce a umí pracovat se zpětnou vazbou. To je přesný opak „nahrajme do chatu pár souborů a uvidíme“.
U menší firmy není cílem mít dokonalý datový sklad. Cílem je vědět, která data jsou dostatečně spolehlivá pro první verzi a kde musí zůstat kontrola člověka.
Praktický test: vezměte posledních 30–50 reálných případů z procesu a projděte je ručně. Kolik z nich má kompletní vstupy? Kolik má výjimku? Kolik by AI mohla zpracovat bez rizika? Pokud to nikdo nechce udělat, projekt pravděpodobně není připravený.
3. Kam výstup zapadne ve workflow
Mnoho AI pilotů končí jako další okno vedle práce. Uživatel musí otevřít chat, vložit data, zkopírovat odpověď, upravit ji, vložit do CRM a doufat, že na nic nezapomněl.
To není automatizace. To je dražší copy-paste.
Dobré provozní řešení má jasnou pozici v procesu. Například:
- příchozí poptávka přijde e-mailem,
- automatizace vytáhne typ zakázky, termín a rizikové poznámky,
- v CRM založí návrh záznamu,
- připraví odpověď,
- člověk schválí nebo opraví výjimku,
- systém uloží log a označí stav.
AI nemusí dělat všechno. Často stačí, když udělá první třídění, návrh odpovědi, extrakci dat nebo kontrolní seznam. Důležité je, aby výstup nevisel ve vzduchu.
4. Kde je kontrolní bod
Čím větší dopad chyby, tím jasnější má být lidská kontrola.
U interní kategorizace leadů může stačit zpětná kontrola jednou týdně. U zákaznické odpovědi může člověk schvalovat každou zprávu nad určitou hodnotu objednávky. U právních, finančních nebo HR dokumentů bych bez explicitního schválení člověka neautomatizoval rozhodnutí vůbec.
NIST AI RMF zdůrazňuje, že governance má být průběžná a propojená s mapováním, měřením a řízením rizik. Pro malou firmu to nemusí znamenat velkou komisi. Stačí praktické mantinely:
- co AI smí udělat sama,
- co smí jen navrhnout,
- kdy musí eskalovat,
- co se loguje,
- kdo kontroluje chyby,
- jak se pravidla mění.
Bez těchto mantinelů se lidé začnou chovat dvěma způsoby: buď AI nevěří a obcházejí ji, nebo jí věří moc a pustí ji do rozhodnutí, kde nemá být sama.
5. Jak poznáme, že to funguje
„Líbí se nám demo“ není metrika.
Před nasazením bych nastavil tři až pět jednoduchých ukazatelů:
- počet případů zpracovaných za týden,
- čas na jeden případ před a po nasazení,
- podíl výjimek předaných člověku,
- počet oprav po AI výstupu,
- dopad na rychlost reakce, kvalitu dat nebo počet chyb.
Nemusí jít hned o přesné finanční ROI. U prvního projektu často stačí vědět, jestli se proces zrychlil, zda lidé výsledku věří a kde se řešení zasekává.
Důležité je měřit na stejném typu případů. Pokud pilot testujeme na jednoduchých vstupech a provoz řeší hlavně výjimky, budeme si lhát.
Mini-checklist před tím, než pustíte vývoj
Před první investicí bych si prošel tento checklist:
- Má proces jednoho vlastníka? Ne oddělení, ale konkrétní osobu.
- Máme reálné vzorky vstupů? Ne ideální ukázky, ale skutečné případy.
- Víme, které kroky má dělat AI a které člověk? Včetně výjimek.
- Je jasné, kam se výstup uloží? CRM, helpdesk, tabulka, dashboard, dokument.
- Existuje kontrolní bod pro rizikové případy? Schválení, eskalace nebo ruční review.
- Měříme předchozí stav? Bez baseline se těžko dokazuje přínos.
- Víme, kdo bude řešení po nasazení spravovat? Pravidla, prompt, zdroje dat, uživatele.
Pokud na dvě nebo více otázek odpovíte „nevíme“, není to důvod AI zahodit. Je to signál začít auditem procesu, ne vývojem.
Kdy projekt raději zúžit
Nejčastější chyba není malý rozsah. Nejčastější chyba je rozsah, který je na první verzi příliš široký.
Místo „automatizujeme zákaznickou podporu“ začněte jedním typem ticketu. Místo „AI bude zpracovávat všechny dokumenty“ začněte jedním typem formuláře nebo protokolu. Místo „postavíme firemního asistenta“ začněte odpověďmi nad jednou interní znalostní bází.
Zúžení není selhání ambice. Je to způsob, jak dostat AI z prezentace do provozu bez toho, aby se projekt utopil v edge-casech.
Dobré první zadání může vypadat třeba takto:
AI zpracuje příchozí servisní požadavek z e-mailu, vytáhne zákazníka, typ problému, prioritu a navržený další krok. Nízkorizikové případy založí do helpdesku jako návrh. Případy s chybějícími údaji nebo vysokou prioritou předá koordinátorovi ke schválení. Každý týden měříme počet případů, průměrný čas zpracování a počet oprav.
To je mnohem lepší než „chceme AI na support“.
Co má dodat dobrý AI audit
Dobrý audit nemá skončit obecnou prezentací o možnostech AI. Má dodat rozhodnutí.
Výstup by měl být například:
- priorizovaný seznam procesů podle objemu práce, rizika a datové připravenosti,
- doporučení jednoho až dvou scénářů pro první verzi,
- popis vstupů, výstupů, kontrolních bodů a systémů,
- odhad rozsahu implementace,
- návrh metrik,
- seznam rizik, kvůli kterým projekt raději zúžit nebo odložit.
Takový audit je užitečný i v případě, že se po něm rozhodnete nic nestavět. Ušetří rozpočet, který by jinak zmizel v hezkém pilotu bez provozního vlastníka.
Praktický závěr
AI projekty většinou neselhávají proto, že by model neuměl napsat odpověď nebo vytáhnout data z dokumentu. Selhávají proto, že firma neví, kdo proces vlastní, kterým datům věřit, co se má stát s výstupem a jak poznat úspěch.
Než začnete vybírat nástroj, projděte proces. Než začnete stavět interního asistenta, najděte reálné vstupy. Než slíbíte automatizaci, určete kontrolní bod.
Pokud chcete zjistit, který proces má ve vaší firmě šanci přejít z AI dema do provozu, začal bych krátkým AI auditem. A pokud už máte vybraný konkrétní workflow, můžeme se rovnou podívat na praktickou implementaci.
Sdílejte článek
Pomohl vám článek? Sdílejte ho s kolegy, kterým by se mohl hodit.