SELINA.ai
Sign in

Companion Chatbot Laws Are Landing State by State: What California, New Jersey, and Pennsylvania Just Passed, and Why Privacy Is the Real Battleground

Six months ago, companion chatbot regulation was a hypothetical. Now it is a compliance category with teeth. California's SB 243 took effect January 1, 2026, creating the first enforceable set of design, disclosure, and safety requirements for operators of conversational AI companions. Since then, privacy obligations specific to this product category have proliferated: nearly 100 chatbot-specific bills introduced across U.S. states in 2026, with California layering on two more (SB 300 and SB 1119), Pennsylvania advancing its own AI Companion Safety Act through the House, and New Jersey introducing a transparency-focused bill package. A federal bill, the GUARD Act, cleared the Senate Judiciary Committee unanimously in April. This is moving fast, and most of the industry is behind.

Key Takeaways

What Does California's SB 243 Actually Require?

SB 243 requires companion chatbot operators to implement what the statute calls "critical, reasonable, and attainable" safeguards, with a particular focus on protecting minors. Governor Newsom signed it into law on October 13, 2025, and it took effect January 1, 2026.

The key provisions are concrete. Operators must disclose that the user is interacting with an AI, not a person. They must implement crisis-referral protocols when conversations indicate risk of self-harm. They must meet design requirements intended to prevent emotional manipulation of minors. And they must report on compliance in ways that are auditable.

The enforcement mechanism is what makes this different from a voluntary framework or a set of best practices. SB 243 creates a private right of action for anyone who suffers "injury in fact." Plaintiffs can seek injunctive relief plus the greater of actual damages or $1,000 per violation, plus attorneys' fees. That per-violation minimum is the detail that should keep compliance teams awake. A single product with millions of users, where each conversation could constitute a separate violation, creates exposure that scales linearly with your user base.

One clause deserves special attention. Compliance obligations attach to whoever offers the chatbot to California consumers, even if the product is built on a third-party AI model. You cannot outsource your legal responsibility to the vendor whose model you're wrapping. If you ship it, you own it. This is a quiet but significant inflection point for every company running a companion product on top of a frontier provider's API.

What Are SB 300 and SB 1119, and How Do They Extend SB 243?

They are follow-on bills that tighten and expand the requirements SB 243 established. Both passed out of the Assembly Privacy and Consumer Protection Committee during the week of July 6, 2026, and moved to Appropriations.

SB 300 would require companion chatbot operators to prevent their products from producing or facilitating sexually explicit material or propositions. The scope here matters: "facilitating" is broader than "generating." It implies an affirmative duty to detect and block, not just a prohibition on intentional output.

SB 1119 introduces an annual comprehensive child-safety risk assessment, to be completed and documented by July 1, 2027. The assessment must be submitted to an independent auditor, and the resulting report goes to the state Attorney General. This is the provision that creates the most operational burden, and the one where your data architecture determines whether compliance is a manageable exercise or a multi-month project every year.

If you retain rich conversational logs, a child-safety risk assessment means cataloguing, classifying, and evaluating that data against the statute's criteria. If you don't retain it, the assessment is fundamentally simpler, because you can demonstrate the absence of risk surface rather than auditing its contents. This is where privacy-by-design stops being an abstract principle and starts being a concrete cost advantage.

What Is Pennsylvania's HB 2006?

Pennsylvania's "AI Companion Safety Act" governs AI companionship applications and imposes its own set of safety and penalty requirements. It passed out of the House Rules Committee in the week of July 6, 2026, and narrowly cleared the House floor 104-98 on July 1 before being re-committed to Appropriations.

That 104-98 vote tells you something about the political dynamics. This is not consensus legislation passing on voice votes. It is contentious, and the opposition is substantive. NetChoice, an industry trade group, formally opposed HB 2006, centering its objections on vague and subjective definitions, excessive civil penalties, and a specific structural problem with the age-assurance provision: it would require operators to collect additional personal information from every user, adult and minor alike, just to identify who is a minor in the first place.

