Children's Data and AI Products Under GDPR Article 8

Article 8 is narrower than its reputation and harder than its headline. It only engages for consent-based information society services offered directly to a child — but where it does engage, the age threshold is set by each member state anywhere between 13 and 16, and a product that hard-codes one number is non-compliant in most of the Union.

When Article 8 applies at all

Article 8(1) of the GDPR applies where point (a) of Article 6(1) — consent — is the lawful basis, in relation to the offer of information society services directly to a child. Three conditions, all of which have to hold. If your lawful basis is performance of a contract under Article 6(1)(b) or legitimate interests under Article 6(1)(f), Article 8 does not engage. If the service is offered to organisations rather than directly to children, it does not engage. If the thing is not an information society service — a service normally provided for remuneration, at a distance, by electronic means and at the individual request of a recipient — it does not engage.

That is a real limit and it is routinely over-read in both directions. A consumer AI assistant with a free tier offered to the public is squarely an information society service offered directly to individuals, and if it relies on consent for anything — analytics profiling, personalisation, training use — Article 8 is live for the under-age users among them. A business API sold to companies is not.

Where Article 8(1) does apply, processing is lawful where the child is at least the applicable age. Below it, consent must be given or authorised by the holder of parental responsibility over the child. Article 8(3) preserves national contract law: parental authorisation under data protection law says nothing about whether a minor can form a binding contract, and in several member states they cannot, which is a separate problem for a paid tier.

The age is not 16 everywhere

Article 8(1) sets the default at 16 and then permits member states to provide by law for a lower age, provided it is not below 13. Most member states used that discretion, and they did not converge. At the time of writing the implementations cluster at four values — 13, 14, 15 and 16 — with roughly a third of member states at 16 (including Germany, Ireland and the Netherlands), a group at 13 (including Denmark, Sweden, Belgium and Portugal), a group at 14 (including Spain, Italy, Austria and Cyprus) and a group at 15 (including France, Greece and Czechia). Ireland’s figure of 16 is set by the Data Protection Act 2018 — the Irish Statute Book text of Act No. 7 of 2018 — and every other member state’s figure sits in its own implementing act in the same way.

The practical consequence is that the applicable age is a function of the child’s member state, which you generally do not know at the moment you need it. Two responses are defensible and one is not. You can apply 16 everywhere, which is over-compliant, costs you users in thirteen-year-old markets, and is safe. You can determine the applicable state and apply its age, which is correct and requires you to have a reliable signal for residence rather than for IP geography. What you cannot defensibly do is apply 13 everywhere on the theory that some member state permits it.

Reasonable efforts to verify

Article 8(2) requires the controller to make reasonable efforts to verify in such cases that consent is given or authorised by the holder of parental responsibility over the child, taking into consideration available technology. It does not say what those efforts are, and that vagueness is the whole difficulty. Two things are clear from the text. The standard is proportionate — reasonable efforts, not certainty — and it moves with technology, so an answer that was reasonable in 2018 is not automatically reasonable now.

A tick box saying “I am over 16” is the minimum and it is widely regarded as insufficient on its own for high-risk processing, because it is an assertion by the person whose age is in question. The proportionality lever is risk: the more intrusive the processing, the more the effort has to be. A model that generates open-ended conversation with a minor, retains the transcripts, and uses them to personalise, is at the high end of that scale. Note also the second-order problem that regulators have raised repeatedly — verifying age and parenthood robustly means collecting more identity data about children than you otherwise would, which cuts directly against Article 5(1)(c) data minimisation. There is no clean answer to that tension in the text, and the pragmatic reading is that verification measures should themselves be minimising: an age signal that returns a yes or no is preferable to one that returns a document.

The obligations that apply anyway

Article 8 is the smallest part of children’s data protection, and a product that escapes it has not escaped much. These apply regardless of lawful basis:

• Article 12(1) transparency. Information must be provided in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. A privacy notice written for a data protection officer does not satisfy this for an audience of fourteen-year-olds.
• Recital 38. Children merit specific protection because they may be less aware of the risks, consequences and safeguards concerned and of their rights. It also singles out marketing, personality and user profiling, and the collection of data when using services offered directly to a child.
• Recital 71 and Article 22. Recital 71 states that a solely automated decision with legal or similarly significant effects should not concern a child. It is a recital rather than an operative prohibition, which matters — but a regulator reading a profiling-driven decision affecting a minor will start from it.
• Article 17(1)(f) erasure. The right to erasure is strengthened where the data were collected in relation to the offer of information society services referred to in Article 8(1). A childhood account is meant to be erasable in a way an adult one is not.
• Article 35 DPIA. Systematic processing of children’s data appears in most supervisory authorities’ mandatory-DPIA lists under Article 35(4). Check your own authority’s list rather than assuming.

What this forces in the product

The design consequences are concrete and they mostly land before any model call happens. The applicable age has to be a configuration value resolved per user rather than a constant. The consent record has to store which age threshold was applied and on what basis, because “we obtained consent” is not an answer to “from whom, and under which member state’s rule”. Parental authorisation, where required, needs to be revocable by the parent and that revocation has to propagate to every downstream store — which for an AI product means conversation history, embeddings and any evaluation dataset the transcripts were sampled into.

The one design choice that removes most of this is not relying on consent. If the processing genuinely is necessary for a contract the user has entered into, Article 8 does not engage, and the analysis moves to whether that necessity claim survives scrutiny — which for personalisation and training use it generally does not. Building the feature so that the minimum processing runs on contract and the optional processing runs on separate, granular, withdrawable consent is both the Article 6 answer and the Article 25 answer at once; see privacy by design applied to an AI feature.

If the product also serves the United States, note that the two regimes do not line up: COPPA is keyed to under-13 and to actual knowledge, with a verifiable parental consent standard that is more prescriptive than Article 8(2) — see COPPA and AI products for children. And if the AI feature is conversational, the AI Act’s transparency duty applies in parallel to a child audience that is particularly likely to be misled about what it is talking to; see the chatbot disclosure duty.