Article 27 in Practice: A Fundamental Rights Impact Assessment Your Validation Function Can Sign

The AI Act is unusually accommodating towards regulated financial institutions. Where an institution already operates under supervisory requirements for internal governance, it does not have to build that substance a second time. The risk management system under Article 9 may form part of, or be combined with, the risk management procedures already established under other Union law (Article 9(10)). For providers that are financial institutions, the quality management system obligation under Article 17 is, with three exceptions, deemed fulfilled by complying with internal governance rules under Union financial services law (Article 17(4)). The same pattern applies on the deployer side: the monitoring obligation is deemed fulfilled through those same internal governance arrangements (Article 26(5)), and automatically generated logs are simply kept as part of the documentation the institution already maintains (Article 26(6)).

Four bridging clauses, four doors. The legislator plainly did not intend to erect a second model risk management framework alongside the existing one.

Article 27 has no such clause. The fundamental rights impact assessment is the one artefact for which the model file offers no template — even where material from other parts of the institution feeds into it. The only bridge the provision itself offers points not towards model validation but towards the data protection impact assessment, and the Digital Omnibus widened precisely that bridge in July 2026.

This is not a drafting curiosity. It is the operational answer to a question that comes up in every institution with a mature validation culture: which parts of the AI Act do we already satisfy, and which do we not? This article sets out why the assessment sits outside the validation perimeter, which of the six required contents can nonetheless be assembled from existing material, which have to be produced from scratch, and in what order the work is worth doing.

Who owes it, and for exactly what

Article 27(1) reaches three groups of deployers: bodies governed by public law, private entities providing public services, and — regardless of legal form or ownership — deployers of high-risk AI systems falling under Annex III, point 5(b) and (c). The third group is the one that matters for banks and insurers. It covers AI systems used to evaluate the creditworthiness of natural persons or establish their credit score, and AI systems used for risk assessment and pricing in relation to natural persons in life and health insurance.

Three scoping consequences follow, and they should be drawn before anything else.

First, the reach is narrower than it looks at first glance. Point 5(b) expressly carves out systems used to detect financial fraud. Point 5(c) names life and health insurance — not motor, not property, not liability. A composite insurer that places its entire pricing apparatus under Article 27 is working on an obligation it does not have at that scope. Creditworthiness assessment of legal persons sits outside as well; point 5(b) speaks of natural persons.

Second, where the reach does bite, it is not negotiable. The filter in Article 6(3), which allows Annex III systems to be classified as not high-risk under narrow conditions, is closed where the system performs profiling of natural persons: such a system is always high-risk. Credit scoring and individualised risk or premium assessment will regularly meet the profiling definition — whether they do so in a given case turns on how the system actually works and which attributes it processes, not on what the product is called. Where they do, the discussion about arguing the system out of the high-risk class is over before it begins.

Third, the obligation attaches to the deployer, not the provider. An institution using a model supplied by a credit bureau, a shared service centre, a group IT provider or a specialist scoring or software vendor cannot transfer responsibility for the assessment to that supplier. The provider supplies the information under Article 13, to which Article 27(1)(d) expressly refers. The assessment itself is owed by the institution that uses the system in its own business process — and it is owed in relation to that process, that portfolio, that customer base.

Why the assessment runs past model validation

Supervisory model validation is a mature, well-documented discipline. For banks it rests on Article 185 CRR and, for institutions supervised within the Single Supervisory Mechanism, on the ECB Guide to internal models, whose July 2025 edition acknowledges the AI Act explicitly. For insurers it rests on Article 124 of Solvency II and the EIOPA material around it. The discipline examines discriminatory power, calibration, stability, representativeness of the development sample, backtesting, treatment of overrides. It is extremely good at answering one question: how reliable is the estimate the institution relies on?

Article 27 asks a different question. Not how well does the model predict, but whom does it affect, how, and what happens to that person as a result. The reference point of the risk concept inverts. In a validation report, risk is the institution’s risk — misclassification leads to default, mispricing leads to portfolio damage. In a fundamental rights impact assessment, risk is the affected person’s risk: refusal of credit, a premium loading, effective exclusion from a product, entrenchment of a disadvantage over time.