This is the recurring tension in companion chatbot regulation. The privacy cost of age verification may exceed the privacy benefit of the child-safety rule it enables. We will come back to this.

What Is New Jersey Doing?

New Jersey introduced Bill A4732 along with several companion AI-transparency measures on March 10, 2026. A4732 would require AI companion chatbots to give clear notification that users are not talking to a human. The legislative intent responds to concern about chatbots' effects on vulnerable populations, specifically teens and seniors, and on mental health and real-world relationships.

Several of these bills have already moved out of committee, and the package signals that New Jersey views AI companion regulation as imminent, not aspirational. The disclosure-focused approach in A4732 is narrower than California's SB 243 or Pennsylvania's HB 2006. It focuses on transparency rather than design mandates. But it is part of the same wave, and operators serving users in New Jersey will need to comply with whatever emerges.

Which Other States Have Already Passed Companion Chatbot Laws?

More than you probably expect. New York's AI Companion Models statute (N.Y. Gen. Business Law § 1700 et seq.) took effect November 5, 2025, making it contemporaneous with California's SB 243. Georgia signed its chatbot bill (SB 540) into law. Colorado's HB 1263 passed its legislature in the spring 2026 session. Rhode Island's Governor signed companion bills H 7350/S 2195 into law. Washington state passed HB 2225 in March, requiring AI companion apps interacting with minors to disclose that the chatbot is not human.

The Future of Privacy Forum tracks this legislative category across all 50 states. Their data confirms what the individual bills suggest: this is not a coastal phenomenon. It is a genuine new regulatory category forming in real time across political geographies.

What Is the GUARD Act, and Why Does It Matter Federally?

The GUARD Act (S.3062) is federal legislation that would ban AI companion chatbots for minors, require AI chatbots to disclose their non-human status, and create new criminal penalties for companies allowing minors to access AI companions that produce sexual content. The Senate Judiciary Committee advanced it unanimously on April 30, 2026, and it now awaits a full Senate vote.

The unanimity of the committee vote is notable, but so is the opposition forming outside the committee. Critics argue that implementing the GUARD Act would effectively require identity verification from all AI chatbot users, since the Act requires every user to create an account with age verification. ITIF published an analysis arguing the bill would effectively ban minors from AI companions through broad age-verification requirements while raising free speech, privacy, and parental-authority concerns.

This is the same structural tension as Pennsylvania's HB 2006, playing out at the federal level. The intent is to protect children. The mechanism chosen to implement that intent requires collecting identity data from everyone. Whether you think the tradeoff is worth it depends on whether you believe less privacy-invasive alternatives exist. We think they do.

Why Does the Age-Verification Mandate Create a Privacy Problem?

Because verifying age at scale, with any reliability, requires collecting identity signals that are themselves sensitive. A date-of-birth field is trivially falsifiable. Government ID verification is not falsifiable in the same way, but it means your companion chatbot operator now holds a copy of your driver's license or passport, creating a data store that is both valuable to attackers and orthogonal to the service being provided.

The NetChoice testimony on HB 2006 flags this directly: the age-assurance provision would require operators to collect additional personal information from every user, not just the minors the law intends to protect. You build a surveillance infrastructure to enforce a child-safety rule. The surveillance infrastructure itself becomes a risk.

There are alternative approaches. On-device age estimation, privacy-preserving tokens, or architectures where the age signal is verified by a third party but the result (over-18, yes/no) is the only data transmitted to the operator. None of these are perfect. But they avoid the failure mode where the compliance mechanism creates a larger data-breach surface than the one it was designed to prevent.

At Selina, we think about this tradeoff constantly. Our position is straightforward: you can satisfy the regulatory intent, keeping AI companions safer for kids, without building the identity-collection pipeline that several of these bills assume. The alternative approaches are harder to implement. They require more engineering work. But they avoid creating new attack surfaces, and that matters.

Why Does the "Operator Can't Offload Liability" Clause Change the Industry?

Because it eliminates the legal fiction that a wrapper application can disclaim responsibility for the behavior of the underlying model. If you offer a companion chatbot to California consumers, you are the operator subject to SB 243, regardless of whether the conversational AI is built on a third-party model.

