Regulatory Divergence Is a Routing Problem

Picture the deal that does not close. A German hospital group wants your clinical-summarization feature. Patient data cannot leave Germany. The only model that clears the accuracy bar for German clinical text runs in a US region, and the vendor will not stand up an EU endpoint for one customer. No destination satisfies both constraints. Routing did not dissolve this conflict. It located it, precisely, which is the most useful thing routing does and the part most pitches skip.

Start with why the obvious fix fails. A single global policy has two settings and both lose. Tighten it to the strictest common denominator and you block your best model, truncate the retention a feature depends on, and bury the product under disclosures to satisfy one regulator. Loosen it and you are non-compliant where it counts, which forfeits the enterprise deal and invites enforcement. There is no correct middle, because the constraints are orthogonal, not stricter-or-looser versions of each other . Residency and transparency do not trade off; they stack. Averaging orthogonal constraints produces a policy that is wrong in every market at once.

So tag each request before it reaches a model and route on the tuple: jurisdiction, data class, user type. That selects a region, a model, a retention window, a redaction rule. This is the multi-model routing you already run for cost and capability, with policy promoted to a first-class key. Useful, and not the whole story, because two words in that sentence are doing more work than they admit.

Routing selects a destination; it does not create a capability

Sending a request to Frankfurt does not deliver right-to-erasure, explainability, or deletability. Those are properties the destination must already implement. And the tag has to follow the data past the inference call. A request correctly routed to an EU region, whose output embedding lands in a US vector index, whose prompt sits in a centralized log, whose nightly backup replicates cross-region, is non-compliant in every way that matters while every routing decision showed green. The hard surface is lifecycle: caches, logs, embeddings, backups, sub-processors, and the genuine contradiction between a retention duty and an erasure duty on the same record. Routing is necessary there and nowhere near sufficient.

The tag is derived, and the inputs disagree

A user sits in France, the data originated in Brazil, the contract is governed by Delaware law. Three claims, one tag. Someone has to own the precedence rule that breaks the tie, write it down, and defend it: data-origin residency wins over user location for regulated classes; contract governing law wins for liability and disclosure; the stricter erasure duty wins when two apply. That mapping from legal text to tag is a maintained artifact with a named owner in legal and in engineering, not a lookup that resolves itself. Left unowned, it rots silently between regulatory changes, and you find out at audit.

Price the set with no route

Now the part the single-policy pitch and the routing pitch both hide: the tuples that map to no row. Do not fail them closed to the strictest route and call it solved; that just reproduces the unusable product on a smaller blast radius. Measure them instead. If 4% of addressable traffic, concentrated in one regulated segment, resolves to no valid destination, that is not an engineering exception. It is a board number with three options attached: fund an in-region capability, exit the segment, or accept documented residual risk with an expiry date. Routing earns its keep by making that set small, visible, and priced, not by pretending it is empty.

Treat the table as code: versioned, reviewed, replayable, so you can show which policy applied to any past request and what was true on a given date. That lookup is what an enterprise buyer or auditor reads instead of a brochure . The maze does not shrink. What improves is that you can see exactly where it has no exit, and decide who pays for that.