Author: Clearon AI

States are starting to regulate companion and conversational AI around the same basic concerns: users mistaking a bot for a person, chatbots mishandling signs of self-harm, and minors being exposed to sexual or manipulative interactions.

The statutes take different routes. Definitions, effective dates, reporting duties, content restrictions, and remedies vary from state to state. Compliance with one law does not necessarily cover another.

This guide tracks enacted state laws that directly regulate conversational or companion AI. It separates those laws from broader children’s online-safety statutes, mental-health practice restrictions, and pending bills.

Last reviewed: July 29, 2026.

Quick Comparison

The table is a screening tool, not a substitute for reading the statute. Coverage can turn on how a service is marketed, whether it sustains a relationship across interactions, whether the operator knows or should know that a user is a minor, and whether an ordinary transactional chatbot is excluded.

What These Laws Have In Common

Most states start with nonhuman notice

Most of the laws require some form of clear notice that the user is interacting with AI rather than a person. The timing differs. Some states focus on the beginning of the interaction. Others require repeated notices, especially for minors or extended sessions.

Writing the notice is the easy part. Companies still need to decide which products qualify, where the notice appears, whether it follows the user across devices, and what records show that it was delivered.

Crisis response is now part of product compliance

Hawaii joins a growing group of states requiring protocols for suicidal ideation or self-harm. These provisions commonly require the operator to identify covered expressions and direct the user to an appropriate crisis service.

The statutes do not all use the same trigger or prescribe the same response. A national program needs a documented detection standard, escalation logic, referral content, testing process, and review owner.

The minor protections reach beyond age gates

Several 2026 laws regulate what the chatbot may say or do after a minor enters the product. Common subjects include sexually explicit material, simulated romantic or dependent relationships, addictive reward systems, isolation from family or friends, secrecy, spending pressure, and design intended to prolong use.

Age assurance is one part of the problem. Operators also need a defensible way to apply the correct experience when they know, or have reason to know, that a user is a minor.

Reporting and remedies vary sharply

Hawaii requires annual reporting to its Behavioral Health Administration. California, Oregon, and Rhode Island also use reporting mechanisms, but the recipients and required data differ. New York relies on Attorney General enforcement. Oregon adds a private action. California provides a separate limited civil remedy. Idaho and Nebraska expressly reject a private right of action.

These differences affect records, litigation exposure, incident review, and contract allocation. A generic safety policy will not cover all of them.

Why Hawaii Act 248 Matters

Hawaii’s Act 248 puts several recurring duties in one law: nonhuman disclosure, suicide and self-harm protocols, protections for minor account holders, annual reporting, and unfair-or-deceptive-practice enforcement.

Hawaii also shows how far this issue has moved beyond California and New York. A company offering one national product may face similar duties through different state statutes, agencies, and enforcement routes.

Laws That Are Related But Not Direct Equivalents

Several enacted laws belong in the same risk review without fitting neatly into the main comparison:

• New York’s Safe By Design Act addresses child accounts on online platforms and disables integrated AI chatbots by default, subject to parental controls.
• South Carolina’s H 3431 is a broader minors’ online-safety and reasonable-care statute rather than a dedicated companion-chatbot law.
• Wyoming’s HB 102 targets intentionally designed or distributed systems involving specified self-harm promotion and sexual deepfake harms, with a narrower and more punitive structure.
• Maine and Utah regulate aspects of AI-delivered therapy, mental-health representations, or professional services.
• Rhode Island separately enacted restrictions involving AI and mental-health care.

These measures can affect the same product or vendor review, but they should not be described as interchangeable with Hawaii’s Act 248.

Pending Measures

Pending bills belong in a separate watchlist. They do not create current compliance duties.

New York’s S 9051-B/A 10379 passed both legislative chambers in 2026 and would impose additional minor-facing companion safeguards. Its provisions should not be treated as enacted unless the governor signs it or it otherwise becomes law.

Other states continue to consider bills addressing age assurance, parental consent, sexual content, emotional dependence, professional impersonation, and crisis response. This guide will move a state into the main table only after enactment can be confirmed through an official source.

A Practical Multistate Review

Companies offering emotionally responsive, relationship-oriented, or highly personalized conversational AI should be able to answer:

1. Which products fall within each state’s companion or conversational-AI definition?
2. Which ordinary business, customer-service, productivity, or professional tools are excluded?
3. Where and how often does the product disclose that it is AI?
4. How does the product detect and respond to suicide, self-harm, or threats of violence?
5. What changes when the user is known or reasonably believed to be a minor?
6. Which engagement, sexual-content, role-play, or spending features must be disabled?
7. What must be reported, to whom, and on what schedule?
8. Which duties belong to the operator, model developer, distributor, or contracting customer?
9. What evidence shows that safeguards were tested and notices were delivered?
10. Which states permit private claims in addition to government enforcement?

Start with a product inventory tied to the state definitions. Then build a control matrix that assigns each duty to an owner and records the supporting evidence, effective date, and reporting deadline.

Sources

• California SB 243
• Colorado HB 26-1263
• Colorado Attorney General AI rulemaking page
• Connecticut Public Act 26-15
• Georgia General Assembly legislation search
• Hawaii SB 3001
• Hawaii Governor announcement concerning Act 248
• Idaho S 1297
• Iowa SF 2417
• Nebraska LB 525
• New York Governor notice concerning Article 47
• Oregon SB 1546
• Rhode Island General Assembly announcement
• Washington HB 2225

This guide is general information, not legal advice. Statutory text, amendments, effective dates, rules, and official guidance should be checked for each product and jurisdiction.

AI agents create a different kind of legal problem from chatbots that only answer questions.

An agent can open an account, send a message, retrieve records, change a file, place an order, run code, or call another system. It may take several steps without asking a person to approve each one. If one of those actions causes harm, saying that the system acted on its own will not settle who is responsible.

California has now made that point explicit. Assembly Bill 316, effective January 1, 2026, says that a defendant who developed, modified, or used AI alleged to have caused harm cannot defend the case by asserting that the AI autonomously caused the harm.

The law does not make every AI developer or user automatically liable. A plaintiff must still prove the elements of a claim. Defendants may still dispute causation and foreseeability, raise other affirmative defenses, and present evidence about another person or entity's comparative fault.

But one escape route is closed. A company cannot place an AI agent between itself and the consequences of an action, then treat the agent's autonomy as the end of the responsibility analysis.

The Short Answer

• AI agents are not independent legal persons that absorb liability for the people and companies using them.
• Responsibility will depend on the claim, the harmful act, who built and deployed the system, who gave it authority, and what controls each party could reasonably exercise.
• The developer, deploying company, employee, vendor, and management team may face different theories of responsibility for the same incident.
• Contracts can allocate losses between companies, but they usually do not erase duties owed to regulators, consumers, employees, or other injured parties.
• The most useful evidence will often be operational: permissions, instructions, approval records, tool calls, logs, testing, warnings, and incident response.

California Has Rejected The Simplest Version Of “The AI Did It”

AB 316 is short, but its language reaches a broad set of actors. It applies to a defendant who "developed, modified, or used" artificial intelligence alleged to have caused harm.

That wording matters. The statute is not limited to frontier-model companies. It can reach a business that configures or deploys a third-party system, as well as a developer that builds one.

The statute also avoids declaring who must lose a case. It does not create strict liability. It does not say every unexpected output was foreseeable. It does not eliminate disputes over whether the AI actually caused the injury. And it preserves evidence about the comparative fault of other people and organizations.

Its point is narrower: autonomy by itself is not a defense.

Utah took a related approach in its Artificial Intelligence Policy Act. In covered consumer-protection matters, a person remains responsible for a violation committed through generative AI even when the AI made the statement or undertook the act at issue. These statutes address different conduct, but they share a basic premise. Businesses remain accountable when they choose AI as the means of acting.

Existing Law Still Does Most Of The Work

There is no single federal statute that assigns every AI-agent loss to a developer, deployer, or user. Courts and regulators will often start with laws that already govern conduct.

Depending on the facts, a dispute may involve negligence, product liability, contract, fraud, consumer-protection law, privacy, discrimination, employment law, professional duties, intellectual property, or computer-access restrictions.

That means the answer to "who is responsible?" changes with the act.

