GDPR and AI: the questions your regulator will ask

Many leadership teams treat GDPR compliance for their AI projects as an afterthought checkbox, addressed once the tool is chosen and the pilot is already running. That’s the reverse of what a regulator expects. GDPR makes no exception for artificial intelligence: every processing of personal data by an AI system must meet the same requirements for legal basis, minimization, and purpose limitation as any other processing. Here are the precise questions a data-protection audit would ask about an AI project — and why it’s better to answer them before, not after.

GDPR doesn’t make an exception for AI

This is the most widespread misunderstanding in the boardroom: the idea that an innovative AI use case earns some kind of regulatory grace period while the law catches up. It doesn’t. An AI system processing candidate, employee, or customer data is personal-data processing like any other, fully subject to GDPR, regardless of how sophisticated the underlying technology is.

The only real specificity of AI, from a regulator’s point of view, is that it makes certain questions harder to document — particularly the traceability of an automated decision and the exact provenance of the data used to train or configure the system. Those are precisely the points an audit focuses on.

The questions your regulator will ask

A structured audit of an AI system generally follows the same logic, regardless of sector:

1. What is the legal basis for the processing? Legitimate interest, consent, contract performance: the legal basis needs to be identified before deployment, not reconstructed after the fact to justify a use already in place.
2. Is the minimization principle respected? Does the system process only the data strictly necessary for its stated purpose, or a broader set “just in case” — a common practice with generative AI tools, and a particularly risky one.
3. Has a data protection impact assessment (DPIA) been carried out? Whenever processing poses a high risk to individuals’ rights — frequent with scoring or automated-decision systems — a documented DPIA is expected, not optional.
4. What does the subprocessor chain look like? Who hosts the model, where are the servers located, does data transit through a country outside the EU — every link in that chain needs to be identified and contractually governed.
5. How are individuals’ rights guaranteed? Right of access, rectification, objection to an automated decision: the system needs to make these concretely actionable, not just theoretically covered in a privacy policy.

Where AI projects most often fall short

In practice, the most frequent failures aren’t a matter of bad faith but a lack of anticipation:

• Shadow AI — teams using consumer-grade AI tools not vetted by IT or the DPO to process sensitive data, with no visibility or control from leadership.
• Data feeding a third-party model’s training — depending on a vendor’s contract terms, customer or employee data can unintentionally contribute to improving an external model.
• No defined retention period — an AI system that accumulates conversation or processing history with no explicit purge policy violates the storage-limitation principle from day one.
• Missing documentation on decision logic — when a system contributes to a decision affecting a person (an application, a credit decision, an evaluation), the lack of an understandable explanation of that logic is one of the most frequently sanctioned control points.

A GDPR-compliant AI project isn’t a slower AI project. It’s an AI project where every design decision can be justified the day someone asks you to.

What a compliant diagnostic changes from the design stage

The best way to avoid these pitfalls isn’t to fix them after deployment, but to address them at the design stage. A diagnostic built on a push model — the client sends a data export, and never grants access to internal systems — mechanically reduces the risk surface: no integration into an HRIS, no standing access to company systems, a data perimeter strictly limited to the file transmitted. An on-premise deployment, for its part, guarantees that data never leaves the company’s perimeter and is never used to train a third-party model.

These architectural choices aren’t incidental sales arguments. They are, very concretely, the answers to questions 3 and 4 above — and they need to be settled before the first byte of data is processed, not negotiated afterward.

The regulatory calendar you need to know

On top of GDPR, the EU AI Act now adds specific documentation obligations for high-risk uses starting August 2026 — December 2027 for entities covered by the Omnibus mechanism. The two frameworks overlap substantially: rigorous GDPR documentation is a solid foundation for meeting AI Act requirements, provided both are anticipated together rather than each deadline handled in a scramble.

On top of that, companies above 300 employees face a works-council (CSE) consultation requirement under the triennial GEPP agreement whenever a transformation touches the organization of work — which is almost always the case for a significant AI deployment. Compliance documentation already in place turns that consultation into a factual discussion rather than a ground for suspicion.

GDPR compliance for an AI project can’t be patched in afterward with a well-written charter. It gets built into the system’s architecture, before the first byte of data is processed.