AI Agent Guardrails Checklist template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

Deploying a customer-facing AI agent without guardrails isn't bold, it's negligent — and it's also unnecessary, because the guardrails are knowable in advance. This is the fourteen-point pre-launch checklist we run before any AI agent touches customers: scope boundaries, escalation paths, safety behaviors, audit logging, and the kill switch.

Every row is pre-filled with a specific guardrail across five categories. The in_place column makes launch a checklist decision — fourteen yeses, or documented reasons — instead of a hope. It applies to support AI agents (Zendesk AI agents, Claude-based agents) and any assistant acting on customer conversations.

How to use it, step by step

1. Define scope before capability. Rows one through three: what the agent may answer, what it must refuse, and what it does when unsure. An agent without written scope boundaries has them anyway — you just discover them in production.
2. Wire escalation as a first-class path. A human handoff that preserves conversation context, triggers on customer request or agent uncertainty, and actually reaches a staffed queue. Escalation that dead-ends is worse than no agent.
3. Set the safety behaviors explicitly. No invented policies, no promises about money or legal matters, no processing of abusive conversations without escalation — each is a row, each needs a named implementation, not an assumption that 'the model handles it'.
4. Turn on audit logging from day one. Every conversation logged, reviewable, and attributable. You'll need it for QA sampling (our CSAT/QA rubric applies to AI conversations unchanged), for incident review, and for the compliance question that eventually arrives.
5. Test the kill switch before launch. Someone on-call can turn the agent off in minutes, and the fallback (queue to humans, honest 'we're unavailable' message) is defined. If disabling the agent takes a vendor ticket, you don't have a kill switch.
6. Review the sheet monthly post-launch. Guardrails drift as prompts, content, and models update. The owner column exists so each guardrail has a person who re-verifies it — this is an operating document, not a launch gate.

What each column means

Common mistakes to avoid

• Launching with scope defined by the marketing demo instead of by written boundaries the agent enforces.
• Escalation that technically exists but lands in an unmonitored queue — customers who asked for a human and waited silently are angrier than ones never offered one.
• No conversation sampling after launch: automated resolutions deserve the same QA rubric as human ones, and skipping it means the agent's failure modes are invisible until a customer posts one.
• Treating the checklist as a launch gate instead of a monthly review — model updates and prompt changes silently move behavior.

Questions, answered

Do AI agents really need all fourteen?

For customer-facing deployment, yes — the checklist is the floor, not the ceiling. Internal-facing agents can defensibly waive some rows (documented, in notes). The pattern to avoid is waiving by omission: every guardrail either exists or has a written reason it doesn't.

Does this apply to Zendesk's built-in AI agents?

Yes — platform AI agents give you many of these controls as configuration (scope by help-center content, escalation rules, conversation logs), but configuration only counts as a guardrail once someone has deliberately set and tested it. The checklist is how you verify the platform's defaults match your intent.

Who should own AI agent guardrails?

One accountable owner for the sheet, with rows delegated — typically support ops for scope and escalation, IT/security for audit and kill switch. Committees own nothing; the owner column forces names. It's the same discipline as our go-live checklist, applied to AI.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.