If an agent makes an unauthorized purchase, the dispute may focus on actual and apparent authority, contract terms, payment controls, and ratification. If it rejects a job applicant, employment-discrimination and automated-decision rules may dominate. If it retrieves protected data, privacy and security duties may matter most. If it sends a false claim to a customer, consumer-protection and misrepresentation theories may apply.

Agentic AI makes the factual chain more complicated. It does not remove the governing law.

Responsibility Can Sit In Several Places At Once

The Developer

A developer may face scrutiny when the system's design creates an unreasonable risk, when safety claims exceed actual testing, or when known limitations are not disclosed to customers.

The harder cases will involve systems sold for action rather than advice. A developer that markets an agent as capable of operating business systems may be asked what it knew about unauthorized actions, prompt injection, credential misuse, error recovery, and escalation to a human.

The developer will also want evidence showing where its role ended: what controls it supplied, what instructions the customer added, what integrations the customer selected, and whether the harmful behavior came from a material modification outside the developer's control.

The Deploying Company

The organization that gives an agent credentials, data, tools, and a business objective will often be the most visible target.

That company decides whether the agent may read or write, recommend or execute, draft or send. It chooses which systems the agent can reach and whether a person must approve a consequential action. It also decides whether the agent operates in hiring, finance, health, legal work, customer service, or another regulated setting.

Those choices can matter more than the fact that the underlying model came from a vendor.

The Employee Or Operator

Individual responsibility will depend heavily on the setting and the person's conduct.

An employee who follows an approved workflow in good faith is differently situated from someone who bypasses controls, grants excessive permissions, ignores warnings, or uses an agent for an unauthorized purpose. Professional rules may add another layer for lawyers, clinicians, financial professionals, and others who cannot delegate their duties simply by using software.

Employers may also face responsibility for employee conduct within the scope of work. Calling an agent a personal productivity tool does not necessarily resolve that question if the company approved, encouraged, or benefited from its use.

Vendors And Integrators

Many agent systems are assembled from several services: a model, orchestration software, cloud infrastructure, identity tools, external data, and specialized integrations.

When something goes wrong, each provider may point to another part of the stack. The model vendor may blame the deploying instructions. The integrator may blame the model. The customer may blame both. The contract may cap damages or assign defense obligations, but the technical record will still matter.

Who supplied the faulty component? Who controlled the relevant setting? Who knew about the risk? Who could have prevented the act? Those questions will shape both liability claims and contractual allocation.

Management And The Board

Not every AI-agent incident becomes a board-level issue. Repeated warnings, material security exposure, regulated operations, or a large financial risk can change the analysis.

Leadership may be asked whether the company approved the use case, assigned an accountable owner, set risk limits, and responded to known failures. A policy that says "human oversight required" will not help much if the system was designed to act at machine speed and no one had the time, information, or authority to intervene.

Authorization Is Becoming A Legal Fact, Not Just A Security Setting

The federal government is beginning to treat agent identity and authorization as a distinct systems problem.

NIST launched an AI Agent Standards Initiative in February 2026. Its National Cybersecurity Center of Excellence has also focused on applying identity and authorization standards to software and AI agents. The concern is practical: agents can take actions with limited human supervision, and the scale of those actions can expand quickly.

The June 2, 2026 executive order on advanced AI security points in the same direction. It directs the Attorney General to prioritize enforcement against people who use AI to unlawfully access or damage computer systems, steal data, or facilitate other crimes under existing federal statutes.

For companies, the question is not only whether a person was authorized to use the agent. It is whether the agent itself had a defined identity, limited permissions, a traceable sponsor, and boundaries that matched the approved task.

An agent using a shared administrator credential creates a much worse evidentiary position than one with its own identity, narrow permissions, and time-limited access.

Contracts Help, But They Do Not Solve The Whole Problem

AI-agent contracts should address more than ordinary uptime and confidentiality terms.

The parties should be clear about:

• which actions the agent is authorized to take;
• who configures permissions and approval thresholds;
• responsibility for third-party tools, models, and data;
• testing obligations before deployment and after material changes;
• notice when the model, orchestration layer, or safety controls change;
• logging, record access, and incident cooperation;
• responsibility for unauthorized transactions or communications;
• indemnity, liability caps, insurance, and exclusions; and
• suspension or shutdown rights when the agent behaves unexpectedly.

Those terms can decide who pays after a loss. They may also reveal who actually controlled the risk.

A broad disclaimer that AI can make mistakes will not answer whether the vendor promised a particular control, whether the customer disabled it, or whether either party ignored a known failure mode.

What A Defensible Agent Record Looks Like

When an agent acts, a company should be able to reconstruct the action without guessing.

That record should identify:

• the agent, model, and relevant version;
• the person or business owner who authorized the deployment;
• the task and instructions given to the agent;
• the systems, data, credentials, and tools it could access;
• the steps it took and external tools it called;
• the information it relied on;
• any human approvals, overrides, or ignored warnings;
• the resulting transaction, message, file change, or decision; and
• what happened after an error or incident was detected.

Logs alone are not enough if no one can interpret them. A defensible record connects technical events to business authorization and human responsibility.

This is also where privilege planning matters. Legal teams should decide which reviews need legal advice, while recognizing that ordinary operating logs and business records will not become privileged merely because lawyers care about them.

What Companies Should Do Before Agents Act At Scale

Companies do not need to resolve every future liability question before using AI agents. They do need to make responsibility visible.

Start with an inventory of agents that can take external action or change a system of record. Assign a named business owner and technical owner. Separate low-risk assistance from consequential execution. Use individual agent identities where possible, keep permissions narrow, and require approval for actions that are hard to reverse.

Test the full workflow rather than the model in isolation. That includes credentials, retrieved data, connected tools, fallback behavior, error handling, and the ability to stop the agent.

Review vendor terms against the actual use case. A general-purpose AI contract may not address payment authority, regulated decisions, customer communications, or the evidence needed after an incident.

Finally, preserve a record that connects authorization to action. If the company cannot show who approved the agent, what it was allowed to do, and what it actually did, the responsibility question will be answered from fragments after the dispute begins.

Bottom Line

AI agents can act with less immediate human involvement. They do not act outside the legal relationships created by the people and organizations that build, configure, authorize, and use them.

California AB 316 makes one part of that principle explicit: a defendant cannot avoid a case simply by asserting that the AI autonomously caused the harm. Other defenses remain, and responsibility may be divided among several parties.

The practical question is therefore larger than "who clicked the button?"

Who gave the agent authority? Who controlled its permissions? Who understood the risk? Who could have prevented the act? And who can prove those answers from a coherent record?

Those questions are likely to decide many of the first serious AI-agent disputes.

Sources

• leginfo.legislature.ca.gov
• whitehouse.gov
• nist.gov
• nccoe.nist.gov
• le.utah.gov
• clearon-ai.com
• clearon-ai.com
• clearon-ai.com

The August 2 Article 50 date is close enough that companies should stop treating it like a policy note.

It is now an operations problem.

That does not mean every Article 50 question is settled. The final Commission guidelines on scope and implementation have still not been identified as final adopted guidance. The transparency Code remains voluntary. But the legal obligation is not voluntary, the date is not moving in this source set, and the recent adequacy assessment plus signatory list make it harder to argue that companies still lack a usable compliance path.

That is the practical shift.

The immediate risk is not that businesses fail to write a label. It is that they wait too long to map which products, workflows, and publication channels actually need one.

For broader tracking context, see Clearon’s Laws, Bills & Regulations page.

What Is Binding On August 2 And What Is Not

The easiest way to get Article 50 wrong is to blur three different things together.

First, Article 50 itself is the law. It creates transparency duties for certain AI-generated or AI-manipulated content and for some AI-system interactions.

Second, the Code of Practice on Transparency of AI-generated content is not the law. It is a voluntary framework the Commission published to help providers and deployers implement parts of Article 50, especially around marking, detection, and labelling.

Third, the Commission’s recent adequacy assessment and the public signatory list do not convert the Code into binding law. They do make the Code look more like the Commission-backed default path for showing compliance with key Article 50 duties.

That distinction matters because companies can still choose not to sign or not to rely on the Code. They just should not confuse that flexibility with having no preparation work to do.

