AI policy: what a company AI policy should contain in 2026
An AI policy is the internal rulebook for how your staff use AI. It names the approved tools, the forbidden inputs, the point where a human has to look, and the person who owns all of it. Here is what goes in, section by section, with a template outline you can start from.
The usual trigger for writing an AI policy is external: an enterprise customer sends a vendor questionnaire with a row that says "AI governance policy: attach", an insurer asks who owns AI risk, or someone pastes a customer contract into a public chatbot and the question "were they allowed to?" has no answer.
Regulation (EU) 2024/1689, the EU AI Act, does not contain an article headed "write an AI policy". What it contains is a set of duties that are difficult to meet, and impossible to evidence, without one. The Article 4 AI literacy obligation has applied since 2 February 2025. The Article 5 prohibitions apply from the same date. The transparency duties in Article 50 apply from 2 August 2026. The deployer duties in Article 26 for high-risk systems follow on the dates in the AI Act timeline. GDPR already governs every piece of personal data that ends up in a prompt. An AI policy is where a company turns those scattered duties into rules its people can follow.
AI policy, AI literacy policy, AI system register: three documents, one system
The terms get mixed up, so a short map before the contents. Three documents do three jobs:
| Document | What it does | Legal hook | Who reads it |
|---|---|---|---|
| AI policy (governance and acceptable use) | Sets the rules: approved tools, permitted purposes, prohibited inputs, human review, disclosure, procurement, incidents, ownership | Art. 4, 5, 26, 50 AI Act; GDPR | Every employee and contractor who touches an AI tool |
| AI literacy policy | Sets out what each role is taught about the tools in use and keeps the record that the training happened | Art. 4 AI Act | The AI Owner, managers, and whoever is asked for evidence |
| AI system register | Lists each AI system in use: vendor, purpose, data classes, risk category, system owner | Art. 26 for high-risk; the factual basis for everything else | The AI Owner, procurement, auditors, enterprise customers |
The AI policy is the rules. The AI literacy policy teaches the rules. The register is the list of things the rules apply to. Write them so each refers to the others rather than repeating them, because the moment a tool is added or a rule changes you want to edit one place.
What an AI policy should contain: the ten sections
1. Purpose and scope
One paragraph on why the policy exists and who it binds. Scope should cover employees, contractors and agency staff. State whether the policy covers personal devices and personal accounts used for work. It should.
2. Roles and ownership
Name an AI Owner: the one person accountable for the policy, the AI system register and regulatory tracking. Name a system owner for each entry in the register. Say who approves a new tool, who signs off a new use case, and who the policy escalates to when the AI Owner is unsure. A policy without a named owner is a document nobody updates.
3. Approved systems
Business use of AI is restricted to systems listed in the AI system register. That sentence converts "is this tool allowed?" into "is it on the list?". The list itself lives in the register, not in the policy, so that adding a tool does not require re-issuing the policy.
4. Acceptable-use rules
What AI may be used for, and what it may not. Start from the Article 5 prohibited practices, which bind anyone using a system, and say plainly that no tool may be used for any of them. Then list the company's own red lines: no AI-only decisions about hiring, firing, credit or access to services; no generating content that imitates a real person without consent; no entering a customer's data into a tool the customer has not agreed to. Keep each rule to one sentence. Rules that need a paragraph of explanation belong in training, not in the policy.
5. Data rules
Define data classes and state which may be entered into which tools. A workable minimum: personal data (GDPR applies, legal basis and processor terms needed), customer confidential (only in tools the customer contract allows), trade secrets and source code (only in tools with a no-training, no-retention contractual commitment), credentials and keys (never). Tie each class to the register: a tool's register entry says which classes it is cleared for.
6. Human review and decisions about people
Require a qualified human review before AI output is published, sent to a customer, or used in a decision that affects a person. Define "qualified": someone who could have produced the output without the tool and can tell when it is wrong. For any system that could fall under Annex III, the high-risk list, this section is also where the Article 26 deployer duties on human oversight get a home, even if the obligation itself does not bind yet. Writing it down early is cheaper than retrofitting it.
7. Transparency and disclosure
Article 50 requires people to be told when they are interacting with an AI system, and requires certain AI-generated content to be marked. The policy should say which of the company's uses trigger this, who owns the wording, and where it appears. A chatbot disclosure that meets Article 50(1) is one line of text; the policy's job is to make sure someone is responsible for it being there.
8. Procurement screening
Before any new AI tool is approved, record: vendor, purpose, data classes it will see, whether the use could fall under Annex III or Article 50, and the legal basis for any personal-data processing. Five fields. The output of the screening is the tool's register entry, so screening and registering are one step, not two.
9. Incident handling
Define an AI incident: wrong output acted on, data entered that should not have been, a tool used outside its approved scope, a disclosure that was missing. Say who gets told, within what time, and who decides whether a customer, a data protection authority or an insurer must be notified. The reporting bar should be low and blame-free, because the incidents you learn about are the only ones you can fix.
10. Regulatory watch and review
The AI Act's obligation dates run through 2028 and the Digital Omnibus, Regulation (EU) 2026/1744, has already rewritten parts of the text once. Name who watches for changes, and set a review date for the policy itself. Annual is the usual cadence, plus a review whenever a new tool, a new use case or a change in the law makes one necessary.
A template outline
The outline below is a fuller version of the five-section governance and acceptable-use policy in Klariq's document pack, which folds scope, data classes, disclosure and review into its acceptable-use section. The three clauses under it are illustrative wording, not pack text. It is a starting point, not a finished document; the register and the company-specific rules are what make it yours.
AI governance and acceptable-use policy: outline
- Purpose and scope
- Roles: AI Owner, system owners, approval and escalation
- Approved systems and the AI system register
- Acceptable-use rules, including Article 5 prohibitions
- Data classes and what may be entered where
- Human review and decisions affecting people
- Transparency and disclosure under Article 50
- Procurement screening for new AI tools
- Incident definition, reporting and response
- Regulatory watch, review date, version history
Illustrative clause, approved systems:
Illustrative clause, data rules:
Illustrative clause, human review:
Three worked examples
Ten-person marketing agency. Uses two generative tools for drafting and image generation. The AI policy is two pages. The register has two entries. The data rule that matters is "no client material in any tool the client has not approved in writing", because the agency's exposure is contractual, not regulatory. Article 50 matters for the image generation, which the policy handles by assigning the content-marking decision to the account lead on each job.
Sixty-person SaaS company with a support chatbot. The chatbot talks to customers, so Article 50(1) disclosure is a live duty and the policy names the product owner as responsible for the wording. Engineering uses a coding assistant, so the data rules section carries a no-training, no-retention requirement on the vendor contract and bars production credentials from prompts. The register has five entries. The procurement screening section is the one that gets used most, because engineers find a new tool every month.
Three-hundred-person manufacturer evaluating an HR screening tool. Recruitment screening is on the Annex III list, so the procurement screening flags the tool as potentially high-risk before anyone signs. The policy's human-review section already requires a person to make the hiring decision. The AI Owner is the existing information-security lead, and the literacy policy schedules deeper training for recruiters, since the people the system is used on are job applicants. Deployer duties under Article 26 start on 2 December 2027; the policy gets the oversight clause now so it is not written in a hurry later.
Common mistakes
- Listing tools in the policy instead of the register. The policy then needs re-issuing every time someone adopts a new tool, so it stops being re-issued and goes stale.
- A policy with no owner. Nobody updates it, nobody enforces it, and when a customer asks who is responsible for AI risk the honest answer is "nobody".
- Rules that read like a law firm wrote them. Staff do not read a twelve-page document. Two to four pages, one sentence per rule, detail pushed into training and the register.
- Banning everything. A policy that forbids all AI use is not followed; it is routed around on personal accounts, where the data rules do not apply and the company has no visibility. Approve tools and set rules instead.
- Treating it as the training. The policy says what the rules are. Article 4 asks you to take measures to support AI literacy, which is a separate document and a separate record.
- No incident path. Without a defined, blame-free reporting route, the first you hear of a data leak into a chatbot is from the customer whose data it was.
How to get one
Start with the free classifier. Klariq's free EU AI Act classifier asks a short set of questions about how you use AI and tells you which risk category and which obligations apply, with the correct post-omnibus dates. That result is the factual basis the AI policy is built on.
The one-time EUR 249 document pack then generates six documents from your answers, including the AI governance and acceptable-use policy whose outline you just read, the AI literacy policy and the AI system register, pre-filled for your company and ready for the AI Owner's name and an effective date. The Article 4 staff training for a team of up to 20 is available on its own for €49, credited in full against the pack.
Common questions
What is an AI policy?
A company AI policy is the internal rulebook for how staff and contractors may use AI systems: which tools are approved, for which purposes, with which data, who reviews the output before it is used, who owns the rules, and what happens when something goes wrong. It is a governance and acceptable-use document, not a training document.
Is an AI policy legally required in the EU?
The EU AI Act does not contain an article that says "write an AI policy". It does impose duties that are hard to meet without one: the Article 4 AI literacy obligation in force since 2 February 2025, the Article 50 transparency duties, the Article 5 prohibitions, and the deployer duties in Article 26 for high-risk systems. GDPR adds rules on personal data entered into AI tools. The policy is how a company shows it took those duties seriously.
What is the difference between an AI policy and an AI literacy policy?
The AI policy sets the rules of use: approved tools, prohibited inputs, human review, disclosure, procurement and incidents. The AI literacy policy, which answers Article 4, sets out what each role is taught about those tools and keeps the record that the training happened. The literacy policy teaches the rules; the AI policy is the rules. Most companies need both, and the AI literacy policy should reference the AI policy rather than repeat it.
What should an AI policy contain?
Ten sections cover it: purpose and scope, roles and ownership, approved systems tied to an AI system register, acceptable-use rules, data rules naming what must never be entered into a prompt, human review before output is published or used in decisions about people, transparency and disclosure, procurement screening for new tools, incident handling, and a regulatory watch with a review date.
Who should own the AI policy?
One named person, often called the AI Owner, accountable for the policy, the AI system register and regulatory tracking, plus a system owner for each entry in the register. In a company of ten the AI Owner is usually a founder or the head of operations. In a larger company it is typically the person who already owns information security or data protection.
How long should an AI policy be?
Short enough that staff actually read it. Two to four pages covers the ten sections for most small and mid-sized companies. Detail belongs in the AI system register and in the role-specific training material, not in the policy itself.