Testare de securitate cu AI: ce ai voie și cum documentezi

Un model modern citește un raport de scanare în câteva secunde, explică o vulnerabilitate mai clar decât majoritatea documentațiilor și scrie raportul final într-o formă pe care clientul chiar o înțelege. Tentația de a merge mai departe — „hai să văd dacă merge și pe sistemul ăsta" — e exact locul unde se termină munca de securitate și începe infracțiunea. Linia nu e trasată de unealtă, ci de o autorizare scrisă, iar în România ea are un articol de lege în spate.

Articolul e pentru echipele care fac testare de securitate autorizată — intern sau pentru clienți — și vor să folosească modele fără să încalce nici legea, nici termenii furnizorului. Nu conține instrucțiuni de atac și nu discută tehnici ofensive: e despre cadrul în care se lucrează legal și despre locurile în care un model chiar aduce valoare.

Ce spune legea în România

Codul penal — Legea nr. 286/2009 — sancționează accesul neautorizat indiferent de intenția celui care îl obține.

Articolul 360, alineatul (1): „Accesul, fără drept, la un sistem informatic se pedepsește cu închisoare de la 3 luni la 3 ani sau cu amendă." Alineatul (2) agravează fapta când e săvârșită „în scopul obținerii de date informatice" — închisoare de la 6 luni la 5 ani. Alineatul (3) merge mai departe: dacă accesul privește un sistem la care, „prin intermediul unor proceduri, dispozitive sau programe specializate, accesul este restricționat sau interzis pentru anumite categorii de utilizatori", pedeapsa e închisoarea de la 2 la 7 ani.

Sintagma care decide totul e „fără drept". Testarea de securitate legitimă nu e o excepție prevăzută pentru profesioniști: e pur și simplu acces cu drept, dovedit printr-un document semnat de cine deține sistemul.

Merită știut și articolul 365, care sancționează producerea, importul, distribuirea sau punerea la dispoziție, fără drept, a dispozitivelor, programelor, parolelor sau codurilor de acces destinate săvârșirii infracțiunilor informatice, precum și deținerea lor în acest scop. Pentru cine lucrează în securitate, concluzia practică e că scopul și contextul contează juridic: aceleași unelte, folosite în cadrul unui contract de testare, respectiv în afara lui, produc consecințe complet diferite.

Cadrul de guvernanță, evaluarea riscurilor și partea de conformitate pentru sistemele care folosesc modele sunt tratate în cursul AI pentru Securitate Cibernetică și SOC.

Ce spun furnizorii de modele

A doua limită, independentă de lege, e contractuală. Politica de utilizare a Anthropic interzice explicit, la capitolul despre compromiterea sistemelor, „descoperirea sau exploatarea vulnerabilităților din sisteme, rețele sau aplicații fără autorizarea proprietarului sistemului", obținerea accesului neautorizat prin atacuri tehnice sau inginerie socială, crearea sau distribuirea de programe rău intenționate și dezvoltarea de unelte pentru atacuri de tip refuz al serviciului.

Formularea e importantă în ambele direcții: nu există o interdicție generală asupra securității ofensive, ci asupra celei neautorizate. Cu o autorizare în regulă, lucrul rămâne în interiorul politicii; fără ea, riști suspendarea contului în plus față de răspunderea penală.

Regula de echipă care rezolvă ambiguitatea: autorizarea se verifică înainte de prima comandă, nu după ce apare un rezultat interesant.

Cum arată o autorizare care te acoperă

Un e-mail cu „aveți acordul nostru" nu e suficient. Documentul minim conține:

