Fundamental rights impact assessment under the AI Act: conducting one step by step

What the obligation asks for

Art. 27(1) of Regulation (EU) 2024/1689 requires three kinds of deployer of a high-risk AI system referred to in Art. 6(2) to perform an assessment of the impact on fundamental rights that the use of the system may produce: a body governed by public law, a private entity that provides public services, and a deployer of a system in Annex III point 5(b) or (c). Systems intended for the area of Annex III point 2 are excepted. The assessment holds six elements, Art. 27(1)(a) to (f): the deployer's processes and the context and conditions of use, the period and frequency of use, the categories of natural persons and groups likely to be affected, the specific risks of harm to those categories with the provider's Art. 13 information taken into account, the implementation of the human oversight measures according to the instructions for use, and the measures to be taken if the risks materialise, including internal governance and complaint mechanisms. Art. 27(2) applies the duty to the first use, lets the deployer rely on a previous assessment or a provider's impact assessment in a similar case, and requires an update when an element changes. Art. 27(3) requires the deployer to notify the market surveillance authority of the results with the filled-out template that the AI Office develops under Art. 27(5), with a possible exemption in the case of Art. 46(1). Art. 27(4) lets the deployer cross-reference or include the relevant parts of a data protection impact assessment; the obligation record notes that Regulation (EU) 2026/1744 added that option. The Art. 27 obligation page lists every element with its split into testable, documentation and process.

The guide covers the five testable elements of the Art. 27 record. The context and conditions of use described under Art. 27(1)(a) fall within the intended purpose and the conditions of use stated in the provider's instructions for use and technical documentation. Each risk of harm listed under Art. 27(1)(d) is tied to a category or group identified under Art. 27(1)(c) and to the accuracy, limitation and residual-risk information the provider supplies under Art. 13. The human oversight measures described under Art. 27(1)(e) are the measures in place in the deployment and match the measures in the instructions for use. The complaint mechanism described under Art. 27(1)(f) accepts a test complaint and routes it to the internal governance arrangement named in the assessment. Each cross-reference to a data protection impact assessment under Art. 27(4) resolves to a section that meets the element it is cited for. The ten documentation elements are assembled as sections of one record, and the four process elements are recorded as triggers and owners. The application date of Art. 27 is an unsettled point: under the working reading the duty applies with the Annex III package 2027-12-02Working reading, and under the alternative reading it stayed on the general application date 2026-08-02In force and already applies. A record prepared on the earlier reading also meets the later one.

Inputs

The list follows the Inputs section of the protocol page; every input is supplied by the deployer, by the provider through the deployer, or by a named protocol.

• The instructions for use under Art. 13(3), with a version identifier and the sections on intended purpose, conditions of use, accuracy, limitations, residual risks and human oversight measures.
• The technical documentation or the extract made available to the deployer, and the promotional or sales materials and statements about the system, each with a capture identifier.
• A description of each deployer process in which the system is used, with inputs, outputs and decision points, and the planned period and frequency of use per system and per process.
• The deployer's determination of its Art. 27(1) category and of the Annex III point 2 exception, as a signed memorandum or a counsel reference.
• The human oversight configuration in the deployment: role assignments, control descriptions, screenshots or configuration exports.
• The internal governance arrangement and the complaint channels, with owner roles and routes, and access to each channel for a test complaint.
• The data protection impact assessment where one exists, with section numbering, and any previous fundamental rights impact assessment or provider impact assessment relied on under Art. 27(2), with a statement of why the case is similar.
• The bias and accuracy evidence: PR-10-BIAS v1.0 and PR-15-ROB v1.0 reports where they exist, or the provider's declarations under Art. 13(3)(b) otherwise.
• The AI Office template for the notification under Art. 27(5), in the form the AI Office issues it, where issued.
• The deployer's harm likelihood and severity scale, as a table of levels with a definition and a justification per level.
• A Python environment with PyYAML, for the completeness check in step 11.

