Un agent AI ar trebui să poată realiza numai acțiunile pentru care are o permisiune explicită, într-un proces definit. A putea formula un răspuns, a pregăti o ofertă și a angaja compania într-o promisiune sunt responsabilități diferite. Limitele trebuie aplicate de sistemele conectate și verificate prin rezultate observabile.
Un asistent poate suna convingător chiar când îi lipsește o informație. De aceea, încrederea în formulare nu poate ține locul unei aprobări comerciale. Întrebarea utilă este concretă: ce informație poate citi, ce poate schimba și cine răspunde pentru acea schimbare?
Începem cu acțiunea, nu cu denumirea soluției
Într-un scenariu ipotetic pentru un showroom, același asistent poate răspunde despre program, poate pregăti o solicitare de vizită și poate propune un interval disponibil. Aceste operații au consecințe diferite.
Citirea programului public nu necesită acces la toate datele clienților. Propunerea unui interval nu înseamnă că acel interval a fost rezervat. Confirmarea unei vizite presupune o operație reușită în sistemul de programări, în condițiile acceptate de utilizator.
Am defini permisiunile pentru fiecare pas. Dacă o funcție nu este necesară procesului, nu îi oferim sistemului acces la ea doar pentru că integrarea o permite.
| Acțiune posibilă | Condiție de proiectare |
|---|---|
| Explică o informație publică | Folosește o sursă aprobată și actuală |
| Pregătește un rezumat | Separă informațiile declarate de cele necunoscute |
| Înregistrează o cerere | Are datele necesare, verifică dreptul de acces și evită duplicatele |
| Confirmă o programare | Utilizatorul a ales, iar sistemul a confirmat înregistrarea |
| Oferă o reducere excepțională | Obține aprobarea rolului comercial desemnat |
| Modifică un contract | Urmează un proces distinct de autorizare și verificare |
Tabelul descrie o posibilă împărțire a responsabilităților. Limitele finale depind de serviciu, impactul unei erori și modul în care lucrează compania.
Permisiunea trebuie să existe dincolo de conversație
Instrucțiunea „nu acorda reduceri” este utilă, dar sistemul conectat trebuie, la rândul lui, să limiteze operațiile disponibile. Dacă instrumentul poate aplica orice reducere fără o verificare independentă, conversația rămâne singurul filtru pentru o decizie comercială.
OWASP descrie riscul de autonomie excesivă în relație cu funcțiile, permisiunile și libertatea de acțiune oferite unui sistem. În proiectare, am traduce această preocupare în acces limitat la operațiile necesare și verificări potrivite consecinței.
Contează și identitatea persoanei. O întrebare despre produse poate primi un răspuns public. O cerere despre o comandă trebuie legată de un client verificat înainte de a afișa datele private ale acelei comenzi. Simpla cunoaștere a unui număr de comandă nu trebuie tratată automat ca dovadă suficientă.
Ce facem cu instrucțiunile din documente?
Un document primit pentru ofertare poate conține cerințe tehnice, dar și text care cere sistemului să ignore regulile sau să transmită alte informații. Conținutul primit se tratează ca material de analizat, fără să îi acordăm dreptul de a schimba permisiunile fluxului.
Aceasta este una dintre situațiile discutate în documentația OWASP despre prompt injection. Pentru exemplul nostru, documentul poate contribui la un brief, iar aprobarea unei acțiuni rămâne în mecanismul separat de autorizare.
Un om implicat are nevoie să poată decide
O aprobare este utilă când persoana vede ce urmează să se întâmple: destinatarul, datele utilizate, promisiunea făcută și eventualele neclarități. Un buton „aprobă” lângă un rezumat incomplet poate muta formal responsabilitatea fără să îmbunătățească verificarea.
Am arăta și sursele relevante, modificările față de cererea inițială și următorul pas. Pentru operațiile sensibile am stabili cine poate aproba, cum se înregistrează decizia și cum se oprește fluxul dacă apare o problemă.
Cum verificăm limitele înainte de utilizare?
Testăm și cereri pe care sistemul trebuie să le refuze sau să le predea: acces la comanda altui client, reduceri neautorizate, date contradictorii, integrare indisponibilă ori repetarea aceleiași solicitări. Verificăm rezultatul din sistem, nu doar răspunsul afișat.
La NOT MORE. putem defini aceste responsabilități împreună cu echipa clientului, apoi proiecta și implementa fluxul convenit. O autonomie mai mare devine justificată când procesul, permisiunile și evaluarea o susțin.
Ce acțiune ai permite sistemului să realizeze singur și ce ai vrea să vezi înainte să o aprobi?