A new lawsuit against Meta asks a question many employers have managed to postpone: what happens when employees say AI helped decide who lost a job, while the employer says humans made the decisions without AI scoring or ranking?

Twenty-six current and former Meta employees allege that the company used internal AI systems, activity-monitoring data, productivity measures, AI-token consumption, and algorithmically assisted rankings to select workers for a May 2026 reduction in force. The plaintiffs say the process penalized employees who had taken protected medical, parental, pregnancy-related, caregiver, or family leave.

Meta denies using AI to make the selections. In a declaration filed with the court, a Meta human-resources director said human business leaders made the decisions using documented criteria and that there was no AI-assisted scoring or ranking related to employee performance.

The case is Does 1 Through 26 v. Meta Platforms, Inc., No. 3:26-cv-07122-WHO, filed July 13 in the Northern District of California. The court has denied the employees' request for a temporary restraining order, but it did not resolve the underlying claims. U.S. District Judge William Orrick found "serious questions going to the merits" and said discovery in arbitration would be needed to test Meta's account.

That dispute is what makes the case useful. It shows the evidentiary problem employers will increasingly face when workforce decisions sit near performance systems, activity data, AI tools, dashboards, and human approvals. The central issue may be less about one identifiable algorithm than whether the employer can prove what did and did not affect the result.

What The Employees Allege

The complaint says Meta began notifying about ten percent of its workforce on May 20 that they had been selected for termination.

According to the plaintiffs, managers who knew the employees' work did not assemble the termination list through individualized judgment. They allege that Meta used a group of internal tools and data sources that included:

• "Metamate," described as an internal large-language-model assistant;
• employee-trained "second brain" agents that ingested communications and work documents;
• keystroke, screen-content, mouse, browser-history, and other activity data;
• dashboards showing employee-level AI-token consumption;
• productivity, output, performance, and calibration measures; and
• algorithmically assisted rankings, including what the complaint calls an "AI-native" rating.

Those details are allegations, not established findings. They still illustrate why a modern workforce case may be hard to explain through a conventional account of one supervisor making one decision.

The plaintiffs' central theory is that the system rewarded signals employees could accumulate only while actively working. Someone on protected leave could not generate code commits, output volume, AI-tool usage, roadmap ownership, or similar measures at the same rate as an employee who was present throughout the measurement period.

The complaint alleges that Meta failed to neutralize protected-leave periods, remove affected employees from the comparison group, or require an individualized review that accounted for leave and accommodations. The employees claim those omissions turned apparently neutral productivity signals into negative factors tied to protected activity or disability.

The complaint brings claims under federal and state employment laws, including the Family and Medical Leave Act, the Americans with Disabilities Act, the Pregnancy Discrimination Act, and the Pregnant Workers Fairness Act. It also invokes laws in several states and the District of Columbia.

What The Court Has Said So Far

The July 17 temporary-restraining-order decision gives both sides something to point to.

Meta submitted a declaration stating that human business leaders made the selections using criteria such as job profile, level, historical and recent performance ratings, tenure, location, job function, specialized skills, and organizational structure. The declaration said no plaintiff was selected because of leave, disability, or another protected characteristic and that AI made no selection decision.

The employees submitted declarations describing their understanding of Meta's growing use of AI in performance reviews and internal employee classifications. But the judge noted that they were not present when the reduction-in-force decisions were made and did not yet have evidence rebutting Meta's direct account.

Judge Orrick found that the employees had raised serious questions but had not shown a likelihood of success on the existing record. He denied emergency relief largely because most claimed harms, including lost employment, benefits, leave, and equity, could be addressed through damages or relief in arbitration.

The order did identify a narrower concern. Four plaintiffs held Meta-sponsored employment visas, and the judge said the potential loss of immigration status likely could constitute irreparable harm. He directed Meta to submit declarations explaining how and why those four employees were selected. The preliminary-injunction hearing is scheduled for August 24.

The order did not decide whether Meta used AI improperly or violated employment law. It framed the proof question: the employees suspect that AI-related systems affected the result; Meta says they did not; and the relevant records are largely controlled by Meta.

The Hard Question Is How The Decision Was Made

Companies often describe AI as advisory. A manager still approves the result, so the company may believe that a human remains responsible for the decision.

That description does not resolve the legal or factual problem.

