Illinois is becoming one of the clearest examples of where employment AI regulation is heading: notice, documentation, and practical scrutiny of how tools influence decisions.
If you want the official bill history, Illinois’s law is here: HB 3773. The Illinois Department of Human Rights also has a direct summary page here: Artificial Intelligence in Employment.
Recent draft rules from the Illinois Department of Human Rights would implement the state's newer restrictions on AI discrimination in employment. The bigger point is the compliance model taking shape around them.
The trigger looks broad
The reported standard is not limited to futuristic hiring bots. The rules would apply when AI is used “to influence or facilitate” covered employment decisions, including recruiting, hiring, promotion, discipline, discharge, training selection, and terms or conditions of employment.
That deserves attention because the notice trigger may be broader than many employers expect. If AI is involved in screening resumes, targeting job ads, evaluating candidates, analyzing interviews, or helping shape employment outcomes, notice may be required even if the employer did not intend discrimination.
Employment AI is becoming an operations issue
The trend line is clear: employment AI law is moving away from “prove the tool caused unlawful bias first” and toward “tell people when the tool is in the process, document what it is doing, and be ready to defend the workflow.”
That is why legal teams need a real inventory of where AI shows up in the employment stack, not just in one recruiting product. AI can appear in sourcing, ranking, interview analytics, assessments, chatbots, promotion systems, and workforce-monitoring features.
The takeaway
The answer is not to ban every automated feature. It is to map the tools, define which ones influence covered decisions, and decide where notice, contract review, testing, and documentation are required.
Illinois is sending a simple message: if AI helps shape employment outcomes, silence is not a compliance strategy.
California's latest AI move did not come through a broad consumer AI statute. It came through procurement.
If you want the official source, California’s executive order is here: Executive Order N-5-26.
In March 2026, Governor Gavin Newsom issued Executive Order N-5-26, directing the state to build a new procurement framework for AI. That may sound narrower than a headline AI law, but it could matter just as much for companies that sell AI tools or services into large buyers.
Procurement is where AI governance gets real
The order points toward a system in which AI vendors may need to make structured representations about how their systems are built, governed, and monitored. That includes familiar pressure points like data handling, bias controls, civil-liberties protections, and related safeguards.
Procurement is where abstract AI principles often become contract obligations. It is easy to talk about responsible AI in marketing language. It is much harder to answer a buyer's concrete questions about training data, oversight, controls, auditability, and remediation.
What legal teams should take from it
Procurement is one of the fastest ways to force operational discipline. Buyers can demand certifications, representations, warranties, and disclosure commitments long before legislatures settle every policy fight.
That means legal departments are no longer just debating AI governance in theory. They are negotiating it in contracts.
The takeaway
For vendors, the lesson is simple: if governance documentation does not exist in a usable form, build it now. For buyers, California offers a practical model for imposing more discipline on higher-risk AI tools without waiting for a perfect statute.
California is not just regulating AI through lawmaking. It is shaping the market through purchasing power. That is often how governance becomes real.
Connecticut has moved from “state to watch” to a state companies may actually need to operationalize against.
If you want the official bill text, Connecticut’s latest substitute text is here: SB 5.
On May 1, 2026, the legislature passed SB 5, a broad AI bill that would place Connecticut among the more aggressive state players in AI governance. The point is not just that another state acted. It is that Connecticut appears to be building a framework that spans multiple AI risk areas at once.
What makes this state move worth watching
A lot of state AI proposals focus on one slice of the problem, usually hiring tools, consumer protection, or deepfakes. Connecticut's approach is broader. It treats AI governance as a cross-functional legal problem rather than a niche product issue.
That matters because it better reflects how organizations actually use AI. AI now touches hiring, customer communications, vendor tools, automated decisions, synthetic media, and internal workflows.
The patchwork problem is getting harder
SB 5 is also another reminder that federal law is not about to simplify the map. States are continuing to legislate, and they are doing it with different definitions, priorities, and enforcement models.
That creates two practical tasks for legal teams. First, they need a real inventory of where AI shows up in the business. Second, they need a governance structure that can absorb state variation without rewriting the whole policy stack every time a legislature moves.
The takeaway
Connecticut’s bill may not become the national template by itself. But it does point toward the future: AI governance that looks more like privacy or employment compliance, meaning state-specific, operationally demanding, and hard to solve with one policy memo.
Connecticut is not the whole story. But it is increasingly part of the real one.
Colorado's AI law is moving again before many companies have even finished mapping the original version.
If you want the official text, the Colorado bill is here: SB26-189.
In May 2026, lawmakers passed SB 26-189, a major rewrite of the state's earlier AI framework. The main shift is from regulating broadly defined “high-risk AI systems” to regulating automated decision-making technology, or ADMT, when it materially influences consequential decisions.
What stands out is how directly the law targets decision environments legal teams already care about: employment, housing, lending, insurance, health care, education, and essential government services. The practical question is less about what a tool is called and more about how it is used when it affects a person in a meaningful way.
The new focus is operational accountability
The revised bill is set to take effect on January 1, 2027. That buys time, but it also makes the compliance direction clearer.
Developers would need to give deployers technical documentation on intended uses, training data categories, limitations, and human-review instructions. Deployers would need to provide consumer notices and, after an adverse outcome, a plain-language explanation of the role the system played. Consumers would also have rights to seek correction of inaccurate data and meaningful human review.
What legal teams should focus on
This is especially important for employment and other high-impact workflows. Recruiting tools, ranking systems, interview-analysis products, and recommendation engines can all end up inside the regulatory frame if they materially influence decisions.
That means the compliance question becomes more concrete: what is the system doing, who is relying on it, what notice is required, and what happens when someone challenges the outcome?
The bigger lesson
Colorado’s rewrite is a useful reminder that state AI compliance is still moving in real time. Static AI policies are going to age badly. Legal and compliance teams need a more flexible operating model that can absorb changing definitions, disclosure duties, and review rights across states.
The takeaway is not that Colorado is backing away from AI regulation. It is that Colorado is trying to make its law more targeted and more workable. For companies using AI in consequential decisions, the safer question is not “do we use AI?” but “can we explain and defend how this system influenced the decision?”
Companies are reporting meaningful efficiency gains from AI, and that kind of advantage is quickly making AI tools essential to staying competitive. In software development, tools like GitHub Copilot can speed routine work, shorten timelines, and help teams do more with less.
But essential does not mean risk-free. From a legal perspective, AI-generated code can create licensing, attribution, and compliance problems if companies are not paying attention. The GitHub Copilot litigation is a useful example because it helps show how those risks can move from the tool provider into the user’s own codebase.
This article explains the risk and offers practical guidance on both the front end and the back end to help companies reduce it.
The Copilot case is a warning sign, not a final doctrinal answer
The district court’s January 22, 2024 order dismissed a number of claims at the pleading stage and narrowed the case substantially, which is an important reminder that the litigation does not establish broad liability simply because the technology is controversial. But the dispute has continued through appeal-related proceedings, including the appellate activity described in this Courthouse News report on the Ninth Circuit argument. For companies watching from the sidelines, that matters. No business needs to wait for a final appellate roadmap before addressing an obvious governance issue.
It would be a mistake to view the Copilot litigation as a problem limited to GitHub, Microsoft, OpenAI, or the named plaintiffs. The more important corporate question is what happens when a developer accepts AI-generated code and merges it into a proprietary codebase. If the generated output is substantially similar to open-source code, the company may inherit a provenance problem. If the code at issue is associated with a copyleft license, the consequences may be more disruptive than a missed notice or attribution defect. The company may face the argument that its own use, distribution, or incorporation of the code triggers obligations it never intended to accept.
What makes copyleft risk different
Many companies already know how to manage conventional open-source software under permissive licenses such as MIT, BSD, or Apache 2.0. Those licenses impose real conditions, but they are usually manageable through familiar inventory, notice, and compliance processes. Copyleft licenses create a different category of concern because they can impose reciprocal obligations that become much more uncomfortable for companies trying to protect proprietary and confidential code. The GNU Project’s explanation of what copyleft means is a useful starting point, even for non-specialists. And courts have long recognized that open-source license conditions can carry real legal force, as the Federal Circuit explained in Jacobsen v. Katzer and as the Northern District of California reinforced in Artifex Software, Inc. v. Hancom, Inc..
From a practical corporate perspective, the fear is easy to understand: a company may face the argument that code it believed it exclusively owned is subject to broader disclosure, source-availability, or licensing obligations.
That is the nightmare scenario.
It is also important not to overstate it. Copyleft consequences are not automatic. Whether any particular use of generated code would trigger meaningful license obligations depends on a fact-intensive analysis and, in a litigated case, on how a court evaluates both the code and the remedy sought. But uncertainty is not a comfort. In many settings, legal ambiguity increases risk because it increases the cost of getting to an answer. Even if a company ultimately prevails, a dispute over provenance, licensing, and code inheritance can produce delay, remediation expense, customer friction, diligence problems in M&A or financing, and significant litigation leverage.
This is not just a lawyer problem
AI-generated code often arrives in a form that feels operationally harmless: a helpful function, a well-structured block, a clean suggestion that appears to solve the task at hand. That experience makes it easy to treat the output as legally equivalent to code written from scratch. But provenance is often opaque, and that opacity is the problem. One recurring legal theory in the Copilot case has involved alleged failures to preserve copyright-related information, an issue tied to 17 U.S.C. § 1202.
A developer may not know whether a snippet is generic, independently generated, loosely informed by training data, or very close to code published in a repository under specific licensing terms. Once that code is accepted, revised, and blended into a broader codebase, tracing the issue later becomes much more expensive.
So the legal risk begins as a workflow issue. It starts with one prompt, one suggestion, and one merge. It becomes a company problem later, when the code is shipped, reviewed in diligence, examined in discovery, or challenged in a dispute. By then, the cheap fix may be gone.
The harshest risk should be described carefully — but not ignored
The worst-case scenario is easy to understand: a claimant argues that the company’s use of AI-generated code has triggered copyleft obligations requiring disclosure or broader licensing of code the company considers confidential and proprietary. That result is not automatic, and it would be careless to say otherwise. Whether such a remedy is plausible in any given case depends on the license, the facts, the nature of the alleged copying, the role of the generated code in the larger work, whether distribution occurred, and the court’s view of appropriate relief. The GNU Project’s GPL FAQ gives a sense of why these questions quickly become complex, even before a court gets involved.
But companies should not take comfort from the fact that a remedy would be contested. The wiser position is not to become the test case.
What companies should do now
The answer is not to ban AI coding tools. The answer is to govern them like they matter.
That starts with front-end controls:
decide which AI coding tools are approved
define where they can and cannot be used
restrict use in especially sensitive or high-value proprietary repositories
train developers not to accept generated code reflexively
treat prompts and outputs as compliance-relevant, not just productivity artifacts
It also requires back-end controls:
human code review with a provenance lens
open-source scanning and similarity review where appropriate
escalation paths for suspicious snippets
documentation of AI-generated code use in development workflows
rewrite questionable code early instead of litigating over it later
Governance frameworks can help here. The NIST AI Risk Management Framework is not specific to software licensing, but it provides a useful model for building governance-based controls around AI adoption. Tool selection matters as well. Enterprise-grade offerings with stronger logging, administrative controls, and contractual commitments are often easier to defend than ad hoc usage with little visibility. And for organizations that want a more structured compliance program around open-source use generally, the Linux Foundation’s open-source guidance resources are a practical place to start.
Front-end controls, however, are not enough. Companies should assume that some risky code may still get through and build back-end review mechanisms designed to catch it before release. That means human review with a provenance lens. Code review should not stop at whether the code compiles, performs, or passes security checks. Where AI coding tools are in use, reviewers should also be alert to suspiciously polished, oddly specific, or poorly explained generated code, especially in contexts where open-source inheritance would create real business pain.
Technical controls can reinforce that process. Open-source scanning tools, similarity review, provenance checks, and escalation procedures can help surface issues while they are still cheap to solve. If a snippet raises concern, rewriting it may be far less expensive than litigating later about whether the original output carried hidden obligations. Documentation also matters. If AI-generated code is used in development, the company should have some way to record where, when, and under what conditions. Those records can help with internal compliance, incident response, diligence, and eventual litigation posture.
This is not bureaucracy for its own sake. It is part of building a defensible process.
How precautions may matter in court
Reasonable precautions do more than reduce the underlying compliance risk. They also affect how a company looks if a dispute arises. Courts pay attention to conduct. A company that rolled out AI coding tools with no restrictions, no training, no review, and no audit trail presents a very different picture from a company that adopted policies, trained developers, implemented controls, and addressed concerns when they surfaced. That difference may not eliminate liability. But it can matter when a court evaluates intent, proportionality, equitable relief, and remedy. The Supreme Court’s decisions in eBay Inc. v. MercExchange, L.L.C. and Winter v. Natural Resources Defense Council, Inc. are reminders that severe equitable relief is not automatic and depends on traditional equitable principles.
That point is especially important where the feared remedy is severe. A company that can show genuine preventive and detective efforts is better positioned to argue that any relief should be tailored rather than effectively punitive. Put more plainly, a court may be less inclined to force the harshest result where the defendant can show it tried to prevent the problem on the front end and catch it on the back end.
Bottom line
The lesson from the Copilot litigation is not that companies must abandon AI coding tools. It is that they should stop treating those tools as legally neutral. Where generated code may carry hidden open-source obligations, especially copyleft risk, the cost of inattention can be far greater than a routine compliance problem. Companies that adopt sensible controls on the front end and disciplined review on the back end will be better positioned to reduce both the underlying risk and the chance that a court views severe remedies as justified.
Lawyers and business teams are increasingly using AI to think through legal and risk questions.
That does not automatically make the prompt, output, or workflow privileged.
The practical risk is simple: if people put sensitive legal analysis into the wrong AI environment, they may create a discoverable record instead of a protected one.
This is a privilege, confidentiality, and workflow problem showing up in a new tool.
The key practical point
There is a major difference between:
a public or lightly controlled AI tool
and an enterprise environment with negotiated controls, restricted retention, and clear terms that do not permit your prompts or data to be used to train models for other users
That distinction should be doing a lot of work in legal AI policy.
If the tool is not enterprise-approved, if the data controls are unclear, or if the provider can use prompts to improve models for others, legal teams should assume the risk is much higher.
What not to do
Do not paste live dispute facts, investigation details, board communications, draft legal theories, or regulator-response strategy into a casual AI tool.
Do not assume a prompt is protected just because it relates to legal advice.
Do not let employees use consumer AI tools for sensitive legal work without tool-specific approval.
Do not treat “internal” and “privileged” as if they mean the same thing.
Do not rely on vague vendor marketing about privacy or security. Check the actual enterprise terms, retention settings, training terms, and admin controls.
What to do instead
Use an enterprise AI environment with contractual controls and settings that prevent your prompts and data from being used to train models for other customers or the public service.
Limit legal-use cases to approved tools and approved users.
Create a short list of off-limits prompt categories, including litigation strategy, privileged investigation facts, deal-sensitive issues, and regulator-response planning.
Require lawyer involvement when the purpose of the workflow is legal advice.
Know what records the tool keeps, where they are stored, who can export them, and how long they remain available.
What recent cases make clear
Recent attention to cases like United States v. Heppner has put a spotlight on a basic point many organizations still blur: a communication can feel private and still fail privilege requirements.
In Heppner, Judge Rakoff held that AI-generated materials created through Claude were not protected by attorney-client privilege or the work-product doctrine because the defendant disclosed information to a third-party platform and the materials were not prepared by counsel or at counsel’s direction.
Different cases can come out differently, and courts are not applying a one-line rule that all AI prompts are discoverable or all AI-assisted work loses protection.
But that is not a reason for comfort. It is a reason to stop assuming the facts will break your way.
A useful default rule
If a prompt would be uncomfortable to hand to an opposing lawyer, regulator, or prosecutor later, it should not be casually entered into an unstructured AI workflow.
That rule is not perfect, but it is much better than assuming “we were just using AI to think.”
The takeaway for legal teams
The real issue is not the model by itself. It is whether the workflow, tool, and contract structure are good enough to support sensitive legal use.
Clearon AI’s recommendation is not to ban AI for legal work. It is to make sure legal AI use happens inside the right workflow.
approve an enterprise AI environment with terms and settings that protect sensitive prompts and do not allow them to train models for other users
block consumer or unapproved tools for privileged, litigation, investigation, and regulator-response work
limit sensitive legal prompting to approved users and defined use cases
give employees concrete do-and-don’t rules instead of vague policy language
treat prompt security, retention, and export controls as part of legal workflow design, not an afterthought
In law, workflow mistakes have a nasty habit of becoming exhibits.
The EU AI Act story in 2026 is no longer about one looming deadline.
It is about figuring out what moved, what did not, and where legal teams should spend compliance time first.
“The AI Act was delayed” is too sloppy to be useful.
Recent reporting indicates that the European Parliament and Council reached agreement on amendments that would postpone some major obligations, especially around high-risk AI uses and watermarking timing, while the European Commission also published draft guidance on transparency obligations that still begin this year.
So the practical question is not whether the AI Act matters less. It is where the immediate compliance pressure now sits.
It is what still appears to hit in 2026 and what can likely be sequenced later.
The short version
Here is the cleanest practical read based on current reporting:
What did not move
core transparency obligations still appear set for August 2, 2026
disclosure expectations for AI systems that interact with people
related user-facing design and notice questions
the need to review where AI-generated or AI-manipulated content appears in products and workflows
What moved later
AI-generated content transparency and some watermarking-related timing reportedly moves to December 2, 2026
Annex III high-risk AI systems reportedly move to December 2, 2027
Annex I product and product-safety high-risk AI systems reportedly move to August 2, 2028
That does not mean companies can relax.
It means they should stop treating every AI Act obligation as if it lands on the same day.
What stayed on the 2026 calendar
The biggest mistake legal teams can make here is hearing “delay” and translating it into “not urgent.”
That would be a bad read.
Even with the reported changes, core transparency obligations still appear positioned to matter starting August 2, 2026.
For many organizations, that means focusing now on systems that interact directly with users and making sure disclosures are not buried in terms or documentation nobody reads.
In plain English, companies should be asking:
Where are users directly interacting with AI systems?
Is the disclosure clear in the interface itself?
Are we treating different user groups appropriately?
Do any product flows involve AI-generated or AI-manipulated content that raises separate transparency issues?
Are product, legal, compliance, and design teams aligned on what the user actually sees?
That is practical work. Not compliance cosplay.
What legal teams should do now
This is the moment for reprioritization, not celebration.
A practical checklist:
map AI systems that directly interact with users
identify where AI-generated or AI-manipulated content appears
review interface-level disclosures instead of relying on buried policies
separate immediate 2026 transparency work from later high-risk build-out
revisit vendor diligence questions and contract language in light of the updated timing
give business teams a clearer timeline so “delay” does not become an excuse for doing nothing
For in-house teams, this is also a communications problem.
If the business hears only that the EU delayed the AI Act, the organization may under-resource work that still appears likely to happen this year.
That misunderstanding can create more risk than the original deadline pressure.
The bigger lesson
The EU AI Act is becoming a sequencing challenge.
That means the winning move for legal teams is not just knowing the rules. It is knowing the order in which the rules matter.
That is what good AI governance looks like in practice.
Not panic.
Not delay theater.
Just disciplined prioritization.
The AI Act still matters in 2026.
The real question now is which part of it is knocking first.
One caution, though: because this area is moving through amendments, guidance, and implementation detail at the same time, legal teams should confirm the latest official timetable before treating any one summary as the final word.
Anthropic's latest legal AI release looks like more than a product update.
On May 12, the company rolled out a broader legal package for Claude that reportedly includes 12 legal practice-area plug-ins, more than 20 integrations with legal and adjacent platforms, and tighter workflow support across Microsoft 365. Public reporting suggests the package is aimed at law firms, in-house teams, and other legal users. It also suggests Anthropic wants Claude closer to the legal workflow layer.
The competitive question is shifting.
It is becoming less about which model writes the best draft in isolation and more about which company can sit inside the legal workflow itself.
Anthropic's latest move looks like an effort to push Claude further in that direction.
From general legal help to practice-specific workflows
Anthropic had already entered the legal workflow conversation earlier this year with a general legal plug-in for Claude Cowork. This new release appears to go further by organizing legal work around more specific workflows and user types.
Public reporting describes plug-ins aimed at commercial, corporate, privacy, regulatory, litigation, employment, product, and AI-governance work, along with tools for law students, clinics, and legal builders. The point is not simply that Claude can answer legal questions. The point is that Anthropic is trying to package legal work into more structured, agentic flows that can move across applications and systems.
That is significant because lawyers do not work in a single interface. They work across Word, Outlook, document management systems, diligence platforms, e-discovery tools, contract systems, research resources, and internal knowledge sources. A system that carries context across those environments becomes much more useful than a model that only produces polished text in a chat window.
This deserves law-firm attention
For law firms and legal departments, the strategic implication is pretty straightforward: foundation-model companies are moving closer to the lawyer.
That puts pressure on legal AI vendors whose main value is wrapping a frontier model with prompts, UI, and light workflow features. It does not mean those vendors disappear. It does mean they will need to show real differentiation — authoritative sources, traceable outputs, stronger governance, better matter-specific workflows, deeper institutional knowledge integration, or more defensible professional use.
For in-house legal departments, the implications may be even more immediate. A system that can help with first-pass contract review, playbook-based redlines, privacy and regulatory issue spotting, and better organization of matter context could allow internal teams to handle more work before involving outside counsel. That does not mean outside firms become less important. It means the handoff may change. Instead of sending out broad, early-stage requests, in-house teams may increasingly use AI-assisted workflows to narrow the issues, improve initial drafts, and escalate more selectively. If that happens, the impact will not just be productivity. It will be a shift in how legal spend is allocated and where legal work gets done.
That is especially clear in the Thomson Reuters response. Thomson Reuters announced a Claude integration for CoCounsel Legal and emphasized “fiduciary-grade” legal AI, authoritative content, traceability, and trusted professional standards. That framing is telling. It suggests the market is sorting into two overlapping but distinct layers:
general-purpose AI for speed, drafting, and exploratory work
professional-grade legal systems for authoritative, high-stakes work
Those are not the same thing, and lawyers should not pretend they are.
A useful tool is not the same thing as a defensible workflow
That is the biggest caution here.
Better plug-ins and more integrations do not automatically solve legal governance. Earlier reporting on Claude Cowork noted that Anthropic’s own support materials warned against using Cowork for regulated workloads because certain activity was not captured in compliance APIs, audit logs, or data exports. Even as Anthropic’s legal tooling gets more capable, firms still need to ask the boring-but-critical questions:
Where does the data go?
What can be logged and audited?
What is retained?
What can be supervised?
Which tasks are appropriate for AI drafting assistance, and which require a more controlled system?
Those questions matter more than the demo.
What this likely means next
Anthropic’s release does not prove that specialized legal tech is finished. It does suggest that the legal tech stack is being reshaped from below. Foundation-model companies no longer seem content to remain behind the scenes while others own the workflow layer.
For lawyers, the right response is neither panic nor dismissal. It is disciplined evaluation.
The firms that benefit most from this shift will not necessarily be the ones that buy the most AI tools. They will be the ones that build the best workflows around them — with clear review standards, source verification, confidentiality guardrails, and realistic decisions about where general-purpose AI is enough and where it is not.
Anthropic’s latest legal release is important not because it settles the legal AI race.
It is important because it makes the real competition harder to miss.
