Privacy-by-Design RAG for Australian Privacy Act 2025 Reforms (2026)

Q: What is the statutory tort for serious invasions of privacy and how does it affect RAG pipelines?

Schedule 2 of the Privacy and Other Legislation Amendment Act 2024 inserted Part IIIE into the Privacy Act 1988, creating a direct cause of action — commenced 10 June 2025 — for an individual whose privacy has been seriously invaded. The tort has two limbs: intrusion upon seclusion, and misuse of information. For the RAG pipeline, the misuse-of-information limb is the architectural hot spot. A system that surfaces an individual's personal information to a user with no lawful basis to receive it can ground a tort claim with no requirement that the OAIC be involved, no requirement that the individual prove financial loss (damages for emotional distress are explicitly available), and no requirement that the operator be a Privacy Act entity (the tort applies to non-APP-entities too). Damages are capped at the same level as defamation non-economic loss (currently A$478,550 and indexed annually). The defences (consent, lawful authority, public interest, necessary for protecting safety, fair-comment-equivalents) require the operator to demonstrate them on evidence at trial; an architecture without provenance at retrieval time cannot demonstrate them. The architectural response is per-query provenance into an admissible-evidence-quality audit log, scoped retrieval that prevents accidental disclosure, and the policy decision point that records lawful basis for every PII disclosure.

Q: How has APP 11 changed and what does it require of a RAG pipeline?

The first tranche of reforms strengthened APP 11(1) — entities must take "such steps as are reasonable in the circumstances" to protect personal information. The OAIC guidance and the Explanatory Memorandum make it clear that "reasonable steps" now includes technical and organisational measures appropriate to the risk profile of the data and the system, with explicit references to AI systems and large-scale automated processing. For high-risk RAG (large volumes of personal information, sensitive information categories under section 6 — health, biometric, genetic, government identifier, sexual orientation, political opinion, racial origin, etc., or AI systems that influence decisions about individuals), the bar for "reasonable" is technical, specific, and auditable. Practically: a RAG pipeline that ingests PII into an embedding store with no per-subject keying, no scoping at retrieval, and no deletion guarantee is unlikely to survive an OAIC inquiry under reformed APP 11. The architectural answer is the PII boundary (classifier + vault + placeholders) before the embedding store, storage-layer scoping at retrieval, and a deletion fan-out that produces a certificate. The reform raises the floor; the architecture above is what the new floor looks like.

Q: Why must the PII boundary be drawn before the embedding store rather than after?

Because PII embedded into a vector store is retrievable forever via similar-chunk search even after the source document is deleted, and that retrievability creates two intractable problems. First, deletion of the source PII does not propagate to retrievability — the embeddings still encode the semantic content of the deleted PII and similar-chunk search will surface them, which means an APP 11(2) deletion request cannot be honoured completely without rebuilding the index, which is operationally infeasible at scale and exposes the system to ongoing OAIC inquiry. Second, an embedding-store leak (security incident, misconfigured access control, departed-employee data exfiltration) leaks PII even though the source documents are protected, because the embeddings encode it. Drawing the boundary before the embedding store inverts both problems: the embedding store is subject-free (the embedded text contains placeholders that point back to the vault), so a leak does not leak PII and a deletion in the vault propagates to the system's ability to retrieve the PII automatically. The cost is one classification pass at ingest and one resolution pass at response generation; the benefit is a deletion model that survives audit and a leak model that contains the blast radius.

Q: How does retrieval allow-listing prevent cross-subject leakage at the storage layer rather than the application layer?

Storage-layer scoping means the index query itself includes the subject-and-tenant filter, and the storage adapter refuses queries where the filter is missing or where the asking user has no documented relationship to the subjects in scope. The retriever signature requires (asking_user, tenant, subjects_in_scope) as mandatory arguments; subjects_in_scope defaults to empty rather than unbounded; admin queries that need to operate without a scope go through a separate broken-glass interface with its own logging. The contrast with application-layer scoping — where the index returns chunks across subjects and the application code filters before responding — is operationally significant. Application-layer scoping fails open: a missing filter, a logic bug in the filter, an exception in the filter path, all produce cross-subject leakage; the leak is invisible to the retriever and only catchable by code review or post-hoc audit. Storage-layer scoping fails closed: the storage refuses the query, the application sees an error rather than wrong data, the leak becomes a build failure rather than a runtime incident. Under the reformed Act and the statutory tort, the difference between fail-open and fail-closed is the difference between a defended architecture and an undefended one — and "defence in depth" expectations now include the storage-layer enforcement explicitly.

