SB 942 is usually summarised as a watermarking law. Half of it is. The other half tells you to build and operate a public service that answers the question “did your system make this?” about a file a stranger uploads — free, at whatever volume arrives, with an API. That is a product, not a metadata field, and it is the part that takes engineering time.
SB 942, the California AI Transparency Act, was enacted in 2024 and added a new chapter to the California Business and Professions Code. It does not apply to everyone shipping a model. It reaches a covered provider: broadly, a person who creates, codes or otherwise produces a generative AI system that is publicly accessible in California and has above a stated monthly user threshold — one million, on the enacted text. Below that line the chapter does not bite at all, which is why the practical population of covered providers is small and consists almost entirely of companies you can name.
The threshold is doing real work and it is worth reading the operative definition rather than a summary of it, because “monthly visitors or users” is not the same measure as monthly active accounts, and a system embedded in somebody else’s consumer product can cross it without the provider tracking that number in the form the statute uses.
This page describes what the statute requires. It is not legal advice, and whether your system is a covered generative AI system under the chapter is a question about your product and your user numbers that you should put to counsel on your own facts.
The detection duty is stated separately from the disclosure duty, and it has its own list of acceptance criteria. Read as a specification, the tool must:
That last criterion is the one people skip and it changes the interface design. A detector that returns a boolean is out of specification; the statute contemplates a confidence-bearing answer, which means you have to decide what a low-confidence answer looks like and what a user is told when the file has been re-encoded past recognition.
The chapter also tells the tool what not to emit. It must not output personal provenance data — the information that would identify the individual user who generated the content, as opposed to the system that generated it. This is the provision that stops the detection tool becoming a deanonymisation service, and it constrains the latent disclosure too: whatever you embed has to be sufficient to identify the system and the moment, and insufficient to identify the person.
If you have ever designed a watermark that encodes a per-request identifier for abuse investigation, this is a direct conflict with the public tool, and the resolution is architectural. The identifier can exist in your own logs keyed to an opaque token in the disclosure; the public tool resolves the token to system-level facts only. Building one payload and one lookup path for both audiences is how a provider ends up shipping something out of compliance. The disclosure duty is bounded work: you emit a manifest and you embed a latent signal, both qualified in the statute by technical feasibility. The detection duty is unbounded, because the input is whatever the public uploads. A screenshot of a generated image, a video re-encoded twice by two social platforms, an image cropped to a face, a PNG converted to JPEG at quality 60 — every one of these destroys embedded metadata, and most of them degrade a robust watermark.
So the tool’s real behaviour is a two-tier answer. Where the manifest survives, you can state provenance with high confidence and echo the system provenance fields. Where it does not, you are relying entirely on the latent signal, and the honest output is a probability with a stated basis. There is a third case worth designing for explicitly: content your system did generate, from which every signal has been stripped. The tool cannot distinguish that from content your system never touched, and saying so plainly in the interface is better than a negative that reads as a denial.
The related duty on licensees is the other operational surprise. Where a third party licenses the system and modifies it so that it no longer includes the required disclosures, the chapter requires the licence to be revoked within a short window — 96 hours on the enacted text — and requires the provider to stop supplying the licensee until capability is restored. That is a contractual and monitoring obligation that has to exist in your licence agreements before it is needed, not after. See the general shape of AI contract clauses for where it sits.
SB 942 as enacted carried a 1 January 2026 operative date. It was amended in the 2025 session by AB 853, which moved compliance dates and extended related duties beyond the original covered-provider class to other actors in the distribution chain, including large online platforms and capture devices, on later dates of their own. Because the amendment changed the dates rather than the architecture, a summary written against the 2024 text is wrong about timing and right about substance.
Dates in this area moved once and can move again. Read the current text of the chapter in the Business and Professions Code before relying on any date — the enacted bill text shows what was passed, not what is currently in force. Primary sources: the California Legislature’s text of SB 942 (2024) and of AB 853 (2025), and the codified chapter at leginfo’s Business and Professions Code index.
Enforcement is public rather than private. The chapter provides for civil penalties per violation per day, recoverable by the Attorney General, a city attorney or a county counsel; there is no private right of action on the enacted text. The per-day framing matters more than the per-violation amount: a detection tool that is down, or that was never built, is a continuing state rather than a discrete event, and that is the exposure shape to model. For how this sits against the EU approach, see the AI Act’s machine-readable marking duty, which is drafted as an outcome rather than as a named tool.