Article 27 — Fundamental Rights Impact Assessment
Article 27 of the EU AI Act requires a Fundamental Rights Impact Assessment before deploying any high-risk AI system. This workbook guides your team through the trigger assessment and — if the obligation applies — all eight mandatory FRIA dimensions, producing a signed, regulatorily-complete document that satisfies the statutory requirement and stands up to supervisory scrutiny.
Overall assessment: v1.0 is structurally sound but carries four critical content gaps, three major compliance deficiencies, and four minor drafting violations that would reduce its credibility at the £97–£147 price point. v2.0 closes all identified gaps. The Regulatory Readiness score rises from 61 to 94.
Dimension F (Materialisation Likelihood) and Dimension G (Mitigation Measures) both lack the worked example panels that Dimensions A–E and H provide. At a £97 price point, every dimension must model output quality to justify the investment. A practitioner staring at a blank textarea with no worked example for the two most technically demanding sections will produce substandard output, undermining the document's regulatory credibility. Resolution in v2.0: "What Good Looks Like" examples added to both Dimension F and Dimension G.
The Dimension D guidance panel references 5 Charter articles (1, 7, 8, 21, 47). The note at the bottom states that "others may be relevant" but provides no structured mechanism for the user to document assessment of additional Charter rights. Article 27(1)(d) requires assessment of specific risks to fundamental rights — this wording does not cap the assessment at 5 rights. A supervisory authority reviewing a FRIA that contains no section for Charter Art. 12 (assembly), Art. 24 (child rights), or Art. 35 (healthcare) in contexts where those rights are engaged would treat the omission as a substantive failure. Resolution in v2.0: Additional Charter rights rows added for Arts. 11, 12, 24, 35, and 41, plus an open "Additional Right" row for legal adviser input.
The Part B progress track (circles A–H) has no JavaScript event binding. Completing a textarea does not change any circle to "done". The sticky readiness bar described in the brief is absent. At £97 this is a significant omission — the product brief requires a live completion score and the regulatory value is precisely that a user can see at a glance which dimensions are complete before signing off. Resolution in v2.0: JavaScript listeners on all write-areas and selects drive the readiness score bar and the progress-circle states in real time.
Article 27(3) of Regulation (EU) 2024/1689 requires deployers to notify the relevant national competent authority (market surveillance authority) where the FRIA identifies a significant risk of infringement of fundamental rights. No such notification requirement, no reference to the relevant competent authority, and no field prompting the user to document their notification determination appears anywhere in v1.0. This is a statutory obligation, not optional guidance. Its omission from a document sold as an Article 27 compliance tool is a critical regulatory gap. Resolution in v2.0: New Section B9 added covering Article 27(3) competent authority notification determination.
v1.0 displays the ISO/IEC 42001:2023 badge on the cover but contains no substantive mapping to the standard's AI Management System requirements. ISO/IEC 42001 Clause 8.4 (AI system impact assessment) directly corresponds to the FRIA obligation. Clause 6.1 (risks and opportunities) aligns with Dimension D. Clause 9.1 (monitoring and measurement) aligns with the review schedule. None of these alignments are documented. A DPO or CIO using this workbook to demonstrate ISO/IEC 42001 compliance will find the badge is not substantiated. Resolution in v2.0: ISO/IEC 42001:2023 alignment notes added to each relevant dimension as "Standard Alignment" sidebars.
Section B0 contains one paragraph mentioning ITIL 4 Risk Management and Service Validation and Testing practices. However: Change Management (the FRIA is a Change Enablement gate), Service Configuration Management (the AI system must be in the CMDB), and Continual Improvement (post-deployment review cycle) are all relevant ITIL 4 practices with no mapping. This is insufficient to support organisations that use ITIL 4 as their operational framework. Resolution in v2.0: ITIL 4 practice alignment panels added at B0 and at the sign-off section.
The Article 27 FRIA must be reviewed when conditions change. v1.0 sign-off item (d) references review triggers as a statement of intent but provides no structured date-and-trigger field where the reviewing team documents the next review date, the triggering conditions, and who is responsible for initiating the review. The review obligation must be documented, not merely stated. Resolution in v2.0: A structured Review Schedule block added to the Part B sign-off section with dateable fields for each review trigger.
v1.0 contains a block at the Part B header styled with a generic "notice" class and labelled "Warning — Activate Part B Only If Triggered." IEC 82079-1:2012 defines precise signal words: WARNING for potential for harm if instructions are not followed; CAUTION for potential for damage; NOTE for information. The v1.0 block is not a safety warning in the IEC sense — it is procedural guidance. Using "Warning" as a signal word for a procedural instruction violates the standard. Resolution in v2.0: All safety/procedural notices recategorised correctly: blocking conditions use WARNING with IEC-compliant styling; procedural guidance uses CAUTION; informational notes use NOTE.
ISO/IEC Directives Part 2 and ISO 10241 define: "shall" = requirement; "should" = recommendation; "may" = permission. v1.0 uses "must" (non-standard) in multiple locations (e.g., "A mitigation that is not owned…is not a mitigation: it is a wish" — strong, but non-standard for a compliance document). Resolution in v2.0: All "must" instances replaced with "shall"; all recommendations consistently use "should"; all permissions consistently use "may".
ISO 9001:2015 Clause 7.5.2 requires documented information to include version control records. The cover states v1.0 and a publication date, but there is no formal amendment history table in the Document Control section that a subsequent review could update. Resolution in v2.0: Amendment history table added to §00 Document Control.
The deployment determination in Part B sign-off instructs the user to "Circle one: APPROVED FOR DEPLOYMENT / DEFERRED." In a digital HTML document, this is a radio button interaction, not a circle instruction. The free-text approach is appropriate for a printed PDF but creates ambiguity in a digital-first workbook. Resolution in v2.0: Radio button inputs replacing the "circle one" instruction, with conditional styling that colours the sign-off block green (approved) or red (deferred).
Article 27(2) of Regulation (EU) 2024/1689 extends the FRIA obligation to certain private-sector deployers beyond public bodies — specifically, deployers whose AI system makes decisions affecting employment conditions or creditworthiness assessments. v1.0 mentions Article 27(1) and public-body scope but does not document the Article 27(2) extended scope. A private legal technology firm assessing creditworthiness in litigation finance contexts could incorrectly conclude they are not in scope. Resolution in v2.0: Article 27(2) scope note added to Section A1.
Audit conducted by: Lead Compliance & Standards Architect · WKBK-AIMS-FRIA-001 v2.0 audit · 30 August 2026 · Standards applied: Regulation (EU) 2024/1689, ISO/IEC 42001:2023, ISO/IEC Directives Part 2, ITIL 4, IEC 82079-1:2012, ISO 9001:2015
Either you confirm Article 27 is not yet triggered, or you complete the full eight-dimension FRIA before deploying a high-risk AI system.
| Version | Date | Author | Summary of Changes |
|---|---|---|---|
| 1.0 | 25 Jul 2026 | UNUS London | Initial release — Part A trigger assessment, Part B Dimensions A–H, QA checklist |
| 2.0 | 30 Aug 2026 | UNUS London | Added: Article 27(3) competent authority notification (§B9), expanded Dimension D Charter rights matrix (Arts. 11, 12, 24, 35, 41), "What Good Looks Like" for Dimensions F and G, ISO/IEC 42001:2023 alignment panels, ITIL 4 practice mapping, real-time readiness score, review schedule fields, IEC 82079-1 compliant safety nomenclature, Article 27(2) scope note, amendment history, radio-button deployment determination, prescriptive language standardised (shall/should/may) |
This workbook shall be completed in conjunction with REG-AIMS-CLASS-001 (the Annex III AI Classification Register). Part A cannot be completed without first knowing the classification outcomes recorded in that register. If your organisation has not yet completed the Annex III classification exercise, that exercise shall be completed first.
Completing this workbook produces one of two outputs — a signed non-trigger confirmation, or a completed FRIA. Both are valid, signed compliance documents.
The COLP, DPO, or the individual with statutory AI governance responsibility shall lead this exercise. Dimension D of Part B — the fundamental rights risk assessment — should involve qualified legal input. The workbook guides the assessment but does not substitute for expert judgement on the Charter rights of specific individuals.
Part A takes approximately 30 minutes. Part B takes two to four working sessions for a first-time completion, depending on the complexity of the AI system being assessed and whether a parallel Data Protection Impact Assessment is already in progress.
Part A (non-trigger confirmation): File in your AI governance pack alongside REG-AIMS-CLASS-001. Review whenever a new AI system is added or an existing system's use case materially changes.
Part B (full FRIA): The COLP and AI Risk Owner shall sign off before the high-risk AI system enters service. File alongside the full AI governance documentation pack. The completed FRIA is the system-level go/no-go gate.
This workbook depends on a completed REG-AIMS-CLASS-001 (Annex III Classification Register). Where REG-AIMS-CLASS-001 has not been completed, this workbook shall not be started. Classification precedes assessment.
Complete Part A if your Annex III classification register records Not High-Risk for all current AI systems. This produces a signed confirmation that Article 27 is not currently triggered — a document that demonstrates a considered assessment, not an omission.
Article 27 of Regulation (EU) 2024/1689 requires a FRIA only where an AI system is classified as High-Risk under Annex III. The first step is determining whether that trigger is met.
"Prior to deploying a high-risk AI system referred to in Annex III, with the exception of high-risk AI systems referred to in point 2 of Annex III, deployers that are bodies governed by public law, or private operators providing public services, as well as deployers referred to in point (a) of Article 27(2), shall perform a fundamental rights impact assessment for the high-risk AI systems referred to in Annex III."
Three elements determine whether Article 27 applies. First, the system shall be High-Risk under Annex III — the gateway confirmed in REG-AIMS-CLASS-001. Second, the deployer category matters: Article 27(1) explicitly covers bodies governed by public law and private operators providing public services. Third, even where Article 27 does not strictly apply, the FRIA represents best practice — a firm that templates a FRIA demonstrates proactive governance that regulators reward.
Article 27(2) extends the FRIA obligation beyond public bodies. Private-sector deployers are required to conduct a FRIA where they deploy AI systems in areas including: (a) creditworthiness assessments or credit scoring, (b) risk assessments in life and health insurance, or (c) employment-related decisions. If your organisation operates in any of these areas, the Article 27(2) scope shall be assessed independently of the Article 27(1) public-body gateway. Do not rely on the private-entity carve-out as a permanent shield without qualified legal advice.
Law firms using AI to assist in asylum or immigration applications (Annex III Area 7) or in legal aid eligibility assessments (Annex III Area 5) are the most likely candidates for a High-Risk classification in the legal sector. If REG-AIMS-CLASS-001 records a High-Risk outcome for any such system, Article 27 applies and Part B shall be completed before that system is used in that context.
| AI System Ref | AI System Name | Classification (from REG-AIMS-CLASS-001) | Art. 27(2) in scope? | FRIA Required? |
|---|---|---|---|---|
Replace the AI systems in the table above with your organisation's AI systems from REG-AIMS-CLASS-001. If any system shows HIGH-RISK, proceed directly to Part B and do not sign Part A. If all systems show NOT HIGH-RISK, proceed to the Part A sign-off below and set a review date of no later than 12 months from today.
A compliance programme that only documents obligations it has met creates a structural gap. An auditor will ask whether Article 27 was assessed and, if not triggered, why not. Part A is the record of that assessment. It requires one working session and costs nothing to maintain. File it — it may be the document that protects your organisation if a deployment decision is later challenged.
The organisation is not currently required to conduct an Article 27 FRIA because no AI system in use is classified as High-Risk under Annex III of Regulation (EU) 2024/1689, and no AI system falls within the extended scope of Article 27(2). This determination is effective as at [DATE] and shall remain valid until: (a) a new AI system is added to the AI system register and receives a High-Risk classification; (b) an existing AI system's use case materially changes, triggering a reclassification review; (c) the Annex III classification register is updated at annual review; or (d) any AI system is identified as falling within the Article 27(2) extended scope.
Activate Part B only if REG-AIMS-CLASS-001 records a High-Risk classification for one or more AI systems, or if Article 27(2) applies. All eight Article 27(1) dimensions shall be completed before the high-risk AI system enters service.
Part B shall only be activated if the trigger assessment in Part A identifies a High-Risk classified AI system under Article 27(1) or an extended-scope deployer under Article 27(2). Activating Part B for a system classified as Not High-Risk creates a misleading compliance record. If all AI systems are classified as Not High-Risk, and Article 27(2) does not apply, your compliance position is covered by the signed Part A confirmation.
Every Part B assessment is specific to one AI system and one use case. If two AI systems require FRIAs, two separate Part B sections shall be completed. State the AI system reference, name, and the reclassification date before completing the eight dimensions.
This FRIA is conducted in fulfilment of Article 27 of Regulation (EU) 2024/1689. It covers the specific use case for which the AI system was classified as High-Risk. It does not extend to all possible uses of the AI system — only the use case that triggered the classification. Any material extension of the use case requires a revised or supplementary FRIA.
Article 27 requires this FRIA to be completed before deployment — not after. If an AI system has already been deployed in a high-risk use case, complete Part B immediately and assess whether retroactive risk mitigation is required.
This FRIA maps to four ITIL 4 practices:
This FRIA supports conformance with ISO/IEC 42001:2023 Clause 8.4 (AI system impact assessment). Completing Part B in full constitutes the impact assessment required by Clause 8.4. The risk register entries generated in Dimension D feed Clause 6.1 (risks and opportunities). The review schedule in Part B sign-off supports Clause 9.1 (monitoring and measurement).
Complete all eight dimensions before signing off Part B. All dimensions shall contain substantive responses.
Article 27(1)(a) requires you to describe what the AI system does within your organisation's workflow — who operates it, whose decisions it informs, and how many people are affected. This is the factual foundation from which all subsequent dimensions flow. A good Dimension A is specific and operational: not a vendor product description, but an account of what your organisation actually does with the system.
Think about: which teams use the system, how often it is used, what input it receives, what output it produces, and which decisions or actions that output informs. Include any controls already in place before output is acted upon.
"The COLP uses GPT-4o via the OpenAI API to generate initial eligibility assessments for legal aid applications. The system receives a client matter summary prepared by a trainee solicitor and produces a structured assessment categorising the matter as eligible, potentially eligible, or ineligible. This output is reviewed by a qualified solicitor before being communicated to the client. Approximately 40 assessments per month are processed this way."
The process description in Dimension A shall align with the AI system record held under ISO/IEC 42001 Clause 8.3. If your organisation maintains an AIMS, the system record and this Dimension A description shall be consistent and cross-referenced.
Describe your organisation's deployment of the AI system identified above. Cover: which teams or individuals operate it, what information is fed into it, what it produces as output, and which decisions that output informs. Be specific — one operational paragraph, not a vendor description.
Dimension B documents two things: the time period during which the AI system will be used in the high-risk deployment (start date and planned end date, or "ongoing until decommission"), and how frequently it is used. Frequency matters because it determines the volume of potential rights impacts. A system used once a year has a fundamentally different risk profile from one used for every client interaction.
If you plan to scale use — for example, moving from a pilot to firm-wide deployment — document both current and planned frequency. A significant scale-up may warrant a supplementary FRIA before it takes effect.
"Deployment period: ongoing from 1 August 2026 until decommissioned or reclassified. Current frequency: approximately 40 assessments per month. Planned frequency: up to 120 per month following firm-wide rollout in Q1 2027. The COLP will review frequency quarterly and conduct a supplementary FRIA if monthly volume exceeds 200 assessments."
State the deployment period and current use frequency. If a scale-up is planned, document the planned frequency and any supplementary FRIA trigger.
Dimension C identifies every category of natural person — every individual — whose rights or interests may be influenced by the AI system's outputs. This is not just the fee earner or analyst using the system. It includes clients, third parties named in documents, and any other person whose life circumstances the AI system's output might affect.
Article 27(1)(c) requires particular attention to vulnerability factors. Your assessment shall consider whether affected persons include: individuals in financial distress, individuals with limited literacy or language barriers, elderly persons, minors, individuals involved in asylum or immigration proceedings, individuals with mental health conditions, or individuals in legal proceedings where the stakes are high.
"Category 1: Legal aid applicants (clients) — estimated 40 per month. Vulnerability factors: financial vulnerability (below legal aid income threshold), potential language barrier, limited legal literacy. Category 2: Third parties named in applications — variable. Vulnerability factors: case-specific. Category 3: Family members of applicants — may be affected by eligibility outcomes without being parties to the matter."
List every category of natural person affected. For each category: (1) who they are, (2) estimated numbers, (3) any vulnerability factors.
Dimension D is the core of the FRIA and its most complex section. Article 27(1)(d) requires you to assess the specific risks of harm to fundamental rights posed by the AI system in your deployment context. This assessment is structured around the EU Charter of Fundamental Rights.
For each fundamental right potentially at risk, assess: (1) the nature of the risk — how could the AI system harm this right in your specific deployment? (2) the likelihood — how probable is a harmful outcome, given current controls? (3) the severity — if a harm occurred, how serious would it be? (4) the residual risk rating — after accounting for existing controls, is the risk LOW, MEDIUM, or HIGH?
Any Dimension D risk rated HIGH residual risk is a blocking condition on the Part B deployment approval. Part B cannot be signed off while an open HIGH residual risk exists. That risk shall either be mitigated (documented in Dimension G) or the AI system shall not be deployed in the high-risk use case.
| Fundamental Right | Charter | Why It Matters in AI Deployment | Key Risk Scenario |
|---|---|---|---|
| Human Dignity | Art. 1 | AI outputs that demean, dehumanise, or produce discriminatory characterisations | AI-generated matter summaries using stereotyped or reductive language |
| Freedom of Expression & Information | Art. 11 | AI systems that restrict information flow or produce biased information filtering | AI legal research tool consistently omitting relevant case law |
| Freedom of Assembly & Association | Art. 12 | AI processing political or union association data to inform decisions | AI systems processing employment data that reveals trade union membership |
| Privacy and Family Life | Art. 7 | Client confidential information processed through AI APIs; inference data retained by providers | Client communications passed to AI system without adequate data processing controls |
| Data Protection | Art. 8 | Personal data of clients and third parties; lawful basis for AI-assisted processing; data subject rights | AI system processes special category data without explicit legal basis |
| Non-Discrimination | Art. 21 | AI trained on biased data may produce systematically different quality outputs for different groups | Legal research AI surfacing less case law for matters involving ethnic minority clients |
| Rights of the Child | Art. 24 | AI decisions affecting minors require enhanced scrutiny; best interests principle applies | Family law AI making residence recommendation outputs that affect children |
| Healthcare | Art. 35 | AI processing health data or informing health-related decisions | AI insurance risk assessment using inferred health data without disclosure |
| Good Administration | Art. 41 | Right to have matters handled impartially, fairly, and within a reasonable time; right to reasons | AI-assisted administrative decision communicated without explanation of AI involvement |
| Effective Remedy | Art. 47 | Persons affected by AI-assisted decisions shall have access to explanation and recourse | AI-generated eligibility assessment communicated without disclosure or right of challenge |
Assess each right below against your specific deployment context. Where a Charter right is genuinely not engaged by the AI system's outputs in your deployment, state this explicitly with the basis for that determination. Do not leave any row blank. Your qualified legal adviser shall confirm which rights require substantive assessment in your specific context.
Each HIGH or MEDIUM residual risk identified in this Dimension shall be entered into the organisation's AI risk register under ISO/IEC 42001:2023 Clause 6.1. The risk register entry shall cross-reference this FRIA by document ID and version.
For each Charter right: describe the risk in your deployment context, then set the likelihood, severity, and residual risk. All rows shall be completed — state "Not engaged" with basis where applicable.
Dimension E documents the human oversight controls in place before and after the AI system produces its output. Article 27(1)(e) requires you to describe the specific measures that ensure a qualified human being reviews, validates, or can override the AI system's output before it is communicated to, or acts upon, an affected person.
Human oversight is not just about having a human in the loop — it is about having the right human, with the right information, with enough time to exercise genuine judgement. A lawyer who rubber-stamps AI output in 30 seconds is not exercising meaningful oversight. Describe the specific review process: who reviews, what criteria they apply, how long the review takes on average, and what happens when they disagree with the AI output.
"All AI-generated eligibility assessments are reviewed by a solicitor with at least 2 years' post-qualification experience in legal aid before being communicated to the client. The reviewer checks: (1) that the legal aid criteria applied match the current Legal Aid Agency guidance, (2) that no special circumstance of the client has been overlooked, and (3) that the output does not contain any factual error about the client's matter. The reviewer may override or amend the AI output and is required to document the basis for any amendment. Average review time: 12 minutes."
The oversight measures described in Dimension E shall align with and reference the Human-in-the-Loop (HITL) procedure PROC-AIMS-HITL-001. ISO/IEC 42001 Clause 8.5 requires documented human oversight arrangements as part of the AI management system.
Describe the human oversight process for this AI system. State: who reviews the AI output, what qualifications or experience they have, what specific checks they perform, how long review takes on average, and what happens when the reviewer disagrees with the AI output.
Dimension F requires a narrative assessment of how likely it is that the risks identified in Dimension D will actually materialise into harm. This is distinct from the residual risk ratings in Dimension D — those capture the current risk level. Dimension F asks you to reason about the pathway from risk to harm: what would need to go wrong, and how probable is that sequence?
Consider: the current volume of AI-assisted decisions (from Dimension B), the strength of the human oversight controls (from Dimension E), the vulnerability of affected persons (from Dimension C), and any known failure modes of the specific AI system being deployed. A system processing 40 low-stakes assessments per month with strong solicitor review has a fundamentally different materialisation profile from one processing 4,000 high-stakes decisions with automated output delivery.
Your Dimension F analysis should also address: system-specific failure modes documented by the AI provider (hallucination rates, known bias patterns), the probability of oversight failure (what percentage of reviews actually catch errors), and cumulative risk at scale (small per-case probability multiplied by high volume).
"The most likely pathway to materialisation of fundamental rights harm in this deployment is: (1) the AI system produces an incorrect eligibility assessment (estimated AI error rate: 3–5% based on provider benchmarks), (2) the reviewing solicitor does not catch the error during the 12-minute review (estimated solicitor catch-rate: 90%), and (3) the client is incorrectly denied legal aid. The combined probability of all three steps occurring for any individual case is approximately 0.3–0.5% (3–5% × 10%). At current volumes of 40 cases/month, the expected frequency of an uncorrected AI error reaching a client is approximately 0.1–0.2 cases per month, or 1–2 per year. This is assessed as MEDIUM risk — low per-case probability but real at annual volume. The primary risk reduction lever is improving solicitor review thoroughness and documenting the catch-rate through quarterly audits."
The materialisation analysis in Dimension F constitutes the likelihood assessment required under ISO/IEC 42001 Clause 6.1. Where quantitative estimates are used (error rates, catch-rates), the source of those estimates shall be documented. Where only qualitative assessments are available, the basis for each assessment shall be stated.
Describe the most likely pathway from the risks in Dimension D to actual harm to an affected person. State: the specific failure sequence, quantitative estimates where available, the factors that increase or decrease probability, and your overall assessment of materialisation likelihood at current volumes.
Dimension G is the action section. For every MEDIUM or HIGH residual risk identified in Dimension D, a specific mitigation measure shall be documented here. The measure shall be concrete, owned, and dated — not a general statement of intent. A mitigation that is not owned by a named individual with a completion deadline is not a mitigation: it is an aspiration.
A HIGH residual risk in Dimension D that remains unmitigated at the time of Part B sign-off is a blocking condition on deployment. The AI system shall not enter service in the high-risk use case until the mitigation is in place and the residual risk has been reassessed and recorded.
If Dimension D identified no MEDIUM or HIGH risks, state this explicitly in the table below with the basis for that assessment. Do not leave Dimension G blank — a blank Dimension G is treated as an unexamined section by any auditor reviewing this document.
"Charter Right: Art. 21 (Non-Discrimination). Risk: AI system produces lower-quality eligibility assessments for applicants whose matter summaries are written in non-standard English, creating differential quality correlated with language background. Mitigation: Introduce a standardised matter summary template (Form AIMS-TEMPL-003) that structures input in a format the AI system handles consistently. Supplementary measure: Quarterly output quality audit sampling 10% of cases, stratified by language background of applicant. Owner: COLP [Name]. Completion date: 30 September 2026. Status: In Progress."
Each mitigation measure in Dimension G constitutes a risk treatment action under ISO/IEC 42001 Clause 6.1.3. Closed actions shall be verified before the Dimension G entry is marked "Closed". Open actions with a future completion date shall be flagged in the organisation's risk register as outstanding treatment actions.
Complete one row per identified MEDIUM or HIGH risk from Dimension D. If all Dimension D risks are LOW or Not Engaged, state this in the first row with the assessment basis. Mitigation measures shall be specific, owned, and dated.
| Charter Right at Risk | Risk Description (brief) | Mitigation Measure | Owner | Completion Date | Post-Mitigation Risk | Status |
|---|---|---|---|---|---|---|
Dimension H documents the relationship between this FRIA and any Data Protection Impact Assessment (DPIA) conducted under Article 35 of the UK GDPR or EU GDPR. The two assessments are complementary but distinct. The DPIA focuses on personal data processing risks to data subjects. The FRIA focuses on the broader fundamental rights impacts of the AI system. Where both are required, they shall be coordinated — not duplicated, and not confused with each other.
If a DPIA has been conducted for the same AI system and use case, state the DPIA reference and confirm that the data protection risks identified in the DPIA are reflected in Dimension D of this FRIA under Charter Art. 8 where appropriate. If no DPIA is required, state the basis for that determination.
"A DPIA has been conducted for this AI system under UK GDPR Art. 35: reference DPIA-AIMS-SYS-001 v1.0, dated 12 July 2026. The DPIA identified two high-risk data processing activities — processing of immigration history data and processing of health data relating to legal aid applicants. Both risks are reflected in Dimension D of this FRIA under Charter Art. 8 (Data Protection) and Art. 35 (Healthcare). The DPIA and FRIA are filed together in the AI governance pack. No duplication of risk assessment has occurred — the DPIA covers data processing risks; the FRIA covers the broader fundamental rights impacts including non-discrimination and effective remedy risks not within the DPIA's scope."
State whether a DPIA has been conducted for this AI system and use case. If yes: provide the DPIA reference and confirm how it coordinates with this FRIA. If no: state the basis for that determination.
"Where deployers identify, in the course of this fundamental rights impact assessment, a significant risk of infringement of fundamental rights, they shall notify the relevant market surveillance authority."
Article 27(3) creates a statutory notification obligation where the FRIA identifies a significant risk of infringement of fundamental rights. This obligation is separate from and in addition to the obligation to complete the FRIA itself. The determination whether to notify shall be documented here — both a decision to notify and a decision not to notify require a written basis.
The Article 27(3) threshold is "significant risk" — which is higher than the MEDIUM risk threshold in Dimension D, but the standard is not defined in the Regulation with precision. Where Dimension D contains any HIGH residual risk that is not fully mitigated, the notification threshold should be treated as presumptively met and qualified legal advice sought before deciding not to notify.
For UK organisations deploying AI systems subject to the EU AI Act extraterritorial scope: the relevant market surveillance authority is determined by the member state where the affected persons are located. For England-based organisations primarily deploying within the UK: monitor the ICO and DSIT for designation of the UK national competent AI authority (anticipated 2026–2027). For EU-facing deployments, identify the relevant national competent authority in each member state where the AI system operates.
Step 1 — Review Dimension D outcomes. Does any Charter right show a HIGH residual risk, or does the cumulative analysis in Dimension F suggest a significant risk of rights infringement at current scale?
Step 2 — Document the notification determination with its basis.
Before completing the sign-off below, confirm the status of all eight dimensions and the Article 27(3) notification determination. All dimensions shall be completed. No dimension may be left blank. Any HIGH residual risk in Dimension D shall either be mitigated to MEDIUM or LOW in Dimension G, or shall result in a Deferred determination below.
The review schedule below constitutes the FRIA's Continual Improvement cycle. Each triggered review shall be initiated as a Continual Improvement action and the updated FRIA filed in the AI governance pack before the trigger deadline passes.
The review triggers below satisfy the monitoring and measurement obligation under ISO/IEC 42001 Clause 9.1 for this AI system. Annual review is the minimum; triggered reviews are mandatory when conditions change.
| Review Trigger | Review Deadline | Review Owner | Status |
|---|---|---|---|
| Annual scheduled review | |||
| Material change to AI system use case | |||
| Deployment volume increase >50% in rolling 12-month period | |||
| Regulatory investigation or incident | |||
| Annex III reclassification of this AI system |
Before filing this document, confirm each item below. A document filed with any item unchecked is incomplete. This checklist is the last gate before the FRIA is treated as a compliance record.
| # | Check Item | Part | Status |
|---|---|---|---|
| 01 | All placeholder text has been replaced with organisation-specific information | All | |
| 02 | REG-AIMS-CLASS-001 has been reviewed and classification outcomes are current | A1 | |
| 03 | Article 27(2) extended scope has been assessed (creditworthiness, insurance, employment AI) | A1 | |
| 04 | Part A sign-off has been completed and dated (if no High-Risk systems) | A2 | |
| 05 | All eight Part B dimensions are complete with substantive responses (if High-Risk system identified) | B-A to B-H | |
| 06 | All Charter rights in Dimension D have been assessed — including Arts. 11, 12, 24, 35, 41 | B-D | |
| 07 | No Dimension D field shows HIGH residual risk without a closed Dimension G mitigation action | B-D, B-G | |
| 08 | DPIA coordination has been confirmed in Dimension H | B-H | |
| 09 | Article 27(3) competent authority notification determination has been completed in §B9 | B9 | |
| 10 | FRIA review schedule is complete with dated triggers and named owners | Sign-Off | |
| 11 | Part B sign-off has been completed by both COLP and AI Risk Owner | Sign-Off | |
| 12 | FRIA filed in AI governance pack alongside REG-AIMS-CLASS-001, DPIA (if applicable), PROC-AIMS-HITL-001 | All |
This workbook is part of a six-module programme covering every statutory obligation the EU AI Act creates for organisations deploying AI systems. From Annex III classification to GPAI verification — the complete toolkit.
Visit the Governance Academy