Skip to content

Worksheet — Acceptable Use Policy drafting

Phase: 0: Readiness (interim AUP); revisited in Phase 2 (permanent AUP). Duration: 90 minutes. Primary output: Interim AUP v0.1 (one page) + Decision Record.

Why this meeting matters

The most common shape of a first AI incident is predictable: an engineer pastes source code or customer data into a public model to "ask a question" and then the company spends weeks unpicking what was exposed. Samsung's 2023 ChatGPT leak1 is the canonical example: an engineer pasted proprietary source code into a public model, triggering a company-wide ban.

An AUP is the policy that makes that incident avoidable rather than inevitable. The interim AUP is short by design: a 70%-correct policy that engineers read and follow is better than a 95%-correct policy that sits in draft for six months.

Pre-work

Who to invite

Sizing guide

  • Small (< 50): CISO-or-equivalent + senior engineer + Legal/Ops contact. One session.
  • Mid (50–500): CISO + Head of Privacy + Legal + 2 engineers + 1 tech lead. One session with async review.
  • Enterprise (500+): CISO + CPO + Legal + Procurement + 2 Eng leads + 1 AppSec + 1 SRE + BU champion. Two sessions: draft then review.
  • Regulated: add Head of Compliance and sector-specific SME (e.g., HIPAA Privacy Officer).

In the room:

  • CISO or delegate: owns data-handling and incident sections.
  • Legal or delegate: owns IP, contracts, vendor terms.
  • Privacy / Data Protection: owns personal data, cross-border issues.
  • At least two senior engineers: they must read aloud whether each clause is followable in their real day-to-day work.
  • One tech lead: they will have to coach the policy to others.

Explicitly not required: the tool vendors. Do not invite the vendor to the AUP meeting; they have a commercial interest in the policy being permissive.

Materials to circulate 48 hours in advance

  1. The leadership charter if it exists; its scope section feeds the AUP.
  2. The risk matrix, so data categories are anchored.
  3. The draft AUP template below; the meeting is an edit session.
  4. Anonymised summaries of 2–3 public incidents (Samsung, Replit agent DB wipe2, DeepSeek ClickHouse exposure3). Ground the meeting in what can go wrong.

Agenda (90 minutes)

Time Topic Owner
0–10 Purpose, pre-read check, ground rules (e.g., "the AUP is a floor, not a ceiling"). Facilitator
10–25 Data classes. Which data categories must never be sent to AI tools, regardless of vendor? CISO + Privacy
25–40 Approved tools. Which 1–3 tools are explicitly allowed? What are the conditions? CISO + Legal
40–55 Developer obligations. What is the engineer required to do? (Verify, review, log, report.) Eng leads
55–65 Incident reporting. Single email/channel. Response SLA. CISO
65–75 Exceptions. Who can approve a one-off, and how? CISO + Sponsor
75–85 Draft live. Scribe fills the one-page template on screen. Scribe
85–90 Sign, or name the blocker. Assign any follow-ups. All

Discussion prompts

Data-classes prompts

  • Of our data classes (public, internal, confidential, restricted), which must never go to any external AI service?
  • Can the permissive list distinguish between vendors with contractual protections (enterprise tier, no training on your data) vs. those without?
  • What about source code? (Most companies allow it for approved enterprise tools; prohibit it for public tools.)
  • What about prompts that describe sensitive data without including it? (Often where the real leak happens: design questions contain architecture and secrets indirectly.)

Approved-tools prompts

  • Which tools are explicitly allowed for use on company work, and under what conditions (SSO, tenant, enterprise tier, jurisdiction)?
  • Is use of personal accounts on approved tools prohibited? (Usually yes; personal accounts lack enterprise controls and audit logs.)
  • What about free / consumer tiers of the same vendor (e.g., ChatGPT vs. ChatGPT Enterprise)? (Usually disallow consumer tiers.)
  • Which tools are explicitly disallowed right now, and why? Can we name them, or should we describe the pattern?

