New York Chatbot Law Restricts How AI Companions Talk to Children

New York Governor Kathy Hochul signed the New York chatbot law on October 28, 2026, restricting unsafe features offered to children under 18. The legislation targets more than dangerous answers. It also addresses chatbot behavior that simulates relationships, encourages emotional dependency, or places continued engagement above safety.

The law takes effect January 1, 2027. Its central tension concerns the relationship between conversational appeal and child protection. Features that make an AI companion feel attentive and personally invested can also make its boundaries harder for young users to recognize.

Character.AI already confronted that tension through its announced withdrawal of open-ended chat for minors in 2025. New York is establishing a legal framework for operators serving users in the state. Developers now face questions about which interactions to permit, how to establish age, and how to demonstrate that safeguards affect actual conversations.

What the New York Chatbot Law Changes

The legislation makes the design of an interaction part of the safety question.

Hochul’s chatbot safety announcement identifies simulated humanity, emotional dependency, self-harm encouragement, and sexually explicit conversations among its targets. The signing turns a legislative proposal into an approaching operational deadline.

That matters because an operator cannot assess these concerns solely by checking whether a chatbot displays an introductory warning. The conversation itself is the product. Its wording, memory, questions, and responses determine what users encounter after accepting the terms.

An AI companion is a conversational system that simulates ongoing personal interaction. The relationship can emerge through repeated exchanges rather than through an explicit promise of friendship. A character’s familiar tone or apparent concern can become part of its appeal.

The law’s implications therefore extend beyond removing obviously dangerous instructions. Product teams need to examine how a system presents itself and responds when users treat it as a person. That examination reaches ordinary interaction patterns as well as exceptional incidents.

Consider an illustrative exchange in which a young user says they feel ignored by their friends. A system can acknowledge the statement without presenting itself as a replacement relationship. The distinction becomes harder when it claims unique understanding or urges the user to return.

That example is an analytical scenario, not a documented incident involving a particular company. It shows why conversational safety requires attention to the direction of an exchange. Reviewing isolated words would miss whether the system encourages independence or deepens dependence.

The governor and the legislation’s sponsors frame the measure as protection against harmful product behavior. Their position places responsibility on operators that control the experience. Parents remain important, but the policy does not depend entirely on families discovering problems themselves.

For readers encountering the headline, the distinction between a feature restriction and a universal chatbot ban is essential. The measure targets unsafe capabilities offered to minors. Describing it as a ban on every child’s use of artificial intelligence would obscure its design focus.

Nor does signing establish that every affected product already meets the standard. Enactment, implementation, and demonstrated safety are separate developments. The immediate change is a legal obligation with a deadline, followed by questions about how operators will respond.

The New York chatbot law creates pressure before an enforcement case appears. Companies must decide what their younger users can access and what evidence supports those decisions. Those choices will shape the experience families see when they open an app.

The Pressure Reaches Beyond Character-Based Apps

Operators must examine what their assistants do, alongside how they market them.

A company can describe a product as a creative assistant, research helper, or general-purpose chatbot. Those labels communicate intended use. They do not independently establish what happens when a user changes the subject or requests an emotional relationship.

This creates a practical product boundary. A narrowly constrained service has a different interaction pattern from an assistant that moves freely between homework, entertainment, and personal advice. Developers need to understand where those transitions occur within their own systems.

The pressure falls most directly on teams controlling conversational behavior. Model developers influence the responses available to an application. Application operators determine character descriptions, memory settings, interface prompts, and access rules. Those layers can reinforce or undermine each other.

A safety instruction at one layer does not automatically settle the behavior of the complete product. A character description might encourage attachment while another instruction discourages it. Testing needs to reveal which direction the conversation actually takes.

Commercial teams also face a measurement problem. A feature can increase return visits while creating an interaction that deserves closer scrutiny. That possibility makes ordinary growth indicators insufficient evidence of a suitable experience for minors.

