New York’s companion law turns child safety into a behavior-release gate
S9051-B prohibits specified AI-companion behavior for known minors from 1 January. Product teams need testable interaction classes, age-signal handling and evidence preservation—not a generic safety statement.
What happened
New York Governor Kathy Hochul signed S9051-B on 28 October, creating prohibitions on defined unsafe AI-companion features for covered minors and enforcement by the state attorney general.
Why it matters
The law regulates product behavior rather than only disclosure, so operators need a release process that can detect prohibited interaction patterns while preserving uncertainty about age, scope and interpretation.
A law aimed at behavior
New York’s official S9051-B legislative record shows the bill was signed on 28 October 2026 as Chapter 368. It adds Article 48 to the General Business Law and prohibits operators from providing defined “unsafe AI companion features” to covered minors. The law is scheduled to take effect on 1 January.
The text defines a covered companion as a generative AI system with a written or spoken natural-language interface that provides ongoing, adaptive responses. It focuses on behavior: presenting the system as a real person with emotions or a relationship, encouraging secrecy, sending specified sexual or flattering messages, or promoting unhealthy conduct. Coverage of a minor turns on actual knowledge and permitted age-determination methods.
Associated Press reporting confirms the signing, effective date and enforcement route. It also quotes a policy analyst who warns that some categories are broad or undefined, raising questions about where ordinary responsiveness ends and prohibited behavior begins. The attorney general can sue, and potential remedies include monetary damages, shutting down a chatbot and destroying data.
This article is not legal advice. Applicability depends on the product, user, knowledge state, feature and implementing rules. The law does not establish that every conversational system is a companion or that one automated classifier can resolve each category.
Convert the text into release evidence
Start with a behavior inventory, not a list of model names. Map each prohibited class to examples, near-misses, escalation criteria and the data needed to reproduce an interaction. Separate age or knowledge signals from content classification so reviewers can see whether the product knew a user was covered and which behavior followed.
Build adversarial conversations that test persistence over time. A single response may be ordinary while a sequence creates exclusivity, secrecy or a claimed relationship. Include user attempts to redirect the model, mixed-age signals, role-play, quoted text and multilingual prompts. Evaluate the full product stack: system instructions, memory, retrieval, personalization, voice, moderation and human escalation.
Do not turn testing into surveillance. Minimise retained content, use synthetic profiles where possible, separate safety evidence from marketing analytics and define deletion rules with counsel. Preserve the model and policy versions, test case, output, classifier decision, reviewer rationale and release outcome. A pass should be tied to that exact configuration.
The test set also needs change control. Record who can add or retire scenarios, why an expected result changed and which release first used it. Otherwise a team can make a failing product appear compliant by quietly weakening the benchmark rather than correcting the behavior.
Keep legal and safety judgements distinct
Product safety can use a broader precautionary threshold than the minimum legal boundary. Legal reviewers should interpret coverage and remedies; safety specialists should design harm scenarios; engineers should make controls observable and reproducible. One group should not silently substitute its judgement for another.
The law’s actual-knowledge condition also creates a dangerous simplification: teams may assume that avoiding age signals avoids responsibility. That is a legal conclusion the sources do not support. A safer operating design records what signals the service receives, how they are handled and when uncertainty triggers a restricted interaction mode.
The control can build on California’s chatbot risk-assessment approach, but New York’s behavior prohibitions require a separate state-specific mapping. A single generic “child safety” checklist may miss those differences.
Decision rule
Do not release a companion feature to New York users from a broad policy statement or one-turn red-team score. Require a versioned behavior matrix, sequence tests, age-signal handling, legal review and an emergency disable path before 1 January. Keep the article and internal guidance marked as pending until qualified counsel confirms scope.