FRIA facilitation and evidence structuring

Deliverables

The four deliverables answer what a market surveillance authority receives under Art. 27(3) and what the deployer holds under Art. 27(1) and Art. 27(2): a structured record of the six elements with the risks of harm register, a mapping of affected groups to rights and risks, a description of the oversight and complaint arrangements as observed in the deployment, and a checklist against the AI Office template for the notification. The specifications and synthetic samples are on the deliverables page, under FRIA record for the record and the mapping, assessment memo for the oversight and complaint-handling description, and register or checklist for the notification checklist.

Who this is for

• Deployers

A body governed by public law, a private entity that provides public services, or a deployer of a creditworthiness or insurance-pricing system under Annex III point 5(b) or (c) bought or licensed a high-risk AI system, for example a benefits-eligibility tool, a credit model or a claims-triage engine, and uses it in its own decisions. Art. 27(1) asks that deployer to assess the impact on fundamental rights before first use, alongside the operational duties under Art. 26. A data protection impact assessment often exists already, and the relation between the two records is what Art. 27(4) settles: the FRIA complements the DPIA and may cross-reference it. The evidence a deployer needs here shows that the affected people and their risks have been examined against what the provider declared, and that the oversight and complaint arrangements named in the record exist in the deployment. The scope limits of the service are stated on what we cannot do.

The applicability date of Art. 27 is an unsettled point; the working reading, shown below with its source, follows the Annex III application date for systems classified under Art. 6(2), and the alternative reading is rendered in the Scope section.

• 2027-12-02Working readingArticle 27 FRIA applicability date

Scope

The engagement covers one high-risk AI system in one deployer organisation at the point of its first use, or at an update of an existing assessment under Art. 27(2). On the record side the scope is the six elements of Art. 27(1): the deployer's processes with the context and conditions of use, the period and frequency of use, the categories of persons and groups likely to be affected, the specific risks of harm per category, the implementation of human oversight measures, and the measures to be taken if a risk materialises, including the internal governance arrangement and the complaint mechanism. On the check side the scope is the five elements with an observable result: the described context of use against the intended purpose and conditions in the instructions for use, each risk of harm against its affected group and the accuracy, limitation and residual-risk information the provider supplies under Art. 13, the described oversight measures against the measures in place, the complaint mechanism with a synthetic test complaint, and each cross-reference to a data protection impact assessment against the section it cites. The notification checklist covers the Art. 27(3) submission against the AI Office template under Art. 27(5) where the template is issued, and against the Art. 27(1) elements where it is not.

The process and the record structure come from ISO/IEC 42005:2025Published, a published ISO/IEC standard: its clauses on scope, affected interested parties, potential harms and benefits, mitigations and review triggers give the sections of the record, and the six Art. 27(1) elements map onto them. No harmonised standard covers the fundamental rights impact assessment, and no harmonised standard is cited in the Official Journal as of the anchor date, so no presumption of conformity attaches to the record; the standard is evidence of the state of the art, and its stage and source are on the standards page.

The engagement does not decide whether the deployer falls within one of the three categories in Art. 27(1), whether the system is high-risk under Art. 6(2), or whether the Annex III point 2 exception applies; the protocol records the deployer's determination and the counsel reference behind it, and Classification and readiness assessment produces a reasoned classification memo where none exists. It does not decide whether a case is similar enough for reliance on a previous assessment under Art. 27(2). It does not produce bias or accuracy evidence: the risks of harm register integrates the outputs of PR-10-BIAS v1.0 and PR-15-ROB v1.0 where they exist and the provider's Art. 13(3) declarations otherwise, and where neither exists the risk stays an open item in the register. It does not perform or assess the data protection impact assessment, and it does not test the oversight controls themselves, which Logging and human-oversight verification covers under Art. 14 and Art. 26. The record and the checks are evidence for the deployer's file and for the notification to the market surveillance authority; whether the assessment meets Art. 27 remains a decision of the deployer and its counsel.

The application date of the duty is the point below. Under the working reading the assessment is due before first use once the Annex III date is reached; under the alternative reading the duty already applies, and a record prepared on that reading also meets the working reading.

What we test

The table lists every testable element of the Art. 27 obligation record, the protocol that produces the observable result, and the artifacts it produces for 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. The protocol takes its criterion from the highest level available in a six-level hierarchy: a harmonised standard cited in the Official Journal, of which none exists as of the anchor date; a JTC 21 draft standard, stated with its stage, of which none covers this article; an ISO/IEC standard or technical report; a Commission guideline or code of practice; NIST AI RMF or a sector framework; and the state of the art that the deployer justifies and documents. For this service the level in use is the third: ISO/IEC 42005:2025Published supplies the process and the structure of the record but sets no acceptance value. The deployer sets its own harm likelihood and severity scale and justifies it against the context of use and the affected groups; the scale-justification step of PR-27-FRIA v1.0 records that justification, and the check results show whether each described element matches what the provider declared and what the deployment holds.

Protocols used

One published protocol covers the service, at the version shown.

• PR-27-FRIA v1.0FRIA facilitation protocolv1.0

