←
AI for Government
Capable · M28 · lesson 28 of 42 · queued
Preview — browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll →
NIST AI RMF: The GOVERN Function
📖
now learning

NIST AI RMF: The GOVERN Function

15 min

Carol Sityar had been the Chief Information Officer (CIO) of Maricopa-adjacent Ridgeline County, population 410,000, for six years when the County Manager added a line to her title that did not come with a budget: County AI Lead. The trigger was a small embarrassment. A caseworker in the Department of Human Services had been using a free online chatbot to summarize child-welfare case notes, pasting in names and addresses, and a local reporter found out. The Board of Supervisors wanted to know who had approved that. The honest answer was nobody, because Ridgeline County had no AI governance at all. No policy, no inventory, no committee, no one accountable. Carol's new job was to build that structure from an empty page. She did not have a Chief AI Officer, a research division, or a spare analyst. She had herself, a county attorney who returned calls within a day, and a Board that would give her exactly one shot to show this was serious without being slow.

This lesson is about the GOVERN function of the National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF): the part of AI risk management that establishes who decides, what the rules are, and who is accountable. A separate lesson covers the other three functions, MAP, MEASURE, and MANAGE, which are the operational work of inventorying systems, testing them, and fixing what is broken. This lesson is the foundation those three stand on. The artifact you will leave with is the one document Carol needed first: a one-page AI Governance Charter.

Why GOVERN Comes First

The NIST AI RMF, version 1.0, is voluntary and non-binding. It is widely referenced across federal, state, and local government, but adopting it is not itself a legal requirement, and binding obligations come from statute and from executive branch policy rather than from the framework. What it supplies is a systematic method for managing AI risk across the full lifecycle of a system, organized into four core functions. GOVERN is the one this lesson is about, and the framework deliberately draws it as the function that wraps around the other three rather than as the first step in a line.

FunctionThe question it answers
GOVERNHow will we make AI decisions? Who decides? What standards apply?
MAPWhat AI systems do we have, and what are their characteristics and risks?
MEASUREHow is this system actually performing? Is it accurate? Is it fair? Are new risks emerging?
MANAGEWhat do we do when we find a problem, and how do we stop it recurring?

The four are cyclical rather than sequential. You do not complete GOVERN and move on. As governance matures it enables better mapping, better mapping enables more sophisticated measurement, better measurement enables more effective management, and everything learned along the way refines the governance. The practical reason GOVERN is drawn as the wrapper is that every one of the other functions raises a question only GOVERN can answer. When MEASURE finds that a benefits-screening tool scores one neighborhood worse than another, someone has to decide whether to pause it. If nobody holds that authority in writing, the finding sits in an inbox.

Carol learned this in her first week. She asked a simple question across her departments: who is allowed to sign off on a new AI tool? She got four different answers. Procurement thought it was an IT decision. IT thought it was a program decision. The program directors thought legal handled it. Legal had never been asked. The chatbot incident happened in exactly that gap. No one bought a dangerous tool. A caseworker simply used a free one, because no rule said she could not, and no body existed to make such a rule. That is what an absent GOVERN function looks like on the ground.

It is not a dramatic failure. It is a quiet vacuum that a well-meaning employee fills with whatever is convenient. Governance is not the brake on AI; it is the steering. An agency with no governance is not moving cautiously. It is moving fast with no hands on the wheel, and the first crash is the one that teaches it the wheel exists. The governance structure you design should be sophisticated enough to support serious measurement and management, and simple enough that people actually use it.

Why This Is Different in Government

In the private sector, a company can sometimes afford to move fast and break things. If an AI system misbehaves, the response is often to fix it quickly and move on, with no formal accountability mechanism beyond lawsuits and regulation. In government the dynamics are structurally different. Agencies operate under statutory authority. They serve people who cannot opt out and cannot take their business elsewhere. They carry explicit obligations around equity, due process, and administrative procedure that no private firm carries in the same form.

