This article is general information, not legal advice. Consult counsel for your specific obligations.
Almost every US state AI statute divides the world into two roles.
A developer builds, sells, licenses, or substantially modifies the system. A deployer uses it to make or materially influence a decision about a person.
The split exists because the two parties know different things. The developer knows how the system was trained, what it was designed for, and where it fails. The deployer knows who it is being used on, for what decision, and with what consequences.
Neither can discharge the other’s duties, which is why the statutes assign different obligations rather than one shared standard.
Here is the part most companies get wrong: these laws are not aimed primarily at OpenAI, Anthropic or Google. Deployer obligations attach to the company that plugged a model into a hiring funnel, a loan decision, or a claims triage queue — regardless of whether it wrote a line of the model.
If your organisation screens resumes, scores leads, prices a policy, or triages support tickets with AI, you are probably a deployer somewhere.
Key Takeaways
- Colorado’s AI Act — the law nearly every “developer versus deployer” guide describes — was repealed before it ever took effect. SB 26-189 replaced it in May 2026, effective 1 January 2027.
- Most published guidance still describes the repealed statute, including its duty of care, impact assessments, and NIST safe harbor. None of those survived.
- These laws do not primarily target frontier labs. Deployer duties fall on the ordinary company that connected a model to a hiring, lending, or claims workflow.
- California’s AI Transparency Act became operative on 2 August 2026, adding watermarking and detection duties with penalties of $5,000 per violation per day.
- Colorado’s replacement voids any contract clause shifting liability for your own violation onto another party — which makes vendor indemnities a live procurement issue.
Quick Navigation
- The State AI Laws Reset of 2026
- Which State AI Laws Are in Force Today
- What Builders Owe Under State AI Laws
- What Deployers Owe Under State AI Laws
- The Contract Layer Most Teams Miss
- When You Are Both Builder and Deployer
- Where State AI Laws Do Not Reach Agents
- State AI Laws and the Federal Preemption Fight
- Building One Program for Many State AI Laws
- Primary sources
- Frequently Asked Questions
The State AI Laws Reset of 2026
This is where accuracy matters most, because the reference point moved.
Colorado’s SB 24-205, signed in May 2024, was the first comprehensive US AI statute and became the model everyone cited. It imposed a duty of reasonable care on both developers and deployers, required annual impact assessments and risk management programmes, and mandated attorney-general notification of algorithmic discrimination.
It never took effect.
The timeline: enforcement was delayed from 1 February to 30 June 2026 by SB 25B-004. On 27 April 2026, a federal court enjoined enforcement in xAI v. Weiser. Then in May 2026, Governor Polis signed SB 26-189, which repealed and reenacted the entire framework as an automated decision-making technology statute effective 1 January 2027.
What did not survive the rewrite is as important as what did.
Gone: the duty of reasonable care, annual impact assessments, risk management programme mandates, and — notably — the framework-based affirmative defense that let companies rely on recognized standards.
Retained and reshaped: developer documentation duties, deployer notice duties, consumer recourse, and three-year recordkeeping.
The scope also narrowed, from “high-risk AI systems” to “covered automated decision-making technology” that materially influences consequential decisions. ADMT is a term borrowed from privacy law, and it may capture tools the old AI-system definition missed.
Any guide describing Colorado’s duty of care or impact assessments is describing a repealed law.
Which State AI Laws Are in Force Today
As of August 2026, here is what actually binds.
| Law | Status | Primary target |
|---|---|---|
| California SB 53 (TFAIA) | In force since 1 Jan 2026 | Frontier model developers |
| California AB 2013 | In force since 1 Jan 2026 | Generative AI developers |
| California SB 942 / AB 853 | Operative 2 Aug 2026 | Large generative AI providers |
| Texas TRAIGA (HB 149) | In force since 1 Jan 2026 | Developers and deployers |
| Illinois HB 3773 | In force since 1 Jan 2026 | Employers |
| NYC Local Law 144 | In force since 2023 | Employers using AEDTs |
| Colorado SB 26-189 | Effective 1 Jan 2027 | Developers and deployers |
Three points worth noting.
Texas is currently the broadest comprehensive law in force. TRAIGA is narrower than Colorado’s original design — the high-risk impact assessment regime was cut from the final bill. It prohibits developing or deploying AI intended to manipulate, unlawfully discriminate, incite self-harm or criminal activity, produce CSAM or non-consensual intimate imagery, or conduct government social scoring. Crucially, it grants an enforcement safe harbor to organisations substantially complying with the NIST AI RMF.
California’s approach is several narrow laws rather than one broad one. SB 53 targets frontier developers with safety framework publication and incident reporting. AB 2013 requires training-data disclosure far more broadly. SB 942, operative since 2 August, requires covered providers with over one million monthly users to offer detection tools and latent disclosures.
Reach follows the consumer, not your address. These laws generally apply if your system affects that state’s residents. A company in Bengaluru with California applicants has California obligations.
What Builders Owe Under State AI Laws
Developer duties cluster into four categories. This is the first of the two role-specific checklists.
Duty 1 — Documentation to deployers. Under Colorado’s SB 26-189, from 1 January 2027 developers must give each deployer, in a form reasonably understandable and protective of trade secrets: a statement of intended uses and known harmful or inappropriate uses; a description of the categories of data used in training, to the extent known; known limitations and risks; and instructions for appropriate use, monitoring and meaningful human review.
Duty 2 — Update notification. Developers must notify deployers of material updates, intentional modifications, and changes to intended use or risk mitigation within a reasonable time. This turns model updates into a communications obligation, not just an engineering event.
Duty 3 — Public transparency. California layers this on separately. AB 2013 requires public documentation of training data. SB 53 requires frontier developers to publish safety frameworks and report critical incidents. SB 942 requires detection tooling and content provenance.
Duty 4 — Recordkeeping. At least three years, including version identifiers, changelogs and material-update documentation.
One scoping limit worth knowing: Colorado’s developer obligations apply where the technology was marketed, configured, contracted or licensed for consequential decisions, or where the developer becomes aware of such use consistent with intended purposes. A general-purpose tool used off-label by a customer is treated differently from one sold for that purpose.
What Deployers Owe Under State AI Laws
Deployer duties are fewer but more consumer-facing, and they carry the operational burden.
Duty 1 — Pre-use notice. Before a covered system is used in a consequential decision, the deployer must tell the consumer. Point-of-interaction notice, plain language.
Duty 2 — Post-adverse-outcome explanation within 30 days. If the system materially influenced a decision that went against someone, the deployer must provide a plain-language description of the system’s role and the principal factors it used. This is the single heaviest operational lift in the new Colorado framework, because it requires per-decision explainability your vendor may not supply.
Duty 3 — A path to meaningful human review. Not a form that disappears. An actual route to a human who can revisit the outcome — which is why human-in-the-loop design has moved from good practice to statutory requirement.
Duty 4 — Recordkeeping. Three years of usage records demonstrating compliance.
Employment deployers carry extra weight regardless of Colorado. Illinois HB 3773 amends the Human Rights Act to prohibit employer use of AI that discriminates against protected classes. NYC Local Law 144 requires bias audits for automated employment decision tools. Both are in force now.
The Contract Layer Most Teams Miss
This provision deserves its own section because it changes procurement, not just compliance.
SB 26-189 voids any contractual clause that attempts to shift liability for a party’s own discriminatory use of ADMT onto another party. An indemnity purporting to shield you from your own violation is void as against public policy.
Two practical consequences.
Your vendor indemnity may not do what you think. If your AI procurement contract leans on the vendor absorbing discrimination liability, that allocation may be unenforceable in Colorado. Review existing agreements now rather than in December.
Your customers will ask you for documentation you do not produce. Deployers cannot meet their obligations without developer documentation covering intended uses, training-data categories and limitations. Most vendors do not currently offer this as a standard contractual commitment. Builders who prepare it early turn a compliance cost into a sales advantage.
Liability now tracks intended use. Developers answer for harms from systems used as intended; deployers answer for their own deployment decisions, including uses the developer never authorized.
When You Are Both Builder and Deployer
Most companies of any size are both, and the roles do not net out.
If you fine-tune a foundation model and use it internally for hiring, you are a developer of the modified system and a deployer of it. You owe documentation duties to yourself in substance — meaning you must actually produce the artefacts, because your deployer-side notices depend on them.

