AI Usage Policy Prompt: Draft One Tailored to Your Risk

Every company now needs an AI usage policy, and most of them are copying a template that has nothing to do with their actual risk. A 12-person agency and a 2,000-person healthcare provider do not have the same data rules, the same tool list, or the same appetite for shadow AI. An ai usage policy prompt drafts a policy from your inputs instead of handing you a generic document to find-and-replace.

The pressure is real. Employees are already pasting customer data into chatbots whether there's a policy or not. Legal wants guardrails. Security wants a sanctioned-tools list. Leadership wants something that doesn't read like it'll strangle productivity. The blank-page problem is what stalls this, and a generic template doesn't solve it. It just moves the editing somewhere worse.

What actually closes the gap is a prompt that asks about your risk profile and writes around it.

The gap: sample policies and starter prompts, no tailoring engine

The advice online splits into two camps, and neither hands you a tailored draft.

The first camp is sample policies and guides. WitnessAI's AI policy template post lays out 11 core components and four example structures for corporate, nonprofit, SMB, and tech orgs (genuinely useful) but, by its own framing, it doesn't include the actual template document or any tool that tailors a policy to a specific company. It positions a governance platform as the enforcement layer, not the drafting one. Most "AI policy template" results work this way: structure and checklist, no fill-in engine.

The second camp is prompt lists. Productiv's 14 LLM prompts for AI governance is the clearest example. The prompts are real and bracketed for variables, but they're scoped to components (map your AI landscape, classify shadow-AI risk, draft an approval workflow) and the author says plainly they're meant to "start the conversation," not produce a finished policy. There's no single prompt that takes your risk profile and returns the whole document.

So the gap is specific: nobody publishes one prompt that ingests company size, industry, sanctioned tools, data sensitivity, and risk tolerance and drafts a complete, sectioned policy. That's a structured-output job, and it's what this post sets up.

What you can do with this prompt

• Draft a full internal AI usage policy from your company's actual profile
• Produce a tiered tool list: sanctioned, conditional, prohibited
• Set data-handling rules matched to your data sensitivity, not a generic one
• Build an approval workflow for requesting new AI tools
• Define human-review gates for AI-generated output by use case
• Generate a violation-and-consequence section and a review cadence
• Adjust strictness with one variable, from permissive to locked-down

Anatomy of the policy prompt

The shape that makes this work: force the risk inputs up front, then lock the output to named policy sections so nothing gets skipped.

Variables  → {{company_size}}, {{industry}}, {{data_sensitivity}},
             {{sanctioned_tools}}, {{risk_tolerance}}, {{regulatory_context}}
Prompt     → Role: policy author for AI governance.
             Task: draft an internal AI usage policy tailored to the inputs.
             Rules: tool list must reflect {{risk_tolerance}}; data rules
             must reflect {{data_sensitivity}}; flag where legal review is needed.
Output     → A sectioned policy:
             1. Scope & purpose  2. Tool tiers (sanctioned/conditional/prohibited)
             3. Data-handling rules  4. Approval workflow  5. Human-review gates
             6. Violations  7. Review cadence
             plus a "Needs legal review:" list of clauses.

The {{risk_tolerance}} and {{data_sensitivity}} variables are what make the output yours. Set sensitivity to "handles regulated health data" and the data-handling section tightens automatically — no pasting customer PII, no public-tier tools, mandatory de-identification. Set risk tolerance to "permissive, productivity-first" and the tool tiers loosen. A template can't do that. A prompt that treats these as constraints can.

Step-by-step usage

1. Profile your risk honestly

Fill {{company_size}}, {{industry}}, and {{data_sensitivity}} truthfully. If you handle customer financial records, say so. Sandbagging the inputs produces a policy that looks fine and protects nothing.

2. List what's actually sanctioned

{{sanctioned_tools}} should name the tools people already use and which you've approved. The policy is more credible when it acknowledges reality. A document banning a tool half the company depends on gets ignored on day one.

3. Set the strictness dial

{{risk_tolerance}} is the dial. Run it once at your intended setting, then once a notch stricter, and compare. Seeing both versions side by side makes the trade-offs concrete for the people who have to sign off.

4. Read the "Needs legal review" list

The prompt flags clauses that should not ship without a lawyer. Take that list seriously. A generated policy is a strong draft, not legal advice, and the IP-ownership and liability clauses in particular need a human with a law degree.

5. Route it for sign-off

Send the draft to legal, security, and HR before it's published. The prompt gets you to a reviewable draft in minutes instead of weeks, which is the point — but the review still happens.

Prompt-craft patterns for policy output

Make risk profile a constraint, not flavor text. A weak prompt mentions the industry in passing. A strong one ties output to it: "Data-handling rules must reflect {{data_sensitivity}}; if it's regulated data, prohibit public-tier tools and require de-identification." Stated as a rule, the model can't default to boilerplate.

If {{data_sensitivity}} indicates regulated or personal data,
the data-handling section must prohibit pasting that data into any
non-sanctioned tool and must require a named approval step. Do not soften this.

Force the model to flag its own legal-review needs. This is the trust move. Telling the model to surface a "Needs legal review:" list keeps it from presenting liability and IP clauses as settled fact. It's honest about the limits of a generated document, and it gives legal a punch-list instead of a wall of text. Worth noting: Claude tends to flag uncertainty in policy language more readily, while GPT-4o sometimes states risky clauses with false confidence unless you explicitly ask it to mark what needs review.

Lock the section list so nothing drops. Policies fail by omission — a missing approval workflow, no review cadence. Name all seven sections in the output contract and require each one. A model handed an explicit section list rarely skips one; a model asked to "write a policy" routinely forgets the boring-but-critical parts.

Variables you'll set

An opinion: a permissive policy people follow beats a strict one they route around

Here's a stance most governance content won't take. The strictest policy isn't the safest one. A document that bans every useful tool and demands sign-off for every prompt doesn't reduce risk — it pushes AI use into personal accounts and unmanaged browsers where you can't see it at all. Shadow AI is the actual threat, and shadow AI grows fastest under policies that are too rigid to live with. A policy that sanctions a few good tools, sets clear data rules, and stays out of the way otherwise gets followed. That's why {{risk_tolerance}} defaults toward workable rather than maximal, and why the smart move is usually a notch looser than legal's first instinct. Enforceable beats ideal.

Getting started

1. Copy the prompt structure above into ChatGPT, Claude, or Gemini.
2. Fill {{data_sensitivity}} honestly — it drives the strictest sections.
3. List the {{sanctioned_tools}} people already use and you've approved.
4. Run it once at your intended {{risk_tolerance}}, once a notch stricter.
5. Read the "Needs legal review" list before anything else.
6. Route the draft to legal, security, and HR for sign-off.
7. For a version with the seven sections, tool tiers, and legal-review flags already locked into the output contract, use the AI Usage Policy & Governance Playbook instead of rebuilding the structure each time.

Governance rarely stops at the policy document. Once the policy names review gates for AI output, the LLM Output Brand-Safety Auditor gives you a concrete rubric to enforce one of them, turning a policy clause into an actual check.

A policy is only as good as the checks behind it. For the security-review angle that backs a policy's data rules, the security code review prompt mapped to CWE shows how to turn a rule into a concrete check, and when AI agents are in scope, prompt injection defense for AI agents covers the risk your policy should name. Then go draft something your team will actually follow.