There is a date on your organisation's AI roadmap that is probably not on your AI roadmap: 10 December 2026. From that day, new automated decision-making transparency rules under the Privacy and Other Legislation Amendment Act 2024 take effect, and they change what your privacy policy has to say about the software making decisions in your business. For most organisations the compliance attention has gone to legal and data teams. The exposure, though, sits somewhere quieter and busier: the contact centre.

This is not a ban on automation, and it is not a chatbot problem. It is a disclosure rule. The question it forces is deceptively simple, and most organisations cannot yet answer it: can you list every automated decision a customer meets before a person does?

What actually changes on 10 December 2026

The reform adds new transparency obligations to Australian Privacy Principle 1, the principle that governs open and transparent management of personal information. The commencement date is 10 December 2026, a 24-month delayed start measured from the Act receiving Royal Assent on 10 December 2024.

From that date, an APP entity that has arranged for a computer program to make, or to do a thing that is substantially and directly related to making, a decision must address that in its privacy policy, where the decision could reasonably be expected to significantly affect the rights or interests of an individual and personal information is used in the program's operation. In plain terms, the policy has to set out the kinds of personal information involved and the kinds of decisions being made this way.

Three points are easy to miss and worth stating plainly:

• "Making a decision" expressly includes refusing or failing to make one, so a system that quietly declines or defers counts.
• Beneficial decisions are captured too, not only adverse ones.
• There is no grandfathering. The obligation applies to decisions made on or after 10 December 2026, regardless of when the system or the data behind it was acquired.

One more caveat matters for anyone drafting content or policy on this right now. The Office of the Australian Information Commissioner published an Issues Paper on 18 May 2026 and closed consultation on 15 June 2026, but final guidance on exactly which decisions fall in scope has not yet been published. So the precise boundary is still being drawn. That is a reason to map your own decisions early, not a reason to wait.

Why the contact centre is the most exposed surface

When people picture automated decisions under this law, they tend to picture credit scoring, insurance underwriting, or government benefits. Those are the illustrative cases regulators point to, and they are real. But they are not where most organisations quietly run the largest volume of automated, customer-affecting decisions every day. That happens in service.

A modern contact centre is a dense layer of software making or shaping outcomes before a human is ever involved. Consider the likely candidates: routing that decides who a customer reaches, triage that decides how urgent they are, deflection that decides whether they get a person at all, hardship pre-screening, priority scoring, and identity or risk flags that change how a case is handled. Each of these can influence a decision that affects a customer's access, eligibility, or treatment, and each typically runs on personal information.

We are careful to call these likely candidates rather than settled examples, because the OAIC has not yet published the guidance that will confirm what counts. The point for a service leader is not to pre-judge the legal line. It is to recognise that the contact centre is where the volume lives, and therefore where the disclosure obligation is most likely to bite.

The two questions your privacy policy now has to answer

The new transparency requirement effectively asks an organisation to describe two categories of automated decision.

Decisions made solely by software

The first is straightforward to picture: decisions made solely by the operation of computer programs, with no human in the loop. A bot that closes a case, refuses a request, or resolves an outcome on its own belongs here.

Decisions software substantially and directly shapes

The second is broader and less comfortable. It covers decisions where a computer program does a thing that is substantially and directly related to making the decision, even when a person signs it off at the end. A human who approves a queue of recommendations they did not generate, or acts on a risk score they cannot see inside, may well be making a decision the software substantially shaped. In a busy operation, that category can reach a great deal of the queue.

Legal can write the paragraph. Only operations can write the list.

This is where the reform stops being a compliance task and becomes an operating-model question. A privacy policy update is a paragraph, and legal can write it. But you cannot disclose a decision you cannot see, and the inventory of automated decisions inside a live service operation is not something legal holds. It lives with the people who run the floor: the operations leaders, the workforce and quality teams, the people who know what the routing engine actually does at 4pm on a Friday.

The work, in other words, is not the wording. It is the list. And the only people who can build an accurate list are the ones close enough to the operation to know where software is quietly making or shaping calls that affect customers.

This is also why the reform is a useful prompt rather than a burden. Building that inventory tends to surface things worth knowing anyway: automated decisions nobody formally owns, deflection logic that no longer matches policy, risk flags that outlived their reason. The disclosure is the deadline. The visibility is the value.

What to do in the three months you have

