Does every business using high-risk AI need a FRIA?

No. Article 27 names bodies governed by public law, private entities providing public services, and deployers of the specified Annex III point 5(b) and (c) systems. The trigger also concerns high-risk systems referred to in Article 6(2).[1] A private company should test its role and exact use, rather than assume every high-risk application creates this duty.

Which private finance uses can trigger Article 27?

Annex III point 5(b) covers AI intended to evaluate a natural person's creditworthiness or establish a credit score, except systems used to detect financial fraud. Point 5(c) covers risk assessment and pricing concerning natural persons in life and health insurance.[1] Those categories can bring a private deployer within the FRIA duty even when it does not provide a public service.

Can an existing DPIA replace a FRIA?

The Digital Omnibus on AI, Regulation (EU) 2026/1744, amended Article 27(4). It allows cross-references to relevant sections of a GDPR Article 35 DPIA, or inclusion of relevant DPIA parts, where that assessment already meets an obligation.[3] It does not remove the need to address FRIA elements the DPIA has not covered. Check the six elements and notification separately.

Does a deployer notify an authority after a FRIA?

Yes, as a rule. After the assessment, Article 27(3) requires notification of its results to the market surveillance authority using the completed Article 27(5) template.[1] In the case referred to in Article 46(1), however, deployers may be exempt from notification.[2] The AI Office is to develop a questionnaire template that can cross-reference relevant DPIA sections.[3]

Must the same system receive a new FRIA on every use?

No automatic fresh assessment follows every use. Article 27(2) applies the duty to the first use and permits reliance on previous FRIAs in similar cases or existing provider impact assessments. If a listed element has changed or become outdated, the deployer must update the information.[1] Compare the new context with the earlier assessment before deciding to rely on it.

Fundamental rights impact assessment: who must do one?

Quick Answer: A fundamental rights impact assessment (FRIA) examines harm before high-risk AI deployment. Article 27 of the EU AI Act catches public-law bodies, private public-service providers and deployers of specified credit and insurance systems. It needs six elements, usually authority notification, and updates. Annex III duties apply from 2 December 2027 ¹^,3.

Summary in a mind map

Fundamental rights impact assessment: who must do one?
│
├─ Who is covered
│   ├─ Public-law bodies and public services
│   ├─ Named credit and insurance uses
│   └─ Article 6(2) high-risk route
│
├─ What the FRIA contains
│   ├─ Process, timing and affected people
│   ├─ Harm and human oversight
│   └─ Response and complaint measures
│
├─ How it connects
│   ├─ Relevant DPIA parts may be reused
│   ├─ Notify with the filled template
│   └─ Annex III date: 2 December 2027
│
└─ Later use
    ├─ Similar cases may rely on prior work
    ├─ Compare the actual use with the first
    └─ Update changed or outdated elements

Who must perform an AI Act Article 27 FRIA?

A fundamental rights impact assessment is the deployer's examination, under Article 27 of the EU AI Act (Regulation (EU) 2024/1689), of how using covered high-risk AI may affect people's fundamental rights. Article 27(1) places the duty before deployment. It applies to bodies governed by public law, private entities providing public services, and deployers of the high-risk AI systems in Annex III points 5(b) and 5(c). Article 27(1) excludes high-risk systems intended for the area in Annex III point 2, critical infrastructure, whoever deploys them¹^,2. The opening condition refers to systems classified as high-risk under Article 6(2)¹. The Commission likewise describes the public-authority and public-service duty as arising before first use⁴.

The trigger is narrower than “our company uses AI”. It is also narrower than “we use any high-risk system”. Intended use matters. A firm must identify what the system does and whether its use falls within the specified high-risk route. It must then identify the deployer category. A company supplying a tool and a company using it in its own process may have different roles. Article 27 names the deployer for this assessment¹^,2.

A public-service role cannot be inferred merely from the company's size or sector label. The actual service and use matter. Similarly, a private firm outside a public-service context may still be caught by the two finance categories. That is why the first practical record should state the system, the business process, the intended use, the deployer's role and the exact limb of Article 27 relied on. The record makes a yes or no decision reviewable without treating every deployment as identical. The decision is especially sensitive where a private organisation believes it provides a public service or a finance tool has several uses.

Deployer and use	FRIA position under Article 27(1)
Body governed by public law using covered high-risk AI	Named deployer category¹.
Private entity providing public services using covered high-risk AI	Named deployer category¹^,4.
Deployer of Annex III 5(b) or 5(c) high-risk AI	Named regardless of public-service status¹.
Any deployer of an Annex III point 2 (critical infrastructure) system	Excluded by Article 27(1)¹^,2.
Other private use	Article 27's named categories do not automatically include it¹.

Credit and insurance uses

Annex III point 5(b) addresses systems intended to evaluate the creditworthiness of natural persons or establish their credit score. It expressly excludes systems used for detecting financial fraud. Point 5(c) covers systems intended for risk assessment and pricing in relation to natural persons in life and health insurance¹. The two descriptions are specific. A credit union using a scoring system for individual loan applicants should examine point 5(b). A firm using a system only to detect fraud cannot silently be placed back into that category after the express exception.

