Are we required to do a FRIA?

If you are a public-sector body deploying an Annex III high-risk AI system, a private entity providing public services with an Annex III system, a credit-scoring or creditworthiness-evaluation deployer (Annex III 5(b)), or a life/health insurance risk-and-pricing deployer (Annex III 5(c)), yes. Other Article 26 deployers do not have an Article 27 FRIA obligation, though they have related obligations under other parts of Article 26.

When does the FRIA need to be completed?

Before the deployer's first use of the high-risk AI system. For systems in production at the August 2, 2026 enforcement date, the FRIA needs to be completed by that date.

Can we use our existing DPIA as the FRIA?

Partially. Article 27(4) allows the FRIA obligation to be met through existing documentation that covers the required elements. A current DPIA covers some FRIA elements directly and others by extension. The cleanest approach is a combined DPIA+FRIA document with explicit cross-references to both regulations' required elements.

Do we need to publish the FRIA?

The FRIA is not required to be published. The deployer must notify the market surveillance authority of the FRIA's results, and the authority may request access to the full assessment. Internal stakeholders, affected persons through complaint mechanisms, and counterparties in contractual due diligence may also request access.

How often does the FRIA need to be updated?

The regulation requires updates whenever any element of the assessment changes in a way that affects the risk evaluation. In practice, deployers commit to an annual review cadence with off-cycle updates triggered by material changes to the system, the use context, or the deployer's organizational arrangements.

What is the relationship between the FRIA and the human-oversight obligation?

The FRIA identifies the oversight measures the deployer commits to implement. The Article 26 human-oversight obligation requires the deployer to actually assign natural persons with the necessary competence to those oversight roles. The FRIA is the design; the role assignment is the operating reality.

EU AI Act FRIA Templates for Deployers: What the Article 27 Assessment Actually Has to Contain

Article 27 of the EU AI Act requires a Fundamental Rights Impact Assessment (FRIA) from certain deployers of high-risk AI systems before first use. The FRIA must cover the deployment process, the time period and frequency of use, the categories of natural persons and groups likely to be affected, the specific risks of harm likely to have an impact on the categories of persons identified, the human oversight measures implemented according to the instructions for use, and the measures to be taken when those risks materialize, including the arrangements for internal governance and complaint mechanisms. The deployer must notify the market surveillance authority of the FRIA's results.

The August 2, 2026 enforcement date means deployers of in-scope systems need a completed FRIA in hand at that point. The assessment is not a one-time artifact: the deployer must update the FRIA when any element changes that affects the risk assessment. The FRIA also feeds the operational compliance posture under Article 26 by identifying the specific oversight measures the deployer commits to implement.

I want to walk through which deployers are in scope under Article 27(1), the section-by-section structure a defensible FRIA needs, the relationship between the FRIA and the GDPR Data Protection Impact Assessment, and the operational artifacts the FRIA produces.

Which deployers are in scope

Article 27(1) names the deployers required to carry out a FRIA. The scope is narrower than the full set of high-risk AI deployers. Three categories are in scope.

Bodies governed by public law, that is, public-sector deployers of any high-risk AI system listed in Annex III.

Private entities providing public services, when those entities deploy a high-risk AI system listed in Annex III. The reference to "public services" captures private operators that perform functions analogous to public-sector functions, such as essential utilities, public healthcare access, or social services delivered under public-sector arrangement.

Deployers of high-risk AI systems used to evaluate the creditworthiness of natural persons or establish their credit score (Annex III, point 5(b)), and deployers of high-risk AI systems used for risk assessment and pricing in relation to life and health insurance (Annex III, point 5(c)). These are private-sector financial deployers explicitly named.

Deployers outside these categories operating other high-risk AI systems do not have an Article 27 FRIA obligation, though they retain the other Article 26 obligations and may have voluntary or sectoral reasons to conduct a fundamental-rights assessment regardless.

What the FRIA has to contain

Article 27(1) specifies the FRIA's six required elements.

A description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose. The description has to be concrete: which business process, which steps in the process, which decisions the AI system contributes to, what happens with the AI output downstream.

The period of time and frequency in which the system is intended to be used. The element captures both the calendar duration (six months pilot; ongoing production; periodic seasonal use) and the operational rhythm (continuous; daily batch; on-demand per case).

The categories of natural persons and groups likely to be affected by the use of the system in the specific context. Categories include the direct subjects of the AI decision, the populations from which the subjects are drawn, and any indirect affected parties such as family members or employers.

The specific risks of harm likely to have an impact on the categories of natural persons or groups of persons identified, taking into account the information given by the provider under Article 13. The element couples the deployer's knowledge of the use context with the provider's documentation of the system's capabilities, limitations, and known failure modes.

A description of the implementation of human oversight measures, according to the instructions of use. The human-oversight description must reference the natural persons assigned to oversight roles, the competence those persons have, the points in the workflow where oversight applies, and the authority those persons have to intervene.

The measures to be taken if the risks identified materialize, including arrangements for internal governance and the complaint mechanisms available to affected persons. The element is the deployer's incident-response posture for fundamental-rights events.

The section-by-section structure of a defensible FRIA

A working FRIA document follows the Article 27(1) elements as its top-level structure. A defensible version of each section in practice:

