Verificați răul pe care îl poate produce funcția AI

O funcție AI ar trebui evaluată în raport cu răul pe care îl poate produce aplicația completă. Evaluarea siguranței unui model oferă dovezi utile despre acel model, în condițiile evaluării. Nu poate demonstra că mecanismele de căutare, permisiunile, instrumentele și ecranele de aprobare împiedică un rezultat dăunător pentru afacere. Definiți modelul de amenințări al aplicației înainte să tratați un scor general ca dovadă pentru lansare.

Această retrospectivă din noiembrie 2026 revine la săptămâna de 15 ianuarie 2025. Autorii Microsoft au trimis Lessons From Red Teaming 100 Generative AI Products pe 13 ianuarie. Raportul lor separă testarea adversarială a produselor de evaluarea standardizată a siguranței. Experiența descrisă le aparține și acoperă peste 100 de produse la Microsoft; nu este un istoric de testare al AL+.

Numiți sistemul și consecința finală

Textul integral al primei versiuni prezintă o ontologie care leagă sistemul, actorul, tacticile și tehnicile, procedurile reproductibile, slăbiciunile și impactul. Include atât actori rău intenționați, cât și utilizatori obișnuiți care întâlnesc accidental erori. Schimbarea importantă este legarea mecanismului de eșec de un rezultat în sistemul din jur.

Categoriile de impact includ consecințe de securitate și prejudicii legate de siguranța conținutului generat. Ele ajută la evitarea presupunerii înguste că orice problemă AI presupune ocolirea ingenioasă a restricțiilor sau furtul unor date de autentificare. Scopul produsului, publicul și capacitățile disponibile stabilesc ce consecințe merită atenție. Vocabularul organizează investigația; nu produce automat o estimare a riscului.

Pentru proprietarul firmei, aceasta schimbă întrebările adresate înainte de lansare. Dacă modelul a refuzat o cerere nesigură și dacă aplicația ar putea divulga informațiile altui client sunt întrebări diferite. Un răspuns satisfăcător la una nu îl poate înlocui tacit pe celălalt. A doua cere explicarea accesului la date și a acțiunilor efective ale aplicației.

Un traseu ilustrativ, de la intrare la impact

Să luăm un asistent fictiv pentru oferte, folosit de un furnizor. Citește specificația încărcată de client, caută informații interne despre produse și pregătește o ofertă pe care o aprobă un angajat. Exemplul este explicit ilustrativ. Nu descrie nici o integrare AL+ instalată, nici un test de penetrare.

Actorul este un client extern care controlează specificația încărcată, dar nu are acces legitim la condițiile negociate de alt client. Intrarea este un document cu instrucțiuni care încearcă să îndrepte asistentul spre acele condiții. Capacitatea relevantă este căutarea în informațiile furnizorului. Slăbiciunea posibilă este un drept de acces la căutare mai larg decât drepturile clientului solicitant, combinat cu tratarea conținutului documentului ca instrucțiuni.

Impactul posibil este divulgarea condițiilor altui client în oferta propusă. Un ecran de aprobare poate interveni înainte de trimiterea externă, dar nu demonstrează că informația confidențială nu a ajuns deja într-un context intern neautorizat sau că evaluatorul îi va observa originea. Traseul identifică ce trebuie verificat; nu afirmă că orice asistent care primește documente se va comporta astfel.

O evaluare propusă ar păstra permisiunile reale ale actorului, ar folosi înregistrări fictive controlate și ar observa dacă informația restricționată poate ajunge în ciornă sau într-o acțiune externă. Protecția ar reuși dacă autorizarea împiedică obținerea sau divulgarea informației, fără să se bazeze doar pe refuzul modelului în fața unui text convingător. Sunt condiții propuse de acceptare, nu constatări noi.

Alegeți remedierea la limita care a cedat

Dacă operația de căutare returnează înregistrări pe care actorul nu ar trebui să le poată folosi, reparați acea limită a permisiunilor. O instrucțiune mai puternică pentru model poate ajuta comportamentul, dar nu explică de ce datele erau accesibile. Dacă ciorna este autorizată intern, însă trimiterea externă cere aprobare, faceți aprobarea relevantă: arătați ce se va trimite și informațiile pe care se bazează decizia.

Același traseu poate arăta mai multe responsabilități fără să ceară o clasificare separată pentru fiecare ecran. Controlul accesului stabilește înregistrările disponibile. Tratarea conținutului nesigur de către asistent stabilește cum interpretează documentul. Controalele de trimitere stabilesc ce poate părăsi aplicația. Evaluarea ar trebui să păstreze legătura dintre slăbiciunea observată și remediul propus.

Subiectul diferă de decizia dacă un agent de browser poate descărca un fișier executabil și de folosirea AI pentru descoperirea vulnerabilităților software obișnuite. Sunt teme utile, dar implică alte capacități și alte dovezi. Aici întrebarea este dacă un traseu concret al aplicației poate lega o intrare nesigură de folosirea neautorizată a informațiilor.

Evaluările de bază ale modelelor rămân utile

Cea mai puternică obiecție privește amploarea muncii. Investigația specifică produsului cere timp, iar evaluările de bază pot compara sistematic comportamentul modelelor. Pot ajuta la alegerea candidaților, la detectarea schimbărilor și la identificarea unor clase largi de ieșiri nedorite. Renunțarea la ele ar elimina dovezi utile, fără să îmbunătățească evaluarea.

Păstrați vizibil domeniul lor. Notați modelul și configurația evaluate, sarcinile acoperite și rezultatul care ar schimba decizia despre produs. Adăugați apoi cazuri specifice aplicației pentru capacități și consecințe neacoperite de evaluarea de bază. Un rezultat bun al modelului poate coexista cu o greșeală periculoasă de permisiuni în software-ul din jur.

Lucrarea istorică oferă un cadru și lecțiile autorilor, nu o schemă de certificare sau o listă completă a prejudiciilor viitoare. Textul cu versiune fixează argumentul din ianuarie fără să trateze documentația ulterioară a furnizorilor ca dovadă contemporană. O lansare reală cere în continuare investigație proporțională cu datele, utilizatorii și consecințele concrete.

Pentru agenți AI, începeți cu un traseu important: cine controlează intrarea, ce capacitate poate acționa asupra ei, ce slăbiciune le-ar putea lega și cine ar putea suferi consecințele. Transformați traseul într-o condiție observabilă de acceptare și păstrați limitele nerezolvate. Scorul de siguranță devine mai util alături de dovezile aplicației, fiecare răspunzând întrebării pe care o poate susține efectiv.