Governance as Code — Policy That Executes, Not Just Advises

Posts 1–3 established ownership, model risk, and agentic controls — all of which need enforcement. This post is about how enforcement scales: by encoding policy as executable rules rather than relying on manual review and human memory. The motivation is simple and hard-won: manual governance doesn’t scale to the speed and volume of modern AI deployment, and anything that depends on people remembering to check will eventually be skipped.

Why written policy isn’t enough

A traditional governance policy lives in a document and is enforced by humans reading it, remembering it, and choosing to comply — which fails predictably at scale: - It’s not consistently applied. Different reviewers interpret it differently, and under deadline pressure checks get waived “just this once.” - It doesn’t scale. Manually reviewing every model, prompt change, and deployment against a policy is impossible once an organization runs dozens or hundreds of AI systems (post 1’s registry usually reveals there are far more than anyone thought). - It’s invisible and unauditable. You can’t easily prove a document-based policy was followed for a given deployment — the evidence is scattered or absent (post 5’s problem). - It drifts from reality. The document says one thing; what systems actually do is another, and nobody notices the gap until an incident.

The core problem is that written policy is advisory — it describes what should happen and depends on humans to make it happen. Governance as code makes policy imperative: the rule executes, and non-compliance is blocked or flagged automatically, the same way a failing test blocks a merge.

What governance as code means

Governance as code (a specialization of policy as code, itself descended from infrastructure as code) means expressing governance rules as machine-executable, version-controlled definitions that run automatically in your pipelines and systems. The pattern mirrors how modern infrastructure is already managed:

• Policies are written as code/config, not prose — a rule like “every model in production must have an approved model card and a passing bias evaluation” becomes an executable check, not a line in a handbook.
• They live in version control, so policy changes are reviewed, diffed, history-tracked, and rolled back like any code — governance itself becomes auditable and deliberate (the same discipline the LLMOps series applies to prompts).
• They run automatically at the points where they matter — in CI/CD when a model is deployed, at runtime when an agent requests an action, at registration when a new system is added — so compliance is checked by the machine, every time, not by a human sometimes.
• They fail closed where it counts — a policy violation blocks the deployment or the action (for high-risk controls) or raises a tracked exception, rather than being silently ignored.

A common enabling tool is a general policy engine (the open-source Open Policy Agent is the widely-used example) that evaluates declarative policies against inputs — “is this deployment allowed given these facts?” — and returns allow/deny. The same engine that gates Kubernetes deployments can gate AI deployments against AI-specific rules. The point isn’t a specific tool; it’s that policy becomes a queryable, executable service rather than a document.

What you can encode — and what you can’t

Governance as code shines for the mechanical, checkable parts of governance, and it’s important to be clear about the boundary:

Encodable as automated checks: - Deployment gates — block a model reaching production unless it has: an owner and registry entry (post 1), an approved risk tier, a model card, passing evaluation and bias thresholds (post 5), and required approvals for its tier. - Runtime policy — for agents, evaluate each requested action against allow/deny rules before execution (post 3’s action guardrails); enforce data-access and tool-permission scopes as policy. - Configuration and standards — enforce that logging/tracing is enabled, PII handling is configured, approved models/regions are used, and required guardrails are present. - Regulatory controls that map to checks — e.g. “high-risk systems (post 6) must have human-oversight configured and documentation complete” becomes a gate.

Not fully encodable — still needs human judgment: - Whether a use case is ethical or appropriate, whether a fairness trade-off is acceptable, whether an evaluation is meaningful for the context. Governance as code enforces that the check was done and passed a threshold; it can’t replace the human decision about whether the threshold and the use case are right.

The mature pattern is therefore hybrid: automate the mechanical, consistent, high-volume checks so humans aren’t the bottleneck and nothing slips, and reserve human review for the genuinely judgmental, high-stakes decisions — with the automated layer feeding the human one (flagging what needs a person). This is how governance keeps up with AI’s velocity without becoming either a rubber stamp or a roadblock.

The throughline: a policy in a PDF is advisory and fails at scale — inconsistent, unscalable, unauditable, drifting from reality — whereas governance as code makes policy imperative: rules expressed as version-controlled, executable definitions that run automatically at deployment, at runtime, and at registration, and fail closed on the controls that matter (often via a policy engine like OPA that answers allow/deny). Encode the mechanical and checkable — deployment gates (registry entry, risk tier, model card, passing bias/eval, approvals), runtime action and access policy, configuration standards, and regulatory controls that map to checks — while keeping human judgment for the ethical and high-stakes calls the code can’t make, in a hybrid model where automation handles volume and flags what needs a person. Governance becomes something the system does, continuously and provably, not something a document asks for.

Key takeaways

• Written policy is advisory and fails at AI scale: inconsistently applied (interpretation + deadline waivers), unscalable to dozens/hundreds of systems, hard to prove was followed, and prone to drift from what systems actually do.
• Governance as code (policy-as-code, descended from infrastructure-as-code) makes policy imperative: rules as executable, version-controlled definitions that run automatically in pipelines/systems and fail closed on high-risk controls — non-compliance is blocked like a failing test, not left to human memory.
• A general policy engine (e.g. Open Policy Agent) evaluates declarative policies against inputs and returns allow/deny — the same mechanism that gates infrastructure, pointed at AI-specific rules; policy becomes a queryable executable service, not a document.
• Encode the mechanical/checkable: deployment gates (owner+registry, risk tier, model card, passing eval/bias thresholds, tier-appropriate approvals — posts 1,2,5), runtime action/access policy for agents (post 3), configuration standards (logging, PII, approved models), and regulatory controls that map to checks (post 6).
• Keep humans for judgment (is the use case ethical? is the fairness trade-off acceptable? is the eval meaningful?) — code enforces that a check passed a threshold, not that the threshold/use case are right — in a hybrid model where automation handles volume and flags what needs a person, keeping pace with AI velocity without becoming a rubber stamp or a roadblock.

Further reading

• Infrastructure as code — the executable-definition pattern governance borrows
• Regulation of artificial intelligence — the obligations being encoded