How States Are Approaching AI Developer Definitions in AI Legislation
Weekly Update, Vol. 82.
Last month, we took a look at how state AI laws defined “deployers” and related downstream actors, and why those definitions matter for businesses that use artificial intelligence systems to make consequential decisions. But deployers are only one half of the regulatory equation. Many of the most consequential policy choices in state AI legislation occur further upstream, in how lawmakers define who counts as a “developer” of an artificial intelligence system in the first place. Those definitions determine which entities are responsible for model design, training, testing, and documentation, and whether obligations attach at the point a system is built or only once it is put to use.
This article continues our series by focusing on how states define AI developers, and how those definitions diverge across emerging regulatory frameworks. As with deployers, small drafting choices can dramatically expand or narrow the scope of regulation, determining whether a law applies to a handful of frontier model builders, a broad swath of software companies, or nearly any business that meaningfully modifies an AI system.
Regulating developers is central to state AI policy because many of the most significant risks associated with artificial intelligence are baked in long before a system is ever deployed. Decisions about training data, model architecture, optimization goals, and built-in safeguards shape how an AI system will behave across countless downstream uses. By the time a deployer uses a system to screen job applicants, underwrite loans, or assess eligibility for housing or benefits, the model’s capabilities and limitations may be largely fixed already. As a result, policymakers seeking to prevent algorithmic discrimination or other harms increasingly view developer obligations as a way to address risk at its source, rather than relying solely on downstream users to identify and mitigate problems after the fact.
What is a developer?
Generally, a developer is considered the entity that develops and trains an AI model. The bills enacted in Colorado (CO SB 205) and vetoed in Virginia (VA HB 2094) would both define developers as an entity that develops an artificial intelligence system, but neither defines the term “develops.” The AI safety bill that was vetoed last year in California (CA SB 1047) went into greater detail, defining a developer as a person who “performs the initial training of a covered model either by training a model using a sufficient quantity of computing power and cost, or by fine-tuning an existing covered model . . . using a quantity of computing power and cost greater than” an amount specified in the bill.
What about those who modify AI systems?
On its own, this framing might suggest that developer obligations attach only to the entities that originally design and train an AI system. In practice, however, that distinction breaks down quickly in modern AI development, where models are routinely fine-tuned, adapted, and repurposed after initial training. As a result, some of the most consequential definitional choices in state AI legislation center not on who built a system first but on when downstream modification becomes significant enough to treat the modifying party as a developer in its own right. The Colorado law includes in the definition of developers those who “intentionally and substantially” modify an AI system, defining that term as a “deliberate change” that "results in any new reasonably foreseeable risk of algorithmic discrimination." The proposed bill in Connecticut (CT SB 2) included a caveat that the change be “not predetermined by a developer.”
Some states may try to apply different standards for general-purpose artificial intelligence models, as lawmakers in Connecticut and Virginia tried to do with legislation this year. Those proposed bills included changes to such an AI model that result in new foreseeable risks of discrimination, but also any change that affects compliance or “materially changes the purpose” of the model.
These bills exclude certain kinds of changes from those that would define an entity as a “developer.” Colorado’s law excludes changes that result from ongoing learning from the AI system, so long as that learning-based change was anticipated in advance, disclosed in the initial impact assessment, and documented in the system’s technical materials. In addition to excluding changes from ongoing learning, Virginia’s bill would have also excluded any customization made by deployers based on legitimate nondiscriminatory business justifications, that is within the scope and purpose of the artificial intelligence tool, and does not result in a material change to the risks of algorithmic discrimination.
Large vs. small developers
Rather than imposing obligations on all entities that develop or modify artificial intelligence systems, some lawmakers have instead sought to narrowly target the largest developers. This approach reflects concern that broadly defined developer obligations could sweep in startups, open-source contributors, and ordinary software vendors whose systems pose limited systemic risk. The California Artificial Intelligence Task Force wrestled with the idea of setting the scope of regulatory policies when it issued its report earlier this year.
“To determine the appropriate approach for setting a threshold in a given policy context, we recommend that policymakers adopt the default approach of using thresholds that align with the regulatory intent.”
By focusing on scale, capability, or compute thresholds, lawmakers can concentrate regulatory requirements on the models that feature greater capability, higher misuse risk, and more significant downstream effects.
California’s newly enacted Transparency in Frontier Artificial Intelligence Act (CA SB 53) applies to developers of “frontier models,” defined as a “foundation model that was trained using a quantity of computing power greater than 10^26 integer or floating-point operations.” That threshold comes from the Biden White House Executive Order on the development of artificial intelligence. The California Department of Technology is directed to review and recommend updates to the definitions of frontier models and frontier developers each year so they can evolve based on technology and standards.
The California law also distinguishes “large frontier developers,” which are defined as those that have over $500 million in annual gross revenues. While all frontier developers are subject to certain transparency requirements, large frontier developers must develop a risk management framework, issue catastrophic risk assessments, and report critical safety incidents.
New York’s RAISE Act (NY AB 6453/SB 6953), which is sitting on the governor’s desk, uses the same computing power threshold as the Biden Executive Order and California’s law, but adds that the compute cost must exceed $100 million. The bill would also apply to developers of artificial intelligence models produced by applying "knowledge distillation" to a frontier model, if the compute cost exceeds $5 million. Knowledge distillation is a technique where a large, powerful model is used to train a smaller or more efficient model. The RAISE Act would also exempt accredited colleges and universities from the definition of “large developers.”
Lawmakers have struggled to strike a balance between establishing meaningful guardrails and maintaining a light regulatory touch, and the scope of these proposals has often been the decisive factor. Concerns over burdening smaller startups have derailed some legislative efforts, while governors have vetoed other proposals because they left loopholes that allowed developers below certain thresholds to avoid meaningful obligations. As states continue to refine their approaches, these scope decisions will remain central, determining whether AI laws meaningfully target the sources of risk lawmakers are most concerned about or instead miss them entirely.