If an algorithm determines which employees receive scrutiny, converts workplace activity into a score, sets a comparative ranking, or supplies the recommended list, the later human approval may carry less weight than the company assumes. The quality of the human review matters more than the existence of a final click.

An employer defending this kind of case may need to show:

• what systems and data affected the decision;
• which metrics were calculated and over what period;
• how leave, disability accommodations, and missing data were treated;
• whether managers could change a recommendation;
• what information managers saw before approving it;
• how often managers overrode the system; and
• whether anyone tested the process for distorted or discriminatory results.

A human signature at the end of the process does not answer those questions.

Measurement Windows Can Become Legal Risk

The complaint focuses attention on a basic design choice: the measurement window.

A productivity system can appear neutral while treating absence as poor performance. That risk grows when the system relies on volume measures such as messages sent, code committed, documents produced, hours active, or AI tokens consumed.

The problem is not limited to formal leave. Disability accommodations may change how or when an employee works. Pregnancy-related restrictions may reduce certain kinds of activity. Caregiving leave can create gaps that a ranking system reads as lower output. A system trained on uninterrupted work histories may treat legally protected circumstances as performance signals unless the employer deliberately changes the design.

Governance teams should therefore ask a more precise question than whether a model uses protected characteristics. They should ask whether the system uses proxies or measurement rules that systematically encode the effects of protected leave, disability, pregnancy, or accommodation.

Employers Need A Decision Record, Not Just An AI Policy

Most AI policies say that people must remain involved in consequential decisions. That is a useful principle, but it is not a litigation record.

For workforce decisions, employers need documentation tied to the actual event. A defensible record should identify the system version, input fields, relevant dates, scoring logic, exclusions, adjustments, reviewers, overrides, and final reasons for each decision.

That record should also explain how the employer handled protected leave and accommodations. If a measurement period overlapped with leave, the company should be able to show whether it adjusted the denominator, removed the affected period, used a different comparison, or excluded the metric.

The same principle applies to vendors. A company may use a third-party model, but the employment decision remains the company's. Contract language should provide access to the documentation, testing information, logs, and technical support needed to investigate a challenged result.

Discovery Will Reach Beyond The Final Layoff Spreadsheet

The complaint also shows how quickly an employment dispute can become an AI-governance and data-preservation matter.

Relevant evidence may include:

• prompts and outputs from internal assistants;
• model and scoring documentation;
• employee-level dashboards;
• activity-monitoring records;
• calibration materials;
• communications about metric selection;
• bias, validation, and impact testing;
• manager instructions and override records; and
• records showing when employees requested leave or accommodations.

Legal holds written for ordinary personnel files may miss much of that material. Some records may sit in analytics platforms, model logs, collaboration systems, or vendor environments with short retention periods.

Employment counsel, privacy teams, and technical owners should decide in advance who can preserve those records and how quickly preservation can begin.

What Companies Should Review Now

Employers do not need to wait for a ruling in the Meta case to examine their own processes.

Start with an inventory of every system that can affect selection for promotion, discipline, performance management, restructuring, or termination. Include systems described internally as analytics, productivity, workflow, or decision support. Labels do not determine whether a tool influences an employment decision.

Then map the inputs. Look specifically for measures that fall when an employee is absent or working under an accommodation. Test whether protected leave changes an employee's score, rank, comparison group, or likelihood of additional review.

Finally, inspect the human-review step. Reviewers need enough information and authority to identify a distorted recommendation. A process that asks a manager to approve hundreds of names without explaining the underlying data is not meaningful review.

The Larger Lesson

The Meta lawsuit may succeed, fail, or narrow as the employees pursue their claims in arbitration. Their allegations have not been proven, and Meta has submitted a direct factual denial.

The governance problem exists either way. Employers are combining workplace monitoring, productivity analytics, internal AI assistants, performance ratings, and ranking systems. When those systems affect a termination decision, the company needs to reconstruct the path from raw data to final outcome.

If AI helps build the layoff list, an employer should be ready to show what the system measured, what it ignored, who reviewed the result, and how legally protected circumstances were kept from becoming negative signals.

Without that record, "a human made the final decision" may be a conclusion the evidence cannot support.

Sources and Related Clearon Coverage

• courthousenews.com
• courthousenews.com
• reuters.com
• reuters.com
• cbsnews.com
• butzel.com

