Skip to content

Acceptable Use Policy

The AUP is the single most referenced document in the program. Every engineer is expected to have read it; every auditor will ask for it; every incident begins with "what does the AUP say about this?"

This page describes what a good AUP contains, independent of any specific company's wording. For the drafting meeting that produces version 0.1, see the AUP drafting worksheet.

Structure

A permanent AUP (Phase 2 onward) typically has these sections. An interim AUP (Phase 0) collapses most of these into one page.

§ Section Length guide
1 Purpose and scope 1 page
2 Approved tools 1 page (updated as tools change)
3 Data handling 2 pages
4 Developer obligations 2 pages
5 Agent-specific rules 1 page
6 IP and licensing 1 page
7 Incident reporting 1 page
8 Exceptions 1 page
9 Review cadence & change log 0.5 page

Total: around 10 pages. Longer AUPs go unread.

Non-negotiables

Regardless of company size or sector, these clauses belong in every AUP:

  1. A single named incident channel with an SLA.
  2. An explicit "prohibited data" list: data classes that must never be sent to any AI tool.
  3. An approved-tools list: not "anything with SSO", but specific tools with specific conditions.
  4. A disallowance of consumer-tier / personal accounts for company work.
  5. A verification obligation. Engineers must verify output, and AI-assisted merges carry the same review obligation as any other.
  6. An exceptions process: named owner, timeframe, evidence required.
  7. A review cadence: ≤ 3 months for interim AUP, ≤ 12 months for permanent AUP.
  8. An acknowledgement requirement. Every in-scope staff member acknowledges each version, tracked.
  9. A per-tool monthly spend cap, defined and enforced (technically where possible) before broad rollout and reviewed at each contract renewal. Caps are tracked per tool independently; a combined budget pool allows a single high-consumption tool to exhaust the annual allocation before the overrun is visible.

Drafting principles

  • Write for the engineer who will act on it. A clause that only a lawyer can parse will be ignored.
  • Reference, don't duplicate. If the retention policy lives in another document, link rather than copy.
  • Use roles, not names. "The CoE Lead" not "Jane Smith." Names change.
  • Cite the external standard when possible. "Per NIST AI RMF Govern function" gives auditors the crosswalk for free.
  • Include negative space. What is out of scope deserves a sentence as much as what is in.

Enforcement

  • HR alignment. Acknowledgement is recorded through the HR system (or equivalent); non-acknowledgement by the deadline is a compliance issue.
  • Tool-level enforcement. SSO, SCIM, and gateway rules enforce the approved-tools clause technically. Policy alone is insufficient.
  • Enforcement placement. Each security control has a named enforcement layer (endpoint, network/platform, or vendor) and a named owner for each layer it spans. The S.H.I.E.L.D. enforcement placement model governs which layer is authoritative for each control type. When the approved stack includes multiple tools, a per-tool enforcement matrix documents where each control is enforced and compensates for vendor gaps at the network layer.
  • Review-level enforcement. AI-adjacent PRs are tagged; tech leads are trained to check tag presence during review.
  • Blame-free reporting. Good-faith incident reports are not a disciplinary matter; not reporting is.

Version and change control

  • AUP lives in version control (git, internal wiki with history, etc.) alongside the Decision Records that drove each change.
  • Every material change produces a DR with status accepted.
  • AUP version bumps are recorded internally (the company's AUP is internal; this framework is only the public scaffolding).

Sizing guidance

Sizing guide

  • Small (< 50): One-page AUP covers it all. Keep the approved-tools list to 1–3 tools. Review quarterly.
  • Mid (50–500): 5–7 page AUP with per-section owners. Review every 6 months.
  • Enterprise (500+): 8–10 page AUP, with BU-specific addenda for distinct sectors. Review annually, with interim patches.
  • Regulated: add sector-specific addenda (HIPAA, PCI, DORA). Map every clause to a control in the regulatory crosswalk. Expect audit-level scrutiny.

Common failure modes

  • "The AUP is six months old and nobody remembers what changed." Add a changelog section; refresh on review cadence.
  • "Engineers use unapproved tools anyway." Policy without technical gates fails. Pair AUP with gateway or tenant-level controls.
  • "Legal rewrote it without Engineering; nobody follows it." AUP requires a working group; see AUP drafting worksheet.
  • "We have five AUPs (one per BU) that conflict." One company-wide AUP, with addenda for BU-specific clauses. Conflicts get a DR.

External references

  • NIST AI RMF1, Govern function (G2, G3).
  • ISO/IEC 42001:20232, clauses 5 and 8 (policy, operational controls).
  • ICO (UK Information Commissioner's Office) guidance on AI and data protection3. Useful when the AUP interacts with UK GDPR.

Next

  1. NIST, NIST AI 100-1, Jan 2023. ↩

  2. ISO, ISO/IEC 42001:2023. ↩

  3. UK ICO, Guidance on AI and data protection. ↩