← auditaisdk.com · All articles
The fundamental rights impact assessment is the document that most often blocks AI vendor onboarding in regulated EU sectors. A retail bank running an AI credit-scoring tool, a life insurer using AI to price applicants, a hospital triaging patients with an Annex III system or a school deploying an admission-scoring tool all carry the Article 27 duty. Their procurement teams know it. When they receive an AI vendor's questionnaire response, the first follow-up is almost always: "do you have a FRIA template we can populate, or do we author one from scratch?"
The vendor that ships a populated template closes the deal in one round. The vendor that does not ships their customer's compliance function into a six-to-twelve week authoring exercise that almost always stalls the procurement cycle. The FRIA is the single artefact that, more than any other, distinguishes AI vendors that close enterprise deals from those that lose them on compliance grounds.
The good news is that the FRIA is structurally simple. Article 27(1) lists six items. The provider's instructions for use under Article 13 pre-fill three of them. The deployer populates the remaining three with population-specific data. The notification to the market surveillance authority under Article 27(3) is a one-page form. This guide builds the populated template and the notification step by step.
Article 27(1) is more precise than usual EU legislation and the precision matters. Three trigger profiles capture the duty.
Bodies governed by public law deploying any high-risk AI listed in Annex III, with the exception of Annex III(2) critical infrastructure. Covers ministries, regulators, regional authorities, social-security agencies, employment offices, courts, military bodies (where Annex III applies).
Private entities providing public services deploying Annex III systems. The Recital 96 reading is broad: utilities, education providers, healthcare providers, social housing operators, employment agencies acting under public-service mandate.
Any deployer — public or private — of an AI system intended to evaluate the creditworthiness of natural persons or establish their credit score. Retail banks, consumer-credit lenders, BNPL operators, fintech credit-decision tools all fall in scope. No carve-out for size.
Any deployer of an AI system intended for risk assessment and pricing in life and health insurance, regardless of whether the deployer is public or private. Captures actuarial-AI tools at insurers and the AI-pricing tools at insurtech intermediaries.
A useful diagnostic: a private retail employer deploying an AI CV-screening tool is on the Article 26 baseline; the Article 27 FRIA does not additionally trigger. The same employer, but in a public-service mandate (a state-funded employment agency, for example), does trigger. A B2B SaaS that sells AI tools across regulated sectors will mostly see Profiles 3 and 4 (banks, lenders, insurers) in the buying pipeline; vertical-public-sector buyers carry Profiles 1 and 2.
Article 27(1) requires the FRIA prior to deploying the high-risk AI system. Prior to deploying means before first use against natural persons in operational conditions. A pilot or proof-of-concept run against real applicants, patients or beneficiaries is deployment. A sandboxed test on synthetic data is not. A staging environment using anonymised historical records sits in the grey zone — most national authorities accept that anonymised historical evaluation does not trigger the duty, but evaluation against current real records that affect downstream decisions does.
Article 27(2) requires the FRIA to be updated when any of its elements changes:
The update is not a re-write. It is a delta-style amendment that records what changed, why and what new mitigation it triggered. National authorities reading FRIAs in 2026 expect a version history at the top of the document with at least three rows visible — the initial assessment plus updates — and a short statement on each row of what triggered the update.
Article 27(1) lists the FRIA content in six labelled items, (a) through (f). Each item maps to a distinct page or section in the populated document. The provider supplies the inputs for (a), (d) and (e) via the instructions for use under Article 13. The deployer populates (b), (c) and (f) with population-specific data. The structure below is what national authorities in the AI Office working group have signalled as the expected layout.
a
The provider's instructions for use already contain the intended purpose. The deployer maps it onto its own operational process. For a bank deploying credit scoring, the description names the lending products covered (consumer loans, mortgages, credit cards), the decision points where the AI output enters (pre-screen, primary decision, escalation), and the downstream actions the score drives. Length: half a page. Common failure: copying the intended purpose verbatim without operational mapping — national authorities read this as a missing operationalisation step.
b
The deployer populates this with the operational reality. For an insurer running AI pricing, the answer is typically "continuously, on every new policy application and every annual renewal", with a stated daily volume range. For an employment agency running a CV-screening tool, the answer is typically "during each recruitment campaign, frequency dependent on hiring cycle". Length: quarter of a page. The volume figure is more important than the cadence — the FRIA is read against the scale of impact, and a system processing 10,000 applications per month carries different weight than one processing 50.
c
This is where most FRIAs fall short. The duty is to identify the categories of affected persons in the specific context — not abstractly. For a bank credit-scoring tool deployed in Spain, the categories include retail credit applicants segmented by income band, by region (urban/rural balance), by age (with attention to under-25 and over-65 outcomes), and by language preference (Spanish, Catalan, Basque). Recital 96 also expects attention to vulnerable groups — minors, asylum seekers, persons with disabilities — wherever the system has reachable impact. Length: one to one and a half pages. The output is a population-segmentation table.
d
The provider's testing and bias evaluation under Annex IV(2)(b) and Article 10 supplies the candidate risk inventory. The deployer adapts to its specific population. A credit-scoring tool that the provider tested on European retail data may carry adverse impact at the regional level the deployer operates in, and the FRIA must capture it. Common risks: indirect discrimination on protected characteristics (race, gender, age, religion under Article 21 EU Charter), denial of essential service, opacity preventing meaningful contestation under Article 47 EU Charter, propagation of historical bias from training data, scope drift via feedback loops. Length: one to two pages. The output is a risk register with severity and likelihood per category from (c).
e
Article 14 of the EU AI Act and Article 26(2) require human oversight; Article 27(1)(e) requires the FRIA to describe how the deployer implements it. The provider's instructions for use specify the recommended oversight profile (review thresholds, override authority, escalation paths). The deployer documents how it operationalises those recommendations — named role of the oversight officer, review percentage, response-time SLA, override audit trail. Length: half to three quarters of a page. Common failure: stating that human oversight is in place without specifying who, how often, with what authority — national authorities read this as oversight on paper rather than in practice.
f
The closing item is the contingency layer. Three elements are mandatory: an internal governance line (who at the deployer is accountable when a risk from (d) materialises), an external complaint mechanism letting affected persons contest decisions (often the existing GDPR Article 22 right to contest automated decisions, extended to the AI Act context), and a remediation protocol (rollback, retraining trigger, deployer-side circuit breaker). Length: half a page. The complaint mechanism is the one most reviewed by deployer customers — the access channel, the response SLA and the escalation path must be concrete.
Article 27(3) requires the deployer to notify the market surveillance authority of the results of the FRIA. The notification uses the template developed by the AI Office under Article 27(5), which the Office released in draft form in February 2026 and finalised in April 2026 for submission via the national authority portal.
The notification is not the FRIA itself. It is a short summary of:
The notification is informational. The market surveillance authority does not approve, validate or counter-sign. The notification creates a record the authority can refer to in any later investigation under Article 74. Most national authorities have signalled in 2026 working-group statements that they intend to treat the notification as a screening tool — they will read the submission, may flag concerns, and may follow up where the mitigation looks insufficient against the risks identified. The deployer's defensible posture is to populate the notification fully and consistently with the full FRIA, not to pad or hedge.
The most operationally useful provision in Article 27 is paragraph (4):
If any of the obligations laid down in this Article is already met through the data protection impact assessment carried out pursuant to Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680, the fundamental rights impact assessment referred to in paragraph 1 of this Article shall complement that data protection impact assessment.
The practical effect is that a deployer that already has a DPIA on the same processing does not redo the privacy analysis in the FRIA. The DPIA covers the personal-data-processing dimension; the FRIA layers the fundamental-rights dimension on top. Three articulation patterns work in practice:
| Pattern | What sits where | When to use |
|---|---|---|
| FRIA-with-DPIA-annex | FRIA is the main document. DPIA is Annex A. The FRIA references the DPIA for the privacy-specific risks under (d) and inherits the controller-level mitigation. | Most B2B SaaS contexts. The FRIA is the artefact procurement reads; pairing the DPIA in the same file lets the deployer's DPO and the AI compliance owner sign on the same package. |
| DPIA-with-FRIA-extension | DPIA is the main document. FRIA is a labelled extension section adding the non-privacy fundamental-rights coverage. | Deployers with mature GDPR governance who prefer to anchor in their existing DPIA workflow. Acceptable to national authorities when the FRIA extension covers all six Article 27(1) items. |
| Stand-alone FRIA | FRIA is a single document; no DPIA exists or the DPIA is for a different processing. | Where the AI system does not process personal data (rare in Annex III) or where the DPIA covers a different operational scope. The FRIA must populate the privacy-specific risks under (d) directly. |
The cleanest enterprise file uses the FRIA-with-DPIA-annex pattern. The deployer's DPO signs the DPIA; the deployer's AI compliance owner signs the FRIA; both sit in one PDF that procurement at the next vendor questionnaire reads as a single artefact.
Below is the template the auditai SDK populates via audit.export_fria_template(). Field names in angle brackets are populated either by the provider's instructions for use (provider-side fields) or by the deployer at first use (deployer-side fields).
FUNDAMENTAL RIGHTS IMPACT ASSESSMENT
EU AI Act Article 27 — Deployer File
Document version: <1.0>
Date of assessment: <2026-MM-DD>
Deployer: <legal name, address, contact>
Provider: <provider name, CE-marking number, conformity assessment ref>
AI system: <product name, version, Annex III category>
Article 27(1) trigger profile: <public body | public-service entity | Annex III(5)(b) | Annex III(5)(c)>
DPIA articulation: <FRIA-with-DPIA-annex | DPIA-with-FRIA-extension | stand-alone>
1. Article 27(1)(a) — Description of deployer's processes
- Intended purpose (from provider instructions for use): <...>
- Operational mapping: <process steps, decision points, downstream actions>
- In-scope products / services: <list>
- Out-of-scope contexts (where the deployer commits not to use the system):
<list>
2. Article 27(1)(b) — Period and frequency of use
- Period of intended use: <start date — review date>
- Frequency: <continuous | per-application | per-cycle>
- Expected volume (daily / monthly): <range>
- Scale dimension (number of natural persons affected per month): <range>
3. Article 27(1)(c) — Categories of affected natural persons and groups
- Primary category: <e.g., retail credit applicants>
- Population segmentation table:
| Segment | Estimated share | Notes |
| -------------------- | --------------- | ------------------- |
| <segment 1> | <%> | <...> |
| <segment 2> | <%> | <...> |
| <segment 3> | <%> | <...> |
- Vulnerable groups assessment: <minors | persons with disabilities |
asylum seekers | low-income | other — note coverage and posture>
- Geographic scope: <jurisdictions and regions>
4. Article 27(1)(d) — Specific risks of harm
- Provider-supplied inputs (from instructions for use Section X):
<summary>
- Deployer-adapted risk register:
| Risk | Category from (c) | Severity | Likelihood | Source |
| -------------------------------------------- | ----------------- | -------- | ---------- | ---------- |
| Indirect discrimination on protected ground | <...> | High | Medium | Provider |
| Denial of essential service | <...> | High | Low | Deployer |
| Opacity preventing contestation | <...> | Medium | Medium | Deployer |
| Bias from historical training data | <...> | Medium | Medium | Provider |
| Scope drift via feedback loops | <...> | Medium | Low | Joint |
- EU Charter rights touched: <Art 1, 7, 8, 20, 21, 24, 26, 31, 34, 47>
5. Article 27(1)(e) — Human oversight measures
- Provider recommended oversight (from instructions for use): <...>
- Deployer implementation:
- Oversight officer (named role): <...>
- Review threshold (% of outputs reviewed): <...>
- Override authority and audit trail: <...>
- Training of oversight personnel: <reference to programme>
- Response-time SLA: <...>
6. Article 27(1)(f) — Measures in case of materialisation
- Internal governance line: <named accountable role | escalation path>
- External complaint mechanism:
- Channel: <web form | dedicated email | helpline>
- Response SLA: <e.g., acknowledgement within 5 business days,
substantive response within 30>
- Affected person right to contest (Art 22 GDPR + 26(11)): <link>
- Remediation protocol:
- Rollback procedure: <...>
- Retraining trigger and process: <...>
- Deployer-side circuit breaker (kill switch): <named role + procedure>
7. Article 27(2) — Update history
| Version | Date | Trigger | Sections updated |
| ------- | ------------- | ------------------- | ---------------- |
| 1.0 | <date> | Initial assessment | All |
8. Article 27(3) — Notification to market surveillance authority
- Notification submitted to: <competent authority + national portal ref>
- Submission date: <date>
- Acknowledgement reference: <ID>
9. Signatures
- Deployer AI compliance owner: <name, role, date>
- Deployer DPO (if DPIA-annex pattern): <name, role, date>
- Deployer legal representative: <name, role, date>
One PDF. Nine sections. Procurement reads the segmentation table, the risk register, the oversight setup and the complaint mechanism, and signs off. The same template fits Annex III(5)(b) credit scoring, Annex III(5)(c) insurance pricing, Annex III(3) education, Annex III(4) employment in public-service contexts, and Annex III(5)(a) and (5)(d) public-benefit eligibility decisions.
A deployer authors the FRIA without using the provider's instructions for use as input. Items (a), (d) and (e) end up generic — "the system processes credit applicants" instead of the specific intended purpose, model architecture and oversight profile the provider documented. National authorities flag this as a missing Article 13 articulation. Fix: ensure the provider's instructions for use are referenced section-by-section in the populated template; quote the provider's language where it satisfies the duty directly.
A bank FRIA populates item (c) with product segments (consumer loan, mortgage, credit card) but omits demographic dimensions (age band, geography, language preference). Procurement reads this as a thin assessment that cannot demonstrate the deployer considered indirect discrimination risks. Fix: build the segmentation table with at least three dimensions — product, demographic and geographic — and explicitly call out vulnerable groups even where the assessment concludes low reachable impact.
Item (e) reads "human oversight is in place" without naming the role, the review percentage, the override authority or the SLA. The duty is to describe implementation, not to state existence. National authorities mark this as oversight on paper. Fix: populate the named role, the review threshold, the override audit trail and the response-time SLA explicitly; reference the deployer's internal oversight policy by ID.
The FRIA is authored and signed, but Article 27(3) notification to the market surveillance authority is never submitted, or is submitted months after first deployment. National authorities have signalled that they treat the notification timing as a screening signal. Fix: build the notification submission step into the deployment runbook between FRIA sign-off and first operational use. Default expectation is within 30 calendar days of FRIA completion and before deployment.
A deployer with a mature DPIA practice re-writes the privacy analysis in the FRIA and produces two divergent versions of the same risk inventory over time. Article 27(4) explicitly avoids this — the FRIA complements the DPIA, it does not duplicate it. Fix: pick one of the three articulation patterns (FRIA-with-DPIA-annex, DPIA-with-FRIA-extension, stand-alone) and apply it consistently. Reference instead of restating.
Item (f) names a complaint mechanism — "affected persons may contest via the customer service channel" — but no documented access channel, response SLA or escalation path exists in practice. The deployer's first real complaint surfaces this and the file becomes evidence of non-compliance. Fix: stand up a working complaint channel before the FRIA is signed; document the channel ID, the response SLA and the escalation path in (f); reference the operational owner of the channel and the audit log.
The auditai SDK ships helpers for the deployer-side FRIA workflow:
audit.export_fria_template("./fria.pdf", deployer_profile="bank_credit_scoring") generates the populated template scaffold for the deployer profile, with the provider-side fields pre-filled from the SDK configuration.audit.fria_link_iu("./instructions-for-use.pdf") reads the provider's IU and inserts the relevant sections into items (a), (d) and (e) by reference.audit.fria_segmentation(dimensions=["product", "demographic", "geographic"]) produces the segmentation table template with the dimensions populated.audit.fria_risk_register(base="annex_iii_5b") seeds the risk register with the candidate harms for credit scoring (or 5c insurance, or 5a public benefits, or 3 education).audit.export_article_27_notification("./notification.pdf", competent_authority="ES_AESIA") produces the notification draft populated against the deployer's national authority.pip install auditai-sdk
from auditai import AuditAI
audit = AuditAI(
product="Acme Credit Score AI",
deployer_profile="bank_credit_scoring", # 5(b) trigger
competent_authority="ES_AESIA", # Spanish national authority
dpia_articulation="fria_with_dpia_annex"
)
audit.export_fria_template("./fria-deployer.pdf")
audit.export_article_27_notification("./notification.pdf")
The SDK ships the bank-credit-scoring, insurance-pricing, education and employment profile scaffolds out of the box. The €199 managed audit populates the template against the specific product context, prepares the Article 27(3) notification draft, and pairs it with the GDPR DPIA articulation under Article 27(4).
Article 27(1) ties the FRIA duty to two categories of deployer. The first is bodies governed by public law and private entities providing public services — schools, hospitals, social services, employment agencies, courts and similar — whenever they deploy a high-risk AI system listed in Annex III. The second is any deployer of the credit-scoring system referenced in Annex III(5)(b) or the risk-assessment and pricing system for life and health insurance referenced in Annex III(5)(c), regardless of whether the deployer is public or private. The duty is on the deployer, not the provider — but B2B SaaS providers selling into banks, insurers and public-sector buyers get pulled in because procurement demands a FRIA template the deployer can populate. The cleanest commercial posture is to ship a FRIA-ready template with the provider-side fields pre-filled and the deployer-side fields scoped for the customer to complete.
Article 27(1) requires the FRIA to be performed prior to deploying a high-risk AI system within the meaning of Annex III, with the exception of Annex III(2) which covers critical infrastructure. "Prior to deploying" means before first use of the system on natural persons in the deployer's operational context — pilot runs against real applicants, real patients or real students count as deployment. Article 27(2) requires the assessment to be updated if any element changes that may affect the FRIA's results, including changes to the risk-mitigation measures, the categories of affected persons, the scale of use or the human oversight measures. Article 27(3) requires the deployer to notify the market surveillance authority of the results once the FRIA is performed. The notification uses a template the AI Office develops; the deployer submits via the AI Office portal that ties the submission to the deployer's national authority.
Article 27(1) lists the FRIA content. (a) A description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose. (b) A description of the period of time within which, and the frequency with which, each high-risk AI system is intended to be used. (c) The categories of natural persons and groups likely to be affected by its use in the specific context. (d) The specific risks of harm likely to have an impact on the categories of natural persons or groups of persons identified pursuant to point (c), taking into account the information given by the provider pursuant to Article 13. (e) A description of the implementation of human oversight measures, according to the instructions for use. (f) The measures to be taken in the case of the materialisation of those risks, including the arrangements for internal governance and complaint mechanisms. The provider's instructions for use under Article 13 are the primary input — a well-prepared instructions-for-use document carries half of the FRIA in pre-filled language the deployer can adopt verbatim.
Not all of them. Article 27(1) carves out Annex III(2), the critical infrastructure category — those deployers carry their own regime under sectoral law. The other Annex III categories are in scope when the deployer matches the actor profile in Article 27(1)(a) (public body or private entity providing public services) or when the system is specifically Annex III(5)(b) credit scoring or Annex III(5)(c) life and health insurance pricing. Private deployers of Annex III(4) employment systems are not directly captured by Article 27 unless they are providing a public service like a public-sector employment agency; the duty in private employment runs through Article 26 deployer obligations and Article 14 human oversight rather than the FRIA route. A useful diagnostic is to ask: "Is the deployer a public body, providing a public service, or running an Annex III(5)(b) or (5)(c) system?" Yes to any of those triggers Article 27; no leaves the deployer on the Article 26 baseline.
The Data Protection Impact Assessment under Article 35 GDPR is a privacy-focused assessment — it asks how personal data flows, where it is stored, who accesses it and what risks the data processing creates for the data subject. The FRIA under Article 27 is a fundamental-rights-focused assessment — it asks how the AI system affects all rights in the EU Charter (non-discrimination, fair trial, freedom of expression, dignity, asylum, child rights, social security), not only privacy. Article 27(4) creates a one-way overlap: if a DPIA already exists for the same processing, the FRIA complements it; the deployer does not re-do the privacy analysis. In practice the two documents share scope and stakeholders but have different lenses — the DPIA goes to the Data Protection Officer, the FRIA goes to the market surveillance authority. The cleanest enterprise file pairs them in one cover memo, with the DPIA as Annex A and the FRIA as the main document, so procurement sees both in one read.
Article 27(3) requires the deployer to notify the market surveillance authority of the results of the assessment. The submission is via the template the AI Office develops. The authority is not required to approve, validate or counter-sign the FRIA — the notification is informational, not gating. The authority may, however, use the submission to flag concerns, request additional information or initiate a market surveillance investigation under Article 74 if the assessment indicates a non-compliant deployment. In practice, the more carefully a FRIA documents the mitigation measures, the human oversight setup and the complaint mechanism, the less likely an authority is to follow up. The notification creates an evidence trail the deployer can produce in a subsequent investigation; it also lets procurement at the deployer's customers point to the submitted FRIA when they receive their own vendor questionnaires.
Article 26 sets the baseline deployer regime — assign human oversight under Article 14, monitor the system's operation, keep the logs the provider generated, inform persons subject to decisions under 26(11), and notify the provider and market surveillance authority of serious incidents. Article 27 sits on top of Article 26 for the narrower deployer profile (public bodies, public-service entities, Annex III(5)(b) and (5)(c) deployers). The FRIA is a planning document; Article 26 is the operating regime. A correctly built deployer file references the FRIA where the Article 26 elements need fundamental-rights grounding — the human oversight measures in the FRIA's point (e) carry over to the Article 26(2) oversight setup, and the complaint mechanism in point (f) carries over to the Article 26(11) information duty to affected persons. The Article 26 deployer obligations guide covers the operating regime; this article focuses on the FRIA planning step.
A B2B SaaS that ships an AI credit-scoring component to retail banks is a provider under Article 16 and a co-controller in fact of the FRIA template. The cleanest commercial pattern is to ship a "FRIA-ready package" alongside the conformity assessment: the description of intended purpose (Article 27(1)(a)) pre-filled with the use case; the categories of affected persons (1)(c) identified at the population level (loan applicants by jurisdiction); the risks of harm (1)(d) inventoried from the provider's testing and bias evaluation; the human oversight setup (1)(e) described in line with the instructions for use; the complaint mechanism (1)(f) suggested in template form. The bank receives the package, populates 1(b) usage period and frequency, validates the population mapping for its branches and signs the document. With this artefact, the bank's procurement team can close the AI vendor onboarding cycle in one round instead of three. Without it, the bank's compliance function has to author the FRIA from scratch — a six-to-twelve week effort that typically stalls the deal.
Article 27 is the EU AI Act provision that does the most to gate enterprise deals in regulated sectors. A bank deploying AI credit scoring, an insurer using AI for life and health pricing, a hospital running Annex III triage tools or a school running Annex III admission scoring all need the FRIA before first use, and all expect the AI vendor to ship the template. B2B SaaS that anticipates the request closes deals in one round; B2B SaaS that does not loses procurement cycles.
The FRIA is structurally simple — six items in Article 27(1), one notification under Article 27(3), one DPIA articulation under Article 27(4). The hard part is the population mapping, the risk register specific to the deployer's context, the named human oversight setup and the working complaint mechanism. The auditai SDK ships the scaffold for each Annex III deployer profile; the managed audit populates the template against the specific product and prepares the notification.
For B2B SaaS selling into banks (Annex III(5)(b)), insurers (Annex III(5)(c)), hospitals (Annex III(5) and public-service profile), schools (Annex III(3) and public-service profile), employment agencies (Annex III(4) in public-service mandate) and public administration (Annex III(5)(a) and Profile 1), the FRIA-ready package is the single highest-leverage compliance artefact in the enterprise sales motion. It is the bridge between a passing Article 26 deployer file (covered by the Article 26 guide) and an Annex IV provider file (covered by the Annex IV template guide) — without it, neither file is sufficient for a regulated buyer; with it, both files together close.
Six items. One notification. One DPIA articulation. The deployer file procurement at banks, insurers and public buyers asks for in round one.
Get the managed audit — €199 →This article is informational and reflects the EU AI Act as in force after the May 2026 Omnibus delay. It is not legal advice. The managed-audit deliverable is a compliance memo, not a legal opinion; engage qualified counsel for binding interpretation. Article references are to the EU AI Act consolidated text. The Article 27(3) notification template referenced is the AI Office April 2026 finalised version; deployers should verify the current template on the national authority portal at submission time.