Most enterprise automation programmes hit a wall around bot 25. The early bots shipped fast — small teams, motivated owners, light review. As the programme scales, somebody (usually risk, usually rightly) asks who's checking that these bots are safe, and the answer is nobody. The over-correction is a 12-week intake committee that strangles the next 25 bots.
Four governance rules that earn their keep
- Every bot has a named business owner accountable for its behaviour. Not the developer — the operator.
- Every bot has a documented system of record, control point, and exception path. If you can't write those down, you can't ship.
- Every bot writes to a shared audit log with operator identity. Anonymous bots do not exist in production.
- Every bot has a kill switch reachable from a single config change. Tested at deploy time, tested at every quarterly review.
Automate the rules, not the review
The reason intake committees calcify is that they're checking the same four things by hand for every release. The fix is to automate those four checks at deployment time. A pre-deploy CI step that fails if any of the four rules isn't met turns governance from a meeting into a green check on a pull request.
When to call in human review
Three triggers reliably justify a human review: it touches money above $X, it touches customer-facing communication, or it changes a control flagged by audit. Everything else can ship on the automated checks. The committee meets quarterly to review trends, not weekly to approve deployments.
What the CoE actually does
A working CoE owns four things: the platform (orchestrator, evals, observability), the catalogue (which bots exist, who owns them), the standards (the four rules, the deploy CI), and the delivery method (how teams scope, build, and ship). It does not own bots themselves — those live with the business owner. This split keeps the CoE small, opinionated, and fast.
Governance is what stops you from shipping the wrong thing fast. It is not what stops you from shipping.