The Australian ADM Transparency Obligation: Your AI Tools Are Now a Privacy Policy Problem

On 10 December 2026, subclauses 1.7, 1.8 and 1.9 of Australian Privacy Principle 1 commence, inserted by the Privacy and Other Legislation Amendment Act 2024. From that date, an APP entity that uses personal information in automated decision making must say so in its privacy policy, describing the kinds of personal information used and the kinds of decisions made. The OAIC published its Automated Decision Making Issues Paper on 18 May 2026, submissions closed on 15 June, and final guidance is expected by September. That timing is the practical problem. The guidance that tells you how broadly to read the obligation arrives roughly ninety days before the obligation itself, which means the work you can only start after reading the guidance had better be a policy edit, not an inventory exercise. The inventory takes months. The policy edit takes an afternoon.

It is worth being precise about how narrow the obligation is on its face, because a lot of commentary has inflated it. This is a transparency requirement and nothing more. Unlike Article 22 of the GDPR, it does not give an individual the right to contest an automated decision, it does not create a right to an explanation of a specific outcome, and it does not require you to notify anyone directly when a decision about them is automated. There is no human review right and no opt out. All that is required is that a public document accurately describes a category of activity. If you have ever wondered why a small obligation deserves attention, the answer is not the burden of the disclosure, it is the burden of working out what has to go in it.

The statutory test is where the reach comes from. The obligation bites where a computer program makes a decision, or does a thing that is substantially and directly related to making a decision, and the decision could reasonably be expected to significantly affect the rights or interests of an individual. That middle limb is doing enormous work. It deliberately captures systems that feed a decision rather than systems that pronounce it. A model that produces a risk score which a human then acts on is not making the decision, but it is very hard to argue it is not substantially and directly related to making one. The OAIC Issues Paper puts exactly this question to consultation, asking where the line sits between minor analytical steps and processes where an algorithm plays a central role, and everything in the commentary so far points to the regulator reading the limb generously rather than technically.

Now map that onto what has actually happened inside Australian businesses over the past two years. Teams have quietly inserted large language models into decision paths without ever calling it automated decision making, because the phrase sounds like a credit scoring engine from 1998. A recruiter pastes a stack of CVs into ChatGPT or Claude and asks for a shortlist. A support lead uses an AI triage layer that decides which tickets are urgent and which wait three days. A sales team runs lead scoring that determines who gets a call back. A trust and safety function uses a model to flag accounts for suspension. Most of these systems process personal information, most of them affect something a person cares about, and almost none of them appear on any register. Add to that the internal tools built with Lovable, Bolt or v0 by someone in operations who needed a workflow on a Tuesday, and you have a category of software that is both squarely in scope and completely invisible to whoever owns the privacy policy.

The instinct at this point is to reach for human review as the escape hatch, and that instinct needs testing before you rely on it. The Issues Paper explicitly canvasses partly automated decisions where a person retains final authority, and asks whether human involvement that is merely formal should be treated the same as involvement that is substantive. That framing is a warning. A reviewer who approves ninety eight percent of model recommendations in an average of eleven seconds is not meaningfully deciding anything, and a regulator with a broad reading of the middle limb will say so. The useful internal test is not whether a human clicked approve. It is whether that human had the information, the authority and the realistic opportunity to reach a different conclusion, and whether you hold any evidence that they sometimes did.

So the work to start now, ahead of the September guidance, is discovery rather than drafting. Do not send around a survey asking whether anyone uses automated decision making, because the honest answer from a team that uses AI daily will still be no. Ask instead where any system produces a score, a rank, a flag, a match, a priority, a recommendation or a shortlist that concerns a named person. For every answer, record four things: the decision the output feeds, the categories of personal information that go in, whether a human reviews the output and how that review is evidenced, and who inside the business owns the system. That register is the artefact. The eventual privacy policy wording is a summary of it, and writing the summary without the register is how organisations end up publishing a disclosure that is confidently wrong.

The good news is that most of this machinery probably exists already under another name. If you hold ISO 27001, you have an asset register and a supplier register, and the AI tools in question are sitting in one of them or should be. If you have started on ISO 42001, the AI system inventory that Annex A expects is close to the same document with an extra column, and treating the ADM register as a view over the ISO 42001 inventory saves you maintaining two lists that will drift apart within a quarter. Organisations reporting against the SOC 2 privacy criteria have already made assertions about how personal information is collected, used and disclosed, and an undisclosed automated decision path is a gap in those assertions as much as it is a Privacy Act issue. Vanta, Drata, Secureframe, Sprinto and Thoropass can all carry the register as a control with an owner and a review cadence, which matters because a static list captured once in November will be stale by the following winter. Anyone already tracking EU AI Act obligations will find the overlap substantial, since both regimes start from the same question of which AI systems touch which people.

On enforcement, keep the stakes in proportion but do not dismiss them. A non compliant privacy policy can attract a compliance notice, an infringement notice, or civil penalty proceedings brought by the Commissioner. In practice the first wave of attention is more likely to be reputational than punitive, and that is precisely why the disclosure needs care. A privacy policy is a public document. Journalists, competitors, enterprise procurement teams and the regulator can all read it, compare it to what your product visibly does, and draw conclusions. A thin or evasive disclosure that omits a system your customers already know about is worse than a candid one, because it converts a transparency question into a credibility question.

The wider pattern here is one that keeps repeating in 2026. The tools got cheap and easy enough that decisions about people started being automated by individuals rather than by projects, and the governance frameworks are catching up by asking organisations to simply write down what they are doing. That is a low bar and a fair one. The organisations that will struggle in December are not the ones with sophisticated models, they are the ones that cannot answer a basic question about where AI touches a customer, because the answer is scattered across a dozen tools that arrived on personal credit cards. Spend August and September building the register. When the OAIC guidance lands, the only thing left to do will be choosing the right words, and that is a problem you can solve in a day.