Sovereignty Collapse: Logging Where Your Prompt Actually Went

A regulator asks a simple question. "For this specific user prompt, submitted at 14:32 UTC last Tuesday, prove which jurisdictions the request and its derived state passed through."

Your application logs say model=claude-sonnet-4-5, region=eu-west-1, latency=2.1s. Your gateway logs say the same. Your provider's invoice confirms the request happened. None of these answer the question. The request entered an EU-hosted gateway, was forwarded to a US-region primary endpoint that failed over to Singapore during a regional incident, and warmed a KV cache on a third-party GPU pool whose residency claims live in a vendor footnote. The audit trail you needed lives at a layer your team does not own.

This is sovereignty collapse: the gap between what your contracts promise about data location and what your runtime can actually prove after the fact. The compliance claim is only as strong as the weakest log line in the chain.

Residency Is Where Data Sits. Sovereignty Is Who Controls It.

The terminology trips up most engineering conversations because residency and sovereignty get treated as synonyms. They are not. Residency is a physical fact: the bytes are on a disk in Frankfurt. Sovereignty is a legal fact: who owns the keys, who can be compelled to disclose, who carries the contract.

A US-headquartered provider running a region in Frankfurt satisfies residency for an EU prompt. It does not satisfy sovereignty if the parent company is subject to US law that can compel disclosure regardless of where the data sits. The EU AI Act, applicable in stages through August 2026, and the GDPR's Chapter V transfer rules both reach into this distinction. So does the post-Schrems landscape, where the EU-US Data Privacy Framework adequacy decision is already under fresh legal challenge by noyb.

For an inference workload, this means a single request can satisfy residency at every hop and still fail sovereignty if any hop is operated by a sub-processor whose legal exposure crosses the boundary. The audit trail has to capture both axes: where the bytes went, and who had the legal authority over them at each step.

The Four Hops Most Teams Don't Log

A prompt from an EU resident arriving at a typical SaaS today touches more layers than any single team has visibility into. Trace one request and you find at least four potential sovereignty transitions:

1. Application gateway: your own ingress, hosted somewhere — often US — terminating TLS, attaching auth, recording the inbound request.
2. AI gateway or router: a layer like LiteLLM, Portkey, TrueFoundry, or a homegrown equivalent that selects a model and provider, applies rate limits, and forwards the request.
3. Inference provider primary: the model endpoint your gateway selected. May be a regional endpoint, may be a global one. Failover behavior is in fine print.
4. Inference provider fallback: where the request goes when the primary is degraded. Often a different region, often a different sub-processor, almost never reflected in your application logs.

Each hop has its own log surface. Each surface uses its own request ID. Almost no one threads a single correlation ID through all four layers, which means reconstructing the path of one request after the fact requires a join across four log systems with different retention windows and different access controls. By the time the regulator's question arrives, the gateway's debug logs have already rolled off.

Per-Request Sovereignty Path as a First-Class Log Field

The fix is not heroic. It is to treat sovereignty path as a structured log field on every request, written eagerly at the layer that has the routing decision in hand, and propagated downstream as a header.

A workable schema:

• sovereignty.gateway_region: where the inbound terminated.
• sovereignty.router_decision: which provider and which region were selected, and why (cache locality, cost, capacity).
• sovereignty.provider_advertised_region: what the provider claims for this endpoint.
• sovereignty.provider_actual_region: what the provider actually returned in response headers (if they expose it).
• sovereignty.failover_chain: ordered list of regions touched if the primary degraded mid-request.
• sovereignty.cache_layer: whether prompt cache or KV cache was involved, and on whose hardware.
• sovereignty.subprocessor_chain: legal entities that touched the request, derived from a static map of provider to sub-processor.

The hard part is not the schema. It is that fields three through seven require the provider to expose information they often do not. Anthropic's Bedrock endpoints will tell you the AWS region. Direct OpenAI calls expose less. KV cache layer is almost never surfaced. The honest log entry has to record unknown_after_handoff for the steps you cannot observe, because pretending otherwise is worse than admitting the gap.

The Contractual Surface That Matches Runtime

Logging only proves what happened. It does not constrain what can happen. The complementary work is a Data Processing Agreement that binds the provider to behaviors your runtime can actually verify.

Three places where standard DPAs fall apart for AI:

