AI Deployer vs Developer Obligations

Most U.S. AI laws and federal frameworks distinguish between developers of AI systems and deployers of those systems. Knowing which role applies to your organization — sometimes both — is the first compliance question.

A deployer is the organization that puts an AI system into operational use to make or materially influence a consequential decision about a person; a developer is the organization that creates, trains, or substantially modifies that system. The distinction decides which duties an organization owes. It does not decide who an enforcement agency can sue — that is a separate question, answered by the liability table under "Can AI developers be held liable?" below, and the two answers frequently diverge. Role definitions and enforcement provisions below were verified against primary statutory text on July 31, 2026.

The role definitions

Developer

A developer creates, trains, or substantially modifies an AI system. Colorado's original AI Act (SB 24-205, C.R.S. § 6-1-1701) defined a developer as a person doing business in Colorado that develops or substantially modifies a high-risk AI system — but that framework never took effect. A federal court paused enforcement on April 27, 2026, and on May 14, 2026 Governor Polis signed SB 26-189, which repeals and reenacts it as a narrower automated decision-making technology (ADMT) law effective January 1, 2027, with Attorney General rulemaking required by that date. SB 26-189 keeps the developer/deployer split for ADMT that materially influences a consequential decision; the operative definitions will not be final until rulemaking closes. See the Colorado AI Act page for current status (retrieved July 31, 2026). NIST AI RMF and ISO/IEC 42001 use parallel developer-side concepts in their MAP function and Annex A control set.

Developer duties typically include:

• Documentation: provide deployers with usage information, intended uses, harmful uses, training data summaries, performance evaluations, and mitigation measures
• Disclosure to deployers: enable downstream deployers to fulfill their own impact-assessment and disclosure obligations
• Bias mitigation in design: actively avoid training on data that produces algorithmic discrimination
• AG notification (Colorado): notify the Attorney General when discrimination is identified in the system

Deployer

A deployer puts an AI system into use for purposes within the law's scope — typically consequential decisions affecting consumers. Deployer duties usually include:

• Impact assessment: the stayed Colorado AI Act § 6-1-1703(3) prescribed an annual impact assessment (purpose, intended outputs, performance, transparency, monitoring, discrimination risks). It is the most detailed deployer-side assessment duty any US state has enacted, and it is not currently enforceable — treat it as a design reference until Colorado's SB 26-189 rulemaking sets the ADMT equivalent
• Consumer disclosure: notify the affected consumer when AI is used in a consequential decision
• Right to correct + right to appeal: where required by law, allow consumers to correct data and appeal adverse decisions
• Post-deployment monitoring: ongoing performance, drift, and bias monitoring
• AEDT bias audit (NYC LL 144): deployers in NYC employment context must run annual independent bias audits

Vendor

Vendors providing AI tools to other organizations sit upstream of deployers and downstream of developers. Specific contractual obligations depend on the relationship — many vendor agreements transfer parts of the developer-side documentation obligation to the vendor.

The split varies by law

Not every law uses the same role taxonomy — and three of the laws below never use the word "deployer" at all. NYC Local Law 144 addresses an "employer" or "employment agency," Illinois HB 3773 an "employer," and California SB 942 a "covered provider." An organization that scopes itself by the word rather than the conduct will mis-scope in all three. The statutory term each law actually uses is in the liability table under "Can AI developers be held liable?" below.

See the Developer obligations page and Deployer obligations page for the consolidated obligation matrix.

Can AI developers be held liable?

Owing a duty and being the party an enforcement agency can proceed against are different questions, and US AI laws answer them differently. The table below records, for each law, who carries the statutory duty, the term the statute actually uses, the enforcement channel, whether a private plaintiff can sue, and any cure period or statutory defense. Compiled from the primary statutory text cited on each law page; retrieved July 31, 2026.

Read down the table and a pattern falls out that the developer-versus-deployer framing alone hides: developer-side exposure in current US AI law is transparency liability, not outcome liability. Where a statute reaches the builder at all — AB 2013, SB 53, SB 942 — the duty is to publish, disclose, or report something. Where a statute reaches the outcome of an automated decision — NYC LL 144, Illinois HB 3773 — the respondent is the employer that used the tool, and the vendor that built it is not a party to the proceeding.

Only Colorado's ADMT Act and Texas TRAIGA place duties on both sides of the same transaction, and neither creates a private right of action, so a developer's statutory exposure in both states runs through a state Attorney General rather than a plaintiff. That is why developer-side risk in practice is usually allocated by contract — indemnities, representations about training data, and audit-cooperation clauses — rather than by statute. Contractual allocation does not move a statutory duty, but it is what determines who ultimately pays.

