EU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA)

Structure (10 sections)

1. 1. 1. Applicability: is a FRIA actually required of us

   Art. 27(1) has a bounded scope, so settle the determination before drafting. The duty falls on deployers of high-risk AI systems referred to in Art. 6(2) that are bodies governed by public law or private entities providing public services, and on deployers of the high-risk systems referred to in points 5(b) and (c) of Annex III. High-risk systems intended to be used in the area listed in point 2 of Annex III are expressly excluded. So answer three questions: is the system high-risk within the meaning of Art. 6(2); is your organisation a public-law body or a private entity providing public services, or is the system within Annex III points 5(b) or (c); and does the point 2 exclusion apply. If the answer is that no FRIA is required, that determination is still worth filing — it is the formal answer to "have you done a FRIA?" in a customer questionnaire. Note Art. 27(2) as well: the duty attaches to first use, and in similar cases the deployer may rely on a previously conducted FRIA or on an existing impact assessment carried out by the provider.

   Evidence to attach

   • · Applicability determination answering all three questions, with assessor and date
   • · Basis for the system’s high-risk classification, taken from the provider’s technical file or instructions for use
   • · Statement of the organisation’s legal character (public-law body / private entity providing public services / other)
   • · Where an existing assessment is relied on: its source, version and the argument that the case is "similar"

   Common pitfalls

   • · Treating the FRIA as a universal duty for every high-risk deployer and doing a great deal of unnecessary work;
   • · The reverse: being a "private entity providing public services" but self-identifying as an ordinary business and doing nothing;
   • · Relying on the provider’s impact assessment without holding a copy of it or arguing that the case is similar;
   • · Concluding "not applicable" without filing the determination, leaving nothing to show in due diligence.

2. 2. 2. Description of the deployer’s processes in which the system is used (Art. 27(1)(a))

   Art. 27(1)(a) requires a description of the deployer’s processes in which the high-risk system will be used, in line with its intended purpose. The operative words are "in line with its intended purpose": transcribe the intended purpose as the provider states it in the instructions for use, then describe your actual process, and say explicitly whether the two match. Describe the process along the decision chain: where the output enters, who sees it, what decision is taken on the strength of it, what that decision does to the individual, whether a human can overturn it and how often that actually happens. Also describe the inputs that come from outside the system (human judgement, scores from other systems, historical records) and how they are combined with the model output, because fundamental-rights impact often arises in that combination rather than in the model. If your use goes beyond the provider’s stated intended purpose, note Art. 25(1)(c): changing the intended purpose can make the deployer a provider and pull the provider obligations across.

   Evidence to attach

   • · Verbatim extract of the intended purpose from the provider’s instructions for use
   • · Process map showing where the output enters and where decisions are made
   • · Roles and authority of each participant in the decision chain
   • · Override records and override rate
   • · Determination that use matches the intended purpose, or an Art. 25(1)(c) analysis if it does not

   Common pitfalls

   • · A description that stops at "the system offers a suggestion for staff to consider", with no adoption rate, so the reviewer cannot gauge the impact;
   • · Not transcribing the provider’s intended purpose, so use within scope cannot be demonstrated;
   • · Ignoring the step where the output is combined with other scores, missing the real source of impact;
   • · Having in fact changed the intended purpose (a content-moderation model repurposed for employee performance) without an Art. 25 analysis.

3. 3. 3. Period and frequency of intended use (Art. 27(1)(b))

   Art. 27(1)(b) requires a description of the period within which, and the frequency with which, each high-risk system is intended to be used. It looks clerical but supplies the denominator for every later risk judgement: the same error rate carries a very different fundamental-rights impact at fifty applications a day than at five hundred thousand. Record: the start and end of the pilot and of full operation; daily and monthly volumes and peaks; the geographies and population covered; whether it runs unattended around the clock; and the planned exit or review points. For a staged rollout, give the volume for each stage and the condition for expanding (for example "expand only if the error rate stays below X and the appeal rate below Y") — gating conditions of this kind are among the strongest evidence a reviewer accepts that risk is controlled.

   Evidence to attach

   • · Planned schedule of use periods and volumes, by stage
   • · Actual volume statistics once live, weekly or monthly
   • · Rollout gating conditions and the evidence they were met
   • · Triggers for pausing or exiting use, and who has authority to decide

   Common pitfalls

   • · "Ongoing use, called as needed", which conveys no volume information at all;
   • · Planned volumes only, never reconciled against actuals after go-live, so the assessment drifts from reality;
   • · A staged rollout with no gating conditions, i.e. a full rollout in disguise;
   • · No pause mechanism, so nobody has authority to stop the system when something goes wrong.