They are also watched from several directions at once. Government Accountability Office (GAO) audits, Inspector General reviews, Congressional inquiries, and Freedom of Information Act requests all reach into how a decision was made and what record was kept of it. An AI system that nobody approved and nobody documented is not merely a technical exposure. It is an answer your agency will eventually have to give in writing to someone with subpoena power, and "we did not have a process" is the worst available version of that answer.

Without clear governance, agencies face four kinds of liability at once, and they compound. Legal liability if a system violates rights. Political liability if a system fails publicly. Operational liability if systems cause internal chaos and conflicting practice across units. Ethical liability if a system harms the communities the agency exists to serve. Clear, well-designed governance is not bureaucratic overhead layered on top of the mission. It is the infrastructure that lets AI be deployed lawfully at all, and the thing that makes responsible innovation possible rather than merely permitted.

The Five Pillars of a Working Governance Structure

GOVERN is not a single thing you stand up. It rests on five interconnected pillars, not sequential steps. Carol used the five as the outline for everything she built, because each pillar answers a question the Board would eventually ask her.

Pillar 1: Structure (who sits where)

Structure means the actual bodies that make AI decisions and who is on them. A mature governance structure draws from a standard menu, and the menu is worth knowing even if you will use only part of it. An AI Steering Committee of senior leadership, typically the CIO, Chief Data Officer, agency leadership, and policy staff, sets AI strategy, allocates resources, and makes high-level policy decisions. An AI Review Board of cross-functional representatives evaluates specific systems for compliance, fairness, and risk, reviews impact assessments, and makes the go or no-go call on individual deployments. That second body is where day-to-day governance actually lives.

Four more appear as agencies grow. A Technical AI Review Committee of engineers, data scientists, and architects assesses whether a proposed technical approach is sound, what it depends on, and what technical risks need managing. A Fairness and Ethics Review Board of subject matter experts focuses specifically on equity, fairness, and civil rights implications. A Data Governance Committee sets standards for data quality, provenance, retention, and access, which for many agencies is the real foundation of everything else. An Incident Response Team handles AI failures; it is often assembled when needed, but knowing its shape in advance is what makes it fast.

Ridgeline County did not need six bodies. Six bodies in a county of Carol's size would have meant the same handful of people attending six meetings. She built two: an AI Steering Committee of senior leaders to set policy and approve high-risk uses, and an AI Review Group of working-level staff from program, legal, privacy, IT security, and civil rights to evaluate specific tools before they go live. The principle is to have as few bodies as will still keep strategic decisions separate from case-by-case ones, and no fewer. What matters more than the count is clarity. Every person in the organization should be able to answer four questions: where does my question about an AI system go, who decides, what is the timeline, and who do I escalate to if I disagree?

Pillar 2: Policies and standards (what the rules are)

Structure decides; policy tells it what to decide on. A complete AI policy set covers eight areas. Permitted use cases: what types of AI use are allowed, what requires approval before deployment, and what is explicitly forbidden. Data standards: what quality bar data must clear before it enters a model, what documentation is required, and how provenance is verified. Fairness requirements: what counts as acceptable fairness, how it is measured, and what happens when a system shows disparate impact. Transparency requirements: how much disclosure is required, whether residents must be told when they are interacting with an AI system, and whether decisions must be explainable.

The other four are the ones that get written last and needed first. Risk tolerance: what level of risk is acceptable for which kinds of decisions, since a benefits eligibility system warrants far more rigor than a tool that ranks internal email by importance. Testing requirements: what must be tested before deployment, including adversarial robustness and performance across demographic groups. Human oversight requirements: which decisions must keep a human in the loop, which may be automated, and what override mechanisms exist. Monitoring and reporting: how often systems are checked for degradation, what metrics are watched, and what triggers escalation.

Carol did not write all of these in week one, and no small agency could. Her charter named them and set deadlines for each, starting with the acceptable-use policy that would have stopped the chatbot incident: an explicit ban on entering personally identifiable or case information into public AI tools. A charter that commits to policies it does not yet have is honest. A charter that pretends the policies already exist is theater. Whatever you write should be documented, accessible to the people it binds, revised as you learn, and above all implementable rather than beautiful in theory and impossible in practice.

Pillar 3: Roles and responsibilities (who owns what)

The most common governance failure is the assumption that someone is watching. Everyone believes somebody else is checking, and nobody is. Roles fix that by naming a person, or at least a position, for each duty. The standard set runs to seven. A Chief AI Officer or equivalent executive is accountable for the organization's overall approach, sets strategy, represents AI in leadership, and argues for the resources governance needs. An AI Governance Officer runs day-to-day operations: scheduling reviews, collecting documentation, tracking decisions, chasing follow-through.

The remaining five attach to specific assets and questions. A data owner is responsible for the quality, provenance, and appropriate use of each dataset. A model owner is responsible for a specific system's performance, monitoring, and maintenance. A domain expert validates whether outputs make sense in context and whether the system captures the real complexity of the decision. A fairness lead evaluates fairness implications and commissions audits. A security lead evaluates cybersecurity and adversarial robustness. For each role, document four things: what they are responsible for, what authority they hold, who they report to, and what happens when they identify a problem.

For federal agencies, Office of Management and Budget (OMB) Memorandum M-24-10 makes the top role mandatory: every covered agency must designate a Chief AI Officer with real authority and direct access to agency leadership. A county is not bound by M-24-10, but Carol borrowed the idea and made the AI Lead a written position with defined authority, so it would survive her eventual departure. A role that exists only because a particular person happens to care about the subject is not a role. It is a coincidence with a job title.

Pillar 4: Decision rights and escalation (who can say yes, who can say no)

Decision rights place each kind of decision at the lowest level that can properly make it, and define what happens when people disagree. Without them, governance either freezes, because everything needs everyone's consent, or leaks, because individuals make large calls alone. A robust framework sorts decisions into tiers. Staff or team level: refining a prompt, adjusting parameters within approved bounds. Unit or department level: deploying a new system, changing a fairness threshold, commissioning an audit. Governance board level: high-risk systems, systems reaching new populations, systems with new fairness implications. Executive level: strategy, budget, new policy commitments.

Carol's version compressed those four tiers into two thresholds plus a route out. Low-risk, internal-only tools could be approved by the Review Group. Anything touching residents' benefits, rights, or personal data went to the Steering Committee. Any unresolved disagreement between a program's wish to deploy and a reviewer's objection escalated to her as AI Lead, with the County Attorney consulted on legal questions. The escalation path matters most of all. If a team believes a system is ready and a fairness reviewer disagrees, that disagreement has to go somewhere and someone has to hold final authority. The whole point is that a reviewer who says "stop" has somewhere for that "stop" to land.

Pillar 5: Accountability and culture (whether any of it is real)

The first four pillars are paper. The fifth decides whether the paper means anything, and it is the hardest to build because it requires changing what people believe is expected of them. Accountability has five components. Decisions are documented: who decided what, when, and on what information, so the record supports later review. Accountability is assigned, so each system has someone who answers for it when it fails. There are real consequences for bypassing the process, not draconian ones, but real, because without them governance becomes theater. There are rewards for responsible practice, so that escalating a concern or slowing down to do something properly is recognized rather than resented. And leaders visibly treat governance as important rather than as something to minimize.

Carol had a choice about which of those to lead with. After the chatbot incident her instinct could have been to threaten discipline. Instead she paired a clear new rule with an approved, safe alternative tool and a fifteen-minute training, and she publicly thanked the supervisor who first flagged the problem. The lesson she was teaching was that raising a concern is rewarded and the safe path is the easy path. Governance that only punishes teaches people to hide their AI use, which is precisely the opposite of the inventory she was trying to build. Consequences still existed in her charter. They were just not the first thing anyone experienced.

Governance Maturity: Knowing Where You Are

