A privacy lead showed me a completed DPIA for an AI-assisted triage tool and asked, reasonably enough, what an AI impact assessment would add. The DPIA was competent. It identified the processing, the lawful basis, the necessity and proportionality argument, the risks to data subjects, and the mitigations. Her question was whether the AI impact assessment her ISO 42001 consultant had asked for was the same document under a different name, or whether she was about to duplicate six weeks of work.
The answer is neither. There is substantial overlap in the inputs and very little overlap in the questions being asked. Once you see where the divergence sits, running them as one exercise with two outputs is straightforward. Running them as two exercises is what wastes the six weeks.
What a DPIA covers, and when you must do one
Article 35 of the UK GDPR requires a data protection impact assessment where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. It is mandatory in three named cases: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based; processing on a large scale of special category or criminal offence data; and systematic monitoring of a publicly accessible area on a large scale.
The ICO publishes its own list of processing operations requiring a DPIA, and it includes several that bear directly on AI: innovative technology, denial of service based on automated decision-making, large-scale profiling, biometrics, and the use of data matching or invisible processing. Most substantive AI deployments touching personal data will trigger at least one.
The content requirements are specified. A systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to the rights and freedoms of data subjects, and the measures envisaged to address those risks. Where residual high risk remains after mitigation, Article 36 requires prior consultation with the ICO.
The object of a DPIA is the individual whose personal data is processed, and the frame is risk to their rights and freedoms. That framing is precise and it is also a boundary.
What an AI impact assessment covers, and how it differs
ISO 42001 requires the organisation to assess the impacts of AI systems on individuals, on groups of individuals, and on societies, and to do so at defined points in the system lifecycle. The AI management system is expected to define the process, apply it, and use the results in risk treatment. ISO/IEC 42005 provides guidance specifically on AI system impact assessment for organisations wanting a fuller methodology.
The difference is in the object rather than the rigour. A DPIA asks what could happen to a data subject as a consequence of processing their personal data. An AI impact assessment asks what the system does and to whom, whether or not personal data is involved and whether or not the affected party is the data subject.
Three concrete divergences illustrate this.
Consider a model that allocates limited resource across a population. The DPIA covers the personal data used to make the allocation. The AI impact assessment covers the distributive effect of the allocation on groups who were never data subjects, including those excluded from the dataset entirely.
Consider model performance degradation. A model whose accuracy declines as the operating population shifts is an AI risk with clear consequences. It is not naturally a data protection risk, and a DPIA template has nowhere to put it.
Consider a system operating entirely on non-personal data, say an industrial forecasting model, whose failure would have significant operational and safety consequences. There is no DPIA at all. There is very much an AI impact assessment.
The reverse is also true. A DPIA reaches purposes, retention, international transfers, and lawful basis in a way that no AI impact assessment methodology requires. Neither instrument is a superset of the other.
Where the FRIA sits
Article 27 of the EU AI Act adds a third instrument, the fundamental rights impact assessment. It applies to deployers rather than providers, and it does not apply to every deployer.
In broad terms it catches deployers that are bodies governed by public law, or private entities providing public services, when deploying certain high-risk AI systems, and deployers of high-risk systems used to evaluate creditworthiness or establish credit scores, and those used for risk assessment and pricing in life and health insurance. It requires a description of the deployment processes, the period and frequency of use, the categories of natural persons affected, the specific risks of harm to those persons, the human oversight measures, and the measures to be taken if risks materialise. Where a DPIA has already been carried out, Article 27 provides that the fundamental rights assessment complements it rather than repeating it.
Two hedges are warranted. First, the EU AI Act timetable has shifted: the Digital Omnibus on AI moved Annex III high-risk obligations to 2 December 2027 and Annex I high-risk obligations to 2 August 2028, so for most deployers the FRIA is a forward obligation rather than a present one. Second, the detailed expectations, including any template from the AI Office, are still settling. Build a process that can accommodate it rather than a document that claims to satisfy it.
For a UK organisation with no EU deployment, Article 27 does not apply. The rights-based framing it uses is nonetheless the framing an AI impact assessment should already be using, so nothing is wasted in adopting it early.
The overlap in practice
Set the three instruments against each other and roughly two thirds of the underlying work is common.
The system description is common. What the system is, what it does, what data it uses, how it is deployed, at what volume, and over what period. All three need it and it should exist once, in the AI system inventory, with the assessments referencing it rather than restating it.
The stakeholder identification is largely common. The DPIA needs the categories of data subject. The AI impact assessment needs affected individuals, groups and wider society. The FRIA needs the categories of natural persons affected. The AI framing is the widest, so identify stakeholders at that breadth once and the narrower instruments draw from it.
The risk analysis is partially common. Bias, inaccuracy, opacity and inappropriate reliance appear in all three, framed differently. Purpose limitation, retention and transfer risk appear only in the DPIA. Performance degradation and lifecycle risk appear only in the AI impact assessment.
The mitigations are almost entirely common. Human review, accuracy thresholds, subgroup testing, explanation to affected persons, appeal routes, logging, monitoring and retraining triggers serve all three. There is no reason to design them three times.
What genuinely differs is framing and audience. The DPIA is written for a data protection audience and, potentially, a regulator. The AI impact assessment is written for the AI governance function and an ISO 42001 auditor. The FRIA is written for a market surveillance authority. Same evidence, three readerships.
How to run them as one exercise
The approach that works is a single assessment workshop producing a shared evidence base, followed by separate structured outputs.
Start from the AI system inventory entry, which should already carry the description, the owner, the deployment context and the data categories. If it does not, that is the first gap and it is a management system gap rather than an assessment gap.
Run one analysis session covering stakeholders, harms, likelihood and severity, and candidate mitigations, scoped at the widest of the three framings. Record everything in one register with tags indicating which instrument each item serves.
Then generate the outputs. The DPIA in the structure Article 35 requires and the ICO expects, because a regulator reading a document that does not follow the expected shape will treat it as a poor DPIA regardless of its content. The AI impact assessment in the structure your AIMS defines, so that an auditor can trace process to output. The FRIA, if and when it applies, in the Article 27 structure, cross-referencing the DPIA as the Article expressly permits.
Assign one owner for the shared evidence base and separate reviewers for each output. The failure mode of the combined approach is a single document that satisfies nobody because it follows none of the three expected shapes.
Article 22, where the three converge
The sharpest convergence point is automated decision-making.
Article 22 of the UK GDPR gives a data subject the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them, subject to limited exceptions. Where an exception applies, safeguards are required, including the right to obtain human intervention, to express a point of view, and to contest the decision.
Every element of that provision is also an AI governance question. Whether the decision is solely automated is a question about the human oversight design, and a human who approves without meaningful capacity to disagree does not make the decision non-automated. Whether the effect is significant is the same question the AI impact assessment asks about consequence. The right to contest requires an explanation, which requires the system to be explainable, which is a design constraint rather than a policy statement. And in the EU AI Act, decisions of this character are exactly what pushes a system into the high-risk category that triggers Article 27.
This is why I would not run these assessments in separate functions. The organisation that treats Article 22 as a privacy matter designs the oversight arrangement to satisfy a legal test rather than to work, and the organisation that treats it as an AI matter documents a beautiful oversight design that nobody checked against the statutory right. The question is one question. It should be answered once, by people who can see both halves of it.
Who should do this work
The combined exercise needs someone who can hold both frames at once, and that is the practical constraint on running it as one.
A data protection specialist working alone will produce a strong DPIA and an AI impact assessment that is a DPIA with different headings, because the questions outside the personal data frame will not occur to them. An AI governance specialist working alone will produce a strong impact assessment and a DPIA that a regulator would find structurally deficient, because the Article 35 content requirements and the ICO's expectations are specific and unforgiving of improvisation.
Two people can do it well if they run the analysis together rather than sequentially. Sequential review, where one drafts and the other comments, produces the shared evidence base in name only, because the second reviewer works within the frame the first established.
To be clear about our own position: Goldline does not act as a Data Protection Officer and does not offer a DPO service. What we do is run the AI governance side of this work with enough data protection literacy to keep the two assessments coherent, alongside your DPO or privacy counsel rather than in place of them. Where an organisation has no data protection resource at all, the right first step is to obtain one, not to have an AI adviser fill the gap.
A note on refresh
Both instruments are living documents and both are commonly treated as one-off deliverables.
A DPIA should be reviewed when the processing changes materially. An AI impact assessment should be reviewed on the lifecycle triggers your management system defines, which at minimum should include model change, material change in the deployment population, a significant incident, and a defined periodic interval.
Because the shared evidence base sits underneath both, a single review updates both. That is the strongest practical argument for the combined approach, and it only holds if the shared register is maintained as the source of truth rather than being abandoned once the two outputs were generated.
If you want the DPIA and the AI impact assessment run as a single exercise with separate outputs, the integrated assessment is built to do exactly that. See how it works.
Last reviewed: August 2026.