Article 27(1) reaches two limbs of deployers rather than every deployer of a high-risk system: bodies governed by public law and private entities providing public services, plus deployers of Annex III point 5(b) and 5(c) systems, with systems in the area of Annex III point 2 expressly excluded. Point 5(b) carves out systems used for the purpose of detecting financial fraud and point 5(c) reaches life and health insurance only, so a bank fraud model and a motor pricing model both sit outside the second limb. Before any of that, Article 111(2) as amended leaves systems placed on the market or put into service before 2 August 2026 outside the Regulation until they are subject to significant changes in their designs, with public authority deployments owing compliance by 2 August 2030 regardless. The assessment itself has exactly six lettered elements, and four of them, (a), (b), (d) and (e), describe a running deployment and map onto artefacts an engineering team already produces. GDPR Article 35(7) has four required contents, and mapping those onto the six leaves three substantially uncovered: period and frequency of use, the implementation of human oversight measures, and the internal governance and complaint mechanism half of element (f). Article 27(3) sends the result to the market surveillance authority, which under Article 74(6) is the national financial supervisor for a regulated financial institution, and the Article 27(5) template that the notification refers to has not been published. Start this week by pulling the provider's instructions for use and checking whether they describe human oversight measures at all, because element (e) cannot be written honestly if they do not.
A private employer running an AI system that filters job applications deploys a high-risk AI system, and owes no fundamental rights impact assessment under the EU AI Act. The FRIA does not attach to every high-risk system. It attaches to two named populations of deployers, and both are narrow.
Article 27(1) says so in its chapeau: "Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce." Two limbs, one exclusion, no general rule.
Article 27 sits in Chapter III, Section 3 of Regulation (EU) 2024/1689, a Section that Article 113, point (c)(i) applies from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III; the dates belong to the high-risk obligations that land on 2 December 2027. What follows is the test, then the assembly: three gates, six elements, four already evidenced.
The Article 27 test has three gates before the six elements matter
Gate one: is the system high-risk under Article 6(2) at all. Article 6(2) is short: "In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk". Article 6(3) is the escape route, for a system that "does not pose a significant risk of harm", on any one of four conditions: a narrow procedural task, improving a previously completed human activity, detecting decision patterns without replacing human review, or a preparatory task. Its own proviso closes it again: an Annex III system "shall always be considered to be high-risk where the AI system performs profiling" of natural persons, and a credit scoring model profiles by construction. When a vendor claims 6(3), the paperwork is the vendor's under Article 6(4): "A provider who considers that an AI system referred to in Annex III is not high-risk shall document its assessment before that system is placed on the market". Ask for it by name.
Gate two: is the system inside the Article 111(2) grandfathering window. The amended text applies the Regulation "to operators of high-risk AI systems... that have been placed on the market or put into service before 2 August 2026, only if, as from that date, those systems are subject to significant changes in their designs", with one carve-out that survives regardless: "the providers and deployers of high-risk AI systems intended to be used by public authorities shall take the necessary steps to comply with the requirements and obligations of this Regulation by 2 August 2030." The cutoff in that paragraph is a fixed calendar date, 2 August 2026, while the obligations in Chapter III, Section 3 apply from 2 December 2027, so the two are not the same date. The shelter is also conditional, so track it per system.
Gate three: are you one of the deployers Article 27(1) names. Article 3(4) defines a deployer as "a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity", and being one is not enough. You also have to sit in one of the two limbs the chapeau names. Either way the exclusion bites: Annex III point 2 covers "AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity", carved out expressly.
The employer row is the one worth arguing with. Annex III point 4(a) covers "AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates". Its deployer carries the Article 26 duties and none of Article 27.
| Deployer | System | Annex III point | High-risk? | FRIA under Art. 27? |
|---|---|---|---|---|
| Private commercial bank | Credit scoring of natural persons | 5(b) | Yes | Yes, second limb of Art. 27(1) |
| Private commercial bank | Transaction fraud detection | None, carved out of 5(b) | Not on this route | No |
| Life insurer | Risk assessment and pricing for life cover | 5(c) | Yes | Yes, second limb |
| Motor or property insurer | Risk assessment and pricing | Not within 5(c) | Not on this route | No |
| Private employer | CV screening and applicant filtering | 4(a) | Yes | No, unless a public-service body |
| Public benefits agency | Eligibility for public assistance | 5(a) | Yes | Yes, first limb |
| Grid operator | Safety component in electricity supply | 2 | Yes | No, expressly excluded by Art. 27(1) |
| Private entity providing a public service | Any Annex III high-risk system other than the point 2 area | Any except 2 | Yes | Yes, first limb |
Why a bank and a life insurer are caught but a motor insurer is not
The second limb reaches two Annex III sub-points, both narrower than "banking and insurance" suggests.
Point 5(b): "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud". Credit decisioning and fraud detection can share infrastructure, features and a serving stack. Scope the test to the system and its intended purpose, not the team.
Point 5(c): "AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance". The final clause is the limit: a motor or property insurer doing the same modelling on the same personal data is not within point 5(c), so its deployer is outside the second limb.
Neither exclusion makes the system unregulated. Article 27 is simply not the provision that reaches it, and the wider compliance surface around credit models is unaffected.
The six elements, and the four your engineering team already owns
Article 27(1) has exactly six lettered elements. Quoted:
Four of the six, (a), (b), (d) and (e), describe a running deployment rather than a legal position, and each maps to an artefact a deployment team already holds. Elements (c) and (f) need someone outside engineering: (c) is a population question, (f) a governance one.
Element (a) is pinned to a defined term by its own words. Article 3(12) defines intended purpose as "the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation". So (a) measures your processes against that stated purpose, and a mismatch is a finding.
| Element | Artefact you already hold | Owner | Produced by engineering? |
|---|---|---|---|
| (a) | Provider instructions for use, intended purpose section, plus the internal process map | Product | Partly |
| (b) | Deployment use register and invocation metrics | Platform | Yes |
| (c) | DPIA data subject inventory | Privacy | No |
| (d) | Provider Art. 13 information plus the DPIA risk register | Risk | Partly |
| (e) | Oversight runbook, named reviewer roles, override and escalation logs | Platform | Yes |
| (f) | Incident runbook and rollback procedure, plus the complaint intake and the governance arrangements around it | Operations and Legal | No |
Element (e) points back at the provider's instructions, and that is a procurement finding
Element (e) turns on its qualifier, "according to the instructions for use", which chains into the provider's Article 13 duties. Article 13(2) requires that high-risk systems "shall be accompanied by instructions for use" containing "concise, complete, correct and clear information" for deployers, and 13(3) lists their contents, of which point (d) is the human oversight measures, including the technical measures that facilitate interpretation of outputs.
Article 14(3) splits oversight measures into two sets: "(a) measures identified and built, when technically feasible, into the high-risk AI system by the provider before it is placed on the market or put into service; (b) measures identified by the provider before placing the high-risk AI system on the market or putting it into service and that are appropriate to be implemented by the deployer." Element (e) describes your implementation of the 14(3)(b) set, not a scheme of your own.
That gives you a test to run before deployment: open the instructions for use and look for the 14(3)(b) measures. If they are absent, element (e) has no honest content, and the fix is a supplier conversation, not a draft.
One adjacent duty is not element (e). Article 26(2) requires that "Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support", which is about the people rather than the description of what they do. The design of the queue those people work in is covered in the oversight mechanism element (e) has to describe.
Element (b), first use, and what a model refresh does to a filed assessment
Article 27(2) sets the timing in three sentences: "The obligation laid down in paragraph 1 applies to the first use of the high-risk AI system. The deployer may, in similar cases, rely on previously conducted fundamental rights impact assessments or existing impact assessments carried out by provider. If, during the use of the high-risk AI system, the deployer considers that any of the elements listed in paragraph 1 has changed or is no longer up to date, the deployer shall take the necessary steps to update the information."
The first sentence is a relief, the third is the standing obligation, and the second means a further deployment under the same purpose does not start from an empty page.
Element (b) alone states a quantity rather than a design, so as a sentence it goes stale quietly. As a record with declared triggers, staleness becomes an event that fires. The file below is one your team keeps in its own repository; no tool reads it and it is not any product's configuration format.
# fria/use-register.yaml # Element (b) of Art. 27(1): period of time and frequency of intended use system: credit-decision-scorer annex_iii_point: "5(b)" provider_instructions_version: "<as printed on the instructions for use>" first_use: 2027-12-02 period_of_use: from: 2027-12-02 to: null # open-ended, reviewed annually frequency: invocation: per application, synchronous expected_volume_per_month: <n> business_hours_only: false update_triggers: # Art. 27(2): any element changed or no longer up to date - model_version_change # any change to weights or scoring logic in production - intended_purpose_change # Art. 3(12); also a substantial modification under Art. 3(23) - substantial_modification # Art. 3(23); may make you the provider under Art. 25(1)(b) - oversight_role_change # changes element (e) - population_change # new product, new market, changes element (c) - volume_outside_declared_range last_reviewed: <date> reviewer: <named role, not a team>
Two of those triggers reach past Article 27, and they collapse into one provision. Article 3(23) defines substantial modification as a change not foreseen in the initial conformity assessment "and as a result of which the compliance of the AI system with the requirements set out in Chapter III, Section 2 is affected or results in a modification to the intended purpose", so a change of intended purpose sits inside that definition. Either one trips Article 25(1)(b), which makes a deployer into a provider while 25(2) removes the original one. That is the argument in when modifying a bought system turns you into its provider. The event that updates element (b) may be the event that changes your role, so route it once. Point the volume and invocation fields at the monitoring that tells you an element has gone stale rather than at an estimate typed in at filing time.
What a completed GDPR DPIA gives you, and the three things it does not
A point 5(b) or 5(c) deployment normally sits inside GDPR Article 35(3)(a), which makes a DPIA mandatory for "a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person".
Article 27(4) as amended has two limbs, both conditioned on the obligation already being met through a DPIA under Article 35 GDPR or Article 27 of Directive (EU) 2016/680. The incorporation limb: the deployer "may, when conducting the fundamental rights impact assessment referred to in paragraph 1 of this Article, include cross-references to the relevant sections of that data protection impact assessment or include relevant parts thereof". The complement limb, which was the whole of the original provision: "the fundamental rights impact assessment referred to in paragraph 1 of this Article shall complement that data protection impact assessment". Lift sections wholesale, and the FRIA still has to exist as its own document.
What it yields is bounded, because Article 35(7) has exactly four required contents: a systematic description of the processing operations and purposes, an assessment of necessity and proportionality, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged to address them. All four are scoped to personal data protection; Article 27(1) is scoped to fundamental rights.
Three elements come out substantially uncovered: (b), (e), and the internal governance and complaint mechanism half of (f). The review triggers differ too. Article 35(11) asks for a review "at least when there is a change of the risk represented by processing operations"; Article 27(2) fires when any of the six elements has changed. A refresh that leaves risk flat but doubles the invocation rate is silent under the first, loud under the second. Treat the DPIA you already ran for the same model as a partial input to four of the six elements and budget real work for the rest.
One cross-reference trap appears twice. Article 26(9) requires deployers to "use the information provided under Article 13 of this Regulation to comply with their obligation to carry out a data protection impact assessment". That obligation is Article 35 GDPR or Article 27 of Directive (EU) 2016/680, the Law Enforcement Directive, not Article 27 of the AI Act. Article 27(4) carries the same reference.
| Art. 27(1) element | Nearest DPIA output | Reusable? | What is still missing |
|---|---|---|---|
| (a) Deployer processes in line with intended purpose | Art. 35(7)(a) systematic description of processing operations and purposes | Partly | The description is scoped to processing, not to the decision process the output feeds |
| (b) Period of time and frequency of intended use | Nothing in Art. 35(7) | No | The whole element |
| (c) Categories of natural persons and groups likely to be affected | Art. 35(7)(c), risks to rights and freedoms of data subjects | Mostly | Groups affected who are not data subjects |
| (d) Specific risks of harm to those categories | Art. 35(7)(c) | Partly | Risks to fundamental rights that are not data protection risks; the Art. 13 provider information |
| (e) Implementation of human oversight measures per the instructions for use | Nothing in Art. 35(7) | No | The whole element, and it depends on the provider's instructions |
| (f) Measures on materialisation, internal governance and complaint mechanisms | Art. 35(7)(d) measures envisaged to address the risks | Partly | Internal governance arrangements and the complaint mechanism as such |
Notifying the market surveillance authority when the template does not exist
Article 27(3): "Once the assessment referred to in paragraph 1 of this Article has been performed, the deployer shall notify the market surveillance authority of its results, submitting the filled-out template referred to in paragraph 5 of this Article as part of the notification. In the case referred to in Article 46(1), deployers may be exempt from that obligation to notify."
Three things in that paragraph decide how you file. The destination is the market surveillance authority, not the AI Office and not the Commission; for a high-risk system used by a financial institution regulated under Union financial services law, Article 74(6) makes that authority "the relevant national authority responsible for the financial supervision of those institutions". The exemption is narrow: Article 46(1) is the derogation from conformity assessment, where an authority may authorise placing on the market "for exceptional reasons of public security or the protection of life and health of persons, environmental protection or the protection of key industrial and infrastructural assets", and only "for a limited period while the necessary conformity assessment procedures are being carried out". And the template does not exist. Article 27(5) requires that "The AI Office shall develop a template for a questionnaire, including through an automated tool, to facilitate deployers", and none has been published. Nothing makes paragraph 1 conditional on it, which is why you draft against the six elements now.
Those three duties hit different populations. Article 49(3) reaches "deployers that are public authorities, Union institutions, bodies, offices or agencies or persons acting on their behalf", so a private bank filing under the 5(b) limb notifies under 27(3) and registers nothing. Article 86(1) runs the other way: a person adversely affected by a decision based on an Annex III system's output, other than point 2, "shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure". Element (f)'s complaint mechanism has to service that.
One structural fact, and one inference it does not support. Article 27 is not among the provisions enumerated in Article 99(4), whose list names Articles 16, 22, 23, 24, 25(2) and (4), 26, 31, 33, 34 and 50. That does not make non-filing free: Article 99(1) requires Member States to "lay down the rules on penalties and other enforcement measures, which may also include warnings and non-monetary measures, applicable to infringements of this Regulation by operators", and Article 85 lets any person complain to the same authority that receives your 27(3) notification.
| Duty | Provision | Who owes it | Goes where |
|---|---|---|---|
| Notify the results of the FRIA | Art. 27(3) | Every deployer caught by Art. 27(1) | The market surveillance authority; for a regulated financial institution that is its national financial supervisor under Art. 74(6) |
| Register the system and its use in the EU database | Art. 49(3) | Public authorities and persons acting on their behalf only | The EU database under Art. 71 |
| Explain an individual decision on request | Art. 86(1) | The deployer, for Annex III systems other than point 2 | The affected person, directly |
A FRIA skeleton mapped to artefacts you already hold
The assembly order follows where the evidence lives: the instructions for use first, because (a), (d) and (e) depend on them, then the DPIA for (c) and part of (d), then the use register for (b), then the oversight runbook, reviewer roster and override log for (e). Fill only the gaps that leaves.
The skeleton below is a document you author. It is not an official format, not a vendor schema, and not a stand-in for the Article 27(5) questionnaire. Its six headings are the six statutory elements, so when the questionnaire arrives the answers already sit where it asks for them.
# Fundamental rights impact assessment # Regulation (EU) 2024/1689, Article 27(1) # System: <name> Annex III point: 5(b) First use: <date> ## (a) Deployer processes, in line with the intended purpose Source: provider instructions for use, section on intended purpose (Art. 13(3)) Source: internal process map for the decision this system feeds ## (b) Period of time and frequency of intended use Source: use register (see the YAML block above) ## (c) Categories of natural persons and groups likely to be affected Source: DPIA assessment of risks to data subjects (GDPR Art. 35(7)(c)) Gap: groups affected who are not data subjects ## (d) Specific risks of harm to the categories identified in (c) Source: provider information under Art. 13 Source: DPIA risk assessment (GDPR Art. 35(7)(c)) Gap: risks to fundamental rights beyond data protection ## (e) Implementation of human oversight measures, per the instructions for use Source: provider oversight measures (Art. 13(3)(d), Art. 14(3)(b)) Source: oversight runbook, named roles, override log Gap: none permitted; if the instructions for use are silent, raise it with the provider ## (f) Measures on materialisation, internal governance and complaint mechanisms Source: incident runbook, rollback procedure, kill switch owner Source: complaint intake that can service an Art. 86(1) explanation request
Nothing in Article 27 turns on where the weights sit. The obligation attaches to the deployer and the Annex III point, not to the hosting model. What changes is who can evidence two elements first-hand. Article 26(6) requires deployers to keep the automatically generated logs "to the extent such logs are under their control". Run the model inside your own perimeter and the invocation counts behind element (b), and the override records, reviewer identities and timestamps behind element (e), are first-party data. Run it as a hosted API and both depend on vendor telemetry, at which point that clause becomes a procurement negotiation rather than a gap in the filing.
Keep Article 27 in proportion. It is the deployer obligation that produces a filed document, not the whole of what lands on the buyer: Article 26 runs to twelve paragraphs of duties, including log retention in 26(6), workforce notification in 26(7), and telling affected persons they are subject to the system in 26(11). Article 26(5) even gives regulated financial institutions a deemed-compliance route for monitoring; Article 27 has no equivalent shortcut.
This week, do one thing. Take a single Annex III point 5(b) or 5(c) system you already run, open the provider's instructions for use, and search it for the human oversight measures required by Article 13(3)(d) and the deployer-implemented set under Article 14(3)(b). If they are there, element (e) has a source and you can start the use register. If not, you have found the gap that will hold up the filing roughly fifteen months early, while it is still a supplier conversation. More walkthroughs of this kind sit in our AI for business guides.
FAQ
Quick answers to the questions this post tends to raise.
