PRACTICAL GOVERNANCE GUIDES
AI governance policy template
A free, editable starting draft for a small team defining how AI use is reviewed, approved and maintained.
Download the editable Markdown policy ↓Original editorial guidance by AI Gov Library · Reviewed 7 October 2026.
Original draft · Version 1.0 · Free to copy and adapt within your organization. Replace bracketed fields and obtain the relevant internal reviews before adoption. This is research support, not legal advice or a compliance certificate.
Download the editable Markdown policy ↓Free AI governance policy draft
You can read and copy the complete draft below. The Markdown download contains the same policy record, clauses and adoption checklist. Start by naming an owner and approving authority; then replace the placeholders with decisions your team can actually follow.
Policy record
Organization: [name]
Policy owner: [role]
Approving authority: [role or body]
Version and effective date: [version / date]
Next review: [date]
Related policies: [security / privacy / procurement / records / other]
1. Purpose and scope
[Organization] uses this policy to assign responsibility for AI use and to require documented review before approval. It applies to [staff, contractors and teams] using, buying or developing [defined AI systems and services], including [AI features in existing products]. Exclusions are [list with reasons and an owner].
2. Roles and authority
The policy owner maintains this policy and coordinates reviews. Each AI use case has a named service owner. [Review roles] evaluate issues within their responsibilities. [Approving authority] records the permitted scope and conditions. Unresolved matters go to [escalation role or body]. Users report concerns through [channel].
3. Intake and review
Before a new pilot, purchase or material change, the service owner records the purpose, intended users, affected people, data, supplier, likely impacts and proposed safeguards. The reviewer records the review route, evidence required and specialist involvement. No pilot or operational deployment starts until [authority] has approved its specific scope and conditions. A pilot approval does not automatically authorize wider deployment.
4. Permitted and restricted uses
Approved uses are recorded in [register] with conditions. Staff use only [approved tools and configurations] for [specified data and tasks]. Restricted or prohibited uses are [list decided by the organization]. Exceptions require [approval route], a documented reason, safeguards and an expiry or review date.
5. Supplier and data review
Before approval, [roles] review supplier evidence relevant to the use, data access and reuse, retention, dependencies, performance, security, support and exit arrangements. Unknowns are recorded with an owner. Material unresolved concerns are escalated before the buying or deployment decision.
6. Human oversight and evaluation
The owner defines representative evaluation tasks, important failure cases and acceptance criteria. [Role] reviews the results. Human review, override and stop arrangements are documented for the approved use. Changes to autonomy or affected users require a new review. Testing and review records are retained according to [records policy].
7. Inventory and decision records
[Inventory owner] maintains records of approved systems and pilots: identifier, purpose, owner, supplier or model, data categories, approved scope, decision, conditions, evidence references and next review. Access is limited according to [access policy]. Retention follows [records schedule].
8. Monitoring, incidents and change
The owner monitors [defined performance and risk indicators] at [cadence]. Staff report unexpected behavior or suspected incidents through [channel]. [Role] can restrict or pause use and coordinates the relevant incident process. Review is triggered by [material supplier or model changes, changed data or purpose, incidents, renewal and other specified events].
9. Training and policy maintenance
[Role] provides task-appropriate guidance and training before use. The policy owner reviews this policy at [cadence] and after relevant organizational or external changes, consulting specialist owners as needed. Revisions are approved by [authority] and communicated to [audience].
Adoption checklist
- Replace all bracketed fields and resolve exclusions.
- Confirm owners, authority, exceptions and reporting routes.
- Review against applicable obligations and existing internal policies.
- Test the intake, decision and incident routes with one realistic case.
- Record approval, communicate the policy and schedule review.
How to adapt this policy
- Define your scope. Include AI features in existing products if they fall within your team’s responsibility. Explain exclusions rather than leaving them implicit.
- Assign real roles. Replace generic reviewers with people or functions who can perform the work. Use existing security, privacy and incident processes where they already cover the task.
- Set rules you can operate. Decide approved tools, data restrictions, exception handling and what a pilot approval permits. Do not leave these as unowned aspirations.
- Test the route. Use one intake case, request supplier evidence if needed, and record an approval with conditions. Check whether a colleague can find the approver and reporting channel.
- Approve and maintain it. Resolve every placeholder, obtain specialist review of applicable obligations, record approval and schedule the next review. Link policy decisions to your inventory.
Filled example: an internal support assistant pilot
| Policy field | Example decision |
|---|---|
| Scope | Draft replies for internal support staff; no automatic sending and no approval for other teams. |
| Service owner | Support lead owns the pilot and its evaluation record. |
| Review roles | Security and privacy reviewers inspect the proposed configuration and data use. |
| Approving authority | Operations lead approves the bounded pilot after recording review findings. |
| Permitted use | Only the named pilot tool and test data may be used until further approval. |
| Human oversight | Staff review every draft before sending; the service owner can pause the pilot. |
| Incident route | Report concerns through the existing incident channel and notify the service owner. |
| Review trigger | Review before rollout, after a material supplier change or after an incident. |
This example shows how operational decisions replace vague language. It is not a recommended approval for any actual product. Your own data, users, deployment and responsibilities determine what needs review.
Back to page sections ↑Policy questions and background sources
Is this an official NIST, ISO or EU AI Act policy?
No. This is an original AI Gov Library draft. It does not reproduce a paid standard, provide clause-by-clause mapping or assert legal compliance. NIST AI RMF Playbook: Govern ↗ and NIST AI RMF Playbook: Manage ↗ provide background context for governance and third-party risk; our wording and operational choices are editorial work.
Can I use it without a committee?
Yes, if an existing authority can make and record the relevant decisions. Use committee and charter resources when responsibilities require a shared body; the policy should name the authority your organization actually uses.
How does this connect to other templates?
The policy assigns responsibilities and review rules. Intake, vendor assessment, procurement and inventory records show those rules being used. The AI governance templates guide helps choose the next record.
Back to page sections ↑