Cookie Consent and AI Personalisation Under ePrivacy

A personalisation feature that reads a signal from the user’s device and feeds it to a model raises two legal questions under two different instruments. Treating them as one is how organisations end up with a valid GDPR analysis and an ePrivacy breach.

Two laws, two questions

The first question is whether you may store information on, or gain access to information already stored on, the user’s terminal equipment. That is governed by Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC, and implemented in national law by each member state — which is why the rule differs in detail across the EU while the GDPR does not.

The second question is whether you may process the resulting personal data for personalisation, profiling, model training or anything else. That is governed by the GDPR, and it needs its own Article 6 basis.

The consequence people trip over: Article 5(3) applies whether or not the information is personal data. A device identifier that you have convinced yourself is anonymous still engages the consent requirement, because the provision protects the terminal equipment rather than the data. And conversely, obtaining consent for the storage does not by itself supply the GDPR basis for the downstream processing — the Court of Justice’s reasoning in Case C-673/17, Planet49, decided on 1 October 2019, runs through consent standards for both, and the two were argued separately for a reason.

What Article 5(3) actually catches

The text does not say “cookie”. It says storing information, or gaining access to information already stored, in the terminal equipment of a subscriber or user. The EDPB’s Guidelines 2/2023 on the technical scope of Article 5(3), adopted 14 November 2023 and finalised after consultation in October 2024, work through the technology-neutral reading in detail and are the document to send to an engineer who says “we do not use cookies”.

On that reading the provision reaches local storage and IndexedDB, pixel-based tracking and tracking links, the collection of any information the browser exposes to script, the reading of an IP address where it originates from the terminal equipment, and identifiers embedded in an installed application or an SDK. For an AI feature this matters because the personalisation signals are rarely in a cookie: a model that adapts to a user typically reads a client-side profile, device characteristics or a locally cached history, and every one of those is an access to stored information.

Fingerprinting is the case that catches teams who deliberately avoided cookies. Assembling a device signature from characteristics the browser exposes is gaining access to information stored in the terminal equipment, notwithstanding that nothing was written. The lack of a storage step is not the exemption; the exemptions are the two below.

The two exemptions, and why AI rarely fits

Article 5(3) exempts two cases. The first is where the storage or access is for the sole purpose of carrying out the transmission of a communication over an electronic communications network. The second is where it is strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide that service.

“Strictly necessary” is narrower than necessary and it is judged against the service the user explicitly asked for, not against the service you would like to provide. A shopping basket, a session token, a load-balancing identifier and a consent-state record all fit comfortably. A recommendation model, an adaptive interface, an engagement-optimised ranking or a personalisation profile do not, because the user asked for the underlying service and the personalisation is the provider’s enhancement of it. That remains true where personalisation is central to the product’s value proposition: regulators have consistently declined to let the business model define the necessity.

Note what the exemptions do not include. There is no legitimate-interest route in Article 5(3). This is the single sharpest difference from the GDPR, and it is why a team that has written a careful legitimate-interest assessment can still be non-compliant: the assessment answers a question the ePrivacy provision does not ask. Where neither exemption applies, the requirement is consent, and consent takes its meaning from the GDPR’s Article 4(11) and Article 7 — freely given, specific, informed, unambiguous, by a clear affirmative action, and as easy to withdraw as to give.

The GDPR question underneath

Once the signal is lawfully read, what happens next is a GDPR question with its own answer, and the answer is not automatically the same.

Some regulators take the position that where consent was required under Article 5(3) for the access, the subsequent processing for the same purpose should also rest on consent rather than on legitimate interest, on the ground that relying on Article 6(1)(f) for the processing would drain the ePrivacy consent of effect. Others accept a split analysis. The safest structure is to make the consent record cover both, and to state the processing purposes in the consent notice rather than only the storage purposes.

Two further constraints attach downstream. If the personalisation produces a decision with legal or similarly significant effects made solely by automated means, you are in Article 22 and the exemptions in Article 22(2) apply. If you intend to reuse the collected interaction data to train or fine-tune a model, that is a further purpose which must survive the compatibility analysis in Article 6(4) or have its own basis — the subject of purpose limitation and training reuse. Reusing personalisation telemetry as a training corpus is one of the most common unnoticed purpose changes in an AI product.

Two adjacent regimes are worth naming so you do not discover them late. Article 21(2) of the GDPR gives an unconditional right to object to processing for direct marketing purposes, including profiling to the extent related to it, and that right has no balancing test at all. Separately, the Digital Services Act prohibits presenting advertising based on profiling using special categories of data, and prohibits profiling-based advertising to recipients the provider knows with reasonable certainty to be minors — obligations that sit outside both instruments discussed here.

The state of the reform

Every discussion of ePrivacy for the last several years has carried a footnote that the Directive was about to be replaced by an ePrivacy Regulation. That is no longer the position. The Commission listed the 2017 proposal for withdrawal in its 2025 work programme, published on 11 February 2025, citing the absence of foreseeable agreement between the co-legislators. Plan on the Directive, as nationally implemented, remaining the operative instrument.

What that means practically is that the divergence between member states is a durable feature rather than a transitional one, and it is real divergence: consent-banner design expectations, the treatment of consent-or-pay models — on which the EDPB adopted Opinion 08/2024 on 17 April 2024 — and the appetite for enforcement all differ by country. A single pan-EU consent implementation is achievable, but it has to be built to the strictest national position you are exposed to rather than to the Directive read on its own.