Design-Time vs Runtime Governance: The Distinction Every AI Leader Should Understand

Most organisations can describe their AI governance process in confident detail. Ask about the approval stage and you will hear about risk classification, bias testing, documentation, sign-off from legal and compliance. Ask a different question, whether anyone could say what a given AI system actually did last Tuesday, and the confidence tends to disappear.

That gap has a name. It is the difference between design-time governance and runtime governance, and it is one of the more consequential distinctions in this entire field, precisely because so few leadership teams have been asked to think about it directly.

Here is the uncomfortable version of the point. An organisation can have more governance activity than it has ever had, more committees, more policies, more approval workflows, and still have less actual control over what its AI systems are doing, because nearly all of that activity is concentrated at a single moment: the point of approval. Everything that happens afterward is where the real risk lives.

What design-time governance covers

Design-time governance is everything that happens before a system goes live. Risk classification. Bias and fairness testing against a known dataset. Review of the vendor's data handling terms. Documentation of intended use. Sign-off from the people whose job it is to catch a problem before it becomes the company's problem.

Done properly, this work matters enormously. It is also, by its nature, a snapshot. It answers the question "is this safe, based on what we know right now," at a single point in time, using the data and the test cases available at that point in time. It cannot answer a question about something that has not happened yet.

Why design-time governance cannot see what happens next

This is not a criticism of design-time governance. It is a description of what it was built to do, and what it was never going to be able to do regardless of how carefully it is carried out.

A model reviewed and approved against a representative dataset will, eventually, meet a real input nobody tested for. An AI agent granted a specific technical permission will, at some point, use that permission in a way that is entirely within its rules and entirely outside what anyone intended. A system's behaviour drifts gradually as the real-world data feeding it shifts, with no code change and no new deployment to trigger a fresh review. This is a close cousin of a different problem worth naming on its own, AI activity that spreads inside an organisation without ever going through approval in the first place, which opens the same blind spot from the opposite direction. None of this shows up in an approval process, either because it did not exist yet at the time of approval, or because it never went through that process at all.

The risk does not materialise in the design review. It materialises later, in production, in the specific moment an employee pastes something they should not into a prompt, or an agent takes an action a human would have stopped had anyone been watching. Design-time governance was already finished by the time any of that happens.

What runtime governance is

Runtime governance is the layer that watches what a system does while it is doing it, rather than what it was expected to do before it started. It is not a second, later approval. It is a continuous function: monitoring live behaviour, enforcing policy at the moment an action would occur, and keeping a record of what happened rather than what was predicted to happen.

The distinction that matters most here is enforcement versus documentation. A policy that says a system must never expose certain customer data is a design-time artefact if it exists only as a paragraph in a governance document. It becomes a runtime control the moment it is checked, automatically, every time that data could be exposed, not reviewed after the fact in a quarterly audit.

The two are not competing. They are sequential

It would be a mistake to read any of this as an argument that design-time governance does not matter, or that runtime governance should replace it. Catching a problem before a system goes live is more efficient and more durable than catching it afterward, and that will remain true regardless of how good runtime monitoring becomes. The organisations that get this right are not choosing between the two. They are treating design-time governance as the first stage of a process, and runtime governance as the stage that has to exist because no design-time process, however rigorous, can account for everything a system will eventually encounter in the real world. In practice, this is why a growing number of organisations are moving away from stitching together a separate design-time review tool and a separate runtime monitoring tool, and instead adopting a single platform built to cover both stages from the outset, since the two were always meant to work as one continuous process, not two disconnected ones.

The organisations that get this wrong tend to do so quietly. Nothing about a design-time-only programme looks broken from the inside. Every system was reviewed. Every approval was properly documented. The gap only becomes visible when something happens that the design-time process was never positioned to catch, and by then the question is no longer whether the gap existed, but how long it had been open.

A short test for where your own organisation sits

Two questions tend to surface this quickly, and the contrast in how easily they get answered is usually the whole point.

How confident is your organisation in its AI approval process? Most leadership teams answer this one without much hesitation. There is a process, people follow it, and it produces documentation everyone can point to.

Could your organisation say, right now, what any given AI system in production did yesterday, in detail? This is the question that tends to produce a longer pause. Not because nobody cares about the answer, but because most governance work was never built to produce one.

Neither answer is a verdict on how seriously an organisation takes AI risk. It is a fairly reliable indicator of which stage its governance programme was designed for, and which stage still needs building.

Common questions

Is runtime governance just monitoring? Monitoring is part of it, but the more important piece is enforcement. Monitoring tells you what happened. Runtime governance is built to act at the moment something is about to happen, blocking or flagging it in real time, not simply logging it for a later review.

Do small or mid-market organisations need runtime governance, or is this only relevant at large enterprise scale? The need scales with how autonomous and how numerous the AI systems in use are, not with headcount. A mid-market firm running a handful of AI-powered customer-facing tools has the same fundamental gap between approval and live behaviour as a much larger one, simply with fewer systems to account for.

Where should an organisation start if it only has design-time governance today? Usually with visibility. Before building enforcement, it helps to know what AI systems are running, what they are doing, and where the current approval process stops seeing them. Enforcement without visibility tends to be built in the wrong places.

If your organisation could describe its approval process in detail but would struggle to say what any given AI system did yesterday, that gap is common, and it is the specific thing worth addressing next, not a sign of a governance programme that has failed.

This is the exact distinction Aligne's platform, Altrum, was built around: covering design-time review and runtime enforcement in one place, rather than treating them as two separate problems that happen to need two separate tools. If it is useful, you can see how that works here.

‍