What should an internal policy for employee AI work records say?
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 starting template for an internal policy, not legal or compliance advice. Adapt it with your own counsel and your sector's requirements before adoption.
An internal records policy exists to make the right behaviour the default before any incident tests it. Long policies fail quietly: nobody reads them, so nobody follows them, so the incident finds the gap the policy was meant to close. The one-page form below keeps only the clauses that change behaviour, each with an owner and a moment where it bites.
Clause one is the recording default: work for clients, and any output a customer, a regulator, or money depends on, runs through the recording connection and is delivered as a record. Clause two is approval: the classes of output that need a named human decision before release (external sends, money movement, customer-data changes) are listed, and the decision is recorded on the work itself. Clause three is retention by class, pointing at the schedule rather than restating it. Clause four is access: the inventory of agents and connections, reviewed quarterly. Clause five is departure: access revoked and record ownership reassigned the day someone leaves, because orphaned records are how companies lose their own history.
Adopt it as a draft, run it for a quarter, and revise from what the records show: the steps nobody recorded, the approval class that generated friction, the retention class that filled with noise. A policy revised from evidence stays alive; a policy written once in a panic becomes wallpaper.
Template: the one-page AI work records policy
1. Recording: client work and consequential outputs run recorded; delivery is a handover. 2. Approval: [list the classes] require a named human decision recorded on the job before release. 3. Retention: per the records schedule [link]; exports quarterly to company storage. 4. Access: agent and connection inventory [link], owner per entry, reviewed quarterly. 5. Incidents: bad outputs are recorded the day they are found, using the incident template. 6. Departures: access revoked and records reassigned on the final day. Owner: [name]. Review date: [quarterly date]. One page; if it grows past one page, move detail into the linked schedules.
Worked example
Clause two in operation is visible on any accepted handover, for example https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , where the decision on the work is recorded by the decider with its date. Policy language becomes real exactly there: a decision that lives on the record, not in a thread.
Frequently asked questions
Who should own this policy?
The person who owns operations or delivery, not the person who owns the AI tools. Records exist for clients, auditors, and incidents; the policy's owner should be the one who answers those audiences.
How do we enforce clause one without policing chats?
Enforce at the delivery boundary: work that leaves the building must arrive as a record. What employees explore privately stays private; what the company stands behind gets recorded. The boundary is enforceable because it is visible.
Does the policy need to name tools?
Name the recording standard and the connection, not a catalogue of permitted apps. Tools change quarterly; the record classes and approval duties are the durable content.
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