No agency goes from nothing to excellent in one budget cycle. Governance matures through recognizable stages, and naming your stage honestly is how you set a realistic target. A common four-level scale runs from ad hoc to optimized, and each level describes a coherent state rather than a score.

  • Level 1, Ad hoc. No formal structure. AI decisions made informally. No central awareness of which AI systems exist. Responsibility for responsible use unclear. Policies absent or purely aspirational. Risk management reactive: problems emerge in production and are handled then. Ridgeline County on the day of the chatbot story was here.
  • Level 2, Initial. A basic structure exists, perhaps one oversight committee. Some systems are documented but not all. Policies exist but are incomplete or inconsistently applied. An oversight process exists but is not fully staffed. Responsibility is beginning to be clarified. Risk management is emerging but still largely reactive.
  • Level 3, Defined. A formal structure with clear roles. Governance processes documented and communicated. Most systems known and documented. Policies clear and consistently applied. Impact assessments required before deployment. Monitoring processes established. Risk management increasingly proactive. This is the realistic two-year target for most counties and mid-sized agencies.
  • Level 4, Optimized. Mature escalation and decision rights. Every system tracked, monitored, and regularly reviewed. Policies comprehensive and regularly updated. Fairness and equity systematically assessed. Continuous improvement processes running. Risk management predictive and data-driven, and AI governance folded into the agency's broader enterprise risk management. Few public agencies are here yet.

Carol placed Ridgeline County at ad hoc and set a defined target within eighteen months. She did not aim for optimized, because aiming for optimized would have produced an elaborate plan the Board would fund once and then quietly abandon. Each step up is worth taking on its own terms. Moving from ad hoc to initial, which is mostly the charter and one committee, eliminates the single largest category of risk: nobody knowing anything is happening. Level 2 is dramatically better than level 1, and level 3 is dramatically better than level 2, which means there is never a good reason to wait for the resources to skip a step.

How GOVERN Aligns With OMB M-24-10

Ridgeline County is local government and is not legally bound by federal AI directives. Carol used them anyway, as a free and well-vetted blueprint, because state and local agencies are increasingly expected to mirror federal practice and because county systems often handle federal funds and federal data. Historically, Executive Order 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, issued in 2023, set the federal policy direction that OMB Memorandum M-24-10 then implemented. Executive orders are revised and revoked across administrations, so treat the current executive authority as something to confirm with counsel; the governance structure below is what proved durable.

M-24-10, "Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence," sets requirements for federal AI governance that are compliance obligations rather than suggestions. Six of them map directly onto the pillars, which is why they work as a checklist for an agency of any size.

  • A designated Chief AI Officer. A senior, accountable official with decision-making authority and direct access to leadership. Carol's mirror is the written AI Lead position.
  • A governance structure with cross-functional representation. Empowered to decide which systems are appropriate to deploy and how they are monitored. Carol's mirror is the two-tier Steering Committee and Review Group.
  • An AI use case inventory. A maintained list of systems in use or in development, with purpose, scope, data sources, and known risks. This is MAP work, but the charter commits to it and assigns it.
  • Impact assessments before deploying significant systems, addressing intended and actual outcomes, potential impacts on civil rights and civil liberties, potential impacts on protected classes, data quality and availability, and whether the resources for successful implementation are actually there.
  • Minimum practices for the higher-risk tier: governance and accountability structures, documentation and transparency, testing for bias and performance, human oversight and review, and ongoing monitoring.
  • Incident reporting. A defined channel for when an AI system causes significant harm or is found to violate civil rights.

M-24-10 is a floor, not a ceiling. It sets minimums, and an agency genuinely committed to responsible AI will exceed them. For Carol it was also a checklist she could hand the Board to prove her charter was not invented out of thin air. It rested on the same structure the federal government had already adopted, which turned out to be worth more in that room than any argument she could have made on her own authority.

Building It: A Six-Step Sequence