• Cine autorizează și dovada că are dreptul să o facă — proprietarul sistemului, nu furnizorul de găzduire și nu un director de departament fără mandat.
• Perimetrul exact: domenii, adrese IP, aplicații, conturi de test. Și, la fel de important, ce e exclus — sisteme terțe, integrări, furnizori de plăți.
• Fereastra de timp, cu dată de început și de sfârșit.
• Tehnicile permise și cele interzise: de regulă sunt excluse testele de disponibilitate, ingineria socială asupra angajaților și orice acțiune care poate distruge date.
• Regula privind datele: ce faci dacă ajungi la date cu caracter personal — de obicei, te oprești, notezi și raportezi, fără să copiezi.
• Contactul de urgență și procedura de oprire imediată.
• Confidențialitatea rezultatelor și termenul până la care clientul poate remedia înainte de orice publicare.

Pentru programele deschise de raportare există un limbaj consacrat, numit safe harbor: proiectul disclose.io îl definește drept text adăugat unei politici care permite celor care acționează cu bună-credință „să raporteze probleme de securitate fără teama consecințelor juridice", și pune la dispoziție șabloane de politică revizuite juridic.

Dacă tu ești cel care primește rapoarte, minimul tehnic e un fișier security.txt, standardizat prin RFC 9116 (publicat în aprilie 2022, cu statut informativ). Se plasează la /.well-known/security.txt și are două câmpuri obligatorii: Contact, care indică metoda de raportare, și Expires, care spune până când informația e valabilă. Câmpurile opționale includ Policy, Encryption, Acknowledgments și Preferred-Languages. Este cea mai ieftină măsură de securitate pe care o poți implementa într-o oră.

Unde ajută modelele, realist

Din practica echipelor care lucrează contractual, valoarea apare în cinci locuri, toate în afara zonei „exploatare":

Triajul rezultatelor. Un scaner produce sute de constatări, dintre care majoritatea sunt zgomot. Un model grupează, ordonează după impact plauzibil și marchează ce merită verificat manual. Economia de timp e reală și nu implică niciun risc juridic.

Înțelegerea unui sistem necunoscut. Documentație, configurații, cod pus la dispoziție de client — un model le citește rapid și răspunde la întrebări, cu condiția să ceri fiecare afirmație cu fișier și linie.

Scrierea raportului. Partea pe care o urăsc toți: descrierea vulnerabilității pentru un cititor non-tehnic, pașii de reproducere, recomandarea de remediere, rezumatul executiv. Aici modelele sunt foarte bune, iar calitatea raportului decide, de fapt, dacă clientul repară ceva.

Testul de regresie pentru remediere. După ce clientul a reparat, ai nevoie de o verificare repetabilă care confirmă că problema nu revine. Un model scrie rapid astfel de teste, integrabile în pipeline-ul clientului.

Traducerea între echipe. Aceeași constatare, explicată developerului, managerului de proiect și responsabilului cu conformitatea, în trei registre diferite.

Unde nu ajută, contrar așteptărilor: nu îți construiește un lanț de exploatare pe un sistem real fără context, nu confirmă că o constatare e exploatabilă — asta se validează manual — și nu înlocuiește judecata privind impactul asupra afacerii clientului.

Ce nu pui niciodată într-un model

Regula e aceeași ca la orice date ale clientului, dar miza e mai mare:

• Credențiale, chei, jetoane de sesiune — inclusiv cele „de test" primite pentru misiune.
• Date cu caracter personal găsite în timpul testului. Dacă ai ajuns la ele, obligația e să te oprești și să raportezi, nu să le procesezi.
• Capturi de ecran cu date reale, trimise „pentru context".
• Configurații complete de infrastructură ale clientului, când contractul le clasifică drept confidențiale.

Practic: în model intră descrieri, structuri și rezultate curățate; datele clientului rămân în perimetrul convenit. Cum izolezi mediul în care rulează agentul, ca să nu devină el însuși suprafața de atac, e detaliat în ghidul despre izolarea agenților de programare. Modelarea amenințărilor și guardrails-urile pentru sistemele care folosesc modele sunt tratate în cursul AI Security și Ethical Engineering.

Raportarea: ce s-a schimbat în 2026

