AI Architecture Review Board Charter: A Template You Can Adapt
A review board without a charter reviews whatever arrives, at whatever speed it can manage. A one-page charter fixes its scope, its decision rights and the turnaround it owes delivery teams.
By Enterprise AI Architects · · 10 min read
An AI architecture review board charter is a short document that states why the board exists, which AI designs must come to it, who sits on it, what it can decide and how fast it must respond. It is what stops a review board from becoming either a rubber stamp or a queue. This guide explains each section of the charter and then gives a template you can copy and adapt.
What the charter is for
A review board without a charter drifts. It starts reviewing every proposal because nobody said what it could skip. Meetings grow, turnaround slips and delivery teams learn to route around it.
A charter prevents that by answering five questions in writing:
- What is the board for?
- What must come to it, and what must not?
- Who decides, and what happens when they disagree?
- What does a team have to submit?
- How long will the board take?
The charter is also evidence. An organization that follows NIST AI RMF 1.0 or runs an AI management system under ISO/IEC 42001:2023 needs to show defined roles, responsibilities and review processes for AI. A charter, a decision log and the minutes behind them are a direct way to show it.
Where the board sits
Most enterprises end up with two bodies, and the charter should say how they relate.
| Body | Decides | Answers to |
|---|---|---|
| AI governance committee or council | Policy, risk appetite, risk tiers, prohibited uses | Executive leadership |
| AI architecture review board | Whether a specific design meets the standards and may proceed | The governance committee and the head of architecture |
| Delivery team | How to build within approved patterns | The business owner of the use case |
The governance committee writes the rules. The architecture review board applies them to real designs. If your organization is small enough for one group to do both, keep the two sets of decisions separate on the agenda. Our guide to an AI governance framework covers the policy and tiering side, and the AI center of excellence guide covers where the board fits in the operating model.
An existing enterprise architecture review board can take on AI work. It needs added members for model risk and AI security, and the AI-specific triggers and submission items described below.
The ten sections of a charter
A complete charter has ten sections. Each one is a few sentences long.
1. Purpose
State the purpose as outcomes. A useful version has three: prevent unsafe or wasteful AI designs from reaching production, keep the AI estate consistent with the reference architecture, and convert approved designs into patterns that others reuse without review.
The third outcome is the one most charters leave out. It is what makes the board’s workload fall over time.
2. Scope and triggers
This section does the most work. List the conditions that bring a design to the board, and state that anything else follows the standard path with no board review.
| Trigger | Why it comes to the board |
|---|---|
| The use case is in the high risk tier | Consequences for people, money or regulated records |
| The design departs from a published pattern | A new pattern may be needed, or the departure may be a mistake |
| A new model provider, vector store or orchestration framework enters the estate | Every new component adds cost, security surface and skills to maintain |
| An agent can write to a system of record | Actions are harder to reverse than answers |
| Sensitive or regulated data is sent to a new destination | Data residency, contractual and privacy obligations |
| A significant change to the shared AI platform | Every workload on the platform inherits the change |
Also list what is out of scope: low-tier internal productivity uses on approved tools, moderate-tier systems built entirely on approved patterns, and routine prompt or configuration changes that pass the evaluation suite. Those go to a delegated reviewer or to automatic approval.
3. Membership and roles
Keep the standing membership to five to seven people. Each seat is a role, with a named deputy who can vote.
| Role | Responsibility on the board |
|---|---|
| Chair (enterprise AI architect or head of architecture) | Sets the agenda, runs the meeting, makes the final call when the board cannot agree |
| AI platform owner | Judges fit with the shared platform and its roadmap |
| Security architect | Reviews the threat model, identity, data flows and tool access |
| Data architect or data owner | Reviews data sources, quality, lineage and entitlements |
| Risk and compliance lead | Confirms the tier and the controls that the tier requires |
| Secretary | Checks submissions for completeness, records decisions, tracks conditions |
| Called as needed: privacy, legal, model risk, procurement, the business owner | Advise on the submissions that concern them |
Set a quorum, for example the chair or deputy plus three standing members, including security.
4. Decision rights
Say exactly what the board can decide. Typical rights: approve or reject a design within its scope, attach binding conditions, grant time-limited exceptions to a standard, publish or retire a pattern, and adjust a provisional risk tier upward.
Say what it cannot decide. Funding, business priority and risk appetite belong elsewhere. A board that argues about whether a use case is worth doing has left its lane. That question is settled earlier, in use case prioritization.
State the decision rule. Consensus with the chair deciding when consensus fails is the common choice. Give security and risk the right to escalate a decision they disagree with, not a silent veto.
5. The submission pack
Ask for one short design document in a standard template, plus evidence generated from the platform where possible. A team should be able to complete the pack in a day if the design work is done.
- The business purpose, the owner and the risk tier from intake.
- An architecture diagram and the data flows, including every external destination.
- The models, providers and hosting, and why they were chosen.
- Options considered and the reasons for the one proposed.
- The departures from published patterns, if any.
- The threat model and the controls that answer it.
- The evaluation plan, thresholds and the results so far.
- Human oversight: which actions need approval and how the system is stopped.
- Monitoring, logging, cost estimate and the run owner after launch.
For agents, add the tool list with read or write marked for each, the agent’s identity and the limits it runs under. Our guide to AI agent governance covers those items in detail, and the AI agent registry template lists the fields to collect.
6. Outcomes
Limit the possible outcomes to four so that every submission ends in a clear state.
- Approved. Proceed as designed.
- Approved with conditions. Proceed, with named conditions, an owner and a date for each.
- Returned. The pack is incomplete or a specific question is open. Resubmit without restarting the clock from zero.
- Declined. The design may not proceed. The board states why and what would change the answer.
7. Cadence and service levels
Publish the turnaround you commit to, and measure it. Teams plan around numbers, not intentions. The figures below are a starting point to adjust, not a standard.
| Path | Who reviews | Example target |
|---|---|---|
| Automatic | Nobody. Registration only, on approved tools and patterns | Same day |
| Delegated | One named reviewer, asynchronously | 3 working days |
| Full board | The board, in its weekly slot | 10 working days from a complete pack |
| Expedited | Chair plus security, for urgent production fixes | 2 working days, ratified at the next meeting |
Hold a fixed weekly slot. Circulate packs a set number of days ahead so that members arrive having read them.
8. Exceptions and appeals
A standard with no exception path gets ignored. Allow exceptions that are time-limited, carry a named owner and state the compensating controls. Record each one and review it at expiry. A standard that collects many exceptions needs rewriting.
Give teams one route of appeal, normally to the governance committee or the CIO, with a deadline for the answer.
9. Records
Every decision goes into an architecture decision log that anyone in the technology organization can search. Each entry records the context, the options, the decision, the conditions and the date. The log is how new teams learn what has already been decided, and it is the audit trail.
Keep the pattern library next to it. When the board approves a design that others will repeat, the approval and the pattern are published together.
10. Measures and review of the charter
The board should measure itself on a small set of numbers and report them quarterly.
- Median and worst-case turnaround on each path
- Share of submissions resolved without the full board
- Number of patterns published, and how often each is reused
- Open exceptions and overdue conditions
- Production incidents traced to a design the board approved, or to one that bypassed it
Review the charter itself at least once a year, and sooner if the queue is growing.
A charter template
Copy the text below and replace the bracketed parts. Keep it to two pages.
1. Purpose. The [Organization] AI Architecture Review Board exists to (a) prevent unsafe, duplicative or untestable AI designs from reaching production, (b) keep AI systems consistent with the enterprise AI reference architecture and (c) publish approved designs as patterns that teams may reuse without further review.
2. Authority. The board is established by [executive sponsor] and reports to [AI governance committee]. It applies the AI policy and risk tiers set by that committee.
3. Scope. A design must be submitted when any of the following is true: [list triggers]. All other AI work follows the standard path and requires registration only. The list of triggers is published at [location].
4. Membership. Standing members are [roles]. Each has a named deputy. The chair is [role]. Advisers from [privacy, legal, model risk, procurement] attend when called. Quorum is [number], including the chair or deputy and the security member.
5. Decision rights. The board may approve, approve with conditions, return or decline a submitted design; grant time-limited exceptions to architecture standards; publish and retire patterns; and raise a provisional risk tier. It does not decide funding, business priority or risk appetite.
6. Decision rule. Decisions are made by consensus. Where consensus is not reached, the chair decides and records the dissent. Security and risk members may escalate a decision to [governance committee] within [number] working days.
7. Submission. Teams submit the standard design document and evidence listed at [location] at least [number] working days before the meeting. The secretary confirms completeness within [number] working days.
8. Cadence and service levels. The board meets [weekly, day and time]. Target turnaround: delegated review [number] working days; full board [number] working days from a complete pack; expedited review [number] working days.
9. Exceptions and appeals. Exceptions state an owner, compensating controls and an expiry date of no more than [number] months. Appeals go to [body] and are answered within [number] working days.
10. Records. Decisions, conditions and exceptions are recorded in the architecture decision log at [location]. Approved patterns are published at [location].
11. Measures. The board reports [measures] to [governance committee] each quarter.
12. Review. This charter is reviewed every [12] months by [owner]. Version [number], approved [date].
Common ways a review board fails
The same five failures show up across organizations, and each one traces back to a missing line in the charter.
- It reviews everything. No triggers were written down, so every proposal arrives. Fix the scope section.
- It reviews too late. Teams come a week before launch with the system already built. Tie submission to the design stage, and connect it to the release gates described in our guide to moving from AI pilot to production.
- It reviews documents, not evidence. A design that reads well can still fail its evaluations. Ask for results.
- It has no service level. With no clock, urgent work bypasses the board and the bypass becomes normal.
- It never publishes patterns. The same design is approved a fifth time. If a design has been approved three times, publish it and stop reviewing it.
The first 90 days
A board can be running in a quarter.
- Weeks 1-2. Name the sponsor and the chair. Draft the charter from the template. Agree the triggers with the governance committee.
- Weeks 3-4. Publish the design document template and the decision log. Appoint members and deputies.
- Weeks 5-8. Run the first reviews on work already in flight. Expect to adjust the triggers after the first few.
- Weeks 9-12. Publish the first two or three patterns from what was approved. Report the first turnaround figures and revise the charter once.
Patterns need something to anchor to. If there is no agreed target design yet, start with an enterprise AI reference architecture, then let the board maintain it.
How we help
We set up architecture review boards as part of an AI operating model: the charter, the triggers, the design template, the decision log and the first set of pre-approved patterns, tied to your AI governance and risk tiers. Our architects can also sit on the board while your own team takes it over. To put a working review process in place before the next wave of AI projects, talk to an architect.
