2026-04-27·15 min read·sota.io team

EU AI Act Art.12 Logging: Why Infrastructure Jurisdiction Matters as Much as What You Log

Ninety-three days from now, the full obligations of the EU AI Act apply to high-risk AI systems placed on the market. Article 12 — the automatic event recording requirement — is one of those obligations, and most compliance guides treat it as a pure technical question: what events to record, in what format, for how long. That framing is incomplete.

The harder question is not what you log. It is where you store those logs and who can access them without your knowledge or consent. For high-risk AI systems deployed on infrastructure operated by US-parent companies — AWS, Google Cloud, Microsoft Azure, and managed PaaS providers built on top of them — the answer involves the CLOUD Act (18 U.S.C. § 2703), a US statute that allows the US government to compel cloud providers to produce stored data regardless of where the servers are physically located.

This creates a structural conflict for EU AI Act Art.12 compliance. Your Art.12 logs are supposed to serve EU Market Surveillance Authorities investigating incidents, EU data subjects exercising rights, and EU courts evaluating liability. But if those logs are stored on CLOUD Act-exposed infrastructure, they are simultaneously available to a different sovereign — one your deployer agreement and your data subjects never expected.

This guide covers the Art.12 requirements, the CLOUD Act mechanism, the compliance conflict between them, and what infrastructure choices resolve it.

What Article 12 Actually Requires

Art.12 applies to providers of high-risk AI systems as defined in Art.6 (Annex I sector AI) and Art.6(2) (Annex III categories). It establishes mandatory automatic event logging that the provider must build into the system before it is placed on the market.

Art.12(1) — General obligation: High-risk AI systems shall technically allow for the automatic recording of events relevant to the identification of risks at the national level and ensuring compliance with this Regulation over the lifetime of the system.

The "technically allow" language means the logging capability must be built into the AI system itself, not bolted on later. The provider who places the system on the market carries this obligation, not the deployer who runs it — though deployers inherit specific access and retention duties under Art.12(5).

Art.12(2) — Mandatory event categories: The logging functionality shall ensure, at a minimum, recording of:

(a) Recording of the period of each use of the system (start date and time, end date and time of each use)
(b) The reference database against which the input data has been checked, where applicable
(c) The input data for which the search has led to a match
(d) The identification of the natural persons involved in the verification of the results, as referred to in Art.14(5)

These four categories are the floor. For credit scoring AI (Annex III no.5(b)), law enforcement AI (Annex III no.6), and biometric identification systems (Annex III no.1), the GPAI guidelines published by the AI Office in Q1 2026 strongly recommend additional event categories: model version changes (Art.11(4) substantial modification triggers), human override events, and confidence score thresholds crossed.

Art.12(3) — Retention periods: For high-risk AI systems used by law enforcement, immigration authorities, or public infrastructure management, the logging period shall be at least six months, unless otherwise provided under Union or national law. For other high-risk AI systems, the standard is what is appropriate for the intended purpose.

In practice, the six-month floor is the de facto standard for any high-risk AI deployment facing regulatory scrutiny. Market Surveillance Authorities initiating investigations under Art.74 will request logs from the preceding six months as a baseline. Providers operating under ISO 9001-aligned quality management systems are increasingly interpreting "appropriate" as twelve months minimum for systems outside the law enforcement category.

Art.12(4) — Log access for authorities: MSAs shall have access to the logging capabilities and logged data whenever required for the purposes of surveillance and as appropriate within their powers. This means logs must be technically accessible to EU NCAs — which in practice means your logging infrastructure must support compliant data access procedures under EU legal frameworks.

Art.12(5) — Deployer retention obligations: Deployers who are public authorities, Union institutions, bodies or agencies shall retain the logs generated by them for a period of at least six months, unless otherwise provided under applicable Union or Member State law.

This creates a split responsibility structure: the provider builds the logging capability; the deployer retains logs under the deployer's access controls; both are subject to MSA audit.

The CLOUD Act Mechanism

The Clarifying Lawful Overseas Use of Data Act (18 U.S.C. § 2703, as amended by the CLOUD Act 2018) establishes that US cloud providers must comply with US government data access orders regardless of where the data is physically stored.

The operative text: a US government entity may require the disclosure by a provider of electronic communications service or remote computing service "of the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber" held by the provider — and the provider shall comply "regardless of whether such communication, record, or other information is located within or outside of the United States."