Substantial modification is the trigger to watch. Prompt engineering probably does not make you a developer. Fine-tuning on your own data probably does. The line has not been tested, and the statutes leave room for argument.
The practical approach: assess role per system, not per company. A single organisation may be a pure deployer for its CRM’s lead scoring, a developer for its fine-tuned resume screener, and out of scope entirely for its internal code assistant. The vocabulary underlying these distinctions is set out in our AI glossary.
Where State AI Laws Do Not Reach Agents
A gap worth naming, because it will shape the next legislative cycle.
Every statute described here regulates decisions about people. Consequential decisions in employment, housing, lending, insurance, healthcare, education, government services. That framing comes from anti-discrimination law, and it works well for a resume screener.
It fits an autonomous agent poorly.
An agent that queries a database, calls three APIs, and modifies a record is not making a consequential decision about a consumer in the statutory sense. It may still cause substantial harm. Nothing in the developer or deployer duties above addresses tool permissions, action scoping, or what happens when an agent takes an irreversible step.
Three practical consequences follow.
Your agent deployments may be out of scope and still risky. Compliance is not a proxy for safety here. The distinction between systems that generate output and systems that take actions is drawn in agentic AI versus generative AI, and current statutes are written almost entirely for the first category.
Scope can attach unexpectedly. If an agent’s output feeds a consequential decision — even indirectly, as one input among several — the deployer duties may apply to the workflow it sits inside. “Materially influences” is a broad phrase and has not been narrowed by any court.
The documentation you build now transfers. System inventories, role assessments and three-year records are the same artefacts any future agent-focused statute will demand. Building them for today’s laws is not wasted effort if the scope expands.
Texas offers a partial preview. TRAIGA’s intent-based prohibitions apply to developing or deploying AI intended to manipulate or unlawfully discriminate, without requiring a consequential-decision context. That structure reaches conduct the Colorado model does not.
State AI Laws and the Federal Preemption Fight
There is no comprehensive federal AI statute as of August 2026, and none appears imminent.
What exists is executive action. Executive Order 14365, signed 11 December 2025, directed the Attorney General to establish an AI Litigation Task Force to challenge state AI laws on interstate commerce and preemption theories, and directed a Commerce review that could condition federal broadband funding on a state’s AI posture. It named Colorado’s AI Act specifically.
No federal preemption has been enacted. The push is live litigation and legislative pressure, not settled law.
The practical posture recommended by most counsel is straightforward: comply with what is in force, track the litigation, and do not treat the preemption push as a reason to pause. State laws remain enforceable unless and until a court or statute says otherwise.
Colorado adds a second layer of uncertainty. Enforcement is subject to the federal stay from xAI v. Weiser, and Attorney General Weiser has indicated the state will not enforce until required rule-making is complete — rule-making that had not formally begun as of mid-2026. The 1 January 2027 date is real but the enforcement posture behind it is not yet fixed.
Building One Program for Many State AI Laws
More than 2,000 AI-related bills have been introduced across the states. Chasing each one individually does not scale.
Inventory first. Every system that processes personal data and produces an output used to make, guide or assist a decision in education, employment, housing, financial services, insurance, healthcare or government services. Include the tools a team bought on a corporate card.
Assess role per system. Developer, deployer, both, or out of scope.
Govern to a stable framework. The NIST AI RMF earns an explicit enforcement safe harbor in Texas. It does not in Colorado’s successor — that defense did not survive the rewrite — but it remains the most widely referenced baseline and satisfies overlapping duties across jurisdictions.
Build the notice machinery. Pre-use disclosure and a 30-day adverse-outcome explanation workflow. Start here if resources are tight; it is the longest lead-time item.
Renegotiate vendor terms. Require developer documentation as a contractual deliverable. Check indemnities against the anti-shifting provision.
Keep three years of records. Version identifiers, changelogs, usage logs, notice delivery evidence.
Re-check quarterly. Colorado’s law was delayed, enjoined, repealed and replaced within eighteen months. Treat any compliance map as a snapshot.
Primary sources
- Colorado SB26-189, Colorado General Assembly
- Texas HB 149 (TRAIGA)
- California SB 53 (TFAIA)
- NIST AI Risk Management Framework
Statutory status changes frequently and several provisions here are subject to pending litigation. This article is general information, not legal advice.
Frequently Asked Questions
Is the Colorado AI Act still law?
No. SB 24-205 was repealed and reenacted as SB 26-189 in May 2026 and never took effect. The replacement is narrower, focuses on automated decision-making technology, and is effective 1 January 2027 subject to ongoing litigation.
Am I a developer or a deployer?
You are a developer if you build, sell, license or substantially modify a covered system; a deployer if you use one to make or materially influence a consequential decision. Many organisations are both, assessed per system rather than per company.
Do state AI laws apply if my company is outside the US?
Generally yes, where your systems affect that state’s residents. Reach attaches through consumers, applicants and data subjects rather than through your business address.
What happens if federal preemption succeeds?
No preemption has been enacted. Executive Order 14365 created a litigation task force, and challenges are pending. Until a court or statute changes it, state obligations remain enforceable.
Which single framework covers the most ground?
The NIST AI RMF. It provides an explicit enforcement safe harbor under Texas TRAIGA and maps onto documentation and governance duties elsewhere, though Colorado’s successor statute dropped its framework-based defense.
Keep reading
Here are the latest posts from the blog.

State AI Laws: 4 Proven Steps for Builders and Deployers

Sandbox Isolation: The 4 Layers That Contain Failure

What Inference Actually Costs Per Token
