AI agent ve firmě use case: od čtení dat po schválení

AI agent ve firmě use case dává smysl jen tehdy, když je popsaný jako konkrétní provozní mechanismus, ne jako kouzelné tlačítko. V praxi to znamená jednoduchý řetězec: agent přečte dostupná data, připraví návrh další akce, člověk ji potvrdí a systém uloží, kdo co schválil. Teprve potom se mění stav v portálu, odešle zpráva nebo vznikne úkol.

V LucidMark se na automatizace díváme jako na vrstvu nad dobrým systémem. Nejdřív musí být jasné, kde data vznikají, kdo za ně odpovídá a jak se pozná správný další krok. AI je užitečná ve chvíli, kdy zmenší ruční práci, ale nezakryje odpovědnost člověka.

Jaký use case si představit?

Dobře uchopitelný příklad je klientský portál ve financích nebo poradenství. Ve FAKTA.md máme u projektu Finapos popsaný portál se semaforem stavů a post-booking sekvencí. Článek proto nepoužívá vymyšlená čísla, ale mechanismus: klient vidí stav svého případu, tým vidí, co chybí, a systém umí připravit další krok.

Bez agenta se podobný proces často láme na ruční kontrole. Někdo otevře detail klienta, přečte poznámky, zkontroluje stav dokumentů, dohledá poslední komunikaci a napíše zprávu. Není to nutně složitá práce, ale je náchylná k přehlédnutí, zvlášť když se opakuje u desítek případů.

AI agent ve firmě use case vypadá praktičtěji takto: agent přečte stav případu, poslední poznámky a checklist dokumentů. Pak připraví návrh zprávy klientovi a navrhne změnu semaforu, například z oranžové na zelenou až po doplnění konkrétní položky. Člověk vidí návrh, upraví ho nebo odmítne, a až potvrzený krok se zapíše do systému.

Co agent čte a co nesmí měnit sám?

Agent má nejdřív číst, ne rovnou zapisovat. Read-first režim je praktické pravidlo, které odděluje orientaci v datech od akce měnící stav. V portálu může agent číst profil klienta, stav checklistu, čas poslední aktivity, interní poznámky a šablony zpráv. Neměl by ale bez potvrzení měnit stav případu, mazat data, odesílat klientovi zprávu ani spouštět navazující sekvenci.

To je důležité i z pohledu rizik. NIST ve svém AI Risk Management Frameworku popisuje potřebu řízení, mapování a měření rizik u AI systémů. Pro běžnou firmu se to dá přeložit jednoduše: víme, odkud agent bere data, víme, jaké akce smí navrhnout, a víme, kdo nese odpovědnost za finální potvrzení.

Read-first režim také omezuje škody při špatném vstupu. Když se v poznámce objeví nejasná instrukce, zastaralý údaj nebo text z e-mailu, agent ho může zahrnout do shrnutí, ale nemá automaticky měnit důležitý stav. U nejistých případů je lepší návrh označit k ruční kontrole, ne předstírat jistotu.

Jak vypadá návrh akce pro člověka?

Návrh akce má být krátký, kontrolovatelný a rozdělený na části. Prakticky může obsahovat shrnutí stavu, důvod doporučení, navržený text zprávy a přesnou akci v systému. Například: chybí potvrzení příjmu, klient dodal smlouvu, doporučená akce je poslat doplňující dotaz a ponechat semafor oranžový.

Dobrý návrh neříká jen co udělat, ale také z čeho vychází. Člověk má vidět odkazy na zdrojová pole v portálu, poslední komunikaci a pravidlo, podle kterého agent doporučil další krok. Když tato vazba chybí, vzniká černá skříňka. A černá skříňka je v interních procesech drahá, protože ji lidé buď slepě následují, nebo jí přestanou věřit.

