_CORE

Agentní AI je víc než chatbot. Jakmile agent umí „dělat kroky" v systémech, stává se součástí provozu. A provoz má pravidla: bezpečnost, audit, měřitelnost a řízené změny. Tohle je 10 bodů, které chceme mít splněné dřív, než řekneme „go-live".

1 Má agent jasně definovaný cíl?

„Pomáhat uživatelům" není cíl. Cíl musí být měřitelný — jinak nepoznáte, jestli agent funguje, nebo jen generuje odpovědi. Dobrý cíl zní: „Vyřešit 70 % L1 ticketů bez eskalace do 3 minut." Špatný cíl zní: „Být užitečný."

Definujte metriku úspěchu dřív, než napíšete první prompt. Agent bez cíle je chatbot s extra náklady.

  • Cíl musí být konkrétní, měřitelný a časově ohraničený
  • Každý agent = jeden jasný scope (ne „dělá všechno")
  • Cíl definuje, jak budete agenta hodnotit v produkci

2 Ví agent, co nesmí dělat?

Hranice jsou důležitější než schopnosti. Agent, který umí všechno, ale nemá jasné limity, je bezpečnostní riziko. Definujte explicitně: jaká data nesmí číst, kam nesmí zapisovat, které akce vyžadují schválení člověkem.

Human-in-the-loop není slabost — je to designové rozhodnutí. U kritických akcí (platby, mazání, eskalace) musí agent čekat na potvrzení.

  • Explicitní seznam zakázaných akcí (not just „be careful")
  • Definované thresholdy pro human-in-the-loop
  • Jasné boundaries pro data access — co agent vidí a co ne

3 Je vyřešený přístup k datům (RBAC/ABAC)?

Agent je uživatel. A jako každý uživatel potřebuje role, oprávnění a omezení. Pokud agent přistupuje k CRM, ERP nebo interním databázím, musí mít přidělené role stejně jako lidský uživatel.

RBAC (Role-Based Access Control) je minimum. Pro komplexnější scénáře — třeba agent, který obsluhuje více oddělení — zvažte ABAC (Attribute-Based Access Control), kde záleží na kontextu dotazu.

  • Agent = service account s minimálními oprávněními (principle of least privilege)
  • Přístup k datům se řídí rolí agenta, ne rolí uživatele, který ho spustil
  • Audit log: kdo (agent), co (akce), kde (systém), kdy (timestamp)

4 Máte auditní stopu?

Každá interakce s agentem musí být dohledatelná. Kdo se ptal, jaké zdroje agent použil, jak se rozhodl, jakou akci provedl. Bez audit trailu je agent černá skříňka — a černé skříňky v produkci nikdo nechce.

Auditní stopa není jen compliance požadavek. Je to debugging nástroj. Když agent udělá chybu, potřebujete vidět celý reasoning chain.

  • Logujte: vstup, kontext, retrieval výsledky, reasoning, výstup, akci
  • Immutable logy — agent nesmí své logy mazat ani přepisovat
  • Retention policy: jak dlouho logy držíte, kde jsou uložené

5 Je knowledge layer (RAG) navržený jako systém?

RAG není „připojíme vektorovou databázi a hotovo." Knowledge layer je systém s vlastním životním cyklem: verzování dokumentů, metadata, testy retrievalu, monitoring kvality.

Pokud agent odpovídá na základě firemních dokumentů, musíte vědět, ze kterých verzí čerpá. Zastaralý dokument = zastaralá odpověď = špatné rozhodnutí.

  • Verzování zdrojových dokumentů — agent ví, z jaké verze čte
  • Metadata: autor, datum, platnost, klasifikace, oddělení
  • Testy retrievalu: „na tento dotaz musí vrátit tyto dokumenty"
  • Monitoring: top dotazy, neúspěšné retrievaly, coverage

6 Umíte agentovo chování měřit?

Co neměříte, to neřídíte. Agent v produkci potřebuje dashboard se čtyřmi typy metrik: přesnost odpovědí, latence, náklady a eskalace.

Přesnost měříte evalsy (viz bod 7). Latenci měříte end-to-end — od dotazu po odpověď. Náklady sledujete per-request (tokeny, API cally, compute). Eskalace ukazují, kde agent naráží na limity.

  • Přesnost: % správných odpovědí (ručně ověřený vzorek)
  • Latence: P50, P95, P99 — ne průměr
  • Náklady: cena za request, měsíční run-rate
  • Eskalace: % dotazů, kde agent řekl „nevím" nebo předal člověku

7 Máte evals a regresní testy?

Golden dataset je základ. Sada otázek a očekávaných odpovědí, kterou pouštíte po každé změně — modelu, promptu, knowledge base. Pokud eval klesne pod threshold, deploy se zastaví.

Bezpečnostní testy jsou stejně důležité: prompt injection, jailbreak pokusy, out-of-scope dotazy. Agent musí na všechny reagovat bezpečně — ne hallucinate, ne leak data.

  • Golden dataset: 50–200 párů otázka-odpověď pro klíčové scénáře
  • Bezpečnostní testy: prompt injection, PII leakage, off-topic handling
  • Regresní testy: automaticky při každém releasu
  • Robustnost: variace dotazů, překlepy, vícejazyčné vstupy

8 Jsou guardrails a fallbacky součást návrhu?

Agent musí umět říct „nevím." To není chyba — to je feature. Horší než žádná odpověď je sebejistá špatná odpověď. Guardrails definují, kdy agent odpovídá, kdy eskaluje a kdy odmítá.

Fallback strategie: confidence pod prahem → předat člověku. Neznámý intent → vytvořit ticket. Kritická akce → požádat o schválení. Každý edge case musí mít definovanou cestu.

  • Confidence threshold: pod X % agent neodpovídá, eskaluje
  • Fallback chain: agent → senior agent → člověk → ticket
  • Zakázané výstupy: PII, finanční rady, právní rady (pokud to není scope)
  • Graceful degradation: i při výpadku LLM API agent nespadne

9 Je release proces pro AI stejně přísný jako pro software?

Změna promptu je release. Aktualizace knowledge base je release. Upgrade modelu je release. A každý release potřebuje: verzování, code review, staging prostředí, canary deploy, rollback plán.

V praxi to znamená: prompt je v gitu, ne v UI konzoli. Knowledge base má deployment pipeline. Nová verze modelu jede nejdřív na 5 % trafficu, ne na 100 %.

  • Prompty a konfigurace v version control (Git)
  • Review proces: peer review pro prompt changes
  • Staging: testovací prostředí s produkčními daty (anonymizovanými)
  • Canary deploy: nová verze na malém % trafficu, monitoring, pak rollout
  • Rollback: one-click návrat na předchozí verzi

10 Máte incident proces pro AI?

AI agent udělá chybu. Ne jestli, ale kdy. Máte připravený proces? Kdo detekuje problém? Jak rychle dokážete agenta vypnout? Jak zjistíte root cause?

Kill switch je povinný — okamžité vypnutí agenta bez rollbacku celé infrastruktury. Incident response musí zahrnovat: detekci (alerting), mitigaci (kill switch / fallback), analýzu (root cause) a opravu (regresní test + fix + deploy).

  • Kill switch: vypnout agenta do sekund, ne minut
  • Alerting: automatické notifikace při anomáliích (spike eskalací, nízká přesnost)
  • Root cause analýza: auditní stopa + reasoning chain + zdroje
  • Post-mortem: co se stalo, proč, jak to opravíme, regresní test
  • Komunikace: kdo informuje stakeholdery, jaký je eskalační řetěz

Závěr

Produkční agent je provozní komponenta. Platí pro něj stejná pravidla jako pro každý jiný systém v produkci: musí být měřitelný, auditovatelný, verzovaný a mít incident proces. Těchto 10 bodů není „nice to have" — je to minimum pro zodpovědné nasazení AI.

Další články
Další krok

Chcete agentní AI v produkci?

Projdeme s vámi těchto 10 bodů na workshopu. Zjistíme, kde jste, co chybí a jak se dostat k bezpečnému go-live.

Domluvme workshop