DPAs and AI systems — what DPOs actually need to document

Three things have changed the regulator stance on AI between 2023 and 2026. The first is the publication of guidance — CNIL's recommendations on AI development, the European Data Protection Board's opinion 28/2024 on AI models, the Garante's decisions on ChatGPT and on training-data lawfulness, the AEPD's guidance on AI auditing, and the Information Commissioner's Office's AI and data protection guidance in the UK. Each authority now has a position on what it expects from organisations processing personal data with AI.

The second change is the EU AI Act, which entered into force in 2024 and is now being applied progressively. The AI Act and the GDPR are separate instruments, but they share an enforcement constituency — most data protection authorities are also designated market surveillance authorities for elements of the AI Act in their jurisdiction. The result is that an AI-related enquiry under the GDPR will often touch AI Act concerns and vice versa.

The third change is the volume of complaints. Data subject complaints about AI have grown rapidly: people contesting automated decisions, people requesting erasure of training data, people asking what data the AI system used to produce an output about them. The DPAs have built capacity to handle these complaints, and the capacity-building means that enquiries that previously took years now arrive within months of a complaint being filed.

The DPO is no longer being asked whether their organisation uses AI. The DPO is being asked to produce the records that prove the use is lawful, documented, and reviewable.

Article 39 of the GDPR sets out the DPO's tasks. They include informing and advising the controller on its obligations, monitoring compliance, providing advice on the DPIA, cooperating with the supervisory authority, and acting as a contact point for data subjects. None of these tasks change when AI enters the picture, but the substance of advice and the depth of documentation do.

For AI specifically, four GDPR provisions are most often the subject of enquiries:

• Article 5 — principles. Lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. Most AI-specific concerns map back to one of these principles — accuracy in particular, because AI outputs can be wrong about identifiable individuals, and the controller is responsible for the accuracy of personal data they process.
• Article 22 — automated individual decision-making.Where a decision based solely on automated processing produces legal effects or similarly significant effects, Article 22 restrictions apply. The threshold is the “solely” word: meaningful human review removes the system from Article 22, but rubber-stamp human review does not.
• Article 25 — data protection by design and default. AI systems should be designed with data protection in mind: data minimisation in training and inference, retention limits, privacy-preserving techniques where applicable. The records of those design decisions sit with the DPO.
• Article 35 — DPIA. Where processing is likely to result in high risk to natural persons, a DPIA is required before processing begins. The DPIA is the single artefact regulators most often ask for in AI-related enquiries.

The DPO does not need to be a machine learning engineer. They do need to be able to read the technical documentation produced by the engineering team and translate it into the privacy framework. Where the engineering documentation is missing or too thin, the DPO is accountable for noting the gap and pushing for it to be closed before processing begins.

Article 30 of the GDPR requires controllers to maintain a record of processing activities (RoPA). The basic fields are well established: name and contact details of the controller, purposes of processing, description of data subject categories, description of data categories, recipients, transfers to third countries, retention periods, and a general description of technical and organisational measures.

For AI processing the RoPA needs to be extended. The extension is not a new standalone record — it is additional fields per processing activity that involves AI. The fields are:

• AI system identifier. The internal name and version of the AI system, and the corresponding entry in the AI inventory. If the system is also in scope for ISO 42001 or the AI Act, cross-reference those scopes.
• Intended purpose.The specific purpose the AI system performs within this processing activity. Purpose limitation requires this to be narrower than “we use AI for customer service.”
• Model provider and configuration. The provider (e.g. AWS Bedrock, Azure OpenAI, an in-house model), the model family and version, and the configuration relevant to data protection — in particular, whether any setting allows the provider to retain or train on input data.
• Legal basis. The Article 6 ground for the processing, and the Article 9 ground if special category data is involved. For AI assisting a human decision, the legal basis may be different from the basis for the underlying decision; document both.
• Training-data use.Whether the AI system was trained on the controller's data, whether it is fine-tuned on it now, and whether it could be in future. The contractual default in most enterprise inference APIs is no training on customer data, but the answer should be in the RoPA, not in the marketing site.
• Sub-processors.Every entity that participates in the processing chain, including the underlying model provider where the controller's vendor uses third-party inference. Older sub-processor lists predate AI features and need refreshing.

The extended RoPA is the first document a DPA reviewer will ask for. It need not be a separate spreadsheet — most organisations add the AI-specific fields as columns or an annex to the existing RoPA. What matters is that the data is captured, kept current, and produced quickly when asked.

A DPIA is required under Article 35 where processing is likely to result in a high risk to the rights and freedoms of natural persons. The article gives three explicit triggers — systematic evaluation, large-scale processing of special category data, and systematic monitoring of publicly accessible areas — and the EDPB Guidelines on DPIAs (WP248) extend the list to nine criteria, of which the presence of two or more usually requires a DPIA.

