EU AI Act Art.75-76: NCA Corrective Actions and GPAI Oversight — Developer Response Guide 2026

Post #2 in the sota.io EU AI Act Enforcement Series

In Part 1 of this series, we covered how national competent authorities (NCAs) initiate market surveillance audits under Art.74. Part 2 covers what happens next: when NCAs move from investigation to action.

Art.75 enables NCAs from different EU member states to coordinate enforcement against a single provider. Art.76 gives the EU AI Office direct oversight powers over providers of general-purpose AI models. Together, they define the corrective action landscape that high-risk AI developers will navigate after August 2, 2026.

The Moment NCA Moves from Observation to Action

During an Art.74 investigation, the NCA is gathering evidence. The moment it forms a view that your system is non-compliant — or poses a risk — it shifts from auditor to enforcement authority.

Two enforcement tracks run in parallel after this shift:

1. Corrective measures — the NCA orders you to fix the identified problem within a defined period. These range from documentation updates to system modifications to withdrawal from the market.

2. Restrictive measures — the NCA limits or suspends your system's use in the market while the corrective process runs. These are immediate.

Which track applies depends on the severity of the non-compliance and whether a serious risk to health, safety, or fundamental rights exists.

Art.75: Cross-Border NCA Coordination

EU AI Act Art.75 addresses market surveillance of AI systems that fall under multiple EU legal frameworks simultaneously. If your high-risk AI system is also subject to DORA (financial sector), the Medical Devices Regulation, or other sector-specific EU law, Art.75 coordinates the NCA responsible for AI Act compliance with the sectoral supervisory authority.

What Art.75 enables across member states:

