New York AI Training Data Transparency Bill

Overview

The Artificial Intelligence Training Data Transparency Act is a New York state legislative measure addressing public information about the datasets used to develop generative artificial intelligence. It is a state bill, not a federal act applying throughout the United States. The official Assembly legislative record identifies A6578B as the active amendment for the 2025-2026 session and records passage through both legislative chambers. The Senate passed the measure and returned it to the Assembly on June 4, 2026. Its status is Adopted, denoting legislative passage.

The bill's central mechanism is developer publication of training-data documentation on a website, including a high-level summary of datasets used to develop a generative AI model or service. Its principal subjects are transparency and disclosure, accountability through documentation, and privacy-related information about training inputs. The original A6578 proposal provides the historical disclosure architecture described below; references to original provisions identify that version specifically. The short title, Artificial Intelligence Training Data Transparency Act, appears expressly in the original proposal.

Definitions and Development Activities

The original proposal defines artificial intelligence as a machine-based system that makes predictions, recommendations, or decisions for human-defined objectives. Such a system uses inputs, automated analysis, and model inference to formulate options. An AI model is an information system or component using computational, statistical, or machine-learning techniques to produce outputs. These definitions connect the proposal to the operation and development of AI systems rather than merely to the commercial labels attached to a product.

A developer, under the original definition, includes a person, partnership, state or local government agency, or corporation that designs, codes, produces, or substantially modifies an AI model or service for public use. Generative artificial intelligence consists of self-supervised models that emulate the structures and characteristics of input data to generate derived synthetic content. Examples include images, video, audio, text, and other digital content. The original definition therefore covers several output media and includes public-sector developers as well as private organizations.

The original proposal expressly includes testing, validation, and fine-tuning within training. A substantial modification includes a new version, release, or update that materially changes functionality or performance, including changes resulting from retraining or fine-tuning. Synthetic data generation means creating artificial data from seed data while retaining some statistical characteristics of the seed data. These definitions make development history, validation datasets, and subsequent model updates relevant to the original disclosure design, rather than limiting attention to a model's first training run.

Legislative and Institutional Framework

The measure proceeds as an amendment to New York's General Business Law. The Assembly record names Bores as sponsor, while the official Senate companion record identifies Andrew Gounardes as sponsor of S6955. The Assembly proposal was introduced on March 6, 2025, and referred to Science and Technology. The Senate companion was introduced on March 27, 2025, and referred to Internet and Technology. The Assembly bill was substituted for S6955A during the Senate proceedings on June 4, 2026.

The active bill metadata identifies proposed General Business Law article 44-C, sections 1430-1432. The original A6578 text proposes article 44-B, sections 1420-1423. These identifiers belong to different versions of the legislative proposal. The original disclosure model assigns website publication to developers themselves, giving members of the public direct access to information maintained by the organization responsible for the model or service.

The Senate sponsor memorandum identifies consumers, regulators, and other stakeholders as intended users of training-data information. It explains the policy value of greater visibility into AI development and the data underlying model behavior. Developer-managed publication is the central organizational feature of the original proposal. Legal, engineering, privacy, procurement, and data-management teams can support that publication through coordinated records, although this allocation of internal responsibilities is an implementation approach rather than a prescribed organizational structure.

Dataset Provenance and Disclosure Content

The original public disclosure provision calls for information about the sources or owners of datasets and an explanation of how those datasets further the intended purpose of the model or service. This links provenance to development objectives: a summary should identify where training inputs originated and explain their role in the resulting system. The original proposal also calls for the number of data points, permitting general ranges and estimates for dynamic datasets. That approach accommodates datasets whose contents or scale change during continuing development.

Descriptions of data-point types are another element of the original disclosure architecture. For labeled datasets, the relevant types are the labels used in the data. For unlabeled datasets, descriptions concern the general characteristics of the data points. Dataset size, labels, and general characteristics together provide a high-level account of the information used in development. The original provision calls for documentation and summaries rather than public distribution of complete training datasets.

Intellectual-property categories include whether datasets contain material protected by copyright, trademark, or patent; whether they consist entirely of public-domain material; and whether the developer purchased or licensed them. These categories distinguish the presence of protected material, public-domain status, and acquisition arrangements. They are informational features of the original proposal. A statement about protected content or a license records an aspect of the dataset and its acquisition; it does not itself resolve a particular infringement dispute or determine the validity or scope of an intellectual-property right.

Privacy, Processing, and Synthetic Data

The original proposal calls for disclosure of whether datasets contain personal information or personal identifying information. Its personal-information category refers to definitions in section 899-aaa of New York's General Business Law. It also addresses aggregate consumer information, drawing a distinction between genuinely group-level information and records that remain individual in character. Privacy-related disclosures form part of a public description of the training inputs rather than an instruction to publish the underlying personal records.

Under the original definition, aggregate consumer information concerns groups whose individual identities have been removed and whose information is not linked or reasonably linkable to a consumer or household, including through a device. The definition expressly excludes merely de-identified individual consumer records. This distinction matters when classifying a dataset: removing direct identifiers from individual records is different from creating information about a group that is not reasonably linkable to particular consumers or households.