PR-27-FRIA v1.0 covers the scope record with the deployer's category determination, the assembly of the six Art. 27(1) elements in the clause order of ISO/IEC 42005:2025Published, the five checks with an observable result, the review triggers under Art. 27(2) and the notification checklist under Art. 27(3). It produces the fundamental rights impact assessment record, the deployment process and context-of-use description, the affected persons and groups mapping, the risks of harm register with the Art. 13 information cross-referenced, the human oversight implementation description, the internal governance and complaint mechanism description, the data protection impact assessment cross-reference map and the notification record. It cannot show that the deployer is within Art. 27(1), that the system is high-risk, that a case is similar for reliance under Art. 27(2), that the list of affected groups is complete, or that the assessment was performed before first use; the test complaint shows that a channel accepts and routes a complaint on the test date, and the handling of complaints over the period of use is outside the check.

Engagement shape

The engagement is fixed-scope, scoped per request. The entry service, Classification and readiness assessment, is the usual starting point where the deployer's role, the Art. 27(1) category or the risk tier of the system is not yet established. The client provides the instructions for use and the technical documentation received from the provider, the promotional or sales materials that describe the system, the description of each process in which the system is used with its period and frequency of use, the deployer's category determination with its counsel reference, the human oversight configuration of the deployment, the internal governance arrangement with access to each complaint channel, the data protection impact assessment where one exists, any previous assessment relied on under Art. 27(2), the bias and accuracy evidence or the provider's declarations, and its harm likelihood and severity scale with a justification per level. The work follows the order of the protocol: preparation sets the scope, records the category determination and the scale, and builds the affected-groups mapping; execution runs the context-of-use comparison, the risks of harm register, the oversight observation, the test complaint and the cross-reference check; analysis classifies each gap by element and article; reporting assembles the four deliverables with the protocol deviation log and the handover manifest.

What we cannot do

• We do not perform conformity assessments where a notified body is required.
• We do not issue CE marking or the EU Declaration of Conformity.
• We are not a notified body.
• We do not give legal opinions on classification or liability.
• We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.

Read the full statement

For this service the record and the checks show what the deployer has described, whether each description matches the provider's information and the deployment, and what the notification to the market surveillance authority holds. The record is an input to the deployer's file; the determination that the deployer is within Art. 27(1) and the notification itself remain acts of the deployer.

What the client must have ready

The documentation and process elements below are inputs to the checks and are assembled into the record, not tested.

The process descriptions are accepted as a document or a diagram with inputs, outputs and decision points; the period and frequency of use as a table with one row per system and process; the oversight configuration as role assignments, control descriptions, screenshots or configuration exports; the data protection impact assessment as a document with section numbering, so that each cross-reference under Art. 27(4) resolves to a numbered section.

Questions

+−What is an FRIA?

A fundamental rights impact assessment is the assessment that Art. 27(1) of Regulation (EU) 2024/1689 requires from certain deployers of a high-risk AI system before first use. The record describes the deployer's processes and context of use, the period and frequency, the persons and groups likely to be affected, the specific risks of harm to them, the human oversight measures in place, and the measures taken if a risk materialises, including a complaint mechanism. PR-27-FRIA assembles the six elements into one record aligned to ISO/IEC 42005:2025, a published standard.

+−Who must conduct a FRIA?

Art. 27(1) places the duty on three kinds of deployer of a high-risk AI system under Art. 6(2): a body governed by public law, a private entity that provides public services, and a deployer of a creditworthiness or life and health insurance pricing system under Annex III point 5(b) or (c). Systems intended for the area of Annex III point 2 are excepted. The provider carries no duty under Art. 27. PR-27-FRIA records the deployer's category determination and the counsel reference behind it and does not make that determination.

+−What are the FRIA requirements?

Art. 27(1)(a) to (f) list six elements of the record. Art. 27(2) requires the assessment before first use and an update when an element changes. Art. 27(3) requires a notification of the results to the market surveillance authority with the AI Office template under Art. 27(5). Art. 27(4) allows a cross-reference to a data protection impact assessment where it already meets an element. Regulation (EU) 2024/1689 sets no likelihood, severity or acceptance value; the deployer justifies its own scale, and the scale-justification step of PR-27-FRIA records it.

+−What is the FRIA deadline?

The application date of Art. 27 is an unsettled point, and the Scope section of this page shows both readings with their sources. Under the working reading, amended Art. 113(c)(i) applies Chapter III Section 3, which holds Art. 27, from the Annex III application date, so a deployer in scope performs the assessment before first use once that date is reached. Under the alternative reading, Art. 27 stayed on the general application date and already applies. The regulation page carries each date from the verified data.

+−What does a FRIA example look like?

The deliverables page holds a synthetic sample of the FRIA record produced by PR-27-FRIA. The sample follows the clause order of ISO/IEC 42005:2025, a published standard: a system identification sheet, the scope record with the deployer's category determination, the context-of-use comparison table, the affected persons and groups mapping with one row per group, process, right and risk, the risks of harm register with the Art. 13 section per row, the oversight and complaint route observations, the DPIA cross-reference map, the review triggers and the notification checklist. Every value is synthetic.

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

Ask about scopehello@aiassurancelabs.com