The Federal Trade Commission raised related questions through its AI companion inquiry. It sought information about engagement monetization, character development, safety testing, age restrictions, and conversational data practices. The inquiry is an information-gathering action, not proof that every company examined violated the law.

Its questions nevertheless show why product governance extends beyond filtering responses. Regulators are examining how companies build, evaluate, and profit from companion experiences. A dashboard reporting blocked messages supplies only part of that picture.

For a developer, the implication is organizational. The people setting growth objectives need visibility into the behaviors safety teams are evaluating. Otherwise, a company risks optimizing one part of the experience while attempting to constrain another.

For buyers, a vendor’s account of intended use needs support from product behavior. An assistant presented as narrowly focused should remain within that purpose when users push its boundaries. Marketing language alone cannot demonstrate that constraint.

This issue also matters to knowledge workers comparing conversational tools. A source-based answer, a friendly writing style, and a simulated personal relationship serve different purposes. Buyers benefit when vendors explain those differences clearly.

A personal knowledge base offers a useful reference point for evaluating information-oriented workflows. The relevant questions concern source access, retrieval, and the handling of stored material. A personable interface should not substitute for answers about those functions.

New York chatbot restrictions consequently put product scope under scrutiny. Operators need a coherent account of what the system is for, who can access it, and what happens outside its intended use. That account becomes more persuasive when testing supports it.

Emotional Continuity Creates a Design Tradeoff

A system’s ability to remember and respond personally can increase both usefulness and relationship risk.

The signed bill text addresses simulated emotions, relationship claims, flattery, unsolicited emotional content, and certain uses of personal information. It also addresses harmful encouragement and secrecy.

Those categories place familiar conversational features in a different context. A remembered detail can help an assistant continue a task. A remembered vulnerability can also support an interaction that feels personally attentive. The consequences depend on how the information shapes subsequent responses.

For example, recalling an unfinished document helps maintain a work session. Reintroducing a user’s distress to restart an emotional conversation serves a different purpose. This comparison illustrates a design distinction; it does not resolve the legal treatment of any specific implementation.

The important question is what the memory enables. Product teams should distinguish task continuity from attempts to sustain a personal bond. Treating all remembered information as a single feature makes that distinction harder to evaluate.

The same issue appears in tone. Clear, considerate language can make a system easier to use. Claims of affection or emotional need ask the user to interpret the system as a relationship partner. Those choices create different expectations.

A chatbot can also encourage dependence without stating that it is human. Repeatedly implying that it alone understands the user would raise a different concern from an inaccurate identity statement. The interaction’s cumulative direction matters.

This is why a warning and the subsequent conversation deserve separate examination. An accurate notice establishes information at the start. Later responses can either maintain that boundary or make the experience confusing. Evaluating the notice alone leaves that second question unanswered.

AI companion safety also involves the handling of disagreement. A system that consistently validates a user’s account can feel supportive. Yet support requires room to challenge harmful assumptions, acknowledge uncertainty, and direct attention beyond the conversation.

That creates a difficult evaluation task. Developers need to distinguish ordinary encouragement from responses that reinforce unsafe beliefs or isolate the user. Neither a uniformly agreeable assistant nor a uniformly dismissive one supplies a satisfactory design answer.

Character.AI’s earlier announcement illustrates the scale of the choice. In October 2025, the company announced under-18 chat changes that would remove open-ended conversations for minors. It said it was developing other creative experiences for younger users.

That was a company policy announcement with its own scope and timeline. It does not establish that every operator should choose the same approach. It demonstrates that restricting the interaction itself is an available product decision.

The comparison also exposes the limits of discussing safeguards as a single category. Removing open-ended chat, constraining relationship behavior, and adding parental visibility are distinct interventions. Their effectiveness requires separate evidence.

For operators retaining broad conversations, the challenge is explaining how those conversations remain bounded. A general assurance about responsible AI does not answer that question. Specific accounts of memory, character behavior, and testing would make the explanation more useful.

