AI and the Australian Privacy Act: a practical compliance guide

The Australian Privacy Act 1988 (Cth) and its Australian Privacy Principles (APPs) apply to AI systems exactly the same way they apply to every other system that handles personal information — which is to say, comprehensively. What’s changed is that AI workflows make a category of compliance questions harder to answer cleanly: where does the data actually go? what gets remembered? who counts as a third-party recipient? what does “use” mean for an LLM?

This guide is the practical mapping we use inside engagements. It assumes the reader is familiar with the APPs at a basic level (if you’re not, the OAIC’s APP Guidelines are the canonical reference). The focus is on the AI-specific patterns: which APPs are tripped most often, how to design around them, and what the OAIC has signalled it expects.

A note on scope: this guide covers the federal Privacy Act and APPs. State and territory health-records legislation (e.g. HRIPA in NSW, HRPCPA in Victoria) and sector-specific obligations (APRA, AHPRA, etc.) add layers; we cover those in other cornerstones by sector.

Which APPs AI workflows trip most often

Of the 13 APPs, five come up in almost every AI engagement we run. The others matter but are usually handled inside existing organisational privacy frameworks; the five below need specific AI-aware treatment.

APP 1 — Open and transparent management of personal information

APP 1 requires entities to manage personal information in an open and transparent way, including by having a clearly expressed and up-to-date privacy policy.

The AI-specific trip: most existing privacy policies don’t mention AI at all, or mention it only in vague terms (“we may use automated systems”). The OAIC has signalled — through guidance documents and informal commentary — that this is increasingly insufficient. Privacy policies should describe where AI is used, what data flows through it, whether AI outputs influence decisions about the individual, and what rights the individual has in relation to the AI use.

Practical guidance: update the privacy policy with an AI section that covers (a) which categories of personal information are processed by AI systems, (b) what AI is used for (e.g. customer service, fraud detection, recommendation systems), (c) what data leaves Australian shores via AI APIs, (d) whether the AI makes or materially influences decisions about the individual, (e) how the individual can request review of AI-influenced decisions.

APP 6 — Use or disclosure of personal information

APP 6 governs when personal information collected for one purpose can be used or disclosed for another. The general rule: only for the primary purpose of collection, or with consent, or where a specific exception applies.

The AI-specific trip: training, fine-tuning, or evaluation of AI models using customer data is often a “secondary purpose” that wasn’t covered by the original collection notice. Even running production inference (e.g. “feed this customer email into our LLM-powered triage system”) can be a secondary purpose if the original collection notice didn’t anticipate AI-driven processing.

Practical guidance: review the collection notices (where consent was the basis of collection) and the implied-purpose chain (where collection was permitted under another basis). For each AI use case, confirm that the AI processing falls within the original purpose; if it doesn’t, the path is usually either (a) update the notice prospectively and rely on it for new collections, (b) obtain refreshed consent for legacy data, or (c) find a different APP basis for the secondary use. Don’t default to “we’ll just rely on a general clause about ‘business operations’” — the OAIC has been increasingly skeptical of that pattern.

APP 8 — Cross-border disclosure of personal information

APP 8 requires reasonable steps to ensure overseas recipients of personal information don’t breach the APPs in relation to that information. There are accountability obligations on the AU entity that initiates the cross-border disclosure.

The AI-specific trip: this is the most consequential APP for AI architecture decisions. Most foundation model providers (Anthropic, OpenAI, Google, Microsoft for Azure OpenAI, AWS for Bedrock) are based outside Australia. Sending personal information to their APIs is a cross-border disclosure that triggers APP 8.

Practical guidance: three implementation patterns.

1. AU-region inference: Anthropic Claude is available in AWS Bedrock’s Sydney region. Azure OpenAI offers Australian regions. Google Cloud has AU regions for Gemini. Choosing AU-region deployment substantially simplifies the APP 8 analysis — data doesn’t cross borders, so APP 8’s cross-border-disclosure obligations don’t engage.

2. De-identification before transmission: if AU-region isn’t available for the chosen model, removing identifiers before the data reaches the LLM avoids the cross-border-disclosure issue. Pattern: PII redaction at the application layer; the LLM sees pseudonymised tokens; the application maps the response back to the identified individual.

3. APP 8 compliance with cross-border disclosure: where the personal information does need to cross borders, the path is to take reasonable steps to ensure APP compliance overseas — typically contractual provisions with the provider, plus assessment of the provider’s privacy practices. Major providers (Anthropic, OpenAI, Google, Microsoft, AWS) all offer Data Processing Addenda that can support APP 8 compliance; the assessment work to confirm fitness is still required.

The pattern we recommend by default: AU-region inference where available, de-identification where not. The compliance overhead of full APP 8 cross-border disclosure compliance is real and increasingly avoidable as AU-region foundation model availability matures.

APP 11 — Security of personal information

APP 11 requires entities to take reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure.

The AI-specific trip: AI systems introduce attack surfaces that don’t exist in traditional applications. Prompt injection can cause models to disclose data they shouldn’t. Model memorisation can persist training data in ways that allow extraction. RAG systems can retrieve information the requesting user shouldn’t see if access controls don’t propagate.

Practical guidance: AI security controls are a real category of work, not a checkbox.

• Prompt injection defences: input sanitisation, output validation, separation of trusted vs untrusted content in prompts. The defensive patterns are still maturing; the OWASP Top 10 for LLM Applications is the canonical reference.
• Access control at retrieval: RAG systems must respect the requesting user’s access permissions when retrieving context. The naive RAG pattern — embed everything, retrieve for everyone — leaks data across access boundaries.
• Data minimisation in prompts: only send the LLM the personal information needed for the specific task. “Send the whole customer record because the model might need it” is rarely the right pattern.
• Audit logging: every inference traced with sufficient detail for incident reconstruction. Critical for APP 11 compliance and for the broader incident-response process.

