Free AI DPIA Template (Copy-Paste) + When One Is Required

1 Jul 2026Sotiris Spyrou

Here's a free AI DPIA template you can copy straight into a document, plus the exact questions to answer, when a DPIA is legally required for an AI system, and how it maps to GDPR Article 35, the ICO's guidance and the EU AI Act. A Data Protection Impact Assessment is the document that proves you thought about the privacy risks of your AI before you switched it on, not after. Under GDPR Article 35 you must run one before any processing that's likely to result in a high risk to people's rights and freedoms. Using AI to profile people, make automated decisions, or process personal data at scale usually clears that bar. Copy the template below, work through the questions, and you'll have a defensible record for a regulator, a buyer's security team or your own board.

What is an AI DPIA?

A DPIA is a structured assessment of how a processing activity affects people's privacy and other rights, and what you're doing to reduce the harm. It's a requirement of the UK GDPR and the EU GDPR, not a nice-to-have.

An AI DPIA is the same instrument pointed at an AI system. It asks the standard questions (what data, whose data, on what lawful basis, held for how long) and then the AI-specific ones the base template misses: is a model making or heavily influencing a decision about someone, could it be biased against a protected group, can you explain its output, and could its training or inputs expose data you didn't intend to expose.

One thing to be clear about. A DPIA isn't a form you fill in once to get a launch signed off. It's a live assessment. Change the model, the data or the purpose, and you revisit it.

When is a DPIA legally required for AI?

GDPR Article 35(1) sets the trigger: a DPIA is required where processing is "likely to result in a high risk to the rights and freedoms of natural persons," taking into account the nature, scope, context and purposes of the processing (GDPR Article 35). Article 35(3) then names three cases where a DPIA is always required:

Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal or similarly significant effects
Large-scale processing of special-category data (health, biometrics, race, and the rest of Article 9) or criminal-offence data
Systematic monitoring of a publicly accessible area on a large scale

The ICO goes further. Its guidance lists the use of "innovative technology," which it explicitly ties to AI, alongside profiling, automated decision-making with significant effects, large-scale processing, and combining datasets, as processing that's likely to be high risk and so needs a DPIA (ICO: when do we need a DPIA?). Most business uses of AI on personal data hit at least one of these. If you're unsure, the ICO's position is to do one anyway, because the assessment itself is cheap next to a wrong call.

Do it before you start processing. A DPIA written after go-live isn't a DPIA, it's an apology.

The free AI DPIA template

Copy the eight sections below into a document. Answer every question honestly for your own system. Where a question doesn't apply, write "not applicable" and say why, rather than deleting it, so a reviewer can see you considered it.

1. System description and purpose

What is the AI system and what does it do, in one plain paragraph?
What's the purpose of the processing? What decision or outcome does the AI drive?
Who's the data controller? Is anyone a joint controller or processor?
Is the model built in-house, bought from a vendor, or an API to a third-party model? Name it.
What's the nature of the processing (training, inference, both) and the expected scale (records, people, frequency)?

2. Necessity and proportionality

Why do you need AI for this at all? What can't a simpler method do?
Is the personal data you're using the minimum needed for the purpose? What could you drop?
Could you achieve the same outcome with less identifiable data (aggregation, pseudonymisation, synthetic data)?
Is the processing proportionate to the benefit, and would an affected person find it reasonable?

3. Data inventory

Field	What to record
Data categories	Every category of personal data used for training and for inference (name, email, behavioural, financial, etc.)
Special-category data	Any Article 9 data (health, biometric, racial or ethnic origin, sexual orientation, religious belief) or criminal-offence data, flagged explicitly
Data sources	Where each category comes from (collected direct, bought, scraped, inferred by the model)
Data subjects	Whose data it is (customers, employees, applicants, the public) and roughly how many
Recipients	Who the data or model outputs are shared with, including sub-processors and the model vendor
International transfers	Any transfer outside the UK or EEA, and the safeguard relied on
Retention	How long training data, prompts, outputs and logs are kept, and the deletion route

4. Lawful basis and automated-decision check

What's your Article 6 lawful basis for the processing (consent, contract, legal obligation, legitimate interests, etc.)?
If you use special-category data, what's your Article 9 condition on top of that?
Does the system make a decision "based solely on automated processing" that produces a legal or similarly significant effect on someone (Article 22)? If yes, which Article 22 exception applies, and what human review, contest route and explanation do you provide?
How do you tell people this processing is happening (privacy notice, in-product disclosure)?

