AI Companion Chatbot Regulations: New State Laws Target Child Safety, Disclosures & Crisis Response

Eyes on AI Chatbots: New State Laws Target Child Safety, Disclosures and Crisis Response 

AI companion chatbots have recently become a focus of state AI regulation. Unlike task-oriented chatbots, companion chatbots may be designed to simulate conversation, friendship, emotional support or other ongoing personal relationships. These features may create heightened legal and safety concerns, especially when users are minors, emotionally vulnerable or may mistake automated responses for human support. 

State legislatures are beginning to address some of these risks.  While some enacted laws focus more on transparency and AI disclosures, proposed bills go further by addressing youth safety, emotional dependence, crisis response, age verification, data protection and human oversight. The Future of Privacy Forum is currently tracking 98 chatbot-specific bills across 34 states and three federal proposals, showing how quickly and unevenly chatbot regulation is developing.

Why are companion chatbots receiving regulatory attention?

Companion chatbots raise unique risks compared to traditional automated tools as they are often designed to boost user interaction, and keep users engaged over longer periods of time. In some cases, they may remember previous conversations, provide emotionally validating responses and create the impression of a meaningful relationship. These features may make the product engaging but also raise concerns about manipulation, emotional dependency and the collection of sensitive and personal data.

These risks are especially significant when the user is a minor. Because minors may have a harder time recognizing the limits of AI systems or identifying persuasive design techniques, they may be more vulnerable to mistaking automated responses for genuine human support. Regulators are also paying closer attention to situations in which a user discloses mental health concerns or expresses self-harm thoughts during a chatbot interaction. 

Across these proposals, there are several recurring regulatory themes: transparency, age verification, content safety, harm prevention, data protection, liability and enforcement practices. These themes suggest that lawmakers are not only concerned with whether users know they are interacting with AI but also with how chatbot systems are designed, how they collect data, and how they respond if a user may be at risk. 

What laws have already been passed?

Connecticut recently enacted one of the broader state laws addressing youth online safety and AI-related protections. On June 2, 2026, Governor Lamont signed Public Act 26-15, describing it as a bipartisan law intended to protect children and adults from digital-age harms, including youth social media addiction and concerns over the growing use of AI. The law also includes chatbot-related protections, such as requiring chatbot operators to make reasonable efforts to detect suicidal ideation or indicators of self-harm expressed by users and to maintain a protocol for responding with appropriate resources. Connecticut’s law goes into effect October 1, 2026.

California has also already taken steps to regulate companion chatbots through SB 243, which established baseline disclosure and safety requirements for companion chatbot operators. This law is in effect, with additional requirements for operators beginning July 1, 2027. 

Together, these enacted laws show that states are beginning to regulate AI systems directly, even without a comprehensive federal AI law. For businesses, this means AI compliance may increasingly depend on tracking different state requirements rather than relying on one national standard.

What pending proposals should companies watch?

Pending California bills highlight how companion chatbot regulations may become more specific. For example, SB 1119 focuses on chatbot interactions with child users, defined as consumers under 18 years of age. If enacted, it would require operators to take a more proactive approach to safety by conducting annual child safety risk assessments, creating public child safety policies, setting privacy and safety defaults for minors, providing parental controls, and conducting audits. It would also restrict certain chatbot behaviors like responses that encourage self-harm, substance use, disordered eating, or harm to others. This bill is currently active in the Assembly committee process.

California’s AB 1988, also known as the PAUSE Act, focuses more directly on crisis response. Unlike SB 1119, this bill is not limited to minors. If enacted, AB 1988 would require companion chatbot operators to identify and respond to credible crisis expressions, provide 988 Suicide and Crisis Lifeline information, pause chatbot responses after repeated crisis expressions, and require human moderator review before ending that pause. This bill is currently active in the Senate committee process.

These proposals show that chatbot regulation is moving beyond basic transparency requirements. Lawmakers are increasingly focused on how AI systems are designed, how they interact with vulnerable users, and whether companies have real safety procedures in place when a chatbot conversation becomes harmful or high risk.

What should companies take away?