For AI specifically, the question is whether the system meets the high-risk threshold. The matrix below covers the scenarios that come up most often in Drel's field of view; it is heuristic, and local DPA mandatory-DPIA lists take precedence where they apply.

The cost of an unnecessary DPIA is low — it is a documentation exercise that produces useful records even when not strictly required. The cost of a missing DPIA is much higher: a regulator finding that processing began without the required assessment is one of the most common enforcement triggers in AI-related cases. When in doubt, document the determination either way: either produce the DPIA, or produce a written record that explains why one was not required.

Article 35(7) sets out the minimum contents of a DPIA: a systematic description of the processing operations and purposes; an assessment of the necessity and proportionality of the processing; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address the risks. For AI, each of the four sections has specific content that a generic DPIA template will miss.

The description of processing should cover the AI system itself, not just the surrounding business process. That means naming the model, the inputs, the outputs, the decision boundary (where the model output ends and a human action begins), the data flows that connect them, and the retention policy for each flow. Where the model is hosted by a third party, the description includes the network path between the controller and the model and any intermediate processing.

The necessity and proportionality assessment is where the substance lives. The standard question — could the purpose be achieved with less personal data, or with anonymised data — is harder to answer for AI systems because the model has been trained on large corpora and may benefit from richer input than the strict minimum. The DPIA needs to record the trade-off explicitly: what data was included, what data was excluded, what the impact on system performance was, and why the included data is proportionate to the purpose.

The risk assessment for AI extends beyond the standard data protection risks. The categories that recur are:

• Bias and unfairness. The system may produce systematically different outcomes for different demographic groups. The DPIA needs to record the testing performed and the residual risk.
• Error propagation. An AI output is used as the basis for a downstream decision; if the output is wrong about the individual, the downstream decision is wrong too. The DPIA needs to record the validation gates that catch errors before they propagate.
• Opacity.The reasoning behind a specific output may not be traceable, making it hard to satisfy the data subject's right to an explanation under Article 22. The DPIA needs to record what explanation the system can produce and what the limits of that explanation are.
• Training-data leakage. Where the system was fine-tuned on controller data, there is a residual risk that the model may regurgitate training content. The DPIA needs to record the controls in place to mitigate leakage and the residual risk after controls.
• Profiling. Even where Article 22 does not apply, profiling is a defined category under Article 4 and carries specific transparency obligations under Articles 13 and 14. The DPIA needs to confirm whether profiling is happening.

The mitigations section then maps each risk to one or more controls and records the residual risk after the control is applied. The pattern mirrors the risk register under ISO 42001 — and most organisations benefit from running the two artefacts off the same underlying register, with the DPIA as a privacy view of the register and the ISO 42001 risk assessment as the AIMS view.

Training-data documentation is the area where a typical DPO has the least history and the regulator has the most interest. The Garante's decisions on ChatGPT in 2023 and 2024 turned on training-data lawfulness; the Hamburg Commissioner's position on model training; and the EDPB's opinion 28/2024 on AI model lawfulness — all centre on training data.

Training data is a separate concern from runtime data. Runtime data is what the model sees at inference time, in the prompts and the retrieval context; training data is what the model was built from. For a controller using a pre-trained model via an API, the training data is upstream — the vendor's responsibility — and the DPO's evidence is the vendor's training-data statement.

For organisations that fine-tune their own models, training-data documentation is internal. The DPO needs to record:

• Sources. Where the training data came from, with sufficient specificity that a regulator can verify the source.
• Legal basis. Article 6 ground for processing the training data, and Article 9 ground if special category data is included. Legitimate interests is often used; the balancing test needs to be documented.
• Retention. How long the training corpus is kept, and the retention rules for any data subject who exercises a right of erasure on the underlying data.
• Data subject rights mechanism.How a data subject can exercise rights with respect to training data, particularly the right of erasure. The Garante's position requires controllers to make this mechanism available even where erasure from a trained model is technically difficult.

For vendor models, the equivalent evidence is the vendor's training-data attestation. Most major enterprise AI vendors publish a statement; the DPO keeps the statement on file, notes the date it was issued, and updates the file when the vendor revises it. A vendor that refuses to make a training-data statement is a procurement risk in itself.

Most AI processing in enterprises is intermediated by a vendor. The vendor sits between the controller and the underlying model — sometimes operating the model themselves, often relying on a foundation model provider. The data protection role question is: who is processor, who is controller, and who is the model provider in this chain.

The conventional analysis is the one used outside AI: the entity that determines the purposes and means of processing is the controller. For most enterprise AI applications, that is still the customer organisation; the vendor processes personal data on the controller's behalf and is therefore a processor. The DPA between them is governed by Article 28.

