Running a Fundamental Rights Impact Assessment (FRIA) from scratch

Who needs to run a FRIA?

Article 27 requires a FRIA when you are a deployer of:

• A high-risk AI system used by a public body (or by a private entity providing public services), OR
• A high-risk AI system used to evaluate creditworthiness or establish a person's credit score (Annex III §5(b)), OR
• A high-risk AI system used for risk assessment or pricing in life and health insurance (Annex III §5(c)).

For other Annex III categories the FRIA is not mandatory — but it is widely treated as best practice, and the methodology below applies regardless.

When to run it

Before deployment. The FRIA is an ex-ante exercise — its job is to surface impacts before they materialise, so you can mitigate them. Updating the FRIA is required when there's a substantial modification to the system, or when the deployment context changes materially.

The six steps

Step 1 — Scope

Define what the FRIA covers — the specific deployment, the territory, the time window, the user population. Be narrow; one FRIA per use case is cleaner than one for the system in general.

Step 2 — Affected rights

List the fundamental rights potentially engaged. The usual suspects in commercial deployments:

• Right to dignity and non-discrimination
• Right to private and family life (privacy)
• Right to protection of personal data
• Right to an effective remedy and a fair trial
• Consumer protection
• Right to work / freedom of profession (for employment-context deployments)

Step 3 — Specific harms

For each affected right, name the concrete harms the system could cause in your deployment. "Could discriminate" is not a harm; "could systematically reject credit applications from applicants in postcode X at 3× the baseline rate" is a harm. Quantify wherever possible.

Step 4 — Mitigations

For each harm, document the mitigations in place:

• Technical (model design choices, calibration, fairness constraints)
• Procedural (human-in-the-loop, escalation thresholds, appeal routes)
• Organisational (training, sign-off authority, governance committee)
• Communication (notice to affected individuals, right-to-explanation handling)

Step 5 — Monitoring

Define how you'll know if a harm starts materialising. Outcome metrics, complaint-rate triggers, periodic fairness audits, who reviews them, on what cadence, and the action threshold that triggers escalation.

Step 6 — Summary and sign-off

A short summary — risk level, residual risk after mitigation, residual-risk owner, review cadence. Signed off by a named individual with the authority to halt deployment if the residual risk is unacceptable.

What good looks like

• The document is 6–12 pages. Longer suggests scope creep; shorter suggests gaps.
• Every claimed mitigation maps to a person or a system that actually performs it.
• The monitoring plan has numbers in it (thresholds, frequencies, owners).
• The residual-risk decision is signed off by someone with the authority to halt.
• Review schedule is documented and on a calendar.

Who notifies the supervisory authority?

Where a FRIA is required under Article 27, the deployer must notify the national supervisory authority. Klarvo currently doesn't submit these notifications for you — the FRIA wizard produces the document, you handle the submission. Submission templates ship in the templates section.