Keeping Minors Off AI Companions Means Collecting More Data

The critical control in an AI companion may be the unremarkable screen before the first conversation: a date-of-birth field, a Continue button, and a decision about whether the service believes the answer.

If the user enters an adult birth date, self-declaration lets the session begin without collecting another sensitive record. Replace that field with a government ID check and the service gains better evidence of age, but someone must now receive a document containing a name, photograph, birth date, document number, and often an address. Replace it with facial age estimation, which predicts an age range from an image rather than identifying a person, and the system still receives a face image while remaining uncertain near the cutoff.

That is the second privacy problem created by age assurance. A companion can operate with an email address, conversation history, and device data, already a sensitive combination when users discuss relationships, sexuality, loneliness, or mental health. An effective age gate can add identity evidence linking those conversations to a legal person.

The engineering question is narrower than whether age checks are good policy. It is which signal can support the access rule, how easily that signal can be defeated, and whether the companion operator ever needs to see the evidence behind it.

The requirement does not always specify the method

The UK provides the clearest distinction between an enforceable obligation and a preferred technical design. Under the Online Safety Act regime, a regulated service must assess whether children are likely to access it and, where the child-safety duties apply, address the relevant risks. Ofcom describes highly effective age assurance using four criteria: it must be “technically accurate, robust, reliable and fair.” Its guidance does not treat a user typing a birth date as highly effective age assurance.

That does not automatically put every AI companion under the same rule. Scope depends on how the service works and whether it falls within a regulated category, not whether its marketing calls it a companion. A chatbot that only returns model-generated text presents a different legal classification question from a platform where users publish characters, prompts, or conversations for others to find. The service must conduct the scope and access analysis before selecting a control.

The European Union’s Digital Services Act takes another route. Article 28 requires online platforms accessible to minors to use “appropriate and proportionate measures to ensure a high level of privacy, safety, and security of minors.” European Commission guidance can influence enforcement, but guidance is not the statutory text, and a recommended age-assurance architecture is not itself a universal command to upload an ID.

In the United States, companion-specific rules and proposals tend to attach protections to users the operator knows, or has reason to know, are minors. That wording matters. It can create pressure to infer age from account behavior without imposing one uniform verification method. A bill proposing mandatory identity checks should not be reported as an existing product requirement, and a service’s voluntary age gate should not be described as proof of compliance.

For a product team, the usable instruction is to write the rule first. “Exclude under-18 users” needs stronger evidence than “adapt features for likely teenagers,” while a rule covering sexually explicit output may justify checking age only before that feature becomes available. Applying the strongest check to every visitor collects more data than a risk-triggered gate.

Four signals, four different failure modes

Return to the birth-date screen. Self-declaration is fast, inexpensive, and privacy-preserving in a limited sense: the service asks for one data point and does not need to inspect a credential. It is also easy to circumvent. A teenager who understands the threshold can enter a different year, and repeated attempts can reveal the accepted answer unless the interface limits retries without retaining a new device identifier.

Self-declaration remains useful when the policy calls for a low-friction warning or when it feeds a broader risk model. It should not carry a claim of verified age. Calling the field “age verification” in an audit record overstates what happened.

A document check offers stronger evidence. The user photographs a passport, driver’s license, or other accepted credential; software tests document features, reads the birth date, and may compare the document portrait with a live selfie. The companion operator can outsource those steps to a verification provider and receive a result such as “over 18,” but that privacy benefit depends on contract terms, logs, retention, and whether the provider returns extra identity fields.

Documents are difficult to forge well, yet the check can still be defeated with a borrowed credential, a compromised verification account, or weak liveness testing, which looks for signs that the person is present rather than holding up a static image. It also excludes some legitimate adults who lack an accepted document or cannot complete the camera workflow. Manual review becomes the fallback, adding delay and exposing the evidence to another person.

Facial age estimation removes the document. The user takes a selfie or short video, a model estimates an age or age band from facial features, and the service compares that output with a threshold. It can be quicker than document review and reveals less conventional identity information if the image is deleted promptly and is not matched against a face database.