Two consequences for scoping:

• A deployer cannot contract out of its own statutory duty. Under LL 144 and HB 3773 the

employer is the respondent regardless of what the vendor agreement says, so procurement language should be read as a recovery mechanism, not a compliance control.

• A developer with no US deployer-side footprint is not automatically out of scope. AB 2013,

SB 53, and SB 942 attach to the act of releasing or providing a system, not to using it in a decision.

How to scope your role

1. List your AI systems in an AI compliance framework register that records owner, role, jurisdiction, and evidence status, then anchor those role decisions in an AI governance operating model.
2. For each system, ask: did we create or substantially modify it? If yes → you are a developer for that system. Did we put it into operational use to make decisions or interact with consumers? If yes → you are a deployer for that system.
3. Both is common: most enterprises that build any in-house AI also deploy AI bought from vendors. You will be a developer for some systems and a deployer for many more.

Use the Compliance Checker to walk through this scoping with your operational facts.

Where the line gets fuzzy

• Substantial modification — fine-tuning a foundation model, applying prompt engineering, or wrapping an API may or may not count. Colorado defines "substantially modify" to include changes that materially alter the system's risks or intended use.
• Vendor-provided AI — if you procure an AI tool and embed it in your decision flow, you are typically a deployer; the vendor is typically a developer. Contractual allocation does not change statutory obligations but can shift indemnification.
• Internal-only deployment — laws focus on consumer-affecting use. Internal productivity AI without consequential decisions is mostly out of scope.

What to do next

• Map each AI system to a role in your inventory
• For developer obligations: prioritize documentation and bias-testing baselines
• For deployer obligations: prioritize impact assessment and consumer-disclosure workflows
• Adopt a federal framework as your control baseline — NIST AI RMF (GOVERN function for developer policy, MAP/MEASURE for performance and bias evidence) or ISO/IEC 42001 (Annex A control set, certifiable AI management system)

Frequently asked questions

What is an AI deployer?

An AI deployer is the organization that puts an AI system into operational use to make or materially influence a consequential decision about a person — a hiring or promotion decision, a credit or insurance determination, a housing decision, or an education, healthcare, or government-services decision, depending on the statute. The deployer is normally the organization the consumer actually interacts with, and it is a deployer whether it built the system or bought it. Buying an AI tool from a vendor and embedding it in a decision flow makes the buyer a deployer, not a bystander. Three of the enacted US laws that impose deployer-style duties do not use the word "deployer": NYC Local Law 144 says "employer" or "employment agency," Illinois HB 3773 says "employer," and California SB 942 regulates a "covered provider" on the developer side instead.

Can AI developers be held liable under US AI laws?

Yes, but narrowly, and not for the decisions their systems produce. As of July 31, 2026, the US laws that reach developers — California AB 2013, California SB 53, and California SB 942 — impose transparency duties: publish a training-data summary, publish a safety framework and report incidents, or provide AI-detection and disclosure capabilities. Colorado's ADMT Act (SB 26-189, effective January 1, 2027) and Texas TRAIGA place duties on developers and deployers alike, and both are enforced exclusively by the state Attorney General with no private right of action. By contrast, the two laws that regulate automated decision outcomes — NYC Local Law 144 and Illinois HB 3773 — name the employer as the responsible party, not the company that built the tool. Developer exposure for downstream harm is therefore usually contractual rather than statutory.

Can a company be both an AI developer and an AI deployer?

Yes, and for most enterprises it is the normal case: the roles attach per system, not per organization. A company that fine-tunes or substantially modifies a model for its own use is a developer of that system and a deployer of it at the same time, while remaining only a deployer of every vendor-supplied tool in its stack. Scoping should therefore be done against an inventory of individual AI systems, with a role recorded for each, rather than by picking one label for the company. The both-roles obligation view shows the combined duty set.

Does a vendor that resells an AI tool count as a developer or a deployer?

It depends on what the vendor does to the system, not on how the contract describes it. A vendor that creates, trains, or substantially modifies the system is a developer; a vendor that only resells or hosts an unmodified third-party system is generally neither a developer nor a deployer of it, because it is not the party putting the system to use in a consequential decision. Utah is the outlier worth checking: its generative-AI disclosure duties in Utah Code title 13, chapter 77 attach to the "person" or "supplier" interacting with the consumer, which can capture a vendor operating a consumer-facing chatbot on a client's behalf. See the vendor obligation view.