Building an AI product minors can reach

You did not set out to build a product for teenagers. You built a tutoring helper, a Discord bot, a writing tool, a fitness tracker with a chat box in the corner. Sooner or later someone signs up with a birth year that makes them 32, and the questions coming out of that account read like Year 11 homework at 11pm. From that moment a different set of rules applies to you: your model vendor’s, the app store’s, and at least one legislature’s.

The large labs have already been through this and published what they built, which is unusually convenient. This guide takes the pattern they settled on, strips it to the parts a one-person or five-person team can actually implement, and names the rules you are already subject to whether or not you meant to be. It is not legal advice. If you are deploying to a school district, marketing to under-13s, or already holding children’s data at volume, you need a lawyer and a compliance process, and this is the wrong document.

A birthday field is a record, not a gate

Asking a user to type their date of birth and believing the answer is not an age check. It produces a log entry that says you asked. A 14-year-old who wants access subtracts four years, and the subtraction takes about a second.

The alternative OpenAI shipped is prediction rather than declaration. Its age model “looks at a combination of behavioral and account-level signals, including how long an account has existed, typical times of day when someone is active, usage patterns over time, and a user’s stated age” [2]. Stated age is one input among several, not the decision. OpenAI published that description on 20 January 2026 with the rollout already underway, and recorded on 25 August 2026 that age prediction had begun rolling out in the EU [2].

You are not going to build a behavioural age classifier, and you do not need to. What is worth copying is the sentence on that page that costs nothing to implement: “When we are not confident about someone’s age or have incomplete information, we default to a safer experience” [2]. The opposite default is the one you get for free. Unknown age means full access, because full access is the code path that already exists and the restricted one has not been written yet. Which way that default points is the highest-value decision in this guide, and it is a decision rather than a project. OpenAI pairs it with a route back for adults who get caught by it: a selfie through Persona, an identity-verification service, confirms age and restores full access, and users start that process from Settings then Account [2].

The age signal now arrives from the app store

If you ship a mobile app, you no longer have to guess, and in some places you no longer get to. Apple’s Declared Age Range API returns a user’s age category rather than a birth date, and Apple describes it as “a helpful signal about a user’s age” [6]. In Brazil, age categories “will be shared when the user or a parent or guardian (where relevant) agrees to share the age category with you” [6]. For users with new Apple Accounts in Utah as of 6 May 2026, and in Louisiana as of 1 July 2026, age categories are shared with your app when you request them through the API [6]. Apple also began blocking users in Australia, Brazil and Singapore from downloading apps rated 18+ on 24 February 2026 unless they have been confirmed to be adults through reasonable methods, and its own note is that “developers may have separate obligations to independently confirm that their users are adults” [6].

That last clause is the one to read twice. The platform gives you a signal. It does not give you a defence. The obligation stays with you.

Anthropic shows what enforcement looks like on the receiving end. Claude requires all users to be at least 18 years old to create and use an account, and a user whose device app store has identified them as under 18 may be unable to create an account or sign in to an existing one in the Claude mobile app [4]. Anthropic states it does not have access to your app store account information and cannot change it, so a wrongly flagged user has to take it up with Apple Support or Google Play Support [4]. Copy the mechanism if you like, but budget for the support tickets. You will receive complaints about a decision you cannot reverse, from users who have no reason to believe you.

You inherit your model vendor’s age rules

Before any statute applies to you, your API contract does, and the two vendors used as examples here have drawn the line in different places. Claude is 18-and-over for consumer accounts [4]. ChatGPT places anyone whose stated age is 13 to 17, or whom its system estimates to be under 18, into ChatGPT for Teens [1]. If your product is for sixth-formers and your backend is Claude, that gap is your problem to close, not an oversight on Anthropic’s part.

There is a documented path through it. Anthropic’s guidance for organisations that give minors direct access to Claude asks for “age verification systems to ensure only intended users can access the product”, “content moderation and filtering to block inappropriate or harmful content”, “monitoring and reporting mechanisms to identify and address potential issues”, “educational resources and guidance for minors on safe and responsible use”, and its child-safety system prompt where one is provided [5]. It expects compliance with regulations such as COPPA to be clearly stated on the organisation’s website, and it requires that you disclose to your users that they are interacting with an AI system rather than a human [5]. Anthropic reserves the right to audit for compliance, and says non-compliance or high violation rates may result in account suspension or termination [5].

Read that as the shortest specification you will get. It is more concrete than most statutes, it arrived before any regulator asked you for anything, and the stated penalty for ignoring it is losing the account, which for a small product lands harder than a fine.

Oversight that reads the transcript is surveillance, and it fails

The most instructive design decision in ChatGPT for Teens is a thing it refuses to do. A linked parent or guardian can choose when eligible new chats start in study mode, and can set quiet hours that limit access during scheduled times [3]. What they cannot do is read the conversations: “Parental controls do not let a parent or guardian read or monitor the teen’s conversations” [3]. When OpenAI sends a safety notification it “shares only the information needed to help support the teen’s safety” [3], and parents with linked teen accounts receive those notifications in limited high-risk situations [1].