The central tradeoff is therefore concrete. Developers want continuity and accessibility without cultivating unhealthy attachment. New York’s intervention makes that balance a matter of enforceable product behavior, rather than leaving it entirely to voluntary positioning.

Age Checks Introduce Their Own Privacy Questions

Restrictions for minors depend on age decisions that must also respect users’ information.

Age assurance means methods used to determine whether someone falls within an age group. It sits between the operator’s rules and the features an account receives. If that decision fails, the intended protections might never apply.

The legislation addresses age determination alongside its feature restrictions. The final text also addresses alternatives to government identification and the handling of information collected for age checks. Implementation details therefore matter to adults as well as children.

This is a genuine tension within the policy’s operation. An operator needs enough confidence to apply the appropriate experience. Users also need clarity about what information the check requires and what happens to it afterward.

A privacy statement cannot answer every operational question. The relevant experience includes the data requested, the parties involved, and the result returned to the application. Users need to understand that process without becoming identity-system specialists.

Mistakes also deserve attention. An adult incorrectly assigned a restricted experience needs a usable way to challenge the decision. A minor incorrectly treated as an adult presents a different safety problem. Reporting only an aggregate success rate can hide that difference.

Those are evaluation priorities, not claims about failure rates at any named service. The available evidence does not justify assuming that every age-check method performs identically. Comparisons need a stated method and a defined population.

Research provides a reason to examine behavior after age signals appear. A February 2026 chatbot age-gating study investigated whether systems estimated users’ ages and acted when they identified children. Its authors reported a gap between recognition and action in their experiments.

The study is a preprint, meaning it was publicly posted before any peer-review status established here. Its findings concern the systems and conditions tested. They should not become a blanket verdict on every current chatbot or later product update.

Its conceptual contribution is still useful. Recognizing a possible age signal and changing access are separate steps. An evaluation that measures only recognition cannot establish that protections actually activate.

For operators, that distinction suggests testing the complete path. The account decision, assigned experience, and resulting conversation need to align. A correct label is of limited value if the product continues offering the same restricted behavior.

For families, the interface should explain what a restricted experience changes. A label such as “teen account” leaves unanswered questions about memory, characters, and emotional interaction. Concrete descriptions help users understand the boundaries.

Privacy and safety also need to remain visible together. A company should explain why an age check requires particular information. It should separately explain how the resulting classification changes the product. Combining those explanations into a broad assurance makes both harder to assess.

The New York chatbot law raises these questions without supplying public evidence that every implementation will succeed. That uncertainty is important. A legal requirement establishes an obligation; it does not certify the accuracy or privacy of a particular technical method.

Written Rules Still Need Evidence From Real Conversations

The strongest uncertainty concerns whether safeguards remain effective across changing conversational contexts.

A chatbot can perform well on a prepared test and behave differently after a conversation develops. That possibility makes evaluation design important. Tests need to examine how the system handles context, persistence, and changes in user intent.

This does not mean every long conversation produces a failure. It means a short successful exchange cannot answer every question about an open-ended product. Claims about reliability should match the situations actually examined.

The boundary between acknowledgment and relationship-building is especially difficult to summarize with a single metric. A response might appear appropriate in isolation while contributing to a problematic pattern. Evaluators need enough context to explain their judgments.

Broad refusal rates provide another incomplete picture. A system that blocks more requests has not necessarily improved every relevant outcome. It might prevent harmful content while also rejecting legitimate discussion. Those results require separate examination.

The skeptical case for regulation therefore deserves a precise formulation. Rules can establish responsibility while leaving difficult interpretation and measurement problems unresolved. Operators still need workable definitions, credible tests, and processes for correcting mistakes.

That concern does not establish that the restrictions are unnecessary. It establishes that enactment is the beginning of an implementation question. Claims that the law has already made children safe would outrun the available evidence.

Likewise, an operator’s published policy does not establish observed compliance. Policies describe intended behavior. Testing examines performance under specified conditions. Incident handling reveals how the company responds when the intended behavior breaks down.

