AI Impact Assessments: DPIA, FRIA and AIA Compared

In one paragraph

Ask three governance teams what an AI impact assessment is and you get three answers, all correct. One means the data protection impact assessment they have run for years under GDPR Article 35. One means the fundamental rights impact assessment the EU AI Act introduced at Article 27. One means the general assessment ISO/IEC 42001 Clause 6.1.4 requires of anyone operating an AI management system. They overlap in evidence and differ almost entirely in conclusion, which is how an organisation ends up holding a complete, competent DPIA with no answer to the question a fundamental rights assessment asks. For a board the practical question is narrower than "which is best practice". It is which one legally binds this organisation, for which systems, by when. And if the answer is Article 27, whether anyone has noticed that a completed assessment sitting in a governance folder does not discharge it.

Three instruments, one phrase

The data protection impact assessment. Required under UK and EU GDPR Article 35 wherever processing is likely to result in a high risk to the rights and freedoms of natural persons. Its subject is the processing of personal data: lawful basis, necessity, proportionality, retention, security. Long-standing law, well understood, already embedded in most organisations' change processes. Many AI deployments trigger one. None of them is discharged by one.

The fundamental rights impact assessment. The EU AI Act Article 27 instrument, and the newest of the three. Narrower in who must carry it out and considerably wider in what it examines: dignity, non-discrimination, freedom of expression, access to an effective remedy. A DPIA was never designed to evaluate those, because a DPIA asks whether you may process the data and says nothing about what the resulting decision does to a person.

The AI system impact assessment. ISO/IEC 42001 Clause 6.1.4: an assessment of the consequences that development, deployment, intended use or foreseeable misuse could have on individuals, groups and society, feeding back into the risk assessment. Not tied to any regulator, and the broadest of the three. If you hold or are pursuing 42001 certification, this one already applies to you regardless of geography.

A fourth phrase circulates. The algorithmic impact assessment is largely a public-sector convention, most developed in Canada and parts of the UK public sector, typically scoring a system's consequence level and attaching proportionate obligations. Usually policy and not statute. The glossary entry on impact assessment sets out the distinctions in more detail.

The question that actually matters

Most published guidance on this topic explains all three instruments and leaves the reader to work out which applies. That gets it backwards. Start with scope.

Article 27 applies to two populations, and only two.

The first is deployers that are bodies governed by public law, or private entities providing public services, using any Annex III high-risk system. Annex III point 2 is excluded, which covers AI as a safety component in critical infrastructure such as road traffic, water, gas, heating and electricity.

The second is every deployer, public or private, of two specific Annex III categories:

• Point 5(b), AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, excluding systems used for detecting financial fraud.
• Point 5(c), AI systems intended for risk assessment and pricing in relation to natural persons in life and health insurance.

Read that second population twice, because it catches ordinary commercial firms with no public-service dimension at all. A lender scoring consumer credit applications is squarely inside Article 27. So is an insurer pricing life cover. Whatever else those firms concluded about the Act, this reaches them, and it is a substantial part of why financial services carries more AI Act exposure than its risk profile alone suggests.

The obligation falls on the deployer, and not the provider. That is deliberate. The assessment is about the specific context of use, and the provider does not know your context. A vendor cannot do this for you, whatever their marketing implies.

If neither population describes your organisation, Article 27 does not bind you. That is a legitimate and common answer. Write it down, with the reasoning, so it does not sit as an unexamined assumption. That assumption is what the missing AI impact assessment process risk describes. Falling outside Article 27 says nothing about ISO/IEC 42001 Clause 6.1.4, or about whether an impact assessment is the right thing to do anyway.

What Article 27 actually requires

Where it does bind, the assessment must contain six things. Reproduced here in the order the Article sets them out, because most templates reorganise them and then cannot demonstrate completeness against the text.

• A description of the deployer's processes in which the high-risk system will be used, in line with its intended purpose.
• The period of time within which, and the frequency with which, the system is intended to be used.
• The categories of natural persons and groups likely to be affected in the specific context of use.
• The specific risks of harm likely to have an impact on those categories, taking account of the information the provider must give under Article 13.
• A description of the implementation of human oversight measures, according to the instructions for use.
• The measures to be taken if those risks materialise, including arrangements for internal governance and complaint mechanisms.

Two observations about that list. Element 4 depends on provider documentation, so an incomplete Article 13 information package from your vendor directly blocks your own compliance. That makes it a procurement question with a lead time attached. And element 6 asks for a complaint mechanism, which is an operational build and not a paragraph. Organisations treating the FRIA as a documentation exercise discover this late.

