Children's Data in AI: GDPR, COPPA and UK Rules Explained

If your AI product might process a child's data, four regimes apply at once: GDPR Article 8 sets the age of consent at 13 to 16 depending on the member state, the UK Children's Code sets 15 design standards, COPPA governs under-13s in the US, and the Online Safety Act now demands age checks that actually work. Data minimisation runs underneath all of them. The board-level question isn't whether you target children. It's whether children can reach the product at all. If they can, the obligations attach whether you planned for them or not.

That distinction catches most companies out. A B2B tool, an education platform, a streaming service, a game: none of these need a child as the intended user for the rules to bite. They only need a child to be a likely user. Below is what each regime asks for, and what your legal, compliance and data teams should be checking now.

Which laws apply when AI processes children's data?

Four frameworks sit on top of each other. They overlap, and they don't always agree on the age line. Here's the shape of it.

Framework	Jurisdiction	Core trigger	Headline duty
GDPR Article 8	EU / EEA	Information society services offered to a child, relying on consent	Verifiable parental consent below the national age threshold (13 to 16)
UK Children's Code	UK	Any online service likely to be accessed by children	15 design standards, high-privacy defaults, data minimisation
COPPA	US	Online service directed to, or with actual knowledge of, under-13s	Verifiable parental consent, retention limits, security programme
Online Safety Act 2023	UK	Services children can access that carry certain content	Highly effective age assurance, child-safety duties

The pattern that trips boards up: these regimes test for likely access, not stated intent. A company can decide its product "isn't for children" and still owe every one of these duties because children turn up anyway.

What does GDPR Article 8 require for children's data?

Article 8 governs consent when an online service is offered directly to a child. The default age of valid consent is 16. Member states can lower it, but not below 13. So the line moves depending on where your user sits.

• Ireland, the Netherlands and Germany set the threshold at 16.
• France sets it at 15.
• The UK (under UK GDPR), Spain, Sweden and Denmark sit at 13.

Below the national threshold, you need consent given or authorised by the holder of parental responsibility. Article 8 also says the controller must "make reasonable efforts to verify" that consent, "taking into consideration available technology." That phrasing matters. It doesn't demand perfect verification. It demands a proportionate, defensible effort that you can show a regulator.

There's a trap in the verification step itself. Age checks can pull in more data than the underlying service ever needed, which breaks data minimisation while trying to satisfy consent. The fix is to verify age without building a new identity database: estimation over hard identification where the risk profile allows it, and deletion of verification data once its job is done.

One more thing Article 8 doesn't do: it doesn't bless profiling a child just because a parent clicked yes. Automated decisions and behavioural profiling that affect children carry their own scrutiny under Article 22 and Recital 71, which discourages profiling children for marketing.

What is the UK Children's Code and who does it cover?

The Children's Code, formally the Age Appropriate Design Code, is a statutory code from the Information Commissioner's Office. It applies to any online service "likely to be accessed by children" in the UK. Not aimed at children. Likely to be accessed by them. That wider test is the point.

The Code sets 15 standards. The ones that bite hardest for an AI product:

• Data minimisation. Collect and keep only the minimum data needed for the part of the service a child is actively and knowingly using.
• High-privacy defaults. Settings default to high privacy unless there's a compelling reason otherwise. Geolocation off by default. Data not shared by default.
• No detrimental use. Don't use children's data in ways shown to be harmful to their wellbeing.
• Profiling off by default. Behavioural profiling switched off unless you can justify it and protect the child.
• No dark nudges. Don't use design techniques that push children to weaken privacy settings or hand over more data.

The "best interests of the child" runs through every standard as the primary consideration. For an AI system, that reframes design questions. A recommendation engine tuned purely for engagement, pointed at a 12-year-old, sits on the wrong side of this Code. The ICO can fine up to 4% of global annual turnover for breaches of the underlying data protection law.

How does COPPA's 2025 update change the rules?

COPPA is the US regime, enforced by the Federal Trade Commission. It covers operators of online services directed to children under 13, or those with actual knowledge they're collecting data from under-13s. The core duty has always been verifiable parental consent before collection.

The FTC finalised the first major rule update in over a decade. The amended Rule took effect on 23 June 2025, with most compliance obligations due by 22 April 2026. The changes that matter for AI builders:

• Biometric and government identifiers are now personal information. Voiceprints, facial patterns, fingerprints and gait data fall squarely in scope. That pulls a lot of AI feature-extraction directly under COPPA.
• Separate consent for third-party disclosure. Operators need separate verifiable parental consent before sharing a child's data with third parties for targeted advertising. Consent to use the service no longer covers downstream sharing.
• Written data retention policy required. You must set out what you keep, why, and for how long, and you can't hold children's data indefinitely "just in case."
• Written information security programme. A documented programme, not an informal practice.

