# Securitatea datelor AI în 2026: ghid pentru companiile din România
Securitatea datelor AI a devenit un criteriu de achiziție, nu o discuție rezervată departamentului IT. Dacă o bancă analizează documente KYC, o clinică rezumă dosare medicale sau un retailer conectează un agent AI la CRM, întrebarea nu mai este doar „Cât timp economisim?”, ci și „Cine poate vedea datele, unde ajung și cum dovedim ce s-a întâmplat cu ele?”. Acest ghid explică termenii esențiali, riscurile reale și pașii prin care o companie din România poate pilota AI fără să trateze confidențialitatea ca pe o promisiune vagă.
De ce securitatea datelor AI devine o prioritate de business
Un semnal relevant a venit în octombrie 2026. Potrivit Forbes România, Anthropic a achiziționat Opaque Systems, companie americană de securitate AI cofondată de Ion Stoica, Raluca Ada Popa, Rishabh Poddar, Chester Leung și Wenting Zheng. Valoarea tranzacției nu a fost făcută publică.
Opaque a pornit din cercetarea realizată la RISELab, UC Berkeley, cu o miză dificilă: organizațiile să poată folosi date sensibile fără să le expună nici măcar în timpul procesării. Ulterior, compania s-a orientat și spre verificarea modului în care rulează modelele și agenții AI. Legătura românească este importantă, dar implicația comercială este și mai puternică: furnizorii globali investesc în protecții care depășesc criptarea obișnuită a fișierelor.
Pentru o companie românească, evenimentul nu înseamnă că un produs devine automat sigur sau conform. Înseamnă că protejarea datelor „în uz” și verificarea tehnică a execuției intră în lista cerințelor enterprise. Instituțiile financiare, clinicile, asigurătorii, firmele juridice și companiile care gestionează volume mari de date despre clienți vor întâlni tot mai des aceste criterii în evaluări, contracte și audituri.
Miza nu este doar evitarea unei amenzi. Un proiect bine proiectat poate scurta timpul de aprobare internă, poate convinge clienții că datele lor sunt tratate responsabil și poate permite automatizarea unor procese care până acum rămâneau blocate din motive de risc.
Ce înseamnă, de fapt, „confidential AI”
Pentru a evalua o ofertă, decidentul trebuie să distingă trei stări ale datelor:
Date în repaus: informații stocate într-o bază de date, într-un fișier sau într-un backup. Acestea pot fi protejate prin criptarea spațiului de stocare și prin controlul accesului.
Date în tranzit: informații care circulă între utilizator, aplicație, model și alte sisteme. Protocoalele criptate reduc riscul de interceptare pe traseu.
Date în uz: informații încărcate în memorie și procesate efectiv. În această etapă, aplicația trebuie să poată „citi” datele, iar suprafața de expunere crește.
Confidential computing urmărește să protejeze tocmai a treia categorie. Sarcina de lucru rulează într-un mediu de execuție izolat, susținut de hardware, adesea comparat cu un seif: datele intră pentru a fi procesate, dar operatorii neautorizați și alte procese nu ar trebui să poată privi în interior. Mecanismele de atestare pot oferi dovezi despre mediul și codul care rulează.
„Verifiable AI” adaugă o altă întrebare: poate organizația să confirme independent că modelul sau agentul s-a comportat conform configurației aprobate? În practică, asta poate include dovezi despre versiunea codului, mediul de execuție, politicile aplicate și integritatea procesului. Nu elimină toate riscurile, dar înlocuiește o parte din încrederea oarbă cu verificări tehnice.
Criptare, anonimizare, pseudonimizare și izolare
Acești termeni nu sunt sinonimi:
Criptarea face datele ilizibile fără cheia potrivită. Protejează stocarea și transferul, iar unele arhitecturi extind protecția și în timpul procesării.
Anonimizarea urmărește eliminarea ireversibilă a legăturii cu o persoană. Dacă reidentificarea rămâne posibilă în mod rezonabil, datele pot fi în continuare personale.
Pseudonimizarea înlocuiește identificatorii direcți cu coduri. Reduce expunerea, dar legătura poate fi refăcută cu informațiile suplimentare potrivite.
Izolarea hardware separă procesarea sensibilă de restul infrastructurii și limitează cine poate accesa datele în uz.
O arhitectură matură combină aceste măsuri. Nu alegi între criptare și acces minim; folosești straturi care se susțin reciproc.
Ce riscuri apar când AI procesează date sensibile
Un chatbot public în care un angajat copiază un contract este doar cel mai vizibil scenariu. În proiectele reale, riscurile apar în mai multe puncte.
Prompturi și documente păstrate fără control
Conversațiile, fișierele încărcate și rezultatele pot fi păstrate pentru diagnosticare, siguranță sau îmbunătățirea serviciului. Dacă retenția nu este configurabilă și scopurile nu sunt clare, compania pierde controlul asupra unor informații care pot conține date personale, secrete comerciale sau clauze confidențiale.
Agenți cu permisiuni prea largi
Un agent conectat simultan la email, CRM, ERP și spațiul de fișiere poate accesa mai mult decât îi trebuie. O instrucțiune malițioasă ascunsă într-un document — un atac de tip prompt injection — poate încerca să determine agentul să divulge informații sau să execute o acțiune nepotrivită.
Principiul accesului minim rămâne esențial: agentul primește doar datele și acțiunile necesare sarcinii curente. Pentru plăți, ștergeri, trimiterea documentelor și modificări de cont trebuie introduse aprobări umane explicite.
Transferuri și subcontractori greu de urmărit
Aplicația cumpărată de companie poate folosi, la rândul ei, un model extern, un serviciu de stocare, instrumente de monitorizare și furnizori de suport. Fiecare verigă poate schimba locul procesării și lista entităților care au acces. O hartă incompletă a fluxului de date face dificilă evaluarea transferurilor internaționale și a obligațiilor contractuale.
Lipsa dovezilor după un incident
Fără loguri complete, echipa nu poate răspunde la întrebări simple: cine a accesat un document, ce prompt a fost trimis, ce instrument a apelat agentul, ce rezultat a produs și cine a aprobat acțiunea? Logarea trebuie proiectată atent: suficient de detaliată pentru audit, dar fără a transforma jurnalul într-o copie neprotejată a tuturor datelor sensibile.
În practică, riscul diferă după proces. O bancă poate analiza documente KYC și tranzacții fără a expune datele brute către operatori neautorizați. O clinică poate genera rezumate medicale, dar are nevoie de reguli stricte pentru acces, retenție și transfer. O firmă de avocatură sau contabilitate procesează contracte, salarii și informații fiscale, iar un retailer trebuie să separe datele clienților și să jurnalizeze fiecare acces al agenților AI.
GDPR și protecția informațiilor procesate de AI în România
Tehnologia nu înlocuiește analiza juridică și guvernanța. Înainte de pilot, compania trebuie să descrie scopul procesării, categoriile de date, persoanele vizate, sistemele implicate și rezultatul urmărit. Apoi poate stabili cine este operator, cine este persoană împuternicită și ce obligații trebuie reflectate în contract.
Scop, temei legal și minimizarea datelor
Faptul că un model poate folosi un set mare de date nu înseamnă că trebuie să îl primească. Echipa ar trebui să elimine câmpurile inutile, să pseudonimizeze unde este posibil și să limiteze accesul la cazurile relevante. Scopul trebuie să fie precis: „asistarea personalului în rezumarea documentelor” este mai controlabil decât „folosirea AI pentru eficiență”.
Retenție, localizare și transferuri
Contractul și configurația tehnică trebuie să răspundă la patru întrebări: unde sunt procesate datele, unde sunt păstrate, cât timp rămân disponibile și ce se întâmplă după ștergere. Pentru transferurile în afara Spațiului Economic European, echipa juridică și DPO-ul trebuie să verifice mecanismele aplicabile și riscurile contextului concret.
DPIA, inventar și trasabilitate
O evaluare de impact asupra protecției datelor poate fi necesară pentru prelucrări susceptibile să genereze risc ridicat. Chiar și când concluzia este că DPIA nu se impune, raționamentul merită documentat. În paralel, compania are nevoie de un inventar al sistemelor AI: proprietar intern, scop, date folosite, furnizori, nivel de risc, versiune și măsuri de control.
AI Act adaugă obligații care depind de rolul organizației și de categoria sistemului. Trasabilitatea, supravegherea umană, documentarea și monitorizarea nu trebuie lăsate pentru etapa de producție. Ele se proiectează în pilot.
Aceasta este o orientare practică, nu un verdict juridic. Aplicarea GDPR, AI Act și a regulilor sectoriale trebuie validată pentru fiecare caz împreună cu DPO-ul, juristul și specialiștii în securitate.
Checklist în 10 întrebări pentru furnizorul AI
Un demo convingător arată ce poate face produsul. Un proces de achiziție matur verifică și ce se întâmplă cu datele din spatele interfeței. Folosește întrebările de mai jos alături de ghidul despre cum alegi o soluție AI sigură.
Sunt folosite datele companiei pentru antrenarea modelelor? Cere diferențiere clară între antrenare, îmbunătățirea serviciului, monitorizare și suport.
Unde sunt stocate și procesate datele? Solicită regiuni concrete, nu formulări precum „în cloud”.
Ce subcontractori au acces și în ce jurisdicții? Verifică lista actuală, mecanismul de notificare și dreptul de opoziție la schimbări relevante.
Datele sunt criptate inclusiv în timpul procesării? Cere detalii despre protecția datelor în repaus, în tranzit și în uz, precum și despre administrarea cheilor.
Există izolare între clienți și sarcini de lucru? Furnizorul ar trebui să explice separarea logică sau fizică și controalele împotriva accesului între conturi.
Putem configura retenția și ștergerea verificabilă? Află ce se șterge, în cât timp, din ce sisteme și cum sunt tratate copiile de siguranță.
Există loguri complete pentru acces și acțiuni? Verifică dacă logurile pot fi exportate către sistemele interne și dacă includ acțiunile instrumentelor folosite de agenți.
Ce certificări, teste și rapoarte independente sunt disponibile? Certificarea nu este o garanție absolută, dar oferă dovezi ce pot fi analizate de echipa de securitate.
Cum sunt gestionate incidentele? Contractul trebuie să precizeze canalele, responsabilitățile, informațiile oferite și termenele de notificare.
Putem exporta datele și schimba furnizorul? Portabilitatea, formatele deschise și procedura de ieșire reduc blocajul tehnic și comercial.
Nu accepta răspunsuri exclusiv de marketing. Transformă afirmațiile importante în cerințe contractuale, configurații verificabile, rapoarte sau teste. Dacă furnizorul promite „zero retention”, cere să afli exact ce excepții există pentru abuz, securitate, backup și suport.
Plan practic de implementare în 30 de zile
Un pilot sigur nu trebuie să dureze șase luni. Are însă nevoie de un scop limitat, proprietari clari și criterii de oprire.
Săptămâna 1: clasifică datele și alege procesul
Inventariază intrările și ieșirile, apoi clasifică datele: publice, interne, confidențiale, personale sau speciale. Alege un proces cu valoare măsurabilă și risc controlabil. De exemplu, începe cu extragerea câmpurilor din documente pseudonimizate, nu cu un agent care poate trimite emailuri și modifica automat conturi de client.
Stabilește responsabilul de business, proprietarul tehnic, persoana care aprobă accesul la date și criteriile de succes. În această etapă poți compara arhitecturi și soluții AI pentru companii adaptate infrastructurii și nivelului de risc.
Săptămâna 2: compară furnizorii și limitează permisiunile
Trimite același set de întrebări furnizorilor și evaluează răspunsurile pe o grilă comună. Definește conturi separate pentru pilot, permisiuni minime, secrete administrate central și acces temporar. Dezactivează integrarea cu sisteme care nu sunt necesare.
Documentează fluxul complet: utilizator, aplicație, API, model, stocare, loguri și subcontractori. Orice „cutie neagră” devine o întrebare deschisă înainte de conectarea datelor reale.
Săptămâna 3: rulează pe date sintetice sau pseudonimizate
Testează funcționalitatea cu date sintetice care reproduc structura cazurilor reale. Apoi, dacă analiza de risc permite, introdu un set restrâns și pseudonimizat. Încearcă scenarii normale, erori, prompt injection, solicitări neautorizate și încercări de extragere a informațiilor din alte sesiuni.
Verifică și calitatea. Un răspuns protejat tehnic poate fi totuși greșit, incomplet sau discriminatoriu. Pentru procesele importante, stabilește praguri de încredere și o rută clară către revizuire umană.
Săptămâna 4: testează, documentează și aprobă gradual
Echipa de securitate verifică accesul, izolarea, logurile și comportamentul la incidente. DPO-ul și juristul validează documentația relevantă. Proprietarul de business compară rezultatele cu procesul existent. Accesul în producție se acordă gradual, inițial unui grup restrâns, cu monitorizare și posibilitatea de oprire rapidă.
Urmărește cel puțin șase indicatori:
numărul incidentelor, alertelor și acțiunilor blocate;
procentul datelor eliminate sau pseudonimizate înainte de procesare;
acuratețea rezultatului și rata de escaladare la om;
timpul economisit per caz;
costul total per caz procesat;
procentul acțiunilor acoperite de loguri utile.
La finalul celor 30 de zile, decizia nu trebuie redusă la „merge” sau „nu merge”. Poate fi: continuăm cu același scop, restrângem datele, schimbăm arhitectura, cerem condiții contractuale suplimentare sau oprim proiectul până la remedierea riscurilor.
Ce nu rezolvă confidential computing
Izolarea procesării reduce o categorie importantă de expunere, dar nu corectează un scop vag, date colectate excesiv sau un agent cu permisiunea de a șterge înregistrări. Nu împiedică automat un utilizator autorizat să folosească greșit informația și nu garantează că rezultatul modelului este corect.
De asemenea, o dovadă că un anumit cod a rulat într-un mediu protejat nu spune, singură, dacă acel cod respectă cerințele companiei. Organizația trebuie să verifice configurația, politicile, modelele folosite, actualizările și legăturile cu alte servicii.
Cele mai robuste proiecte combină protecția tehnică cu minimizarea datelor, controlul accesului, contracte adecvate, retenție limitată, testare adversarială, monitorizare și supraveghere umană. Fiecare strat acoperă un alt tip de eșec.
Concluzie: securitatea datelor AI devine avantaj comercial
Companiile care pot demonstra unde circulă datele, cine le accesează și ce controale se aplică vor adopta AI mai repede decât cele care încearcă să rezolve riscurile după lansare. Confidential computing și verificarea tehnică pot reduce expunerea datelor în uz, însă valoarea lor apare doar într-o arhitectură completă, susținută de guvernanță și responsabilități clare.
Agenția de AI ajută companiile să evalueze procese, să compare furnizori și să proiecteze piloți controlați, cu obiective de business și măsuri de siguranță explicite. Dacă vrei să identifici primul caz potrivit pentru compania ta, discută cu un consultant AI.
Întrebări Frecvente
Ce înseamnă securitatea datelor AI?
Înseamnă protejarea informațiilor folosite de sisteme AI în stocare, transfer și procesare, prin criptare, acces minim, izolare, loguri, retenție controlată și reguli clare pentru furnizori.
Poate o companie din România să folosească AI cu date personale?
Da, dacă stabilește un scop și un temei legal, minimizează datele, controlează accesul, verifică furnizorii și aplică obligațiile GDPR. Pentru prelucrări cu risc ridicat poate fi necesară o DPIA.
Confidential computing garantează conformitatea cu GDPR?
Nu. Protejează mai bine datele în timpul procesării, dar conformitatea cere și guvernanță, contracte, politici de retenție, drepturi ale persoanelor, evaluări de risc și control uman.
Ce trebuie întrebat un furnizor AI înainte de semnarea contractului?
Întreabă unde procesează datele, dacă le folosește la antrenare, cine sunt subcontractorii, cât le păstrează, ce loguri oferă, cum izolează clienții și cum notifică incidentele.
Vrei un pilot construit în jurul riscurilor și obiectivelor companiei tale? Descoperă serviciile Agenției de AI și discută cu un consultant AI.
Vrei să discutăm despre proiectul tău?
Primul apel e gratuit.
HAI SĂ DISCUTĂM?
