Child Safety in AI Products: The Board Accountability Guide

If your AI product can be accessed by children, the board owns the risk. Regulators in the UK and EU now expect a named accountable person, a documented child-risk assessment, and high-privacy defaults that ship by design, not on request. This isn't a developer problem to delegate downwards. It's a governance duty that sits at the top, and the law now writes it that way.

Three frameworks moved in 2025 that change what "due diligence" means for any AI product reaching under-18s. Ofcom's Protection of Children Codes came into force in July 2025. The EU AI Act's ban on AI that exploits children's age took effect in February 2025. The ICO's Children's Code has been enforced since 2021. A board signing off a child-facing AI product needs to evidence all three. Here's the framework to do it.

Who on the board is actually accountable for child safety in AI?

One named person. That's now the legal expectation, not a nice-to-have.

Ofcom's Protection of Children Codes require in-scope services to have a named person accountable for children's safety, with a senior body reviewing the management of that risk every year (Taylor Wessing, April 2025). The NIST AI Risk Management Framework points the same way: its Govern function tells organisations to define clear roles, responsibilities, and delegated authorities for AI risk, documented and understood across the business (NIST AI RMF, Govern).

The pattern holds across every framework that touches this. Accountability has to be a name, a role, and a reporting line, not a committee that meets when something breaks. If your org chart can't answer "who loses sleep when a child is harmed by this product," the governance isn't done.

What the board has to hold:

• A single accountable executive for child safety, named and minuted.
• An annual senior review of child-risk management, in board papers.
• A documented escalation path from product team to board for any child-safety incident.
• Clear delegated authority: who can pause or pull a feature, and how fast.

What does the law now require for AI products that reach children?

Three regimes apply at once if you operate in the UK and EU. Map your obligations against all three, because they overlap but don't substitute for each other.

Framework	What it requires	Who enforces	In force since
ICO Children's Code (UK)	15 standards: high-privacy defaults, data minimisation, no manipulative nudges, profiling off by default	Information Commissioner's Office	September 2021
Online Safety Act 2023 / Ofcom Codes (UK)	Named accountable person, child-risk assessment, age assurance, protection from harmful content	Ofcom	July 2025
EU AI Act, Article 5 (EU)	Bans AI that exploits children's age to distort behaviour and cause significant harm	National authorities	February 2025
NIST AI RMF (voluntary, global)	Govern, Map, Measure, Manage functions; accountability and documentation	Self-adopted	2023

The ICO Children's Code: 15 standards, applied by design

