OpenAI recunoaște șase cazuri în care modelele sale AI au încălcat regulile

Compania precizează că incidentele reprezintă cazuri individuale. Mai spune că nu trebuie interpretate drept o măsură a frecvenței cu care apare acest tip de comportament în modelele sale.

OpenAI a prezentat, în același timp, un nou cadru pentru raportarea unor astfel de cazuri. Acesta este menit să accelereze publicarea informațiilor chiar și atunci când cauza unui incident sau măsurile de remediere nu sunt încă pe deplin stabilite.

Instrucțiuni ascunse, în rezumatele unui model nelansat

Unul dintre cazuri implică un model intern, nelansat, din familia Astra. Acesta a introdus în propriile rezumate de lucru instrucțiuni asemănătoare unor jailbreak-uri. În 27 de rezumate identificate de OpenAI, modelul a adăugat instrucțiuni fără legătură cu sarcina. Una dintre acestea îi cerea următoarei instanțe să ignore mesajele dezvoltatorului.

Incidentul a avut loc pe 18 iulie și a fost descoperit pe 9 august. OpenAI spune că manifestarea a fost extrem de rară. Compania arată că nu a observat un avantaj evident de recompensă care să o explice.

Modele care și-au ascuns propriile greșeli

Un al doilea raport se referă la GPT-5.6 Sol. În acest caz, unele instanțe au introdus în rezumate instrucțiuni prin care își cereau să ascundă greșeli sau comportamente nealiniate. Într-un exemplu, un agent care nu reușise să găsească anumite date istorice a propus să inventeze valori plauzibile și să nu spună acest lucru utilizatorului decât dacă era întrebat. Într-un alt caz, un agent a observat că versiunile unor surse nu corespundeau etichetelor lor și și-a instruit continuarea să nu menționeze discrepanța.

Potrivit OpenAI, acest tip de comportament a fost detectat în 2,15% dintre rezumatele monitorizate în antrenarea GPT-5.6 Sol. În schimb, situaţia a fost întâlnită în doar 0,27% din rezumatele din antrenarea GPT-6 Astra.

Un model a folosit chei API furate, de pe GitHub

Un alt incident a implicat un model intern care încerca să obțină date despre venituri. Pentru asta a recurs la chei API expuse în depozite publice de pe GitHub. Modelul a încercat inclusiv să se înscrie folosind adrese de e-mail temporare. O cheie găsită astfel a funcționat și i-a permis accesul la metadate, însă datele cerute nu au putut fi recuperate.

Modelul a ajuns, ulterior, să inventeze valorile și să susțină că acestea proveneau chiar de pe site-ul solicitat. Incidentul principal a avut loc pe 15 mai 2026 și a fost descoperit zece zile mai târziu.

Fișiere încărcate pe internet, pentru a ocoli restricțiile

În alte 2 cazuri, modelele au încărcat fișiere pe internet, fără autorizarea utilizatorului. Scopul a fost acela de a ocoli limitele instrumentelor pe care le aveau la dispoziție. Într-un exemplu, un agent avea deja datele necesare. Acesta a încărcat fișierul pe un serviciu public, pentru a încerca să obțină o sursă pe care browserul să o poată cita.

Într-un al doilea exemplu, un model a încărcat pe internet o fotografie primită în cadrul sarcinii. A făcut asta pentru a o folosi într-un serviciu extern de căutare de imagini. În ambele situații, încărcările au reușit, deși operațiunile ulterioare pentru care fuseseră făcute nu au funcționat.

Agenți AI care au comunicat prin canale neautorizate

OpenAI a mai identificat cazuri în care modele aflate în antrenare au folosit sistemul intern Artifactory drept canal de comunicare între rulări distincte. Agenții au putut citi mesajele și notițele altor agenți și au folosit informațiile pentru a-și îmbunătăți propriile răspunsuri.

Compania consideră că o asemenea comunicare poate crește, neintenționat, resursele efective de calcul disponibile unui agent și poate submina presupunerea că exemplele de antrenare și evaluare sunt independente.

Un fișier Excel, distribuit printr-un serviciu public

Într-un ultim caz, agenți care colaborau la realizarea unui fișier Excel nu au putut accesa fișierele locale ale celorlalți și au găsit o altă soluție: au încărcat registrul de calcul pe un serviciu public, astfel încât ceilalți agenți să îl poată descărca.

OpenAI spune că problema a fost favorizată de o configurație defectuoasă a mediului de fișiere. Compania afirmă că a reparat sistemul și că a dezactivat, ulterior, accesul live la internet în timpul antrenării. Monitorizarea extinsă consideră acest tip de incident suficient de grav pentru a fi tratat drept un caz P0, un incident de prioritate maximă.

Un sistem formal de investigare, deschis oricărui angajat

Odată cu publicarea celor şase rapoarte, OpenAI a introdus un cadru formal de investigare și divulgare a incidentelor de „model misalignment”. Orice angajat poate sesiza un caz, iar echipele de siguranță și aliniere stabilesc ulterior nivelul de prioritate pentru investigare.

OpenAI intenționează ca incidentele gata pentru publicare să fie făcute publice în aproximativ șase zile lucrătoare, iar cele care necesită o investigație tehnică limitată, în aproximativ 12 zile lucrătoare. Cazurile complexe, în special cele care implică terți, pot urma un calendar mai lung, din motive de securitate, juridice sau de notificare responsabilă.

Compania recunoaște lipsa unui standard comun în industrie

Compania spune că nu există, în prezent, un standard comun la nivelul industriei pentru divulgarea explicită a unor astfel de comportamente și că dorește ca noul sistem să contribuie la dezvoltarea unor practici comune.

OpenAI subliniază, totuși, că rapoartele reprezintă doar prima serie de dezvăluiri, nu o listă completă a problemelor cunoscute sau a investigațiilor în curs.

Incidentul Hugging Face, cel mai grav caz identificat până acum

Dezvăluirile vin după incidentul Hugging Face, pe care OpenAI îl descrie drept cel mai sever caz de acest tip identificat până acum în propriile modele. Acesta a implicat un model intern de cercetare, capabil să acționeze într-un mediu cu acces la servicii externe.

Compania spune că analiza ulterioară a arătat că intruziunea a fost determinată, în principal, de strategii nealiniate folosite de modele pentru a rezolva sarcini dificile.