What must an Australian business disclose about its automated decisions?

The Privacy and Other Legislation Amendment Act 2024 added new paragraphs to Australian Privacy Principle 1, the principle that governs what an entity's privacy policy has to contain. According to the Office of the Australian Information Commissioner, those paragraphs commence on 10 December 2026.

From that date, an APP entity that has arranged for a computer program to make a decision, or to do a thing that is substantially and directly related to making a decision, where the decision could reasonably be expected to significantly affect an individual's rights or interests and personal information about the individual is used in the program's operation, must set out in its privacy policy the kinds of personal information used and the kinds of decisions involved.

The Commissioner has also said the obligation applies to decisions made from that date regardless of when the arrangement was put in place. An automated decision that has been running quietly for five years is in scope from the day the provision commences.

This page is a plain summary written for the people who will have to do the finding. It is not legal advice, and the authority on what the provision requires is the Commissioner and the legislation itself.

On 30 September 2026 the Office of the Australian Information Commissioner published its final guidance on the obligation: an updated chapter 1 of the Australian Privacy Principles Guidelines, a fact sheet on the APP 1.7 to 1.9 transparency obligation, and a flowchart for working through it. The OAIC's announcement of all three, the guidelines chapter and the fact sheet are linked under Sources below, and they are the documents to work from.

Three points in it matter most for the finding. According to the OAIC's fact sheet, "substantially" means the program's output is a key factor in helping a person make the decision, and "directly" means it has a direct connection to the decision.

The guidance also says a decision can be in scope even where the program's output does not replace the whole decision-making process, or is subject to human review. A person signing off is not, on its own, a way out.

And it confirms the obligation reaches well beyond AI. Decision-support tools and technology embedded in other software can be caught, which is why the list of AI tools an organisation bought is the wrong place to start.

The provision is written about computer programs, not about artificial intelligence. That distinction is the one most likely to catch an organisation out.

A rules engine that declines an application on a threshold is a computer program making a decision. A scoring spreadsheet that a person then approves may be a program doing something substantially and directly related to the decision. A model that ranks cases for review shapes which people get looked at, which is a decision about their interests even though a human signs it.

So the inventory that matters is not the list of AI tools the organisation bought. It is the list of places where software decides something about a person, or does the work a decision is then based on. Those two lists overlap far less than people expect, and the second is much longer.

There is a great deal of published guidance on the obligation, most of it from law firms, and it is generally accurate about what the law requires. Very little of it addresses the operational question that follows: how do you find every automated decision you already make?

That gap exists because the finding is not a legal problem. It is a discovery problem, and it looks like this: decisions are embedded in processes, processes span systems and teams, nobody holds a list, and the people who could tell you do not describe what they do as an automated decision because to them it is just how the system works.

The approach that works is to start from the processes rather than from the systems, because a decision belongs to a process even when it happens inside a system nobody thinks of as decisive.

• List the processes that touch individuals: customers, applicants, employees, claimants, patients, students. This is a shorter list than the full process inventory and it contains almost everything in scope.
• For each one, walk the path an individual takes through it and mark every point where an outcome is determined, narrowed, ranked, scored, prioritised, flagged or routed. Include the points where a person signs off on something a system prepared.
• At each marked point, ask what produces the outcome. A person applying judgement, a rule in a system, a model, a spreadsheet, or a configuration nobody has looked at in years. Write down which, and where it lives.
• Ask what personal information goes in. The provision is about programs using personal information, so the inputs matter as much as the logic.
• Ask who could reasonably be affected and how significantly. This is a judgement, and it is the one worth taking advice on rather than settling internally.

The disclosure itself is not onerous once the finding is done. It describes the kinds of personal information used and the kinds of decisions made, in language a member of the public can follow, in the privacy policy where a member of the public can find it.

The difficulty is that writing it publicly forces an internal question that can be avoided indefinitely while the list is private: is this decision one we are comfortable describing? An organisation that finds itself reluctant to write a sentence about a particular decision has learned something more valuable than a compliance artefact.

It is also worth keeping the finding rather than only its output. A privacy policy paragraph is the visible tip; the register behind it is what lets you answer the next question, whether that comes from a regulator, a board, or an individual asking why.

Everything above can be done with a spreadsheet and a series of conversations, and for a small organisation that is the right answer.

It gets hard when the processes are many, cross several systems, and are not written down, because then the finding is gated on a mapping exercise nobody has done. That is the situation Omni is built for: a model of how the work actually happens, generated from the documents, transcripts and wiki pages the organisation already has, with the AI governance module holding the decisions and their owners in the same model as the processes they sit inside.

The point is not the software. It is that this obligation rewards organisations that already know how their work runs, and gives the ones that do not a deadline to find out.