Înainte ca o firmă mică să lanseze un formular „cu AI” sau un asistent conectat la un model extern, întrebarea importantă nu este doar dacă funcționează. Întrebarea este: pe unde trec datele oamenilor? Un câmp de contact, o descriere de problemă, un CV, o sesizare sau un fișier încărcat pot ajunge în baza aplicației, în prompt, în loguri, în instrumente de analiză și la un furnizor de API. Fără o hartă clară, riscul este să descoperi prea târziu că ai colectat mai mult decât trebuia sau că nu poți explica ce se întâmplă cu datele.
Data mapping înseamnă să trasezi concret fluxul: ce intră, unde se salvează, cine are acces, către cine pleacă, cât timp rămâne și când se șterge. Nu este o formalitate pentru companii mari. CNIL descrie registrul activităților de prelucrare ca instrument pentru inventarierea activităților, actorilor, categoriilor de date, scopurilor, destinatarilor, duratelor de păstrare și măsurilor tehnice ori organizatorice. În practică, exact această disciplină ajută și un freelancer sau un startup să nu trateze AI-ul ca pe o cutie neagră.
Primul pas este formularul. Notează fiecare câmp: nume, email, telefon, companie, mesaj liber, atașamente, consimțăminte, identificatori tehnici. Apoi întreabă rece: fiecare câmp este necesar pentru scopul declarat? Orientările ANSPDCP/CEPD privind protecția datelor din momentul conceperii și în mod implicit insistă pe principii precum limitarea scopului, minimizarea datelor, limitarea stocării, integritatea, confidențialitatea și responsabilitatea. Dacă aplicația doar clasifică o cerere, poate nu are nevoie de CNP, adresă completă sau documente încărcate implicit.
Al doilea pas este aplicația. Unde se salvează datele: bază de date, CRM, email, ticketing, storage pentru fișiere, cache? Cine poate vedea înregistrările: administratorul, suportul, dezvoltatorul, contabilitatea, contractorii? Există exporturi CSV? Există backupuri? Data mapping-ul bun include și copiile uitate, nu doar fluxul principal din interfață.
Al treilea pas este promptul. În multe aplicații AI, datele din formular sunt transformate într-un mesaj pentru model: „rezumă cererea”, „clasifică lead-ul”, „scrie un răspuns”. Aici trebuie decis ce intră efectiv în prompt. Poți masca sau elimina datele care nu sunt necesare? Trimiți documentul complet sau doar fragmente relevante? Păstrezi promptul și răspunsul pentru audit, debugging sau îmbunătățirea produsului? Dacă da, cât timp și cu ce acces?
Al patrulea pas sunt logurile. Pentru sisteme AI cu risc ridicat, AI Act cere capabilități de logging care să permită trasabilitatea, monitorizarea după introducerea pe piață și monitorizarea operării. Nu orice formular AI intră automat în categoria high-risk, dar principiul este util: logurile trebuie proiectate, nu lăsate la întâmplare. Salvează evenimente, ID-uri, timpi, versiuni de model și erori, dar evită să copiezi inutil conținut sensibil în fiecare jurnal tehnic. Un log bun ajută la audit; un log prost devine o a doua bază de date cu date personale.
Al cincilea pas este furnizorul de model sau API. Verifică ce date trimiți, în ce regiune sunt procesate, dacă sunt folosite pentru training, fine-tuning, evaluare sau abuz prevention, ce opțiuni de retenție există și cum se gestionează ștergerea. CNIL subliniază că GDPR și AI Act se aplică împreună când sunt folosite date personale și că trebuie analizate separat fazele de dezvoltare și deployment, precum și rolurile: operator, operatori asociați sau persoană împuternicită. Cu alte cuvinte, nu este suficient să spui „folosim AI”; trebuie să știi cine decide scopurile și cine prelucrează datele în numele cui.
Pentru temeiul legal, evitați automatismul. EDPB arată, în opinia sa despre modelele AI și GDPR, că interesul legitim cere un test în trei pași: scop legitim, necesitate strictă și balanță între interesele organizației și drepturile persoanei. Tot EDPB explică prudent anonimizarea: un model poate fi considerat anonim doar dacă este foarte puțin probabil ca persoanele din datele folosite să fie identificate direct sau indirect ori ca date personale să fie extrase prin interogări. Asta nu se presupune; se demonstrează tehnic și juridic.
O hartă minimă pentru o aplicație AI ar trebui să aibă coloane simple: punct de colectare, categorie de date, scop, temei analizat, sistem unde se stochează, destinatar intern, furnizor extern, intră în prompt sau nu, intră în loguri sau nu, folosit pentru training sau analiză, durată de păstrare, măsură de ștergere, măsuri de securitate și responsabil. ICO oferă un toolkit de risc AI util ca reper practic pentru drepturile și libertățile persoanelor, chiar dacă ghidul este în revizuire în UK și nu este sursă de drept pentru România.
Pentru fondatori, concluzia este simplă: nu lansa întâi și documenta după. Fă harta datelor înainte de formular, revizuiește-o la fiecare schimbare de model, furnizor sau funcționalitate și păstrează deciziile explicate. Acest articol nu este consultanță juridică definitivă; pentru cazuri concrete, verifică sursele oficiale și discută cu DPO-ul, juristul sau consultantul potrivit.
Surse
- EDPB — EDPB opinion on AI models and GDPR principles support responsible AI
- CNIL — AI system development: CNIL’s recommendations to comply with GDPR
- CNIL — Record of processing activities
- ICO — AI and data protection risk toolkit
- Comisia Europeană — AI Act, regulatory framework
- AI Act Service Desk — Article 12, Record-keeping
- AI Act Service Desk — Article 11, Technical documentation
- AI Act Service Desk — Article 50, Transparency obligations
- ANSPDCP/CEPD — Orientări privind Articolul 25 RGPD, protecția datelor începând cu momentul conceperii și în mod implicit