Q: What does proof-of-deletion look like architecturally and why does it matter?

Proof-of-deletion is a delete-subject API call that fans out across all stores transactionally — vault, embeddings, cache, LLM-call log, analytics warehouse, per-subject index — and emits a deletion certificate at completion: subject identifier (hashed), timestamp, list of stores affected, count of records removed per store, request originator, lawful basis for the request. The certificate is retained in the audit log as the evidence the deletion happened; it is also surfaced to the requesting individual as the response to their subject access or correction request. Backups are addressed either by time-bounding (backups older than the retention window are deleted on schedule, so deletion against the live system reaches all backups within the window automatically) or by per-subject deletion-replay against backups (each backup gets a certificate). Why it matters: APP 11(2) requires destruction or de-identification when the personal information is no longer needed, and the OAIC has been increasingly explicit that derived data including embeddings and inferences falls within the scope where it is reasonably identifiable. "We tried to delete it but the embeddings are still searchable" is not a defence; the deletion certificate is the operational artefact that turns deletion from a forensic project into a transactional operation, and the certificate trail is the evidence that survives a regulatory or litigation discovery process.

Q: How does the policy decision point enforce lawful basis under APP 6?

APP 6 governs use and disclosure of personal information — entities may only use or disclose personal information for the primary purpose of collection, or a related secondary purpose the individual would reasonably expect, or with consent, or under a small set of statutory exceptions. The policy decision point is the architectural component that enforces APP 6 at the moment PII would be disclosed in a response. When the LLM response would resolve a PII placeholder back to actual personal information, the call goes through the policy decision point: who is asking (asking_user role and identity), what is the lawful basis (consent on file, legitimate purpose under contract, statutory authority, subject-access from the individual themselves), what is the purpose of disclosure (matching against APP 6 primary or secondary purpose), is there a public-interest or safety override that applies. The decision is logged with the policy version that authorised it; the resolved PII flows to the response only after approval. This produces three architectural properties: every disclosure is auditable (policy decision point log is the chain of authority), every disclosure is reviewable (policy changes are version-controlled and the audit log can be replayed against new policies for compliance assessment), and every disclosure is defendable (the operator can produce, on demand, the chain of authority that justified each disclosure under APP 6).

Q: How is the December 2026 automated-decision-making transparency requirement handled architecturally?

New section 26(b) and related amendments require entities to include, in their privacy policy, information about the kinds of personal information used in automated decisions and the kinds of decisions made or substantially made by automated means. The provision applies in full from December 2026; preparation needs to start in 2026. Architecturally, the pattern is to maintain a machine-readable register of automated decisions alongside the system: each entry records what categories of personal information the decision consumes, what kind of decision is produced, what human-review path is available, what model or rule version made the decision, and how an individual can challenge or seek explanation. The privacy-policy section is generated from the register on every release so the policy stays in sync with the system as the system evolves; the register is reviewed at architecture-review for new automated-decision surfaces; the regulator-facing evidence is the register history. This pattern composes with the human-in-the-loop escalation pattern — every automated decision in the register has a documented human-review path the individual can invoke — and with the audit-log discipline already in place for retrieval, so an explanation request can be answered with the actual provenance of the decision rather than a generic policy statement.

Q: How does cross-border transfer (APP 8) work when the model provider is in the US or EU?