The word “estimation” carries the constraint. A model can place an adult below the line or a minor above it, particularly when the face is close to the required age, image quality is poor, or presentation changes the model’s output. Vendors compensate with a buffer: someone estimated well above the threshold passes, someone well below it fails, and the uncertain middle group gets a document fallback. A wider buffer reduces risky passes but sends more adults into the more invasive workflow.

Fairness also requires measurement by relevant demographic groups and operating conditions, not one overall accuracy figure. A provider should disclose false acceptance and false rejection rates around the product’s actual cutoff, along with performance on the cameras and lighting conditions users have. Mean absolute error across a broad age range does not answer whether a 16-year-old will be classified as over 18.

App-store or operating-system age signals can avoid a new selfie. Apple and Google have developed mechanisms through which an app can receive an age range or age-related status derived from the platform account, subject to the platform’s rules and user or family settings. The app can then disable the companion or restrict features without collecting the birth date itself.

This is attractive data minimization, but the signal inherits the account’s weaknesses. Adults and children share devices, account ages may have been self-declared years earlier, family controls can be missing, and a web version does not automatically receive the same result. Platform signals are therefore good routing inputs. Their suitability as the only gate depends on how the platform established the age and whether the regulator accepts that level of assurance.

Keep the proof away from the conversation

The safest redesign of the Continue button separates age proof from the companion account. An assurance provider examines the document or face, decides whether the threshold is met, deletes the raw evidence under a defined retention schedule, and returns a signed token stating only that the check passed, which method met the required assurance level, and when the result expires.

A signed token is a cryptographically protected claim that the companion can validate without receiving the underlying evidence. It need not contain a name or exact birth date. The operator still needs enough logging to show that the gate ran, but an audit record can store the policy version, provider, result, and token identifier rather than a copy of the passport.

That separation is not automatic. A stable token reused across unrelated services can become a tracking identifier, while indefinite retention lets a breach connect identity evidence with intimate chat records. The product specification should prohibit use of age-check images for model training, advertising, face recognition, or fraud products unrelated to the gate. Deletion must cover vendor backups and manual-review queues, not only the app’s primary database.

The companion should also avoid silently inferring age from the conversation as its main control. Language, school references, voice, and usage hours may indicate that an account belongs to a minor, but they are noisy proxies and require inspecting more behavior. Such signals can trigger a fresh check or a safety review; treating them as verified age invites inconsistent restrictions and broadens profiling.

Procurement can be reduced to a few receipts. Ask the vendor for cutoff-specific error measures, spoofing tests, demographic evaluation, retention periods, subprocessors, breach allocation, and a diagram showing every system that receives the raw image. Then test circumvention with a changed birth date, a borrowed adult account, a replayed image, a shared phone, and a switch from the app to the web service. The point is not to promise an unbreakable gate.

It is to know which bypasses remain after collecting highly sensitive evidence.

That brings the analysis back to the first screen. If self-declaration is insufficient, the next step should not automatically be “collect passports.” A platform-derived age range may support a feature restriction; facial estimation with a document fallback may support a higher threshold; a full identity check may be reserved for the narrow cases where policy requires that confidence. The strongest available method is not proportionate by default.

Questions people ask

Can an

AI companion verify age without seeing my ID?

Yes. It can use facial age estimation, an app-store age range, or a third-party provider that checks a document and returns only an over-threshold token. Each option still relies on sensitive inputs somewhere, and the service should disclose who receives them, how long they remain, and what fallback applies.

Is entering a birth date enough to keep minors out?

No, if the goal is strong age assurance. Self-declaration collects little data and adds almost no delay, but a user can usually enter an older birth year. It works as a notice or low-confidence signal, not as evidence that a service has verified age.

Is facial age estimation less invasive than an ID check?

It can be, because the service does not need a name, address, document number, or exact birth date. The tradeoff is uncertainty: users near the cutoff can be misclassified, and rejected adults may still need to submit an ID. Deleting the face image promptly is central to the privacy claim.

What should an AI companion keep after an age check?

Ideally, it keeps a signed pass or age-band token, the assurance method, an expiration time, and an audit event tied to the policy version. It should not retain the document or face image with the conversation unless a specific, documented requirement makes that necessary.