◆ Quick answer
A GenAI Employee AUP should include a Data Classification × Tool Tier matrix, an Approved Tool List with vendor DD status (DPA, SOC 2, BAA, training opt-out), 15+ Pre-Approved Use Cases, a low-touch Employee Use Case Intake Form with cascading auto-routing, Prohibited Uses (PII into consumer tools, MNPI anywhere, credentials), Output Handling Rules by output type, and an AI Incident Response Runbook.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ 13-tab Excel workbook (60 formulas, 3 data validations, 9 conditional formatting groups)
- ◆ Data Classification × Tool Tier Matrix — Public / Internal / Confidential / Restricted mapped to Consumer / Enterprise / Prohibited
- ◆ Approved Tool List — 10 starter entries with vendor DD status (DPA, SOC 2, BAA, training opt-out, data residency)
- ◆ 15 Pre-Approved Use Cases — the productivity payoff (employees self-serve common patterns)
What is this template for?
A Generative AI Acceptable Use Policy is the framework compliance, IT, and AI governance leads use to govern employee use of GenAI tools (ChatGPT, Claude, Microsoft Copilot, Google Gemini, GitHub Copilot, and AI features embedded in third-party SaaS) — separately from production AI/ML systems that go through the model risk management framework. The useful version is data-classification-led (Public / Internal / Confidential / Restricted), tool-tiered (consumer / enterprise / prohibited), and includes a pre-approved use cases list so employees self-serve common patterns. A low-touch employee intake form auto-routes anything new (new tool, new use case, new data class) without bottlenecking on compliance for every prompt.
◆ Audience
Who needs this.
- ◆ Your employees are already using ChatGPT or Copilot and you need a structured framework — not a ban that pushes use underground.
- ◆ Your existing AI policy was built for production model risk (SR 11-7 / interagency 2026 MRM / NIST AI RMF) and doesn't cover employee-facing GenAI tools.
- ◆ You want a Pre-Approved Use Cases list so employees self-serve common patterns instead of bottlenecking on compliance for every prompt.
- ◆ You need a Vendor DD Register documenting DPA / SOC 2 / training opt-out / BAA status for each approved tool.
- ◆ You have a shadow AI problem and need detection (DLP, browser allow-list, shadow AI scanning) plus a non-punitive intake culture so employees self-report.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| Data classification | What you input determines what tier of tool you can use — Confidential and Restricted data has hard restrictions. | Public (published earnings); Internal (drafts); Confidential (customer data); Restricted (MNPI, PHI, credentials, attorney-client privileged) |
| Tool tier and vendor DD status | Enterprise tools have DPAs, training opt-out, and security certifications; consumer tools do not. | Microsoft 365 Copilot — Enterprise, DPA in place, SOC 2 Type II, training opt-out confirmed, US/EU data residency |
| Pre-approved use case category | Common patterns shouldn't require an intake form — employees self-serve when their use case is on the list. | Drafting internal emails (Internal data, Enterprise tool); summarizing public earnings calls (Public data, any tier); code review in approved repos (Confidential code, GitHub Copilot Business) |
| Prohibited uses (firm "no" list) | Some uses have no exception pathway — these are categorical prohibitions. | No customer PII into consumer tools; no MNPI in any AI tool; no credentials or API keys; no AI-only adverse-action decisions about customers; no local LLMs on personal devices |
| Output handling required review | AI-generated content needs human review before it reaches customers, regulators, or production code — review depth varies by destination. | Internal email = light author review; customer-facing mass = Compliance pre-review; regulatory filing = Compliance + Legal review; adverse-action communication = meaningful human review (cannot be AI-only) |
| Detection & monitoring layer | Policy alone isn't enough — DLP and browser allow-list backstop the AUP. | DLP blocks paste of SSN/credit-card/credential patterns to AI domains; browser blocks unapproved AI extensions; quarterly shadow AI scanning of network traffic |
| Vendor DD on each approved tool | Vendor security posture changes; the register tracks DPA dates, SOC 2 currency, BAA availability, training opt-out posture, and re-review cadence. | DPA on file 2026-Q1, SOC 2 Type II 2025 (refresh due 2026-Q4), BAA available, training opt-out written confirmation, US data residency |
| AI incident response runbook | When something goes wrong (PII paste, MNPI exposure, hallucinated regulatory filing, prompt injection) — improvised response is too slow. | 8-incident runbook with severity (Low / Medium / High / Critical), 0–4 hour immediate action, day-1 action, owner, follow-up |
◆ Worked example
Example Data Classification × Tool Tier row
| Data class | Confidential — customer data, source code, vendor contracts, employee PII |
|---|---|
| Tool tier permitted | Enterprise AI only (M365 Copilot, Claude for Enterprise, GitHub Copilot Business, ChatGPT Enterprise) with no-training opt-out confirmed and DPA in place |
| Prohibited tier | Consumer AI tools (free ChatGPT, Claude.ai, Gemini consumer) — these may train on inputs and data leaves company control |
◆ Implementation roadmap
How to roll this out.
Align Data Classification Matrix with your existing Information Classification Policy
Owner · AI Governance Lead with CISO + Privacy
Output · Four-class matrix (Public / Internal / Confidential / Restricted) mapped to tool tiers; employees know which tier they can use for which class
Populate Approved Tool List with your organization's actual enterprise tenants and contract details
Owner · IT + AI Governance Lead
Output · Tool list with vendor DD status (DPA, SOC 2, BAA, training opt-out) per tool; consumer tools restricted to personal use with Public data only; prohibited tools (local LLMs, AI browser extensions, etc.) explicitly listed
Customize Pre-Approved Use Cases (15+ common patterns) so employees self-serve
Owner · AI Governance Lead with business leads
Output · List of common patterns (drafting emails, code review, summarizing public docs, etc.) each marked Permitted / Conditional / Prohibited with output handling required and owner identified
Roll out the Use Case Intake Form for new tools / use cases / data classes
Owner · AI Governance Lead + HR
Output · ~5-minute structured form with 18+ data validation dropdowns; cascading auto-routing formula produces Approved / Conditional / Route to Vendor DD / Escalate / Declined
Configure Detection & Monitoring with IT Security (DLP, browser allow-list, shadow AI scanning) and stand up the AI Incident Response Runbook
Owner · IT Security + AI Governance Lead + CISO
Output · DLP rules covering known AI domains; managed-browser allow-list; quarterly shadow AI scan; IR runbook with 8 incident types and severity-tiered response (intake culture for shadow AI; discipline reserved for prohibited uses)
◆ Ready to use it?
Download the GenAI Employee AUP Kit.
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
How is a GenAI Employee AUP different from a model risk management policy? ⌄
MRM governs production AI/ML systems that produce outputs used in business decisions — credit scoring models, fraud detection, AML monitoring. Those systems go through validation, governance committees, monitoring per SR 11-7 / the 2026 interagency revised MRM guidance / NIST AI RMF. The GenAI Employee AUP covers the layer above MRM: ChatGPT, Claude, Copilot, Gemini, and AI features embedded in third-party SaaS — employee-facing tools that sit in front of every desktop. Two distinct policies; complementary, not duplicative.
Won't employees just go around the policy? ⌄
They will if the policy is a ban or makes every prompt require permission. The fix is the Pre-Approved Use Cases list — 15+ common patterns (drafting emails, summarizing public docs, code review, etc.) are pre-approved so employees self-serve. The intake form is only for new tools, new use cases for approved tools, or new data classes — ~5 minutes, structured questions, auto-routing. Detection (DLP + browser allow-list + shadow AI scanning) backstops the policy. Shadow AI incidents are handled as intake events — non-punitive — to surface unmet needs and add them to the Pre-Approved list.
Which data classes can go in which AI tools? ⌄
Public data may be used in any approved tool tier (including consumer tools used on personal accounts). Internal and Confidential data may only be used in Enterprise tools (with no-training opt-out and DPA in place). Restricted data (MNPI, PHI, credentials, attorney-client privileged) is generally prohibited in any AI tool; specific exceptions require pre-approval. The matrix is the load-bearing piece of the policy — what you input determines what tier of tool you can use.
Does this cover the Colorado AI Act, EU AI Act, and similar state laws? ⌄
The kit's Prohibited Uses include AI-only adverse-action decisions about customers without meaningful human review — an approach informed by ECOA, FCRA, the Colorado AI Act (revised effective date January 1, 2027 — verify current status with counsel), and other emerging state-law frameworks under which AI-driven decisions about consumers generally call for meaningful human review. For EU AI Act exposure, additional review with EU counsel is recommended; the framework is structurally compatible but does not include EU-specific compliance attestations.