How to Build a Model Routing Policy for UK Business AI Workflows

Tools & Technical Tutorials

26 July 2026 | By Ashley Marshall

Most AI workflow failures do not come from choosing the wrong model once. They come from having no policy for choosing models repeatedly.

Start With Workflow Classes, Not Model Names

The first mistake in model routing is to start with a vendor comparison table. That looks practical, but it pushes the business towards a model shopping exercise instead of an operating policy. A UK business should start by classifying the work. Customer support summarisation, invoice coding, internal research, contract clause extraction, marketing copy, personal data triage and regulated advice support are not the same workload. They differ in tolerance for error, sensitivity of data, need for traceability, latency pressure and business value per successful output.

A useful routing policy begins with five workflow classes. Class one is low risk productivity work, such as rewriting internal notes or producing meeting summaries without sensitive personal data. Class two is structured extraction from business records, where accuracy can be tested against fields. Class three is customer facing assistance where tone, completeness and escalation matter. Class four is decision support in areas such as HR, finance, legal, insurance or health related operations, where the AI output may influence a consequential human decision. Class five is restricted work, where the workflow must use approved environments only or stop until a human handles it.

This maps neatly to the UK's context. The ICO's AI guidance makes clear that organisations still need a lawful basis, fairness, transparency and accountability when AI processes personal data. The UK government's AI Champions' AI Adoption Plans, published on 8 June 2026, also frame AI adoption by sector and use case rather than as a generic technology upgrade. That is the same instinct a model routing policy needs: route the work, not the hype.

The practical output is a routing register. For each workflow, record the business owner, data class, permitted model families, maximum cost per transaction, target latency, evaluation set, fallback path and human review condition. This register should sit alongside your wider AI runtime policy enforcement controls, because routing is not a diagram. It is a rule that should execute every time the workflow runs.

Define The Routing Inputs You Can Actually Measure

A routing policy is only useful if the router can evaluate its inputs at runtime. Many organisations write attractive policy statements such as use the best model for sensitive work or use a cheaper model where possible. Those phrases are too vague for an operations desk, a developer or an auditor. The policy needs concrete signals: data sensitivity, task complexity, confidence score, output impact, user role, model availability, cost budget, latency target and evidence requirement.

Data sensitivity should be explicit. A support ticket with a customer name, email address and complaint history is different from a public product description. A contract extract with supplier bank details is different again. Under UK GDPR, the question is not merely whether the data is stored in the UK. It is whether processing is lawful, fair, transparent, minimised, secure and controlled. That is why model routing should connect to data classification rather than vendor geography alone. We covered the wider sovereignty misconception in Data Residency Is Not The Same As AI Sovereignty.

Task complexity also needs a measurable proxy. For example, a router might send short classification tasks to a small model, extraction tasks to a structured output model, and ambiguous multi-document reasoning to a stronger model only when cheaper stages fail. The policy can use document length, number of source records, regulated keyword flags, retrieval confidence and test-set performance as routing inputs. In a claims workflow, that might mean a small model classifies an inbound message, a stronger model drafts the response where the complaint is complex, and a human reviews anything involving vulnerability, compensation or legal language.

Cost and latency should be first class inputs, not afterthoughts. Google's Gemini API pricing lists costs by model and token class, while Anthropic's Claude pricing separates consumer plans and API economics. The important point is not one vendor's price on a given day. It is the spread between fast small models, premium reasoning models and specialist multimodal models. A policy that does not set token budgets and escalation conditions will quietly turn a successful pilot into a monthly cost surprise.

Build A Tiered Model Catalogue With Guardrails

The model catalogue is where routing becomes operational. Keep it simple enough for teams to use, but detailed enough to stop accidental drift. I normally recommend four tiers for UK business workflows. Tier A is cheap and fast models for classification, rewriting, summarisation and lightweight extraction. Tier B is balanced general models for most customer and staff workflows. Tier C is premium reasoning or long-context models for multi-step analysis, complex documents and edge cases. Tier D is restricted or specialist models, including private deployments, UK or EU hosted environments, domain tuned models, embeddings, speech models and vision models.

