AI Governance & Risk: Building AI the Right Way

A model goes to production in March. In September a customer sends a questionnaire asking which data the system was trained on, who approved its deployment, and how outputs are reviewed before they reach a person.

Nobody kept the training data lineage. The approval happened in a Slack thread. There is no review step, because the output goes straight into the workflow — that was the point of building it.

Answering that questionnaire honestly now costs a quarter of engineering time. Answering it dishonestly costs considerably more later. Neither is a technical problem, and neither would have existed if three decisions had been made before the model shipped.

This is the most expensive pattern I see, and it comes from a category error: treating an AI product as a model. It is not. It is a decision system — a model plus the data feeding it, the people acting on its output, and the process that decides when it is wrong. The model is the part everyone governs. The rest is where the exposure lives.

Why retrofitting costs more than it looks

Every governance question has a point in the lifecycle where it is cheap to answer and a point where it is not. The gap between them is larger for AI than for most systems, because the answer often depends on decisions that are no longer recoverable.

• Data lineage. Cheap at selection: record the source, the licence, and the basis for processing. Expensive afterwards: reconstructing what was in a training set eighteen months later, when the pipeline has been rebuilt twice, is sometimes impossible.
• Human oversight. Cheap at design: build the review step into the workflow. Expensive afterwards: inserting a human checkpoint into a process the business has already optimized around removing one. That is a change management fight, not a control.
• Access control. Cheap at build: scope who can query the model and who can see the output. Expensive afterwards: nobody wants to take access away from people who have had it for a year.
• Approval record. Cheap at the decision: one paragraph naming who authorized deployment and on what basis. Expensive afterwards: there is no way to manufacture a contemporaneous record, and everyone can tell.

That last one is the reason “we’ll document it later” fails as a strategy. Most governance artifacts can be produced late. A record of a decision cannot — its whole value is that it was made at the time.

What governance by design actually means

The phrase gets used loosely enough to mean nothing. Concretely, it means five decisions are made at defined points, and each one produces an artifact.

Before data selection

What data will this system process, where did it come from, and on what basis are we permitted to use it for this purpose? Artifact: a data source record, written before the pipeline is built.

The question that catches people is “for this purpose.” Data lawfully collected for one purpose is not automatically available for training. That determination belongs at selection, not at audit.

Before architecture is fixed

Where does a human sit in this workflow, and what can they actually do? Artifact: a named role, a defined intervention point, and a record that intervention was possible.

“A person reviews the output” is not oversight if that person sees four hundred outputs an hour and has no authority to reject one. Meaningful oversight requires time, information, and the ability to override. Design it in, or accept that you do not have it.

Before deployment

Who authorizes this going live, against what criteria? Artifact: a dated approval naming a person, not a committee.

If three functions are jointly responsible, nobody signs, and the record you need in eighteen months does not exist.

At vendor selection

What is this vendor’s governance, and what happens to our obligations if they change the model underneath us? Artifact: contract terms covering model change notification, data use, and audit rights.

Most AI in your organization was built by someone else. Their governance becomes your exposure, and a silent model update can change your system’s behaviour without a single line of your code changing.

Continuously, after launch

Is it still doing what we approved? Artifact: a monitoring output with somewhere to go and someone who reads it.

Systems drift. Inputs shift. A decision made once is not a control.

This is not a new programme

The most useful thing I can tell a security or compliance team starting this work: you already own most of the machinery.

You have vendor management, change control, access management, risk assessment, and records retention. You run them for other asset classes already. AI governance is largely a set of amendments to processes that exist — an AI flag on the vendor register, three questions added to procurement intake, a model-change trigger in change control — rather than a parallel structure with its own headcount.

Teams that grasp this move considerably faster, because they stop trying to build something and start extending something. Teams that do not spend a quarter selecting a framework before finding out what they actually run.

What good looks like

You should be able to answer these from documents, not memory, in under five minutes:

• Which AI systems influence a decision about a person, and who owns each one?
• For the three with the greatest decision impact: what data do they process, and on what basis?
• Who approved each deployment, when, and against what criteria?
• If a vendor changed its model tomorrow, how would we find out?

That last question is the one almost nobody can answer, and it is the one that turns a governed system into an ungoverned one without anybody noticing.

Five failure patterns worth avoiding

• Governing the model and not the decision system. The model is rarely where the exposure sits. The data going in and the action taken on the output are.
• Treating oversight as a checkbox. A reviewer with no time and no authority to override is not oversight. It is a person absorbing liability.
• Prohibiting rather than permitting. A policy banning AI use produces shadow adoption on personal devices, where you have no visibility at all. Permit specific tools under stated conditions.
• Governing only what you built. The larger exposure is almost always purchased — AI features shipped into tools you already use, often with no procurement decision at all.
• Waiting for a deadline. Governance exists because someone will eventually ask you to justify a decision — a regulator, a customer, a court, an insurer. That question does not wait for a compliance date.

Where to start

If a system is already in production, you cannot rewind. What you can do is stop the gap widening.

Write down what you know now — the data sources you can still identify, who is currently accountable, what the output feeds into. An incomplete record created today is worth more than a complete one you never get to. Then put the five decisions above in front of the next system, before it ships.

Structure is not overhead. It is the difference between answering a questionnaire in an afternoon and losing a quarter to one.

---

Get the template

Our AI Governance Starter Kit ships with the data source record, the oversight design worksheet, the deployment approval form, and the vendor change-notification clauses — tailored to your sector and size.

Browse governance documents →

Already in production and not sure where you stand? Book a free 30-minute call. No slides — you leave with the two or three things worth doing first, whether or not you hire us.

References

– NIST AI Risk Management Framework 1.0 — Govern, Map, Measure, Manage
– ISO/IEC 42001:2023 — AI management system requirements
– Regulation (EU) 2024/1689 (EU AI Act) — Article 9 risk management, Article 14 human oversight

Advisory content, not legal advice.

---