AI Usage Policy Template
A capability of the Behest AI Token FinOps platform.
Last updated:
A practical, copy-and-adapt employee AI policy for CISOs, CIOs, and platform owners — and the piece most templates skip: how to make each clause enforce itself instead of relying on the honor system.
The short version
What is an AI usage policy template?
An AI usage policy sets which AI tools employees may use, what data is allowed, and who owns the cost. Honor-system policies fail; Behest's AI Token FinOps control center turns the policy into enforced defaults — model allowlists, PII scrubbing, budgets, and an audit trail. Copy the template below.
Why most AI policies don't change behavior
A written policy is necessary, but on its own it's a document that competes with a deadline. It asks every employee to remember which tools are approved, what data is off-limits, and whose budget they're spending — for AI tools that are one browser tab away. Under pressure, the convenient path wins, and that path is often an unapproved tool with a customer list pasted into it.
The fix isn't a longer policy — it's making the rules the default. When approved tools are the only ones that work, PII is scrubbed before it can leave, and budgets are enforced on the request path, the policy stops depending on discipline. The template below is written to be enforced that way: every section maps to a control Behest can run on the request path, not a rule you hope people follow.
The template
Copy the markdown below into your docs tool and replace the [bracketed] fields. It covers every section a defensible policy needs — scope, allowlist, data rules, access tiers, budgets, a shadow-AI reporting path, technical enforcement, and a review cadence.
# [Company] AI Usage Policy
Version: 1.0 | Owner: [Name / Team] | Effective: [Date] | Review: Quarterly
## 1. Purpose & Scope
This policy governs how employees, contractors, and systems use generative AI
and large language models (LLMs) for [Company] work. It applies to all AI use
that touches company data, code, customer information, or is done on company
time or systems — including tools accessed through a personal account.
## 2. Approved Tools & Models (Allowlist)
- Only tools and models on the approved allowlist may be used for company work.
- Current allowlist: [e.g., Behest-routed OpenAI, Anthropic, Google Gemini].
- Requesting a new tool/model: [link to intake form]. New models are reviewed
before they are made reachable — not after they have processed company data.
- Using an unapproved tool for company work is a policy violation.
## 3. Data Rules
- Do NOT paste customer PII, secrets, credentials, or regulated data into any
unapproved AI tool.
- Approved tools route through Behest, where PII scrubbing runs before prompts
leave the environment (enforce mode: mask, redact, or block).
- Classify data before use: [Public / Internal / Confidential / Restricted].
Restricted data may be used only with [named self-hosted / approved path].
- Model outputs are drafts, not decisions — a human reviews before anything
ships to a customer, goes to production, or is treated as fact.
## 4. Access & Tiers by Role
- Access to models and features is granted per role, least-privilege by default.
| Role | Approved models | Limits / notes |
| ----------------- | -------------------- | ----------------------- |
| [General staff] | [mid-tier, small] | [standard tier] |
| [Engineering] | [+ frontier] | [higher rate limit] |
| [Restricted-data] | [self-hosted only] | [no external providers] |
## 5. Budgets & Cost Accountability
- Every team has a monthly AI token/dollar budget owned by [team lead].
- Spend is attributed per user, project, and session; teams review it monthly.
- Hard budgets are enforced on the request path: a call that would exceed the
cap is blocked or throttled before it reaches the provider invoice.
- Budget changes require [approver] sign-off.
## 6. Shadow-AI Reporting Path
- Found an unapproved tool in use, or need one that isn't on the allowlist?
Report or request it here: [link]. No blame for surfacing it early.
- Security/IT reviews requests within [X business days] and adds approved
tools to the allowlist and the governed routing path.
## 7. Enforcement (Technical, Not Honor-System)
This policy is backed by controls, not trust alone:
- Model allowlists block unapproved providers at the gateway.
- PII scrubbing (Presidio-based) redacts sensitive data before egress.
- Prompt-injection screening (Sentinel) checks inbound prompts on every call.
- Token/dollar budgets stop overruns on the request path.
- An audit trail records who called which model, when, and at what cost.
## 8. Review Cadence
- Reviewed quarterly by [owner] and after any material change in tools,
regulation, or incident. Allowlist and budgets are re-baselined each review.
Questions: [contact]. Violations may result in [consequence per HR policy].This template describes capabilities and controls, not certifications. Adapt the data-classification tiers, roles, and consequences to your own legal and HR requirements.
Turn the policy into enforced defaults
Each policy section maps to a control Behest runs on the request path — in our cloud or yours.
- 1
Turn the allowlist into a gateway rule
Instead of asking people to remember which models are approved, route all AI through one governed endpoint and enforce a model allowlist there. Unapproved providers simply aren't reachable, so Section 2 stops being a request nobody reads and becomes the default.
- 2
Enforce the data rules with PII scrubbing
Run every prompt through PII scrubbing (Presidio-based) before it leaves your environment, in mask, redact, or block mode. Section 3 no longer depends on each employee spotting sensitive data — the control catches it on the request path.
- 3
Grant access and tiers per role
Map Section 4 to real per-role and per-tier access: which models and features each role can reach, with least-privilege as the default. Restricted-data roles can be pinned to an approved path rather than trusted to avoid external providers.
- 4
Make budgets enforce themselves
Attribute spend per user, project, and session and set the team token and dollar budgets from Section 5 as hard caps evaluated on the request path. A call that would blow the budget is blocked or throttled before it reaches the provider invoice.
- 5
Keep an audit trail as the evidence base
Record every call — model, tokens, cost, user, project — plus security events like PII redactions and blocked injection attempts. Section 7's enforcement clause is only credible if there's a trail to review, and this is it.
Frequently asked questions
- Why do honor-system AI policies fail?
- Because a policy that only lives in a document depends on every employee reading it, remembering it, and choosing to follow it under deadline pressure — for tools that are one browser tab away. The result is predictable: sensitive data gets pasted into unapproved tools, unsanctioned 'shadow AI' spreads, and spend accrues with no owner. A policy holds only when its rules are also enforced as technical defaults — model allowlists, PII scrubbing, budgets, and an audit trail — so the safe path is the path of least resistance rather than an act of discipline.
- What should an employee AI usage policy include?
- At minimum: purpose and scope; an allowlist of approved tools and models; data rules (what may and may not go into AI tools, and how PII is handled); access and tiers by role; budgets and cost accountability per team; a shadow-AI reporting path so people can surface or request tools without blame; an enforcement section describing the technical controls behind the policy; and a review cadence. The template on this page includes all of these as fill-in-the-blank sections you can copy and adapt.
- How do I enforce an AI usage policy instead of just publishing it?
- Route AI through one governed path and wire each policy clause to a control on that path. The allowlist becomes a gateway rule, the data rules become PII scrubbing before egress, access maps to per-role and per-tier permissions, budgets become hard caps enforced on the request path, and everything lands in an audit trail. Behest runs as SaaS or self-hosted in your own cloud (GKE or any Kubernetes); on the Enterprise self-hosted option, prompts and provider keys stay in your environment, so enforcement doesn't mean centralizing your data elsewhere.
Make the policy enforce itself
See how Behest turns your AI usage policy into defaults — model allowlists, PII scrubbing, budgets, and an audit trail on every call — SaaS or self-hosted in your own cloud.