2026-09-02
These are the transferable design patterns that emerged from designing an AI governance operating model for a department in 2026. They're written to apply anywhere — a private-sector governance function, a startup working out its AI policy, an internal team standing up responsible AI review, or anyone trying to bring order to the way AI enters an organization.
The specific engagement produced a 156-page operating model with ten linked papers and eleven appendices — described separately at AI Governance Operating Model — A Reference Model for a Public Agency. This page extracts what carries forward: the patterns, the moves, the design principles. No client, department, or person is named — I've deliberately omitted references to any specific individual or group.
One structural fact matters throughout: in this department, the office in charge of AI governance is not in charge of app development. Neither approval, nor funding, nor building — those live in other groups. Some organizations combine these responsibilities; this one keeps them separate. That separation shapes almost everything the office can and cannot do — and, more importantly, what it has to design around rather than command.
For the parallel piece on the methodology used to actually write the operating model — coauthoring at scale with AI — see Patterns for Coauthoring with AI.
Each pattern below is followed by a brief note on where else it transfers.
Classify an AI capability by what it does, not the category it's filed under. Labels don't match how tools actually work or how tools evolve. Categories like "chatbot" or "analytics" or "a Canva feature" arrive out-of-date and get more out-of-date every quarter.
But behavior alone isn't enough. A single application can enable many workflows, and different workflows can carry very different risk. Combining two photos taken seconds apart to improve lighting is a different workflow from combining two photos taken days apart to change the story. Removing a distracting background person is a different workflow from removing a public figure from a scene. Same tool, same capability, meaningfully different behaviors.
The move is deceptively simple but requires discipline. When someone says "we need to approve the tool," push back with "which specific behavior, in which workflow, for what use?" That one reframe kills a lot of otherwise-endless categorization arguments.
Transfers to: any fast-moving technology governance problem where the taxonomy is always behind the tools.
Rate risk on independent dimensions and never sum them. The version I used was three: harm (damage if it's wrong), control-gap (chance an error goes uncaught), and dependency (how much of the tool sits outside your control). A single blended score hides the shape.
Consider two tools. One is catastrophic when it fails but always caught before harm reaches anyone. The other is trivially wrong in ways that silently corrupt downstream decisions. Averaged into a score, they might look similar. In the actual dimensions, they need completely different responses. A blended score erases exactly the information you need to act on.
The principle isn't specific to three dimensions. It's about keeping the axes independent and readable, rather than compressing them into a number that looks decisive but hides the shape it's summarizing. It's not a new idea — NIST's AI Risk Management Framework takes a similar posture. What's specific to this framework is the choice to keep the dimensions independent through characterization, review, and reporting.
Transfers to: vendor risk, security risk, any triage where a heat-map number is doing damage by oversimplifying.
A governance function should own its lens and attach it to the processes other people already run, rather than claiming new authority (and possibly starting turf wars in the process). This scales — because you're not asking to be a new gate, you're adding a reading to existing gates.
The corollary: don't rebuild what's already working. If a process is doing its job and the institution is participating, add the missing parts rather than replacing the whole thing. Sometimes this isn't possible — the existing process is broken, captured, ignored, or hostile — but when it is possible, attaching can save an enormous amount of effort.
Where you attach matters. Attaching to a gate that everyone respects gives you real reach. Attaching to a gate that everyone ignores — or adding a new gate that ends up ignored — gives you the same problem the ignored gate has. Choose the attachment point carefully, and pay attention to whether the gate you attached to is still working.
Transfers to: any staff or oversight function (security, privacy, legal, risk) standing up inside an organization that already has owners for everything.
The durable output of a governance effort isn't the policy paper. It's the reusable mechanism people fill out. Most people will never read the policy paper — and that's fine. The paper explains how things operate and the reasoning behind them. That's the reference for people who need to change the role of the department or the processes it runs — they need to understand why the system was designed the way it was before they change it. Everyone else just needs the instrument.
On this engagement, the instrument was a single intake filing that right-sizes from a few-minute self-clearance up to a full review, and is designed to interoperate with the existing mandatory state form rather than duplicate it — it includes the other form by reference and adds only the questions that form omits.
There's a further advantage to instruments: they're things people interact with. When you change an instrument, everyone who fills it out sees the change. A paper filed on a website tells nobody anything; an updated field on an intake form tells everyone who fills out the form. This makes instruments a working communication channel with the people doing the work, not just an artifact of the work.
The test of a governance design is whether it leaves behind a thing people do or create — not a thing they cite. Papers get filed away and quoted. Instruments get filled out and used. If your governance design doesn't produce an instrument that outlasts the person who wrote it, you have written a paper, not a system.
Transfers to: any process design where the win is the artifact that outlives the author — intake forms, decision templates, checklists, playbooks.
The pattern isn't "don't build taxonomies." A working taxonomy can be genuinely better than no taxonomy — you have to name things to reason about them. The pattern is: build the taxonomy to help you notice what's arriving, and treat it as always-incomplete. McKinsey's classical framing of MECE — mutually exclusive, collectively exhaustive — works well for classifying data. It works poorly for classifying ideas or capabilities, which often span categories or belong to categories that don't yet exist.
Map the distinct ways the thing you govern enters the organization — but don't turn those entry paths into permanent categories. The paths help you notice what's arriving; they don't need to define how it's handled after arrival.
In this engagement, four doors mattered: funded projects, procurements, in-estate (AI arriving inside tools already owned), and citizen-built. Each door has its own detection challenge and its own conversation with existing process owners. But everything lands in one governance record. The entry path is a field on the record, not a folder.
A discovery backstop catches whatever slipped every screen — and importantly, is treated as a success when it fires, not a failure. If discovery never finds anything, either the front-door screens are perfect (unlikely) or discovery is broken. A discovery hit is a system working.
Transfers to: intake design for anything that arrives through multiple channels and must not fall through the cracks.
In a thicket of rules, a few changes unlock everything and the rest is noise. The skill is identifying the two or three moves that matter and drafting them as tight, grantable asks that extend an existing pattern rather than invent a new one.
Here, two precise asks to the central IT authority were the difference between a framework that works at scale and one that collapses under its own paperwork:
Both asks are subset moves — they extend or narrow an existing state pattern rather than propose something new. Both are grantable in a single conversation. Both unlock work that would otherwise stall indefinitely.
There's a Pareto pattern underneath this: ask for everything and it's easy to ignore; ask for one or two targeted things and each ask has a real chance of being considered on its merits. The reformer's temptation is to bring the full list. The reformer's discipline is to identify the two moves that unlock the rest, and let the rest go.
The pattern is: don't try to change the whole regulatory picture. Find the two moves that unlock everything else, and draft them so tightly that the answer is either yes or a specific, narrow follow-up question.
Transfers to: any regulatory or policy reform where leverage is unevenly distributed.
A single commercial platform can do a dozen things — design, generate images, edit, publish, summarize. Approving or denying "the tool" is the wrong unit. Instead, endorse named capabilities for a described use, within stated limits, with conditions attached (no confidential input; human review of every output; public output through the normal channel).
One characterization done at the capability-plus-use-case level can then satisfy several separate compliance instruments at once — because you've specified what's being done, not just what's being used.
There's another reason this matters. Commercial platforms change names and licensed features constantly. "Approve Adobe Creative Cloud" today isn't a coherent statement six months from now, when the branding has shifted, the tier boundaries have moved, and features you didn't know existed have been added or moved between tiers. Capability-and-use-case approval survives those changes because you approved what people do, not what a vendor happens to be calling it this quarter.
This is also the escape from the false binary that "shadow IT" and blanket bans both feed on. If the only options are "approve the whole tool for everything" or "block the whole tool for anything," you lose either way — either through over-approval that creates real risk, or through blanket bans that push work underground.
Transfers to: SaaS and tool approval generally, and to any "shadow IT" problem where blanket yes/no both fail.
A governance function's real value is partly un-countable (harms prevented never show up) and partly perverse to measure (rewarding "no" or friction measures the opposite of the goal).
Start with the invisible-prevention problem. We didn't accidentally leak private citizen data and get ransomed for a billion dollars. Good outcome. Very hard to estimate the probability that would have happened if we hadn't done X. The value of prevention is precisely the harm that never showed up — which means the number is unobservable, and any measurement is a hypothetical. This isn't a reason to abandon measurement. It's a reason to be honest about what any given metric can and can't tell you.
Second, consider denial rate. What percentage of AI app submissions should the office deny? High denial rate as a success metric implies denying is good. Low denial rate as a success metric implies allowing is good. Neither is right. What we want is to deny what's dangerous and allow what's not — which is the same shape as hiring. A company that hires everyone it interviews and a company that hires nobody are both broken. The right rate depends on the underlying quality distribution of what's coming in, and on whether we're calibrated correctly against that distribution. Denial rate as a metric is only interesting against a baseline of what should have been denied or allowed, which is exactly the hard thing to measure.
Third, Goodhart's law: when a measure becomes a target, it stops being a good measure. Applied here: the moment you make "incidents surfaced" a target the team is graded on, teams start under-surfacing or over-surfacing depending on which way the incentive tilts.
None of this argues against measurement itself. The strongest counter is: you have to report to boards, budgets, and voters, and "we don't measure our impact" is not a defensible position. Sophisticated metrics people know Goodhart and argue for leading indicators (process signals rather than outcomes), portfolio measurement (multiple dimensions read together — this framework's three-dimensional risk read is exactly that pattern), and direct outcome studies where feasible. What this framework tries to add is a specific caution: for governance functions whose value is largely un-observable, the metrics that look most decisive often obscure the most. Choose measurements that keep the shape visible.
One exception to the general skepticism about metrics: the office has customers — the people and groups it works with. Their feedback, ideas, and suggestions are absolutely worth collecting and considering. A Net Promoter Score for the governance function, or something like it, is a legitimate signal to track. It measures something honest — whether the people you serve find you useful — which most other governance metrics don't.
The doctrine that emerged from this work:
Grounded in NIST's AI Risk Management Framework, safety-engineering near-miss practice, and Goodhart's law.
Transfers to: measuring any preventive or enabling function — security, safety, compliance, internal platforms, developer tooling.
On content authenticity — AI-transparency laws, content-credential standards, watermarking — these tools can attest to the legitimacy of a specific piece of media. They cannot prove what the content is or isn't. The difference matters.
A determined bad actor strips provenance metadata, forges it, or works around it entirely. Consider a straightforward example: I generate a fake image with AI. I print it. I take a photograph of the print with a phone. The photograph is a 100% legitimately-captured image (with valid provenance metadata) of a fake. Every technical mechanism said the right things. The content is fake anyway.
And absence proves nothing: plenty of legitimate content has no credential attached, either because the creator didn't add one, or because the platform stripped it in transit, or because the format doesn't support it.
Three consequences follow:
I wrote about this because in the wake of California's SB 942 (as amended by AB 853), many readers took the law to mean AI-generated content could be traced back to its source. It cannot — not reliably, not against determined actors, not without provenance the creator chose to attach.
Transfers to: any disclosure or authenticity regime — deepfakes, synthetic media, supply-chain attestation, source verification.
The nine patterns cluster into three broader moves.
Govern by behavior (#1), doors are sensors (#5), and capability-and-use-case approval (#7) all refuse the seduction of clean categories. Your categories will always lag; design for that.
Attach don't mandate (#3), build instruments (#4), and find the load-bearing policy change (#6) are all about doing the most work with the least authority. When you don't have the power to command, you design your way in.
Risk is a shape (#2), measure the governed work (#8), and provenance authenticates the honest (#9) are all about resisting false clarity. The summary metric, the confident authentication, the composite score — each looks decisive and each obscures more than it reveals.
For the operating model these patterns emerged from, see the companion summary and table of contents. The full (modestly redacted) document is available on request.
For the methodology used to actually write it — coauthoring at scale with AI, and what that requires — see Patterns for Coauthoring with AI.
Contact: jeremy@bloomfamily.com