AI agent může provést stovky změn. Governance stále počítá tickety

Bezpečnostní tým potřebuje opravit zranitelnou knihovnu ve 140 repozitářích. Agent najde dotčené projekty, vytvoří větve, upraví závislosti, spustí testy, opraví část nekompatibilit, založí pull requesty a u vybraných služeb připraví postupné nasazení. Za několik hodin vzniknou stovky technických zásahů.

Tradiční ITSM se zeptá, kolik je to změn. Jeden ticket? Sto čtyřicet? Každý commit, merge, build a deployment zvlášť? Odpověď není administrativní detail. Podle zvolené jednotky buď zahltíme proces záznamy, které nikdo smysluplně neposoudí, nebo schováme velký dopad pod jediný neurčitý ticket.

Agentní automatizace proto nemění účel change managementu. Mění objekt, který je třeba řídit. Autorita už nemá ručně potvrzovat každý krok. Má schválit mandát, hranice, povinné důkazy, stop podmínky a maximální dopad, v němž se agent smí pohybovat.

Problém není ITIL. Problém je ticket jako falešná jednotka řízení

Oficiální popis ITIL Change Enablement staví jeho účel na maximalizaci úspěšných změn prostřednictvím přesného posouzení rizik, autorizace a řízení harmonogramu. To je podstatně širší cíl než pravidlo „jeden technický zásah = jeden ticket“.

V mnoha implementacích se však ticket stal současně požadavkem, schválením, časovým oknem, auditní stopou i účetní jednotkou práce. Tento model funguje, když člověk připraví jednu změnu a jiný člověk ji jednou provede. U agenta se jednotlivé vrstvy rozpojí: jeden obchodní cíl může vytvořit stovky větví, testovacích běhů, artefaktů a dílčích nasazení.

Agent pracuje v cyklu, ne v jednom kroku

Současné agentní frameworky počítají s opakovaným používáním nástrojů, větvením postupu, udržováním stavu, tracingem a pozastavením běhu na schvalovacích bodech. Agent tedy nedostane jen příkaz a nevydá jeden výsledek. Průběžně pozoruje výstupy, mění další postup a skládá delší sekvenci akcí.

Microsoft tento rozdíl popisuje přímo: agent může plánovat, řetězit akce napříč systémy a volat nástroje v pořadí, které u každého jednotlivého kroku explicitně neschválil člověk. Právě proto nestačí převzít model servisního účtu a přidat k němu prompt.

Novou jednotkou řízení je mandát agenta

Mandát není dlouhý prompt. Prompt popisuje záměr. Mandát spojuje obchodní autorizaci s technicky vynutitelnými hranicemi. Jeden záznam může zastřešit velké množství kroků, ale pouze tehdy, když je každý krok navázán na stejnou identitu, rozsah a auditní stopu.

Lidské schválení se přesouvá na hranice

Pokus schvalovat každý krok vytváří pouze iluzi dohledu. OpenAI doporučuje automatické guardrails pro opakovatelné kontroly a lidské pozastavení před citlivými akcemi s vedlejším účinkem. Anthropic současně upozorňuje na approval fatigue: v jejich telemetrii uživatelé schválili přibližně 93 % permission promptů a s rostoucím počtem výzev jim věnovali méně pozornosti.

Člověk proto nemá potvrzovat každé otevření souboru, spuštění testu nebo vytvoření větve. Má rozhodovat v okamžiku, kdy se mění charakter oprávnění nebo dopadu:

• agent chce rozšířit původně schválený rozsah na další systém, data nebo tým;

• má provést zápis do produkce, změnit identitu, oprávnění nebo bezpečnostní politiku;

• krok je nevratný, vytváří externí právní či finanční účinek nebo zasahuje zákazníka;

• výsledek testů je nejednoznačný, vzniká nová třída výjimky nebo agent překročil akční rozpočet;

• další dávka zvyšuje souběh či blast radius nad předem schválenou hranici.

