Which assessment do you actually owe?

Three assessments get confused with one another constantly: the fundamental rights impact assessment under the EU AI Act, the data protection impact assessment under GDPR, and the algorithmic impact assessment, which is not a legal instrument at all in most places. They have different triggers, different contents, different audiences and different consequences for getting them wrong. Treating them as one document produces something that satisfies none of them.

The FRIA scope is narrow, and most people get this wrong

Article 27 of the EU AI Act does not impose a fundamental rights impact assessment on every deployer of a high-risk system. It reaches four categories: bodies governed by public law, private entities providing public services, deployers of Annex III 5(b) creditworthiness and credit scoring systems, and deployers of Annex III 5(c) risk assessment and pricing in life and health insurance.

Read that list against your own estate before you commission anything. A general insurer pricing motor cover is not in it. A life insurer pricing a term policy is. A bank scoring a mortgage application is. A retailer using an Annex III employment system is a deployer of a high-risk system with the Article 26 duties attached, and is not subject to Article 27.

The failure runs in both directions and both are expensive. Scoping a FRIA programme across every high-risk system burns a year of a compliance team's capacity producing documents nobody will ask for. Assuming it does not reach you because you are a private company misses the two insurance and credit entries that were put there precisely to catch private firms.

The six elements, and why they are hard to fake

Article 27(1) enumerates six elements, and each one is a question about the deployment rather than about the model:

• (a) The deployer's processes in which the system will be used, in line with its intended purpose.
• (b) The period over which, and the frequency with which, the system will be used.
• (c) The categories of natural persons and groups likely to be affected.
• (d) The specific risks of harm likely to affect those categories.
• (e) How the human oversight measures will be implemented, per the instructions for use.
• (f) The measures to take if those risks materialise, including internal governance and complaint mechanisms.

Element (e) is the one that catches organisations out, because it cannot be written without the provider's Article 13(3) instructions for use in hand. If your vendor has not given you those instructions, you cannot complete a FRIA, and the gap is a procurement failure rather than a drafting one. Element (b) is the one that changes most often and is almost never revisited: a pilot on two hundred applications a month and a production rollout on twenty thousand are different assessments.

Results are notified to the market surveillance authority. That single fact should govern the register you write in. This is not an internal memo.

The DPIA relationship

The two assessments overlap heavily, and the Digital Omnibus, Regulation (EU) 2026/1744, permits a FRIA to incorporate or cross-refer to a GDPR Article 35 DPIA rather than repeating it. Use that. Article 26(9) already requires deployers to use the Article 13 information when carrying out a DPIA, so the material flows in both directions.

Be precise about what each one is for. A DPIA asks whether the processing of personal data is proportionate and what protects the data subject. A FRIA asks who is affected by the deployment and what happens to them when it goes wrong, including people who are not data subjects of yours. Cross-referring is permitted; substituting is not.

Colorado: the duty people are still planning for was repealed

Colorado SB 24-205 required annual impact assessments of high-risk AI systems and offered a rebuttable presumption for organisations using the NIST AI Risk Management Framework. It was repealed and replaced by SB 26-189, signed 14 May 2026 and effective 1 January 2027. The impact assessment duty and the NIST presumption were both removed.

What survives in Colorado is narrower and more procedural: developer-to-deployer documentation, pre-use consumer notice, disclosure after an adverse decision within thirty days, and three-year record retention. If your programme still carries a Colorado impact assessment work item, delete it, and check whether anything downstream was justified by the NIST presumption that no longer exists.

The algorithmic impact assessment

An algorithmic impact assessment is a practice, not a statute, outside specific public-sector procurement regimes. ISO/IEC 42005:2025 addresses AI system impact assessment and is the obvious reference point, though we do not reproduce its clause text here. Use the term internally if it helps, but never let it appear in a compliance register as though it discharged a statutory duty. When an auditor asks which provision a document answers, "it is best practice" is a finding.

Worked example: a life insurer and a motor insurer reach different answers

A composite insurer runs two underwriting models. The life book uses a model that segments applicants by predicted mortality to set premiums. The motor book uses a model that sets premiums from telematics and claims history.

The life model sits squarely in Annex III 5(c): risk assessment and pricing in life and health insurance. The insurer is a deployer of a high-risk system and owes a FRIA, notified to the market surveillance authority, covering all six elements.

The motor model is not in Annex III 5(c), which names life and health. The insurer still owes the general deployer duties where the system is high-risk on another ground, still owes a DPIA where the processing is high-risk under GDPR, and still faces Swiss Article 21 revFADP duties for any solely automated pricing decision with significant effect. What it does not owe is an Article 27 FRIA.

Two models, one company, one compliance team, and a different answer. The reasoning is what goes in the classification record, because the question will be asked again after the next reorganisation.

As of 24 September 2026.