5. Stakeholder consultation

Have you sought the views of the people whose data is processed, or explained why that isn't appropriate?
Has your DPO given input, and is their advice recorded?
Have security, legal and the system owner reviewed it?
If a vendor supplies the model, what did their documentation tell you about training data, bias testing and data handling?

6. Risk assessment

Score each risk to individuals by likelihood and severity, 1 to 5 each. Risk score is likelihood times severity, 1 to 25.

Risk ID	Risk to individuals	Likelihood (1-5)	Severity (1-5)	Score	Notes
P-01	Bias or discrimination: the model produces worse outcomes for a protected group	3	5	15	Hiring, credit, fraud and pricing use cases are highest exposure
P-02	Lack of transparency: a person can't get a meaningful explanation of a decision about them	3	4	12	Sharpens under Article 22 and Article 15
P-03	Data security: prompts, training data or outputs are exposed through a breach or model leak	3	5	15	Includes personal data pasted into third-party model prompts
P-04	Re-identification: supposedly anonymised or aggregated data is linked back to a person	3	4	12	Rises with rich behavioural data and model memorisation
P-05	Function creep: data collected for one purpose is reused to train or run the model	3	4	12	Common failure; check the original lawful basis still holds
P-06	Inaccuracy: the model asserts false personal data as fact, affecting a decision	4	4	16	Engages the Article 5 accuracy principle
P-07	Loss of control: a person can't exercise access, rectification or erasure over model-held data	3	4	12	Hard to satisfy erasure once data is baked into weights

The scores above are illustrative. Rate your own system honestly and add rows for any risk specific to your context.

7. Mitigations and residual risk

For each risk above, record:

The measure that reduces it (bias testing across affected groups, human-in-the-loop review, input filtering to keep personal data out of prompts, retention limits, an enterprise contract with no-training terms, explainability tooling, and so on)
The residual risk score after the measure is applied
Whether the residual risk is acceptable, and who agreed that

If a residual risk stays high after mitigation, GDPR Article 36 requires you to consult your supervisory authority (the ICO in the UK) before you start processing (GDPR Article 36). That's the prior-consultation duty, and it's a hard stop, not a formality.

8. Sign-off

Field	Detail
DPO opinion	The DPO's written view on whether the processing can proceed, and any conditions
System owner	The named person accountable for the system and its risks
Controller sign-off	The decision to proceed, refuse or proceed-with-conditions, dated
Prior consultation	Whether Article 36 consultation with the ICO was needed, and the outcome
Review date	When this DPIA gets revisited

How do you use an AI DPIA?

The template is the easy part. The discipline around it is what makes it hold up.

Do it before processing starts. Article 35 is explicit: the assessment happens "prior to the processing." That means before you train on real personal data and before the system touches a live decision. Retrofitting one after launch defeats the purpose and won't impress a regulator.

Get the DPO involved and record it. Article 35(2) says you must seek the DPO's advice where one is appointed. Their opinion goes in the sign-off section. The controller makes the final call, but the DPO's view is part of the record.

Know who signs. The controller owns the DPIA and the decision to proceed. If your assessment shows a high residual risk you can't mitigate, you don't get to sign it off yourself. You consult the ICO first under Article 36.

Review on a cadence and on change. Revisit the DPIA when the model changes, the data changes, the purpose changes, or the vendor swaps their underlying model. As a floor, review live AI systems at least annually. A DPIA that describes a model you retired two versions ago is fiction.

Keep it, don't file it. The DPIA is evidence of accountability under Article 5(2). You may need to show it to the ICO, an enterprise buyer's security team, or an auditor. Store it where you can find it and keep the version history.

A DPIA satisfies data protection law. It doesn't, on its own, satisfy the EU AI Act. Here's how the three fit together.

GDPR Articles 35 and 36. Article 35 sets the requirement, the minimum content (a description of the processing, an assessment of necessity and proportionality, a risk assessment, and the measures to address those risks), and the trigger cases (GDPR Article 35). Article 36 adds the prior-consultation duty when residual risk stays high (GDPR Article 36). The template above is built around exactly this content, so working through it produces an Article 35-compliant DPIA.

ICO guidance. The ICO's DPIA guidance is the practical UK reference. It confirms that AI and other innovative tech, profiling, automated decisions with significant effects, and large-scale processing are triggers, and it publishes a screening checklist and a template of its own (ICO: when do we need a DPIA?). If you're a UK controller, treat the ICO's guidance as the operative standard and this template as a working way to meet it.

