The EU KIDS Act: what your product would have to do

21 September 2026

On 17 September 2026, the European Commission proposed an EU KIDS Act. It would regulate how age is established online, set an EU-wide minimum age of 15 for social media accounts, and impose binding safe-design rules on social networks, video-sharing platforms, online games, software application stores, and AI companions. It would apply to your product if you offer one of seven named kinds of services to users in the European Union (small companies not excluded). As it stands this is a proposal: it doesn’t bind anyone yet and you should expect some changes. However, it’s worth taking note if your product can reach children, because the direction of travel is clear and almost every obligation impacts how and what you build.

What the Commission proposed

The Commission put forward a draft Regulation, titled the “Keeping Internet Digital Spaces Accountable and Trustworthy” or “KIDS” Act. It would harmonise a minimum age for social media accounts, impose design requirements on services minors can reach, and set rules for how a user’s age may be established.

Much of the substance is not new. The Commission’s current Guidelines on measures to ensure a high level of privacy, safety and security for minors online under the Digital Services Act (“DSA”) already set out most of the safe-design measures as guidance. The current proposal would convert those into binding text and broaden their applicability. Where such soft law is being hardened, the direction is settled even if the exact wording is not.

The same obligations are arriving through other channels too. Several will bind you before any new EU Regulation will. There are 17 countries in the European Union now independently legislating on minors’ access to online services. Application store policy and procurement questionnaires will also move faster than the EU legislature. Seek out the common denominators to set your baselines, and understand differentiators to make architectural decisions.

Is your product in scope?

The scope is determined based on seven kinds of service and a feature test. For many software businesses, the honest answer is that it’s not applicable.

The seven: social networking services, video-sharing platforms, software application stores, online games, operating systems, AI companions, and general conversational chatbots. The KIDS Act would apply if you offer the service to users in the Union wherever you’re established. 

Carve-outs cover not-for-profit encyclopaedias and research repositories, educational services run by or for schools, open-source development platforms, work done solely for scientific research, and systems public authorities build for their own use.

Small companies get no relief. Micro and small enterprises would be in scope on the same terms as everyone else. The only size-based concession spares them a single post-market monitoring duty attaching to AI companions.

The chatbot definition is narrower than the headlines suggest. It applies to general-purpose assistants a user can talk to about anything. The KIDS Act excludes systems whose conversational functionality is limited to a specialised service, task or pre-defined set of functions. Customer service, business operations, technical support, transactional, educational, information retrieval, industrial and manufacturing applications are named explicitly. So a support bot on your SaaS product would sit outside it. A general assistant would be in scope.

The minimum age would be triggered by features, not by what you call your product. The under-15 rule would apply where a service has any one of five properties. That includes real-time transmission to an indeterminate audience, contact between users who are not already connected, a recommender built on profiling, or a recommender that suggests new contacts or out-of-network content. It also includes features intended or reasonably foreseeable to enable uninterrupted consumption, incentivise interaction, or send automated notifications prompting a user to return.

What you would have to build

As envisaged, almost every substantive obligation in the KIDS Act imposes product specific design or engineering work. Grouped by where they land in the product:

Safe design defaults. Geolocation and tracking, microphone and camera access, contact recommendations, contact synchronisation and push notifications would all be off by default for minors. They should be changeable only for users over 15 who had been clearly informed and had explicitly agreed.

Underneath the above sits a harder requirement: you need to design to offer a minor-safe experience by default and unlock the adult configuration only once age assurance returns an adult signal. The safe build becomes the base case and the adult experience becomes a conditional unlock. That is a design and architecture change, not a settings change.

The scheduler needs to know something it did not need to know. Autoplay without effective interruptions would be prohibited, as would notifications not triggered by the user’s own activity, rewards for sharing or live transmission, and streak mechanics that penalise a lapse. You would also have to ship time-limiting and interruption features that protect core sleep and school hours. That means your notification scheduler would need the user’s local time and some model of their school day.

Ranking signals, weighted and resettable. Explicit user-stated preferences would carry primary weight and implicit engagement-based signals would be off by default. Data collected outside the service should not feed a recommender system at all. Learned preferences would need a reset control, and at least one non-profiling feed would have to be available.

A particularly challenging requirement: your ranking metrics would have to capture quality, safety and mental health outcomes for minors for evaluation. That changes what your ranking team optimises against and obliges you to show the change.

Interface states, shown and hidden. Other users could not initiate direct contact with a minor without prior approval, minors would be excluded from contact recommendations, and group adds would require explicit agreement. A minor’s content would be invisible to non-connections by default and to logged-out users entirely. Screenshots and downloads of it by other users would have to be blocked, and minor-hosted live streaming would be off by default.

Money, made legible. A minor would have to be told in real time that a transaction is a transaction, virtual currency would have to display its value in the currency of the country where the minor lives, and variable reward mechanics (loot boxes) would be prohibited.