Why The Countdown Feels Different Now

A month ago, some teams could still tell themselves the EU was building toward Article 50 but had not yet shown what practical implementation would look like.

That is a much weaker position now.

The Commission has already published the final transparency Code. It has said the Code adequately covers Articles 50(2), 50(4), and 50(5), and the AI Board adopted its own adequacy assessment. It has also publicly identified signatories to the broader GPAI Code structure, including major companies. Even though the final Article 50 guidelines are still pending, the EU has already done enough to make "we are waiting for more clarity" a less comfortable answer inside legal and compliance teams.

The remaining uncertainty is real, but it is narrower than before. The bigger question now is not whether Article 50 will become operational. It is whether a company can show that it used the remaining time to make reasonable role, scope, and workflow decisions.

What The Real Work Looks Like

Most Article 50 coverage still focuses on the headline duty to label or mark synthetic content.

That is only the visible tip.

The harder work sits underneath:

• identifying which systems generate or manipulate audio, image, video, or text in ways that may fall within Article 50;
• separating provider obligations from deployer obligations, while recognizing that many companies will be both;
• deciding when content qualifies as a deepfake or as text published to inform the public on a matter of public interest;
• figuring out where machine-readable marking, provenance, or detection measures already exist and where they do not;
• deciding where visible labels or notices belong across websites, apps, feeds, reports, marketing assets, media workflows, and syndicated content; and
• preserving records showing that these decisions were made and implemented deliberately rather than improvised after launch.

That is why Article 50 is now a workflow deadline. None of those tasks can be finished responsibly in one late sprint.

The Provider And Deployer Split Is Where Teams Lose Time

One reason organizations stall is that they try to answer Article 50 at the company level instead of at the product and workflow level.

That usually fails.

A business might provide a generative AI tool to customers, use another model internally to create marketing or knowledge content, distribute AI-assisted public communications, and operate interfaces that interact directly with users. In one setting it may act as a provider. In another, as a deployer. In some workflows, both labels may matter at different points in the chain.

If teams try to solve that with a single abstract governance memo, they usually end up delaying the operational decisions that matter most. The better approach is narrower: map role by product, by feature, and by publishing or distribution workflow.

That also makes it easier to assign ownership. Article 50 work tends to get stuck when legal assumes product owns implementation, product assumes policy owns interpretation, and editorial or marketing teams assume disclosures will arrive as a final design asset later.

The Label Is Not The Control

Another common mistake is to treat Article 50 as a design problem.

It is partly a design problem, but only partly.

The label on a webpage, video, image, chatbot interface, or public-facing text output is just the final expression of a deeper classification and governance process. If the company has not decided what content is in scope, who makes that call, how the decision is recorded, and what happens when content is remixed or redistributed, the label will be inconsistent even if the wording looks fine.

That is especially true for content that moves.

A disclosure that appears clearly on the original page but disappears when the content is exported, reposted, screenshotted, clipped, embedded, syndicated, or reformatted is not much of a safeguard. The same is true for machine-readable markers that do not survive downstream workflows or for internal rules that depend on business teams remembering them manually.

The practical question is not just "what will the notice say?" It is "how will this notice stay attached to the content or interaction where users actually encounter it?"

What Companies Should Be Doing Right Now

The short-term plan should be boring and concrete.

First, build an inventory. Identify the products, tools, and publication flows most likely to trigger Article 50 analysis. This should include customer-facing AI systems, media-generation tools, marketing and communications pipelines, newsroom or publishing workflows, synthetic audio or video use, and any interface where a person may interact with AI under conditions requiring notice.

Second, assign owners. There should be one accountable legal or compliance lead and one operational lead for each major workflow. Shared ownership without a named decision-maker is how deadlines quietly fail.

Third, write provisional scope rules now rather than waiting for final guidelines. Teams can flag open questions while still making working classifications about deepfakes, public-interest text, machine-readable marking, and user-notice triggers.

Fourth, test real distribution paths. Check whether labels, markers, icons, metadata, and notices remain visible and meaningful across the channels that matter most. That includes web pages, mobile views, PDFs, image exports, social posts, video clips, reposted content, and partner distribution.

Fifth, keep evidence. The Commission-backed path may be voluntary, but the broader compliance reality is not. Companies should expect later questions about what role they assigned themselves, what controls they used, when they tested them, who approved exceptions, and how they decided certain content was inside or outside scope.

Why The Signatory Story Still Matters Here

The signatory list is not the main legal event. It is still worth including in the planning discussion.

It changes the pressure around alternatives.

Before the adequacy assessment and public signatory list, a company could more easily say it planned to build a custom transparency approach and that the market had not yet shown whether the Code would matter. That argument is weaker now. A Commission-backed Code exists, the Commission and AI Board have treated it as adequate for key duties, and visible companies have aligned with that path.

That does not eliminate flexibility. It does mean companies that go another way should be prepared to explain why their approach is adequate and how it is being validated.

The xAI chapter-level detail illustrates the point. Partial participation is possible, but it leaves the company needing to demonstrate compliance through other adequate means for the areas it did not adopt. That is a useful reminder that Article 50 planning is not mainly about symbolism. It is about evidence.

What Still Needs Watching

The final Commission guidelines still matter more than another routine signatory-page update.

Those guidelines should help narrow unresolved scope and implementation questions, including who is covered, which outputs are in scope, and how compliance may be demonstrated in practice. Companies should fold those guidelines into their plan as soon as they are published.

The transition period for some systems already placed on the market also matters, but it should not become an excuse to delay the core inventory and workflow work. Even where timing nuances exist, organizations still need the same underlying mapping, testing, and recordkeeping structure.

The larger point is simple. Most of the hard work required for Article 50 readiness is the same work companies would need to do regardless of whether the next Commission update answers every remaining question.

Bottom Line

The Article 50 countdown is now a workflow deadline.

The Code is still voluntary. The final Commission guidelines are still pending. But the legal duty is close, the Commission-backed implementation path is visible, and the work that matters most can no longer be compressed into a last-minute labeling exercise.

Companies that start now still have time to make reasonable decisions. Companies that keep waiting are more likely to discover that the hardest part was never the label itself. It was identifying the content, owners, controls, and records needed to make the label mean something.

Sources

• Commission announcement on the final Code of Practice on marking and labelling AI-generated content
• European Commission opinion on the assessment of the Code of Practice on Transparency of AI-generated content
• European Commission page for the GPAI Code and signatories
• Code of Practice on Transparency of AI-generated content
• Commission Q&A on the transparency Code of Practice
• Clearon: EU AI Act Transparency Code Turns AI-Generated Content Labels Into Compliance Work
• Clearon: The EU AI Transparency Code Now Has Signatories. That Makes Article 50 Harder To Ignore.
• Clearon: Why Transparency Keeps Becoming AI Regulation’s Common Rule

The EU’s AI transparency Code of Practice is still voluntary.

It is also getting harder to treat it like background noise.

The European Commission has now published signatories to the General-Purpose AI Code of Practice, after already saying that the transparency code adequately covers Articles 50(2), (4), and (5) of the AI Act and after the AI Board adopted its own adequacy assessment. That combination matters more than either development standing alone. The Code is not binding law, and it is not the final Article 50 guidance. But it is starting to look like the Commission’s preferred operating lane for showing compliance with the AI Act’s transparency duties before those obligations begin applying on August 2, 2026.

That is the part companies should pay attention to now.

This is no longer just a story about Brussels publishing another voluntary framework. It is a story about the EU building a practical compliance path, naming who is willing to take it, and leaving everyone else to explain what they plan to do instead.

For broader tracking context, see Clearon’s Laws, Bills & Regulations page.

What Actually Changed

There are now two official milestones that need to be read together.

First, the Commission said on July 9 that, following its July 8 conclusion, the Code of Practice on Transparency of AI-generated content adequately covers the obligations in Articles 50(2), 50(4), and 50(5) of the AI Act and facilitates their effective implementation. The Commission page also says the AI Board adopted its adequacy assessment the same day.

Second, the Commission’s General-Purpose AI Code of Practice page now publicly identifies signatories. The page names companies including Amazon, Anthropic, Google, Microsoft, Mistral AI, OpenAI, and others. It also says xAI signed only the Safety and Security chapter, which means transparency and copyright compliance would need to be demonstrated through other adequate means.