The original disclosure categories also cover cleaning, processing, or other modifications performed by the developer, including their intended purpose. They address the period during which data was collected, whether collection continues, and the dates on which datasets were first used in development. Synthetic data generation is a separate disclosure subject. Taken together, these categories describe not only the source material but also its transformation, temporal scope, and use during development. Disclosure of personal-information presence is informational and is distinct from a determination that processing satisfies other applicable privacy duties.

Employee and Contractor Data

The original proposal contains a separate provision concerning data substantially derived from employees or contractors. It addresses disclosures to affected employees and includes the intended purpose of the relevant use and dataset characteristics among its subjects. This creates a distinct historical strand of the proposal: public training-data documentation is accompanied by an employee-facing disclosure concept tied to the origin of development data.

The distinction between general public summaries and employee-facing information is important for organizing records. Data lineage can connect a dataset to employee or contractor activity, while development documentation can identify the purpose for which the dataset is used. An internal inventory can therefore distinguish workforce-derived inputs from other sources and record the associated purpose and characteristics. This is an organizational approach based on the original proposal's categories, not an additional statutory requirement.

The original developer definition includes both public and private entities, making the identity of the developer separate from the workforce origin of a dataset. Employee- or contractor-derived material can also intersect with the proposal's broader categories concerning personal information, processing history, dataset ownership, and licensing. Maintaining those categories separately helps preserve the distinction between provenance, privacy classification, acquisition arrangements, and the purpose of development.

Coverage and Implementation Approach

The original proposal applies its public disclosure design to relevant generative AI models or services made publicly available to New Yorkers, regardless of whether compensation is charged. It connects publication to public availability and substantial modifications. Its release-coverage reference begins on January 1, 2022, and its original initial disclosure deadline is January 1, 2026. Those dates belong to the original proposal. The original text also contains an immediate-effect statement.

Two exceptions appear in the original proposal. One concerns a model or service whose sole purpose is aircraft operation in the national airspace. The other concerns a national-security, military, or defense model or service available only to a federal entity. These historical exceptions use the purpose of the model or service and the identity of its users as distinguishing conditions.

A practical preparation approach is to maintain an inventory of models, releases, training inputs, sources, owners, licenses, personal-information indicators, and processing history. A release-management workflow can connect documentation updates to material changes in functionality or performance, including retraining and fine-tuning. Dataset records can also capture approximate size, the basis for estimates, collection periods, first-use dates, and synthetic-data generation. These steps are operational preparation methods derived from the original disclosure categories, rather than additional publication formats or audit mandates.

Monitoring and Documentation Quality

The original disclosure categories offer a structure for checking the accuracy of a developer's published summary. An organization can compare its website statements with procurement records, dataset inventories, engineering documentation, and release histories. Such comparisons help keep descriptions of sources, licensing, processing, and development use consistent across teams. They are practical quality-control methods, separate from the original proposal's enumerated disclosure content.

Dynamic datasets require particular attention because the original proposal permits ranges and estimates for dataset size. Records of the estimation method and date can help explain how a high-level description relates to an evolving dataset. Continuing collection, ongoing synthetic-data generation, and material retraining likewise create reasons to review whether a published account still reflects the development process. Documentation can distinguish stable dataset characteristics from information that changes with a release or collection cycle.

The Senate sponsor memorandum explains that training-data documentation can help identify biases, inaccuracies, and ethical concerns affecting AI performance and fairness. This is a policy rationale for transparency. The original disclosure architecture concerns access to information about data and development; its documentation categories are distinct from a particular fairness score, safety certification, or performance benchmark. Version-aware legislative records also distinguish original article and section numbering from the identifiers attached to the active amendment.

Relationship to Other Legal Instruments

The proposal's location in the General Business Law connects it to New York's existing statutory framework for business practices. The original personal-information category expressly references section 899-aaa of that law. Its intellectual-property categories use existing concepts of copyright, trademark, patent protection, public-domain status, purchase, and licensing. These connections support the classification of training inputs without turning the disclosure categories into amendments to intellectual-property rights or substitutes for privacy obligations.

The Senate sponsor memorandum states that the measure is based on a California law and presents interstate standardization as a reason for adoption. The rationale is to provide New Yorkers with insight into AI data use while supporting a more consistent approach across states. This is an interstate policy connection, distinct from an international treaty or mutual-recognition arrangement. The original New York coverage connection is public availability to New Yorkers, and its aviation and federal-use exceptions address particular use contexts.

A separate federal proposal, H.R.8094, concerns Federal Trade Commission public-information requirements relating to AI training data. It is a different instrument from the New York bill. The state measure's identity, sponsors, legislative route, and proposed General Business Law amendments remain specific to New York. For organizations operating across jurisdictions, a shared dataset inventory can support separate legal assessments while preserving the distinction between each jurisdiction's instrument and requirements.

Implementation Timeline

Documentation Preparation Checklist

Sources and References