For each tier, document the approved vendors and exact model identifiers, not just brand names. Examples might include Gemini Flash and Pro families, Claude Sonnet and Opus families, OpenAI GPT models, Mistral models, Azure OpenAI deployments, AWS Bedrock options, or an internal open model for lower risk extraction. The exact list will change, so the policy should separate the tier definition from the live model inventory. The tier says what the model is allowed to do. The inventory says which current model fulfils that tier.

The guardrails matter more than the catalogue. A Tier A model should not receive special category data, confidential board papers or high impact decision support prompts just because it is cheap. A Tier C model should not be used for every request just because it feels safer. Premium models can still hallucinate, leak reasoning into the wrong place, mis-handle prompts, or produce overconfident answers. The NCSC secure AI system development guidelines emphasise secure design, development, deployment and operation. The same life cycle thinking applies here: a model is not approved once. Its permissions, prompts, retrieval sources and monitoring need to remain under change control.

A practical pattern is to create a policy matrix. Rows are workflow classes, columns are model tiers, and each cell says allow, allow with controls, escalate, or block. Add notes for personal data, confidential data, regulated terms, external tool access, customer visibility and human approval. That matrix becomes the business language shared by product owners, legal, security and engineering.

Route For Evidence, Not Just Accuracy

The leading misconception is that routing is about sending easy tasks to cheap models and hard tasks to expensive ones. That is part of it, but it is incomplete. In a UK business environment, routing also has to answer an evidence question: what will we need to prove later? A workflow that drafts a sales email may only need output sampling and brand review. A workflow that helps triage a complaint, score a supplier risk, summarise a disciplinary investigation or recommend a financial action needs stronger evidence that the route was appropriate.

Evidence-aware routing changes the policy. If a workflow involves personal data, the router should log the data class, model tier, prompt version, retrieval sources, user role, output status and whether a human approved the result. If the workflow influences a decision, the policy should capture the human decision point separately from the AI output. If the workflow uses retrieval augmented generation, record which documents were retrieved and whether they came from an approved knowledge base. If the workflow triggers external tools, log the tool call, not just the model response.

This is where ISO/IEC 42001, the international AI management system standard, is useful even when a company is not pursuing certification. It pushes organisations towards management controls, responsibilities, risk treatment, monitoring and continual improvement. The UK's AI assurance work makes a similar practical point: trust needs evidence. Routing gives you a repeatable way to collect that evidence while the workflow runs, rather than reconstructing it after something goes wrong.

There is also a commercial reason. Evidence-aware routing reduces review burden. Low risk outputs can be sampled. Medium risk outputs can require automatic checks against source data. High risk outputs can require human approval before release. Restricted outputs can be blocked. That is much better than asking managers to review everything, which quickly turns AI from leverage into queue management.

Use Evaluation Gates To Prevent Silent Degradation

A routing policy without evaluation is just a preference file. Models change, prompts drift, business language evolves and source systems get messy. Even where a vendor version is stable, your workflow can degrade because staff start using it for adjacent tasks it was never tested on. The policy needs evaluation gates at three levels: before a model is approved, before a route is promoted, and during live operation.

The first gate is an offline evaluation set. For support workflows, build it from resolved tickets. For finance extraction, build it from invoices and manually verified fields. For contract review, use clauses with known answers and accepted risk labels. The evaluation should include ordinary cases, edge cases and deliberately awkward cases. It should measure task success, source faithfulness, refusal behaviour, format validity, privacy handling and escalation accuracy. A model that gets the answer right but fails to flag uncertainty may be dangerous in a customer workflow.

