AI safety & conduct
AI safety & conduct is the content-moderation layer. It inspects what customers send in and what your assistant sends back, and because Configuration is project-level, whatever you enable here covers every agent - single and multi alike.
Find it at AI agents → Configuration → AI safety & conduct.
This section only appears if it's enabled for your account. If it isn't under Others in the left menu, safety filters aren't provisioned for your project - talk to your account team.
Standard content safety
Always on, and not configurable. It "provides foundational content moderation through a standard, built-in safety check" - the baseline every assistant gets whether or not you touch anything else on this page.
Advanced safety checks
Six optional checks on top of the baseline, in two groups of three. Each group shows how many you have on.
Customer query filters
Checks on what the customer sends in, before your assistant acts on it.
| Filter | What it does |
|---|---|
| Banned Topics | Restricts conversations on improper topics |
| Violence | Detects and blocks harmful, offensive or abusive language in an incoming message |
| Sexual content | Blocks sexually explicit or inappropriate language |
AI response filters
Checks on the reply your assistant has generated, before it goes out.
| Filter | What it does |
|---|---|
| Sensitivity | Removes personal or sensitive data from the output |
| Toxicity | Flags and blocks offensive or harmful language |
| Bias | Detects and reduces unfair or unintended bias |
The verbs matter, and they aren't all the same. Most of these filters block - the turn stops and the customer sees nothing. But Sensitivity redacts rather than blocks: the reply still goes out, with the sensitive values stripped. Bias reduces rather than stops. So don't assume enabling a filter means an offending turn never reaches the customer - for two of the six, a modified reply does.
That distinction decides where you need a fallback. A blocked turn needs somewhere to land; a redacted one doesn't.
The latency trade-off
Every check you enable is another moderation pass, and the page says so directly:
Enabling filters adds latency. For time-sensitive use-cases like VoiceAI agents, consider disabling them.
A pass that's invisible on chat can be an audible pause on a call. If one project serves both, decide which checks are non-negotiable for compliance and keep only those on for voice - you can run a fuller set on chat, where the cost doesn't show.
Best practices
- Turn them on before you ship, not after a customer finds the gap. A filter added in a post-incident review has already cost you the incident.
- Cover both directions for anything high-stakes. Query filters stop unsafe inputs; response filters stop unsafe outputs. Regulated or personal data wants both.
- Test what you expect to be caught. Send the inputs you most want blocked - banned topics, hostile language, attempts to extract personal data - through the Testing Lab before each release, and confirm each filter actually fires.
- Pair blocking filters with a safe landing. In finance or healthcare, back them with legal-approved fallback wording so a blocked turn has somewhere to go instead of a generic error.
- Re-measure latency after every change, especially on voice. Adding a check shifts your turn-timing profile.
That's the last Configuration section. Next: Create an agent - put these shared settings to work.
Building for phone calls? Voice settings is project-level too, but lives under AI agents → Voice.