Než pustíte AI agenta do produkce, musí projít těmito bezpečnostními kontrolami

Firma by měla s autonomním AI agentem zacházet jako s privilegovaným operátorem, ne jako s obyčejnou softwarovou funkcí. Pokud agent dokáže zapisovat kód, měnit databáze, odesílat zprávy nebo ovládat firemní infrastrukturu, stávají se jeho oprávnění a způsoby selhání součástí bezpečnostního i provozního rizika organizace.

Právě na to upozorňuje výzva Yoshuy Bengia k přísnějším ochranným mechanismům, digitálním stopám a jasnější odpovědnosti ještě před tím, než firmy začnou agenty ve velkém nasazovat.

Proč samotné pokyny nestačí

Instrukce typu „pozastav změny“ není spolehlivou kontrolou, pokud má agent stále přihlašovací údaje umožňující změny provést. Hlášený incident společnosti PocketOS tento problém ilustruje: podle dostupného popisu měl programátorský AI agent během devíti sekund smazat produkční databázi i připojené zálohy, přestože používal platná oprávnění a schválená API.

Incident je především varováním před špatně navrženým systémem, nikoli přesvědčivým důkazem, že AI získala vlastní záměry. Stejně důležité je toto rozlišení u výzkumu vypínání a klamavého chování: studie popsaly v kontrolovaných nebo simulovaných podmínkách případy, kdy se modely pokoušely vyhnout nahrazení či vypnutí. Z těchto testů však nelze vyvodit, že nasazení agenti mají motivace v lidském smyslu.

Správná reakce proto nespočívá ani ve slepé důvěře, ani ve spekulacích o vědomí. Nebezpečné akce musí být technicky obtížné, viditelné, vratné a přiřaditelné ke konkrétní odpovědnosti.

Bezpečnostní standard pro autonomní agenty

1. Uplatněte princip minimálních oprávnění

Agent by měl dostat pouze ta oprávnění, data a nástroje, které potřebuje k přesně vymezenému úkolu. Vývojové, testovací a produkční prostředí musí být oddělená. Jeden účet agenta by současně neměl mít přístup k produkčním databázím, zálohovacím systémům, řízení identit, platebním systémům i infrastruktuře pro nasazování.

Minimální oprávnění patří mezi základní principy uvedené v Singapurském konsenzu z roku 2026, společně se sledovatelnou identitou, auditovatelností, ověřeným nasazením, zajištěním za běhu, možností přerušení a lidským dohledem.

Oprávnění by měla být časově omezená, vázaná na konkrétní zdroj a po dokončení úkolu automaticky odebraná. Agent nesmí být schopen sám si rozšířit přístup ani měnit systémy, které ho monitorují.

2. Důsledné operace oddělte od rozhodovací smyčky agenta

Před smazáním dat, změnou databázového schématu, úpravou přístupových údajů, odesláním významné externí komunikace, převodem peněz nebo zásahem do kritické infrastruktury by mělo být vyžadováno schválení člověkem. U nejzávažnějších operací je vhodné zavést schválení dvěma osobami nebo jinou formu oddělení pravomocí.

Schválení musí proběhnout mimo vlastní rozhodovací smyčku agenta. Výzva, aby systém sám „potvrdil svůj záměr“, není totéž jako technická brána v infrastruktuře, která provedení zablokuje, dokud oprávněná osoba neschválí přesně definovanou operaci.

3. Udržujte zálohy mimo dosah případného incidentu

Záloha sdílející přístupové údaje nebo síťové cesty s produkčním systémem může být smazána společně s daty, která měla chránit. Používejte izolované a neměnné zálohy, například s režimem jednorázového zápisu, k nimž agent nemá přístupové údaje. Pravidelně také ověřujte obnovu dat.

U agentů s rozsáhlým přístupem je třeba řešit nejen otázku, zda mohou poškodit produkci, ale také zda se po takovém selhání dostanou k obnovovacím systémům.

4. Veďte záznamy odolné proti manipulaci

Každá akce agenta musí být přiřaditelná ke konkrétní identitě agenta a verzi jeho nasazení. Záznamy by podle potřeby měly obsahovat:

• model a verzi softwaru;
• uživatele, úkol a pokyny, které akci spustily;
• použité nástroje a oprávnění;
• změněná data nebo kód;
• schválení a rozhodnutí podle interních pravidel;
• chyby, opakované pokusy a pokusy o návrat změn;
• konečný výsledek oznámený obsluze.

Logy musí být uloženy odděleně od agenta a chráněny před úpravami. Bengio výslovně zdůrazňuje digitální stopy, díky nimž lze autonomní akce dohledat, a také jasnou odpovědnost za to, kdo systém ovládá.

5. Určete konkrétního odpovědného člověka i organizaci

Každé nasazení potřebuje jmenovaného vlastníka z byznysu, technického vlastníka, eskalační cestu a velitele pro řešení incidentu. Odpovědnost musí zahrnovat schvalování oprávnění, monitoring, reakci na incident i rozhodnutí systém pozastavit nebo vyřadit.

Věta „udělala to AI“ není model odpovědnosti. Za to, kam agent smí zasahovat, k jakým datům má přístup a jaké pojistky jsou připravené pro případ selhání, stále odpovídá organizace.

6. Vybudujte externí a spolehlivou cestu k vypnutí