Două obligații care ating direct munca de testare.

Vulnerabilitățile exploatate activ. Obligațiile de raportare din Regulamentul privind reziliența cibernetică se aplică din 11 septembrie 2026 pentru produsele cu elemente digitale puse pe piața europeană. Dacă în timpul unui test descoperi că o vulnerabilitate e deja exploatată, discuția nu mai e doar între tine și client — detaliile sunt în articolul despre Cyber Resilience Act.

Lanțul de aprovizionare. Clienții aflați sub regimul NIS2 își evaluează furnizorii și transmit cerințe prin contract, inclusiv privind testarea de securitate; contextul de aplicare în România e în articolul despre NIS2, sancțiuni și obligațiile conducerii.

Tot aici intră și situația inversă, în care tu ești furnizorul evaluat: întrebările pe care le primești într-o evaluare de securitate și pachetul de răspuns sunt în articolul despre chestionarul de securitate al clientului enterprise.

Consecința pentru o firmă de servicii: raportul tău de testare devine document de conformitate al clientului, deci trebuie să fie datat, versionat, cu perimetru explicit și cu retestare documentată.

Trei tipuri de misiuni, trei forme de autorizare

Testarea contractată. Cea mai clară situație: un contract de servicii, cu perimetru, interval și persoane de contact. Autorizarea e o anexă la contract, semnată înainte de începere. Dacă clientul folosește infrastructură terță — găzduire, procesator de plăți, furnizor SaaS —, ai nevoie și de acordul acelui furnizor sau de excluderea explicită a sistemelor lui din perimetru.

Programele de divulgare și bug bounty. Autorizarea vine din politica publică a organizației, nu dintr-un contract individual. Citește-o integral înainte: perimetrul, tehnicile interzise, regulile privind datele și, cel mai important, dacă include clauza de tip safe harbor. Absența acesteia nu te împiedică să raportezi, dar îți spune că organizația nu și-a asumat public că nu te va acționa în justiție.

Testarea internă, în propria firmă. Aparent cea mai simplă, practic cea în care apar cele mai multe neînțelegeri. Ai nevoie de un mandat scris de la conducere, pentru că sistemele aparțin companiei, nu echipei tale, iar accesul „fără drept" se poate discuta și în interiorul unei organizații. În plus, dacă testezi sisteme care conțin date ale angajaților, intră în joc și obligațiile privind protecția datelor și informarea prealabilă.

Pentru toate trei, verificarea preliminară e identică: cine deține sistemul, cine a semnat, ce e în perimetru, până când e valabil.

Raportul: partea care decide dacă se repară ceva

Un test bun cu un raport prost nu produce nicio îmbunătățire. Structura care funcționează, și la care un model ajută real:

• Rezumat pentru conducere, în zece rânduri, fără jargon: ce se poate întâmpla, ce costă, ce se face săptămâna asta.
• Constatări ordonate după impact real asupra afacerii, nu după scorul generic al scanerului.
• Pași de reproducere suficient de clari pentru ca developerul să confirme problema în cinci minute.
• Recomandare de remediere concretă, cu alternative dacă soluția ideală e costisitoare.
• Dovezi curățate: capturi fără date personale, identificatori mascați.
• Plan de retestare, cu dată și criterii de închidere.

Modelul ajută la primele trei și la a patra, dacă îi dai constatarea validată manual și contextul tehnic. Nu îi ceri să inventeze impactul asupra afacerii — acela vine din discuția cu clientul, iar o exagerare în raport te costă credibilitatea la următoarea misiune.

Listă de control înainte de a începe