That does not convert the Code into a mandatory rulebook. It does something more practical. It shows that the Commission’s preferred path is real, usable, and already being adopted by a visible group of companies.

Why The Signatory List Matters More Than It May Look

The July 9 adequacy assessment was important, but it still left a common reaction available: wait and see.

A company could say the Code had moved in the right direction, but the real market test would come later. Would major providers and deployers actually sign? Would the Code become an industry norm or just a formal option on paper?

The signatory list answers part of that question.

Once the Commission names signatories, the discussion changes. Companies are no longer evaluating an abstract framework in isolation. They are evaluating whether to join a public compliance lane that peers are already using.

That matters for at least three reasons.

First, it creates a benchmark. A company that does not sign is no longer choosing between two equally hypothetical paths. It is choosing between a Commission-backed adequate Code with visible market uptake and a self-built approach that may have to be defended authority by authority.

Second, it raises governance pressure inside companies. Legal, compliance, public policy, and product teams now have to answer a basic question from management: are we planning to sign, and if not, why not?

Third, it increases the odds that the Code becomes the reference point for cross-border discussions about what "good enough" transparency implementation looks like in practice, even if it remains voluntary as a matter of law.

Voluntary Does Not Mean Unimportant

This is where AI Act coverage often gets flattened.

Article 50 is the law. The Code is not. The final Commission guidelines on scope and implementation also still matter, and those guidelines have not been identified yet as final adopted guidance.

But voluntary instruments can still become the practical center of gravity in compliance work.

That happens all the time in regulated environments. A framework does not need to be binding to become the default evidence path. It only needs three things:

• a regulator willing to point toward it;
• a credible claim that it adequately covers the legal obligation; and
• enough market uptake that declining to use it starts becoming a decision that must be justified.

The EU transparency Code is getting closer to that position.

The xAI Detail Is More Interesting Than It Looks

The Commission page’s note that xAI signed only the Safety and Security chapter deserves more attention than a generic signatory headline.

That detail is useful because it shows the Code is not just a symbolic coalition list. It shows chapter-level choices still matter and that partial participation can carry legal consequences for how compliance must be demonstrated.

In the Commission’s framing, if a company does not sign the relevant transparency and copyright chapters, it must show compliance through other adequate means. That is a more concrete version of a broader AI-law pattern Clearon has been tracking: regulators may allow flexibility, but they increasingly expect companies to prove why their alternative is good enough.

For companies watching from the outside, the takeaway is simple. Choosing not to follow the default path is still allowed. It is just not cost-free from a governance and evidence perspective.

What Article 50 Still Requires

The signatory list does not change what Article 50 is about.

The core obligations still concern transparency around AI-generated or AI-manipulated content, including deepfakes and certain text published to inform the public on matters of public interest. The broader Article 50 framework also covers user notice when people interact with an AI system in contexts where that disclosure is required.

The operational point remains the same as it was when the final Code first appeared: most of the real work sits behind the label.

Companies still need to know:

• which systems and workflows generate or manipulate content in scope;
• whether they are acting as providers, deployers, or both;
• when content crosses into deepfake or public-interest-text territory;
• what machine-readable marking or provenance measures exist;
• where visible labels or notices must appear;
• whether those disclosures survive syndication, reposting, cropping, remixing, and downstream distribution; and
• what records show the organization made and implemented reasoned decisions.

The signatory list does not solve those questions. It makes them harder to postpone.

Why This Calls For A Longer Read, Not A Short Update

A short item could have said that signatories were published. That would have been true, but it would have missed the point.

The real development is not just publication of names. It is the way three developments now fit together:

1. the final transparency Code was published;
2. the Commission and AI Board said it adequately covers the relevant Article 50 duties; and
3. major companies are now publicly identified as signatories.

Put together, that looks less like a minor implementation note and more like the emergence of a default compliance architecture ahead of the August 2 deadline.

That is why a longer article makes sense. The legal status has not changed from voluntary to mandatory, but the practical status has changed from "one option among many" to something closer to "the path everyone will have to evaluate explicitly."

What Companies Should Decide Now

The immediate question is not whether Article 50 matters. It does.

The immediate question is whether the company wants to align with the Commission-backed path or defend a custom alternative.

That choice should trigger a real internal review.

At a minimum, companies should decide:

• whether they are likely to sign the relevant transparency commitments;
• which products, publishing flows, and synthetic-content use cases fall within scope;
• who owns the classification calls for deepfakes and public-interest text;
• how labels, notices, icons, or machine-readable markers will actually be deployed;
• what business units need to change workflows before August 2;
• what evidence will be kept to show the controls were not just designed but used; and
• how the eventual final Article 50 guidelines will be folded into the existing plan.

For many organizations, the hardest part will not be writing a disclosure sentence. It will be assigning ownership across product, legal, trust and safety, editorial, policy, and engineering teams.

What Practical Planning Should Look Like

Companies should be planning this as a workflow project with legal ownership, not as a last-minute content-labeling task.

The first step is role mapping. Many organizations will be both providers and deployers in different contexts. A company may provide a generative AI tool to customers, use a different model internally for marketing or publishing, and also operate chatbot or search-style interfaces. Those roles should be mapped product by product and workflow by workflow instead of being answered once at a policy level.

The second step is content mapping. Teams should identify where AI-generated or AI-manipulated audio, images, video, and text are created, edited, approved, published, syndicated, or redistributed. The important question is not just whether the company uses generative AI. It is where synthetic content enters production systems, whether it stays machine-readable, and where public-facing disclosures may be lost.

The third step is decision mapping. Someone has to own judgments about whether material is a deepfake, whether text concerns a matter of public interest, whether an interface requires a user notice, and whether enough human review or editorial responsibility exists to affect how the output is treated. If those calls are left vague, the company will end up with inconsistent labeling across teams and channels.

The fourth step is control testing. Labels, icons, notices, provenance data, and machine-readable markers should be tested in the environments that matter most: web pages, mobile surfaces, social posts, video clips, images, PDFs, partner distribution channels, press workflows, and republished content. A disclosure that disappears during export, reposting, clipping, or formatting conversion is not much of a control.

The fifth step is evidence design. Companies should assume they may later need to show not only that a policy existed, but that the policy was used. That means keeping records of role classifications, workflow decisions, labeling rules, exceptions, review steps, implementation dates, and testing results. If a company chooses not to sign the Code, this documentation matters even more because the alternative path will need to be defended as adequate on its own terms.

A Sensible Near-Term Plan

For companies trying to get from policy discussion to execution, a practical short-term plan would look something like this.

In the next two weeks:

• identify the products, publishing flows, and public-facing content systems most likely to fall within Article 50;
• assign one accountable owner across legal or compliance and one operational owner across product or content operations;
• decide whether the company is evaluating signature as the default path or only as one option among several; and
• create a short issue list for unresolved scope questions, especially around deepfakes, public-interest text, and user-notice triggers.

In the next month:

• inventory existing labeling, disclosure, watermarking, provenance, and notice controls;
• test how those controls behave across distribution channels and downstream formats;
• write working rules for when disclosures must appear and who can approve exceptions;
• build review checkpoints into publishing, moderation, and launch workflows; and
• start collecting implementation evidence in a place legal and compliance teams can actually retrieve later.

Before Article 50 goes live:

• decide whether to sign the relevant commitments or rely on another approach;
• close the highest-risk gaps in content workflows that publish synthetic media or public-interest text;
• train the teams making real-world classification and publishing decisions;
• align external messaging so product, legal, policy, and communications teams are not describing the controls differently; and
• update the plan again when the final Commission guidelines arrive.

That is not glamorous work, but it is the work that determines whether Article 50 compliance is real or performative.

What To Watch Next

Three follow-up items still matter.

First, final Commission Article 50 guidelines would be a bigger legal implementation event than another signatory-page refresh. Those guidelines should help narrow scope and application questions that the Code alone does not fully settle.

Second, changes to the signatory list matter because they will show whether the Code is stabilizing as an industry norm or whether visible holdouts remain.

Third, enforcement and dispute posture matter. The more Article 50 becomes operational, the more courts, regulators, publishers, and counterparties will test whether companies actually did the classification, notice, and recordkeeping work they claimed to have done.