If you train or run models on children's voice or image data, the biometric expansion is the line item to brief your board on first.

What does the Online Safety Act mean for age assurance?

The Online Safety Act 2023 added a UK duty that's separate from data protection: keep children away from content and services that aren't appropriate for them. The mechanism is age assurance, and Ofcom set the bar.

Ofcom's final guidance calls for "highly effective age assurance." A method counts as highly effective only if it meets all four criteria: technical accuracy, robustness against circumvention, reliability and fairness. Self-declaration, the tick-box "I am over 18," doesn't clear that bar. Ofcom's non-exhaustive list of acceptable methods includes facial age estimation, photo-ID matching, open banking and digital identity services.

Enforcement is live. Ofcom can act on breaches of the Protection of Children Codes from 25 July 2025, with penalties up to £18 million or 10% of qualifying worldwide revenue, whichever is higher. By February 2026 it had opened investigations into more than 90 services and issued its first fines under the regime.

There's a tension to manage here. Strong age assurance can mean collecting sensitive data (a face scan, an ID document) from the very users you're trying to protect. The way through is proportionality and minimisation: pick the lightest method that clears Ofcom's bar for your risk level, process it on-device or via a certified provider where you can, and don't retain what you don't need. That brings the Online Safety Act back into line with everything the Children's Code and GDPR already ask.

What should businesses actually do?

Strip away the regime-by-regime detail and the practical work converges on the same short list. This is the agenda for a legal, compliance and data review.

1. Run a likely-access assessment. Decide honestly whether children can reach your product, on the "likely to be accessed" test, not your marketing intent. Document the conclusion either way. This single step decides whether the rest applies.
2. Map every flow of children's data. Where it's collected, why, where it goes, how long you keep it. AI training data and inference logs included. You can't minimise what you haven't mapped.
3. Set defaults to high privacy. Geolocation off, profiling off, sharing off, until there's a documented reason otherwise. This satisfies the Children's Code and reduces COPPA and GDPR exposure at the same time.
4. Choose proportionate age assurance. Match the method to the risk. Verify age without standing up a new identity database, and delete verification data once it's done its job.
5. Get consent right per jurisdiction. Parental consent below the national age line, separate consent for third-party sharing under COPPA, and reasonable verification effort you can evidence.
6. Write the policies down. Data retention policy, security programme, and a Data Protection Impact Assessment for the AI processing. A DPIA is effectively mandatory where you're processing children's data at scale or profiling them.
7. Constrain the model, not just the form. Apply minimisation and profiling limits to what the AI does with the data, not only to what the sign-up form collects. The model is where the risk concentrates.

Privacy-preserving techniques help with the technical side of this work. Synthetic data done correctly, on-device processing and strict retention limits all reduce how much real child data ever needs to move. The technical requirements for child-safe AI design sit alongside this governance layer. And if you operate in the EU, the EU AI Act compliance picture by industry adds a further layer where children's services count as higher risk.

Frequently asked questions

Does GDPR Article 8 set the age of consent at 13 or 16?

Both, depending on the country. The default in Article 8 is 16. Member states can set a lower age, but not below 13. France sits at 15, the UK and Spain at 13, Ireland and Germany at 16. If you serve users across the EU, you apply the relevant national threshold for each, not a single line.

Does COPPA apply to a UK or EU company?

It can. COPPA reaches operators that direct services to US children under 13 or knowingly collect their data, regardless of where the company is based. If US under-13s can use your product, the amended COPPA Rule applies, with most obligations due by 22 April 2026.

Is "I am over 18" enough for age assurance?

No, not under the Online Safety Act. Ofcom's standard is highly effective age assurance, which a self-declared tick-box fails. Acceptable methods include facial age estimation, photo-ID matching and open banking. The duty has been enforceable since 25 July 2025.

What's the single biggest mistake companies make here?

Assuming the rules don't apply because children aren't the target audience. The Children's Code and the Online Safety Act both test for likely access, not intent. A product "not meant for kids" still owes the full set of duties if children can and do use it.

The bottom line

The hard part of children's data protection in AI isn't reading the law. It's accepting that the law applies to you when you didn't plan for it. Most companies that end up under investigation didn't set out to process children's data. They built a product, children reached it, and the obligations were already running.

My view: treat the "likely to be accessed by children" test as the first question in any AI product review, not a footnote in a privacy policy. Get that judgement right and the rest is disciplined execution: map the data, minimise it, default to high privacy, verify age proportionately, write it all down. Get it wrong, and you're explaining to a regulator why you never asked the question. The data minimisation principle that runs through every one of these regimes is also, conveniently, the cheapest insurance against all of them. Collect less, keep it shorter, and most of the risk simply isn't there to manage.

More in VerityAI's protecting children's health data in AI.

If you want support with this, VerityAI offers responsible AI governance.