AI policy: what it must contain and how it fits your policy set

The customer's security questionnaire has a new section on AI, and its first line asks you to attach your AI policy. You have a paragraph in the staff handbook about ChatGPT. The deal is waiting, and that paragraph will not answer the question the customer is really asking.

An AI policy is the top-level document that states how your firm will develop, buy and use AI responsibly, who is accountable, and how any AI use is approved, recorded and reviewed. The staff usage rules sit beneath it, usually in the acceptable use policy. Customers and ISO/IEC 42001 expect both layers.

This guide is for founders, COOs and security leads at UK technology firms of 25 to 250 people. It sets out what each layer contains, how the AI rules line up with the policies you already hold, and which questionnaire questions and EU AI Act duties the policy answers.

What is an AI policy?

An AI policy is a short governance document, approved by leadership, that sets the firm's commitments on AI, names the owner, and defines how AI use is approved, recorded and reviewed. It covers AI you build, buy and use inside other software. It is not a list of staff do's and don'ts; those rules belong one level down.

Most AI policy examples you will find online are usage policies: approved tools, banned data, a reminder to check outputs. They are useful, and they answer one question: what may staff do today?

A company AI policy answers a different question: how does the business decide? It is the document a customer, an investor or a certification auditor reads to judge whether AI is governed or merely tolerated.

For how to write the usage rules themselves, our guide to governing shadow AI covers the approved-tool list, the data rules and the register behind them.

Why does one AI policy document fail at both jobs?

A single document that tries to be both the governance policy and the usage rules ends up doing neither well. The commitments get buried under tool names, and the tool names go stale within months. Every change to the approved list then needs leadership sign-off, so the list stops being updated.

The two layers change at different speeds. Commitments, ownership and the approval route should hold for a year or more. The approved tools and data rules may change every month.

Split them, and each layer can move at its own pace. Leadership approves the policy once a year. The owner updates the usage rules whenever a tool is approved or retired, inside a process the policy already authorised.

A policy that names ChatGPT is already out of date.

What should an AI policy contain?

A governance-level AI policy should cover ten things: purpose and scope, commitments, roles, objectives, approval and recording of AI use, the trigger for risk and impact assessment, supplier and data rules, the route for incidents and concerns, training, and the review cycle. Each can be a short paragraph. Together they show the firm decides deliberately.

1. Purpose and scope. Why the policy exists and what it covers. Name all three routes AI enters the business: systems you build, tools you buy, and AI features embedded in software you already use. The third route is the easiest to miss.
2. Commitments. Your principles turned into statements someone can check, such as "a person reviews any AI output sent to a customer". A principle with no check behind it is a slogan.
3. Roles and the named owner. One accountable executive, plus who approves new AI use, who maintains the register and who handles concerns.
4. AI objectives. Two or three measurable aims for the year, such as every AI use recorded in the register or every member of staff trained before first use.
5. Approval and recording of AI use. The route a new tool or use case follows before anyone relies on it, and where each approved use is recorded.
6. Risk and impact assessment trigger. What sends a use case for a fuller assessment: personal data, customer data, automated decisions about people, or use in the service you sell.
7. Supplier and data rules. What you require from AI vendors before approval, and which data classes may never enter an AI tool.
8. Incidents and concerns. How staff report an AI output that went wrong, or a use they think breaks the policy, and how the firm responds.
9. Training. Who receives AI training, when, and how it is recorded.
10. Review. How often the policy is reviewed, who signs it off, and what triggers an early review.

An AI governance policy that covers these ten points rarely needs to exceed four pages. If yours does, the usage rules have probably crept back in.

What does ISO/IEC 42001 expect from an AI policy?

ISO/IEC 42001:2023 requires top management to establish an AI policy in clause 5.2, and Annex A.2 adds three controls on policies related to AI: the AI policy itself, its alignment with other organisational policies, and its review. The standard asks for a documented, communicated policy that frames AI objectives and commits to meeting requirements and improving.

We describe these requirements in our own words, because the standard's text is copyrighted. In outline, clause 5.2 expects the AI policy to:

• suit the organisation's purpose;
• provide a framework for setting AI objectives;
• commit to meeting applicable requirements and to continual improvement;
• be documented, communicated inside the organisation and available to interested parties where appropriate.

Annex A.2 then turns those expectations into controls. A.2.2 covers having the AI policy. A.2.3 asks you to work out where other policies, such as security, privacy or quality, already touch AI and to keep them consistent. A.2.4 asks for review at planned intervals and when things change.

The alignment control is the easiest to overlook, and the table below answers it. Our ISO/IEC 42001 overview explains how the policy fits the wider management system.

You do not need to pursue certification to use this structure. A policy built to clause 5.2 and A.2 answers most AI questions a customer will ask, and it means the work is already done if certification comes later.

The NIST AI Risk Management Framework, a voluntary US framework released on 26 January 2023, points the same way. Its GOVERN function expects the characteristics of trustworthy AI to be "integrated into organizational policies, processes, procedures, and practices", and expects policies that address AI risks from third parties.

How does the AI policy fit with your other policies?

The AI policy should sit alongside your information security, data protection, supplier and acceptable use policies, not on top of them. Each existing policy keeps its own subject and adds the AI rule that belongs there. The AI policy sets the commitments and points to where each rule lives, so nothing is written twice.

The usage rules themselves are not rewritten here. For the acceptable use document, start from our acceptable use policy template, and add the AI section the shadow AI guide describes.

