How to keep AI governance records that stand up to scrutiny

What “records that stand up” means

A record stands up when the person reading it cannot easily discount it. Three things decide that. It has to be complete, so the trail is not missing the systems or the decisions the reader cares about most. It has to be current, so it reflects the system running now rather than the one you assessed two years ago. It has to be verifiable, so the reader can confirm when it was captured and that it has not been edited to suit the moment. A record that fails any of the three still exists, but it does less work. For what an auditor does with these records, read how to prepare for an AI governance audit.

Which records to keep

The core set covers each material system’s inventory record, its assessments, its ownership and its monitoring. ISO/IEC 42001 frames these as documented information for the AI management system, and the test is simple. If a reviewer asked how a given system came to be in use and how you know it is still safe, the records should answer without anyone reconstructing the story from memory.

Record type	What it shows	When it is created
Register record and its versions	The system exists, what it does, who supplies it and how it has changed	At intake, then on every material change
Risk or impact assessment	What could go wrong, for whom, and the decision taken	Before deployment, then at each review or change
Owner and decision record	Who is accountable and what they accepted	When ownership is assigned or changes
Approval line and action log for agents	What an agent may do, who approved it and what it actually did	At approval, then continuously while it runs
Monitoring and review history	The system was watched and reviewed on schedule	At each review and threshold breach
Incident record	What went wrong, what was done and how it closed	From triage to closure
Policy and control versions	Which rules applied at the time of a decision	On each new version

How long records matter

A governance record matters for as long as the system it describes is in use, and usually beyond it. An assessment is not spent once the system goes live, because a reviewer looking at the system today will want the decision that put it there and every review since. When a system is retired, its records still answer questions about decisions made while it ran, so keep them rather than clearing them out.

Set a retention approach that treats the trail as evidence of governance over the system’s whole life plus a tail after retirement, not as a working file you tidy up once the project ships. Then check it against any period a law sets for you. Under the EU AI Act, providers of high-risk systems keep technical documentation for ten years after the system is placed on the market (Article 18), and deployers, the organisations using those systems, keep the logs a high-risk system generates for at least six months (Article 26). Records, privacy, employment and sector rules can set their own periods, and where personal information sits inside a record, privacy law may also limit how long you keep it.

Keeping records current

Records go stale when the system changes and the trail does not. An AI system’s risk shifts as its data, its permissions, its prompts, its model version or its purpose change, so an assessment that was accurate at procurement can describe a system that no longer exists. Keep the trail current by tying a review to the change, so that when a material system changes the assessment is due again. Set a regular review schedule for systems that drift slowly rather than in obvious steps. A record that is never revisited answers the question you had at the start, not the one a reviewer is asking now.

Keeping records verifiable

A document in a shared drive proves its contents but not its history, so a reviewer has no way to know it was not edited to fit the review. Capture records as the work happens, date and attribute them, and hold them where later changes are visible as new versions rather than silent edits. How far to take this, from version history up to records a third party can check independently, is covered in what makes AI governance evidence independently verifiable.

Common mistakes

• Keeping records for the flagship systems and none for the AI bought inside other software.
• Treating an assessment as finished at go-live and never revisiting it.
• Storing the trail where its contents are clear but its history cannot be shown.
• Clearing out records when a system is retired, then losing the story behind the decision.
• Recording the decision but not the owner or the date it was made.

In Australia

Australia’s Guidance for AI Adoption (AI6, National AI Centre, October 2025) replaced the Voluntary AI Safety Standard. It expects organisations to keep records that show how AI is governed but does not set a retention period, because it is guidance rather than law. Retention duties come from elsewhere, such as the Privacy Act 1988 (APP 11 requires personal information to be destroyed or de-identified once no longer needed), state and Commonwealth records legislation for public bodies, and APRA’s prudential standards for regulated entities.

Where Aicura fits

Aicura keeps two kinds of record, and they answer different questions. The audit log, on every plan, shows each change to your records in Aicura, with the fields before and after, who made it and when. At Pro, the Evidence Vault keeps sealed snapshots of governance-worthy events, such as an assessment accepted, an owner recorded, a guardrail version published or a batch of agent decisions, filed under the system and version they concern.

Keeping records current is the harder part, and the Cadence view, Aicura’s screen for recurring work, is built for it. At Pro, it shows how long ago each piece of work on each system, vendor, data asset, policy and training course was last done, marked Current, Aging or Stale, so an out-of-date assessment shows up before a reviewer asks for it. Your retention approach stays your decision.

Sources

• ISO/IEC 42001:2023, AI management system, International Organization for Standardization, iso.org
• AI Risk Management Framework (AI RMF 1.0), National Institute of Standards and Technology, nist.gov/itl/ai-risk-management-framework
• Regulation (EU) 2024/1689 (EU AI Act), Articles 12, 18, 19 and 26, eur-lex.europa.eu
• Guidance for AI Adoption, National AI Centre, Department of Industry, Science and Resources, industry.gov.au

A note on this page

This guide is general information on how to keep AI governance records against current international guidance, with an Australian note. It is not legal advice and it does not tell you what records or retention periods a particular law or contract requires of your organisation. For how the guidance applies to you, read the primary sources above and take your own professional advice.