APP 8 requires entities, before disclosing personal information to an overseas recipient, to take reasonable steps to ensure the recipient does not breach the APPs in relation to that information. The architectural answer in the privacy-by-design RAG pattern has three layers. First, the prompt that crosses the border contains placeholders rather than identities — the model provider is not receiving personal information in the sense the Act defines, because the placeholders are not reasonably identifiable without access to the vault, which never leaves Australia. Second, the model-provider contract includes zero-data-retention or short-retention with explicit no-training, no-third-party-disclosure terms; the major providers (Anthropic, OpenAI, Bedrock, Vertex) all offer enterprise zero-retention configurations and the gateway hard-fails for any provider configuration that does not have it enabled. Third, the privacy impact assessment documents the cross-border flow, the contractual protections, the technical de-identification, and the residual-risk assessment; the PIA is the regulator-facing evidence that "reasonable steps" were taken. The pattern reduces APP 8 from "we sent personal information overseas and hope" to "we sent placeholders overseas under a zero-retention contract and the personal information stayed in Australia," which is a defensible position under the reformed Act.

Q: How portable is this architecture to UK GDPR, EU GDPR, India DPDP, and Singapore PDPA?

Highly portable; the regulatory specifics differ but the architectural pattern is the same. UK and EU GDPR — the PII boundary maps to the data-minimisation principle (Article 5(1)(c)), the subject-keyed vault enables the right to erasure (Article 17) and the right to data portability (Article 20), the policy decision point enforces lawful-basis-per-purpose (Article 6), per-query provenance supports the right to information (Articles 13-15), the deletion certificate is the evidence for the erasure obligation, the cross-border discipline maps to Chapter V (international transfers) and the SCC framework. India DPDP 2023 — subject-keyed vault enables the right to correction and erasure under section 12, the policy decision point enforces the consent-and-purpose model under section 6, deletion certificates support the obligation to delete on withdrawal of consent under section 13, the storage-layer scoping enforces section 8 (data fiduciary obligations). Singapore PDPA — the same boundary and scoping enforce the access and correction obligations (Part V), the deletion certificate evidences compliance with the retention-limitation obligation, the cross-border pattern maps to Section 26 transfer-limitation. The Australia-specific pieces (statutory tort, OAIC powers, ADM transparency under section 26(b), section 6 sensitive-information categories) are regulatory-mapping changes; the architecture itself ports without modification.

Q: What is the sequence to build this without a six-month re-platform?

Build the PII boundary first — three to four engineering weeks. Stand up the classifier (deterministic patterns plus an LLM second pass), wire the vault as a Postgres table with per-subject indices, add the placeholder-substitution step before the embedder runs, re-embed the corpus through the new path. The embedding store becomes subject-free; the leak surface drops dramatically. Add storage-layer scoping second — two weeks. Move tenant and subject filters into the storage query, add the asking_user / tenant / subjects_in_scope contract to the retriever, refuse queries that omit the contract, add the build-failure test. Cross-subject leakage becomes structurally impossible. Build the deletion certificate third — two to three weeks. Implement the saga-pattern fan-out across stores, emit the certificate at completion, surface it to the requesting individual, retain it in the audit log, address backups via time-bounding. Proof-of-deletion works. Add the policy decision point and per-query audit log fourth — three to four weeks. Wire the gate in front of every PII resolution, log per-query provenance to the admissible-evidence-quality store, enforce zero-retention at the LLM gateway. The system survives the statutory-tort discovery pattern. Add the automated-decision register and deletion-replay testing fifth — ongoing. Maintain the register as a first-class artefact, generate the privacy-policy section from it, run deletion-replay in the release pipeline. The architecture review board can sign off without conditions. Each step ships value independently; no step requires the next to be useful.

Satyam Kumar

Back to Blog

ai-architecture

Privacy-by-Design RAG Architecture for the Australian Privacy Act 2025 Reforms and the Statutory Tort (2026)

By Satyam KumarMay 11, 202619 min read

australia privacy act privacy by design rag architecture statutory tort privacy app 11 oaic pii boundary right to erasure automated decision making privacy compliance ai governance australia multi tenant rag data residency cross border transfer ai architecture privacy 2026

Privacy-by-Design RAG Architecture for the Australian Privacy Act 2025 Reforms and the Statutory Tort (2026)

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Privacy-by-Design RAG Architecture for the Australian Privacy Act 2025 Reforms and the Statutory Tort (2026)

Frequently Asked Questions

Share this article

Comments

Leave a comment