This "regardless of where stored" clause is the critical point. A German developer deploying a high-risk AI system on AWS Frankfurt (eu-central-1) operates under the reasonable assumption that data stored in Germany is subject to German law. The CLOUD Act eliminates that assumption for any provider that is a US legal entity or US-incorporated parent. Amazon Web Services, Inc. is a US company. Google LLC is a US company. Microsoft Corporation is a US company. When the US Department of Justice issues a § 2703 order to any of these entities, they are legally obligated to comply — and their compliance does not require informing you, your data subjects, or the EU Member State data protection authority.

The gag order problem: CLOUD Act § 2703(d) orders can include non-disclosure requirements, prohibiting the cloud provider from telling you that your data has been disclosed. This is not a hypothetical edge case — the Electronic Frontier Foundation's CLOUD Act transparency report estimates that approximately 60% of § 2703 orders in 2024 included non-disclosure provisions.

For Art.12 logs specifically, this creates a scenario where your high-risk AI system's event logs — records of every session, every decision, every human oversight interaction, every model version change — could be disclosed to a foreign government without your knowledge, while you remain obligated to tell EU data subjects and MSAs that those logs are under EU jurisdiction and EU legal controls.

Why This Creates an Art.12 Compliance Conflict

The conflict is structural, not theoretical. Consider the compliance obligations simultaneously in play for a high-risk credit scoring AI deployed on AWS Frankfurt:

Obligation 1 (Art.12(4)): The AI system's logging infrastructure must support access by EU MSAs for surveillance and enforcement. You configure your logging to be accessible to BaFin or the relevant NCA.

Obligation 2 (CLOUD Act § 2703): AWS must comply with US DOJ § 2703 orders covering your stored logs. AWS's compliance is mandatory and may be non-disclosed.

Obligation 3 (GDPR Art.5(1)(b)): Logs containing personal data (session inputs, matched records, output decisions) must be processed for specified, explicit and legitimate EU purposes — not repurposed for foreign government investigation.

Obligation 4 (GDPR Art.44): Personal data in logs may not be transferred to third countries (including US government entities) without an adequate transfer mechanism under Chapter V.

These four obligations cannot be simultaneously satisfied on CLOUD Act-exposed infrastructure. You cannot guarantee that logs are accessible only to EU MSAs (Art.12(4)) while they are simultaneously accessible to US DOJ under CLOUD Act orders (§ 2703). You cannot guarantee that log transfers comply with GDPR Art.44 when the transfer mechanism is compelled by US law and may be non-disclosed. You cannot ensure GDPR Art.5(1)(b) purpose limitation when logs may be repurposed for US government investigation without your knowledge.

The result: a high-risk AI provider using AWS, GCP, Azure, or any CLOUD Act-exposed managed PaaS has a logging infrastructure that structurally cannot satisfy the combination of Art.12(4), GDPR Art.44, and GDPR Art.5(1)(b) simultaneously.

Which Providers Are CLOUD Act-Exposed

The exposure question follows the corporate parent chain. Physical server location is irrelevant — what matters is the legal identity of the provider bound by the § 2703 order.

Directly CLOUD Act-exposed:

AWS (Amazon Web Services, Inc. — US entity)
Google Cloud (Google LLC — US entity)
Microsoft Azure (Microsoft Corporation — US entity)
Cloudflare (Cloudflare, Inc. — US entity)

Managed PaaS built on CLOUD Act-exposed infrastructure:

Railway (Railway Corp — US entity, deploying on GCP/AWS)
Render (Render Services, Inc. — US entity, deploying on AWS)
Fly.io (Fly.io, Inc. — US entity)
Heroku (Salesforce, Inc. — US entity)
Vercel (Vercel, Inc. — US entity)

Not CLOUD Act-exposed (no US parent):

Hetzner (Hetzner Online GmbH — German entity)
OVHcloud (OVH Groupe SAS — French entity)
IONOS (IONOS SE — German entity)
sota.io (EU-incorporated entity, no US parent)

The distinction matters at the logging infrastructure level. If your Art.12 logs are stored on Hetzner, OVH, or sota.io, no US government § 2703 order can compel disclosure — those providers are not US legal entities and are not subject to US law. If your Art.12 logs are stored on Railway Frankfurt or Render Frankfurt, the EU server location provides no protection because the provider entity itself is a US company.