Sub-processor lists that match runtime behavior. A sub-processor list is only useful if the runtime cannot route around it. OpenAI publishes a sub-processor list that updates periodically. When Anthropic became a Microsoft Copilot sub-processor in early 2026, the chain of legal exposure for any Copilot tenant changed overnight. Anthropic is excluded from the EU Data Boundary at the time of writing, which means a request that the application thinks is staying inside the boundary may not be. A DPA that lists sub-processors without committing to runtime enforcement is documentation theater.

Residency commitments that survive failover. Every provider with a regional offering implicitly assumes the happy path. The contract language to look for is what happens during incidents: does the provider commit to fail closed (refuse the request rather than route out of region), or fail open (route to whatever endpoint is healthy)? Most default to fail open, because availability sells. For a regulated workload, fail-closed is the only safe default, and it has to be in writing because the runtime configuration alone is not enforceable evidence.

Cache retention policies in writing. Prompt caching and KV caching create derived artifacts that may persist on infrastructure outside the request's nominal region. The cache retention window, the cache eviction policy, and whether cache contents can be subpoenaed independently of the primary request are all questions that most provider DPAs do not address. A cache hit on US infrastructure of a prompt nominally processed in the EU is a transfer event that nobody logged.

The Legal Review Where "The Provider Handles It" Stops Working

The pattern that breaks under scrutiny: the application team points at the provider, the provider points at sub-processors, and the sub-processors point at infrastructure operators. Nobody owns the audit answer.

The shift that holds up under audit is to make sovereignty a first-party engineering concern. That means:

• The platform team owns the gateway log schema and is on the hook for completeness.
• The legal team gets a report, not an explanation: a per-quarter sample of requests with their full sovereignty path attached.
• The vendor management team treats sub-processor changes as a code-level event. When OpenAI adds a sub-processor, the change has a ticket, a review, and a sign-off, not a passive notification email.
• Failover policy is a configuration, not a default. Every region pair has an explicit fail-closed or fail-open setting, with the legal rationale recorded next to the config.

This is administrative work, but it is the work that turns an audit from a multi-week archeology project into a query.

The Tabletop That Tells You What You Don't Have

Run the exercise before the regulator does. Pick a real request from last week. Walk it end-to-end and answer four questions on paper:

1. Which jurisdictions did it touch? Reconstruct the full path from your logs alone. If you cannot, mark which steps required guessing.
2. Who are the legal entities involved? For each hop, name the corporate entity responsible. If the answer is "I think it's the same parent," that is a finding.
3. What persisted, and where? Inputs, outputs, embeddings, cache entries, eval datasets, debug captures. For each, name the storage location and the retention window.
4. What could you produce within 72 hours? GDPR breach notification timelines and AI Act incident reporting both run on tight clocks. If the answer to question one took your team a week, the answer to question four is "not the truth."

The first time a team runs this exercise, the result is rarely embarrassing in the way they expect. The embarrassment is not that data went somewhere it should not have. It is that nobody can tell whether it did. CISA's joint AI tabletop exercises have repeatedly surfaced the same finding: the gap between assumed and provable data flows is the largest unmeasured risk in production AI.

What to Build First

If the audit is a year out and the budget is small, prioritize ruthlessly:

• A correlation ID that survives every hop. One field. Required on every log line. This is a week of plumbing work and it makes every subsequent investigation tractable.
• A sub-processor map maintained in code. A YAML file mapping provider to current sub-processors, updated when the provider's page updates, with a CI check that fails when the upstream changes. This is the difference between "we'll check" and "we know."
• A failover policy switch per provider pair. Default to fail-closed for any pair that crosses a sovereignty boundary. Make the override an explicit deploy.
• A quarterly sample report. Pick fifty requests at random, attach their full sovereignty path, and put the result in front of legal. The point is not the report. The point is to discover, every quarter, which fields are still unknown_after_handoff so the engineering work to close them is visible.

The compliance posture you want is not "we never crossed a boundary." That is a promise no multi-region inference deployment can keep with full honesty. The posture you want is "for any request, we can prove what happened within the time the regulator gives us." That is a posture you build at the gateway layer, in your logs, in your contracts, and in the muscle memory of running the tabletop until the answer comes back without a war room.

The token-routing layer is where sovereignty either holds or collapses. The application layer is too late.