GDPR pe înțelesul tuturor: checklist practic de confidențialitate pentru aplicații

La HashCoreAI construim aplicații iOS, Android, Flutter și web pentru clienți, plus propriile noastre aplicații și jocurile gratuite din browser din „Neon Arcade". Aproape de fiecare dată când lansăm ceva, apare aceeași întrebare de la proprietarul produsului: „Ce trebuie să fac, de fapt, pentru GDPR?". Răspunsul scurt este că nu trebuie să devii avocat — dar trebuie să înțelegi ce date atinge aplicația ta și să fii onest cu utilizatorii despre asta. Acest articol traduce GDPR în limbaj de proprietar de aplicație și se termină cu un checklist concret.

Acest articol are scop educativ și nu constituie consultanță juridică. Pentru situația ta specifică, consultă un avocat sau un specialist în protecția datelor.

Ce date personale colectează de fapt aplicația ta

Prima surpriză pentru mulți proprietari: „nu colectăm date" e aproape întotdeauna fals. Date personale înseamnă orice informație despre o persoană identificabilă — iar asta include mult mai mult decât numele și emailul. Iată ce atinge tipic o aplicație mobilă sau web, chiar și una simplă.

Categorie	Exemple concrete	De unde vine
Identificatori de cont	Email, nume, parolă (hash), ID utilizator	Înregistrare / autentificare
Identificatori de dispozitiv	Advertising ID (IDFA/GAID), device ID, IP	SDK-uri de analytics și reclame
Date de utilizare	Ecrane vizitate, evenimente, durata sesiunii	Analytics (Firebase, etc.)
Date tehnice	Model dispozitiv, OS, limbă, crash logs	SDK-uri de diagnostic
Localizare	GPS precis sau aproximativ (din IP)	Permisiuni / rețea
Conținut generat	Mesaje, poze, scoruri, achiziții	Funcționalitatea aplicației

Chiar și un joc simplu de browser care afișează reclame prin AdMob sau AdSense plasează cookie-uri și transmite un advertising ID către rețeaua publicitară. Asta înseamnă procesare de date personale, deci GDPR se aplică. Regula practică: dacă integrezi orice SDK terț, presupune că date personale părăsesc aplicația ta până dovedești contrariul.

Temei legal și consimțământ: nu e același lucru

GDPR cere ca fiecare procesare de date să aibă un temei legal. Cele relevante pentru aplicații sunt:

Executarea contractului — ai nevoie de email ca să creezi contul și să livrezi serviciul. Nu îți trebuie consimțământ separat pentru asta.
Interesul legitim — de exemplu prevenirea fraudei sau securitatea de bază. Trebuie documentat și echilibrat cu drepturile utilizatorului.
Consimțământul — necesar pentru lucruri care nu sunt strict necesare: reclame personalizate, analytics non-esențial, tracking între aplicații.

Greșeala clasică este să ceri un singur „Accept" global care acoperă tot. Consimțământul valid trebuie să fie liber, specific, informat și ușor de retras — la fel de ușor cum a fost de dat. Pentru reclame și tracking pe dispozitive iOS, ai nevoie și de App Tracking Transparency (ATT), separat de consimțământul GDPR. Pe web, dacă servești utilizatori din UE cu AdSense, ai nevoie de un banner de consimțământ conform (CMP), nu doar de o bară care spune „folosim cookie-uri".

O politică de confidențialitate reală (nu un template gol)

O politică de confidențialitate copiată de pe internet și lăsată nemodificată e mai rea decât niciuna: declară lucruri false despre produsul tău. O politică reală răspunde, în limbaj clar, la întrebări concrete:

Cine ești — operatorul de date, cu o adresă de contact reală.
Ce date colectezi — categoriile de mai sus, mapate pe aplicația ta.
De ce și pe ce temei — scopul fiecărei categorii și temeiul legal.
Cu cine le împarți — lista de procesatori: Firebase, AdMob, un furnizor de plăți, etc.
Cât timp le păstrezi — perioade de retenție concrete, nu „atât cât e necesar".
Ce drepturi are utilizatorul — acces, rectificare, ștergere, portabilitate, opoziție.
Cum le exercită — un email sau un buton în aplicație care chiar funcționează.

Politica trebuie să fie accesibilă înainte de descărcare (link în App Store / Google Play) și din interiorul aplicației, nu îngropată într-un PDF.

Ștergerea contului în aplicație: acum obligatorie

