When the city of Brookhaven's first AI governance board met, it took ninety minutes to approve a font. Twenty-two people sat around the table: every department head, two union representatives, the city attorney, three IT staff, a community advocate, and a councilmember who had read about AI on a flight. The board had no charter, no decision rules, and no idea what it was actually allowed to decide. By the third meeting, attendance had collapsed and two urgent AI projects had stalled waiting for an approval the board did not know how to give. The deputy city manager who had convened it, Daniel Cho, learned the hard lesson the expensive way: a governance board without a charter is not governance. It is a recurring meeting.

This lesson is about building the opposite: an AI governance board that actually governs, makes timely decisions, and earns the trust of both leadership and the public. We will rebuild Brookhaven's board the right way, and the centerpiece is the document Daniel skipped, the charter.

What a governance board is actually for

A governance board exists to make a specific set of decisions that no single official should make alone, and to make them consistently. For AI, those decisions cluster around three questions: What AI systems does the agency operate, and are they safe and aligned? Who is accountable for each one, and what happens when something goes wrong? And how does the organisation learn and improve over time? A board that knows these are its job moves fast. A board that thinks its job is "to discuss AI" will spend ninety minutes on a font.

The board is not a technical review committee, and it is not a rubber stamp. It is the place where the agency's values, its legal obligations and its operational reality meet to make a call on the uses of AI that carry real consequences for the public. Without such a venue, AI decisions get made in silos: engineering optimises for accuracy, compliance worries about regulation, operations worries about cost, advocacy groups worry about harm, and nobody is looking at the whole picture. A board's job is to make decisions, not to have meetings. If it cannot tell you what it decides, it will not decide anything.

Why government governance is not corporate governance

Four features of public-sector work change the design. Public accountability: government decisions affect people's lives and are subject to public scrutiny, and unlike a private company you cannot quietly withdraw a biased AI system. When it fails, the public knows. Statutory compliance: agencies operate under specific statutes, among them the Administrative Procedure Act, the Privacy Act and the Freedom of Information Act, and AI systems have to comply with them. A board can put compliance on the agenda and demand evidence; it cannot by itself make a system compliant, and treating board attention as proof of compliance is how gaps survive.

The other two features are about people. Stakeholder diversity: agencies serve elected officials, the public, civil service unions, contractor communities and advocacy groups at once, and a board is the forum where those interests get integrated deliberately rather than by whoever pushed hardest. Career civil service: government staff often stay for decades and inherit systems built by people who have retired. A board with continuity and written decisions can preserve the reasoning behind those systems, which is the difference between inheriting a tool and inheriting a mystery.

Three models, and how to pick one

There are three primary governance models, and the right one is a function of size, distribution and risk tolerance rather than fashion. Choosing badly is a common cause of board failure, because a structure that fits a 200-person agency will throttle a department of thousands, and a structure built for a sprawling federation will let a small agency's decisions drift apart.

The four design choices that make or break a board

Every effective governance board resolves four questions on paper before its first meeting. Brookhaven resolved none of them, which is why it failed. Here is each, with the choice Daniel made the second time.

Structure: how big, and reporting to whom

The first board's fatal flaw was size. Twenty-two people cannot decide anything; they can only react. Seven to eleven members is the range that works: large enough for genuine diversity of view, small enough for substantive conversation. The redesigned board had nine voting members, a deliberate odd number to break ties, drawn for the perspectives a good AI decision needs rather than for representation of every department. It reported directly to the city manager, which gave it the authority to make decisions stick. A board that reports nowhere in particular has recommendations no one has to follow.

Membership: the perspectives, not the org chart

Daniel chose members by the lens each brought, not by title. Six perspectives have to be present or decisions become one-sided: mission and programme leadership, which understands what the organisation is trying to accomplish; technical leadership, which can evaluate feasibility and identify risks; compliance and legal, which knows the statutory requirements; security and privacy, which understands infrastructure risk and privacy implications; workforce and labour, which represents affected employees and unions; and operations and finance, which understands implementation cost and sustainability. Brookhaven added a community representative who could speak for residents on the receiving end of these systems.

