Cum proiectezi un asistent AI delimitat prin instrumente, permisiuni și limite de context

Limita reală a unui asistent AI este contractul executabil al serviciului, nu interdicția formulată într-un prompt. Dacă modelului i se spune să nu trimită mesaje, dar integrarea îi oferă totuși instrumentul și acreditările necesare, restricția rămâne fragilă. Un serviciu controlabil separă fiecare operațiune vizibilă utilizatorului și îi stabilește datele eligibile, identitatea, instrumentul, permisiunile, plafonul de acțiune, aprobarea, dovezile și traseul de escaladare. Astfel, o conversație aparent continuă nu primește automat o autoritate la fel de largă.

Ce ar trebui să aibă voie să facă asistentul?

Echipa ar trebui să înceapă cu o cartă de serviciu exprimată într-o singură frază: „Pentru [utilizatorii eligibili], asistentul poate [familia de sarcini] folosind [informațiile aprobate] pentru a produce [rezultatul permis], dar nu poate [non-obiectivele sau deciziile cu consecințe]”. Formula obligă proprietarul serviciului să numească utilizatorii, mediul de utilizare, informațiile disponibile, supravegherea umană și rezultatele interzise înainte de conectarea oricărui instrument.

Verbele largi precum „ajută”, „gestionează” sau „rezolvă” ascund diferențe importante de autoritate. „Caută un caz”, „rezumă cazul”, „propune un răspuns”, „creează o ciornă” și „trimite răspunsul” sunt capabilități separate. NIST AI RMF susține documentarea scopului, sarcinilor, limitelor de cunoaștere și supravegherii, iar OWASP recomandă funcționalitate minimă pentru instrumente. Alegerea capabilității drept unitate de control este însă o sinteză editorială practică, nu o cerință impusă de aceste organizații.

• Numește actorii eligibili și metoda prin care le este stabilită identitatea.
• Separă rezultatele informative, propunerile, ciornele, modificările și acțiunile externe.
• Declară non-obiectivele, sistemele afectate, proprietarul riscului și destinația escaladării.
• Păstrează absentă orice capabilitate care nu este necesară pentru valoarea inițială a serviciului.

Ce informații poate folosi fiecare capabilitate?

Fiecare capabilitate are nevoie de un înveliș informațional, nu doar de o limită tehnică de tokenuri. Învelișul precizează sistemele și tipurile de înregistrări eligibile, clasificarea, filtrele pe obiecte, intervalul temporal, prospețimea necesară, drepturile utilizatorului și datele interzise. O fereastră de context mai mare nu creează autoritate și nu face adevărată o informație neverificată. Dacă dovezile necesare lipsesc, sunt inaccesibile sau sunt prea vechi, răspunsul trebuie limitat ori refuzat.

Documentele recuperate, anexele, mesajele externe și răspunsurile API trebuie tratate ca date neîncrezătoare, separate de instrucțiunile serviciului. Această separare reduce expunerea, fără să elimine injecțiile de instrucțiuni. Istoricul sesiunii și memoria persistentă se proiectează separat: ce poate fi păstrat, cum sunt izolați utilizatorii și sesiunile, ce se validează înaintea persistenței, când expiră datele și cum sunt șterse. Valorile concrete pentru volum și durată aparțin serviciului, politicilor interne și obligațiilor aplicabile.

• Aplică drepturile utilizatorului la fiecare recuperare, nu numai la intrarea în conversație.
• Înregistrează sursa, clasa de încredere și prospețimea necesară pentru răspuns.
• Exclude din memorie secretele, acreditările și datele pe care serviciul nu are un motiv aprobat să le păstreze.
• Nu folosi încrederea declarată de model drept unic criteriu pentru răspuns, refuz sau escaladare.

Cum impun identitatea, instrumentele și permisiunile limita?

Autentificarea, autorizarea și aprobarea trebuie tratate ca trei decizii distincte. Autentificarea stabilește cine este utilizatorul, clientul sau identitatea de lucru. Autorizarea stabilește ce operațiune poate executa acea identitate asupra unei resurse protejate. Aprobarea acceptă o anumită acțiune propusă. Echipa trebuie să aleagă explicit între autoritatea delegată a utilizatorului și o identitate de serviciu controlată; asistentul nu ar trebui să moștenească în tăcere contul privilegiat al unui operator.