Procedure

The sequence follows the four phases of PR-27-FRIA; each step names the protocol steps it condenses and the clause or article those steps derive from. The fundamental rights impact assessment outline gives the same elements as headings for a deployer that starts from a blank document.

1. Record the deployer category, the counsel reference, the Annex III point 2 confirmation and the assessment scope.

   Record Scope record with the deployer category, the counsel reference, the Annex III point 2 confirmation, the sites, the processes, the versions and the period

   [Regulation (EU) 2024/1689, Art. 27(1); ISO/IEC 42005:2025 §5.5, scope of the assessment; PR-27-FRIA steps 1 to 4]

2. Register the instructions for use, the technical documentation, the promotional materials, the DPIA and the evidence, with version and hash.

   Record Source document register with version and hash per document, the evidence register, and the reliance record

   [Regulation (EU) 2024/1689, Art. 27(1)(a), 27(1)(d), 27(2) and 27(4); PR-27-FRIA steps 5 to 8]

3. Assign one owner role per Art. 27(1) element and record the likelihood and severity scale with a justification per level.

   Record Responsibility table with one owner role per Art. 27(1) element, and the scale justification record

   [ISO/IEC 42005:2025 §5.6, allocating responsibilities, and §5.7, thresholds and impact scales; PR-27-FRIA steps 9 and 10]

4. Open the record with one section per Art. 27(1) element, in the layout of the record example.

   Record Fundamental rights impact assessment record, six element sections opened

   [AIAssuranceLabs procedure; ISO/IEC 42005:2025 §6.2 to §6.9, documentation; PR-27-FRIA step 11]

5. Describe each process, compare its context of use with the instructions for use, and record the period and frequency.

   Record Context-of-use comparison table with a result per process, and the period and frequency record

   [Regulation (EU) 2024/1689, Art. 27(1)(a) and 27(1)(b); ISO/IEC 42005:2025 §6.6, deployment environment; PR-27-FRIA steps 12 to 15]

6. List the categories of natural persons and groups affected in each process and map each to the rights affected.

   Record Affected-groups mapping with one row per group and right

   [Regulation (EU) 2024/1689, Art. 27(1)(c); ISO/IEC 42005:2025 §6.7, interested parties, and Annex C, harms taxonomy; PR-27-FRIA steps 16 and 17]

7. Record each risk of harm against one group, one right, the Art. 13 section and the evidence or open item.

   Record Risks of harm register with group, right, Art. 13 section and evidence per row, and the open items list

   [Regulation (EU) 2024/1689, Art. 27(1)(d) and Art. 13(3)(b); PR-27-FRIA steps 18 to 21]

8. List the oversight measures from the instructions for use, observe each in the deployment, and record match or gap.

   Record Oversight comparison table with role, control, trigger and a match or gap result per measure

   [Regulation (EU) 2024/1689, Art. 27(1)(e) and Art. 13(3)(d); PR-27-FRIA steps 22 to 24]

9. Record the measures per risk, the governance arrangement and each complaint channel, then submit one synthetic test complaint per channel.

   Record Governance and complaint description, and the complaint route test record with a routed or not routed result per channel

   [Regulation (EU) 2024/1689, Art. 27(1)(f); ISO/IEC 42005:2025 §6.9, measures, and §5.12, monitoring and review; PR-27-FRIA steps 25 to 29]

10. Follow each DPIA cross-reference and record whether the cited section meets the Art. 27(1) element.

    Record Data protection impact assessment cross-reference map with a result per cross-reference and the element coverage

    [Regulation (EU) 2024/1689, Art. 27(4); PR-27-FRIA steps 30 and 33]

11. Rate each risk on the recorded scale, record the review triggers, and run the completeness check.

    Record Check results table, review trigger list, and the completeness check output

    [ISO/IEC 42005:2025 §5.9, analysing the results; Regulation (EU) 2024/1689, Art. 27(1) and 27(2); PR-27-FRIA steps 31, 32, 34 and 35]

