Child-Safe AI Design: The Technical Requirements, Explained

Child-safe AI design means the protective settings are on by default, the system collects the least data it can, age is established with confidence proportionate to the risk, and a child can understand what the service does with their information. In UK practice the standard is set by the ICO's Age Appropriate Design Code (the Children's Code) and its 15 standards, with the Online Safety Act 2023 adding duties on age assurance and harmful content. This is a board-level design question now, not a feature request, because the obligations are live and the regulators are active.

The good version of this is not complicated to describe. A child opens your product and the high-privacy settings are already on. Geolocation is off. Profiling is off. The service asks for the minimum it needs to work, and it explains itself in language a child can follow. Nothing nudges the child into giving up more. That is what "child-safe by design" looks like in production, and the rest of this piece breaks it into the technical decisions that get you there.

What does "child-safe by design" actually require?

The Children's Code sets 15 standards for any online service likely to be accessed by under-18s in the UK. It applies whether or not children are your target market. "Likely to be accessed" is the test, and it catches a lot of general-purpose AI products that assumed they were adult-only.

The 15 standards, in order, from the ICO's code standards:

#	Standard	What it asks of the build
1	Best interests of the child	Make the child's interests the primary design consideration
2	Data protection impact assessments	Run a DPIA covering different ages and development stages
3	Age appropriate application	Apply protections by age band, or apply them to all users
4	Transparency	Privacy information in clear language suited to the child's age
5	Detrimental use of data	Don't use children's data in ways shown to harm wellbeing
6	Policies and community standards	Uphold your own published terms
7	Default settings	High privacy by default
8	Data minimisation	Collect and retain the minimum needed
9	Data sharing	Don't disclose children's data without a compelling reason
10	Geolocation	Off by default; visible when active
11	Parental controls	If you track or monitor, make it obvious to the child
12	Profiling	Off by default
13	Nudge techniques	Don't nudge children into weakening their own protections
14	Connected toys and devices	IoT toys meet the same standards
15	Online tools	Give children easy tools to exercise their data rights

Read together, these standards are an engineering spec, not a values statement. Each one maps to a default, a config flag, a data-flow decision, or a UI pattern your team can implement and test.

What does data minimisation look like in code?

Data minimisation (standard 8) is the cheapest control to get right and the most expensive to retrofit. The rule is plain: collect only what the feature needs, keep it only as long as you need it, and don't repurpose it.

In a model pipeline that means a few concrete choices:

• Strip identifiers at ingestion, not later. If a feature works on aggregate or on-device signals, the raw child data never needs to leave the device.
• Set retention windows per data type and enforce them with a job, not a policy document. A deletion that depends on someone remembering is not a control.
• Separate the data that trains or tunes a model from the data that operates it. Children's interactions should not silently become training data without a lawful basis and a DPIA that considered it.

On-device and edge processing help here because they shrink the volume of child data that ever transits your systems. The point is the smaller surface, not the technology label.

How do you establish age without collecting more data?

Age assurance is the standard that trips most teams up, because it pulls in two opposite duties. The Children's Code says establish age with a certainty proportionate to the risk. Data minimisation says don't hoover up identity documents you don't need. Both are right, and the resolution is risk-tiering.

Low-risk processing can rest on lighter age signals. Higher-risk features, or content the law restricts, need stronger methods. Under the Online Safety Act, Ofcom's guidance sets a bar of highly effective age assurance for the riskiest content, judged against four criteria: technical accuracy, robustness, reliability, and fairness.

What clears that bar and what doesn't:

Approach	Ofcom's view
Facial age estimation	Can be highly effective
Photo-ID matching	Can be highly effective
Mobile-network operator checks	Can be highly effective
Digital identity services	Can be highly effective
Self-declaration of age	Not highly effective
A disclaimer that users must be 18	Not highly effective

Two design notes that keep you on the right side of both regimes. First, prefer age estimation over identity verification where the risk allows it, so you confirm a band rather than collect a passport. Second, whatever method you pick, the data it generates is itself children's data and falls under every standard above. Age assurance is not a loophole out of data minimisation.

The legal floor underneath all of this: under UK GDPR Article 8 and section 9 of the Data Protection Act 2018, a child in the UK can consent to an information society service from age 13. Below that, you need consent from someone with parental responsibility, and you have to make reasonable efforts to verify it.

Which defaults and content controls have to ship on day one?

Defaults are where the Children's Code is least flexible, and rightly so. A protection that a child has to find and switch on is a protection most children never get.

