Lideri de opinie

Măsurile de protecție pentru IA în companii pot conta mai mult decât modelele de frontieră

mm
Adaugă Unite.AI la sursele tale preferate pe Google

Lăsați deoparte modelele de frontieră în domeniul IA. Clienții cer companiilor să introducă mai multe măsuri de protecție pentru IA pe care o folosesc deja, iar experiența cu PCI DSS oferă un model util.

Perioada de grație în materie de reglementare pentru IA s-a încheiat. Dezvăluirile recente au dat naștere unor discuții despre încetinirea dezvoltării modelelor de frontieră și impunerea unor măsuri de control. Unul dintre puținele puncte asupra cărora există consens este că aceste măsuri ar trebui să fie independente de modele și să fie verificate independent.

Ce se va întâmpla în continuare este încă dezbătut, însă autoritățile de reglementare acționează. Regulamentul UE privind inteligența artificială introduce treptat obligații de securitate, inclusiv răspunderea cumpărătorilor. În Statele Unite, Cadrul NIST de gestionare a riscurilor asociate IA este adoptat ca standard pentru diligența rezonabilă. La nivel mondial, Top 10 OWASP pentru aplicațiile LLM a devenit o referință frecventă în evaluările de securitate, iar certificarea ISO/IEC 42001 apare în documentele de achiziții.

Asta înseamnă că dezvoltatorii de modele nu sunt singurii care răspund pentru riscuri. Obligațiile și riscurile de securitate revin și companiilor care folosesc modele deja lansate, mai ales în cazurile de utilizare cu risc ridicat. Răspunsurile greșite la un chestionar de securitate al unui client sau într-o ofertă depusă ca răspuns la o cerere de propuneri pot bloca o tranzacție B2B.

PCI DSS arată calea de urmat

Din fericire, am mai văzut acest scenariu. Acum douăzeci de ani, securitatea aplicațiilor web se baza în principal pe audituri periodice ale codului, scanări statice și disciplina dezvoltatorilor. Apoi, Cerința 6.6 din PCI DSS, publicată în 2006 și aplicată începând din 2008, a impus organizațiilor care prelucrează datele deținătorilor de carduri fie să verifice întregul cod al aplicațiilor pentru a depista vulnerabilități, fie să instaleze măsuri tehnice de control automatizate. Ulterior, opțiunea de verificare a codului a fost eliminată, iar măsurile tehnice de control au devenit obligatorii.

Însă PCI DSS nu a început ca lege. A început cu un standard contractual care a remodelat piața, probabil mai rapid decât ar fi făcut-o legislația, deoarece contractele evoluează mai repede decât legile adoptate de guvern.

În mod similar, organizațiile resimt acum presiuni pentru introducerea unor măsuri de protecție pentru IA implementată, nu din partea autorităților de reglementare, ci a clienților și partenerilor, prin chestionare de securitate, clauze din cereri de propuneri și cerințe ale polițelor de asigurare.

Rezolvați problema operațională, iar conformitatea va urma

Poate fi dificil să răspunzi acestor presiuni, deoarece guvernanța IA nu ține doar de politici. Este vorba și despre dovezi tehnice continue.

Multe dintre companiile cu care discut rulează în mediul de producție o jumătate de duzină sau mai multe modele, pe care le conectează frecvent în lanț sau le orchestrează astfel încât rezultatul unuia să fie folosit ca intrare pentru altul. Imaginați-vă că trebuie să demonstrați aplicarea la nivelul întregului sistem a unei singure politici, cum ar fi împiedicarea includerii datelor cu caracter personal (PII) în rezultatele modelelor, în astfel de condiții. Auditarea manuală a mai multor modele configurate individual ar consuma foarte mult din timpul dezvoltatorilor. În plus, majoritatea organizațiilor întâmpină dificultăți în gestionarea utilizării nesancționate și cu risc ridicat a IA, de exemplu atunci când angajații introduc date sensibile în instrumente IA destinate consumatorilor sau când furnizorii SaaS activează pe ascuns funcții noi de IA. Cu toate acestea, întreaga răspundere revine companiei.

În scenarii atât de dificile, cerințele pot fi reduse la o singură sarcină simplă: să demonstrați că puteți limita în mod continuu intrările și ieșirile modelelor și că înregistrați această activitate pentru verificare. Pe măsură ce aplicațiile apelează modele, agenții invocă instrumente, iar modelele efectuează acțiuni sau declanșează fluxuri de lucru, acțiunea este cea care trebuie controlată: apelul instrumentului, solicitarea API, declanșarea fluxului de lucru.

Mutați securitatea pe calea de inferență

Această acțiune reprezintă punctul de aplicare a măsurilor de control pe care experții în securitatea aplicațiilor îl dezvoltă de 20 de ani pentru traficul aplicațiilor. Mai ales când inferența este direcționată printr-o infrastructură partajată, calea de inferență devine punctul ideal de control pentru mai multe modele și chiar pentru utilizarea nesancționată a IA. Traficul de inferență IA trebuie livrat, inspectat, autentificat și guvernat ca orice altă interacțiune importantă cu o aplicație, în funcție de sursa traficului și de acțiunea pe care încearcă să o efectueze. Spre deosebire de auditarea manuală, guvernanța traficului de inferență se va putea scala.

Cum să începeți

Având în vedere direcția în care evoluează reglementările, organizațiile trebuie să înceapă chiar acum să facă trei lucruri:

  1. Identificați-vă aria de răspundere, de la API-urile SaaS și punctele finale găzduite până la IA din umbră.
  2. Separați politicile de securitate și aplicarea lor de modele și integrați-le în calea de inferență.
  3. Asigurați-vă că jurnalele de audit sunt generate în afara controlului modelelor și agenților, despre care s-a demonstrat că încearcă să modifice înregistrările propriilor acțiuni.

Cerințele pentru ceea ce constituie monitorizare și aplicare adecvate sunt încă în curs de stabilire, însă echipele de operațiuni și de securitate ale companiei știu ce poate fi aplicat în mod real, cât costă o măsură de control în termeni de latență și complexitate și în ce situații o regulă bine intenționată ar putea avea efectul nedorit. Implicați-le chiar acum. Riscurile de securitate și obligațiile asociate utilizării IA sunt reale, iar clienților și directorilor companiei le pasă, fără îndoială, mai mult de riscurile cu care se confruntă astăzi decât de amenințările pe care le-ar putea aduce mâine modelele de frontieră.

Michael Montoya este director executiv pentru operațiuni tehnologice la F5. El conduce organizațiile de securitate, risc și operațiuni digitale și s-a alăturat echipei de conducere executivă a F5 după ce a făcut parte din Consiliul de administrație al F5 în perioada 2021-2025. Experiența anterioară a lui Montoya include funcții de nivel C la BlueVoyant, Equinix, Digital Realty și Microsoft.