Project · Governance & rollout plan

1 · The scenario

Start where every new head of AI actually starts: not with a blank page, but with a mess someone else made. Teams have already shipped things. Nobody wrote down what. A customer is now asking a question you can't yet answer, and the clock started before you did. If you've ever joined a company and discovered the "system" was three people's habits and a Slack channel, you know this feeling — and you know the instinct to panic and build a giant policy binder is exactly wrong.

Think of it like being handed a house that's already half-built by different crews with no blueprint. You don't bulldoze it and you don't add a second storey — you first walk every room and write down what's there, then decide which walls are load-bearing. Governance works the same way: you inventory before you rule, and you rule before you scale. The scenario below is deliberately ordinary — a mid-size B2B company, three half-shipped AI features, one nervous enterprise customer — because that ordinariness is the point. This is the median situation, not the dramatic one, and the median is what you'll actually be hired into.

Why does the order matter so much? Because governance you impose before you know what exists is theatre — you'll write rules for imaginary systems and miss the real one that's already talking to customers. And the common mistake here is treating "describe your AI governance" as a documentation task. It isn't. It's a signal that a buyer is deciding whether you're a safe vendor, and your honest answer is worth more than a polished lie you can't back up. Read the scenario as a founder would: what's the smallest set of true things I can stand up in 90 days that makes this company safer and faster?

Representative scenario. "Meridian" is a ~600-person B2B software company. Teams have started shipping AI features ad hoc: a support-drafting agent, a doc-search assistant, and a prototype that drafts customer-facing content. There is no inventory, no review process, and no one accountable. A large EU customer just asked, in a security questionnaire, "describe your AI governance." You've been hired as the first head of AI engineering. Deliver the foundation in 90 days.

2 · Deliverable A — the governance charter

You've seen the failure mode even if you've never called it governance. A team writes a 40-page "AI policy," circulates it once, and six months later nobody can find it, three new systems shipped without touching it, and the doc contradicts the runbook someone actually follows. The policy wasn't wrong — it was overloaded. It tried to be a constitution and an instruction manual at once, so it aged like milk and got ignored like fine print.

A charter is the constitution, and the analogy is exact: a national constitution says "there shall be a supreme court" — it does not list next Tuesday's docket. It states durable principles (what is in scope, how we tier risk, who is accountable) and delegates the changeable mechanics to laws and procedures beneath it. Your charter should read the same way: short enough to actually read, stable enough that you're not rewriting it every sprint, and authoritative enough that every other artifact — the register, the gate, the rollout — points back to it as the source of truth.

The precise point: the six sections below aren't a checklist for its own sake — each one answers a question a real reviewer, auditor, or nervous customer will ask. What do you even govern? (scope). How do you decide how hard to govern it? (risk tiering). What does a system have to have before it ships? (mandatory artifacts, as deploy blockers — not aspirations). Who is on the hook when it breaks? (roles). Why keep it stable rather than comprehensive? Because a charter you rewrite monthly has no authority — people learn to wait it out. The common mistake is stuffing tool choices and exact eval thresholds into the charter; those belong in linked procedures, which you'll change often precisely so the charter doesn't have to.

The charter is the constitution: short, durable, and the thing everything else references. It reuses EL1's policy shape. Minimum sections:

3 · Deliverable B — the risk register

Here's the moment the register would have saved you. Something goes wrong in production — a wrong answer reaches a customer, or a doc-search result leaks across tenants — and in the postmortem someone asks "did we know this could happen?" If the answer is "no," you have a competence problem. If the answer is "yes, but nobody owned it," you have a governance problem, and it's worse. The risk register exists to make the second answer impossible: every foreseeable failure is written down, ranked, and has exactly one name next to it.

Think of it as a pre-flight checklist crossed with a bet. Pilots don't file a checklist because they expect the engine to fail; they file it because knowing which failures are plausible, how bad each is, and who handles it turns a crisis into a procedure. A risk register does the same for an AI portfolio — and the "bet" part is the two numbers on every row: likelihood × impact. That product is what ranks the list, and the top of the list is where your scarce control effort goes. A rare-but-catastrophic cross-tenant leak and a common-but-mild hallucination are genuinely different problems, and pretending they're the same is how teams either over-invest in the trivial or sleepwalk into the disaster.

The point most people miss: a risk register is not a static compliance artifact you write once — it's the source that feeds your board risk framing (each row collapses to a three-sentence "what could go wrong / how likely and how bad / who owns it and how it's mitigated") and it changes as systems change. The common mistake is a register full of risks with no owner. A risk everyone is responsible for is a risk no one is — the single accountable owner per row is the load-bearing column, not the mitigation text.

Inventory each in-flight AI system, then log its risks in the EL6 format. A starter register for Meridian's three systems:

4 · Deliverable C — the rollout plan

