Executive summary

Discovering an AI-related mistake is only the beginning of putting it right.

Correcting a record may leave someone with costs, lost time or an opportunity they cannot recover. This paper explains how organisations can respond to the person affected, look for others who may have experienced the same problem and check that changes have improved the process. The practical test is whether the promised help actually reached people and whether the next person will have a better experience.

For someone who has spent weeks trying to resolve a problem, “we have fixed the system” may not be the answer they need. The system might now work perfectly. They may still be waiting for a service, out of pocket or unsure whether anyone understands what happened to them.

Paper 15 followed the person asking an organisation to reconsider a decision. This paper begins after the organisation accepts that something went wrong. What needs to happen now, and when can it reasonably say the matter is resolved?

The answer needs to start with the person, not the technical repair. It also needs to reach beyond them, because the first person to report a mistake may not be the only one affected.

Begin with what the mistake meant

Consider a hypothetical request for assistance delayed because an AI tool misread a date and placed it in the wrong queue. Three weeks later, a staff member finds the error and moves the request forward.

That correction matters. It may prevent further delay. It does not tell us what those weeks meant for the applicant. Perhaps they incurred an expense or missed an opportunity. Perhaps the most frustrating part was being unable to obtain an explanation. These are possibilities the organisation needs to understand, not consequences it should assume.

A useful response makes room for the person’s account. What happened from their point of view? What is still unresolved? What would help now?

The appropriate remedy might include reconsidering the decision, correcting information, restoring access where possible, explaining the failure or considering other redress within the organisation’s powers. Some consequences cannot be undone, and that should be acknowledged honestly.

The Commonwealth Ombudsman’s complaint handling guide supports fair, timely and proportionate remedies, followed through rather than merely promised. [1] The available response depends on the organisation’s authority, contracts and legal obligations. This is not a universal entitlement to compensation, nor a suggestion that an apology always settles the matter.

Keep someone responsible until the help arrives

It is easy for a response to become a collection of handoffs. The complaints team writes to the applicant. A technical team corrects the record. Another team is expected to provide the service.

Each may complete its task while the person is still waiting.

Someone needs to follow the promised outcome through. In our example, that means checking that the corrected request reached the right team and received the attention agreed. If something remains open, the applicant should know what happens next and who is responsible.

This need not require an elaborate system. A clear record of the agreed action, owner, timing and result can help a small team keep its promise. The record should also show unresolved consequences and any available route for disagreeing with the proposed response.

The distinction is worth keeping in mind: sending an instruction to fix something is different from knowing that the person received the benefit of the fix.

Look for people who have not come forward

Once a fault is found, the organisation has a reason to ask whether it happened elsewhere. Waiting for another complaint leaves that discovery to the people least able to see the pattern.

A Commonwealth Ombudsman case about historic child support assessments shows why this matters. An individual complaint revealed an IT-system problem affecting approximately 33,000 people. This was not identified as an AI failure. It is a useful example of how resolving one complaint can leave a much larger task unfinished. [2]

For our hypothetical date-reading problem, the organisation would need to find requests that may have passed through the same faulty process. Which documents were involved? When did the problem begin? Did a particular version or instruction make a difference?

The first search may be incomplete. Cases marked routine or successful may also deserve attention. There should be a reason for including or excluding a group, rather than an assumption that only people who complained were affected.

Where further review or contact is appropriate, it needs an authorised owner and a plan for urgent cases and people who cannot easily be reached. Personal records must be protected. In a regional community, removing a name may not prevent details from identifying someone.

Protect people while you investigate

People may need help before the cause is fully understood. Within its powers, an organisation might pause an adverse action, introduce an extra check or temporarily stop the affected use. These measures can reduce further harm while the investigation continues.

They are temporary protections, and someone should return to assess whether they are still needed. An additional check introduced for a week can otherwise become a permanent burden without anyone deciding that it is the right solution.

The cause may also be wider than the model. A missing document, unclear policy, changed prompt or screen that hid uncertainty could have contributed. Staff may have relied on a summary because the original information was difficult to reach. Repairing the software alone may leave those conditions unchanged.

Suppliers can help diagnose and correct their products. The organisation still needs to own its response to affected people and obtain the evidence needed to understand its decisions.

The Australian Government AI technical standard addresses incident handling and corrective and preventive action. Its required criteria and explanatory material have distinct status and a government scope. [3] NIST’s voluntary framework also connects recovery with improvement. [4] Both provide useful reference points without creating identical legal duties for every regional organisation.

Check the repair before closing the matter

A change that fixes the first example may fail on another document, or create a new difficulty elsewhere. Testing should therefore include the affected pattern and relevant cases that previously worked.

In the date-reading example, that could include unfamiliar document layouts and dates the tool cannot confidently interpret. Staff should be able to show how they respond when the answer remains uncertain. These are practical tests proposed by BRAIN, not proof that every future case will be safe.

Before restarting a paused use, an authorised person needs to understand the test results and remaining risk. There should also be a reason to reopen the investigation if the problem returns. Important closure decisions benefit from a reviewer able to question the evidence, even when a small team shares several roles.

At the same time, check the individual outcomes. Have promised corrections happened? Have people been told what was found? Does anyone remain without an answer?

What will be different next week

A report headed “Lessons Learned” can be useful. The real lesson appears in what changes afterwards.

Perhaps staff will check the original document before an adverse decision. Perhaps a supplier agreement will provide better access to records. Perhaps the organisation will narrow the task or stop using AI for it. Give the change an owner and return to see whether it helped.

For leaders, a short account of unfinished remedies, unexamined cases and temporary protections is more useful than a reassuring list of meetings held. It keeps attention on the work that still matters.

BRAIN can support regional learning through research and practical governance methods without deciding another organisation’s remedies or collecting its private case files.

The applicant whose date was misread deserves more than a corrected entry. Taking their experience seriously means checking what can still be put right, finding others who may need help and carrying the lesson into the next decision.

About BRAIN

The Ballarat Region Artificial Intelligence Network (BRAIN) is a regional institution focused on understanding the impact of artificial intelligence across Ballarat and surrounding communities and strengthening the capability required to respond. Through research, publications and regional collaboration, BRAIN examines how AI can contribute to regional prosperity and wellbeing while helping institutions navigate its risks and wider consequences.

About the Author

Matt Bowd is Co-Founder and Chief Executive Officer of the Ballarat Region Artificial Intelligence Network (BRAIN). His work focuses on AI governance, institutional capability and the implications of artificial intelligence for regional organisations and communities.

Sources

[1] Commonwealth Ombudsman, Better Practice Complaint Handling Guide, 2023, pp. 29–32 and 36. Remedies, communication, follow-up and monitoring improvements.

[2] Commonwealth Ombudsman, Historic child support assessments, 2024. The case concerns an IT-system error, not an identified AI failure; approximately 33,000 individuals were affected.

[3] Digital Transformation Agency, AI Technical Standard: Statement 39, criteria 140–141; Introduction, Scope and Target Audience. Required criteria concern incident handling and corrective/preventive actions within the standard’s government scope; explanatory notes should not be confused with separate universal duties.

[4] NIST, AI Risk Management Framework Core, AI RMF 1.0 (2023), MANAGE 4.1–4.3. Voluntary guidance on monitoring, recovery and improvement.

Sources checked 21 October 2026.