What Evidence Do You Actually Need to Show You're Governing AI?

Detailed Explanation

Ask most small businesses whether they govern their use of AI and they'll point to a document: an AI usage policy, a list of approved tools, maybe a data processing agreement filed away from when they signed up to a vendor. That's a reasonable starting answer, and it's also not what "evidence of governance" actually means once someone with a real reason to ask — a customer's security questionnaire, an insurer at renewal, an auditor, a regulator following up a complaint — starts asking follow-up questions.

The distinction is between an artefact and a record. An artefact describes intent: this is our policy, this is our approved-tools list, this is our register of what we use. A record proves conduct: on this date, this tool processed this task, this person reviewed the output before it went to the customer, and this is what changed as a result. Almost every business that believes it's "covered" has artefacts. Very few have records, and it's the records that actually answer the question being asked.

This matters because the artefact-only position collapses under one follow-up question. "You have a policy that says outputs get reviewed before sending — can you show me an example of that review happening?" A business with only a policy document has nothing to show. A business with even a basic record — an approval note, a timestamp, an initial next to the output — has an actual answer.

What Counts as Evidence, Concretely

For a small or mid-sized Australian business, useful evidence of AI governance is built from a handful of specific, low-effort things, tracked consistently rather than elaborately:

• Which tool and model handled the task. Not just "we used AI" — which product, and which underlying model where that's known and relevant (a customer-facing chatbot answer generated by one model behaves differently to one drafted with a different model or a different system prompt).
• Which prompt or template version was used, where the business uses a standard prompt, template, or workflow for a repeated task. A prompt that gets quietly edited over time without anyone tracking the change is one of the more common ways an AI-assisted process drifts from what was originally reviewed and approved.
• Where it ran, in terms of data handling — a cloud consumer tool, a business-tier account with different data-handling terms, or a private/on-premises setup. This is the same information a register captures at the tool level, but tied here to the specific run.
• Who reviewed the output, and when, before it reached a customer or fed into a decision. A name and a date is often enough; the point is that it's recorded somewhere rather than trusted to memory.
• What changed as a result of the review, if anything. A record showing outputs are reviewed and never once changed is a different (and less convincing) story than one showing genuine edits, corrections, or occasional rejections — the latter is what a review process that's actually doing something looks like.

None of this needs a dedicated compliance system to start. A shared spreadsheet, a workflow tool's own run history, or a simple approval step logged in whatever platform already runs the process is enough for most businesses — the standard is consistency and honesty, not sophistication.

The Difference Between a Policy, an Inventory, and Evidence

These three documents get conflated constantly, and keeping them distinct makes the evidence question much easier to answer:

• A policy (see what should an employee AI usage policy include) states the rules: which tools are approved, what data can and can't go into them, what review is required before output is used.
• A register (see what actually goes in an AI register, and who is going to read it) lists what's actually in use, at the tool level — one row per AI tool, who owns it, what it can access.
• Evidence is the third layer neither of the above provides: proof that the policy was followed and the register reflects reality, demonstrated through actual, dated records of use.

A business can have excellent versions of the first two and still fail an evidence check, because a policy and a register both describe a snapshot or an intention, not an ongoing practice. The three work together — the policy sets the rule, the register tracks what exists, and the evidence shows the rule was applied to what exists.

This is exactly the gap that shows up when a customer sends a security questionnaire with an AI section — a policy and a register answer most of the structural questions, but the questions about what actually happened on a specific engagement need the evidence layer to answer honestly.

Things to Consider

• Start with the highest-stakes workflows, not everything at once. A business doesn't need evidence records for every trivial internal use of AI on day one — begin with anything customer-facing, anything feeding a decision about a person, or anything a contract or customer already asks about, and expand from there.
• Consistency beats sophistication. A plain, consistently kept log beats an elaborate governance framework that's only ever filled in properly for the first two weeks. Whoever asks for evidence is generally more reassured by a boring, current record than an impressive-looking document nobody's touched since it was created.
• Evidence should be quick to produce on request, not reconstructed under pressure. If pulling together proof of a specific review means asking three different people to remember what happened, the record-keeping isn't actually working yet, even if the underlying review itself was fine.
• This isn't only about certification or regulation. Even a business with no compliance obligation at all benefits from being able to answer "did we actually catch that mistake before it went out?" with a record rather than a guess.
• How long evidence needs to be kept is a separate decision from whether to keep it at all. See how long should you keep records of AI tool conversations and outputs for setting a retention period once the practice of keeping records is in place — and where a sector-specific rule already fixes the answer, such as NDIS providers' 7-year claim-record duty, that rule takes precedence over a business's own discretionary policy.

Common Mistakes

• Treating the policy document as the finish line. Writing (or buying a template for) an AI usage policy and considering the governance question closed is the single most common gap — the policy is the easy 10%; the ongoing record-keeping is the part that actually gets tested.
• Confusing "we could technically reconstruct this" with "we have a record." Being able to dig through email threads and chat histories after the fact if pressed is not the same as having a current, purpose-built record — the difference shows immediately when someone asks for evidence with a short deadline.
• Recording only the successes. A review log that never shows an output being corrected or rejected looks curated rather than genuine, and undermines confidence in the whole record rather than building it.
• Over-engineering the first version. Waiting to roll out evidence-keeping until a proper system, dashboard, or dedicated tool is in place means most businesses never start — a spreadsheet used consistently from today beats a perfect system planned for next quarter.