Governance as Code or Not at All

Why more governance boards won't save you from autonomous agents.

Governance documents, review boards, approval processes. Three instruments that have worked for decades. And three instruments that fail the moment an autonomous AI agent makes a decision in milliseconds.

The question is no longer whether you need governance. The question is whether your governance is fast enough to still matter.

Most of CIOs worldwide plan to deploy AI agents in production. The uncomfortable reality: most haven’t translated their governance rules into a format an autonomous agent can understand and follow. They’re planning autonomous systems while steering them with handbooks and quarterly reports.

What happens when governance can’t keep up

An autonomous agent processing data, issuing recommendations, or initiating transactions needs clear boundaries. Not as a PDF in a SharePoint folder. Not as a slide in a steering committee presentation. As version-controlled code that physically prevents an action outside the permitted scope.

I’ve spent years in a large, heavily regulated organization watching what happens when those boundaries don’t exist in machine-readable form. Review boards that meet four times a year routinely delay decisions by six months or longer. A deferral here, a supplementary review there, a referral to another committee the quarter after. While the board deliberates, the technology moves on. The organization stops steering. It reacts. At best. At worst, it doesn’t notice that autonomous systems are already making decisions no committee has ever seen.

Policy-as-Code reverses this logic. Instead of discussing rules in meetings and approving them by resolution, they get deployed as machine-readable logic. Like software: with tests, with versioning, with automatic enforcement in real time.

Concretely: a rule like “no personal data transferred to external interfaces without clearance” stops being a paragraph in a governance document. It becomes a constraint embedded in the agent’s code. The agent cannot cross that boundary because the code physically prevents it. Not because it read the policy. Because the policy is part of its architecture.

The demographic dimension most organizations ignore

In many organizations I’ve worked with, the most important business rules don’t exist in documents. They live in people’s heads. Passed along in hallway conversations, refined in informal discussions, explained over coffee. The colleague who has known for thirty years which data categories must never go to external systems has never written it down. She didn’t need to. She was always there.

In five years, she’ll be retired. None of that knowledge is machine-readable. None of it survives the generational transition unless someone captures it in a form an autonomous system can interpret. This isn’t an abstract risk. It’s a concrete knowledge loss already priced into the age structures of many organizations.

Three things you can do this week

Start with three rules, not thirty. Identify the three governance rules whose violation would cause the most damage. Access rights to critical data, budget limits for autonomous procurements, classification rules for sensitive information. Code them as machine-readable constraints. Three working rules matter more than three hundred documented ones.

Create the role of the governance engineer. Someone who writes governance rules as code, reviews them, deploys them into the agent environment. The experienced staff bring domain knowledge. The younger colleagues bring the technical implementation. Neither replaces the other.

Make the governance auditable. Every change to a governance rule gets versioned. Who changed what, when, and why? In regulated environments, this traceability isn’t a nice-to-have. It’s an obligation that coded rules make easier to fulfill than any document-based governance ever could.

The biggest hurdle isn’t the technology. It’s the culture. Most governance teams see themselves as gatekeepers. Policy-as-Code demands the opposite: not “no,” but “yes, within these boundaries.” From preventer to enabler. That sounds like a nuance. In practice, it’s a paradigm shift that touches the self-image of entire departments.

I’ve caught myself underestimating that shift. The hard part isn’t writing the code. It never was.

If this resonates -- or if you’d push back on any of it -- I’d genuinely like to hear it. Hit reply.