12. Record the approval, fill the notification checklist or the Art. 46(1) exemption entry, and version the record.

    Record Approval entry, market surveillance authority notification checklist with the Art. 46(1) entry where claimed, and the versioned record with open items

    [ISO/IEC 42005:2025 §5.10, recording and reporting, and §5.11, approval; Regulation (EU) 2024/1689, Art. 27(3) and 27(5); PR-27-FRIA steps 36 to 40]

Example for step 4. The record below is a synthetic example for an invented eligibility pre-screening tool; the system name, the provider, the versions, the document identifiers, the hashes, the groups and every value are invented. The six Art. 27(1) elements are top-level keys named after their point, so that the check in step 11 can address each by name. The comments name the clause of ISO/IEC 42005:2025Published or the article each block holds. The evidence value of risk R-02 is left empty and the template field of the notification is left empty on purpose, so that the check has something to report.

# Synthetic example: fria-record.yaml for demo-eligibility-tool 1.3.0; every name, number and identifier is invented
record: fundamental-rights-impact-assessment
record_version: 2

system_information:                              # ISO/IEC 42005:2025 §6.3
  name: demo-eligibility-tool
  version: "1.3.0"
  provider: demo-provider-gmbh
  instructions_for_use: { id: IFU-1.3.0, hash: "sha256:9b1e4c7a2f0d8e6b3a5c1f9d7e2b4a6c8d0f1e3a5b7c9d1f3e5a7b9c1d3f5e7a" }
  technical_documentation: { id: TD-1.3.0-extract, hash: "sha256:2c8a6e4b0d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3b5d7f9a1c3e5b7d9f1a3c" }

scope:                                           # ISO/IEC 42005:2025 §6.2; Art. 27(1)
  deployer_category: private-entity-providing-public-services
  counsel_reference: MEMO-0007
  annex_iii_point_2_exception: not-applicable
  reliance_on_previous_assessment: none          # Art. 27(2)
  sites: [site-north, site-south]

scale:                                           # ISO/IEC 42005:2025 §5.7; set and justified by the deployer
  likelihood: [rare, occasional, frequent]
  severity: [minor, serious, severe]
  justification: SCALE-JUST-01

art_27_1_a_processes_and_context:                # Art. 27(1)(a); ISO/IEC 42005:2025 §6.6
  - process: P-01
    description: pre-screening of benefit applications before a caseworker decides
    context_of_use: applications submitted through the online portal, all sites
    intended_purpose_match: within
    source_clause: IFU-1.3.0 §2.1

art_27_1_b_period_and_frequency:                 # Art. 27(1)(b)
  period: twelve months from first use, then reviewed
  frequency: every application at intake

art_27_1_c_affected_groups:                      # Art. 27(1)(c); ISO/IEC 42005:2025 §6.7
  mapping_file: affected-groups.csv
  groups: [G-01, G-02, G-03, G-04]

art_27_1_d_risks_of_harm:                        # Art. 27(1)(d); ISO/IEC 42005:2025 §6.8
  - id: R-01
    group: G-01
    right: Charter Art. 21 non-discrimination
    art_13_section: IFU-1.3.0 §5.2 subgroup accuracy
    evidence: PR-10-BIAS-RPT-0003
    likelihood: occasional
    severity: serious
  - id: R-02
    group: G-02
    right: Charter Art. 21 non-discrimination
    art_13_section: IFU-1.3.0 §5.2 subgroup accuracy
    evidence:
    likelihood: occasional
    severity: serious

art_27_1_e_human_oversight:                      # Art. 27(1)(e); Art. 13(3)(d)
  - measure: a caseworker confirms every decline before it issues
    implemented_as: { role: caseworker, control: confirm-button, trigger: every decline }
    match: match
  - measure: the caseworker can see the three input fields that weighed most
    implemented_as: { role: caseworker, control: none-observed, trigger: none }
    match: gap

