Every Australian business that runs machinery keeps a near-miss log. A forklift that stopped thirty centimetres short, a spill that nobody slipped on, a guard found unlatched. None of these caused harm, but each one gets written down, because a near-miss is the cheapest warning you will ever get. AI agents deserve the same treatment. When Claude drafts a client email with the wrong figure and a person catches it before it sends, that is a near-miss. Right now, most companies throw that signal away.
Why a near-miss beats an incident report
By the time you are writing an incident report, the damage is already done. A wrong invoice went out, a customer saw data that was not theirs, a contract clause was misread. Safety teams worked this out decades ago: for every serious incident there are dozens of near-misses that share the same root cause. Catch the pattern in the near-miss and you never have to write the incident report. The same maths applies to AI. If your agent mishandles a date format and someone notices, that is a free lesson. If it happens forty times before anyone connects the dots, you have a systemic fault that will eventually reach a customer.
The cost gap is real. A single privacy breach reported to the OAIC can run past $45,000 once you count investigation time, customer notification, and remediation, and the maximum penalties under the amended Privacy Act now reach into the millions. A near-miss costs you two minutes to write down. Australian firms that treat AI oversight as a logging habit rather than a firefighting exercise spend far less across a year, and sleep better doing it.
What belongs in an AI incident register
A register only works if the fields are consistent. Keep it boring and keep it short. Every entry should answer what the agent was doing, what went wrong or nearly went wrong, who caught it, and what changed as a result. A workable set of columns:
Date, time, and which agent or workflow was running, for example the accounts-payable assistant or the client-intake bot.
What was expected versus what actually happened, in one plain sentence.
Severity: near-miss, minor, or reportable. Reportable means it may trigger an obligation under the Privacy Act or your APRA requirements.
Who caught it, and how: a human reviewer, an automated check, or a customer complaint.
Root cause once known: a bad prompt, missing context, a stale source document, or a genuine model limitation.
The fix, and the date it shipped. An open near-miss with no fix is just a scheduled incident.
Where the regulators are heading
This is not only good hygiene. APRA's CPS 230 operational risk standard expects regulated entities to identify, monitor, and manage the risks of the services they run, including services delivered by automation. AUSTRAC has been clear that reporting entities stay accountable for automated decisions inside anti money laundering processes. ASIC has warned Australian financial firms that deploying AI without adequate governance is a licence risk. A dated, honest incident register is exactly the kind of evidence these bodies ask for. It shows you saw the problems, ranked them, and acted.
The Privacy Act reforms raised both the penalties and the expectations around how organisations handle personal information inside automated systems. If an agent touches customer data, and almost all of them do, the register is where you demonstrate a reasonable standard of care. Regulators rarely expect perfection. They expect a system that notices and corrects itself, and a paper trail that proves it happened.
A register Claude can keep for you
The reason most incident logs die is friction. Nobody wants to stop, open a spreadsheet, and fill in eight fields while the real work waits. This is where Claude earns its place. You can point Claude at the channels where near-misses already surface, the review comments, the corrected drafts, the quick message that says a number was wrong, and have it draft a register entry in the agreed format for a person to confirm. The reviewer spends ten seconds approving instead of two minutes writing.
One Sydney logistics client we work with runs this pattern across three agents. Claude watches the correction signals, proposes register entries each afternoon, and a team lead approves them in a five minute review. Over a quarter they logged sixty near-misses, traced eight of them to a single badly worded instruction, fixed it once, and removed a whole class of error. The register paid for itself the first time an insurer asked how they manage AI risk.
Start this week
You do not need a platform or a policy committee to begin. You need a shared document and a habit.
Create one register for the whole business, not one per team. Patterns hide when logs are fragmented.
Agree the severity words up front so reportable means the same thing to everyone.
Log near-misses, not just failures. The near-misses are where most of the value sits.
Review the register fortnightly and ask one question: what shows up more than once?
Give a named person the job of closing entries, even when closing means deciding no fix is needed.
An AI incident register is the least glamorous governance tool you will build, and quite possibly the most useful. It turns scattered moments of 'that was close' into a record you can learn from, and into evidence that your business takes automation seriously. If you want help setting one up and wiring Claude in to keep it current, we can map it to your workflows in a short session. You can book a time with our team here.
