Voice AI and the Children's Code: Under-18 Callers

An inbound voice agent cannot see who is calling. It hears a voice, matches an intent, and starts processing personal data before anyone has confirmed how old the caller is. In education, retail, ticketing, leisure, and parts of healthcare, a meaningful share of those callers are under 18. That is not a hypothetical edge case. It is the ordinary reality of a phone line that anyone can dial.

Most enterprise teams assume the Information Commissioner's Office (ICO) Children's Code is a problem for apps and websites, not for a phone number. For a traditional phone line, that instinct was broadly right. For modern voice AI, it is out of date, because the channel underneath your agent has changed and the ICO scope test has moved with it. The load-bearing question is no longer "is this a website?" It is a precise legal test with several limbs, and the answer for a given deployment can genuinely go either way.

This guide walks the actual test. It covers when internet-based voice puts you in scope, when it does not, what the Data (Use and Access) Act 2025 added on top, how the lawful basis and profiling rules tighten when the caller could be a child, and what proportionate age assurance looks like on a channel where you cannot show a date-of-birth screen.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. For a scoping and design assessment before you go live, see DATS, our five-stage AI consulting system.

Does the Children's Code apply to a voice AI phone line?

It can, and for most enterprise voice AI the honest answer is "quite possibly yes." The Children's Code is the ICO's statutory Age Appropriate Design Code, made under section 123 of the Data Protection Act 2018. It applies to "relevant information society services which are likely to be accessed by children" in the UK. Traditional telephony historically fell outside it, but internet-based voice is treated differently, so the channel your agent runs on now matters to the answer.

The trap is treating "phone line" as a synonym for "out of scope." It is not. The Code never turned on whether a service felt like a phone call; it turned on a definition of an information society service, and on whether children are likely to reach the service. A voice AI deployment can satisfy both, which means the Code, and the 15 standards inside it, can bind the design of your agent just as they bind a mobile app.

Why does internet-based voice change the answer for voice AI?

Because the scope test asks whether a service is delivered "by electronic means," and that specific limb is what used to keep ordinary telephone lines out. Almost every enterprise voice agent runs over internet-based voice, or VoIP, routed through carriers and platforms such as Twilio rather than a legacy PSTN circuit. That is a different transport layer, and the ICO addresses it directly in its guidance on the services the Code covers.

"Traditional voice telephony services are not relevant ISS. This is because they are not considered to be 'delivered by electronic means'. This differs from internet based voice calling services (VOIP) which are within scope as they are delivered over the internet by electronic means."

That sentence settles one thing only: the transport question. It removes the historical excuse that a phone line is not delivered by electronic means. It does not, on its own, put your voice line in scope, because "by electronic means" is a single limb of a four-part definition. Reading the quote as "voice AI is in scope, full stop" is the most common mistake here, and it is wrong in both directions: it over-claims for lines that fail another limb, and it lulls teams who assume the whole thing is about apps.

What is the full test for whether a voice line is in scope?

An information society service is defined as "any service normally provided for remuneration, at a distance, by electronic means and at the individual request of a recipient of services." All four limbs must hold, and then a fifth question applies: is the service likely to be accessed by children. VoIP answers the third limb. It says nothing about the other three, and the ICO's own carve-outs turn on them.

The carve-outs are the proof that VoIP is necessary but not sufficient. A voice agent that only books an in-person appointment can fail the "at a distance" limb, because the underlying service is delivered face to face. A non-commercial public service can fail "normally provided for remuneration." Processing by a competent authority for law enforcement purposes is outside the Code because it is outside the scope of the UK GDPR itself. So a line can be VoIP and still out of scope, which is exactly why you run the whole sequence rather than stopping at the transport layer.

The practical discipline is to make this a written decision, not an assumption. If you conclude your line is in scope, the 15 standards become design requirements. If you conclude it is out of scope, you still owe a defensible record of why, which is the same evidence an ICO reviewer would ask to see. Our AI placement diagnostic treats this scoping call as a gate before deployment, not a paragraph in a policy nobody reads.

When is a voice line "likely to be accessed by children"?

The test is deliberately broad. The ICO's position is that a service is likely to be accessed by children when the possibility of that happening is "more probable than not," and the Code applies even to services that are not aimed at children, provided under-18s are nonetheless likely to use them.

A child, for this Code and under the UNCRC, is anyone under 18, not under 13. So the question is not "did we market to teenagers," it is "will teenagers realistically call this number."

For a retailer's order line, a cinema or venue booking line, a school or college enquiry line, or a utility with family accounts, the realistic answer is yes. Where you judge that children are not a likely part of your caller base, the ICO expects you to "document and support your reasons for your decision," using evidence such as who your service is for and how it is accessed. That written judgement, revisited when your traffic changes, is the artefact that protects you. It connects directly to the data protection impact assessment the Code already expects, and it belongs in your record of processing activities.

