AI governance policy: what it must contain and how to write one

The short answer: An AI governance policy is the top-level document in which leadership sets out why the organisation uses AI, what it will and will not use it for, who is accountable, and how AI risk, data, human oversight and incidents are handled. It is the policy that ISO/IEC 42001 clause 5.2 requires, and the anchor the rest of your AI management system hangs from. It is short, signed by top management, and backed by procedures that do the detailed work.

Two years ago an AI policy was a paragraph in the staff handbook. Now it is a line on customer security questionnaires, the first document an ISO 42001 auditor reads, and what a regulator asks for when an automated decision goes wrong. Most organisations have a one-page "be careful with ChatGPT" note that names no owner and covers no vendor tool. That is an acceptable-use note, and it will not carry the weight now being put on it.

{{snapshot}}

AI governance policy at a glance

• One policy, procedures underneath. The governance policy states intent and accountability; the acceptable-use policy tells staff what they may do; procedures and controls do the work.
• ISO 42001 clause 5.2 requires it. Top management must establish an AI policy that fits the organisation's purpose, frames AI objectives, and commits to meeting requirements and to continual improvement.
• Annex A backs it up. Objective A.2 covers the AI policy, its alignment with other policies and its review; A.3 covers roles and the reporting of concerns.
• Scope must include bought AI. Vendor features, embedded copilots and the tools staff sign up for on a company card all count.
• The EU AI Act reads it too. AI literacy duties applied from February 2025; most high-risk obligations follow from August 2026.

{{/snapshot}}

Governance policy, acceptable-use policy, governance framework: which one do you need?

All three, and they are not interchangeable. People use "AI policy" to mean any of them, which is how a staff memo ends up doing the job of a management system.

The AI governance policy is the board-level statement. It sets principles, objectives, scope, accountability and the commitments the organisation is prepared to be measured against, for staff, customers, regulators and auditors alike. Two to four pages, signed at the top.

The AI acceptable-use policy is operational and addressed to staff. Which tools are approved, what data may go into them, what to do when the output looks wrong. It changes often, which is exactly why it should not be welded to the governance policy.

The AI governance framework is the whole structure: policy, roles, risk method, inventory, controls, evidence, review. We have written separately on building an AI governance framework and on why an AI policy on its own is not governance. A policy nobody can map to an owner, a control and a piece of evidence is a document, and auditors do not certify documents.

What ISO 42001 clause 5.2 and the EU AI Act actually ask for

ISO/IEC 42001:2023 follows the same harmonised structure as ISO 27001, so clause 5.2 does the same job in both: it requires top management to establish an AI policy. The policy must be appropriate to the purpose of the organisation, provide a framework for setting AI objectives, and commit to satisfying applicable requirements and to continual improvement of the AI management system. It must be documented, communicated internally and available to interested parties where appropriate.

Annex A then adds teeth. Control objective A.2 requires an AI policy, its alignment with other organisational policies and its planned review. Objective A.3 requires defined AI roles and responsibilities and a process for reporting concerns. A.9 covers responsible use of AI systems and A.10 third-party and customer relationships. An auditor will trace each back to the policy, so the policy should point at them. Our guide to ISO 42001 clauses 4 to 10 walks through the full set, and the AI management system hub explains how the policy sits inside the AIMS.

The EU AI Act does not use the words "governance policy" anywhere, but its obligations assume one exists. Article 4 has required providers and deployers to ensure AI literacy among staff since February 2025, which is hard to evidence without a policy and a training record. Deployers of high-risk systems must assign human oversight to competent people, monitor operation and report serious incidents, mostly from August 2026. A policy that already names oversight roles, a monitoring cadence and an incident route is a large share of that paperwork done early.

In the UK there is no single AI statute. The ICO's guidance on AI and data protection is the practical reference for anything that processes personal data, including automated decision-making under UK GDPR. Cite it by name rather than gesturing at "applicable law".

The section-by-section template

Each row is a section of the policy. The last column is what that section evidences, so you can show an auditor the mapping rather than describe it.

