On 2 March 2026 the Department for Science, Innovation and Technology published a national consultation titled Growing up in the online world. 1 The document covers social media, gaming, screen time, and AI chatbots. Questions 26 through 30 deal specifically with generative AI. DSIT is considering whether AI chatbots should fall within scope of the Online Safety Act 2023. 2
Most responses will come from platforms defending their existing safety features, parents demanding bans, and advocacy groups calling for restrictions. Hypereum responded because the principles that make AI safe for children are the same principles that make AI safe for everyone. The architecture does not care about the user’s age.
Growing up in the online world: a national conversation
The question DSIT asked
The consultation asks five questions about AI chatbots. What benefits do they offer children. What risks exist. Should age restrictions apply. Which features should be restricted for children. What would effective safety look like.
The framing matters. DSIT is not asking whether AI chatbots are safe. It is asking how to make them safe, which presupposes they will continue to exist. The responses will shape legislation. On 16 February 2026 the Prime Minister announced new legal powers to act on the consultation findings without waiting for new primary legislation. 3
Sixty-four per cent of 9 to 17 year-olds in the UK now use AI chatbots, according to Nominet polling cited in the consultation document itself. 4 The question of whether children will interact with these systems is already settled. They do.
The wrong layer
Most approaches to AI safety for children operate at the wrong layer of the stack.
Content filtering sits at the output layer. It scans what the model generates before delivering it to the user. Content filters are bypassable. Prompt injection, adversarial inputs, jailbreaks. A determined teenager can get past a content filter in minutes. There is a growing body of published research on this. Building child safety on content filtering alone is building a lock that only works when nobody tries to pick it.
Age verification sits at the access layer. It checks who the user is before granting access. Self-declaration is meaningless. Document verification adds friction but does not change what the system does once access is granted. A verified 16-year-old interacting with an architecturally unsafe system is still interacting with an architecturally unsafe system.
Both approaches are necessary. Neither is sufficient.
The question is not whether a child should be allowed to use an AI chatbot. The question is whether the chatbot is engineered to be safe for anyone.
The third layer is the architecture itself. Safety constraints enforced at the system level. Not as a filter on the output. Not as a gate on the input. As a boundary on what the system can do.
Architecture as regulation
We proposed three principles in our response. All three are implemented in Hivemind today.
Policy-governed execution. If the policy says “do not generate sexual content in conversations with users under 18,” that constraint should be enforced architecturally. Not dependent on a content classifier that might miss an edge case. Not reliant on a prompt prefix that can be overridden. Enforced at the system level, where agents operate within their policy boundary because the architecture prevents anything else. The agent does not choose to comply. It cannot choose otherwise.
Tamper-evident audit trail. When a harmful interaction occurs, the full decision chain must be reconstructable. What was the input. What did the model generate. What safety checks were applied. What was delivered to the user. Without this, harmful interactions cannot be analysed, attributed, or prevented in future.
Every block contains the hash of the previous. Change one, the chain breaks.
Most AI chatbot architectures deployed in the UK in 2026 do not produce tamper-evident records. The interaction happens, the response is delivered, and if a child is harmed, there is no verifiable chain of evidence showing what happened and why. Logs exist. Tamper-evident logs do not.
Fail-closed design. If the safety controls are unavailable (the policy engine is down, the content filter is unreachable, the audit system is offline) the system must halt. Not degrade gracefully. Not continue with reduced checks. Halt.
A fail-open AI chatbot that loses its safety controls during a conversation with a child continues generating unrestricted output. The child does not know the safety controls are down. The parent does not know. Nobody knows until harm has already occurred. This is the default behaviour of most deployed systems. EU AI Act Article 15 requires accuracy, robustness, and cybersecurity for high-risk AI systems, 5 but most chatbot architectures would not satisfy the robustness requirement if their safety layer failed silently.
Why an AI infrastructure company responded
Hypereum’s founder is 17. By this consultation’s own definition, a child. He is also the director of a UK-registered company building AI orchestration infrastructure for regulated industries.
The engineering perspective is underrepresented in these conversations. Most respondents will argue about age limits and feature restrictions. Very few will propose architectural requirements.
Hypereum is an early-stage company. One founder. One product in development. The principles proposed are not early-stage.
The engineering perspective is underrepresented in policy conversations about AI safety. Most respondents will argue about age limits. Very few will propose architectural requirements.
What happens next
DSIT will publish a summary of responses. The government has committed to acting on the findings. The Prime Minister’s February announcement indicates a willingness to use existing powers rather than wait for new primary legislation.
Hypereum’s name will appear in the published list of respondents. The principles we proposed (policy-governed execution, tamper-evident audit trails, fail-closed design) are not theoretical. They are implemented, tested, and running. Whether the regulatory framework will require them is a different question, and one we cannot answer.
The consultation closes on 26 May 2026. The architecture has been ready for longer.