Aceasta este cea mai des trecută cu vederea cerință din ultimii ani. Atât Apple cât și Google cer ca orice aplicație care permite crearea unui cont să ofere și o cale de a-l șterge — din interiorul aplicației, nu doar trimițând un email. La HashCoreAI tratăm asta ca pe o cerință de lansare, nu ca pe un „nice to have".

Câteva detalii practice pe care le verificăm de fiecare dată:

Opțiunea de ștergere trebuie să fie ușor de găsit, de obicei în setări sau profil — nu ascunsă după trei meniuri.
Trebuie să șteargă efectiv datele, nu doar să dezactiveze contul. Dacă o parte se păstrează din motive legale (de ex. facturi), explică ce și de ce.
Dacă oferi un link web pentru ștergere (acceptat de Google în anumite cazuri), trebuie să fie clar și accesibil.
Ștergerea trebuie să se propage și la procesatorii terți, unde e posibil.

SDK-uri terțe și rețele de reclame: dezvăluie tot

Fiecare SDK pe care îl adaugi e un potențial transfer de date. AdMob și AdSense plasează cookie-uri și folosesc advertising ID-uri; un SDK de analytics trimite evenimente pe servere externe; un SDK de crash reporting urcă date de dispozitiv. Toate acestea trebuie:

Inventariate — ține o listă a fiecărui SDK și ce date atinge.
Declarate în politica de confidențialitate și în formularele de platformă (App Privacy „nutrition label" la Apple, Data Safety la Google).
Controlate prin consimțământ — SDK-urile de reclame personalizate nu ar trebui să pornească înainte ca utilizatorul din UE să accepte.

O notă specifică pentru jocurile noastre: jocurile cu temă crypto din portofoliu sunt simulatoare cu monede virtuale, fără valoare reală. Din perspectiva datelor, ele se comportă exact ca orice alt joc casual — colectează aceiași identificatori prin SDK-urile de reclame, și exact acolo se concentrează obligațiile GDPR.

Minimizarea datelor și retenția

Două principii care reduc dramatic riscul, pentru că nu poți pierde sau folosi greșit date pe care nu le ai:

Minimizare — cere doar ce ai nevoie acum. Nu colecta data nașterii „pentru orice eventualitate". Fiecare câmp trebuie să aibă un scop.
Retenție — definește cât timp păstrezi fiecare categorie și șterge automat după. Logurile pot fi 30–90 de zile; datele de cont, cât durează contul plus o fereastră scurtă; backup-urile, conform ciclului tehnic.

Checklistul practic GDPR

Am cartografiat fiecare categorie de date personale pe care o atinge aplicația.
Pentru fiecare procesare am identificat și documentat un temei legal.
Consimțământul este granular, opțional și la fel de ușor de retras cât de dat.
Pe iOS am implementat ATT; pe web am un CMP conform pentru AdSense.
Politica de confidențialitate reflectă produsul real și e accesibilă înainte și după instalare.
Există ștergere de cont în aplicație, ușor de găsit, care chiar șterge datele.
Am un inventar al tuturor SDK-urilor terțe și ce date transmit.
Am completat App Privacy (Apple) și Data Safety (Google) corect.
SDK-urile de reclame personalizate nu pornesc înainte de consimțământ.
Colectez doar datele necesare și am perioade de retenție definite.
Am o cale clară prin care utilizatorii își exercită drepturile.

Dacă lansezi sau actualizezi o aplicație și vrei ca partea de confidențialitate să fie făcută corect de la început — de la formularele de platformă până la ștergerea contului în aplicație — putem ajuta. Scrie-ne la contact@hashcoreai.com sau aruncă o privire la jocurile noastre gratuite pe games.hashcoreai.com.

At HashCoreAI we build iOS, Android, Flutter and web apps for clients, plus our own apps and the free browser games in "Neon Arcade." Almost every time we ship something, the same question comes from the product owner: "What do I actually have to do for GDPR?" The short answer is that you don't need to become a lawyer — but you do need to understand which data your app touches and be honest with users about it. This article translates GDPR into app-owner language and ends with a concrete checklist.

This article is educational and is not legal advice. For your specific situation, consult a lawyer or a data protection specialist.

What personal data your app actually collects

The first surprise for many owners: "we don't collect data" is almost always false. Personal data means any information about an identifiable person — and that's far more than name and email. Here's what a typical mobile or web app touches, even a simple one.

Category	Concrete examples	Where it comes from
Account identifiers	Email, name, password (hash), user ID	Sign-up / login
Device identifiers	Advertising ID (IDFA/GAID), device ID, IP	Analytics and ad SDKs
Usage data	Screens viewed, events, session length	Analytics (Firebase, etc.)
Technical data	Device model, OS, language, crash logs	Diagnostics SDKs
Location	Precise GPS or coarse (from IP)	Permissions / network
Generated content	Messages, photos, scores, purchases	App functionality

Even a simple browser game that shows ads through AdMob or AdSense drops cookies and passes an advertising ID to the ad network. That is processing of personal data, so GDPR applies. The practical rule: if you integrate any third-party SDK, assume personal data leaves your app until you prove otherwise.

Lawful basis and consent are not the same thing

GDPR requires every processing of data to have a lawful basis. The ones relevant to apps are:

Performance of a contract — you need the email to create the account and deliver the service. You don't need separate consent for that.
Legitimate interest — for example fraud prevention or basic security. It must be documented and balanced against the user's rights.
Consent — required for things that are not strictly necessary: personalised ads, non-essential analytics, cross-app tracking.

The classic mistake is a single global "Accept" that covers everything. Valid consent must be freely given, specific, informed and as easy to withdraw as it was to give. For ads and tracking on iOS you also need App Tracking Transparency (ATT), which is separate from GDPR consent. On the web, if you serve EU users with AdSense, you need a compliant consent banner (a CMP), not just a strip that says "we use cookies."

A real privacy policy (not an empty template)

A privacy policy copied from the internet and left unedited is worse than none: it makes false statements about your product. A real policy answers, in plain language, concrete questions:

Who you are — the data controller, with a real contact address.
What data you collect — the categories above, mapped to your app.
Why and on what basis — the purpose of each category and the lawful basis.
Who you share it with — the list of processors: Firebase, AdMob, a payment provider, and so on.
How long you keep it — concrete retention periods, not "as long as necessary."
What rights the user has — access, rectification, deletion, portability, objection.
How they exercise them — an email or an in-app button that actually works.

The policy must be accessible before download (a link in the App Store / Google Play) and from inside the app, not buried in a PDF.

In-app account deletion: now mandatory

This is the most commonly overlooked requirement of recent years. Both Apple and Google require any app that lets you create an account to also offer a way to delete it — from inside the app, not just by emailing support. At HashCoreAI we treat this as a launch requirement, not a "nice to have."

A few practical details we check every time:

The deletion option must be easy to find, usually in settings or profile — not hidden three menus deep.
It must actually delete the data, not just deactivate the account. If something is retained for legal reasons (e.g. invoices), explain what and why.
If you offer a web link for deletion (accepted by Google in certain cases), it must be clear and reachable.
Deletion should propagate to third-party processors wherever possible.

Third-party SDKs and ad networks: disclose everything

Every SDK you add is a potential data transfer. AdMob and AdSense set cookies and use advertising IDs; an analytics SDK sends events to external servers; a crash-reporting SDK uploads device data. All of this must be:

Inventoried — keep a list of every SDK and the data it touches.
Declared in the privacy policy and in the platform forms (Apple's App Privacy "nutrition label", Google's Data Safety).
Gated by consent — personalised ad SDKs should not start before an EU user accepts.

A specific note about our games: the crypto-themed games in our portfolio are simulators using virtual coins with no real-world value. From a data standpoint they behave exactly like any other casual game — they collect the same identifiers through ad SDKs, and that's precisely where the GDPR obligations sit.

Data minimisation and retention

Two principles that dramatically reduce risk, because you can't lose or misuse data you never collected:

Minimisation — collect only what you need now. Don't collect date of birth "just in case." Every field must have a purpose.
Retention — define how long you keep each category and delete automatically afterwards. Logs might be 30–90 days; account data, for the life of the account plus a short window; backups, per the technical cycle.

The practical GDPR checklist

I have mapped every category of personal data the app touches.
For each processing I have identified and documented a lawful basis.
Consent is granular, optional and as easy to withdraw as to give.
On iOS I implemented ATT; on the web I have a compliant CMP for AdSense.
The privacy policy reflects the real product and is accessible before and after install.
There is in-app account deletion, easy to find, that actually deletes the data.
I have an inventory of every third-party SDK and the data it transmits.
I filled out App Privacy (Apple) and Data Safety (Google) correctly.
Personalised ad SDKs don't start before consent.
I collect only the data I need and have defined retention periods.
I have a clear path for users to exercise their rights.

If you're launching or updating an app and want the privacy side done right from the start — from the platform forms to in-app account deletion — we can help. Write to us at contact@hashcoreai.com or take a look at our free games at games.hashcoreai.com.