Keep the policy at the level of commitments and push the detail into procedures. "We assess every AI system before deployment" belongs in the policy. The scoring scale does not. Our guides to running an AI risk assessment and AI risk management cover what those procedures need to contain.

Scope: the AI you know about and the AI you don't

Most first drafts fail on scope, because they only cover the AI the IT team bought on purpose. Write it in three bands.

Systems you build or fine-tune. Models, agents and features your engineers ship, including anything wrapped around a third-party API. These get the full treatment: impact assessment, testing, monitoring, documentation.

AI you buy. Standalone AI tools plus the AI features inside software you already own: the CRM's summariser, the meeting-notes bot, the copilot that appeared in your office suite after an update. If it processes your data or shapes a decision, it is in scope, and the supplier contract is a control.

Shadow AI. Tools staff sign up to without asking. The policy should require registration of any AI tool used for work, offer an approval route fast enough that registering is worth the bother, and state plainly that unregistered tools handling company or customer data are prohibited. Build the inventory before you finalise the scope; the first pass usually turns up twice as many tools as anyone expected.

Rolling it out: ownership, approval, training, review

Four moments decide whether a policy becomes real or quietly dies.

Ownership. Name one accountable owner for the policy, usually the AI governance lead or the CISO, and one owner for each AI system on the inventory. Shared ownership is no ownership, and auditors know it.

Approval. Clause 5.2 makes this top management's policy, so it needs a board or executive signature, a version number and a date. Record the approval as a minute, not an email thread.

Training and attestation. Every person the policy binds reads it, is trained on the parts relevant to their role, and confirms both. Developers need the life-cycle and testing sections, everyone needs the acceptable-use rules. The EU AI Act's AI literacy duty makes this a legal expectation for anyone in its reach.

Review. Annually at minimum, plus triggers: a new high-impact use case, a significant incident, a regulatory change, a supplier changing its model or terms. Log each review even when nothing changes. Silence is a finding.

Hicomply's policy management module holds policy templates mapped to ISO 42001 controls, tracks versions and approvals, and records staff attestation, so you can show who read what and when. HealthBoxHR used policy and procedure templates linked to controls to go from nothing in place to ISO/IEC 27001:2022 certification in 12 weeks; the AI policy set follows the same pattern. Our guide to AI governance tools sets out what a platform should do beyond storing a PDF.

Mistakes that turn a policy into shelfware

Copying a template and changing the logo. Principles that do not describe how your organisation actually makes decisions are a finding waiting to happen.

Writing it for the auditor instead of the staff. If a new starter cannot read it in ten minutes and know what they may do, it will be ignored, and an ignored policy is a written record of a rule you do not enforce.

Prohibiting everything. A blanket ban drives AI use underground. Say what is allowed, make approval quick, and reserve prohibition for the practices that warrant it.

Leaving out incidents. Someone will paste a client contract into a public model. The only question is whether they tell you. A blame-light reporting route is the cheapest control you will ever write.

Never mapping it to controls. Each commitment in the policy should trace to a control, an owner and a piece of evidence. The ISO 42001 checklist confirms nothing in Annex A has been left without a home.

{{snapshot}}

Hicomply's take

We have read a lot of AI policies this year and most share one fault: they are acceptable-use notes dressed up as governance. The ones that work are short, signed at the top, and honest about scope, including the tools nobody in IT approved. Write the policy last, not first. Build the inventory, run a first-pass risk assessment, decide who owns what, then write down what you have decided. A policy that describes a system which exists will pass audit. A policy that describes a system you intend to build one day will not, and everyone in the room will know it.

{{/snapshot}}

Get your AI governance policy signed, mapped and evidenced

The policy is easy to write and hard to keep alive. Templates, versioning, attestation and control mapping turn a draft into something an auditor can rely on.

Run the free ISO 42001 readiness assessment to see where your policy set stands, then book a demo to see the policy templates, control mapping and attestation trail on one platform. Bring your current AI policy, however short. Short is fixable.