GDPR and Artificial Intelligence: How to Prove Your Controls

This article is operational guidance and does not replace legal advice from your DPO or counsel.

Table of contents

• When the GDPR applies to an AI system
  • What belongs in the scope
  • Turning an assertion into verifiable evidence
• Coordinating the GDPR and the EU AI Act with traceable evidence
• Legal bases, purposes and data minimisation across lifecycle phases
  • Five separate checks to document
• Transparency, profiling and automated decision‑making
  • When Article 22 matters
  • Demonstrable human review
• DPIA and treatment register: minimum fields and review cadence
  • Timing and re‑assessment
  • Minimal register fields
• Real cases that highlight enforcement risks
• Common mistakes and a pre‑audit checklist
  • Distinguishing exceptions, findings and incidents
  • Seven‑question checklist
• FAQs: roles, anonymisation, chatbots and model updates

When the GDPR applies to an AI system

The weakest audit claim is: “the model does not use personal data, so GDPR doesn’t apply.” If no one has logged what inputs enter the system, what logs are retained, or what inferences the model produces, the auditor will mark the relevant control as “not demonstrated.”

What belongs in the scope

Personal data is any information relating to an identified or identifiable person. “Processing” is broader than ingestion: it includes training, testing, inference, outputs, retention and logs. Examples of items that bring an AI system into scope:

• CVs or candidate data used to train or test hiring models
• Support tickets, prompts or chat logs that include customer identifiers
• Inference outputs that create scores or profiles linked to people
• Logs that contain internal identifiers for employees or contractors

The EU supervisory authorities stress that GDPR and the EU AI Act must be applied together where an AI system uses personal data. An AI Act classification (high/low risk) does not replace the privacy verification of purpose, legal basis, categories of data, roles, retention, security, DPIA and registration in the record of processing activities.

Practical rule: classifying a system as low risk under the AI Act does not automatically eliminate GDPR obligations. You must be able to prove why data are not personal or why residual risk is acceptable.

Turning an assertion into verifiable evidence

Instead of an unsupported statement, maintain a short applicability sheet for every AI system. The sheet should include:

• What data sources are used and how they were sampled
• A dated, signed statement by the DPO or responsible person
• A re‑identification test when data have been anonymised
• A link to the dataset and model version used in the assessment

Examples of scenarios and minimal evidence:

• Recruitment model using CVs: legal basis, transparency notices, DPIA
• Training on internal logs: documented legal basis and scope of consent or legitimate interest
• Model trained on anonymised data: dated anonymisation methodology and re‑identification test
• Outputs that produce person‑level scores: accuracy checks, rectification procedures and access logs
• System producing materially significant decisions: human intervention evidence and appeal channels

A missing applicability sheet makes even a correct conclusion indefensible.

Coordinating the GDPR and the EU AI Act with traceable evidence

The AI Act addresses risks and obligations specific to AI; the GDPR protects the rights and freedoms of individuals. Treating these as alternatives creates incoherent dossiers: an AI inventory disconnected from ROPA, DPIA and subject rights is not sufficient.

Operationally connect the AI inventory to privacy documentation and ensure each artefact can be verified. Minimum elements linking the two frameworks include:

• A dated system sheet (purpose, provider, data processed, model version)
• A documented AI Act category with rationale and approver signature
• Phase‑specific GDPR legal bases and a DPIA where required
• Test reports for accuracy and bias tied to a model/dataset version
• Logs of human oversight and incident handling tickets with timestamps

Segregation of duties matters: the proposer of a classification should not be the final approver; the operator who performs tests should not be the sole verifier of their own controls. Capture requirement → control → owner → dated evidence → audit trail → remediation.

An AI inventory tool can help keep references consistent, but it does not replace regulatory decisions which remain the organisation’s responsibility. For an example of a platform that links AI Act requirements to an inventory, see AuditReady’s AI Act feature page: https://audit-ready.eu/features/ai-act

Legal bases, purposes and minimisation across lifecycle phases

A single legal basis rarely covers every phase of an AI system. Data collection, training, testing, production inference and log retention may pursue different purposes. If your ROPA contains a generic formula, an auditor cannot determine which phase is covered and what data are necessary.

Five separate checks to document