art_27_1_f_measures_if_risks_materialise:        # Art. 27(1)(f); ISO/IEC 42005:2025 §6.9
  measures:
    - risk: R-01
      measure: suspend pre-screening for the affected group and re-run its applications manually
  governance_arrangement: fairness review board, chaired by the oversight owner role
  complaint_channels:
    - channel: web-form
      test_complaint_result: routed
    - channel: front-desk-form
      test_complaint_result: not routed

dpia_cross_references:                           # Art. 27(4)
  - element: art_27_1_c_affected_groups
    dpia_section: "DPIA-2 §4.2"
    result: meets

review_triggers:                                 # Art. 27(2); ISO/IEC 42005:2025 §5.12
  - new system version or new instructions for use
  - a complaint that names a group not in the mapping
  - issue of the AI Office template under Art. 27(5)

notification:                                    # Art. 27(3); Art. 27(5)
  authority: market surveillance authority for the deployment sites
  template:
  status: prepared
  exemption_basis: none                          # Art. 46(1) where claimed

approval: { role: head of service delivery, status: draft }   # ISO/IEC 42005:2025 §5.11

Example for step 6. The mapping has one row per affected group and right, so that a group affected in two rights has two rows and each row can carry its own risk. The right column names the article of the Charter of Fundamental Rights of the European Union that the use of the system can affect; the art_13_section column names the section of the instructions for use with the accuracy, limitation or residual-risk information; the evidence column names the PR-10-BIAS v1.0 or PR-15-ROB v1.0 report or marks an open item. The groups, the sections and the report identifiers are invented.

group_id,process_id,category,right,risk_id,art_13_section,evidence
G-01,P-01,applicants with a non-EU place of birth,Charter Art. 21 non-discrimination,R-01,IFU-1.3.0 §5.2,PR-10-BIAS-RPT-0003
G-02,P-01,applicants above the state pension age,Charter Art. 21 non-discrimination,R-02,IFU-1.3.0 §5.2,none: open item for the provider
G-03,P-01,applicants with a disability,Charter Art. 26 integration of persons with disabilities,R-03,IFU-1.3.0 §5.4 limitations,PR-15-ROB-RPT-0002
G-04,P-01,all applicants,Charter Art. 47 effective remedy,R-04,IFU-1.3.0 §6 oversight,none: open item for the deployer

Example for step 11. The script loads the record, checks that each of the six Art. 27(1) elements holds content, that every risk in the register carries a group, a right, an Art. 13 section, an evidence entry and a rating, that every oversight measure has a match or gap result, that the Art. 27(1)(f) block names a governance arrangement and gives every channel a test result, and that the Art. 27(3) notification fields are present, with an Art. 46(1) basis where the status is exempt. It prints one line per failure and exits with code 1 when any check fails, so that it can run before the record is approved. It needs the PyYAML parser.

# Synthetic example: check fria-record.yaml for content under every Art. 27(1) element
# and for the Art. 27(3) notification fields.
import sys
import yaml

ELEMENTS = {
    "art_27_1_a_processes_and_context": "Art. 27(1)(a)",
    "art_27_1_b_period_and_frequency": "Art. 27(1)(b)",
    "art_27_1_c_affected_groups": "Art. 27(1)(c)",
    "art_27_1_d_risks_of_harm": "Art. 27(1)(d)",
    "art_27_1_e_human_oversight": "Art. 27(1)(e)",
    "art_27_1_f_measures_if_risks_materialise": "Art. 27(1)(f)",
}
RISK_FIELDS = ("group", "right", "art_13_section", "evidence", "likelihood", "severity")
NOTIFICATION_FIELDS = ("authority", "template", "status")


def empty(value):
    if value is None:
        return True
    if isinstance(value, (str, list, dict)):
        return len(value) == 0
    return False


with open("fria-record.yaml", encoding="utf-8") as f:
    record = yaml.safe_load(f)

failures = []

