Nobody gets asked whether they used AI. They get asked to show what they used, what it touched, and who checked the result before it mattered. Those are three different records, and almost nobody is keeping them.
The organizations that will struggle are not the ones using AI aggressively. They are the ones using it casually, with no record, and finding out eighteen months later that a question has been asked they cannot answer.
Who eventually asks
The list is longer than most people assume, and the requests do not look alike.
- A client or a customer whose contract says something about confidentiality, subcontracting, or how their data may be processed.
- A funder or a grantor asking how deliverables were produced.
- A regulator in a sector that already regulates the underlying decision — lending, employment, health, insurance, education.
- Your own auditor during a routine controls review, once AI is on their checklist.
- Opposing counsel, if a decision your organization made is ever disputed.
- A prospective customer's procurement team, in a security questionnaire, before they will sign.
That last one arrives soonest and is the easiest to underestimate. Vendor questionnaires now routinely ask about AI use, and the honest answer of "we are not sure" costs deals.
Document the process, not the keystroke
The instinct is to log everything. Every prompt, every response, retained forever. That program dies in about six weeks, because the volume is unmanageable and nobody can find anything in it.
Document at the process level instead. For each business process where AI is used, keep a short standing record:
| Field | What it captures |
|---|---|
| Process | The specific workflow — drafting client correspondence, summarizing intake notes, screening applications |
| Step | Where in the workflow AI enters, and what it does not do |
| Tool | Which tool, which account type, and as of when |
| Data | What categories go in — and, explicitly, what does not |
| Review | Who reviews output, against what, before it moves on |
| Owner | The named person accountable for this process |
Six lines per process. For most organizations that is a page or two total, and it answers the majority of what anyone will ask.
Then keep transcripts only where they matter
There is a narrow category where the process-level record is not enough: anywhere AI output informs a decision about a specific person. Hiring, discipline, promotion, benefits, credit, eligibility for a service, disciplinary referrals. In that category, keep the actual artifact — the input, the output, and the reviewer's disposition.
The reason is simple. If that decision is ever challenged, the question will be whether the person got individualized consideration or whether a tool sorted them. A process description does not answer that. A record showing what the tool produced, what the reviewer changed, and why does.
Keep that category deliberately small. If it is growing, that is worth a conversation about scope rather than a bigger storage bill.
Name a human in the record
The single most common gap is that review is described in the abstract. "Output is reviewed before publication" appears in the policy, and nowhere in any document is there a name.
Put the reviewer in the record. Not a role — a person, or a role that resolves to one identifiable person on a given date. What that buys you is the ability to say that a human took responsibility, which is the question underneath nearly every AI accountability inquiry. A reviewer who is described but never named reads, to anyone examining it later, as a reviewer who did not exist.
The same applies to what they did. "Reviewed and edited for accuracy; corrected two figures against the source" is worth more than a checkbox, and it takes about the same amount of time to write.
Write the disclosure rule down before you need it
Whether to tell clients that AI was used in their work is a real question and the answer depends on your contracts, your sector, and your relationships. What is not optional is deciding it on purpose and writing it down.
Three things to settle:
- What your existing contracts already say. Confidentiality clauses, subcontracting and third-party processing terms, and data-handling schedules often already govern this. Read them before writing a new policy that contradicts them.
- Where your sector has an expectation. Some professions have published guidance on disclosure. Check yours rather than assuming.
- What you will say when asked directly. Draft it once, in advance. Answers improvised during a client call become de facto policy, and rarely a good one.
Retention follows the work, not the tool
AI does not create a separate retention regime. A record connected to a personnel decision follows your personnel retention rules. A record connected to a client engagement follows the engagement schedule. The mistake is inventing an "AI retention policy" that sits beside your real schedule and quietly contradicts it. Confirm the applicable schedule with counsel and attach the AI records to it.
Start smaller than you think
Documentation programs fail because they are designed for an organization with a compliance department. If you do not have one, build the version you will actually maintain:
- List the processes where AI is used. One line each. You will discover some you did not know about; that is the point.
- Fill the six fields for the three highest-stakes ones. Highest stakes means anything touching a person, a regulator, or a client deliverable.
- Add the named reviewer to those three. If there is not one, that is the finding, and you found it before someone else did.
- Put a date on the document and a review interval. Quarterly is enough for most organizations. An undated record with no review date reads as abandoned.
- Extend one process at a time. A living record covering four processes beats a comprehensive one covering everything as of a date nine months ago.
Why this is worth the hour
Documentation gets treated as defensive overhead. It is, but that is not the main return. The act of writing down where AI enters a process, what data it touches, and who reviews the result surfaces the gaps while they are still cheap to fix — the process nobody realized had no reviewer, the tool three people are using under personal accounts, the step where sensitive data goes somewhere it should not.
You find those by writing it down. Every organization that finds them the other way describes the experience the same way afterward: we knew, we just had never written it down anywhere we would have to look at it.
Questions people ask
Do we have to log every single AI interaction?
No, and trying to is how documentation programs collapse. Log at the level of the process, not the keystroke: which processes use AI, for what step, with what human review. Full transcript retention is reserved for the small number of uses where a decision affects a person.
What should an AI use record actually contain?
At minimum: the process, the tool and version or date, what categories of data it touched, what the AI produced, who reviewed it, and what they changed. That set answers the questions an auditor, a regulator, or opposing counsel will ask.
How long should we keep AI records?
Match the retention schedule that already applies to the underlying work. AI does not create a separate retention regime; a record about a personnel decision follows your personnel retention rules. Confirm the applicable schedule with counsel rather than inventing a new one.
Who is responsible if the AI output was wrong?
The organization and the person who signed off. No credible framework treats a tool as an accountable party, which is exactly why the reviewer needs to be named in the record rather than implied.
Is a policy enough, or do we need evidence?
A policy states intent. Evidence shows practice. Anyone reviewing you will ask for both, and the gap between them is the finding. A modest amount of real evidence beats a thorough policy nobody can show was followed.