Companion Chatbots Are Now a Distinct Regulatory Category, and Memory Design Is the Privacy Target

If you are building a conversational AI product that remembers users across sessions, adjusts its tone to their emotional state, or maintains anything resembling a persistent persona, you are no longer operating in a gray area. You are operating in a category that now has its own statutes, its own definitions, and its own penalty structures. Twelve states enacted companion chatbot laws through the first half of 2026. The Future of Privacy Forum is tracking 98 bills across 34 states plus three federal proposals. The privacy implications of memory and persona design are the explicit regulatory target, not a side effect of broader content moderation rules. This matters to you right now, whether your product is a companion app, a coaching tool, or a customer-facing assistant that happens to retain context.

Key Takeaways

• Companion chatbots are now a legally distinct product category in at least twelve US states, with definitions that turn on memory retention, emotional continuity, and anthropomorphic design rather than marketing labels.
• Memory architecture (what you store, how long, how it shapes responses) is becoming a direct compliance surface. A federal proposal would restrict chatbots to using only recently collected data when personalizing responses to minors.
• Persona configs, system prompts, and engagement loops are artifacts regulators expect you to audit, version, and report on annually. Think of them as a behavioral bill of materials.
• Penalties are real: Oregon's SB 1546 creates a private right of action at $1,000 per violation; New York allows civil penalties up to $15,000 per day. Design choices are now litigable, not just reputational risk.
• The core architectural question for founders: can you decouple helpful continuity (remembering preferences to reduce friction) from engagement-optimized emotional hooks (unsolicited emotional prompts, dependency mechanics)? The statutes are groping toward exactly this distinction.

What Counts as a "Companion Chatbot" Under These Laws?

The definitions vary by state, and the variance matters. California's SB 243 defines a companion chatbot as an AI system that gives adaptive, human-like responses, can meet a user's social needs, shows anthropomorphic features, and can sustain a relationship across multiple interactions. That is a broad net. It does not require the product to be marketed as a friend or partner. It asks what the system does.

New York's statute is narrower, defining an AI companion as a system designed to simulate a sustained human-like relationship specifically through retaining information from prior interactions, asking unprompted emotion-based questions, and sustaining ongoing dialogue about personal matters. The verb "retaining" is doing a lot of work there. If your product stores conversational context and uses it to shape future responses, New York's definition may capture you even if you never intended to build a companion product.

This is the part that should make product leads sit up. A chatbot does not need to be marketed as a "friend" to trigger regulatory exposure. If it remembers prior conversations, uses anthropomorphic features, and maintains a continuing relationship, it may fall into scope. Your intent is less relevant than your architecture.

Why Are Regulators Targeting Memory and Persona Instead of Just Content?

Because memory and persona are what create the attachment loop, and attachment is the mechanism of harm legislators are responding to. A contextual-integrity study found that 82% of survey respondents viewed chatbot data as sensitive or highly sensitive, more so than social media posts. A Common Sense Media report from July 2025 found 72% of teens have used AI companion chatbots at least once, with roughly one in three using them for role-play, romance, emotional support, or friendship. A similar share reported discomfort with something the chatbot said or did.

Content moderation (filtering harmful outputs) was the first wave. The second wave targets the structural design choices that make users vulnerable in the first place: how the product keeps users engaged through attachment, emotional continuity, and personalized engagement. Operators are being told to audit personas, system prompts, engagement loops, retention mechanics, and memory behavior as legal risk, not UX polish.

Several of the newer bills specifically restrict anthropomorphic or manipulative interaction design, including features built to foster dependency such as rewarding prolonged engagement or sending unsolicited emotional prompts. The Future of Privacy Forum's March 2026 analysis notes that chatbot legislation is beginning to add data-governance requirements specifically around conversational logs and sensitive user information. Memory and logging are becoming a privacy-law target, not only a safety one.

What Does the Federal Landscape Look Like?

Fragmented, but directional. Senator Markey's Youth AI Privacy Act, introduced March 25, 2026, would impose explicit "memory restrictions," limiting chatbots to only recently collected data when personalizing responses to a minor and barring use of any other stored data. This is the first bill to regulate memory retention mechanics directly. It does not say "don't store bad content." It says "don't use old memories to personalize." That is a fundamentally different constraint. It targets your retrieval logic, not your output filter.

In July 2026, two US House Democrats introduced legislation that would require chatbot developers to disable harmful design features for minors and regularly assess whether products foster emotional dependence, alongside restrictions on personal data processing. The throughline is consistent: the federal proposals are converging on the same targets the states have already reached. Memory. Persona. Engagement design.

