AI Governance Charter for Companies: Decision Rights and Review Dates

An AI governance charter for a company is a short written document, ideally one page, that lists which agent capabilities exist, who has authority to approve each one, what evidence that person needs before approving, and the date when the approval will be reviewed again. It turns general concern about AI into named decisions that an operations leader can defend. The rest of this guide explains how to write one without turning it into a policy binder.

Key takeaways

• Write decision rights for each capability, such as reading a folder, sending a message or changing a record, not for each tool or department.
• Name one accountable approver for every capability, plus a backup who can act when that person is unavailable.
• Attach a review date to every approval, and review higher-risk permissions more often than low-risk ones.
• Require evidence that the agent meets a written success criterion before any capability is approved or expanded.
• Keep the charter to one page and keep the detailed evidence in the systems where the agent actually runs.

What decision rights does the charter actually govern?

A decision right is the authority to say yes to a specific action taken by an agent. Many companies discover, a few weeks after a pilot starts, that the agent can already do more than anyone formally agreed to. Tools were connected for convenience, a shared folder was opened, or a channel was added during testing and never removed. The charter closes that gap by making each permission visible and owned.

The NIST AI Risk Management Framework describes AI risk work in terms of governing, mapping, measuring and managing risk, with roles and responsibilities made explicit. A one-page charter is the practical version of that idea for a small leadership team. It does not need to cover every model detail. It needs to answer who decides what the agent may do, and on what basis.

Separate three kinds of authority, because each one carries a different level of risk. The first is what the agent may read. The second is what it may write, send, or change. The third is what it may decide without a person checking the result. Reading an internal document is a low-stakes permission. Sending a message to a customer, issuing a refund, or changing a price is a high-stakes one, and it should never share an approval line with the first.

What belongs on the one page?

A useful charter has five blocks. Each block should fit in a few lines, so that a manager can read the whole document in a few minutes.

• Purpose: the single role the agent performs and the outcome it is judged on.
• Capability register: each permitted action, the tool or data source it touches, and the channel it uses.
• Approvers: the accountable owner for each capability, the named backup, and the conditions that require a second approver.
• Review dates: when each approval is reviewed, and which events force an early review.
• Stop conditions: who may suspend a capability immediately, and how they do it without waiting for a meeting.

The charter should point to evidence rather than contain it. Test results, interaction logs, and the record of past changes belong in the systems where the agent runs. The charter only states where that evidence is kept and who looks at it. Companies that already run an internal governance process for vendors or data can reuse that structure. For a lighter starting point, the guidance in AI Governance for Companies: A Lightweight Start for Mid-Sized Firms shows how to keep the first version short.

How do you name approvers without creating a bottleneck?

Assign approvers by capability, not by job title alone. A head of operations might approve read access to internal process notes. The head of customer support might approve drafting replies, and that same person plus a finance-facing approver might be required before any refund step is allowed. The question to ask for each capability is simple: who would be accountable if this action caused harm, and who understands the business consequence well enough to judge it?

The OWASP authorization guidance points toward a useful default: deny access unless it has been explicitly granted, and grant only the privileges a task requires. Applied to a charter, this means a capability that is not in the register is not allowed, even if the tool technically permits it. It also means a permission granted for one purpose does not quietly cover another.

To avoid a bottleneck, group low-stake capabilities under a standard approval that the owner can sign once for a defined set of actions. Reserve individual sign-off for capabilities that touch money, personal data, external commitments, or the agent's own configuration. Do not let the person who built or configured the agent be the only approver of its expansion. A second person should read the evidence, even if the review takes ten minutes.

How do you set review dates people will actually keep?

A review date without an owner is a wish. The charter needs a calendar entry, a named reviewer, and a checklist that makes the review fast. Use the following sequence the first time, then repeat it when the charter changes.

• List every capability the agent has today, including the ones granted informally during testing.
• Mark each capability as low, medium or high stake, based on what a mistake would touch.
• Assign one approver and one backup to each capability, and record the date of the decision.
• Set the review interval: longer for read-only work, shorter for anything that writes, sends or spends.
• Add event triggers that force an early review, such as a new tool, a new data source, a model change, or an incident.
• Place the review on a calendar owned by a named person, and keep the evidence next to the charter.

For most teams, a quarterly cycle works well for the full register, with a short check after any trigger event. The steps in Quarterly AI Agent Permission Review: Steps and Evidence show what to inspect during each cycle. When a capability needs to change, route the request through a written record so the approval history stays intact. The workflow in How to Request and Approve Changes to a Managed AI Agent describes one way to do that.

Illustrative scenario: a support agent asks for write access

The following scenario is illustrative and does not describe a real client. Imagine an internal agent that answers staff questions from a knowledge base and drafts replies for a support team. Under the charter, read access to the knowledge base was approved by the support lead, with a quarterly review. Later, the team asks for permission to change ticket status so the agent can close resolved requests.

Because this is a new write capability, it is not covered by the existing approval. The support lead remains the primary approver. The request is reviewed against a log of drafted replies that a human had to correct, which shows where the agent is reliable and where it is not. The approval is granted only for status changes on a defined category of tickets. Refunds stay outside the capability register, and any request to add them would need a finance-facing approver and a separate evidence review. The new capability gets a review date four weeks out, and the charter lists the ticket tool as a trigger, so any change to that tool forces a check before the agent continues.

Notice what the charter did in this case. It did not stop the team from improving the agent. It made the expansion visible, gave it an owner, and set the point at which someone would look again.

How does a managed approach keep the charter current?

In Be Human's managed model, the charter is written during the first engagement, when the company defines one useful role, the memory and tools that role needs, the approval boundaries, and an observable success criterion. After that, managed operations cover the parts of governance that decay over time: recurring permission review, integration maintenance, incident response, and controlled improvements routed through approvals. The client keeps approval authority over every capability. Be Human prepares the evidence, the change record, and the proposed review date so the decision can be made quickly and without guesswork. For teams wondering what the first months of that arrangement involve, What the First Months With a Managed AI Agent Look Like describes the typical sequence. If you are not yet sure which task should be the first one handed to an agent, the free Be Human AI diagnostic can help you find it.

Frequently asked questions

How long should an AI governance charter be? It should fit on one page, because a document that nobody reads offers no control. The page should name the role, the capabilities, the approvers, the review dates, and the stop conditions. Detailed test results and logs belong in the systems where they are generated and are referenced from the charter.

Who should sign the charter? The charter should be signed by the executive who owns the business outcome the agent supports, and by the person accountable for the systems the agent touches. Approvers for each capability should also sign or acknowledge their responsibilities. A signature without a named owner for each capability adds little, so the register matters more than the signature block.

How often should approvals be reviewed? Low-stake, read-only capabilities can be reviewed quarterly, while capabilities that write, send, or spend need shorter intervals. Any new tool, new data source, model change, or incident should trigger an early review regardless of the calendar. The right interval is the one the named reviewer can actually keep.

Does a governance charter replace legal or privacy review? No. The charter assigns internal decision rights, but it does not replace advice from counsel or a privacy specialist. If an agent processes personal data, Brazilian companies should check obligations under the LGPD and the guidance of the ANPD, and companies serving European users should consider the EU Artificial Intelligence Act. Those checks should be recorded as evidence attached to the relevant capability.

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