AI Governance Charter Template: Owners, Approvals and Review Cadence

An AI governance charter is a short document that names who owns each AI agent, which actions the agent may take alone, which ones need a named person to approve them, and when the arrangement is reviewed. A one-page version is enough for most companies, and it should be revised whenever the agent gains a capability, a tool or access to new data. The template below lists the sections to complete and the decision each one forces.

Key takeaways

• Name one accountable owner for each agent, and a separate operator who maintains it.
• Write approval levels as specific actions, not general labels such as "sensitive" or "important".
• Tie review dates to two triggers: the calendar and any change in what the agent can do.
• Store the charter next to the agent's permission settings so the two cannot drift apart.
• Re-read the charter when a model, tool or data source changes, not only after something breaks.

Why a one-page charter works better than a policy binder

Most AI policies are written once, approved in a meeting and then forgotten by the people who run the agent. A charter is meant to be read by the person who must decide quickly. A practical test: someone outside the project should be able to read it in about ten minutes and answer three questions. What is this agent for? Who is responsible for it? What is it not allowed to do without asking first?

One page also forces trade-offs. If a rule does not fit, it is either too detailed for a charter and belongs in an operating procedure, or it has not been decided yet. Both outcomes are worth knowing before the agent goes live. For the wider context on where a charter sits among company AI decisions, the governance guide for mid-sized firms covers a lightweight starting point.

The six sections of the template

Copy these headings into one document and fill each with a short, specific answer. Leave a line blank rather than writing a general statement.

• Purpose: the business role the agent performs, the outcome it is meant to improve, and the work it does not do.
• Owners: the business owner who accepts results, the operator who maintains the agent, and the reviewer who belongs to neither team.
• Capabilities and boundaries: the tools, data sources and channels the agent can use today, and the ones it cannot reach.
• Approval levels: what the agent may do alone, what needs a named approver, and what it must never do.
• Review cadence: the scheduled reviews and the events that trigger an early review.
• Evidence and stop conditions: what is logged, where the log is kept, and the conditions under which the agent is paused.

The last two sections are the ones most often missing. Without them, a charter states intent but gives nobody a way to check that the agent kept to it.

Assign owners who can actually decide

Three roles do different work, and the charter should name a person for each. The business owner decides what the agent is for, accepts its results and settles disputes about scope. The operator keeps integrations, credentials and monitoring working, but should not be able to widen the agent's permissions alone. The reviewer checks permissions and incidents and has the authority to recommend a pause. When one person holds all three roles, the charter can still work for a small team, but the reviewer should be someone who did not build the agent, because that person is the check on the builder. The companion article on decision rights and review dates goes deeper on who decides what.

Set approval levels as actions, not categories

Words like "sensitive" or "high risk" do not tell an agent or its operator what to do. Write each level as a concrete type of action. A workable set looks like this:

• Read and summarize: the agent may retrieve and describe information from approved sources.
• Draft: the agent may prepare an output that a person reviews before anything leaves the team.
• Act with approval: the agent may take the action only after a named person approves that specific request.
• Act within limits: the agent may take the action alone, within a stated limit, and reports it afterwards.
• Never: the action is outside the agent's permissions, whatever the request says.

Illustrative scenario: a support agent drafts replies to refund questions at the draft level. It may issue a refund only within a fixed limit and only after a team lead approves the specific ticket, so that action sits under act with approval. Changes to the refund policy text fall under never, because the agent is not the author of the policy.

Record the level for each action in the same place the permissions are configured. A charter that says one thing while the system allows another is one of the most common gaps a review uncovers. The authorization guidance from OWASP makes the general point that access should be checked at each action, not only when a session begins.

Set review dates and triggers that follow capability

A calendar alone is not enough for agents whose capability changes. Use two kinds of review. The first is scheduled: a monthly operational review of logs, errors and incidents, and a quarterly permission review in which the reviewer confirms that every tool and data source is still needed. The second is triggered, and it should start a review rather than wait for the next calendar slot:

• A new model version is adopted, or the provider changes how the model behaves.
• A new tool, connector or data source is added to the agent.
• The agent is given a new channel, such as email, a customer portal or a messaging app.
• An incident occurs, including an output that was wrong and was caught by a person.
• A contract, regulation or internal policy changes a rule the agent must follow.

Capability growth should arrive as a change request, not as a quiet expansion of access. The request states what the agent will be able to do that it could not do before, who approved it, and what evidence will show that it works. The steps are described in how to request and approve changes to a managed AI agent. The NIST AI Risk Management Framework treats governance as an ongoing function across the life of a system, which is the right way to read a review cadence.

Write the stop conditions in plain terms. For example, the agent is paused when it repeats the same error, when it attempts an action marked never, or when the reviewer asks for a pause. Logging is what makes these conditions checkable. Recording the request, the tools called, the approver and the outcome is the basic practice that observability guidance, such as OpenTelemetry's primer on observability concepts, describes for software systems in general.

How Be Human runs the charter in a managed engagement

Be Human designs, implements and operates personalized AI infrastructure for companies, so the charter is not a document filed after launch. In a first engagement, the useful role, the memory and tools it needs, the approval boundaries and an observable success criterion are defined together, and the charter is written from those decisions. In managed operations, the same owners and review dates drive monitoring, recurring evaluations, permission review and incident response, and any change in capability passes through the approval path the charter describes. The goal is that the document and the running system stay the same.

Choosing the first agent to govern

Start with one agent, one role and one named owner, rather than a company-wide policy that covers tools nobody has deployed yet. Pick the role whose approval levels are easiest to write, because that makes the first review fast and gives the team a working example. Extend the template to a second agent only after the first has been through a full review cycle. If you are unsure which task should be the first one with a charter, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

How long should an AI governance charter be? One page is a good target, and a charter that needs a second page usually holds procedure that belongs in an operating document. The test is whether a new reviewer can read it once and know who decides, what the agent may do, and when it will be checked again.

Who should sign the charter? The business owner should sign because they accept the agent's results, and the reviewer should sign to confirm that the boundaries can be checked. The named roles matter more than the signatures, so when people change, the charter should be updated with the new names and the date of the change. Leadership sign-off is worth adding when the agent touches customers or payments.

How is a charter different from an AI policy? A policy states general principles that apply across the company, while a charter describes one agent, its owners, its permissions and its review dates. Many companies need both, with the policy setting the rules and each charter applying them to a specific agent. A charter can work alone for a single agent, but it becomes hard to reconcile when several agents share the same tools or data.

What should happen when an agent gets a new capability? The change should go through a written change request before it is enabled, not after. The request should say which new action becomes possible, who approved it, which approval level applies, and what evidence will show the change is working. After the change, the reviewer should update the charter and the permission settings together, so the document never describes a system that no longer exists.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.