The classification depends on intended use, not a general description such as “finance AI”. Purpose is decisive. An internal helper that summarises a policy and a model that scores an applicant serve different purposes. The assessor should write down which output enters which decision. For an insurance use, identify the named life or health insurance setting. Then check whether the system assesses risk or prices cover for natural persons. This distinction makes the Article 27 screen more precise than a checklist with a single finance box¹.

The six FRIA elements

Article 27(1) specifies six elements. Together, they connect the system to its actual use and to people who may be harmed. A generic description of the model is therefore insufficient. The deployer needs a description of its own process, timing and frequency, groups affected, particular risks, the implementation of human oversight, and measures to take if risks materialise¹^,2.

Process: Describe the deployer's processes in which the system will be used, including where its output enters a decision¹.
Use period: State the intended period and frequency of use¹.
People: Identify categories of natural persons and groups likely to be affected¹.
Harm: Describe the specific risks of harm likely to affect those people¹.
Oversight: Describe how human oversight measures will be implemented¹.
Response: State measures for risks that materialise, including internal governance and complaint mechanisms¹.

The following credit-union loan example illustrates how the six statutory elements could be recorded; it is not a prescribed control design¹.

Element	Credit-union loan example
Process	An AI score informs decisions on individual loan applications.
Use period	The union plans daily use for one year, then reviews the arrangement.
People	Individual applicants, including those refused a loan or offered a higher rate.
Harm	An inaccurate score could wrongly refuse an applicant or raise the offered rate.
Oversight	A loan officer reviews every automated decline before it is sent.
Response	An applicant can complain and trigger a manual re-review; the union records the incident and checks similar decisions.

FRIA and DPIA overlap

A data protection impact assessment under Article 35 GDPR and an Article 27 FRIA can cover overlapping material, but the Article 27 checklist has its own scope and notification step. The Digital Omnibus on AI, Regulation (EU) 2026/1744, replaced Article 27(4): where an obligation is already met through a GDPR Article 35 DPIA, the deployer may cross-reference the relevant DPIA sections or include relevant parts in the FRIA³. Reuse is therefore possible. It is not a reason to leave an Article 27 element unaddressed.

The practical comparison is element by element. If a DPIA describes affected people and a risk, those sections may be useful in the FRIA. The deployer must still check intended period and frequency. Human oversight needs its own description. So do the measures for harm that materialises. A copied document title does not show that those topics were covered. The DPIA guide explains the data protection assessment on its own terms; the present test remains Article 27 ¹^,3.

A FRIA also is not the provider's generic model evaluation. Article 27(2) allows reliance on existing impact assessments carried out by the provider in similar cases, but the deployer must see whether its own context is similar and current¹. A scoring system used with different people or decisions may need information the provider did not have. Record what was reused and what the deployer added.

Notice and new dates

After performing the assessment, the deployer must normally notify the market surveillance authority of the results and submit the completed Article 27(5) template¹. The AI Office must develop a questionnaire template, including through an automated tool, with an option to cross-reference relevant DPIA sections where appropriate³. Article 27(3) permits an exemption from notification in the case referred to in Article 46(1)². A firm planning a covered use should allow time for the assessment and any required notification before deployment¹.

The Digital Omnibus on AI changed the high-risk application timetable in Article 113. Chapter III Sections 1, 2 and 3 apply from 2 December 2027 for systems classified under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I³. Systems already placed on the market or put into service before the applicable Chapter III date generally enter this regime only if their designs change significantly from that date³. Providers and deployers of high-risk systems intended for public authorities must in any case take the necessary steps to comply by 2 August 2030³. Article 27's described systems are tied to the Article 6(2) route. The Annex I date is separate. Article 27 sits in Chapter III Section 3, so for covered Annex III systems the FRIA duty applies from 2 December 2027 ²^,3.

After the first deployment

Article 27(2) makes the obligation apply to the first use of the high-risk system. In similar cases, the deployer may rely on earlier FRIAs or existing provider impact assessments. If any of the six elements changes or is no longer current, it must update the information¹. This is a useful middle course between treating an old assessment as permanent and starting from an empty page for every repeat use.

A second branch, new group of applicants or change in review could affect different elements. The deployer should compare those facts against the prior assessment. Similar use may support reuse. The record should identify the earlier document and explain the match. A changed element needs an update. The reviewer should also check any consequences for the other parts. Article 27 does not give a universal interval that makes an assessment expire after a fixed number of months¹.

What to do next

List the system's intended use, the deployer's role and the relevant Annex III category. The AI Act risk categories guide helps identify high-risk uses. Compare the use with Article 27(1), then draft each of the six elements against the real process. Identify any DPIA sections that already meet an element. Plan any required authority notification with the AI Office questionnaire template after the assessment¹^,3. The AI Act dates guide explains the 2 December 2027 and 2 August 2028 high-risk application dates. Before a later use, compare the new context with the first record and update changed elements¹^,3.