AI Usage Policy Skill
Most corporate AI policies fail in one of two ways: a fearful ban everyone quietly ignores (shadow AI, zero visibility), or legal fog nobody can apply to the question they actually have — "can I paste this customer email into Claude?" This skill writes the policy as a decision aid: one page, answerable in the moment of use, with the reasoning logged separately for counsel.
What This Skill Produces
- A one-page policy: approved tools, the data traffic-light, disclosure duties, review obligations, and how to get a tool approved
- A decision log: the reasoning behind each rule, for legal/leadership review
- A rollout note: how the policy lands without becoming shelfware
Required Inputs
Ask for (if not already provided):
- The org: size, industry, regulatory exposure (health, finance, gov contracts change the answers)
- Current reality: which AI tools are already in use — officially and (honestly) unofficially
- Data landscape: what sensitive classes exist (customer PII, PHI, source code, financials, client-confidential)
- Enterprise agreements in place: which tools have zero-retention/no-training terms signed vs consumer accounts
- Risk appetite: enable-with-guardrails or restrict-hard? (Get the sponsor's one-word answer.)
Policy Method
- Legalise reality first. Shadow AI is the largest risk created by strict policies. Start from what people already use; the policy's first job is making the sanctioned path easier than the unsanctioned one — approved tools with enterprise terms, clearly listed, with a fast approval lane for new ones (named owner, ≤2-week SLA).
- Rule on data, not tools. Tools churn monthly; data classes don't. The core artifact is a traffic-light table people can apply in three seconds:
- 🟢 Fine in approved tools — public info, your own drafts, non-confidential work product
- 🟡 Approved tools with enterprise terms only — internal business data, code, unreleased plans
- 🔴 Never in any AI tool (until a named exception is granted) — regulated data (PHI, card data), client-confidential under NDA, credentials, anything under legal hold Each row names examples from this org's actual work, not abstract categories.
- Set the accountability rule once, clearly. The human who ships it owns it — AI-assisted or not. From that root, the review duties follow: outputs going to customers/public/regulators get human review by someone competent to catch the errors; internal drafts don't need ceremony. State both halves; policies that demand review-everything get review-nothing.
- Decide disclosure deliberately. Internal: generally not required (it's a tool). External: disclose where the audience would feel deceived otherwise (bylined content, legal filings, anything presented as human judgment — expert reports, references) or where law/regulator requires it. Write the specific disclosure lines for this org's cases, not a principle.
- Keep the enforcement honest. First violations of 🟡 rules are coaching moments; 🔴 violations follow the existing data-handling discipline process (don't invent a parallel one). The policy names its owner, its review cadence (quarterly — the landscape moves), and where questions go today.
- Log the reasoning separately. Every rule gets one line in the decision log: what we ruled, why, what we considered. Counsel reviews the log; humans read the page.
Output Format
AI Usage Policy: [org] — v1, [date] · owner: [role] · review: quarterly
Approved tools: [tool → account type (enterprise/consumer-banned) → what it's approved for] Getting a tool approved: [the lane: who, what they check, SLA]
The data rule (the table above, with org-specific examples per row)
Your accountability: [the ship-it-you-own-it rule + review duties by output destination]
Disclosure: [the org's specific cases with the exact lines to use]
If something goes wrong: [pasted the wrong thing / AI error shipped → who to tell, framed as no-fault-if-fast]
Decision log (separate artifact): [rule → reasoning → alternatives considered → open questions for counsel]
Rollout note: [announce with the enabling frame; 30-min manager briefing; the three examples everyone actually asks about, answered]
Quality Checks
- A stressed employee can answer "can I paste X into Y?" from the page in under a minute
- Every data-class row carries examples from this org's real work
- The sanctioned path is genuinely easier than shadow use (tools listed, approval lane fast)
- Disclosure rules are specific lines for specific cases, not a value statement
- The policy names its owner, review cadence, and question channel
- The decision log exists — counsel reviews reasoning, not just conclusions
Anti-Patterns
- Do not ban broadly and enforce never — that policy trains people to hide usage you most need to see
- Do not write rules per-tool as primary structure — tools churn; data classes are the stable spine
- Do not require human review of everything — undifferentiated duty guarantees zero real review
- Do not copy another company's policy without the data-class mapping — the table is the policy
- Do not present this as legal advice — it's the draft counsel refines, and the page says so
