Agenții tăi de IA au nevoie de fișe de post, nu de prompturi mai bune

Întrebați o companie ce are voie să facă o nouă analistă în departamentul de conturi de plătit și veți primi un răspuns precis. Ea lucrează în aceste sisteme, cu acești furnizori, iar orice sumă care depășește un plafon de aprobare — să zicem, 10.000 de dolari — ajunge la managerul ei pentru semnătură. Se află în perioada de probă în primele câteva luni. De obicei, toate acestea sunt consemnate într-un tabel de delegare a autorității, pe care auditul intern îl verifică în fiecare an.

Întrebați aceeași companie ce are voie să facă noul său agent pentru facturi și veți primi adesea o captură de ecran a unui prompt.

Această discrepanță mă preocupă mai mult decât orice evaluare comparativă a modelelor. Angajăm o forță de muncă digitală fără sistemul de management pe care l-am construit pentru oameni de-a lungul unui secol: nimeni nu-i consemnează autoritatea, nimeni nu-i testează discernământul înainte să înceapă și nimeni nu a exersat procedura de dezactivare.

De ce un prompt nu poate înlocui fișa postului

Un prompt descrie intenția. Spune la ce folosește agentul. Rareori precizează ce nu are voie să facă în nicio situație, unde îi sunt limitele sau când trebuie să se oprească și să lase decizia în seama unei persoane.

Iar când un prompt precizează aceste lucruri, nimic nu garantează respectarea lor. O instrucțiune prin care i se spune unui agent să nu acorde rambursări de peste 500 de dolari este doar o solicitare adresată unui sistem probabilistic. Niciun auditor nu ar aproba „i-am cerut frumos analistei” drept măsură de control pentru o persoană, așa că nu înțeleg de ce acceptăm așa ceva în cazul unui program.

Specialiștii în securitate au deja un nume pentru acest rezultat. OWASP Top 10 pentru aplicațiile LLM enumeră autonomia excesivă printre riscurile majore, cauzată de funcționalități excesive, permisiuni prea largi sau autonomie excesivă. Pe scurt, e ca și cum unui angajat i s-ar da, chiar din prima zi, cheile de la toate. Recomandările OWASP seamănă cu o listă de verificare pentru un manager bun: oferă-i agentului doar instrumentele de care are nevoie, limitează-i permisiunile, solicită aprobarea unei persoane pentru acțiunile cu impact major și aplică autorizarea în sistemele din aval, în loc să te bazezi pe model să se controleze singur.

Aș sublinia ultimul punct. Autorizația trebuie să fie aplicată acolo unde are loc acțiunea: în identitatea de serviciu proprie a agentului, în permisiunile acordate instrumentelor sale și în plafonul de cheltuieli de la gateway-ul API. Să rulezi agenți folosind un cont de serviciu comun e ca și cum cinci persoane ar împărți aceeași legitimație. Când ceva nu merge bine, jurnalul de audit arată că a acționat contul de serviciu, iar tu rămâi să ghicești care agent a fost responsabil.

Anulările indică o problemă de management

Gartner estimează că peste 40% dintre proiectele de IA agentică vor fi anulate până la sfârșitul lui 2027, invocând creșterea costurilor, valoarea neclară pentru afaceri și controalele de risc inadecvate.

Entuziasmul exagerat și produsele imature fac și ele parte din această poveste. Totuși, încercați să priviți cele trei cauze din perspectiva unui director operațional. Costurile cresc când nimeni nu a stabilit un buget. Valoarea rămâne neclară când nimeni nu a consemnat ce rezultate trebuia să producă munca respectivă. Controalele de risc sunt insuficiente când nu există limite, verificări și nicio persoană care să răspundă în mod clar. Gartner nu prezintă lucrurile astfel; aceasta este interpretarea mea. E același lucru care se întâmplă când oamenii sunt lăsați să acționeze fără un sistem de management, iar problema aceasta e mult mai veche decât IA.

Cadrele de lucru identifică aceeași lacună. Cadrul NIST pentru gestionarea riscurilor asociate IA tratează Guvernanța ca funcția care se desfășoară prin Cartografiere, Măsurare și Gestionare, iar Profilul pentru IA generativă extinde această abordare la sistemele generative. Cadrele de lucru nu vă pot oferi însă mecanismele operaționale — autorizațiile, testele și verificările pe care o echipă le aplică efectiv într-o zi de marți. Fără ele, guvernanța rămâne un PDF pe o unitate partajată.

Cum se aplică instrumentele tradiționale de management agenților

Începeți cu fișa postului, care, în cazul unui agent, devine o delegare de autoritate. Înainte ca un agent să interacționeze cu un sistem activ, cineva ar trebui să poată redacta o pagină în care să precizeze ce are voie să facă, ce nu are voie să facă niciodată, care sunt pragurile de aprobare, cine este persoana responsabilă de el și cine îi poate extinde limitele. În matricea RACI, persoana care răspunde în ultimă instanță este un om. Dacă nu puteți redacta acea pagină, rolul nu este pregătit pentru ocupare — și ați spune același lucru și despre angajarea unei persoane.

