How long does a DPIA take to write?

For a straightforward AI system (chatbot, document processor), a DPIA takes 2-4 days of focused work. Complex systems with multiple data sources, automated decision-making, or special category data take 1-2 weeks. The key is having the technical details available — data flows, processing purposes, security measures. If you built the system, writing the DPIA is much faster because you already understand it.

What should a DPIA for an AI chatbot include?

At minimum: description of the chatbot and its purpose, what personal data it processes (conversation content, user IDs, IP addresses), the lawful basis for processing, data flows (where conversations go — your server, LLM provider, CRM), risk assessment (what could go wrong — data breach, inappropriate responses, over-collection), security measures, data retention policy, and how you handle data subject rights requests.

Does the ICO have a DPIA template?

Yes. The ICO provides a DPIA template on their website, but it's generic — not AI-specific. It covers the GDPR requirements but doesn't address AI-specific risks like model bias, hallucination, training data issues, or automated decision-making. You'll need to supplement the ICO template with AI-specific risk assessment. Or use a specialist who provides an AI-focused DPIA from the start.

Who should be involved in writing the DPIA?

The person who built or understands the AI system (for technical details and data flows), someone with data protection knowledge (to assess risks and identify requirements), and ideally whoever will operate the system (to understand practical use). If you have a DPO, they must be consulted. For small teams, one person who understands both the tech and the regulation can handle it — that's what we do.

Do I need to share my DPIA with the ICO?

Not automatically. You must consult the ICO before processing only if your DPIA identifies a high risk that you cannot mitigate. In practice, most DPIAs identify risks and then document the measures that mitigate them — so prior consultation is rare. But you must keep the DPIA on file and be able to produce it if the ICO asks. Regulators frequently request DPIAs during investigations.

How to Write a DPIA for Your AI System: A Practical Guide With Examples

You already know you need a DPIA. Maybe you read our article on when a DPIA is required, or maybe your DPO told you. Either way, the question isn't "do I need one?" — it's "how do I actually write one that holds up?"

That's what this guide is for. Step by step, with real examples for the three most common AI systems we see: chatbots, document processors, and automated decision-making tools.

No theory. No hand-waving. Just the practical work.

What a DPIA Actually Is (in 30 Seconds)

A Data Protection Impact Assessment is a structured document that answers three questions:

What are you doing with personal data?
What could go wrong?
What are you doing to stop it going wrong?

That's it. GDPR Article 35 requires it whenever processing is "likely to result in a high risk" to people's rights and freedoms. AI systems almost always qualify because they involve new technology, often automated decision-making, and usually process data at scale.

The ICO doesn't want a novel. They want evidence that you thought about the risks before you started processing — not after you got caught.

Step 1: Describe the Processing

This is where most DPIAs fall apart. People write something vague like "we use AI to process customer data" and move on. That's useless.

You need to document:

What the system does — in plain English, not marketing language
What personal data it processes — be specific: names, email addresses, conversation content, IP addresses, behavioural data
Where the data comes from — direct from users, imported from a CRM, scraped from public sources
Where the data goes — your servers, your LLM provider's servers, a database, a CRM, analytics tools
Who has access — your team, the AI provider, any third parties
How long you keep it — retention periods for each data type

Example: AI Customer Support Chatbot

The system is a customer support chatbot deployed on our website. It uses the Anthropic Claude API to generate responses based on our FAQ knowledge base. When a customer starts a conversation, the chatbot collects: conversation text (which may contain names, account numbers, or other personal data the customer volunteers), IP address, browser session ID, and timestamp. Conversation data is sent to Anthropic's API for processing, with responses returned to the user in real time. Conversations are stored in our PostgreSQL database hosted on AWS eu-west-1 for 90 days, then automatically deleted. Access is limited to the customer support team (3 people) and the system administrator.

See the difference? An ICO reviewer can read that and understand exactly what's happening. No follow-up questions needed.

Example: AI Document Processor

The system processes scanned invoices submitted by clients. It uses OCR (Google Cloud Vision API) to extract text, then a custom classification model to categorise expenses. Personal data processed includes: supplier names, contact details, bank account numbers (partial, last 4 digits visible), and invoice amounts tied to identified individuals. Documents are uploaded via a secure portal, processed in Google Cloud eu-west2, and results stored in our accounting system. Original scans are deleted after 7 days. Processed data retained for 6 years (HMRC requirement).