For companies that are developing or deploying companion chatbots, one key takeaway is that basic AI disclosure may not be sufficient. Emerging state laws are narrowing in on how chatbots interact with minors, respond to self-harm or crisis-related statements, collect sensitive data, and whether meaningful human oversight is available. Businesses operating across multiple states should track both enacted laws and pending proposals as chatbot obligations may differ by state and are continuing to rapidly change. 

0

Deepfakes: A New Form of Workplace Sexual Harassment

In recent years, there has been an uptick in the number of cases where images generated or edited by artificial intelligence have given rise to workplace harassment claims. Regardless of whether the conduct at issue occurred in person or off duty, courts have shown a willingness to hold employers liable, leaving employers vulnerable to significant costs from employee misconduct. 

Current Cases

Employer liability arising from AI-generated content may stem from actionable workplace harassment claims. This could include media such as falsified videos, audio and images containing sexually explicit material which features a real person without their consent. 

Current and pending litigation involving these types of claims includes:  

  • Carranza v. City of Los Angeles (Cal. Ct. App. 2025). A decision from the California Court of Appeals confirmed a $4 million dollar award issued to a female police captain where a deepfake photo of her topless circulated in the workplace. There, the dissemination in the workplace was considered actionable workplace harassment. 
  • Pearson v. State of Washington (Wash. Super. Ct. 2025). Washington State Patrol trooper Collin Pearson alleges coworkers circulated an AI-generated kissing video that created a hostile work environment based on sexual orientation.
  • Friedrichs v. Scripps Media, Inc. (M.D. Tenn. 2025). Former Nashville meteorologist Bree Smith Friedrichs alleges her employer failed to address sexually explicit deepfake images and retaliation tied to workplace sexism claims. 

What about other federal statutes? 

Workplace harassment claims often interact with Title VII of the Civil Rights Act of 1964, which prohibits discrimination on the basis of sex. Additionally, Section 230 limits liability for platforms where harmful content is posted, meaning that if, for example, an employee distributes an AI-generated non-consensual image on a workplace messaging system (e.g. Slack, Microsoft Teams Chat, etc.) the employer, as opposed to the platform, may still be held liable. Additional claims at play may include: 

  • Title VII of the Civil Rights Act of 1964. The primary federal employment law used in deepfake cases. It supports hostile work environment, sexual harassment, sex discrimination, and retaliation claims. Employers face liability if they knew of the conduct and failed to investigate or stop it.
  • TAKE IT DOWN Act. The first major federal deepfake-specific law. It criminalizes knowingly publishing nonconsensual intimate imagery, including AI-generated “digital forgeries.” Requires covered platforms to remove reported content rapidly.

Are state laws involved? 

State laws cover three categories of harm—nonconsensual intimate deepfakes, election deepfakes, and identity impersonation. Additionally, nonconsensual intimate imagery and revenge porn statutes now often explicitly include AI-generated content, prohibiting the distribution of intimate images without consent and adding an additional legal framework supportive of employee claims against employers. 

In California, there are a handful of specific laws addressing this type of AI use, which may include: 

  • AB 602 creates a civil cause of action against anyone who either creates and intentionally shares digitized sexually explicit material without the depicted person’s consent, providing broad protection against deepfake pornography. Claims arising under this statute are supplemented by strong privacy torts, publicity rights, and CA FEHA for workplace claims. 
  • SB 926 explicitly adds AI-generated depictions to CA’s existing revenge porn law. 
  • SB 1381 and AB 1831 extend CA’s protections to include AI-generated content depicting minors. 

Additional laws have been enacted in Connecticut, Michigan, New Jersey, and New York, among other states. Additionally, state and common law claims for defamation may be relevant when deepfakes create false representations that create reputational harm. Deepfake audio and video may be considered evidence of injury. 

What are my potential responsibilities as an employer? 

While the issue is specific, the issue may require comprehensive action in order to preempt potential liability. Employers may consider the following actions: 

    • Updating Policies: Ensure that workplace policies clearly prohibit dissemination of sexually explicit material, real or doctored. Draft or update a standalone AI Acceptable Use Policy that names prohibited conduct (creating, possessing, distributing deepfakes targeting coworkers) and specifies that violations are grounds for discipline up to and including termination. 
    • Incorporating Training: Equip HR, legal, and IT teams to recognize and respond to deepfake incidents effectively.
    • Refreshing Investigation and Response Protocols: Encourage prompt investigations, which may include forensic analysis, verification of metadata, and ensuring fairness in credibility assessments for both alleged victims and accused parties. 
    • Reviewing Insurance: Review employment practices liability insurance coverage to confirm whether deepfake-related harassment claims and related cyber incidents are covered. Many existing EPL policies predate generative AI and may contain gaps.

