AI Usage Policy Skill

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

1. 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).
2. 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.
3. 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.
4. 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.
5. 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.
6. 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)