As artificial intelligence becomes embedded in everyday business operations, one of the most important practical trends is the growing overlap between GDPR enforcement and AI governance. GDPR continues to apply whenever personal data is processed in the development, fine-tuning, deployment or operation of an AI system and the EU AI Act does not change that.
It’s Not About Whether Something Is Labelled “AI”
For organizations using Azure AI Foundry, Anthropic Claude, OpenAI or another hosted model, the key GDPR question is not what the provider calls the product or whether the model is “pre-trained”. GDPR cares less about the label and more about what happens to the personal data. And while the Digital Omnibus has now been formally adopted and signed, the relevant provisions may have different dates of application. Until each applicable amendment takes effect, organizations must continue to apply the GDPR as currently in force. In other words, the label may change; the GDPR homework remains.
When Is an AI Model Anonymous?
The EDPB makes one thing clear: a model trained on personal data is not automatically anonymous. Anonymity must be assessed case by case, including whether personal data can be extracted from the model or revealed through queries.
That is a high bar. “It contains weights, not a database” is not proof of anonymization.
Suppliers should therefore be able to provide evidence of extraction and memorization testing, adversarial or red-team testing, training-data filtering and deduplication, and controls against data leakage for the specific model and deployment in question.
Anonymization is an evidence-based assessment, not a contractual promise.
Lawful Basis for AI Processing
The EDPB confirms that legitimate interest can support AI development or deployment but it is not a shortcut. Controllers still need to show a clear purpose, necessity and fair balance. “Improving our AI product” is too vague. A defensible purpose might be detecting fraud or reducing unsafe outputs, backed by evidence that the data is genuinely necessary and proportionate. The assessment should also consider individuals’ expectations, the source and sensitivity of the data, scale and duration, objection rights, and safeguards such as filtering, pseudonymization, access controls and retention limits.
“We have a legitimate interest” is the beginning of the analysis, not the end.
Unlawful Training Data Can Create Continuing Risk
If personal data was unlawfully used to train a model, the problem may not end with training. The EDPB indicates that corrective measures could include deleting the unlawfully processed data and, depending on the circumstances, potentially the model itself. Article 17 erasure rights may also apply.
The position is different only where the model no longer processes personal data and has been properly anonymised. And once new personal data enters through prompts, files, logs or outputs, GDPR is back in the room.
AI Service-Provider Roles
For hosted AI, assess the provider’s role activity by activity. A DPA calling a vendor a “processor” does not settle the question if the vendor uses the data for its own purposes, such as model development.
Prompts, Outputs and Logs
Personal data does not stop at the prompt. It can appear in uploads, outputs, chat history, logs, telemetry, human reviews, evaluation datasets, embeddings and audit records. Map the whole journey from input and inference through storage, monitoring and review to deletion and downstream use. The prompt is only the beginning of the data trail.
Interaction With the AI Act
GDPR and the AI Act are partners, not substitutes:
- GDPR governs personal-data processing and individuals’ rights.
- The AI Act adds requirements based on the AI system, its risk and the roles involved.
- AI Act compliance does not create a GDPR lawful basis.
- GDPR compliance does not, by itself, satisfy the AI Act.
What to Question in Supplier Assessments
Treat claims such as these as claims, not conclusions:
- “The model is anonymous.” Show the testing.
- “We don’t store prompts.” What about logs, backups and monitoring?
- “We’re only a processor.” What are you doing with the data independently?
- “Customer data isn’t used for training.” What about feedback, evaluation and human review?
- “Data stays in the EU.” What about remote access and sub-processors?
- “The AI Act covers this.” It doesn’t replace GDPR.
A defensible assessment should cover the provider’s DPA, data-use policy, sub-processors, retention, transfers, security controls, training commitments, deletion process and privacy-testing evidence.
The Practical Takeaway
The Digital Omnibus on AI is no longer merely a proposal. The final regulation was adopted in 2026 and amends the EU AI Act and related legislation. However, its provisions do not all apply at the same time: the regulation sets different application dates and transitional arrangements, including postponed dates for certain high-risk AI obligations.
The practical message remains simple: AI does not put GDPR on hold. Organisations should classify roles and processing activities, establish the relevant lawful basis, test anonymisation claims, and know where personal data goes including through cloud infrastructure, AI providers and subprocessors.
The technology may be new. The GDPR questions are not.
If you have any questions or would like help navigating the GDPR implications of AI, please contact Compleye at info@compleye.io. We are here to help you make sense of the rules and turn them into practical steps.
Frequently Asked Questions
Does the GDPR still apply if a company uses a hosted AI tool like Claude, OpenAI or Azure AI Foundry?
Yes. GDPR applies whenever personal data is processed at any stage of an AI system’s lifecycle, whether that’s development, fine-tuning, deployment or day-to-day use. The AI Act doesn’t remove or replace this obligation.
How do I make my AI startup GDPR compliant?
The core requirements are the same as any GDPR compliance program — a documented lawful basis, mapped data flows, and evidence of safeguards — but AI adds specific complications, like proving a model is genuinely anonymized rather than assuming it, and accounting for personal data across prompts, logs, and outputs rather than just the prompt itself. Compleye helps AI companies build this out rather than piecing it together from generic guidance.
Do I need a Data Protection Officer (DPO) for an AI company?
Whether a DPO is mandatory depends on the scale and nature of your processing, but AI companies increasingly need dedicated GDPR expertise regardless of the legal threshold, because AI processing raises questions — lawful basis, vendor role assessment, training data provenance — that a generalist compliance function often isn’t equipped to answer.
What's the difference between GDPR compliance and EU AI Act compliance — do I need both?
Yes, both apply, and one doesn’t substitute for the other. GDPR governs personal data processing and individual rights; the AI Act adds separate obligations based on a system’s risk classification. A compliant AI Act filing does not establish a GDPR lawful basis, and GDPR compliance alone doesn’t satisfy AI Act requirements — most AI companies need a combined framework, not two disconnected checklists.
How much does GDPR compliance cost for an AI/SaaS company?
Cost depends heavily on scope — how much personal data your system touches, whether you’re training models, how many vendors and sub-processors are in your chain — but the more efficient path for most SaaS companies is a structured platform-plus-expert approach rather than ad hoc legal hours, since AI-specific issues (anonymization evidence, vendor role assessments) tend to recur and are reusable across audits.