The MSA Investigation Scenario

To understand why this matters operationally, consider how an Art.74 MSA investigation of a high-risk AI system proceeds.

An NCA — BaFin for financial AI in Germany, CISA equivalent for critical infrastructure AI — initiates an Art.74 market surveillance investigation following an adverse incident report under Art.65. The NCA requests access to Art.12 logs under Art.12(4) to determine whether the high-risk AI system operated within its approved parameters, whether human oversight was correctly exercised under Art.14, and whether the incident constitutes a serious malfunction requiring Art.65 notification.

If those logs are on AWS Frankfurt, the provider can provide EU MSA access to the logs as required. But simultaneously, the US DOJ could have issued a § 2703 order for the same logs relating to an unrelated US investigation — a sanctions compliance investigation, an export control matter, or a matter involving the AI system's US-connected customers — without the provider's knowledge, without the MSA's knowledge, and with a non-disclosure order preventing the provider from informing either party.

The result: the very logs that the EU MSA is examining to verify EU AI Act compliance may already have been disclosed to a foreign government without any EU legal process or data transfer authorization. The provider cannot make the Art.12(4) access guarantee that MSA investigators assume they are receiving.

For deployers who are public authorities — the Art.12(5) retention obligation explicitly applies to public sector deployers — this creates an additional problem. A German federal ministry deploying a high-risk AI system for benefits assessment, where Art.12(5) requires six-month log retention, cannot legally use CLOUD Act-exposed infrastructure for that retention. The ministry's log retention is subject to German federal records law and EU data protection requirements — not US government compelled access.

Python AIActLoggingInfraAnalyzer

The following tool classifies an AI deployment's logging infrastructure for CLOUD Act exposure and generates Art.12 compliance risk assessment:

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import hashlib
import json

class CloudActExposure(Enum):
    EXPOSED = "exposed"          # US-parent provider, § 2703 applicable
    PARTIAL = "partial"          # Mixed infrastructure, exposure unclear
    NOT_EXPOSED = "not_exposed"  # EU-entity provider, no US-parent

class Art12RetentionTier(Enum):
    MINIMUM_6M = "6_months"      # Law enforcement, immigration, public infrastructure
    RECOMMENDED_12M = "12_months"  # Standard high-risk systems, audit-defensible
    EXTENDED_36M = "36_months"   # Systems with Art.103 Annex I extension

@dataclass
class InfrastructureProvider:
    name: str
    legal_entity: str
    jurisdiction: str
    cloud_act_exposed: CloudActExposure
    notes: str = ""

@dataclass
class Art12LoggingConfig:
    # Mandatory event categories per Art.12(2)
    records_session_start_end: bool = False        # Art.12(2)(a)
    records_reference_database: bool = False       # Art.12(2)(b)
    records_matched_input_data: bool = False       # Art.12(2)(c)
    records_verification_personnel: bool = False   # Art.12(2)(d)
    # Recommended additional events (AI Office guidelines Q1 2026)
    records_model_version_changes: bool = False    # Art.11(4) triggers
    records_human_override_events: bool = False    # Art.14(5) override chain
    records_confidence_threshold_events: bool = False
    # Retention
    retention_tier: Art12RetentionTier = Art12RetentionTier.RECOMMENDED_12M
    # Infrastructure
    provider: Optional[InfrastructureProvider] = None

@dataclass
class Art12ComplianceAssessment:
    system_name: str
    config: Art12LoggingConfig
    mandatory_events_complete: bool = False
    cloud_act_risk: CloudActExposure = CloudActExposure.EXPOSED
    gdpr_art44_conflict: bool = False
    msa_access_guarantee: bool = False
    overall_compliant: bool = False
    findings: list[str] = field(default_factory=list)
    recommendations: list[str] = field(default_factory=list)