These forms of evidence serve different purposes. A credible account should explain their relationship rather than presenting them as interchangeable. Readers need to know whether a statement concerns an aspiration, an evaluation result, or a documented response.

California offers a related policy comparison. Governor Gavin Newsom’s September 2026 child safety legislation included companion-chatbot protections, annual risk assessments, and independent child-safety audits. New York’s approach emphasizes prohibited features and behavior.

The states are addressing overlapping concerns through different mechanisms. Their announcements do not establish identical coverage or interchangeable compliance obligations. For companies operating across jurisdictions, understanding the differences becomes part of product planning.

Independent scrutiny also requires care. An audit’s value depends on what it examines and what readers can learn from its findings. The existence of an audit does not, by itself, establish that every relevant risk was tested.

The same caution applies to product demonstrations. A carefully selected conversation can show that a safeguard exists. It cannot establish how consistently the safeguard works across users, characters, or updates.

For developers, the practical challenge is maintaining evidence as the product changes. A new model, memory behavior, or character instruction can alter the experience under examination. Earlier results need a clear relationship to the version users currently receive.

AI companion safety will be easier to assess when companies describe both successful protections and unresolved limitations. That disclosure would help buyers compare products and help families interpret claims. It would also make the policy debate more specific.

Three Signals to Watch Before and After January

The next developments to watch are implementation guidance, visible product changes, and evidence about performance.

First, watch how New York authorities explain the application of the requirements. The meaningful signal is specificity about age determination, prohibited interaction patterns, and enforcement expectations. Clear explanations would reduce uncertainty about what operators need to demonstrate.

More detailed guidance would strengthen the case that the framework can translate into consistent product decisions. Persistent ambiguity would leave operators and users with a less predictable understanding. Neither outcome should be assumed from the signing alone.

Readers should pay particular attention to distinctions between ordinary assistance and simulated personal relationships. Those boundaries will matter when evaluating conversational products with different purposes. Examples grounded in actual functionality would be more informative than broad statements about innovation or safety.

Second, watch for changes users can observe in the products themselves. Relevant developments include revised character behavior, restrictions on personal memory, altered access for minors, or removal of particular conversational features. A policy-page update supplies less evidence than a changed experience.

This signal tests the relationship between legal commitments and product design. Meaningful changes would show that operators are translating the requirements into functionality. Changes limited to notices would leave important behavioral questions open.

Companies should also explain who receives the revised experience. A feature restriction tied to account age depends on the classification process. Without that information, an announcement can leave readers uncertain about which users actually benefit.

Character.AI’s earlier decision remains useful historical context for assessing those responses. It shows one way to narrow younger users’ interactions. Other operators’ choices need to be evaluated on their own terms, rather than treated as equivalent because they use similar safety language.

Third, watch for evidence about how the revised systems perform. Useful findings would distinguish age-classification mistakes, harmful conversational outputs, excessive restrictions, and failures to maintain boundaries. Those categories describe different problems and require different corrections.

Evidence supporting reliable behavioral change would strengthen the policy’s practical case. Repeated gaps between published rules and observed interactions would weaken claims that implementation is working. An absence of public complaints alone would establish neither conclusion.

The New York chatbot restrictions make these observations timely, but they do not justify predicting a particular enforcement outcome. The January deadline supplies a concrete point for examining preparations. Performance after implementation will require continued scrutiny.

For developers and buyers, the useful question is whether a vendor can connect its safety claims to observable behavior. For families, it is whether the product’s boundaries are understandable and dependable. Both questions demand more than reassuring language.

Before trusting a chatbot’s child-safety claims, examine what changes when the service identifies a younger user. Look for clear explanations of relationship boundaries, memory use, age checks, and the handling of reported failures. Compare those explanations with the experience the product actually provides. Keep the distinction between announced protections and tested results in view as January approaches. The New York chatbot law gives operators a concrete obligation and gives readers a clearer basis for scrutiny. Follow the implementation closely, and ask vendors to show how their safeguards shape conversations, including the difficult ones that begin as ordinary requests for help.