Last updated: September 15, 2026
An AI governance policy is the top-level document that states how your organization will develop, procure, deploy, and monitor artificial intelligence responsibly. It sets the principles, assigns accountability, defines which uses are permitted and prohibited, and points to the procedures that enforce it. The complete template below is free to copy, needs no form to access, and is written to satisfy the AI policy requirement in ISO 42001 (clause 5.2 and Annex A control A.2.2), the governance expectations of the NIST AI RMF, and the accountability obligations of the EU AI Act.
This template is part of our AI governance guide. Fill in the bracketed fields, delete anything that does not apply, and have it approved by the executive named in section 3. Where you need a companion document for day-to-day staff use, pair it with a shorter AI acceptable use policy.
Key takeaways
- A governance policy sits above the acceptable use policy. It sets direction and accountability; the AUP tells employees what they may and may not do.
- ISO 42001 requires a documented AI policy that is approved by top management, communicated, and reviewed. This template meets those conditions when adopted.
- Keep it under six pages. Detailed procedures (risk assessment, vendor review, incident response) live in separate documents the policy references.
- Every principle needs an enforcing control. A principle with no control behind it is a liability in an audit.
- Review the policy at least annually and whenever regulation, your AI inventory, or your risk appetite changes.
What should an AI governance policy contain?
A workable policy answers eight questions: Why do we have this policy? What does it cover? Who is accountable? What principles guide our use of AI? What is prohibited? How do we manage risk across the lifecycle? How do we handle vendors? And how do we handle exceptions, incidents, and review? The template follows that order. Each section notes the framework requirement it addresses so you can map it in your control library.
AI governance policy template
1. Purpose
This policy establishes how [Organization Name] governs the development, acquisition, deployment, and use of artificial intelligence (AI) systems. Its purpose is to ensure that AI is used in a manner that is lawful, ethical, safe, secure, and aligned with the organization’s values, risk appetite, and obligations to customers, employees, regulators, and the public.
Maps to: ISO 42001 clause 5.2(a); NIST AI RMF GOVERN 1.1.
2. Scope
This policy applies to all employees, contractors, and third parties acting on behalf of [Organization Name], and to all AI systems that the organization develops, fine-tunes, procures, embeds in its products, or uses in its operations. This includes machine learning models built in-house, applications that call external foundation models, AI features within third-party software, and general-purpose AI tools used by staff. Systems in scope are recorded in the AI system inventory maintained under section 6.1.
For the purposes of this policy, an AI system is a machine-based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.
Maps to: ISO 42001 clause 4.3; EU AI Act Article 3(1) definition.
3. Roles and accountability
Executive sponsor. [Title, for example Chief Information Officer or General Counsel] is accountable to the [Board / Executive Committee] for this policy and for the organization’s AI governance program. The executive sponsor approves this policy, allocates resources, and receives reporting under section 9.
AI governance committee. A cross-functional committee comprising [Legal, Security, Privacy, Data Science, Product, HR, and Risk] meets at least [quarterly] to review the AI inventory, approve high-risk deployments, decide exception requests, and oversee incidents. The committee is chaired by [Title].
AI system owners. Every AI system in the inventory has a named business owner accountable for its intended use, risk assessment, controls, and ongoing monitoring, and a technical owner responsible for its operation.
All personnel. Everyone in scope must complete AI literacy training appropriate to their role, follow the AI acceptable use policy, and report suspected AI incidents or policy violations.
Maps to: ISO 42001 clauses 5.1 and 5.3, Annex A.3; NIST AI RMF GOVERN 2; EU AI Act Article 4 (AI literacy).
4. Governing principles
All AI systems in scope shall be designed, selected, and operated in accordance with the following principles.
4.1 Lawful and accountable. AI use complies with applicable law, including data protection, anti-discrimination, consumer protection, sector regulation, and the EU AI Act where applicable. A named individual is accountable for every system.
4.2 Safe and reliable. Systems are tested for accuracy, robustness, and safety before deployment and monitored for performance degradation and drift in operation.
4.3 Fair. Systems that affect individuals are assessed for discriminatory outcomes across protected characteristics, and identified disparities are remediated or the use is withdrawn.
4.4 Transparent. People are informed when they are interacting with an AI system or when an AI system materially influences a decision about them, and AI-generated content is labelled where required.
4.5 Subject to human oversight. Decisions with legal or similarly significant effects on individuals include meaningful human review, and operators are able to interrupt, override, or halt a system.
4.6 Privacy-preserving and secure. Personal data used in training, fine-tuning, prompts, or outputs is processed under a documented lawful basis, minimized, and protected. Systems are covered by the information security program, including controls for prompt injection, data leakage, and model supply chain risk.
4.7 Sustainable and proportionate. Compute and data use are proportionate to the business need.
Maps to: ISO 42001 clause 5.2(b) and Annex A.2, A.6, A.7, A.9; NIST AI RMF trustworthiness characteristics; EU AI Act Articles 13, 14, 50.
5. Prohibited and restricted uses
5.1 Prohibited. The organization will not develop, procure, or deploy AI systems for purposes that are prohibited under Article 5 of the EU AI Act or equivalent law, including social scoring, manipulative or exploitative techniques that cause significant harm, untargeted scraping of facial images, and emotion inference in the workplace or education except for safety or medical reasons. The organization will not use AI to make fully automated decisions with legal or similarly significant effects on individuals without a lawful basis and human review.
5.2 Restricted. The following uses require AI governance committee approval and a completed AI risk assessment and, where applicable, impact assessment before deployment: [recruitment, performance evaluation, or termination decisions; credit, insurance, or pricing decisions affecting individuals; biometric identification; systems that process special category personal data; systems embedded in products sold to customers; any system classified as high-risk under the EU AI Act].
5.3 Data restrictions. [Confidential, customer, or regulated] data may not be entered into any AI tool that has not been approved and listed in the AI inventory with an appropriate data classification.
Maps to: EU AI Act Articles 5 and 6, Annex III; ISO 42001 Annex A.6.1.2 and A.9.
6. Lifecycle requirements
6.1 Inventory. All AI systems in scope are recorded in the AI system inventory before pilot or production use, including owner, purpose, data, model provenance, autonomy level, and risk tier. The inventory is reviewed [quarterly].
6.2 Risk classification. Each system is classified against the EU AI Act risk tiers and the organization’s internal impact criteria at intake and on material change.
6.3 Risk and impact assessment. Each system undergoes an AI risk assessment before deployment. Systems classified as restricted or high-risk also undergo an AI impact assessment covering affected individuals, groups, and society. Assessments are reviewed at least [annually].
6.4 Design and development. In-house development follows the documented AI development lifecycle, including data quality requirements, documentation of design decisions, testing for accuracy, robustness, and bias, and security review.
6.5 Deployment. Deployment requires sign-off by the system owner and, for restricted systems, the AI governance committee. Human oversight measures and transparency notices are in place before go-live.
6.6 Monitoring. Systems in production are monitored for performance, drift, misuse, and incidents against defined metrics. Logs are retained for [period] to support investigation and regulatory requests.
6.7 Change and retirement. Material changes trigger reassessment. Retired systems are decommissioned securely and their inventory record updated.
Maps to: ISO 42001 clauses 6.1.2, 6.1.4, 8.2, 8.3, 8.4 and Annex A.4, A.6, A.8; NIST AI RMF MAP, MEASURE, MANAGE; EU AI Act Articles 9, 12, 26, 27, 72.
7. Third-party and vendor AI
Before procuring software with AI capabilities or engaging an AI service provider, the organization will assess the vendor’s AI practices, including model provenance, use of customer data for training, security, transparency documentation, and regulatory role under the EU AI Act. Contracts will include provisions on data use, notification of material model changes, incident notification, and audit rights. Vendor AI systems are entered in the inventory and reviewed on the same cadence as internal systems.
Maps to: ISO 42001 Annex A.10; NIST AI RMF GOVERN 6; EU AI Act Article 25.
8. Incidents, exceptions, and reporting concerns
8.1 Incidents. Any event where an AI system causes or nearly causes harm, produces materially incorrect or discriminatory outputs, leaks data, or is used in breach of this policy is an AI incident. Incidents are reported to [channel] and handled under the incident response procedure, including regulatory notification where required (for example, serious incident reporting for high-risk systems under EU AI Act Article 73).
8.2 Exceptions. Requests to deviate from this policy are submitted to the AI governance committee with a risk justification, compensating controls, and an expiry date. Exceptions are logged and reviewed at each committee meeting.
8.3 Speaking up. Personnel may raise concerns about AI use through [channel] without fear of retaliation.
Maps to: ISO 42001 clause 10 and Annex A.8; NIST AI RMF GOVERN 4 and MANAGE 4.
9. Training, review, and enforcement
9.1 Training. All personnel complete AI literacy training on joining and annually thereafter. Owners of restricted or high-risk systems complete role-specific training.
9.2 Reporting. The executive sponsor reports to the [Board / Executive Committee] at least [annually] on the AI inventory, risk profile, incidents, exceptions, and program maturity.
9.3 Review. This policy is reviewed at least annually and on material change in law, business activity, or risk appetite. Version history is maintained below.
9.4 Enforcement. Breaches of this policy may result in disciplinary action up to and including termination, and in termination of contracts for third parties.
Maps to: ISO 42001 clauses 7.2, 7.3, 9.3, Annex A.2.4; NIST AI RMF GOVERN 1.5.
10. Related documents
- AI acceptable use policy
- AI system inventory and intake procedure
- AI risk assessment and impact assessment procedure
- AI development lifecycle standard
- Third-party and vendor AI assessment procedure
- Information security policy and incident response plan
- Data protection and privacy policy
11. Approval and version history
| Version | Date | Author | Approved by | Summary of changes |
|---|---|---|---|---|
| 1.0 | [Date] | [Name] | [Executive sponsor] | Initial release |
How do you adapt the template to your organization?
Start with scope. If you only use vendor AI and general-purpose tools, section 6.4 on in-house development can be cut to a sentence. If you sell AI-enabled products, section 5.2 and section 7 need the most attention, because you may be a provider under the EU AI Act with obligations that go well beyond a deployer’s. Use your AI system inventory to decide which restricted-use categories in 5.2 actually apply, and be specific: “recruitment decisions” is enforceable, “sensitive uses” is not.
Next, align the review cadence and committee membership with what you can sustain. A quarterly committee that meets is better than a monthly one that does not. Then map each principle in section 4 to at least one concrete control in your control library. ISO 42001 auditors will look for exactly this linkage, and our guide to ISO 42001 requirements lists the Annex A controls to map to.
Finally, keep the policy itself stable and let the referenced procedures absorb change. The risk assessment procedure will evolve every few months as your methods mature; the policy should not.
What are the common mistakes in AI governance policies?
The most frequent problem is a policy that is all principles and no mechanism: it says the organization values fairness and transparency but assigns no owner, requires no assessment, and defines no prohibited uses. The second is copying a vendor’s or a regulator’s language wholesale, producing a document nobody in the company can explain. The third is conflating the governance policy with the acceptable use policy, which produces a document too long for staff to read and too operational for the board to approve. The fourth is ignoring vendor AI, which for most organizations is the majority of their AI footprint. And the fifth is publishing without a review date, so the policy silently goes stale as regulation moves. Since the EU AI Act’s Digital Omnibus changed the high-risk timeline in July 2026, for example, any policy that hard-coded the original August 2026 date is now wrong; see our EU AI Act compliance guide for the current dates.
Frequently asked questions
What is the difference between an AI governance policy and an AI acceptable use policy?
The governance policy is the organization’s commitment and operating model for AI, approved by executives and aimed at the board, auditors, and regulators. The acceptable use policy is the short, practical set of rules for employees using AI tools day to day. The AUP is a child document of the governance policy.
Does ISO 42001 require a specific AI policy format?
No. Clause 5.2 requires that top management establish an AI policy that is appropriate to the organization’s purpose, provides a framework for AI objectives, includes commitments to meet requirements and continually improve, is documented, communicated, and available to interested parties. Annex A control A.2.2 reinforces this and A.2.4 requires periodic review. Any format that meets those conditions is acceptable.
Who should approve the AI governance policy?
A member of the executive leadership team, and ideally the board or a board committee should be informed. ISO 42001 places responsibility for the policy on top management, and enterprise customers increasingly ask who signed it.
How long should the policy be?
Four to six pages is typical. If it is longer, procedural detail has crept in that belongs in the referenced standards and procedures.
Do we need this policy if we only use ChatGPT and Copilot?
Yes, though a lighter version. Even general-purpose tools raise data leakage, confidentiality, accuracy, and intellectual property risks, and the EU AI Act’s AI literacy duty applies to deployers of any AI system. Focus on sections 2, 3, 5.3, 7, and 9, and pair the policy with a clear acceptable use policy.
How often should the policy be reviewed?
At least annually, plus whenever there is a material change in regulation, in the systems you use, or in your risk appetite. Record each review in the version history even if nothing changed.
Compyl turns this policy into a working program: policies are versioned and mapped to controls, controls are linked to the AI inventory and risk assessments, and evidence collects automatically for ISO 42001, the EU AI Act, and the NIST AI RMF. Request a demo to see how the policy, the inventory, and the audit trail fit together on one platform.
