Using AI with personal information? What changes on 10 December 2026

This is a practical overview for product teams, not legal advice. Your obligations depend on your organisation and your data, so check the detail with your privacy adviser.

If your product uses AI with personal information, a date is coming up that is worth planning for. From 10 December 2026, organisations covered by the Privacy Act must explain certain automated decisions in their privacy policies. The change came in through the Privacy and Other Legislation Amendment Act 2024, which added APPs 1.7 to 1.9.

It is a transparency obligation, not a ban. But preparing for it forces useful questions about where AI sits in your product, and the design decisions that make disclosure simple are the same ones that make the product safer.

What the new obligation covers

The obligation applies where all of these are true:

• You have arranged for a computer program to make a decision about an individual, or to do something substantially and directly related to making one.
• The decision could reasonably be expected to significantly affect that person's rights or interests.
• Personal information is used in the process.

Where it applies, your privacy policy needs to describe the kinds of personal information used and the kinds of decisions made. You are not expected to publish commercially confidential detail about how your system works.

The OAIC consulted on guidance through May and June 2026 and said it intended to publish that guidance ahead of the start date. Check the OAIC website for the current version before you finalise anything.

Why "a human decides" may not be enough

Many teams will assume they are outside the rule because a person makes the final call. Be careful with that. The obligation covers programs that do something substantially and directly related to a decision, not only programs that make it. Several law firms reading the OAIC's issues paper have noted it points to a broad interpretation, where AI that materially shapes what a decision maker sees may still bring the workflow in scope.

Context matters too. The OAIC has indicated that whether an effect is significant can depend on who is affected, and a decision affecting a child or a vulnerable person may be significant where the same decision for someone else would not be. If you build for health, disability, education or community services, assume closer scrutiny.

The obligations that already apply

The December change sits on top of principles that already apply whenever personal information passes through an AI feature:

• Use and disclosure (APP 6). Personal information collected for one purpose generally can't be used for another without consent or another exception. Sending it to a model to power a new feature is a use.
• Cross-border disclosure (APP 8). If your model provider processes data outside Australia, that is likely an overseas disclosure you need to account for.
• Quality (APP 10). Information used to make decisions has to be accurate, up to date and complete.
• Security (APP 11). You need reasonable steps to protect it, including at the model provider.

The OAIC's guidance on commercially available AI products also recommends, as best practice, that organisations don't enter personal information, and particularly sensitive information, into publicly available generative AI tools.

On coverage: many small businesses with annual turnover under $3 million are exempt from the Privacy Act, but not all. Health service providers are covered regardless of size, and so are some other organisations. Don't assume the exemption applies without checking.

Design decisions that reduce your exposure

The cheapest compliance work is done in the architecture, before launch. These are the decisions we made on Nooma, the AI practice companion we designed and built with O-HR, where the data is workplace investigation records about real people:

• Model terms that rule out training on your data. Nooma's model access runs under an agreement that prohibits training on customer data and deletes inputs within thirty days.
• Australian hosting. The application and its data stores run in an Australian region. Whether to route model traffic through an Australian-hosted gateway was named as a separate decision with its own cost, not assumed.
• Personal information as optional. Identifier fields can hold employee numbers instead of names, so personal information need never enter the AI processing layer.
• Bounded retrieval. The AI answers from a governed set of sources, with no open web.
• Decisions recorded as they happen. Every decision is timestamped against the person who made it, in a record that can't be edited afterwards, with a defined retention period.
• Every subprocessor disclosed. Each service that touches the data is listed and reviewed.

Not every product needs all of these. But each one is far cheaper to decide before the build than to retrofit after a customer, a board or a regulator asks.

A checklist before 10 December

1. Inventory. List every place your product sends personal information to an AI model or uses AI output about a person.
2. Classify. For each, ask whether the output feeds a decision that could significantly affect someone. Include decisions a person makes with AI-prepared inputs.
3. Map the data flow. Where does the data go, which provider processes it, in which country, and what their terms say about retention and training.
4. Update the privacy policy. Describe the kinds of personal information and the kinds of decisions in plain language.
5. Design the decision points. Where a person is accountable, make the gate real and record the decision. We wrote about how to draw that line.
6. Set up change control. A new model, a new provider or a repurposed feature should trigger a fresh look at all of the above.

If you want an independent view of where AI touches personal information in your product, Strategy & Audit covers it as part of a fixed-scope review. Or see how we build AI into products that handle sensitive data.