That is where this stops being a transparency branding exercise and becomes legal infrastructure.

Bottom Line

The signatory list by itself is modest. Combined with the Commission’s adequacy assessment and the approaching Article 50 deadline, it marks a more meaningful shift. The EU has not made the transparency Code binding law. It has done something that may matter almost as much in practice: it has made the Code look like the default path companies will be expected to consider, and possibly expected to explain if they reject.

That is a real compliance development, and it is worth treating like one.

Sources

• European Commission page for the General-Purpose AI Code of Practice and signatories
• European Commission opinion on the assessment of the Code of Practice on Transparency of AI-generated content
• Commission announcement on the final Code of Practice on marking and labelling AI-generated content
• Code of Practice on Transparency of AI-generated content
• Commission Q&A on the transparency Code of Practice
• Clearon: EU AI Act Transparency Code Turns AI-Generated Content Labels Into Compliance Work
• Clearon: Why Transparency Keeps Becoming AI Regulation’s Common Rule

The Great American Artificial Intelligence Act is easy to describe badly.

It is not an enacted Federal AI law. It is not even an introduced bill yet. It is a discussion draft released by Representatives Lori Trahan and Jay Obernolte with official supporting materials inviting feedback before formal introduction.

That said, it is still worth reading because it shows what one serious bipartisan Federal AI framework may try to do.

The most important point is not just that the draft creates frontier-model transparency, audits, and a new Federal standards center. It is that the draft tries to split AI regulation into two lanes:

• Federal rules for model development and frontier safety; and
• continued state authority over deployment, use, and generally applicable law.

That split is where the real fight will be.

The Short Answer

• The Great American AI Act is currently a discussion draft, not introduced legislation and not law.
• The draft would create a Federal frontier-governance regime centered on published risk frameworks, model-specific transparency reports, critical-safety-incident reporting, independent verification audits, and whistleblower protections.
• It would also preempt state laws that specifically regulate AI model development, while preserving state laws of general applicability and state rules governing deployment or use of AI systems after the model stage. The official FAQ says that preemption would sunset three years after enactment.

The Draft Is Trying To Create One Federal Rulebook For Frontier Development

The official section-by-section and FAQ materials make the architecture fairly clear.

The draft would formally establish a Center for AI Standards and Innovation, or CAISI, within the Department of Commerce. According to the section-by-section summary, CAISI would develop voluntary standards and best practices, evaluate AI systems, support synthetic-content detection tools, and administer the licensing regime for independent verification organizations.

The frontier-governance pieces then stack on top of that center.

According to the section-by-section summary, large frontier developers would have to write, implement, comply with, and publicly post a frontier AI framework covering catastrophic-risk thresholds, model-weight cybersecurity, internal and external deployment decisions, and related governance practices. Before or at deployment of a new frontier model, they would also have to publish a model-specific report describing release date, supported languages, modalities, intended use, restrictions, risk assessments, and mitigation steps.

The section-by-section summary also says developers would have to report critical safety incidents to CAISI, with State attorneys general able to opt into receiving those reports.

That is already a lot more concrete than generic calls for "responsible AI."

The Audit Structure Is Not Voluntary

Another major part of the draft is the independent verification regime.

The section-by-section summary says CAISI would license independent verification organizations, or IVOs, and large frontier developers would have to retain licensed IVOs to audit compliance and assess whether the developer’s framework achieves acceptable levels of catastrophic-risk mitigation.

Those organizations would get access to company materials, submit reports to CAISI, and provide a channel for corrective action and more frequent review if risk changes.

That matters because the draft is not relying only on self-attestation. It is trying to build a recurring third-party review structure around the largest frontier developers.

If a future bill keeps that structure, companies should expect the compliance file to include more than a policy page and a red-team slide deck. It would need documented frameworks, incident reporting, audit access, governance controls, and a defensible explanation of how catastrophic risk is being measured and mitigated.

The Sharpest Provision Is The Preemption Section

The real legal flashpoint is section 121.

The draft says no state or political subdivision may establish or enforce any law or regulation specifically regulating the development of any AI model. That is the clean preemption sentence.

The surrounding text matters just as much. The same section says it does not preempt:

• state laws of general applicability;
• common-law remedies; or
• state laws and regulations that apply to activities occurring upon or after deployment, including implementation, deployment, distribution, offering, or use of AI systems, products, or services built from the model.

The official FAQ goes further and says the framework would preserve state regulation of post-deployment or use-stage harms, including areas like hiring, housing, health care, education, chatbots, deepfakes, child sexual abuse material, and consumer privacy. The same FAQ says the preemption would sunset three years after enactment.

That is why this draft is better understood as a Federal-state line-drawing proposal than a generic AI bill.

Why The Preemption Debate Will Be Hard

The draft is trying to do something politically familiar.

It says model development should face one Federal rulebook, while states keep room to regulate downstream uses and harms. The official materials even compare that structure to national vehicle standards with state rules of the road.

There is a logic to that.

Frontier developers do not want fifty different state development-stage obligations, especially when those duties touch testing, documentation, training, or internal governance. At the same time, states are unlikely to give up their role in policing consumer protection, employment, health care, education, or chatbot harms that show up after deployment.

The practical question is where "model development" stops and "deployment or use" begins.

That line will not always be clean. A transparency rule, watermarking rule, or documentation rule can look like development-stage governance from one angle and user-facing product regulation from another. The official FAQ itself highlights that tension by listing specific state laws the drafters view as federalized or preempted.

The Draft Also Shows Which Companies The Drafters Care About Most

The supporting materials suggest the framework is aimed at the largest frontier developers rather than every startup or open-source project.

The section-by-section summary says the transparency regime would apply to large frontier developers with more than $500 million in revenue. The FAQ also frames the bill as focusing obligations on frontier companies while giving startups and smaller builders more room.

That does not mean smaller companies can ignore it.

If Congress keeps this structure, the Federal debate may center on a frontier tier first, while states keep regulating use-stage harms lower down the stack. Smaller companies could still feel those downstream state laws even if the heaviest Federal development-stage duties land elsewhere.

What Companies Should Watch

For now, this is still a discussion draft. That status matters and should not be blurred.

Still, the draft is worth tracking closely if any of these questions matter to the business:

• would the company fall into a frontier-developer bucket if revenue and model-capability thresholds survive;
• does the company already have a publishable risk framework, incident-reporting process, and audit-ready governance file;
• how much of the company’s state-law exposure sits at the model-development layer versus the deployment or product-use layer; and
• would preemption help the company, or would the operational pain simply move into downstream state rules on use, distribution, privacy, employment, health care, or consumer deception.

The most useful reading is not "Federal AI bill exists." It is "a bipartisan draft is trying to define which AI risks belong to Washington and which still belong to the states."

Bottom Line

The Great American AI Act discussion draft is not law yet, but it is a serious marker of where Federal AI governance negotiations could go.

Its structure matters more than its name. The draft would pair frontier transparency, incident reporting, third-party audits, and whistleblower protections with a temporary preemption rule for state laws specifically regulating model development, while preserving state authority over use-stage harms and general law.

That is the real issue to watch. If Congress moves on AI, one of the hardest questions will not be whether there should be regulation. It will be who gets to regulate which layer of the stack.

Sources

• Great American AI Act discussion draft PDF
• Trahan and Obernolte discussion-draft announcement
• Official section-by-section summary
• Official FAQ on the discussion draft
• Lori Trahan op-ed on the framework’s Federal-state split

Rhode Island’s latest AI package is useful because it does not pretend every chatbot problem is the same.

The General Assembly approved one bill aimed at companion-style AI and another aimed at the use of artificial intelligence in therapy and psychotherapy settings. That split matters because the compliance questions are different.

One bill is basically a product-safety and disclosure measure for AI companions. The other is a professional-practice and patient-protection measure for mental-health care. Treating them as one generic "AI safety" story would hide the most practical part.

As of this update, the cleanest official Rhode Island source I found is the General Assembly’s June 8 announcement that both measures were approved and sent to the governor for consideration. So the article below focuses on what the legislature approved and why the two-bill structure is worth watching closely.

The Short Answer

