California SB 942 AI Compliance Checklist: Ten Items Split by Who Actually Owns Each One
A working checklist for the California AI Transparency Act (SB 942), operative 2 August 2026 after AB 853 delayed it. The list is split deliberately: the provenance and detection items a covered provider owns at the generation layer, and the evidence and verification items a deployer or licensee owns in the traffic. Each item names the action, who owns it, and the evidence to produce, so nobody assumes the vendor covered their side.
The California AI Transparency Act (SB 942) becomes operative on 2 August 2026, after AB 853 moved it from January and extended the regime to large online platforms and capture-device manufacturers in later years. SB 942 binds covered providers: operators of generative image, video, or audio systems with more than one million monthly users in California. A useful checklist separates what a covered provider builds at the generation layer from what a deployer or licensee has to evidence in the traffic, because the two get conflated and one side ends up uncovered.
Each item names the owner and the evidence. The first three belong to the covered provider. The remaining seven are the deployer and licensee duties that most enterprises actually carry.
1. Embed latent disclosures (covered provider)
The covered provider embeds provenance data in generated content: provider name, system name and version, and creation time, readable by the detection tool. Owner: covered provider, at the generation layer. Evidence: the provenance specification and test results. A deployer cannot perform this item and should not assume it is theirs.
2. Operate a public detection tool (covered provider)
The covered provider offers a free, publicly accessible tool that checks whether content came from its system. This is a covered-provider duty, evidenced by the live tool and its coverage. It runs as a provider-operated service outside any deployer's control.
3. Offer the manifest disclosure option (covered provider)
The covered provider makes a user-facing option available to label content as AI-generated. Owner: covered provider, at the generation or UX layer. Evidence: the option's availability in the product.
4. Record covered-system use per request (deployer)
Log which identity requested generation from a covered system, which endpoint answered, and when. Owner: deployer, at the traffic layer. Evidence: a per-request record, the foundation for every deployer-side claim.
5. Verify latent disclosures on the response path (deployer)
Check each covered-system response for the expected provenance markers before it reaches a downstream user, and flag or hold responses that lack them. This is a deployer duty, evidenced by the verification log, built with response schema validation pointed at the provenance property.
6. Maintain the licensee capability (licensee)
If you license a covered system, keep its latent-disclosure capability intact, since the provider must revoke your license within 96 hours of discovering you broke it. This is a licensee duty, evidenced by a continuous per-response record showing the capability held.
7. Bind identity to generative requests (deployer)
Route generative traffic so a named user or agent, not a shared key, attaches to each request. This is a deployer duty, evidenced by the identity-bound request record that makes item 4 meaningful.
8. Keep the evidence independent of the application (deployer)
Ensure the compliance record is written by a system separate from the one making the generative call, so it survives selective logging and crash-loss. This is a deployer duty, evidenced by a signed, tamper-evident log outside application custody, as argued in You Own the AI Liability, Not the Vendor.
9. Do not treat the vendor attestation as your evidence (deployer)
A covered provider's promise that its system embeds disclosures is due diligence, and it does not show a specific served response carried the marker. This is a deployer duty, evidenced by your own per-response verification from item 5, not the provider's SOC 2 report. My honest take: this is the item that decides how a deployer's enforcement inquiry goes.
10. Work to the 2 August 2026 date, not January
Plan the deployer-side controls to the operative date AB 853 set, and track the 2027 and 2028 phase-ins for platforms and device makers if they apply to you. This is a deployer duty, evidenced by a dated readiness plan tied to the SB 942 controls mapping.
How the checklist maps to the controls
Items 4 through 9 resolve to a small set of enforcement points at the request boundary, laid out in the SB 942 controls mapping. The audit-evidence view covers what each deployer artifact looks like. Items 1 through 3 stay with the covered provider, and the whole point of the split is that neither side assumes the other covered it.
DeepInspect
DeepInspect owns the deployer half of this list and none of the provider half. It sits inline between your users or agents and the generative APIs they call, binds identity to each request, records which covered system answered and when, and verifies on the response path that expected latent-disclosure markers arrived. It does not embed watermarks or run a detection tool.
For an enterprise deploying or licensing a covered generative system before 2 August 2026, that means items 4 through 9 become a running control with evidence attached, while items 1 through 3 stay clearly the provider's. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Which SB 942 items does my enterprise own if it is not a covered provider?
Items 4 through 9: recording covered-system use, verifying latent disclosures on responses, maintaining licensee capability, binding identity, keeping evidence independent, and not leaning on the vendor attestation. Items 1 through 3, the provenance embedding, the detection tool, and the manifest option, belong to the covered provider. The split matters because a deployer that assumes the provider covered everything has no evidence of its own side.
- Does SB 942 require action before 2 August 2026?
Yes. The deployer-side controls in items 4 through 9 should be in place by the 2 August 2026 operative date, since that is when the covered-provider obligations, and the licensee duties tied to them, apply. AB 853 also phases in obligations for large online platforms in 2027 and capture-device manufacturers in 2028, so track those if they apply.
- What happens if a licensee breaks the latent-disclosure capability?
Under SB 942, if a licensee modifies a covered system so it no longer includes latent disclosures, the covered provider must revoke the license within 96 hours of discovering the breach. A licensee avoids that outcome by continuously verifying the capability held, which is a per-response record rather than a one-time integration test.