Australia’s December 2026 automated-decision privacy changes: what website, CRM and AI teams should review

An organisation can update the wording on its privacy page in an afternoon. It cannot accurately explain automated decision-making if nobody can say which systems make which decisions, what personal information they use, how people are affected or who is accountable when the process changes.

That distinction matters because Australia’s automated-decision transparency obligation starts on 10 December 2026. The Office of the Australian Information Commissioner says that APP entities using personal information in automated decision-making with the potential to affect rights or interests will have to include information in their privacy policies about the kinds of personal information used and the kinds of decisions made. The more precise statutory threshold concerns decisions that could reasonably be expected to significantly affect an individual’s rights or interests. The OAIC’s current APP 1 guidance and its 2026 consultation page should be treated as the primary public references while final regulatory guidance is developed.

This is not merely an artificial-intelligence disclosure exercise. A rules engine, score, ranking model, workflow, fraud flag, recommendation service or CRM automation may be relevant even when the organisation does not describe it as AI. Conversely, the presence of AI does not automatically mean that every use falls within this particular disclosure obligation.

The practical task is to connect legal interpretation with the real digital estate. Privacy, legal, risk, product, data, CRM, customer service, marketing and website teams need a shared map. This article provides a readiness framework, not legal advice. Organisations should obtain advice on whether the Privacy Act applies to them and whether particular arrangements satisfy the statutory threshold.

The short answer

Before 10 December 2026, an organisation should be able to answer six questions:

1. Is it an APP entity for the relevant activity?
2. Has it arranged for a computer program to use personal information?
3. What decision does the program make, or what does it do that is substantially and directly related to making that decision?
4. Could the decision reasonably be expected to significantly affect a person’s rights or interests?
5. Which kinds of personal information and decisions must be described in the APP Privacy Policy?
6. Do collection notices, interfaces, human-review processes and internal controls match the public explanation?

Do not begin by asking a copywriter to add a generic paragraph about AI. Begin by finding the decision arrangements and confirming how they work.

What changes on 10 December 2026?

The amendments add APP 1.7, APP 1.8 and APP 1.9 to the privacy-policy framework. The OAIC explains that the additional requirements apply where an APP entity has arranged for a computer program to use personal information to make a decision that could reasonably be expected to significantly affect an individual’s rights or interests. The changes were introduced through Part 15 of the Privacy and Other Legislation Amendment Act 2024, with the consolidated Privacy Act 1988 remaining the authoritative legislation source.

The policy will need to describe:

• The kinds of personal information used in the operation of such computer programs.
• The kinds of decisions made solely by those programs.
• The kinds of decisions for which a thing done by the program is substantially and directly related to making the decision.

That last category is important. A human clicking “approve” at the end of a workflow may not, by itself, place the arrangement outside the disclosure requirement. If a system’s output is substantially and directly related to the decision, the arrangement may still need to be considered. The correct conclusion depends on the actual process and should be confirmed by the organisation’s advisers.

Examples that deserve screening may include eligibility, access, pricing or terms, application triage, recruitment screening, claims, fraud review, account restrictions, service priority and other decisions with meaningful consequences. These are examples for investigation, not a declaration that every instance is captured.

This is a systems problem before it is a website problem

A privacy policy is only the publication surface. The evidence lives elsewhere:

• The CRM may calculate a score or trigger a pathway.
• An application platform may apply rules before a person sees the record.
• A marketing automation platform may infer categories or rank prospects.
• A customer portal may change available actions according to status or risk.
• A third-party AI service may generate a recommendation used by staff.
• A data warehouse may combine information from several business units.
• A vendor may change the model or feature without the website team knowing.

If the website team receives only the instruction “update the privacy policy”, it will probably publish language that is too broad, too narrow or already out of date. The policy owner needs an operating process that detects changes across the full stack.

The OAIC’s broader APP 1 guidance says privacy policies should be clearly expressed, up to date, easy to navigate and tailored to the entity’s actual information-handling practices. It also distinguishes the organisation-wide privacy policy from the more specific notice provided when information is collected. That distinction should shape the implementation.

Build a decision-system register before rewriting the policy

A decision-system register is a practical bridge between legal analysis and implementation. It does not have to be a new enterprise platform. A controlled register can work if it has clear ownership, review dates and change triggers.

For each candidate arrangement, record the following.

1. The business decision

Describe the outcome in plain language. “Uses machine learning” is not a decision. “Prioritises applications for manual review”, “sets an account limit” or “determines whether a customer can access a service” is closer to the information a reviewer needs.

2. The people and consequences

Identify who is affected and how. Separate inconvenience from significant impact. Record whether the result changes eligibility, access, terms, price, priority, employment, finance, insurance, health, education or another material interest. Do not decide the legal threshold through a workshop alone; flag it for the appropriate adviser.