Example: Automated Decision-Making System

The system scores job applications for initial screening. It processes: candidate name, email, CV text (which includes employment history, education, skills, and potentially age/nationality indicators), and cover letter content. The system assigns a score of 1-100 based on keyword matching and experience relevance. Applications scoring below 40 are flagged for rejection. A human reviewer approves all rejections — no application is automatically rejected without human review. Data is processed via OpenAI's API (with DPA in place) and stored in our ATS for 6 months post-decision.

Step 2: Assess Necessity and Proportionality

This step asks: is what you're doing actually justified? The ICO wants to see that you've considered whether there's a less invasive way to achieve the same goal.

Answer these questions honestly:

Is there a lawful basis? Legitimate interest, consent, contractual necessity — pick one and justify it
Is the processing proportionate? Are you collecting more data than you need?
Could you achieve the same thing with less data? If your chatbot works fine without storing IP addresses, why are you storing them?
Have you told people what you're doing? Your privacy notice needs to mention AI processing specifically

This is where you might realise your system collects data it doesn't need. Good. Strip it out now, before someone asks you why you're hoarding it.

For example, if your chatbot sends the entire conversation history to the LLM on every message (to maintain context), you should ask: do you need the full history, or would the last 5 messages work? Less data sent = less risk = easier DPIA.

Step 3: Identify and Assess Risks

This is the part that separates a real DPIA from a box-ticking exercise. You need to think about what could actually go wrong — not just generic data breach scenarios, but AI-specific risks.

Generic Risks (Apply to All AI Systems)

Risk	Likelihood	Severity	Overall
Data breach — unauthorised access to personal data	Medium	High	High
Excessive data collection — processing more than necessary	Medium	Medium	Medium
Inadequate retention — keeping data longer than needed	Medium	Medium	Medium
Third-party processor breach — LLM provider compromised	Low	High	Medium
Cross-border transfer issues — data sent outside EEA without safeguards	Low	High	Medium

AI-Specific Risks (This Is What the ICO Looks For)

Risk	Likelihood	Severity	Overall
Hallucination — AI generates false information about a real person	Medium	High	High
Bias — AI makes unfair distinctions based on protected characteristics	Medium	High	High
Prompt injection — user manipulates AI to reveal other users' data	Medium	High	High
Training data leakage — AI inadvertently reveals data from training	Low	High	Medium
Over-reliance — users treat AI outputs as authoritative without checking	High	Medium	High
Opacity — inability to explain why AI made a particular decision	Medium	High	High

Rate each risk as low, medium, or high for both likelihood and severity. Be honest. If you rate everything as "low" the ICO won't take your DPIA seriously.

What This Looks Like for Each System Type

Chatbot risks to highlight: Hallucination (giving customers wrong information), prompt injection (extracting other users' data), conversation data being used for LLM training (check your provider's terms), storing sensitive data customers volunteer (credit card numbers, health info).

Document processor risks: OCR misreading personal data, incorrect classification leading to wrong financial decisions, bank details being exposed, retention periods not being enforced automatically.

Automated decision-making risks: Bias in scoring (the big one — if your CV scorer systematically underscores certain demographics, that's discrimination), lack of explainability (can you tell a rejected candidate why?), over-reliance on AI scores without meaningful human review (rubber-stamping doesn't count).

Step 4: Document Mitigation Measures

For every risk you identified, you need a concrete mitigation. Not "we'll be careful." Specific, technical, verifiable measures.

Here's what good mitigations look like:

Risk: Hallucination

System prompt instructs the AI to only answer from the approved knowledge base
Responses are tagged with confidence scores; low-confidence responses are escalated to a human
Regular testing with adversarial prompts to catch hallucination patterns

Risk: Prompt injection

Input sanitisation on all user messages
System prompt hardening with instruction boundaries
Regular penetration testing focused on prompt injection vectors
Conversation isolation — no user can access another user's conversation data

Risk: Bias in automated scoring

Monthly bias audits comparing scores across demographic groups
Human review required for all rejection decisions (not just a checkbox — documented review with reasoning)
Candidates can request human-only assessment as an alternative
Training data reviewed for demographic balance

Risk: Cross-border data transfer

DPA with LLM provider includes Standard Contractual Clauses
Transfer Impact Assessment completed and documented
Data minimisation — only necessary fields sent to the API, not full records

Risk: Excessive retention

