# AI Use Policy — `[TEAM / COMPANY NAME]` *Everything above the line is the policy. It's one page on purpose — people read one page. Fill in the brackets, delete what doesn't apply, and publish it somewhere people will actually find it.* --- **Effective `[DATE]` · Owner: `[NAME]` · Review: `[QUARTERLY / DATE]`** We want you using AI at work. This page says how, and where the limits are, so you don't have to guess. ## 1. What we want you using it for Go ahead and use `[APPROVED TOOL]` for: - Drafting — emails, docs, updates, first passes at anything - Summarizing long documents, threads, and meeting notes - Rewriting and editing your own work - Brainstorming and thinking out loud - Explaining things you don't understand — jargon, contracts, code, spreadsheets, acronyms - `[TEAM-SPECIFIC: e.g. drafting test cases, turning exports into summaries, first-pass customer replies]` You don't need permission for any of this. You don't need to disclose that you used AI to help write an internal email. ## 2. What never goes in Do not paste into any AI tool: - **Customer or client data** that identifies real people - **Employee data** — compensation, performance, health, personal details - **Anything under NDA** or marked confidential - **Regulated data** — health records, financial account details, legal case specifics - **Credentials** — passwords, API keys, tokens, connection strings - `[COMPANY-SPECIFIC: e.g. unreleased financials, M&A material, pre-announcement product plans, source code outside these repos: …]` The simple version: **if you'd hesitate to post it publicly, it doesn't go in.** Why: with many AI tools, what you type can be retained, and depending on the product and its settings, used to train future models. Our `[APPROVED TOOL]` account is on a `[BUSINESS / ENTERPRISE]` plan, which contracts that away — free consumer accounts often don't. Use the company account, not your personal one. **Need to work with something on this list?** Ask `[NAME]`. There's usually a safe way — sanitized examples, an approved tool, or a different approach. Ask before, not after. ## 3. You own what you send AI drafts. A person approves. Specifically: - **Verify anything that leaves the team or drives a decision.** These tools state wrong things with complete confidence — wrong numbers, wrong citations, invented quotes, plausible-looking names. Check the facts, not just the tone. - **You are responsible for what you send**, regardless of what drafted it. "The AI wrote it" is not a defense we can offer a customer. - **Disclose where it matters.** Not on a reworded email. Yes on analysis or content presented as your own careful work, and anywhere your audience would reasonably want to know. If you're unsure whether it matters, it probably does. ## 4. Some things stay human Don't hand these to a tool: performance feedback, disciplinary matters, condolences, apologies to a specific person, or anything where the point is that a person spent the time. `[ADD YOUR OWN]` ## 5. Ask, and tell us what you learn This policy will change as the tools do. If you're unsure whether something is okay — **ask `[NAME]` in `[CHANNEL]`**. Nobody has ever been in trouble here for asking. A question asked out loud is a problem prevented. Found something that works well? Post it in `[CHANNEL / PROMPT LIBRARY LINK]` so the rest of the team gets it too. --- ## Notes for whoever is filling this in *Not part of the policy — delete this section before publishing.* **Get section 2 confirmed in writing** by security, legal, or IT before you publish. Don't draft it from memory, and don't publish it as "provisional" while you wait — a document you wrote that permits customer data into a tool isn't made safe by a caveat at the top, and it isn't your call to make. If the answer hasn't come back yet, publish the interim notice in [getting-approval.md](./getting-approval.md) instead: it permits public and made-up material only, pauses everything else, and keeps the decision where it belongs. If your company has genuinely no owner for this — no security, legal, IT, compliance, or privacy function — see section 7 of that document. The short version: get a sign-off from whoever carries company risk, and put their name on it rather than yours. That's the hard part, and it's a document of its own: [getting-approval.md](./getting-approval.md) has who to ask, the five questions worth asking, the email to send, and what to do when nobody replies — which is the most likely outcome. Send it before you fill in anything else here. **See one filled in.** [worked-example.md](./worked-example.md), section 2, is this template completed for an (invented) 14-person claims team. The thing to copy is how specific section 2 gets. **Name a real person in sections 2 and 5**, not a team or an alias. The whole mechanism depends on there being someone obvious to ask. **Keep it to one page.** Every addition costs you readers. If you find yourself adding a sixth section, ask whether it's really policy or just guidance that belongs somewhere else. **Publish it where people work** — pinned in the team channel, linked in onboarding, not buried in a wiki nobody opens. **Revisit it quarterly.** Tools change, plans change, and a policy naming a tool you no longer use teaches people to ignore the whole thing. **Related:** the full rollout guidance is in [managers-toolkit.md](./managers-toolkit.md); the workshop where your team puts this into practice is in [ai-workshop.md](./ai-workshop.md).