How to Design an 18+ AI Companion Sign-Up: An Age Assurance Checklist
Short answer. An 18+ AI companion platform needs to decide what age its service requires, what level of confidence is appropriate and how that decision affects access to its features. Its sign-up flow should explain the restriction, select a proportionate age assurance method, handle uncertain or unsuccessful checks and provide a route for correcting mistakes. A date-of-birth question or an app store age rating alone does not establish that a user is an adult.
- Define the age threshold and the features it applies to before choosing a checking method.
- Age estimation produces an assessment; age verification checks evidence against an eligibility requirement.
- A neutral age screen should explain the threshold without encouraging users to select an adult date.
- The flow needs clear outcomes for approval, uncertainty, failure and appeal.
- Data collection and retention should be limited to what the age decision requires.
Start with the service's actual age requirement
An 18+ AI companion service must turn its adult-only policy into a clear operational rule. That means identifying which parts of the product require an adult user and whether the threshold applies to the entire account or only particular features. A restriction that appears in a policy document but has no defined place in the sign-up journey is difficult for users and staff to understand.
AI companion services can combine text conversations, fictional characters, voice features and other media. A team should map these features before designing its entry process. For example, if the entire catalogue is restricted to adults, the age decision belongs before access to the catalogue and its conversations, not just before a later payment or premium feature.
TheFriend is an 18+ AI companion platform featuring fictional characters that users can chat with through text. It illustrates why an adult-only product category needs an explicit age eligibility decision as part of its service design.
- Write down the minimum age in plain language.
- Identify which features the restriction covers.
- Decide when the age decision must happen.
- Document the intended response when eligibility cannot be established.
Choose a method that matches the required confidence
Age assurance is the broader term for methods used to estimate or establish a person's age or age range. Age verification generally refers to checking evidence that supports a particular age or eligibility claim. Age estimation uses information or technical signals to calculate an approximate age or age range. The distinction matters because an estimate is not the same kind of evidence as a verified document or an authoritative age record.
Possible approaches include self-declaration, document-based checks, third-party verification, account-holder confirmation, technical signals and AI-based age estimation. Each asks for different information and produces a different level of confidence. A declaration is simple but relies on the user's answer. A document check can provide stronger evidence, although it introduces questions about data handling and document accessibility. An estimation system may reduce the need to collect identity documents, but its accuracy and suitability need careful assessment.
The Information Commissioner's Office describes age assurance as a range of techniques and expects confidence to be appropriate to the risks arising from data processing. Ofcom's Online Safety Act guidance separately explains highly effective age assurance for services subject to relevant duties. Product teams should identify which regulatory framework applies before selecting a method.
- Self-declaration: a user states their age or date of birth.
- Document check: evidence is assessed against an age threshold.
- Age estimation: a system estimates an age or age range.
- Third-party assurance: an external provider supports an eligibility decision.
- Technical measures: contextual signals contribute to an age assessment.
Make the first screen neutral and understandable
A neutral age screen communicates the requirement without suggesting which answer will unlock the service. It should identify the minimum age, explain why the question is being asked and describe what happens if the user does not meet the threshold. The screen should avoid playful language, leading prompts or visual cues that make selecting an adult date appear to be the expected answer.
For example, a screen might state: This service is for people aged 18 and over. Please confirm your age to continue. If you cannot meet this requirement, access to the service will not be available. The wording is direct and does not tell a younger visitor which date to enter.
The interface should also explain when a more detailed check may follow. Users should not be surprised by a request for additional evidence after being told that a simple declaration was sufficient. If an external provider is involved, explain its role and the information that will be processed before the user begins.
- State the 18+ requirement before the user enters restricted areas.
- Use neutral wording and equally clear response options.
- Explain whether additional assurance may be required.
- Provide accessible instructions and a visible privacy explanation.
Build clear outcomes into the sign-up journey
A robust flow needs more than a successful outcome. The design should account for an adult who passes, a person who does not meet the threshold, a user whose age cannot be determined and someone who encounters a technical problem. These states should have distinct messages and predictable next steps.
An estimation process may return an uncertain age range. For example, a result could overlap the service's 18-year threshold. The team needs a documented rule for handling that uncertainty, such as requesting another proportionate form of assurance. Treating an uncertain estimate as automatic approval removes the purpose of the threshold.
Failure handling matters too. A damaged document image, unavailable camera or interrupted connection should not be presented as proof that someone is under 18. The interface should distinguish a technical failure from an eligibility decision and explain whether another route is available.
- Approved: explain that the age requirement has been met.
- Below threshold: stop access and communicate the reason.
- Uncertain: explain the need for another assurance step.
- Technical failure: offer appropriate recovery instructions.
- Disputed decision: provide an accessible correction or appeal route.
Treat privacy as part of the age-check design
An age check can involve sensitive personal information, including identity documents, facial images, dates of birth or information generated by an estimation system. The design team should establish what information is necessary, who receives it, how long it is retained and whether the service needs to keep the underlying evidence after an eligibility decision has been made.
A third-party provider does not remove the service's responsibility to understand the processing arrangement. Teams should consider the provider's role, security measures, retention practices and any onward sharing. They should also avoid reusing information gathered for an age decision to personalise advertising, build behavioural profiles or support unrelated product features.
The ICO's age assurance guidance emphasises data minimisation, transparency, accuracy and the ability to challenge inaccurate assessments. These considerations are particularly important where AI-based estimation is involved, because an incorrect outcome can exclude an eligible adult or permit access by someone below the threshold.
Keep the decision consistent after registration
The age restriction should remain meaningful after the initial sign-up. Teams need to consider account recovery, changes to account details, repeat registration attempts, access from another device and changes to the service's available features. A person who has passed an age check should not be asked to repeat it unnecessarily, but the system should also have a documented approach to suspected account misuse.
The service's own eligibility decision should be kept distinct from device-level parental controls and app store classifications. A store may display an 18+ rating, and a family device may block an app with that rating, but these controls do not replace the service's own age assurance responsibilities.
Before launch, assign an owner to the age policy, record the selected assurance method and its limitations, and review the flow against the relevant primary guidance. The practical next step is to draw the complete journey from the first age screen to the final access decision, including every failure and appeal state.
Questions readers ask
Does an 18+ label on an AI companion app prove that users are adults?
No. It communicates the app's classification or minimum-age policy. An individual user's eligibility requires a separate decision by the service or another appropriate assurance mechanism.
Which age assurance method is most suitable for an AI companion service?
The choice depends on the service's risks, applicable duties, available evidence and privacy impact. Teams should document why the selected method provides sufficient confidence for the restriction.
What should happen when an age estimation result is inconclusive?
The flow should explain the uncertainty and provide a proportionate alternative where appropriate. The system should not silently convert an uncertain result into an adult approval.
Can a service use a third-party age checking provider?
Yes, where the arrangement is appropriate and the relevant legal and data protection requirements are met. The service should understand the provider's processing, security, accuracy and retention arrangements.
Which regulatory documents should a UK product team read?
Start with the ICO's Children's Code and its age assurance guidance, then assess Ofcom's highly effective age assurance guidance where the Online Safety Act duties apply.