for key, ref in ELEMENTS.items():
    if empty(record.get(key)):
        failures.append("%s: no content under %s" % (ref, key))

for risk in record.get("art_27_1_d_risks_of_harm") or []:
    for field in RISK_FIELDS:
        if empty(risk.get(field)):
            failures.append("Art. 27(1)(d): risk %s has no %s" % (risk.get("id", "?"), field))

for measure in record.get("art_27_1_e_human_oversight") or []:
    if measure.get("match") not in ("match", "gap"):
        failures.append("Art. 27(1)(e): measure %r has no match or gap result" % measure.get("measure"))

block_f = record.get("art_27_1_f_measures_if_risks_materialise") or {}
if empty(block_f.get("governance_arrangement")):
    failures.append("Art. 27(1)(f): no internal governance arrangement named")
for channel in block_f.get("complaint_channels") or []:
    if channel.get("test_complaint_result") not in ("routed", "not routed"):
        failures.append("Art. 27(1)(f): channel %r has no test complaint result" % channel.get("channel"))

notification = record.get("notification") or {}
for field in NOTIFICATION_FIELDS:
    if empty(notification.get(field)):
        failures.append("Art. 27(3): notification field %s is empty" % field)
if notification.get("status") == "exempt" and empty(notification.get("exemption_basis")):
    failures.append("Art. 27(3): status exempt without an Art. 46(1) basis")

for line in failures:
    print("FAIL " + line)
present = sum(1 for key in ELEMENTS if not empty(record.get(key)))
print("%d of %d elements have content; %d failures" % (present, len(ELEMENTS), len(failures)))
sys.exit(1 if failures else 0)

On the record above the script reports two failures: risk R-02 has no evidence entry, and the notification template field is empty. The first is the open item for the provider that step 7 lists; the second is the case the Limitations section of PR-27-FRIA v1.0 covers, where the checklist follows the Art. 27(1) elements and the content of Art. 27(3) until the AI Office issues the template, and the record lists the issue of the template as a review trigger. The not routed result of the front-desk channel is not a failure of the check; it is a recorded result that the check results table in step 11 carries as a gap under Art. 27(1)(f). Every count is an output of this example, never a requirement of the Act.

A pitfall that vendor documentation omits

Questionnaire-style FRIA templates and GRC forms offer one "affected persons" field and one free-text "risks" field, and accept a record in which the affected persons are one category and the risks are a paragraph. Art. 27(1)(c) asks for the categories of natural persons and groups likely to be affected in the specific context, and Art. 27(1)(d) asks for the specific risks of harm to those categories, with the information the provider gives under Art. 13 taken into account. The obligation record for Art. 27 names the two resulting findings: affected persons are listed as one category, so no risk of harm is tied to a specific group; and risks of harm are stated without the accuracy, limitation and residual-risk information from Art. 13. A register with one row per risk, one group and one right per row and an Art. 13 section per row is the unit at which step 18 of PR-27-FRIA v1.0 records a risk, and the check in the example above fails a row that lacks any of those fields. The Limitations section of the protocol states the boundary from the other side: the protocol cannot show that the list of affected groups is complete, because the identification of interested parties under ISO/IEC 42005:2025Published depends on the deployer's knowledge of its processes and on consultation the protocol does not perform. The check shows that every listed group has a row; the claim that no group is missing stays with the deployer.

The complaint mechanism has a second gap of the same kind. A form with a "complaint channel" field accepts the name of a mailbox, and Art. 27(1)(f) asks for the arrangements for internal governance and complaint mechanisms as measures to be taken if the risks materialise. The obligation record names the finding: the complaint mechanism is named but no route from a complaint to a review of the assessment is recorded. Steps 27 to 29 of the protocol submit a synthetic test complaint through each channel, record where it arrives, and record whether the route feeds a review under clause §5.12 of ISO/IEC 42005:2025Published; the not routed result in the example is what a named channel without a route looks like in the record.

