Keelson · Blog
Mid-Market AI Governance Framework · Keelson
01 · Policy
What the Monday-morning policy actually says.
Governance begins with a single sheet the named operator can print, sign, and file in the runbook binder on a Monday morning. The sheet names the workflows AI is allowed to touch, names the workflows it is not, names the operator who owns the policy, and names the threshold at which an exception crosses the line from “flagged” into “escalated.” The policy is short because everything long is a wishlist no operator reads. The sheet is the only governance artifact the audit signs against.
The policy names each workflow by the word the operator uses on the floor: claims triage, contract drafting, settlement matching, exceptions cleared per shift, defects per thousand shipped units. Each row on the policy pairs the workflow with the metric, the named escalation threshold, and the operator who signs off when the exception queue crosses the line. Anything not on the sheet is, by definition, not approved — not because the work is forbidden, but because an unapproved workflow has no runbook to read when the system breaks.
The “not allowed” sheet is the half the policy exists to write down. No customer-record data leaves the named environment without a written sign-off. No model retraining runs that the operator cannot read the eval set for. No new tool lands in the environment without the scorecard from section three. No exception crosses the threshold without a human picking up the phone. The lines are conservative on purpose: the cost of moving them under pressure is larger than the cost of holding them for a week.
02 · Accountability
Who owns what, on a sheet every operator can read.
A governance policy with no names attached is a strategy deck that will not survive a real exception fire. The accountability sheet names four humans and nothing else: a named AI operator, the CFO who reads the locked metric, the governance committee that meets on a fixed cadence, and the named escalation contact whose phone number sits on the cover page of the runbook. Four names, four phone numbers, four pages. That is the full organizational chart of governance at a mid-market operator.
The named AI operator is the single person whose name sits on the cover page of the runbook. They open the Monday dashboard, walk the exceptions queue, and sign off on the weekly retraining note. They are the same person who reviews the override log every month. They are not a committee; they are a single employee whose email the vendor, the CFO, and the escalation contact all have on file.
The CFO is not asked to govern AI. The CFO is asked one thing, on a fixed cadence: read the metric the audit locked, in writing, without opening the build. The metric is claims cycle time, contracts drafted per week, hours reclaimed per close, exceptions cleared per shift, defects per thousand shipped units. The CFO’s only governance role is to verify, on a Monday morning, that the metric the invoice was priced against is still the metric the invoice is measured against.
The governance committee is four named humans meeting on a fixed monthly cadence: the named operator, the CFO or a designated finance deputy, a legal reviewer, and a workflow owner from the team the AI ships into. The committee reads the override log, reviews the drift map, and signs off on every new tool landing in the environment. The committee does not run the build; it reads the artifacts the build produced and decides whether the policy still matches the workflow.
The named escalation contact is the single phone number the runbook prints in bold on the cover page. When the exceptions queue crosses the threshold the policy set, this contact answers the phone inside one business hour. The contact is not a shared inbox and not a ticketing queue; it is one named human whose role is to pick up. Mid-market governance fails most often because the escalation route is a phone tree. The named contact is the fix.
03 · Tool vetting
The five-row scorecard before a tool lands in the environment.
A new AI tool lands in the operator’s environment by a vendor pitch, a Friday afternoon demo, or a Slack message that says “try this.” None of those are a governance process. The tool-vetting scorecard is five rows, signed by the governance committee before any tool reads a single record. Five rows, two sign-offs, no exceptions. The full method for what to look for when a tool is being evaluated sits on the build method page; the scorecard is what the operator applies before a tool ships.
Does the tool read the operator’s own data in the operator’s own environment, or does it pull data into a third-party system the operator cannot audit? A tool that ships against a screenshot or a CSV import fails the scorecard on row one. Governance cannot sign off on a system the operator cannot see running.
Is the vendor a named person or a shared inbox? A scoring rubric the operator cannot read in five minutes fails the scorecard on row two. Governance requires the same single-name rule the runbook applies: the same person who sold the tool is the person on the escalation email when the first exception fires.
Can the vendor name the single metric the tool will move if it ships? A tool that promises four KPIs, three dashboards, and a quarterly executive readout fails the scorecard on row three. Governance locks on one number the CFO can already verify before and after; a tool that does not pick a single number has no way to be evaluated.
What happens the week after the vendor walks off the engagement? A tool with no post-handoff plan — no runbook, no retraining cadence, no named escalation after the contract ends — fails the scorecard on row four. Governance signs off on tools the operator team can keep running on a Monday morning three months later.
Can the operator reproduce every decision the tool made in the last week? A tool that does not expose its inference log, its retraining history, and its override ledger fails the scorecard on row five. Governance cannot govern a system whose decisions cannot be replayed on a Monday morning when the CFO asks what happened.
04 · Compliance checkpoints
The calendar the operator can read off a wall planner.
Governance without a cadence is a draft policy nobody reads. The compliance calendar pairs three checkpoints with three dates a calendar can print: a monthly override-log review, a quarterly drift-map refresh, and an annual policy rewrite. Each checkpoint ties to a named human, a named artifact, and a sign-off the committee file in the runbook. The cadence is short on purpose: the longer the gap between checkpoints, the further the policy drifts from the workflow.
On the first Monday of every month, the named operator opens the override log alongside the exceptions queue and lists every recurring override the team has written in the last four weeks. The committee reads the list at the next meeting; the next retraining cycle is built off it. The review is short, it is signed, and it files into the runbook binder.
Every ninety days, the governance committee refreshes the drift map: which upstream feeds changed shape, which downstream metrics moved when the upstream moved, which failure modes the inference path hardened against, and which failure modes are still open. The refreshed map is what the named operator carries into the next target-selection meeting.
Every quarter, the committee runs the tool-vetting scorecard against every AI tool currently in the environment. Tools that fail any row are scheduled for removal; tools that no longer serve an active workflow are decommissioned on a fixed date. The roster shrinks on a calendar, not on a panic.
Once a year, on the anniversary of the first sign-off, the committee rewrites the policy sheet from scratch. Workflows the team no longer run are removed; workflows the team now runs are added; thresholds are reset against the locked metric; and the escalation contact is re-read aloud. The rewrite is a Monday morning meeting that produces a fresh one-page policy the operator signs by lunch.
05 · ROI review cadence
What gets measured, who reads the number, and how often.
Governance without an ROI cadence is a compliance program that nobody can tie to the locked metric. The ROI cadence pairs three artifacts with three readers and three cadences: a monthly exception-queue note the named operator reads, a quarterly board-memo the CFO reads, and an annual ROI review that runs against the lock doc the audit signed on day fourteen. The cadence fits on one page because every reader reads one artifact.
The named operator writes a one-page note on the exceptions queue: how many cases the system resolved, how many it escalated, and what shape the overrode cases carried this month. The note feeds the next retraining cycle and the next monthly override-log review. It is short enough to read in ten minutes and long enough to be the document the committee quotes at the next meeting.
The CFO receives one memo per quarter with the locked metric, the trend over the last twelve weeks, and the one sentence on whether the engagement is repeated or wound down. The memo is the only document the CFO signs; it is not the place to load in dashboards. Three numbers and a sentence is the entire memo.
Once a year, the committee opens the original lock doc the audit signed, reads the metric the invoice was priced against, and reads the metric the operator is shipping today. The review decides whether the engagement is renewed, whether the metric moves up the stack, or whether the program is wound down. The review is short because the lock doc was short, and the lock doc was the entire audit.
Governance at a mid-market operator is not a committee, a strategy memo, or an annual conference talk. Governance is a one-page policy, four named humans, a five-row scorecard, three checkpoints per year, and one metric the CFO can read on a Monday morning. That is the entire framework, and the one-page policy fits on the cover of the runbook and survives a Monday morning three months from now.
Continue reading
Related posts
More working notes for operators building AI systems that hold up after handoff.
Governance / AI Ops
A practical operating checklist for mid-market teams: inventory every AI workflow, assign owners, set risk tiers and approval gates, control data and vendors, define human review and exception escalation, log what matters, and review the system monthly and quarterly before drift becomes an incident.
AI Ops / Strategy
How mid-market teams scale AI workflows after the first build: strengthen governance, change operator behavior, assign durable ownership, write runbooks and escalation paths, and expand a portfolio without losing metric discipline.
How mid-market operators choose one workflow, establish a baseline they can defend, measure implementation ROI, set pilot exit gates, and hand a production system to the person who will run it on Monday morning.
The practical AI ops digest
Working notes on outcome-locked pricing, the 90-day build, and what AI Ops actually does after handoff. No marketing — just the operator notes we send to the people who already read this blog.
Bring us the workflow
Stand up the framework on your own dashboard.
The self-serve audit walks the eight questions an operator can answer in twenty minutes and ends in the same one-page policy the named operator hands you on the paid engagement — workflow by name, metric the CFO can verify, named escalation on cover. Or talk to a build operator directly if you already know which workflow needs the framework.
Replies within one business day.