A bank buys a credit-scoring model from a vendor that has done everything the law asks of a builder. The bank has bought carefully, the vendor has built carefully, and the bank still owes a substantial obligation the vendor cannot discharge for it.
That obligation is the Fundamental Rights Impact Assessment, and it is the one significant high-risk duty the EU AI Act puts on the deployer - the organisation that merely uses the system, rather than the provider that built it.
It is also, in my experience, the obligation deployers most underestimate, because it asks a kind of question their organisation has no existing process to answer.
Who actually owes one
Before anything else, the scope, because it is narrower than "every high-risk system" and getting it wrong in either direction is costly.
A FRIA is required of public bodies and of private organisations providing public services when they deploy a high-risk system, and of any deployer using AI for credit scoring or for insurance risk assessment. That last part is why this matters well beyond the public sector: a bank running an AI creditworthiness model, or an insurer pricing risk with one, owes a FRIA as the deployer, whatever the vendor has already done.
So the first question is not "how do we do a FRIA" but "are we in scope for one" - and for financial services, the answer is frequently yes.
Why it is the deployer's job, and no one else's
The logic is worth understanding, because it explains why the vendor cannot help you much. A provider building a credit-scoring model knows how the model works. It does not know how you will use it - on which population, in which decisions, with what human involvement, in what social context. The fundamental-rights impact of an AI system depends on all of that, and all of it lives with the deployer.
This is the uncomfortable core of the FRIA: it is an assessment of your specific deployment, in your specific context, on your specific affected people. A vendor's conformity work covers the system in the abstract. The FRIA covers what happens when that system meets your customers, which is knowledge only you hold, and therefore work only you can do.
What actually goes into one
The FRIA is not a form to tick.
It asks the deployer to set out, in substance:
how and for what the system will be used, and how often; which categories of people it will affect; the specific risks of harm to those people's fundamental rights; the human-oversight measures in place; and what the organisation will do if the identified risks actually occur.
Read that list again and notice what it is really asking. Not "does the model perform well" - that is the provider's conformity question. It asks: who could this hurt, how, and what is our plan when it does. That is a different intellectual exercise, and most organisations have no established way to carry it out.
Why it is genuinely hard
The difficulty is not administrative. It is that the FRIA asks an organisation to reason about rights it has never had to name.
Data protection, most firms can handle - there is a DPO, a lawful-basis framework, an established discipline. But a FRIA reaches past data protection into non-discrimination, human dignity, access to justice, freedom of expression, the broader fundamental rights the EU Charter protects.
An engineering-led organisation has metrics for accuracy and latency. It usually has nothing for "could this credit model systematically disadvantage a protected group, and how would we know" - which is exactly the question the FRIA puts at the centre.
Non-discrimination is usually the sharp end. A high-risk AI system's most likely fundamental-rights harm is that it treats some group of people worse than another, often through patterns no one designed and no one can see without looking.
Assessing that honestly means confronting the possibility that a system the business wants to deploy is unfair in a way that is hard to measure and harder to admit. That is not paperwork difficulty; it is the difficulty of asking a question you might not like the answer to.
Before deployment, and on the record
Two features of the FRIA sharpen the obligation. The first is firm: it has to be done before the system is put into use, not reconstructed afterwards, a FRIA written after a problem surfaces is not a FRIA, it is a defence.
The second is that, in the cases where the results have to go to the market surveillance authority, the FRIA stops being a document you can quietly file and becomes a statement to a regulator about the risks you identified and what you plan to do about them.
Even left as an internal assessment, the before-deployment requirement is what makes the FRIA a real commitment rather than a box. You are putting on the record, in advance, that you looked for the ways your AI could harm people and made a plan. If you did not really look, that shows, and it shows most in the cases where a regulator gets to read it.
Where the DPIA fits, briefly
If you are thinking this sounds close to a Data Protection Impact Assessment, you are right that they overlap, and the two can be combined rather than run in parallel, which is the practical path for most organisations that already have a DPIA discipline. The relationship is worth its own treatment, and our writing on GDPR documentation covers it.
The point for a FRIA is only this: the overlap is real but partial. The DPIA handles the data-protection slice; the FRIA's harder, broader questions about discrimination and dignity are the part the DPIA was never built to answer, and the part that cannot be borrowed.
The honest takeaway
I will be straight about where this leaves a deployer. There is no way to make the FRIA easy, because its difficulty is not procedural, it is the difficulty of assessing your own system for harms you would rather not find.
A template helps you structure it; it cannot do the looking for you.
What a deployer can do is treat the FRIA as what it is, a genuine risk assessment owed by the user, not a form owed to the vendor, and start it before deployment, while there is still time for the answer to change a decision.
The organisations that struggle are the ones that discover, late, that the hardest obligation in the Act was theirs all along, and that no one else could have done it for them.
Frequently asked questions
Who has to do a Fundamental Rights Impact Assessment under the EU AI Act?
Montro's reading is that a FRIA is required of public bodies and private organisations providing public services when they deploy an Annex III high-risk AI system, and of any deployer using AI for credit scoring or insurance risk assessment.
It is a deployer obligation, not a provider one, meaning even an organisation using a third-party AI tool whose vendor has met all its own obligations can owe a FRIA the vendor cannot complete on its behalf, because it turns on how and where the tool is used.
What is the difference between a FRIA and a DPIA?
A DPIA under GDPR Article 35 assesses risks arising from personal data processing; a FRIA under EU AI Act Article 27 assesses impacts on a broader set of fundamental rights, non-discrimination, dignity, access to justice - not only data protection.
They overlap where an AI tool processes personal data, and the two can be combined rather than run separately, but the FRIA's broader rights questions are not covered by a DPIA alone.
What does a FRIA have to include?
In substance: a description of how and how often the system will be used, the categories of people affected, the specific risks of harm to their fundamental rights, the human-oversight measures in place, and the steps the organisation will take if those risks materialise.
It is a substantive risk assessment of the specific deployment, not a generic form, and it has to be completed before the system is put into use.
Why is a FRIA considered difficult?
Because it asks an organisation to reason about rights it usually has no process for, particularly non-discrimination, where the likely harm is that an AI system treats some group worse than another through patterns no one intended and no one sees without looking. Most organisations have well-developed data-protection discipline but nothing equivalent for assessing broader fundamental-rights impact, which is why the FRIA is the high-risk obligation deployers most often underestimate.
