2026-09-02
This is a summary of a governance operating model I designed and authored for a state agency in 2026 — a body of work that runs about 150 pages (with some rendering options increasing or reducing this by 15%) across ten linked papers and eleven supporting appendices. The full (modestly redacted) document is available on request. This page summarizes each piece — what it does, what it decides, and where it fits — so a reader can see the shape of the work without needing the full text.
One structural fact matters throughout: at the time of writing, the office had one full-time employee — the Chief Data and AI Officer — governing the department's AI adoption at scale of 23,000 employees. Additional headcount was planned but not yet in place. That gap between one FTE and 23,000 employees shapes almost every design choice below.
For the design patterns underlying this work — the core principles and patterns I developed as I built this — see Patterns for Governing Enterprise AI Adoption.
The engagement started with an open question: what should a newly-formed executive AI office at a public agency actually do, and how should it operate? The model below is the answer I worked out — deliberately expansive in scope (govern all AI, not GenAI alone), deliberately restrained in posture (attach the office's characterization to whoever already holds authority, rather than claim new approval power over anyone else's process).
There were reasonable questions during the engagement about how large the office should ultimately grow. My position was that defining what the office does — and doesn't do — has to come first. Only then can you sensibly estimate the headcount needed to actually do it. This body of work is the answer to the first question; the staffing question waits on it.
Word counts are rounded; page counts are approximate (~500 words per page, single-spaced).
| Piece | Words | ~Pages |
|---|---|---|
| Paper 1 — Foundations & Operating Model | 7,100 | 14 |
| Paper 2 — Characterization & Risk | 6,600 | 13 |
| Paper 3 — State AI Terrain | 9,200 | 18 |
| Paper 4 — Citizen AI | 13,500 | 27 |
| Paper 5 — Engagements | 2,900 | 6 |
| Paper 6 — In-Estate AI | 1,500 | 3 |
| Paper 7 — Other Venues (stub) | 860 | 2 |
| Paper 8 — Enablement (stub) | 380 | 1 |
| Paper 9 — Metrics (stub) | 310 | 1 |
| Paper 10 — GenAI and Media Editing | 2,400 | 5 |
| Appendix A — Category Clearance Request | 700 | 1 |
| Appendix B — Use Carve-out Request | 870 | 2 |
| Appendix C — AI Intake Template | 1,300 | 3 |
| Appendix D — Intake Worked Example | 1,400 | 3 |
| Appendix E — AI Content Provenance & Disclosure | 5,300 | 11 |
| Appendix F — State Process Reference | 6,300 | 13 |
| Appendix G — Governance Reference Diagram | 150 | 1 |
| Appendix H — Sources & Materials | 590 | 1 |
| Appendix I — How AI Contributed | 260 | 1 |
| Appendix J — Series Glossary | 1,800 | 4 |
| Total | ~63,400 | ~130 |
~7,100 words · ~14 pages
Establishes why the office exists, where its authority comes from, and the top-level model. The authority is grounded in a founding memo from the parent agency and a signed duty statement, which together define a broad data-and-AI role whose AI mandate covers all AI, not GenAI alone. This was a point of real early confusion — state legislation and governor directives at the time were largely focused on "GenAI" without defining it, which left it unclear whether an ML-based fraud detector, an analytics-tool suggestion feature, and a chat interface all fell under the same rules. Taking the whole-family posture cut through that ambiguity.
The framework recognizes four ingress paths — the doors through which AI enters the department: funded projects, procurements, in-estate (AI showing up in tools the department already owns), and citizen-built. It is held together by seven principles:
These principles didn't arrive at once. They accreted — and some had to change as the framework met the terrain. A principle that looked right in September needed refinement by November when a specific class of case broke it. The set stabilized only after enough cases had been worked through that the exceptions stopped surfacing.
~6,600 words · ~13 pages
The characterization and risk-assessment process the office applies to every AI item, however it arrived: built, bought, borrowed, copied, turned on, or delivered. It reads a capability on three independent dimensions rather than reducing them to a single number: harm (how bad if the tool is wrong, and who is exposed), control-gap (how likely an error is to go uncaught), and dependency (how much of the tool is out of the department's hands — lock-in, model provenance, long-term accountability).
The three-dimensional read is not unprecedented — NIST's AI Risk Management Framework takes a similar posture — but keeping the dimensions independent, rather than blending them into a composite score, is a specific choice. It lets a reviewer tell a "catastrophic but always caught" tool from a "trivial but silently wrong" one. A blended score would hide that distinction.
One of my earlier versions of this framework tried scoring on a dozen characteristics. The current three-dimensional read is what survived stress-testing against real cases — enough dimensions to capture what matters, few enough to actually be applied. It also helps reviewers focus on where the risks actually are (harm, control, dependency) rather than getting lost in how precisely to characterize each type.
The paper also draws the boundary of what the office governs at all, through the warranted-tool principle: a tool is warranted when it is deterministic or bounded, professionally accepted for the purpose, and backed by a vendor who would be accountable if it failed (a spreadsheet's summation, for instance). State law had relatively little to say about this distinction, so much of the warranted-tool framing is my own — an attempt to draw a defensible line so the office doesn't waste time governing a SUM function while still governing consequential AI use. What the office governs is unwarranted reliance on a probabilistic or unaccountable process for a consequential result.
Two automatic escalations act as hard floors. The confidential-data line is drawn at "confidential data" specifically, rather than at any "state data" — a more liberal reading than the maximalist interpretation, but one more consistent with the state's own stated goals of enabling innovation and protecting citizens (the maximalist reading serves neither). When a tool touches confidential or personal data, existing state risk-assessment obligations kick in.
The automated-decision-system line uses a specific statutory term with defined obligations. Read too broadly, "automated decision system" could encompass almost any workflow with software in it. The office issued interpretive guidance to keep the term aligned with what the statute actually addresses — decisions that assist or replace human judgment about people, in ways with legal effect. Because those obligations are legal ones, the office recognizes the lines and routes them rather than asserting rules of its own.
~9,200 words · ~18 pages
Maps the state rules that already apply to AI at the department and how the office reads them. The state has real machinery — the state's project lifecycle governs funded projects, the state's procurement rules govern purchases, and any GenAI tool touching state data owes a risk assessment filing, which in practice is closer to registration for review than to actual assessment.
Two observations shape the paper. First, most employees don't know these state processes exist at all — the risk assessment, the lifecycle gates, the associated forms are invisible to the people building or adopting AI. Second, the forms as structured are approvals — a signature saying "this may proceed" — rather than substantive risk evaluations. The paper is careful to note that distinction, because much of the office's work involves adding the evaluation layer the existing forms do not carry.
The paper's key structural observation is that the per-tool signature does not scale. When employees build or adopt AI in the hundreds or thousands, a signed form for each one either bottlenecks at central IT or pushes building into unmanaged shadow AI. That is the driver for one of the office's two narrow policy asks: a one-time category clearance for a defined class of low-risk, citizen-built tools, so they can register and proceed without a per-tool signature. A separate ask concerns everyday use of outside tools on public information.
~13,500 words · ~27 pages
Governs the AI tools employees build for themselves and their peers — both tools that use AI and tools built with AI.
Of all the papers in the series, this was — and still is — the most contentious. The initial reaction from most reviewers was some version of no — we can't do that. The concern was legitimate: unmanaged citizen AI has real downside. But the concern wasn't universal, either. Engineers wanting to automate their own tedious work, analysts building tools to streamline data pipelines, and other builders were already producing AI-enabled tools without any governance touch — the "state employees will never do this" premise was already false in practice.
The counter-argument the paper carries throughout: the choice is not citizen AI or no citizen AI. It's managed citizen AI, or denying reality until a problem big enough forces a better answer anyway. Everything else in the paper follows from taking the first branch.
One property worth naming: a small number of citizen developers can build tools that a large number of employees end up using. Distribution scales in ways individual authorship does not — and that turns out to be a governance opportunity, not just a risk. A tool published through the office's gallery, with characterization attached, is easier to track and update than the same tool copied around by email. It also protects against a subtler problem: when tools are shared by copy, a bad actor can modify a version and re-share it. When tools are distributed through a single gallery, every user pulls a fresh copy from the reviewed source. Distribution becomes a maturity signal to watch.
One terminology note: I differentiated citizen AI from citizen developer. The latter typically refers to non-technical staff building applications using low-code or no-code tools in hardened environments (Power Apps, ServiceNow app builder, etc.). Citizen AI is broader — it includes anyone building AI-enabled tools regardless of the platform, and the risk considerations are different because the models themselves add a probabilistic layer that no-code doesn't.
The same state rules still apply: a citizen-built tool that touches state data still owes the state risk assessment. That existing per-tool assessment required signatures from two officers within the department — not the tool's creator — which meant every citizen build consumed senior IT time from people not close to the work. It did not scale, and it was the immediate driver for the office's first policy ask (see Appendix A).
What the office adds is structure and support so a non-developer can build safely and at volume — a proportionate intake instrument that includes the state assessment by reference and adds the office's behavior-based characterization; a self-clear bar — a strict subset of the state's simplified assessment — so genuinely low-risk tools can register and proceed without heavy review; a single publishing and distribution location (the gallery), which doubles as the review-before-hand-off gate; and support for builders (templates, guidance, safe distribution) so the supported path is the easy path.
The paper also makes a specific move on responsibility: the user owns their reliance on the output, the author owns honest disclosure and good-faith security response, and the institution owns the systemic safety net.
~2,900 words · ~6 pages
Governs AI that arrives through the two formal doors — a funded project and/or a procurement — where the state's own approval and buying processes already run, and are mature enough to catch most considerations that need catching. What they don't catch is the AI-specific characterization, which is what the office adds.
Two adjustments from the citizen path: a heavier starting posture (an engagement opens the office's full governance record rather than the light "registered tool" used for most citizen builds), and a different trigger at each door. Project characterization attaches at lifecycle gates during development; procurement characterization attaches through the acquisition and contract terms, where a vendor's AI can be pinned down before the tool is even in hand. This attaches naturally to an iterative development model where the risk profile is developed and refined as the tool matures, rather than fully specified up front — which is aligned with the state's broader direction to move from waterfall to iterative development.
An engagement's characterization is not set-and-forget. Periodic reviews are required, more frequently for high-risk or high-usage items. Random audits also apply, so no engagement can assume it's fully outside scrutiny once initially cleared.
~1,500 words · ~3 pages
Governs AI that shows up in tools the department already owns or licenses — a vendor feature an administrator switches on, or one the vendor simply pushes into a product already in use. The paper's organizing idea is a control-lever ladder: from veto (the department owns the on-switch and can decline the feature) down through partial-control cases to no lever (the vendor pushed it in without asking). That control level determines how the office can act, though characterization proceeds identically to every other path.
Because this door has no process step that forces the AI question — the AI just appears — the paper leans on detection, with discovery as the backstop. Two further points shape characterization here: inherited access (an embedded feature is read on what its host tool can already reach), and this door's role as a catch-all for AI that did not get caught elsewhere (remnants from other paths that slipped their checks tend to surface here). The paper also carries the concealed-AI case, where AI is present but undisclosed.
~860 words · ~2 pages
The deliberately unfinished part of the model — a home for AI that does not fit the four ingress doors cleanly and for forms new enough that governance is still being worked out. Marked stub by design, and structured as an invitation for the office to add categories as the terrain changes.
~380 words · ~1 page
Outlines how the office builds workforce capability to use and build AI responsibly. A colleague on the engagement was leading the operational Copilot rollout, and the plan was to extend her draft with responsible-use guidance, existing AI tooling, and tool registration once her work reached a good stopping point. The stub records that intent without pre-empting her work.
~310 words · ~1 page
Outlines how the governance function measures itself. This turned out to be a surprisingly hard section to write — the easy metrics (submissions, approvals, cycle times) mostly turn out to be vanity metrics rather than health signals. What does mean something: discovered-but-managed AI beats undiscovered AI; a rising self-clear rate against a rising submission volume is a sign the system is working; a consistently falling self-clear rate is a sign the process is being distrusted or gamed.
Two other signals matter. Near-misses — cases where a tool almost caused harm but was caught in time — are the most valuable metric to track because they surface systemic weaknesses before harm happens. And the self-clear threshold itself is an adaptive parameter, not a fixed rule: if the office finds it is self-clearing tools that turn out to be dangerous, the bar should rise. If it is blocking tools that turn out to be safe, the bar should drop, or a new lower-risk category should be created. The point of measurement is to inform where the line sits, not to prove the line was drawn correctly the first time.
~2,400 words · ~5 pages
Governs AI-created and AI-edited media (images as the worked example; the pattern extends to video and audio). The core observation: AI doesn't require new rules for media governance — the two-process model most organizations already use (approve the tool, approve the output) is fundamentally sound. What AI requires is more review capacity, because more people can create and modify media more easily and more quickly than ever before. Governance work here is about scaling the existing review to handle the new volume, not about inventing new categories of oversight.
The paper assumes the department already has a functioning media-review system, which was true in this engagement. For departments that don't, the paper carries starter ideas and worked examples for building one, but does not attempt to specify a full media-review system from scratch. It identifies only the AI-specific items worth adding to an existing system: provenance (source and edit-history tracking, with realistic expectations about its limits), and how output review scales once the capability is in everyone's hands. It defers the technical and legal detail to Appendix E.
~700 words · ~1 page
The first of the office's two narrow policy asks. Modeled on the state's existing category clearance (which already allows Copilot for certain preapproved office productivity tasks), and structured so it is largely a subset of the existing simplified-assessment envelope. Requires a periodic refile with any material changes. This is the single change on which scalable, governed citizen AI depends: without it, every citizen-built tool needs the two-officer signature that Paper 4 describes as the immediate scaling problem.
~870 words · ~2 pages
The second policy ask: a narrow carve-out so everyday use of approved outside tools on public-information data is not blocked by a strict "any state data" reading. The underlying concern is broader than the specific rule: when a rule is so overbroad that everyone ignores it, that rule stops working and it makes it easier to ignore the rules that actually matter. This appendix argues for making the rule small enough to be followed.
~1,300 words · ~3 pages
The office's single AI intake instrument. The intake is intentionally aligned with the state IT group's existing instrument — described in parallel, referencing rather than replacing. The office's characterization is additive, not competitive with, existing authority. The same skeleton sizes from a few minutes of self-clear filling for a lightweight registered tool up to a full, signed engagement.
The intake is descriptive rather than checkbox-style: what does the tool do, how could it do harm, what guardrails or mitigations exist? This contrasts with more traditional risk forms that ask "what type of risk is this?" with Low/Medium/High checkboxes. The descriptive form takes longer to fill but produces richer signal — and forces the submitter to think about the tool rather than pattern-match to a category.
~1,400 words · ~3 pages
Two filled illustrative intake forms — a light self-clearing registered tool and a heavier engagement that trips both escalation triggers — showing the instrument in use. Worked examples turned out to be the best way to test whether the intake actually worked; a process that reads clean on paper often looks different once someone tries to fill it in.
~5,300 words · ~11 pages
The technical and legal reference on the California AI Transparency Act (SB 942 as amended by AB 853), the C2PA and watermark provenance technologies underneath it, and the limits of both, for media and documents.
The appendix exists because many readers of the new law treated it as implying that any AI-generated artifact could be traced back to its origin. It cannot. The appendix works through what provenance authenticates, what it does not, and where the gaps sit. Its central claim: provenance authenticates the honest, cannot catch the dishonest, and its absence proves nothing.
~6,300 words · ~13 pages
The neutral, cited factual base — the state's forms, lifecycles, security program, and acquisition rules — that the papers compress and cite. It takes no positions, so it can be shared openly.
This appendix also functioned as a working document during the engagement — a way to work through a body of state law and process that was new to me at the start. AI was useful here for research assistance and for translating specific kinds of legal text (amendments-to-amendments, cross-references, statutory definitions that only make sense in context) into workable summaries. The final text is human-authored; the process behind it was AI-assisted where that helped.
~150 words · ~1 page
A one-page organization-and-authority diagram (roles only) showing the parent-agency, department, and central-IT structure, the GenAI governance flow, and the risk-assessment signing chain.
~590 words · ~1 page
The list of statutes, state administrative instruments, department governance documents, and provenance and federal references the series consulted.
~260 words · ~1 page
A short, factual methodology note on how AI tools contributed to the series. In summary: the paper was produced through a structured authoring process. Outlines and section notes were agreed before any drafting. Most sections — including all introductions and load-bearing sections — were human-authored first. AI drafted to the agreed structure. Human editing sat on top throughout: for accuracy, for voice consistency, and for the removal of the specific patterns AI leaves in prose when it is not caught.
The process worked especially well where the work required both technical accuracy and voice consistency — the AI drafts to a firm structure, and human editing catches drift in both directions. A concrete example: renaming a working group referenced across a dozen sections was straightforward to do consistently and readably with AI, and would have taken hours by hand across scattered occurrences. Small, repeatable, high-consistency edits at scale are where the AI-assisted process most cleanly beats manual work.
~1,800 words · ~4 pages
The shared definitions for the series' terms, with proposed (not-yet-ratified) names clearly marked.
The papers are a series, but they don't have to be read in order.
For the design patterns underlying all of this — govern by behavior not label, attach don't mandate, risk is a shape not a score, doors are sensors, build instruments not documents, and five more — see Patterns for Governing Enterprise AI Adoption.
The full (modestly redacted) document is available on request. Contact: jeremy@bloomfamily.com