Author the Team AI-Usage Policy People Can Actually Follow

Workflow area: Policy & Governance · Tier: Core · Hands-on time: ~40 minutes

Policy vacuums don't stay empty. In the absence of a written stance, engineers either paste production credentials into consumer chatbots (the incident that usually triggers policy-writing) or refuse to use sanctioned tools "just in case" (the productivity loss nobody logs). Both are rational responses to ambiguity. The goal is a document an engineer can apply in ten seconds at the moment of decision — can I paste this stack trace into Claude? — not a legal artifact that scores well in audit and gets read once. Governance frameworks like the NIST AI RMF give you the risk categories; your job is translating them into the specific yes/no calls your team makes daily.

When to use — and when not to

• Use it before the tools arrive, ideallypolicy shipping with the rollout (pb-43) sets norms once; policy arriving after an incident sets them adversarially.
• Use it to consolidate folkloreif your team's current answers to "can I use AI on client code?" vary by who you ask, the policy exists to end the variance.
• Use it after shadow-AI discoverypb-32's amnesty inventory is the single best input to this document: it tells you what people actually need permission for.
• Skip copying another company's policy wholesalea borrowed policy encodes someone else's risk profile, client base, and tool contracts; use templates for structure, never for the actual boundaries.
• Skip aspirational bans you won't enforcea policy that prohibits what half the team demonstrably does daily (and leadership tolerates) teaches that the whole document is decorative; write the boundary you'll actually hold.

The recipe

1. 1.

   Gather the real inputs. Four things: your org's existing security and data-classification policies (the AI policy must inherit, not contradict them), your tool contracts (which tiers have training-on-your-data disabled — the pb-42 vendor answers), client or regulatory constraints on AI use (pb-33's territory), and the shadow-AI inventory if you have one. Twenty minutes here prevents a policy that conflicts with the MSA someone signed last year.

2. 2.

   Draft against a risk-framework skeleton.

   Copy

   Draft a team AI-usage policy an engineer can apply in
   seconds. Structure it NIST AI RMF-aligned (govern/map/
   measure/manage), but the output must be operational, not
   framework prose.
   
   Inputs:
   - Approved tools + tiers: [LIST, with data-handling terms]
   - Our data classes: [e.g., public / internal / confidential
     / client-owned / regulated PII]
   - Client constraints: [SUMMARY]
   - Known current usage: [SHADOW-AI FINDINGS]
   
   Required sections:
   1. APPROVED TOOLS — named tools and tiers; everything else
      requires an exception, not forgiveness.
   2. DATA RULES — a class-by-class table: what may enter
      which tool. Include the concrete cases: stack traces,
      code snippets, logs with user data, credentials (never),
      architecture docs, client code.
   3. CLIENT-CODE BOUNDARY — default stance for client-owned
      work, and where per-client agreements override.
   4. REVIEW GATES — AI-assisted changes follow [OUR REVIEW
      STANDARDS]; no-AI zones listed explicitly.
   5. DISCLOSURE NORMS — when to say work was AI-assisted:
      in PRs, in docs, to clients.
   6. EXCEPTION PROCESS — who approves, how fast, and how an
      exception becomes a policy update.
   7. WHAT HAPPENS ON VIOLATION — proportionate, learning-
      first, consistent with our incident culture.
   Write it in second person. One page of rules, one page of
   the data table. No corporate throat-clearing.
   

3. 3.

   Red-team the draft with real scenarios. Same conversation: "Apply this policy to: (1) pasting a production stack trace containing a customer email into an approved tool; (2) using AI on a client repo whose MSA is silent about AI; (3) an engineer wants to try an unapproved agent tool on internal tooling; (4) generating test data that resembles real PII. For each: what does the policy say, and where does an engineer have to guess?" Every "the policy is ambiguous here" answer is a section to sharpen. Good output looks like:

   Copy

   Scenario 1: Data table row "logs/traces with user data" →
   ALLOWED only after scrubbing identifiers, approved tools
   only. Clear.
   Scenario 2: GAP — the client-code section defaults to
   "allowed with approved tools" but MSA-silent is not the
   same as MSA-permitting. Suggest: MSA-silent client code
   requires the pb-33 approval workflow before first use.
   

4. 4.

   Make the exception process the pressure valve. The policy's survival depends on this section: a named approver (you or a delegate), a response SLA measured in days not quarters, and a standing rule that three approvals of the same exception trigger a policy amendment. Teams with dead exception processes don't stop needing exceptions — they stop asking, and you're back to shadow AI with extra steps.

5. 5.

   Ratify, teach, and version it. Walk the team through the document live — the data table especially — and collect the "what about X?" questions; the first month's questions are free red-teaming. The policy carries an owner, a version, and a review date two quarters out: model capabilities, tool contracts, and client terms all drift, and an unrevised AI policy is stale in a year. Week-one onboarding acknowledgment (pb-23) makes it stick for every future hire.

Make it yours

• Small team or startup: one page total, three sections — approved tools, the data table, "ask before anything else." You likely lack enterprise tiers, which makes the data rules stricter, not looser: consumer-tier tools mean nothing confidential enters any prompt, and the policy should say so bluntly.
• Large org or GCC: your policy nests inside org-level security policy and possibly a parent org's AI governance — write the team layer to reference, not restate, the org layer, so updates don't drift. Client-services and GCC contexts make section 3 the longest: maintain the per-client matrix (pb-33) as an appendix owned jointly with delivery leadership, and get legal review before anything client-facing ships.
• Regulated industries: add data-residency and audit-trail requirements to the tool-approval criteria, involve compliance in ratification, and expect the exception process to carry most of the load — regulated work is where blanket rules fit worst and documented case-by-case decisions matter most.

Quality check

• The ten-second test passeshand an engineer the policy and a scenario ("stack trace with a customer email — which tool, if any?"); if the answer takes more than ten seconds to find, the data table needs work.
• Every approved tool's data terms were verifiedthe table's promises are only as good as the contract tier behind them; check that "training disabled" is true for the tier you actually pay for.
• No rule contradicts observed reality without a planany boundary the team currently crosses daily ships with either enforcement (pb-28's CI gates) or a transition note, never silence.
• The exception process has a pulseafter one quarter, count requests: zero means people aren't asking (bad), not that the policy is perfect.
• Version and owner are on the documentan unowned policy is abandonware; the review date is the difference between a living boundary and a 2024 artifact quoted sarcastically in 2026.