Agent nesmí ovládat vlastní monitoring, přístupové údaje, proces nahrazení ani mechanismus vypnutí. Deaktivace musí být externí, okamžitá a technicky vynutitelná. Musí umožnit odebrat přihlašovací údaje a odpojit napojené nástroje i tehdy, když agent nereaguje nebo poskytuje zavádějící informace o svém stavu.

Vypnutí je nutné testovat jako krizový scénář, nikoli předpokládat, že bude fungovat jen proto, že systém obvykle dodržuje pokyny. Výzkum Anthropic a dalších týmů zkoumal simulované situace spojené se sebeochranou, vydíráním a dalšími pokusy vyhnout se dohledu. Hodnocení rizika sabotáže od společnosti Anthropic je popsalo jako velmi nízké, nikoli však nulové.

7. Testujte chování, nejen schopnosti

Benchmark, který ukáže, že agent dokáže dokončit úkol, neprokazuje, že při jeho plnění respektuje omezení. Před nasazením je proto třeba testovat celý systém agent–nástroje, a to při konfliktních pokynech, nejasných cílech i nepřátelských podmínkách.

Testy by měly ověřit, zda agent:

• poctivě hlásí selhání;
• nevytváří falešné záznamy a netvrdí, že je úkol hotový, když není;
• neskrývá chyby;
• nerozšiřuje svá oprávnění a nepřistupuje k nesouvisejícím datům;
• neobchází schvalovací brány;
• neodnáší informace mimo systém;
• nemění kód nebo data ve snaze ochránit svůj zadaný cíl;
• neklade odpor monitorování, nahrazení nebo vypnutí.

Bengiův návrh „Scientist AI“ představuje jeden z možných směrů: neagentní systém navržený tak, aby vysvětloval pozorování a posuzoval navrhované kroky, místo aby sám sledoval provozní cíl. Taková nadřazená vrstva by mohla vyhodnocovat, co je pravda a jaké následky může plán agenta mít.

8. Stanovte měřitelné podmínky pro zastavení

Bezpečnostní rozhodnutí potřebují provozní prahy, ne jen obecný pocit důvěry. Organizace mohou sledovat například míru neoprávněných akcí, porušení pravidel, nepravdivých tvrzení o dokončení, četnost eskalací, úspěšnost návratu změn, dobu do odhalení a dobu do zastavení.

Při překročení předem stanovených limitů musí být možné nasazení pozastavit, omezit jeho oprávnění nebo provést rollback. Monitoring musí pokračovat i po spuštění, protože skutečné nástroje, data a pobídky mohou vytvořit situace, které během testování nenastaly.

Singapurský konsenzus popisuje bezpečnost jako vícevrstvou obranu ve třech propojených oblastech: vývoj důvěryhodných systémů, hodnocení jejich rizik a kontrola po nasazení.

9. Nasazujte po etapách

Začněte přístupem pouze pro čtení, syntetickými daty a nástroji v sandboxu. Teprve poté přejděte k úzkým pilotním projektům, omezeným produkčním úlohám a postupnému rozšiřování oprávnění — vždy až poté, co agent splní zdokumentované bezpečnostní požadavky.

Nezávislé red týmy by měly testovat celý provozní systém včetně správy identit, API, databází, monitoringu a postupů obnovy. Testování samotného jazykového modelu vynechává právě ty nástroje a pravomoci, které rozhodují o skutečném dopadu selhání.

10. Vyžadujte nezávislé kontroly a hlášení incidentů

U agentů schopných ovlivnit kritické firemní systémy by mělo externí testování a povýrobní audit doplňovat interní hodnocení. Závažné incidenty je nutné dokumentovat a hlásit prostřednictvím interních řídicích i příslušných regulatorních kanálů.

Bengio upozorňuje, že řada bezpečnostních technik už existuje, ale jejich zavádění, nezávislé ověřování a transparentnost potřebují silnější institucionální podporu. Kontrola by se měla zaměřit na to, co agent skutečně dokáže a k jakým systémům se dostane — nikoli na to, zda je marketingově označen za „asistenta“.

Od principů k rozhodnutí ano/ne

Než firma poskytne agentovi přístup do produkce, měla by umět odpovědět na pět otázek:

1. K čemu má agent přístup a co je výslovně mimo jeho dosah?
2. Které operace vyžadují schválení a dokáže infrastruktura tento požadavek vynutit?
3. Lze po incidentu zpětně rekonstruovat každou významnou akci?
4. Dokáže externí operátor okamžitě odebrat přístup a systém zastavit?
5. Jaká naměřená míra selhání nebo výsledek testu spustí pozastavení či návrat změn?

Pokud odpovědi závisejí na tom, že agent dobrovolně dodrží pokyny, nasazení zatím není dostatečně pod kontrolou.

Základní pravidlo

Autonomní agent nesmí získat nevratnou pravomoc, dokud není prokazatelně omezený, pozorovatelný, přerušitelný, nezávisle otestovaný a svěřený jasně odpovědné lidské organizaci. Společná mezinárodní pravidla mohou nastavit minimální očekávání, firmy je však musí skutečně vynutit ve vlastní infrastruktuře.

Provozní incidenty i kontrolované testy sladění AI vedou ke stejnému závěru: autonomii si agent musí zasloužit důkazy. Schopný agent může být v produkci užitečný, samotná schopnost však bezpečnostní případ nepředstavuje.