What did the Data (Use and Access) Act 2025 change for children's data?

It raised the bar for services already in scope, without widening what counts as in scope. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, its main data protection reforms took effect on 5 February 2026, and the remaining provisions were in force by 19 June 2026.

Section 81 amends Article 25 of the UK GDPR, on data protection by design and by default, to add an express duty on controllers providing information society services likely to be accessed by children.

That new duty requires you to weigh "children's higher protection matters," including how best to protect and support children using the service and the fact that children merit specific protection with regard to their personal data. The ICO's guidance on the Act frames it plainly: if you provide an online service likely to be used by children, the Act "explicitly requires you to take their needs into account when you decide how to use their personal information," and you should already satisfy this if you conform to the Age Appropriate Design Code. In short, the Act puts the Code's design expectations onto a statutory footing. It does not make a voice line in scope that was not already, so the scoping test above still comes first.

How does lawful basis and profiling change when the caller could be a child?

The lawful basis you leaned on for adults gets more fragile. Under Article 8(1) of the UK GDPR, where you rely on consent for an information society service, "the processing of the personal data of a child shall be lawful where the child is at least 13 years old," and below 13 you need consent from the holder of parental responsibility.

Consent obtained mid-call from someone who may be a child is weak, so many controllers move to legitimate interests or contract, and your organisation as controller, not the voice vendor as processor, owns that decision. But children merit specific protection, which tips the legitimate interests balancing test towards the child and against your commercial purpose.

Profiling is where voice AI teams most often trip. Standard 12 of the Code says profiling should be off by default for children, and Standard 5 forbids using their data in ways shown to be detrimental to their wellbeing. That constrains the exact behaviours a voice platform makes easy: scoring a caller for upsell, feeding call outcomes into marketing segments, or letting the model make a consequential decision without a human check. If your agent takes automated decisions about a young caller, read it alongside the Article 22 rules on automated decision-making, and revisit your legitimate interests balancing test with the child as the affected party. The organising principle sits in Standard 1: the best interests of the child are the primary consideration when you design the service.

The same design logic runs through our AI operating model consulting, where lawful basis and profiling controls are set once and enforced across every agent rather than rebuilt per line.

What is the best way to make a voice AI deployment Children's-Code-ready?

There is no single "best" configuration, because the right answer depends on whether children should reach your line at all. The strongest position is often prevention rather than accommodation: if a service is genuinely adult-only, the ICO's own view is that your focus should be on preventing access, in which case the Code does not apply, and a hard age gate can beat elaborate child-friendly design.

Where children legitimately do call, "best" means a documented scoping decision, proportionate age assurance, minimised data, default-off profiling, and a DPIA that names children as a risk group.

Proportionate age assurance is the part people over-engineer. You cannot show a date-of-birth screen on a call, and Standard 3 asks for measures appropriate to the risks, not maximal collection. Standard 8 pushes the other way, towards data minimisation, so demanding identity documents to verify age can itself breach the Code. A layered approach works better: self-declared age at the start, behavioural signals during the call, and an escalation path to a human when the answer is uncertain, all sized to how sensitive the transaction is. Platforms such as Vapi, Retell AI, Bland AI, Synthflow, PolyAI, and ElevenLabs give you the voice layer, but none of them make the scoping decision, set the lawful basis, or configure default-off profiling for you. That governance is yours, and it is where Dilr Voice and the wider DATS five-stage methodology concentrate, reflecting our approach to placing AI inside enterprise systems. For the full regulatory picture, the UK and EU voice AI compliance guide maps how the Children's Code sits alongside the rest of your obligations.

Does the Children's Code apply if most of our callers are adults?

Yes, potentially. The Code applies wherever children form a substantive and identifiable part of your user base, or are otherwise likely to access the service, even when they are a minority of callers and even when you never targeted them. An overwhelmingly adult order line still triggers the Code if teenagers realistically call it.

The safe path is to make the "likely to be accessed" judgement in writing, support it with evidence about your callers, and review it whenever call patterns shift, exactly as you would maintain any other ICO audit record.

What happens if you get children's call data wrong?

The consequences are real and quantified. On 4 April 2023 the ICO fined TikTok £12.7 million for allowing an estimated 1.4 million UK children under 13 to use the platform without parental consent between May 2018 and July 2020, having originally proposed a £27 million penalty.

Beyond the fine, the reputational cost of mishandling children's data is severe, and it is the kind of finding that surfaces in every future procurement. Getting the scoping and design right before launch is far cheaper than defending the decision afterwards, which is the whole argument for treating it as a vulnerability and safeguarding question up front.

Want to pressure-test your own line? Try Dilr Voice in production, book an AI placement diagnostic, read our guide to subject access requests over call recordings, or browse the full voice AI compliance library.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.