The second gate is route comparison. Test the same workflow through a small model, balanced model and premium model. Look for the point where quality improvement no longer justifies cost or latency. This is where previous work on AI workflow unit economics becomes practical. You are not buying intelligence in the abstract. You are buying acceptable outcomes per transaction. If a Tier A model handles 80 percent of classification cases and routes the remaining 20 percent upward correctly, that may be stronger than putting every request through a premium model.

The third gate is live monitoring. Sample outputs by route, track override rates, watch latency, record token spend and investigate fallback spikes. A sudden increase in premium escalations may mean the input mix has changed, retrieval quality has fallen or a prompt update broke the cheap route. A good policy makes those changes visible before users simply lose trust.

Design Fallbacks, Human Review And Counterarguments Up Front

The counterargument to model routing is understandable: why not just use the strongest model everywhere? For a handful of executive users, that may be acceptable. For a business workflow that runs thousands of times a month, it is usually lazy architecture. It ignores cost, latency, availability, data exposure, assurance and the fact that stronger models are not automatically safer for every task. A premium model may produce more fluent wrong answers. It may also be slower, more expensive and harder to justify for routine work that a smaller model can perform accurately.

That does not mean routing should become a brittle maze. The policy should have clear fallbacks. If the preferred model is unavailable, the router can use an approved equivalent in the same tier. If confidence is low, it can escalate to the next tier. If the prompt contains restricted data, it can switch to a private deployment or stop. If the output fails schema validation, it can retry once with a repair prompt, then escalate. If the workflow hits a high impact condition, it can require human review before any customer or staff action is taken.

Human review should be designed as a specific control, not a comfort phrase. Define who reviews, what they see, what they must check, how long they have, and how their decision is logged. For example, in an HR grievance summarisation workflow, the reviewer should see the source documents, the AI summary, uncertainty markers and any policy citations. In a customer complaint workflow, the reviewer should see the complaint category, suggested response, relevant account history and escalation reason. Without that context, human review becomes rubber stamping.

The final practical step is governance cadence. Review the routing matrix monthly during rollout, then quarterly once stable. Re-test routes when vendors release new model versions, when pricing changes materially, when the workflow expands, or when monitoring shows drift. The policy should be owned jointly by the process owner, security, data protection and the AI delivery team. That shared ownership is what turns model routing from a technical optimisation into a business control.

Frequently Asked Questions

What is a model routing policy?

A model routing policy is a set of rules that decides which AI model or environment should handle a task. It uses signals such as data sensitivity, task complexity, cost, latency, confidence and required human review.

Why do UK businesses need model routing?

UK businesses need routing because AI workflows often process personal data, confidential records and customer facing outputs. A policy helps control cost, data protection risk, audit evidence and model quality across repeated workflow runs.

Is model routing only about reducing AI costs?

No. Cost is important, but routing is also about data minimisation, latency, assurance, fallback, resilience, user permissions and human review. Cheap models are useful only when they are allowed and tested for the task.

Should we use the most powerful model for every workflow?

Usually not. Premium models may be justified for complex reasoning or high value work, but using them everywhere can increase cost, slow workflows and weaken evidence discipline. Many structured tasks perform well on smaller models with proper escalation.

How does UK GDPR affect model routing?

If the workflow processes personal data, the route should reflect lawful basis, fairness, transparency, minimisation, security and accountability. The policy should stop or redirect prompts that contain data a given model or vendor is not approved to process.

What should be logged when a router chooses a model?

At minimum, log the workflow, data class, selected model tier, model identifier, prompt version, retrieval sources, user role, confidence score, fallback reason, output status and human approval where applicable.

How often should a model routing policy be reviewed?

Review it monthly during rollout and quarterly once stable. Also review it whenever a vendor changes model versions or pricing, when prompts are changed, when source systems change, or when monitoring shows a quality or cost drift.

Can model routing work with multiple vendors?

Yes. In fact, routing is often most useful in multi-vendor environments using providers such as Google, Anthropic, OpenAI, Mistral, Azure OpenAI or AWS Bedrock. The policy should define approved equivalent models and fallback routes.