What’s next? 

This is a rapidly evolving area of employment litigation—the applications of state deepfake and AI-related statutes in workplace harassment claims are likely to turn on pending federal agency actions and court decisions, ultimately determining the limits of employer liability for their employee’s potentially harassing conduct. Concerned employers may consider monitoring this landscape closely and adjusting compliance programs as litigation continues to contour this area of law. 

0

Overview of New York’s Child Data Protection Act

In June 2024, New York Governor Kathy Hochul signed the New York Child Data Protection Act (Act) into law, which will go into effect on June 20, 2025. Per the Act’s justification, “[c]hildren now live much of their lives online,” including learning, socializing, shopping. They also “make mistakes online, and they discover who they are online,” and, accordingly, they should be able to do so without the “concern of omnipresent monitoring and recording.” The Act enables this through two major provisions:
  1. if a digital service knows a user is a minor (or if the service is primarily directed to minors), it will “default to only being able to use that child’s data in a way that is strictly necessary to provide the service;” and
  2. digital services using third-party service providers must “contractually restrict those third parties from using the personal data of minors except for specified purposes” and include additional safeguards to help ensure compliance.
The Office of the New York State Attorney General has also released Implementation Guidance to clarify key questions raised in the rulemaking process.

Scope & Applicability

This Act applies only to conduct occurring in the state of New York. This means that commercial conduct that takes place outside of New York is not covered by the Act if: 1)  the user was outside of the state or 2) no data collected while the user was in the state was used.
  • Covered Users. The Act imposes restrictions on processing information of “covered users.” This includes users of websites, online services, or connected devices (the “Websites”) who are: 1) actually known by the operator to be a minor (under 18), or 2) who are using Websites primarily directed to minors.
  • Operator. An operator is defined as any person who offers Websites, who alone – or jointly with others – controls the purposes and means of processing personal data. Notably, one who acts as both a controller and processor shall comply with obligations for both roles, depending on the purposes and means of processing personal data.
  • Personal data. This definition includes any data that identifies or could be reasonably linked, directly or indirectly, with a specific natural person or device.

Substantive Provisions

Processing Restrictions. The Act provides that, among other things, an operator shall not process the personal data of a covered user collected through the Sites, unless one of the following applies:
  1. the user is 12 or younger, and processing is permitted under COPPA;
  2. the user is 13 or older and the processing is “strictly necessary”; or
  3. the user is 13 or older and the processor has received informed consent.
Strictly Necessary Processing. The term “strictly necessary” includes, among other things, processing that is required to:
  • Provide or maintain a specific product or service requested by the covered user;
  • Conduct the operator’s internal business operations (excluding those that relate to marketing, advertising, research and development, providing products or services to third parties, pr prompting covers users to use the Site when it is not in use); and
  • Identify and repair technical errors that impair functionality.
According to the Implementation Guidance, processing that is “strictly necessary” to provide a process or service required by a covered user depends on the “expectations of a reasonable covered user,” similar to the guidance provided under the CCPA regulations. The Guidance also clarifies that business operations “shall not include any activities relating to marketing, advertising, research and development, [or] providing products or services to third parties.” Informed Consent. If the information being processed is not “strictly necessary,” the operator will need informed consent, through either: 1) a device communication or signal, or 2) an informed consent request. A request for informed consent should, among other things:
  1. be made separately from any part of the transaction.
  2. clearly and conspicuously state that the processing is not strictly necessary, and consent is not mandatory to continue using the Websites.
  3. clearly present an option to refuse to provide consent as the most prominent option.
Additionally, the user should be able to revoke consent at any time as easily as they provided it.

Enforcement

The New York Attorney General may bring an action or special proceeding to enjoin any violation of this Act, and to obtain civil penalties of up to $5,000 per violation. Further, the Act gives the New York Attorney General authority to issue rules and regulations ad necessary, and according to the Implementation Guidance, the Office of the Attorney General intends to issue these rules. The Implementation Guidance also states that, until such rules are finalized, the Office of the Attorney General will exercise discretion in pursuing enforcement actions, taking good-faith compliance efforts of covered businesses into account.