3. The personal information

List categories rather than copying customer records. Include information collected directly, supplied by third parties, derived from behaviour and inferred or generated by the system. The OAIC’s guidance on commercially available AI products notes that privacy obligations can apply to personal information input into an AI system and to generated output where it is personal information.

4. The technical arrangement

Record the system, vendor, model or rules engine, relevant integration, environment and data flow. Identify whether the organisation configured the decision, purchased a product, enabled an optional feature or relies on a provider’s default. Record who can explain the configuration without exposing sensitive security details publicly.

5. The human role

Avoid binary labels such as “automated” and “human in the loop”. Document what the person actually sees, what discretion they have, whether they can obtain additional information, whether they routinely follow the output and how an override is recorded. A ceremonial human step is different from meaningful review.

6. Ownership and change

Nominate a business owner, technical owner, privacy reviewer and policy owner. Record the next review date and the events that force an earlier review, such as a new data source, changed scoring rule, new market, vendor release, altered customer outcome or removed human check.

Audit arrangements, not product names

Searching the software inventory for “AI” will miss relevant processes and create false positives. Use decision-centred interviews and evidence.

Ask business teams:

• Which customer or staff outcomes are calculated, ranked, recommended, restricted or routed?
• Which outputs do staff generally accept without further investigation?
• Which processes use scores, flags, segments, inferred attributes or predicted outcomes?
• Which vendors can change logic or models?
• Which decisions generate complaints, corrections or manual overrides?

Then trace each candidate arrangement through the systems. A CRM score may be created from website behaviour, enriched by a third party, sent into an automation platform and shown to a salesperson as a priority. No single system owner sees the entire chain. The register must.

This investigation is also an opportunity to remove abandoned rules, duplicated data and poorly owned integrations. It should not be disguised as a free pre-sales audit. If an organisation needs specialists to inspect its systems, data flows and decision logic, that work should be separately approved and appropriately governed.

Separate four kinds of automated activity

One register can include several categories, but the categories should not be treated as interchangeable.

Content and productivity assistance

Drafting text, summarising a document or helping a staff member search internal material may involve personal information and broader APP obligations. It does not automatically make a decision that meets the December 2026 threshold. It still needs appropriate privacy, security and accuracy controls.

Personalisation and recommendation

Selecting content, products or next actions can range from low-consequence convenience to a pathway that materially changes an offer, term or opportunity. Record the outcome and significance rather than assuming all personalisation is either harmless or captured.

Triage and decision support

Ranking, flagging and recommending can materially shape a human decision. Investigate what happens after the output is produced. If staff rarely depart from it, or if lower-ranked cases receive materially different treatment, the system’s role may be consequential.

Solely automated decisions

Where the computer program makes the decision without human involvement, record the rule, data, consequences, exception path and monitoring. Sole automation is an explicit category in the amendments, but it is not the only category to assess.

A privacy policy cannot carry the whole explanation

The privacy policy is an organisation-wide document. It should explain the required kinds of decisions and personal information clearly without becoming an unreadable technical inventory. The OAIC notes that a layered approach can help people understand an online policy, with key information linked to appropriate detail.

The wider experience may need three coordinated layers.

Layer 1: the APP Privacy Policy

This provides the required organisation-wide description and the established information about collection, use, disclosure, access, correction and complaints. It should have a visible last-updated date, stable location and owner.

Layer 2: contextual notices and journey content

Where personal information is collected, an appropriate notice can explain the immediate context: what is collected, why, the likely disclosures and where to find the policy. A collection notice is not interchangeable with the APP Privacy Policy. Avoid hiding a material explanation behind a checkbox or relying on consent language where consent is not the correct legal basis.

Layer 3: product and operating controls

People may need understandable status messages, ways to supply correct information, accessible support, escalation and review. Staff need procedures for complaints, overrides, errors and system changes. The public words will lose credibility if the operating model cannot support them.

Review accuracy, fairness and human oversight as separate questions

The new obligation is about transparency, but disclosure does not make the underlying decision appropriate. Existing privacy obligations still matter. The OAIC says APP 10 requires reasonable steps to ensure personal information collected is accurate, up to date and complete, and information used or disclosed is accurate, up to date, complete and relevant for the purpose. Its AI guidance recommends understanding how outputs are produced, assigning a human who can verify accuracy and overturn decisions where AI assists decision-making, and maintaining controls across the product lifecycle.

For each material arrangement, test:

• Input quality: Are sources current, authorised and fit for the decision?
• Output quality: What error, bias, drift and edge-case testing occurs?
• Human authority: Can a reviewer genuinely depart from the output?
• Correction: Can a person correct inaccurate personal information?
• Explanation: Can the organisation explain the decision process meaningfully without exposing security-sensitive detail or proprietary code?
• Monitoring: Are adverse outcomes, overrides and complaints reviewed?
• Change control: Does a material model or rule change trigger reassessment and policy review?