Concepts do not become governance on their own. The pragmatic sequence runs in six steps, and the first is the one people skip. Step 1, assess the current state. Before building anything, find out what AI systems already exist, who is responsible for each, whether decisions are made formally or informally, what documentation exists, who in leadership cares most about responsible AI, and what barriers stand in the way. This assessment typically takes two to four weeks and involves interviews with technical staff, program managers, and leadership. It is also how you find your allies.

Step 2, define the structure, sized to your agency. At minimum you need a single accountable person, a governance body that decides about specific systems, clear roles for data owner, model owner, and fairness lead, and defined escalation paths. For a small agency, meaning fewer than 500 people, that might be one part-time committee. For a large agency it might be several committees with full-time staff. Step 3, establish policies, starting with the essentials: what requires board approval before deployment, what data standards apply, what fairness assessment is required, how decisions are documented, and how concerns escalate. Build practical policies you can refine, not perfect ones you never finish.

Step 4, communicate and train. A governance process nobody knows about is indistinguishable from no process. Explain why it exists, how it works, and how to use it. Step 5, pilot and refine. Run a few real decisions through the structure and find out what works, what is burdensome, and what is missing. Step 6, scale and mature. As people grow comfortable, add fairness assessment, add monitoring, increase oversight of high-risk systems. The sequence deliberately front-loads the cheap steps, because a structure that has survived five real decisions is far easier to fund than one that exists only as a proposal.

Scaling Governance: Small Agency Versus Large

The single most common mistake Carol avoided was copying a large department's org chart onto a small county. A cabinet-level federal department with thousands of AI systems genuinely needs separate executive, technical, fairness, and data bodies, full-time governance staff, and formal charters for each board. A county, a city, or a small bureau does not. For a small agency the same five pillars are satisfied by fewer bodies wearing more hats: one steering group, one review group, named owners drawn from existing staff, and a single short charter. The pillars do not shrink. The number of meetings does.

The inverse mistake is just as real. A large agency that runs everything through one overloaded committee creates a bottleneck that staff route around, which recreates the shadow-AI problem at scale. The right size of governance is the smallest structure that still keeps strategic decisions separate from case-by-case ones and still gives every "stop" somewhere to land. Carol's test was a question any employee should be able to answer: if I want to use a new AI tool, where do I go, who decides, and how long will it take? On the day of the chatbot story, no one in Ridgeline County could answer it. Ninety days after the charter, everyone could.

The Artifact: A One-Page AI Governance Charter

Everything above lives or dies as one document. A governance charter is the founding instrument that establishes the bodies, names who sits on them, sets decision rights and escalation, commits to the policies that will follow, and fixes a review cadence. It should fit on a page, because a charter no one reads governs nothing. Here is the charter Carol brought to the Board, reproduced in the seven clauses she used.

  1. Purpose. To ensure that every use of artificial intelligence by Ridgeline County is lawful, fair, secure, and accountable to residents, and to prevent the unmanaged adoption of AI tools with county data.
  2. Scope. All AI systems used by any county department, whether built in-house, purchased, embedded in other software, or adopted by staff from free or public tools. Covers systems in development and in production.
  3. Governance bodies and membership. The AI Steering Committee, chaired by the County CIO and AI Lead, with the County Attorney, Privacy Officer, Human Services Director, and Finance Director, sets policy and approves rights-impacting and safety-impacting deployments; it meets quarterly and on demand. The AI Review Group, working-level staff from IT security, legal, privacy, civil rights, and the sponsoring program, reviews each proposed tool before go-live and approves low-risk internal uses; it meets monthly.
  4. Decision rights and escalation. Low-risk, internal-only tools are approved by the Review Group. Tools affecting residents' benefits, rights, or personal data are approved by the Steering Committee after a required impact assessment. Disputes between a program and a reviewer escalate to the AI Lead, with the County Attorney consulted on legal questions. A reviewer objection halts deployment until resolved.
  5. Policies this charter commits to, with deadlines. Acceptable-use policy including a ban on entering personal or case data into public AI tools, 30 days. AI procurement-review rule, 30 days. AI use-case inventory, 60 days. Incident-reporting procedure, 60 days. Data-handling standard, 90 days. Human-oversight standard for rights-impacting AI, 90 days.
  6. Accountability. Every deployed system has a named system owner. All approvals and impact assessments are documented and retained. Use of AI outside this process is a defined policy violation, and the safe, approved alternative plus brief training are provided to every employee.
  7. Review cadence. The Steering Committee reviews this charter and the system inventory annually, and after any AI incident.

