Depășirea mentalității „IA este magie”: de ce înțelegerea modului de funcționare a modelelor de IA trebuie să fie o prioritate la nivelul întregii companii

Pe fondul avertismentelor privind agenții IA scăpați de sub control, un dezvoltator i-a acordat recent unui agent de programare acces nerestricționat la o mașină fără copie de rezervă la distanță. A șters 48.000 de fișiere în mai puțin de două minute.

Astfel de incidente ne reamintesc cu brutalitate că implementarea agenților IA implică riscuri; nu este suficient să adăugăm un evaluator uman undeva într-un proces complex și să presupunem că totul este sigur. Unele procese nu necesită nicio intervenție, în timp ce altele au nevoie de verificări mult mai stricte. Este clar că remedierea unei greșeli de scriere și ștergerea a mii de fișiere nu prezintă același nivel de risc, așa că supravegherea trebuie să țină seama de miza reală.

Organizațiile trebuie să identifice mai bine momentele în care judecata umană contează cu adevărat, mai ales când o acțiune are un impact major sau este greu de anulat. Iar când agenții fac greșeli, mediul trebuie să limiteze amploarea efectelor.

IA nu este deterministă, ci probabilistică

În primul rând, este esențial ca fiecare angajat implicat direct sau indirect în dezvoltarea de software să dobândească o înțelegere fundamentală a modului în care modelele de IA procesează informațiile. Nu este o sarcină ușoară; presupune un angajament de a instrui echipele și, în cele din urmă, ar trebui să devină un obiectiv la nivelul întregii companii.

Când cineva începe să interacționeze cu IA, aceasta pare magică. Tastezi o propoziție și, dintr-odată, porți o conversație. Pentru a stabili politici de IA la nivelul întregii companii în ceea ce privește securitatea și productivitatea, este important să înțelegem, măcar la nivel de bază, cum funcționează în realitate modelele și antrenarea lor. Rețeaua neuronală, tokenizarea și analiza statistică din spatele acestora, precum și modul în care toate acestea duc la generarea rezultatelor reprezintă o oportunitate importantă de instruire pentru toți angajații companiei.

Modelele lingvistice mari nu vor produce niciodată rezultate deterministe. Rezultatul este probabilistic. În cazul software-ului obișnuit, când introduci date, ai anumite așteptări privind rezultatul posibil, să zicem A, B sau C. Însă, în cazul IA, ai putea obține F, un & sau descrierea unei pisici care poartă ochelari de soare.

Când ceva este probabilistic, nu îl poți testa în mod obișnuit. Ai nevoie de o metodă de testare care să permită ajustarea, raționarea, înțelegerea și preluarea rapidă a contextului, pentru a surprinde elementele probabilistice și a recunoaște problemele pe care le-ar putea cauza. În funcție de amploare și de risc, acest tip de testare poate fi gestionat fie de IA, fie de o persoană cu expertiza necesară. Implicarea unei persoane în proces este cea mai utilă chiar de la început, pentru a stabili problema care trebuie rezolvată, și apoi la final, pentru a evalua rezultatul.

Deoarece dezvoltatorii sunt cei mai în măsură să observe variabilele și practicile uzuale prin care IA internă a organizației lor generează răspunsuri pe baza datelor de intrare, ei pot contribui în mod semnificativ la conturarea instruirii privind IA în cadrul companiilor lor și se pot asigura că toată lumea înțelege această diferență dintre determinism și probabilism în IA, precum și importanța ei. Scopul este să renunțăm la mentalitatea potrivit căreia utilizarea IA este ca prin magie și că orice rezultat este acceptabil. În schimb, organizațiile ar trebui să depună eforturi pentru a demistifica și a prezenta modelele pe care le folosește compania, modul în care sunt utilizate, problemele care pot apărea, felul în care sunt verificate și rezultatele acestui proces.

Mecanismele de protecție țin de infrastructură, nu de model

După ce „magia” IA este demistificată și un proiect bazat pe IA este în desfășurare, este esențial să existe o politică transparentă de auditare, pentru a ne asigura că totul evoluează conform planului. Astfel, dacă proiectul generează un rezultat „prost” sau nesatisfăcător, persoana responsabilă poate audita etapele parcurse și poate împiedica repetarea problemei. O astfel de politică este utilă și atunci când rezultatele sunt mai bune decât se aștepta, deoarece etapele parcurse pot fi reproduse și împărtășite cu alte proiecte sau grupuri.

