AI Certification and the FRIA Burden Under Article 27

Why this question is landing on so many desks right now

The Fundamental Rights Impact Assessment obligation under Article 27 of Regulation (EU) 2024/1689 applies before certain deployers put a high-risk AI system into use. It falls specifically on bodies governed by public law, private operators providing public services, and deployers of systems used to evaluate creditworthiness or for life and health insurance risk assessment and pricing. For those organisations, the FRIA is not an optional governance nicety. It is a precondition to lawful deployment, sitting alongside a wider penalty regime that reaches up to EUR 35 million or 7 percent of global annual turnover for the most serious infringements of the Act, in force since August 2025.

At the same time, a growing number of businesses in this position have already been through, or are considering, a structured certification assessment of their AI agents, whether through a framework like this one or through adjacent standards such as ISO/IEC 42001 or the NIST AI Risk Management Framework. It is a natural question to ask whether the two processes can be combined, and an even more natural temptation, for anyone selling certification, to answer that question more generously than the law allows. This article resists that temptation and sets out exactly where the overlap is real and where it stops.

What a FRIA actually has to contain

Article 27 sets out specific content requirements rather than leaving the FRIA as a vague governance exercise. A compliant FRIA must describe the deployer's processes in which the high-risk AI system will be used, in a manner consistent with its intended purpose. It must set out the period of time within which, and the frequency with which, the system is intended to be used. It must identify the categories of natural persons and groups likely to be affected by the specific use in context. It must identify the specific risks of harm likely to have an impact on those categories of persons, taking into account the information given by the provider under its instructions for use. It must describe the human oversight measures the deployer will put in place. And it must set out the measures to be taken in the case of the materialisation of those risks, including internal governance and complaint mechanisms.

Read closely, that list is not abstract. It is a request for concrete, deployment-specific analysis: who is affected, for how long, in what context, with what oversight, and with what plan if something goes wrong. None of that can be filled in by a generic assessment conducted before the deployer knows the specific population it will affect. That is the first and most important limit on any claim that certification substitutes for a FRIA, and it is worth stating before discussing where the two genuinely converge.

Where certification evidence and FRIA evidence genuinely converge

The convergence is real, and it follows from how a structured certification assessment is built. This framework's seven dimensions evaluate an AI agent across Trust and Safety, Context Integrity, Distribution Control, Product Maturity, Governance, AI Integration, and Autonomy Envelope. Several of these dimensions ask for exactly the categories of evidence a FRIA also requires, produced independently of the specific deployment context and therefore reusable once that context is known.

The Governance dimension in particular maps closely onto the FRIA's requirement for internal governance and mitigation planning, and this site's earlier analysis of the Governance dimension sets out what that evidence looks like in practice: documented escalation paths, incident response procedures, and a named accountable owner. The Trust and Safety dimension, and its treatment of human oversight specifically, corresponds directly to the human oversight measures a FRIA must describe, a link this site has examined in detail in relation to Article 14 oversight evidence. The Autonomy Envelope dimension, which documents the boundaries placed on autonomous decision making, speaks to the same underlying question a FRIA asks about risks of harm from the system acting within or beyond its intended scope.

This overlap is not a coincidence of framework design. It exists because Articles 9, 10, 14, and 72 of Regulation (EU) 2024/1689, covering risk management systems, data governance, human oversight, and post-market monitoring respectively, already require providers and deployers to produce much of the same underlying documentation a FRIA depends on. A certification assessment built around those same control areas is, in effect, assembling FRIA raw material as a byproduct of assessing the agent against its own criteria. A deployer who has been through such an assessment is not starting the FRIA from nothing. It is starting from an organised evidence base covering oversight, governance, and risk identification, with the deployment-specific analysis still to be layered on top.

Where the overlap stops, and why that limit is not a technicality

The limit matters because Article 27 was written specifically to catch a gap that generic technical assessments do not close: the effect of an AI system on the fundamental rights of the actual people it will be used on, in the actual context of use. A certification assessment evaluates the agent. A FRIA evaluates the agent as deployed, against a named or describable population, for a defined period, in a specific institutional process. Those are different questions, and answering the first one well does not answer the second.

Concretely, no certification assessment can tell a deployer which categories of persons will actually interact with a specific benefits eligibility system in a specific municipality, or what the demographic composition of applicants to a specific credit product looks like, or how long a specific deployment is expected to run before review. Those facts belong to the deployer's own operational knowledge, not to an assessor evaluating the underlying AI agent in the abstract. A FRIA that copied certification findings into these fields without deployer-specific analysis would not meet the Article 27 standard, regardless of how strong the underlying certification was. This is also true of ISO/IEC 42001 and the NIST AI RMF: both are valuable management system references, and both generate governance evidence that can feed a FRIA, but neither one, any more than certification, discharges the deployer's obligation to conduct the assessment itself.

A practical sequence: certification evidence first, deployment-specific analysis second

The workflow that follows from this is straightforward and worth setting out plainly, since it is the accurate version of the argument this article opened with. A deployer that has completed a certification assessment should treat the resulting scorecard, dimension findings, and governance documentation as the first input into its FRIA drafting process, not as the finished product. The oversight, governance, and risk identification sections of the FRIA can draw directly on that material, adapted to the specific system's deployment. The affected persons analysis, the period and frequency of use, and the deployment-specific risk narrative still need to be built from scratch, because they depend on facts only the deployer holds.

Approached this way, the time saved is concentrated in the sections of the FRIA that would otherwise require the deployer to reconstruct oversight and governance evidence from separate internal records, interviews, and policy documents. It is not saved in the sections that require fresh analysis of the deployment's actual human impact, because no external assessment can pre-populate those honestly. For a full walk through of the Article 27 obligation itself, including the ninety day preparation window many deployers are now working against, agentliability.eu's deployer checklist sets out the practical timeline in detail, and its companion guide to the FRIA obligation covers the legal requirement in full.

What to tell a compliance team or a board honestly

The defensible claim, stated plainly, is this: certification is not a FRIA and cannot be represented as one, because Article 27 places a specific, non-delegable obligation on the deployer that no third party assessment discharges. What certification reliably does is reduce the marginal burden of producing a FRIA, by generating organised, evidenced documentation across oversight, governance, and risk identification that would otherwise need to be assembled separately. A deployer weighing whether to pursue certification ahead of a FRIA deadline should expect a real reduction in drafting time and a stronger evidence base, not an exemption from the assessment itself. Anyone claiming otherwise, including a certification provider, should be treated with the same scrutiny this site applies to its own claims elsewhere in this series.