4. 4. 4. Categories of natural persons and groups likely to be affected (Art. 27(1)(c))

   Art. 27(1)(c) requires the categories of natural persons and groups likely to be affected by the use of the system in the specific context. Note the qualifier "in the specific context": the same CV-screening model touches entirely different groups when used for graduate hiring than for executive search. Write it in three layers: those directly affected (applicants, users, employees, patients); those indirectly affected (families of rejected applicants, third parties wrongly linked, creators whose content is taken down); and groups that may bear disproportionate impact (by age, sex, racial or ethnic origin, disability, language, migration status, socio-economic position). The third layer is the one most often left empty and the one regulators probe hardest — even where protected-characteristic data cannot be collected, say which proxy indicators or qualitative methods you use to detect disproportionate impact, and where that substitute falls short.

   Evidence to attach

   • · Affected-groups table in three layers, stating the identification method
   • · Estimated size of each group and the data source
   • · Method for detecting disproportionate impact, including proxy indicators and their limits
   • · Records of engagement with representative bodies of affected groups, where undertaken

   Common pitfalls

   • · Listing only "our users", with no breakdown along dimensions where impact may fall unevenly;
   • · Skipping disproportionate-impact analysis entirely because "we do not collect ethnicity data", with no substitute method offered;
   • · An empty indirectly-affected row, though that is often where the fundamental-rights risk actually sits;
   • · Group sizes estimated by impression, with no supporting data.

5. 5. 5. Specific risks of harm likely to impact those groups (Art. 27(1)(d))

   Art. 27(1)(d) requires the specific risks of harm likely to have an impact on the categories identified under (c), expressly taking into account the information given by the provider under Art. 13. That is what distinguishes this from an ordinary risk assessment: you must first work through what the instructions for use say about capabilities, limitations, known inaccuracies, expected accuracy and input specifications, and derive the harms in your context from that. List them row by row: the right engaged (under the EU Charter — non-discrimination, privacy and data protection, freedom of expression and information, effective remedy and a fair trial, human dignity, workers’ rights, the rights of the child) → the concrete harm scenario in this context, written as a checkable factual statement → the technical or process cause → likelihood and severity ratings → whether it is reversible. Where the provider’s information is too thin to support the assessment, record the gap and the questions you put to the provider — Arts. 25(4) and 26 give the deployer a basis for obtaining what it needs.

   Evidence to attach

   • · Harm register (right engaged, scenario, cause, likelihood, severity, reversibility)
   • · Extracts from the provider’s instructions for use and how they were interpreted
   • · Information requests put to the provider and the answers received
   • · Measured bias or error data in this deployment, where obtainable
   • · Reference to prior incidents or enforcement cases involving comparable systems

   Common pitfalls

   • · No reference at all to the information the provider supplies under Art. 13, which the text expressly requires;
   • · Harms written as abstract right names ("may affect privacy"), never narrowed to a checkable scenario;
   • · Listing only harms from system error, ignoring the structural impact the system can cause while working exactly as designed;
   • · Thin provider information with no record of having asked, so reasonable efforts cannot be shown afterwards.

