AI Acceptable Use Policy: The Two Policies the AI Act Names

An AI acceptable use policy is the document that tells staff which AI tools they may use, for which tasks, with which data, under which review and disclosure rules, and what happens when they ignore it. Most templates treat it as an HR memo. In Europe it is now evidence: the EU AI Act already uses the term for model providers, Article 4 has been enforced by national authorities since 2 August 2026, and ISO/IEC 42001 and NIST AI 600-1 name the policy by its function. This guide shows what each clause expects, and how to write a policy that survives an inspection.

AI acceptable use policy shown as a wooden signpost with a green arm and a red arm on an office desk beside a notebook and a fountain pen

Key takeaways

  • The EU AI Act names “the acceptable use policies applicable” in Annex XI and Annex XII, so every deployment carries two policies: the model provider’s and yours, and yours cannot permit what theirs forbids.
  • Article 4 on AI literacy has been enforced by national market surveillance authorities since 2 August 2026; the Commission expects an internal record, not a certificate.
  • Article 5(1)(f) (no emotion inference at work) and Article 50 (disclosure, marking, AI-written text) already apply; Article 26 for high-risk systems follows on 2 December 2027.
  • ISO/IEC 42001 control A.9.2 and NIST AI 600-1 actions GV-1.4-002, GV-3.2-003 and GV-6.1-010 describe the policy almost section by section.
  • Shadow AI is the cost of not having one: 20 percent of breaches in IBM’s 2025 report involved it, at USD 670,000 extra per breach.

What an AI acceptable use policy is, and the two policies the law names

An AI acceptable use policy is the operational rulebook for people who use AI tools on behalf of an organisation. It answers six questions: who is covered, which tools are approved, which tasks are permitted, which data may go into a tool, which outputs need human review or disclosure, and what the consequences of a breach are. It is short, it is signed, and it is the document a new hire reads before opening a chatbot.

The phrase comes from IT security, where acceptable use policies governed email and internet use for twenty years; generative AI brought the same question back in a new form: what may an employee paste into a system the company does not control?

What the templates miss is that the law already uses the phrase. Regulation (EU) 2024/1689, the EU AI Act, requires providers of general-purpose AI models to document “the acceptable use policies applicable” in two places: Annex XI, Section 1, point 1(b), as part of the technical documentation under Article 53(1)(a), and Annex XII, point 1(b), as part of the information handed to downstream providers under Article 53(1)(b). The GPAI Code of Practice of 10 July 2025 turned that into a field of its Model Documentation Form. In practice these are the documents you already know: OpenAI’s Usage Policies, Anthropic’s Usage Policy, which the company also calls its Acceptable Use Policy, and Meta’s Llama Acceptable Use Policy.

So every deployment carries two acceptable use policies. The provider’s sets the outer boundary of what the model may be used for. Yours sets the inner boundary for your people. The chain only works one way: your rules cannot allow what the provider’s policy forbids, and if a team uses a model for a prohibited purpose, the contractual exposure sits with you. The practical consequence is simple. The provider’s policy belongs in your tool register, next to the data-processing terms, and the general-purpose AI obligations of your supplier belong in your due diligence file.

Acceptable use policy versus AI policy

The two documents are often confused, and ISO/IEC 42001 keeps them apart for a reason. The AI policy states commitments, principles, roles and the governance structure; it is the object of clause 5.2 and of control A.2.2. The AI acceptable use policy is the operational layer beneath it: the rules a user applies at the keyboard, the object of control A.9.2 (“Processes for responsible use of AI systems”) and A.9.4 (“Intended use of the AI system”). One is a charter approved by the board; the other is a procedure approved by the policy owner and acknowledged by every user. An organisation can have the first without the second, and that is exactly where shadow AI grows.

Why it became a compliance artefact: dates and numbers

Four obligations now assume that the rulebook exists, and each has a date.

Article 4 has applied since 2 February 2025. The Digital Omnibus on AI, Regulation (EU) 2026/1744, rewrote it with effect from 27 July 2026: providers and deployers must “take measures to support the development of AI literacy” of their staff and of other persons operating AI on their behalf. Since 2 August 2026 the national market surveillance authorities supervise and enforce it. The Commission’s AI literacy questions and answers, last updated on 20 October 2026, states that there is “no one size fit all”, that “there is no need for a certificate”, and that a company whose employees use ChatGPT for advertising copy or translations must make sure “they should be informed about the specific risks, for example hallucination”. The AI acceptable use policy is where that information lives.

