AI compliance evidence
AI compliance evidence: the records that show what you actually did
Most published AI governance material stops at policies and principles. The question that gets asked in practice is narrower and harder: when an insurer, a large client or a regulator asks what you did about AI, what do you hand them?
Australian government guidance is direct about this. Keep clear records of the actions you take under each essential practice, because good documentation is what supports audits and reviews later.
General information about Australian obligations, not legal advice.
What evidence should an Australian business keep about its use of AI?
At minimum, seven records: a register of the AI systems in use, a named person accountable for them, the assessment and decision recorded for each provider, the AI policy with its approval and staff acknowledgements, training completions by name, records of any AI-related incident and what was assessed, and the date each of those was last reviewed. Organisations with higher-risk uses add risk assessments, privacy impact assessments, use-case decisions and output verification records.
Each of those has to pass the same test: a record that a specific thing was decided, done or checked, by a named person, on a date, and which existed before anyone asked for it. Everything below is an application of that test.
Evidence assembled after an incident is not worthless, but it answers a different question. The question being asked is what the organisation's position was at the time, and a record created afterwards cannot speak to that.
This matters more for AI than for most areas, for a specific reason. AI has made it trivial to produce a convincing document about anything. The artefact no longer distinguishes an organisation that did the work from one that generated a description of the work, which shifts the weight onto the things a document cannot fake: a named person, a date, a decision with consequences, and a review that happened when it was due rather than when it was needed.
A stated position and an operating control are different evidence
Both belong in the record. What causes trouble is presenting the first as though it were the second, usually without meaning to, because a compliance folder flattens everything into files.
Evidence of a stated position
- An AI usage policy exists and says X.
- The register lists five approved AI services.
- A supplier questionnaire was completed for a provider.
- A risk was recorded with a treatment decision.
- The policy names a review frequency.
Answers the question: what does this organisation say it does?
Evidence that something operated
- Eleven of twelve staff acknowledged the policy, on these dates.
- MFA was confirmed enforced on every AI account in March.
- A named person assessed the provider and refused two others.
- The risk owner reviewed it in June and left it accepted, in writing.
- The review ran on the date it was due, and here is what changed.
Answers the question: what actually happened here?
The test that separates them
Ask whether the record could exist if the underlying thing had not happened. A policy can exist without a single control being implemented. A dated acknowledgement list with eleven names on it cannot exist unless eleven people acknowledged something. That is the difference, and it is why the second kind is worth disproportionately more when someone is actually looking.
Sixteen records worth keeping about AI
Not all of these apply to every business. A ten-person firm with two approved tools and no automated decisions can produce a credible record from about seven of them.
| Record | What it evidences, and what it does not |
|---|---|
| 1. Approved AI tool register | Which services the organisation decided to permit, with the owner and the date. Evidences the decision. Does not evidence that staff only use those. |
| 2. AI system inventory | Everything in use including embedded features, with purpose and information types. The foundation record. Its value depends entirely on whether it is maintained. |
| 3. Provider due diligence records | What was asked, what the answers were, where they came from and when. Evidences that an assessment happened, which a completed template alone does not. |
| 4. Approval or refusal decisions | The outcome, the basis and the person. Refusals are frequently better evidence than approvals, because they show a real decision was being made. |
| 5. Risk assessments and treatments | The risk, its rating, its owner, and whether it was reduced, transferred, avoided, monitored or accepted. An accepted risk should carry a written acceptance rather than silence. |
| 6. Privacy review or impact assessment | Where an AI use touches personal information. The OAIC recommends a privacy impact assessment as part of a privacy by design approach to AI products. |
| 7. Policy approval | Who adopted the AI policy, on what date, and which version. Not the same as the policy document itself. |
| 8. Staff acknowledgements | Named people who have read and accepted the rules, with dates. The record most often missing, and the one most often asked for. |
| 9. Training completions | Who was trained, on what, when, and whether it is still current. Attendance at a meeting with no list is not this. |
| 10. Assigned responsibilities | Who owns AI governance, who assesses providers, who receives incident reports, and evidence that those people know. |
| 11. Use-case decisions | For each significant use: what was permitted, under what conditions, and what verification applies. Particularly important for anything affecting people's rights. |
| 12. Output verification records | For the categories where checking is mandatory, evidence that a named person did it. Usually lives in an existing sign-off rather than a separate record, which is fine if the sign-off is real. |
| 13. Technical control evidence | MFA on AI accounts, access reviews, offboarding completion, integration authorisations reviewed. Point-in-time confirmations with dates. |
| 14. Exception records | Where something outside the rules was allowed, who allowed it, on what basis, and for how long. An exception with no end date is a rule change nobody made. |
| 15. Incident and breach records | What happened, when it was known, what was assessed, what was decided, what was done. Including the assessment against the notifiable data breach criteria where personal information was involved. |
| 16. Review history | That the policy, the register, the providers and the risks were reviewed when they were due, by whom, and what changed. This is what turns everything above from a snapshot into a position. |
An AI governance evidence map
Control, owner, action, evidence, review. Five columns is enough to make a governance position legible, and the discipline of filling in the last two is where most of the value is. This is a worked example, not a template to adopt unread.
| Control | Owner | Action | Evidence | Review |
|---|---|---|---|---|
| AI accountability | Managing director | A named senior person owns AI use | Policy naming the owner, adopted and dated; the owner has accepted the assignment | Annual |
| Approved AI systems | Operations manager | Maintain the list of permitted services | Current register with dates; the two refusals recorded with reasons | Quarterly |
| Provider assessment | Operations manager | Assess before approval, not after adoption | Completed assessment per provider, with sources and the approval decision | Annual, or on terms change |
| Information rules | Managing director | Define what may and may not be entered | Rules in the acknowledged policy; acknowledgement list with names and dates | Annual |
| Staff awareness | Practice manager | Train people on the rules and the failure modes | Completion records by name and role, currency status | Annual, plus induction |
| Human oversight | Team leads | Verify defined output categories before release | Existing sign-off records for client-facing work, showing a named reviewer | Semi-annual sample |
| Account security | IT provider | MFA and access control on every AI account | Dated confirmation check; exceptions recorded and closed | Quarterly |
| Access removal | Practice manager | Remove AI access at offboarding | Completed leaver checklists including AI accounts and integrations | Per departure |
| Incident handling | Privacy officer | Report, assess and act on AI-related incidents | Incident records with dates and outcomes; breach assessments where applicable | Per event |
| Governance review | Managing director | Review the AI position and record the outcome | Dated review record with what changed and what stayed open | Annual |
Read the last column first. A map with ten controls, ten owners and no review dates describes an organisation that did this once. The review column is what makes it a position rather than a project.
Evidence that looks like evidence and is not
None of these are dishonest. They are what an organisation produces when it is asked for something it does not have, and the gap only becomes visible under a specific question.
A policy with no adoption record
The document exists and nothing says who approved it, when, or which version anyone read. It evidences that someone wrote something.
A register built for the questionnaire
Assembled the week it was requested, accurate on that day, never updated. It describes a moment rather than a practice, and the next questionnaire will find it stale.
Training that happened in a meeting
The training was real and useful. With no attendance record, no date and no content, there is nothing to produce and nothing to renew.
A supplier assessment with no decision
The questions were asked and the answers recorded. Nothing says whether the provider was approved, refused, or approved on conditions, so nobody owns the outcome.
An owner who does not know
A name appears against a control in a document the named person has never opened. Assignment on paper is not assignment.
Evidence that has quietly expired
A control check from three years ago against a control that is reviewed annually. It is genuine history and it is not current proof, and presenting it as current is the mistake.
The three moments this gets tested
An insurer
Wants to know what controls were in place, whether staff were trained, and whether the position was maintained. Increasingly asks about AI use specifically. Answers given at application become part of the record.
A larger customer
Sends a security questionnaire with AI questions in it: which tools, whether our data goes into them, whether it trains models, who reviews output. Wrong or unsupported answers are worse than gaps.
A regulator
Asks what reasonable steps were in place before the incident. A record built afterwards addresses a question nobody asked. What regulators check.
How long to keep it
Long enough to cover the period someone might ask about, which in practice means several years rather than one. Keep superseded versions of policies and registers rather than overwriting them, because the question is usually about a past state. Expired evidence should stay in the history and stop being presented as current, which is a different thing from deleting it.
Built as the work happens, not assembled when asked
The evidence problem is not storage. It is that records get created by the work and then scattered, so the organisation has done the thing and cannot show it. Cleverer's model is built around exactly the distinction on this page.
Declared and evidenced are separate states
Saying a control is addressed is recorded as a declaration. It caps there. Only current independent evidence or a passed dated verification check moves a control to evidenced, so an assertion cannot promote itself.
Evidence expires
A record is current for its own expiry date, or failing that for the control's authored review cadence. When it lapses it stays in the history and stops counting as proof, and the gap surfaces rather than sitting invisible.
Gaps stay visible
A failed or overdue verification raises a deficiency with an owner. An unassessed control is recorded as unassessed rather than being averaged away, so the coverage figure is paired with how much has actually been assessed.
What comes out at the end
A dated Evidence Pack assembled from the organisation's own record: what applies to the business and why, control posture with the evidence behind each area, open gaps and who owns them, policy and governance lifecycle, training by role, asset and supplier registers, incident and breach history, risk register and treatments, and the chronology of when all of it happened. Expired evidence is included and labelled rather than presented as current, and verification failures are in it too.
It does not guarantee legal compliance and no platform can. It lets the organisation demonstrate the reasonable steps it took, with dates against them. How the evidence system works, or what audit evidence looks like.
Which of these could you produce this afternoon?
That is a more useful question than whether the records exist somewhere. The Readiness Check walks the same ground as the sixteen records above and tells you which ones are actually reachable.
Questions about AI compliance evidence
What evidence should an organisation keep about AI?
Seven records cover most small and medium organisations: the AI system register, the named accountable person, the provider assessments and decisions, the policy with its approval and acknowledgements, training completions by name, incident records including anything assessed against the notifiable data breach criteria, and a review date against each. Higher-risk uses add risk assessments, privacy impact assessments, use-case decisions and output verification records. The sixteen records on this page set out the full set and what each one does and does not evidence.
Is a policy document evidence of compliance?
It is evidence that a policy exists. It says nothing about whether the policy was approved, issued, understood, followed or reviewed, and nothing about whether the controls it describes are in place. Those are separate records, and they are the ones that carry weight when someone is actually testing the position.
Does evidence have to be created in a system?
No. A dated email approving a tool is evidence. A spreadsheet somebody maintains is evidence. The practical problem with informal records is not their form, it is that they are scattered, undated, unowned, and impossible to assemble under time pressure, which is exactly when they get asked for.
Can we use AI to help produce compliance evidence?
To draft and structure a record of something that happened, yes. A review summary drafted with AI and confirmed by the people who were in the review is ordinary documentation. What cannot happen is the record existing without the event. The test is not how the text was produced, it is whether the thing it describes occurred.
How long should AI compliance records be kept?
Long enough to cover the period someone might ask about, which usually means several years. Keep superseded versions rather than overwriting them, because the question is generally about a past state. Expired evidence should be retained as history and clearly marked as no longer current.
What is the single most useful record to start with?
The list of AI systems actually in use, with an owner and a date. Every other record depends on it, most organisations do not have it, and it is the one that takes a week rather than a quarter.
