When an enterprise writes its first AI usage policy, the natural instinct is to write one document that covers everyone. That instinct is right for the baseline — everyone needs the same definitions, the same prohibited uses, the same escalation path. But it breaks down at the edges. Marketing drafting campaign copy with Claude faces very different risks than treasury summarizing pre-release financials. If one policy has to cover both, it will either strangle the low-risk team or under-protect the high-risk one. The pattern that works in practice is a layered policy: a short company-wide baseline, plus department addenda that can tighten it but never loosen it.
The baseline: what applies to everyone
The company-wide layer should stay short and stable. It typically covers: which AI tools and platforms are approved, which data classifications may never be sent to any AI system, the requirement that a human remains accountable for anything acted upon, and where employees go with questions or incidents. Because it applies to everyone, keep it free of team-specific detail — the moment the baseline says "except for the finance team," you have started writing spaghetti policy. See the policy template article for a section-by-section starting point.
Department addenda: tighten, never loosen
Each addendum inherits the baseline and adds controls specific to that department's data and decisions. The one rule that keeps the stack coherent: an addendum may only add restrictions, never grant permissions the baseline denies. If a department genuinely needs something the baseline prohibits, that is not an addendum — it is an exception, and it should go through your exception process where it gets an owner, a scope, and an expiry date.
Typical addenda: finance adds output-verification requirements for anything feeding regulatory reporting; HR adds decision-influence limits around recruiting; legal adds privilege and confidentiality rules; customer-facing teams add disclosure and accuracy obligations.
Avoiding contradictions
Contradictions creep in when addenda are written by different people at different times with no shared owner. Three practices prevent most of them:
Single editorial owner. Departments propose their addenda, but one function — often the AI steering committee or its policy lead — merges and publishes them, checking each new addendum against the baseline and its siblings before it ships.
An explicit precedence rule. Write it into the baseline: "Where documents appear to conflict, the more restrictive requirement applies, and the conflict must be reported to the policy owner." That gives employees a safe default while the wording gets fixed.
Synchronized review. Review the whole stack together on one cadence rather than each document on its own anniversary. Contradictions are usually introduced by asynchronous edits.
Making the layers real on the platform
A policy that lives only in a PDF depends entirely on people remembering it. On the Claude API and Claude Platform on AWS, the natural enforcement unit is the workspace: workspaces separate different projects, environments, or teams while keeping billing and administration centralized, and an organization can have up to 100 of them. API keys are scoped to a single workspace, so "the finance workspace" and "the marketing workspace" can carry genuinely different operational settings. Workspace-level spend caps and rate limits can be set lower than — but not higher than — the organization's limits, which mirrors the tighten-never-loosen rule exactly. And when a department's use case is retired, archiving its workspace immediately revokes all API keys in it.
On Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, the equivalent enforcement lives in your cloud's own account, project, and IAM structure — the mapping differs by provider, so confirm the details with your cloud team.
Where to go next
Start with the enterprise policy template for the baseline layer, then read the department-specific guides for finance, HR, and legal. For the platform side, the platform overview covers how each cloud structures access.