What is a DPIA?
Privacy, law and compliance
A DPIA, or Data Protection Impact Assessment, is a structured check used before high-risk personal data processing begins. In AI work it helps an organisation describe the processing, test whether it is necessary and proportionate, identify risks to people, choose mitigations and decide whether it needs further advice before launch.
What this means
A DPIA is not a legal afterthought or a form to complete at the end of a project. It is a way to slow down a proposed use of personal data before the organisation commits to it. The question is practical: what are we trying to do, whose data is involved, what might go wrong for those people, and what controls would make the work fairer, safer and more proportionate?
The term is used most often in UK and EU data protection work. Under the UK GDPR, a DPIA is required where processing is likely to result in a high risk to individuals. Many AI workflows can move into that territory because they may combine large datasets, profiling, automated recommendations, sensitive context, monitoring, or decisions that affect access to services, employment, finance or support.
For a smaller organisation, the useful habit is not to ask whether a DPIA sounds formal enough. It is to ask whether the proposed AI use changes the risk profile for real people. If it does, the DPIA becomes a working document that helps the team decide what should be changed before the workflow goes live.
Why it matters
AI projects can look operational on the surface but still create data protection risk. A customer service assistant may expose old notes. A sales scoring model may use personal data in ways people would not expect. A HR workflow may summarise sensitive information. A knowledge search tool may retrieve records that were never meant to be combined. A DPIA gives the organisation a structured place to test those risks before they become incidents.
It also helps with accountability. Leaders often ask for "safe AI" but leave teams without a decision trail. A DPIA records the purpose, lawful basis considerations, data categories, necessity, proportionality, risks, controls, residual risk and ownership. That record is useful when a supplier changes, a regulator asks questions, a customer challenges a decision, or a board wants assurance that AI adoption is not just enthusiasm wrapped around unmanaged data.
The best DPIAs improve the design of the work. They may reduce the data used, add a human review point, change retention periods, improve privacy notices, restrict access, remove a risky data field, or decide that the use case should not proceed in its current form.
How it works
A practical DPIA starts with a clear description of the processing. The team should be able to explain the workflow in ordinary language: the trigger, the data inputs, the system or supplier involved, the output, who uses the output, who is affected, and what decision or action follows. If that cannot be described simply, the project is not ready for meaningful risk review.
The next step is necessity and proportionality. This asks whether the same outcome could be achieved with less personal data, less sensitive data, shorter retention, fewer users, stronger aggregation, or a simpler non-AI process. This is where data minimisation becomes operational rather than theoretical.
The DPIA then identifies risks to individuals. Those risks may include unfair treatment, inaccurate inference, loss of confidentiality, unexpected reuse, lack of transparency, difficulty challenging an outcome, or harm caused by over-reliance on an automated recommendation. The team should then record mitigations: access controls, supplier due diligence, human review, testing, monitoring, deletion rules, staff guidance and escalation points.
Finally, the organisation decides whether the residual risk is acceptable. If high risk remains after mitigations, UK guidance expects the organisation to consult the ICO before going ahead. That is a significant boundary: a DPIA is not there to justify a decision already made.
Examples
A professional services firm wants to use an AI assistant to search client files and draft internal summaries. A DPIA would map which client records are indexed, whether personal data or special category data is included, who can query the system, whether outputs can reveal restricted information, and how inaccurate summaries are checked before use.
A retailer wants to use AI to prioritise fraud reviews. A DPIA would examine the personal data used, the effect of the score on customers, the chance of false positives, whether individuals can challenge the outcome, and whether human reviewers understand the limits of the model.
A care provider wants to summarise staff notes. A DPIA would need to be especially careful because the data may be sensitive and the people affected may be vulnerable. The output should not quietly become a decision record unless the organisation has designed review, correction and accountability into the workflow.
Common misunderstandings
A DPIA is only for large organisations. No. Size matters less than risk. A small organisation can still process sensitive or high-impact personal data.
A supplier DPIA is enough. Usually not. A supplier can explain its system, but the organisation deploying it still owns the context, purpose, data and effect on people.
A DPIA blocks innovation. A good DPIA often enables a safer version of the idea. It shows what must change for the use case to be proportionate.
AI automatically means a DPIA is required. Not always. The real test is whether the processing is likely to result in high risk, but AI often introduces factors that make the assessment worth doing.
Risks and boundaries
The main risk is treating a DPIA as compliance theatre. A document that lists generic risks but does not change the design of the workflow is weak evidence and weak governance. Another risk is completing the assessment too late, when the supplier has already been selected and the team feels committed.
A DPIA is also not the same as a complete AI risk assessment. It focuses on data protection risks to individuals. AI work may also need wider checks around security, model performance, bias, explainability, safety, procurement, intellectual property and operational resilience.
Jurisdiction matters. UK and EU terminology is close, but not identical in every operating setting. Organisations working across borders should check which data protection regime, supervisory authority and transfer rules apply.
What to do next
Start with a DPIA screening step for any AI workflow that uses personal data. Ask five questions: who is affected, what personal data is used, whether the output influences a decision, whether people would reasonably expect the use, and what harm could follow from error, misuse or disclosure.
For higher-risk workflows, create a short owner-led DPIA before procurement or build work becomes locked in. Keep it connected to the workflow map, supplier review, access model, testing plan and launch checklist. Review it again when the data, model, supplier, purpose or user group changes.
FAQs
Is a DPIA the same as a privacy policy?
No. A privacy policy tells people how data is used. A DPIA is an internal assessment of proposed processing, risk and mitigation before the work begins.
When should a DPIA happen in an AI project?
Early enough to influence the design. It should not wait until after the tool has been bought, configured and rolled out.
Who should own the DPIA?
Ownership normally sits with the business area using the workflow, supported by data protection, security, legal or governance specialists where available.
Does a completed DPIA make an AI system compliant?
No. It is evidence of assessment and risk treatment. Compliance still depends on the actual processing, controls, transparency, records and ongoing operation.
Sources
ICO: Data Protection Impact Assessments - primary UK regulator guidance on what DPIAs are, when they are needed and how they are carried out.
UK GDPR Article 35 - statutory basis for data protection impact assessments in UK GDPR retained law.
NIST AI Risk Management Framework - supporting context for wider AI risk management beyond privacy alone.