You've probably watched a launch that was really just an announcement. "It's live for everyone as of Monday" — and then week two is a support fire, half the org quietly stops using it, and the retro concludes "the tool wasn't ready." Usually the tool was fine; the rollout was a cliff, not a ramp. There were no checkpoints where you could look at real evidence and decide whether to widen the door or hold it shut.

A good rollout looks less like flipping a switch and more like a clinical trial: a small phase to prove it's safe and wanted, a larger phase to prove it holds under load, and only then general availability — and crucially, each phase-to-phase move is a decision gated on evidence, not a date on a calendar. The graduation gate is the whole idea: "we scale when the pilot squad hits the acceptance target and wants to keep it," not "we scale on the 15th because the plan said so." That single reframe — dates are guesses, gates are facts — is what separates a governed rollout from optimistic scheduling.

Two things make or break it, and both are about honesty. First, pick adoption metrics that measure value, not vanity: "% of eligible drafts done via the agent" and "time saved per ticket" tell you something; "total logins" tells you nothing and is easy to game. Second, match the human-in-the-loop policy to the risk of each action — a draft internal note can be autonomous, but sending to a customer needs a human hand on it. The common mistake is scaling on enthusiasm: a loud pilot squad loves it, so you go company-wide before you've proven the support load is survivable or the trust hasn't been quietly broken. Enthusiasm is a signal to test the next gate, not to skip it.

For the system worth scaling first (the internal, grounded support agent), lay out the pilot → scale path from EL4 with graduation gates, a rollout RACI, adoption metrics, and the HITL policy. The flow below is the whole governed lifecycle, from a system entering governance to being monitored in production.

5 · Deliverable D — the eval + monitoring gate

Ask a hard question of any governance program: what does it physically stop? If the answer is "it produces a document," it's not governance — it's paperwork. A charter that classifies risk and a register that names owners are worthless if a failing system can still deploy and stay deployed. The gate is where the abstract becomes enforceable: it's the one place in the whole program where a machine, on evidence, says no.

The mental model is a security checkpoint at an airport, and it has two halves people often forget are separate. There's the gate at the door — you don't board unless you clear it (the CI deploy gate: quality evals pass, cost-per-success within budget, and for high-risk systems, faithfulness and an isolation canary). And there's ongoing surveillance after you're through — because a passenger who was fine at security can still cause trouble mid-flight (runtime monitoring for drift, error/refusal spikes, cost anomalies, with rollback triggers). A deploy gate with no monitoring lets systems rot in production; monitoring with no deploy gate lets rotten systems in to begin with. You need both, and they check different things at different times.

The deepest point is that the gate should get stronger over time, and this is where governance either compounds or decays. When an incident happens, the amateur move is to patch the bug and move on; the professional move is to turn that failure into a permanent check — a new eval case, a new monitor, a new rail in the deploy gate — so that exact class of failure can never silently return. Do this and your gate ratchets: every scar becomes armor. The common mistake is uniform strictness — running expensive faithfulness and isolation checks on every system, including the low-risk internal one. That doesn't make you safer; it makes teams route around the gate. Match the check to the tier, and reserve the heavy machinery for the systems that can actually hurt someone.

Governance is only real if something can fail. Define the gate that governs deployment and continued operation, drawing eval discipline from the safety/case-study tracks and cost/adoption from EL3/EL4:

6 · Self-assessment rubric

The trap at the end of a big deliverable is relief. You produced a charter, a register, a rollout plan, and a gate — four real artifacts — so it's tempting to call it done. But "I made the thing" and "the thing is good" are different claims, and the gap between them is exactly where a governance program that looks complete quietly fails to protect anyone. The rubric exists to close that gap by making you grade yourself honestly, against a bar, before someone else does it for you in a boardroom or a security review.

Think of it the way a pilot treats a checkbook of standards rather than a feeling of "that landing seemed fine." Two levels — meets bar and above bar — force a specific judgment on each dimension: not "did I write a risk register?" but "does every risk have a single owner and a real mitigation, and did I identify and hardest-govern the top one?" The above-bar column is deliberately concrete because vague self-grading always inflates; "it's pretty good" is how weak work survives.

The point worth internalizing: not all dimensions are equal, and the rubric tells you which failures are fatal. If your risk register or your eval + monitoring gate is below the bar, systems can ship or drift with no owner and no way to fail — fix those before anything cosmetic. And the difference between a binder no one reads and governance leadership actually trusts lives almost entirely in the last two rows, communication and honesty: a program that's technically sound but can't be explained to a skeptical CFO, or that overclaims maturity it doesn't have, will lose the room even when the engineering is right. The common mistake is grading the artifacts you enjoyed making generously and skimming the ones you found tedious — which are usually the ownership and honesty rows that decide whether the whole thing holds.

Grade your full deliverable. This is the whole track, integrated — score each dimension honestly at meets-bar or above-bar.