1. Purpose specificity — document the concrete operational outcome, the people affected and uses that are excluded; record owner and approval date.
2. Legal basis (Article 6) — map each lifecycle phase to a legal basis and keep the written reasoning, not just a reference citation.
3. Special categories and criminal data (Articles 9–10) — check these before ingestion; even incidental presence changes obligations.
4. Minimisation (Article 5) — record which fields are excluded, the rule applied, filter version and a sample verification.
5. Retention rationale — assign retention periods for raw datasets, prompts, outputs and logs, with deletion events and responsible owners.

If you rely on legitimate interest, keep a dated balancing test enumerating the interest, necessity, expectations of data subjects, less intrusive alternatives, risks and mitigation. A copied paragraph across systems does not demonstrate a case‑by‑case balancing exercise.

In employment contexts, consent is often not a valid basis due to the imbalance of power. Document alternative bases, DPO advice and strict usage limits. A signed form alone is not decisive if the employee’s free choice is in doubt.

Example: a policy says health data are forbidden in training data. That policy does not prove the control worked. A dated exclusion log showing how many records were discarded, which filter version ran and a sample re‑check does.

Evidence minimums: per‑phase legal basis registry, dated balancing tests, allowed/forbidden field matrices, filter logs and retention rules. Each element must reference the exact model and dataset version used.

Transparency, profiling and automated decisions

Profiling and automated decision‑making are related but distinct concepts. Profiling is automated processing to evaluate personal aspects; automated decision‑making is profiling that produces legal effects or similarly significant consequences. Confusing them leads to vague notices and poorly designed human review.

When Article 22 matters

Article 22 applies where decisions are based solely on automated processing and produce legal effects or similarly significant impacts. Where an exception applies, the system must still provide safeguards such as human intervention, the opportunity to express a viewpoint and a mechanism to challenge the decision.

Information duties (Articles 13–14) must describe purpose, data, foreseeable consequences and provide “meaningful information about the logic involved.” You do not need to publish source code; you must explain in clear terms the main factors driving decisions, possible outcomes, and how to request review.

Supervisory guidance also highlights identity or age verification where relevant, transparency, the legal basis, correction mechanisms and algorithmic bias prevention controls.

Demonstrable human review

A legitimate human reviewer needs authority, access to relevant information and time to alter the outcome. An interface that only allows “approve” makes the review formal and audit‑weak.

Keep logs with case identifier, reviewer (different from the system proposer), date, outcome, rationale, any override and whether the subject was notified. Combine this with documented accuracy and bias tests, anomaly handling procedures and periodic re‑reviews of prompts and training data. Escalation paths for serious issues should include the DPO, CISO and process owner.

DPIA and record of processing activities: minimal fields

A DPIA (Article 35) is required where processing is likely to result in a high risk to individuals’ rights and freedoms. For AI, typical triggers include systematic evaluation of personal aspects, use of new technologies, worker monitoring, special categories of data, or large‑scale processing. The presence of one indicator does not automatically require a DPIA, but it requires a documented decision.

Timing and re‑assessment

Complete the DPIA before putting the system into production so it can prevent risks through design choices. A DPIA signed after deployment loses its preventive value. Reassess the DPIA after significant model, dataset, purpose, vendor or supervision changes.

Your processing register (ROPA) should not be disconnected from the AI inventory. Use a common identifier so an auditor can trace ROPA entry → DPIA → inventory item → evidence.

Minimal register fields

• Stable treatment identifier used across ROPA, DPIA and inventory
• AI system name, vendor, model and release date
• Purpose(s) and legal basis per lifecycle phase
• Categories of data subjects and data processed, and data sources
• Recipients and subprocessors, with contractual roles
• International transfers and the mechanism used
• Retention periods or deletion criteria and the deletion owner
• Security measures and links to supporting evidence
• DPIA outcome, date, DPO opinion and next review date
• Owner and last review date
• Residual risk level and compensating controls
• Evidence of approval, testing and remediation closure

A blank, generic or undated field is equivalent to an unverifiable control. Treat each missing field as a gap to assign and remediate.

Real cases that highlight enforcement risks

Enforcement actions show how missing controls translate into business risk. For instance, algorithmic assignment systems that affect worker rights have attracted substantial sanctions and corrective orders where transparency, fairness and human oversight were lacking. Similarly, supervisory action has blocked automated passenger processing systems that failed to comply with privacy rules.

