GDPR vs Privacy Act 1988 for Australian Midsize

When an Australian Business Suddenly Has Two Privacy Regulators

Consider a typical Australian SaaS business based in Sydney. Their AI features summarise customer support tickets, draft replies, and surface insights from chat history. The product was built for the Australian market. Over three years, sales picked up a long tail of UK and EU customers (small but real revenue), a Berlin contractor joined the engineering team, and the AI vendor processing the embeddings turned out to host its inference workload in Frankfurt and Dublin for latency reasons.

That business is now sitting inside the GDPR, the UK GDPR, and (depending on how the AI is used) the EU AI Act. It is also fully bound by the Privacy Act 1988 (Cth) and the 2024 amendments that introduced the new Australian automated decision-making transparency obligations. Two regulators, two breach clocks, two different consent standards, and a transfer regime that does not treat Australia as adequate. None of this was on the original product roadmap.

This is the tenth and final article in our series for Australian businesses running AI in production. The earlier articles covered why DIY without understanding fails, the operating reality of AI agents in production, the staffing gap, vendor selection, ACCC consumer guarantees, financial services AI compliance, the 50-point AI security checklist, the business case template, change management, and most recently AI agent governance, data access, and human override.

This article closes the loop on the cross-border privacy question: what happens when your AI or data flows touch the EU or UK, and where the two regimes actually diverge in ways that change what you need to build.

The thesis in one paragraph

Australia's Privacy Act 1988 and the EU GDPR look broadly similar at 30,000 feet. Both protect personal information, require lawful collection, mandate breach notification, and grant access rights. At the ground level, they diverge sharply on consent standard, lawful basis structure, automated decision-making rights, DPIA mandate, cross-border transfer mechanics, and penalty design. The EU AI Act now sits on top of GDPR with a separate set of obligations triggered by AI use, not just data processing. For any Australian business whose AI touches EU or UK personal information, those divergences decide what you must actually build.

Part 1: The 30,000-Foot Similarities

Read either statute and you will find a recognisable shape. Both regimes share the same broad architecture.

The shared architecture is genuine. A team that has done a serious Privacy Act 1988 compliance build will recognise the GDPR vocabulary. The trap is assuming the similarity goes all the way down. It does not.

Part 2: Where the Two Regimes Actually Diverge

These are the divergences that materially change what you build when AI is in the mix.

1. Consent threshold

The Privacy Act and GDPR both use the word "consent". They mean different things.

GDPR Art 4(11) and Art 7 define consent as "freely given, specific, informed and unambiguous indication of the data subject's wishes" by a "clear affirmative action". Bundled consent fails. Pre-ticked boxes fail. Service-gated consent generally fails. Withdrawal must be as easy as giving consent.

Privacy Act APP 3 requires consent for collection of sensitive information and references the concept of "consent" defined in s 6(1), but does not codify the specificity, bundling, and withdrawal mechanics that GDPR does. The OAIC's APP Guidelines recommend express, informed, voluntary, and current consent, but the statutory text is less prescriptive.

For AI, the divergence matters at training-data ingestion and at any user-facing feature where you ask permission to feed inputs into a model. A consent flow that satisfies the OAIC may fail the GDPR test.

2. Lawful basis structure

GDPR has six lawful bases in Art 6 (consent, contract, legal obligation, vital interests, public task, legitimate interests) plus the layered special-category rules in Art 9 (which require both an Art 6 basis and an Art 9 condition). Choose one, document it, stick to it. "Legitimate interests" is available but requires a documented balancing test.

The Privacy Act does not work this way. APP 3 governs collection by reference to whether collection is reasonably necessary for the entity's functions or activities (plus consent for sensitive information). There is no equivalent of the Art 6 menu, and no equivalent of a documented balancing test as a precondition.

For AI projects, this is one of the largest practical gaps. Many Australian businesses have never recorded a lawful basis for any processing because the Privacy Act has not asked them to. The first GDPR-touching AI use case typically exposes a complete absence of that documentation.

