RO
English (English)
Ultima actualizare: 26 septembrie 2026. Articolul descrie practicile și sursele disponibile la această dată. Secțiunea despre 2027 conține scenarii de planificare, nu predicții garantate. Informațiile juridice sunt generale și nu înlocuiesc analiza aplicată situației concrete.
Un agent AI devine cu adevărat util când nu se limitează la a redacta un răspuns, ci poate consulta aplicații, modifica înregistrări, trimite mesaje sau porni procese. În același moment apare însă o întrebare pe care multe proiecte pilot o amână: în numele cui acționează agentul, ce are voie să facă și cum putem demonstra ulterior ce s-a întâmplat?
Pentru un IMM, răspunsul nu trebuie să fie o infrastructură greoaie de corporație. Este nevoie de un set proporțional de controale, aplicate în locurile potrivite. Modelul lingvistic poate interpreta o cerere și poate propune următorul pas, dar nu ar trebui să fie singura componentă care decide dacă acel pas este autorizat. Permisiunile, aprobările și jurnalizarea trebuie impuse de cod, identitate și politici aflate în afara modelului.
Acest ghid explică o arhitectură practică pentru agenți AI care lucrează cu e-mail, CRM, documente, facturi, site-uri sau infrastructură. Nu promite risc zero și nu tratează aprobarea umană ca pe o soluție universală. Obiectivul este mai realist: să limităm impactul unei erori, să oprim acțiunile nepermise înainte de execuție și să putem reconstrui evenimentele fără a transforma jurnalul într-o nouă bază de date sensibilă.
Un agent de încredere are nevoie de șase proprietăți:
Aceste principii nu sunt specifice unui anumit model sau furnizor. Ele adaptează practici consacrate de control al accesului și arhitectură zero trust la particularitățile agenților AI: planuri dinamice, apeluri de instrumente, conținut extern nesigur, delegare și posibilitatea de a produce efecte în mai multe sisteme.
Un chatbot produce, de regulă, text pe care omul îl citește înainte de a-l folosi. Un agent poate parcurge o buclă mai lungă:
Riscul nu provine doar dintr-un răspuns greșit. Poate proveni dintr-un apel corect executat, dar nepotrivit: un e-mail trimis destinatarului greșit, o reducere aplicată unui client neeligibil, o înregistrare ștearsă, un fișier confidențial încărcat într-un serviciu extern sau o comandă rulată în producție.
Cercetarea confirmă că aceasta nu este doar o problemă teoretică. ToolEmu a construit scenarii pentru instrumente cu miză ridicată și a identificat eșecuri cu posibile consecințe financiare sau de confidențialitate. AgentDojo evaluează agenți care folosesc instrumente peste date externe nesigure și arată că atacurile de tip prompt injection pot devia acțiunile agentului. Aceste rezultate nu oferă o rată universală de risc pentru orice implementare, dar demonstrează de ce un prompt bine formulat nu poate înlocui controlul tehnic.
Regula de proiectare este simplă:
Modelul propune. Politica autorizează. Instrumentul execută. Jurnalul dovedește.
Autentificarea răspunde la întrebarea „cine este?”. Pentru un flux agentic pot exista simultan mai multe identități:
Dacă toate apar în jurnal sub același cont generic, responsabilitatea devine imposibil de stabilit.
Autorizarea răspunde la întrebarea „ce poate face această identitate asupra acestei resurse, în acest context?”. Nu este suficient ca agentul să aibă acces la CRM. Politica trebuie să poată diferenția între citirea unui contact, modificarea lui, exportul unei liste și ștergerea înregistrării.
Delegarea înseamnă că o persoană sau un serviciu îi acordă agentului o autoritate limitată pentru o sarcină. Autoritatea delegată nu ar trebui să fie mai mare decât autoritatea persoanei și nici să fie transmisă automat unui subagent fără limite explicite.
Aprobarea este o decizie punctuală privind o acțiune concretă. Ea nu substituie autorizarea. O interfață care îi cere utilizatorului să aprobe o plată nu trebuie să permită plata dacă utilizatorul nu avea oricum dreptul să o facă.
Auditul este capacitatea de a reconstrui cine a cerut, ce a decis sistemul, ce politică a fost aplicată, ce s-a executat și cu ce rezultat. Auditul nu este același lucru cu monitorizarea în timp real și nici cu stocarea integrală a conversațiilor.
Principiile de bază sunt mature, dar identitatea și delegarea pentru agenți sunt încă o zonă în dezvoltare. NIST a publicat în februarie 2026 un document conceptual despre identitatea și autorizarea agenților software și AI. Statutul său este de document conceptual, nu de standard final. El arată însă că industria încearcă să aplice agenților practici cunoscute de identity and access management, în loc să inventeze o securitate separată pentru fiecare platformă.
NIST Zero Trust Architecture formulează un principiu relevant: accesul se decide pentru fiecare cerere, cu privilegii minime, fără încredere implicită bazată doar pe poziția în rețea. NIST SP 800-53 Rev. 5 oferă familii consacrate de controale pentru acces, privilegii minime, identificare, audit și protejarea jurnalelor. Aceste publicații nu sunt rețete dedicate exclusiv agenților, dar constituie o bază solidă.
În zona agenților, OWASP Top 10 for Agentic Applications 2026 și ghidul Agentic AI Threats and Mitigations tratează riscuri precum deturnarea obiectivului, folosirea abuzivă a instrumentelor, identitatea și privilegiile, memoria contaminată și eșecurile în cascadă. Publicat la 1 septembrie 2026, OWASP Agent Control Standard propune puncte de control și politici declarative aplicate în timpul execuției, dar este un standard deschis nou, nu o dovadă automată că o implementare este sigură. Documentația actuală OpenAI despre guardrails și aprobări recomandă plasarea verificărilor la limita instrumentului care produce efectul. Google Cloud descrie identități dedicate, privilegii minime, politici de refuz și moduri cu aprobare umană pentru instrumentele MCP.
Concluzia practică din 2026 este că nu există un singur produs care să transforme automat un agent într-un sistem de încredere. Controlul rezultă din combinarea identității, politicii, izolării, aprobărilor, jurnalizării și testării.
O permisiune utilă pentru agenți trebuie descrisă pe mai multe axe:
| Axă | Întrebarea de control | Exemplu |
|---|---|---|
| Instrument | Ce integrare poate folosi? | CRM, e-mail, facturare |
| Operație | Ce funcție poate apela? | citește, creează, modifică, șterge |
| Resursă | Asupra căror obiecte? | doar lead-urile echipei București |
| Câmpuri | Ce date poate vedea sau schimba? | fără CNP și fără date bancare |
| Mediu | Unde poate acționa? | test, nu producție |
| Timp | Cât este valabil accesul? | 20 de minute pentru execuția curentă |
| Volum | Câte operații poate face? | maximum 25 de mesaje pe rulare |
| Valoare | Până la ce prag? | ofertă sub 5.000 lei, fără plată |
| Destinație | Cui poate transmite date? | doar domeniile aprobate |
| Context | În numele cui și pentru ce scop? | pentru utilizatorul X, tichetul Y |
Un rol generic precum admin nu exprimă aceste limite. Nici un scope larg precum crm.write nu este suficient pentru un agent care trebuie doar să actualizeze starea unui lead.
Evitați conturile tehnice comune mai multor agenți. O identitate distinctă permite:
Identitatea agentului nu trebuie să ascundă utilizatorul. Într-un flux delegat, jurnalul ar trebui să păstreze atât identitatea agentului, cât și utilizatorul sau procesul în numele căruia acționează.
Cheile API, tokenurile de acces și parolele nu trebuie introduse în prompt, memorie sau documentele consultate de model. Un gateway, un vault sau chiar un serviciu intern simplu poate atașa credențialul doar după ce politica a acceptat apelul.
Preferințele tehnice sunt:
RFC 9700 reunește practicile curente de securitate OAuth 2.0, iar RFC 9396 permite descrierea unor autorizații mai detaliate decât o listă simplă de scope-uri. Nu orice IMM trebuie să implementeze singur aceste protocoale, dar furnizorul ales ar trebui să poată explica audiența tokenurilor, expirarea, revocarea și limitarea privilegiilor.
Fraza „nu șterge nimic fără aprobare” din prompt este utilă ca îndrumare, dar nu este o barieră de securitate. Un atac de tip prompt injection, o eroare de planificare sau un context ambiguu poate determina modelul să o ignore ori să o interpreteze greșit.
Controlul trebuie repetat chiar înainte de operație:
Această verificare dublă previne situația în care orchestratorul acceptă o acțiune, dar API-ul execută cu un cont tehnic nelimitat.
Un agent care analizează facturi nu are nevoie implicit de dreptul de a le plăti. Un agent care redactează un articol nu trebuie să îl poată publica automat. Separarea poate fi făcută prin instrumente diferite, identități diferite sau pași diferiți ai fluxului.
Pentru sarcini sensibile, este util un model în două etape:
Modelul nu primește acces direct la baza de date dacă o funcție îngustă, precum actualizeaza_status_comanda(id, status_permis), este suficientă.
Nu orice apel necesită intervenție umană. Dacă omul trebuie să confirme fiecare citire, sistemul devine lent și oamenii învață să apese „Aprobă” fără să verifice. Aceasta este oboseala de aprobare.
O clasificare practică poate porni de la cinci întrebări:
| Nivel | Exemple | Control recomandat |
|---|---|---|
| Scăzut | căutare în documente interne nesensibile, citire catalog produse | execuție automată, limite de volum, jurnal |
| Moderat | creare draft, actualizare câmp reversibil, răspuns intern | politică automată, validare de schemă, eșantionare umană |
| Ridicat | trimitere externă, publicare, modificare preț, acces la date personale | aprobare explicită înainte de efect, autentificare actuală |
| Critic | plată, ștergere masivă, acces privilegiat în producție, schimbare cont bancar | control dublu, autentificare suplimentară, limite stricte sau interdicție |
Aceasta este o matrice de pornire, nu o clasificare juridică. Pragurile trebuie adaptate companiei, procesului și consecințelor reale.
O aprobare bună nu cere confirmarea unei intenții vagi precum „agentul vrea să continue”. Interfața trebuie să arate:
Aprobarea trebuie legată criptografic sau printr-un identificator unic de acțiunea concretă. Dacă agentul modifică destinatarul, suma sau atașamentul după aprobare, aprobarea veche nu mai este valabilă.
Principiul celor patru ochi este potrivit pentru acțiuni cu impact mare: plăți peste prag, schimbarea contului unui furnizor, exporturi masive de date, modificări privilegiate în producție ori ștergeri ireversibile. A doua persoană trebuie să aibă rolul corespunzător și să nu fie aceeași identitate care a inițiat cererea.
O cerere de aprobare trebuie să expire. Dacă serviciul de politici sau aprobare nu este disponibil, acțiunile sensibile ar trebui să eșueze în siguranță, nu să fie executate implicit. Refuzul trebuie transmis agentului ca stare finală clară, pentru a preveni reformularea repetată a aceleiași acțiuni până când trece de control.
Un jurnal util răspunde la întrebări, nu doar acumulează text. Pentru fiecare rulare și apel important este recomandat să existe:
Pentru fluxurile distribuite, OpenTelemetry oferă convenții de trasare care pot lega invocarea agentului, apelurile modelului și execuțiile instrumentelor. Aceste urme tehnice trebuie completate cu deciziile de politică și aprobările de business. O simplă urmă de performanță nu este automat un jurnal de audit.
Auditabilitatea nu presupune păstrarea unui raționament intern complet. Acesta poate fi indisponibil, instabil sau poate conține date pe care nu dorim să le reținem. Mai util este să stocăm:
Astfel putem explica procesul observabil fără să tratăm un text generat de model drept justificare juridică sau adevăr absolut.
Un jurnal care păstrează tokenuri, parole, prompturi integrale, atașamente sau date personale fără limită poate produce un risc mai mare decât cel pe care încearcă să îl reducă. Materialele EDPB despre riscurile de confidențialitate ale LLM-urilor recomandă controale de acces și jurnalizare, dar și minimizarea datelor din loguri.
Practici minime:
Nu este necesar ca fiecare element să fie un produs separat. Importantă este separarea responsabilităților:
Politica trebuie să fie aplicată într-o componentă pe care modelul nu o poate modifica. Dacă agentul poate edita fișierul care îi definește limitele, controlul este doar aparent.
Următoarea regulă este conceptuală, nu sintaxă pentru un produs anume:
Avantajul politicilor explicite este că pot fi revizuite, testate și versionate. Instrucțiunea naturală din prompt rămâne utilă pentru comportament, dar politica deterministă decide autoritatea.
Agentul citește cererea unui client, consultă catalogul și pregătește o ofertă. O configurație echilibrată ar putea permite automat:
Ar solicita aprobare pentru:
Ar refuza complet exportul bazei de clienți și schimbarea datelor bancare. Jurnalul ar lega oferta trimisă de prețurile și politica de discount valabile în acel moment.
Agentul poate extrage datele facturii, verifica furnizorul și pregăti plata. Totuși, dreptul de citire a facturilor nu implică dreptul de a plăti.
Un flux sigur separă:
Schimbarea IBAN-ului și prima plată către un beneficiar ar trebui să declanșeze o verificare suplimentară, nu să fie învățate automat dintr-un e-mail primit.
Agentul cercetează și redactează un articol în CMS. Citirea articolelor existente și salvarea unui draft sunt operații reversibile. Publicarea, modificarea unui articol deja publicat și ștergerea unei imagini au impact extern.
Permisiunile pot fi separate astfel:
Acest model previne atât publicarea accidentală, cât și pierderea modificărilor făcute între timp de o persoană.
Model Context Protocol standardizează modul în care aplicațiile expun instrumente și resurse agenților. Protocolul nu elimină obligația de a proiecta permisiunile. Un server MCP care expune o funcție periculoasă cu un token prea larg rămâne periculos.
Documentația și SDK-urile MCP actuale se bazează pe OAuth și pe metadate ale resursei protejate. Practicile relevante includ:
Specificația și ghidurile MCP trebuie verificate la momentul implementării, deoarece protocolul evoluează. Pentru un IMM, criteriul esențial nu este doar compatibilitatea MCP, ci capacitatea furnizorului de a limita fiecare instrument și de a produce urme de audit utile.
Un agent nu ar trebui promovat în producție doar pentru că îndeplinește corect câteva demonstrații. Testarea trebuie să acopere atât succesul, cât și refuzul.
Verificați explicit:
Introduceți în documente, e-mailuri și pagini de test instrucțiuni care încearcă să convingă agentul să ignore obiectivul, să divulge date sau să folosească alt instrument. Scopul nu este doar să vedeți dacă modelul refuză. Verificarea esențială este dacă sistemul de autorizare blochează efectul chiar atunci când modelul propune un apel greșit.
Rulați aceste teste după schimbarea modelului, promptului, instrumentelor, politicilor sau conectorilor. O evaluare veche nu garantează comportamentul unei configurații noi.
Înainte de execuție reală, agentul poate lucra în mod umbră: propune acțiuni, iar sistemul le compară cu deciziile oamenilor fără a produce efecte. Următoarea etapă permite automat operații cu risc scăzut și păstrează aprobarea pentru celelalte. Autonomia crește numai pe baza datelor observate, nu a impresiei că demonstrația „pare inteligentă”.
Pe lângă timp economisit și rată de finalizare, urmăriți:
O rată foarte mare de aprobare nu dovedește neapărat siguranță. Poate indica aprobări inutile sau oboseală. O rată foarte mare de refuz poate indica un agent prost configurat ori o politică incompatibilă cu procesul.
Permisiunile și auditul sunt controale tehnice. Ele nu stabilesc singure legalitatea prelucrării sau clasificarea unui sistem AI.
Dacă agentul prelucrează date personale, se aplică în continuare principiile GDPR: scop determinat, minimizarea datelor, securitate, perioade de păstrare și capacitatea operatorului de a demonstra conformitatea. Jurnalul trebuie proiectat în acord cu aceste principii. A păstra totul „pentru audit” fără scop și termen nu este o soluție prudentă.
Regulamentul european privind inteligența artificială include cerințe de păstrare automată a jurnalelor și supraveghere umană pentru anumite sisteme cu risc ridicat. Aceste obligații nu transformă orice agent intern într-un sistem cu risc ridicat. Clasificarea depinde de utilizare, rolul organizației și context. În plus, calendarul aplicării unor reguli pentru sistemele cu risc ridicat a fost modificat și clarificat în 2026. Comisia Europeană menține o pagină actualizată privind aplicarea AI Act.
Pentru decizii care afectează angajați, creditare, acces la servicii esențiale sau alte drepturi, este necesară o evaluare juridică specifică. Acest articol oferă un cadru tehnic, nu consultanță juridică.
Promptul nu reduce privilegiile contului. Dacă agentul este compromis sau greșește, impactul maxim rămâne cel al administratorului.
Consimțământul inițial pentru o integrare nu este aprobare pentru orice acțiune viitoare. Operațiile sensibile trebuie evaluate în contextul concret.
Prea multe aprobări produc rutină. Mai mult, omul poate fi indus în eroare de o descriere incompletă. Interfața trebuie să arate efectul exact, iar politica trebuie să blocheze operațiile neautorizate indiferent de aprobarea superficială.
Logurile unui singur furnizor pot arăta apelul modelului, dar nu întreaga succesiune dintre utilizator, orchestrator, politică, aprobare și API-ul final. Verificați dacă există identificatori de corelație și posibilitate de export.
Aceasta poate copia în jurnal informații personale, secrete și documente integrale. Definiți câmpurile necesare, mascați conținutul și păstrați referințe sau hash-uri unde textul complet nu este justificat.
Delegarea în lanț poate amplifica privilegiile și poate pierde legătura cu utilizatorul inițial. Fiecare subagent trebuie să primească un set cel mult egal și, de regulă, mai restrâns, adaptat subtaskului.
Reîncercarea fără idempotency key și fără verificarea stării poate dubla plăți, comenzi sau mesaje. Instrumentele cu efect trebuie să distingă o reluare sigură de o operație nouă.
Următoarele sunt scenarii plauzibile, nu certitudini.
Inițiativele NIST și evoluția platformelor cloud indică posibilitatea unor identități de workload dedicate agenților, cu delegare și trasabilitate mai bune. Este probabil să vedem integrare mai strânsă între registre de agenți, IAM, gateway-uri și sisteme de politici.
În locul scope-urilor statice și largi, platformele pot folosi tot mai des autorizare la cerere, limitată la acțiune, resursă, sumă și interval. Aceasta ar reduce credențialele permanente, dar poate crește complexitatea și dependența de servicii centrale.
Operațiile de risc moderat ar putea fi evaluate automat de un motor de politici plus un model de control separat. Cercetarea din 2026 arată însă că monitorii bazați pe modele pot fi la rândul lor ocoliți. Prin urmare, un astfel de evaluator nu ar trebui să înlocuiască barierele deterministe pentru operații critice.
Pe măsură ce sarcinile trec între agenți și organizații, vor fi necesare dovezi portabile despre delegare, politici și rezultate. Convențiile de observabilitate ajută, dar nu există încă o soluție universală pentru non-repudiere și proveniență completă în fluxuri agentice.
Pentru un IMM, strategia sănătoasă este să folosească acum standardele existente, să evite blocarea într-un format proprietar și să păstreze controlul asupra identităților, politicilor și logurilor esențiale.
Încrederea într-un agent AI nu trebuie măsurată prin cât de convingător explică ceea ce intenționează să facă. Ea trebuie construită prin limite verificabile.
Un agent de încredere nu este un agent căruia îi acordăm acces nelimitat pentru că modelul pare capabil. Este un agent care poate lucra eficient într-un perimetru clar, folosește autoritate temporară, cere aprobarea potrivită înainte de efect și lasă dovezi suficiente pentru verificare. Dacă o eroare sau un atac apare, arhitectura limitează paguba și permite intervenția.
Pentru majoritatea IMM-urilor, primul pas nu este achiziția unei platforme complexe. Este inventarierea acțiunilor, separarea citirii de scriere, eliminarea conturilor administrative din fluxurile automate și definirea a trei categorii: ce poate face agentul singur, ce necesită aprobare și ce nu îi permitem deloc.
Dacă vrei să evaluăm un proces concret, permisiunile necesare și arhitectura de control potrivită companiei tale, discută cu echipa Imagine Infinity. Putem transforma un pilot promițător într-un sistem măsurabil, auditabil și pregătit pentru producție.