1. Autorizare scrisă, semnată de cine deține sistemul, cu perimetru și fereastră de timp.
2. Lista explicită a sistemelor excluse, inclusiv a celor ale terților.
3. Tehnici interzise, scrise, nu subînțelese.
4. Procedura pentru datele cu caracter personal întâlnite accidental.
5. Contact de urgență, disponibil pe toată durata testului.
6. Confirmarea că furnizorii de unelte și de modele permit utilizarea în acest context.
7. Mediu de lucru separat, fără credențiale de producție proprii.
8. Jurnal al acțiunilor, cu marcaj de timp — îți protejează munca la fel de mult ca autorizarea.
9. Reguli despre ce iese din perimetru: în model intră descrieri, nu date.
10. Calendar de raportare și de retestare, agreat înainte de prima comandă.

Întrebări frecvente

Î: E legal să folosesc AI pentru testare de securitate? R: Da, în cadrul unei testări autorizate. Instrumentul nu schimbă încadrarea juridică: ceea ce contează e dacă accesul la sistem e „cu drept" sau nu. Articolul 360 din Codul penal sancționează accesul fără drept la un sistem informatic cu închisoare de la 3 luni la 3 ani sau cu amendă, cu variante agravate. Autorizarea scrisă, cu perimetru și interval definite, e documentul care face diferența.

Î: Politica furnizorilor de modele îmi permite acest tip de muncă? R: Politica de utilizare a Anthropic interzice descoperirea sau exploatarea vulnerabilităților fără autorizarea proprietarului sistemului, accesul neautorizat, crearea de programe rău intenționate și uneltele pentru atacuri de tip refuz al serviciului. Interdicția vizează activitatea neautorizată; munca într-un perimetru autorizat rămâne în interiorul politicii. Verifică termenii furnizorului pe care îl folosești, pentru că formulările diferă.

Î: Unde aduce un model cea mai mare valoare într-un test? R: În triajul rezultatelor unui scaner, în înțelegerea rapidă a unui sistem documentat, în scrierea raportului și a testelor de regresie pentru remediere, și în traducerea constatărilor pentru publicuri diferite. Validarea faptului că o constatare e exploatabilă rămâne manuală.

Î: Ce fac dacă dau peste date personale în timpul testului? R: Te oprești, notezi minimul necesar pentru raport — fără să copiezi datele — și anunți imediat contactul stabilit în contract. Procedura trebuie scrisă în autorizare înainte de începerea testului, tocmai ca decizia să nu se ia sub presiune.

Î: Cum primesc rapoarte de securitate dacă sunt de partea cealaltă? R: Publici o politică de divulgare cu limbaj de tip safe harbor, pentru cercetătorii de bună-credință, și un fișier security.txt la /.well-known/security.txt, conform RFC 9116, cu cel puțin câmpurile Contact și Expires. Costă o oră de muncă și transformă un raport pierdut într-unul primit.

Concluzie

Modelele au schimbat economia muncii de securitate: triajul, înțelegerea unui sistem și raportarea se fac de câteva ori mai repede. Ce nu s-a schimbat e cadrul juridic — accesul fără drept rămâne infracțiune, indiferent de unealtă, iar politicile furnizorilor spun același lucru în limbaj contractual.

Echipele serioase rezolvă asta plictisitor: autorizare scrisă înainte de orice comandă, perimetru explicit, jurnal al acțiunilor, date ale clientului care nu părăsesc perimetrul convenit și un raport care ajută clientul să repare. Restul e muncă tehnică, iar acolo un model e un coleg foarte bun.

Surse: Codul penal, art. 360 — accesul ilegal la un sistem informatic · Codul penal, art. 365 — operațiuni ilegale cu dispozitive sau programe informatice · Anthropic — Usage Policy · disclose.io — safe harbor și politici de divulgare · RFC 9116 — security.txt

Articol informativ, publicat la 19 septembrie 2026. Are caracter educativ și nu constituie consultanță juridică. Nu conține instrucțiuni operaționale de atac. Testarea de securitate se efectuează exclusiv în baza unei autorizări scrise din partea deținătorului sistemului; pentru încadrarea juridică a unei situații concrete, consultă un avocat.