Article 5(1)(f) has prohibited AI systems that infer the emotions of a person in the workplace since 2 February 2025, with a medical and safety exception. Article 50 has applied since 2 August 2026: users must know they are talking to a machine, synthetic content must carry machine-readable marking (with a transition to 2 December 2026 for systems already on the market), deepfakes must be disclosed, and AI-written text published to inform the public on matters of public interest must be disclosed unless it went through human review or editorial control. Article 26 adds deployer duties for high-risk systems, including informing workers’ representatives, from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.

The numbers explain the urgency. Deloitte’s UK workforce survey, with fieldwork in May and June 2026, found that 63 percent of the UK workforce had used generative AI for work and 12 percent used it every day; 31 percent of those users did so without their employer knowing, 46 percent used free tools, and 17 percent paid for their own. IBM’s Cost of a Data Breach Report 2025 put the global average breach at USD 4.44 million, found that 20 percent of breaches involved shadow AI at USD 670,000 more than the average, that 63 percent of breached organisations had no AI governance policy, and that 97 percent of organisations with an AI-related breach lacked proper AI access controls. The reference incident is still Samsung: engineers pasted internal source code into ChatGPT in April 2023, and a May 2023 memo restricted generative AI tools on company devices.

AI acceptable use policy clause map

The fastest way to turn a template into evidence is to annotate each section with the clause that assumes it and the record an auditor can ask for. The map below is our own reading; the clause titles are those of ISO/IEC 42001:2023 Annex A and the action identifiers those of NIST AI 600-1.

Policy sectionClause that assumes itEvidence to keep
Scope, roles, ownerISO/IEC 42001 A.2.3 and A.3.2; NIST AI 600-1 <code>GV-1.4-002</code>Signed policy, version history, RACI
Approved tools and tiersAI Act Article 4 and Article 26(1); ISO/IEC 42001 A.9.4 and A.4.4; <code>GV-6.1-010</code>Tool register linked to the AI inventory, provider acceptable use policy on file
Prohibited uses (red lines)AI Act Article 5(1)(f) and Article 50(4); ISO/IEC 42001 A.9.2; <code>GV-1.3-004</code>Red-line list, exception register
Data rulesGDPR Articles 5 and 32; ISO/IEC 42001 A.7 and A.9.2Data classification matrix, gateway or DLP logs
Human review of outputsAI Act Article 26(2), Article 50(4) editorial control; ISO/IEC 42001 A.9.2Review step in the workflow, named reviewer
Training and literacyAI Act Article 4; ISO/IEC 42001 clause 7.3 and A.4.6Training register, acknowledgements
Incidents and concernsAI Act Article 26(5); ISO/IEC 42001 A.3.3 and A.8.4Incident log, reporting channel
Review cadenceISO/IEC 42001 A.2.4; <code>GV-6.1-010</code>Annual review record, change log

Two readers will use this map. An ISO/IEC 42001 auditor starts from the Statement of Applicability, where the 38 Annex A controls in nine objectives are selected or excluded with a justification, and looks for A.9.2 and its records; our ISO 42001 guide covers that document. A national market surveillance authority starts from Article 4 and asks what measures you took and how you know they reached the people who use AI. The same policy, with the same acknowledgements and the same tool register, answers both.

NIST is unusually explicit here. Our count of the Generative AI Profile found 212 unique action identifiers, and four of them name the artefact: <code>GV-1.4-002</code> asks organisations to “establish transparent acceptable use policies for GAI that address illegal use or applications of GAI”, <code>GV-3.2-003</code> to “define acceptable use policies for GAI interfaces, modalities, and human-AI configurations”, <code>GV-1.3-004</code> to obtain stakeholder input “to identify unacceptable use”, and <code>GV-6.1-010</code> to update the policies “to address proprietary and open-source GAI technologies and data, and contractors, consultants, and other third-party personnel”. A policy written against the map above satisfies all four without a separate exercise under the NIST AI RMF.

Red lines every policy needs, and the legal line behind each