Specialists needed only occasionally, like a particular department head, were made standing advisors who attended when their area came up rather than permanent voting members. That kept the voting body small while keeping the expertise available. Four further membership principles are worth writing into the charter. Members need senior authority, usually director level or equivalent, because a board of mid-level staff cannot enforce a decision that senior leadership dislikes. Each member needs a defined role: what they represent, what they own, what their escalation path is. Workload should be reasonable, in the range of two to four hours a month for anyone but the chair, because a board that demands more will be staffed by people who cannot attend. And membership should carry across fiscal years with staggered terms, because constant turnover destroys institutional memory.

Decision authority: what the board can actually do

This is the choice Brookhaven most conspicuously skipped, and its absence is why projects stalled. The charter must state exactly what the board can decide on its own, what it can only recommend upward, and what it can stop. Daniel's board could approve moderate-impact AI uses outright, could approve high-impact uses with the city manager's co-sign, and could pause or halt any system already in use that showed signs of harm. Low-impact internal tools were delegated to a light staff process with documentation, and came to the board only as a quarterly report. Spelling this out meant a project sponsor knew, going in, exactly what a "yes" from the board was worth.

Decision rules: how a call actually gets made

Finally, the board needed a method for reaching a decision, so that disagreement did not become paralysis. The charter set a quorum of five voting members, decisions by majority, and a fallback: if the board deadlocked on a high-impact decision, it went to the city manager with the board's reasoning attached. There was also a fast track, so a low-risk, time-sensitive use could get an email approval from the chair plus two members rather than waiting a month for the full meeting. Speed and care are not opposites if you design for both, and an express lane that exists in writing is far safer than the informal one a board acquires when it has no express lane at all.

A usable artifact: the AI governance board charter

Below is the charter skeleton Daniel adopted. A charter is short on purpose; a board that needs forty pages to explain itself will never act, and a three-page document is enough for most agencies. Fill in the entries for your agency, get it signed by the official the board reports to, plan to revisit it annually, and you have converted a recurring meeting into a governing body.

The "what comes to the board" row is the unlock

Notice the row most charters omit: what actually triggers a board review. Without it, the board either drowns trying to look at every spreadsheet macro, or finds out about high-impact systems only after a reporter does. Daniel tied the trigger to impact level, the same way his agency's risk practice classified AI uses. Low-impact internal tools went through a light staff process and never reached the board. Anything touching the public, or carrying high impact, came automatically. This single rule kept the board focused on the decisions that mattered and out of the ones that did not, which is precisely the discipline the first board lacked.

Scaling scrutiny to risk

Your board should not spend the same time approving a chatbot as it does approving a system that determines benefit eligibility. A risk-based framework fixes that by defining, in advance, which category a system falls into and what that category buys it. Four tiers are enough for most agencies, and the point of writing them down is that the tier is assigned at intake by criteria rather than argued about after a sponsor has a launch date.

Define which of your systems sit in each tier before you need to, and publish the criteria. This prevents the board from being overwhelmed with routine approvals while ensuring risky systems get proper attention. It also removes the most common source of friction between a board and a delivery team, which is not disagreement about risk but uncertainty about which process applies.

The machinery between meetings

A board that meets monthly and makes decisions is still not governance. Three pieces of infrastructure carry the work between meetings, and all three are unglamorous. The first is a system inventory: a living list of every AI system with its risk level, owner, status and last review date, updated quarterly and reviewed by the board. If you do not know what systems exist, you cannot govern them, and the first version of this list is almost always longer than leadership expects.

The second is a standard review checklist, so that every system faces the same questions and the board's decisions stay comparable over time. Six questions cover most of it: What problem does it solve? What data does it use? How accurate is it, and how do you know? What could go wrong, and what is the mitigation? Who is accountable if it fails? How is it monitored? The third is a documented escalation procedure: teams raise issues to the board, and the board decides among fixing it, monitoring it, shutting it down, or escalating further. Add to that a habit of reviewing failures, audit findings and near-misses, because a board that never examines what went wrong will keep approving the thing that caused it.

The review conversation, worked through

Watch the checklist do its job on one of Brookhaven's stalled proposals: a tool that would score building-permit applications for likely code violations and route the high scores to inspectors first. What problem does it solve? Inspection capacity is fixed and the queue is first-in-first-out, so serious violations wait behind trivial ones. What data does it use? Past inspection outcomes, which is where the board's technical member stopped the presentation, because past inspection outcomes record where inspectors went, not where violations were.

