Compliance-Aware Model Routing: Routing by Data Classification, Not Just Cost

Model routing is usually sold as a cost lever. Inspect each request, send it to the cheapest model that can answer well, and watch the AI bill fall. That framing is correct, and for many teams it is the first reason to adopt a router. But in a regulated, on-premises deployment, the router is doing something more consequential than saving money. It is deciding which model is allowed to see which data, where that inference runs, and what evidence survives afterwards.

That makes the router a governance control, not just an optimisation. A cost-only router that ignores data classification can quietly send a document containing personal or restricted data to a model or location that policy forbids — and produce a lower invoice while doing it. Compliance-aware routing inverts the priority: policy first, cost second.

This piece explains what compliance-aware routing is, the classification and residency logic it enforces, the architecture patterns that make it work in private infrastructure, and the failure modes to design against.

Cost routing and compliance routing solve different problems

Cost-based routing, covered in How LLM Routing Reduces AI Cost and Energy Consumption, answers one question: what is the cheapest model that can handle this task well? It sorts requests by difficulty and matches each to the least expensive capable model.

Compliance-aware routing answers a different question first: what is this request allowed to touch? Before capability or cost enters the decision, the router evaluates:

• Data classification — is this prompt or its retrieved context public, internal, confidential, or restricted?
• Residency and sovereignty — must this data stay in a specific jurisdiction, data centre, or network segment?
• Model eligibility — which models are approved for this data class and this task type?
• Location of inference — may this run on an external endpoint, a private-cloud model, or only on an air-gapped on-premises node?

Only after those constraints define an allowed set does the router optimise for cost and quality inside it. Cost is optimised within the compliance envelope — never around it. The two goals are compatible; the ordering is what matters.

The classification is the routing key

Everything downstream depends on knowing what class of data a request carries. A practical scheme uses a small number of tiers that map cleanly to policy:

• Public — non-sensitive content, marketing copy, published documentation. Widest model eligibility.
• Internal — ordinary business content with no personal or regulated data. Restricted to approved models, but flexible on location.
• Confidential — personal data, commercially sensitive material, privileged content. On-premises or private-cloud models only.
• Restricted — special-category personal data, regulated records, security-sensitive material. Pinned to a specific node or air-gapped segment, with the tightest model catalogue.

The classification signal can come from several sources, and a robust router combines them: the data source the retrieval step drew from (a restricted repository stamps its results), metadata and labels attached to documents, the calling workflow’s declared risk level, and a fast classifier for free-text prompts that arrive without a label. When signals disagree, the router should take the most restrictive class — fail safe, not fail open.

This is where routing connects to the wider data plane. If prompts, retrieved documents, and embeddings are not classified consistently, the router has nothing reliable to route on. Classification is a platform property, not a router feature bolted on at the end.

Residency and sovereignty as hard constraints

For a multinational or a public-sector body, data classification is only half the decision. The other half is where the computation may happen. A confidential record that must remain within an EU data centre cannot be sent to an inference endpoint in another jurisdiction, however capable or cheap that endpoint is.

Compliance-aware routing treats residency as a hard constraint expressed in policy, not a preference. Each model in the catalogue is tagged with where it runs — which data centre, which jurisdiction, which network zone — and each data class carries the residency rules it must obey. The router’s job is to find the intersection: models that are both eligible for the data class and located where that data is permitted to be processed.

The distinction between residency and sovereignty matters here, and we cover it in depth in Data Sovereignty vs Data Residency in AI Procurement. Residency is about geography — where the bytes are processed and stored. Sovereignty is about control — who can compel access, apply their own law, or change the terms. A router can enforce residency directly by pinning inference to approved locations. It supports sovereignty by ensuring restricted workloads never leave infrastructure the organisation actually controls, such as an on-premises or air-gapped node.

Architecture patterns for private infrastructure

Compliance-aware routing in a data centre or restricted network tends to settle into a few repeatable patterns.

Tiered local model catalogue. The bulk of routing targets are local: a small language model for classification and extraction, a mid-tier model for summarisation and drafting, a larger local model for reasoning. Because they run on-premises, they are eligible for confidential and restricted classes by default. Cost routing operates freely inside this local tier, since the compliance boundary is already satisfied.

Guarded egress for low-risk work. Where policy permits, public and internal requests may route to external or private-cloud endpoints for capability or burst capacity. This egress is a governed exception, not the default path — gated by classification, logged explicitly, and easy to disable per data class or per jurisdiction when policy changes.

Pinned nodes for restricted classes. The most sensitive workloads route to a specific, isolated node — often air-gapped, as described in Air-Gapped AI Deployments for Restricted Networks. The router never even considers other targets for these classes, so a misconfiguration elsewhere cannot leak them.

Policy as data, not code. The approved-model catalogue, the classification-to-model mapping, and the residency rules live in policy that governance owners can review and change without redeploying the router. Hard-coded routing rules age badly and hide the decision logic from the people accountable for it.

The audit trail is part of the routing decision

A routing decision that leaves no record is a governance gap. For every request, a compliance-aware router should be able to answer, after the fact: which data class was assigned and why, which models were eligible, which model was chosen, where the inference ran, and whether any policy constraint blocked a cheaper or more capable option.

That record is what turns routing from an internal optimisation into reviewable evidence. When a compliance officer, auditor, or regulator asks which model produced this output, and was it allowed to see this data, the answer should be a lookup, not an investigation. This connects routing to the broader practice of decision records covered in AI Decision Receipts for Regulated Workflows and to the record-keeping and traceability expectations that regulated AI operators increasingly plan around.

None of this is a legal guarantee. Routing does not make a system compliant on its own. What it does is make model selection an explicit, policy-driven, logged decision — which is exactly the property auditors and oversight functions look for.

Failure modes to design against

Fail-open classification. If an unlabelled request defaults to the widest model set, the router leaks by omission. Default to the most restrictive class and require an explicit signal to relax it.

Cost overriding policy. Any router that lets a cheaper model win against a residency or classification rule is misconfigured. Policy constraints are filters applied before optimisation, never weights traded off against cost.

Silent egress. External calls that are not logged and not attributable per data class are the single most dangerous pattern. Every egress should be visible, classified, and revocable.

Stale catalogues. Models get added, deprecated, and re-certified. A catalogue that is not maintained will route to a model that is no longer approved. Treat it as governed configuration with an owner and a review cadence.

How VDF AI approaches compliance-aware routing

VDF AI Networks treats model routing as a first-class, policy-driven node rather than a hidden default, and the same routing layer is available to individual agents in VDF AI Agents. Routing decisions are governed by an approved-model catalogue, aware of data classification and residency constraints, and logged at the same fidelity as the model output — so which model saw which data class, and where it ran, is always answerable. For teams that want to push efficiency further, VDF Data Suite fine-tunes and evaluates specialist local models that expand what the on-premises tier can safely handle without egress.

The point is simple. In a regulated on-premises deployment, the router is not just choosing the cheapest model. It is enforcing the boundary between what your AI is allowed to do and what it is not. Build it as a governance control, and cost savings follow inside the lines rather than across them.