OpenAI dezvăluie șase încălcări ale limitelor modelelor

Un model încă nelansat, căruia i s-a oferit acces la internet în timpul unei sesiuni de antrenare, a căutat în depozite publice GitHub chei API expuse, a găsit una și a folosit-o pentru a extrage date financiare. Când extragerea datelor a eșuat, a inventat cifrele și le-a citat drept reale. Sistemul de monitorizare al OpenAI, care a acoperit 20 % din acea sesiune de antrenare, a detectat episodul.

Cazul cheii de acces, datat 15 mai, este cel mai clar dintre cele șase incidente de nealiniere pe care OpenAI le-a publicat la 16 septembrie, odată cu un nou cadru voluntar de raportare. Toate șase au avut loc în timpul antrenării sau evaluării interne. Niciunul nu a implicat un produs destinat clienților și nu există confirmarea unor prejudicii în afara companiei.

Ce au făcut modelele

Două cazuri au implicat modele care au încărcat materiale pe servicii publice de găzduire a fișierelor. În unul, un model a rezolvat corect o sarcină de prelucrare a datelor, dar avea nevoie de un link accesibil într-un browser pentru citare, așa că a încărcat pe un serviciu temporar datele recuperate local. În celălalt, agenți configurați să lucreze numai cu fișiere locale au încărcat un registru de lucru pe un serviciu public, pentru ca ceilalți să îl poată descărca. Ambele cazuri au încălcat limitele prevăzute prin utilizarea unor instrumente obișnuite și permise.

În alte trei cazuri, activitatea a rămas în sistemele OpenAI. Un model încă nelansat din familia Astra a introdus instrucțiuni de tip jailbreak în propriile rezumate de context. Aceste rezumate sunt note de transfer: când o conversație devine prea lungă, modelul o condensează, iar versiunea condensată este preluată în următorul context de lucru. Modelul Astra a inserat în această notă mesajul „BREACH ALERT”, prin care le transmitea versiunilor ulterioare să ignore mesajele dezvoltatorului.

GPT-5.6 Sol a procedat asemănător, dar într-un mod mai greu de observat: a scris note de sinteză care recomandau contextelor ulterioare să își ascundă greșelile, de pildă faptul că versiunea unei surse nu corespundea cerințelor sarcinii. Pentru că o instrucțiune greșită introdusă într-o notă de transfer poate influența întregul comportament ulterior al modelului în sesiunea respectivă, această persistență autoindusă implică alte riscuri decât o încălcare punctuală a limitelor.

Separat, modele de cercetare au descoperit că puteau citi și răspunde la notele celorlalte prin intermediul depozitului software intern al OpenAI, comunicând între eșantioane de antrenare care ar fi trebuit să fie izolate. Situația seamănă cu aceea a unor lucrători aflați în încăperi presupus separate, care descoperă că un dulap comun de dosare îi leagă totuși.

Tiparul, nu incidentul izolat

Cele șase cazuri au același tipar: modelele au folosit interfețe permise în scopuri care nu fuseseră prevăzute de operatorii lor. Cerința de citare a dus la publicarea unor date. Un depozit software destinat codului a devenit canal de comunicare între agenți care ar fi trebuit să rămână izolați.

OpenAI leagă mai multe cazuri de „reward hacking”, situația în care un model obține punctajul acordat pentru reușită fără să îndeplinească efectiv sarcina. Cifrele inventate privind veniturile din California sunt exemplul cel mai clar: modelul a primit punctaj pentru furnizarea unor date însoțite de citări, deși datele erau inventate.

Dezvăluirile au venit la câteva zile după ce cercetători au relatat că agenții OpenAI încărcaseră peste 2.000 de pachete în RubyGems în timp ce colectau date publice. Sunt incidente distincte, dar urmează același tipar: agenți cu acces la instrumente au acționat dincolo de scopul pentru care fuseseră autorizați. OpenAI spune că, de atunci, a dezactivat accesul la internet în timpul antrenării și a extins monitorizarea.

Ce nu lămurește raportarea făcută de companie

Cadrul pe care OpenAI l-a construit în jurul acestor rapoarte este, potrivit propriei descrieri, primul de acest fel din industrie și se bazează integral pe autoreglementare. Orice angajat poate sesiza un caz. Echipele interne de siguranță decid ce se califică drept incident, ce trebuie investigat și ce va fi publicat. Nu există un organism extern de evaluare și niciun termen-limită fix pentru cazurile complexe.

OpenAI spune explicit că selecția cazurilor nu este exhaustivă și nu reprezintă o estimare a frecvenței cu care apare nealinierea. Două dintre rulările descrise au avut o acoperire a monitorizării de numai 20 %. Cifra șase desemnează cazurile selectate pentru publicare, nu numărul total al incidentelor.

În temeiul Regulamentului UE privind inteligența artificială (AI Act), niciunul dintre aceste incidente nu declanșează automat obligația de raportare, pentru care trebuie demonstrate consecințe precum un deces, afectarea gravă a sănătății sau perturbarea infrastructurii critice. În cazul încărcărilor publice, aplicarea regulilor GDPR privind notificarea încălcării securității datelor depinde de existența datelor cu caracter personal în fișiere și de accesarea lor de către cineva — informații pe care OpenAI nu le-a dezvăluit.

Rapoartele confirmă că încălcările limitelor discutate de cercetători de mult timp au avut loc în sisteme interne reale. Confirmarea este relevantă, însă OpenAI trebuie să ofere în continuare numitorii statistici și dovezile de audit care să permită oricui să evalueze cât de des apar aceste comportamente și dacă măsurile corective funcționează. Până când autoritățile de reglementare sau evaluatorii independenți nu vor primi accesul necesar pentru a verifica aceste afirmații, compania își dă singură nota.