How accurate is it, and how do you know? The sponsor had the vendor's overall accuracy figure and nothing broken out by neighbourhood, which is exactly the breakdown that would have shown whether the tool was reproducing historical inspection patterns. What could go wrong, and what is the mitigation? The community member named it: properties in historically under-inspected areas stay under-inspected, and the tool makes that look like data-driven prioritisation. Who is accountable if it fails, and how is it monitored? Neither question had an answer on the slide.

The board did not reject the proposal. It approved it conditionally, with three conditions written into the minutes: performance broken out by council district before deployment, a named accountable official, and a quarterly report comparing tool-prioritised inspections against violations found. That is what a functioning board produces, and it took less than one agenda item. Note what made it possible: a standard checklist meant nobody had to invent the questions, and a seated community perspective meant the sharpest question came from someone with no stake in the project's schedule.

What this looks like at three scales

A regional agency with twelve AI systems creates a nine-person board: director, deputy director for programmes, IT director, legal counsel, chief financial officer, union representative, programme manager, IT security officer and community representative. They meet monthly for two hours, use a risk-based decision framework, and require board approval above the moderate tier. Systems are reviewed annually with quarterly check-ins for the high-risk ones. They write a three-page charter and keep a simple inventory spreadsheet. It is neither too heavy nor too light for what they run.

A large federal agency with more than eighty AI systems adopts hub-and-spoke instead. A central board of about ten people meets monthly to set standards, review high-risk systems and handle conflicts, with representatives from each major department plus central IT, legal, finance and security staff. Department-level committees of six to eight people meet every other week to handle routine approvals and local escalations, staffed by programme managers, technical leads and local compliance officers. Standards live in a fifteen-page framework. The structure prevents silos while remaining scalable.

A government working across multiple agencies in different countries goes federated. Each country's board is autonomous but coordinates on shared training data, cross-border data sharing and escalations that affect more than one jurisdiction. A coordination committee meets quarterly and shares audit findings. Note what stays constant across all three: cross-functional representation, clear authority, risk-based decisions, documentation and executive sponsorship. The structure varies with the organisation. Those five principles do not.

Making the board credible, inside and out

A board can have a perfect charter and still fail if no one trusts it. Two practices earned Brookhaven's redesigned board its credibility. First, it published its decisions and their reasoning, so residents could see not just that the city used AI but how those uses were vetted. Invisible governance loses trust; transparency converted the board from a black box into a visible safeguard. Second, the board kept a standing relationship with the people doing the technical and risk work, so its decisions rested on real evidence rather than the loudest opinion in the room. The board did not do the analysis itself; it consumed the analysis and made the call, which is the right division of labour.

The contrast tells the whole story. The first board approved a font in ninety minutes and stalled two real projects for a month. The second board, smaller and chartered, cleared a backlog of six AI proposals in its first two meetings, paused one that lacked a bias review, and sent a high-impact one upward with a clear recommendation. The difference was not the people. Most were the same people. The difference was that the second time, the board knew what it was for.

Anti-Patterns

Four failure modes account for most dead boards, and a fifth for most boards that look alive and are not.

• A board without authority. The board recommends, and leadership ignores it. A board advises against deploying a facial recognition system on bias grounds; leadership deploys it anyway; citizens sue; the agency loses. This happens when executive leadership treats the board as advisory rather than as setting policy. Make executive sponsorship explicit and public, and if leadership will not back the board, do not create one. A board known to be overridable is worse than no board, because it launders decisions it did not actually control.
• A board as rubber stamp. Members are overworked, the sponsor presents well, nobody wants to slow things down, and everything gets approved. A hiring system passes without anyone asking about fairness testing, discriminates against women in production, and afterwards people say "but the board approved it" when the board never examined the fairness data. A board approval records that a meeting happened, not that anyone read the evidence. Give members the time and material to ask hard questions, and expect friction between delivery speed and governance.
• Governance without documentation. The board exists but decisions are not recorded and standards are understood implicitly. A month later nobody remembers what was decided, new members do not know the precedents, and when auditors ask what the board's decision criteria were, there is no answer. System A was approved with conditions; System B arrives looking similar; the conditions are forgotten. Lightweight minutes answering what was decided, why, by whom, and what happens next are enough.
• A board without diversity of perspective. All engineers, or all compliance, or all leadership. An all-engineering board approves technically sophisticated systems with poor user experience; an all-compliance board blocks everything; a board with no workforce voice approves a hiring system and never asks about its effect on job seekers with disabilities. Build the six perspectives deliberately, because the easy path is to invite whoever was in the last meeting.
• Treating the charter as the deliverable. A signed charter, a published inventory and a monthly meeting are the preconditions for governance, not the evidence of it. The test is whether a system has ever been stopped, whether a condition attached to an approval was ever checked, and whether anyone can name a decision the board made that a sponsor did not want. If the answer to all three is no, the board is documentation.