Două reguli tradiționale privind delegarea autorității se aplică și aici. Nu poți delega o autoritate pe care nu o deții, așa că un subagent nu ar trebui să primească niciodată o delegare mai largă decât agentul care l-a creat. Se aplică în continuare și separarea atribuțiilor. Faptul că un agent poate atât să înregistreze un furnizor, cât și să-l plătească ar constitui aceeași constatare de audit ca în cazul unei persoane.

Urmează testul de selecție. De obicei, testăm agenții așa cum am testa un calculator, verificând dacă răspunsul este corect. Un test pentru un angajat ar verifica dacă acesta a respectat limitele autorizației, a cerut aprobarea atunci când era necesar, a escaladat situația când aceasta depășea sfera atribuțiilor sale și s-a oprit când trebuia.

În cercetările mele, construiesc un test de evaluare cu 50 de scenarii care vizează exact aceste eșecuri: depășirea pragurilor de aprobare, acționarea pe baza unor date învechite, urmarea unor instrucțiuni injectate care extind sfera atribuțiilor și păstrarea accesului după schimbarea rolului. Până acum l-am aplicat doar unor agenți cu comportament prestabilit, pentru a verifica dacă scenariile se desfășoară conform proiectării, așa că nu am rezultate despre modele de raportat. M-a surprins, în timp ce le scriam, cât de obișnuite sunt aceste situații. Sunt modurile obișnuite în care angajații se abat de la atribuțiile lor, reformulate pentru programe. Majoritatea clasamentelor publice evaluează în continuare îndeplinirea sarcinilor, iar foarte puține verifică dacă agentul și-a respectat autoritatea.

Perioada de probă și promovarea se transpun destul de direct. În cazul oamenilor, începem prin a le atribui un rol restrâns și le extindem aria de responsabilitate pe măsură ce își dovedesc discernământul. Agenții își pot câștiga limitele în același fel, dovedind că respectă limitele stabilite, escaladează situațiile în mod adecvat și se opresc fără probleme; acest istoric poate justifica la fel de bine restrângerea autorizației.

Agenții aduc o complicație care nu există în cazul oamenilor. Când un furnizor actualizează modelul de bază, practic ai un nou angajat care poartă vechea legitimație. Aș trata asta ca pe o schimbare și aș retesta agentul înainte ca autorizația să i se aplice în continuare.

Procedura de încetare a activității trebuie exersată înainte să ai nevoie de ea. Dacă ar trebui să oprești acest agent și să-i retragi accesul în următoarea oră, ai putea să o faci? Cine are autoritatea să ia această decizie la 2 noaptea? Ce se defectează în aval și ce angajamente aflate în curs trebuie să anuleze cineva manual? Dacă nimeni nu a făcut această simulare, nu faci decât să speri că mecanismul de oprire de urgență funcționează.

Poți trage un angajat la răspundere. Nu poți trage un agent la răspundere pentru nimic, iar aici comparația nu mai funcționează. Tocmai de aceea autorizația trebuie impusă prin sisteme și fiecare agent trebuie să aibă o persoană desemnată care răspunde de el. Oricum, cineva ajunge să poarte răspunderea. De obicei, este persoana care și-a dat aprobarea, indiferent dacă știa sau nu că își dă acordul.

Ce va întreba analiza incidentului

În cele din urmă, unii dintre acești agenți vor face ceva ce nu ar trebui să facă. Când se va întâmpla asta, analiza de după incident va pune aceleași întrebări pe care le pune deja în cazul oamenilor. Ce avea voie să facă și unde este consemnat acest lucru? Cine a aprobat extinderea accesului? Cât a durat până să fie oprit? Cine răspundea de el?

Dacă răspunsurile sincere sunt „un prompt”, „nimeni nu-și amintește”, „ore” și „neclar”, un model mai bun nu te-ar fi salvat.

Unde ajunge să fie avantajul

Modelele devin resurse închiriate, înlocuite și actualizate după calendarul furnizorului. Două companii pot folosi același model și pot ajunge în situații foarte diferite. Una are agenți cu bugete, limite, responsabili și o pistă de audit pentru fiecare acțiune cu consecințe importante, în timp ce cealaltă are un proiect-pilot costisitor, pe cale să ajungă în statisticile de anulare ale cuiva.

Diferența o face sistemul de management construit în jurul modelului. Acesta se construiește lent, în principal de către oameni care au condus organizații înainte.

Dacă cel mai nou agent al tău și-ar depăși mâine autoritatea, ar observa cineva din compania ta? Și ai putea să-i arăți unui auditor, în scris, unde era limita?