Blast radius je důležitější než počet ticketů

S růstem schopností a přístupu agentů roste jejich teoretický blast radius. Anthropic proto doporučuje neomezovat pouze pravděpodobnost chyby, ale také maximální škodu, kterou může jedna chyba způsobit.

Pro change management to znamená nahradit neurčitou formulaci „agent může opravit všechny dotčené systémy“ konkrétními limity. Rozsah se neměří jen počtem repozitářů. Měří se také privilegii, objemem dat, zákaznickým dosahem, souběhem, délkou běhu a reverzibilitou.

Známé třídy změn lze zachovat. Musí se ale přemapovat

Agentní governance nemusí vytvářet paralelní svět mimo ITSM. Lze ji připojit ke známým třídám změn. Rozdíl je v tom, že se klasifikuje celý mandát a jeho hranice, nikoli každá elementární akce.

Modelový příklad: jedna kampaň, 86 repozitářů a žádných 86 porad

Představme si zranitelnost ve společné knihovně. Analýza najde 86 repozitářů. Starý proces nabízí dvě špatné možnosti: vytvořit 86 ticketů a každý formálně schválit, nebo vše skrýt pod jeden change s neurčitým dopadem.

Lepší model vytvoří jeden kampaňový záznam s manifestem všech dotčených služeb. Agent smí pouze vytvořit větev, upravit závislost, spustit definované testy a založit pull request. Automatické sloučení je povoleno jen u předem klasifikované nízkorizikové skupiny. Nasazení probíhá po dávkách; systém kontroluje přesný artefakt, canary signály, souběh a limit chyb. Nestandardní repozitáře, nekompatibility a žádosti o vyšší oprávnění se oddělí jako výjimky pro člověka.

Výsledkem není méně evidence. Je jí více a je přesnější: jeden schválený mandát, 86 navázaných objektů, kompletní trace jednotlivých kroků, důkazy každého artefaktu a samostatná rozhodnutí pouze tam, kde se změnil předpokládaný risk profile.

Nejčastější selhání agentního change managementu

• Jeden široký ticket slouží jako alibi pro libovolný počet neomezených zásahů.

• Každý tool call vytváří mikro-ticket, který lidé bez čtení hromadně potvrzují.

• Agent používá identitu zaměstnance, takže nelze oddělit lidské a autonomní akce.

• Audit uchová pouze finální odpověď, nikoli tool calls, artefakty, handoffy, approvals a skutečné side effects.

• Agent smí měnit vlastní prompt, policy, nástroje nebo oprávnění, kterými je řízen.

• Běh nemá rozpočet akcí, času, nákladu ani souběhu a pokračuje, dokud formálně nedokončí úlohu.

• Schválení přichází až po provedení kroku nebo je technicky možné jej obejít bez nezávislé stopy.

Co má měřit vedení

Počet uzavřených ticketů je u agentní automatizace téměř bez významu. Stejný počet ticketů může reprezentovat jednu bezpečně řízenou kampaň i stovky nekontrolovaných zásahů. Užitečnější jsou:

• podíl akcí, které zůstaly uvnitř schváleného mandátu a policy;

• počet a typ výjimek, scope expansion a lidských approval bodů;

• nejvyšší skutečně dosažený blast radius a souběh;

• čas od překročení hranice k automatickému zastavení a odebrání identity;

• change failure rate, doba obnovy a počet chyb zachycených ještě před vedlejším účinkem;

• úplnost vazby mandát; identita; tool call; artefakt; deployment; výsledek;

• počet trvalých bypassů a změn agentních politik bez nezávislého review.

Třicetidenní přechod od ticketů k řízení mandátu

Otázka budoucího CAB proto nebude znít „kolik změn agent udělal?“. Bude znít: „Jaký mandát měl, jak daleko se skutečně dostal a dokázal jej systém zastavit dříve, než překročil přijatelný dopad?“