3. Automated decision-making rights

This is the divergence that hits AI hardest.

GDPR Art 22 grants data subjects the right "not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her", subject to limited exceptions (contract necessity, EU or member state law, explicit consent). Where an exception applies, the controller must implement suitable safeguards including the right to obtain human intervention, to express a point of view, and to contest the decision.

Privacy Act historically had no equivalent. The Privacy and Other Legislation Amendment Act 2024 introduced new APP 1.7 transparency obligations for entities that use computer programs to make decisions that could reasonably be expected to significantly affect the rights or interests of an individual. Entities must include information about that use in their privacy policy. The substantive provisions commence in December 2026. This is a transparency obligation. It is not a right not to be subject to automated decisions, and it does not require human intervention as a right.

The gap matters. An AI scoring engine that auto-declines an EU resident's application is potentially an Art 22 decision and triggers the full safeguard stack. The same engine applied to an Australian resident must be disclosed in the privacy policy under the 2024 reforms, but does not need to offer human intervention as a statutory right.

4. DPIA versus PIA

GDPR Art 35 requires a Data Protection Impact Assessment "where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons". The EDPB's guidance on DPIAs lists AI involving automated decision-making with significant effects, large-scale processing of special categories, and innovative use of new technologies as triggers. DPIAs are mandatory where the trigger applies, and supervisory authorities can demand to see them.

The OAIC recommends Privacy Impact Assessments and publishes a PIA guide, but the Privacy Act does not impose a general statutory PIA requirement on private sector entities. The Australian Government Agencies Privacy Code requires PIAs for agencies, not the private sector.

For an Australian business building AI features, the DPIA stops being optional once GDPR is engaged. If your AI involves automated decisions, special-category inference, or biometric processing on EU residents, you need a documented DPIA before the processing begins.

5. Cross-border transfers

GDPR Chapter V restricts transfers of personal data to "third countries" (any country outside the EU and EEA) unless one of the listed mechanisms applies: an adequacy decision (Art 45), appropriate safeguards including Standard Contractual Clauses or Binding Corporate Rules (Art 46), or limited derogations (Art 49). The Schrems II judgment (Case C-311/18, July 2020) added the requirement that controllers conduct a Transfer Impact Assessment for each transfer using SCCs, evaluating the third country's law and practice against EU standards. The European Commission issued updated SCCs in June 2021 (Decision 2021/914).

Australia does not currently hold an EU adequacy decision. The European Commission's adequacy list, as of early 2026, includes the UK, Switzerland, Japan, South Korea, New Zealand, Canada (commercial), Israel, Argentina, Uruguay, Andorra, the Faroes, Guernsey, Jersey, the Isle of Man, and the United States (under the EU-US Data Privacy Framework, with limitations). Australia is not on it.

The practical effect: every transfer of EU personal data into an Australian-hosted AI system, or an Australian vendor's database, requires SCCs plus a TIA. The TIA must assess whether Australian surveillance and law-enforcement law (including the Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018) provides essentially equivalent protection to EU standards, and whether supplementary technical, organisational, or contractual measures are needed.

APP 8 is the inverse view. It requires APP entities to take reasonable steps to ensure that overseas recipients do not breach the APPs, and makes the disclosing entity accountable for the recipient's acts in most cases. APP 8 is a "reasonable steps" standard. Chapter V is a prohibition with enumerated exceptions.

6. Penalty design

The Privacy Legislation Amendment (Enforcement and Other Measures) Act 2022 lifted maximum penalties under s 13G of the Privacy Act for serious or repeated interferences with privacy to the greater of A$50 million, three times the benefit obtained, or 30% of adjusted turnover for the relevant period. The 2024 amendments added a tiered civil penalty structure with mid-tier and low-tier offences.

GDPR Art 83 sets maximum administrative fines at the higher of EUR 20 million or 4% of total worldwide annual turnover of the preceding financial year (for the more serious infringements in Art 83(5)). The EUR 10 million or 2% tier applies to Art 83(4) infringements.

