DEV Community

2pizza.team
2pizza.team

Posted on Originally published at 2pizza.team

10 December 2026: Your Privacy Policy Has to Name the Decisions Your Software Makes

Not legal advice, an engineering read. From 10 December 2026, an APP entity that uses personal information in a computer program to make or substantially contribute to a decision that could reasonably be expected to significantly affect a person's rights or interests must say so in its privacy policy: what kinds of personal information, and what kinds of decisions. Civil penalties apply to a privacy policy that does not. The date is fixed in the legislation, not a target.

Most of the Australian AI regulation conversation this year has been about things that did not happen. The ten mandatory guardrails for high-risk AI were proposed, consulted on, and then shelved in favour of regulating through existing law. A lot of businesses built a mental compliance plan around those ten and are now aimed at nothing.

Meanwhile the obligation that did pass, quietly, inside the Privacy and Other Legislation Amendment Act 2024, commences on 10 December 2026. It is narrower than the guardrails and far more concrete, and it is the one with your name on it if you run automation that touches people.

Does it apply to you

Three conditions, and all three have to be true.

  • You are an APP entity: most businesses over the turnover threshold, plus health service providers and some others regardless of size

  • Personal information goes into a computer program that makes a decision, or does something substantially and directly related to making one

  • That decision could reasonably be expected to significantly affect someone's rights or interests

The second condition is wider than people assume and it is where most automation projects land. It does not require the software to make the final call. A scoring step that a human then rubber-stamps is substantially and directly related to the decision. The regulator has signalled a broad reading, so a system designed around the argument that a person technically decided is a system designed around a weak position.

What counts as significantly affecting rights or interests

Not defined exhaustively, and it will be argued at the edges. The clear cases are the familiar ones: credit and lending, employment and hiring, insurance, access to a service someone depends on, tenancy, anything about eligibility. The clearly-outside cases are equally familiar: a chatbot answering opening hours, a recommendation of which blog post to read next, routing an enquiry to the right inbox.

The uncomfortable middle is where most small businesses actually operate. Lead scoring that decides who gets called back is closer to the line than people expect, because the person who never gets called has had an outcome decided about them by software.

What the obligation is, precisely

This is a transparency measure and nothing more, and being precise about that saves a lot of unnecessary engineering.

What you must do:

  • Say in your privacy policy that personal information is used in automated decision-making

  • Say what kinds of personal information are used

  • Say what kinds of decisions are made that way

What it does NOT require:

  • A right for the individual to contest the decision

  • An explanation of the logic or the model

  • A right to human review

  • Direct notification of affected individuals

That second list matters as much as the first. Several vendors are already selling explainability and appeal workflows as though December requires them. It does not. Build those if your own standards call for them; do not buy them under the impression that the Privacy Act is asking.

The part that is actually hard

Writing the paragraph is an afternoon. Knowing what to write in it is the project, and this is where the deadline bites.

To describe the kinds of decisions your software makes, somebody has to enumerate them. In most businesses we look at, nobody can. Automation accretes: a scoring step here, a routing rule there, a threshold somebody set two years ago and left. The privacy policy is downstream of an inventory that does not exist yet.

The inventory that has to happen first:

  • Every automated step that consumes personal information, including the ones inside tools you did not build

  • For each, what it decides or contributes to deciding, in plain words

  • Which of those could reasonably be said to significantly affect someone

  • What personal information each one actually reads, not what the spec says it reads

  • Who owns it, because someone has to keep the policy true as the system changes

Third-party tools are the part that catches people. A CRM that scores leads, an email platform that decides send order by predicted engagement, a support tool that routes by sentiment: you did not build the model, but you chose to use it on your customers' personal information, and the decisions are yours.

What it means if you are building automation right now

Three engineering consequences, all of them cheap now and expensive in November.

  • Log what the system decided and on what inputs, per decision, from day one. Not for the regulator, who is not asking for it, but because the inventory above is impossible to reconstruct later from code.

  • Keep the decision points nameable. A pipeline where scoring, routing and thresholding are distinct, named steps can be described in a privacy policy. One where they are tangled through a prompt cannot.

  • Write the policy paragraph while you build, not after. If it is hard to write, the design is unclear, and that is worth knowing before launch rather than after.

A proportionate plan, if you are starting now

Eleven weeks is enough, and it is not a lot.

  • Weeks 1 to 2: inventory. List every automated step touching personal information. Expect the list to be longer than anyone predicts, mostly because of bought tools.

  • Weeks 3 to 4: triage. Mark the ones that plausibly affect rights or interests. When unsure, mark it in; the cost of disclosing something you did not have to is nothing, and the cost of the reverse is a penalty.

  • Weeks 5 to 6: write the policy text and have it reviewed by someone qualified. This is the step to spend money on.

  • Weeks 7 onward: fix the systems that could not be described, because that is the real finding.

One honest note on the last line. Every time we have run this exercise, the valuable output was not the policy paragraph. It was discovering two or three automated decisions nobody in the business knew were being made.

Verify current status and your own position with someone qualified before making a compliance decision. If you want the inventory done rather than the advice, that is a thing we build: the audit at /audit is free and takes two minutes. Ivan / 2pizza.team


Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Top comments (0)