Nishant Tamilselvan

Updated 5 min read

What it takes to put AI inside a government delivery pipeline

Most AI pilots in the public sector fail at the governance seam. The work is in making governance something a delivery team can program against.

  • AI delivery
  • Governance

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. Nobody can say where the data sits. Security asks that question first, and the pilot considered it last.

The pilot still has value, 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 reusable assets that teams adopt independently:

  • an AI delivery 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 knowledge service built on the Model Context Protocol and 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 a retrieval assistant 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 slows teams down.

Governance as a gate compared with governance as an interface Two rows. In the gate row, the team builds, a review happens at the end, and the answer is rework or no. In the interface row, a contract is published first, the team's tooling reads it at the moment of each decision, and the evidence is ready when review arrives. Gate Team builds Review at the end Rework, or no Interface Contract published Tooling reads it Evidence ready The contract: hosting patterns, identity and information-protection requirements, the review forum and its questions, and the decision record owed on divergence.
A gate says no late. An interface publishes the rules early enough to follow.

The Enterprise AI Framework, which I maintain in the open, sets out this kind of contract for any organization.

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 takes longer than planned

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.