Fundamental Rights Impact Assessment (FRIA): The Article 27 Document Most Deployers Are Missing
Article 27 of the EU AI Act requires public bodies and private deployers of certain high-risk AI systems to perform a Fundamental Rights Impact Assessment before first use. The FRIA is a documented process covering intended purpose, persons affected, specific risks of harm, and human-oversight arrangements. It is distinct from a GDPR DPIA. This piece walks through what the FRIA includes, who has to perform one, the August 2026 trigger, and how per-decision records at the AI request boundary feed the FRIA evidence base.
Article 27 of the EU AI Act sets up the Fundamental Rights Impact Assessment, or FRIA, as a documented process that certain deployers of high-risk AI systems must complete before first use. The obligation applies to public bodies, to private deployers providing public services, and to deployers of Annex III systems in the credit scoring and life or health insurance categories. The August 2, 2026 enforcement date for high-risk systems carries this obligation with it. The deployer cannot place the system in use without the FRIA on file. The FRIA is not the GDPR Data Protection Impact Assessment. The two regimes have overlapping inputs and entirely distinct outputs.
I want to walk through what the FRIA must contain, who is on the hook, where it overlaps with a DPIA without replacing one, and how the per-decision records the AI Act also requires feed the FRIA evidence base on an ongoing basis.
Mandate
Article 27 lists six minimum elements the FRIA must cover. The deployer documents each before the AI system is placed in use, updates the FRIA if any element materially changes, and provides it to the national market surveillance authority on request.
The six elements
The first element is the process in which the AI system will be used in line with its intended purpose. The deployer describes how the high-risk system fits into the broader decision workflow.
The second is the period and frequency of intended use. A system used continuously in production has a different risk profile from a system used quarterly in a discrete review cycle.
The third is the categories of natural persons and groups likely to be affected. Loan applicants, job candidates, students, patients, persons subject to law enforcement. The deployer identifies who carries the downstream risk.
The fourth is the specific risks of harm likely to impact the categories identified in element three. The risks must be specific, not generic. "Risk of bias" does not satisfy the requirement. "Risk that gender encoded in the applicant's name affects the model's credit decision under the current scoring policy" does.
The fifth is the description of the implementation of human oversight measures, in line with the instructions for use and Article 14. The deployer documents who reviews AI outputs, under what conditions, with what authority to override.
The sixth is the measures to be taken in the case that the risks materialize. The deployer describes the response plan for an adverse outcome that lands on a real person.
Who has to perform the FRIA
Article 27(1) lists three categories of deployer. Bodies governed by public law (public-sector entities and agencies). Private operators providing public services (e.g. private schools, private healthcare providers, private operators of social benefits). Private deployers of Annex III systems used to evaluate creditworthiness or credit score of natural persons, or for risk assessment and pricing in life and health insurance.
A private bank deploying an AI credit-scoring system in the EU is on the hook. A private fintech doing the same is on the hook. A SaaS HR platform used by private companies sits outside Article 27's direct scope, while its enterprise customers may be where the customer's use falls under a public-service mandate.
The timing
The FRIA must be completed before the first use of the high-risk system. Once on file, the deployer notifies the market surveillance authority of the FRIA's results using the template the AI Office will publish. The notification template is under development, with the AI Office consulting throughout 2026.
Compliance gap
The FRIA looks like a one-time document at procurement. Operationally, it is a living artifact that needs to track the system's behavior in production.
Element 3 needs the deployment context the procurement record does not have
The categories of affected persons depend on which segments of the deployer's customer base the system actually processes. A credit-scoring system deployed across consumer mortgages and small-business loans affects two distinct populations with different protected-attribute exposures. The procurement record captures the intended deployment scope. The production traffic captures the actual deployment scope. The FRIA needs both, and most deployers can produce only the first.
Element 4 needs evidence the model has been audited against the specific risks
Specific risks of harm to specific categories need specific evidence. The evidence is either a peer-reviewed model card, an internal bias audit, or production decisions reviewed for the pattern. A general statement of "the provider attests the model is unbiased" does not satisfy a regulator looking at element 4 of a contested FRIA.
Element 5 needs per-decision evidence that human oversight actually fires
Human oversight described in element 5 must be operationally real, not a paper plan. The records that demonstrate this are per-decision: how many decisions did the AI system make in the last quarter, how many were flagged for human review, how many were overridden, what were the patterns in the overrides. Without per-decision records, the deployer cannot demonstrate that the human-oversight design works in production.
Mandate vs. Compliance
Article 27 reads at the policy and process level. The FRIA needs to land at the records level.
Disclosure test
When the national market surveillance authority requests the FRIA under Article 27(5), the deployer must produce the assessment plus the operational evidence behind each of the six elements. The procurement-side FRIA covers the intended use and the procurement-time bias audit. The operational evidence covers what actually happened in production: how many requests, what categories of affected persons appeared in the traffic, what the model's behavior was across categories, how many overrides fired, what the response was when an adverse outcome was reported.
Vendor liability
The FRIA obligation sits with the deployer, not the system provider. The deployer cannot transfer the obligation through contract. If a third-party vendor's AI system processes data the deployer is responsible for, the deployer owns the FRIA. The vendor's documentation (model card, technical documentation under Article 11) is an input to the FRIA, not a substitute.
Compliance gap
Most regulated deployers can produce procurement-time documentation. Few can produce the production-side records that make elements 3, 4, and 5 live. The gap is structural: application logs lack data-classification fields that would let the deployer report on affected categories, lack policy-version metadata that would tie the human-oversight design to the system's actual behavior, and lack the integrity controls that make the records admissible.
DeepInspect
This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between any application and any LLM. Per-request, the gateway captures identity (the natural person and the agent), data classification (the protected attributes, the sensitivity tier, the purpose marker), policy version (the rule in effect at the moment), and decision outcome (permit, redact, deny, human-review).
These are the operational inputs that make the FRIA evidence base hold up under inquiry. Element 3 gets the affected-categories report from the data-classification field. Element 4 gets the specific-risk evidence from the policy-version and decision-outcome history. Element 5 gets the human-oversight rate from the human-review flags. The records are independent of the application that originated the request, signed, tamper-evident, and committed before the response returns to the application.
If you are facing the August 2 deadline and Article 27 applies to your deployment, let's talk.
Frequently asked questions
- Is the FRIA the same as a GDPR DPIA?
The two are distinct and can both apply to the same deployment. A GDPR Data Protection Impact Assessment under Article 35 evaluates risks to data subjects from data processing. A FRIA under AI Act Article 27 evaluates risks to fundamental rights from the AI system's operation, which is broader. Both can run on the same system, with overlapping inputs (categories of affected persons, intended purpose) and distinct outputs (DPIA addresses processing risks, FRIA addresses fundamental-rights risks including non-discrimination, dignity, and access to public services). Where both apply, Article 27(4) explicitly allows the deployer to consolidate the work to avoid duplication, but each output must satisfy its own legal basis.
- Who is "providing public services" under Article 27?
The category covers private operators carrying out tasks of public interest, such as private schools, private hospitals, private operators of social benefits, and private utility operators. The threshold is whether the service is one that would otherwise be provided by a public authority. National implementations of Article 27 will refine the scope. Member state guidance from 2025 and 2026 suggests a broad reading that captures regulated industries with public-service characteristics (healthcare under national health systems, education with public funding) and a narrow reading that excludes purely commercial services. Where the question is contested, the deployer should err on the side of performing the FRIA.
- What happens if I deploy first and complete the FRIA later?
Article 27 requires the FRIA before first use. Deploying without the assessment is non-compliance with Article 27 and triggers the Article 99 penalty regime. The supplying-misleading-information tier at 7.5 million EUR or 1% of global turnover applies if the deployer represents to authorities that the FRIA was completed when it was not. The high-risk non-compliance tier at 15 million EUR or 3% applies if the deployer simply skipped the FRIA. Retroactive completion of the FRIA does not cure the original non-compliance. The defensible course is to complete the FRIA before deployment and update it materially as the system evolves.
- Does the FRIA need to be updated when the system changes?
Yes, where the change is material. Article 27(2) requires the FRIA to be updated where the deployer considers that any of the six elements has materially changed during the period of use. A change to the intended purpose, a new category of affected persons entering the deployment, a new specific risk identified through post-market monitoring, or a change to the human-oversight design all trigger an update. The update obligation makes the FRIA a living document with operational inputs from production. Per-decision records are how the deployer detects when the production population diverges from the procurement scope.
- How does the FRIA interact with Article 11 technical documentation?
Article 11 technical documentation is the provider's obligation. The FRIA is the deployer's obligation. The provider's Article 11 documentation describes the system as it was placed on the market (intended purpose, training data, known limitations, instructions for use). The FRIA describes the system as the deployer puts it into service in a specific context. The deployer uses the provider's Article 11 documentation as an input to the FRIA but cannot substitute one for the other. The provider does not know the deployer's affected categories. The deployer does not know the provider's training methodology. The two documents converge on a complete record of the high-risk deployment when read together.