Notice what the charter does and does not do. It does not write the acceptable-use policy. It commits to writing it by a date and says who owns it. It does not inventory the county's AI. It commits to the inventory and assigns it. This is what lets one page carry an entire governance program. The charter is the spine; the policies and the inventory are the limbs that grow from it on a published schedule. Carol's Board approved it in a single meeting, precisely because it was one page they could read in the room, and because every line answered a question they were about to ask.

Anti-Patterns

  • Governance as bottleneck. Well-intentioned governance becomes so complex and slow that teams avoid it, because asking forgiveness is faster than asking permission. It happens when committees are too large, sign-offs too many, policies too stringent, or meetings too rare. You end up with two governance systems: the formal one people work around, and the informal one that actually happens, which is less accountable than having none. Design lean. Target a decision in one to two weeks rather than months, meet on a regular cadence, and push decisions to the lowest level that can properly make them. Excessive friction is a signal to redesign the process, not evidence that people should route around it.
  • Governance without compliance. Structures and policies that look good on paper while systems get deployed without review and decisions go undocumented. It happens when leadership does not visibly back the process and there are no real consequences for skipping it. The result is the worst of both worlds: the bureaucratic burden without the benefit, and then people blame governance for the failure. Leadership has to push back visibly when someone bypasses the process, recognize the teams that follow it, and keep the process easy enough that compliance is not an act of heroism.
  • Governance capture. The structure exists but a single perspective dominates it, so fairness concerns are systematically subordinated to speed, or legal caution smothers every proposal, or technical staff turn a rights question into an architecture question. Whoever holds the most power on the body shapes its decisions. Guarantee representation explicitly across domain, fairness, legal, technical, and program perspectives; create space for disagreement rather than routing around it; and make sure a perspective that loses a decision still sees that it was heard.
  • Governance fatigue. After the launch enthusiasm, meetings feel repetitive, policies feel like busywork, and decision-making becomes perfunctory. Committees meet but do not decide. You keep the burden and lose the benefit. The antidote is visible value: when governance prevents a problem, say so out loud; when it catches an issue early, share the story; when responsible practice delivers a result, name it. Then keep the machinery lean, with no extra meetings, no unnecessary documentation, and no approval required for trivial decisions.
  • Punishment-first enforcement. Responding to the first incident with discipline alone teaches staff to hide their AI use, which destroys the inventory before it exists. Pair every new prohibition with an approved alternative and the training to use it, so the compliant path is also the convenient one.
  • The charter as the finish line. Adopting the charter feels like completion, and the deadlines inside it quietly slip. The charter is a set of promises with dates attached. Track those dates the way you would track any other commitment to your governing board, and report on them at the same meeting.
  • Assuming the framework does the governing. Naming the AI RMF in a policy document produces nothing on its own; it is voluntary and it has no enforcement mechanism. What governs is the named official, the written decision right, and the escalation path that a real reviewer used last month.

