How to Document Your AI Workflow for an Auditor

The question is not whether your AI use is compliant. It is whether you can demonstrate what you did.

Auditors, clients performing due diligence, and regulators all ask variations of the same thing: what tools did you use, on what data, and how did you decide that was appropriate. An organization with a one-page record answers in a minute. An organization without one spends a week reconstructing it from memory and Slack history, and the reconstruction is always worse than the original would have been.

Here is the record, and it genuinely fits on a page.

What To Write Down

The tool inventory. For each AI tool in actual use: name, version, what it is used for, who uses it, and whether it transmits content externally. That last column is the one everything else depends on.

The data categories. Which kinds of content go to which tool. Concrete categories, not “sensitive data”: client names attached to matters, financial figures, personnel material, contract language, health information.

The model and license. For locally run models, the exact model identifier and revision, the license, and the date you verified it. For hosted models, the model version serving your requests and how you are notified of changes.

The vendor answers. For each hosted tool: inference location, retention period, subprocessor list, training exclusions, and the date you obtained those answers. See how to audit an AI vendor in 2026.

The decision and its reasoning. Two or three sentences per tool on why this use is appropriate. This is the part people skip and the part auditors most want.

The review date. When you last checked, and when you will check next.

That is six items. An hour of work, and it converts an anxious conversation into a document handover.

Why The Reasoning Column Matters Most

An auditor is not primarily checking whether you chose correctly. They are checking whether you chose deliberately.

“We use a local model for client-confidential drafting because content is not transmitted externally, and a hosted model for general drafting containing no client-identifying detail” is a defensible position. It shows a distinction was drawn and applied.

“We use AI for writing” is not a position. It shows nothing was considered, which is the finding an auditor is looking for.

The reasoning does not need to be sophisticated. It needs to exist, be written down before you were asked, and be consistent with what people actually do.

Records For Locally Run Models

Local processing removes most vendor questions and introduces one obligation of its own: you are now the record keeper, because there is no vendor to ask.

Five things to capture per model, once:

1. Exact model identifier and revision. Families contain many variants with different terms.
2. License name and version, copied into your records rather than linked, since pages get edited.
3. Published checksum and confirmation that the downloaded file matched it.
4. Total parameter count and quantization, so you know what you actually ran.
5. Date recorded.

That answers “which model version processed client data in March, and under what license,” which is the specific question that arrives eighteen months later when nobody remembers.

Wrivio verifies model downloads against a published SHA-256 before use, which covers item three automatically. Items one, two, four, and five are a five-minute copy-and-paste.

If your documentation lives in files you need to annotate, stamp, or sign before sending to a client, a browser-based tool like Docento handles that without a full desktop PDF suite, and it says files are processed locally on the device.

The Inventory Problem Nobody Admits

Your inventory will be wrong if you build it from procurement records, and this is not a minor discrepancy.

Surveys through 2026 consistently find roughly a third of employees using AI tools their employer does not know about, and that among workplace AI users a large majority bring unapproved tools. An inventory assembled from what was purchased describes a different organization from the one you have.

The fix is to ask, anonymously, with a credible promise of no consequences for honest answers. You will learn more in one survey than from a year of network logs, because the usage on personal phones never appears in your logs at all. See shadow AI statistics for 2026.

An inventory that acknowledges shadow usage and describes what you did about it is stronger than one that pretends it does not exist. Auditors have seen the surveys too.

Writing The Summary For An External Reader

The document that leaves your building needs to be specific without being a security disclosure.

Before:

We are committed to responsible AI use and comply with all applicable data protection regulations. Our AI tools are used in accordance with our internal policies and industry best practices.

After:

AI use summary, reviewed 30 July 2026

Drafting and editing of client-related documents uses a rewriting tool that runs locally on our workstations. Document text is not transmitted to any external service, which we have verified by network monitoring. The model is licensed Apache 2.0, and the version and checksum are recorded in our asset register.

General drafting containing no client-identifying detail may use an approved hosted service, contracted under a data processing agreement, with processing located in the EEA and content excluded from provider training.

We do not use AI to make or materially influence decisions about individuals, and we have reviewed our use against the EU AI Act risk categories without identifying any high-risk system under Annex III.

Next review: January 2027.

That paragraph answers what was asked, states what was verified rather than what was promised, and names a review date. A blanket claim of full compliance is weaker than a specific accurate statement, because it invites the follow-up question of how you know.

A Wrivio Context for compliance documentation could say:

Rewrite this as a formal compliance record for an external reader. Neutral professional register, complete sentences, no contractions. Keep every date, version number, license name, jurisdiction, and factual claim exactly as written. Do not add certifications, guarantees, or commitments that are not in the original, and do not replace specific statements with general assurances.

Press Ctrl+Shift+Space, run it, and read the diff carefully. Specific verified claims turning into blanket assurances is the exact failure a rewriting pass introduces here, and an overstated compliance claim is worse than a modest accurate one. Run this in Local mode, since the document describes your own controls.

Keep It Boring And Current

Two habits that make this sustainable.

Review on a schedule, not when asked. Quarterly or semi-annually, with the date written in the document. A record with a recent review date signals a process; one dated eighteen months ago signals a panic.

Note changes rather than rewriting history. When you switch models or vendors, add a line with the date rather than replacing the old entry. The trail is the value.

Common Questions

Is this necessary for a small firm?

If you handle client, patient, or financial data, yes, and it takes an hour. The alternative is reconstructing it under time pressure while a client waits.

What if we have no formal policy yet?

Write the record first. It will show you what your de facto policy is, which is a better starting point for a written one than a template.

Do we need to record every rewrite?

No. You record the workflow, the tools, and the reasoning, not individual uses. Per-use logging would itself create a data-protection problem.

Who should own this?

Whoever owns your risk register, with input from whoever actually uses the tools. A record written without the users will describe an organization that does not exist.

Download Wrivio for Windows to run a checksum-verified local model, with the documentation trail already simple.