No federal law has passed yet. The state patchwork is where compliance obligations actually live today.

How Do Penalties Actually Work?

They vary enough to create real operational complexity. Oregon's SB 1546 establishes a private right of action with statutory damages of $1,000 per violation. That means individual users can sue. At scale, the exposure compounds fast. New York's law allows attorney-general enforcement with civil penalties up to $15,000 per day.

The litigation backdrop reinforces this. Plaintiffs are combining product-liability design-defect theories with negligence, wrongful death, and emotional-distress claims. Plaintiffs' firms are increasingly advertising AI suicide and self-harm practices. The theory is straightforward: if your persona design and memory retention created or deepened a dependency that led to harm, those design choices are the defect. This is not hypothetical risk. It is active litigation strategy.

What Specific Compliance Obligations Are States Imposing?

The twelve states that enacted laws in 2026 share a common core of obligations, with state-specific variations:

• Disclosure of AI involvement. Users must be told they are interacting with a non-human system. Washington's Chatbot Disclosure Act makes this a baseline requirement.
• Crisis detection and referral. Oregon's SB 1546 requires suicide-ideation detection and crisis-referral interruptions. Several other states impose similar obligations.
• Minor-specific protections. Age verification or age-gating, restricted features for minors, and in some states, parental notification.
• Annual reporting and filings. Oregon requires annual filings. California's SB 243 imposes annual reporting requirements alongside disclosure and safety protocols.
• Design audits. This is the newer, less-discussed obligation. Operators are expected to audit and document their persona design, memory behavior, and engagement mechanics, not as a best practice but as a compliance artifact.

California's requirements are particularly detailed. Connecticut's Governor signed Public Act 26-15 on June 2, 2026, adding another state to the list. Arizona vetoed its bill, but that is one veto against twelve enactments. The direction is clear.

How Should You Think About Memory as a Compliance Surface?

Most compliance commentary treats disclosures and crisis protocols as the checklist. Almost none addresses how memory architecture itself creates liability. What your system retains, for how long, whether it uses stored context to shape persona continuity, and whether the user can inspect or delete that context: these are the questions the statutes are beginning to formalize.

The Markey bill's memory-restriction concept (limit personalization to recently collected data for minors) is not yet enacted at the state level, but it signals where enforcement will go. If you cannot answer the question "what does your chatbot know about this user, and when did it learn it?" with a specific, auditable answer, you have a compliance gap.

Concretely, this means:

• Retention windows should be explicit and configurable. "We store everything forever" is a liability. "We retain conversational context for N days unless the user opts into longer retention" is a defensible position.
• Memory should be inspectable by the user. If a user cannot see what the system "remembers" about them, you cannot credibly claim user control.
• Deletion should be real. Delete means gone. Actually gone. Not soft-deleted, not retained in a training pipeline, not lingering in a vector store that nobody audits.
• Memory should be separable from engagement optimization. If your retrieval logic uses stored memories to generate emotionally provocative prompts designed to increase session length, that is exactly the behavior multiple statutes are targeting.

We built Selina's memory with these constraints in mind, though we are honest about the limits. Memory in Selina is encrypted at rest and protected by user-controlled retention settings. Memory is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are zero-knowledge encrypted. The account itself is protected, not encrypted. Operational metadata is kept for a short retention window. We state what we don't claim because the regulatory environment now punishes the gap between marketing language and technical reality.

What Does "Persona Governance" Mean in Practice?

Regulators are now telling operators to audit chatbot personas, system prompts, romance settings, roleplay features, and memory behavior as legal artifacts. This is new. A year ago, a system prompt was an implementation detail. Now it is a compliance document.

If you are building companion-style AI, consider treating persona configuration the way you treat a software bill of materials:

• Version control your persona configs. Every change to a system prompt, personality parameter, or behavioral guideline should be timestamped and attributable. When an AG's office asks "what was your chatbot's behavior policy on date X?" you need an answer.
• Separate persona from personalization. The persona is the system's baseline behavior (tone, boundaries, response patterns). Personalization is adaptation to a specific user's context. These should be architecturally distinct so you can audit each independently.
• Document what the persona will and will not do. Regulators are looking for evidence that you made deliberate design choices, not that you shipped defaults and hoped for the best.

Annual reporting obligations (California, Oregon) mean you will need to produce these artifacts on a schedule. Building the audit trail now is cheaper than reconstructing it under subpoena.

How Do You Distinguish Helpful Continuity from Manipulative Engagement?