What do customer questionnaires ask about your AI policy?

AI sections in customer security questionnaires usually ask whether you have an AI policy, who owns it, how AI tools are approved, whether customer data enters AI tools, and how staff are trained. The policy answers the first question. Approval dates, review records and the register are the evidence that answers the rest.

A one-line "yes" invites follow-up questions. A short answer with evidence behind it ends the thread. Prepare these items once and reuse them:

• The policy itself, with its version, approval date and approving body on the cover.
• The owner, named by role.
• The last review record, showing the policy was looked at and what changed.
• The AI register, listing approved tools and use cases, the data each may touch and its approval date.
• Supplier evidence for the AI vendors that process customer data.
• Training records showing who completed AI training and when.

The register does most of the work. It turns "we govern AI" into a list a customer can test. Our guide to the AI governance framework shows how the policy, the register and the review cycle run as one operating model.

Does the EU AI Act require an AI policy?

The EU AI Act does not require a document called an AI policy. It requires providers and deployers within its reach to take measures that support staff AI literacy, and it places further duties on deployers of high-risk systems. The AI policy is the natural place to record how your firm meets the duties that apply to it.

Who is a deployer. The Act defines a deployer as a person or organisation "using an AI system under its authority", unless the use is personal and non-professional. A firm whose staff use AI tools at work will normally be a deployer of those tools.

Whether the Act applies to a UK firm. Under Article 2, the Act applies to deployers established in the EU, and to deployers outside the EU "where the output produced by the AI system is used in the Union". A UK firm with EU operations, or whose AI outputs are used in the EU, should check its position. A UK firm with no EU link is generally outside the Act. Our EU AI Act guide covers roles and scope.

Article 4, as amended. The Digital Omnibus on AI, Regulation (EU) 2026/1744, replaced Article 4 with effect from 27 July 2026. Providers and deployers must now "take measures to support the development of AI literacy" of their staff and others using AI on their behalf. The Commission's AI literacy questions and answers say there is "no need for a certificate", the duty does not require any specific level of AI literacy, and organisations can keep an internal record of training.

The AI policy should state which measures you take and where the record is kept. That is a modest duty, and it should be described as one.

High-risk deployer duties. Article 26 adds duties for deployers of high-risk AI systems, such as following the provider's instructions for use and assigning human oversight to people with the necessary competence, training and authority. Under Regulation (EU) 2026/1744, these rules apply from 2 December 2027 for the systems listed in Annex III. Most UK technology firms using general-purpose AI tools will not deploy a high-risk system. Your policy's risk and impact assessment trigger is where you would catch one.

What does UK GDPR add when AI meets personal data?

UK GDPR applies whenever an AI tool processes personal data, whether it is a customer's, an employee's or a prospect's. The ICO holds senior management accountable, and says most AI use involves processing likely to result in high risk, which triggers a legal duty to carry out a DPIA. The AI policy should send those cases to your DPIA process.

The ICO's guidance on AI accountability and governance is direct about ownership: "You cannot delegate these issues to data scientists or engineering teams." It says that "in the vast majority of cases" AI use will trigger the DPIA requirement, and asks firms to align their policies with their overall AI governance and risk management strategy.

The guidance notes that it is under review following the Data (Use and Access) Act. Check the current version when you next review your policy.

In practice, the AI policy needs three links to your data protection work:

• the risk and impact assessment trigger names personal data as a reason for a DPIA;
• the supplier rules require a processor agreement before any AI vendor handles personal data;
• the data rules say which personal data must never enter an AI tool.

How should you approve, communicate and review the AI policy?

Approve the AI policy at board or leadership level, publish it where staff already find policies, and review it at least once a year and whenever your AI use changes materially. Record each approval and review, because those records are the evidence customers and ISO/IEC 42001 auditors ask to see.

A workable rhythm for a firm of 25 to 250 people:

1. Draft with the owner, security and whoever handles data protection.
2. Approve at a leadership meeting, and minute the decision.
3. Communicate through the channel staff already use for policies, with a short summary of what changed. Link the usage rules from the same place.
4. Train staff before they use an approved AI tool for the first time, and record it.
5. Review yearly, and early when you approve a new kind of AI use, start selling an AI feature, enter a new market or change a key AI supplier.

The UK government's AI Cyber Security Code of Practice, a voluntary code published on 31 January 2025, makes a related point. Its first principle, aimed at developers, system operators and data custodians, asks them to raise awareness of AI security threats and to include AI security content in their cyber security training.

Common mistakes with an AI policy

The most common AI policy mistakes are writing usage rules and calling them governance, leaving out AI embedded in existing software, and approving the policy once and never reviewing it. Each one leaves a gap a customer questionnaire or an ISO/IEC 42001 audit will find.

• The tool list as policy. Approved tools belong in the usage rules, not in the document leadership signs.
• Ignoring embedded AI. AI features switched on inside your CRM, help desk or code platform are AI use. Scope them in.
• No owner. A policy owned by "the business" is owned by nobody.
• Copying a template unchanged. A generic AI policy template commits you to processes you do not run. Customers notice when the answers do not match the document.
• Overstating the law. Telling staff the EU AI Act requires certified training, or that every UK firm is in scope, creates work and erodes trust in the policy.
• No evidence trail. Without approval minutes, review records and a register, the policy is a claim rather than proof.

An AI policy nobody has reviewed is a statement of past intent.

Frequently asked questions