The Children's Code sets 15 standards for any online service likely to be accessed by children, even if children aren't the target audience (ICO Children's Code FAQs). The first standard is the one boards should anchor on: the best interests of the child must be the primary consideration when you design and develop the service.

The standards that bite hardest in AI products:

• High-privacy settings on by default, unless there's a compelling reason otherwise.
• Data minimisation: collect only what the service genuinely needs.
• Profiling off by default. For AI, that means recommendation and personalisation engines start switched off for child users.
• No nudge techniques that push children towards weaker privacy choices. Manipulative design is named and banned.
• Geolocation off by default, with a visible indicator when it's on.

The code is enforced under the Data Protection Act 2018, so a breach carries the same enforcement weight as any other UK GDPR failure.

The Online Safety Act: risk assessment first, then mitigation

Ofcom's children's codes came into force on 25 July 2025, with the first children's risk assessments due by 24 July 2025 (White & Case, 2025). The sequence matters for a board: you assess the risk to children before you ship the mitigation, and you keep the record.

The highest-risk services have to use age assurance that actually works, to keep children away from harmful material while letting adults reach legal content. A service that can't deploy effective age assurance has to assume younger children are present and apply child-appropriate protections to everyone. The penalties give the duty teeth. Ofcom can fine up to £18 million or 10% of qualifying worldwide revenue, whichever is greater (Pinsent Masons, 2025).

The EU AI Act: a hard red line on exploiting children

Since 2 February 2025, Article 5 of the EU AI Act has prohibited 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 (Article 5, EU AI Act). Children are named as a distinct vulnerable group. There's no requirement to prove malicious intent. The effect is enough.

For a board, that reframes design choices that used to be growth tactics. An engagement loop tuned to keep a child watching, a feature that nudges a child to share more data, a reward mechanic built on a child's impulsivity, all sit close to a prohibited practice in the EU now. The 5Rights Foundation put it plainly: AI that exploits children's vulnerabilities is now illegal in the EU (5Rights, 2025).

What review gates belong at the top, not in the product team?

Most child-safety controls are technical and belong with engineering. Four decide whether the product ships at all, so they sit with the board.

Gate 1: the child-risk assessment, before launch. No child-facing AI feature ships without a documented assessment of how it could harm a child and what controls are in place. Ofcom now requires this for in-scope services. Treat it as the entry ticket to launch.

Gate 2: defaults sign-off. The named accountable executive confirms that privacy is high by default, profiling is off by default, and no growth feature relies on a nudge the Children's Code or the AI Act would treat as manipulation. A 20-minute review that heads off a multi-million-pound enforcement risk.

Gate 3: age assurance decision. Someone senior decides how the product knows it's dealing with a child, and what happens when it can't tell. If age assurance is weak, the default is to protect everyone as a child. A commercial call with legal weight.

Gate 4: the annual review. A senior body reviews child-risk management once a year and minutes it. Ofcom expects this. It's also your evidence file when a regulator asks what the board knew and when.

How do you evidence due diligence if a regulator asks?

The honest answer: if it isn't written down and dated, it didn't happen. Regulators and courts work from the record, so build the record as you go.

A defensible evidence file holds:

• The child-risk assessment, dated, with the author and the reviewer named.
• Board minutes showing the named accountable person and the annual review.
• A decision log for every child-safety design choice: what was decided, by whom, on what date, against which standard.
• Records of age-assurance testing and its results.
• A change log showing what was fixed after each review or incident.

The NIST AI RMF makes documentation a core expectation of its Govern function for exactly this reason: roles, responsibilities, and risk decisions have to be documented and understood, not held in someone's head (NIST AI RMF, Govern). The Children's Code requires a data protection impact assessment as one of its 15 standards. Both turn good intentions into evidence a third party can verify.

For the build-side controls, see child-safe AI design technical requirements and the data side in AI child data protection and GDPR. For the broader board view of assessing any autonomous system before it ships, see our AI agent risk assessment executive framework.

Frequently asked questions

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

Yes. The code applies to any service likely to be accessed by children, even if they aren't your intended audience (ICO Children's Code FAQs). The test is access, not intent. If under-18s can reach your AI product, the standards apply.

Who should be the named accountable person for child safety?

A senior executive with the authority to pause or pull a product, not a junior compliance officer. Ofcom's codes expect a named person accountable for children's safety, reviewed by a senior body annually (Taylor Wessing, April 2025). The role needs real authority, or it's a name on a form.

What's the penalty for getting this wrong in the UK?

Under the Online Safety Act, Ofcom can fine up to £18 million or 10% of qualifying worldwide revenue, whichever is greater (Pinsent Masons, 2025). Children's Code breaches are enforced under the Data Protection Act 2018 and carry UK GDPR-level penalties. The reputational cost usually runs ahead of the fine.

How does the EU AI Act differ from UK rules on children?

The EU AI Act sets a hard prohibition. Article 5 bans AI that exploits a child's age to distort behaviour and cause significant harm, with no need to prove intent (Article 5, EU AI Act). The UK rules are more about process and design standards. If you operate in both, you meet the EU red line and the UK process duties together.

The bottom line

Child-safety AI governance has stopped being a values statement and become a documented duty with named owners, review gates, and fines attached. My view: the boards that treat this as a design-stage discipline will move faster than the ones treating it as a legal review at the end, because retrofitting high-privacy defaults and age assurance into a shipped product costs far more than building them in.

The work isn't exotic. A named accountable executive, a child-risk assessment before launch, high-privacy defaults, age assurance that works, and a dated evidence file. Five things. Most of the cost is the discipline to do them in order and write them down. The frameworks already tell you what good looks like. The only open question is whether your board can show its working when someone asks.

This is the kind of work our responsible AI governance handles.