U podobných systémů se vyplatí začít úzkým rozsahem. Ne celý klientský servis, ale jeden moment v procesu. Třeba kontrola, zda má případ vše pro další krok. To je přesně typ problému, kde custom systém dává větší smysl než hromada tabulek. Pokud firma řeší podobný provozní chaos, dává smysl podívat se na LucidMark jako na partnera pro web, portál a automatizaci v jednom toku.

Proč je lidské potvrzení pořád klíčové?

Lidské potvrzení není brzda, ale pojistka odpovědnosti. Agent může výrazně zkrátit cestu od dat k návrhu, ale finální rozhodnutí má zůstat u člověka tam, kde akce mění vztah s klientem, stav případu nebo obchodní závazek.

OWASP u aplikací s velkými jazykovými modely dlouhodobě upozorňuje na rizika typu prompt injection a nevhodné zacházení s výstupy modelu. V praxi to znamená, že text v e-mailu, dokumentu nebo poznámce nemá mít stejnou důvěru jako interní pravidlo systému. Agent může text přečíst, ale systém musí mít jasné role, oprávnění a hranice.

Konkrétní ovládací prvek může být jednoduchý: tlačítko Schválit, Upravit, Odmítnout. Při úpravě se ukládá finální verze. Při odmítnutí se může uložit důvod, aby se později poznalo, jestli agent navrhoval špatný typ akce, nebo mu chyběla data. Tím se z automatizace stává měřitelný proces, ne slepý experiment.

Co se má logovat a proč?

Logování odpovídá na otázku, co se stalo a kdo za tím stál. U AI asistovaných akcí se vyplatí uložit čas návrhu, zdrojová data použitá pro návrh, verzi šablony nebo pravidla, text návrhu, identitu schvalující osoby a finální akci. NIST SP 800-92 je dokument zaměřený na správu bezpečnostních logů, ale jeho hlavní myšlenka je užitečná i tady: bez kvalitních záznamů se špatně vyšetřují incidenty a provozní chyby.

Log nemusí být složitý. Důležité je, aby šel filtrovat podle případu, uživatele a typu akce. Když klient tvrdí, že zprávu nedostal, tým se podívá, zda byla jen navržená, schválená, nebo skutečně odeslaná. Když se opakuje stejná úprava návrhu, je to signál, že pravidlo nebo šablona potřebuje změnit.

Podobný princip souvisí i s interním reportingem. Pokud vás zajímá, jak navazující automatizace pomáhá ve firmě s přehledem a rutinním vyhodnocováním, navazuje na to starší článek Jak automatizovat měsíční reporting ve firmě. Reporting a agentické návrhy mají společný základ: dobrá data, jasný vlastník a čitelný výstup.

Kdy AI agent ve firmě nedává smysl?

Nedává smysl tam, kde není stabilní proces. Pokud každý člen týmu řeší stejný případ jinak, agent jen zrychlí zmatek. Nejdřív je potřeba popsat stavy, vstupy, odpovědnosti a výjimky. Teprve potom má smysl přidat vrstvu, která čte data a připravuje návrhy.

Také není dobré začít citlivou akcí. Lepší první krok je interní návrh bez automatického odesílání. Tým získá zkušenost, uvidí, kde agent pomáhá a kde se plete, a postupně může rozšířit rozsah. Poctivě navržený AI agent ve firmě use case má proto začít malým, kontrolovatelným tokem, ne slibem, že převezme celé oddělení.

Závěr: kde je skutečná hodnota?

Skutečná hodnota není v tom, že systém něčemu říká agent. Hodnota je v kratší cestě od roztroušených dat k připravenému, kontrolovatelnému kroku. Agent přečte kontext, navrhne akci, člověk ji potvrdí a log ukáže, co se stalo.

To je střízlivý základ, na kterém se dá stavět. Pro portál se semaforem stavů, rezervační systém nebo interní reporting platí totéž: nejdřív pořádek v datech a rolích, potom automatizace. AI je užitečná až ve chvíli, kdy pomáhá lidem dělat méně rutiny a lepší rozhodnutí, aniž by jim brala odpovědnost.