The Assessment the Buyer Owes and Only the Vendor Can Answer

A Narrow Obligation That Is Widely Misread

The FRIA does not attach to every high-risk system, and it does not attach to everyone touching one. It reaches deployers that are public bodies or private entities delivering public services, plus private deployers using high-risk systems for creditworthiness evaluation and for risk assessment and pricing in life and health insurance.

Two consequences follow that people get wrong in both directions. A large software company building an HR screening tool does not owe a FRIA for it, however high-risk the tool is — it owes provider obligations instead. And a mid-sized lender that bought a scoring product off the shelf does owe one, even though it wrote no models and considers itself a customer rather than an AI operator.

The population that owes it, in other words, is disproportionately made up of organisations with no AI governance function, buying from vendors who have one.

What the Document Has to Establish

The required content is unusually concrete for a rights instrument, and each element is a question about your deployment rather than about the technology:

• The processes it sits in. Not "we use an AI scoring tool" but where in the decision flow the output lands, what it replaces, and what happens next to the person.
• Period and frequency of use. Continuous scoring of every applicant is a different risk profile from a pilot on one product line, and the assessment should describe the one you are actually running.
• Categories of persons affected. Including those affected indirectly, and specifically any group likely to be disproportionately represented among adverse outcomes.
• Specific risks of harm. Named harms to named groups — a declined facility, a priced-out policy, an eligibility refusal — rather than a generic reference to bias.
• Human oversight measures. What the reviewer sees, what authority they have to depart from the output, and what evidence exists that they use it. An oversight claim with a ninety-nine percent acceptance rate documents its own failure.
• Response measures. What you do when a risk materialises: internal governance, escalation, and the complaint route available to the affected person.

Reusing the DPIA Without Pretending It Suffices

Where a data protection impact assessment already exists for the same processing, the FRIA is expected to complement it rather than duplicate it, and running them as one exercise is sensible. But the overlap is partial in a specific way: a DPIA is organised around processing operations and data subjects' privacy risk, while the FRIA is organised around a use context and the full range of rights that can be affected by it.

In practice the fields that survive from a DPIA are the data flows, the categories of data, the security measures and the retention position. The fields that do not are the affected-groups analysis beyond data subjects, the harm-by-group risk statement, the oversight-effectiveness evidence and the remedy mechanism. If your combined document contains only the first list, it is a DPIA with a new title.

The Vendor Documentation Gap

Here is the structural problem. The deployer owes the assessment, but four of the six elements above depend on facts only the provider holds: how the system performs, where its accuracy degrades, how it behaves under uncertainty, and what an operator can actually see and change. Deployers who ask for this get marketing collateral, a model card written for engineers, or a refusal on trade-secret grounds.

For vendors selling into EU financial services, insurance or the public sector, this is a commercial opportunity that most are treating as a compliance chore. A standing deployer support pack — intended purpose, limitations, measured performance including subgroup variation, uncertainty behaviour, oversight surface, interpretation guidance, change notification commitments — turns a six-week procurement stall into an attachment.

The change notification piece is the one vendors underrate. The deployer's assessment must be kept current, so a silent model update breaks their compliance, not just their expectations. A contractual commitment to notify material model changes is worth more to a regulated buyer than most feature roadmap items.

A Workable Sequence

1. Establish your role first. Provider, deployer, or both. Buying a system and putting your own brand on it can move you into provider territory, which changes the entire obligation set.
2. Confirm the use case is in scope. Creditworthiness and life or health insurance pricing for private deployers; public service delivery for the rest. Adjacent uses may be high-risk without triggering a FRIA.
3. Pull the existing DPIA. Harvest the reusable sections rather than starting blank, then mark the gaps explicitly.
4. Send the vendor a fixed question set. The same one every time, derived from the elements above, so answers are comparable across products and renewals.
5. Test the oversight claim with data. Override rates by reviewer and by outcome. This is the element most likely to be challenged and the only one you can evidence from your own systems.
6. Set a review trigger, not a review date. Model version change, scope expansion, new customer segment, or a shift in override rate — any of which makes the current assessment stale.

Common Questions