Verified against ChatGPT · 2026-08-13
Write an employee-facing AI use policy short enough that people actually read it before ignoring it
Produces a concise, plain-language employee AI use policy covering approved tools, data red lines, and disclosure rules, deliberately kept short and specific so it gets read rather than skimmed, framed as a draft pending legal sign-off.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Write a short, plain-language employee-facing AI use policy — the kind an employee will actually read in three minutes, not a legal document nobody opens past the title. APPROVED TOOLS AND USE CASES ChatGPT Enterprise (company account) approved for drafting, brainstorming, and summarizing internal documents; no approval yet for customer-facing chatbots. HARD DATA RED LINES Customer names paired with account numbers, any unreleased financial results, source code from the payments repository. DISCLOSURE EXPECTATIONS Any customer-facing email drafted with AI assistance must still be personally reviewed and sent by the employee, no auto-send. WHAT HAPPENS IF SOMEONE VIOLATES THIS First accidental red-line violation: report it immediately, no punishment, treated as a training moment. Repeated or deliberate violations go to HR. WRITING RULES Write this as short numbered rules an employee could actually remember, not paragraphs of legal prose — each rule should be one or two sentences, plain language, no defined-terms formality. Lead with what's allowed and encouraged before what's prohibited; a policy that opens entirely with restrictions reads as adversarial and gets skimmed defensively rather than actually absorbed. State every data red line as a concrete example of what not to paste into a general AI tool, not an abstract category — "customer social security numbers or full payment card numbers" lands with an employee in a way "personally identifiable information" does not, because it's instantly checkable against something they might actually be about to do. State the disclosure rule as a specific action (label AI-assisted content, note it in a specific field, tell your manager) rather than a vague expectation to "be transparent about AI use." State consequences honestly but without hostility — what actually happens on a first violation versus a repeated one, since a policy that implies immediate termination for any AI mistake trains people to hide mistakes rather than report them. WHAT NOT TO DO Do not write this in a formal legal register with defined terms and "whereas" clauses — that register signals "skip this" to most employees and defeats the actual goal, which is behavior change, not legal formality. Do not state that this policy fully satisfies any specific regulatory requirement — if regulatory compliance is a goal here, note that legal has reviewed this for that purpose only if I've told you that review already happened; otherwise, leave that claim out entirely. OUTPUT FORMAT A short policy: title, one-paragraph "why this exists" framed positively, a numbered "what's encouraged" section, a numbered "hard red lines" section with concrete examples, a short disclosure-rule section, and a brief, non-hostile consequences section. Total length under 500 words. Close with a line noting this is a draft pending legal review, and that it must be approved by a qualified lawyer or compliance officer before being published or enforced as an actual company policy.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The instruction to lead with what's encouraged before what's prohibited, and to keep the whole thing under 500 words, directly targets a known failure mode of internal policy documents: a policy that opens with restrictions and runs long reads as adversarial compliance theater, gets skimmed rather than internalized, and employees default back to whatever they were already doing the moment they close the document — a short, front-loaded-with-permission policy is measurably more likely to actually change behavior, which is the entire point of writing one. Requiring data red lines as concrete, instantly-checkable examples rather than abstract categories like 'personally identifiable information' matters because an employee about to paste something into a chat window needs a rule they can apply in the two seconds before hitting enter, and 'PII' requires them to first correctly classify what they're holding as PII, a step most people skip under time pressure — 'customer names paired with account numbers' requires no classification step at all, just pattern recognition against something they're looking at right now. The honest, non-punitive framing of first-violation consequences is a deliberate behavioral design choice, not just a tone preference: a policy that implies severe consequences for any AI-related mistake predictably drives underreporting, since an employee who accidentally pastes something sensitive will hide it rather than flag it if they believe disclosure ends badly for them, which defeats the entire purpose of having a reporting mechanism — stating plainly that a first accidental violation is a training moment, not a punishment, is what makes the reporting channel something people will actually use. The refusal to claim regulatory sufficiency unless legal has actually confirmed it protects against the document being relied on as evidence of compliance it hasn't actually earned, which matters most in exactly the scenario where this policy would later be scrutinized — after an incident, not before one.
What you get back
WHY THIS EXISTS: AI tools genuinely help us move faster — this policy exists so we can use them with confidence, not to slow anyone down. HARD RED LINES: Never paste a customer's name together with their account number or full card number into any AI tool. Never paste unreleased financial results. If you're not sure whether something counts, ask before pasting, not after. FIRST MISTAKE: If you accidentally paste something on this list, tell your manager right away — this is treated as a training moment, not a punishment, the first time. This is a draft pending legal review and must be approved by a qualified lawyer or compliance officer before being published or enforced.
Verified against
ChatGPT GPT-5.1 · 2026-08-13
Changelog
- 2026-08-13 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
