Companion chatbot operators face a new compliance layer in 2026: prove how you know who is a child, or apply strict child safety defaults to everyone. California's SB 1119 (Adam's Law), building on SB 243 and AB 1043's Digital Age Assurance Act, gives operators two paths: verify ages using privacy-protective signals, or extend minor protections to all users when verification fails.
AI chatbot age verification is not one technology. Platforms mix self-attestation, OS-level age bracket signals, third-party age assurance vendors, and behavioral inference. This guide compares methods, privacy tradeoffs, bypass risks, and implementation patterns for AI chatbot and AI companion products subject to California and emerging multistate rules.
Legal Drivers for Stronger Age Checks
California law now expects companion chatbot operators to determine user age or apply child-grade protections broadly, with published methodologies and audit trails. SB 243 created baseline disclosure, self-harm protocols, and minor-specific guardrails effective January 1, 2026. SB 1119 adds risk assessments, parental controls, age assurance, independent audits, and limited parental notification for imminent harm risks.
AB 1043 requires operating systems and app stores to provide age bracket signals through secure APIs when applications launch. Developers must request signals at download and launch. Operators who cannot determine age through the Digital Age Assurance framework must rely on alternate determinations under Health and Safety Code Section 27001 or apply SB 1119 protections to all users except where parental default settings should remain locked for likely children.
New York, Texas, and other states are introducing similar chatbot safety regimes with different thresholds. California remains the most prescriptive baseline for age assurance publication requirements and audit timelines stretching into 2029.
Senate Judiciary analysis of SB 1119 emphasized that operators need not guess user ages in a vacuum: the bill offers a deliberate fork between verified minor pathways and apply-all-user guardrails. That flexibility reduces false precision but increases documentation burden. Product counsel should work with growth teams early because aggressive adult-only marketing combined with weak age gates creates enforcement narratives regulators already use in social media cases.
Verification Technique Overview and Comparison
No single age verification method satisfies every product surface; operators converge on layered signals with conservative defaults when inputs conflict. The table below compares common techniques deployed in 2026 companion chatbot compliance programs.
| Method | How it works | Strength | Weakness |
|---|---|---|---|
| Self-attestation | User enters birthdate or age at signup | Low friction, easy to implement | Trivial bypass; floor only under SB 243 knowledge standard |
| OS age bracket signal (AB 1043) | Device or app store sends non-PII age range via API | Privacy-preserving; state-preferred path | Coverage gaps on web-only, older devices, sideloaded apps |
| Government ID / document scan | Third-party vendor verifies ID image or NFC chip | Higher assurance for high-risk features | Privacy backlash; storage and breach risk; adult drop-off |
| Payment card age check | Card network or wallet signals adult status | Useful for paid tiers | Excludes minors legitimately; parental card sharing |
| Behavioral inference | Models flag child-like language, hours, or risk patterns | Catches mis-declared ages post-signup | False positives for ESL adults; discrimination concerns |
| Parental account linking | Child profile tied to verified parent account | Supports SB 1119 parental controls and notifications | Onboarding friction; teens seek unlinked accounts |
| Apply-all-user protections | Treat every user with minor-grade guardrails | Avoids age determination failures | Product experience limits for adult power users |
SB 1119 explicitly allows operators to prohibit child users entirely if they publish how age assurance works. Operators who permit minors must publish child safety policies describing age methodology and actions taken when a likely child is identified, including parental default settings that cannot change unless the operator knows the user is not a child.
Privacy and Data Minimization
California rejected invasive document uploads as the default path, favoring age bracket data that is not personally identifiable under AB 1043 definitions. Operators should store the minimum age signal needed for compliance, not full birthdates copied from every user into application databases.
- Prefer OS or app store signals over re-collecting birthdates when APIs are available.
- If using ID vendors, contract for deletion after verification and avoid retaining document images.
- Document lawful basis and retention for any age-related data in privacy policies.
- Separate age assurance logs from chat content stores to limit breach impact.
- Publish high-level methodology without enabling reverse-engineering of bypass paths.
Good-faith compliance efforts by OS providers and app stores receive liability protections when signals err, but developers remain responsible for how they act on signals. Willfully disregarding available age bracket data creates enforcement exposure.
Bypass and Fraud Risks
Age verification fails in both directions: minors bypass weak gates, while over-aggressive detection frustrates adults and raises fairness complaints. Product and trust-and-safety teams should plan for adversarial testing alongside legal review.
Common Bypass Patterns
- False birthdates at signup with no secondary signals
- Sideloaded or web clients that skip OS signal APIs
- Shared family devices with adult-default OS profiles
- VPN or region switching to evade state-specific gates
- Prompt engineering to coax adult-mode personas on apply-all-user products
Mitigation Strategies
Layer self-attestation with OS signals where available, then add behavioral escalation when content risk scores rise. Re-verify age before enabling high-risk features such as unmoderated voice, memory export, or romantic persona modes. For products that cannot verify age reliably, SB 1119's apply-all-users path may be the safest legal choice despite UX cost.
Legal exposure runs both ways. Under-detecting minors triggers SB 243 and SB 1119 duties when operators should have known users were children. Over-detecting minors without appeal paths can create discrimination and consumer complaints. Document conservative defaults and human review paths for edge cases.
Implementation Roadmap for Product Teams
Age verification is a product, legal, and trust-and-safety joint deliverable with hard statutory deadlines. Use this phased roadmap to align engineering with SB 1119 and AB 1043 timelines.
- Inventory surfaces: Map every client (iOS, Android, web, API partners) and whether AB 1043 signals are available on launch.
- Choose path: Decide per product whether to verify ages, block minors, or apply-all-user protections. Document the decision in your child safety policy.
- Integrate signals: Request OS age bracket APIs at download and launch; add fallback flows for web-only users before July 2027 legacy device deadlines.
- Layer defenses: Combine self-attestation with behavioral escalation for high-risk content modes such as romantic personas or persistent memory export.
- Publish methodology: Post high-level age assurance descriptions required by SB 1119 before July 1, 2027 risk assessment duties intensify.
- Audit readiness: Prepare for independent child safety audits by January 1, 2029 with logs proving signal usage and escalation actions.
Multistate Divergence Watchlist
New York's companion chatbot legislation and Texas proposals use different definitions and age thresholds. Operators serving multiple US states should build configurable policy engines rather than hard-coding California logic only. EU and UK age assurance regimes add another layer for global products. The lowest-friction approach is often to implement California-grade protections globally when engineering cost is lower than jurisdictional forks, especially for apply-all-user strategies.
SB 243 already requires operators who know a user is a minor to disclose AI identity on a recurring cadence and to block sexually explicit material. SB 1119 adds parental notification within twelve hours when imminent self-harm risk appears for connected minor accounts. Age verification is therefore not an isolated signup field; it feeds ongoing duty cycles that trust-and-safety teams must operationalize after the first session.
Frequently Asked Questions
Is self-declared age enough in California?
Self-attestation is a floor, not a ceiling. SB 1119 expects Digital Age Assurance signals when available, or alternate determinations, or apply-all-user protections. Scale and risk profile determine how much layering regulators expect.
When must AB 1043 signals be integrated?
Developers should request signals when applications download and launch. OS providers must offer account-holder interfaces to set age brackets, with legacy device coverage before July 1, 2027. Plan engineering sprints around those dates.
Can we block all minors instead of verifying?
Yes, if you publish how age assurance prevents child access. You still need a credible methodology and child safety policy disclosures under SB 1119.
Do age rules apply to enterprise chatbots?
California companion chatbot statutes target consumer relationship-oriented products with adaptive, human-like dialogue. Pure internal enterprise copilots may fall outside scope, but consumer wrappers on the same model likely do not.
How often should methodology be reviewed?
Review at least quarterly and before major product changes. SB 1119 requires child safety audits before new or substantially modified companion chatbots launch, with independent audits by January 1, 2029 for existing products.
What happens if OS signals are unavailable?
Operators may rely on alternate age determinations under Health and Safety Code Section 27001 or apply SB 1119 minor protections to all users. Web-only products should plan explicit fallback flows rather than assuming mobile signal APIs will cover every user session.
