AI Deployment Governance: Authorisation, Sandboxing and Rollback

In Age of Ultron, two engineers build and activate a system overnight in a private lab. Nobody accountable signs it off. It runs with unbounded reach from the first second. Once activated, there is no way to switch it off or undo what it has already done. The story that follows is fiction. The deployment failure that starts it happens in real organisations every week.

AI deployment governance is the set of controls that decide when an AI system is allowed to act on real data, real records and real people. It covers who authorises activation, how the system’s actions are bounded while its behaviour is still unknown and how the decision is reversed if it goes wrong.

Nobody in that lab is reckless. They are capable people working on something they understand better than anyone else in the building, and they skip the process because the process would have cost them a night they did not have to spare. That is shadow AI with the stakes raised.

Three controls would have contained the outcome:

• Authorisation by a named person before activation.
• A bounded environment in which to observe the system’s behaviour.
• A tested way to reverse the decision and its effects.

None of them are exotic, and none of them work if the authorised route is slower than building in private.

Authorisation: a named person signs off before activation

An AI authorisation process requires a named, accountable person to approve a system before it can act on anything real. It forces a decision point between “this works” and “this is live”.

The record does not need to be long. It should state:

• What the system is permitted to do.
• Which data it may read and which it may write.
• Who owns it once it runs.
• What conditions would trigger shutting it down.

Four answers, held by someone whose name is on them.

Where this fails is not the requirement, it is the queue. An architecture board that meets monthly cannot approve an internal tool that took an afternoon to build. Engineers will conclude, correctly, that asking means waiting five weeks, and they will ship it anyway.

Sandboxing: bound the actions until the behaviour is understood

Sandboxing means running a new system where its actions are constrained and observable before it touches production. In practice that means:

• Read-only access to copies of real data.
• No write permissions.
• No outbound integrations.
• No ability to trigger a downstream process affecting a customer, a patient or a colleague.

The purpose is observation. Agentic systems behave differently once they can chain actions together, and the useful failures appear in the gap between what the system was asked to do and the route it chose. You cannot review that in advance; you can only watch it. The same separation of data, tooling and authority is the subject of test environment separation, and the two controls fail together when either is skipped.

Sandboxing also needs exit criteria set before the system goes in. Decide what you expect to see, how long you will observe it and what would stop promotion. Otherwise the sandbox becomes a formality that everything passes.

Rollback: if you cannot switch it off, you have not finished deploying it

An AI rollback plan covers two problems. The first is stopping the system, which needs a kill switch that works without the cooperation of the person who built it. Build it into the deployment rather than the runbook, and confirm it does not depend on credentials only one team holds.

The second problem is undoing what the system did, and it is the one teams forget. A system that has written records, sent emails, raised tickets, updated a CRM or communicated a decision to someone outside the organisation has left effects that stopping it does not reverse. Some of those effects are recoverable from logs and backups. Some are not recoverable at all, which is itself worth knowing before activation rather than after.

So the plan has to name the effects. For each thing the system is permitted to write, send or trigger, someone should be able to explain how that action would be found and undone, and who would do it at two in the morning. Where an effect cannot be reversed, that is an argument for keeping the system inside the sandbox longer or narrowing what it is allowed to touch.

Then test it. An untested rollback plan is a document, and documents do not switch anything off.

Governance slower than the workaround will be worked around

This decides whether the other three controls exist in practice or only in policy. If the authorised route takes five weeks and building privately takes an afternoon, capable people will build privately, and you will discover the result during a shadow AI discovery exercise months later.

The fix is tiering rather than tightening:

• A self-service path, measured in days, for bounded internal use where a system reads non-sensitive data and cannot act on anything.
• Full review for anything that touches personal data, influences decisions about people or holds authority to act on the organisation’s behalf.

Publish both routes, commit to a turnaround time and measure how long approvals actually take. If your median approval time is longer than your median build time, your governance is manufacturing the problem it exists to prevent.

What clients ask us about AI deployment controls

Who should own AI deployment sign-off in a mid-sized organisation?

A single named individual with technical judgement and organisational authority, usually the CTO, IT Director or head of engineering. Committees dilute accountability and add delay. The owner can delegate low-risk approvals to engineering leads, provided the delegation is written down and the owner still answers for the outcome.

What slows an authorisation process down in practice?

Rarely the decision itself. Delay comes from unclear submission requirements, approvals routed through meetings that happen monthly and requests bouncing between security, legal and data protection with no agreed sequence. Fixing the queue matters more than fixing the form, and a low-risk internal tool rarely needs more than a few days.

What should we do about AI systems already running without approval?

Inventory before enforcement. Find what exists, assess what each system can access and act on, then retrofit controls in risk order. Removing a tool that people depend on without offering an authorised alternative drives the behaviour further out of sight.

Does this apply to third-party AI tools as well as systems we build?

Yes, and the questions barely change. What can it read, what can it write, who authorised it and how would you stop it and reverse its effects. With a supplier product you control less of the internals, which makes the authorisation record and the rollback plan more important.

Where to start

The underlying problem is ordinary: deployment decisions made by the people best placed to make them and least able to be objective about them. Authorisation, sandboxing and rollback keep that judgement inside a boundary.

Our AI Security Programmes build those controls into how your teams already deliver, at a pace engineers will actually use. If you are not sure what is already running, that is where we begin.