Every organization deploying Claude in production has, or should have, a content policy: the categories of output that must never reach a user, the categories that need review, and the tone and claims the system is allowed to make on the company's behalf. Enforcement is where policies succeed or fail, and reliable enforcement is always a layered system — automated checks doing the volume, human sampling catching what automation misses, and an escalation path that turns findings into fixes. This article describes that layered model as recommended practice.
Layer 0: what the model and platform already do
Your enforcement stack does not start from zero. Anthropic's models are trained and operated under its Usage Policy, and refuse certain categories of request outright. On newer models this is visible in the API itself: Claude Fable 5, for example, can return a stop_reason of "refusal" with a stop_details.category field indicating why (documented categories include "cyber" and "bio"). Your application should handle refusal stop reasons explicitly — log them, show the user a graceful message, and count them, because a rising refusal rate is itself a policy signal worth investigating.
The cloud platforms add their own optional layers: Amazon Bedrock offers Guardrails, and Microsoft Foundry offers content filtering — see Bedrock Guardrails and Foundry content filtering for details. These enforce broad safety categories well. What they cannot do is enforce your policy: your regulatory phrasing rules, your prohibited product claims, your brand constraints. That requires the next layers.
Layer 1: automated checks you own
Run every output that reaches a user through checks you control, in order of increasing cost:
- Deterministic rules first. Blocklisted terms, required disclaimers present, links restricted to approved domains, output length and format constraints. These are cheap, fast, and auditable — write them as code, not prompts.
- Classifier checks second. For policy dimensions that need judgment ("does this constitute financial advice?"), a second, small model call can classify the output against your policy rubric before release. Keep the rubric versioned alongside the policy itself.
- Structured outputs where possible. Constraining the model to a schema shrinks the space of things that can go wrong — a JSON field can't contain a rogue paragraph the way free text can.
Decide per use case what a failed check does: block and regenerate, block and escalate to a human, or release with a flag for review. High-stakes surfaces (customer-facing, regulated content) should block; internal drafting tools can usually flag.
Layer 2: human-review sampling
Automation drifts out of date the moment your product, policy, or model version changes. A standing human-review sample is your calibration instrument. As recommended practice: review a fixed, random sample of production outputs on a regular cadence, plus 100% of outputs that were flagged-but-released; grade each against the policy rubric; and track the violation rate over time. When the sampled violation rate moves, something changed — a prompt edit, a model migration, or user behavior — and the sample tells you before customers do. Keep the graded samples: they double as training material and as evidence that your enforcement operates continuously (useful when regulators ask for records).
Layer 3: escalation and correction
A caught violation with no follow-through is a liability discovered and then ignored. Define, in writing: who is notified for each severity level, how fast, who can pull a feature from production, and where the incident is recorded. Every confirmed violation should end in one of three outcomes — a rule added to Layer 1, a prompt or system change, or a documented accepted risk with an owner's name on it. If your sampling keeps finding the same class of violation, the escalation path is broken, not the model.
A note on flagged content and retention
Be aware that enforcement exists on Anthropic's side too: if content is flagged as violating Anthropic's Usage Policy, Anthropic's documentation states it may retain those inputs and outputs for up to two years (and trust-and-safety classification scores longer) — an exception that applies even under zero-data-retention arrangements. Your internal policy training should make clear that "the API is stateless" is not a license to send prohibited content.
Where to go next
See designing human oversight for sizing the review function, the content moderation pattern for an implementation blueprint, and acceptable use for the policy layer beneath all of this.