AI Compliance · 2026-07-30 · 10 min read

AI Acceptable Use Policy: What to Include in 2026 (Guide)

Most AI acceptable use policies fail the same way: a stale tools appendix nobody trusts. Here is the seven-section structure that holds up in 2026 — an approved-tools list generated from a live registry, concrete prohibited inputs, and training that doubles as your EU AI Act Article 4 evidence.

An AI acceptable use policy (AI AUP) is the internal rulebook that defines which AI tools employees may use, what data they must never feed into them, when they must disclose that AI was involved, and how new tools get approved. In 2026 it is also compliance evidence: EU AI Act Article 4 and a growing list of US state laws assume your staff know these rules — and that you can prove it.

Why every company needs an AI acceptable use policy in 2026

Employees adopt AI faster than IT can review it, and regulators have stopped treating that gap as a technicality:

  • EU AI Act Article 4, in force since 2 February 2025, requires both providers and deployers of AI systems to ensure their staff have adequate AI literacy. A written policy plus documented training is the most direct evidence of that duty.
  • EU AI Act Article 50 transparency obligations apply from 2 August 2026, backed by the general penalty regime of up to €15 million or 3% of worldwide turnover, in force since 2 August 2025. Your AUP pushes those duties down to the people who launch chatbots and publish AI content — our Article 50 transparency obligations breakdown covers the substance.
  • US state law is already live. Illinois HB 3773 (775 ILCS 5/2-102(L)), in force since 1 January 2026, turns AI use in employment decisions into civil-rights exposure and adds a notice duty to employees. Texas TRAIGA (HB 149), also in force since 1 January 2026, carries penalties up to $200,000 for uncurable violations. Maine's chatbot disclosure law (10 M.R.S. §1500-DD) has been in force since 16 September 2025. See the complete map of US state AI laws.

An AUP does not make you compliant by itself — it translates legal obligations into rules an employee can follow on a Tuesday afternoon.

What should an AI acceptable use policy include?

A workable AI AUP in 2026 has seven sections — anything shorter leaves enforcement ambiguous; anything longer goes unread.

#SectionWhat it does
1Scope and definitionsSays who is covered and what counts as an "AI tool"
2Approved-tools listNames permitted tools, with per-tool conditions
3Prohibited inputsDefines the data that must never enter an AI tool
4Disclosure requirementsSays when staff must reveal AI involvement
5New-tool request pathGives employees a fast, legitimate approval route
6Training and acknowledgmentCreates your Article 4 literacy evidence
7EnforcementSets consequences people believe and follow

1. Scope and definitions

Cover employees, contractors, and anyone with access to company data. Define "AI tool" broadly enough to catch how AI actually arrives: standalone apps, AI features inside SaaS you already license, browser extensions, and direct API access. Most shadow AI enters through the middle two categories, not through new signups.

Sample language theme: the policy applies to any system that generates content, makes or supports decisions, or processes company data using machine learning — regardless of whether the company pays for it.

2. The approved-tools list — and why it cannot be a static appendix

This is the section employees actually consult. A list frozen into a PDF appendix goes stale within weeks; generate it from your live AI inventory (more below), and give each entry conditions, not just a name:

  • which teams may use it,
  • which data classifications may enter it,
  • which use cases are approved (drafting, coding, customer-facing output),
  • whether output needs human review before it ships.

Sample language theme: approve tools for something, never in the abstract — "approved for internal drafting with public and internal data" is enforceable; "approved" alone is not.

3. Prohibited inputs: what employees must never paste into AI tools

Be concrete. "Use good judgment" is not a control. Name the categories:

  • customer personal data and anything covered by a privacy notice or DPA,
  • credentials, API keys, secrets, security configurations, and vulnerability details,
  • material non-public financial information,
  • anything received under NDA,
  • source code, where your licensing or IP posture requires it.

Pair the list with the reason: many AI vendors train on customer inputs by default. That is a vendor-diligence problem as much as an employee-behavior one — our AI vendor risk assessment questions cover what to verify before a tool reaches the approved list.

One quieter trap deserves its own clause: California AB 2013 (Civ. Code §§3110–3111), in force since 1 January 2026 with no size threshold, requires developers of generative AI made publicly available to Californians to publish a 12-element training-data summary — and fine-tuning expressly counts as "substantial modification" (§3110(d)). An employee who fine-tunes a model for a public-facing feature can create developer duties nobody planned for. Prohibit unauthorized fine-tuning explicitly.

4. Disclosure requirements: when staff must say "this is AI"

Disclosure duties come from several directions at once; the AUP should collapse them into simple internal rules:

  • EU AI Act Article 50 (applies from 2 August 2026): inform people they are interacting with an AI system; mark AI-generated or manipulated content; plus deep-fake and emotion-recognition disclosures.
  • Maine 10 M.R.S. §1500-DD (in force since 16 September 2025): if a reasonable consumer could be misled into thinking they are chatting with a human, clear disclosure is required — up to $10,000 per intentional violation.
  • Utah AIPA (Utah Code ch. 13-77, as narrowed by SB 226): on-request disclosure for generative AI in consumer transactions; prominent disclosure for regulated professionals in high-risk interactions.
  • California BOT Act (BPC §17940, in force since 2019): bots must not mislead to incentivize purchases or votes without disclosure.

