Does SB 942 require a formal AI risk assessment?

The chaptered text prescribes detection and manifest disclosure, as well as latent disclosure and licensing. It also prescribes enforcement and related data-handling duties. It does not prescribe a document called an AI risk assessment. Organizations use the assessment to decide applicability and test each mechanism. They also use it to assign remediation and preserve an approval record. Labeling it as an internal workflow avoids presenting implementation advice as statutory wording.

Should text-only LLM deployments enter the assessment?

Record them during applicability triage because the statutory GenAI definition includes text. The operative duties address generated images, videos, audio, and combinations of those media. A service that produces text alone has a different exposure than a multimodal service that can generate an image inside the same product. Preserve the facts behind that distinction for legal review.

How often should the assessment run?

Run it before approving a covered path and again after a material change. Useful triggers include a model-version change and an added output medium. A new licensee or revised export pipeline should also trigger a run. The same applies to a component that rewrites metadata. A fixed annual cycle can supplement those triggers. It should never delay a retest after engineering changes the provenance path.

Where does DeepInspect fit in the assessment?

DeepInspect covers deliberately routed HTTP traffic between authenticated users or agents and LLM endpoints. It can record the application-supplied identity and model destination, along with the policy version and request decision for traffic it receives. Watermark creation and manifest labeling sit outside that boundary. The provider's public detection tool and provenance that downstream software strips also sit outside it. The assessment should record both layers without treating one as proof of the other.

California SB 942 AI Risk Assessment: A Scoped Workflow for Content Provenance

California SB 942 calls for an assessment with a tight object: the systems and content types covered by California's provenance rules, plus the relevant licenses and distribution paths. The statute itself does not prescribe a formal AI risk assessment. A team creates one to establish applicability and test the required disclosures. It also assigns gaps and preserves a dated readiness decision.

I would keep that scope on one sheet of paper. A broad enterprise AI risk register can hide a failed latent disclosure behind dozens of unrelated model risks.

TL;DR

SB 942 creates provenance and detection duties, rather than a statutory risk-assessment format.
Start with the covered-provider definition and the one-million-user threshold. Then record California availability and the media each system creates.
Test manifest and latent disclosure. Check the public detection tool and each licensed deployment separately.
Keep generation-layer findings separate from HTTP request evidence and assign every gap to a named owner and date.

Fix the legal scope before scoring risk

The chaptered SB 942 text defines a covered provider as a person that creates or codes a generative AI system, or otherwise produces one, with more than 1,000,000 monthly visitors or users that is publicly accessible in California. Its GenAI definition includes systems capable of producing text and images, along with video and audio. The operative duties focus on image and video content, plus audio content and combinations of those media.

The first assessment record should identify the legal entity that creates the system and the measured visitor or user population. It should also identify the California access path and the output media. Record the measurement date and source. A product owner saying "about a million" across a conference table is a lead for investigation, rather than an applicability conclusion.

Also capture the statutory exclusion for products and services providing exclusively non-user-generated experiences in video games, television, streaming, movies, or interactive media. Legal should own that interpretation. Engineering should supply the product facts it rests on.

Build the inventory around generation paths

List every production path that can create or alter covered media. Give each path a system name and version, owner, endpoint, and output type. Also record its user population and California availability, plus its licensing status. Include direct product features and APIs. Add batch jobs and licensed deployments operated by another party.

This inventory differs from the evidence package in our SB 942 audit-evidence guide. The assessment decides which paths deserve tests and remediation. Audit evidence proves how a selected path behaved on a selected date.

For each path, draw the response route through generation and storage, then through editing and export before publication. The useful diagram names the service that first writes the content and every component that may rewrite metadata. A thumbnail generator or transcoder can sit downstream of the model and still determine whether provenance survives. The same applies to a social publishing step.

Test the four statutory mechanisms separately

SB 942 creates distinct mechanisms, so a single "watermark present" result leaves too much unresolved.

First, test the manifest disclosure option. Confirm that a user can choose a clear disclosure appropriate to the medium and that the disclosure persists as far as technically feasible.

Second, test the latent disclosure on generated image, video, and audio content. The statute names the covered provider and the system name and version. It also names the creation or alteration time and a unique identifier among the information conveyed where technically feasible and reasonable. Preserve the original output and the test result.

Third, exercise the provider's no-cost detection tool by file upload and URL. The statute requires public access and support for an API. It must output detected system provenance data and apply restrictions around personal provenance data and submitted content.

Fourth, test every licensed deployment. The contract must require the licensee to maintain latent-disclosure capability, and the provider needs a process for the 96-hour revocation duty described in our incident-reporting analysis.

Score failures by exposure and controllability

A useful rating combines the number of affected generation paths with the point where the disclosure fails. It also includes the time required to stop further affected output. Keep each component visible instead of compressing the finding into a coloured square.

A missing disclosure at initial generation belongs to the covered provider's output pipeline. A disclosure stripped during an enterprise export belongs to that downstream application owner. A licensed deployment that lost the capability also activates a provider-side discovery and revocation process. Those findings require different owners even when the resulting content looks identical.

My view is blunt: a risk score without a named failure point is decoration. The assessment should identify the component and owner, then provide the test case and evidence location. It should state the corrective action and due date, with a separate retest condition. The SB 942 controls mapping helps keep those owners aligned with the layer they can actually change.

Turn the result into a dated control cycle

Create one assessment record per system version or material distribution-path change. Attach the applicability facts and system diagram. Add the sample set and results for all four mechanisms. Include the license list, open findings, and approval. Define reassessment triggers for a new model version or output medium. Also trigger reassessment for a changed provenance specification, a new export path, or a licensee modification.

The AB 853 chaptered text moved the chapter's operative date to August 2, 2026. It also added later duties for large online platforms beginning January 1, 2027 and capture-device manufacturers beginning January 1, 2028. Treat those as separate scope branches. A covered provider assessment should avoid silently absorbing controls owned by a platform or device maker.

Finish with a residual-risk decision signed by legal and product, with engineering included. The signature records who accepted a known limitation and the date of that decision. It never turns a missing statutory mechanism into compliance.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For generation calls deliberately routed through it, DeepInspect evaluates the application-supplied identity and role against organizational policy for content classification and model authorization before forwarding the request.

Each decision produces a signed, tamper-evident record outside the calling application's write path. That record supports the request-side portion of an SB 942 assessment by showing the user and model route. It also shows the governing policy and the time of the request. Generation-layer provenance and downstream content handling remain separate controls with separate evidence.

Book a technical deep dive at deepinspect.ai.