The Fundamental Rights Impact Assessment for AI Deployers (Article 27)

The fundamental rights impact assessment is frequently described as something every deployer of a high-risk AI system must carry out. It is not. Article 27 names a specific and fairly short list of deployers, and most private-sector deployers of high-risk systems are not on it.

Who actually owes a FRIA

Article 27(1) of Regulation (EU) 2024/1689 imposes the duty on deployers of high-risk AI systems referred to in Article 6(2) — that is, Annex III systems — where the deployer is one of the following:

• A body governed by public law. Public authorities and bodies in the ordinary sense.
• A private entity providing public services. The limb that catches contractors and concessionaires — a private company running an employment service, a housing allocation function or aspects of healthcare provision on behalf of the state can be here, and the assessment is about the function rather than the ownership.
• Deployers of Annex III point 5(b) systems. AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, other than systems used to detect financial fraud.
• Deployers of Annex III point 5(c) systems. AI systems intended for risk assessment and pricing in relation to natural persons in the case of life and health insurance.

That is the list. Note what is absent. A private employer deploying an Annex III point 4 recruitment system does not owe a FRIA under Article 27, even though it is deploying one of the most consequential categories in the annex — it owes the Article 26 duties, and it may owe a DPIA under the GDPR, but not this. A bank doing consumer credit scoring does owe one; a bank deploying an internal fraud model is expressly outside point 5(b). The Annex III point 5 category is described on the essential services page.

The six required contents

Article 27(1)(a) to (f) lists what the assessment must consist of. It is a short list and it is worth reading as a set of questions rather than a form:

• (a) Processes. A description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose. Not a description of the system — a description of your process.
• (b) Period and frequency. The period of time within which, and the frequency with which, each high-risk AI system is intended to be used.
• (c) Affected persons. The categories of natural persons and groups likely to be affected by its use in the specific context.
• (d) Specific risks of harm. The specific risks of harm likely to have an impact on those categories, taking into account the information given by the provider under Article 13. Specific: the risks in your deployment, not the generic risks of the model class.
• (e) Human oversight measures. A description of the implementation of human oversight measures, according to the instructions for use. This dovetails with the Article 26(2) assignment duty.
• (f) Response measures. The measures to be taken if those risks materialise, including arrangements for internal governance and complaint mechanisms.

Point (f) is where the assessment stops being paperwork. It requires a named internal governance arrangement and a complaint route, which means somebody inside the organisation has to own the answer when the system harms somebody. An assessment that identifies risks in (d) and has nothing operative in (f) has not done the work.

Timing, reuse and updating

Article 27(1) requires the assessment to be performed prior to deploying the system. Article 27(2) then softens the burden in two ways: the obligation applies to the first use of the high-risk AI system, and the deployer may in similar cases rely on previously conducted assessments or on existing assessments carried out by the provider. Article 27(2) also requires the deployer to update the assessment if, during use, it considers that any of the elements listed in Article 27(1) has changed or is no longer up to date.

“In similar cases” is the phrase to be careful with. It permits reuse across genuinely similar deployments, not across an organisation by default; the whole point of the assessment is that Article 27(1)(a), (c) and (d) are context-specific, so two deployments of one system in materially different populations are not similar cases in any meaningful sense.

The reliance-on-provider-assessment route in the same paragraph is useful and limited for the same reason. A provider cannot assess your processes, your affected populations or your governance arrangements, so it can supply inputs and not the assessment.

Notifying the market surveillance authority

Article 27(3) is the part most often left out of summaries: once the assessment has been performed, the deployer must notify the market surveillance authority of its results, submitting the filled-out template referred to in Article 27(5) as part of the notification. In the case referred to in Article 46(1) — the derogation from conformity assessment for exceptional reasons of public security or protection of life and health — deployers may be exempted from that notification obligation.

Article 27(5) tasks the AI Office with developing a template for a questionnaire, including through an automated tool, to facilitate compliance. At the time of writing that template had not been published in final form, which leaves an awkward practical gap: the duty applies from the date Chapter III applies, and the instrument for discharging part of it is a Commission deliverable. How authorities handle notifications made before a template exists is not resolved, and it is a reasonable thing to raise with your national authority rather than to guess at.

How it relates to a DPIA

Article 27(4) provides that if any of the Article 27 obligations is already met through a data protection impact assessment conducted under Article 35 GDPR or Article 27 of Directive (EU) 2016/680, the fundamental rights impact assessment shall complement that DPIA.

Complement, not replace, and the direction matters. A DPIA is about risks to data subjects arising from processing personal data; the FRIA is about risks to fundamental rights arising from the use of a system in a context, and it reaches rights a DPIA typically does not centre — non-discrimination, effective remedy, access to services, freedom of expression. There is genuine overlap in the affected-persons and risk-identification sections, and running them as one exercise with two outputs is the sensible way to avoid duplicating the analysis while keeping the distinct filings. See the DPIA triggers page and the DPIA structure page.

On timing, the date for this obligation moved. Article 27 was originally to apply from 2 August 2026 under Article 113; for stand-alone Annex III high-risk systems — which is the whole of Article 27’s scope, since it bites only on Article 6(2) systems — that date is now 2 December 2027, postponed by Regulation (EU) 2026/1744. That extra time is also time for the AI Office to publish the Article 27(5) questionnaire template, whose absence is the practical gap described above.

The Article 111 transitional provisions for systems already on the market, including the 2 August 2030 date for public authorities under Article 111(2), are stated here from Regulation (EU) 2024/1689 as adopted. Whether the 2026 amendment shifted those transitional dates along with the main one is outside what this page can confirm, and it is exactly the kind of consequential detail that is easy to get wrong at second hand — read the consolidated text before relying on 2030.