Both regimes can put a serious dent in a P&L. The structural difference is who imposes the penalty: a court on application by the Information Commissioner in Australia, versus the relevant supervisory authority by administrative decision in the EU (subject to appeal).

7. EU AI Act

Regulation (EU) 2024/1689 (the EU AI Act) entered into force on 1 August 2024, with staged application. Prohibitions on the listed unacceptable-risk practices applied from February 2025. Governance and obligations for general-purpose AI models applied from August 2025. The bulk of high-risk AI system obligations apply from August 2026.

The AI Act has extraterritorial reach. It applies to providers placing AI systems on the EU market or putting them into service in the EU, and to providers and deployers established outside the EU "where the output produced by the AI system is used in the Union". An Australian business that develops an AI system used by EU-based customers, or whose AI output is consumed inside the EU, can fall within scope even with no EU establishment.

High-risk classification depends on whether the AI system is listed in Annex III (areas including employment decisions, credit scoring, biometric categorisation, critical infrastructure, and education) or is a safety component of a product covered by Annex I. High-risk systems carry obligations across risk management, data governance, technical documentation, transparency, human oversight, accuracy, and robustness.

For Australian businesses, the AI Act is not engaged by every AI use case. It is engaged when the AI is placed on the EU market or its output flows into the EU, and the obligations bite hardest at the high-risk tier.

Part 3: The Four Scenarios Where Dual Jurisdiction Lands on an Australian Business

Most businesses do not arrive at dual jurisdiction deliberately. They arrive at it through one of four routes.

The third scenario is the one most often missed. A business with no EU customers and no EU staff can still find its AI workload routed through Frankfurt or Dublin because that is where the vendor's nearest GPU capacity lives. Whether GDPR formally applies in that case depends on whether the AU business is acting as a controller of EU personal data, but the vendor's data processing agreement will almost certainly impose GDPR-style obligations regardless.