• Rhode Island’s legislature approved separate AI measures for companion-chatbot safety and for AI use in mental-health care.
• The companion bill would require crisis protocols, recurring notices that the user is not interacting with a human, annual Attorney General reporting, and expose operators to civil penalties up to $15,000 per day.
• The mental-health bill would limit how AI can be used in therapy and psychotherapy services, require informed written consent for certain recorded or transcribed sessions, bar unlicensed entities from offering therapy through AI, and keep therapeutic decisions with licensed professionals.

Rhode Island Is Drawing Two Different Regulatory Lines

A lot of AI-law coverage still treats emotionally responsive systems, therapy-like systems, and ordinary chat interfaces as one category.

Rhode Island does not.

Its legislature approved one bill for "artificial intelligence companion models" and another called the "Oversight of Artificial Intelligence Technology in Mental Health Care Act." That is a useful signal because it suggests lawmakers are distinguishing between:

• consumer-facing systems designed to simulate sustained human-like relationships; and
• clinical or quasi-clinical use of AI in actual therapy settings.

Those are different products, different risks, and different compliance owners.

The Companion Bill Is About Crisis Protocols and Nonhuman Notice

H 7350 Substitute A as amended would create a new chapter on artificial intelligence companion models.

The definition matters. The bill does not cover every chatbot. It targets systems that simulate a sustained human or human-like relationship by retaining information across sessions, asking unprompted emotion-based questions, and sustaining ongoing personal dialogue. It also excludes ordinary customer-service systems, research or technical-assistance tools, and internal productivity uses.

That narrower definition is exactly what makes the bill practical.

For covered operators, the bill would make it unlawful to operate or provide an AI companion unless the system contains a protocol addressing:

• possible suicidal ideation or self-harm expressed by a user;
• possible physical harm to others expressed by a user; and
• referral to crisis services as soon as those expressions are detected.

The bill would also require a clear and conspicuous notice at the beginning of an interaction and at least every three hours of continued interaction stating verbally or in writing that the user is not communicating with a human.

That recurring-notice structure is worth noticing. Rhode Island is not treating disclosure as a buried one-time term. It is treating nonhuman notice as an ongoing duty for relationship-style systems.

Beginning July 1, 2027, operators would also have to file annual reports with the Attorney General including the number of safety-protocol activations and related metrics, with aggregated data published on the Attorney General’s website.

The enforcement section is not symbolic. It would authorize Attorney General enforcement and civil penalties of up to $15,000 per day, with fines directed to suicide-prevention programs. The bill text says it would take effect on January 1, 2027.

The Mental-Health Bill Is Not A Chatbot-Disclosure Rule

H 7349 Substitute A does something different.

It is not mainly about telling a user they are talking to AI. It is about limiting how AI can be used in therapy and psychotherapy services and preserving the role of licensed professionals.

The bill defines administrative support, supplementary support, therapeutic communication, consent, and permitted uses of AI. It then builds several restrictions on top of those definitions.

Most importantly, it would prohibit licensed professionals or providers from using AI designed to simulate emotional attachment, bonding, or dependency, or AI companions for mental health or emotional support, to assist in supplementary support or therapeutic communication in therapy or psychotherapy services where the client’s therapeutic session is recorded or transcribed unless the patient or authorized representative is informed in writing and provides consent.

That written disclosure must cover:

• that AI will be used;
• the specific purpose of the AI tool or system; and
• written consent to that use.

The bill would also bar any individual, corporation, or entity from providing, advertising, or otherwise offering therapy or psychotherapy services, including through Internet-based AI, unless those services are conducted by a licensed professional or provider.

That is a harder line than a lot of generic "AI in healthcare" commentary suggests.

Therapeutic Decisions Stay With Humans

The part many companies should read most carefully is the section limiting what a licensed professional may let AI do.

Under the bill, a licensed professional or provider could not allow AI to:

• make independent therapeutic decisions;
• directly interact with clients in therapeutic communication without an established treatment relationship and appropriate consent; or
• determine therapeutic recommendations or treatment plans.

The provider retains responsibility for clinical judgment and reasonable therapeutic oversight of the patient’s use of the system, though not for vendor-controlled design, algorithms, or outputs.

That is a strong statement about where Rhode Island thinks professional responsibility should stay. The tool can assist around the edges. It cannot own the treatment decision.

The bill also adds a confidentiality section and gives the Executive Office of Health and Human Services investigative authority. The text says the act would take effect upon passage.

Why The Two-Bill Structure Matters

The practical lesson is that Rhode Island is not regulating "AI" in the abstract.

It is assigning duties based on use case.

If a product is built to simulate emotional attachment or companionship, the pressure point is crisis response, recurring nonhuman disclosure, and reporting. If a product is used in therapy or psychotherapy, the pressure point is consent, licensure, confidentiality, and preserving human clinical judgment.

That split is more useful than a broad AI-principles statute because it maps directly to product, legal, and operational questions companies can actually answer.

What Companies Should Review Now

If these Rhode Island measures matter to the business, the near-term review should be concrete:

• decide whether any product could fit the legislature’s companion-model definition rather than an ordinary support-tool definition;
• identify where self-harm and violence escalation protocols live and who owns crisis-referral design;
• review whether recurring nonhuman disclosures can actually be delivered and logged during long-running sessions;
• determine whether any mental-health or wellness product is drifting into therapy or psychotherapy claims;
• review whether recorded or transcribed sessions involving AI would require a separate written-consent workflow; and
• make sure no vendor or marketing language implies that AI itself is offering therapy where licensure rules would say otherwise.

The bigger point is simple. A lot of AI risk is becoming a classification problem first. What kind of system is this, what kind of use is this, and which rule set attaches once that label is accurate?

Bottom Line

Rhode Island’s legislature approved two AI bills because it appears to see two different problems.

Companion systems raise disclosure, crisis-intervention, and engagement-risk questions. Therapy-related systems raise licensure, consent, confidentiality, and clinical-judgment questions. That separation is the real takeaway.

Even before final governor status is confirmed, the bill texts are a useful picture of where state safeguards are heading. Companies that build emotionally responsive AI or use AI around mental-health services should not treat those as the same compliance lane.

Sources

• Rhode Island General Assembly announcement on the approved AI measures
• Rhode Island H 7350 Substitute A as amended
• Rhode Island H 7349 Substitute A
• Clearon article on companion-chatbot compliance
• Clearon article on the FTC’s companion-chatbot inquiry

Connecticut’s AI law is no longer a bill to watch.

SB 5 was signed on May 27 as Public Act 26-15, and that enacted status matters because the law does not read like one abstract AI-principles document. It reads like a stack of operational rules with different effective dates, different targets, and different compliance owners.

That is probably the most useful thing about it.

Public Act 26-15 does not try to settle every AI policy fight at once. It puts real duties into places companies already understand: companion-chatbot safety, workplace decision tools, synthetic-content provenance, workforce programs, and youth-platform design. That is much closer to how AI compliance is likely to arrive in practice.

The Short Answer

• Connecticut's SB 5 is enacted as Public Act 26-15.
• The law includes staggered requirements touching AI companions, employment-related automated decision tools, provenance for certain public generative-AI systems, frontier-developer whistleblower protections, and youth-platform safeguards.
• For many businesses, the most practical near-term items are the October 1, 2026 provenance and employment provisions, the January 1, 2027 companion-chatbot safeguards, and the October 1, 2027 trigger for certain employment-tool deployment duties.

Why The Enacted Version Matters More Than The Bill Debate

A lot of AI-law coverage treats passage as the interesting moment and implementation as the footnote.

With Connecticut, the implementation is the story.

The enacted law is broad, but it is not one uniform compliance event. It is a phased package. Some parts are effective in mid-2026, some in October 2026, some in January 2027, some in October 2027, and some youth-platform provisions arrive in 2028.

That means legal teams should stop asking whether Connecticut passed "an AI law" and start asking which business function owns which date.

The Employment Piece Is One Of The Most Concrete

The workplace provisions are likely to be the most immediate operational issue for many companies.

Public Act 26-15 defines automated employment-related decision technology and sets up a developer-deployer structure for related obligations. Starting October 1, 2026, the statutory framework is in place. For deployers using covered tools on or after October 1, 2027, the law requires disclosure when an employee or applicant is interacting with such technology unless a reasonable person would think that is obvious.

