New York's SHIELD Act and AI Vendor Security Requirements

The Stop Hacks and Improve Electronic Data Security Act is not an AI statute and never mentions a model. It is nonetheless one of the instruments most likely to be applied to an AI product built in or sold into the United States, because it imposes a substantive security- programme duty on anyone holding a New York resident’s private information, and it says something specific about the vendors you hand that information to.

Who the Act reaches

The SHIELD Act, enacted in 2019, amended New York General Business Law by rewriting section 899-aa (breach notification) and adding section 899-bb (data security). The reach of section 899-bb is defined by whose data you hold, not by where you are: any person or business that owns or licenses computerised data including the private information of a New York resident is covered. The New York State Senate publishes the text of GBL § 899-bb. There is no requirement to conduct business in New York, no revenue threshold for coverage, and no carve-out for a business that never intended to have New York users.

There is a scaled obligation for small businesses — section 899-bb defines one by employee count, gross annual revenue and year-end assets, and permits its safeguards to be appropriate to its size and the sensitivity of the data. That is a proportionality rule, not an exemption. A ten-person company processing health-adjacent free text through a model API is a small business with sensitive data, and the scaling cuts the other way.

What counts as private information

Section 899-bb borrows the definition from section 899-aa, and the borrowed definition is narrower than people assume and broader than the pre-2019 one. It is not “any personal data”. It is, broadly, personal information combined with one of an enumerated set of data elements — social security number, driver’s licence or non-driver ID number, account or card number with any required security code, biometric information — plus, separately, a username or email address in combination with a password or security question answer that would permit access to an online account.

Two consequences follow for an AI product. First, a chat transcript that is merely personal is often outside the definition, and a questionnaire that answers “we hold private information” reflexively is over-inclusive. Second, a chat transcript is unstructured, and users paste account numbers and identity documents into it. The realistic position for most conversational products is that they hold private information intermittently and without knowing which sessions those are, which is an argument for treating the whole store as in scope rather than for a per-record classification you cannot actually perform. A 2024 amendment to the New York breach statute also expanded the covered elements to include certain medical and health-insurance information, which pulls a further class of product into scope; check the current text of section 899-aa rather than a 2019 summary of it.

The service-provider clause

Section 899-bb requires a reasonable security programme, and then — unusually for a statute of this vintage — enumerates examples of what administrative, technical and physical safeguards look like. One of the administrative examples is that the business selects service providers capable of maintaining appropriate safeguards and requires those safeguards by contract.

That is two obligations in one clause and they fail differently. “Selects service providers capable of” is a diligence duty performed before you sign: you have to have formed a view, on some basis, that the vendor can protect the data. “Requires those safeguards by contract” is a drafting duty: the protections have to be in the agreement, not in a marketing page or a trust-centre screenshot. A vendor file containing a SOC 2 report and no contractual security schedule satisfies the first and fails the second, and that is the most common shape of the failure.

Applying it to a model API

Now put a third-party model provider in the service-provider slot. The data leaves your perimeter, is processed on hardware you do not control, and may be retained for a period set by the provider’s policy rather than by your contract. A defensible file for that arrangement has to answer questions the standard vendor questionnaire does not ask:

• Retention of prompts and completions. Providers differ, and the default for a self-serve account is frequently not the default for an enterprise agreement. The relevant fact is what your contract says, not what the public documentation says.
• Training use. Whether inputs may be used to improve the provider’s models is a security-programme question as well as a privacy one, because it determines whether the data persists somewhere you cannot enumerate or delete.
• The sub-processor chain. A model vendor is often itself calling another provider’s API, or hosting on a third party’s infrastructure. The contractual safeguards clause has to flow down, and this is the link most often missing. See subprocessing clauses in AI data processing agreements.
• Human review. Trust-and-safety review pipelines mean humans may read content flagged by a classifier. That is a legitimate practice, and it is also a disclosure you need to have made and a control you need to have assessed.
• Deletion on termination. The disposal element of section 899-bb’s physical safeguards has an analogue in the vendor contract: what happens to logs and cached content when you leave.

Note what the statute does not do. It does not require a particular control, does not name an encryption standard, and does not certify anyone. It requires a programme that is reasonable for your data and your size, and it requires you to be able to show it. In an investigation the artefact that matters is the risk assessment that identified the model API as a risk and the contract that addresses it.

The breach-notification half

Section 899-aa is the other half and it interacts with AI architecture badly. A breach is defined around unauthorised access to or acquisition of computerised data compromising security, confidentiality or integrity; the 2019 amendments broadened “breach” from acquisition to access. For a system where prompts pass through several hops, the hard operational question is not the legal test but whether you can determine, after an incident at a vendor, which of your users appeared in the affected window. If your logging does not let you answer that, the notification analysis defaults to over-notifying.

There is also a genuine open question, and it should not be papered over: it is not settled how a regulator would treat model memorisation — private information that finds its way into a fine-tuned model and is later emitted — against a definition written around access to stored data. No New York decision has addressed it. Anyone telling you the answer is confident is guessing. See breach notification for an AI leak for how the equivalent question is framed under a different regime.

Enforcement and what a failure costs

Section 899-bb is enforced by the Attorney General, and the section states that there is no private right of action for the data-security duty. The Attorney General may seek injunctive relief and civil penalties; the penalty scale for the notification failures in section 899-aa is set per instance with a statutory cap, and it is worth reading the current text rather than a figure quoted from a 2019 article, because these numbers have been amended.

In practice the New York Attorney General has pursued security-programme failures through assurances of discontinuance that impose a programme rather than only a fine, which means the operative output of an enforcement action is a set of controls you then have to run for years. That is a strong argument for building the vendor file before rather than after, and it maps closely onto what a right-to-audit clause is for.