The non-negotiable defaults:

• High privacy settings on by default (standard 7).
• Geolocation off by default, and a visible signal whenever location is in use (standard 10).
• Profiling off by default, including the recommendation and personalisation logic that drives most AI products (standard 12).
• No nudge patterns that push a child toward lower privacy or more disclosure (standard 13).

That last one matters more for AI than for static services. A conversational system that gently encourages a child to "tell me more about yourself" to improve its answers is a nudge technique, even when the intent is helpfulness. Content controls and recommender logic need the same scrutiny. The Online Safety Act's Protection of Children Codes, in force since 25 July 2025, expect services likely to be accessed by children to assess and mitigate the risk of harmful content, with recommender systems named as a specific area to control.

What does transparency mean when the user is a child?

Transparency (standard 4) is not your standard privacy policy in smaller type. It's a separate obligation to explain the service in language suited to the child's age, at the point it matters.

For an AI product that means explaining, in plain terms a child can follow, what the system does with what they say, when a human might see it, and how they get their data back or deleted. Standard 15 then requires the tooling to act on that: a child should be able to exercise their data rights without filing a formal request an adult would struggle with.

This is also where AI systems carry an extra duty of honesty. If a child is talking to a model, the design should not let them believe they're talking to a person. Clarity about what the system is sits at the centre of both the Children's Code's transparency standard and the EU AI Act's rules on AI that interacts with people.

Where does the EU AI Act fit for products that reach children?

For boards with EU exposure, the EU AI Act adds a hard line. Article 5 prohibits AI systems that exploit the vulnerabilities of a person or group due to their age, where the effect is to materially distort behaviour in a way likely to cause significant harm. That prohibition has applied since 2 February 2025, with no grace period.

In design terms, this bans the engagement patterns that target a child's developmental stage to drive behaviour the child wouldn't otherwise choose. An AI toy that pressures a child into purchases is the textbook example. The practical read for product teams: the addictive-by-design and manipulation patterns that the Children's Code discourages, the EU AI Act can flatly prohibit. The Act and the Code point the same direction. Build to the stricter of the two and you clear both.

For a fuller view of how these regimes interact across sectors, our EU AI Act compliance checklist by industry maps the obligations to specific use cases.

Frequently asked questions

Does the Children's Code apply if children aren't our target audience?

Yes. The test is whether your service is "likely to be accessed" by children in the UK, not whether you market to them. General-purpose AI products that assumed an adult-only user base are frequently in scope. The ICO expects you to assess this honestly rather than assume your way out of it.

What's the difference between the Children's Code and the Online Safety Act?

The Children's Code is data protection law, enforced by the ICO, and governs how you handle children's personal data. The Online Safety Act is content and safety law, enforced by Ofcom, and governs protecting children from harmful content and the age assurance behind that. They overlap on age assurance, and a child-facing AI product usually has to satisfy both. The two regulators have published a joint position on how the regimes fit together.

At what age can a child consent to our service in the UK?

Thirteen, under UK GDPR Article 8 and section 9 of the Data Protection Act 2018. Below 13 you need verifiable consent from a holder of parental responsibility. Note this differs across the EU, where the baseline is 16 unless a member state has lowered it.

Is age assurance the same as age verification?

No, and the distinction is a design lever. Verification confirms a specific identity, usually by checking a document. Assurance establishes age or an age band with a confidence level proportionate to the risk, and can often do so with less data, for example through facial age estimation. Reach for the lightest method the risk allows, because the data you collect to check age is itself children's data.

The bottom line

The teams that struggle with child-safe AI are the ones treating it as a compliance overlay bolted onto a finished product. It doesn't work that way. High privacy by default, profiling off, geolocation off, the minimum data collected, age established with proportionate confidence, and an honest explanation a child can read. These are architecture decisions, and they are far cheaper made at design time than retrofitted after an ICO assessment or an Ofcom enquiry.

My view: the 15 standards of the Children's Code are the clearest engineering brief any regulator has handed product teams in years. Most of the hard thinking is already done. The standards tell you which defaults to ship, which data not to collect, and how to talk to the user. A board that treats them as a design spec rather than a legal risk will build better products and sleep better too.

For the data protection side of the same problem, see our companion piece on AI child data protection and GDPR compliance for youth-facing technology.

VerityAI advises boards and engineering leaders on Responsible AI design and the governance behind it. We're a Responsible AI advisory, not a software vendor.

For hands-on help, see VerityAI's responsible AI governance.