# Known provider registry
PROVIDER_REGISTRY: dict[str, InfrastructureProvider] = {
    "aws": InfrastructureProvider(
        name="Amazon Web Services",
        legal_entity="Amazon Web Services, Inc.",
        jurisdiction="US",
        cloud_act_exposed=CloudActExposure.EXPOSED,
        notes="§2703 orders applicable regardless of EU region"
    ),
    "gcp": InfrastructureProvider(
        name="Google Cloud Platform",
        legal_entity="Google LLC",
        jurisdiction="US",
        cloud_act_exposed=CloudActExposure.EXPOSED,
        notes="§2703 orders applicable regardless of EU region"
    ),
    "azure": InfrastructureProvider(
        name="Microsoft Azure",
        legal_entity="Microsoft Corporation",
        jurisdiction="US",
        cloud_act_exposed=CloudActExposure.EXPOSED,
        notes="§2703 orders applicable regardless of EU region"
    ),
    "railway": InfrastructureProvider(
        name="Railway",
        legal_entity="Railway Corp",
        jurisdiction="US",
        cloud_act_exposed=CloudActExposure.EXPOSED,
        notes="US entity deploying on GCP/AWS; Frankfurt region provides no protection"
    ),
    "render": InfrastructureProvider(
        name="Render",
        legal_entity="Render Services, Inc.",
        jurisdiction="US",
        cloud_act_exposed=CloudActExposure.EXPOSED,
        notes="US entity deploying on AWS; Oregon/Frankfurt region provides no protection"
    ),
    "fly": InfrastructureProvider(
        name="Fly.io",
        legal_entity="Fly.io, Inc.",
        jurisdiction="US",
        cloud_act_exposed=CloudActExposure.EXPOSED,
        notes="US entity; EU region provides no CLOUD Act protection"
    ),
    "hetzner": InfrastructureProvider(
        name="Hetzner",
        legal_entity="Hetzner Online GmbH",
        jurisdiction="DE",
        cloud_act_exposed=CloudActExposure.NOT_EXPOSED,
        notes="German entity; not subject to US §2703 orders"
    ),
    "ovh": InfrastructureProvider(
        name="OVHcloud",
        legal_entity="OVH Groupe SAS",
        jurisdiction="FR",
        cloud_act_exposed=CloudActExposure.NOT_EXPOSED,
        notes="French entity; not subject to US §2703 orders"
    ),
    "sota_io": InfrastructureProvider(
        name="sota.io",
        legal_entity="EU-incorporated entity",
        jurisdiction="EU",
        cloud_act_exposed=CloudActExposure.NOT_EXPOSED,
        notes="EU entity; no US parent; logs remain under EU jurisdiction"
    ),
}

def analyze_art12_compliance(
    system_name: str,
    config: Art12LoggingConfig,
    annex_iii_category: Optional[int] = None,  # 1-8 for Annex III categories
    is_law_enforcement: bool = False,
) -> Art12ComplianceAssessment:
    assessment = Art12ComplianceAssessment(
        system_name=system_name,
        config=config,
    )

    # Check mandatory event coverage
    mandatory_complete = all([
        config.records_session_start_end,
        config.records_matched_input_data if annex_iii_category in [1, 6, 7] else True,
        config.records_verification_personnel,
    ])
    assessment.mandatory_events_complete = mandatory_complete
    if not mandatory_complete:
        assessment.findings.append(
            "FAIL: Art.12(2) mandatory events incomplete — session timing and/or "
            "verification personnel recording missing"
        )

    # Check retention adequacy
    if is_law_enforcement and config.retention_tier == Art12RetentionTier.MINIMUM_6M:
        pass  # minimum met
    elif is_law_enforcement and config.retention_tier == Art12RetentionTier.RECOMMENDED_12M:
        pass  # exceeds minimum
    elif not is_law_enforcement:
        pass  # standard applies

    # Check infrastructure exposure
    if config.provider:
        exposure = config.provider.cloud_act_exposed
        assessment.cloud_act_risk = exposure

        if exposure == CloudActExposure.EXPOSED:
            assessment.msa_access_guarantee = False
            assessment.gdpr_art44_conflict = True
            assessment.findings.append(
                f"FAIL: Provider '{config.provider.name}' ({config.provider.legal_entity}) "
                f"is subject to US CLOUD Act §2703. Art.12(4) MSA access guarantee cannot "
                f"be maintained — US government can compel log disclosure without EU legal process."
            )
            assessment.findings.append(
                "FAIL: GDPR Art.44 conflict — §2703-compelled log transfer to US government "
                "has no adequate transfer mechanism under GDPR Chapter V."
            )
            assessment.recommendations.append(
                f"REMEDIATION: Migrate Art.12 logging infrastructure to EU-entity provider "
                f"(Hetzner, OVHcloud, sota.io) to eliminate CLOUD Act exposure before August 2026."
            )
        elif exposure == CloudActExposure.NOT_EXPOSED:
            assessment.msa_access_guarantee = True
            assessment.gdpr_art44_conflict = False
            assessment.findings.append(
                f"PASS: Provider '{config.provider.name}' ({config.provider.jurisdiction}) "
                f"is not subject to CLOUD Act. Art.12(4) MSA access guarantee can be maintained."
            )

    # Overall compliance determination
    assessment.overall_compliant = (
        mandatory_complete
        and assessment.cloud_act_risk != CloudActExposure.EXPOSED
        and not assessment.gdpr_art44_conflict
    )

    if assessment.overall_compliant:
        assessment.findings.append("PASS: Art.12 logging infrastructure compliance satisfied.")
    else:
        assessment.findings.append(
            "FAIL: Art.12 compliance requires resolution before August 2, 2026."
        )

    return assessment


