Governance isn't what slows automation down. It's what gets it approved.

Most AI deployments fail the same way. Not technically — the demo works, the model calls the right API, the output looks right. They fail in the security review, three weeks later, when someone in compliance or IT asks a question nobody thought to answer in advance: what happens when this is wrong?

At that point, the project usually stalls. Not because the automation doesn't work, but because there's no answer to that question — no approval path, no record of who signed off on what the agent is allowed to touch, no way to say with confidence what happens if it makes a bad call at 2am with nobody watching.

Governance is a design decision, not a policy document

The instinct with most automation projects is to build the workflow first and worry about approval later — get something working, then figure out the guardrails once it's proven useful. That ordering is exactly backwards for anything with write access to a real system.

Governance, done properly, isn't a PDF that sits in a shared drive. It's a set of rules the automation itself is built against: which actions an agent can take unsupervised, which ones always need a human to click approve, and what the threshold is for the difference. Get that right before the first workflow goes live, and the automation earns trust as the audit trail proves it deserves more scope. Get it wrong — or skip it — and every review from then on starts from a position of "convince me this is safe" instead of "here's the record."

What this looks like in practice

In our own deployments, this shows up as a straightforward gate: guardrails independently re-check every action a model wants to take, rather than trusting the model's own opinion of whether something needs sign-off. Under a defined threshold, with the checks that matter for that business passing, an action can go straight through. Above it — or anything the checks flag — it waits for a person. That split isn't a limitation bolted on afterward. It's the first thing we design, before the workflow that automates the actual task.

The result is automation that survives a security review instead of triggering one. Not because it does less, but because every action it takes can be traced back to a policy and a reason, on request, without someone reconstructing what happened after the fact.

The question to ask before you automate anything

If you're evaluating an AI agent for a workflow that touches money, customer data, or anything else with real consequences, the governance question comes first: who decides what this thing can do without asking, and what's the record when it does something outside that? If nobody can answer that in a sentence, the automation isn't ready yet — regardless of how well the demo went.

Written by Andrew Dainty, founder of Blackwall Labs.