Most AI governance programmes I have seen start by creating a forum. It meets fortnightly, produces minutes, approves use cases. Six months later there is a repository of decisions and no control running.
Why the committee alone fails
It is not a competence problem. It is a speed mismatch. The committee decides every two weeks; the agent acts in milliseconds, thousands of times a day. Any control whose enforcement depends on a human in the path will be bypassed by volume, not by bad faith.
Add to that the fact that use-case approval governs what was declared. Shadow AI — the MCP server started on a laptop, the integration someone plugged in — passes through no committee, and that is where most of the risk lives.
Governance that exists only in meetings governs slides. It does not govern what is running.
Translating policy into control
For each line of policy, ask which mechanism makes it true with nobody present:
- “Agents must have their own identity” → a pipeline check that blocks deploys using a shared service account.
- “Credentials must not be static” → a scanner that fails the build on finding a key in an environment variable.
- “Irreversible actions require a human” → a gateway rule, not a sentence in the prompt.
- “Every tool call must be audited” → missing logs become a health alert, not a checklist item.
- “Third-party servers need approval” → an allowlist enforced at runtime, and anything absent does not connect.
Anything with no translation into a mechanism should either leave the policy or be explicitly accepted as risk, with an owner and a date.
What is left for the committee
What remains is what only humans do: setting the limits, arbitrating exceptions and accepting residual risk with a name and a signature. That is valuable, and it fits in a short monthly meeting — provided day-to-day enforcement lives in code.
