AI Act și GDPR: cum folosești date personale în AI
Ghid practic pentru datele introduse în sisteme AI: scop, temei GDPR, minimizare, furnizori, retenție, drepturi și evaluarea riscului.
AI ACT · PROTECȚIA DATELOR
AI Act și GDPR nu sunt două liste alternative din care alegi una. Primul privește sistemul AI, rolurile și riscurile sale; al doilea se aplică atunci când acel sistem prelucrează date despre persoane. Într-un proiect real, cele două analize se întâlnesc în același prompt, log și flux de lucru.
AI Act nu oferă un temei GDPR
Respectarea unei obligații de transparență, inventarierea sistemelor sau clasificarea riscului conform AI Act nu autorizează automat colectarea datelor personale. Pentru fiecare prelucrare trebuie stabilite separat scopul, temeiul aplicabil, necesitatea, informarea persoanei, durata de păstrare și destinatarii. O bifă „AI Act” nu înlocuiește această analiză. [EU-REG] [EDPB-28]
Avizul EDPB 28/2024 arată că legitimitatea interesului trebuie evaluată printr-un test în trei pași și în contextul concret. Același aviz spune că anonimitatea unui model nu se presupune: trebuie să fie foarte improbabil ca persoanele din datele de dezvoltare să fie identificate sau ca datele lor să fie extrase prin interogări. [EDPB-28]
Desenează traseul datelor înaintea traseului API
Pornește cu patru zone: intrare, context, ieșire și log. Intrarea poate conține nume, email sau conversație; contextul poate proveni din CRM, documente ori istoric; ieșirea poate infera informații despre o persoană; logul poate păstra toate acestea la furnizor și în infrastructura proprie. Notează pentru fiecare câmp sursa, scopul și cine îl poate vedea. [EU-REG] [OAI-DPA]
Separă datele necesare pentru rezultat de cele introduse doar pentru comoditate. Un rezumat al unei solicitări poate avea nevoie de contextul cazului, dar nu de CNP, parolă sau întregul istoric al clientului. Folosește pseudonime, identificatori temporari și filtrare înainte de trimiterea către model atunci când informația direct identificabilă nu schimbă rezultatul. [EDPB-28] [OAI-DPA]
Contractul cu furnizorul nu rezolvă designul produsului
OpenAI declară că, implicit, nu folosește intrările și ieșirile din API și produsele business pentru antrenarea modelelor, dacă organizația nu optează explicit pentru partajare. Această afirmație este relevantă, dar nu înseamnă „datele nu sunt prelucrate” și nu stabilește scopul sau temeiul companiei care trimite datele. [OAI-DATA]
DPA-ul OpenAI descrie responsabilități de procesator, asistența pentru incidente, returnarea sau ștergerea după încetarea contractului, mecanisme de transfer și obligația clientului de a deține notificările și autorizările necesare. Tot el lasă clientului anumite decizii de configurare, inclusiv retenția și ștergerea. Contractul trebuie citit împreună cu configurația efectivă. [OAI-DPA]
Verifică lanțul de subprocessatori și transferurile
Lista OpenAI din 9 iulie 2026 arată subprocessatori diferiți în funcție de produs și scop, cu locații de procesare din mai multe regiuni. DPA-ul prevede notificarea modificărilor și o fereastră de obiecție. Evaluarea furnizorului trebuie să păstreze versiunea listei consultate, produsele folosite și mecanismul de transfer relevant. [OAI-SUB] [OAI-DPA]
Nu copia lista într-o politică și apoi o uita. Abonează un responsabil la notificări, definește criteriile de reevaluare și leagă modificarea furnizorului de registrul AI și evidența GDPR. Un nou subprocessator, o regiune nouă sau activarea unui conector poate schimba traseul datelor fără să modifice interfața vizibilă. [OAI-SUB] [EU-REG]
Drepturile persoanei trebuie să funcționeze tehnic
O procedură de acces sau ștergere este inutilă dacă echipa nu poate găsi promptul, logul, vectorul, fișierul și ieșirea legate de aceeași persoană. Decide din proiectare ce identificator permite căutarea, ce copii există, ce poate fi rectificat și unde o ștergere trebuie propagată. Evită arhive imposibil de interogat doar pentru că stocarea este ieftină. [EDPB-28] [OAI-DPA]
Separă și situația în care datele există doar în contextul aplicației de aceea în care ar putea fi memorate sau reflectate de un model. EDPB cere o analiză de caz pentru anonimitatea modelului și consecințele datelor prelucrate nelegal. Nu promite ștergerea din model dacă arhitectura și contractul nu pot susține promisiunea. [EDPB-28]
Fișa minimă pentru aprobarea unui caz de utilizare
Înainte de lansare, fișa trebuie să conțină: scopul, categoriile de persoane și date, sursa, temeiul evaluat, rolurile operator/procesator, produsul și regiunea, subprocessatorii, retenția, accesul, filtrarea datelor, informarea, mecanismul pentru drepturi, testele și proprietarul intern. Adaugă data următoarei revizuiri și semnalul care o declanșează mai devreme. [EU-REG] [EDPB-28] [OAI-DPA] [OAI-SUB]
Pentru un flux SEO, un agent WordPress sau un asistent de suport, regula practică este aceeași: nu trimite către model mai mult decât ai putea explica persoanei vizate într-o propoziție clară. Când nu poți explica de ce un câmp este necesar, elimină-l sau oprește lansarea până când scopul și controlul sunt reale. [EDPB-28] [EU-REG]