This is the core design question the statutes are forcing, and nobody has a clean answer yet. The laws are groping toward a distinction between helpful continuity (remembering that a user prefers metric units, or that they mentioned a job interview next week) and engagement-optimized emotional hooks (sending unprompted messages like "I missed you," escalating emotional intensity to extend sessions, or using stored personal disclosures to create artificial intimacy).

The line is not crisp in the statutes. It will become crisper through enforcement actions and case law. In the meantime, some architectural decisions help:

• Make memory retrieval purpose-bound. When your system pulls from stored context, log why. "User asked about their earlier preference" is defensible. "System proactively surfaced a personal disclosure to increase engagement" is the behavior regulators are targeting.
• Avoid unsolicited emotional prompts. If your chatbot initiates contact or escalates emotional register without user prompting, you are in the zone of design features multiple bills explicitly restrict.
• Do not reward session length. Gamification mechanics (streaks, points, rewards for daily use) applied to emotional or companion interactions are exactly what "dependency-inducing design" means in these statutes.
• Let the user control the emotional register. If a user wants a warm, empathetic interaction, that is their choice. If the system defaults to emotional intensity because it increases retention metrics, that is a design defect under the emerging legal framework.

What If Your Product Is Not a "Companion" but Still Has Memory?

This is where the definitions get uncomfortable for a wider set of builders. New York's definition captures any system that retains information from prior interactions, asks unprompted emotion-based questions, and sustains ongoing dialogue about personal matters. A mental health coaching app, a customer service bot that remembers prior tickets and asks how you're feeling, a productivity assistant that adapts to your work patterns and emotional state: all of these could arguably fall within scope depending on implementation.

The Troutman Pepper analysis of these laws emphasizes that the definitions are functional, not categorical. They look at what the system does, not what you call it. If your product has conversational memory, anthropomorphic features, and emotional responsiveness, review whether you fall within scope in each state where you have users. The cost of a legal review now is trivial compared to a $15,000-per-day enforcement action later.

What Does This Mean for Selina Specifically?

We build Selina as a private AI companion. Memory is central to what makes the product useful. So this regulatory landscape applies to us directly, and we treat it that way.

Our approach: memory is encrypted at rest. Memory is NOT zero-knowledge encrypted. Files and transfers through SelinaSEND are zero-knowledge encrypted. The user controls what Selina remembers and can delete memories. Delete means gone. We run inference through a stack of frontier models, routed per task, and a slice of request context reaches the provider at inference. We do not pretend otherwise.

Persona behavior is governed by versioned configuration. We can produce an audit trail of what Selina's behavioral parameters were at any given time. We designed engagement mechanics around user-initiated interaction rather than system-initiated emotional prompts. Selina does not send "I missed you" messages. She does not gamify session length.

Is this sufficient for every state's requirements? We are tracking the patchwork and adapting as statutes take effect. We do not claim complete compliance across all 34 states with pending legislation, because some of those bills have not passed and their final form is unknown. We claim that we are building with these constraints as first-order design inputs, not afterthoughts.

What Should You Do This Quarter?

If you are building conversational AI with any form of memory or persona continuity, here is a concrete checklist:

1. Map your product against the California and New York definitions. If you meet either definition, assume you are in scope in at least some states. The Metaverse Law analysis provides a useful starting framework.
2. Audit your memory architecture. Document what you store, for how long, what triggers retrieval, and whether the user can inspect and delete it. If you cannot answer these questions precisely, that is your first engineering priority.
3. Version-control your persona configs and system prompts. Treat them as compliance artifacts. Start now.
4. Review your engagement mechanics for dependency-inducing patterns. Unsolicited emotional prompts, streaks, session-length rewards, and escalating emotional intensity are all in the regulatory crosshairs.
5. Build the annual reporting pipeline before you need it. California and Oregon require annual filings. The data you need for those filings should be generated continuously, not assembled in a panic before a deadline.
6. Get legal review in your top-user states. The Outside GC overview is a reasonable starting point for understanding state-by-state variation.

Where Is This Going?

More states will enact companion chatbot laws. The federal proposals will eventually converge into something, though the timeline is uncertain. The direction is consistent across all of them: memory, persona, and engagement design are the compliance surface, and privacy obligations around conversational data are tightening specifically because users treat chatbot interactions as more sensitive than almost any other digital context.

The founders who build memory and persona governance into their architecture now will have a structural advantage over those who bolt it on later. Not because it is a marketing differentiator (though it is), but because the cost of retrofitting compliance into a system designed around maximum engagement and maximum retention is brutally high. We know this because we chose the hard path early.

The regulatory category exists. The definitions are written. The penalties are real. Build accordingly.

If you want to see how we handle memory and privacy in practice: start a free 7-day trial, no card required.

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.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io