Before an employment-related decision is made, the deployer must also provide written notice describing:

• that the technology has been deployed,
• the purpose of the technology and the nature of the decision,
• the trade name of the technology,
• the categories of personal data it will analyze or process and how that data will be assessed,
• the source of that data, and
• contact information for the deployer.

The law also says use of automated employment-related decision technology is not a defense to a discrimination complaint. That is a clean point legal teams should not miss.

In other words, Connecticut is not treating workplace AI as a novelty. It is treating it as another decision system that can create notice, documentation, and discrimination exposure.

The Companion-Chatbot Rules Are Not Cosmetic

Starting January 1, 2027, Connecticut adds another enacted state model for companion-style AI.

The law defines an artificial intelligence companion in a way that turns on sustained, anthropomorphic, relationship-like interaction while carving out a range of ordinary business and operational chat uses. That definitional line matters because it tries to separate companion-style consumer products from ordinary support and productivity tooling.

For covered companions, the law requires operators to use evidence-based methods to detect user expressions clearly indicating risk of suicide, self-harm, or imminent physical violence and to institute measures to prevent the system from generating outputs that encourage those harms. If such a signal is detected, the operator must refer the user to appropriate crisis resources.

The law also requires clear and conspicuous notice when a reasonable user might think they are interacting with a human rather than an AI companion. And for minor users, the law adds additional safeguards around self-harm, suicidal ideation, violence, disordered eating, alcohol, drugs, sexual exploitation, and parental management tools.

This is not just a disclosure rule. It is a product-safety and response-protocol rule.

Connecticut Also Moves On Provenance

Another part of the law, effective October 1, 2026, applies to certain publicly accessible generative-AI providers with more than one million monthly users.

That section requires covered providers, to the extent commercially and technically reasonable, to include provenance data in covered audio, image, or video content created or materially altered by the provider's generative-AI system, and to use reasonable methods to make that provenance data difficult to tamper with, remove, or separate from the content.

That matters for two reasons.

First, it shows Connecticut is willing to move beyond general transparency rhetoric into implementation detail around synthetic-content authenticity. Second, it uses a familiar enforcement model: unfair or deceptive trade practice treatment, enforced solely by the Attorney General, with no private right of action.

Frontier Developers And Internal Reporting Are In The Mix Too

The law also includes a frontier-developer section effective January 1, 2027.

Large frontier developers must maintain a reasonable internal process for anonymous reporting by covered employees who in good faith identify activity posing a specific and substantial public-health or public-safety danger tied to catastrophic risk. The law also requires updates, board-level sharing in most cases, and notice of employee rights.

That does not affect every company. It still matters as a signal.

Connecticut is treating frontier-model governance not just as a public-policy debate, but as an internal reporting, employee-protection, and documentation issue.

The Effective-Date Map Matters

The biggest practical mistake would be treating Public Act 26-15 as one single compliance date.

The rough timing looks more like this:

• July 1, 2026: the Connecticut AI Academy provision takes effect.
• October 1, 2026: provenance rules for certain public generative-AI providers, employment-tool framework provisions, anti-discrimination clarifications, and WARN-related AI/technology layoff disclosure provisions take effect.
• January 1, 2027: companion-chatbot safeguards and frontier-developer reporting provisions take effect.
• October 1, 2027: certain automated employment-related decision technology deployment duties apply when covered tools are deployed on or after that date.
• January 1, 2028: certain youth-platform algorithmic and warning provisions take effect.

That timeline is why this should be treated as an inventory problem, not a headline problem.

What Companies Should Review Now

If Connecticut matters to the business, the review should be practical:

• identify whether any consumer product could fit the law's companion definition;
• identify whether any hiring or employment workflow uses tools that could materially influence a decision;
• determine whether any public generative-AI product crosses the monthly-user threshold for the provenance section;
• review vendor and internal documentation needed to support employment notices;
• map who owns self-harm response, crisis referral, and notice design for companion-style systems; and
• track which dates matter for which products, functions, and contracts.

The legal burden here is not only about whether AI is used. It is about whether the company can show where the law attaches and who owns the response.

Bottom Line

Connecticut's Public Act 26-15 is a good picture of how state AI compliance actually arrives.

Not through one giant theory of artificial intelligence, but through layered rules touching employment, companion products, provenance, internal governance, and youth-facing design. The law is enacted, the dates are staggered, and several of the duties are concrete enough that companies should already know which teams will own them.

For legal and compliance teams, that is the real lesson. State AI law is getting less theoretical and more operational.

Sources

• Connecticut Public Act 26-15 text
• Governor Lamont announcement on Public Act 26-15
• Clearon article on companion-chatbot compliance

New York now has a live AI advertising disclosure rule.

That matters because this is not just another policy speech about deepfakes or responsible innovation. It is a binding state law that requires disclosure when advertisements include synthetic performers.

The practical point is easy to miss. New York did not adopt a broad rule saying every advertisement touched by AI needs a label. It adopted a narrower rule aimed at a specific advertising use case: synthetic people used to sell products or services.

That narrower framing is exactly why advertisers, agencies, and in-house counsel should pay attention.

The Short Answer

• New York's synthetic-performer advertising disclosure law is in effect.
• The official state materials describe it as requiring people who produce or create an advertisement to identify when it includes AI-generated synthetic performers.
• The New York Senate bill page describes the measure as carrying a $1,000 civil penalty for a first violation and a $5,000 penalty for subsequent violations.

What New York Officially Announced

Governor Kathy Hochul first announced the measure when she signed S.8420-A/A.8887-B in December 2025. The signing release described it as first-in-the-nation legislation requiring individuals who produce or create advertisements to disclose if AI-generated synthetic performers are used.

The Governor's later June 2026 announcement said the law is now in effect. That release again described the requirement in practical terms: people who produce or create an advertisement must identify if it includes AI-generated synthetic performers.

The same official announcement describes AI-generated synthetic performers as digitally created media that appear as a real person. It also says those performers are increasingly used across media, including social media and digital advertising.

That is enough to make the compliance point clear. This is not only a film-industry talking point. New York is framing it as an advertising transparency rule with broader digital relevance.

This Is Narrower Than “All AI Ads Must Be Labeled”

The law matters partly because it is targeted.

It is not framed in the official materials as a blanket requirement to disclose any use of AI in ad production. It is framed around advertisements that include synthetic performers.

That distinction matters for compliance planning.

Using AI for copy variants, background cleanup, translation, editing assistance, audience analysis, or production workflow support is not the same thing as using a synthetic human-like performer in the ad itself. New York's rule is important precisely because it focuses on the part consumers are likely to experience as a person-like visual or audiovisual performance.

That does not make the rule minor. It makes it easier for regulators to explain and easier for advertisers to get wrong if their internal review process still treats synthetic humans as just another creative asset.

Why The Rule Matters Beyond New York

This is one of the clearest state examples yet of AI transparency moving into ordinary commercial law.

The policy logic is simple. If an advertisement presents something that looks like a real human performer, the public may be misled if no disclosure appears and the performer is actually synthetic.

That puts the law in the same broader family as other AI notice rules Clearon has been tracking, even though the subject matter is narrower than chatbot laws or the EU AI Act's content-labeling framework.

New York is not trying to solve all AI deception risk in one statute. It is taking one commercially legible category and attaching a disclosure duty to it.

That is often how these rules spread. Legislatures do not start with a complete theory of synthetic media. They start with a use case that sounds concrete, consumer-facing, and politically defensible.

The Penalties Are Not Huge, But They Are Real

The New York Senate bill page describes the measure as imposing a $1,000 civil penalty for a first violation and a $5,000 penalty for any subsequent violation.

Those numbers are not existential on their own for major brands or agencies. They still matter.

First, a real penalty means this is not merely guidance. Second, once a disclosure duty exists, a company that misses it may also create knock-on problems in regulatory examinations, platform disputes, contract fights, influencer or talent conflicts, substantiation reviews, or broader deception arguments.

For many legal teams, the bigger risk is not the face amount of the first penalty. It is having no workflow for deciding when a synthetic person appears in an ad and who is responsible for making sure disclosure happens.

What Advertisers And Agencies Should Review Now

