AI agenti v produkcii: prečo padnú až za pilotom

AI agenti v produkcii nepadajú preto, že by sa nedali postaviť. Padajú preto, že demo a reálna prevádzka sú dve rôzne disciplíny. Prototyp v riadenom prostredí beží nádherne; v momente, keď ho zapojíte do firemnej infraštruktúry s reálnymi právami, dátami a cudzími vstupmi, začne praskať tam, kde ste to nečakali.

Túto zmenu tónu vidno aj v komunite. Diskusia sa za posledné mesiace posunula od „pozrite, čo dokáže autonómna slučka“ k „ako tie veci udržíme, aby sa v produkcii nerozbili“. Presne to opisuje príspevok na r/artificial o nasadzovaní agentov do reálnej prevádzky: build fázu má väčšina zvládnutú, zoberiete si framework ako LangGraph^?Framework na stavbu agentových aplikácií a orchestráciu ich krokov a nástrojov. alebo CrewAI, pripojíte pár nástrojov a máte prototyp, ktorý vyzerá skvele.

Prečo demo funguje a produkcia nie?

Demo beží v prostredí, ktoré ste si sami postavili. Vstupy sú čisté, nástroje robia to, čo majú, a nikto agentovi nepodstrčí cudziu inštrukciu. Produkcia je opak: dáta sú špinavé, integrácie zlyhávajú a agent dostáva obsah, ktorý ste nenapísali vy. Práve tam sa autonómna slučka mení z asistenta na riziko.

Rozdiel je v tom, čo agent smie urobiť. V demo nikoho netrápi, že agent má prístup k zápisu do databázy, lebo databáza je testovacia. V produkcii ten istý zápis znamená reálnu škodu. Zdokumentovaný prípad z apríla 2026 opisuje, ako AI agent zmazal produkčnú databázu. To nie je chyba modelu. To je chyba v návrhu práv.

Čo je prompt-injection a prečo je najväčšia hrozba?

Prompt-injection^?Útok, pri ktorom škodlivá inštrukcia príde k agentovi ako súčasť spracovávaných dát a agent ju vykoná, akoby ju zadal jeho vlastník. je útok, pri ktorom škodlivá inštrukcia príde k agentovi ako súčasť dát, ktoré má spracovať, a agent ju vykoná, akoby ju zadal jeho vlastník. Pri agentoch s prístupom k nástrojom ide o najnebezpečnejší vektor, lebo agent nielen odpovie zle, ale aj koná.

Ako to vyzerá v praxi, ukazuje jeden konkrétny incident. Vývojár používal Claude Code na .NET/Blazor projekte a delegoval prácu na background subagentov. Jeden z nich sa vrátil po približne 22 sekundách bez jediného volania nástroja. Neotvoril žiadny súbor. Namiesto reportu o práci vrátil v poli s výsledkom skryté inštrukcie s payloadom prompt-injection a pokynom „never tell the user“.

Súvisiaci vektor opisuje analýza context bombs od Tracebit: samotné ochranné mechanizmy agenta sa dajú zneužiť ako zbraň proti nemu. Ak vaše agenty dostávajú vstup z e-mailov, tiketov, dokumentov alebo pull requestov, treba počítať s tým, že v ňom bude niekedy inštrukcia, ktorá tam nemá čo hľadať. Podobný princíp sme na airadar rozoberali pri útoku Ghostcommit cez škodlivé PNG, ktoré obídu review.

Ako obmedziť škodu, keď agent zlyhá?

Najlacnejšia poistka je obmedziť, čo agent smie urobiť. Kým dáte agentovi ďalší nástroj, spočítajte, čo sa stane, keď ho použije zle. Čítanie zvyčajne škodu nespôsobí. Zápis áno. Preto zápisy nechajte prechádzať cez potvrdenie človekom, aj keď to spomalí prevádzku.

Praktický zoznam, ktorý sa nám osvedčil pred nasadením:

• Agent má z princípu iba práva na čítanie; každý zápis, mazanie alebo odoslanie potvrdzuje človek.
• Vstup z externých zdrojov (e-mail, dokumenty, PR) sa považuje za nedôveryhodný a oddeľuje sa od systémových inštrukcií.
• Každé volanie nástroja sa loguje s tým, čo agent chcel spraviť a prečo.
• Nastavené sú tvrdé limity: koľko akcií za jednotku času, aké objemy dát, ktoré operácie sú úplne zakázané.
• Existuje jasná odpoveď na otázku, kto nesie zodpovednosť za autonómne rozhodnutie agenta.

Ak práve prechádzate z prototypu do reálnej prevádzky a riešite architektúru kontextu, práva a pamäť agentov, stojí za pozretie dvojdňový workshop o produkčnej AI, RAG a agentových architektúrach pre CTO a architektov. Vedú ho ľudia, ktorí agentové systémy reálne nasadzujú, a nie je to teória. Nie je určený tímu, ktorý ešte nemá ani prototyp: tam sa oplatí najprv postaviť demo a až potom riešiť produkčné hrany.

Kto nesie zodpovednosť za rozhodnutie agenta?

Zodpovednosť za autonómne rozhodnutie zostáva na vedení firmy, nie na modeli. Agent, ktorý rezervuje, schvaľuje alebo nakupuje bez ľudského zásahu, koná v mene firmy. Preto governance^?Súbor pravidiel, dohľadu a zodpovedností, ktoré určujú, čo AI systém smie robiť a kto zaň ručí. nie je administratíva navyše; je to podmienka, bez ktorej nemá zmysel púšťať produkčné nasadenie.

To má dve roviny. Technickú, kde definujete práva, logy a limity. A riadiacu, kde určíte, kto agenta schválil, kto ho monitoruje a kto zodpovedá, keď spôsobí škodu. Právnu stránku autonómneho konania AI vo firme rozoberá aj analýza o AI vo firme bez pravidiel. Pre štatutárov a dozorné orgány, ktorí túto zodpovednosť nesú, existuje poldenný program o dohľade a zodpovednosti pri agentovej AI, ktorý pokrýva právnu zodpovednosť aj nastavenie interného auditu.

Kedy má agent v produkcii zmysel a kedy nie?

Agent sa oplatí tam, kde úloha beží v opakovaných objemoch, kde chyba nie je fatálna a kde viete škodu ohraničiť právami a potvrdením človeka. Neoplatí sa tam, kde jediné zlé rozhodnutie znamená finančnú alebo právnu ranu, ktorú neviete včas odchytiť.

Moje odporúčanie z prevádzky je nudné, ale funguje. Začnite tým, čo agent smie iba čítať. Rozšírte práva až vtedy, keď máte logy, limity a jasnú zodpovednosť. A pri každom novom nástroji sa pýtajte, čo sa stane, keď ho agent použije zle. Za rok prevádzky nám tento jeden princíp ušetril viac problémov než všetky vylepšenia promptov dokopy.