Agenții AI primesc bugete și obiective: câtă autonomie poate ceda o companie fără să piardă controlul?
Un asistent care propune trei hoteluri este ușor de evaluat: te uiți la opțiuni și alegi. Un agent care caută, compară, rezervă și plătește schimbă natura relației. Compania nu îi mai cere doar o informație, ci îi permite să producă efecte în afara conversației, folosind bani, conturi și date care aparțin organizației. Comoditatea devine reală, iar greșeala poate deveni la fel de concretă.
Promisiunea este atractivă pentru o firmă în care oamenii pierd timp cu operațiuni repetitive. Un agent ar putea pregăti comenzi, urmări răspunsuri, actualiza evidențe și rezolva etapele intermediare ale unei sarcini. Întrebarea dificilă apare când întâlnește o situație care nu a fost anticipată: continuă în limitele unui mandat clar sau improvizează o soluție pe care compania nu ar fi acceptat-o?
Autonomia nu trebuie înțeleasă ca un comutator între control total și libertate deplină. Ea se poate împărți după tipul acțiunii, valoare, destinatar și posibilitatea de anulare. Pentru o companie din România, un agent util va avea nevoie de obiective inteligibile și de limite aplicate în sistemele pe care le folosește, nu doar de o instrucțiune politicoasă să fie atent.
Un obiectiv comercial nu este suficient pentru a defini mandatul
Un agent folosește un model AI împreună cu instrumente prin care poate observa rezultate și continua activitatea. Diferența față de un chatbot simplu este capacitatea de a alege pași și de a acționa în aplicații. Performanța nu depinde astfel numai de model, ci și de mediul de lucru, de accesul primit și de felul în care este construit fluxul.
„Redu costurile cu deplasările” pare un obiectiv clar, dar lasă multe lucruri nespuse. Cel mai ieftin bilet poate presupune o escală imposibilă, bagaj insuficient sau condiții de anulare nepotrivite. Dacă agentul optimizează doar prețul afișat, poate îndeplini indicatorul și totuși produce o alegere proastă. Mandatul trebuie să includă condițiile care fac rezultatul acceptabil pentru organizație.
Într-un scenariu ipotetic, agentul poate căuta zboruri și pregăti o rezervare pentru un coleg, însă cumpărarea este permisă numai în anumite intervale, la furnizori acceptați și cu reguli explicite despre modificare. Dacă întâlnește o excepție, o trimite persoanei responsabile. Compania păstrează astfel flexibilitatea căutării fără să cedeze implicit și dreptul de a decide orice compromis.
Este importantă și delimitarea acțiunilor care seamănă între ele. Citirea unui document nu implică dreptul de a-l edita, iar redactarea unui e-mail nu implică dreptul de a-l trimite. O comandă pregătită pentru verificare este diferită de un contract acceptat. Interfața poate prezenta toate aceste operațiuni ca pași firești, dar efectele lor justifică permisiuni distincte.
Mandatul are nevoie și de durată. Accesul acordat pentru o campanie sau o deplasare nu trebuie presupus valabil la nesfârșit. Când se schimbă obiectivul, beneficiarul ori echipa, condițiile trebuie reevaluate. O sarcină încheiată ar trebui să lase în urmă rezultate și evidențe verificabile, fără să mențină inutil posibilitatea unor acțiuni ulterioare.
Aceste limite nu trebuie să rezolve prin instrucțiuni fiecare situație imaginabilă. Scopul este identificarea zonelor în care agentul poate alege și a celor în care trebuie să se oprească. O formulare precum „găsește cea mai bună soluție” poate rămâne utilă pentru explorare, dar este insuficientă ca autorizare generală a cheltuielilor și transmiterii de informații.
Bugetul trebuie verificat în afara conversației cu modelul
Un plafon scris în instrucțiuni ajută agentul să înțeleagă intenția, dar nu reprezintă singur un control financiar. Sistemul care execută plata sau comanda ar trebui să verifice independent condițiile aprobate. Recomandările OWASP privind autonomia excesivă insistă tocmai asupra limitării funcțiilor, permisiunilor și acțiunilor, cu aplicarea autorizării în componentele care primesc solicitările agentului.
Bugetul are mai multe dimensiuni. O limită pe tranzacție nu limitează automat suma cheltuită într-o săptămână, iar un plafon total nu stabilește ce categorii de produse sunt permise. Mai trebuie definite moneda, taxele și costurile suplimentare. Separat există costul funcționării agentului, care poate crește chiar dacă acesta nu finalizează nicio achiziție utilă companiei.
Un exemplu orientativ ar fi un mandat de maximum 500 de euro pentru consumabile, într-o perioadă stabilită, cu furnizori și categorii aprobate. Această sumă nu reprezintă o recomandare universală; pragul potrivit depinde de activitate și de impactul unei greșeli. Important este ca plafonul să includă comenzile relevante și să nu poată fi ocolit prin fragmentarea lor.
Trebuie luate în calcul și operațiunile aflate încă în curs. Dacă două cereri verifică același buget înainte să fie înregistrată prima cheltuială, fiecare poate părea acceptabilă separat. Proiectarea unui control care rezervă suma pentru comenzile în așteptare este o măsură practică de luat în considerare. Verificarea trebuie să privească situația comună, nu doar fotografia fiecărei cereri izolate.
O altă situație banală este lipsa unui răspuns de la aplicație. Agentul nu trebuie să presupună că operațiunea a eșuat și să cumpere din nou. Fluxul ar trebui să poată identifica repetarea aceleiași solicitări și să verifice starea comenzii. Altfel, o încercare de a fi eficient poate produce dubluri, cu timp suplimentar pentru anulări și reconciliere.
Nici furnizorul acceptat nu rezolvă toate riscurile. O ofertă poate include un abonament, o reînnoire automată sau obligații ulterioare. Mandatul financiar trebuie corelat cu tipul de angajament permis. Prețul inițial redus nu justifică automat acceptarea unor condiții contractuale noi, iar agentul trebuie să știe când cumpărarea depășește operațiunea obișnuită pentru care a primit acces.
Informația întâlnită în lucru poate încerca să schimbe instrucțiunile
Agentul poate citi e-mailuri, pagini web și documente pe care compania nu le controlează. Acestea sunt surse de informații, dar pot conține și instrucțiuni malițioase. Atacul de tip prompt injection încearcă să transforme conținutul întâlnit în lucru într-o comandă pentru sistem. Riscul crește atunci când aceeași aplicație poate atât interpreta mesajul, cât și transmite date sau executa operațiuni.
Într-un exemplu ipotetic, o ofertă trimisă agentului de achiziții ar putea susține că o procedură urgentă cere încărcarea evidenței furnizorilor într-un portal nou. Faptul că textul apare într-un document relevant comercial nu îi conferă autoritate asupra regulilor companiei. Agentul trebuie să trateze solicitarea ca pe un conținut de evaluat, iar accesul disponibil să limiteze eventualele consecințe.
De aceea, un agent de aprovizionare nu are nevoie implicit de acces la toate dosarele de personal sau la întregul e-mail al directorului. Identitatea și permisiunile sale ar trebui să reflecte sarcina. Un cont separat ori un acces limitat poate face mai ușoară urmărirea operațiunilor, în funcție de arhitectura aplicațiilor, decât folosirea nediferențiată a drepturilor unui administrator.
Protecția presupune mai multe niveluri. Instrucțiunile modelului, configurarea instrumentelor și verificările din aplicațiile conectate trebuie să lucreze împreună. Niciun mesaj care cere agentului să ignore atacurile nu oferă, singur, o garanție. Pentru proiectarea sistemului, presupunerea prudentă este că un conținut poate fi interpretat greșit și că impactul trebuie limitat chiar și atunci.
Datele pot fi expuse și fără o plată. Trimiterea unei oferte interne către un destinatar greșit, încărcarea unui contract într-un serviciu neaprobat sau includerea unui atașament nepotrivit au consecințe proprii. O politică de autonomie trebuie să privească divulgarea informațiilor separat de valoarea tranzacției. Un e-mail fără cost direct poate fi mai sensibil decât o comandă mică de consumabile.
Este util ca interfața de verificare să arate efectul concret: destinatar, documente, valoare și condiții. Explicația fluentă a agentului despre intențiile sale nu înlocuiește această vizibilitate. Persoana care aprobă are nevoie să compare acțiunea propusă cu mandatul, fără să reconstruiască dintr-o conversație lungă ce fișiere vor pleca și către cine.
Controlul uman trebuie păstrat acolo unde poate schimba rezultatul
Solicitarea unei aprobări pentru fiecare citire poate încetini inutil munca. La extrema cealaltă, aprobarea generală a unui plan vag poate ascunde deciziile importante care apar ulterior. O variantă rezonabilă este separarea operațiunilor obișnuite de excepții și de acțiunile greu reversibile, cu intervenție umană acolo unde consecințele justifică verificarea. Pragurile trebuie adaptate procesului, nu copiate mecanic.
Persoana desemnată trebuie să aibă timp și informații pentru verificare. Dacă primește zeci de cereri asemănătoare, fără evidențierea diferențelor, aprobarea riscă să devină un gest automat. Calitatea controlului depinde și de prezentare: ce s-a schimbat, ce limită este depășită și de ce este necesară intervenția. Un buton apăsat repetat nu demonstrează singur o supraveghere eficientă.
Testarea ar trebui să includă situații neplăcute, cu date și conturi de test: furnizor indisponibil, preț schimbat, răspuns întârziat și instrucțiuni contradictorii. Rezultatul urmărit este felul în care agentul se oprește sau cere ajutor, nu numai succesul unei demonstrații ideale. Pentru o companie, excepțiile pot consuma mai mult timp și bani decât operațiunile care funcționează conform scenariului.
Este necesară și o cale practică de oprire: suspendarea accesului, revocarea acreditărilor și identificarea operațiunilor în curs. Oprirea agentului nu anulează automat o comandă deja acceptată și nu recuperează informația transmisă. Planul trebuie să includă persoanele care urmăresc aceste efecte și pot continua activitatea manual, astfel încât incidentul să nu blocheze întreaga funcție a companiei.
Evidențele ar trebui să permită reconstruirea acțiunilor: cine a autorizat mandatul, ce instrument a fost folosit și ce rezultat a întors. Explicațiile produse de model pot ajuta, dar nu sunt un substitut pentru înregistrările aplicațiilor. Responsabilitatea organizației se clarifică prin atribuții, contracte și fapte verificabile, fără să fie transferată pur și simplu unui sistem care a primit un nume și un obiectiv.
Compania poate ceda autonomie în etape, după rezultate și după capacitatea de a limita pierderile. Un agent care lucrează bine cu acces restrâns poate primi atribuții suplimentare, însoțite de controale potrivite. Întrebarea decisivă rămâne dacă organizația știe ce se poate întâmpla, poate observa la timp o abatere și poate interveni. Această capacitate face autonomia utilizabilă în afaceri.