What records should I set up before AI agents touch customer data?
A handover brings the recorded AI work and its verifiable receipts into one proof link. Review the evidence behind each claim, check what was and was not observed, then Accept or Flag.
Scope: a readiness checklist for records, not a compliance certification and not legal advice. Data duties depend on your sector, your contracts, and your jurisdictions.
Customer data changes the cost of every record failure. A missing step in a research job is an inconvenience; a missing record of which agent read or changed a customer's data is an incident you cannot scope. The setup on this page is therefore done before the first live run, as a gate, not as an aspiration.
The access inventory is the foundation: every agent and connection that can reach customer data, the scope of that reach, and a named owner, reviewed on the same quarterly cadence as the rest of the access record. The job record is the operating layer: work on customer data runs recorded, with the data-touching steps identifiable as their own class, so the question "what did the agent do with this customer's record" is answered by filtering steps, not by reading a quarter's chats.
Approval gates and the incident path complete the posture. Changes to customer data above your defined threshold wait for a recorded human decision; the gate itself is a step, so its presence or absence is visible on the record. And the incident template from this file's incident page gets a customer-data variant agreed now: who is told, in what order, from which records, because the first hours of a data incident are the wrong time to design the paperwork.
Checklist: before agents touch customer data
1. Access inventory: agent, data scope, owner, review date, for every connection that can reach customer data. 2. Recording rule: customer-data work runs only as recorded jobs; data-touching steps identifiable. 3. Approval gates: the change classes needing a recorded human decision first, listed with thresholds. 4. Minimisation: job records carry references to customer data, not bulk copies of it. 5. Incident path: the template, the notification order, and the records each step draws on, agreed and filed. 6. Review: inventory and gates re-checked quarterly and at every new connection.
Worked example
The approval gate in operation looks like the decision layer on any accepted record, for example https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , where a human decision is recorded on the work itself. For customer data, that same pattern is placed before the change executes, which is the only position where a gate protects anything.
Frequently asked questions
We are a tiny team. Is this proportionate?
The checklist scales down to a page: a handful of connections, one recording rule, two gate classes, one template. What does not scale down is the incident question, which arrives at full size regardless of team size, and is answerable only from records set up in advance.
Should customer data itself be inside the job records?
No: records should reference the data (which record, which customer system, what changed) rather than copy it. The record proves the touch and its authorisation; the data stays in its own governed systems.
Our agents only read customer data, never change it. Do gates still apply?
Reads need the inventory and the recorded steps; gates attach to changes. But define "change" carefully: an agent that reads and then sends, posts, or exports has crossed into the gated classes through the send, which is why the classes are defined by consequence, not by verb.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai