Your martech stack is a collection engine. The OAIC just said so.

I am not a lawyer. This is my professional view, written for marketers who need to understand what this means for how they operate. If you’re making compliance decisions, get a privacy lawyer involved.

On 13 May 2026, the OAIC published a substantial rewrite of its APP 3 guidelines, the chapter of the Australian Privacy Principles that governs how organisations collect personal information. The first significant rewrite in over a decade.

I am almost certain most marketers won’t read this, but it is relevant to us, so I have and here’s what you need to know. The definition of “collection” now explicitly covers what modern martech does by default: inferring audiences, enriching profiles, tracking behaviour, capturing chatbot inputs, and generating AI meeting transcripts. If your stack touches personal information (it does), the compliance surface just expanded significantly.

My read: this is overdue and welcome. The old guidance left “collection” effectively undefined for anything more sophisticated than a contact form. Marketing teams and their legal advisors have been operating in interpretive grey for over a decade. The new version names AI inference, enrichment, scraping, and observation explicitly. Clarity gained. But clarity cuts both ways. The “we didn’t realise” defence has been retired.

Here’s what changes in practice.

AI inference is now a collection event

Before: your CDP scoring customers for churn risk, your personalisation engine inferring purchase intent, your ad platform building lookalike audiences from inferred attributes, your AI tool tagging behavioural data with predicted demographics. None of this was clearly “collection.” It was processing of data you’d already collected.

Now: the OAIC explicitly states that personal information “generated, inferred or observed from” other data you hold is a collection event. AI, automated decision-making, data analytics, cookies and IoT devices are named.

What this means operationally: every audience built on inferred attributes needs a documented justification under APP 3. You can’t bury this in a privacy policy. You need to demonstrate that the inference is reasonably necessary for a specific function, that the privacy impact is proportionate to the benefit, and that the fairness test is satisfied. The reasonable expectations standard is well-established in Australian law. What’s being worked out in real time is how that standard applies to AI inference, enrichment, and modern data practices. The interpretive frontier is the modern stack, and that’s where the operational risk sits.

Practical impact: a lot of standard CDP and personalisation workflows now generate ongoing compliance obligations that someone needs to own. Marketing operations teams need to extend their data use register to track inferred attributes alongside collected ones. If you can’t say why an inferred attribute exists, what it’s used for, and how the privacy impact is justified, you have exposure.

Data enrichment from third parties is materially harder to justify

Before: buying enriched data from a broker, appending demographic or firmographic data to your CRM records, using a third-party identity graph for matching. Standard practice, justified loosely on legitimate interest or buried in the privacy notice.

Now: the OAIC has added a worked example that explicitly closes the “unreasonable or impracticable” exception when the real reason is that direct collection is inconvenient. The fairness test now asks whether the individual would reasonably expect their information to be matched and enriched.

What this means operationally: explicit consent for enrichment at the point of original collection is the cleanest answer, but it isn’t always viable. Reconsenting a customer base of millions to retroactively cover enrichment activity is operationally disproportionate to the privacy benefit gained, and proportionality cuts both ways. The practical operating standard most organisations will land on: apply the new fairness factors prospectively, document the reasoning, capture better consent going forward, narrow the scope of what gets enriched, and accept that historical records sit under the previous standard. Where historical consent is clearly defective, targeted remediation rather than blanket reconsent.

Practical impact: B2B teams running outbound on enriched data, B2C teams using identity graphs for matching, and anyone running lookalike audiences built on third-party-enriched first-party data all need to review their consent chain and justification. The “we bought it from a vendor who said it was consented” line will not survive scrutiny if the consent chain doesn’t extend to the use you’re putting it to. Going forward, capture consent for enrichment at the point of original collection, or narrow the use case until it sits comfortably inside the consent you have.

Consent UX is now subject to a structured fairness test

Before: a “reject all” button somewhere on the consent banner was treated as sufficient. Default opt-in was contested but widely practised. Bundled consent (one click for marketing, analytics, and personalisation) was common.

Now: the OAIC explicitly names confirmshaming, bundled consent, biased framing, and default settings as practices that can make collection unfair. The test isn’t whether the user technically clicked accept. It’s whether their choice was genuine, informed, and free from manipulation. This is privacy by design applied at the point of consent capture.

What this means operationally: consent banners need to be reviewed against the new fairness factors. “Accept all” and “Reject all” need equal visual weight. Granular consent (separate toggles for marketing, analytics, personalisation, third-party sharing) becomes the safe default. Pre-ticked boxes for optional purposes are out.

Practical impact: direct hit on CMP configurations. The signal loss this creates is the single biggest operational consequence of this guidance for performance marketers, and I’ll come back to it.

Public web data and AI training are now in scope

Before: scraping public web data for competitive intelligence, social listening, brand monitoring, or AI training was treated as outside APP 3 because it was “publicly available.” A grey area at worst.

Now: the OAIC explicitly states that publicly available status does not entitle you to collect and use the data however you choose. Collection from public sources still needs to pass the reasonably necessary and fair means tests. The guidance includes a specific example: training an AI model on personal information when de-identified data would have worked may not pass the reasonably necessary test.