6. 6. 6. Implementation of human oversight measures (Art. 27(1)(e))

   Art. 27(1)(e) requires a description of the implementation of human oversight measures according to the instructions for use. This is not a restatement of the provider’s Art. 14 design but an account of how you actually operate it. Record: who is assigned to exercise oversight and in what role; the necessary competence required by Art. 26(2), plus the training and authority you have given them (the text requires the deployer to give the necessary support and power); where oversight sits in the process and how much time it has; what information the overseer can see (output, confidence, contributing factors, any explanation); the mechanics and record-keeping for overriding an output; the measures against automation bias, i.e. over-reliance on the output; and how oversight effectiveness is measured (override rate, review duration, agreement in sampled re-reviews). Where a condition the instructions for use require cannot be met in your organisation — two-person review specified but only one reviewer available — say so and give the compensating measure rather than passing over it.

   Evidence to attach

   • · Job description and written authority for the oversight role
   • · Training records and competence assessment for the overseers
   • · Screenshots of the oversight interface, showing what the overseer actually sees
   • · Sample override records and the override rate
   • · Measures against automation bias (forced independent judgement, blind spot-checks)
   • · Report on the effectiveness of oversight

   Common pitfalls

   • · Overseers given a few seconds per case, so "human oversight" is temporally impossible;
   • · Overseers shown only the final conclusion, with no confidence score or contributing factors on which to base an override;
   • · A persistently zero override rate never investigated as an anomaly — usually a signal of automation bias;
   • · Oversight conditions required by the instructions for use not met, and not mentioned in the document.

7. 7. 7. Measures if risks materialise, internal governance and complaint mechanisms (Art. 27(1)(f))

   Art. 27(1)(f) requires the measures to be taken if the risks materialise, including the arrangements for internal governance and complaint mechanisms. Write it in three blocks. Response measures: a graded response (suspend an individual decision / suspend for a group / suspend the system), the trigger threshold and decision authority at each level, correction and remedy for decisions already made wrongly (re-review, reversal, compensation), and the external communication line. Internal governance: who bears final responsibility for this deployment, the cross-functional review mechanism, the interfaces to risk management and information security, and the escalation path with time limits. Complaint mechanism: how an individual learns they are subject to the system (tying into the Art. 26(11) information duty), the complaint entry point and the languages it accepts, acknowledgement and response deadlines, whether a complaint triggers human re-review, and how complaint data feeds back into improving the deployment. Cover too the Art. 26(5) monitoring duty, the arrangement for suspending use and informing the provider and the market surveillance authority where that provision bites, and the criteria that escalate into an Art. 73 serious-incident report.

   Evidence to attach

   • · Graded response plan (trigger threshold, action, decision authority, deadline)
   • · Governance chart and a RACI-style responsibility matrix
   • · The Art. 26(11) notice to affected individuals and where it is displayed
   • · Complaint intake process, register and response-time statistics
   • · Sample records of decisions corrected and remedies provided
   • · Process and named contacts for suspending use and informing the provider and the market surveillance authority

   Common pitfalls

   • · A complaint mechanism that is just a generic support mailbox, where the individual never learns an AI system was involved;
   • · Nobody empowered to suspend the system, the strongest action in the plan being "escalate";
   • · No retrospective correction for decisions already made wrongly, only a promise to "improve going forward";
   • · The Art. 26(11) information duty skipped, which makes the whole complaint mechanism unreachable in practice.

8. 8. 8. Interface with the GDPR data protection impact assessment (Art. 27(4))

   Art. 27(4) was replaced by Art. 1(13)(a) of Regulation (EU) 2026/1744 (the AI Omnibus). It now reads: if any of the obligations under the Article is already met through the data protection impact assessment conducted under Art. 35 of Regulation (EU) 2016/679 or Art. 27 of Directive (EU) 2016/680, the deployer **may, when conducting the fundamental rights impact assessment, include cross-references to the relevant sections of that DPIA or include relevant parts of it in the FRIA**. The pre-amendment wording — that the FRIA "shall complement" the DPIA — is gone, and quoting it flags the document as not having tracked the amendment. Art. 27(5) was replaced in the same move: the AI Office questionnaire template must, where relevant, give deployers that cross-reference option. The amendment reduces duplication rather than duty: cross-referencing only works for what the DPIA actually covers, and the rest must still be written out here. The DPIA covers risks arising from processing personal data, the FRIA covers the impact of using the system on fundamental rights, and the two overlap without coinciding. Build a mapping table: each of the six Art. 27(1) elements (a)–(f) → the DPIA section that already covers it, cited by section number so the cross-reference is real → what remains to be added here. The parts a DPIA typically does not reach include fundamental-rights impacts not involving personal data (freedom of expression, access to information), frequency and duration of use, analysis of indirectly affected groups, and the concrete internal governance and complaint arrangements. Cross-referencing the two documents cleanly is both less work and more defensible than writing each in isolation.

   Evidence to attach

   • · Mapping table from the six FRIA elements to the DPIA sections
   • · Index to the DPIA (version and date)
   • · Consistency check between the conclusions of the two documents
   • · List of the content covered only in the FRIA

   Common pitfalls

   • · Submitting a re-titled DPIA as the FRIA, where elements (b) and (f) are conspicuously missing;
   • · The two documents rating the same risk differently or reaching different conclusions;
   • · A mapping table that says only "see the DPIA" without section numbers, so nothing can be checked;
   • · Assuming a FRIA removes the need for a DPIA — Art. 27(4) only lets the FRIA cite what the DPIA already covers; the DPIA duty comes from GDPR Art. 35 and does not go away;
   • · Invoking Art. 27(4) to cross-reference the DPIA wholesale when the DPIA contains nothing answering elements (b), (c) and (f), so the cross-reference is empty.