If a company uses synthetic people in commercial creative, it should be able to answer a few practical questions quickly:

• What counts internally as a synthetic performer for campaign review purposes?
• Which teams can approve ads that include synthetic human-like visuals or performances?
• Where in the workflow is the disclosure added and checked?
• Does the review cover social media, short-form video, programmatic creative, influencer-style campaigns, and localized variants?
• Are agencies, production vendors, and post-production teams required to flag synthetic performer use?
• Can the brand prove after the fact which campaigns used synthetic performers and what disclosure appeared?

This is the kind of rule that sounds simple until the asset pipeline gets messy.

If one team generates the performer, another edits the cut, a third places the media, and a fourth localizes the campaign, disclosure responsibility can disappear in the handoff.

The Operational Lesson Is Familiar

The hardest part usually is not writing the notice.

It is deciding when the rule is triggered, who makes that call, how the decision is documented, and whether the final delivered ad still contains the required disclosure after resizing, localization, reposting, clipping, or repackaging.

That is why this should be treated as a workflow issue, not only a creative issue.

Marketing teams may see a fast, cheap way to create human-like commercial content. Legal and compliance teams should see a disclosure trigger that needs a review path.

Bottom Line

New York's synthetic-performer law puts a real disclosure requirement into the advertising pipeline.

The official state materials describe a rule that is already in effect and that requires people who produce or create advertisements to identify when AI-generated synthetic performers are used. The Senate bill page also describes civil penalties for violations.

For advertisers and agencies, the practical message is direct: if a campaign uses a synthetic person to sell something, disclosure is no longer just a best practice in New York. It is a legal step that should be built into campaign review.

Sources

• Governor Hochul signing announcement for S.8420-A/A.8887-B
• Governor Hochul announcement that the law is now in effect
• New York Senate bill page for S8420A
• Clearon article on AI transparency as a common regulatory rule

The newest White House AI memorandum for the national security enterprise is easy to summarize badly.

At a high level, yes, it is about faster AI adoption across military and intelligence functions. That much is obvious from the title and the fact sheet.

The more useful reading is narrower. NSPM-11 is also a procurement, control, and accountability document. It pushes agencies to move faster, but it also says national security systems should not depend on AI tools that a private company can disable, degrade, or materially modify without government knowledge and approval.

That point should get the attention of contractors, frontier-model vendors, and legal teams working on high-consequence government deployments.

The Short Answer

• NSPM-11 tells the national security enterprise to accelerate AI adoption across intelligence and warfighting functions.
• It also makes vendor control, multi-vendor access, updated autonomy policy, and recurring governance updates part of the Federal AI agenda for national security systems.
• One of the most practical provisions says agencies should ensure, through contract clauses or other means, that no commercial entity or adversary can prevent use of, disable or degrade, or materially modify an AI system that warfighters rely on.

What The Memorandum Actually Does

The memorandum organizes policy around four pillars: adoption, adaptation, assurance, and accountability.

That framing matters because it is not simply a call to buy more AI. It is a directive to identify mission uses, adapt commercial and open-source systems where possible, demand reliability and control, and keep responsibility with commanders, directors, and agency heads.

Several implementation pieces stand out.

First, the memorandum orders an update to DOD Directive 3000.09 on autonomy in weapon systems within 90 days, with annual review after that.

Second, it calls for an AI governance policy for national security systems within 90 days, with implementation and reporting requirements and an instruction to maximize consistency with broader Federal AI governance rules where appropriate.

Third, it tells agencies to review procurement processes within 120 days so they can onboard advanced AI models from multiple vendors more quickly.

Fourth, it directs the government to build more secure computing access, support AI test ranges, create industry security partnerships, expand AI talent pipelines, and launch an AI National Security Strategic Reserve of non-governmental talent.

This is a serious operating memo, not just a statement of intent.

The Vendor-Control Clause Is The Provision Companies Should Not Miss

The strongest practical compliance signal may be in the assurance section.

The memorandum says the national security enterprise must ensure, through contractual clauses or other means, that no commercial entity or adversary can prevent use of, disable or degrade, or materially modify without Federal Government knowledge and approval an AI system that personnel depend on for missions.

That is bigger than a generic security aspiration.

It points toward concrete contracting and product questions:

• Can the vendor remotely limit, suspend, or alter mission-critical functionality?
• Can a model provider push material changes without customer approval?
• Can availability be interrupted by unilateral policy, billing, sanctions, hosting, or safety-gating decisions?
• Can the government keep using the system in a contested environment or after supplier disruption?
• What audit trail exists for model updates, safety controls, and configuration changes?

For companies selling into defense, intelligence, or other national security settings, this starts to look like a product-governance term sheet, not just a policy slogan.

Multi-Vendor Access Is Not Just About Competition

The memorandum also criticizes single-vendor dependence and tells agencies to rapidly onboard advanced AI models from multiple vendors.

That has an obvious competition angle, but it also has a resilience angle.

If agencies are being told to avoid brittle dependence on one supplier while also making sure no outside entity can silently disable or reshape a mission-critical AI system, vendors should expect procurement scrutiny around portability, continuity, fallback options, and operational control.

In practice, that can spill into:

• termination and transition rights,
• escrow or continuity planning,
• approval rights for major model changes,
• logging and notice obligations,
• deployment architecture choices, and
• subcontractor flow-downs.

The legal issue is not just whether the model performs well. It is whether the government can trust the control surface around the model.

The Contract-Termination Language Raises The Stakes

Another provision deserves more attention than it has gotten.

The memorandum directs relevant agencies, to the maximum extent permissible by law, to terminate for default or convenience contracts with companies that have repeatedly shown a pattern of conduct inconsistent with the memorandum's policy, subject to a limited waiver process.

That does not mean routine AI vendor disagreements will suddenly become termination fights.

It does mean the document is not only aspirational. It ties the policy to procurement consequences. For AI vendors and prime contractors, that creates a reason to document how products, update practices, surveillance boundaries, speech-related controls, and customer restrictions line up with the memorandum's policy pillars.

Accountability Still Sits With Human Decision-Makers

The memorandum is also explicit that commanders, directors, and agency heads remain responsible for ensuring that civil-liberties, privacy, and legal obligations are met.

That matters because fast adoption documents often get read as if responsibility is being pushed into the tooling layer.

This one does not do that. It accelerates deployment while keeping human accountability in place. That means agencies will still need governance records showing who approved use cases, what limits applied, what testing occurred, and how oversight kept pace with system changes.

For vendors, that usually means customer questionnaires, documentation demands, and negotiation pressure around explainability, testing, validation, logging, and update controls.

Why This Matters Beyond Defense Contractors

The memo is written for the national security enterprise, but some of its logic is broader than that label.

If the Federal Government is moving toward AI procurement terms centered on operational control, vendor independence, multi-vendor resilience, and documented accountability, those expectations may not stay neatly confined to warfighting systems.

Critical-infrastructure programs, sensitive public-sector systems, and other high-consequence deployments may start borrowing the same logic even when this exact memorandum does not apply.

That is often how these Federal signals travel. The first hard questions show up in national security. The contracting habits spread later.

What Companies Should Review Now

Companies that build or supply AI into government or high-consequence environments should be able to answer a few questions now:

• Who can remotely change, restrict, or disable the product?
• What contract language governs model updates, service suspension, and customer approval?
• Can the deployment survive vendor interruption, adversary disruption, or loss of one supplier?
• What evidence exists for testing, validation, logging, and approval of material changes?
• Are product, security, legal, and government-sales teams aligned on what control commitments are actually being made?

If those answers are fuzzy, NSPM-11 is a useful reason to tighten them.

Bottom Line

NSPM-11 is not just a message that national security agencies should use more AI.

It is also a signal that the government wants advanced AI systems it can control, validate, sustain, and procure without fragile dependence on a single vendor or silent private-sector override. The memorandum's vendor-control clause and contract-termination language are the parts companies should read most carefully.

For contractors and AI vendors, the practical takeaway is simple: capability matters, but control rights, update rights, resilience, and documentation are becoming part of the product.

Sources

• National Security Presidential Memorandum/NSPM-11
• White House fact sheet on the memorandum
• Clearon article on the earlier AI cybersecurity and frontier-model executive order