What it actually takes to put AI inside a government delivery pipeline

Every organisation that has tried to introduce AI into delivery has hit the same wall, and the model is rarely it. The wall is the moment someone with accountability asks a question the pilot cannot answer: what did it read, who approved that, and what happens when it is wrong.

In government that question arrives earlier and harder than anywhere else, because the obligations are statutory rather than reputational. That is useful. It forces you to build the thing you should have built anyway.

The pilot trap

The default pattern is a sandbox. A small team gets an allowance, wires up a chat interface over some documents, demonstrates something impressive, and then discovers that nothing about the sandbox is transferable. The retrieval corpus was assembled by hand. The prompts live in someone’s notes. There is no answer to the question of where the data sits, which is the first question security will ask and the last one the pilot considered.

The pilot is not wasted, because it establishes appetite. Adoption is a different problem. It requires that the second team, and the eighth team, can do the same thing without re-deriving the governance every time. That is an architecture problem, and it is the problem I have spent my time at the Government of Alberta on.

Three assets instead of a platform

The instinct at this point is to build a platform. Resist it. A platform implies a central team that every delivery team must queue behind, and queues are where enthusiasm goes to die.

What worked instead was a small set of named, reusable assets that teams adopt independently:

• a DDD AI Playbook, which describes how AI-assisted delivery fits the governance that already exists rather than proposing a parallel process;
• an AI Toolkit of reusable enablers, so a team’s first week is configuration rather than invention;
• an Architecture Playbook MCP, a Model Context Protocol knowledge service deployed on the Alberta Digital Service Platform, which makes architectural standards available to tooling instead of leaving them in documents nobody opens mid-sprint.

Alongside those sits the Librarian Agent, a retrieval system that gives the architecture practice instant access to policy and standards. It is unglamorous and it is the most useful thing we built, because it removes the most common excuse for non-compliance: I did not know that standard existed.

Governance as an interface

The framing that works is to stop treating governance as a gate at the end and start treating it as an interface teams program against.

A gate is a person who says no late. An interface is a contract published early: these are the hosting patterns available to you, these are the identity and information-protection requirements, this is the review forum and what it will ask, this is the decision record you owe when you diverge. That contract removes the ambiguity that actually slows teams down.

The practical test is simple. If your governance artefacts can only be consumed by a human reading them in a meeting, they are documentation. If they can be consumed by a delivery team’s tooling at the moment of the decision, they are architecture.

What you should expect to be hard

Three things consistently take longer than teams plan for.

Retrieval quality is a content problem. The failure mode is rarely the embedding model. It is that the source corpus contains three versions of the same standard, two of them superseded, none of them dated. Fixing that is editorial work, and it has to happen before anyone blames the retriever.

Auditability has to be designed in. If you cannot reconstruct which sources produced an answer and when, you do not have an assurance story, and you will be asked for one. This is far easier to build at the start than to retrofit.

Sensitivity classification decides your architecture. Where the data sits determines the hosting pattern, and the hosting pattern determines almost everything else. For the highest-sensitivity work that means Protected C hosting on OpenShift and secure integration patterns defined before the first sprint rather than after a security review says no.

The measure that matters

The temptation is to measure AI adoption by usage: how many people opened the tool. That number flatters everyone and predicts nothing.

The measure I care about is whether a team that has never spoken to the architecture practice can start an AI-assisted piece of work, make defensible choices, and produce the evidence a reviewer will ask for, without booking a meeting. When that is true, the governance has been absorbed into the delivery path. When it is not, you have a pilot with better branding.

AI must be auditable before it is impressive. In government, that is the only version of ambition that survives contact with an audit.