These controls require privacy and legal judgement as well as product, data and technical work.

Make the website implementation maintainable

Once the approved wording is ready, the website work should be controlled like any other regulated content change.

1. Publish the policy in accessible HTML, even if a PDF copy is also offered.
2. Keep the policy reachable from persistent navigation, commonly the footer.
3. Use descriptive headings and anchor links for long policies.
4. Record the effective date and retain an approved version history.
5. Link relevant collection journeys to the policy and the correct notice.
6. Test links, responsive layouts, keyboard access and screen-reader structure.
7. Confirm analytics do not collect sensitive form content.
8. Assign an owner and review trigger in the CMS governance process.

The website should not expose model thresholds, security controls, confidential vendor information or technical detail that would create a new risk. The goal is clear and truthful transparency, not publication of an attack guide.

A practical readiness sequence

Now: establish scope and ownership

Appoint an accountable privacy or legal owner, create a cross-functional working group and confirm which entities, brands and activities require review. Agree the evidence standard and decision-escalation process.

Next: discover and classify arrangements

Interview decision owners, map systems and vendors, build the register and screen each arrangement. Resolve uncertainty with qualified advisers. Do not wait for final website copy before finding the systems.

Then: remediate the operating model

Address missing ownership, unclear human review, weak change controls, inaccurate data, inaccessible escalation and inconsistent notices. Decide which arrangements need a PIA or other formal assessment. The OAIC describes a privacy impact assessment as a systematic assessment of a project’s privacy impact and recommendations to manage, minimise or eliminate that impact. Its PIA tool is a useful starting reference.

Before commencement: approve and publish

Obtain legal and privacy approval, implement policy and notice changes, test every affected journey, brief customer-facing staff and record the evidence. Schedule the first post-publication review rather than treating launch as completion.

Ongoing: monitor change

Connect procurement, product releases, CRM changes, new data sources and AI adoption to the register. A policy can be accurate on 10 December and wrong on 11 December if a major feature changes without governance.

Use a release gate for any change that affects decision purpose, data inputs, vendor, model, rules, human review or outcome. The gate should ask whether the register, privacy assessment, collection notice, public policy, support guidance and escalation path remain accurate. This is a modest addition to ordinary change control, but it prevents a static compliance document from drifting away from a live digital service.

Frequently asked questions

Does the obligation apply only to artificial intelligence?

No. The statutory framing concerns arrangements for a computer program to use personal information in specified decision-making. Rules engines, scoring systems and workflow automation may need assessment even if nobody calls them AI. Not every AI use will necessarily meet the threshold.

Does having a human approve the outcome remove the obligation?

Not automatically. The amendments also address decisions where something done by a computer program is substantially and directly related to making the decision. The real role of the system and human reviewer must be assessed.

Which organisations are covered?

The additional requirements sit within APP 1 and apply to APP entities. Coverage and exemptions can be fact-specific. Confirm the position for each relevant entity and activity with a qualified privacy or legal adviser.

Is changing the privacy policy enough?

No. The policy must accurately reflect the operating model. Organisations also need a system register, owners, change control, appropriate collection notices, reliable data, complaint and correction pathways, and governance that keeps the words current.

Should every automated decision be listed separately?

The amendments refer to kinds of decisions and kinds of personal information. The appropriate level of grouping should be confirmed against the final OAIC guidance and legal advice. Avoid wording so general that it tells people nothing or so technical that it becomes unmaintainable.

Do we need to reveal algorithms or security controls?

The obligation is not a reason to publish source code, model weights, thresholds or security-sensitive detail. The policy should meet the required transparency standard while protecting genuinely sensitive information. Obtain advice on the correct balance.

What if a third-party vendor operates the system?

Vendor operation does not remove the need to understand the arrangement. Record data flows, roles, configuration, change notifications, assurance evidence and contractual responsibilities. Confirm the organisation’s legal obligations rather than assuming the vendor owns compliance.

Is this article legal advice?

No. It is a digital readiness and implementation framework. The legislation, final OAIC guidance and the organisation’s circumstances should be assessed by qualified privacy and legal advisers.

How Emote can help

Emote can help organisations translate an approved privacy and governance position into a usable digital experience across websites, forms, portals, CRM-connected journeys and content-management workflows. That can include information architecture, accessible policy presentation, contextual notice placement, interface changes, integration requirements, implementation and testing within an approved scope.

For related planning, see Emote’s guide to website and system integration decisions.

If you need to turn an approved privacy position into practical website or portal changes, book a meeting with Emote.