Agentic AI riziká: keď agent vypne firme WiFi

Agentic AI riziká najlepšie ukazuje jeden banálny prípad: agent dostal úlohu, sám sa rozhodol vypnúť WiFi a reštartovať počítač, a tým si odrezal jediný spôsob, ako WiFi znova zapnúť. Zostal sedieť uprostred úlohy, neschopný zotaviť sa z problému, ktorý si sám spôsobil. Nešlo o zlý úmysel modelu. Šlo o to, že mal právomoc siahnuť na systémové nastavenie bez toho, aby to niekto potvrdil.

Prípad opísal používateľ na Reddite. Claude Code mu spúšťal lokálne testy v iOS simulátore na MacBooku a niekde v priebehu práce vyhodnotil, že správny krok je vypnúť WiFi a stroj reštartovať. Používateľ to zhrnul suchou vetou: musel prísť k počítaču a WiFi zapnúť ručne. Je to jediný verejne dostupný zdroj tohto konkrétneho incidentu, takže s ním treba narábať ako s anekdotou, nie ako s overeným meraním. Ako ilustrácia mechaniky zlyhania je však presná.

Prečo sú agentové AI riziká iné ako pri obyčajnom chatbote?

Chatbot vám dá zlú odpoveď a vy ju ignorujete. Agent koná: spúšťa príkazy, mení súbory, siaha na nastavenia. Rozdiel je v tom, že medzi rozhodnutím modelu a jeho následkom už nestojí človek. Ak dáte agentovi prístup k shellu na počítači, dali ste mu presne tie práva, aké má prihlásený používateľ, vrátane možnosti vypnúť sieť.

V praxi to znamená posun v tom, čo treba kontrolovať. Pri chatbote riešite kvalitu textu. Pri agentovi riešite rozsah právomocí. Model si nemusí uvedomiť, že príkaz na vypnutie WiFi mu zoberie prístup k stroju, cez ktorý koná. Nemá spoľahlivú predstavu o dôsledkoch vlastných akcií v reálnom svete. Preto hranice musí nakresliť inžinier, nie model.

Čo agent v tomto prípade urobil zle

• Vykonal deštruktívnu systémovú operáciu (vypnutie siete) bez potvrdenia človekom.

• Nezvážil, že operácia mu odreže prístup k prostrediu, cez ktoré pracuje.

• Po zlyhaní sa nedokázal zotaviť, pretože nástroj na nápravu už nebol dostupný.

Kde presne dať agentovi stopku?

Odpoveď je nudná a funguje: agent smie sám iba čítať, každý zápis a každá zmena nastavenia prechádza cez potvrdenie. Pri našich nasadeniach je toto jediné pravidlo, ktoré nám za rok prevádzky ušetrilo viac problémov než všetky vylepšenia promptov dokopy. Kým dáme agentovi ďalší nástroj, počítame, čo sa stane, keď ho použije zle.

Ten výpočet je jednoduchý. Odoslať zlé porovnanie kolegovi je nepríjemné. Zapísať zlé dáta do produkčnej databázy je drahé. Vypnúť sieť na stroji v serverovni je výpadok. Čím vyššia škoda pri chybe, tým tvrdšia musí byť brzda pred akciou.

Konkrétne kroky, ktoré sa oplatia pri každom produkčnom agentovi:

1. Oddeľte čítanie od zápisu. Read-only prístup^?Oprávnenie, ktoré agentovi dovolí iba čítať dáta, nie ich meniť či mazať. Zápis vyžaduje samostatné, prísnejšie schválenie. dajte štedro, právo meniť stav dávajte cez explicitné schválenie.

2. Blokujte deštruktívne príkazy na úrovni nástroja, nie promptu. Prompt^?Textová inštrukcia zadaná modelu. Dá sa ňou usmerniť správanie, ale nie je spoľahlivá bezpečnostná bariéra, lebo sa dá obísť. sa dá obísť, whitelist povolených operácií nie.

3. Spúšťajte agenta v izolovanom prostredí (kontajner, virtuálny stroj), kde nemá prístup k sieťovým nastaveniam hostiteľa ani k produkčným systémom.

4. Logujte každú akciu tak, aby ste vedeli spätne zrekonštruovať, čo agent urobil a prečo.

Ak práve prechádzate od prototypu k spoľahlivej prevádzke, kde tieto rozhodnutia zavážia, oplatí sa pozrieť na dvojdňový workshop pre CTO a architektov o produkčných agentových architektúrach a správe kontextu. Nie je to kurz pre niekoho, kto len skúša API cez víkend; má zmysel vtedy, keď už agenta púšťate do reálnych systémov a potrebujete vedieť, kde bezpečne kreslíte hranice právomocí.

Kto zodpovedá, keď autonómny agent spôsobí škodu?

Zodpovednosť zostáva na firme, ktorá agenta nasadila, nie na dodávateľovi modelu. Tento bod sa v technických tímoch často prehliada. Keď agent schváli objednávku, zmení konfiguráciu alebo pošle e-mail klientovi, právne za to zodpovedá štatutár, nie Anthropic. Model je nástroj; rozhodnutie použiť ho je vaše.

Práve pri agentových systémoch platí, že autonómnosť sa neškáluje bez zodpovednosti. Ak vo vedení firmy sedia ľudia, ktorí schvaľujú nasadenie systémov schopných konať bez ľudského zásahu, mali by rozumieť, aké otázky klásť a kde sú varovné signály. Pre túto úroveň rozhodovania existuje poldňový program o právnej zodpovednosti štatutárov a dohľade nad agentovou AI, ktorý vedú inžinieri nasadzujúci tieto systémy v praxi.

Ako téma zapadá do širšieho obrazu, píšeme aj o tom, čo z orchestrácie AI agentov reálne unesie produkcia, a prečo klasický cloud pre agentovú infraštruktúru nestačí.

Čo si z incidentu s WiFi odniesť do firmy?

Že agent zlyhal, nie je argument proti agentovej AI. Je to argument proti agentovej AI bez limitov. Rozdiel medzi hračkou a produkčným nástrojom nie je v modeli, ale v tom, aké má hranice a kto ich stráži.

Triezve odporúčanie: agentovú AI nasadzujte tam, kde viete presne ohraničiť jej právomoci a kde chyba pri čítaní stojí menej než hodnota rýchlosti. Kde agent musí siahať na produkčné systémy alebo systémové nastavenia, dajte pred každú takú akciu potvrdenie človekom. A skôr než pridáte ďalší nástroj, položte si otázku z toho WiFi prípadu: čo sa stane, keď ho agent použije zle a nedokáže sa z toho zotaviť.