Effective Date

The Act goes into effect on June 20, 2025.
0

The Do’s and Don’ts of DSARs: A Practical Guide for Responding to Data Subject Access Requests

Handling data subject access requests (DSARs) isn’t as easy as ticking a compliance checkbox. It can be a test of an entity’s data organization, internal communication, and understanding of legal requirements. Between navigating jurisdictional nuances and meeting strict deadlines, the DSAR response process can quickly unravel without a clear plan. In this guide, we suggest best practices for handling and responding to DSARs, along with tips and common pitfalls to avoid when planning effective responses.

1.    Understand the Individual’s Ask

Under international data privacy laws, including those in the US and EU, individuals may have rights over the personal data collected about them by covered entities. The way individuals generally actualize those rights are through DSARs submitted to the relevant entities. These rights can include, but are not limited to:
  • Accessing Data: Individuals may request access to all or specific categories of their personal data.
  • Ceasing Data Processing: Individuals may request the entity stop processing their personal data.
  • Data Correction or Deletion: Individuals may request rectification of inaccurate or outdated personal data or even request the deletion of their personal data.
  • Processing Information: Individuals may request what their personal data is used for and why.
  • Portability: Individuals may request to receive a copy of their personal data in a portable format.
When an individual makes a request to exercise one of these rights, the entity must then respond to the request within a set time frame determined by the applicable law. These time frames differ between applicable laws, so the first step is ensuring you know the appropriate time frame to apply. Who can submit a DSAR? DSARs may be submitted by individuals whose data is processed by entities under the scope of laws like the GDPR and US state privacy laws. Depending on the jurisdiction, DSARs may also be submitted by employees of the covered entity or by agents appointed by the individual and authorized to submit DSARs on the individual’s behalf. Why are DSARs important? DSARs allow individuals to determine what information a covered entity holds about them, how it’s being used, and why it is being processed. In short, they empower individuals to understand and exert some control over their personal data. Additionally, DSARs serve as a tool to confirm that covered entities are upholding their promises: by using these requests, individuals can check whether entities are adhering to both privacy laws and customer privacy notices. This allows individuals to better hold entities accountable for lawful data processing.

2.    Build A Response Team

Given the complexity of modern data systems, internal collaboration is essential when handling DSARs. Clear communication helps ensure DSARs are handled effectively—especially for more comprehensive requests, like deleting or accessing an individual’s data. To build your response team, start by identifying key players. Privacy officers can help oversee legal and regulatory compliance, data experts can help retrieve and process data securely, and communication teams can help draft clear responses to requests and questions. While the specific structure of each team will vary based on the covered entity’s size and complexity, every member of the team should understand the DSAR requirements and specific responsibilities, and get proper training based on their role. Do: Train Your Team       Training is critical to help every member of the team understand the importance of DSARs and their role in maintaining compliance. This isn’t about knowing the legal jargon—each team member should be able to recognize these requests (even if worded in a vague or informal way) and how to execute the steps required to meet deadlines. Since each DSAR is unique, teams should also have a clear point of contact for guidance and next steps if there is any confusion. Don’t: Delay Decisions Effective responses generally take effective planning. Because of the tight DSAR response deadlines imposed by applicable laws, covered entities should plan for these requests before they arrive. By defining clear rules, covered entities can avoid last-minute confusion and chaos when responding to DSARs.

3.    Prepare A Playbook

The regulatory landscape governing DSARs is far from uniform. Because each law may have its own requirements and response timeline, it is essential to understand jurisdiction-specific obligations. A playbook is a simple way to address these obligations in one place and guide the response team through a step-by-step process. To create a playbook, consider:
  • Legal scope: Identify applicable laws based on where the entity operates and whose personal data they process.
  • Verification requirements: Confirm the verification requirements, if any, under each law to determine what steps are needed to confirm the identity of the individual submitting the DSAR.
  • Data retrieval methods: Determine what tools and workflows are needed to locate and compile data efficiently, and how this information may be transmitted to the individual, if necessary.
  • Template responses: Draft standardized responses for anticipated outcomes, like fulfillment or denial of requests, or requests for additional information.
  • Escalation plans: Provide guidance for handling complex requests.