The last major excuse for waiting is gone.

The European Commission has now adopted final Article 50 transparency guidelines. At nearly the same time, the EU's Digital Omnibus was published in the Official Journal and made parts of the AI Act's high-risk timetable final law.

Those two developments belong in the same article because plenty of teams are going to misread them together.

The easiest mistake now is to assume the Omnibus delayed the whole AI Act rollout. It did not. The amended high-risk dates are now final law, but the Article 50 transparency duties still apply on August 2, 2026.

That means companies no longer need to guess whether practical Commission guidance will arrive before the deadline. It arrived. They also should stop telling themselves that the new Omnibus timing buys them more time on transparency. It does not.

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

What Changed This Week

Three separate EU developments now need to be read together.

First, the Commission adopted final practical guidelines on Article 50 transparency obligations for providers and deployers of AI systems. The guidance covers direct AI interactions, machine-readable marking of AI-generated or AI-manipulated content, deepfake labelling, certain public-interest text disclosures, and notice duties for emotion-recognition and biometric-categorisation systems.

Second, the Digital Omnibus was officially published as Regulation (EU) 2026/1744. That matters because it turns the revised high-risk timetable into final law instead of a politically agreed future change.

Third, the EU also published Commission Implementing Regulation (EU) 2026/1755 on procedural arrangements for Commission evaluations of general-purpose AI models. That is not an Article 50 rule, but it shows the wider AI Act implementation machinery is moving from policy talk into formal instruments.

The practical result is simple. The EU implementation picture is now clearer, not blurrier.

What The Omnibus Actually Changed

The Omnibus matters. It just does not matter in the way some summaries will imply.

The new regulation changes parts of the AI Act's high-risk timetable. According to the official publication, the relevant Annex III high-risk regime now moves to December 2, 2027, and product-embedded high-risk systems move to August 2, 2028.

That is real law now.

But the Omnibus did not postpone Article 50. The transparency obligations still apply from August 2, 2026. If a company walks away from this week thinking "the EU delayed AI Act deadlines," that company may be calm about exactly the wrong deadline.

This distinction matters because Article 50 sits in a very different lane from the high-risk regime. The high-risk rules are about system categories, lifecycle controls, and sector-specific obligations. Article 50 is about transparency in actual outputs and interactions. For many companies, Article 50 hits public-facing content and product workflows much sooner than the heavier high-risk framework ever will.

Why The Final Guidelines Matter

Until now, some teams could say they understood the direction of travel but were still waiting for final Commission guidance on scope and implementation.

That position is much harder to defend now.

The Commission has moved Article 50 guidance from pending to final. The guidance is still nonbinding. Article 50 itself remains the binding law. But final Commission guidance changes the planning posture in at least three ways.

First, it narrows the room for pretending that core implementation questions are still too unsettled to begin workflow changes.

Second, it gives legal and compliance teams a better basis for making near-term judgments about which products, interfaces, and publishing flows are in scope.

Third, it raises the standard for companies that want to reject the Commission-backed path and rely on a custom approach instead. That choice is still available. It is just easier to scrutinize now.

The earlier milestones already pointed in this direction. The Commission had published the transparency Code of Practice, said it adequately covers Articles 50(2), (4), and (5), and publicly identified signatories to the broader GPAI Code structure. The final guidelines now add the missing implementation layer many organizations said they were waiting for.

The Rule Is Binding. The Guidance Is Not. That Distinction Still Matters.

This is where companies can still trip over their own summaries.

The legal obligation comes from Article 50. The final guidelines do not replace the statute and do not create a new binding act. They are implementation guidance.

The Code of Practice is different again. It remains voluntary even after the Commission's adequacy assessment and public signatory list.

So there are three separate layers:

• Article 50 is binding law.
• The final guidelines are nonbinding Commission guidance.
• The transparency Code is a voluntary compliance path.

That separation matters because teams need to know what they must do, what the Commission recommends, and what route they may choose to use as evidence of compliance.

It also matters for anyone writing internal updates. If a business memo says "the Commission finalized Article 50 rules," it risks flattening together the law, the guidance, and the Code in a way that creates confusion later.

What Companies Should Be Doing Right Now

The final guidelines do not eliminate every edge case. They do make it harder to justify delay in the parts of the work that were always operational.

That work starts with inventory.