Practice Prompts

  • Map your current governance. Take thirty minutes and document your agency's AI governance as it exists today, including the absence of it. What structures exist? Who actually makes decisions about AI systems? Are those decisions documented anywhere? Who is accountable for each system in production? Be honest about the gaps, because the gaps are the work.
  • Design governance for one unit. Pick a specific program or unit rather than the whole agency. Design the minimum governance that would work for it: which bodies or roles, meeting how often, deciding what. Be ruthlessly practical about what could actually be implemented with the people who are already there.
  • Identify your three obstacles. What is preventing better AI governance in your agency right now? Leadership support, capacity, unclear responsibilities, conflicting priorities, something else? Name the top three and sketch one possible move against each, including the cheapest one you could make this month.
  • Research peer agencies. Look at how agencies similar to yours have structured AI governance. Many have published their frameworks publicly. What transfers to your context, and what does not? Adapting a peer's structure is faster than inventing one and easier to defend to your leadership.
  • Place yourself on the maturity scale. Using the four levels above, where does your agency sit today? What specifically would it take to advance one level, what would the benefit be, and what would it cost in staff time rather than dollars? Which single investment is the highest priority?
  • Draft your one-page charter. Using Carol's seven clauses as the outline, draft a charter for your own organization. Name real bodies, real positions, and real deadlines. If a clause is uncomfortable to write because you do not know who owns something, you have found a decision right that does not yet exist.

Reflection

Take three minutes. Think about the governance in your organization as it stands, starting from whatever exists even if it is minimal. What decisions are being made about AI systems right now? Who is making them? Are they documented anywhere a successor could find them? Is it clear who holds the authority to stop a deployment, and would that person know they held it?

If you had to describe your current governance in a single sentence, what would that sentence be? Is it the governance you want? What would need to change for the sentence to be different in a year? And finally, who in your organization cares most about responsible AI governance? Those are the people to partner with, and in most agencies they are already doing part of this work without a title for it.

Glossary

  • Chief AI Officer (CAIO): a senior official responsible for establishing and overseeing an organization's AI governance framework, strategy, and compliance with AI governance requirements.
  • Governance structure: the organizational arrangements, committees, and decision-making processes through which an organization decides about AI systems and assigns responsibility.
  • Governance charter: the founding document establishing the governance bodies, their membership, decision rights, escalation path, committed policies, and review cadence.
  • Impact assessment: a systematic evaluation of the intended and potential unintended consequences of an AI system across fairness, civil rights, performance, and resource requirements.
  • Model owner: the person designated as responsible for a specific model's performance, maintenance, monitoring, and compliance with governance requirements.
  • Data owner: the person designated as responsible for the quality, provenance, appropriate use, and governance of a specific dataset.
  • Decision rights: the explicit allocation of authority specifying who can make which decisions about AI systems, and when a decision must be escalated.
  • Escalation process: the formal procedure for raising a concern, conflict, or decision above the authority of the person or group currently holding it.
  • Governance maturity: the stage of an organization's governance development, commonly described on a four-level scale from ad hoc to optimized.
  • Shadow AI: AI tools adopted by staff without procurement, IT, or legal review, and therefore invisible to governance and to the inventory.

Closing

Governance is the unglamorous part of AI adoption. It does not produce models, deploy systems, or solve a program's problem. What it does is create the conditions under which everything else can happen responsibly. Structure that makes clear who decides what. Policies that encode institutional values. Roles that create accountability. Decision rights that enable speed while preventing rogue calls. Culture that makes people actually care about doing it right. Together those elements produce an organization that can innovate with AI while keeping its institutional integrity intact: one where problems get escalated rather than hidden, decisions get documented, and fairness and security are built into how choices are made rather than reviewed afterward.

Carol's county did not become sophisticated. It became legible. Ninety days after a caseworker pasted child-welfare notes into a public chatbot, every employee could say where an AI question goes, who decides, and how long it takes; a named official was accountable; and six policies had owners and due dates. None of that required a research division or a budget line. It required one page, two committees, and a leader willing to write down who decides. The framework is the map. Somebody still has to sign the charter.