Practice Prompts

• Map your organisation: how many AI systems does your agency operate or plan to operate, and who are the key stakeholder groups affected by them? Produce the count before you design anything, because the count picks the model.
• Choose your model, centralized, hub-and-spoke or federated, and write the two-sentence justification you would give an executive sponsor. State explicitly what the model's known weakness is and how you will compensate for it.
• Define membership seat by seat. For each person, write what they represent, which decisions they own and what their escalation path is. Flag any of the six perspectives you cannot fill and name who would have to approve creating that seat.
• Develop the decision criteria: which systems would the board approve, and what may teams do without board approval? Write the criteria as tests a sponsor could apply themselves at intake, not as categories requiring interpretation.
• Draft the charter to three pages using the sections in this lesson, then have someone who was not involved read it and tell you what the board is allowed to stop. If they cannot answer, the authority section is not finished.
• Identify obstacles: what would make this hard in your organisation, and how would you address each one? Be specific about which existing body would see the board as a competitor for authority.
• Write the engagement plan for staff and leadership, including how board decisions will be communicated to the public and what will be withheld and why.

Reflection

Think about your agency's AI governance as it exists today, not as it is described in a policy document. Does it exist in any formal way? If it does, ask what the last decision it made was and whether anyone would have noticed had it not met. If it does not, ask what would actually be needed to establish it: not the charter, which is a weekend of writing, but the executive sponsorship, the seat allocations and the authority to stop a project that someone senior wants. Then ask the question that separates a real board from a performative one: if the board recommended against a deployment that leadership wanted, what would happen next, and who in your organisation would decide?

Glossary

• Charter: The written document defining a board's authority, scope, decision rights, review cadence, escalation path, accountability and transparency obligations. Three pages is usually enough.
• Decision authority: The power to make binding decisions about which systems are deployed, as distinct from the power to advise on them.
• Decision rights: The specific split between what requires board approval and what teams may do on their own, written so a sponsor can tell which applies before they ask.
• Cross-functional: Including perspectives from different organisational functions, specifically mission, technical, compliance, security and privacy, workforce, and operations and finance.
• Hub-and-spoke model: A governance structure in which a central board sets standards and reviews high-risk systems while local committees handle routine approvals.
• Federated model: Multiple autonomous boards with light coordination at the centre, suited to networks of independent organisations.
• Risk-based framework: An approach in which oversight intensity scales with a system's impact, so scrutiny is spent where consequences are largest.
• System inventory: The living record of all AI systems with risk level, owner, status and last review date. Governance of an uninventoried system is aspirational.
• Escalation: The defined mechanism for raising an issue from an operational team to the board, and from the board upward when it cannot resolve one.
• Standing advisor: A subject expert who attends when their area is on the agenda without holding a permanent vote, which keeps the voting body small.

Related Lessons

• GAO AI Accountability: Four Principles in Practice supplies the accountability standard your charter should be able to answer to.
• OMB M-24-10 Deep Dive: Full Implementation covers the federal governance obligations a board inherits.
• OMB M-24-18 and AI Procurement Governance handles the acquisition decisions that arrive at the board as approvals.
• NIST AI RMF: The GOVERN Function is the framework treatment of everything in this lesson.
• NIST AI RMF: Practical Implementation Workflows turns that function into the workflows a board consumes.
• Enterprise AI Risk Management builds the register that feeds the board's agenda.
• Risk Classification: Safety-Impacting vs. Rights-Impacting is the tiering decision your charter depends on.
• AI Use Case Inventory and Documentation (OMB M-24-10) details the inventory the board reviews quarterly.
• Oversight Mechanisms: IG, GAO, Congress explains who audits the board itself.
• Transparency: Citizens' Right to Know covers what publishing board decisions actually requires.

Closing

An AI governance board is the institutional mechanism through which an organisation keeps control of distributed AI development. Without one, teams make decisions locally with no organisational view. With one that is designed well, the organisation gets consistency, clear accountability and a place where tradeoffs are made deliberately rather than by default. It will not prevent every mistake, and any board that claims it will is setting itself up to be blamed for the first one.

