EU AI Act Art.27 FRIA Monitoring, Review and Update Obligations: Continuous Compliance After Initial Assessment (2026)

Post #3 in the sota.io EU AI Act FRIA 2026 Series

Post #1 established who must conduct a Fundamental Rights Impact Assessment under Art.27. Post #2 provided a seven-section template and methodology. This post addresses the question that organisations most often miss when they first focus on Art.27: the FRIA is not a point-in-time compliance box to tick. It is an ongoing obligation.

After completing your initial FRIA, three ongoing requirements take over: a duty to update the FRIA when the system or its deployment context changes, a duty to retain the documentation for ten years, and a practical need for periodic review even absent formal changes. Each of these has operational consequences for how you structure your AI governance programme.

Why Ongoing Obligations Matter

Most compliance attention before August 2, 2026 focuses on getting the initial FRIA done in time. That is understandable — the deadline pressure is real. But organisations that treat the FRIA as a one-time deliverable will find themselves out of compliance within twelve to eighteen months of the initial assessment, because high-risk AI deployments change. Models are updated. New use cases are approved. The pool of affected persons expands. Operational contexts shift.

Art.27 anticipates this. The update obligation in Art.27(3) ensures that the FRIA reflects the actual, current state of the deployment — not the state at the time of initial assessment. Failing to update after a qualifying change is a violation in its own right, separate from any deficiency in the original FRIA.

Understanding the ongoing obligations also shapes how you build the initial FRIA. A document written with future updates in mind — with clear version control, modular sections, and explicit change-trigger criteria — is far easier to maintain than one drafted as a static compliance artefact.

The Art.27(3) Update Obligation: When Must You Revise the FRIA?

Art.27(3) of the EU AI Act states that the deployer shall update the Fundamental Rights Impact Assessment as necessary in light of any changes to the high-risk AI system or its operating context that may affect the assessment.

Three categories of change can trigger an update obligation:

1. Changes to the AI System Itself

The most obvious trigger is a change to the AI system you are deploying. This includes:

• Model updates or new model versions released by the provider. Even if the provider has conducted their own updated conformity assessment, a changed model may alter how rights are affected in your specific deployment context. A credit-scoring model updated with new training data may exhibit different demographic performance characteristics. A recruitment-screening system updated to incorporate new signals may affect new groups of applicants differently.

• Changes to input features or output interpretation. If the system begins using new data fields — even fields your own organisation controls — and those fields relate to protected characteristics or function as proxies for them, the fundamental rights risk profile of the deployment has changed.

• Changes to the decision-making pipeline. If the AI output was previously one factor among many in a human decision and the process is reconfigured so the AI recommendation carries more weight, the effective impact on affected persons has increased even if the model itself is unchanged.

2. Changes to the Operating Context

Art.27(3) covers not just the system but its operating context. This is a broader concept that encompasses:

• Expansion to new categories of affected persons. If your HR-screening AI, initially deployed for one job category, is extended to additional roles — particularly roles in a different labour market segment with different baseline demographics — the fundamental rights analysis for that new population has not been done.

• New geographic scope. Deploying to a new EU member state is not automatically covered by the original FRIA, because the legal framework for human oversight and redress may differ, and local regulatory guidance may impose additional considerations.

• Changes to human oversight arrangements. Art.27(1)(g) requires the FRIA to document the human oversight measures in place and the possibility for affected persons to seek redress. If your human review process changes — reviewers are removed, the escalation threshold is altered, the redress pathway is restructured — the FRIA section covering these arrangements is outdated.

• Changes in the volume or frequency of deployment. A system deployed at limited scale may have manageable fundamental rights exposure. A tenfold increase in deployment volume — affecting far more persons under the same per-decision risk profile — changes the aggregate risk assessment even if each individual interaction is identical.

3. Changes in the Legal or Regulatory Context

This category is often overlooked. Changes in applicable law — new supervisory authority guidance, changes to sector-specific rules, new adequacy decisions or their withdrawal, national AI Act implementing measures — can alter the fundamental rights analysis even if the system and deployment are unchanged. If a national supervisory authority issues guidance that changes how Art.27 applies to your sector, an update to address that guidance is appropriate.