APP 12 — Access to personal information

APP 12 gives individuals the right to access their personal information held by an entity. The right is broad and the exceptions are narrow.

The AI-specific trip: what counts as “personal information” inside an LLM-powered system can be unexpectedly broad. Conversation logs with an AI assistant. RAG retrievals that included the individual’s data. Embedding vectors derived from the individual’s personal information. The audit trail of AI inferences that involved the individual.

Practical guidance: design AI systems with access-request response in mind from day one. The questions to be able to answer:

• What AI processing has been performed on this individual’s personal information?
• What records were generated by that processing?
• What outputs (recommendations, decisions, classifications) about this individual did the AI produce?
• Where are those records stored, and how can they be retrieved?

In practice, this usually means structuring audit logs so they’re searchable by subject ID, and being able to render the relevant records in human-readable form for an access request response.

What “use” of personal information actually means in an LLM context

The APPs were drafted before LLMs existed, so applying them requires some interpretation. Two areas where interpretation matters most:

Sending personal information to an LLM in a prompt

This is unambiguously a use of personal information for APP purposes. The LLM provider is processing the personal information (even if statelessly), the AU entity is causing that processing, and the use must fit within the APP framework.

If the LLM provider is overseas, this is also a cross-border disclosure (APP 8). If the purpose is different from the original collection purpose, APP 6 applies. If the prompt includes more personal information than needed for the task, APP 3 (collection) and APP 11 (security) considerations apply.

Training or fine-tuning a model on personal information

This is also a use, and it’s the use case where the OAIC has been most active in commentary. Fine-tuning a model on customer data creates a model whose weights have learned patterns from that data. There are legitimate technical questions about whether the data can be considered “retained” in the model in the APP sense; the OAIC’s emerging position seems to be that the precautionary answer — treat it as retention — is the prudent one.

For most enterprise use cases, fine-tuning on personal information is avoidable. RAG patterns (retrieve at query time, don’t embed in weights) provide most of the same capability without the model-training implications. Where fine-tuning is the right architecture, the data preparation step should include de-identification where possible and explicit lawful basis analysis where not.

Consent — when it’s the right basis and when it isn’t

Consent is sometimes the right basis for AI processing of personal information, and often isn’t. The conditions for valid consent are well-established (informed, specific, current, voluntary), but the OAIC has signalled increasing skepticism of broad blanket consents that purport to cover unspecified future AI processing.

The pattern we typically recommend:

• For AI use cases that are clearly within the original purpose of collection (a customer service AI processing customer service queries), rely on the original collection notice + a privacy policy update rather than seeking refreshed consent.
• For AI use cases that are clearly outside the original purpose (training a model on customer data for unrelated future products), seek specific consent for that processing.
• For ambiguous cases, conduct a Privacy Impact Assessment to make the analysis explicit and defensible. The PIA is the artefact the OAIC would want to see if the matter ever became contentious.

What the OAIC has signalled (but not yet formalised)

The OAIC has been increasingly vocal about AI through 2024–2026 via guidance documents, speeches, and informal commentary. None of this is formal regulation, but the directional signals are worth knowing about.

• Generative AI guidance for organisations (2024 onwards): emphasis on transparency to individuals about AI use, including in privacy policies, and clear accountability for AI outputs that affect individuals.
• Concern about LLM training data: the OAIC has flagged that personal information used to train models — particularly where consent wasn’t obtained — is an active area of analysis. Entities training models on customer data should expect future scrutiny.
• Privacy Impact Assessments expected for material AI deployments: not a formal requirement, but the OAIC has consistently named PIAs as the expected practice for AI projects that materially affect individuals.

The Privacy Act itself is also under active review — the Australian government’s Privacy Act reforms (announced 2023, with progressive implementation through 2024–2026) include several AI-relevant changes, including a likely right to meaningful information about automated decision-making. The shape and timing of the final reforms is still uncertain; designing AI systems with explainability and contestability in mind now is the prudent posture.

The practical compliance checklist

For any new AI use case involving personal information, the questions we walk clients through during the AI Governance Review:

1. What personal information will the AI process? Categories, sensitivity, volume.
2. What was the original collection purpose, and does the AI use fit within it?
3. Will the data cross borders (APP 8)? If yes, what’s the mitigation — AU-region, de-identification, or APP 8 compliance with cross-border disclosure?
4. What APP 11 security controls are in place? Prompt injection defences, access control, data minimisation, audit logging.
5. How will APP 12 access requests be handled? Can we retrieve and render the AI processing records?
6. Does the privacy policy adequately describe the AI use?
7. Is the AI making or influencing decisions about individuals? If yes, what’s the explanation + contestability mechanism?
8. Is a Privacy Impact Assessment warranted? For material AI deployments, the answer is almost always yes.

Walking through the checklist takes 1–2 hours per use case. The output is either “compliant” or a list of specific items to address before deployment — much cheaper than discovering issues at audit or after an incident.

Next step

If you’re working through AI compliance posture and want a structured walk-through aligned to both the Privacy Act and the Voluntary AI Safety Standard, the AI Governance Review is the 4-week engagement designed for exactly this work.

For a faster conversation about your specific situation, the discovery call is 30 minutes, no agenda. We’ll walk through where you are and what the highest-leverage compliance work looks like for your AI footprint.

This guide is general information, not legal advice. For privacy-sensitive AI work, getting your General Counsel or external privacy lawyer involved early is part of the discipline — they should be in the design workshop alongside the engineers.