EU AI Act Art.74 Market Surveillance: Why Your Infrastructure Hosting Jurisdiction Determines NCA Access
Post #4 in the sota.io EU AI Act Infrastructure Compliance 2026 Series
Article 74 of the EU AI Act grants national competent authorities (NCAs) comprehensive market surveillance powers over every high-risk AI system operating in the EU. From August 2, 2026, NCAs can demand access to your technical documentation, audit your risk management system, test your AI model in live conditions, and compel you to provide copies of your training datasets.
Most compliance guides treat Art.74 as a documentation readiness problem: have your Annex IV package ready, maintain your post-market monitoring logs, keep your incident records in order. That framing misses the infrastructure dimension. Where you host your AI system directly determines whether your NCA can exercise its Art.74 powers—or whether it runs into a jurisdictional wall you created accidentally by choosing AWS Frankfurt.
What Art.74 Actually Grants NCAs
Art.74 creates the EU's market surveillance framework for AI systems, working alongside the general EU Market Surveillance Regulation (EU 2019/1020). The core powers NCAs receive are:
Documentary access: NCAs can demand your complete Annex IV technical documentation package, your Art.9 risk management system records, your Art.10 training dataset documentation, your Art.12 logs, your Art.72 post-market monitoring data, and your Art.73 serious incident history. Not abstracts—the full records.
System access: NCAs can require you to demonstrate your AI system in controlled conditions. This means live access to the running model: input prompts, outputs, confidence scores, intermediate processing where observable.
Infrastructure access: NCAs can inspect the physical and logical infrastructure hosting your AI system. Under Regulation 2019/1020, market surveillance authorities can enter premises and conduct on-site inspections. For cloud-hosted AI, "premises" extends to the logical environment—your cloud account, your storage buckets, your compute clusters.
Third-party cooperation: NCAs can compel your cloud provider, your SaaS vendors, and your infrastructure suppliers to provide documentation and access. This is where the jurisdictional problem begins.
The Infrastructure Jurisdiction Problem
When a German BNetzA inspector or a French CNIL inspector exercises Art.74 powers against your AWS Frankfurt-hosted AI system, they are dealing with a layered jurisdictional reality:
Layer 1: EU data protection and AI Act jurisdiction applies to your AI system because you process EU residents' data and operate under EU law. The NCA has full legal authority to demand access.
Layer 2: AWS Frankfurt is EU-located but US-owned. Amazon Web Services EMEA SARL (Luxembourg entity) operates AWS Frankfurt. The ultimate parent is Amazon.com, Inc., a US corporation subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713).
Layer 3: The CLOUD Act gap. Under the CLOUD Act, a US government authority—DOJ, FBI, CISA—can compel Amazon to produce data stored on any AWS infrastructure worldwide, including Frankfurt. Amazon is legally prohibited from notifying you in many cases. The EU NCA accessing your training datasets and the US DOJ subpoenaing those same datasets are operating on independent legal tracks, simultaneously, without coordination.
This creates a concrete compliance problem under Art.74: your NCA's evidence access is structurally compromised because the same evidence lives in a dual-jurisdiction zone.
Why This Matters for Art.74 Specifically
Art.74 inspections are triggered by:
- Proactive market surveillance sweeps (NCAs can select providers at random)
- Serious incident reports (Art.73) that trigger investigation
- Complaints from deployers, users, or third parties
- EU AI Office referrals for GPAI models
- Cross-border incidents affecting multiple member states
When an NCA initiates an Art.74 inspection, they need confidence that the evidence you produce reflects your actual system—that logs haven't been modified, that training datasets are complete, that risk assessments represent the live system. If your infrastructure runs on AWS or Azure with a US parent:
- The NCA cannot rule out prior US government access to the same evidence
- You may not be able to disclose if prior CLOUD Act access occurred (gag order provisions)
- The chain of custody for your compliance evidence is legally compromised
A sophisticated NCA inspector who understands CLOUD Act implications will ask: can we trust this evidence?
Three Infrastructure Scenarios for Art.74 Compliance
Scenario A: EU-Sovereign Infrastructure (Compliant)
Your AI system—model serving, training data storage, RMS records, post-market monitoring logs, Annex IV documentation—runs entirely on EU-incorporated providers with no US parent: Hetzner, Scaleway, OVHcloud, IONOS, Infomaniak, or equivalent.
Art.74 outcome: The NCA issues an inspection request. You provide access credentials to your Hetzner object storage for training datasets and your Scaleway instances for model infrastructure. The NCA inspector has full evidence access. No CLOUD Act mechanism applies. Chain of custody is clean.
Infrastructure pattern:
- Object storage: Hetzner Object Storage (S3-compatible) or Scaleway Object Storage
- Model serving: Hetzner dedicated servers or Scaleway GPU instances
- RMS documentation: EU-sovereign document storage or self-hosted with EU-owned data
- Monitoring: Self-hosted Prometheus/Grafana on EU infrastructure
- Logging: OpenSearch/Loki on EU-sovereign compute
Scenario B: US-Owned EU-Region (Partial Risk)
Your AI system runs on AWS Frankfurt (eu-central-1), Azure Germany West Central, or GCP Frankfurt (europe-west3). Your EU data residency settings are configured. You believe you're "EU-compliant."
Art.74 outcome: The NCA requests access. You provide it. Technically, you've complied. But:
- Your cloud provider is subject to CLOUD Act subpoenas for this data
- If prior CLOUD Act access has occurred, you may be legally prevented from disclosing it to the NCA
- Your Art.12 logs are stored in the same CLOUD Act-exposed environment
- Your NCA's findings are based on evidence that a parallel US legal process could have modified, accessed, or compelled disclosure of
The legal risk here is not that the NCA will refuse your evidence—it's that if a serious incident occurs and the US government has already accessed your incident logs under CLOUD Act, you may not be able to provide the NCA with a complete and uncompromised evidence package.
Scenario C: US-Hosted with EU Presence (High Risk)
Your AI system primary infrastructure runs on US East or US West AWS/Azure/GCP. You have some EU components but core training data and model weights are in US regions.
Art.74 outcome: The NCA may not be able to exercise its Art.74 powers at all. Regulation 2019/1020 gives NCAs enforcement jurisdiction within the EU, but compelling access to US-hosted infrastructure requires mutual legal assistance treaties (MLATs)—a process that takes months, not days. Your 30-day Art.74 response window will expire before cross-border legal process completes.
What Specifically Needs to Be in EU-Sovereign Infrastructure
For Art.74 compliance, the following components need guaranteed EU-jurisdiction hosting:
1. Annex IV Technical Documentation Package
Your technical documentation under Art.11 and Annex IV must be accessible to NCAs without jurisdictional complications. This means:
- Documentation version control (git repository or document management) on EU-sovereign infrastructure
- Cryptographic signing with keys that reside entirely in EU jurisdiction
- Immutable audit trails showing document history (for chain-of-custody purposes)
2. Art.9 Risk Management System Records
Your RMS documentation—risk registers, mitigation records, residual risk assessments—requires:
- Storage in EU-sovereign database or document system
- WORM (Write Once Read Many) compliance for immutability evidence
- Automated integrity verification (hash checks) demonstrable to NCA inspectors
3. Art.10 Training Dataset Documentation
Training dataset records accessible under Art.74 include:
- Dataset provenance documentation and lineage graphs
- Bias testing results and methodology records
- Preprocessing pipeline documentation
- Data governance records
These must reside on EU-sovereign infrastructure. Note: the actual training datasets may be large and impractical to fully replicate. The documentation and metadata must be EU-sovereign; for large raw datasets, a hybrid approach (EU-sovereign metadata + EU-sovereign validation splits) is defensible.
4. Art.12 Logs and Art.72 Post-Market Monitoring
Your operational logs under Art.12 and your post-market monitoring system under Art.72 are the primary NCA evidence target in a reactive investigation. These need:
- Real-time log forwarding to EU-sovereign log storage
- At minimum 30-day retention in EU-sovereign storage (NCAs need evidence from the incident period)
- Immutable log architecture (WORM-capable storage, Merkle tree integrity verification)
- Query interface accessible to NCA inspectors remotely without requiring US-provider portal access
5. Model Inference Infrastructure (for Testing Under Art.74)
Art.74 allows NCAs to test your AI system in controlled conditions. This requires:
- An inference endpoint accessible to NCA testing (either live or sandbox environment)
- Model versioning that maps deployed versions to specific Annex IV documentation revisions
- A capability to run inspector-supplied test cases and return unmodified outputs
This last point is significant: NCAs can require you to demonstrate that your AI system produces specific outputs for specific inputs. If your model serving infrastructure is on AWS and NCA access requires AWS IAM credentials, you're providing an EU public authority with credentials to a US-controlled cloud account—a legal complexity most compliance teams haven't mapped.
Designing for Cooperative Art.74 Access
The infrastructure pattern that maximizes Art.74 cooperability:
Principle 1: Segregate compliance evidence from operational infrastructure. Your primary AI workloads can run on mixed infrastructure. Your compliance evidence—logs, documentation, RMS records—must be on EU-sovereign infrastructure with clean chain of custody.
Principle 2: Provide NCA access without AWS/Azure portal dependency. Design your inspection access layer so that NCAs can access evidence through mechanisms you control (API endpoints, read-only access tokens to your systems) rather than through your cloud provider's management plane.
Principle 3: Maintain an NCA access playbook. When Art.74 powers are invoked, you have a defined response window. Your playbook should include: who receives the NCA request, what evidence is provided first, how remote access is provisioned, and how chain of custody is documented.
Principle 4: Document your infrastructure topology in your Annex IV package. NCAs should be able to understand from your technical documentation where every compliance-critical component runs and under what legal jurisdiction. Gaps in this map raise red flags.
The Cooperative Inspection Model
Under Art.74, the expected interaction model between providers and NCAs is cooperative rather than adversarial—particularly before August 2026 when the enforcement machinery is still being established. NCAs in the initial enforcement period are more likely to request documentation access than to conduct surprise on-site inspections.
This cooperative model works better when:
- Your evidence is accessible through documented, provider-controlled interfaces
- Your infrastructure topology is pre-documented and available to NCAs on request
- You have designated a single point of contact for NCA communications (consistent with Art.16 provider obligations)
- Your evidence retrieval process is automated rather than manual (reduces response time)
EU-sovereign infrastructure enables this cooperative model cleanly. Mixed or US-parent infrastructure creates friction at every step—not because NCAs will reject your evidence, but because every handoff involves a jurisdictional negotiation that doesn't need to exist.
Art.74 Infrastructure Compliance: 10-Point Checklist
Before August 2, 2026, verify the following:
| # | Check | Status |
|---|---|---|
| 1 | Annex IV documentation stored on EU-sovereign infrastructure with immutable history | ☐ |
| 2 | Art.9 RMS records on WORM-compliant EU-sovereign storage | ☐ |
| 3 | Art.10 training dataset documentation on EU-sovereign storage | ☐ |
| 4 | Art.12 operational logs streaming to EU-sovereign log store in real time | ☐ |
| 5 | Art.72 post-market monitoring dashboard accessible without US cloud portal | ☐ |
| 6 | Model inference sandbox available for NCA testing without AWS/Azure IAM dependency | ☐ |
| 7 | Infrastructure topology documented in Annex IV (including cloud providers, legal entities, jurisdictions) | ☐ |
| 8 | NCA communication contact designated and published to Art.16 register | ☐ |
| 9 | Art.74 response playbook written and rehearsed (roles, timelines, evidence retrieval) | ☐ |
| 10 | CLOUD Act exposure assessment completed for all compliance-critical infrastructure components | ☐ |
What sota.io's Infrastructure Model Provides
EU-sovereign hosting means your NCA has a clean, single-jurisdiction path to exercise their Art.74 powers. No US parent. No CLOUD Act mechanism. No dual-jurisdiction evidence chain that requires a MLAT to resolve.
For providers building high-risk AI systems for EU markets, the August 2, 2026 deadline is the trigger. But the infrastructure decisions that determine Art.74 cooperability need to be made months earlier—migrating compliance-critical infrastructure in the 30 days before a deadline is not a realistic plan.
See Also
- EU AI Act Art.9 RMS Documentation: Why Your Risk Register Hosting Is a Compliance Variable
- EU AI Act Art.10 Training Data Governance: Why Dataset Storage Location Is a Compliance Decision
- EU AI Act Art.12/19 Record-Keeping: Log Storage Jurisdiction and CLOUD Act Exposure
- EU AI Act Art.74 Market Surveillance: What NCAs Can Inspect and Demand
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.