Data privacy in the age of AI: GDPR and LGPD in practice
Legal basis, minimization, anonymization, impact assessments and model-vendor clauses — what changes when AI enters the workflow.
*Sixth article in our series on enterprise AI, legacy integration and information governance.*
Executive summary
There is no "special AI regime" that suspends data protection rules: GDPR and LGPD apply in full, and AI simply amplifies the scale and speed of processing. What changes in practice is the difficulty of answering the same old questions — what is the purpose, what is the legal basis, which data is truly necessary, and how does a data subject exercise their rights — once data flows through indexes, prompts, histories and chained vendors.
The four questions behind any use case
- 1.Purpose. What exactly does this system process personal data for? "Improving the experience" is not a purpose; "suggesting a support reply based on customer history" is.
- 2.Legal basis. Contract performance, legal obligation, legitimate interest or consent — and the chosen basis must also support the AI use, not just the original collection.
- 3.Minimization. What is the smallest data set that produces the same result? Sending the full record when three fields suffice is free exposure.
- 4.Data subject rights. If someone requests access, correction or erasure, can the company locate that data in indexes, prompt logs and vendor histories?
Anonymization, pseudonymization and the honest middle ground
True anonymization is irreversible — and often destroys the data's usefulness. Pseudonymization (replacing identifiers with codes) keeps utility and lowers risk, but the data remains personal and in scope.
The practical pattern that works: mask direct identifiers at the edge, before sending to the model, keeping the re-identification key inside the company perimeter. That reduces personal data in transit without pretending the problem disappeared.
When an impact assessment is required
A DPIA stops being optional when the use case combines any of these factors:
| Factor | AI example |
|---|---|
| Automated decision with significant effect | Credit screening, résumé shortlisting |
| Sensitive data | Health, biometrics, children's data |
| Scale and monitoring | Analysis of employee communications |
| New technology applied to personal data | Assistant with access to customer history |
Vendors: what must be in the contract
- Each party's role (controller and processor) and the authorized purpose.
- Express prohibition on using content for training.
- Subprocessor list, with advance notice of change.
- Processing region and international transfer mechanism.
- Retention period, full export and certified deletion at termination.
- Incident notification within a window compatible with your own obligations.
The operational detail of that path is covered in Where what your employees type into AI ends up.
Automated decisions require explanation
When a system supports or makes a decision affecting people, the data subject may request review and explanation. That has architectural consequences: you must store what went in, what came out, which model version answered, and who reviewed it. Without that record, the obligation cannot be met — the subject of the next article in this series, on audit trails.
What to do on Monday
- Build an inventory of AI use cases with a declared purpose and legal basis for each.
- Rank them by risk and decide which require an impact assessment before proceeding.
- Review active AI contracts against the clause list above.
- Test end to end how the company would handle an erasure request today when AI-processed data is involved.
Conclusion
Privacy is not the brake on an AI program; it is what makes the program defensible. Companies that declare purpose, minimize data and keep a trail scale use cases faster — because they do not have to stop everything each time someone asks whether that was allowed.
Further reading
Engineering track:
- PII detection and masking in AI pipelines — the technical deep dive on this topic.