What a FRIA is — and who has to do one
A Fundamental Rights Impact Assessment (FRIA) is the EU AI Act's mechanism for making deployers think, on paper and before deployment, about how a high-risk AI system could affect the people subject to it. It sits alongside the provider's technical conformity work and asks a different question: not 'is the system built correctly?' but 'what could it do to someone's rights, and what will we do about it?'
It is not required of everyone. Article 27 applies to deployers that are bodies governed by public law or private entities providing public services, and to deployers of the Annex III §5(b) and §5(c) systems — creditworthiness and credit scoring, and risk assessment and pricing in life and health insurance. If you are a private-sector deployer outside those categories, you generally will not owe a FRIA, though Article 26 still applies.
When you must complete it
The FRIA must be done before the high-risk system is put into use. It is not a launch-week formality: it is a pre-condition of lawful deployment for the deployers in scope. Where a similar assessment already exists for a comparable use, you can rely on it, but you must keep it current — if the system's purpose, the population affected, or the oversight arrangements change, the FRIA needs to be revisited.
The six things a FRIA must contain (Article 27(1))
Article 27(1) is unusually concrete about what a FRIA has to cover. A complete assessment addresses all six points:
- (a) A description of the deployer's processes in which the high-risk AI system will be used, in line with its intended purpose.
- (b) The period of time and frequency over which the system is intended to be used.
- (c) The categories of natural persons and groups likely to be affected by its use.
- (d) The specific risks of harm likely to impact those persons or groups, taking the provider's instructions for use into account.
- (e) A description of the human oversight measures, per the instructions for use.
- (f) The measures to take if those risks materialise — including internal governance and complaint mechanisms.
Step by step: running your first FRIA
In practice, a defensible FRIA follows a predictable arc. Start by scoping the deployment precisely — which process, which decisions, which population. Pull the provider's instructions for use, because Article 27 expects you to reason from them. Then map the affected groups and the concrete harms each could face: discrimination, loss of access to a service, erosion of privacy, or a decision a person cannot contest.
For each material risk, record the human oversight measure that catches it and the fallback if it fails — who is alerted, how a person complains, and when you would pause the system. Finally, assign an owner and a review date. Veritome structures the FRIA as a guided form mapped to the six Article 27 elements, so the output is a complete record rather than a blank document.
FRIA vs DPIA: how they fit together
If the system processes personal data, you may already owe a Data Protection Impact Assessment under GDPR Article 35 — and the two assessments overlap on affected individuals and risk. Article 27(4) recognises this directly: where a DPIA already exists, the FRIA complements it, and you should not duplicate the analysis you have already done.
The practical move is to treat the DPIA as an input. Reuse the data-flow and affected-persons analysis, then extend it to the fundamental-rights questions the DPIA does not ask — non-discrimination, access to essential services, and the human-oversight and remedy measures specific to the AI system.
What you do with the result
A FRIA is not a drawer document. Under Article 27(3), once the assessment is complete, the deployer must notify the market surveillance authority of its results, submitting the filled-out template that the AI Office makes available for the purpose. Keep the FRIA, its evidence and its review history together — if a regulator asks, you want to produce the reasoning and the date it was signed, not reconstruct it.
That auditability is the point of doing the FRIA inside a system rather than a word processor: every element is timestamped, owned and re-openable, and it links to the obligations and oversight measures it references.