What belongs in a board-approved AI policy versus management-level AI procedures, standards, and runtime controls
A board-approved AI policy should state intent, risk appetite, accountability, prohibited use categories, decision rights, and reporting expectations. Content that changes with tools, models, and agent capabilities, such as approved-tool lists, permission rules, and approval workflows, belongs in management standards and procedures. Runtime controls enforce those rules, and audit evidence shows the board that they work.
Why policy and procedure get mixed together
Policy, standards, procedures, and technical controls all describe how an organization governs AI, so detail tends to drift into whichever document is being written. Approved-tool lists, permission rules, and approval workflows are common examples of operational detail that ends up in a board-level policy.
That detail changes with tools, models, and agent capabilities. A board document is meant to state durable intent and accountability. When it also carries fast-changing operating rules, the policy becomes harder to keep current and harder to read, and the rules it contains are not clearly tied to enforcement or evidence.
What the board-approved policy should contain
The board-approved policy should state the following, and little else:
- Intent: what the organization is trying to achieve and protect with AI.
- Risk appetite: the level of AI risk the organization is willing to accept.
- Accountability: who is answerable for AI use and its outcomes.
- Prohibited use categories: the kinds of AI use that are not allowed.
- Decision rights: who may approve, restrict, or stop AI use.
- Reporting expectations: what the board expects to be told, and how often.
Assigning content to a layer
Each layer has a distinct job. The board sets direction, management translates it into requirements and workflows, runtime controls enforce those requirements technically, and audit evidence shows the controls operate as intended.
- Board policyIntent, risk appetite, accountability, prohibited uses, reporting
- Management standardsMandatory requirements derived from the policy
- ProceduresOwned, repeatable workflows such as approvals and incident response
- Runtime controlsTechnical enforcement of identity, permissions, and tool access
- Audit evidenceRecords showing the controls operate as intended
| Layer | What belongs here | Examples |
|---|---|---|
| Board policy | Durable statements of direction and accountability | Intent, risk appetite, accountability, prohibited use categories, decision rights, reporting expectations |
| Management standards | Mandatory requirements derived from the policy | Approved-tool lists, permission rules |
| Procedures | Owned, repeatable workflows | Approval workflows, incident response |
| Runtime controls | Technical enforcement of the rules | Identity, permissions, tool access |
| Audit evidence | Records that controls operate as intended | Evidence the board report draws on |
A three-question test for placing content
When a statement is proposed for the board policy, ask these questions in order:
- Is it intent, risk appetite, accountability, a prohibited use category, a decision right, or a reporting expectation? If so, it belongs in the board-approved policy.
- Does it change with tools, models, or agent capabilities? If so, it belongs in a management standard or procedure, such as an approved-tool list, a permission rule, or an approval workflow.
- Can it be enforced technically and evidenced? If so, it should map to a runtime control, with audit evidence showing that the control operated.
Traceability check for each policy commitment
- The commitment is stated at the level of intent, not tool or configuration.
- A named executive owns it, and a named process owner runs the supporting procedure.
- At least one management standard cites the policy as its authority.
- The standard maps to a runtime control or a documented manual control.
- A defined evidence record shows the control operated, and the board report draws on it.
Why agents tighten the link between policy and enforcement
Autonomous AI agents act through identity, permissions, and tool access. Those are the areas where runtime controls apply, so a policy commitment about agent behavior is only as strong as the control that enforces it.
This makes the chain from policy to standard, procedure, runtime control, and audit evidence more important for agents. Standards and procedures that are documented but difficult to verify for AI agents leave the board without proof that its policy is being followed.
Connect policy intent to runtime enforcement
If your standards and procedures are documented but difficult to verify for AI agents, a technical discussion can help identify where enforcement and evidence are missing.
Talk to an Expert