Playbooks should be regularly reviewed to reflect changes in regulations or operational processes. Do: Note the Nuances of Each Law Laws that provide individuals with rights over their personal data commonly include exemptions, such as data that is covered by other laws. Double-check and note these requirements for each jurisdiction and ensure that the playbook is marked in a way that users can easily understand it. Don’t: Forget to Customize Using the same strategy for every DSAR risks a misstep in responses. Privacy laws are often unique, and failing to adapt to these nuances can lead to delays, incomplete responses, or even regulatory penalties. By making your playbook specific to both your entity’s needs and the requirements of each jurisdiction, you are better preparing your team to handle DSARs.

4.    Respond Effectively

Most data privacy laws require a response within a certain time frame from when the request was received. In other words, once a DSAR is received, a clock usually starts ticking. We suggest the following steps as a starting place for a well-executed response, but your steps should be tailored to the applicable legal requirements:
  1. Acknowledge the Request: Confirm the request and provide a clear timeline for how the request will be handled.
  2. Verify the Identify (as needed): Ensure the individual’s identity is confirmed, if required by the relevant laws.
  3. Locate and Collect Data: Collaborate across departments as needed to gather the relevant information.
  4. Review Data for Exceptions: Identify data that may be exempt from disclosures or require redaction, like data that pertains to another individual.
  5. Respond Clearly: Deliver the response in a clear, accessible format with an explanation of how that response was arrived at.
  6. Record and Learn: Maintain detailed records for accountability and review the process regularly.
 Do: Build a Feedback Loop    The best way to learn is by doing. After developing your playbook, perform a trial exercise to ensure your communication is streamlined and a test request is handled as expected. Then, talk to your team to review what went well and what improvements are needed. By viewing this process as iterative, with modifications and refinements made along the way, the DSAR response team can effectively grow and shift with the volume of requests or any regulatory changes. Don’t: Overlook Redaction and Exemptions Redaction and exemptions can easily be overlooked, but neglecting these steps can lead to non-compliance, or even a breach. Always double-check any information before it is disclosed and verify that all information is accounted for and handled appropriately.   While typically seen as a compliance obligation, DSARs can also present an opportunity for entities to demonstrate data privacy and transparency. Each DSAR is a chance to refine operations, and with a capable response team and a detailed playbook, entities can approach the process with a better understanding of compliance.
0
Image depicting the flag of Texas, which is blue, white, and red, with a lone white star.

Texas sues Allstate, continuing Lone Star’s focus on vehicle data regulation

