What is a FRIA under the EU AI Act?
A Fundamental Rights Impact Assessment (FRIA) is an assessment that certain deployers of high-risk AI systems must carry out, under Article 27 of Regulation (EU) 2024/1689, before putting the system into use. It documents how the system will be used, who will be affected, which fundamental rights could be harmed, and what human oversight and governance measures will be in place if a risk materialises. It is a deployer-side obligation about a specific use in a specific context — not a technical assessment of the model itself.
- The point of a FRIA is to force a structured conversation before deployment: what could go wrong for the people on the receiving end of this system, how would we notice, and what would we do about it. The Regulation also requires deployers to notify the results to the market surveillance authority, and the AI Office is tasked with developing a questionnaire template to support that.
Who has to complete a Fundamental Rights Impact Assessment?
Article 27 does not apply to every deployer of every high-risk system. It applies to a defined subset, and most private-sector SMEs fall outside it — though not all.
- Deployers that are bodies governed by public law — for example public authorities and public agencies with these exeptions: Annex III point 2 (critical infrastructure) systems are excluded from the Article 27 obligation, and Article 6(1) product-safety high-risk systems are outside Article 27 entirely.
- Private entities providing public services, such as operators in education, healthcare, social services, housing, or the administration of justice.
- Deployers of high-risk systems used to evaluate creditworthiness or establish a credit score for natural persons, as listed in Annex III.
- Deployers of high-risk systems used for risk assessment and pricing in relation to life and health insurance for natural persons, also in Annex III.
Two practical consequences follow. First, an SME running a high-risk recruitment tool for its own hiring is a deployer with Article 26 obligations, but is not automatically in scope for Article 27. Second, an SME that delivers a service on behalf of a public body, or that scores creditworthiness, may well be in scope even though it is small and has only one or two AI systems.
As a compliance matter, the first step is therefore a scoping determination you can show: is this system high-risk, are we the deployer, and do we fall into one of the categories above? Record the reasoning, including negative findings — a documented "not in scope, because" is worth far more later than silence.
Step-by-step guidance on running the scoping determination is in the Veritome Help Center (help.veritome.eu).
How is a FRIA different from a DPIA?
A Data Protection Impact Assessment under Article 35 GDPR assesses risks arising from the processing of personal data. A FRIA assesses risks that the use of a specific high-risk AI system poses to fundamental rights generally — which includes data protection, but extends to non-discrimination, human dignity, effective remedy, access to essential services, and the rights of children, among others.
The main differences in practice
- Legal basis: Article 35 GDPR versus Article 27 of the AI Act.
- Trigger: high-risk processing of personal data versus deployment of a listed high-risk AI system by a listed category of deployer.
- Object of assessment: the processing operation versus the concrete use of the AI system in its deployment context.
- Scope of harm: risks to data subjects' rights and freedoms in relation to their data versus risks to the fundamental rights of affected persons and groups, whether or not personal data is involved.
- Output: internal record and, in some cases, consultation with the supervisory authority, versus a record plus notification of results to the market surveillance authority.
- Article 27 explicitly avoids duplication: where a DPIA has already been carried out, the FRIA is to complement it. In practice that means cross-referencing rather than copy-pasting. A system that already has a DPIA covering data minimisation, retention, and security can inherit those findings; the FRIA then adds the parts a DPIA does not reach — for example whether error rates differ across groups, whether affected people are told a decision involved an AI system, and how they can contest an outcome.
What does a defensible FRIA contain?
Article 27 sets out the elements the assessment must cover. A defensible FRIA works through each of them with specifics rather than generalities, and shows where each answer came from.
- A description of the deployer's processes in which the high-risk system will be used — the actual workflow, decision points, and where the output enters a human process.
- The period of time 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 persons or groups, taking into account the information the provider supplied under Article 13 in the instructions for use.
- A description of the human oversight measures to be implemented, according to the instructions for use.
- The measures to be taken if the identified risks materialise, including internal governance arrangements and complaint mechanisms.
What separates a strong assessment from a weak one
The weakest FRIAs describe the system and then assert that risks are low. The strongest ones do four things. They name affected groups concretely, including groups who are not customers — applicants who are rejected, family members, people whose data is used as a comparison set. They quantify where quantification is possible, drawing on the provider's Article 13 information about accuracy and known limitations rather than restating marketing claims. They tie each identified risk to a named oversight measure and a named owner. And they state clearly what would cause the organisation to pause or stop using the system.
The Article 13 instructions for use are the raw material. If the provider's documentation does not tell you the intended purpose, the accuracy levels, the known limitations, or the required human oversight measures, the assessment cannot be completed properly — and that gap is itself a finding worth recording and raising with the provider.
Keeping the FRIA a living document, not a box-ticking artefact
Article 27 requires the deployer to update the assessment where any of the elements it lists are no longer up to date. That obligation is what turns the FRIA from a pre-deployment formality into an ongoing control. The practical question is what counts as a change, and who is expected to notice.
Change triggers worth writing into your process
- A new use case, business unit, country, or population segment for an existing system.
- A provider update: a new model version, revised instructions for use, or changed stated accuracy or limitations.
- A material shift in volume or frequency of use, or a move from advisory output to a more decisive role in the process.
- Removal or weakening of a human oversight step — for example approval thresholds being raised or a review queue being automated away.
- A pattern in complaints, appeals, or overturned decisions, or a monitoring signal suggesting uneven performance across groups.
- An incident, near miss, or serious incident reported under the Regulation.
Two mechanics make this sustainable for a small team. First, version the assessment and keep the superseded versions: the audit question is rarely "is it correct today" but "when did you know, and what did you do". Second, attach each risk to a monitoring signal that someone actually looks at — a complaint volume, an override rate, an outcome distribution — so that updates are prompted by evidence rather than by a calendar reminder.
Guidance on setting up change triggers, versioning, and monitoring signals is in the Veritome Help Center (help.veritome.eu).
Timing, notification, and how to sequence the work
The obligations for high-risk AI systems, including Article 27, apply from 2 August 2026 for most systems in the Annex III categories. The assessment is to be carried out before the high-risk system is first put into use, which means the work needs to sit inside procurement and go-live processes rather than alongside them.
- Inventory the AI systems in use or planned, with the role your organisation plays for each — provider, deployer, or both.
- Classify each system: outside scope, limited-risk with transparency duties, or high-risk under Annex III or the product-safety route.
- For each high-risk system where you are the deployer, determine whether Article 27 applies to you, and record the reasoning either way.
- Collect the provider's Article 13 instructions for use and note any gaps in accuracy, limitations, or oversight information.
- Check whether a DPIA exists or is required, and plan the FRIA to complement it rather than repeat it.
- Complete the six Article 27 elements, with named owners for oversight measures and response actions.
- Notify the market surveillance authority of the results, using the template provided for that purpose.
- Set the change triggers and monitoring signals that will prompt the next update.