Sample language theme: give staff one default — when in doubt, disclose — and route edge cases (deep-fakes, voice agents, hiring tools) to compliance instead of asking employees to parse statutes.

5. The new-tool request path

If the only sanctioned answer is "no," employees route around the policy. A credible path:

  1. Employee submits a short request — tool name, use case, and the data classes involved. Two minutes, not a procurement form.
  2. Vendor assessment runs against a standard checklist — training-on-inputs defaults, retention, subprocessors, security posture.
  3. Compliance classifies the use case — does it touch employment decisions, consumer disclosure duties, or EU AI Act obligations?
  4. The decision lands in the AI registry with conditions attached — approved, restricted, or denied with a stated reason.
  5. The approved-tools list updates automatically from the registry.

Publish a service-level target — five business days is realistic; the faster the legitimate path, the less traffic the illegitimate one gets.

6. Training and acknowledgment: your Article 4 evidence

EU AI Act Article 4 has been in force since 2 February 2025, and it applies to deployers — companies that merely use AI — not just those that build it. The AUP is where you anchor the evidence:

  • annual (or on-material-change) acknowledgment, recorded per person,
  • role-based training — the team generating synthetic media needs different depth than finance,
  • records you can produce on request. California's FEHA automated-decision regulations (2 CCR §§11008.1, 11009(f)), in force since 1 October 2025, expect four-year records (§11013(c)) for covered employment uses.

Shieldra ships in-product Article 4 literacy courses and an AI policy template set, so training evidence lives beside your tool inventory — see what's included.

7. Enforcement that people actually believe

Graduated enforcement outperforms zero-tolerance: good-faith mistakes reported promptly get coaching, not discipline; deliberate exfiltration of prohibited data follows the same track as any other data-handling violation. A policy that threatens termination for pasting a paragraph into a chatbot will never be reported against — and unreported incidents become breaches.

Why the approved-tools list should generate from your AI registry

The biggest failure mode of AI AUPs is the stale appendix: AI features ship inside already-approved SaaS constantly, and quarterly review cannot keep pace.

Static appendixRegistry-generated list
FreshnessStale within weeksUpdates when a tool's status changes
CoverageTools someone remembered to listEverything discovery finds, including AI in existing SaaS
ConditionsA name, at bestData classes, teams, and use cases per tool
Audit story"Here is the PDF from March"Live list with change history
Shadow AIInvisible until an incidentSurfaced and triaged continuously

The mechanics: discover what is actually in use, record every finding in a central AI registry with an approval status, and render the AUP's approved-tools section from that registry. Our shadow AI discovery guide walks through the discovery half; Shieldra matches findings against 284 known AI tools and a 40-profile verified vendor catalog, so training-on-your-data defaults arrive pre-documented.

How to roll out an AI acceptable use policy: 6 steps

  1. Run discovery first. Write the policy against what employees actually use. A policy that bans the five most-used tools on day one fails on day two.
  2. Draft the seven sections above and keep the document under four pages. Length is inversely correlated with compliance.
  3. Map your legal surface — duties depend on where you operate and what your AI touches. For the EU side, the free EU AI Act checker returns a risk tier and role-scoped obligations with citations in about three minutes.
  4. Pilot with one department for two weeks and fix the friction — usually the request path.
  5. Launch with training and acknowledgment together, so the Article 4 evidence exists from day one.
  6. Review on two clocks: the approved-tools list continuously via the registry; the policy text annually or when the law moves — as Article 50 does on 2 August 2026.

FAQ

What is an AI acceptable use policy?

An AI acceptable use policy is an internal document that governs how employees use AI tools at work: which tools are approved, what data may enter them, when AI involvement must be disclosed, how new tools get approved, and what happens when rules are broken. It covers employees and contractors, and AI features inside existing software as well as standalone tools.

Is an AI acceptable use policy legally required?

No law mandates a document with that name. But EU AI Act Article 4, in force since 2 February 2025, requires providers and deployers to ensure staff AI literacy, and state laws such as Illinois HB 3773 (in force since 1 January 2026) and Maine 10 M.R.S. §1500-DD (in force since 16 September 2025) impose notice and disclosure duties your staff must carry out. An AUP with training and acknowledgment is the standard evidence for all of it.

What data should employees never put into AI tools?

At minimum: customer personal data, credentials and API keys, security details, material non-public financial information, and anything under NDA. Many AI vendors train on user inputs by default, so data pasted into an unapproved tool may leave your control permanently. Unauthorized fine-tuning deserves its own prohibition: California AB 2013 (Civ. Code §3110(d)) treats it as substantial modification that can trigger developer-level training-data disclosure duties.

How often should an AI acceptable use policy be updated?

Review the policy text at least annually, and immediately when a new obligation starts applying — for example, EU AI Act Article 50 transparency duties apply from 2 August 2026. The approved-tools list should not wait for review cycles: generate it from a live AI registry so it updates whenever a tool is approved, restricted, or banned.

Who should own the AI acceptable use policy?

Give it one accountable owner — typically the CISO or compliance lead — with named input from IT (discovery), legal (jurisdiction mapping), and HR (training and enforcement). Distributed ownership without one accountable name is how the appendix goes stale and enforcement goes silent.