Companies should identify which products and workflows may trigger Article 50 analysis. That includes customer-facing AI systems, media-generation tools, marketing and communications pipelines, newsroom or publishing processes, synthetic audio and video workflows, public-facing text generation, and interfaces where a user may need to be told they are interacting with AI.

Then comes role mapping.

Many organizations will be both providers and deployers depending on the product or workflow. That cannot be solved once at the company level and forgotten. It has to be mapped feature by feature and channel by channel.

Then comes scope mapping.

Teams need working rules for when content qualifies as AI-generated or AI-manipulated, when it becomes a deepfake, when text is published to inform the public on a matter of public interest, and when direct AI interaction notices are required.

Then comes control testing.

The key question is not whether a label can be drafted. It is whether the notice, marker, metadata, or disclosure actually survives the channels where people encounter the content. Web pages, mobile surfaces, PDFs, screenshots, syndicated content, reposted clips, social snippets, image exports, and partner distribution all deserve testing.

Then comes evidence.

If a company is ever asked what it did before August 2, it should be able to show role assignments, workflow decisions, scope calls, implementation dates, exception handling, and testing results. A last-minute label pasted onto content with no decision trail behind it is weak compliance hygiene.

Where The Hard Questions Still Sit

The public conversation around Article 50 still overfocuses on labels.

The harder questions are mostly underneath the label:

• Who decides when a piece of content is in scope?
• Who owns the distinction between provider and deployer in mixed workflows?
• How will machine-readable marking behave when content is clipped, embedded, reformatted, or redistributed?
• What counts as enough disclosure when AI-generated text is part of a broader edited publication?
• How will product, legal, trust and safety, editorial, and communications teams avoid giving different answers to the same question?

The final guidelines help. They do not remove the need for judgment.

That is why the next two weeks matter more than the next abstract policy debate. Most organizations do not need another conceptual conversation about transparency. They need ownership, workflow decisions, and testing.

Why The New GPAI Evaluation Rule Still Belongs In The Background

The new implementing regulation on evaluations of general-purpose AI models is not the headline for most readers of this article.

It still matters.

It shows that the EU is not only publishing speeches, FAQs, and voluntary frameworks. It is also putting binding procedural instruments in place for the Commission's evaluation and enforcement architecture.

That broader context should affect how companies read Article 50. Even though Article 50 is about transparency rather than GPAI model evaluations, both developments point the same way: the implementation phase is now real enough to change legal and product behavior, not just policy slide decks.

A Better Internal Message Than “The EU Delayed Things”

If you need a one-line summary for management, this is the better one:

The EU clarified and formalized more of the AI Act this week, but it did not delay the Article 50 transparency duties that matter on August 2.

That framing is closer to the truth than the broader and sloppier claim that the EU "pushed back AI Act deadlines."

Some deadlines did move. This one did not.

That matters because Article 50 is likely to hit public-facing workflows sooner than many teams expect. It is not mainly a frontier-model issue. It is a publishing, product, disclosure, and recordkeeping issue.

Bottom Line

The final Article 50 guidance is here.

The Omnibus is now final law.

Neither development gives companies a reason to delay transparency work.

The opposite is true. The Commission has made the implementation picture clearer, and the new Omnibus publication removes one source of confusion while creating another for anyone who reads it carelessly. The high-risk timetable changed. The Article 50 date did not.

If teams are still waiting for the right moment to move Article 50 from policy discussion into operational compliance, this was that moment.

Sources

• European Commission final guidelines on Article 50 transparency obligations
• Regulation (EU) 2026/1744 in the Official Journal
• Commission Implementing Regulation (EU) 2026/1755
• European Commission opinion on adequacy assessment of the transparency Code
• European Commission page for the GPAI Code and signatories
• 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: Article 50 Is Almost Here. Treat EU AI Transparency As A Workflow Deadline.

Sources and Related Clearon Coverage

• digital-strategy.ec.europa.eu
• eur-lex.europa.eu
• eur-lex.europa.eu
• digital-strategy.ec.europa.eu
• digital-strategy.ec.europa.eu
• clearon-ai.com
• clearon-ai.com
• clearon-ai.com

I started looking more closely at Hawaii’s new conversational-AI law because it seemed familiar.

Act 248 requires AI disclosures, suicide and self-harm protocols, protections for minor account holders, and annual reports to the state Behavioral Health Administration. Violations can be treated as unfair or deceptive practices.