Both perspectives work in part with the same measurements. They lead to different cuts of the data, different thresholds and different conclusions. A model can be prudentially sound and simultaneously place a group systematically worse off without that fact appearing anywhere in the validation report — not because the work was poor, but because the question was never put.

There is a scoping nuance worth naming here, because it decides how much of the existing evidence base actually transfers. In many banks the retail application scorecard is not the IRB model. Where the scoring system sits outside the internal model perimeter, the validation material available for it is thinner than the perimeter documentation suggests, and the gap Article 27 has to close is correspondingly wider.

This also explains the absence of an equivalence clause. The legislator could not deem the fundamental rights impact assessment satisfied by compliance with sectoral governance, because sectoral governance does not cover the subject matter.

What Article 27 offers instead is in paragraph 4: the connection to the data protection impact assessment under Article 35 GDPR. In the original text this was a complementarity rule — where obligations are already met through the data protection impact assessment, the fundamental rights assessment complements it. The Digital Omnibus made the provision workable: the fundamental rights impact assessment may include cross-references to the relevant sections of the data protection impact assessment, or incorporate parts of it. The recast paragraph 5 requires the AI Office to design the questionnaire — including through an automated tool — so that those cross-references work in practice.

That is a real reduction in documentation effort. More importantly, it is a statement about location. The nearest relative of the fundamental rights impact assessment inside the institution is not the model file. It is the data protection impact assessment, which for a scoring system will usually already exist, because automated individual decision-making and scoring routinely cross the Article 35 GDPR threshold. Anyone allocating ownership of Article 27 should know this: a substantial part of the raw material sits with the data protection officer, not with risk control. The empirical core sits with neither.

Six required contents, mirrored against the model file

Article 27(1) lists six contents. The table below maps each of them onto the material an institution with mature validation practice typically holds.

Two groups emerge. Points (a), (e) and (f) can be assembled from existing material — with re-cutting, cross-referencing and one addition at (f). Points (b), (c) and (d) have to be produced from scratch. Point (b) is only apparently trivial: it calls for an express statement of how long and how often the system is to be used, and in most institutions nobody has committed that to paper. The substantive work is at (c) and (d).

Point (c) calls for a decision. Which groups of people are differently affected in the specific deployment context, and on what basis was that selection made? The starting point is Article 21 of the Charter of Fundamental Rights, together with the Union equal treatment directives and their national implementing law. For this segment two of them are directly operative rather than background: Directive 2004/113/EC on equal treatment between men and women in the access to and supply of goods and services, which since Test-Achats rules out sex as a rating factor in insurance pricing, and Directive 2000/43/EC on racial equality, which covers access to goods and services including insurance and credit. On the second, my own reading is that the directive leaves no justification route for differentiation on grounds of racial or ethnic origin comparable to the actuarial justification available elsewhere — I flag that as an interpretation, and the practical test set out below stands without it.

What matters more is what the provision does not say. It speaks of categories and groups likely to be affected in the specific context, not of protected characteristics. The catalogue is a starting point, not a closed list. Context-specific and particularly vulnerable groups belong in it too — people with thin credit files, with atypical employment histories, in the role of co-borrower or guarantor — as do indirect, proxy and intersectional effects. An institution that draws the circle that wide must at the same time decide which groups are measured empirically and which are assessed qualitatively. Otherwise completeness produces a workload nobody carries.

Point (d) then calls for evidence rather than assertion. Once a group is named, the specific risk of harm to it has to be shown. Article 27 prescribes no metrics — it fixes the subject of the assessment, not the method. What is methodologically appropriate, and in practice hard to substitute, is group-differentiated outcome measurement: refusal and loading rates, error rates by group, the stability of those quantities over time, each with documented case numbers, uncertainties and limits of inference.

The blanket objection at this point — that special categories of personal data may not be processed for such an analysis under any circumstances — no longer holds since the Digital Omnibus. The new Article 4a(2) of the AI Act expressly extends to deployers. It does not, however, open a general permission to collect protected attributes: it is a narrowly construed exception subject to cumulative conditions and the standard of strict necessity, and on the recitals it is to be read as a specification of substantial public interest within the meaning of Article 9(2)(g) GDPR rather than as a free-standing legal basis. Purpose, absence of alternatives, data scope, safeguards, retention, access rights and deletion have to be documented beforehand, and the data protection impact assessment will regularly need updating. The provision sits in Chapter I and has applied since 27 July 2026 — it does not follow the deferral of the high-risk obligations. It expressly creates no obligation to perform bias detection; it removes an obstacle.