Regulation (EU) 2024/1689 sets no numeric threshold for Art. 27: no likelihood, severity or acceptance value is given for a risk of harm, and the pass criterion of every check in this guide is a consistency criterion from the text of the article. The hierarchy for the rating scale is the one the obligation record states: no harmonised standard is cited in the Official Journal as of the anchor date, so no presumption of conformity exists; no JTC 21 draft in the standards tracker addresses Art. 27; the level in use is an ISO/IEC standard, ISO/IEC 42005:2025Published, published, whose clause §5.7 places the setting of thresholds and impact scales with the organisation and sets no acceptance value; the scale is the deployer's justified choice, recorded at step 3 and applied at step 11.

What the result shows and what it does not

The record, the mapping and the check show that the assessment holds the six Art. 27(1) elements with content, that each risk is tied to a group, a right and the provider's information, that the described oversight measures were observed or recorded as gaps, that each complaint channel routed or did not route a test complaint, and that each DPIA cross-reference met or did not meet its element. The Limitations section of PR-27-FRIA v1.0 sets the boundary. The protocol cannot show that the deployer is within Art. 27(1) or that the system is high-risk under Art. 6(2), and it cannot show that a case is similar for reliance under Art. 27(2); it records the deployer's determination and the counsel reference. It cannot show that the assessment was performed before the first use; the approval entry carries the record version, and the timing of first use is a process element the deployer evidences. The test complaint shows that a channel accepts a complaint and routes it to the named arrangement, not how complaints are handled over the period of use. The cross-reference check shows that a cited DPIA section holds the content of the element it is cited for; it does not assess the DPIA against Art. 35 of Regulation (EU) 2016/679, and the FRIA vs DPIA scenario sets out the relation between the two instruments. Where no bias or accuracy report exists and the instructions for use carry no Art. 13 information, the risks stay open items; the protocol does not produce that evidence. The result is evidence for the deployer's own file, not a conformity assessment. The FRIA facilitation and evidence structuring service runs the full protocol and delivers the FRIA record in the form specified on the deliverables page, within the limits stated on what we cannot do.

Related pages

The obligation, the protocol, the related guide on the GDPR crosswalk and the hub for the deployer role are listed below; every protocol on the site is on the methodology index.

Obligations

• Art. 27

Protocols

• PR-27-FRIA v1.0

Related guides

• EU AI Act vs GDPR: differences and overlap

ICP hubs

• Deployers

Questions

+−What does Article 27 of the AI Act require?

Art. 27(1) of Regulation (EU) 2024/1689 requires the deployers it names to assess the impact on fundamental rights before the first use of a high-risk AI system referred to in Art. 6(2). The assessment holds six elements under Art. 27(1)(a) to (f). Art. 27(2) permits reliance on a previous assessment in a similar case and requires an update when an element changes. Art. 27(3) requires notification of the results to the market surveillance authority with the filled-out template. Art. 27(4) permits cross-references to a data protection impact assessment.

+−What is a fundamental rights impact assessment (FRIA)?

A fundamental rights impact assessment is the record that Art. 27 of Regulation (EU) 2024/1689 requires from the deployers it names. The record describes the deployer's processes and context of use, the period and frequency of use, the affected groups, the specific risks of harm to those groups, the human oversight measures as implemented, and the measures taken if the risks materialise. ISO/IEC 42005:2025, a published ISO/IEC standard, gives a record structure that the six elements map onto. The assessment complements a data protection impact assessment under Art. 27(4).

+−When is a fundamental rights impact assessment for high-risk AI systems performed?

Art. 27(1) and 27(2) place the assessment before the first use of the high-risk AI system, by a body governed by public law, a private entity providing public services, or a deployer of an Annex III point 5(b) or (c) system. The application date of Art. 27 is an unsettled point. Under the working reading the duty applies with the Annex III package, on the date shown on the regulation page. Under the alternative reading the duty already applies. A record prepared on the earlier reading meets both readings.

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com