This matters because a large portion of the companion chatbot market consists of applications built on top of a frontier provider's API. The application developer chooses the persona, the system prompt, the guardrails (or lack of them), and the user interface. The model provider supplies the inference. Under SB 243, the application developer bears the compliance burden. "Our model vendor's safety team handles that" is not a defense.

The practical implication: if you are shipping a companion chatbot, you need your own crisis-protocol logic, your own self-harm detection, your own disclosure enforcement, your own audit trail. These cannot be delegated. They must exist at the application layer, where you control them and can demonstrate compliance.

This creates an interesting product opportunity for infrastructure companies. The compliance requirements are non-trivial, the penalty exposure is significant ($1,000 per violation, plus attorneys' fees, with a private right of action), and most small companion-chatbot operators do not have the engineering capacity to build compliant safety layers from scratch. There is a defensible product category forming around compliance infrastructure for this specific regulatory surface.

How Should You Think About Compliance Architecture?

There are two approaches, and they produce very different cost structures over time.

The first is compliance-by-policy. You take your existing chatbot, add disclosure language ("I am an AI, not a human"), bolt on a crisis-referral script that triggers on keyword matches, and hire a law firm to write a compliance report. This satisfies the letter of SB 243 in the short term. It does not scale well to SB 1119's annual risk assessment, because the assessment requires you to catalogue and evaluate your data practices, and if you retain rich conversational data, that catalogue is large and expensive to audit.

The second is compliance-by-architecture. You design your system so that the data that creates regulatory exposure does not exist in the first place, or exists in a form that limits the scope of what an auditor must examine. If you don't retain conversational data that could reveal a minor's mental state, the risk assessment under SB 1119 is structurally simpler. You are demonstrating the absence of a risk surface rather than auditing the contents of one.

This is the lens through which we built Selina's data architecture. Content is encrypted at rest. Memory is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference, and we are honest about that limit. Files and transfers via SelinaSEND are zero-knowledge encrypted. Non-content operational metadata is kept for a short retention window, not indefinitely. The account is protected, not encrypted. These are specific, bounded claims, and we state both what we do and what we don't do because the distinction matters.

The result is that when a regulation like SB 1119 requires an annual child-safety risk assessment, the scope of what we need to evaluate is constrained by architecture, not just by policy. We can prove what data we don't hold. That proof is cheaper and more durable than auditing what we do hold.

What about the disclosure requirements?

Every bill in this wave, from SB 243 to A4732 to the GUARD Act, requires disclosure that the user is interacting with an AI. This is the lowest-cost compliance requirement and the one most operators already satisfy. If your product does not already make this clear, you have a design problem independent of regulation.

What about crisis-referral protocols?

SB 243 and its progeny require operators to intervene when conversations indicate risk of self-harm. The backstory is specific and tragic: much of this legislative wave traces to advocacy from Megan Garcia, whose 14-year-old son Sewell Setzer died by suicide after forming an emotional relationship with an AI companion chatbot. Senator Padilla drafted SB 243 in response.

Implementing crisis referral well is harder than it looks. Keyword-matching is brittle (users express distress in indirect ways). Over-triggering degrades trust and drives users away from the safety net. Under-triggering creates liability. The right approach involves contextual detection that considers conversational patterns, not just individual tokens, and routes to human crisis resources (988 Suicide and Crisis Lifeline, Crisis Text Line) with minimal friction. This is an area where we invest significant engineering effort, and where we do not claim perfection.

What Does the Compliance Timeline Look Like?

Here is what is already in effect and what is coming:

If SB 1119 passes, its annual risk-assessment deadline is July 1, 2027. That is less than a year away. If your data architecture requires significant restructuring to support a child-safety risk assessment, the time to start is now, not when the bill is signed.

How Fragmented Will This Get?

Very. The Future of Privacy Forum's analysis of this wave notes the complexity of an increasingly fragmented state-by-state landscape. Each bill defines "companion chatbot" slightly differently. Each imposes different disclosure, design, and reporting requirements. Some create private rights of action (California). Some impose criminal penalties (the GUARD Act). Some focus on transparency (New Jersey). Some mandate specific content prohibitions (SB 300). Some require annual audits (SB 1119).

If you serve users in multiple states, you are looking at a compliance matrix, not a single checklist. The federal GUARD Act could preempt some of this fragmentation, but given the controversy around its age-verification provisions and the pace of Senate action, state laws will likely remain the primary compliance surface for at least the next 12 to 18 months.

The operators who will navigate this most efficiently are the ones whose architecture produces the smallest possible compliance surface area. Less data retained means less data to audit. Stronger encryption means fewer breach-notification scenarios. Privacy-preserving age signals mean less identity data to protect. This is not a novel insight. But the bills arriving in 2026 are turning it from a design philosophy into a measurable cost advantage.

What Should You Do Right Now?

If you operate a companion chatbot, or build infrastructure that companion chatbots run on, five things:

  1. Audit your current state against SB 243's requirements. It is already enforceable, with a private right of action. If you serve California users and are not compliant, your exposure is accumulating daily.
  2. Map your data retention practices against SB 1119's anticipated risk-assessment requirements. Determine how much of your conversational data you actually need to retain, and whether reducing retention would simplify compliance.
  3. Evaluate your age-verification approach for privacy impact, not just efficacy. If your method requires collecting government ID from every user, consider whether privacy-preserving alternatives (on-device estimation, third-party age tokens) can satisfy the regulatory intent with less data exposure.
  4. Confirm that your safety and compliance layers operate at the application level, not just at the model level. SB 243's non-delegable liability clause means your model vendor's safety features do not satisfy your compliance obligations.
  5. Track the legislative calendar. SB 300, SB 1119, HB 2006, A4732, and the GUARD Act are all in motion. The compliance requirements they impose, if enacted, will require engineering work that takes months, not weeks.

The companion chatbot regulatory category did not exist two years ago. It now spans multiple states, has federal momentum, and creates private rights of action with per-violation damages. The velocity is unusual. The direction is clear. Build accordingly.

If you want to see what privacy-first companion AI looks like in practice, start a free 7-day trial, no card required.

Frequently Asked Questions

What does California's SB 243 require companion chatbot operators to do?

SB 243 requires operators to disclose that users are talking to an AI rather than a human, implement crisis-referral protocols for self-harm risk, meet design requirements to prevent emotional manipulation of minors, and report on compliance in an auditable way. It took effect January 1, 2026, and creates a private right of action with damages of actual harm or $1,000 per violation, whichever is greater, plus attorneys' fees.

Can a company avoid liability under SB 243 by blaming the underlying AI model vendor?

No. SB 243 attaches compliance obligations to whoever offers the chatbot to California consumers, even if it's built on a third-party model, so operators cannot outsource legal responsibility to the model vendor.

What new requirements do SB 300 and SB 1119 add in California?

SB 300 requires operators to prevent their products from producing or facilitating sexually explicit material or propositions, with 'facilitating' implying an affirmative duty to detect and block such content. SB 1119 requires an annual child-safety risk assessment, due by July 1, 2027, that must go to an independent auditor and then to the state Attorney General.

Why are critics concerned about age-verification requirements in these bills?

Critics, including NetChoice regarding Pennsylvania's HB 2006 and ITIF regarding the federal GUARD Act, argue that age-verification mandates force operators to collect additional identity data from all users, not just minors, creating a new privacy attack surface rather than reducing risk.

Besides California, which other states and the federal government have moved on companion chatbot laws?

New York's AI Companion Models statute took effect November 5, 2025, and Georgia, Colorado, Rhode Island, and Washington have all passed their own companion chatbot laws or disclosure requirements. Pennsylvania's HB 2006 and New Jersey's A4732 are advancing through their legislatures, and federally, the GUARD Act cleared the Senate Judiciary Committee unanimously in April 2026 and awaits a full Senate vote.

Sources & References

Michael C.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

Learn more about Selina.ai