The best internal AI policies share two traits: they fit on roughly one page, and they default to "yes, with conditions" rather than "no, unless approved." A policy nobody reads protects nobody, and a policy that forbids everything just recreates the shadow usage it was meant to prevent. What follows is a section-by-section template for a Claude acceptable-use policy, written for an organization accessing Claude through a third-party platform such as Amazon Bedrock, Google Vertex AI, Microsoft Foundry, or Claude Platform on AWS.
Section 1: Scope and approved tools
Name the sanctioned tools explicitly: the internal assistant, the approved platform endpoints, and any embedded features. State that these are the only approved ways to use LLMs with company data, and that consumer AI accounts (personal logins on any provider's public tools) are not approved for work content. Naming the approved path first matters: the policy should read as "use this" before it reads as "don't use that."
Also state which model tiers and platforms the organization has approved, so teams building new features know the menu (for example: Claude Opus 4.8, Sonnet 5, and Haiku 4.5 via your chosen cloud). Keep this list in one place so updating it does not require re-signing the policy.
Section 2: What is allowed by default
Most everyday knowledge work should be allowed without asking anyone: drafting and editing documents, summarizing meetings and internal materials, writing and reviewing code against internal repositories where engineering leadership has approved it, brainstorming, translation of non-sensitive content, and answering questions grounded in internal documentation. Spell these out. Every explicit "yes" in the policy removes a hallway question and a shadow workaround.
Add the universal condition here: a human owns the output. Whoever uses the model's output is responsible for verifying it before it influences a decision, ships to a customer, or enters a system of record. This one sentence does more governance work than any restriction list, because it survives every new use case.
Section 3: What requires review, and what is prohibited
The review tier covers uses that are legitimate but need a second pair of eyes before they start: sending customer personal data in prompts (route through your PII-handling standards), regulated content such as health or financial records, anything feeding automated decisions about individuals (hiring, credit, discipline), and any new tool-use integration that lets the model act on other systems. The trigger for review should be the use case, not each individual request, or the process will be ignored.
The prohibited tier should be short and non-negotiable: entering company data into unapproved consumer AI tools, using model output to impersonate people, representing unreviewed model output as verified professional advice (legal, medical, financial), and attempting to bypass access controls or misuse the platform in violation of provider terms. Note that whichever platform you use has its own usage policies that bind you contractually; your internal policy should reference them rather than restate them.
Section 4: Logging, transparency, and enforcement
Tell employees plainly what is logged. A typical stance for a 3P deployment: API-level usage (who called which model, when, token volumes) is always logged through cloud-native audit tooling; prompt and response content may be logged for approved use cases with defined retention and restricted access. People behave differently, and better, when logging is disclosed rather than discovered.
For enforcement, distinguish honest mistakes from deliberate circumvention. A first accidental paste of sensitive data into the wrong tool should trigger a correction and maybe a training nudge; deliberate, repeated bypassing of controls is a conduct issue like any other. Announce an amnesty for past shadow usage when the policy launches, so your inventory of existing habits comes to you voluntarily.
Keep it alive
Assign an owner, review the policy quarterly for the first year, and version it visibly. New model capabilities, new platform features, and new use cases will all arrive faster than an annual review cycle. The quarterly review is also where you promote patterns: when three teams have asked for the same restricted use case and handled it well, move it into the allowed-by-default list. A policy that only ever adds restrictions is a policy losing touch with how the organization actually works.
Where to go next
For the adoption problem this policy supports, read From Shadow AI to Sanctioned AI. The PII standards referenced in your review tier are covered in Handling PII in Claude Requests, and the logging stance in Audit Logging Claude Usage.