Automated deletion scripts run nightly
Retention periods documented and enforced technically (not just in policy)
Audit logs track deletion compliance

The pattern is: risk → specific technical or organisational measure → how you verify it's working.

Step 5: Consult Your DPO (If You Have One)

GDPR Article 35(2) says you must seek the advice of your Data Protection Officer when carrying out a DPIA. If you don't have a DPO, you should still have someone with data protection knowledge review it.

Document the consultation. Record what advice was given and whether you followed it. If you didn't follow the DPO's advice, document why — the ICO will ask.

Step 6: Sign Off and Record the Decision

Your DPIA needs:

A clear outcome — is the residual risk acceptable, or do you need to do more?
Sign-off from a decision-maker — someone with authority, not the intern
A date — the DPIA should be completed before processing starts
A review schedule — when will you revisit this? (At least annually, or when the system changes)

If your DPIA concludes that risks remain high even after mitigation, you must consult the ICO before proceeding. This is called prior consultation under Article 36. It's rare if you've done the mitigation work properly, but the obligation exists.

What the ICO Actually Looks For

Having reviewed ICO enforcement actions and guidance, here's what triggers problems:

No DPIA at all — MediaLab.AI, £247,590 fine. They didn't even bother.
DPIA done after launch — The whole point is to assess risks before you start processing.
Generic template that doesn't match the actual system — If your DPIA says "chatbot" but your system makes automated hiring decisions, it's worthless.
No AI-specific risks addressed — Standard data breach scenarios aren't enough. Where's the bias assessment? The hallucination risk? The prompt injection analysis?
Mitigations without evidence — Saying "we have security measures" isn't a mitigation. Name the measures. Show they're implemented.
No review date — A DPIA is a living document. If you wrote it 18 months ago and haven't looked at it since, it's stale.

Five Common Mistakes (And How to Avoid Them)

1. Too vague. "The system processes customer data using AI." That tells nobody anything. Name the data fields, the providers, the storage locations, the retention periods.

2. Doesn't cover AI-specific risks. A DPIA that only talks about data breaches and missed the fact that your AI chatbot hallucinates wrong medical advice isn't fit for purpose.

3. Written after launch. The ICO's position is clear: the DPIA should inform your design decisions. If you launch first and assess second, the document is just an exercise in post-rationalisation.

4. Downloaded a template from the internet. The ICO template is a reasonable starting point, but it's not AI-specific. And a template from a US website probably won't cover GDPR requirements properly. Your DPIA needs to match your actual system, not a hypothetical one.

5. Treats human oversight as a magic fix. Writing "a human reviews all decisions" only works if the human actually reviews them meaningfully. If your "human reviewer" approves 500 AI decisions per hour without reading them, that's rubber-stamping, not oversight. The ICO knows the difference.

What It Costs

Let's be direct about pricing:

DIY using ICO template: Free, but you need someone who understands both AI systems and data protection law. If you get it wrong, the cost of fixing it (or defending it to the ICO) is much higher.
DPIA with external legal review: £500–£1,000. You write it, a data protection lawyer checks it. Good if you understand your system but want legal sign-off.
Specialist DPIA (outsourced): £1,000–£2,000. A data protection specialist writes the whole thing after understanding your system. Best for complex AI systems or if you don't have in-house expertise.
DPIA as part of a build engagement: Included. When we build an AI system, the DPIA is part of the deliverable — because we already understand the data flows, the architecture, and the risks. It's the most efficient approach because the people writing the DPIA are the same people who built the system.

The last option is what we recommend, and it's what we do. Compliance documentation written by people who actually understand the technology, not lawyers guessing at how the system works.

Putting It All Together

Here's your checklist:

If you've ticked every box, you've got a DPIA that will stand up to scrutiny. If you haven't, you've got a document that looks like a DPIA but won't protect you when it matters.

Need Help?

If you're building an AI system and want the compliance documentation done properly — as part of the build, not bolted on afterwards — talk to us. We build AI systems that work and come with the documentation to prove they're compliant. DPIAs, risk assessments, and data protection documentation are included in every engagement. Check our services and pricing to see how it works.

Related reading: Already assessed whether you need a DPIA? Good — you're in the right place. If you're building a chatbot specifically, our guide on building a GDPR-compliant AI chatbot covers the technical side. And if your AI system falls under EU AI Act high-risk classification, you'll also need a conformity assessment — here's how to do one.