Australia's 10 December AI Decision Disclosure Deadline

From 10 December 2026, Australian Privacy Principles entities that use personal information in automated decisions capable of significantly affecting an individual must say so in their privacy policy — specifically, the kinds of personal information involved and the kinds of decisions being made. The obligation was introduced by amendments to the Privacy Act made by the Privacy and Other Legislation Amendment Act 2024. It bites where an automated decision significantly affects an individual and meets the criteria set out in APP 1.7 to 1.9, so not every automated score, sort, price or approval is caught — but if you run automation that decides something consequential about a person, that deadline is yours.

The temptation is to treat this as a paragraph of text your lawyer adds to the privacy page. That reading is wrong, and it will cost you more later than doing it properly now. You cannot describe the kinds of decisions your systems make until you know what those systems are, what data they read, and what happens when they get it wrong. The disclosure is the output. The inventory, the decision logs and the escalation design are the work.

What the obligation actually covers

The trigger is narrower than "we use AI". It applies where personal information is used in an automated decision that could significantly affect an individual. In an SME context that usually means:

• Credit, payment terms, or deposit requirements set by a rule engine or model
• Pricing and discount eligibility that varies by customer attributes
• Recruitment screening, ranking or auto-rejection of applicants
• Eligibility assessments — for a service, a plan tier, a membership, a rebate
• Risk scoring that changes how a person is treated, including fraud flags and account suspensions
• Rostering or shift allocation decisions applied to employees

It does not obviously catch a workflow that summarises an email, drafts a reply for a human to send, or moves a file between systems. Nor does it catch every piece of sorting or ranking — the test is whether a decision about a person is made, and whether it significantly affects them. Where you are unsure, the safer position is to document it and disclose it. The cost of over-disclosure is a longer privacy policy. The cost of under-disclosure is explaining yourself to a regulator or a customer's lawyer without the records to do it.

Two other points matter for scoping. The obligation applies to APP entities, which excludes many businesses under the $3 million annual turnover threshold, but not those that trade in personal information, provide health services, or are contracted to the Commonwealth. And "automated" includes decisions made by deterministic rules, not just by models. A Retool app that auto-declines an application when three fields fall outside a range is an automated decision. Nobody needs to have used the words "AI" for the rule to apply.

The inventory is the whole job

Most SMEs cannot produce a list of their automations on request. The workflows accumulated over three years, some in n8n, some as Zapier zaps a departed marketing coordinator built, some as scheduled scripts, some as logic embedded in a Retool app that only two people can open. A privacy disclosure written without that list is a guess.

Build the inventory as a table, not a document. One row per automation, with these columns:

For a business running twenty to forty automations, this is two to three days of work if someone who knows the stack does it, and considerably more if they are reconstructing intent from a colleague's workflow named "new one v3 FINAL". The rows that come back marked "arguable" and "not at all" are your remediation list. Everything else is documentation.

If you want a structured way through the audit, our automation assessment works through the same mapping, and the integrations page lists the systems we most often find holding the decision logic.

Decision logging is the part that actually breaks

Here is the practical problem. When the OAIC, a customer's lawyer, or a customer asks why a particular application was declined on 14 January, you need to reconstruct the decision. That means the inputs as they existed at the time, the version of the logic that ran, the output, and who reviewed it.

Standard tooling does not give you this. n8n's execution history is built for debugging, and in most deployments old executions get pruned to stop the database growing without limit. Retool audit logging depends on plan tier and on the app being instrumented to record what it decided rather than only that someone clicked a button. Neither is designed as a seven-year evidentiary record, and neither should be relied on as one.

The fix is unglamorous and takes about a day per decision path. Write to a dedicated decisions table — Postgres, or whatever your primary database is — as a deliberate step in the workflow, not as a side effect of execution logging. Store:

• A decision ID and timestamp
• The subject (customer, applicant, employee) as a stable identifier
• A snapshot of the input fields the decision actually used, not a pointer to a record that will change
• The rule set or model version identifier
• The output and any score or confidence value
• Whether it was auto-applied or reviewed, and by whom
• The outcome of any subsequent appeal or override

That last field is the one everyone skips and the one that tells you whether your automation is any good. If eighteen per cent of auto-declines get overturned on review, your threshold is wrong and you have the evidence to fix it. Logging designed for compliance turns out to be logging designed for improvement, which is the only reason operations teams maintain it.

Escalation paths need to exist before they are documented

The second structural gap is human review. Plenty of SME automations have no defined path back to a person. The workflow decides, the email goes out, and the only escalation route is the customer ringing the office and getting whoever answers.

Design the path explicitly for every automation flagged as significantly affecting someone:

Pre-decision escalation. Define the conditions under which the automation refuses to decide and queues the case instead. Missing data, values at the edge of a threshold, an unusual combination of inputs, or a model confidence score below a set level. In n8n this is an IF node routing to a review queue rather than to the approval branch. In Retool it is a status field that puts the record in a reviewer's inbox.

Post-decision review. A named person, a stated response window, and a mechanism the affected individual can actually use. If your disclosure says decisions can be reviewed, the review has to happen.

Override capture. When a human changes the outcome, record the change and the reason against the original decision ID. This is what lets you demonstrate meaningful human oversight rather than rubber-stamping.

There is a reason to get this right beyond the December deadline. Reporting in August 2026 suggested roughly half of Australian and New Zealand organisations are already running AI agents, frequently with no formal governance around them. That is a lot of production automation with no inventory, no logs and no escalation design, and it is the pattern regulators will find first when they look.

The regulatory direction behind the date

The 10 December obligation is not an isolated item. On 15 July 2026 the Prime Minister reversed Australia's light-touch position on AI, announcing mandatory Australian AI Standards and a new Office of AI, with a national framework going to National Cabinet in August 2026 and legislation targeted for early 2027. On 19 July 2026 the government signalled it would tighten rules on automated decision-making inside departments including Centrelink and Services Australia, alongside a look at AI protections under consumer law. The ACCC has been tracking the spread of AI agents and integrated AI features across digital platforms as a competition and consumer issue.

None of that creates an immediate obligation for a thirty-person business. All of it changes what your customers will ask you in procurement, and what a "black box" vendor answer will cost you in a tender. Systems that can produce an auditable decision log will be easier to sell around than ones that cannot.

A four-month sequence

Working back from 10 December 2026, and assuming you get no further regulatory guidance in the meantime:

• August: Build the inventory. Classify each row for significant effect against the APP 1.7 to 1.9 criteria. Identify the automations with no log and no escalation path.
• September: Start decision logging on the highest-risk two or three paths. If the OAIC publishes guidance during this period, re-check your significant-effect calls against it; if it does not, document the reasoning behind each call so you can revise it quickly later.
• October: Build escalation routing and review queues. Backfill logging on the remaining flagged automations. Test by asking someone to reconstruct a specific decision from three weeks earlier.
• November: Draft the privacy policy disclosure from the inventory, not from a template. Brief the people who will handle review requests.
• Early December: Publish. Keep the inventory as a live document with an owner.

Four months is enough, provided the first fortnight goes on the inventory rather than on the policy wording.

Pull your automation list together this week — every n8n workflow, Retool app and vendor feature that reads customer or employee data — and mark the ones that decide something about a person. If that list runs longer than you expected, or you cannot tell what half of them do, book a scoping call and we will work through the classification with you.