AI introduces two complications. The first is configuration. Most foundation model APIs offer settings that determine whether the customer data is used for training or model improvement. When the setting is “no training reuse” — the default for almost all enterprise inference offerings — the vendor remains a processor. When the setting allows the vendor to train on customer data, the vendor is determining a new purpose (model improvement) and may become a joint controller for that purpose, or a separate controller depending on the contract.

The second complication is the model provider. A vendor that uses a third-party foundation model is effectively sub-processing to that provider for the inference step. The model provider should appear on the vendor's sub-processor list and should be covered by an Article 28-compliant chain. Older sub-processor lists predate AI features and often omit the model provider entirely; the DPO should ask explicitly.

Cross-border transfer rules apply to AI-routed data flows just as they do to any other personal data flow. What differs is the visibility: most controllers know where their CRM is hosted, but fewer know where the inference endpoint of their AI vendor sits, where the model is trained, and where each sub-processor in the inference chain operates.

The DPO's checklist for AI transfers is:

• Model hosting jurisdiction. Where the inference servers run. Many vendors offer regional endpoints — EU-only, US-only, multi-region — at different price points. The choice matters for transfer compliance.
• Sub-processor jurisdictions. Where the underlying foundation model provider operates and where their support staff sit. A vendor hosted in the EU may still rely on a model provider with US operations.
• Data residency for prompts and outputs.Whether prompts and outputs are routed through the model provider's home region or kept within a chosen region throughout the request lifecycle.
• Logging and audit.Where the vendor's observability and audit logs are stored. These often contain prompts and outputs in plaintext and need the same transfer analysis.

For each transfer to a third country, the DPO needs a transfer mechanism — typically Standard Contractual Clauses, or reliance on an adequacy decision where one applies — and a transfer impact assessment that considers the laws of the destination country and the specific risks to data subjects. The TIA template that works for SaaS in general works for AI vendors too, but the inputs need to be specific to the AI configuration: which data flows go where, in what volumes, with what protection in transit and at rest.

Across recent enquiries by EU data protection authorities, the same set of questions appears with high frequency. The DPO who anticipates these questions and prepares the answers in advance will spend significantly less time on the enquiry response than the DPO who starts from scratch when the letter arrives.

1. How was the legal basis established for the AI processing, and is it documented per Article 6 (and Article 9 where applicable)?The regulator expects a written legal basis analysis, not a reference to a generic privacy notice.
2. Can you produce the DPIA for the AI processing, with the dates of the assessment and any subsequent revisions?If the answer is “no DPIA was required,” the regulator expects a written determination that explains why.
3. How have data subjects been informed of the AI processing under Articles 13 or 14, and how specific is the notice?Generic “we may use AI” language is often insufficient where the processing has specific characteristics that affect the data subject.
4. How can data subjects exercise their rights against an AI system — access, rectification, erasure, restriction, objection, automated decision-making rights?The regulator expects an operational mechanism, not just a statement that rights are respected.
5. Who are the processors and sub-processors involved in the AI processing, and are the Article 28 contracts in place?The model provider in particular tends to surface as an unmentioned sub-processor in older arrangements.

The questions are not exotic. They are the questions a competent DPO would expect for any new processing operation. The challenge with AI is that the answers often need to be reconstructed retroactively because the procurement happened before the privacy office was looped in.

The DPO who is ready for a DPA enquiry on AI keeps a defined evidence package on file. The package is not a single document — it is a set of artefacts that together answer the questions the regulator is most likely to ask. The components are:

• Extended RoPA entries. The Article 30 record with the AI-specific fields populated for every processing activity that involves AI. Kept current as systems change.
• DPIAs, or the documented determination that one is not required.One per high-risk AI processing operation. Dated and revised when the system changes materially.
• Legal basis analyses. Per processing activity. Where legitimate interests is the basis, the balancing test is in the file.
• Vendor DPAs and sub-processor lists. Article 28-compliant contracts with every processor, including the model provider where the primary vendor is using third-party inference.
• Training-data attestations. From every vendor whose models touch personal data, plus the internal record for any fine-tuning you perform.
• Data subject rights mechanism documentation. How a request is received, how it is routed, how the AI-specific dimension is handled (e.g. how the system identifies the data it holds about the requester), and the response timelines achieved.
• Transfer impact assessments. Per third-country transfer chain, with the AI-specific data flows mapped explicitly.
• Re-assessment triggers. The events that would prompt a review of any of the above — most commonly a model version change, a configuration change, a sub-processor change, or an incident.

The list looks long. In practice, most of the items are short documents — a DPIA may be ten pages, a legal basis analysis two pages, a transfer impact assessment three. The volume is manageable; the discipline is in keeping each artefact current and connected to a system that is itself changing.

Related reading: for the upstream content on AI risk management evidence that underpins much of this package, see the Article 9 evidence piece in this series. For the audit-readiness perspective on the same documents, see the ISO 42001 audit readiness piece.