Section 1: Deployment process. A diagram or workflow description of the business process the AI system operates in. The diagram includes the human decision points, the AI decision points, the data inputs at each step, and the outputs that feed downstream. The diagram should be detailed enough that a fundamental-rights expert reading it can identify the decision points where AI output materially affects natural persons.

Section 2: Time and frequency. A statement of the deployment's calendar duration, the operational frequency, the expected throughput per period, and the conditions under which the deployment would be paused or terminated. Pilot deployments warrant explicit pilot-specific FRIA scoping with milestones for transition to production.

Section 3: Affected persons. A categorization of the natural persons affected with population estimates where available. The categorization should be specific: not "applicants" but "applicants for loan products in the credit-card segment in member states X, Y, Z, in calendar year 2026". The categorization should call out groups particularly vulnerable to harm, including but not limited to those protected under EU anti-discrimination law.

Section 4: Specific risks of harm. A risk catalog covering accuracy failures, discrimination, denial of service, lack of meaningful information about the AI's role in the decision, inability to contest or appeal the AI-influenced decision, and any other risk class relevant to the use case. Each risk includes the affected population, the magnitude of the potential harm, the likelihood given the system's documented performance, and the cumulative impact at the deployment's scale.

Section 5: Human oversight. A description of the natural-person oversight assigned to the workflow, including which steps the oversight applies to, the competence requirements for the oversight role, the training the natural persons in the role have received, the authority those persons have to override the AI output, and the resources (time, information, tooling) the persons have to exercise oversight meaningfully.

Section 6: Risk response and complaints. The internal escalation procedure for identified risk events, the threshold at which deployment is paused or suspended, the relationship of the AI workflow to existing complaint and appeal mechanisms, and the contact point for affected persons to raise concerns. The section should be explicit about the timeline for response and the records retained for each complaint.

How the FRIA interacts with the GDPR DPIA

When the AI system processes personal data, the deployer also has a GDPR Article 35 DPIA obligation if the processing is likely to result in a high risk to the rights and freedoms of natural persons. The FRIA and the DPIA cover overlapping but distinct ground.

The DPIA is data-centric: it focuses on what data is processed, why, by whom, under what legal basis, with what retention, with what security measures. The FRIA is decision-centric: it focuses on the AI system's role in a decision process and the impact on affected persons regardless of whether personal data is the input.

The regulation allows the FRIA to build on the DPIA where applicable. Article 27(4) states that the obligation in Article 27(1) is fulfilled by other parts of the deployer's documentation that already meet the assessment's requirements. A deployer with a current, comprehensive DPIA can extend it to cover the FRIA elements rather than producing a parallel document.

In practice, the cleanest approach is a single combined DPIA+FRIA document with explicit cross-references to Article 35 and Article 27, structured so each regulation's required elements appear as named sections that an auditor can verify against the statutory text.

The operational artifacts the FRIA produces

A completed FRIA is itself an artifact, but the value of the assessment is in the operational artifacts that flow from it.

The human-oversight role definitions become the input to the deployer's Article 26 obligation to assign natural persons with the necessary competence to the oversight role. The competence requirements identified in the FRIA become the qualification criteria.

The risk catalog becomes the input to the deployer's monitoring program under Article 26(5) (the operation-monitoring obligation). The monitoring metrics are calibrated to detect when the risks identified in the FRIA materialize at higher rates than the assessment assumed.

The complaint mechanisms become the input to the deployer's customer-facing communications and the records retained when complaints are received. The complaint records feed the periodic FRIA update cycle.

The decision-point inventory becomes the input to the deployer's Article 19 logging architecture: the AI request boundary where every model call gets a per-decision audit record needs to align with the decision points the FRIA identified as material.

The Article 19 logging anchor

Every fundamental-rights risk the FRIA identifies needs a verification mechanism. The verification mechanism is the per-decision audit record that captures who was authorized, what decision was made, what data classification applied, what policy governed the decision, and what the outcome was.

Without per-decision records, the FRIA's risk catalog is unverifiable: the deployer cannot demonstrate, after the fact, whether the identified risks materialized, at what rate, against which affected populations, and under what oversight. The FRIA becomes a planning document with no operating reality behind it.

With per-decision records, the FRIA becomes a reviewable assessment that the deployer can update against actual operating data on each review cycle. The records are also the evidence the deployer presents to the market surveillance authority on request.

DeepInspect

DeepInspect's role in the FRIA workflow is to produce the per-decision audit records the FRIA's risk verification depends on. DeepInspect sits inline between authenticated users or agents and the LLMs they call, binds every request to a verified identity, enforces per-route per-role policies, and writes a per-decision audit record outside the calling application.

The audit record contains identity, role, policy version, data classification, decision outcome, and timestamps with sufficient precision to correlate across systems. The record format aligns with the data elements Article 19 requires for the deployer's logging obligation, and the same record stream feeds the FRIA's risk verification.

For a deployer in Article 27 scope, the FRIA is the planning artifact and the per-decision audit log is the operating evidence. The two together form the deployer's defensible compliance posture for fundamental-rights review.

If you are facing the August deadline as an Article 27 deployer and your FRIA depends on application logs that the application controls, let's talk today.