This article explains what a governance policy should cover, who should own it, and how it becomes operational. It is an explanatory design guide, not a complete copy-and-adapt policy asset.
What is an AI governance policy?
A governance policy sits within the wider AI governance framework. While the framework defines the operating model, the policy records the approved rules and decision rights that apply to AI use. It answers: what is in scope, who is accountable, what must be done before a use is approved, and how the organisation will monitor and review.
The NIST AI RMF Core supports documented requirements, risk tolerance, defined roles and executive accountability. These are outcomes the policy should address, but meeting them does not by itself prove compliance or effectiveness.
A governance policy is distinct from an organisation-wide AI policy (which may include operational clauses) and from an acceptable-use policy (which sets day-to-day user rules). The governance policy is the top-level mandate.
AI governance framework versus AI governance policy
The framework is the structure; the policy is the rule set within that structure.
| Aspect | Framework | Policy |
|---|---|---|
| Purpose | Define the operating model | Record approved rules and decision rights |
| Audience | Governance leaders, board | All staff, use-case owners, approvers |
| Content | Roles, processes, artefacts, review cycles | Scope, requirements, approval paths, exceptions |
| Changes when | The operating model, roles or lifecycle changes | Approved rules, thresholds or evidence requirements change |
| Evidence | Framework review, maturity assessment | Policy acknowledgement, decision and control records |
The UK Government AI Playbook supports named ownership, governance expertise, a live inventory, lifecycle assessment and change control. It was published in February 2025 for government organisations; private organisations may adapt its patterns.
If these foundations are not yet settled, design the wider AI governance framework before asking a policy document to carry decisions the organisation has not made.
Decisions to make before writing the policy
Before drafting, an organisation should resolve:
- What is in scope: all AI, specific categories, or only certain risk levels?
- Who is accountable: a single executive, a committee, or distributed ownership?
- What approval authority exists: who can approve each locally defined risk band?
- What risk model applies: qualitative tiers, quantitative scores, or a hybrid?
- What data categories are relevant: personal data, confidential business information, regulated data?
- What provider requirements apply: security, privacy, contractual, assurance?
- What human oversight is required: review, approval, or both?
- What legal or contractual duties exist in the organisation's jurisdictions?
- What incident path applies: who is notified, what is the response timeline?
- What review triggers exist: material change, periodic review, incident-driven?
These decisions are organisation-specific. No universal answer exists, and the policy must reflect local context.
Capture the answers in a short decision note before drafting prose. For each choice, record the decision owner, the reason, any source requirement and what would trigger reconsideration. This avoids a familiar failure mode: a polished policy goes for approval while unresolved questions remain hidden inside vague phrases such as “appropriate review” or “authorised use”.
What an AI governance policy should contain
The following architecture is an editorial synthesis requiring adaptation. Each section records a decision or rule, assigns an accountable owner, identifies the supporting procedure or record, and defines a review trigger.
| Section | Decision or rule | Accountable owner | Supporting procedure or record | Review trigger |
|---|---|---|---|---|
| Purpose and scope | Which AI uses are governed | Executive sponsor | Scope statement | Material change in AI use or regulation |
| Definitions | Key terms used consistently | Policy owner | Glossary | New terms introduced |
| Accountability | Who owns decisions at each level | Executive sponsor | RACI or role matrix | Organisational change |
| Risk tiers and criteria | How uses are classified | Risk owner | Tier definitions | New risk categories identified |
| Approval paths | Who approves at each tier | Defined authority | Approval workflow, records | Change in approval authority |
| Data and information | Classification, minimisation, handling | Data owner, privacy lead | Data classification policy | New data categories |
| Provider requirements | Security, privacy, contract terms | Procurement, security | Vendor assessment, contract | Provider change, new provider |
| Human oversight | Review, verification, disclosure | Use-case owner | Oversight procedure | Change in use or model |
| Records and evidence | What must be documented | Governance coordinator | Record-keeping procedure | Audit finding, incident |
| Incidents | Detection, response, review | Incident lead | Incident procedure | New incident type |
| Exceptions | How and when exceptions are granted | Defined authority | Exception register | Exception expiry |
| Training and awareness | What staff must know | HR, policy owner | Training records | Policy update |
| Review and improvement | How the policy is kept current | Policy owner | Review schedule, change log | Periodic, incident, regulatory change |
The NIST AI RMF Playbook provides suggested implementation actions and documentation for RMF outcomes. It is a living, voluntary resource; organisations need not implement every suggestion.
The architecture should also expose the chain from rule to operation. If the policy says that new AI uses require approval, a supporting procedure should explain how to request it, an assessment should provide the decision evidence, and an approval record should capture the authority, conditions and review triggers. None of those records shows on its own that a control continued to work after launch.
Organisations that need the full umbrella document can use the copy-and-adapt AI policy template after these governance choices have been approved.
Roles, approval authority and escalation
The policy should name or define the roles that make decisions. Depending on organisation size:
- A small organisation may have a single accountable executive who also serves as the approval authority for most uses.
- A medium organisation may have a governance coordinator, use-case owners, and a defined approval panel.
- A larger organisation may have a board-level sponsor, a governance committee, and tiered approval authorities.
The ICO's AI governance and accountability audit toolkit supports senior sign-off, clear roles, steering options, action tracking, reassessment on change, risk-register integration, procurement involvement and risk-based audit and change management. These are audit expectations focused on data protection; not every item is a freestanding statutory duty.
Escalation paths should be explicit: what happens when a use-case owner disagrees with an approval decision, when a new risk category emerges, or when an incident reveals a policy gap.
Keep three roles visible even when one person holds more than one of them. The accountable owner answers for the policy as a whole. The policy owner maintains the document and coordinates review. The authorised decision-maker accepts, conditions or rejects a particular use. Naming the hat being worn prevents routine administration from quietly becoming risk acceptance.
Escalation should lead to a decision, not simply another meeting. State who may pause a use, who resolves a disagreement, which specialists must be consulted and how the outcome is recorded. In a small organisation this can be a short named route; it does not require a new committee.
Risk tiers, lifecycle gates and exceptions
The policy should define how its locally chosen risk levels map to approval requirements. An illustrative pattern is:
- Lower-impact band: a defined delegate may decide using a shorter evidence set.
- Intermediate band: a fuller assessment and an independent or specialist review may be required.
- Higher-impact band: a senior authority decides after the organisation's specified specialist reviews and evidence requirements are complete.
These are example bands, not universal thresholds or names. The policy must define which factors move a use between them, what evidence each path needs and who holds the matching authority.
Lifecycle gates are points where the policy requires a specific action before proceeding: initial assessment, pre-deployment review, post-deployment monitoring, periodic reassessment, and change-triggered review.
The assessment should record inherent risk before proposed controls and residual risk after the selected controls and their evidence have been considered. A completed form or a low label is not automatic approval. To keep that decision record separate from the policy itself, assess a defined AI use case using the organisation's own criteria and acceptance authority.
Exceptions should be time-limited, documented with justification, and subject to review. The NIST Govern Playbook suggests inventory fields including purpose, use, risks, data, ownership, scope, maintenance and review. These are suggestions, not a statutory schema.
Records, monitoring and incident response
The policy should require records for:
- Each AI system or use case in the inventory.
- Each risk assessment and approval decision.
- Each control implementation and test.
- Each incident and its resolution.
- Each exception and its review.
- Each policy review and update.
Monitoring should track whether controls are operating, whether outcomes are on track, and whether new risks are emerging. The DSIT Introduction to AI Assurance distinguishes assessment, audit, conformity assessment and verification as distinct assurance techniques. It was published in February 2024 and is guidance, not law.
Choose evidence that answers the policy's actual question. A tool register can show what has been recorded. An approval log can show what was decided. A control test can show how a safeguard behaved under defined conditions. Outcome monitoring can reveal performance changes or emerging impacts. Combining all four into one “compliant” status would hide the distinction the reviewer needs.
Incident response should be defined in the policy: who is notified, what is the response timeline, what evidence is retained, and what triggers a policy review.
How to implement and review the policy
Implementation is not a one-time event. The policy becomes operational through:
- Communication: all relevant staff are informed of the policy and their responsibilities.
- Training: role-specific training covers the rules that apply to each function.
- Procedures: supporting procedures translate policy rules into day-to-day actions.
- Evidence: records show what was done under the policy and support testing of specific controls.
- Review: control tests, monitoring and event-triggered reassessment show what needs to change.
Assign an owner and a completion test to each step. “Training delivered” might require a defined audience, relevant material and completion records. “Procedure implemented” might require a team to run one real request through it and retain the resulting decision record. The completion test should match the rule; volume alone does not show that the rule is understood or effective.
The ICO's guidance on when a DPIA is needed clarifies that a DPIA is required when processing is likely to result in high risk to people's rights and freedoms. It is not required merely because a system is called AI, and it is not a substitute for broader risk assessment. ICO guidance is under review.
Review triggers should include: periodic review (at a locally defined interval), material change in AI use, regulatory change, incident, audit finding, or new risk category.
Document inputs and evidence within governed AI use
The policy may require that documents entering an AI workflow have been classified, authorised and minimised. Teams should connect AI rules to the data classification policy so that a user can tell which information is allowed in which approved service. The policy may also require a document-level checkpoint as one control within the approved process.
.mdSiren is a document security workspace for AI, coming soon. Its Standard Scan will check the exact document version before AI use, route that version to Approved, Needs review or Quarantine, and keep Approved versions in a private Library for dependable reuse. The product does not author, approve, manage or enforce an organisation's policy; assign a risk tier; grant organisational approval; supply a complete governance or audit record; or prove compliance.
Before relying on that checkpoint, review current security scope and disclosures against the organisation's own provider and workflow requirements.
Frequently asked questions
What is an AI governance policy?
It is the approved document that sets scope, accountability, decision rights and minimum requirements for AI across its lifecycle. It sits within the wider governance framework and is one component of the overall system.
Is it the same as an AI policy?
The terms are sometimes used interchangeably, but in this cluster's usage, the governance policy is the top-level mandate and decision-rights document, while the AI policy (or umbrella policy) is the broader organisation-wide document that may include operational clauses. The governance policy is narrower and more strategic.
Who should own the policy?
The policy should have a named accountable owner, often an executive or senior leader with authority over its scope. Day-to-day maintenance may be delegated to a governance coordinator or policy owner. The accountable owner oversees implementation and review; control and use-case owners still remain responsible for their own defined work.
What should the approval process cover?
The approval process should cover: who can approve each locally defined risk band, what evidence is required for approval, what conditions may be attached, how exceptions are handled, and what triggers a re-approval. The specific thresholds and authorities are organisation-specific.
How often should an AI governance policy be reviewed?
There is no universal review cadence. The policy should define its own review triggers: periodic review at a locally defined interval, plus event-driven reviews triggered by material change, incident, regulatory change, or audit finding. The interval should reflect the pace of change in the organisation's AI use and the regulatory environment.