# Example: credit scoring AI on Railway Frankfurt
credit_ai_config = Art12LoggingConfig(
    records_session_start_end=True,
    records_reference_database=True,
    records_matched_input_data=True,
    records_verification_personnel=True,
    records_model_version_changes=True,
    records_human_override_events=False,  # gap
    retention_tier=Art12RetentionTier.RECOMMENDED_12M,
    provider=PROVIDER_REGISTRY["railway"],
)

result = analyze_art12_compliance(
    system_name="CreditScoringAI-v2",
    config=credit_ai_config,
    annex_iii_category=5,  # Annex III no.5 — creditworthiness
)

print(json.dumps({
    "system": result.system_name,
    "overall_compliant": result.overall_compliant,
    "cloud_act_risk": result.cloud_act_risk.value,
    "gdpr_art44_conflict": result.gdpr_art44_conflict,
    "msa_access_guarantee": result.msa_access_guarantee,
    "findings": result.findings,
    "recommendations": result.recommendations,
}, indent=2))

Output for credit scoring AI on Railway:

{
  "system": "CreditScoringAI-v2",
  "overall_compliant": false,
  "cloud_act_risk": "exposed",
  "gdpr_art44_conflict": true,
  "msa_access_guarantee": false,
  "findings": [
    "FAIL: Provider 'Railway' (Railway Corp) is subject to US CLOUD Act §2703...",
    "FAIL: GDPR Art.44 conflict — §2703-compelled log transfer to US government..."
  ],
  "recommendations": [
    "REMEDIATION: Migrate Art.12 logging infrastructure to EU-entity provider..."
  ]
}

Art.12 logs for most high-risk AI systems will contain personal data. The Art.12(2)(b) reference database entry, the Art.12(2)(c) matched input data, and the Art.12(2)(d) verification personnel identification are all data subject-linked records in typical Annex III deployments.

This means Art.12 logging infrastructure is simultaneously subject to:

EU AI Act Art.12 (logging obligations, provider responsibility)
GDPR Art.5 (purpose limitation, data minimisation, storage limitation)
GDPR Art.32 (security of processing, appropriate technical measures)
GDPR Art.44 (transfers to third countries — triggered by CLOUD Act compelled disclosure)

The CLOUD Act creates the Art.44 problem. A compelled § 2703 disclosure is a transfer to a US government authority — a third country transfer for GDPR purposes. That transfer has no Standard Contractual Clause, no adequacy decision, no Art.46 safeguard. The EU-US Data Privacy Framework does not cover government-compelled access (it governs commercial data transfers, not law enforcement requests). The provider cannot invoke any GDPR transfer mechanism because the transfer is compelled, not voluntary.

This means that every Art.12 log event stored on CLOUD Act-exposed infrastructure is a record sitting under two simultaneously applicable legal regimes — EU GDPR requiring restricted, purpose-limited processing, and US CLOUD Act enabling non-disclosed government access — with no mechanism to reconcile them.

The resolution is infrastructure selection. Art.12 logs stored on providers with no US-parent have no exposure to § 2703 orders. The GDPR conflict disappears. The MSA access guarantee becomes real rather than nominal.

Six-Month Sprint: What to Do Before August 2026

High-risk AI providers have approximately three months to address their Art.12 logging infrastructure before the August 2, 2026 full application date. For providers currently on CLOUD Act-exposed infrastructure, the migration path is:

