A DPIA for AI is the board's pre-launch test for personal data risk. It records the purpose, data, people affected, risks, controls and residual risk before processing starts, then turns model evidence, supplier terms, monitoring and sign-off into a go or no-go decision.
The legal trigger is not the use of a model by itself. The ICO says Article 35 requires a data protection impact assessment where processing is likely to result in high risk to individuals. The ICO's AI explanation guidance also says that where AI uses personal data to train, test or deploy a system, data protection law is in scope.
That makes the assessment a board paper, not a compliance appendix. If the use case affects tenants, pupils, service users, job applicants, customers or employees, the board needs evidence before approval: what data enters the system, what decision or recommendation comes out, what harm could follow, who owns each control, and what would stop the deployment.
Key takeaways
- The trigger is likely high-risk personal-data processing, including innovative technology with other risk indicators, automated decisions with significant effect, vulnerable people, large-scale sensitive data, tracking or data matching.
- If an AI system trains, tests or deploys on personal data, the ICO says data protection law applies; if it does not, the board still needs an AI risk assessment, but not necessarily a UK GDPR assessment.
- The ICO's process starts early, before processing begins, and covers need, processing description, consultation, necessity, risks, mitigations, sign-off and review.
- The evidence should feed the AI risk register, because residual privacy risk is also a live governance risk.
- For EU high-risk deployments in scope, Article 27 of the EU AI Act adds a fundamental-rights impact assessment that complements, rather than replaces, existing data protection assessments.
When a DPIA for AI is required
Start with the personal data question. The ICO's legal framework for explaining AI says data protection law applies when personal data is used to train, test or deploy an AI system, and that predictions or inferences about identifiable people can themselves be personal data. If the use case is purely operational and does not process personal data, it may still belong in the AI governance framework and the risk register, but the UK GDPR impact-assessment duty is not the same.
Where personal data is involved, Article 35 screening should happen before procurement approval, pilot launch or production go-live. The ICO lists three categories that automatically require an assessment: systematic and extensive profiling with significant effects, large-scale use of special-category or criminal-offence data, and large-scale systematic monitoring of a publicly accessible area. It also lists risk indicators such as evaluation or scoring, automated decision-making with legal or similarly significant effect, vulnerable data subjects, data matching, tracking, invisible processing and innovative technology, including AI.
A board can turn that into a practical screening rule:
- Any AI use that influences access to a service, benefit, opportunity, tenancy, education, care, employment, credit or complaint outcome should be treated as high-risk until evidenced otherwise.
- Any use involving children, patients, vulnerable residents, applicants, employees, service users, special-category data, criminal-offence data or location tracking should be assessed before a pilot.
- Any vendor feature that uses your data for prediction, scoring, classification, summarisation or workflow triage should be screened even if it arrived inside an existing product. For a new purchase, pair the assessment with the AI procurement checklist and supplier due-diligence questions.
- If the organisation decides an assessment is not needed, the ICO says that decision and the reasons should be documented, including DPO advice where there is a DPO.
This is also where shadow use matters. If staff are already pasting case notes, complaints or customer correspondence into external AI tools, the board's first task is discovery and triage, not a retrospective privacy form. The companion guide to shadow AI policy for boards sets out that first inventory step.
What the board must decide before work starts
The board does not need to recalculate every privacy risk. It needs to set the decision frame and refuse approval where the evidence is thin. Five questions should be answered before the assessment is commissioned.
- What is the decision or operational change? A drafting assistant, fraud flag, repairs triage model and recruitment screen have different risk profiles. The assessment must describe the process in which the AI system will be used, not only the product name.
- Who is affected, and what could happen to them? The ICO frames risk as potential physical, material or non-material harm to individuals, assessed by likelihood and severity. That includes loss of access to services, discrimination, financial loss, loss of confidentiality and other significant disadvantage.
- Who owns the assessment and the controls? The ICO says an organisation can decide who carries out and signs off impact assessments, and can ask a processor to help, but the controller remains responsible. If there is a DPO, their advice must be sought and documented.
- What would stop the deployment? The board should set residual-risk thresholds before teams are attached to the solution. If the mitigations do not reduce the risk to an acceptable level, the answer is not "launch with monitoring"; it is redesign, pause or consult the ICO.
- How will the decision be reviewed? The ICO says outcomes should be integrated into project plans and kept under review. For AI, review triggers should include model change, supplier-term change, data-source change, new affected groups, a material incident or a drift in measured performance.
These are board governance questions. They are also the questions in a good AI policy: scope, permitted and conditional use, data rules, human oversight, suppliers, incidents, training and ownership. The same evidence should shape the organisation's acceptable-use rules, so privacy restrictions are not left to user judgement.
Controls and evidence the assessment should produce
The ICO's process is flexible, but it is not empty. It asks organisations to describe the nature, scope, context and purpose of processing; assess necessity and proportionality; identify risks; record mitigations; sign off residual risk; and keep the outcome under review. For an AI use case, the evidence needs to be wider than a conventional software rollout because the model, data, supplier and user behaviour all shape the risk.
| Board question | Evidence to table | Likely owner |
|---|---|---|
| What personal data enters the system? | Data map covering collection, storage, inference, outputs, access, retention, sharing and transfers | Data protection lead with product owner |
| Why is AI needed for this purpose? | Necessity and proportionality note, including non-AI alternatives considered and why they were rejected | Executive sponsor |
| Can the data lawfully be used this way? | Lawful basis, special-category condition where relevant, privacy information, data minimisation and data-quality checks | DPO or privacy counsel |
| How does the model behave for affected groups? | Test evidence, known limitations, error analysis, bias checks and evidence of human oversight where outcomes affect people | Model owner with risk lead |
| What does the supplier do with the data? | Controller or processor analysis, Article 28 terms where relevant, training-data position, retention, sub-processors and transfer mechanism | Procurement with legal |
| How is the system secured? | Threat model, access controls, logging, monitoring, incident route and change-management evidence | Information security lead |
| What happens if the risk materialises? | Mitigation plan, complaint route, human review route, rollback plan and named owner for each action | Business owner |
| Who accepts residual risk? | Sign-off record showing DPO advice, accepted risks, rejected mitigations, review date and escalation threshold | Accountable executive and board committee |
This table should survive first contact with an auditor. If a row is answered by "supplier says it is compliant", the assessment is not finished. The NCSC's secure AI guidance, published in November 2023, asks providers and risk owners to consider secure design, secure development, secure deployment and secure operation through the AI lifecycle. The board should expect that security evidence to sit beside the privacy evidence, not behind it.
How it maps to risk registers and frameworks
An assessment is not a separate governance island. It is one evidence source inside the wider AI control system. That matters because different frameworks ask the same underlying questions in different words.
| Framework or record | What it asks from the assessment | Board use |
|---|---|---|
| ICO DPIA process | Purpose, personal data, affected people, necessity, risks, mitigations, residual risk, DPO advice and review | Decide whether processing can begin, continue, pause or be redesigned |
| AI risk register | Risk statement, owner, control, evidence, residual rating and review cadence | Keep the risk live after approval rather than frozen in a launch document |
| NIST AI RMF Playbook | Suggested actions aligned to Govern, Map, Measure and Manage | Connect privacy risk to wider AI risks such as validity, reliability, accountability and monitoring |
| ISO/IEC 42001 | A management-system approach for responsible development or use of AI systems | Place individual assessments inside policy, objectives, controls and continuous improvement |
| ISO/IEC 42005 | Guidance for AI system impact assessments focused on effects on individuals, groups and society | Extend privacy analysis into broader human and societal impact where the use case warrants it |
| EU AI Act Article 27 | Fundamental-rights assessment for certain high-risk systems, including affected groups, risks, human oversight and mitigation | Check whether an EU-facing high-risk deployment needs a complementary FRIA as at 17 June 2026 |
| GOV.UK Algorithmic Transparency Recording Standard | Public-sector publication of information about algorithmic tools, their use and accountability | Turn internal evidence into a publishable transparency record where the organisation is in scope |
This mapping prevents duplicate paperwork. One well-built assessment can supply the board paper, the risk register, the supplier file, the public transparency record and the action plan. The mistake is treating the form as the output. The output is a decision and a set of controls someone can evidence three months later.
Common mistakes and next step
The first mistake is timing. An assessment written after procurement has chosen the system is usually a justification exercise. The ICO says the process should begin early, before processing starts, and run alongside planning and development. For AI, that means before the pilot has created real-world habits and before a vendor contract has narrowed the options.
The second mistake is assessing the model in the abstract. Risk changes with context: the same summarisation tool used on published board papers, tenant complaints, HR grievances or safeguarding notes creates different obligations. A supplier's model card does not answer your lawful basis, affected groups, retention period, human review route or escalation process.
The third mistake is losing the assessment after sign-off. The ICO says outcomes should be integrated into project plans and kept under review. A board should ask for a living register entry, action owners, an incident route and a review date. If the evidence cannot be tracked, the governance cannot be repeated.
Use the AI Risk Register Generator to convert the assessment into live risks, owners, controls and evidence. Then use the Board AI Scorecard to test whether your board can govern those controls across the organisation. If the use case is material, regulated or already in flight, the AI governance diagnostic turns the assessment into a sequenced action plan before go-live.
Sources:
- ICO, when do we need to do a DPIA?
- ICO, how do we do a DPIA?
- ICO, what are the accountability and governance implications of AI?
- ICO, explaining decisions made with AI: legal framework
- NIST AI RMF Playbook
- ISO/IEC 42001:2023 AI management systems
- ISO/IEC 42005:2025 AI system impact assessment
- NCSC guidelines for secure AI system development
- EU AI Act Service Desk, Article 27
- GOV.UK Algorithmic Transparency Recording Standard guidance
- Governance AI Risk Register Generator
