GDPR și software custom: ce trebuie să știe orice antreprenor înainte să colecteze date

Consimțământ, dreptul la ștergere, audit logs, criptare, DPA și protecția datelor încă din faza de proiectare — ghid pentru antreprenori care construiesc aplicații custom.

Când un antreprenor decide să construiască o aplicație software custom, primele discuții sunt de obicei despre funcționalități: conturi de utilizator, dashboard, plăți, formulare, notificări, rapoarte, portal client, aplicație mobilă sau integrări cu alte sisteme.

Foarte rar, prima discuție este despre date.

Ce date colectăm? De ce le colectăm? Cine are acces la ele? Cât timp le păstrăm? Cum le ștergem? Cum demonstrăm că utilizatorul și-a dat consimțământul? Ce se întâmplă dacă un client cere exportul datelor? Cine răspunde dacă apare o breșă de securitate? Ce obligații are firma de software și ce obligații are clientul?

Aceste întrebări pot părea juridice, dar ele au consecințe tehnice directe. GDPR nu este doar o politică de confidențialitate pusă în footer. GDPR influențează arhitectura aplicației, baza de date, logurile, permisiunile, formularele, notificările, backupurile, contractele cu furnizorii și modul în care aplicația răspunde la cererile utilizatorilor.

Pentru un software custom, protecția datelor trebuie gândită din prima etapă, nu adăugată la final. Dacă aplicația este construită fără logică de ștergere, fără audit, fără roluri, fără evidența consimțământului și fără control asupra accesului, conformarea devine mai grea și mai scumpă ulterior.

GDPR nu este doar problema avocatului

Mulți antreprenori tratează GDPR ca pe un document juridic: politică de confidențialitate, termeni și condiții, banner de cookies și eventual un contract cu firma de software.

Aceste documente sunt importante, dar nu sunt suficiente.

Dacă aplicația ta colectează nume, emailuri, telefoane, adrese, date de facturare, documente, mesaje, locații, IP-uri, date medicale, date financiare sau orice alte informații care pot identifica o persoană, atunci GDPR trebuie integrat și în modul în care aplicația funcționează.

De exemplu, nu este suficient să scrii în politica de confidențialitate că utilizatorul poate cere ștergerea datelor. Aplicația trebuie să permită identificarea datelor asociate acelui utilizator, analizarea motivului legal pentru păstrare sau ștergere și executarea cererii într-un mod controlat.

Nu este suficient să spui că datele sunt protejate. Aplicația trebuie să aibă parole stocate corect, conexiuni securizate, roluri, permisiuni, backup, loguri și măsuri împotriva accesului neautorizat.

Nu este suficient să ai un checkbox de consimțământ. Trebuie să știi exact pentru ce a consimțit persoana, când, prin ce formular, pentru ce scop și cum își poate retrage consimțământul.

GDPR este juridic, dar implementarea lui este și tehnică.

Începe cu întrebarea corectă: ce date colectăm și de ce?

Primul pas într-un proiect software custom este inventarierea datelor. Înainte de a construi formulare și baze de date, trebuie clarificat ce informații sunt cu adevărat necesare.

Întrebări utile:

• Ce date colectăm de la utilizatori?
• Care sunt obligatorii și care sunt opționale?
• Pentru ce scop folosim fiecare categorie de date?
• Avem nevoie reală de aceste date sau le colectăm „poate ne vor folosi”?
• Cine are acces la ele?
• Cât timp le păstrăm?
• Le transmitem către furnizori externi?
• Le folosim pentru marketing?
• Le folosim pentru profilare sau decizii automate?
• Le exportăm către alte sisteme?
• Le stocăm în România, în UE sau în afara UE?

Această analiză este importantă pentru că unul dintre principiile sănătoase în protecția datelor este minimizarea: colectezi doar ce ai nevoie pentru scopul declarat.

Dacă aplicația este un portal de programări, poate ai nevoie de nume, telefon, email și serviciul solicitat. Dar poate nu ai nevoie de CNP. Dacă aplicația este un marketplace, ai nevoie de date de facturare și livrare. Dar poate nu ai nevoie să păstrezi anumite documente după finalizarea procesului.

Cu cât colectezi mai multe date, cu atât crește responsabilitatea.

Baza legală: consimțământul nu este singura opțiune

O greșeală frecventă este presupunerea că orice prelucrare trebuie bazată pe consimțământ. În realitate, consimțământul este doar una dintre bazele legale posibile.

În funcție de situație, datele pot fi prelucrate pentru executarea unui contract, pentru respectarea unei obligații legale, pentru interes legitim, pentru consimțământ sau pentru alte temeiuri prevăzute de GDPR.

De exemplu, dacă un client cumpără un produs, ai nevoie de datele lui pentru a procesa comanda și pentru a emite factura. Aici nu este neapărat vorba despre consimțământ, ci despre executarea contractului și obligații legale.