The fourth scenario sits upstream. If the foundation model you embed in your product was trained on EU personal data, the model provider carries direct GDPR exposure (as the Italian Garante's intervention and subsequent regulatory work on generative AI training have shown). Your obligation as a deployer is to satisfy yourself that the provider has a defensible position. The EDPB's December 2024 Opinion 28/2024 on AI models and personal data is the current reference point.

Part 4: The Data Flow Map with Regime Checkpoints

For any AI use case that may touch EU or UK personal information, draw the flow. The checkpoints fall in predictable places.

Each checkpoint is a place where the two regimes ask different questions of the same data. The map needs to be complete rather than pretty, and it needs to be the artefact that the CIO, CPO, and General Counsel work from when scoping any AI build that may touch EU data.

Part 5: The Practical Control Stack

If you are an Australian business with confirmed or possible EU exposure on an AI workload, this is the control stack to put in place. Order matters.

The stack is the same regardless of vendor. SaaS-bought, partner-built, or in-house: someone has to own each of these eight artefacts, and they need to refer to each other.

Part 6: How Much GDPR Exposure Do You Actually Have?

Most businesses overestimate or underestimate this. The decision tree below is a first pass.

The honest answer for most Australian businesses with any international footprint is that at least one of the moderate triggers is already live, even if leadership has never been asked about it. Run the test, document the answer, and re-run it every twelve months and on every material change to the product, the supply chain, or the workforce.

Part 7: Ten-Question Readiness Checklist for the GC and CPO

Before any new AI program goes live, the General Counsel and Chief Privacy Officer (or whoever holds those responsibilities) should answer these ten questions in writing.

1. Have we identified every category of personal information the AI will collect, infer, or output, and tagged each by data-subject jurisdiction (AU, EU, UK, other)?
2. Have we recorded a lawful basis under GDPR Art 6 (and Art 9 if special category) for each processing operation that touches EU personal data?
3. Have we completed a DPIA under Art 35 for the AI use case, and is the DPIA proportionate to the risk?
4. For any EU-to-AU data flow: have we signed the June 2021 SCCs and completed a Schrems II Transfer Impact Assessment with documented supplementary measures?
5. For UK data: have we executed the UK International Data Transfer Agreement or the UK Addendum to the EU SCCs?
6. Does our AI make any solely automated decision with legal or similarly significant effect on EU residents, and if so, which Art 22(2) exception applies and what safeguards are in place?
7. Have we mapped APP 1.7 transparency disclosures for the December 2026 commencement, including all in-scope automated decisions affecting Australians?
8. Does our incident response plan trigger both the GDPR 72-hour clock and the OAIC NDB 30-day clock from a single incident detection, with parallel notification templates?
9. Have we determined whether the EU AI Act applies (system placed on EU market or output used in EU) and if so, whether the system is high-risk under Annex III?
10. Have we documented the answers to questions 1 through 9, dated them, and assigned a named owner for re-review at twelve months or on any material change?

If you cannot answer any of these in writing, that is the gap to close first.

Where This Series Leaves You

This is the tenth and final article in the series for Australian businesses running AI in production. Across the ten posts the through-line has been the same: AI is no longer a research project, the operational and regulatory load is real, and the businesses that survive the next two years are the ones treating governance as a build deliverable rather than a slide deck.

The cross-border privacy question is the last unguarded edge for most businesses. The Privacy Act 2024 reforms moved Australia closer to GDPR on transparency and penalties, but the structural divergences on consent, lawful basis, Art 22, DPIA, and Chapter V transfers remain real. Add the EU AI Act and the dual-jurisdiction footprint is now broader than it was twelve months ago.

If your business has any of the triggers in Part 6 live, the right next step is a focused discovery: one workshop, one data flow map, one written exposure assessment, one prioritised remediation plan. We do that work as part of our AI Strategy and Managed AI Services engagements, and our data sovereignty guide is the open companion if you want to read first.

For a consultative scoping conversation: book a 30-minute call. No deck, no pitch. We will work through the four scenarios in Part 3 against your business, write the answers down, and tell you which controls in Part 5 you actually need.

Related Reading:

• Why Australian Businesses Should Not DIY AI Agents Without Understanding - Where this series began. The risk profile of unmanaged AI.
• Operating AI Agents in Production: The Reality - The day-two operational load that follows any AI build.
• The AI Agent Staffing Gap in Australian Business - Who actually does the work covered in this article.
• AI Vendor Selection Questions for Australian Business - The vendor diligence layer that surfaces EU processing locations.
• ACCC Consumer Guarantees and AI Implementation - The Australian Consumer Law layer alongside privacy.
• Financial Services AI Compliance: APRA and ASIC - Sectoral overlay if you are in finserv.
• AI Security Checklist: 50 Points for Australian Businesses - The security control set that sits underneath the privacy stack.
• Automation Business Case Template for Australian Business - How the compliance cost gets into the business case.
• AI Change Management and Employee Adoption - The people side of compliance rollout.
• AI Agent Governance, Data Access, Privacy, and Human Override - The previous article in this series. The internal governance frame that this cross-border article extends.

Sources:

This article references the Privacy Act 1988 (Cth) and the Privacy and Other Legislation Amendment Act 2024; Regulation (EU) 2016/679 (GDPR) including Arts 3, 6, 7, 9, 13 to 22, 30, 33, 35, 37, 45, 46, 49, 83; the Data Protection Act 2018 (UK) and UK GDPR; Regulation (EU) 2024/1689 (EU AI Act); the Court of Justice judgment in Case C-311/18 (Schrems II); European Commission Decision 2021/914 on Standard Contractual Clauses; the OAIC's APP Guidelines and guidance on Australian entities and the GDPR; the EDPB's guidance on DPIAs and Opinion 28/2024 on AI models and personal data; published actions by the Italian Garante and French CNIL relating to generative AI. Legal positions evolve. This article is general information, not legal advice.