Australia's 10 December 2026 Automated Decision-Making Rules: What App and AI Builders Must Do

From 10 December 2026, if your app or AI agent uses personal information to make or drive decisions that significantly affect people, your Australian privacy policy has to say so. That date is about two months away, and most product teams have not yet listed which of their features count.

This guide explains what the rule actually requires, which common app features trigger it, how to audit your product in an afternoon, and what to put in the policy. It is written for founders and engineers, not lawyers. Confirm your own position with a privacy lawyer.

What changes on 10 December 2026

The Privacy and Other Legislation Amendment Act 2024 added new transparency requirements to Australian Privacy Principle 1 in the Privacy Act 1988. They switch on 10 December 2026.

An organisation is caught if all three of these are true:

1. It has arranged for a computer program to make a decision, or to do something substantially and directly related to making it.
2. The decision could reasonably be expected to significantly affect the rights or interests of an individual.
3. The program uses personal information about that individual to operate.

"Making a decision" includes refusing or failing to decide, and it applies whether the outcome helps or hurts the person.

If you are caught, your privacy policy must set out:

• the kinds of personal information used in operating those programs;
• the kinds of decisions made solely by a program; and
• the kinds of decisions where a program does something substantially and directly related to the decision (a human is still in the loop, but software drives the outcome).

Two details matter for builders. First, the rule is technology-neutral. It is not limited to AI. Second, it covers existing systems, not only new ones.

Which app features probably trigger it

"Significantly affect" is a question of substance, not labels, and the guidance is still settling. The table is our reading of where the line likely sits. It is not legal advice.

When a feature is borderline, the practical advice is to disclose it. Over-disclosure in a privacy policy costs you a sentence. Under-disclosure is the thing a regulator can point to.

The 5-step builder audit

You can do a first pass of this in a day with one engineer and one product owner.

1. Inventory every automated decision

Walk the product and list every place software decides something about a person without a human typing the outcome. Check:

• backend services and cron jobs (scoring, flagging, auto-approval);
• AI agents and LLM calls that classify, rank, approve or deny;
• third-party SDKs and APIs, such as fraud tools, ID verification, credit bureaus and recruitment platforms, because using someone else's model does not remove your obligation;
• no-code automations (Zapier, Make, n8n) that route or reject customers.

2. Record the personal information each one uses

For every item, note which fields feed the decision: identity details, financial data, location, behavioural data, device signals, free-text user input. This becomes the "kinds of personal information" list in your policy.

3. Classify the impact

Mark each decision as low, borderline or significant. Be conservative. Anything that affects money, access to a service, employment, housing, insurance or account status should be treated as significant.

4. Separate "solely automated" from "substantially driven"

The policy needs both categories. A fraud system that auto-blocks a card is solely automated. A model that scores applicants for a recruiter to review is substantially driven. Keep the lists separate, because the wording differs.

5. Build logging so the disclosure stays true

A privacy policy that was accurate in December can be wrong by March when someone ships a new model. For each significant decision, log the inputs category, model or rule version, outcome and timestamp. Add "update the privacy policy" to your release checklist for anything that adds a new automated decision. This is also the foundation for answering complaints and access requests.

What to write in the privacy policy

Keep it plain English and specific. Vague lines such as "we may use automated tools to improve our services" are unlikely to satisfy the requirement. A workable structure:

Automated decision-making. We use computer programs to make or support the following kinds of decisions:

• Account verification and fraud checks. We use your name, date of birth, identity document details, device information and transaction history to decide whether to approve, restrict or suspend an account. These decisions are made by software, with human review available on request.
• Eligibility assessment. We use your income information and repayment history to recommend whether you qualify for a product. Our staff review these recommendations before a final decision.

Adapt the content to your real system. Do not copy sample wording that describes decisions you do not make, or leave out ones you do.

Where this sits next to UK and EU rules

If you sell in more than one market, the Australian rule is lighter than the European model in one way and broader in another.

• EU and UK GDPR (Article 22) historically restrict decisions based solely on automated processing with legal or similarly significant effects. The UK has since reformed this area through the Data (Use and Access) Act 2025, so check current UK guidance rather than older summaries.
• Australia takes a disclosure-first approach but reaches further into "human in the loop" decisions where software substantially drives the outcome.

A single decision register, with the data used, impact rating and human-review status for each automated feature, serves all three regimes. Build it once.

Why this matters for AI agents specifically

AI agents make this easy to miss. An agent that handles support tickets, triages leads, screens documents or processes refunds is making decisions all day, often through prompts rather than code that a developer can grep for. Teams routinely forget about them.

If you run agents in an Australian business, add them to the inventory, record which tools they can call and what authority they have, and keep an audit trail of what they decided and why. We cover that architecture in our guides to AI agents for business and fintech AI agent platforms, where audit logging and human-in-the-loop checkpoints are standard requirements.

Timeline to get ready

Need help building compliant decision systems?

We build AI agents, fintech platforms and web and mobile apps for businesses in Australia and other regulated markets, with decision logging, audit trails and human-review checkpoints designed in from the start. If you want a second pair of eyes on your product's automated decisions before December, book a free scoping call or see how we work with Australian clients.

This article is general information, not legal advice. Check the Privacy Act and OAIC guidance, and speak to a qualified privacy lawyer about your situation.