A test that passes or fails, with evidence behind it. If you offer AI companions then you could not use design features that are likely to create emotional dependency. You would need to run evaluation and testing for risks to minors before and after release. A companion sits inside a social product or a game would not be allowed to auto-activate, be displayed prominently or pushed at minors. It should be capable of being switched off at any time.

A data field with a retention rule and a deletion trigger. For the minimum-age rule you would have to use a certified EU age verification solution rather than a vendor of your choosing. Self-declaration would not count as age assurance. Operating system providers would have to pass an age signal to you with the user’s consent, which will put a platform-level token in your design space whether or not you planned for one.

Additional limitations would apply to the data you rely on for age verification. Whatever you use for age verification cannot identify, locate, track, target or profile the user. It may not be combined with any other data you or a third party holds, and would have to be zero-knowledge. The only thing you could retain is a bare age signal at account level, to avoid re-checking.

The Commission’s own impact analysis recognizes that technical and practical circumvention will remain possible. So the risk is funding development time on a control a determined 14-year-old can still defeat. Track platform support and explore options to procure the remaining logic before building anything!

Timelines. You would have six months from the date of application to establish whether existing account holders are over 15. You’d have to disable the accounts of those who are not and those whose age you cannot establish. You’d be able to skip verification where you can already establish with high confidence that a holder is 15 or over based on account age or a linked payment instrument. That might change a six-month project to a six-week one.

The largest designated platforms would be subject to two additional duties: notifying a compliance plan to the European Commission and commissioning an independent audit of it.

How this would be enforced, and when

Supervision
Enforcement is envisaged to align with structures that already exist. So the authority supervising you would be the one that already supervises you under existing laws and regulations:

  • as a social network, video-sharing platform, gaming platform or application store, you would be supervised by the Digital Services Coordinator of the EU country where you have your main establishment, or by the Commission instead if you are designated a very large online platform;
  • as a provider of an AI companion or general conversational chatbot, you would be supervised under the AI Act, by a national market surveillance authority or by the Commission’s AI Office;
  • as a provider of a game that is not a platform, you would be supervised by an authority designated in the EU country where you have your main establishment;
  • on every route, data protection authorities would supervise the age-assurance processing, with fines available under the General Data Protection Regulation

Penalties would reach 6% of worldwide annual turnover on the DSA and AI Act routes, with data protection fines available on top. A fast-track procedure, with preliminary findings due within 30 working days, would apply only to the cases the Commission handles itself.

Note that if you have no establishment in the European Union, you would have to appoint a legal representative in a country where you offer the service and that would largely decide which regulator you fall under.

Timelines
Treat the date of provisional political agreement between the Parliament and the Council in trilogue as a marker in your calendar. That ends the closed negotiation in which the final text is settled. I would treat that as the trigger to commit engineering time.

The final regulation would enter into force 20 days after publication in the Official Journal. It is envisaged to apply six months after that, which is short (the DSA allowed 15 months)! That is deliberate, because the Commission wants harmonised rules in place before national rules multiply.

What I would do this quarter

I would spend it establishing facts about your own product rather than interpreting a text that is going to move.

  1. Run the scope test against the service definitions and the chatbot question. Capture your reasons, so that a change in the text does not mean starting from scratch.
  2. Work through the five feature conditions for the minimum age. Any one of them puts you in the strict regime and that has a downstream impact on your roadmap.
  3. Inventory what is switched on by default for a 14-year-old. That is likely to require reviewing your code, which even with help of AI, will take you some time. It’ll be well spent!
  4. Separate your recommender’s signals into (i) explicit and implicit; and (ii) on-platform and off-platform. You will need that to be able to meet the ranking requirements otherwise.
  5. Establish whether you can already age-assure your existing users with confidence. Your ability to do so or not will affect your planning.
  6. Manage expectations with your customers if you sell into in-scope businesses. Compliance is co-produced: your customer would carry the regulatory liability and you would carry the functionality that makes satisfying it possible. Do this before the first request for proposal arrives with these requirements in an annex.

Why this is worth building before the text is final

If your product is in scope, compliance will be a funded workstream with owners and release dates across your product team. Age safe products set feature and design objectives. A default setting is a value in a config file. A notification window will rely on a scheduler with awareness of user’s timezone. Compliance will not be achievable through a policy document. Teams that treat compliance as a policy exercise will discover the difference under a deadline. 

I would go further. Don’t read these obligations as one Regulation that may or may not pass in this form, but as a specification of what the European market is starting to expect from consumer software. 17 national legislatures, two more mature non-EU regimes (Australia and the UK), application store policy and procurement questionnaires are already converging on the same requirements. The Commission has now written down in unusual detail what “safe for minors” is going to mean.

Products that can demonstrate that they are “safe for minors” will sell into that market. Products that cannot will face commercial resistance and need to retrofit against an unusually short deadline.

Sources

FTC Announces Additional Payments to Consumers Stemming from FTC’s Amazon Prime Settlement

EDPB harmonises fining methodology and adopts final DSA-GDPR guidelines