Privacy Act, AI, and your customer data — what AU SMEs need to know

Most AU SMEs hesitate on AI not because they doubt the capability. They hesitate because they are not sure what they are allowed to do with customer data.

That caution is reasonable. Sending customer data to a US-based AI provider is not the same as storing it in your own systems. The Privacy Act 1988 has things to say about third-party disclosures of personal information. The rules are workable, but they require deliberate choices most teams are not making by default.

Here is the practical version — not legal advice, but the common patterns we see firms navigate.

Three things you actually need to know

1. Where the data goes

When you send a prompt containing customer data to an AI provider, that data is processed on their infrastructure. Both Anthropic (Claude) and OpenAI publish data processing agreements (DPAs) and disclose which regions they process in. Both allow you to opt out of training on your inputs — Anthropic does this by default for API use, OpenAI offers it via the API but not the consumer ChatGPT product.

That distinction matters. If your team is pasting customer data into a free ChatGPT browser tab, the API terms do not apply.

2. What "processing" counts as

Under the Privacy Act, sending customer data to a third party for processing is a disclosure. If your Privacy Policy does not mention that you use AI tools to process personal information, it probably needs updating.

This is not a large change. It is a sentence or two in your privacy policy describing the categories of tools you use and what data they may process. The OAIC has published guidance on AI and privacy that covers what a reasonable disclosure looks like.

The firms that get into trouble are not the ones who updated their privacy policies. They are the ones who deployed AI workflows for six months without thinking about it, then had a client ask.

3. The Notifiable Data Breaches scheme

Australia's Notifiable Data Breaches (NDB) scheme requires eligible organisations to notify the OAIC and affected individuals when a breach is likely to result in serious harm.

If a breach occurs at an AI vendor — not in your own systems, but at the provider you send data to — you may still have a reporting obligation. The fact that the breach happened upstream does not eliminate your obligation to assess whether notification is required. Major AI providers have disclosed incidents. Understanding your response process before something happens is easier than working it out in the middle of one.

Five questions to ask any AI vendor

1. Where do you process data geographically?

If your vendor cannot answer this specifically, that is a red flag.

2. Do you train on my inputs?

Get this in writing, not just from a sales call. Look for the DPA, not the marketing page.

3. How long do you retain prompts and outputs?

Retention periods vary significantly. Some providers retain inputs for 30 days for safety review. Some retain nothing.

4. Have you signed a DPA?

For any AI tool processing personal information at volume, a DPA is not optional.

5. What happens if you have a breach?

Does the vendor have an obligation to notify you? In what timeframe? This affects your own NDB obligations. If the vendor's answer is vague, the relationship is not ready for production use with customer data.

Three patterns we use

Anonymise before sending

For most workflows, the AI does not need to know who the customer is. Strip names, account numbers, and personal identifiers before the prompt reaches the AI. Reconstruct on the way back — your system maps the anonymised token back to the real record. The AI sees data shape, not identity.

This works cleanly for invoice extraction, query classification, and document drafting. It handles most cases.

Self-host where the data is sensitive

For legal, medical, or financial contexts where anonymisation is not practical, a self-hosted model avoids the third-party disclosure entirely. Self-hosted open-source models — Llama and similar — run on infrastructure you control. The trade-off is capability: self-hosted models are generally less capable than frontier API providers. A Sydney law firm handling sensitive family law matters is a different calculation from a mid-sized retailer drafting product descriptions.

Explicit consent at the point of collection

When a workflow requires sending personal data to an AI provider and anonymisation is not viable, make the consent explicit at the point of collection. A plain-English line in your intake form or client agreement — noting that certain data may be processed by AI tools and identifying the category of provider — satisfies the disclosure requirement. One sentence in plain language works.

A worked example

A Sydney financial planning firm wanted to use AI to assist with Statement of Advice (SOA) drafting. SOAs contain detailed personal financial information — sending them to an AI API required addressing the privacy obligations first.

Two changes unblocked the project. They updated their privacy policy to include a short disclosure about AI-assisted document preparation. And they added a consent line to their client engagement letter: "We use AI tools to assist in preparing advice documents. Your information may be processed by third-party AI providers operating under data processing agreements."

Neither change required legal counsel. Their principal had both done in an afternoon. The integration went ahead.

A note on the OAIC's guidance

The OAIC published guidance on privacy and AI in 2024. It is publicly available and worth reading if you are deploying AI at any meaningful scale. It does not resolve every question — the regulatory environment is still developing — but it establishes a reasonable baseline for what the regulator expects.

---

If you have a workflow you want to scope, we run 30-minute scoping calls. They are free. We will not pitch you. [Book one →](/p/scoping)