From early September, you have just over three months. A sensible sequence looks like this.

First, map the automated decisions in your service operation before you touch the policy page. Get operations, not only legal, in the room. Second, sort them into the two categories above, and be honest about the second one, the decisions software substantially shapes. Third, note which of these could reasonably be expected to significantly affect a customer's rights or interests, since that is the threshold the law turns on. Finally, hand legal a real list to describe, rather than a blank page to guess at.

None of this requires waiting for the final OAIC guidance. The decisions already exist in your operation today. The only question the deadline adds is whether you can see them.

Australian organisations have spent three years buying automation for the contact centre. Bots, virtual agents, self-service flows, AI triage. The spending has a logic, and the demand is real: 98% of organisations expect their self-service to grow, according to the 2026 Australian Contact Centre Best Practice Report. What almost nobody bought, or built, is the handover. And the handover is where customers actually decide what they think of you.

The same report found that only 13% of contact centres achieve a genuinely smooth transition from self-service to a live agent. Read that next to the 98% number and the picture is uncomfortable. Nearly everyone is expanding automation, and roughly one in eight has made the moment where automation gives way to a person work properly. The automation to human handover gap is not a rough edge on an otherwise sound strategy. For most organisations it is the strategy's blind spot.

The failure is the seam, not the bot

It is tempting to read a bad handover statistic as a bad bot statistic, and to fix it by buying a better bot. That is the wrong diagnosis. The failure point is not the automation. It is the seam between the automation and the person who has to finish the job.

A customer journey fails somewhere between a bot, an integration, and a knowledge article. No single team owns that seam, so nothing alarms when it breaks. What surfaces instead is a symptom in someone's dashboard: one agent's handle time creeping up, one team's quality score slipping, one leader's numbers trending the wrong way. The organisation responds to the symptom it can see. It coaches the agent.

This is the quiet cost of an unowned seam. The report gives it a sharp edge: only 27% of contact centres have the baseline observability to see the technical and experiential conditions driving their outcomes. The other 73% are, in effect, coaching people on outcomes they were never able to see, let alone control. Add that only 21% of frontline agents are reported to be excited about AI, and the shape of the problem is clear. The tools are fine. The model decides who gets blamed.

Adding tools to a broken model scales the break

There is a reason more technology has not closed the gap. The report found that only 38% of organisations say their AI self-service is delivering as expected, and 66% have designed their self-service AI to handle only basic queries. So the automation is, by design, handing off everything that is not basic, and handing it off into a seam nobody owns.

Salesforce's 2026 State of Service research points the same way from the agent's side: 63% of Australian service teams using AI already spend more time supervising AI than handling simple requests, and 67% expect that to increase within six months. The work did not disappear. It moved to the seam and changed shape.

This is the trap of treating service as a technology problem. Adding tools to a broken operating model does not fix the model. It scales the break, faster, and pushes the visible cost onto the agent and the customer at the exact point the model hands over.

Customers experience your operating model, not your org chart

Here is the reframe that changes the conversation. Customers never see your org chart. They experience your operating model, one handover at a time.

Every routing rule, every deflection, every escalation path is a decision your operating model made long before a customer reached the queue. When the handover fails, the customer is not experiencing a training gap in one agent. They are experiencing the org chart reaching them: the fact that the bot team, the integration team, the knowledge team, and the frontline each own a piece of the journey and nobody owns the join.

This is why service is best understood as an enterprise capability, not a departmental one. A smooth handover cannot be bought as a feature or coached into an individual. It has to be designed across the functions that each hold part of it. Most service problems are enterprise design faults made visible at the counter, and the handover is the clearest example there is.

What good looks like

Fixing the handover is not a procurement exercise. It is an operating-model exercise, and it tends to run in a particular order.

First, make the seam visible. The 27% observability figure is the real starting line: you cannot design a handover you cannot see. Second, give the seam an owner. A join that spans four teams needs someone accountable for the whole, not four teams each accountable for their end. Third, judge automation by what it hands over, not only by what it deflects. A bot that contains 40% of contacts but corrupts the 60% it passes on is not a saving. Fourth, stop reading agent metrics as agent problems until you have ruled out the model. The handle time is often the seam talking.

None of this is anti-automation. Self-service is growing and should. The point is that the return on all that automation is captured or lost at the handover, and the handover is an enterprise design decision, not a vendor setting.