Operational Change vs. Substantial Modification: A Critical Distinction

Not every change to a high-risk AI deployment triggers a FRIA update with equal weight. It is important to distinguish between:

Operational changes — changes within the parameters of the original deployment that do not materially alter the fundamental rights profile. Routine model re-training on updated but similarly distributed data, threshold adjustments within the documented range, performance monitoring interventions that do not change decision logic, and minor UI changes that do not affect how decisions are communicated to affected persons are examples of operational changes. These may trigger a FRIA review but do not necessarily require a full update.

Substantial modifications — changes that materially alter the system's intended purpose, its performance characteristics, or its risk profile. The EU AI Act defines substantial modification as a change to a high-risk AI system after it has been placed on the market or put into service which affects compliance with the requirements or results in a change to the intended purpose. A substantial modification triggers not only a FRIA update but a new conformity assessment by the provider, and deployers should treat a provider's notification of a substantial modification as an automatic FRIA update trigger.

The practical implication: your FRIA governance process should include a change classification procedure — a lightweight internal review each time a change to the AI system or its deployment is proposed, that asks:

1. Does this change affect which persons are affected, how many, or in what way?
2. Does this change affect protected characteristics exposure, directly or via proxy features?
3. Does this change affect the human oversight arrangements or redress pathways?
4. Would a market surveillance authority reviewing our compliance expect to see this change reflected in the FRIA?

If any answer is yes, a FRIA update is required before the change is deployed.

The Annual Review: Even Without Changes

Art.27 does not explicitly mandate an annual review in the absence of qualifying changes. However, conducting a structured annual review is strongly recommended for three reasons:

First, the "as necessary" language in Art.27(3) requires a judgment call about whether changes rise to the level of requiring an update. An annual review provides a structured opportunity to assess accumulated smaller changes — none of which individually crossed the update threshold — that together may have materially shifted the deployment's fundamental rights profile.

Second, supervisory authorities assessing compliance will typically ask when the FRIA was last reviewed, not just when it was first prepared. A FRIA dated August 2026 that has never been touched by mid-2027 invites questions about whether the deployer has a genuine ongoing compliance process or simply completed the FRIA to check a box.

Third, annual reviews catch documentation drift — situations where the actual deployment has diverged from what the FRIA describes, without any single qualifying change having been identified. This drift is common in organisations where the team responsible for AI operations and the team responsible for compliance documentation are not the same people.

Annual Review Checklist

Conduct the following review annually, and document the outcome:

• Confirm the description of the AI system and its purpose matches the system currently deployed
• Confirm the list of affected persons and affected groups remains accurate
• Confirm the fundamental rights risks identified remain the primary risks, and no new risks have emerged from operational experience
• Confirm the mitigation measures documented are still in place and effective
• Confirm the human oversight arrangements are operational as documented
• Confirm the redress pathways are functional and accessible
• Confirm no regulatory guidance has been issued since the last review that changes the analysis
• Review any incidents, near-misses, or complaints since the last review for fundamental rights implications
• Confirm the FRIA has been provided to the provider where required under Art.26

Document the outcome of the review — even if no changes are required — as a timestamped review record appended to the FRIA version history.

Art.27(5): The Ten-Year Retention Requirement

Art.27(5) requires deployers to retain the Fundamental Rights Impact Assessment and all documentation related to it for ten years from the date of its completion or, if the system is still in use, for ten years from the date the system ceases to be used.

This has several practical implications:

Scope of retained documentation. The retention obligation covers not just the FRIA document itself but the documentation it references and relies on: the system description documents from the provider, the records of consultation with affected groups or their representatives, the risk register, the mitigation plans, and the review records from annual reviews and update assessments.

Version control. Because the FRIA is subject to updates, you must retain all versions, not just the current one. A market surveillance authority investigating a complaint about a decision made in 2027 under a system deployed in 2026 will want to see the FRIA as it existed at the time of that decision, not the revised 2029 version.