Instrumentul ar trebui să expună o operațiune îngustă, cu parametri validați, în locul accesului general la căsuța poștală, baza de date, browser sau shell. Poarta instrumentului și sistemul executant trebuie să limiteze verbele, resursele, obiectele, câmpurile, destinațiile, durata acreditării și audiența tokenului. Promptul poate descrie politica, dar nu este control de autorizare. Pentru integrările MCP protejate, specificația ilustrează separarea dintre client, serverul de autorizare și resursa protejată; nu este o cerință universală pentru orice arhitectură.

• Validează autorizarea la fiecare apel și păstrează contextul de acces al utilizatorului când acțiunea se face în numele său.
• Solicită numai domeniul de acces necesar capabilității și leagă tokenul de resursa destinatară unde arhitectura permite.
• Stabilește limite de rată, reluare, lot, durată, cost și adâncime a lanțului în funcție de serviciu.
• Folosește idempotență, revenire și întrerupătoare de circuit acolo unde consecințele operaționale le justifică.

Conversația poate curge fără întrerupere, dar autoritatea ei trebuie împărțită în capabilități mici, impuse independent.

Câtă acțiune poate executa o capabilitate?

Fiecare capabilitate trebuie să aibă un plafon explicit de acțiune, iar controalele independente devin mai puternice pe măsură ce serviciul se apropie de modificarea stării externe. O scară practică pornește de la răspuns sau rezumat, continuă cu recomandare, propunere și ciornă, apoi cu o modificare limitată și reversibilă, o acțiune externă cu consecințe și, în final, o decizie interzisă. Scara este sinteză editorială și trebuie adaptată impactului real din organizație.

Crearea unei ciorne trebuie separată de trimitere, iar actualizarea reversibilă a unui câmp de ștergerea unei înregistrări. Înaintea unei acțiuni consecvente, utilizatorul trebuie să vadă o previzualizare inspectabilă. Aprobarea se leagă de actor, instrument, resursă, parametrii normalizați și expirare, apoi se verifică din nou la execuție. Dacă destinatarul, conținutul ori alt parametru relevant se schimbă, propunerea are nevoie de validare și aprobare proaspătă.

• Răspuns sau rezumat: citește numai informațiile eligibile și prezintă baza utilizată.
• Recomandare sau propunere: construiește o variantă inspectabilă fără să o execute.
• Ciornă: salvează numai într-un spațiu nefinal, cu un revizor identificat.
• Modificare reversibilă: permite doar obiectele și câmpurile aprobate și păstrează dovada operațiunii.
• Acțiune externă consecventă: cere autorizare validă, aprobare exactă și politică independentă de execuție.
• Decizie interzisă: capabilitatea lipsește, sistemul refuză, iar judecata este direcționată către procesul calificat.

Aprobarea nu furnizează o autorizare lipsă, nu extinde permisiunea permanentă și nu transformă o decizie interzisă într-una permisă. Plățile, acordarea accesului, operațiunile distructive, schimbările în producție, angajamentele externe materiale și judecățile profesionale cu miză ridicată trebuie să rămână sub control uman calificat și politici deterministe potrivite organizației. Niciun prag numeric universal nu poate înlocui analiza serviciului, a consecințelor și a posibilității reale de remediere.

Ce se întâmplă când asistentul ajunge la o limită?

Refuzul, ajutorul parțial sigur, predarea către un om și escaladarea de securitate trebuie proiectate ca rezultate explicite ale serviciului, cu oprire efectivă. Motivele pot include sarcina în afara domeniului, informații neeligibile, autorizare insuficientă, aprobare necesară, dovezi lipsă sau vechi, judecată de specialitate, dependență indisponibilă, limită operațională ori semnal de securitate. Mesajul explică limita pe înțelesul utilizatorului, fără să dezvăluie reguli sensibile.

Asistentul nu trebuie să pretindă că a verificat o sursă, a primit o aprobare, a apelat un instrument sau a efectuat o modificare dacă operațiunea nu a reușit. Poate oferi partea sigură: o ciornă, o listă de verificare sau o solicitare pentru informația lipsă. Pachetul de predare include obiectivul inițial, contextul nesensibil relevant, capabilitatea încercată, motivul opririi, dovezile disponibile sau absente, pasul propus și un identificator de trasare.