A red line is only credible when the reader can see the rule behind it. These eight belong in every European AI acceptable use policy.

  • <b>Inferring emotions of colleagues or candidates.</b> Article 5(1)(f) prohibits AI that infers emotions in the workplace, with a narrow medical and safety exception; it has applied since 2 February 2025 and sits in the top fine band of Article 99(3), up to EUR 35 million or 7 percent of worldwide turnover. No sentiment scoring of meetings, interviews or support calls.
  • <b>Pasting personal data of customers, colleagues or candidates into a public tool.</b> GDPR Articles 5 and 32 apply at the moment of the paste, not when the output is used; our guide to GDPR-compliant AI sets out the legal basis questions.
  • <b>Pasting trade secrets, source code or unreleased financials.</b> The Samsung memo is the precedent; the loss is contractual and competitive before it is regulatory.
  • <b>Using an output to decide about a person without human review.</b> For high-risk systems Article 26(2) requires oversight by persons with competence, training and authority; for everyone, GDPR Article 22 limits solely automated decisions. See human oversight for the evidence that proves review happened.
  • <b>Publishing AI-written text on matters of public interest without editorial control.</b> Article 50(4) requires disclosure unless a person holds editorial responsibility and the text was reviewed; the practical rule is that nothing AI-written reaches the public without a named editor. Our Article 50 guide covers the marking and disclosure duties.
  • <b>Creating or circulating deepfakes without disclosure.</b> Also Article 50(4), with fines up to EUR 15 million or 3 percent under Article 99(4).
  • <b>Personal accounts and unapproved tools.</b> The IBM figure (97 percent of AI-related breaches without proper access controls) and the Deloitte figure (31 percent of users hidden from their employer) describe the same behaviour; the shadow AI article explains how to find it.
  • <b>Using a model outside the provider’s own acceptable use policy, or letting contractors work outside yours.</b> The Annex XII chain and <code>GV-6.1-010</code> both point to the same gap: the people and the purposes the template forgot.

Green lights: making permitted use explicit

An AI acceptable use policy made only of prohibitions produces the behaviour it fears, because people do not stop using tools, they stop declaring them. The CNIL said it plainly on 18 July 2024 in its first guidance on deploying generative AI: define a list of authorised and prohibited uses, and train and raise the awareness of end users. The Commission’s Q&A adds that there is no one size fits all, which is an invitation to be specific about what is allowed.

Three lists make permitted use explicit. The first is the tool register, in three tiers: enterprise tools under a contract with data-processing terms and no training on your inputs; approved tools with restrictions, typically free tiers limited to public information; and prohibited tools, including personal accounts of otherwise approved products. The register should be the same object as your AI inventory, because the authority that asks for one will ask for the other.

The second is the data matrix: which data class may enter which tier. Public, internal, confidential and personal data map to tiers one to three with a yes, a no or a condition, and the condition is written down. The third is the task catalogue, with the review level each task family needs: drafting and summarising internal material (self-review), customer-facing text (second reviewer), anything that informs a decision about a person (named reviewer with authority, and the Article 26(2) requirements when the system is high-risk), anything published to the public (editorial control under Article 50(4)).

Add a service promise. Who approves a new tool, on which criteria, and within how many working days. A request route that answers in ten days removes most of the incentive for shadow AI; the vendor due diligence questions can be reused for every entry.

The AI acceptable use policy as Article 4 evidence

Since 2 August 2026 a national authority can ask a deployer what it did under Article 4. The amended text sets the standard: measures that support the development of AI literacy, taking into account technical knowledge, experience, education and training, the context of use and the persons affected; the article states that it does not require any specific level of literacy to be guaranteed for any individual. The new paragraph 2 commits the Commission and the Member States to support, including practical examples on the single information platform; the new paragraph 3 asks the AI Board to adopt recommendations taking into account European competence frameworks. As of 26 October 2026 we found no adopted Board recommendations, so the Commission’s Q&A and its living repository of AI literacy practices (published 4 February 2025, updated 10 August 2026) are the reference points, and the Commission notes that inclusion in the repository “does not automatically grant presumption of compliance with Article 4”.

The Q&A also removes two excuses. There is no certificate to buy, and there is no mandatory training programme to purchase; what the authority expects is a record of the measures taken. A minimal defensible file has five parts: the AI acceptable use policy itself with version, owner and approval date; acknowledgements from every covered person, including contractors; a role-based training register, since a developer, a recruiter and a marketing writer need different content; the tool register and a common AI taxonomy, which is CIPL’s fifth best practice in its Article 4 paper of 8 May 2025; and a feedback loop, its eighth, that records what changed after an incident or a new tool. ISO/IEC 42001 clause 7.3 on awareness expects the same chain, and the AI literacy article covers the role-to-competence matrix in detail.