This is where our own work starts. The fairness and monitoring modules of waveTest produce exactly this group-differentiated measurement, client-side in a container, so the computation does not leave the institution and only pre-agreed, reviewed analysis results are processed on EU-resident infrastructure for reporting. It says nothing about what conclusion to draw from a measured difference; that is the institution’s decision, and in the context of internal models a supervisory event of its own kind.

Measuring is not assessing

Points (c) and (d) establish whom the system affects and to what extent. An impact assessment is not finished at that point: it calls for an evaluation. Otherwise it remains open which measured difference is objectively explicable, which remains legally or ethically problematic, which residual risk is accepted — and who takes that decision.

Four questions carry the step. Is the observed difference explained by an objective, articulable reason, and is that examination documented? How severe and how far-reaching is it for the group concerned? Which existing control at process level actually mitigates it? And who decides that the remaining residual risk is borne — by name and date. The fourth is the question on which assessments fail in review.

Controls and decisions stay at deployer level here: process, human oversight, complaint route. Adjusting the model itself is a supervisory model change event and belongs in the procedure established for it, not in an impact assessment.

Who receives the results

Article 27(3) requires the deployer to notify the market surveillance authority of the results of the assessment, submitting the completed questionnaire referred to in paragraph 5. That is not the same as sending the full internal report — though it does mean the internal report has to carry the results notified.

Who receives the notification is settled by Article 74(6): for high-risk AI systems used by financial institutions regulated under Union financial services law, the market surveillance authority is the national authority responsible for their financial supervision, in so far as the use is in direct connection with the provision of those financial services. The identity of that authority changes with the jurisdiction — BaFin, ACPR, DNB, IVASS, the Central Bank of Ireland — but the pattern does not. This is the point at which the Article 27 conversation stops being a national one: the relevant variable is the type of institution and its supervisory perimeter, not the member state. Where an institution sits outside the perimeter of the principal supervisor — regional or public-law insurers under sub-national supervision in some jurisdictions — the competent authority is a different one, and that should be established before notification rather than assumed.

The quality standard follows from this. The results are evaluated in a prudential setting and have to connect to the level of evidence customary there. The documentation standard of a validation report is the natural benchmark: named method, named data basis, named limits of inference. That it is literally the same body that assesses the models does not hold throughout, however — internal model approval for SSM-significant institutions sits with the European Central Bank, not with the national supervisor.

The questionnaire itself does not yet exist. That is no reason to wait: the six required contents are in paragraph 1 and are independent of format. The questionnaire is the transmission form, not the substance.

Building it in seven steps

1. Scope, rather than assume. An inventory of deployed systems tested against Annex III, point 5(b) and (c), with an express note on the exclusions — fraud detection, legal persons, insurance lines outside life and health. The result is often smaller than feared, and sharper than a blanket self-classification.

2. Inventory artefacts instead of rewriting them. For points (a), (e) and (f) the rule is: cross-reference where cross-referencing is possible. Since the Digital Omnibus, paragraph 4 expressly permits cross-references to the data protection impact assessment and the incorporation of parts of it. The first working session should therefore bring risk control, the business line and data protection to the same table.

3. Determine and justify the affected groups. Point (c) is the step at which a decision is taken and documented — starting from Article 21 of the Charter and the equal treatment directives, extended by the context-specific and particularly vulnerable groups of the actual deployment, with a determination of which groups are measured and which assessed qualitatively, and an honest note on the attributes for which no reliable data basis exists.

4. Measure the risks of harm. Point (d) is an empirical task. Group-differentiated outcome and error distributions, documented methodology, documented case numbers and limits of inference. The legal basis for the processing this requires may be Article 4a(2) — with prior documentation of purpose, absence of alternatives, data scope, safeguards, retention and deletion, and an update to the data protection impact assessment.

5. Evaluate and decide on the residual risk. The four questions above, answered in writing, with a named decision-maker and a date.