EU AI Act. The Act classifies AI systems by risk (unacceptable, high, limited, minimal) and puts heavy duties on high-risk systems, including a risk management system, data governance, and detailed technical documentation (EU AI Act high-level summary). Two things matter here. First, a DPIA is not an AI Act conformity assessment. The conformity assessment is a separate, broader obligation about the system's compliance with the Act, and the technical documentation it requires (Annex IV) goes well beyond privacy. A completed DPIA does not tick that box. Second, the Act adds a Fundamental Rights Impact Assessment for certain deployers of high-risk systems under Article 27, which overlaps with a DPIA but isn't the same document. The clean way to think about it: the DPIA covers data protection, the conformity assessment and FRIA cover the AI Act. You may need all of them for one high-risk system. For where AI Act duties bite by sector, see our EU AI Act compliance checklist by industry and test your position with the EU AI Act readiness tool.

A DPIA is a live assessment, not a launch form

The most common mistake isn't writing a weak DPIA. It's writing a solid one, getting the launch signed off, and never touching it again. AI systems drift. Vendors change the model underneath your feet. A new data source gets plumbed in without anyone re-checking the lawful basis.

The DPIA that earns its keep is the one you reopen when something material changes, and review on a schedule even when it doesn't. New model, revisit it. New purpose, revisit it. New special-category data, definitely revisit it. That habit is the difference between a document that protects you and one that just proves you once meant to.

Frequently asked questions

When is a DPIA required for AI?

Whenever the processing is likely to result in a high risk to people's rights, which most AI on personal data is. GDPR Article 35(3) makes it mandatory for systematic automated evaluation and profiling with significant effects, large-scale special-category data, and large-scale systematic monitoring. The ICO adds AI and other innovative technology, automated decision-making, and large-scale processing to the list of high-risk triggers. If your AI profiles people, makes or heavily influences decisions about them, or processes personal data at scale, run a DPIA before you start.

Is a DPIA the same as an EU AI Act assessment?

No. A DPIA is a data protection instrument under GDPR Article 35 and covers privacy risk. The EU AI Act's conformity assessment is a separate, wider obligation for high-risk systems, backed by technical documentation requirements (Annex IV) that go beyond data protection. The Act also introduces a Fundamental Rights Impact Assessment for some deployers under Article 27. A completed DPIA does not satisfy the AI Act. For a high-risk system you may need the DPIA and the AI Act assessments, and they're different documents.

Who signs off a DPIA?

The data controller owns the DPIA and makes the final decision to proceed. Where you've appointed a DPO, you must seek their advice and record it. If the DPIA shows a high residual risk you can't mitigate, you don't sign it off yourself. GDPR Article 36 requires you to consult your supervisory authority (the ICO in the UK) before the processing begins.

Do we need a DPIA for a third-party AI tool?

Often, yes. If you're the controller deciding to use a third-party AI tool on personal data, the DPIA duty sits with you, not the vendor. You assess how the tool processes your data subjects' data, what the vendor does with prompts and outputs, whether data is used for training, and where it's transferred. The vendor's documentation feeds your assessment, but it doesn't replace it. Buying the tool doesn't buy you out of the obligation.

What should an AI DPIA include?

At minimum, per Article 35(7): a description of the processing and its purpose, an assessment of necessity and proportionality, an assessment of the risks to individuals, and the measures you'll use to address those risks. The template above adds the AI-specific layers the base version misses: a data inventory that flags special-category data, an Article 22 automated-decision check, bias and explainability risks, and a sign-off block that captures the DPO opinion and any Article 36 consultation.

The bottom line

Most teams deploying AI on personal data don't have a real DPIA. They have a launch approval with a privacy box ticked. The gap between those two shows up the moment a regulator asks, a customer's security team runs due diligence, or a model does something no one assessed for.

Start with the template above. Work through all eight sections for your actual system, score the risks to individuals without flattering yourself, and get the DPO and controller to sign it. Do it before you process, review it when things change, and keep it where you can produce it. That single habit clears the Article 35 bar and gives you a document you can put in front of anyone.

The harder part is doing it well: honest bias analysis, a real read on residual risk, and knowing when a system tips into needing an EU AI Act assessment on top of the DPIA. That's the work we do. For the wider view, read our free AI risk register template and our AI compliance audit guide, and if you're using synthetic data to cut privacy risk, our note on GDPR and synthetic data privacy rights.