12. Safety, Policies, and Guardrails

What this section is for

As soon as your AI feature touches real users, safety becomes an engineering requirement, not a vibe.

This section teaches you how to build systems that behave predictably when:

• the model refuses or content is blocked,
• users submit ambiguous, adversarial, or sensitive inputs,
• outputs need to be safe and policy-aware,
• you need auditability without leaking private data.

The mental model: safety is multi-layer

Safety is not one setting. It’s multiple layers working together:

• Model behavior: built-in refusal patterns and boundaries.
• Platform safety settings: category thresholds and filtering.
• App-level guardrails: your prompts, schemas, validation, UX, logging, and access controls.

Platform safety helps, but it cannot replace app design.

The builder’s job (what you control)

As a builder, your job is to make safety behavior:

• predictable: clear outcomes and clear UX states,
• recoverable: users can rephrase or choose safe alternatives,
• auditable: you can understand what happened without storing dangerous data,
• bounded: untrusted input doesn’t become instructions, tools don’t run wild.

Section 12 map (12.1–12.5)

• 12.1 What safety filters can and cannot do
• 12.2 Designing prompts that avoid risky behavior
• 12.3 Building “refusal-aware” UX in your app
• 12.4 Handling sensitive data responsibly
• 12.5 Audit trails: saving prompts and outputs safely

Where to go next

• Start with 12.1
• Then continue to Part V (real projects)