Dacă trimiți newsletter comercial, cel mai probabil ai nevoie de consimțământ sau de o analiză foarte atentă a temeiului folosit.

Dacă păstrezi facturi, nu poți șterge totul imediat doar pentru că utilizatorul cere ștergerea, deoarece pot exista obligații fiscale de păstrare.

De aceea, aplicația trebuie proiectată în funcție de scopuri și temeiuri diferite. Nu toate datele au același regim.

Consimțământul: nu doar un checkbox

Dacă folosești consimțământul ca bază legală, acesta trebuie tratat serios. Un checkbox ascuns, pre-bifat sau formulat vag nu este o soluție bună.

Consimțământul trebuie să fie clar, specific, informat și ușor de retras. Utilizatorul trebuie să înțeleagă pentru ce își dă acordul.

Exemple de consimțământ prost:

• „Sunt de acord cu tot.”
• „Accept termenii și marketingul.”
• „Sunt de acord cu prelucrarea datelor.”

Exemple mai bune:

• „Sunt de acord să primesc newslettere cu oferte și articole pe email.”
• „Sunt de acord ca datele mele să fie folosite pentru crearea unui cont în platformă.”
• „Sunt de acord să fiu contactat telefonic pentru detalii despre solicitarea trimisă.”

Într-o aplicație custom, consimțământul trebuie salvat ca eveniment în sistem. Ideal, aplicația trebuie să păstreze:

• cine a consimțit;
• pentru ce scop;
• data și ora;
• versiunea textului acceptat;
• sursa consimțământului;
• adresa IP sau alt identificator relevant, dacă este justificat;
• momentul retragerii consimțământului, dacă apare.

Această evidență este importantă pentru demonstrarea conformării.

Dreptul la ștergere: mai complicat decât pare

Dreptul la ștergere, numit uneori „dreptul de a fi uitat”, este unul dintre cele mai cunoscute drepturi GDPR. Mulți utilizatori cred că pot cere oricând ștergerea completă a tuturor datelor. În practică, lucrurile sunt mai nuanțate.

Unele date pot fi șterse imediat. Altele trebuie păstrate o perioadă din motive legale, contractuale, fiscale sau pentru apărarea unor drepturi.

De exemplu, un cont de utilizator inactiv poate fi șters sau anonimizat. Dar facturile emise către acel client pot trebui păstrate conform obligațiilor legale. O cerere de suport poate fi ștearsă după o perioadă rezonabilă, dar un istoric de tranzacții poate avea alt regim.

De aceea, software-ul trebuie să permită diferențierea datelor:

• date de cont;
• date de facturare;
• date contractuale;
• date operaționale;
• date de marketing;
• loguri tehnice;
• documente încărcate;
• istoric comenzi;
• mesaje;
• date anonimizate pentru raportare.

O aplicație bine proiectată nu tratează ștergerea ca pe un simplu buton „delete user”. În multe cazuri, este mai corect să existe fluxuri de ștergere, anonimizare, restricționare sau arhivare, în funcție de natura datelor.

Dreptul de acces și portabilitate: poți exporta datele utilizatorului?

GDPR oferă persoanelor vizate dreptul de a afla ce date sunt prelucrate și, în anumite situații, de a primi o copie a datelor într-un format utilizabil.

Din perspectivă software, asta înseamnă că aplicația ar trebui să poată identifica și exporta datele asociate unei persoane.

Într-un sistem simplu, acest lucru poate fi ușor. Într-o aplicație complexă, datele pot fi răspândite în mai multe tabele: cont, profil, comenzi, facturi, mesaje, documente, notificări, loguri, preferințe, consimțăminte, plăți și activitate.

Dacă această cerință nu este gândită din faza de proiectare, răspunsul la o cerere de acces poate deveni o operațiune manuală dificilă.

Pentru aplicațiile business, este util să existe un modul administrativ prin care operatorul poate căuta o persoană și poate vedea ce categorii de date sunt asociate acesteia. În funcție de context, se poate genera un export structurat.

Audit logs: cine a făcut ce, când și de unde?

Audit logs înseamnă jurnalizarea acțiunilor importante din aplicație. Nu orice click trebuie salvat, dar acțiunile relevante trebuie urmărite.

Exemple:

• cine a accesat un dosar;
• cine a modificat datele unui client;
• cine a descărcat un document;
• cine a schimbat rolul unui utilizator;
• cine a șters o înregistrare;
• cine a exportat date;
• cine a aprobat o cerere;
• cine a modificat consimțământul;
• cine a schimbat setările de securitate.

Audit logs sunt importante pentru securitate, responsabilitate și investigații. Dacă apare o problemă, firma trebuie să poată vedea ce s-a întâmplat.