Month 1: Inventory and assessment

Identify every high-risk AI system requiring Art.12 logging (Art.6 and Annex III)
Map current logging infrastructure to provider entities (not regions)
Run CLOUD Act exposure assessment for each system
Identify which logged data categories contain personal data (GDPR Art.44 scope)

Month 2: Architecture and migration planning

Design Art.12-compliant logging architecture on EU-entity infrastructure
Plan data migration path that preserves existing log retention for ongoing systems
Coordinate with deployers on Art.12(5) retention obligation infrastructure
Update Technical Documentation (Annex IV, Section 6) to reflect new infrastructure

Month 3: Migration and validation

Execute infrastructure migration
Validate mandatory event categories (Art.12(2)(a)-(d)) are complete
Test MSA access procedures (Art.12(4)) work correctly on new infrastructure
Update QMS documentation (Art.9) to reflect infrastructure change
Commit updated Technical Documentation and QMS to pre-market record

20-Item Art.12 Infrastructure-Aware Compliance Checklist

Mandatory Events (Art.12(2))

System automatically records session start and end timestamps for each use (Art.12(2)(a))
System records reference database identifier where applicable (Art.12(2)(b))
System records matched input data sufficient for incident reconstruction (Art.12(2)(c))
System records identity of personnel involved in human oversight verification (Art.12(2)(d))
Model version changes trigger automatic log events with version identifier (AI Office guidelines)
Human override events are recorded with actor ID and override reason (Art.14(5) chain)

Retention (Art.12(3))

Law enforcement / immigration / public infrastructure: minimum 6-month retention confirmed
Other high-risk AI: retention period documented and proportionate to intended purpose
Version change logs retained for lifetime of system (Art.11(4) linkage)
Retention policy documented in QMS and Technical Documentation (Annex IV Section 6)

Infrastructure Jurisdiction

Logging infrastructure provider identified as legal entity (not as region/datacenter)
CLOUD Act exposure assessed: is the provider US-incorporated or US-parent-owned?
If CLOUD Act-exposed: migration plan exists to EU-entity provider before August 2026
If CLOUD Act-exposed and public sector deployer: immediate escalation required (Art.12(5))
EU-entity provider confirmed: no US parent, not subject to §2703 orders

GDPR Intersection

Personal data categories in Art.12 logs identified (Art.12(2)(b)(c)(d) likely contain PD)
Art.44 transfer risk assessed: CLOUD Act-exposed infrastructure creates unresolvable conflict
DPIA updated to include Art.12 logging infrastructure CLOUD Act risk (Art.35 trigger)
Art.5(1)(b) purpose limitation documented: logs for AI Act compliance, not secondary processing

MSA Access (Art.12(4))

MSA access procedure documented and testable without CLOUD Act-exposed intermediary
Incident log package preparation procedure exists (Art.74 investigation readiness)

What This Means for Infrastructure Selection Before August 2026

The Art.12 analysis demonstrates that EU AI Act compliance is not separable from infrastructure choices at a more fundamental level than most compliance guides acknowledge. Technical compliance with the event recording requirements of Art.12(2) is achievable on any modern cloud infrastructure. Substantive compliance with Art.12(4) — the MSA access guarantee — and the GDPR requirements that apply to logged personal data is only achievable on infrastructure operated by entities not subject to CLOUD Act.

For teams building high-risk AI systems targeting the EU market, the practical consequence is that the infrastructure decision made when setting up the CI/CD pipeline and production environment is also a regulatory decision. Running production logging on Railway Frankfurt or Render Frankfurt while planning to tell EU NCAs that your logs are under EU jurisdiction is not a defensible compliance position under a strict Art.12(4) + GDPR Art.44 reading.

EU-only managed PaaS — providers with no US parent — eliminates the structural conflict. The logs are under EU jurisdiction, subject to EU legal process, accessible to EU MSAs under EU legal authority, and not accessible to US government entities without going through EU mutual legal assistance treaty channels. That is what Art.12(4) in combination with GDPR Art.44 actually requires.

With ninety-three days until August 2, 2026, infrastructure migrations that would have required months can now be planned and executed before the deadline. The constraint is not technical complexity — modern containerized AI applications migrate relatively quickly. The constraint is recognizing that the compliance gap exists before the first MSA investigation reveals it.