• Predarea de rutină ajunge la proprietarul serviciului sau la operatorul responsabil de caz.
• Aprobarea de business ajunge la persoana răspunzătoare pentru angajamentul propus.
• Un semnal de exfiltrare, escaladare a privilegiilor, contaminare a memoriei sau ocolire a aprobării intră pe traseul de incident.
• Execuția rămâne oprită cât timp responsabilul analizează cazul; modificarea propunerii cere validare nouă.

Cum transformă echipa limitele într-un design operațional?

Echipa ar trebui să completeze câte un rând de design pentru fiecare operațiune vizibilă utilizatorului și să lege fiecare rând de controale executabile, dovezi, teste, metrici și un proprietar. Rândul consemnează actorul eligibil, autentificarea, învelișul informațional, regulile sesiunii și memoriei, instrumentul îngust, identitatea activă, resursa, plafonul de acțiune, aprobarea, limitele operaționale, refuzul, jurnalul și destinația escaladării. Fără aceste legături, matricea rămâne documentație decorativă.

Un asistent intern pentru echipa de suport arată de ce aceeași interfață conversațională nu trebuie să însemne aceeași autoritate. Rezumarea unui caz, redactarea răspunsului și trimiterea aprobată pot folosi același fir de conversație, dar au acces, instrumente, permisiuni, plafoane și proprietari diferiți. OWASP susține minimizarea funcționalității și a permisiunilor, iar NIST subliniază rolurile clare, monitorizarea și revizuirea; pânza concretă de mai jos este o aplicare editorială a acestor principii.

Jurnalul trebuie proiectat pornind de la întrebările pe care o investigație trebuie să le poată răspunde: cine a cerut, ce capabilitate și politică s-au aplicat, ce clase de surse și instrumente au fost folosite, ce decizii de autorizare și aprobare au existat și ce rezultat s-a produs. Nu este o invitație de a păstra fiecare prompt integral. Secretele și contextul sensibil se redactează, iar accesul și durata păstrării urmează cerințele organizației.

Ce dovezi sunt necesare pentru lansare și operare?

Lansarea necesită dovezi că serviciul permis funcționează și că refuzurile, opririle și escaladările așteptate se produc în condiții apropiate de utilizarea reală. Testele pozitive trebuie însoțite de acces între conturi, instrument neautorizat, dovadă veche, conținut recuperat contaminat, date interzise, ocolirea aprobării, parametri modificați, reluări duplicate, dependențe indisponibile, tentative de exfiltrare și lanțuri scăpate de sub control. Scenariile și pragurile de acceptare se stabilesc pentru serviciul concret.

În producție, metricile trebuie urmărite la nivel de capabilitate: apeluri neașteptate de instrumente, refuzuri repetate, erori de autorizare, aprobări modificate, secvențe anormale, degradarea calității, latență, consum de resurse și defecțiuni. Monitorizarea trebuie să respecte confidențialitatea și protecția datelor. Proprietarii comportamentului serviciului, granturilor de acces, predărilor de business și incidentelor de securitate au nevoie de autoritatea de a suspenda, modifica sau retrage capabilitatea.

• Leagă fiecare scenariu de test de capabilitate, versiunea politicii, sursele, instrumentele și rezultatul așteptat.
• Verifică atât reușita operațiunilor permise, cât și calitatea refuzurilor și a pachetelor de predare.
• Revizuiește permisiunile, jurnalele, metricile, limitările cunoscute și capacitatea reală de oprire înaintea lansării.
• Redeschide testele afectate după modificări materiale ale modelelor, prompturilor, recuperării, memoriei, datelor, instrumentelor, permisiunilor, politicilor, furnizorilor sau mediului operațional.

Începe cu cea mai mică operațiune care oferă valoare și extinde autoritatea numai printr-o schimbare revizuită, nu prin editarea izolată a promptului. Implică responsabilii de securitate, identitate, confidențialitate, evidență, risc și operare când capabilitatea atinge date sensibile, memorie persistentă, acces privilegiat, modificări distructive sau angajamente externe. Judecățile juridice, de reglementare ori alte decizii profesionale cu miză ridicată trebuie direcționate către specialiști calificați și procese guvernate separat.