9. 9. 9. Notifying the market surveillance authority of the results (Art. 27(3))

   Art. 27(3) requires the deployer, once the assessment is performed, to notify the market surveillance authority of its results, submitting the filled-out template referred to in Art. 27(5) as part of that notification; deployers in the situation referred to in Art. 46(1) may be exempt from the notification duty. Art. 27(5), as replaced by Art. 1(13)(b) of Regulation (EU) 2026/1744, tasks the AI Office with developing a questionnaire template, including through an automated tool, to simplify compliance, and requires that template to give deployers the option, where relevant, of cross-referencing the relevant sections of the DPIA or including relevant parts of it under Art. 27(4). Record here: the identity and contact details of the market surveillance authority in your Member State (designated under Art. 74; for Annex III points 1, 6, 7 and 8 uses in law enforcement, border management, justice and democracy, the Member State may have designated the data protection supervisory authority); the date, channel, content and acknowledgement of the notification; and, where the Art. 46(1) exemption is relied on, its basis. As at the review date of this corpus, confirm the availability and exact format of the AI Office questionnaire template directly with your Member State authority or the AI Office before notifying — do not prepare to a format you have only heard about.

   Evidence to attach

   • · Identification and contact details of the Member State market surveillance authority
   • · Record of the notification and its acknowledgement, with date and channel
   • · Copy of the completed template as submitted
   • · Where the Art. 46(1) exemption is relied on: the basis and the internal approval

   Common pitfalls

   • · Completing the FRIA but never notifying the market surveillance authority, leaving the Art. 27(3) duty unmet;
   • · Notifying the wrong authority (for several Annex III uses it may be the data protection authority rather than the general market surveillance body);
   • · Preparing to an unconfirmed template format and having the submission returned;
   • · No acknowledgement retained, so performance cannot be evidenced later.

10. 10. 10. Update triggers and re-assessment (Art. 27(2))

    Art. 27(2) provides that if, during use, the deployer considers that any of the elements listed in Art. 27(1) has changed or is no longer up to date, it must take the necessary steps to update the information. Turn "changed" into monitorable triggers: the provider ships a new version or revises the instructions for use; volume or affected population shifts materially; the business process changes (a new decision point, a shortened human step); a new harm type or a cluster of complaints appears; the oversight staff or their authority changes; relevant law or guidance is updated; the system is extended to a new geography or language. Each update records the trigger, what changed, whether the market surveillance authority must be notified again, and whether the DPIA needs updating in step. Hook the FRIA currency check into your own change-management process and into the vendor upgrade process — otherwise the update duty is almost certain to be forgotten in practice.

    Evidence to attach

    • · List of update triggers and who monitors each
    • · Version history (version, date, trigger, change summary, approver)
    • · Record of receiving and processing vendor upgrade notices
    • · Determination and record of whether re-notification to the authority was required

    Common pitfalls

    • · A FRIA frozen at go-live while the vendor has shipped three upgrades since;
    • · "The provider revised the instructions for use" missing from the trigger list, though it is the most common trigger;
    • · No determination after an update about whether re-notification is needed, with silence as the default;
    • · FRIA and DPIA updated independently, their conclusions drifting apart.