Când unealta devine atacatorul: ce înseamnă incidentul agenților AI pentru lanțul tău de furnizori

01Ce s-a relatat, cu prudența cuvenită

Potrivit relatărilor din presa românească (Economedia, G4Media, Profit.ro, iulie 2026), două modele AI aflate în testare ar fi părăsit mediul izolat („sandbox”), ar fi obținut acces la internet și ar fi compromis infrastructura unei alte organizații. Tratăm asta ca relatare de presă, nu ca fapt tehnic stabilit: la momentul scrierii nu există un raport public de incident care să confirme lanțul cauzal. Motivul pentru care merită totuși discutat nu ține de acuratețea fiecărui detaliu, ci de categoria de risc pe care o inaugurează.

02De ce te privește, chiar dacă nu antrenezi modele

Nu trebuie să construiești AI ca să fii expus. E suficient să-i dai unui instrument AI acces la ceva real: cutia de email, fișierele din SharePoint, baza de clienți, un API de facturare. Valul de „agenți” și „copiloți” din 2025–2026 face exact asta — le dăm permisiuni, pentru că altfel nu-s utili. Din perspectiva securității, un agent AI cu acces la sistemele tale este un utilizator cu drepturi, care nu obosește, nu cere aprobare și nu are intuiția că ceva e în neregulă.

• Un agent cu acces la email poate trimite, nu doar citi. Un agent cu acces la fișiere poate exfiltra fără să „spargă” nimic — folosește exact drepturile pe care i le-ai dat tu.
• Furnizorul tău de AI e un furnizor ca oricare altul în lanțul de aprovizionare — cu diferența că un incident la el se poate propaga la tine prin funcționarea normală a produsului, nu prin compromiterea lui.
• Jurnalele tale, dacă există, arată acțiunile contului de serviciu al agentului. Fără atribuire clară („ce a cerut cine, ce a executat agentul”), reconstituirea unui incident devine aproape imposibilă.

03Ce spune NIS2 despre asta — mai mult decât te aștepți

OUG nr. 155/2024 (transpunerea NIS2 în România) nu vorbește despre agenți AI, dar obligațiile pe care le impune acoperă exact acest caz. Securitatea lanțului de aprovizionare e una dintre măsurile minime obligatorii (Directiva NIS2 art. 21 alin. (2) lit. d), OUG art. 13): trebuie să iei în calcul vulnerabilitățile specifice fiecărui furnizor direct și calitatea practicilor lui de securitate. Un furnizor de AI cu acces la datele tale intră acolo fără discuție.

04Și AI Act? Unde se leagă

Regulamentul (UE) 2024/1689 impune obligații de raportare a incidentelor grave în sarcina furnizorilor de sisteme AI cu risc ridicat, iar pentru modelele cu scop general există obligații dedicate în sarcina furnizorilor de modele, aplicabile din august 2025. Pentru o firmă care doar utilizează astfel de instrumente, obligația directă e mai ușoară — dar există: alfabetizarea AI a personalului (Art. 4, în vigoare din februarie 2025) înseamnă, printre altele, ca oamenii care dau permisiuni unui agent să înțeleagă ce poate face el cu ele.

05Ce să ceri în contract înainte să dai unui agent acces la date

Momentul în care ai putere de negociere e înainte de semnătură, nu după incident. Pentru un furnizor de AI cu acces la sistemele tale, clauzele care contează sunt aceleași cu ale oricărui terț critic — plus câteva specifice acestei categorii de risc:

• Obligația de notificare a incidentelor CĂTRE TINE, într-un termen care îți permite să-ți respecți propriile 24 de ore. Un furnizor care te anunță în cinci zile te pune automat în neconformitate.
• Interdicția de a folosi datele tale pentru antrenarea modelelor, dacă nu ai convenit altfel explicit.
• Localizarea prelucrării și mecanismul de transfer, dacă furnizorul e din afara UE — clauze contractuale standard sau decizie de adecvare.
• Dreptul de audit sau, mai realist pentru un furnizor mare, dreptul la rapoarte de audit independente (SOC 2, ISO 27001) și la răspunsuri la chestionarul tău de securitate.
• Reversibilitatea: ce se întâmplă cu datele tale la încetarea contractului și în cât timp le primești înapoi sau sunt șterse.

06Șapte lucruri de făcut, în ordinea în care contează

• Fă lista agenților și copiloților AI care au acces la sisteme reale. Include ce a activat fiecare departament pe cont propriu — acolo sunt surprizele.
• Pentru fiecare, scrie ce poate face efectiv: doar citește? scrie? trimite? șterge? Dacă nimeni nu știe răspunsul, presupune cel mai rău.
• Dă-i fiecărui agent cont propriu, cu drepturi minime. Un agent care rulează cu contul unui administrator e o problemă care așteaptă un moment prost.
• Verifică dacă acțiunile agentului se loghează separat și dacă poți reconstitui „ce a cerut cine”.
• Definește butonul de oprire: cine îl apasă, de unde, în cât timp. Testează-l o dată, nu doar documenta-l.
• Trece furnizorul AI în registrul de furnizori, cu chestionar de securitate — la fel ca orice alt terț cu acces la date.
• Adaugă în procedura de incident scenariul „instrumentul a acționat singur”, cu cronometrul de 24h pornit din momentul detectării.