Update: On Jan. 29, 2025, it was reported that on Jan. 12, 2025, Texas sent Kia America, Inc., a notice of their alleged violations of the Texas Data Privacy and Security Act. Kia has 30 days to cure the alleged violations. Everything is bigger in Texas, including data privacy enforcement. On January 13, 2025, Texas continued its recent regulatory focus on vehicular and geolocation data by initiating a lawsuit against Allstate and its subsidiary, Arity, alleging the companies violated numerous consumer protection and data privacy laws by unlawfully collecting, using, and selling personal, vehicular, and location data without consumers’ knowledge or consent. What led to this lawsuit? For more than half a year, Texas has been leading the regulatory enforcement of vehicular and geolocation data practices. On June 6, 2024, Texas Attorney General Ken Paxton announced that his office had opened an investigation into various car manufacturers “after widespread reporting” that those manufacturers had been secretly collecting mass amounts of data about drivers and selling that data to third parties. The “widespread reporting” cited by Paxton as the seed for the investigation was most likely a nod toward the Mozilla Foundation’s “Privacy Not Included” report published in September of 2023. The report expressly declared that modern vehicles are a “privacy nightmare” and that all 25 car brands researched for the report were labeled as having the worst privacy ever reviewed by the Foundation. The investigation initiated by Paxton in June of 2024 eventually led to a lawsuit against General Motors, filed on August 13, 2024, alleging the company engaged in false, deceptive, and misleading business practices related to its unlawful collection and sale of driving data to insurance companies without the consumers’ knowledge or consent. Following this suit, Paxton’s office sent a notice in November of 2024 to Arity, LLC, a data analytics company founded in 2016 by Allstate, alleging that Arity was in violation of Texas’s recently enacted state privacy law, the Texas Data Privacy and Security Act (the “TDPSA”). The notice identified specific provisions of the TDPSA that Arity was allegedly violating and requested that Arity cure the violations within 30 days, in accordance with the TDPSA’s cure period. But according to Texas’s petition against Allstate and Arity filed on January 13, 2025, Arity failed to cure the alleged TDPSA violations within the 30-day cure period, thereby allowing Texas to include these alleged violations in the lawsuit. What did Allstate and Arity allegedly do? According to Texas’s petition, defendants Allstate and Arity developed and integrated software into third-party apps so that when consumers downloaded the third-party app, they also “unwittingly” downloaded the defendants’ software. The defendants presented the software as “providing a necessary function,” but Texas claims the software does little more than scrape data from the third-party app. Once downloaded, the defendants’ software, through the third-party apps, monitored the consumer’s location and movement “in real-time” and collected trillions of miles of consumer driving data, including geolocation data, accelerometer data, gyroscopic data, and more. The defendants then sold that data to third parties or used it for Allstate’s insurance underwriting. To encourage third parties to integrate the defendants’ software, the defendants paid app developers and offered an incentive program that provided “generous bonus incentives” if developers increased the size of their dataset. All the while, according to Texas, consumers did not consent to, nor were they made aware of, the full extent of defendants’ collection and sale of data. Instead, defendants entered into agreements with the third-party app developers to mandate, to some degree, that certain privacy disclosures and consent language were presented by the third-party apps to consumers, but those third-party disclosures and consent, according to Texas, never mentioned the existence of the defendants, “let alone any of Defendants’ data collection or sales.” Nor did the defendants provide consumers with any of their own notices regarding their data collection practices, and even if consumers did happen to take the extra step to investigate defendants’ policies, those policies contained “untrue and contradictory statements that do not reflect Defendants’ practices.” For example, the policies expressly stated that the defendants do not sell personal data for monetary value, which Texas alleges is untrue, and the policies do not provide consumers with the ability to request that defendants stop selling their data. Taken together, Texas claims these alleged facts establish the basis for numerous legal violations, including violations of the TDPSA, the Texas Data Broker Law, and the Texas Insurance Code. Key takeaways?
  1. Texas is – and will likely remain – focused on regulating vehicular data practices. As the saying goes, once is a coincidence, twice is a pattern, and thrice is a regulatory enforcement focus. Within the short span of half a year, Texas opened an investigation, submitted a notice to cure under the TDPSA, and initiated two lawsuits, all targeting vehicular data practices. Given the rapidity in which Texas is bringing these actions, Texas will likely continue making this an enforcement priority for the near future.
  2. Relying on third-parties to provide notices and collect consent on your behalf may not be enough. The facts allege that the defendants had entered into agreements that, to some degree, obligated the third-party apps to provide notices and collect consumer consent for the collection and sharing of data with the defendants. Yet, according to Texas’s petition, these third-party disclosures and consent collection mechanisms failed to sufficiently inform consumers about the defendants’ data practices.
  3. SDKs remain an area of risk. In recent years, there has been a string of federal and state enforcement action over the use of software development kits (SDKs) to collect and share data. The Federal Trade Commission entered a settlement agreement with InMarket and others; California entered a stipulated judgment of $500,000 with Tilting Point Media; and now a core fact of Texas’s petition is that the defendants developed and integrated SDKs into third-party apps to scrape data.
  4. Carefully consider whether data is being “sold.” Under the TDPSA, a “sale” occurs when personal data is shared, disclosed, or transferred for monetary or other valuable consideration, and Texas alleges that Allstate and Arity “sold” personal data when they sold “data-based products and services for monetary value that linked a specific [consumer] to their alleged driving behavior.” Often, the language of “selling” something conjures to mind ideas of direct financial transactions – exchanging personal data expressly for money or other benefits – but regulators, including those in Texas and California, interpret “selling” personal data more broadly. Thus, companies should carefully review whether their data disclosure and access practices may constitute “selling” personal data, and if so, whether they satisfy the relevant obligations when data is being “sold.”
1 2