The two duties almost no template covers

Here is where the freely available FRIA templates tend to stop, and where the obligation does not.

Article 27(3) requires you to tell the regulator. On completion, the deployer must notify the market surveillance authority, submitting the filled-out template, subject to an exemption under Article 46(1). A FRIA that sits in a governance folder, however well written, does not discharge Article 27. Very few of the templates circulating as lead magnets mention this at all, so an organisation can complete one diligently and remain non-compliant.

Article 27(5) promises a template, and you should expect to map to it. The AI Office is to develop a template questionnaire, including through an automated tool, to facilitate compliance. The sensible reading is not "wait for it", since the obligation does not pause. Build so you can map to it instead. Keep your assessment's structure traceable to the six statutory elements, and not to a house format, so transposing it into the official questionnaire later is a mapping exercise and not a rewrite.

How a FRIA and a DPIA fit together

Article 27(4) is explicit and helpful. Where the deployer already meets any of these obligations through a data protection impact assessment under GDPR Article 35, or Article 27 of the Law Enforcement Directive, the fundamental rights assessment complements that DPIA instead of repeating it.

In practice a combined or cross-referenced document is not merely permitted but sensible. The overlap is real: affected categories of people, identified risks, and mitigation measures appear in both. The non-overlap is where the work is.

A useful way to hold the distinction. A DPIA asks whether you may lawfully process this data, and whether doing so is necessary and proportionate. A FRIA asks what the resulting decision does to a person's rights, and how they would challenge it.

A system can pass the first comfortably and fail the second badly. Credit scoring is the standing example. The processing may be entirely lawful, minimised and secured, while the decision it produces materially affects access to housing, and the affected person has no practical route to contest it.

Organisations that already run mature DPIAs have most of the evidence-gathering machinery they need. What they usually lack is the rights analysis and the remedy design, which is why the missing DPIA risk and the fundamental-rights gap are distinct register entries.

Timing, and one genuinely open question

The assessment must be performed before the high-risk system is put into use. Article 27(2) allows a deployer to rely on a previously conducted assessment, or on one carried out by the provider, in similar cases, and requires the information to be updated where any of the six elements has changed or is no longer up to date. It is a live document and not a gate you pass once.

When Article 27 starts applying is currently unclear, and it is worth being honest about that instead of picking a date. Article 27 sits in Chapter III, Section 3 of the Act. The AI Omnibus deferred Chapter III obligations for stand-alone Annex III high-risk systems from 2 August 2026 to 2 December 2027, and for Annex I embedded systems to 2 August 2028. On the structural reading, Article 27's application moves with them. Some commentary published before the Omnibus was adopted argued the deferral did not reach Article 27; that commentary was written against the proposal and not the final text.

Two things hold regardless of how that resolves. The FRIA is tied to the high-risk regime, so it moves with it or it does not, and either way it was not the obligation that bit this month. That was Article 50 transparency, which was expressly left alone. And any organisation inside Annex III 5(b) or 5(c) needs this work done whichever year the deadline lands in, because element 6 includes an operational complaint mechanism that cannot be built in the fortnight before a deadline.

What to do now

If you are in scope, meaning a public body, a provider of public services, a consumer lender, or a life or health insurer using AI in scoring or pricing:

• Confirm scope in writing, per system, with the Annex III point cited. "We think we are probably in scope" does not survive an inspection.
• Check your Article 13 information packages from every provider. Element 4 cannot be completed without them, and a gap here is a supplier conversation with a lead time.
• Design the complaint mechanism as a build. Element 6 asks how a person raises a concern and what happens next. That is a process with owners and service levels.
• Structure the assessment against the six statutory elements, so the AI Office questionnaire becomes a mapping exercise later.
• Plan for the notification. Identify your market surveillance authority now and understand what submission will involve.

If you are not in scope, filing this away is the wrong move. ISO/IEC 42001 Clause 6.1.4 requires an impact assessment of anyone operating an AI management system, and the substantive questions Article 27 asks are the right ones for any consequential deployment. Run a proportionate version, and keep the scope determination on file so nobody has to re-litigate the question every time someone reads a headline. The AI impact assessment process control entry covers how to run one, and the compliance crosswalk shows how the requirement maps across the frameworks.

Every organisation in scope will eventually be asked which assessment binds it. The ones that can answer will have written the determination down, with a date and a name against it, before anybody asked.