# Fundamental Rights Impact Assessment (FRIA) Template **Version:** 1.0 **Last Updated:** 2026-06-01 **Legal basis:** EU AI Act (Regulation (EU) 2024/1689), Article 27 **Source:** KLA Digital (kla.digital/tools/fria-generator) --- ## About This Template A Fundamental Rights Impact Assessment (FRIA) is the assessment that **deployers** of certain high-risk AI systems must complete under **Article 27** of the EU AI Act before putting the system into use. It examines how the system could affect people's fundamental rights — non-discrimination, privacy, human dignity, access to justice, and more — and documents the safeguards in place. This template reproduces the six mandatory elements of **Article 27(1)(a)–(f)**. It is provided for information only and is **not legal advice**; confirm your obligations with qualified counsel. ### Timing (status as of June 2026) - The Article 27 FRIA obligation was originally set to apply from **2 August 2026** (stand-alone Annex III high-risk systems). - The EU's **Digital Omnibus**, provisionally agreed ~7 May 2026, would defer that date to **2 December 2027** (and to **2 August 2028** for high-risk AI embedded in regulated products). - **That deferral is not yet law.** Until it is adopted and published in the Official Journal, **2 August 2026 remains the binding date**. Keep preparing on that basis and re-check the status before relying on any deadline. ### Who must complete a FRIA A FRIA is required of deployers that are: - **public bodies** or private entities **providing public services** (education, healthcare, social services, housing, justice), using high-risk AI listed in Annex III; and - **any deployer** using AI for **creditworthiness / credit scoring** (except fraud detection) or **risk assessment and pricing in life and health insurance**. --- ## How to Use This Template 1. Read the guidance under each section. 2. Replace the bracketed placeholders with your own information. 3. Complete the **risk register** (Section 4) — one row per fundamental right at risk. 4. Have the completed FRIA reviewed and approved internally, then notify the market surveillance authority of the results (Article 27(3)). If a section does not apply, say so explicitly rather than leaving it blank. Re-run the FRIA whenever the system, its context, the affected population, or the known risks change materially. > **Tip:** the interactive [FRIA generator](https://kla.digital/tools/fria-generator) fills this structure in your browser and exports a draft in Markdown or JSON. --- ## Section 1 — System Description & Intended Purpose *Article 27(1)(a)* Describe the deployer's processes in which the high-risk AI system will be used, in line with the intended purpose defined by the provider. - **AI system name and version:** [e.g. CreditScore AI v3.2] - **Provider and contact:** [provider legal name + compliance contact] - **Intended purpose (as defined by the provider):** [...] - **Deployer process where the system is used:** [...] - **Operational context and environment:** [...] > *Example:* Automated assessment of consumer creditworthiness for personal-loan applications, used in the retail-lending origination workflow to recommend approve / refer / decline outcomes to a loan officer who reviews every output. --- ## Section 2 — Duration & Frequency of Use *Article 27(1)(b)* Describe the period of time within which, and the frequency with which, the system is intended to be used. - **Planned deployment start date:** [YYYY-MM-DD] - **Expected duration:** [indefinite / fixed term / pilot] - **Frequency of use:** [continuous / periodic / event-triggered] - **Volume of decisions:** [e.g. decisions per day / month] - **Geographic scope:** [...] --- ## Section 3 — Categories of Affected Persons *Article 27(1)(c)* Identify the categories of natural persons and groups likely to be affected in the specific context. - **Persons subject to AI-driven decisions:** [...] - **Third parties indirectly affected:** [...] - **Vulnerable groups requiring special attention:** [children, elderly, persons with disabilities, minorities, non-native speakers, low digital literacy, ...] --- ## Section 4 — Specific Risks to Fundamental Rights *Article 27(1)(d)* Identify the specific risks of harm to the persons above, using the information the provider must supply under Article 13. Record each risk in the register. - **Fundamental rights potentially at risk:** [non-discrimination (Art 21), data protection (Art 8), dignity, access to essential services, ...] - **Provider information relied on (Article 13):** [Annex IV documentation, instructions for use, bias-testing results, ...] ### Risk-scoring matrix (likelihood × severity) | Likelihood ↓ / Severity → | Negligible | Minor | Moderate | Major | Catastrophic | | --- | --- | --- | --- | --- | --- | | **Rare** | Low | Low | Low | Medium | Medium | | **Unlikely** | Low | Low | Medium | Medium | High | | **Possible** | Low | Medium | Medium | High | High | | **Likely** | Medium | Medium | High | High | Critical | | **Almost certain** | Medium | High | High | Critical | Critical | ### Risk register | Fundamental right | Harm scenario | Likelihood | Severity | Risk level | Mitigation | Residual risk | | --- | --- | --- | --- | --- | --- | --- | | [right] | [harm] | [rare…almost certain] | [negligible…catastrophic] | [Low/Medium/High/Critical] | [measures] | [Low/Medium/High/Critical] | > *Worked example (credit scoring):* > > | Fundamental right | Harm scenario | Likelihood | Severity | Risk | Mitigation | Residual | > | --- | --- | --- | --- | --- | --- | --- | > | Non-discrimination (Art 21) | Historical bias and proxy variables (e.g. postcode) produce disparate decline rates. | Possible | Major | High | Quarterly disparate-impact testing; remove proxy features; human review of declines for underrepresented groups. | Medium | > | Access to essential services / property | An erroneous low score wrongly denies credit. | Unlikely | Major | Medium | Manual-assessment pathway; human override; clear adverse-action explanation. | Low | > | Protection of personal data (Art 8) | Excessive or inaccurate data degrades fairness and accuracy. | Possible | Moderate | Medium | Data-minimisation review; DPIA integration; data-quality controls (Art 10). | Low | --- ## Section 5 — Human Oversight Measures *Article 27(1)(e)* Describe how human oversight is implemented, in accordance with the instructions for use. - **Designated oversight roles:** [...] - **Intervention capabilities:** [override, request information, escalate, stop control, ...] - **Qualifications and training:** [automation-bias training, refresh cadence, ...] --- ## Section 6 — Measures if Risks Materialise: Governance & Complaints *Article 27(1)(f)* Describe the measures to be taken if the identified risks materialise, including internal governance and complaint mechanisms. - **Technical measures:** [bias audits, accuracy thresholds, logging, ...] - **Organizational measures:** [governance committee, policies, review cycles, ...] - **Complaint and redress mechanisms:** [right to human review, complaint channel, remediation SLA, fallback, ...] - **Notification to the market surveillance authority (Art 27(3)):** [notify the authority of the FRIA results, submitting the Article 27(5) template once available] --- ## Review & Approval - **Prepared by:** [name / role] — [date] - **Reviewed by (legal/compliance):** [name / role] — [date] - **Approved by:** [name / role] — [date] - **Next review due:** [date or trigger conditions] --- *This template is for general information only and does not constitute legal advice. Confirm your obligations under Article 27 of the EU AI Act with qualified counsel, and re-check the regulatory status (including the Digital Omnibus) before relying on any deadline.* *Generated by KLA Digital — kla.digital/tools/fria-generator*