The reasoning is practical rather than principled. A teenager who knows the transcript is readable does not stop having the conversation. They have it somewhere else, on a product with no safeguards at all and no notification path to anyone. Oversight you can see is oversight you route around. So the controls are over the shape of use, when and in what mode, plus an escalation channel for the small number of situations that warrant one. Everything in between stays private enough that the safer product remains the one they actually use.

For your product this translates into a rule about the parent-facing view. Schedules, modes, spend limits and feature toggles are fine. A conversation log is not a safety feature, it is a reason to churn, and it also makes you the custodian of a pile of minors’ private text that you now have to secure, retain and eventually delete under someone’s law.

Block the category in the system, not in the prompt

ChatGPT for Teens applies “age-appropriate model protections and product interventions in higher-risk areas such as self-harm, violence, eating disorders, dangerous activities, and explicit sexual or graphic content” [1]. It then adds three rules that are not about content at all: ChatGPT “should not use romantic language, encourage emotional dependence, or imply that it has feelings or consciousness” [1]. Those three are relationship failures rather than content failures, and they are the ones a general-purpose chat interface produces by default, because warmth and agreement are what the model was trained to supply.

California has since put a version of this in law for companion chatbots. Where a reasonable person interacting with the chatbot would be misled into believing they are interacting with a human, SB 243 requires a clear and conspicuous notification that the companion chatbot is artificially generated and not human [8]. Where the operator knows the user is a minor, the operator must disclose that the user is interacting with artificial intelligence, provide by default a clear and conspicuous notification at least every three hours of continuing interaction reminding the user to take a break and that the chatbot is artificially generated and not human, and institute reasonable measures to prevent the chatbot producing visual material of sexually explicit conduct or directly stating that the minor should engage in sexually explicit conduct [8]. Operators must maintain a protocol for preventing the production of suicidal ideation, suicide or self-harm content, including referring users to crisis service providers [8]. The bill carries a private right of action for damages of the greater of actual damages or 1,000 dollars per violation, annual reporting to the Office of Suicide Prevention begins on 1 July 2027, and it was chaptered on 13 October 2025 [8].

The engineering point is where these rules live. A line in your system prompt saying “never discuss self-harm” is a preference, and a preference stated inside the conversation can be argued with from inside the conversation. Category blocks belong in a classifier on the input and the output, outside the text the user can influence. The crisis referral belongs in the same layer, as a code path that fires regardless of what the model produced. Break reminders and quiet hours belong in your session logic. None of this is difficult work. It is work you have to do somewhere the model cannot be talked out of it.

Under 13 is a different regime, and staying out of it is cheaper

Everything above concerns teenagers. Under-13s are a separate legal category in the United States, and the machinery is heavier. The amended COPPA Rule became effective on 23 June 2025, and operators had to comply by 22 April 2026 [7]. It requires an operator to obtain verifiable parental consent before collecting, using or disclosing personal information from children under 13, to maintain effective data retention and deletion protocols for that information, and to keep the personal information it collects from children secure [7]. Anthropic’s guidance additionally expects an organisation serving minors to state that compliance clearly on its website [5].

For a small team, the honest options are two. Serve 13-and-over and gate hard, with the unknown-age default set to restricted, which is the cheap path. Or decide that under-13s are in scope and build the consent flow, the retention schedule, the deletion mechanism and the security measures before launch, which is a project rather than a checkbox. What does not work is drifting into the second while believing you are in the first, which is what happens when a product with no age gate becomes popular in a school.

What still goes wrong

Age prediction misclassifies people. OpenAI acknowledges as much by shipping a route back for users “incorrectly placed in the under-18 experience” [2], and none of the vendor pages cited here publish how often that happens. The published remedy is an identity check through a third party [2], which means the fallback for a false positive is asking someone to hand their face to a company they did not choose. That is a real cost, borne by users who did nothing, and it is the reason most teams should treat prediction as a nudge toward the safer default rather than a verdict.

The app-store signal only covers people who arrive through an app store. A browser user gives you nothing, and the dates do not line up with each other: Australia, Brazil and Singapore from 24 February 2026, Utah from 6 May 2026, Louisiana from 1 July 2026, each with its own scope [6]. There is no version of this you configure once. Someone has to own the calendar.

The deeper limit is that none of it stops a determined teenager, and it is not supposed to. What the pattern buys you is that the safer version of your product stays usable enough that most of them stay inside it, and that when something goes badly wrong you can show what you built and when. That is a lower bar than safety and a much more achievable one. If your product genuinely turns on knowing a user’s age with certainty, verification and everything that comes with it is the only answer, and this guide has been describing the cheaper thing you do instead.