California · AI Transparency Act

California SB 942: the four duties, and the evidence each one leaves behind

SB 942 is operative 2 August 2026. It tells covered providers what to embed, what to offer, what to run, and how fast to revoke. It does not tell them how to prove any of it afterwards. That gap is what this page is about.

Operative
2 August 2026 Bus. & Prof. Code §§ 22757–22757.6.
Penalty
$5,000Per violation. Each day of a continuing violation is a separate violation.
Threshold
1,000,000Monthly visitors or users. Measured at the provider, not the deployer.
Enforced by
AGAttorney General, city attorneys, county counsel. A prevailing plaintiff recovers fees.

01The clock

SB 942 passed in 2024 with a 1 January 2026 start. AB 853 moved it, and the new date was not arbitrary: California landed on the same day the EU AI Act's transparency article begins to apply. A provider serving both markets gets one deadline, not two.

  1. The California AI Transparency Act is signed

    Adds a new chapter to division 8 of the Business and Professions Code, with an original operative date of 1 January 2026.

  2. Amended, delayed, and widened

    AB 853 pushes the operative date to 2 August 2026 and extends the regime beyond the original covered providers to further classes of duty holder on later dates.

  3. The four duties attach

    Latent disclosure, the manifest disclosure option, the public detection tool, and the 96-hour revocation duty are all live. Penalties accrue per day.

  4. EU AI Act Article 50 begins to apply

    The marking and disclosure obligations of Regulation (EU) 2024/1689 start on the same date. The EU duties are different in shape — one evidence trail can answer both, but only if it was designed to.

02Are you covered?

This is the first question every reader has, and most summaries bury it. The test is narrow, and it lands on the builder of the system rather than the business that merely uses one.

  1. Do you create, code, or otherwise produce a generative AI system — as opposed to buying access to somebody else's?
  2. Is that system publicly accessible in California?
  3. Does it have more than one million monthly visitors or users?

Three yeses makes you a covered provider, and all four duties attach on 2 August 2026. A company that only calls a third-party model through an API is generally not the covered provider for that model — but read duty four, because licensing somebody else's covered system carries its own obligation, and it runs on a 96-hour clock.

Two things about that third question are widely misread, and both come from the drafting history rather than from any commentary.

There is no measurement window. As introduced, SB 942 counted users "on average over the preceding 12 months." An Assembly committee amendment in June 2024 struck the averaging clause, and no committee discussed the deletion. What survives is a bare threshold with no lookback at all — so a system that crosses one million in a single month has, on the face of the text, crossed it. AB 853 later wrote further thresholds with windows and did not restore one here.

The count is not California-only. The enacted text counts visitors and users; it does not limit them to the state. An Assembly analysis of AB 853 glosses the law as reaching developers with a million monthly California users, but a committee gloss that contradicts the enacted text is weak authority — and that phrasing appears to have been carried over from a different bill that never passed. Plan against the worldwide count.

03The four duties

Each duty below is stated as the statute frames it, then as an engineer has to build it, then as an enforcement inquiry will test it. The third framing is the one nobody writes down, and it is the only one that decides whether you can answer.

1 · Latent disclosure

Embedded provenance, carried in the content itself

Covered content must carry a disclosure embedded in the content itself, conveying — where technically feasible and reasonable — the provider's name, the name and version of the system that produced it, the time and date it was created or altered, and a unique identifier. It must be detectable by the provider's own detection tool, consistent with relevant industry standards, and permanent or extremely difficult to remove.

Cal. Bus. & Prof. Code § 22757.3 · latent disclosure

In practice this is a watermark or a signed metadata assertion — C2PA Content Credentials is the standard most providers are reaching for. The statute does not name a technology. It names four data elements, a detectability requirement, and a durability requirement.

Two drafting points that matter more than they look. "Technically feasible" is part of the duty, not a defence to it — the phrase was contributed by an industry association during the 2024 amendments and it bounds what the duty demands, which means the burden of getting around it sits with the enforcer rather than with you. And whether text is covered was never settled: a committee noted that embedding disclosures in text was not feasible at scale, warned that the phrase "other digital content" could be read to include it, and invited the authors to clarify. They did not.

What an inquiry asks

Not "do you embed disclosures?" — everyone says yes. It asks: for this specific artefact, on this specific date, what did you embed, and what were the four values?

Why your logs do not answer it