Developer-obligations prompts

  • Must every AI-generated change be reviewed? By whom?
  • Must AI-adjacent changes be flagged in commit messages or PR descriptions? (Recommended for audit trail.)
  • What testing/verification is required before merge? (See V.E.R.I.F.Y..)
  • Are there categories where AI assistance is prohibited regardless (e.g., cryptographic primitives, key management, access control logic)?

Incident-reporting prompts

  • Where do engineers send an incident report? (One channel only.)
  • What is the SLA for triage? (Typically same business day.)
  • What data should they preserve? (Prompt, output, timestamp, tool version.)
  • What is the penalty model? Blame-free reporting is the standard. Say so explicitly.

Exceptions prompts

  • Who can approve a one-off exception (e.g., a team that wants to trial a new tool outside the approved list)?
  • What is the timeframe? (Typically 30 days with a written review.)
  • What is logged? (Request, rationale, approver, expiry.)

The interim AUP template (one page)

Copy into a durable location. Aim for ≤600 words. If it exceeds a page, you are over-specifying for the interim version.

Acceptable Use Policy — AI-Assisted Development (Interim v0.1)

Effective: 2026-04-24 Owner: role, e.g., CoE Lead or CISO Next review: 2026-07-24 (or sooner if triggered)

1. Scope. This policy applies to all engineers, contractors, and other staff authoring or reviewing code for company. It covers AI coding assistants, code-generation agents, and AI models used to analyze or transform company source code, data, or documents.

2. Approved tools.

  • Tool A — conditions: tenant, SSO, audit logs required
  • Tool B — conditions: ...

Any tool not on this list must be reviewed via the Exceptions process (section 7) before use on company work.

3. Prohibited data. The following must never be sent to any AI service, including approved tools unless the Data Handling Addendum explicitly permits it:

  • Customer personal data or personally identifiable information.
  • Regulated data (e.g., PHI, PCI, classified data for regulated industries).
  • Authentication material: secrets, keys, tokens, passwords, credentials.
  • Source code of systems tagged Critical in the risk register, unless within an approved enterprise tenant.
  • Contract or HR information about identifiable individuals.

4. Developer obligations. When using approved AI tools, engineers must:

  • Verify outputs before use — a suggestion is not a review.
  • Review AI-generated code as they would any other contribution; peer review is required for merge.
  • Flag AI-adjacent changes per the team's PR template.
  • Preserve prompts and outputs long enough to reproduce an incident (retention per section 6).

5. Prohibited uses.

  • Using personal or consumer-tier accounts for company work on the approved tools.
  • Using any unapproved AI service on company data.
  • Deploying autonomous agents with write access to production without an approved Runbook and Exception.
  • Committing AI-generated code to security-sensitive paths without sign-off from AppSec (paths listed in appendix).

6. Data handling & retention. Prompts and outputs from approved tools are company records. They are retained per the standard Engineering Records retention policy (link). Personal data must not be present in prompts in any case.

7. Incident reporting. Report any incident or near-miss to single email or Slack channel within one business day. Preserve the prompt, the output, the tool version, and the timestamp. Reporting in good faith is not a disciplinary matter; failing to report is.

8. Exceptions. Exceptions are granted by named role, valid for up to 30 days, and must be reviewed before renewal. Exception requests include: purpose, tool, data classes, mitigation, expiry date.

9. Enforcement and review. This policy is owned by role. It is reviewed every 3 months or after any incident classified Category 2 or above, whichever is sooner. Material changes are versioned and announced.

10. Acknowledgement. All in-scope staff must acknowledge this policy in the HR system within 10 working days of publication or hire.

# Acceptable Use Policy — AI-Assisted Development (Interim v0.1)

**Effective:** 2026-04-24
**Owner:** <role, e.g., CoE Lead or CISO>
**Next review:** 2026-07-24 (or sooner if triggered)

## 1. Scope

This policy applies to all engineers, contractors, and other staff
authoring or reviewing code for <company>. It covers AI coding
assistants, code-generation agents, and AI models used to analyze or
transform company source code, data, or documents.

## 2. Approved tools

- <Tool A — conditions: tenant, SSO, audit logs required>
- <Tool B — conditions: ...>

