California's AI Transparency Act: what AI builders need to know now

California's AI Transparency Act (SB 942) is now enforceable, and it holds covered generative-AI providers to a clear set of obligations: embed provenance data, ship a free detection tool, and offer visible labels. Done right, compliance becomes a competitive feature — a public signal that your outputs are traceable and the receipts exist. Done wrong, it carries civil penalties that compound daily. If you built the generator, this post is for you.

Who the law covers

The statute defines a "covered provider" as a person that creates, codes, or otherwise produces a generative AI system with over 1,000,000 monthly visitors or users, publicly accessible within California's geographic boundaries. Note the trigger: it is the creator of the system, not the downstream integrator or API reseller, and the threshold is one million monthly California users. The full bill text is public on the California Legislative Information portal, and every claim about the statute in this post is grounded in that text — re-read the operative sections before you brief counsel, because this post is engineering context, not legal advice.

"Provenance data" in the statute means data embedded into digital content, or included in its metadata, for verifying authenticity, origin, or modification history. The law distinguishes system provenance data (device/service/authenticity info not linkable to a user) from personal provenance data (anything linkable to a person) — and the detection tool must output the former while withholding the latter.

What SB 942 actually requires

The law imposes three parallel obligations on covered providers.

Provenance data must be embedded. The statutory standard is data embedded in the content or its metadata for authenticity verification — which in practice means pixel-domain watermarks, signed cryptographic manifests in the container, or both, not a comment in a header that any editor strips. The accepted technical standard is C2PA, the Coalition for Content Provenance and Authenticity, which uses signed manifests to bind origin claims to files.

A free, public detection tool. The statute requires a no-cost tool that lets a user assess whether image, video, or audio content was created or altered by the provider's system — accepting uploads or URLs, outputting detected system provenance data, withholding personal provenance data, and publicly accessible subject only to reasonable security limitations. Think of it as a "view source" for AI provenance: neutral, stateless, and accessible.

A visible label option. The provider must let users opt in to a manifest-style disclosure on the output. The label is optional for the user, but the option must exist, and the user's choice must be honoured.

These pieces travel together. A standalone watermark without a detection tool does not satisfy the law. A detection tool without embedded provenance in the underlying files does not satisfy the law. Every covered provider needs all of them — confirm the exact operative language in the bill text rather than relying on summaries.

How to actually implement C2PA today

C2PA is a real, working spec. The technical specification is open, reference implementations are production-grade, and major generative vendors have shipped it at scale. The minimum viable integration for a covered provider has four steps.

1. Generate a signing identity. You need a certificate tied to your organization. Available C2PA implementations support this — generate a keypair, obtain a cert from a CA that supports C2PA signing, and store the private key somewhere it cannot be exfiltrated. For most teams, a managed KMS is the right answer.

2. Sign the manifest at generation time. When the model produces an output, wrap it with a manifest that records the AI assertion, the model version, the timestamp, and the signing identity. This is the hard-to-remove part — the manifest is cryptographically bound to the file, not bolted on. The C2PA specification site is the authoritative reference for manifest structure.

3. Validate on the way out. Before delivery, run the manifest through a C2PA validator to confirm it parses and the signature verifies. Ship only validated outputs. A broken manifest is worse than no manifest — it tells attackers exactly which validator to spoof.

4. Stand up the detection tool. A simple server that accepts a file or URL, extracts the provenance record, returns the manifest contents minus anything personal, and discards the upload. Stateless. No PII. Load-test it before launch — the statute makes it public, so it will be crawled.

// signed manifest, simplified shape
const manifest = {
  vendor: "your-org",
  claim_generator: "your-model-id@vN",
  assertions: [
    { label: "c2pa.actions", data: { actions: ["c2pa.created"] } },
    { label: "c2pa.ai_generated", data: { type: "image" } },
  ],
  signature: {
    algorithm: "ES256",
    cert_serial: process.env.C2PA_CERT_SERIAL,
    value: "<signed payload>",
  },
};

The tooling is no longer the bottleneck. The bottleneck is treating provenance as a launch blocker instead of a week-two task — which is where most teams fail. Our ship AI MVP to production checklist puts provenance alongside the other launch gates (access controls, data handling, rollback) so it ships in order instead of shipping late.

Where the market already stands

The compliance gap between generators is already visible and already a competitive signal. Several major vendors ship C2PA-backed provenance on flagship image and video models, combining signed manifests with invisible watermarking so that stripping one layer still leaves the other. Others ship little or nothing — no credentials, no watermark, no detection tool. Vendor postures change quickly, so verify each claim against the vendor's current docs before citing it in a procurement memo; what matters structurally is that the standard exists, the tooling exists, and buyers can now ask for the certificate instead of the promise.

That buyer dynamic is the real story. Enterprise procurement teams already know how to read a SOC 2 letter. SB 942 gives them a second document to ask for: the provenance attestation. Vendors who have it move through review in days. Vendors who do not get a new line item on the questionnaire. Our AI app security checklist covers the adjacent questions — secrets handling, sandboxing, human oversight — that belong in the same review.

What this means for builders shipping AI features

If you are under the threshold today, you will not necessarily stay there. A consumer app that finds product-market fit in California crosses one million monthly users faster than its roadmap assumes, and provenance retrofitted after launch is an order of magnitude more expensive than provenance built in. Sign manifests from day one; the marginal cost per generation is negligible and the option value is enormous.

If you build on top of other providers' models rather than training your own, the statute's creator-trigger likely puts the primary duty on the model vendor — but your customers will still ask you for the provenance story of your product. Preserve upstream manifests through your pipeline instead of stripping them in preprocessing, and surface them in your own outputs. Stripping a manifest your vendor embedded is the fastest way to inherit liability you never needed.

And if you ship across web and mobile, remember that provenance must survive every export path: resized thumbnails, share-sheet recompression, CDN transforms. A manifest that dies at the first image resize is compliance theater. Test the full pipeline the way our one codebase across three platforms notes recommend testing every asset path — on each platform, through each transform.

The Transparency Act does not ask builders to solve deepfakes. It asks them to sign their work, publish a way to check the signature, and let users label it. That is a weekend of engineering for a team that plans ahead — and a very expensive quarter for a team that does not.

Build the traceable thing from the start. OTF starter kits ship with structured, auditable output pipelines — typed config, CI, and one component API across web and native — so provenance is a property of the build, not a retrofit: https://otf-kit.dev/templates.

Sources

• California Legislative Information, Bill Text SB-942, Chapter 25 (definitions, covered-provider threshold, detection-tool duties) — https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202320240SB942
• C2PA (Coalition for Content Provenance and Authenticity, the provenance standard) — https://c2pa.org/