The Anatomy of AI Deployment

Why the model is the smallest part of a public-sector AI deployment, and what to get right instead.

Most government AI initiatives open with the same question: which model should we use? It is the wrong place to start. Models are swapped every few months, so that choice is easy to reverse. The decision that sets an agency's course for years is how much of the system to build, buy, or blend.

Our new paper, The Anatomy of an AI Deployment: From Data to Delivery, sets out the framework Scale uses with government partners. It draws on dozens of production deployments across sectors and countries. Here are the ideas that matter most.

The model is not the product

Ask a frontier model to classify a permit application against national regulation, or draft a cabinet briefing in a ministry's format. It will answer fluently, with no basis for trusting the result.

Closing the gap between a plausible answer and a usable one is what a deployment exists to do. Nearly all the engineering sits in that gap, and none of it shows up in a model comparison. So two questions come before the model question: does this workflow warrant a tailored system at all, and if so, what gets built around the model?

Build, buy, or blend

This picks up where Scale’s Sovereign AI framework stops: once a use case has cleared the national-level question of whether it needs sovereign control, how much of the system should the agency build, buy, or blend? Build versus buy is a false choice. Nearly everything governments run in production is a combination. The real question is how much of the system an agency must control.

Off-the-shelf wins on generic tasks and non-sensitive data, and it wins fast. Translation, internal drafting, and Q&A on public documents are good fits. Tailoring earns its cost when a use case crosses a threshold a bought product cannot meet: sovereign data, a specialised workflow, decisions that must be audited, or a high cost of error. Most government workflows cross at least one.

Five questions place almost any use case, usually in a single workshop:

1. Is the data sensitive or sovereign?
2. Is the workflow generic or specialised?
3. Do the decisions need to be auditable?
4. What is the cost of being wrong?
5. Will the use case still matter in 18 months? If yes, owning pays off. If not, rent.

The licence fee is rarely the largest line on the bill

Most procurement decisions go wrong by comparing only the visible cost. Over the life of a tailored system, licence or API fees are usually the smallest line. Integration with identity, legacy databases, and network rules is typically the largest and most underestimated. Change management, inference at scale, ongoing model upgrades, and the cost of switching later all add up.

Adoption deserves special attention. An unused system costs 100% and returns zero. It needs its own budget line, an accountable owner, and a measure of real use rather than licences issued.

Value should be measured in four layers: adoption first, then impact against a pre-deployment baseline, then outcomes for citizens, then return over the system's full life.

Eight assets, one of them licensed

Every tailored deployment is built from the same eight assets. Only one, the model weights, is licensed from a foundation model lab. The other seven are engineered for the use case and, on the right terms, owned or controlled by the agency:

• Data model: the agency's own structured knowledge of its domain. The most durable asset; it outlives every model.
• Prompts: the instructions and context sent on each call. Structured iteration typically takes an early prompt from around 70% on an evaluation set to the high 80s or low 90s, with the same model.
• Context engineering: retrieval and memory that decide what the model sees, so answers come from current, authoritative text and can cite sources.
• Agent scaffolding: planning, routing, retries, and validation. Without it, a model can answer but not act.
• Tools: the functions a model calls to work in real systems.
• Inference parameters: the dials that trade cost, speed, and consistency.
• Evaluation harness: the test set and rubrics that score every change.

The custom harness is the default

There are three ways to make a model work. Out-of-the-box engineers none of the eight assets and suits generic chatbots. Fine-tuning engineers all eight, including the weights, at the highest cost. The custom harness engineers seven of eight around a strong model with no retraining, and it is the right default for most specialised workflows.

Fine-tuning is justified in two cases: when the most sensitive workloads must run on-premise on smaller models, or when no frontier model can reach the task through engineering alone. Two agencies can call the same frontier model and get very different outcomes. The reason is rarely the model.

Evaluation is the anchor

Delivery runs through six phases: define the use case, build the evaluation set, baseline and iterate, a decision point, harden and deploy, then maintain. Skipping evaluation-set construction is the most common cause of failed deployments.

A useful harness has three properties:

• Coverage: typical, difficult, and unusual cases, not just the easy ones.
• Rubrics: explicit criteria such as accuracy, format, completeness, and tone, agreed with the agency before tuning.
• Speed: a full run in under ten minutes, so it runs on every change.

The harness is also a governance artefact. Every change is scored against the same set, and a regulator can re-run it independently. Public benchmarks help shortlist a model; only the harness shows whether the system does the job.

Responsible AI is built in, not bolted on

Controls live inside the eight assets. People make the final call on permits, approvals, and entitlements. Evaluation sets cover every operating language, and a system measurably worse in one language fails, whatever its average. Red-team attacks that succeed become permanent test cases.

Data stays under agency control. Reference and operational data never enter the model. Training data is needed only for fine-tuning, and when the harness hits its target, no training data is used at all.

Design for change

Capability trickles down fast. A task that needs the most expensive model this year will run on a cheaper one next year. Because the data model, evaluation harness, and retrieval pipelines carry over unchanged, a model swap takes days, not a rebuild.

The principle: lock in to use cases, not vendors. Every component should be portable across models and usable without the team that built it, including the delivery partner. Review the model, hosting, and cost once a year against what the market now offers.

Six recommendations

The model is the smallest part of the work. The decision to build, buy, or blend is the largest.

For the decision, before any code is written:

1. Start with the outcome, not the technology. Define the problem, the users, and measurable success first.
2. Expect a blend. Off-the-shelf for generic tasks and non-sensitive data; tailored for specialised workflows and sovereign data.
3. Build what you need to control; buy the rest. Control can come from the contract as well as from building.

For the method, once the decision is made:

1. Define success as a measurable score on an agreed evaluation set, not a feature list.
2. Make the evaluation set the first deliverable, not the last.
3. Prefer the custom harness. Fine-tune only when the evaluation evidence demands it.

The frontier will keep moving. Built this way, a deployment gains from each new model instead of being made obsolete by it.

Read the full paper: The Anatomy of an AI Deployment: From Data to Delivery covers the full framework, cost categories, delivery lifecycle, and responsible-AI controls in detail.

Read the full White-paper here