Building the FRIA: Turning the Fundamental Rights Impact Assessment Into a Repeatable Template

The fundamental rights impact assessment is a structured artefact, not an essay — and every team that treats it as prose produces something no regulator can audit and no colleague can repeat.

Article 27 of the EU AI Act asks certain deployers of high-risk AI systems to carry out a fundamental rights impact assessment — the FRIA — before they put the system to use. Most organisations respond by handing someone a blank document and a deadline. What comes back is a few pages of well-intentioned narrative that reads differently every time, cannot be compared across deployments, and falls apart the moment a supervisor asks to see the version that was current when a specific decision was made. The article does not ask for an essay. It enumerates fields. The engineering task is to treat those fields as a schema.

Who actually has to do this, and when

The FRIA is not a universal obligation. Under Article 27(1) it falls on deployers that are bodies governed by public law, private entities providing public services, and deployers of high-risk systems used for creditworthiness and credit scoring or for risk assessment and pricing in life and health insurance — points 5(b) and 5(c) of Annex III. If you are a bank scoring loan applicants, an insurer pricing health cover, or a public authority running an Annex III system, you are in scope. The assessment is required before first use, per Article 27(2), with the ability to rely on an earlier assessment in comparable situations and an obligation to update it when the underlying elements change.

Timing matters more than it used to. The Digital Omnibus agreed in 2026 moved the application date for stand-alone Annex III high-risk obligations to 2 December 2027, from the earlier 2 August 2026. That change takes legal effect only on formal adoption and publication in the Official Journal, so treat the date as agreed rather than final and verify it against the published text. Either way the practical point stands: the reprieve is time to build the artefact properly, and — as we have argued about the wider deadline — that reprieve is a trap if you wait to start.

What Article 27 actually enumerates

Article 27(1) lists six things the assessment must contain. Read them as field definitions, not as essay prompts:

1. The deployer’s processes in which the system will be used, in line with its intended purpose.
2. The period and frequency over which each system is intended to be used.
3. The categories of natural persons and groups likely to be affected in the specific context.
4. The specific risks of harm likely to affect those categories.
5. The human oversight measures, in line with the instructions for use.
6. The measures to be taken if those risks materialise, including internal governance and complaint mechanisms.

Six fields. Each has a clear owner in a real deployment: the process owner describes one and two, the risk and legal functions own three and four, the engineering team owns five against the vendor’s instructions for use, and governance owns six. An essay smears all of that into continuous prose and loses the ownership. A schema keeps it separated, so each field can be reviewed, challenged and signed off by the person actually accountable for it.

Turn the article into a schema

The template below maps each Article 27(1) requirement to a defined field, with controlled vocabularies where the answer should be constrained rather than free-typed. The point is not the file format — it is that a completed FRIA becomes a validated, diffable object rather than a document. The same schema thinking underpins an AI system inventory that maps to the Act’s risk tiers; the FRIA is the per-deployment record that hangs off each high-risk entry in that inventory.

# fria.schema.yaml — one record per deployment, versioned in git
system_id: inv-2024-0142            # foreign key to the AI system inventory
fria_version: 3
deployment_context:                 # Art 27(1)(a)
  process: "Retail credit application scoring"
  intended_purpose: "Rank applicant creditworthiness for manual review"
  annex_iii_point: "5(b)"
usage_profile:                      # Art 27(1)(b)
  period: "2027-12-02/ongoing"
  frequency: "~4000 decisions/month"
affected_groups:                    # Art 27(1)(c)
  - group: "First-time borrowers"
    vulnerability: elevated         # enum: standard | elevated | high
  - group: "Applicants relying on thin credit files"
    vulnerability: high
risks:                              # Art 27(1)(d)
  - id: R1
    harm: "Systematic under-scoring of thin-file applicants"
    right_engaged: non_discrimination   # enum from your rights taxonomy
    likelihood: medium             # enum: low | medium | high
    severity: high
human_oversight:                    # Art 27(1)(e)
  measures:
    - "No automated rejection; every decline routed to a reviewer"
    - "Reviewer sees top score drivers and can override with reason"
  instructions_for_use_ref: "vendor-iful-v2.pdf#p12"
mitigations:                        # Art 27(1)(f)
  - risk_ref: R1
    action: "Quarterly subgroup performance review vs approval rates"
    owner: "Head of Credit Risk"
    complaint_route: "Model decisions appealable via customer portal"
governance:
  msa_notified: false               # Art 27(3): notify market surveillance authority
  dpia_ref: "dpia-2027-0031"        # Art 27(4): FRIA complements the Art 35 GDPR DPIA
  approved_by: "Model Risk Committee"
  approved_on: "2027-11-04"

A validator turns the schema from documentation into a gate. This one refuses to accept a FRIA that leaves a risk unmitigated or an affected group unassessed — the two failures that make an assessment indefensible.

#!/usr/bin/env python3
"""Validate a FRIA record against Article 27(1) minimums before sign-off."""
import sys, yaml

REQUIRED = ["deployment_context", "usage_profile", "affected_groups",
            "risks", "human_oversight", "mitigations"]

def validate(doc):
    errors = []
    for field in REQUIRED:
        if not doc.get(field):
            errors.append(f"missing or empty field: {field}")
    covered = {m.get("risk_ref") for m in doc.get("mitigations", [])}
    for r in doc.get("risks", []):
        if r.get("id") not in covered:
            errors.append(f"risk {r.get('id')} has no mitigation (Art 27(1)(f))")
    if not doc.get("affected_groups"):
        errors.append("no affected groups identified (Art 27(1)(c))")
    return errors

if __name__ == "__main__":
    doc = yaml.safe_load(open(sys.argv[1]))
    errs = validate(doc)
    if errs:
        print("FRIA INVALID:")
        for e in errs:
            print(f"  - {e}")
        sys.exit(1)
    print(f"FRIA valid: {doc['system_id']} v{doc['fria_version']}")

Version per deployment, not per year

The discipline that makes a FRIA repeatable is the same one that makes any artefact auditable: it lives under version control, one record per deployment, and every material change bumps the version. When a supervisor asks which fundamental rights assessment was in force on the day a particular applicant was scored, you check out the commit, not a shared drive full of near-identical Word files with names like FRIA_final_v2_REVISED. This is the artefact-as-code posture we apply to generating Annex IV technical documentation from the pipeline: the compliance record is generated and versioned alongside the system, not written up afterwards from memory.

Two integration points keep it honest. Article 27(4) says that where the obligations are already met through a data protection impact assessment under Article 35 GDPR, the FRIA complements that DPIA — so the schema carries a reference to the DPIA rather than duplicating it, and the two are reviewed together. Article 27(3) requires the deployer to notify the market surveillance authority of the results using a template that the AI Office is to provide, including through an automated tool. Model the notification as a state on the record, not a task in someone’s inbox, so an unnotified FRIA is visibly incomplete.

Where teams still get it wrong

The most common failure is a FRIA written once, at go-live, and never touched again — which contradicts Article 27(2)’s duty to update when elements change. The second is a risks section with no corresponding mitigations, which reads as an admission that harms were identified and then ignored. The third is affected groups described so generically (“customers”, “the public”) that no one could tell whether a vulnerable subgroup was ever considered. A schema with enumerated fields and a validator that blocks sign-off catches all three before the assessment leaves the building.

Give a deployment team a blank document and you will get a different, unverifiable assessment every time. Give them a schema, a controlled vocabulary and a validator, and you get a FRIA that any two teams complete the same way, that versions cleanly per release, and that a regulator can actually read. The AI Office will publish its own questionnaire; build yours now so that filling in theirs is a mapping exercise, not a scramble.