Application logs are mutable, rotate on a retention schedule, and are written by the same system whose behaviour is in question. They are an assertion by the accused, produced after the fact, with no way for a third party to detect edits.

2 · The manifest disclosure option

A visible disclosure the user can choose

A covered provider must offer the user the option of a manifest disclosure — one a person can actually see — applied in a clear and conspicuous manner, appropriate to the medium, and permanent or extremely difficult to remove.

Cal. Bus. & Prof. Code § 22757.3 · manifest disclosure

Note the verb. The duty is to offer, not to apply. The user decides. That makes the compliance artefact a record of the offer being available on a channel at a time — not a record of a visible mark existing on any particular file.

What an inquiry asks

Was the option actually presented on this surface during the period under review, or did it silently regress in a release three months ago?

Why your logs do not answer it

A deployment record shows what shipped. It does not show what a user was offered, per channel, per day — which is the shape of the duty.

3 · The public detection tool

Free, public, and answering

A covered provider must make available a free, publicly accessible AI detection tool that accepts content from a user and assesses whether it was created by the provider's system. It must accept upload or a URL, expose an API, output any available system provenance data — and it must not output personal provenance data about the person who created the content.

Cal. Bus. & Prof. Code § 22757.2 · AI detection tool

This one is unusual: it is a duty to operate a service, continuously. Uptime is the compliance posture. A tool that was down for six days in March is six separate days of violation, and the penalty is calculated per day.

One relief worth knowing, because it is often read too broadly: the tool only has to identify your own system's output. The legislative record is explicit on this — you are not being asked to build a general-purpose detector for everyone's AI.

What an inquiry asks

On which days was the tool reachable and answering? Prove it for the whole period, not for the day you were asked.

Why your logs do not answer it

Your uptime monitor is a vendor dashboard you can edit, with a retention window measured in weeks. It was built to page an engineer, not to survive an adversarial reading.

4 · Revoke a licensee within 96 hours

The only duty in the Act with a clock on it

Where a covered provider licenses its system to a third party, and later discovers that the licensee has modified the system so that it no longer applies the required disclosures, the provider must revoke the licence within 96 hours of discovery. The licensee must then stop using the system.

Cal. Bus. & Prof. Code § 22757.4 · licensee revocation

Correct one widespread error first: the trigger is actual knowledge. Several secondary summaries add "or reasonably should know" — the statute does not. There is no constructive-knowledge trigger.

Ninety-six hours from discovery. That makes the moment of discovery a legally load-bearing fact — and it is a fact about your own knowledge, which is exactly the kind of thing that is impossible to establish later from ordinary systems. If discovery is not timestamped when it happens, the clock has no provable start.

What an inquiry asks

When did you find out, and when did you revoke? The gap between those two timestamps is the entire question, and both must be independently credible.

Why your logs do not answer it

A ticket in an issue tracker has an editable creation date and an editable history. It proves a ticket exists, not when you knew.

04Proving the negative

Here is the problem nobody's compliance page addresses. Suppose you produce four million images a month and you seal a record for every disclosure you embed. An investigator asks the question that actually matters: how do I know you didn't skip some?

A pile of receipts proves the acts you chose to record. It says nothing about the ones you didn't. Evidence that only ever confirms is not evidence — it is a testimonial with extra steps.

The fix is arithmetic. Before any duty records are written, a covered provider declares the system once: what it is in scope to produce, which marking techniques are in use, and — critically — where in its own code a per-system counter increments. From then on, each record carries that counter's value. Gaps in the sequence are visible to anyone reading the series. Omission stops being invisible and becomes a number.

This does not make the counter honest. Nothing can. What it does is make the audit question answerable in one sentence instead of an engagement: the sequence runs 1 to 4,102,887 with no gaps, and the declaration that bound the counter was sealed before the first record. Narrowing scope later is possible, but it is an affirmative, dated act that supersedes the prior declaration and leaves the old one standing in the record — not a quiet retroactive edit.

05The answer the legislature wrote down

There is a paragraph in this bill's committee history that nobody cites, and it describes the compliance architecture the statute was expected to produce.

Considering how a provider could answer the detection-tool duty at scale, the committee observed that by keeping a record of all content their systems produce — perhaps in a privacy-protective form, like a cryptographic hash — providers can quickly and easily determine whether user-uploaded content was generated by their systems.

Assembly Privacy & Consumer Protection committee analysis, SB 942 (2024)