What this means operationally: if you’re fine-tuning a custom AI model on customer data, communications, support tickets, or scraped web content, you need to justify why personal information specifically is required rather than de-identified data. If you’re using a social listening tool that matches public posts to individuals, you need to assess whether the OAIC would consider that fair. If your sales team is scraping public profiles for outbound, you have new exposure.

Practical impact: any in-house AI training pipeline needs a “de-identification considered and rejected because…” justification step before it can ingest personal data. Social listening and brand monitoring use cases need review. Outbound built on scraped public data needs reassessment.

What the platforms will and won’t do

Marketers should not expect the platforms to solve this for them. Here’s the split.

Consent Management Platforms (OneTrust, Didomi, Cookiebot, Sourcepoint) will update their default templates to reflect the new fairness factors. Granular toggles, equal-weight accept/reject, removal of pre-ticked boxes. The vendors move quickly on this kind of thing. But the historical consent records they hold for you do not become compliant automatically. Forward-going consent is on them. Audit, remediation, and substantive justification is on you.

Google and Meta will push obligation downstream. We’re seeing this with the June 15 2026 Google change (Signals migration to ad_storage via Consent Mode), where the consent banner is now the only control surface Google will accept. Expect Australian-specific equivalents. The platforms will protect themselves; they won’t protect you.

Email and marketing automation platforms (Mailchimp, HubSpot, Marketo, Klaviyo) will continue to require some form of opt-in but won’t validate the quality of your consent. That’s your problem.

The most exposed layer of the stack is the part that handles inference, enrichment, and identity resolution. That covers mature CDPs, DSPs, identity resolution platforms, and data brokers. The platforms themselves will add features (consent metadata per attribute, lawful basis tracking, consent-aware activation), but the substantive work, justifying each inference, documenting each enrichment, demonstrating proportionality, sits with the marketer.

The summary: platforms will handle the surface. They will not handle the substance.

The performance cost is real

Now the part that matters most for performance marketers. The new guidance, taken seriously, reduces the amount of usable data in the stack. That has direct performance consequences.

Granular consent reduces marketing-eligible audiences. Industry analyses of the EU GDPR rollout report consent-driven reach losses of up to 70% in some categories. Australian reductions are likely to be lower, because privacy salience is lower here, but the direction is clear. Brands that relied on aggressive defaults to drive opt-in rates will see significant attrition. Brands that already ran balanced consent flows will see modest impact.

Signal loss compounds across the stack. Less consent-eligible signal means weaker behavioural modelling, lower-quality lookalike audiences, less effective bidding, and degraded attribution. Marketing teams already lose 30 to 50 percent of attribution signal to existing consent management depending on category. This guidance tightens that further.

Inference and enrichment are the engines of personalisation. Both are under pressure. Less inferred data means less effective personalisation. Less enrichment means weaker segmentation. The economics of one-to-one marketing depend on data that this guidance puts under scrutiny.

This is the real conversation marketers need to have with their boards. Compliance is not free. The performance cost is real. The strategic response is to invest harder in first-party data, design stronger value exchanges that drive genuine consent, and lean into contextual targeting where behavioural fails. The brands that build genuine consent at scale will compound advantage. The brands that rely on defaults and dark patterns to drive opt-in rates are looking at a structural performance reset.

CUV becomes the operating layer

I wrote about the CUV Framework (Consent, Utility, Value) as a way to evaluate whether a data use case is ethical, valuable, and legally defensible. The new APP 3 guidance is essentially the regulatory expression of the same logic. The reasonably necessary test maps to Consent and Utility. The proportionality balancing exercise maps to Value. The fairness factors (dark patterns, vulnerability, choice architecture) map back to Consent and Value.

If you already operate against a framework like CUV, the new guidance shouldn’t surprise you. If you don’t, you need one, because the OAIC has now given you the questions and you need a repeatable way to answer them across hundreds of use cases.

Clarity gained, exposure gained, performance pressured

The OAIC has caught up to the modern marketing stack. Marketing teams operating CDPs, personalisation engines, AI tools, and third-party enrichment workflows now have explicit guidance on what counts as collection and how that collection needs to be justified. That is a net positive for the industry. Clarity gained.

But the same clarity that helps you operate confidently also exposes you. You can no longer plausibly claim you didn’t realise your CDP was generating collection events. The “we didn’t know” defence is gone. Operate well, and the new guidance is a roadmap. Operate badly, and it’s a charge sheet.

This is also why specialist representation in this space matters. Regulators write guidance that is technically correct but operationally abstract. Generalist marketing bodies advocate at the level of brand and creative. Neither does the work of translating regulatory change into practical operating standards for data-driven marketing teams, or of feeding operator reality back into the regulatory process. That work is specialist. It needs people who understand both the legal text and the actual mechanics of a CDP, a consent platform, an LLM training pipeline. The new OAIC guidance is exactly the kind of moment where that translation layer earns its keep.

The ADM provisions (APP 1.7 to 1.9) come into force on 10 December 2026. This Chapter 3 rewrite is the OAIC setting the interpretive baseline for what “collection” means in an AI and automated context, six months out. The marketers who treat this as a structural shift in how the discipline operates will adapt. The ones who treat it as compliance theatre will get caught.