AI Content Safety and Refusal Policies in Production

Write the refuse list before you ship "helpful"

Content safety is not vibes from the foundation model. It is a product policy: categories you will not assist with (and how you fail closed)—medical diagnosis overreach, weapons help, prohibited discrimination, and whatever else your counsel and risk owners name. APRF Safety & Responsible AI expects that document, an owner, and enforcement that survives a prompt edit.

A consumer bot once leaned only on provider defaults. A "be maximally helpful" prompt tweak weakened self-harm-adjacent refusals. No policy ID, no classifier, no safety suite in CI. Restoring the old prompt stopped the bleed; the lasting fix was an explicit policy plus a pre-response filter.

Layers, not a single sermon

1. Policy text with IDs referenced in configs

2. Model instructions aligned to that policy

3. Input/output filters (and tool blocks for disallowed actions)

4. Fail closed on filter errors for high-severity classes

5. Safety evals that gate release—including jailbreaks aimed at your refusals

6. Refusal logs (category, policy ID, request ID) without hoarding unnecessary sensitive content

Filtering only the user message misses tool output and retrieved text. Provider moderation is a layer, not the program.

Review on a calendar

Policies age when products and regulations move. Schedule reviews. Borderline cases get a human escalation queue—not improvised per-request ethics from the model. Injection attacks often combine with safety bypass; defend both (see the injection guide).