Decision rights and change
AI Agent Governance Policy
Create a usable governance policy that names owners, limits authority, controls releases and expires exceptions. Includes adaptable policy clauses and a travel-advance example.
A governance policy is useful when someone can use it to decide whether a new tool may be connected, who may approve a release and what happens when the approved reviewer is unavailable. A document that only asks people to use AI responsibly leaves those decisions unresolved.
For an agent, governance must follow authority. A change from summarising a request to submitting it changes the organisation’s exposure, even if the interface looks identical. This guide provides an original policy structure for business and technology owners to adapt. It is not a claim that Open for AI or a regulator has approved your particular workflow.
Give the policy an operating home
Record a policy identifier, version, effective date, owner, approving authority, next review date and the services it covers. Connect it to existing security, privacy, procurement and incident policies instead of copying them into an agent-specific document. Name which policy controls if requirements conflict and how a conflict is escalated.
The NIST AI RMF Playbook’s Govern function provides voluntary guidance on organisational policies, responsibilities and risk management. Use such guidance as a reference, while establishing your own decisions for the actual service. A framework citation is not an implementation record or a certification.
Our illustrative service prepares employee travel-advance requests from an approved travel policy and an authenticated employee request. It can identify missing fields, calculate a proposal using approved rules and prepare a submission for review. It does not change payroll, release funds or decide employee eligibility outside the agreed rules. This case gives the policy a concrete subject without prescribing a universal travel process.
Clause 1: every service has accountable owners
Adaptable policy clause: Every deployed agent service must have a named business owner and technical owner, a documented purpose, supported users, approved information sources, permitted actions and an operational support arrangement. A service without a current accountable owner must not gain new users or authority until ownership is restored.
The business owner decides what outcome is wanted and which residual operational risks are acceptable within their authority. The technical owner is responsible for implementation and service integrity. Privacy and security reviewers make the decisions assigned to them by existing policies. The people who build the agent should not silently acquire authority to accept every business or regulatory risk.
| Decision | Accountable role | Evidence expected |
|---|---|---|
| Supported request types and financial limits | Finance operations owner | Approved workflow and rule version |
| Identity and tool permissions | Application security owner | Access design and negative tests |
| Personal-data purposes and retention | Authorised privacy decision owner | Processing review and retention schedule |
| Technical release readiness | Service engineering owner | Evaluation, recovery and monitoring evidence |
| Production use within approved limits | Designated release authority | Recorded decision and unresolved limitations |
One person may hold more than one role in a smaller organisation, but make the combination explicit. For material decisions, arrange an appropriate independent review rather than giving a builder an unrecorded self-approval. The team-structure guide helps assign responsibilities without inventing unnecessary headcount.
Clause 2: authority is registered, limited and enforceable
Adaptable policy clause: The service may use only registered sources and tools for the approved purpose. Each operation must have an authority level and enforcement mechanism. Conversation content, retrieved material and model output must not grant permissions, change policy or add a recipient.
For this service, define four practical states: read approved policy; draft a request; submit a specifically approved request through an authorised interface; and prohibited operations. The final category includes fund release and payroll changes in this example. These are local design categories, not a universal regulatory classification.
Store the operation name, permitted users, target system, preconditions, required approval, maximum scope and fallback. A control written only in a policy is insufficient if a broad credential still permits more. Connect the register to the security architecture and test that prohibited actions are unavailable or rejected.
Clause 3: releases require task-specific evidence
Adaptable policy clause: A production release must identify its model, instructions, tools, source versions and configuration. Approval must reference evidence for the supported tasks, foreseeable exceptions, access boundaries and recovery arrangements. Unresolved limitations must have an owner and an explicit operating decision.
A single accuracy percentage is not a release policy. The travel assistant may need separate evidence for amount calculation, source applicability, missing approvals, Arabic and English interpretation, duplicate submissions and stale requests. Severe authority failures should remain visible even if the overall task average is high.
Set acceptance criteria before the final test. Record denominators, severity definitions, reviewer disagreements and unsupported cases. Distinguish exploratory demonstrations from a held-out assessment. The testing and evaluation guide supplies a method for constructing that evidence; the policy assigns who may act on it.
Clause 4: material changes return to the right reviewer
Adaptable policy clause: Changes to purpose, users, data categories, recipients, permitted actions or material dependencies must be assessed before release. The change owner must identify affected controls and obtain the required approvals. A change must not be classified as minor solely because it is implemented through configuration or prompt text.
Suppose the travel policy introduces a new currency rule. Updating a paragraph can change the proposed amount, so finance needs to approve the authoritative rule and the regression cases. Suppose instead the model endpoint moves to a different processing region: the visible answer may remain the same, but the data-flow review changes. Use the residency assessment for that decision.
Maintain a change record containing the request, reason, affected service version, evidence, approvers and release time. Routine changes can follow a proportionate predefined path; they do not all require a large committee. The point is to route the decision to the person who owns the changed risk.
Clause 5: exceptions are narrow and expire
Adaptable policy clause: An exception must state the requirement affected, business reason, bounded scope, compensating measures, accountable approver, expiry and closure condition. Exceptions must not waive applicable law. The service owner must review them before expiry and verify that temporary access or behaviour is removed when the exception ends.
Consider a missing approver during a travel peak. The policy should identify a formally authorised deputy or a manual route. It should not convert silence into approval. Similarly, if an integration cannot support a required approval field, a temporary response can be to keep submission manual while the agent prepares a draft. Granting broad write access is not a necessary consequence of urgency.
Track exceptions separately from defects and feature requests. A defect needs repair; a new capability needs scope; an exception permits a specifically bounded departure that someone has authority to approve. Repeated extensions are evidence that the permanent design or business process needs attention.
Clause 6: oversight must have capacity and a fallback
Adaptable policy clause: Required human review must be performed by a qualified authorised person with access to the relevant evidence and time to assess it. When review is unavailable or overdue, the service must follow its documented hold, expiry or manual-escalation behaviour. It must not treat an unattended queue as approval.
For the travel assistant, show the applicable rule, calculation inputs, proposed amount and any missing evidence. Preserve the employee’s ability to correct a misunderstood request through an established channel. Review the demand on approvers before expanding the workload. The human-oversight model develops the queue, approval and escalation design in detail.
Clause 7: incidents and disagreements have owners
Adaptable policy clause: The service must have a documented route for reporting suspected unauthorised actions, data exposure, materially incorrect outputs and repeated operational failures. Authorised responders may suspend affected capabilities. Business, security and privacy owners determine recovery and any required notifications under their existing responsibilities.
Do not wait for the model to classify an event as serious. An employee who sees another person’s request or an unexplained amount change needs a direct reporting route. Record what happened, the affected release and the containment decision. Keep evidence proportionate and accessible to the authorised investigation team.
Distinguish a disputed business rule from a technical failure. If two departments interpret a travel allowance differently, the policy owner resolves the rule and the agent’s source is updated afterwards. Engineering should not settle the dispute by choosing whichever answer is easiest to automate.
Clause 8: every service can be reviewed and retired
Adaptable policy clause: The service owner must periodically review continued need, accepted outcomes, review burden, incidents, costs, dependencies and outstanding exceptions. Retirement must include user communication, authority removal, data handling, credential revocation and transfer of any continuing business responsibility.
Use event-driven reviews as well as scheduled ones: a changed law, new data source, material incident, supplier retirement or ownership change can require earlier attention. Keep the policy review proportionate to the service. A bounded drafting assistant and a tool that changes operational records need different evidence and scrutiny.
A retirement record should confirm that scheduled workers and service accounts have stopped, not just that the interface has disappeared. Preserve the necessary business records under the applicable retention rules and dispose of temporary stores appropriately. The audit-trail design helps distinguish what must remain reviewable from content that no longer needs to be retained.
Adopt the policy through one real decision
Before issuing the document broadly, walk one proposed change through it. Can the team identify the owner, authority category, evidence, approvers, exception route and release record without improvising? If not, revise the policy or the operating process. A short policy that works in a concrete case is more useful than an extensive document that nobody can execute.
Open for AI’s governance setup and agent development can be scoped together around these decisions. Bring one agent use case and your existing approval structure to define a policy that connects authority, evidence and accountable operation.