6. Evidence oversight and the return path. For point (e), not the authority framework but its effectiveness: Article 14(4) names the test points itself — comprehensibility of the output, awareness of the tendency to rely automatically on it, authority to depart from it. What has to be collected is qualification, powers, information available and time available to the people exercising oversight, together with the analysed override and escalation cases and their distribution. A low override rate on its own evidences nothing: it may indicate a well-functioning system or an oversight function that is effectively inert. For point (f), the construction of the missing return path — with attribution of the complaint to the system actually used, individual redress (for solely automated decisions supplemented by Article 22(3) GDPR, and for consumer credit by the human-intervention and explanation rights under Directive (EU) 2023/2225), a trigger threshold for a systemic investigation, and a named owner for the response.

7. Sign, and define the update triggers. Paragraph 2 attaches the obligation to first use, permits reliance on earlier assessments in similar cases, and requires updating as soon as an element is no longer current. A trigger definition is therefore unavoidable: model change, material change to the data basis, portfolio and population shift, threshold breach in ongoing monitoring, technical or organisational incident, change to the underwriting or credit policy, new legal or factual findings. The most economical place to anchor them is the existing validation cycle — with the caveat that the fundamental rights impact assessment must not be absorbed into it, because it answers a different question.

That leaves the signature. Article 27 prescribes no particular organisational signing order; what follows is a recommendation, not a statutory instruction. In practice three functions compete for ownership: risk control, compliance and data protection. Allocating the file to any one of them alone produces a document with a known weakness — data protection lacks the model empirics, compliance lacks the measurement basis, risk control lacks the fundamental rights perspective. The workable cut separates specialist preparation, methodological review, legal and data protection involvement, and final accountability: prepared by the business line holding model ownership, methodologically reviewed and countersigned by independent validation, with compliance and data protection involved, owned and released by the responsible management body as deployer. Whether release sits with the full management body or a delegated function follows the institution’s authority framework. A fundamental rights impact assessment that independent validation does not countersign is a document about a model for whose statements nobody stands.

Timing

Article 27 sits in Chapter III, Section 3 of the AI Act and therefore follows the application schedule as amended by the Digital Omnibus: 2 December 2027 for high-risk systems under Article 6(2) and Annex III, 2 August 2028 for systems under Article 6(1) and Annex I. The Digital Omnibus — Regulation (EU) 2026/1744, in force since 27 July 2026 — changed the text; applicability continues to be governed by Article 113.

So there is no cause for haste, and this article does not argue from deadline pressure. It argues from sequence. Points (c) and (d) require a data basis that can often only be reconstructed incompletely after the fact. An institution that stands up group-differentiated measurement only at the application date has a cross-section and not a time series — and therefore nothing to say about whether a measured difference is entrenching or eroding. The effort of the first pass is manageable; the value accrues in repetition.

For systems already in use before the application date, the transitional rules in Article 111 apply, turning in substance on significant changes in design. That has to be checked case by case against the consolidated text and does not serve as a planning basis, because any substantial model overhaul puts the question afresh.

What comes next

The fundamental rights impact assessment is the one place where the AI Act does not point back at existing governance. It is therefore also the place where it shows most clearly whether an institution treats the regulation as a documentation exercise or as an operating question.

The second such place is the affected person’s right to an explanation under Article 86. That is not an artefact but a process, with deadlines, escalation stages and a steady-state operating rhythm — and it is the subject of the next article in this series.

A scaffold to take away

This article comes with a scaffold for the fundamental rights impact assessment as a PDF: the six required contents of Article 27(1), each with the existing artefact and the remaining evidence gap, plus a matrix for evaluation and the residual risk decision and working tables for update triggers and signature. No registration form, no email address, no newsletter — direct download:

→ FRIA scaffold under Article 27 (PDF, 7 pages, ungated)

If you would like to discuss how this cuts for your institution — in particular the allocation of preparation, review and signature across risk control, compliance and data protection — a plain email is enough: valentin.mayr@waveimpact.de. An answer to a technical question costs nothing and commits you to nothing.

Dr Valentin José Mayr is founder and managing director of waveImpact GmbH in Bremen, Germany. waveImpact tests AI systems for fairness, transparency and regulatory fit — with a toolchain whose computation stays inside the client’s environment.

Legal position: 29 July 2026. Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. This article states a professional view and does not constitute legal advice in an individual case.