California, New York, Oregon, Washington, Connecticut, Colorado, Idaho, Iowa, Nebraska, Georgia, and Rhode Island have enacted laws that reach parts of the same product category. Once those statutes are placed next to one another, the overlap is obvious. So are the differences.

I could not find a useful way to explain that in a short state update. So I built a State AI Companion and Conversational Chatbot Law Guide for Clearon.

A State Count Does Not Tell You What To Build

“Similar laws” is a fair description. Product and legal teams still need the differences before they can decide what to build.

One state may require recurring disclosures. Another may focus on the start of the interaction. Some regulate crisis referrals for every user. Others add detailed restrictions for minors involving sexual content, emotional dependence, reward systems, secrecy, isolation, or spending pressure.

The reports go to different places. Hawaii uses its Behavioral Health Administration. California uses its Office of Suicide Prevention. Rhode Island requires reports to the Attorney General. Oregon has a separate reporting structure.

The remedies differ too. Some statutes rely on state consumer-protection enforcement. Oregon provides a private action for ascertainable harm. California includes a separate limited civil remedy. Idaho and Nebraska say their laws do not create a private right of action.

Those choices affect product design, recordkeeping, contracts, and litigation risk.

What The Guide Covers

The guide compares enacted laws in twelve jurisdictions that directly regulate companion or conversational AI:

• California
• Colorado
• Connecticut
• Georgia
• Hawaii
• Idaho
• Iowa
• Nebraska
• New York
• Oregon
• Rhode Island
• Washington

For each jurisdiction, the guide identifies the law and operative date, then compares disclosure, crisis response, protections for minors, reporting, and enforcement.

The guide keeps related laws in a separate section. Broader children’s online-safety statutes, therapy-bot restrictions, and narrowly targeted criminal provisions may belong in the same risk review, but they do not regulate the same products in the same way.

Pending bills stay in a separate section. Legislative passage is not enactment, and a proposal does not create a current compliance duty.

The Repeated Requirements

The statutes keep returning to four practical questions.

Does the user know this is AI? A notice may be required at the start of an interaction, during a long session, or more often when a minor is involved.

What happens when a user expresses suicidal thoughts or an intent to self-harm? The answer has to work inside the product. It also has to be tested and documented.

What changes for minors? The newer laws reach the conversation and the engagement design. They address sexual content, simulated dependence, isolation from trusted adults, rewards, and emotional pressure to keep using the product.

Can the company prove what happened? Annual reports, Attorney General inquiries, and private claims all depend on records. A company may need to show which notice appeared, how the system handled a crisis signal, and which safeguards were active for a minor account.

Hawaii Shows Why A Multistate Map Is Necessary

Act 248 sits near the center of this group. It combines disclosure, crisis protocols, minor protections, reporting, and consumer-protection enforcement. It still falls short as a national template.

A company could satisfy Hawaii’s reporting route and miss California’s reporting details. It could comply with one state’s disclosure language and miss another state’s frequency requirement. It could maintain a general minor-safety policy without addressing Washington’s or Idaho’s more specific engagement restrictions.

I think a control matrix is more useful than twelve isolated memos. Each duty can be assigned to a product owner and matched with an effective date, a technical or operational control, and evidence that the control works.

This Will Need Maintenance

The guide is dated and was last reviewed July 29, 2026.

Several laws have 2027 operative dates. Colorado rulemaking is still developing. New York has a separate minor-safety bill that passed both chambers but had not been confirmed as enacted when the guide was prepared. Other states are considering their own measures.

I drew a firm line between enacted duties and pending proposals. A state will move into the main table only after enactment can be confirmed through an official source.

Blending bills, signed laws, effective requirements, investigations, and enforcement findings produces a misleading picture of what companies must do now.

Companion chatbot regulation has become a multistate compliance issue.

The statutes share a basic structure: nonhuman notice, crisis response, protections for minors, reporting, and enforcement. The legal work is in the differences.

Read the new State AI Companion and Conversational Chatbot Law Guide for the comparison table, source links, and practical review questions.

Sources

• Hawaii SB 3001 and Act 248
• Hawaii Governor announcement
• California SB 243
• Connecticut Public Act 26-15
• Oregon SB 1546
• Washington HB 2225

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