Australia Privacy LLM Requirements: Inputs, Outputs and Evidence

Australia has no separate privacy rulebook that replaces the Australian Privacy Principles when an organisation deploys an LLM. The existing duties follow the personal information through prompt assembly and provider processing. They continue through generated output and logs, then into retrieval stores and later correction or deletion. The hard part is identifying which act occurs at each boundary.

I would make every deployment team label whether one request is collection or use. The team should then determine whether it is disclosure before approving the route. That small exercise exposes vague privacy language quickly.

TL;DR

• The Privacy Act and Australian Privacy Principles apply whenever an LLM deployment handles personal information.
• Deployers need a defined purpose and lawful, necessary collection. They also need notice and an APP 6 basis for use or disclosure, plus an APP 8 analysis for overseas recipients.
• AI-generated personal information attracts collection and quality duties. Access and correction paths are required, along with security and deletion handling.
• Runtime evidence should connect identity with data classification. It should also record the destination and policy, then preserve the decision and retained records for each model route.

Scope follows personal information through the system

The OAIC's commercial AI product guidance says the Privacy Act applies to AI uses involving personal information during training and testing as well as operational use. Personal information includes information or an opinion about an identified or reasonably identifiable person. Truth is irrelevant to that definition, so an inaccurate model output about a person can still qualify.

Map the full LLM system. Include direct user prompts and retrieved documents; system-added context and provider requests; model responses and prompt logs; evaluations and embeddings; feedback and fine-tuning datasets. Mark who controls each copy and where another party gains access.

The operational distinction between use and disclosure matters. The OAIC says processing may remain a use where information stays within the organisation's effective control. Making it accessible outside that control may constitute disclosure. The contract and architecture inform that assessment, as do the route and provider access.

APP 1 requires governance tied to the deployment

The Privacy Act 1988 gives APP 1 its legal foundation. APP 1 requires reasonable steps to implement practices and procedures, along with systems that support APP compliance and privacy inquiries or complaints. For an LLM deployment, that means an approved use-case register and accountable owners; product due diligence and a privacy impact assessment where appropriate; operating rules and staff guidance; testing and a review process.

The OAIC recommends privacy by design and a proportionate, risk-based selection process. The organisation should understand the product's training data and limitations. It should assess security controls and data flows, then review third-party access and the operating environment before deployment. A customer-facing decision system requires more scrutiny than a controlled drafting tool with synthetic data.

The Australia privacy AI risk assessment covers the assessment workflow. Governance approval should name the exact LLM use and model routes. It should also list allowed data classes and prohibited actions, then name the evidence owner and review triggers.

APP 3 and APP 5 govern collection and notice

APP 3 requires solicited personal information to be reasonably necessary for the entity's functions or activities and collected by lawful and fair means. Sensitive information generally receives a higher threshold, including consent unless an exception applies. When an LLM generates or infers personal information, the OAIC treats that event as collection and applies APP 3 to the generated information.

Ask what the system creates about a person. A support summary may infer sentiment. A fraud workflow may generate a risk opinion. A meeting assistant may capture health or union information that the stated purpose never needed. Those outputs need the same disciplined inventory as prompt inputs.

APP 5 requires reasonable steps to notify individuals of relevant collection matters. The notice should describe the actual handling instead of hiding LLM processing inside broad wording. Record the notice version presented at collection and connect it to the approved use case.

APP 6 controls prompt use and provider disclosure

APP 6 generally limits use or disclosure to the primary purpose of collection, unless an exception permits a secondary purpose. The OAIC advises organisations to construe purposes narrowly in ambiguous cases. A secondary use may rely on consent or reasonable expectations where the statutory conditions are met, with a stricter relationship test for sensitive information.

For every model route, record the original collection purpose and the proposed LLM purpose. Separately identify the APP 6 basis and the recipient. Minimise the personal information included in the prompt. The OAIC recommends avoiding personal information, particularly sensitive information, in publicly available AI chatbots as a matter of best practice.

A policy should enforce the approved conclusion. If health information may use an internal route but cannot reach a public chatbot, the destination and classification belong in the request decision. AI data classification explains the classifications that make that rule executable.

APP 8 follows overseas model processing

APP 8 governs cross-border disclosure of personal information. A cloud LLM route may involve a provider or subprocessor outside Australia even when the user and application are in Australia. Data residency for stored application data may differ from the location used for transient inference or support. It may also differ from the location used for logging or abuse monitoring.

Document each recipient country or region and the provider role. Add each subprocessor and retention term. Record the contractual control too. Privacy should determine how APP 8 applies to the arrangement and retain that analysis beside the vendor record. Routing changes deserve review because dynamic model selection can alter the recipient behind a stable product interface.

The AI vendor risk assessment supplies the procurement questions. The LLM requirement is narrower: the production route must stay inside the destinations and terms that privacy approved.

APP 10 applies to generated personal information

APP 10 requires reasonable steps to ensure personal information collected is accurate and up to date, as well as complete. Information used or disclosed must also be relevant for its purpose. The OAIC highlights the probabilistic nature of generative AI and training-data limitations. It also identifies bias and hallucination, along with deterioration, as accuracy risks.

Define the allowed role of an output. A draft that a trained employee checks creates a different consequence from an output copied into an eligibility decision. Higher-impact uses need stronger source verification and testing. They also need human review and correction, with restrictions on downstream action.

Preserve source references and the model version for sampled outputs. Maintain a route for individuals to challenge inaccurate personal information. Trace a correction into logs and retrieval stores, plus downstream systems where the information remains held. A disclaimer cannot repair a workflow that treats generated personal information as verified fact.

APP 11 requires security and deletion controls

APP 11 requires reasonable steps to protect personal information from misuse or interference, as well as loss. It must also be protected from unauthorised access and modification or disclosure. APP 11 includes destruction or de-identification duties when the entity no longer needs the information, subject to legal retention requirements. LLM deployments extend that analysis into prompts and responses. It also covers evaluation datasets and vector stores, plus provider records.

Security controls should cover identity and least privilege. They should restrict approved destinations and classify prompts and responses. Connector scope and secrets need controls, along with monitoring and incident response. Test a prohibited request and preserve the refusal. Test deletion for a seeded person across each retained store. Confirm that the provider terms and technical settings match the approved retention position.

The Australia Privacy Act audit evidence guide lists recurring artifacts. The requirement here is direct: every retained copy needs an owner and purpose. It also needs an access rule and retention rule, plus a tested disposal path.

DeepInspect

DeepInspect can enforce request-level rules on deliberately routed HTTP traffic between authenticated users or agents and LLM endpoints. It evaluates application-supplied identity and role, then checks content classification and model destination against organizational policy before forwarding a prompt or returning a response.

The resulting per-decision record can show which policy allowed or blocked a specific route. Collection purpose and notice remain organizational responsibilities outside that HTTP decision boundary. The same applies to consent and provider contracting, as well as cross-border legal analysis. The organization also remains responsible for output accuracy and correction, plus retention and deletion.

Book a technical deep dive at deepinspect.ai.