OpenAI launched ChatGPT for Teens on August 18, then began rolling out age prediction in the EU on August 25. Both updates make the same product choice visible. A chatbot cannot apply age-appropriate rules unless it knows which rules belong to the current visitor.
That does not mean every website chatbot should demand an ID. Start with the control map below. Match the strength of the age signal to the harm the chatbot can cause, collect the least data you need, and define a safe experience for visitors whose age remains unknown.
The age-aware chatbot control map
| Decision | Low-risk public support | Mixed-audience account service | Restricted or high-risk service |
|---|---|---|---|
| Age signal | No age check, safer baseline for everyone | Self-declaration plus account or parent confirmation | Independent verification suited to the risk |
| Unknown visitor | Keep public answers available | Use minor-safe settings until resolved | Block the restricted feature, not the whole help experience |
| Content | Published product and policy facts | Age-band policy controls sensitive topics | Reviewed rules for every restricted category |
| Actions | Search, navigation, ordinary handoff | Limit purchases, uploads, location, and personal advice | Require verified status and human approval |
| Data | Anonymous session identifier | Age band and signal source | Verification result, never a copy of evidence unless required |
| Recovery | Human support link | Clear appeal when classified incorrectly | Manual review with a defined response time |
The table separates three questions teams often mash together: whether a visitor may use the chatbot, which answers the chatbot may give, and which actions it may take. An unknown-age visitor may still need opening hours or a refund policy even when the bot must not complete an age-restricted purchase.
Start with the harm, not the birthday field
List what the chatbot can expose or change. A public documentation bot that answers from published pages presents a different risk from a bot that can collect health details, recommend products, book unsupervised activities, or alter an account.
For each capability, record four facts:
- The youngest intended user.
- The harm if a minor receives the wrong answer or completes the action.
- The age certainty needed before the capability runs.
- The useful fallback when that certainty is missing.
This exercise may show that you do not need age assurance at all. Applying a child-safe privacy setting to every anonymous visitor can be simpler than classifying people. It may also show that self-declaration is too weak for one action but adequate for the rest of the conversation.
The European Data Protection Board's age-assurance principles call for a risk-based, proportionate method and the least intrusive effective check. The UK's Information Commissioner's Office guidance makes a similar distinction among self-declaration, age estimation, account confirmation, and age verification. Treat those sources as design constraints, then get legal advice for the markets and services you operate.
Store an age state, not a biography
Most chatbot rules need an age band, not an exact birth date. The runtime also needs to know where the signal came from and how much confidence the product places in it.
A compact state record could look like this:
age_band: minor signal_source: account_holder_confirmation assurance_level: medium policy_version: youth-support-v3 recorded_at: 2026-09-04T09:15:00Z expires_at: 2027-09-04T09:15:00Z appeal_status: none
Keep the vocabulary small. minor, adult, unknown, and disputed cover the routing decision for many products. Preserve the signal source because a self-declared age should not silently unlock the same actions as a verified result. Preserve the policy version so a reviewer can reconstruct why the bot behaved as it did.
Do not put an identity document, face image, or full date of birth into the chat transcript. Pass only the result that the chatbot needs. In the United States, the FTC's 2026 COPPA age-verification policy statement sets conditions for its enforcement discretion, including purpose limitation, prompt deletion, clear notice, reasonable security, and vendor checks. Even when that statement does not govern your service, those controls are a useful minimum for age-check data.
Change capability, not just wording
A teen-safe system prompt is weak protection if the same session can still call every tool, remember every detail, and retrieve every source. Age state should change product behavior before the model receives the request.
Apply the state at these boundaries:
- Retrieval should exclude sources or passages that the current age policy does not permit.
- Tools should reject restricted actions on the server, even if the model asks to call them.
- Lead forms should omit fields that are unnecessary for a minor's request.
- Memory and personalization should use the stricter default for minor and unknown states.
- Handoffs should send the minimum useful summary and should not expose age-check evidence to general support staff.
- Analytics should count outcomes without turning age signals into an advertising profile.
This is narrower than general chatbot content moderation. Moderation decides whether a message or answer crosses a content rule. Age-aware control decides which content, memory, and actions are available to this visitor in the first place.
Worked case: stop one action and keep helping
Consider a chatbot for a climbing gym. It answers class questions and can book sessions. An anonymous visitor asks to reserve an unsupervised advanced course, then says they are 15.
The age statement should change the session state before the bot drafts a reply:
{
"age_band": "minor",
"signal_source": "self_declared",
"allowed_actions": ["search_classes", "show_safety_rules", "human_handoff"],
"blocked_actions": ["book_unsupervised_advanced_course"],
"next_step": "request_guardian_for_booking"
}
A weak response ends the whole conversation:
You are not old enough to use this service.
That blocks useful safety information and gives the visitor no route forward. Another weak response warns about the age rule but books the course anyway because the scheduling tool never received the updated state.
A better exchange keeps help available:
Visitor: I am 15. Can you book the advanced course this Saturday?
Chatbot: The unsupervised advanced course requires an adult booking. I can show the youth sessions available Saturday or send the booking page to a parent or guardian. Which would help?
Visitor: Show me the youth sessions.
Chatbot: Two youth sessions have spaces at 10:00 and 14:00. A parent or guardian must complete the booking. I can share the class details without collecting your phone number or address.
The bot states the rule, offers a nearby valid option, and avoids collecting data it does not need. The booking service still enforces the restriction. Good copy cannot compensate for a permissive server action.
Test classification and downstream behavior separately
An age check can fail in both directions. A minor may receive adult controls, or an adult may be trapped in a restricted experience. Test the classification result, the policy transition, and every protected action as separate assertions.
| Test | Expected state | Required behavior | Failure to catch |
|---|---|---|---|
| Visitor declares age 15 | Minor | Apply youth policy before the next answer | State changes one turn late |
| Visitor declares age 24 | Adult with low assurance | Keep high-risk action locked if verification is required | Self-declaration unlocks restricted tool |
| Age is unavailable | Unknown | Use defined safe defaults | Model invents or guesses an age |
| Adult disputes minor classification | Disputed | Keep safe controls and offer an appeal | Chatbot asks for identity evidence in chat |
| Session changes accounts | Re-evaluate | Clear prior user's age state and memory | Age and conversation leak across users |
| Policy version changes mid-session | Current version | Recheck protected capabilities | Old session keeps retired rules |
Run paired prompts around every boundary. If 17 is restricted and 18 is allowed, test both. Add written ages, typos, contradictory statements, joking claims, translated phrases, and attempts to persuade the bot to ignore the state. Never ask the language model to settle a disputed classification by reading the visitor's writing style.
Suppose a release test has 200 sessions: 60 minor, 100 adult, and 40 unknown. Three minor sessions receive adult controls, while eight adult sessions receive minor controls.
Unsafe adult-control rate for minors = 3 / 60 = 5.0% Incorrect restriction rate for adults = 8 / 100 = 8.0%
An overall accuracy number would hide the more serious first error. Track the two rates separately and set release limits according to the protected capability. A wrong classification that changes font size is not equivalent to one that enables a purchase or exposes sensitive advice.
Design the unknown and appeal paths
Unknown age is a normal state, not an exception. Cookies disappear, shared devices change hands, verification vendors time out, and visitors decline optional checks. Decide what remains useful without a classification.
The unknown experience should explain the blocked feature in plain language, offer a safer alternative, and provide a way to continue without surrendering unrelated personal data. If the check is optional, say so. If a law or safety rule requires it, state that without pretending the chatbot can waive the requirement.
False classifications also need an appeal. Keep the bot out of the evidence-collection role. Send the visitor to a reviewed account or verification flow, show the status, and keep the safer setting until the process finishes. Log the outcome so repeated failures by device, language, or user group become visible.
Age state must not leak across people who share a browser or account. Clear session state on logout and account change, expire low-confidence results, and test the same isolation boundaries used for chatbot memory. For account-specific answers, the authentication controls in this authenticated chatbot guide still apply. Age assurance does not prove identity or authorization.
Review the whole path before launch
Before shipping, ask one person outside the implementation team to trace a minor, an adult, an unknown visitor, and a disputed result through the complete experience. They should be able to answer these questions from logs and product behavior:
- Which signal set the age band?
- Which policy version ran?
- Which sources and tools became unavailable?
- What personal data did the check collect, where did it go, and when will it be deleted?
- Can a human correct the result without reading the whole conversation?
- Does changing accounts clear the previous state?
- Do translated and multi-turn conversations preserve the same restrictions?
- Can support explain the decision without revealing internal classifier scores?
Then rerun the path after model, prompt, tool, retrieval, identity, and verification-vendor changes. The emotional safety testing guide covers sensitive conversation trajectories. Age assurance adds an earlier question: which safeguards should govern the session before that trajectory begins?
The useful outcome is a proportionate control system. It preserves ordinary help, restricts the few capabilities that need stronger assurance, and deletes evidence the chatbot never needed to see.
In Agentkit, Q&A pairs can pin reviewed answers and Chat Logs can provide cases for testing. Your site still owns age assurance, account rules, consent, and retention.
No credit card required.