That is a hash-record compliance path, endorsed in the legislative record, and it is not in any client alert we can find. It matters for a reason beyond flattery of our own design: an output-side corpus of hashes is not caught by the retention limits the statute puts on the detection tool itself. The tool is forbidden from emitting personal provenance data. A hash ledger of what you produced is a different object, held on your side, and answers a different question.

The rest of this page is what that record looks like when it is built to survive a hostile reading rather than merely to exist.

06Duty → receipt

This is where Planisphere enters, and not before. The California pack registers one event type per statutory act. The field names below are not illustrative — they are the fields the API accepts, and they were chosen to match the statute's own vocabulary.

Statutory actEvent typeWhat is committed
Declaring what is in scope system_declared role output_classes marking_techniques counter_binding window_cadence effective_from · commits scope_sha256
Latent disclosure embedded latent_disclosure_embedded The four statutory elements — provider_name system_name system_version created_or_altered_at unique_identifier · commits content_sha256 manifest_sha256
Manifest disclosure offered manifest_disclosure_offered offered_at channel · commits manifest_sha256
Detection tool answering detection_tool_heartbeat endpoint probe_result probed_at
Licence granted license_granted granted_at · commits licensee_id_sha256 contract_sha256
Licence revoked, 96-hour clock license_revoked revoked_at cease_by · commits licensee_id_sha256 contract_sha256

Two properties matter more than the field list. Content never leaves your systemssource_payload takes hash commitments, never bytes, so a record can commit to an image without the image ever being transmitted. And each record is sealed on write: hash-chained into a per-tenant series, signed, and periodically anchored, so a later edit to any earlier record breaks the chain in a way a third party can detect without trusting either of us.

07The integration

One HTTPS call per act, from wherever the act happens. This is the whole surface — there is no agent to install, no proxy in your generation path, and nothing that can fail closed and take your pipeline down with it.

Declare the system once, before anything else:

# One-time: what this system is in scope to produce. curl -X POST https://api.planisphere.ooo/v1/record \ -H "Authorization: Bearer $PLANISPHERE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "pack": "ca-sb942", "event_type": "system_declared", "occurred_at": "2026-08-02T00:00:00Z", "system_id": "image-gen-prod", "sequence_binding": true, "metadata": { "role": "covered_provider", "output_classes": "image,video", "marking_techniques": "c2pa,invisible_watermark", "counter_binding": "render_pipeline.emit_seq", "effective_from": "2026-08-02" } }'

Then one call per act. Here is the disclosure record — note that only hashes cross the wire:

# Per artefact: the four statutory elements, plus the counter. curl -X POST https://api.planisphere.ooo/v1/record \ -H "Authorization: Bearer $PLANISPHERE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "pack": "ca-sb942", "event_type": "latent_disclosure_embedded", "occurred_at": "2026-08-02T14:22:07Z", "system_id": "image-gen-prod", "system_seq": 4102887, "source_payload": { "content_sha256": "9f2c…", // the image. Never sent. "manifest_sha256": "41ab…" }, "metadata": { "provider_name": "Northlight Studios, Inc.", "system_name": "Northlight Render", "system_version": "4.2.1", "created_or_altered_at": "2026-08-02T14:22:06Z", "unique_identifier": "nl-img-8830a1f4" } }'

At volume you do not want one HTTPS round trip per image in the render path. Batch transport exists for exactly this, and batching changes nothing about the evidence: each item is still its own record with its own key and its own place in the chain. The 96-hour revocation duty uses the same call with license_revoked, where starts_from_action_key ties the revocation to the moment of discovery, so the elapsed time is computed from sealed records rather than asserted.

The full API reference covers authentication, idempotency and rate limits; pricing is per record with a monthly free allowance.

08Anyone can check it, without an account

Evidence that only you can read is not evidence. Every sealed record has a public standing endpoint — no key, no login, no relationship with us. A regulator, an opposing counsel, or a customer can confirm that a record exists, that it has not been withdrawn, and which anchored epoch pins it:

# Public. No authentication. Try it with any action key. curl https://api.planisphere.ooo/trust/records/<action_key> { "object": "trust_record", "action_key": "…", "exists": true, "seal_standing": "sealed", "anchor": { "epoch_sha256": "…" }, "disclosure": "pin_only" }

The endpoint answers existence, standing and the anchor pin — deliberately not the contents. Your metadata stays yours; what a third party gets is the ability to confirm that the record you are showing them is the record that was sealed, unchanged, at the time you say it was.

