Australia’s Privacy Act Reform: Building Automated Decision-Making Transparency Before It Bites

From 10 December 2026, an Australian organisation that lets software make consequential decisions about people has to say so, in plain words, in its privacy policy. The trap is not the disclosure. It is that most firms cannot yet list the systems the disclosure is meant to describe.

The Privacy and Other Legislation Amendment Act 2024 (Cth) received Royal Assent on 10 December 2024 and, among other changes, inserted three new sub-clauses into Australian Privacy Principle 1: APP 1.7, 1.8 and 1.9. These commence on 10 December 2026. They create a transparency duty around automated decision-making, and the Office of the Australian Information Commissioner has confirmed the date. This is not a live obligation yet. That is precisely why it is worth acting on now, because the work it demands is inventory work, and inventory work is slow.

What APP 1.7 to 1.9 actually oblige you to publish

The trigger sits in APP 1.7. It engages when an entity arranges for a computer program to make, or to do a thing that is substantially and directly related to making, a decision about an individual, where personal information is used and the decision could reasonably be expected to significantly affect the rights or interests of that individual. If that is happening, APP 1.8 requires the privacy policy to disclose three things: the kinds of personal information used in the operation of those programs, the kinds of decisions made solely by the programs, and the kinds of decisions for which a program does something substantially and directly related to making the decision. APP 1.9 closes an obvious gap by confirming that a “decision” includes a refusal or failure to make one, and that it counts whether the outcome helps or harms the person.

Two features matter for the technology function. First, the threshold is effect, not autonomy: a decision that significantly affects someone’s rights or interests is in scope even when a human signs it off, provided a program did something substantially and directly related to making it. A rules engine that scores an application and hands a human a recommendation is not obviously outside this. Second, the disclosure is at the level of “kinds” of decisions, not individual determinations, and the explanatory material is clear that you are not expected to publish commercial-in-confidence detail about how the models work. The duty is to describe the categories honestly, not to open the source.

The disclosure is trivial; the inventory is the work

Writing a paragraph for a privacy policy takes an afternoon. Being able to write a paragraph that is true takes a register. You cannot describe what you have not catalogued, and no organisation of any size has a reliable, current list of every place where software makes or materially shapes a decision about a person. That list has to be assembled deliberately, and the assembling is where the deadline actually lands.

Start an ADM inventory now and treat it as an engineering artefact, not a policy annexe. Each entry names a decision, not a system — one platform may host several distinct decisions, and one decision may span several systems. For each decision you record what personal information feeds it, whether the program decides alone or does something substantially and directly related to a human deciding, and what right or interest the outcome touches. Anyone who has built the equivalent register for the CCPA’s automated-decision duties will recognise the shape of this, and the two can share a spine even though the wording and thresholds differ.

Characterising each decision: role and effect

Two axes decide whether a decision belongs in the disclosure and how it should be described. The first is the program’s role: solely automated, or substantially and directly related to a human decision. This is a judgement about causal weight, not about whether a person clicks “approve”. If the human is rubber-stamping a score they cannot realistically override, the program is doing something substantially and directly related to the decision, and honesty requires you to say so. The second axis is effect: does the outcome significantly affect the individual’s rights or interests? The statutory examples run to granting or refusing a benefit, affecting contractual rights, and affecting access to a significant service or support. Marketing segmentation and internal routing that no one experiences as a decision about them will usually sit below the line; credit, eligibility, pricing, fraud holds, and access to services usually sit above it.

Record the judgement, and the reason for it, against every entry. When the OAIC or a complainant later asks why a given system was left out of the policy, “we assessed it and here is the note” is a defensible position. “We did not know it existed” is not. This is the same discipline that makes an AI-interaction disclosure hold up under the EU AI Act: the published words are only as good as the register they are drawn from.

A schema that generates the statement

Make the disclosure a build output, not a hand-written page that drifts out of date the moment a new model ships. Hold the inventory as structured data, tag each entry with the role and effect judgement, and render the privacy-policy language from it. The schema below is deliberately small; the value is that the same record drives the register and the published text.

# adm-inventory.yaml — one record per decision, not per system
# Renders the APP 1.8 privacy-policy language; keeps register and
# published text in step. British English throughout.

decisions:
  - id: credit-limit-assessment
    decision: "Set or decline a customer credit limit"
    personal_information:      # feeds APP 1.8(a)
      - Income and employment details
      - Repayment and transaction history
      - Credit-bureau score
    program_role: substantial   # solely | substantial | out_of_scope
    significant_effect: true    # APP 1.7 threshold
    right_or_interest: "Access to a financial product"
    assessed_by: "R. King"
    assessed_on: 2026-02-11
    note: "Analyst may override, but rarely does; program is a key factor."

# render.py — build the disclosure block (run in CI, not by hand)
import yaml

SOLE = "decisions made solely by our systems"
SUB  = "decisions our systems substantially and directly shape for a person to confirm"

with open("adm-inventory.yaml") as f:
    data = yaml.safe_load(f)

in_scope = [d for d in data["decisions"]
            if d["significant_effect"] and d["program_role"] != "out_of_scope"]

sole = sorted({d["decision"] for d in in_scope if d["program_role"] == "solely"})
sub  = sorted({d["decision"] for d in in_scope if d["program_role"] == "substantial"})
info = sorted({i for d in in_scope for i in d["personal_information"]})

print(f"We use personal information — {', '.join(info)} — in "
      f"automated systems. These include {SOLE}: {'; '.join(sole) or 'none'}. "
      f"They also include {SUB}: {'; '.join(sub) or 'none'}.")

The point of the pipeline is not elegance. It is that when a new decision system reaches production, adding its record to the inventory is the step that also updates the policy, so the two cannot silently diverge. A privacy policy that is generated from the register is a policy you can defend as current.

Where the shadow decisions hide

The systems you will name easily are the ones procurement bought as “decisioning” tools. The ones that will catch you out are the ones nobody labelled that way: a spreadsheet with embedded scoring logic that a team has relied on for years, a rules layer inside a CRM that auto-declines below a threshold, a fraud vendor whose hold nobody treats as a decision, a workflow tool quietly gating who gets escalated to a human at all. Each of those can be substantially and directly related to a decision that significantly affects someone, and each is invisible to a search that only looks for “AI”. The discovery exercise has to walk the actual customer journeys and ask, at every branch, whether software decided or shaped who went which way. Firms that have been through the equivalent under the UK’s data-protection reform, re-engineering safeguards for automated decision-making under the DUAA, consistently report that the shadow systems, not the flagship ones, took the time.

There are roughly eighteen months on the clock, and most of that is not drafting time. It is the time it takes to find every place a program decides something about a person, decide honestly whether it clears the threshold, and write the judgement down. The organisations that discover their shadow decisions in the last quarter of 2026 will not be able to describe them accurately, because accurate description depends on understanding you cannot manufacture under deadline. Start the inventory now, while it is cheap to be thorough.