Storage jurisdiction. The FRIA may reference personal data — names of affected persons consulted during the assessment, details of specific incidents that influenced the risk analysis, or other information that falls within GDPR scope. The storage location for FRIA documentation is therefore subject to GDPR Chapter V transfer restrictions. Storing FRIA documentation — including the underlying evidence it relies on — on US-jurisdiction cloud infrastructure introduces CLOUD Act exposure for compliance documentation that market surveillance authorities may request under Art.74.

Practical implication for SaaS deployers. If you are using a SaaS platform to manage FRIA documentation — a GRC tool, a document management system, or a compliance platform — verify that the platform is EU-hosted and not subject to US jurisdiction. Market surveillance authority requests for FRIA documentation are increasingly likely as enforcement ramps up after August 2026. FRIA documentation stored on infrastructure under a US-parent company's control is potentially reachable under CLOUD Act subpoenas that bypass GDPR Art.48's judicial cooperation requirements.

Building a FRIA Governance Programme

Treating the FRIA as part of an ongoing AI governance programme rather than a one-time deliverable requires establishing several operational capabilities:

FRIA registry. Maintain a central registry of all FRIA assessments — one per qualifying high-risk AI deployment. The registry should record the system, the deployer entity, the date of initial assessment, the date of last review, the date of last update, and the storage location of the current and all prior versions.

Change notification pipeline. Establish a process by which changes to AI systems — model updates, new provider releases, changes to input features, deployment expansions — are routed through a FRIA impact assessment before implementation. This does not require a heavy process; a lightweight classification form reviewed by the AI compliance officer or DPO is sufficient for most changes.

Integration with DPIA process. For AI systems that also trigger a GDPR Art.35 DPIA — which applies when processing is likely to result in high risk to natural persons — coordinate the FRIA update review with the DPIA review. Many triggering events are shared, and the shared foundation sections of both documents should remain consistent.

Provider notification tracking. Under Art.26, deployers are required to cooperate with providers and competent authorities. When providers notify deployers of substantial modifications or significant changes to the AI system, those notifications should trigger an automatic FRIA review. Track these notifications in the FRIA registry.

Incident integration. Any incident involving the high-risk AI system that has fundamental rights implications — a biased output affecting a protected group, a failure of the human oversight mechanism, a complaint from an affected person about the impact on their rights — should be routed into the FRIA review process. Art.27 documentation should capture the incident and the FRIA's assessment of whether the incident reflects a systemic risk or an isolated event, and whether mitigation measures require updating.

Practical FRIA Continuous Compliance Checklist

The August 2, 2026 Transition: Getting Ongoing Compliance Right From Day One

For deployers conducting their first FRIA to meet the August 2, 2026 deadline, the ongoing compliance structure matters from the moment the initial assessment is complete. A few practical recommendations:

Build the governance process before you finish the first FRIA. If you write the FRIA document but have no established process for updates, you will have a compliant document on August 2 and a non-compliant programme by October.

Date and version the initial FRIA clearly. The document should state on its face that it is Version 1.0, completed on a specific date, and subject to review under the procedures documented in your AI governance policy.

Schedule the first annual review immediately. Put a calendar reminder for twelve months from the date of initial completion, and identify who owns the review.

Coordinate with the DPO. If your organisation has a DPO under GDPR, the DPO should be aware of the FRIA and involved in the annual review. Many of the obligations are parallel, and the DPO's expertise in privacy impact assessments is directly transferable.

What Comes Next in This Series

Post #4 covers sector-specific FRIA considerations for deployers in regulated sectors: HR and employment, credit and financial services, and education. The risk profiles, stakeholder groups, and mitigation measures differ significantly across these sectors, and the template in Post #2 requires sector-specific adaptation.

Post #5 will be the FRIA compliance finale: a complete documentation package, an August 2026 readiness checklist, and the key failure modes to avoid.

Related posts:

• Post #1: EU AI Act Art.27 FRIA — Who Must Conduct It and How
• Post #2: FRIA Template & Methodology: Seven-Section Assessment Guide
• EU AI Act Art.26 Deployer Obligations: Complete Guide 2026
• EU AI Act CE Marking: Complete Implementation Checklist (August 2026)
• EU AI Act EU Database Registration: Complete Deployer Guide 2026