On penalties, precision matters. Article 99(4) lists the obligations that carry the EU-level ceiling of EUR 15 million or 3 percent (Articles 16, 26 and 50 among them); Article 4 is not on that list. The consequences for Article 4 come from the rules Member States adopt under Article 99(1), and the Commission’s Q&A says the national authorities “could impose penalties and other enforcement measures”. A missing policy will more often surface as an aggravating fact in a GDPR, Article 50 or high-risk investigation than as a stand-alone fine.

Workers’ representatives and national rules

No template on the first page of results mentions the people who must be told. Article 26(7) is explicit for high-risk systems: before putting such a system into service at the workplace, employers “shall inform workers’ representatives and the affected workers”, following the Union and national rules on information of workers. It applies from 2 December 2027 for Annex III systems. The AI acceptable use policy is where that information is drafted, and the operators guide explains who counts as a deployer.

The national layer is older and applies now. In Germany, the Arbeitsgericht Hamburg decided on 16 January 2024 (24 BVGa 1/24), in the first German labour court case on ChatGPT at work, that guidelines allowing use in the browser through private accounts, with no employee data flowing to the employer, did not trigger co-determination under section 87(1) no. 1 or no. 6 BetrVG; the guidelines required staff to flag AI-generated results. The lesson travels: the moment a policy relies on monitoring logs, the works council and the data-protection rules on monitoring return. In France the CSE must be informed and consulted before the introduction of new technologies likely to affect working conditions (Code du travail, article L2312-8), and the CNIL guidance above is the reference. In Spain, article 64.4 d) of the Estatuto de los Trabajadores gives the works council the right to the parameters, rules and instructions of algorithms that affect working conditions, access to and maintenance of employment. In Italy, article 1-bis of d.lgs. 152/1997, inserted by the Decreto Trasparenza, creates information duties for fully automated decision or monitoring systems, which legge 132/2025 confirms. In Portugal, Lei 13/2023 added the same duty to article 106(3)(s) of the Código do Trabalho.

The AI acceptable use policy should therefore name the representative body, the moment it is informed (before approval of any tool that touches evaluation, task assignment or monitoring), and the person who signs that it was done. An AI governance committee with a seat for HR is the simplest way to keep that record current.

Writing the AI acceptable use policy in 8 steps

  1. <b>Inventory the tools in use, including shadow AI.</b> Pull the SaaS and browser data, survey teams, and record every tool, account type and purpose. The result is the first version of the register and the baseline for the AI inventory.
  2. <b>Tier the tools and file each provider’s acceptable use policy.</b> For every entry, capture the provider’s usage policy, its data-processing terms and its position on training on your inputs; assign tier one, two or three. This is the Annex XII chain made concrete.
  3. <b>Define the data classes and the matrix.</b> Reuse the information classification you already have, add “personal data of identifiable people” as its own line, and decide class by tier.
  4. <b>Write green lights and red lines, each mapped to a clause.</b> Use the clause map above; a rule without a clause behind it will be challenged, a clause without a rule in front of it will be missed.
  5. <b>Set review and disclosure rules.</b> Human review before any output informs a decision about a person; editorial control before any AI-written text reaches the public (Article 50(4)); disclosure for deepfakes; marking for synthetic media, with the 2 December 2026 transition in mind.
  6. <b>Inform or consult worker representatives under national law.</b> Do it before the policy is approved, record the date and the body, and plan the Article 26(7) notice for any high-risk system.
  7. <b>Roll out and record.</b> Collect acknowledgements, deliver role-based training, and keep the Article 4 record: who was trained on what, when, and what the policy version was.
  8. <b>Enforce and review.</b> Monitor proportionately and transparently, keep an exception register, route incidents through the channel you already use for AI incident reporting, and review the policy at least annually (A.2.4) or when a tool, a model or a law changes.

The versioning, the acknowledgements and the review calendar are what an AI acceptable use policy needs from a policy management tool, and the AI Sigil platform keeps them next to the inventory and the controls they feed.

FAQ

<b>Is an AI acceptable use policy legally required in the EU?</b>