Key Takeaways

  • GOVERN wraps around the other three functions; it does not precede them in a line. MAP, MEASURE, and MANAGE all raise the question only GOVERN answers: who is allowed to decide. Build the wheel before you press the accelerator.
  • An absent governance function is a quiet vacuum, not a dramatic failure. The risk shows up as a well-meaning employee filling the gap with whatever free tool is convenient, because no rule and no body existed to guide them.
  • Government raises the stakes structurally. Statutory authority, citizens who cannot opt out, GAO and Inspector General oversight, Congressional inquiries, and FOIA requests mean legal, political, operational, and ethical liability all land at once when nobody governed the decision.
  • The five pillars are structure, policies, roles, decision rights, and accountability and culture. The first four are paper. The fifth, especially culture, decides whether the paper means anything.
  • Clarity beats completeness in structure. The menu of governance bodies runs to six, but what matters is that every employee can answer where a question goes, who decides, how long it takes, and who to escalate to.
  • Name your maturity level honestly and target the next one, not the top. Moving from ad hoc to initial removes the single largest risk. Aiming straight for optimized produces a plan that gets funded once and abandoned.
  • The AI RMF is voluntary; M-24-10 is not, for the agencies it covers. The Chief AI Officer, the governance body, the inventory, impact assessments, minimum practices, and incident reporting are compliance obligations for federal agencies, and a free, vetted blueprint for everyone else.
  • Scale the number of bodies, never the pillars. A small agency satisfies all five with one steering group, one review group, and named owners from existing staff. A large agency that funnels everything through one committee recreates shadow AI at scale.
  • A charter that commits to policies it does not yet have is honest; one that pretends they exist is theater. Name each policy, assign an owner, set a deadline. One page can carry an entire program if it is a spine, not a finished body.
  • Pair every new rule with a safe, approved alternative. Governance that only punishes teaches staff to hide their AI use, which is the opposite of the inventory you are trying to build.

Frequently Asked Questions

Our agency is not covered by federal AI policy. Why should we follow any of this? Because the alternative is inventing it yourself. Federal requirements were developed with substantial legal and technical review, and mirroring them costs nothing and gives you something defensible to hand your governing board. There is also a practical reason: state and local systems frequently handle federal funds and federal data, and expectations tend to travel with the money. Carol used M-24-10 exactly this way, as a blueprint rather than an obligation.

We have two people and no budget. Is a governance structure realistic? Yes, at the scale that fits. The five pillars are satisfied by a written charter, one decision-making group, named owners drawn from staff who already do the work, and a documented escalation route. What you cannot do is skip the pillars; what you can do is collapse six potential bodies into one and hold the meeting monthly. The most valuable thing a small agency can produce is the answer to a single question: if I want to use a new AI tool, where do I go?

How do we keep governance from becoming the thing everyone routes around? Measure it. Track how long a review actually takes and publish the number. If a low-risk internal tool takes eight weeks to approve, staff will stop asking, and the informal system that replaces yours will be less accountable than having no process at all. Push routine decisions to the lowest competent level, meet on a predictable cadence rather than on request, and reserve the heavyweight path for systems that touch rights, benefits, or safety.

Who should chair the governance body? Someone with authority over resources and access to agency leadership, which in practice often means the CIO, a Chief Data Officer, or a designated AI Lead. For federal agencies M-24-10 settles the top role by requiring a Chief AI Officer with real authority. The failure mode to avoid is a chair whose influence is personal rather than positional, because that governance evaporates when they take another job. Write the position down, with its authority, before you fill it.

What goes in the charter versus in a policy? The charter establishes bodies, membership, decision rights, escalation, accountability, and the review cadence, and it commits to the policies with dates and owners. The policies themselves carry the operational rules: what tools staff may use, what data may go where, what testing is required, what oversight applies. Keeping them separate is what lets the charter stay one page, and it means you can revise an acceptable-use policy without reopening the founding document.

Something has already gone wrong. Do we investigate first or build governance first? Do both, and let the incident carry the governance. An incident is the moment an agency is most willing to fund structure, and the charter is faster to produce than a full investigation. Carol's sequence is a reasonable template: an immediate rule with a safe alternative attached, then the charter naming the bodies and the deadlines, then the inventory that tells you whether the same gap exists elsewhere. Handle the incident punitively and in isolation, and you will learn nothing about the other cases you have not found yet.