Sistematizarea acestui proces este deosebit de importantă în companiile mari, unde fiecare echipă poate avea zeci de dezvoltatori, iar sute de dezvoltatori pot lucra la cod pe parcursul zilei. IA poate face multe lucruri foarte repede, iar dacă ceva nu merge bine, trebuie să existe un sistem care să stabilească cu exactitate în ce etapă a apărut problema. Să ne uităm la agenții OpenAI care au compromis Hugging Face în vara aceasta. OpenAI testa cât de bine puteau modelele sale să exploateze vulnerabilitățile software, folosind un set de evaluare numit ExploitGym. Pentru acest test, a relaxat în mod deliberat refuzurile modelelor privind activitățile cibernetice ofensive. Singura cale de ieșire din mediul izolat era printr-un proxy de pachete. Modelele au descoperit o vulnerabilitate necunoscută în acel proxy, au evadat și au petrecut mai mult de două zile în sistemele de producție ale Hugging Face, căutând răspunsurile la test.

Titlurile din presă au numit-o IA scăpată de sub control. Eu aș numi-o o configurație deterministă în jurul unui sistem probabilistic. OpenAI le-a spus modelelor să pirateze, apoi s-a bazat pe faptul că acestea aveau să respecte traseul așteptat. Creatorul setului de evaluare spune că modelele trișaseră și înainte la test, dar întotdeauna în interiorul mediului izolat. De data aceasta, unul dintre ele a ieșit din el. Mecanismele standard de protecție presupun un comportament standard, dar IA nu este obligată să respecte standardele.

De aceea, securitatea IA ține de acces și de controale, aplicate de mediul de lucru, nu de comportamentul adecvat al modelului. Presupuneți că agentul va încerca fiecare ușă și lăsați deschise doar ușile de care are nevoie. Agentului care a șters 48.000 de fișiere i se spusese să lucreze pe copii și să lase originalele neatinse. Cu toate acestea, a șters originalele. Instrucțiunile nu sunt controale.

Gestionarea permisiunilor unui agent seamănă cu integrarea unui nou dezvoltator junior. Nu i-ați acorda acces root la mediul de producție chiar din prima zi. Dacă ați face-o și acesta v-ar șterge baza de date, nu ați pune asta pe seama faptului că ar fi un hacker genial. În incidentele de securitate, indiferent de amploare, este esențial să se identifice cauza fundamentală. Este modelul? Este compania care a creat modelul? Este compania care i-a acordat modelului acces? Oricare ar fi cauza, în ultimă instanță, un om este responsabil.

În cele din urmă, o problemă esențială de abordat astăzi este ce se întâmplă în culise, pe laptopul unui dezvoltator. În trecut, fluxul de lucru era mai ușor de urmărit. Dezvoltatorii scriau codul, îl revizuiau și îl lansau, așa că exista o cale clară de a reveni la momentul în care ceva nu a mers bine. Acum, un dezvoltator poate să-i fi dat unui agent tichetul și să-i fi spus: „rezolvă asta”. Dacă activitatea se desfășoară fără să fie văzută, nu există nimic de urmărit. Fiecare etapă trebuie să lase o pistă completă: ce agent a rulat, ce model a folosit, ce instrucțiuni a primit, ce instrumente a apelat și ce permisiuni avea în acel moment. Rularea agenților la nivel central, în loc de pe laptopuri individuale, este o modalitate de a ajunge la acest rezultat. Important este să existe o pistă de audit.

În cele din urmă, dacă are loc un incident, fiecare companie trebuie să se protejeze. Pista de audit ar trebui să conțină suficiente informații pentru a realiza o analiză a cauzei fundamentale și a identifica etapa și codul care au provocat problema.

IA a schimbat enorm lumea, iar procesele de afaceri trebuie să țină pasul. Pentru a identifica măsurile de protecție adecvate, este nevoie de o mai bună înțelegere a proceselor IA, a testării, a ciclurilor de revizuire și a ciclurilor de audit – atât în echipele de dezvoltare, cât și la nivelul întregii companii.