The Go-Live Checklist Before an AI Agent Touches Client Data

A demo running on sample data proves an automation can work. It doesn't prove it's safe to run unsupervised on a client's actual accounts, inboxes, or records. The gap between those two states needs its own checklist: what data the agent can read, what actions it can take without approval, what it must route to a human first, and who signs off before it goes live.

Treat that sign-off as a required gate tied to the specific client engagement, not a general policy someone remembers to apply. Each client's tolerance for an automation acting on their behalf is different, and the checklist should capture that client's specific limits, not a generic default.

Before an agent goes live on client data, the checklist should record:

• What data the agent is allowed to read in the client's accounts, inboxes or records.
• Which actions the agent can take without approval, such as confirming an appointment already on the calendar.
• Which actions must route to a human first, such as sending a payment or committing to a price.
• Who signs off before go-live, tied to this specific client engagement rather than a general policy.
• The client's own limits on automation acting on their behalf, written down instead of assumed.

An agent's behavior changes when its prompt, its tool access, or the model behind it changes, and a client-facing incident is a bad time to discover nobody knows which version was actually running when something went wrong. A workflow that requires a version note, a summary of what changed and why, before any update ships to a live client environment turns that into a traceable record instead of a guess.

Pair that with a defined evaluation step: a short set of test cases the update has to pass before it replaces the version currently running, so a change doesn't reach a client purely because it looked fine on the one example someone happened to try.

Some actions are safe to automate fully, confirming an appointment already on the calendar, for instance. Others need a human to approve before anything happens, sending a payment, committing to a price, or replying to a message that mentions a complaint. The line between the two categories should be written down per client, not decided in the moment by whoever's watching the agent that day.

Build the approval step into the workflow itself: the agent drafts, a named person reviews and approves or edits, and only then does the action actually execute. This is the single most common gap in early automation builds, and the single most common cause of a client losing trust in the whole engagement. It also gives the agency a clean way to answer a client who asks, mid-engagement, exactly what the automation is and isn't allowed to do on its own.

Every live automation eventually does something the client didn't want. What separates a minor incident from a client firing the agency is whether there's a rehearsed rollback: how to pause the agent immediately, how to identify everything it touched since the last known-good state, and how to communicate what happened to the client without waiting for them to notice first.

Write this checklist before the agent goes live, not after the first incident. An agency that can say exactly what happened and what was already fixed by the time the client asks looks far more competent than one still investigating. Practicing the rollback once on a non-critical automation, before it is ever needed for real, also surfaces gaps in the plan while the stakes are still low.

Not everything needs to be a checklist someone runs. The reasoning behind a client's specific automation, why it's scoped the way it is, what was tried and rejected, is reference material for the next person who touches that account, not a repeatable procedure. A well-organized, searchable knowledge base handles that better than forcing it into a workflow tool built for step-by-step execution.

Use the checklist tool for the go-live gate, the version-update process, and the rollback plan. Use a documentation library for everything explaining why those checklists look the way they do for a given client.