Practical consequence: privacy‑by‑design (Article 25) means protections must be built into the system from the start — not retrofitted after deployment. Responsibility does not disappear because a third party supplied the algorithm.

Where users can object to model training (for example, social media users objecting to platform use of their content for model training), organisations must maintain intake channels, stop contested uses, remove affected items from datasets and document responses.

For subject access, rectification, objection and contestation, your DSAR register should include case id, receipt date, identity verification, implicated system, statutory deadlines, owner, outcome and evidence of the response. Link DSARs to model decisions and logs so responses are verifiable and not lost in a personal inbox.

Common mistakes and a pre‑audit checklist

Frequent audit findings are not missing documents alone but inconsistent timelines: DPIAs signed after launch, approvals dated retroactively, classifications without rationale, transparency notices that omit the logic, and untracked subject requests. Low‑risk AI Act classifications do not remove GDPR obligations: every system must produce a dated chain of evidence from legal basis to human review.

Distinguishing exception, finding and incident

• Exception: an authorised, time‑limited deviation with mitigations and recorded acceptance of residual risk.
• Finding: a non‑conformity requiring corrective action and independent verification.
• Incident: a security or personal data breach with its own response path and notification timeline (72 hours where required).

Mixing these three states in one register obscures responsibilities and can lead to apparent but unsupported closures.

Common audit‑neutralising evidence includes:

• DPIA dated before production
• Renewals of exceptions documented with new approvals and expiry
• DSAR requests logged with deadlines and responses
• Exports/screenshots accompanied by system version, timestamp and file hash
• Findings closed only after verification by an independent owner

Files scattered across email, chat and personal folders weaken the dossier as much as missing controls. If evidence lives only in someone’s head, continuity is lost when that person leaves.

Seven‑question pre‑audit checklist

1. Is the GDPR/AI Act applicability sheet signed and dated?
2. Is the legal basis recorded per phase, with balancing tests or valid consent?
3. Was the DPIA completed before deployment and re‑assessed after changes?
4. Do human reviews have an author distinct from the system proposer and include rationale?
5. Are subject requests logged with id, deadlines, outcome and response evidence?
6. Does every piece of evidence have an owner, date, version and immutable reference?
7. Do exceptions have expiry dates and documented approvals (no silent renewals)?

If any answer is negative, open a finding with severity, owner, due date, remediation and proof of closure.

AuditReady centralises versioned evidence, immutable audit trails and an Audit Day Pack, but it does not automate governance or assume regulatory responsibility. The platform supports GDPR, NIS2, EU AI Act, Model 231 and DORA frameworks; decisions and compliance remain with management, the DPO and process owners. Explore a demo of AuditReady for GDPR and EU AI Act workflows: https://audit-ready.eu/?lang=en

Frequently asked questions

Q: The model is provided by a third party. Who is the controller and who is the processor? A: Determine roles by who decides the purposes and means of processing. The controller defines purpose and means; the processor acts on documented instructions. Record contractual roles in the ROPA and retain dated attestations from vendors.

Q: Is a system trained only on anonymised data exempt from a DPIA? A: It depends. Keep the anonymisation method, a dated re‑identification test and a residual risk assessment on file. If re‑identification is reasonably possible, data remain personal and a DPIA may be required.

Q: Is an internal chatbot subject to Article 22? A: Only if it produces decisions based solely on automated processing that have legal effects or similarly significant impacts. A drafting assistant that suggests text typically falls outside Article 22, but controls on inputs, access and retention still apply.

Q: If a finding was closed, does a model update reopen it? A: Not automatically. Significant changes to model, data, vendor or purpose require a re‑review of the applicability sheet, risk classification and DPIA. Reopen the original finding or create a linked finding if the control no longer covers the changed system.

Q: Can an exception be renewed? A: Yes — but only with new documented approval, a fresh residual risk assessment, compensating controls and a new expiry date. Silent renewals convert a temporary exception into an audit problem.

To link AI inventory, ROPA, DPIA, subject requests, findings and evidence in a verifiable lifecycle, consider a platform such as AuditReady and request a demo dedicated to GDPR and EU AI Act workflows: https://audit-ready.eu/?lang=en

AuditReady centralises evidence with traceability and prepares an Audit Day Pack, while legal and compliance decisions remain with your DPO and management.