Totuși, logurile trebuie proiectate atent. Ele pot conține date personale și trebuie protejate. Nu trebuie păstrate la nesfârșit fără motiv. Trebuie să existe reguli privind accesul la loguri, perioada de retenție și protecția împotriva modificării.

Un log bun este util doar dacă este complet, securizat și ușor de interpretat.

Criptarea: importantă, dar nu suficientă

Criptarea este o măsură tehnică importantă, dar nu este singura măsură de securitate.

Într-o aplicație custom, criptarea poate apărea în mai multe forme:

• conexiune HTTPS;
• criptarea parolelor prin hashing sigur;
• criptarea datelor sensibile în bază;
• criptarea backupurilor;
• criptarea fișierelor stocate;
• criptarea comunicării între servicii.

Dar securitatea nu se oprește aici. Ai nevoie și de:

• roluri și permisiuni;
• autentificare puternică;
• 2FA pentru administratori;
• limitarea accesului intern;
• backup testat;
• monitorizare;
• validarea inputurilor;
• protecție împotriva atacurilor comune;
• actualizări de securitate;
• politici pentru parole;
• separarea mediilor de test și producție;
• principiul accesului minim necesar.

Criptarea protejează datele, dar nu compensează o aplicație prost proiectată.

Privacy by design și privacy by default

Protecția datelor trebuie gândită din faza de proiectare. Aceasta este ideea din spatele conceptelor privacy by design și privacy by default.

Practic, asta înseamnă că aplicația trebuie construită astfel încât să colecteze și să expună implicit cât mai puține date necesare.

Exemple practice:

• un utilizator vede doar datele proprii;
• un angajat vede doar clienții de care se ocupă;
• un manager vede rapoarte agregate, nu neapărat toate datele sensibile;
• câmpurile opționale nu sunt obligatorii fără motiv;
• datele sensibile nu apar în notificări email;
• linkurile către documente expiră;
• exporturile sunt limitate pe roluri;
• conturile inactive sunt analizate periodic;
• datele sunt șterse sau anonimizate după perioada stabilită;
• parolele nu sunt trimise niciodată pe email.

Privacy by default înseamnă că setările implicite sunt sigure. Utilizatorul nu trebuie să configureze manual protecția datelor ca să fie protejat.

DPA: contractul dintre operator și persoana împuternicită

DPA vine de la Data Processing Agreement. În română, este acordul sau contractul privind prelucrarea datelor între operator și persoana împuternicită.

Într-un proiect software, antreprenorul este adesea operatorul datelor, pentru că decide de ce și cum sunt prelucrate datele. Firma de software poate fi persoană împuternicită dacă prelucrează date în numele clientului, de exemplu prin găzduire, mentenanță, suport sau acces la baza de date.

Acest rol trebuie clarificat contractual. Un DPA ar trebui să explice:

• ce date sunt prelucrate;
• în ce scop;
• pe ce durată;
• ce categorii de persoane vizate există;
• ce obligații are furnizorul;
• ce măsuri de securitate aplică;
• dacă există subprocessatori;
• unde sunt stocate datele;
• cum se gestionează cererile persoanelor vizate;
• cum se notifică incidentele;
• ce se întâmplă cu datele la finalul contractului;
• cum se fac audituri sau verificări.

Fără DPA, relația dintre client și firma de software poate fi ambiguă, mai ales dacă furnizorul are acces la date reale.

Backup și restore: nu ai protecție reală dacă nu poți restaura

Backupul este esențial. Dar un backup care nu a fost testat este doar o speranță.

O aplicație custom care colectează date personale trebuie să aibă o strategie clară de backup:

• cât de des se face backup;
• unde se stochează;
• dacă este criptat;
• cât timp se păstrează;
• cine are acces;
• cum se restaurează;
• cât durează restaurarea;
• cum se testează periodic;
• ce se întâmplă dacă backupul conține date care au fost ulterior șterse.

Ultima întrebare este importantă. Dacă un utilizator cere ștergerea datelor, dar datele lui rămân în backupuri pentru o perioadă, trebuie să existe o politică clară. De obicei, backupurile au rol de recuperare în caz de incident și sunt păstrate o perioadă limitată, dar nu trebuie folosite ca arhivă paralelă necontrolată.

Breșe de securitate: ai un plan?

O breșă de securitate nu înseamnă doar un atac spectaculos. Poate însemna și trimiterea unui fișier către persoana greșită, acces neautorizat la conturi, expunerea unor date printr-un link public, pierderea unui laptop sau o eroare de configurare a serverului.

Într-o aplicație custom, trebuie să existe un plan pentru incidente:

• cum detectăm incidentul;
• cine este notificat intern;
• cine analizează impactul;
• ce loguri verificăm;
• cum limităm efectele;
• ce comunicăm clientului sau utilizatorilor;
• când notificăm autoritatea, dacă este cazul;
• cum documentăm incidentul;
• ce măsuri luăm pentru prevenirea repetării.