When an NCA in one member state (say, Germany's BNetzA) receives a complaint or identifies a potential violation involving an AI system also marketed in France, the Netherlands, and Spain, Art.75 provides the coordination mechanism:

• The requesting authority contacts other member state NCAs to share information, request joint action, or request that they investigate within their jurisdiction.
• The requested authority must respond within 30 days unless it has already acted on the same system.
• Evidence gathered in one jurisdiction can be used in enforcement proceedings in another.

What this means for SaaS developers:

If your high-risk AI product is available EU-wide, a single complaint in any member state can trigger coordinated investigation across all markets where you operate. The era of "we only need to worry about the German NCA" ended with Art.75.

Developer preparation:

• Maintain a lead NCA designation in your documentation — identify which member state is your primary market and therefore most likely to be the coordinating authority.
• Ensure your technical documentation package is ready in English (accepted by all NCAs) plus the language of your primary market.
• Configure your incident reporting pipeline to notify your DPO and legal team when any NCA — not just your primary market's NCA — contacts you.

Cross-Border Infrastructure and Art.75

A frequently overlooked dimension of Art.75 is infrastructure access. When NCAs coordinate across borders, they exchange information about your system's architecture, data flows, and audit logs. If your infrastructure spans US-based cloud providers, the question of who can access what becomes legally complex.

Art.75 coordination between EU NCAs assumes that the evidence they share is within EU jurisdiction. Audit logs stored on AWS US-East, model training data in Google Cloud US-Central, or API gateway telemetry in Azure East US can create gaps in what EU NCAs can demand versus what US discovery processes might compel.

EU-native infrastructure (Hetzner Germany, OVHcloud Paris, Scaleway) keeps all evidence within the same jurisdiction as the enforcement action. This reduces the CLOUD Act exposure that US-parent cloud providers carry into every cross-border EU enforcement scenario.

Art.76: EU AI Office Oversight of GPAI Models

Art.76 carves out a distinct oversight track for providers of general-purpose AI models (GPAI models) — models like GPT-4o, Claude 3, or Gemini 2.0 that have at least 10^25 FLOPs of training compute or designated systemic risk.

The EU AI Office — not national NCAs — has primary jurisdiction over GPAI model providers under Art.76.

What Art.76 gives the EU AI Office:

• Power to request the GPAI provider to supply technical documentation, training data information, and model evaluation results.
• Authority to conduct its own evaluations of the model (including adversarial testing).
• Power to order the GPAI provider to take corrective measures, restrict availability, or suspend the model if it poses systemic risk.
• Ability to coordinate with NCAs in member states to investigate downstream deployments built on the GPAI model.

This creates a two-level enforcement structure:

EU AI Office (Art.76)
└── Investigates/acts on: GPAI model providers (OpenAI, Anthropic, Google, Meta)

National NCAs (Art.74/75)
└── Investigate/act on: High-risk AI system providers who may build on GPAI APIs

If you build a high-risk AI system using a third-party GPAI model (e.g., a medical triage tool built on Claude or GPT-4), you are subject to Art.74/75 NCA oversight for your system while the underlying model provider faces separate Art.76 EU AI Office oversight.

What Corrective Actions Actually Mean for SaaS

The EU AI Act's enforcement mechanisms were designed primarily for hardware products (robots, medical devices, vehicles). For SaaS developers, the terminology needs translation.

Order Type 1: Documentation Remediation

NCA may order: Update or supplement your technical documentation, risk management system documentation, or conformity assessment records.

For SaaS: This is the most common first-step order. You have a defined period (typically 10 working days to start, longer for completion) to provide the corrected documentation. The system stays live.

Developer action: Have your compliance documentation version-controlled. When an NCA orders a remediation, you need to track exactly what changed, when, and who verified it.

Order Type 2: Technical Modification

NCA may order: Modify the AI system to bring it into conformity — this might mean changing the algorithm, retraining on different data, modifying human oversight interfaces, or changing logging behavior.

For SaaS: This is a software update that must be completed within the ordered timeframe. If the modification constitutes a "substantial modification" (as defined in Art.3(23)), it may require re-running conformity assessment before the corrected version goes live.

Developer action: Your CI/CD pipeline needs a "compliance branch" track — a way to deploy corrective updates with full audit trail that you can present to the NCA as evidence of compliance.

Order Type 3: Restriction of Use

NCA may order: Restrict who can use the system, in which contexts, or for which use cases, while the underlying compliance issues are resolved.

For SaaS: This is a feature flag with regulatory backing. You're required to prevent specific user segments, use cases, or deployment contexts from accessing the system. Your access control systems must be granular enough to enforce this.

Developer action: Build use-case and user-segment access controls at the API gateway level — not just in the UI. NCAs will look at whether technically capable users could bypass UI-level restrictions.

Order Type 4: Withdrawal from Market

NCA may order: Cease making the AI system available in the relevant market. For SaaS, this means suspending service to users in the ordering jurisdiction.

For SaaS: Geographic service suspension is the nuclear option. Unlike hardware recall (which requires physically collecting products), SaaS withdrawal means blocking access based on jurisdiction. Your infrastructure must support geographic service gating.

Developer action: Implement jurisdiction-level access controls now, before you're ordered to activate them. A country-level kill switch is easier to add during normal development than during a 10-day NCA compliance deadline.

Developer Response Protocol When Ordered to Take Corrective Action

The moment you receive formal written notice from an NCA that corrective action is required:

Hour 0: Receipt and Escalation

• Log the notice with timestamp and jurisdiction.
• Notify your legal team and DPO immediately.
• Identify which specific compliance gap the NCA has identified.
• Assign a single internal owner (compliance lead) for the response.

Day 1-3: Initial Response

• Send written acknowledgment to the NCA confirming receipt.
• Request clarification on any ambiguous requirements (this pauses some timelines).
• Begin internal technical assessment of what the corrective action requires.
• Identify whether the required change constitutes a substantial modification.

Day 5-8: Corrective Action Execution

• Implement the ordered change in a staging environment first.
• Run your internal conformity checks against the updated system.
• Document every step in your audit trail.
• If you can't meet the deadline: communicate proactively with the NCA in writing — unexplained non-compliance is treated as defiance, proactive communication with justification is treated as good faith.

Day 10: Compliance Deadline

• Deploy the corrective change to production.
• Send written confirmation to the NCA that the ordered action has been completed.
• Include your updated technical documentation reflecting the change.
• Request formal acknowledgment that the NCA is satisfied with the remedy.

Day 30-90: Verification Period

• Expect the NCA to verify your corrective action was effective.
• This may involve another audit request or remote testing.
• Maintain heightened monitoring of the affected system components during this period.

GPAI Downstream Risk: When Your Upstream Model Is Under Investigation

If your high-risk AI system depends on a third-party GPAI model API, Art.76 investigations into your provider can create downstream risk for you.

Scenario: The EU AI Office opens an investigation into a GPAI model provider under Art.76 and determines the model poses systemic risk. The Office can order the provider to restrict access to certain use cases — which may include exactly the use case you've built your system around.

What this means for you:

• Your system's conformity assessment may need to be re-run if the underlying model changes significantly.
• If the GPAI model is restricted or suspended, your API-dependent service goes down along with it.
• The NCA overseeing your high-risk AI system may ask for evidence that your GPAI model dependency has been evaluated for systemic risk.

Developer preparation:

• Document your GPAI model dependency in your technical documentation (Art.9 requirement).
• Monitor EU AI Office communications about your model provider.
• Have a fallback plan if your GPAI API becomes restricted.
• Consider whether your use case could be served by an alternative model if your primary provider faces enforcement action.

The Procedural Rights You Have Before NCA Acts

Before an NCA can impose a restriction or withdrawal order, the EU AI Act's procedural guarantees give operators the right to be heard. Specifically:

• The NCA must give you written notice identifying the problem and the proposed measure.
• You have the right to submit written observations within a period of at least 10 working days.
• The NCA must consider your observations before finalizing any measure.
• You can present technical evidence showing why the proposed measure is disproportionate.

Exception: If the non-compliance poses an immediate, serious risk to health, safety, or fundamental rights, the NCA can impose temporary restrictive measures immediately and give you the right to be heard afterward.

This due process window is your most important window for corrective action. The moment you receive a notice of proposed measures, act immediately — don't wait for the right to be heard to expire before beginning remediation.

What Comes Next in This Series

In Part 3 of this series, we'll cover Art.79 and Art.80 — the complaints mechanism for affected persons and the right of individuals to request explanations of AI-driven decisions. For SaaS developers who deploy high-risk AI systems that affect individual users, these provisions create new transparency obligations and response protocols.

Series overview:

1. Art.74: What NCAs Will Actually Check — Developer Guide ✓
2. Art.75-76: Corrective Actions and GPAI Oversight ← you are here
3. Art.79-80: Complaints + Rights of Affected Persons (coming next)
4. Art.81-82: Confidentiality + Cross-Border Enforcement
5. Art.99/101: Penalties + Appeals — Complete Enforcement Checklist Finale

The EU AI Act enforcement framework becomes fully applicable August 2, 2026. For high-risk AI providers, the window for proactive compliance is closing. EU-native infrastructure removes one major variable from this equation — if your audit logs, model artifacts, and compliance documentation live outside US-parent cloud providers, you eliminate CLOUD Act exposure from your NCA audit risk profile. That's one less thing to explain to a cross-border coordinated investigation under Art.75.