Getting started
Do new state AI laws apply to companies that supply training data?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
New state AI laws, such as Colorado's AI Act and the Texas Responsible Artificial Intelligence Governance Act, place their main obligations on developers and deployers of AI systems, not on companies that supply training data. Suppliers still have work to do: document provenance, rights and privacy preparation, because developers ask for that evidence to meet their own duties.
Key takeaways
- Recent state AI laws are written around developers, who build AI systems, and deployers, who use them in decisions.
- A company that only licenses records is usually neither role, but it is drawn in through contract representations.
- Suppliers should limit warranties to facts they control, such as how records were collected and prepared.
- A supplier that also builds or uses AI in its own decisions is assessed separately for that activity.
- Provenance, rights, permitted use, privacy and release records answer most developer requests.
Who do new state AI laws actually regulate?#
New state AI laws mainly regulate developers, who build or substantially modify AI systems, and deployers, who use those systems to make or support decisions about people. A company that only licenses records for training is usually neither, and most of these laws do not define a separate data supplier role.
That does not take suppliers out of the picture. Developers carry documentation and risk duties, and they meet those duties partly by asking their data sources for evidence. The supplier's obligations arrive through contracts, alongside the privacy, intellectual property and confidentiality laws that already apply to its records.
The practical question for a supplier is therefore not whether it is regulated as a developer, but what its buyer is building. Records that will train a tool used in hiring, lending or housing decisions draw more questions than records used for a scheduling assistant.
Developer, deployer or data supplier: a role table#
A role table is the quickest way to see where obligations land. The descriptions are general; each law defines its roles in its own words, and one company can hold more than one role at the same time.
| Role | Who it is | Typical focus of recent state AI laws | Where a data supplier fits |
|---|---|---|---|
| Developer | Builds or substantially modifies an AI system | Documentation for deployers, disclosure of known risks and reasonable care against algorithmic discrimination in high-risk systems | Usually your buyer, who will ask you for provenance and rights evidence |
| Deployer | Uses an AI system to make or support decisions | Risk management, impact assessments and notices to affected people | Only if your company also uses AI in its own decisions |
| Data supplier | Licenses records used for training or evaluation | Generally no role-specific duties under these laws | Privacy law, contracts and IP law still govern the records |
| Supplier that also builds or uses AI | Licenses data and runs its own AI tools | Developer or deployer duties for those separate activities | Review each activity on its own terms |
What Colorado's and Texas's laws focus on#
Colorado's AI Act (SB 24-205), signed in May 2024, was written around high-risk AI systems used in consequential decisions, such as employment, housing, lending or insurance, with duties for developers and deployers. Its start date moved twice: a 2025 law delayed it to June 30, 2026, and on May 14, 2026 Colorado repealed and reenacted it in a narrower form effective January 1, 2027. Counsel should read the reenacted text rather than summaries of the original.
The Texas Responsible Artificial Intelligence Governance Act (HB 149), signed June 22, 2025, took effect on January 1, 2026. As generally described, it reaches private businesses more narrowly than Colorado's original law and centers on certain prohibited uses of AI and on government use. Neither law, as generally described, places direct duties on a company because it licensed training data. Both continue to be interpreted, which is why the analysis is done deal by deal with counsel.
Disclosure laws can reach suppliers indirectly. California AB 2013 requires developers of generative AI systems released on or after January 1, 2022 to post training-data documentation by January 1, 2026, including whether datasets were purchased or licensed and whether they contain personal information. A developer subject to it may ask its suppliers for exactly those facts.
How suppliers get pulled in through contracts#
Suppliers get pulled into AI law compliance through the license agreement, where developers ask for representations, documentation and cooperation that support their own obligations. The requests often go further than a supplier can verify, so the drafting matters.
A supplier can usually give factual statements about collection and preparation with confidence. It should be careful with promises about how a model will behave, because it does not control training, deployment or the decisions a model influences.
- A representation that records were collected lawfully and that the supplier has the rights to license them.
- A description of what the dataset contains, its sources, its date range and the systems it came from.
- Confirmation that sensitive categories, such as health details or protected characteristics, were removed or never collected.
- Cooperation with regulator inquiries or with the developer's own impact assessments.
- Indemnities for breaches of those representations.
What a supplier should still document#
A supplier should still document provenance, rights, permitted use and privacy preparation for every dataset, because that record answers both the developer's questions and any later dispute. Industry standards give a useful checklist even where no law requires them.
The Data & Trust Alliance Data Provenance Standards, for example, include a Use group with elements for confidentiality classification, consent documentation location, privacy-enhancing technologies applied, allowed and excluded processing and storage geographies, license to use, intended data use, and copyright, patent and trademark status. A supplier that can fill in those fields for each package is ready for most developer requests.
| Record | What it shows a developer | Who usually prepares it |
|---|---|---|
| System and date-range inventory | Where the records came from and what period they cover | COO or IT lead |
| Rights review | Contracts, vendor terms and notices that allow the license | General counsel or outside counsel |
| Privacy record | What was removed or transformed, and how it was checked | Privacy lead with the preparation team |
| Permitted use statement | What the developer may and may not do with the data | Counsel, agreed with the buyer |
| Release authorization | Who approved the final dataset and when | The supplier's authorized signer |
When a supplier becomes a developer or deployer#
A supplier becomes a developer or deployer when it builds or uses AI itself, and that activity is assessed separately from the license. A staffing firm that screens candidates with an AI tool may be a deployer for that screening, whatever it does with its training data.
The same applies to a software company that fine-tunes a model and offers it to customers, which may make it a developer for that product. Keeping the licensing workstream and the company's own AI use in separate documents helps counsel see each role clearly.
Illustrative: a recruiting firm reviews a buyer's warranties#
Illustrative: a fictional recruiting firm is asked to license job requisitions and recruiter workflow notes from its Bullhorn ATS to a developer building hiring tools. Hiring was treated as a consequential decision under Colorado's law as originally enacted, so the developer's draft asks the firm to warrant that the data is free of bias and will not lead to discriminatory outcomes.
Counsel concludes the firm is a data supplier, not a developer or deployer, for this transaction, and that it cannot warrant model outcomes. The firm excludes candidate resumes and any field that records or implies protected characteristics, documents that exclusion, and agrees to representations limited to its collection and preparation. The developer accepts the narrower terms because the documentation supports its own impact assessments.
How SourceX handles AI law questions#
SourceX keeps AI law questions inside the Rights and Approval steps of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The supplier's counsel reviews representations before anything is signed, and the laws that may apply are assessed deal by deal.
The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, which is the documentation developers most often need from a supplier to meet their own duties.
Frequently asked questions
Does the EU AI Act apply to a US company that supplies training data?
The EU AI Act places its main duties on providers and deployers of AI systems and on providers of general-purpose AI models, including a public summary of training content. A US supplier is usually affected through buyer requests for information that supports that summary, rather than through direct obligations. Counsel should confirm this for any specific deal.
Are privacy laws more important than AI laws for a supplier?
For most suppliers, yes. State privacy laws, customer contracts and employee notices govern whether records can be licensed and how they must be prepared. AI laws mostly shape what the buyer asks the supplier to document. Both are reviewed, but privacy and contract questions usually decide the scope.
Can a supplier be held responsible for what a model does?
Suppliers reduce that risk by limiting representations to facts they control, such as how records were collected and prepared, and by avoiding promises about model behavior or outputs. Indemnities should be tied to breaches of those representations. Whether liability could arise in a particular case depends on the facts and the contract.
Should a supplier ask what the developer is building?
Yes. Knowing whether the product will support consequential decisions, such as hiring or lending, tells the supplier which representations the developer is likely to request and which fields should be excluded. The answer also belongs in the permitted use clause, so the records cannot later be moved into a higher-risk product without a new review.
What if a law requires developers to publish training data summaries?
Where a law requires developers to publish training data documentation, as California AB 2013 does, a supplier's records may be described in general terms, for example as licensed data that has or has not been checked for personal information. Suppliers who want confidentiality should agree in the license how they may be described, for example by record type and industry rather than by company name.
Sources
- The Colorado AI Act (SB 24-205), signed May 17, 2024, was delayed by SB 25B-004 to June 30, 2026, and on May 14, 2026 SB 26-189 repealed and reenacted it in a narrower form effective January 1, 2027. Source
- The Texas Responsible Artificial Intelligence Governance Act (HB 149), signed June 22, 2025, took effect January 1, 2026. Source
- California AB 2013 requires developers of generative AI systems released on or after January 1, 2022 to post training-data documentation by January 1, 2026, stating whether datasets were purchased or licensed and whether they include personal information. Source
- The Use group of the Data & Trust Alliance Data Provenance Standards includes confidentiality classification, consent documentation location, privacy-enhancing technologies applied, allowed and excluded processing and storage geographies, license to use, intended data use, and copyright, patent and trademark status. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.