The wrong first question
"Are we even allowed to do this under GDPR?" is the question that stops most AI initiatives in German companies in their tracks - often before anyone has defined exactly what "this" is. The GDPR genuinely has no exception for artificial intelligence: the moment personal data is processed - customer names in a prompt, applicant data in a screening tool, training data with real personal references - the same rules apply as for any other data processing. But that's a different statement from "AI is banned." The more useful question isn't "are we allowed to?" but: at which concrete points does legal risk actually arise - and for whom, the company or its customers?
Friction point 1: the legal basis for training and use
Any processing of personal data needs a legal basis under Art. 6 GDPR - for AI, that's usually "legitimate interest" (Art. 6(1)(f)), the basis most providers and companies rely on. The European Data Protection Board (EDPB) published a closely watched opinion on this in December 2024: legitimate interest can be a valid basis, but only after a genuine case-by-case balancing test - necessity and proportionality have to be actually assessed, a blanket invocation isn't enough. For companies, that means: if you use a vendor's AI tool and that vendor trained it on personal data, you should know on what basis that happened - especially because, per the EDPB, unlawfully collected training data can undermine the lawfulness of later use if the model wasn't effectively anonymised.
Day-to-day reality: ChatGPT & co.
For internal use - employees using ChatGPT, Claude or Copilot in daily work - the picture is easier to grasp but just as often unresolved in practice: without a data processing agreement, without a disabled training opt-out for confidential inputs, and without a binding internal policy, customer data or draft contracts sooner or later end up in a tool that was never cleared for them. That's the part of the topic our How-to-AI module "Data Protection & AI" already covers as a practical checklist - this article deliberately goes a step further, into the strategic and customer-facing questions behind it.
Friction point 2: automated decisions affecting customers
Art. 22 GDPR prohibits decisions that are based solely on automated processing and produce legal or similarly significant effects for a person - with narrow exceptions (contract necessity, legal authorisation, explicit consent). This hits the customer-facing side of a business directly, the moment AI stops merely assisting internally and starts effectively deciding about people:
- Automated credit or creditworthiness scoring that materially drives a contract decision
- AI-assisted pre-screening of job applications that automatically filters out candidates
- Dynamic pricing that automatically assigns different individual customers different terms
- Automated risk classification of customers, for example in insurance or financial services
There's a ruling here that many companies underestimate. On 7 December 2023, the European Court of Justice clarified in the so-called SCHUFA case (C-634/21) that the automated calculation of a score alone can already qualify as an "automated decision" under Art. 22 GDPR - specifically when that score substantially predetermines a downstream decision made by a third party (such as a bank). A human who formally rubber-stamps the algorithm's output isn't enough to fall outside the article's scope - what's required is a substantive, independent review with genuine authority to overrule it. For any company using AI to pre-score customers or applicants, that's one of the most practically important questions: does a human genuinely decide in the end - or only on paper? Anyone whose use case also touches Annex III of the EU AI Act (for example HR selection or creditworthiness assessment) picks up additional obligations from a second regulatory regime starting in August 2026, running in parallel with the GDPR.
Friction point 3: when data leaves the EU
Most leading AI providers process data in the US. Since July 2023, the EU-US Data Privacy Framework (DPF) has allowed data transfers to certified US providers on the basis of an EU Commission adequacy decision - provided the specific provider is actively listed and its certification actually covers the relevant type of data. Even so, legal certainty is only partial: the US CLOUD Act still lets US authorities compel US companies to hand over data regardless of where it's stored, and EU data residency alone doesn't protect against that. Data protection experts consider it plausible that the DPF will eventually end up before the ECJ, just like its two predecessors (Safe Harbor, Privacy Shield). For companies handling sensitive customer or HR data, the practical takeaway is: if you rely on a US provider today, you should know what happens if that provider's legal basis collapses tomorrow - not find out when it actually does.
Friction point 4: the obligation most companies only discover once the regulator calls
Art. 35 GDPR requires a data protection impact assessment (DPIA) whenever a processing activity is likely to result in a high risk to people's rights and freedoms - new technologies such as AI, profiling or biometric systems are a typical trigger. In practice, this is exactly where AI projects most often get caught out: a company rolls out an AI tool because it visibly saves time - and only weeks later, usually after an inquiry from the data protection authority, realises a DPIA should have been carried out first. The obligation sits with the company as controller, not with the tool vendor as processor. If personal health, financial or HR data runs through an AI model, that assessment belongs before the rollout, not after.
The wishful thinking behind "anonymised"
A common argument goes: "Our data is anonymised, so GDPR doesn't apply." The EDPB's December 2024 opinion spells out when an AI model actually counts as anonymous: it must be reasonably unlikely both to identify the individuals whose data was used for training and to extract that data from the model through targeted queries - and that has to be assessed case by case, not assumed. For large language models trained on extensive, often publicly scraped data, that bar is harder to clear in practice than marketing language tends to suggest. That collides with a second structural problem: the right to erasure (Art. 17 GDPR). A model, once trained, doesn't "forget" individual data points on request - unlike a database row, a learned pattern can't simply be deleted without retraining the model. For companies training or fine-tuning their own models (not classic RAG setups, where the source data itself stays untouched), that's a point worth thinking through early.
Is the GDPR "AI-ready"? The debate playing out live
German industry is unambiguous on this point: in a Bitkom survey, 97 percent of companies surveyed cited high bureaucratic burden from the GDPR, 77 percent said it holds back the digitalisation of their business model, and 63 percent fear it is endangering AI development in Europe. 79 percent are calling for fundamental reform at EU level, 71 percent want the rules adapted to the AI era. That's one side of the debate - and it has grown louder since the EU Commission itself responded.
On 19 November 2025, the EU Commission presented a "Digital Omnibus" package aimed specifically at easing GDPR and AI Act obligations for AI applications: processing personal data for the "development and operation of AI models" should generally be allowed on the basis of legitimate interest, pseudonymisation should benefit more from being treated closer to full anonymisation, and data protection impact assessments should be simplified and better harmonised. The timeline shows just how much this is still in motion: after criticism from the EDPB and the European Data Protection Supervisor in January and February 2026, Parliament and Council reached a provisional political agreement on the package on 7 May 2026 - but it is not yet binding law until formally adopted and published in the Official Journal. Until then, today's GDPR rules apply unchanged.
The genuinely interesting part of this debate, though, isn't industry versus regulators - it's that Germany's own data protection conference (DSK) called for reform on 18 December 2025, with a different approach than the Commission: dedicated, clearly defined legal bases for the development, training and operation of AI models written directly into the GDPR - instead of a blanket reliance on legitimate interest with an opt-out. Alongside that, a second proposal particularly relevant for companies: stronger manufacturer liability for IT vendors, requiring them to build data protection into their products from the start - rather than leaving companies that merely deploy a tool to carry the full legal responsibility for how it was built, with no influence over its design. Privacy activist Max Schrems (noyb) criticised the Commission's proposal from a third angle on 16 December 2025: a blanket opt-out for training AI on customer data is legally unclear and, in the end, commercially risky too - what's needed instead are concrete, binding requirements, for example on data cleaning, deletion concepts, and retraining when results turn out to be problematic.
Three sides, three different diagnoses - but one shared conclusion: even the institutions that enforce the GDPR consider today's legal framework for AI not fully thought through. That's the real insight behind the "AI-ready" question: it isn't about whether the GDPR fundamentally blocks AI - it doesn't - but about the fact that the AI-specific questions (training on large datasets, model anonymity, responsibility split between vendor and deployer) simply weren't anticipated back in 2018 and are now being retrofitted. Anyone planning an AI initiative today is planning against a legal framework that will likely still shift over the next 12 to 24 months.
The honest answer: does the GDPR slow down or block AI rollouts?
Block: rarely. Not one case in this article describes a blanket prohibition of AI - each describes a condition under which a specific use of AI is, or isn't, permitted. Slow down: yes, but less often because of the statutory text itself than because of what companies don't know before they start. The pattern behind most of the problematic cases we see in practice (like the insurance broker example mentioned earlier, who rolled out an AI tool for claims assessment without realising he was already running health data through a model) is almost always the same: legal basis, data flow and DPIA obligation weren't clarified before the rollout, only once the regulator asked. Companies that think through these questions from the start aren't actually slower than the competition in practice - they just avoid the expensive rebuild that follows when a live system has to be made compliant after the fact.
What this means for your AI rollout
These four friction points add up to a screening framework worth working through before budget goes into implementation - not as an exhaustive checklist, but as a map of the questions that need a solid answer:
- Clarify the legal basis before the first feature gets built: on what basis (contract, consent, legitimate interest) does the specific processing run - and does that basis actually hold up in production, not just in testing?
- Check customer-facing automation for Art. 22 exposure: does an AI system effectively decide about a person in the end, even if someone formally still "approves" it?
- Map data flows to third-party vendors: what data leaves the EU, on what legal basis, and what happens if that basis collapses in the next few years?
- Check DPIA obligations before the rollout, not after - especially with sensitive data categories or larger-scale automation, this check is worth doing before a system goes live.
- Keep an active eye on the shifting legal framework: the Digital Omnibus will likely change the picture in the coming months - plan your architecture to absorb that shift, rather than building against today's rules as if they were fixed.
None of these points can be settled with a generic answer - it depends on the specific processing, the vendors involved, and the risk class of the data concerned, and none of this replaces individual legal advice. What can be said clearly: these questions belong at the start of an AI initiative, in the assessment of processes and ideas - not as a compliance afterthought at the end. That's exactly the part we build into the AI Opportunity Scan, before any implementation decision is made.