California SB 942 AI Audit Evidence: What a Deployer of Covered Generative Systems Has to Show
The California AI Transparency Act (SB 942) takes effect 2 August 2026 after AB 853 delayed it from January, and it puts content-provenance obligations on covered providers of generative image, video, and audio systems with more than one million monthly users. Watermark generation sits at the model layer, outside an HTTP proxy. The evidence an enterprise deploying or licensing those systems has to produce sits in the traffic. This walks the audit artifacts that are actually visible at the request boundary and names what is not.

The California AI Transparency Act (SB 942) becomes operative on 2 August 2026. AB 853, signed in October 2025, moved the date from 1 January 2026 and layered obligations onto large online platforms from 2027 and capture-device manufacturers from 2028, according to the AB 853 bill text and Cooley's state AI law tracker. SB 942 applies to covered providers: operators of generative AI systems producing image, video, or audio content with more than one million monthly users in California.
Before walking the evidence, one boundary has to be honest. The core SB 942 obligations, a public AI-detection tool and latent provenance embedded in generated content, live at the model and generation layer. An HTTP proxy does not create a watermark. What a proxy can produce is the record an enterprise deploying or licensing a covered system needs to show which traffic used that system and whether the required disclosures survived. I want to walk that record, because deployers keep assuming the covered provider's obligations are also their evidence.
The manifest and latent disclosure split
SB 942 defines two disclosure types. A manifest disclosure is user-facing and optional to apply per piece of content. A latent disclosure is embedded provenance data carried inside the content, conveying the provider name, the system name and version, and the time the content was produced, detectable by the provider's tool. The generation of both sits with the covered provider. For a deployer, the audit question is narrower: for content your systems generated or passed through, can you show the latent disclosure was present and not stripped downstream.
The traffic record a deployer can produce
An enterprise that routes user or agent requests to a covered generative endpoint sees every request and response at the HTTP boundary. That is where a defensible record forms: which identity requested generation, which covered system answered, the timestamp, and whether the response carried the expected latent-disclosure markers. This record does not replace the provider's watermark. It proves your side of the chain, which is the part an enforcement action against a deployer would examine. The same primitive underpins SOC 2 AI controls mapping and ISO 42001 audit evidence.
The licensee obligation and the 96-hour clock
SB 942 addresses licensing directly. When a covered provider licenses its generative system to a third party, the licensee must maintain the system's capacity to include latent disclosures, and if a licensee modifies the system so it no longer meets the requirement, the covered provider must revoke the license within 96 hours of discovery. A licensee's evidence is a record showing the latent-disclosure capability stayed intact across its deployment. A per-request log of covered-system responses and their provenance markers is that evidence, produced continuously rather than reconstructed after a complaint.
Response-side verification as an enforced control
The one enforcement action a proxy can take is on the response path. When a covered system returns content, a decision point can check for the expected latent-disclosure markers before the content reaches a downstream user, and flag or hold responses that lack them. This is response schema validation applied to a compliance property rather than a data-shape property. It does not create the disclosure; it verifies the disclosure the covered provider was supposed to embed actually arrived, which is the deployer's exposure.
Why the provider's word is not your evidence
A covered provider will attest that its system embeds latent disclosures. That attestation is procurement-time due diligence, and it does not show that a specific piece of content your deployment served carried the marker on a specific date. The distinction between due diligence and due care runs through every regulated regime, and I argued it for AI specifically in You Own the AI Liability, Not the Vendor. My blunt view: the deployers most exposed under SB 942 are the ones treating a vendor SOC 2 report as if it were a per-request provenance log, which it is not.
DeepInspect
DeepInspect sits inline between your users or agents and the generative APIs they call. It does not embed watermarks or generate latent disclosures; that stays with the covered provider. What it does is produce the deployer-side record SB 942 exposure turns on: which identity requested generation, which covered system responded, when, and whether the response carried the expected provenance markers. On the response path it can flag or hold content that arrives without them.
For an enterprise deploying or licensing a covered generative system before 2 August 2026, that record is the difference between proving your side of the disclosure chain and taking the provider's word for it. The SB 942 controls mapping shows how each obligation lines up with what a proxy can and cannot enforce. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does SB 942 apply to my company if I only use a generative AI vendor?
SB 942's covered-provider obligations fall on the operator of the generative system with more than one million monthly users. If you license or embed such a system, the licensee provisions apply to you: you must maintain the latent-disclosure capability, and the provider must revoke your license within 96 hours if you break it. Your evidence is a record showing the capability stayed intact, which is a deployer-side audit artifact.
- What is the difference between manifest and latent disclosure in evidence terms?
A manifest disclosure is a visible label a user can apply to a piece of content, so evidence is whether the option was offered and used. A latent disclosure is provenance metadata embedded in the content itself, so evidence is whether that metadata was present in the content your deployment served. The latent disclosure is the one that persists and the one a detection tool reads, which makes it the higher-stakes artifact for a deployer.
- Can an HTTP proxy make my generative content SB 942 compliant?
No. Compliant content requires the covered provider to embed latent disclosures and offer a detection tool, which happens at the generation layer. A proxy verifies that those disclosures arrived in the responses your deployment served and produces the per-request record of covered-system use. Treat the proxy as the evidence-and-verification layer, not as the watermarking layer.
- When exactly does SB 942 take effect?
The core covered-provider obligations take effect 2 August 2026, after AB 853 moved the date from 1 January 2026. AB 853 also phases in obligations for large online platforms from 1 January 2027 and capture-device manufacturers from 1 January 2028. A deployer preparing evidence should work to the August 2026 date for the generative-system provisions.