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 it is the record it claims to be rather than one edited to suit the moment. A record that fails any of the three still exists, but it does less work, and the whole point of keeping records under Guardrail 9 is that a third party can rely on them.

Which records to keep

Keep the records that show each material AI system was known, assessed, owned and watched. In practice that is the register entry for the system, the impact assessment behind any high-risk use, the named owner and the risk decision, the approval line and oversight arrangements for anything that acts on its own, the monitoring and review history and the incidents you logged with what you did about them. ISO/IEC 42001 frames this 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.

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, not a working file you tidy up once the project ships.

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 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, and by setting a review cadence 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.

Making records verifiable

The weakest point in most governance trails is not that records are missing but that they cannot be trusted. 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. Records that a third party can confirm have not changed since capture close that off, because they move the burden off your word and onto the record itself. This is the quality that separates a trail that survives an audit from one that merely exists, and it is worth building in from the start rather than reaching for when someone asks.

Common mistakes

• Keeping records for the flagship systems and none for the ones 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.

Frequently asked questions

What does Guardrail 9 actually require? It asks organisations to keep and maintain records that allow third parties to assess compliance with the standard. It does not prescribe a format, so the practical bar is that an outside reviewer could use your records to assess how your AI is governed.

Is there a mandated retention period for AI governance records in Australia? The Voluntary AI Safety Standard does not set one, because it is guidance rather than law. Other obligations that apply to your organisation, such as records or privacy requirements in your sector, may set retention periods, so check those against your own trail.

What makes a record verifiable rather than just stored? A stored record proves its contents. A verifiable record also proves it has not changed since it was captured, so a third party can rely on it without trusting whoever holds it. That is the difference an auditor or a due-diligence reader weighs.

Does Aicura decide what records I need to keep? No. Aicura surfaces the picture and holds the records you capture. It does not decide your retention approach, judge whether your trail is sufficient or attest to it on your behalf. The accountable owner sets the approach and answers for it.

Where Aicura fits

Aicura is your AI Register. It holds the AI systems in use as the record, versions each one as it changes and prompts you when a review is due, so the trail stays current with the systems rather than drifting behind them. Impact Assessments hold the risk decisions and their owners against each system, and Incidents holds the record of what went wrong and what you did, so the trail reflects how the systems actually behaved.

The Evidence Vault seals each record so it can be shown unchanged since capture, evidence you don’t have to trust us for, cryptographically anchored and verifiable without Aicura in the loop. That is what turns a stored record into one a reviewer can rely on. The Trust Centre lets you share those records with a board, an auditor or a customer directly, and Attestation lets an accountable owner sign a statement against the trail. Aicura surfaces the picture and holds the evidence. It does not set your retention approach, judge your trail or attest on your behalf. You decide what to keep and you answer for it.

For the related work, read how to prepare for an AI governance audit and how to respond to an AI governance due-diligence questionnaire. If you are weighing tooling, the AI governance software overview sets out what Aicura supports.

Sources

• Voluntary AI Safety Standard, Department of Industry, Science and Resources, industry.gov.au/publications/voluntary-ai-safety-standard
• 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

A note on this page

This guide is general information on how to keep AI governance records against current Australian and allied guidance. 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.