The feature was small: a model call that drafts the reply, scores the applicant, or generates the image. Nobody in the sprint review used the word deployer, and nobody needed to, because the regulation assigns the role by what the feature does, not by what the team calls itself.
The EU AI Act assigns roles per feature, and your own changes can switch them
Article 3 of the European Union’s AI Act (Regulation 2024/1689) defines a provider as a body that “develops an AI system” or has one developed and places it on the market or puts it into service “under its own name or trademark.” A deployer is a body “using an AI system under its authority,” other than in a personal, non-professional activity. The roles attach per system, not per company. A startup that builds a screening feature on a model API and sells it is that feature’s provider; the customer running it on applicants is its deployer; and the startup is a deployer of every AI tool its own staff use. Most teams hold both roles by their second product and have written neither down.
The provision product teams rarely read is Article 25, amended by the Digital Omnibus. A deployer or other third party is treated as the provider of a high-risk AI system in three circumstances: when “they put their name or trademark on a high-risk AI system already placed on the market or put into service,” without prejudice to contracts that allocate the obligations otherwise; when “they make a substantial modification to a high-risk AI system that has already been placed on the market” and it remains high-risk; or when “they modify the intended purpose of an AI system, including a general-purpose AI system,” so that it becomes high-risk. When any of those occurs, “the provider that initially placed the AI system on the market or put it into service” is no longer the provider of that system, and must cooperate with the new one on documentation and technical access, unless it clearly specified that the system was not to be changed into a high-risk system.
Two definitions in Article 3 make this a product problem rather than a legal one. A substantial modification is a change after market placement “which is not foreseen or planned in the initial conformity assessment carried out by the provider.” And the intended purpose is whatever the provider stated, “as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.” The landing page copy is part of the legal definition of what the product is for. A white-label deal, a fine-tune, and a new use case in a sales deck are each a feature decision and a role switch, and nothing in the pipeline flags it.
Regulators do not ask what you call yourself. They ask what the feature does, and assign the role from there.
Regulators do not ask what you call yourself. They ask what the feature does, and assign the role from there.
The Omnibus moved the high-risk dates and left the role mechanics alone
The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026. Cuatrecasas’ same-day summary sets out what moved: obligations for the stand-alone high-risk systems in Annex III now apply from 2 December 2027, and those for high-risk systems embedded in products under harmonised safety legislation from 2 August 2028. Providers of generative AI systems placed on the market before 2 August 2026 “will have a transitional period until December 2, 2026, to meet the marking obligation in article 50(2).” A separate grace period lets high-risk systems already on the market before their application date carry on under the old rules, with a trap: “any significant change to the design after the date specified will trigger the obligation to fully comply with the provisions applicable to high-risk AI systems.” The deadlines moved. The mechanism that assigns roles, and the one that resets the clock when a team changes the product, did not.
If the feature lands in a high-risk category, such as hiring, credit or education, Article 26 sets the deployer’s duties, and each becomes a question in your customer’s procurement. The deployer must use the system “in accordance with the instructions for use,” assign human oversight to “natural persons who have the necessary competence, training and authority,” inform the provider immediately of a serious incident, keep the automatically generated logs “of at least six months,” inform workers’ representatives before workplace use, and “inform the natural persons that they are subject to the use of the high-risk AI system.” A provider without instructions for use, a logging interface, and an incident channel is selling a feature its customers cannot lawfully run.
Colorado rewrote its statute and kept the roles
Colorado’s year shows how durable the mechanism is. Senate Bill 24-205, the 2024 Colorado Artificial Intelligence Act, was due to take effect on 30 June 2026. It never did. Eckert Seamans’ June 2026 analysis records that “a major AI developer commenced a federal constitutional challenge” and that the US Department of Justice intervened on its side. “A federal court entered a stay of enforcement on April 27, 2026.” On 14 May 2026 Governor Polis signed SB 26-189, which repeals and replaces the 2024 act and “is scheduled to take effect on January 1, 2027.”
Seyfarth’s account of the replacement law lists what was removed: the duty of reasonable care against algorithmic discrimination, formal risk management programs, impact assessments, and the rebuttable presumption of compliance tied to frameworks such as the NIST AI RMF. What survived is what product teams should study. The statute covers automated decision-making technology that processes personal data to produce predictions, scores or recommendations that guide decisions about individuals. Developers owe deployers “a general statement of the ADMT’s intended uses, known risks and limitations,” the categories of training data, and material updates. Deployers must give notice before use and, after an adverse outcome, provide disclosures “within thirty days,” including a plain-language explanation and the right to “request for meaningful human review and reconsideration of the decision.” Liability under existing anti-discrimination law is “allocated based on relative fault,” and indemnification provisions that shield either party are “void as contrary to public policy under the new Colorado law.”
The roles survived the rewrite intact. What changed is what each owes the other: the documentation flow from developer to deployer, and the limits on shifting liability by contract, are now written into law. A startup that cannot produce the intended-use statement has handed its Colorado customers a compliance gap, and indemnifying its way out will not hold.
The role determination is a launch artifact, and product owns it
Our assessment is that the fix is a one-page role determination per AI feature, written before launch and re-run at every model swap, fine-tune, or purpose change. It records what the feature does, who uses it under whose authority, and which role that creates in each market. It states the intended purpose in the provider’s own words and checks that the sales deck says the same thing, because under Article 25 the purpose statement is the line your own team can cross without noticing. It lists what the company will hand its customers: instructions for use, logs, an incident channel, and the intended-use statement Colorado’s developers will owe from January 2027. The product lead owns it, counsel reviews it, and it ships with the feature.
No regulator will ask what the team called itself in the sprint review. The feature either interacts with people, generates content, or shapes a consequential decision, and the role follows from that. Teams that write the determination down inherit their obligations on purpose; the rest inherit them anyway, and find out in diligence or in discovery.