Any tool not on this list must be reviewed via the Exceptions process
(section 7) *before* use on company work.

## 3. Prohibited data

The following must **never** be sent to any AI service, including
approved tools unless the Data Handling Addendum explicitly permits it:

- Customer personal data or personally identifiable information.
- Regulated data (e.g., PHI, PCI, classified data for regulated industries).
- Authentication material: secrets, keys, tokens, passwords, credentials.
- Source code of systems tagged Critical in the risk register, unless
  within an approved enterprise tenant.
- Contract or HR information about identifiable individuals.

## 4. Developer obligations

When using approved AI tools, engineers must:

- **Verify** outputs before use — a suggestion is not a review.
- **Review** AI-generated code as they would any other contribution;
  peer review is required for merge.
- **Flag** AI-adjacent changes per the team's PR template.
- **Preserve** prompts and outputs long enough to reproduce an incident
  (retention per section 6).

## 5. Prohibited uses

- Using personal or consumer-tier accounts for company work on the
  approved tools.
- Using any unapproved AI service on company data.
- Deploying autonomous agents with write access to production without
  an approved Runbook and Exception.
- Committing AI-generated code to security-sensitive paths without
  sign-off from AppSec (paths listed in appendix).

## 6. Data handling & retention

Prompts and outputs from approved tools are company records. They are
retained per the standard Engineering Records retention policy
(<link>). Personal data must not be present in prompts in any case.

## 7. Incident reporting

Report any incident or near-miss to <single email or Slack channel>
within **one business day**. Preserve the prompt, the output, the tool
version, and the timestamp. Reporting in good faith is not a
disciplinary matter; failing to report is.

## 8. Exceptions

Exceptions are granted by <named role>, valid for up to **30 days**,
and must be reviewed before renewal. Exception requests include:
purpose, tool, data classes, mitigation, expiry date.

## 9. Enforcement and review

This policy is owned by <role>. It is reviewed every **3 months** or
after any incident classified Category 2 or above, whichever is
sooner. Material changes are versioned and announced.

## 10. Acknowledgement

All in-scope staff must acknowledge this policy in the HR system
within 10 working days of publication or hire.

Outputs

  • Interim AUP v0.1 published to a durable location within 48 hours.
  • Decision Record covering tools chosen, data classes prohibited, and exceptions process.
  • Acknowledgement tracker started (HR system is ideal; spreadsheet is acceptable).
  • Training update: this AUP becomes a module in the pilot training (Training needs).

Follow-ups

  • Within 48 hours: publish + announce (all-hands, email, or Slack).
  • Within 7 days: all in-scope staff acknowledge.
  • Within 30 days: review incident log; apply learnings.
  • Within 90 days: review AUP holistically; plan migration to permanent version in Phase 2.

Facilitator tips

  • Draft lives on screen during the meeting. Do not leave and "send it around"; it will not come back.
  • Read every clause aloud. If anyone in the room can't explain what it means in plain language, rewrite it.
  • Test against scenarios. Walk through: "Engineer X pastes snippet Y into tool Z, is this allowed?" for at least three real situations before signing.
  • Avoid naming people. Use roles, not names; names change.

Anti-patterns

Don't

  • Don't copy a vendor's sample AUP wholesale. They will be permissive on things that matter to them. Your AUP must reflect your data classes and your tolerances.
  • Don't make the AUP 10 pages. No one will read it. Link out to the retention policy, the risk matrix, and the IR playbook rather than duplicating them.
  • Don't bury "incident reporting" in a footnote. It should be one of the most visible sections.
  • Don't set a review cadence longer than 3 months for the interim AUP. The space moves fast enough that quarterly review is the floor.

Next

  1. Bloomberg, "Samsung Bans Staff's AI Use After Spotting ChatGPT Data Leak", May 2023. ↩

  2. Replit agent deleted production database during code freeze, Jul 2025. See Evidence: security incidents. ↩

  3. Wiz Research, "Wiz Research Uncovers Exposed DeepSeek Database", Jan 2025. ↩