No single article says “write an acceptable use policy”. Several articles assume one. Article 4 requires measures that support AI literacy, and the Commission expects an internal record of them; Article 50 requires disclosure and review practices that only a written rule can make consistent; Article 26 will require organisational measures and worker information for high-risk systems from 2 December 2027. ISO/IEC 42001 control A.9.2 is the closest thing to an explicit requirement for certified organisations. The policy is the cheapest evidence that these measures exist.

<b>What is the difference between an AI policy and an AI acceptable use policy?</b>

The AI policy states what the organisation commits to and who is accountable: principles, roles, the governance body, the risk approach. It maps to ISO/IEC 42001 clause 5.2 and control A.2.2. The AI acceptable use policy is the rulebook for users: approved tools, permitted tasks, data limits, review and disclosure duties, consequences. It maps to controls A.9.2 and A.9.4. The first is approved by the board, the second is acknowledged by every user.

<b>Does an AI acceptable use policy satisfy Article 4 of the AI Act?</b>

Not on its own, but it is the backbone of the file. Article 4 asks for measures that support AI literacy, assessed against the context of use and the people involved. An AI acceptable use policy that names approved tools and risks, is acknowledged by staff, is backed by role-based training and is reviewed regularly is exactly the kind of measure the Commission’s Q&A describes, and the record of those steps is what a national authority will ask for.

<b>What must employees never put into a public AI tool?</b>

Personal data of customers, colleagues or candidates; source code, trade secrets and unreleased financial or strategic information; anything covered by a confidentiality undertaking with a client; and anything the provider’s own usage policy prohibits. For tier-two tools the safe rule is public information only. The AI acceptable use policy should state the rule per data class, not as a general warning, and it should say what to do after an accidental paste: report it through the incident channel, the same day.

<b>Do contractors and suppliers have to follow it?</b>

Yes, and the AI acceptable use policy should say so. Article 4 covers “other persons dealing with the operation and use of AI systems” on the organisation’s behalf, NIST action <code>GV-6.1-010</code> names contractors, consultants and third-party personnel, and ISO/IEC 42001 control A.10.3 covers suppliers. The practical mechanism is contractual: the policy is annexed to the engagement, the contractor acknowledges it, and the supplier’s own acceptable use policy is checked against yours during due diligence.

<b>How often must it be reviewed?</b>

At least once a year, and whenever a trigger fires: a new tool or model, a provider changes its usage policy, a regulatory date passes, or an incident reveals a gap. ISO/IEC 42001 control A.2.4 expects a planned review of the AI policy, and the AI acceptable use policy should follow the same cadence. The 2 December 2026 marking transition and the 2 December 2027 high-risk date are two triggers already on the calendar.

Conclusion

The AI acceptable use policy stopped being an IT formality when the EU AI Act started using the term and when Article 4 became enforceable. Written well, an AI acceptable use policy is the single document that shows an authority the measures you took, shows an auditor the processes behind control A.9.2, and shows your people the line between a useful tool and a reportable incident. Start from the inventory, tier the tools, file the providers’ policies, map every rule to its clause, inform the people the law says must be informed, and keep the record. The template gets you a document; the clause map gets you evidence. If you want the register, the acknowledgements and the review calendar in one place, the AI Sigil platform is built to hold them alongside your AI governance controls.

AI Security Framework: Which One Will an Auditor Accept?

AI security framework comparison: SAIF, CSA AICM, DASF, OWASP, ATLAS, NIST and ISO/IEC 27090, mapped to EU AI Act Article 15 and the evidence auditors accept.

AI Lifecycle Management: Stages, Duties and Evidence

AI lifecycle management from intake to retirement: the stages, the EU AI Act duty at each one, change control after the Omnibus, and the evidence to keep.

AI Acceptable Use Policy: The Two Policies the AI Act Names

An AI acceptable use policy is now evidence: Article 4 enforced since 2 August 2026, Article 50, ISO 42001 A.9.2, NIST AI 600-1. Clause map and 8-step build.

NIST AI 100-2: The Attack Taxonomy as AI Act Evidence

NIST AI 100-2 explained: the NISTAML attack IDs, what the 2025 edition changed, and how to turn the taxonomy into EU AI Act Article 15 evidence.

International AI Safety Report 2026: From Science to Evidence File

The International AI Safety Report 2026, read as compliance evidence: what it says, where it fits under Article 55 and the GPAI Code, and what to log.

AI Liability in 2026: Who Pays, and on What Evidence

AI liability turns on evidence from 9 December 2026: what the new EU Product Liability Directive presumes, who answers, and the file to keep ready.