Policies say what is allowed. Committees decide cases. But neither works unless something upstream grants them authority — and that something is the program charter. It is deliberately short: one page that scopes what the governance program covers, names who is accountable, and establishes the escalation chain before any AI system reaches production. This article walks through the sections. Treat it as recommended practice to adapt with your legal and executive teams, not a compliance artifact in itself.
Why a charter, and why first
Every governance failure story has the same second act: a review body raised a concern, a product team disagreed, and nobody could say who wins. A charter answers that in advance. It is also the document that survives personnel change — when the founding CISO or sponsor leaves, the charter is what tells their successor what they inherited. Write it before the policy, before the committee's first meeting, because both derive their force from it.
The six sections
1. Mission and scope. Two sentences on why the program exists, then a precise scope statement: which systems (say, "any system that sends data to or acts on output from a large language model, on any platform"), which organizational units, and which environments. Be explicit that scope covers all routes to the models you use — first-party API, Claude Platform on AWS, Amazon Bedrock, Vertex AI, or Foundry — so platform choice can never be used to route around governance.
2. Authority. The load-bearing sentence. State what the program can do: approve or block launches, set mandatory review gates, require evidence, suspend a deployment that violates policy. State the source of that authority (the signing executive) and its limits.
3. Named owners. Roles and names, not just roles: the executive sponsor, the program owner who runs day-to-day governance, and the standing seats on the steering committee. Mirror the accountability in your platform's access model — on the Claude Console, for instance, organization membership carries one of five roles (user, claude_code_user, developer, billing, admin), and only members with the admin role can provision Admin API keys; the charter should say which named owner holds admin, so paper authority and technical authority point at the same people. See AI roles and responsibilities for fuller role definitions.
4. Decision rights and delegation. Which decisions the committee owns, which are delegated to the program owner or a fast-track reviewer, and the tie-breaker (usually the sponsor). A short table beats prose here.
5. Escalation chain. The path a concern travels: use-case owner → program owner → committee → sponsor, with expected response times at each hop, and an out-of-cycle trigger for incidents per the incident playbook.
6. Review clause. When the charter itself is revisited — annually is typical — and who can amend it.
Common failure modes
Authority without a sponsor's signature. An unsigned charter is a memo. Scope defined by tool names. "This charter covers our Bedrock usage" silently exempts the team that adopts Vertex AI next quarter; define scope by capability, then list current platforms in an appendix. Owners defined by committee. "The steering committee is accountable" means no one is; the committee decides, but a named person owns each decision's execution. No suspension power. If the program can delay launches but not stop a running system, it governs only the well-behaved.
From charter to working program
With the charter signed, the rest of the stack has ground to stand on: the use policy cites the charter's authority, the intake process implements its scope, and the inventory is the register of everything the charter claims jurisdiction over. Revisit the charter when scope genuinely changes — new business lines, new regulatory exposure — not for routine platform additions.
Where to go next
Continue with building the governance program for how the charter fits the other three building blocks, and approval gates for turning decision rights into a concrete launch process.