The specific design matters less than the principles behind it: cross-functional representation, clear authority, risk-based decisions, documentation and executive sponsorship. Honour those and a small board works as well as a large federated structure. Start simple, learn, and evolve. The board that fits your agency today will need adjusting as AI adoption scales, and that is not failure. Brookhaven's second board was mostly the same twenty-two people, minus thirteen seats and plus a charter, and that was the whole difference between a font debate and a governing body.

Key Takeaways

• A board without a charter is just a meeting. Authority, scope, decision rights, cadence, escalation, accountability and transparency must be settled on paper before the first session, or projects will stall waiting on approvals the board does not know how to give.
• Keep it small and odd-numbered. Seven to eleven members is the working range; nine can decide where twenty-two can only react. Use standing advisors for expertise needed only occasionally.
• Pick members by perspective, not org chart. Mission, technical, compliance and legal, security and privacy, workforce and labour, and operations and finance all have to be present, plus a community voice where the public is affected.
• Members need seniority, defined roles and a survivable workload. Director level or equivalent, a written statement of what each represents and owns, roughly two to four hours a month, and staggered terms so memory carries across fiscal years.
• Match the model to the organisation. Centralized for smaller agencies with a handful of systems, hub-and-spoke for large agencies with distributed development, federated for networks of autonomous units. Each has a named weakness you must actively manage.
• State exactly what the board can decide, recommend and stop. A sponsor must know going in what a "yes" from the board is worth, and a board that cannot stop anything is not governing.
• Tie scrutiny to a risk tier assigned at intake. Low-impact tools go through a documented staff process and a quarterly report; high-impact and critical systems get legal review, independent audit and executive sign-off.
• The infrastructure is the inventory, the checklist and the escalation path. A monthly meeting without them produces decisions that cannot be compared, defended or remembered.
• Executive sponsorship is the precondition, not a bonus. If leadership will not back the board's decisions, do not create the board; an overridable board launders decisions rather than governing them.
• Publish decisions to earn trust. Recording and sharing the board's reasoning turns it from a black box into a visible public safeguard, and invisible governance loses trust even when it is working.

Frequently Asked Questions

Our agency is small. Do we really need a board?

You need the function, which may not require a standing body. A small agency with a handful of low-impact tools can meet the need with a defined approver, a short written standard and an inventory reviewed quarterly by existing leadership. What you cannot skip is the decision record and the named accountability, because those are what an auditor asks for and what a successor needs. Create the board when the count of systems or their impact makes single-person approval indefensible, which usually happens the first time a system touches the public.

What if leadership will not give the board real authority?

Then say so, in writing, before the board is created rather than after it has approved something. A board that is publicly presented as oversight while being privately overridable transfers blame to its members without transferring power to them, and it gives the agency a defence in an audit that the evidence will not support. The honest alternatives are to secure explicit executive sponsorship, or to run an advisory group that is named and described as advisory so nobody mistakes its output for a decision.

How do we stop the board becoming a bottleneck?

By deciding what never reaches it. The tiering table is the mechanism: low-impact work is documented and self-approved, moderate work is on the monthly agenda, and only high-impact and critical work gets the full treatment. Add a written fast track for urgent low-risk items so that urgency has a legitimate channel. Most bottleneck complaints trace to an absent trigger rule rather than to slow deliberation, because without one the board is looking at everything.

The board approved a system and it caused harm. Who is accountable?

Write the answer into the charter before it happens: the system owner is accountable for the system, and the board is accountable for the quality of its oversight. Those are different failures with different remedies. If the owner concealed a known problem, that is an owner failure. If the board approved without asking for evidence it should have demanded, that is an oversight failure, and the remedy is a change to the review checklist rather than to the owner. Splitting this in advance is what stops the post-incident argument from consuming the response.

How much of the board's work should be public?

As much as you can defend publishing, and the default should lean toward disclosure because the systems affect residents who did not choose them. Decisions and their reasoning are the core: what was approved, on what conditions, and why. Some material genuinely cannot be released, including security details and anything covered by a statutory exemption, but withholding should be a named decision with a stated basis rather than a habit. An agency that publishes only its approvals, and never its conditions or its refusals, will be read as marketing.