09Who enforces it — and what has actually happened

Almost nothing, so far. That is worth stating plainly rather than implying a wave of enforcement that has not arrived.

There is no agency guidance, and there cannot be regulations. Chapter 25 delegates rulemaking authority to no one. Enforcement runs through the Attorney General, city attorneys and county counsel by civil action only — there is no agency with the power to write implementing rules, publish an FAQ with legal weight, or run a registry. An earlier draft of SB 942 did create a registry at a state department; committee amendments struck it in May 2024. The California Privacy Protection Agency has no role here either: its automated-decision rules govern decisions made about people, while this chapter governs content provenance. The two do not overlap.

There is no litigation on this statute. A docket search for the code sections returns nothing. Expect to see one case cited as though there were: a suit filed against the Attorney General in late 2025 by an AI developer is about California's training-data transparency law, not this one — its complaint does not mention these sections at all. The distinction matters for how much comfort you take from it, because compelled disclosure of proprietary training data is a much stronger First Amendment target than a requirement to label content with factual provenance.

Enforcement capacity was an open question during passage. The Department of Justice told an appropriations committee it could not absorb the work without additional staff, and noted that implementation would depend on funding. A committee analysis observed that if the department chose not to pursue enforcement, it would likely incur no costs. Draw your own conclusion about near-term risk — but note that the per-day penalty structure means exposure accrues quietly during exactly the period when nobody is knocking.

One live item: a further bill amending the large-online-platform section on system provenance data passed the Assembly unanimously in May 2026 and was moving through the Senate at the time of writing. It does not touch the operative date.

10What Planisphere does not do

Stated plainly, because a vendor who is vague here is a vendor who will be vague in front of a regulator. Planisphere is an evidence layer. It sits beside your systems, never inside the act.

  • It does not embed latent disclosures, apply watermarks, or write C2PA manifests. Your pipeline does that.
  • It does not operate, host, or observe your detection tool. It records the result of a probe you ran, as you reported it.
  • It does not present the manifest disclosure option to your users.
  • It does not revoke licences, and it cannot make a revocation happen inside 96 hours.
  • It does not certify compliance, issue an opinion, or make a legal determination. No vendor can. A record is evidence a third party can check; it is not a finding that you complied.
  • It does seal the acts you performed, at the moment you performed them, in a form that a hostile reader can verify and you cannot quietly revise.

11Questions

We use a third-party model. Are we the covered provider?
Generally not — the duties fall on whoever creates, codes or produces the system, which is the model developer rather than a business calling its API. But check your licence terms: if you have licensed a covered system and modified it in a way that strips the disclosures, duty four makes you the subject of a 96-hour revocation by your licensor.
Does the penalty really run per day?
Yes, and it changes what "being compliant" means operationally. The defensible question is not are you compliant — it is on which days can you show you performed the duty. A continuous per-day record answers a per-day penalty. A screenshot does not.
We are already doing C2PA. Isn't that enough?
C2PA addresses the latent disclosure duty well, and it is the obvious way to meet the "consistent with industry standards" language. It does not address the detection tool, the manifest disclosure option, or the 96-hour revocation — and a manifest travelling with a file proves what the file claims today, not what you did on a date two years ago when the file is no longer in your hands.
What happens to our content and our metadata?
Content is never transmitted — only hash commitments. Declared metadata values are retained only when the pack marks the key as retainable and your organisation has enabled retention; otherwise only the key names and a canonical hash are kept. Person-identifying keys are never retainable.
What if we start recording after 2 August?
Then your evidence begins on the day you start, and it says so. A record cannot be back-dated — occurred_at is your own claim, but it is committed into the sealed payload and pinned by the anchor, so a record written in October cannot be made to look like one written in August. Starting late is recoverable. Starting late and pretending otherwise is not.
Does this cover the EU obligations too?
The same evidence discipline, different duties. Article 50 binds providers and deployers differently and turns on marking and disclosure rather than detection tools and licensing, so it has its own pack and its own event types. The EU page walks through it.

12Sources

Every date, threshold and figure on this page traces to one of these. Where the statute is summarised rather than quoted, the summary is ours and the citation points at the text so you can check it.

Start the evidence trail

The console opens on the California pack with every duty listed, each one showing the exact call that seals it. Sealing one record takes about a minute, and the first thousand each month are free. If you would rather read first, the integration guide covers authentication, batching and the retention controls.