Someone else's code is collecting on your behalf.
On 24 June 2026 the Privacy Commissioner published two determinations, both dated 11 June 2026, finding that Medmate Australia and Monash IVF interfered with the privacy of individuals whose sensitive information was collected through third-party tracking pixels on their websites. Published alongside them was a report on an inspection of 50 health service provider websites. Most of the commentary read this as an advertising technology story. It is not. It is the clearest statement an Australian regulator has made about who owns code that someone else wrote and you chose to embed.
That question is about to matter far more than it did, because the fastest growing category of embedded third-party code is no longer a marketing tag. It is an assistant your customers talk to.
What did the Commissioner actually decide?
The media release states the position plainly. The determinations conclude a year-long investigation into how the two providers collected sensitive information on websites offering telehealth and fertility services. The Commissioner's decision, in the OAIC's own words, "establishes that the use of tracking pixels to track website visitors to health-related websites, and to subsequently target them with advertising on social media platforms, amounts to a collection sensitive information for which the website provider must obtain users' consent".
The Commissioner added the operative sentence for every entity that runs a website: "Today's decision establishes that the advanced technology used for tracking and targeted in the online realm still has to be used in compliance with the Privacy Act. That means website providers must obtain consent where they're using tracking pixels to collect sensitive information, such as data on health, political opinions, race or ethnicity."
The OAIC's determinations register records the findings in the Monash IVF matter against Australian Privacy Principles 3.3, 5.1, 5.2 and 7.1, with catchwords covering whether personal information was collected and whether reasonable steps were taken to notify individuals. Remedies in both matters require the entity not to repeat or continue the acts and practices found to be an interference with privacy, and to take specified steps.
Two things are worth separating. The first is the subject matter, which is health information on health websites. The second is the principle, which is not limited to health at all: the entity that deploys someone else's code on its own page is the entity answerable for what that code collects.
How widespread is the practice?
The OAIC published the scale alongside the determinations. In October and November 2024 it scanned 50 health service provider websites spanning helplines and mental health services, services for children and young people, pharmaceuticals, and health services including insurance, fertility and abortion.
Of those websites, 96 per cent used tracking technologies and 52 per cent used a third-party tracking pixel. Of the entities using a third-party pixel, 77 per cent did not mention the use of third-party tracking pixels in their privacy policy.
The OAIC then inspected 12 sites more closely. All 12 used more than one third-party tracking pixel and all used the pixel provided by Meta. Half used the TikTok pixel and a quarter used the Snapchat pixel. The OAIC observed web browsing activity being transmitted to social media platforms including full URLs, website searches, button clicks, time and date stamps and device information. It also observed form fields including hashed name, address or telephone numbers being shared, which is used to match a person to their profile even where they are not logged in.
Only four of the 12 referred to tracking pixels in their privacy policies. Of those four, only two named the platform the information was going to.
Read that gap as a control failure rather than a disclosure failure. A privacy policy that does not mention a component is usually a policy written by people who did not know the component was there.
Why does this reach an AI assistant?
Because the architecture is the same, and the risk profile is worse.
A tracking pixel is code supplied by a third party, embedded in a page you control, that receives a record of what people do on that page and transmits it somewhere you do not operate. A customer-facing AI assistant is code supplied by a third party, embedded in a page you control, that receives what people type on that page and transmits it somewhere you do not operate. The only structural difference is the input channel, and the input channel is the part that got worse.
A pixel observes behaviour. An assistant invites disclosure. It is designed to elicit detail, it responds in a way that encourages more of it, and it does not filter what arrives. A person asking about a payment they cannot make will explain why. A person asking about a policy exclusion will describe a diagnosis. None of that was requested on a form, and none of it is less sensitive for having been volunteered.
The OAIC has already put the AI half of this in writing. Its guidance on privacy and the use of commercially available AI products, published on 21 October 2024 and updated on 17 January 2025, states that businesses "should update their privacy policies and notifications with clear and transparent information about their use of AI, including ensuring that any public facing AI tools (such as chatbots) are clearly identified as such to external users such as customers". It also states that where AI systems are used to generate or infer personal information, that is a collection of personal information. And it records the OAIC's best-practice recommendation that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools.
Put the two documents side by side and the position is not ambiguous. Third-party code on your page collects for you. AI-generated inferences are themselves a collection. Public-facing AI tools have to be identified as AI. Nothing in the June determinations narrows any of that to pixels.
What does a compliance function do about it?
Run this as a component inventory, not as a privacy policy rewrite. The policy is the last artefact you change, not the first.
- List every third-party component on customer-facing pages. Advertising and analytics tags, session recording, chat and support widgets, personalisation engines, embedded AI assistants, accessibility overlays, consent tools. Ask engineering for the tag manager export and the content security policy, not marketing for a list.
- Record what each component receives. Page URLs, search terms, form field contents, free text, uploaded files. Free text and uploads are a different class from clickstream and should be recorded as such.
- Classify the sensitive information exposure. Not what you intend to collect, but what a user could plausibly type or trigger on that page. Health, racial or ethnic origin, political opinions, religious beliefs, sexual orientation and criminal record are the categories that raise the consent bar.
- Name the collection and the disclosure separately. Information arriving at your assistant is a collection by you. Information onward to a model provider or an advertising platform is a separate question about use and disclosure. Organisations routinely answer the first and forget the second.
- Test the consent, do not read it. Have someone who did not write it walk the journey. If the notice says cookies and the component is a pixel or a model, the specificity is doing no work. Consent for sensitive information carries a higher bar than a banner clears.
- Assign an owner per component with a review date. The inventory decays the moment a campaign ships. An owner and a date is the only part of this that survives contact with a marketing calendar.
Three of those six steps typically surface a component that no current employee chose. That is the finding worth reporting, because it is the one that repeats.
Where do organisations get this wrong?
Three ways, all avoidable.
Treating the vendor's assurance as your control. A supplier telling you their pixel or model does not retain personal information is a statement about their systems. It is not evidence about your configuration, and configuration is where these matters were decided. The OAIC's November 2024 guidance is explicit that organisations deploying third-party pixels should conduct appropriate due diligence to ensure they are used in a compliant way, and should adopt a data minimisation approach.
Assuming free text is the user's problem. It is not. A person volunteering their diagnosis to your assistant has not consented to anything by typing it, and an assistant that accepts it has collected it. If you cannot stop the input, control the retention, the routing and the downstream use, and say so where the person can see it before they type.
Scoping the review to the privacy team. The components sit in a tag manager owned by marketing, a widget owned by digital, and a model contract owned by procurement. A privacy review that never reaches those three functions produces an accurate document about an inaccurate picture.
Bottom line
The Privacy Commissioner has now applied the Privacy Act to third-party code embedded in a page and found the deploying organisation responsible for what it collected. The reasoning does not depend on the code being a pixel, and the highest-exposure component most organisations will add this year is a customer-facing AI assistant that invites people to type whatever they like. Inventory the code, classify what it receives, fix the consent where sensitive information is realistically in scope, and give every component an owner. This is third-party risk management applied to a page instead of a supplier.
Do this Monday:
- Pull the tag manager export and the content security policy for your top five customer-facing pages
- List every third-party component, including any AI assistant, and name what each one receives
- Flag every page where a user could plausibly disclose health, financial hardship or identity details in free text
- Check whether your public-facing AI tools are clearly identified as AI, per the OAIC's October 2024 guidance
- Assign an owner and a review date to each component before the next campaign ships
Content disclaimer: This article is for general educational and informational purposes only. It does not constitute legal advice, regulatory guidance, or a substitute for professional compliance judgement. Regulatory obligations vary by entity type, licence, and circumstance. Always refer to primary source guidance from APRA, ASIC, the OAIC or the relevant regulatory authority.
Primary sources
- OAIC, Privacy Commissioner finds privacy breaches in third-party tracking pixel investigation, media release, 24 June 2026. https://www.oaic.gov.au/news/media-centre/privacy-commissioner-finds-privacy-breaches-in-third-party-tracking-pixel-investigation
- Commissioner Initiated Investigation into Monash IVF Pty Ltd (Privacy) [2026] AICmr 40, 11 June 2026, and Commissioner Initiated Investigation into Medmate Australia Pty Ltd (Privacy) [2026] AICmr 41, 11 June 2026, as recorded in the OAIC privacy determinations register. https://www.oaic.gov.au/privacy/privacy-assessments-and-decisions/privacy-decisions/privacy-determinations
- OAIC, Your life, pixelated: how tracking pixels watch your every click, 24 June 2026. https://www.oaic.gov.au/news/blog/your-life,-pixelated-how-tracking-pixels-watch-your-every-click
- OAIC, Tracking pixels and privacy obligations, 4 November 2024. https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/organisations/tracking-pixels-and-privacy-obligations
- OAIC, Guidance on privacy and the use of commercially available AI products, 21 October 2024, updated 17 January 2025. https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-the-use-of-commercially-available-ai-products
TheAICommand. Intelligence, At Your Command.