Firma de software trebuie să știe ce obligații are dacă descoperă un incident. Clientul trebuie să știe cine ia deciziile și cum se comunică.

Securitatea nu este doar prevenție. Este și reacție organizată.

Date sensibile: medical, financiar, juridic, minori

Nu toate datele au același nivel de risc. Unele proiecte software sunt mai sensibile decât altele.

O aplicație medicală, un portal pentru pacienți, un sistem juridic, o platformă financiară, o aplicație HR sau un sistem care procesează date despre minori trebuie tratate cu atenție sporită.

În aceste cazuri, este posibil să fie necesare măsuri suplimentare:

• autentificare cu doi factori;
• criptare avansată;
• audit detaliat;
• separarea strictă a rolurilor;
• DPIA;
• politici de retenție clare;
• training pentru utilizatori;
• revizuire juridică;
• contracte stricte cu furnizorii;
• testare de securitate;
• monitorizare.

Cu cât datele sunt mai sensibile, cu atât aplicația trebuie proiectată mai atent.

GDPR și AI în aplicații custom

Dacă aplicația folosește inteligență artificială, lucrurile trebuie analizate separat. AI-ul poate procesa date personale în moduri mai puțin evidente.

Exemple:

• chatbot care primește întrebări de la clienți;
• AI care clasifică documente;
• AI care extrage date din facturi;
• AI care analizează comportamentul utilizatorilor;
• AI care generează recomandări;
• AI care detectează anomalii în date.

Înainte de a integra AI, trebuie clarificat ce date sunt trimise către model, unde sunt procesate, dacă sunt stocate, dacă sunt folosite pentru antrenare, cine are acces și cum se poate limita informația transmisă.

O regulă bună este minimizarea datelor trimise către AI. Modelul trebuie să primească doar ceea ce are nevoie pentru sarcina respectivă. De asemenea, pentru decizii importante, este recomandat ca omul să păstreze controlul final.

Greșeli frecvente în proiectele software custom

1. GDPR ca etapă de final — adăugarea ulterioară a ștergerii, auditului, rolurilor și exportului poate fi costisitoare.
2. Colectarea excesivă de date — fiecare câmp în plus aduce responsabilitate în plus.
3. Consimțământul vag — un checkbox general nu rezolvă toate problemele.
4. Lipsa unei politici de retenție — datele nu trebuie păstrate la nesfârșit.
5. Lipsa audit logs — greu de investigat incidente sau abuzuri.
6. Date reale în testare — fără anonimizare sau reguli clare.
7. Lipsa DPA-ului — cu furnizorii care au acces la date.
8. Securitate redusă — pentru conturile de administrator.
9. Lipsa unui plan pentru breșe.
10. Presupunerea că firma de software „rezolvă GDPR-ul” singură — conformarea este o responsabilitate comună.

Checklist pentru antreprenori înainte de dezvoltare

Înainte să construiești o aplicație custom care colectează date, clarifică următoarele:

• Ce date personale colectăm?
• Pentru ce scop?
• Care este baza legală?
• Ce date sunt obligatorii și ce date sunt opționale?
• Cine are acces?
• Ce roluri există?
• Cum obținem și demonstrăm consimțământul?
• Cum se poate retrage consimțământul?
• Cum răspundem la cereri de acces, rectificare, ștergere sau portabilitate?
• Cât timp păstrăm datele?
• Ce date se anonimizează?
• Ce date se șterg?
• Ce date se păstrează din obligații legale?
• Există audit logs?
• Există criptare?
• Există backup și restore testat?
• Există DPA cu firma de software?
• Există subprocessatori?
• Unde sunt găzduite datele?
• Există plan de incident?
• Este nevoie de DPIA?
• Există politică de confidențialitate actualizată?
• Aplicația este proiectată cu privacy by design și privacy by default?

Acest checklist nu înlocuiește consultanța juridică, dar ajută enorm în discuția cu firma de software și cu avocatul.

Rolul firmei de software

O firmă de software serioasă nu ar trebui să spună „GDPR este problema avocatului”. Nici nu ar trebui să promită că „aplicația este 100% GDPR compliant” fără analiză juridică și operațională.

Rolul corect al firmei de software este să construiască funcționalitățile tehnice care permit conformarea:

• roluri și permisiuni;
• consimțăminte salvate corect;
• export date;
• ștergere sau anonimizare;
• audit logs;
• securitate;
• criptare;
• backup;
• limitarea accesului;
• documentarea proceselor tehnice;
• suport pentru cereri ale persoanelor vizate;
• măsuri pentru incident response.

Conformarea GDPR este rezultatul colaborării dintre antreprenor, avocat/DPO și echipa tehnică.