Describe your business, leave with a checklist you can assign

A large frontier developer must write, implement, comply with and clearly and conspicuously publish on its website a frontier AI framework describing how it incorporates national standards, international standards and industry-consensus best practices; defines and assesses thresholds, which may be tiered, for identifying capabilities that could pose catastrophic risk; reviews assessments and the adequacy of mitigations as part of the decision to deploy or use a model extensively internally; determines what substantial modifications trigger updated disclosures; and assesses and manages catastrophic risk from internal use, including the risk of a model circumventing oversight mechanisms.

Evidence: Published frontier AI framework text with version history; Definition of capability thresholds and the assessment methodology; Pre-deployment risk assessment and mitigation adequacy review records; Framework update triggers and the record of actual updates

ISO/IEC 42001 AI management system implementation and certification readiness checklist

A frontier developer must report any critical safety incident involving its frontier models to the Office of Emergency Services within 15 days of discovery. If the incident poses an imminent risk of death or serious physical injury, the developer must disclose it within 24 hours to an appropriate authority, including any law enforcement or public safety agency with jurisdiction, as required by law. Amended reports may be filed as new information emerges. Statutory incident types include unauthorized access to, modification of or exfiltration of model weights resulting in death or bodily injury; loss of control of a frontier model causing death or bodily injury; and a model using deceptive techniques against the developer to subvert its controls or monitoring outside an evaluation designed to elicit that behaviour, in a manner demonstrating materially increased catastrophic risk.

Evidence: Incident classification criteria document; Incident register recording discovery time, classification and reporting time; Reports filed with the Office of Emergency Services and filing receipts; Records of 24-hour disclosures showing recipient and channel

AI incident and serious incident reporting record (register plus report drafts)

Before, or concurrently with, deploying a new frontier model or a substantially modified version of an existing one, a frontier developer must clearly and conspicuously publish a transparency report on its website stating the release date, languages supported, output modalities supported, intended uses and any generally applicable restrictions or conditions on use. A large frontier developer must additionally include summaries of the catastrophic-risk assessments conducted under its frontier AI framework and of the other steps taken to fulfil that framework for the model.

Evidence: Archived transparency report for each model version with publication timestamps; Catastrophic-risk assessment reports mapped to the published summaries; Determination records for what counts as a substantial modification; Release checklist evidencing the sequencing of deployment approval and report publication

Model Card

A large frontier developer must transmit to the Office of Emergency Services a summary of any assessment of catastrophic risk resulting from internal use of its frontier models every three months, or on another reasonable schedule communicated to the Office in writing, with written updates as appropriate. The Office must establish a mechanism for confidential submission and limit access to the reports.

Evidence: Methodology and records for internal-use risk assessments; Written notice of an alternative reporting schedule where the quarterly cadence is not used; Each submitted summary and its filing receipt; Records of internal-use oversight mechanisms and circumvention testing

A frontier developer must not make a materially false or misleading statement about catastrophic risk from its frontier models or about its management of that risk. Read with the transparency report and framework duties, publicly claimed safety evaluations, red-teaming and mitigations must match what is actually performed internally.

Evidence: Reconciliation working papers mapping public safety claims to internal evidence; Raw records of red-teaming and safety evaluations; Compliance review records for marketing and sales materials; Fact-check records for responses to customer security questionnaires

A frontier developer must not make, adopt, enforce or enter into any rule, policy or contract that prevents a covered employee from disclosing, or that retaliates for disclosing, information where the employee has reasonable cause to believe it shows that the developer activities pose a specific and substantial danger to public health or safety from a catastrophic risk, or that the developer violated the TFAIA. Developers must give covered employees clear notice of these rights, either by posting in the workplace or by annual written notice. A large frontier developer must also provide a reasonable internal anonymous disclosure process with monthly status updates to the discloser on the investigation and the actions taken.

Evidence: Records of compliance edits to the employee handbook, confidentiality agreements and restrictive covenants; Proof of workplace posting or delivery and acknowledgement of the annual written notice; Technical design and operating records for the anonymous reporting channel; Case log of disclosures with evidence of monthly status updates

A business must conduct a risk assessment before initiating any processing that presents significant risk to consumer privacy. The enumerated activities are selling or sharing personal information; processing sensitive personal information (excluding processing of employee and independent contractor sensitive information solely for administering compensation payments, determining and storing employment authorization, administering benefits, providing legally required reasonable accommodation or statutory wage reporting); using ADMT for a significant decision concerning a consumer; and using automated processing to infer or extrapolate a consumer intelligence, ability, aptitude, work performance, economic situation, health including mental health, personal preferences, interests, reliability, predispositions, behaviour, location or movements based on systematic observation of that consumer acting as an education program applicant, job applicant, student, employee or independent contractor.

Evidence: Risk assessment report structured to the elements of section 7152; Processing inventory mapped to the triggering paragraphs; Evidence that the assessment predates the start of processing; Update triggers and records of assessment updates

A business whose processing presents significant risk to consumer security must complete a cybersecurity audit. The triggers are meeting the threshold in Civil Code section 1798.140(d)(1)(C), or meeting the (d)(1)(A) revenue threshold and having processed the personal information of 250,000 or more consumers or households, or the sensitive personal information of 50,000 or more consumers, in the preceding calendar year. First audit reports are phased by revenue: due 2028-04-01 where 2026 annual gross revenue exceeded $100,000,000 as of 2027-01-01, covering 2027-01-01 to 2028-01-01; due 2029-04-01 where 2027 revenue was between $50,000,000 and $100,000,000 as of 2028-01-01, covering 2028-01-01 to 2029-01-01; and due 2030-04-01 where 2028 revenue was below $50,000,000, covering 2029-01-01 to 2030-01-01. After 2030-04-01 the audit becomes a rolling annual obligation.

Evidence: Trigger determination working papers with consumer, household and sensitive information counts; Cybersecurity audit report; Remediation register for audit findings with closure evidence; Revenue evidence for the phasing tier and the calendar reminders for each due date

SOC 2 Type II readiness checklist (Trust Services Criteria)

A business that uses ADMT to make a significant decision concerning a consumer must provide a Pre-use Notice, and unless an exception applies must include in it the right to opt out of that use and how to exercise it. A business using ADMT for significant decisions before 2027-01-01 must be compliant no later than 2027-01-01; a business that begins on or after that date must be compliant at any time it is using ADMT for a significant decision.

Evidence: Pre-use Notice text and screenshots of where it is displayed; Inventory of ADMT uses distinguishing significant decisions from other uses; Delivery records and version control for the notice; Project plan and sign-off evidencing readiness by 2027-01-01

A business must establish and publicize channels and workflows for requests to opt out of ADMT (section 7221) and requests to access ADMT (section 7222). Where the business relies on an exception in section 7221(b) instead of offering an opt-out, it must say so in the Pre-use Notice and give the consumer the explanation that section requires.

Evidence: Screenshots of the opt-out and access request intake pages; Request log recording intake time, identity verification, outcome and turnaround; Memo on any exception relied on and its legal basis; Records of human review and of notifying the consumer of outcomes

First determine whether the company meets the CCPA definition of a business. Effective 2025-01-01 the annual gross revenue threshold in Civil Code section 1798.140(d)(1)(A) is $26,625,000 as adjusted for inflation. The determination should be documented and reviewed annually because the risk assessment, cybersecurity audit and ADMT duties all depend on it.

Evidence: Business-status determination memo covering revenue, consumer counts and the share of revenue from selling or sharing data; Annual review record; Applicability matrix across group entities

For risk assessments conducted in 2026 and 2027 the business must submit the required information to the California Privacy Protection Agency no later than 2028-04-01. For assessments conducted after 2027 submission is due by April 1 of the following year. The submission covers the business name and a point of contact with name, phone and email, the time period covered by month and year, the number of risk assessments conducted or updated in total and per triggering activity, and whether those assessments involved each of the categories of personal and sensitive personal information in Civil Code sections 1798.140(v)(1)(A)-(L), (ae)(1)(A)-(G) and (ae)(2)(A)-(C).

Evidence: Register counting risk assessments per triggering activity; Submission working papers and receipt; Mapping table for the personal and sensitive personal information categories; Point-of-contact authorization and change records

On or before 2026-01-01, and before each subsequent time a generative AI system or service released on or after 2022-01-01, or a substantial modification of it, is made publicly available to Californians, the developer must post documentation on its website covering at least: the sources or owners of the datasets; how the datasets further the intended purpose; the number of data points, which may be given in ranges with estimates for dynamic datasets; the types of data points, meaning label types or the general characteristics of unlabelled data; whether the datasets include material protected by copyright, trademark or patent, or are entirely in the public domain; whether the datasets were purchased or licensed; whether they include personal information as defined in Civil Code section 1798.140(v); whether they include aggregate consumer information as defined in section 1798.140(b); whether the developer cleaned, processed or otherwise modified the datasets and for what purpose; the time period of collection, noting whether collection is ongoing; the dates the datasets were first used in development; and whether the system used or continuously uses synthetic data generation. The duty applies regardless of whether use is for compensation.

Evidence: Archived copies of the training-data disclosure page with timestamps for each release or modification; Dataset inventory recording source, licence status and purchase or licence evidence; Working papers on data point counts and types; Statement on synthetic data use and determinations on personal information and aggregate consumer information

Data Card — datasheet for a training, validation or test dataset

No documentation is required for a generative AI system or service whose sole purpose is to help ensure security and integrity, using the Civil Code section 1798.140(ac) definition but applied to any developer or user rather than only to businesses; whose sole purpose is the operation of aircraft in the national airspace; or that is developed for national security, military or defence purposes and made available only to a federal entity. A developer relying on an exemption should retain a written determination to support enforcement responses and customer diligence.

Evidence: Exemption determination memo citing the specific paragraph relied on; Statement of product purpose and customer scope; Internal approval record

Data Card — datasheet for a training, validation or test dataset

A covered provider must make available, at no cost, an AI detection tool that lets a user assess whether image, video or audio content, or a combination, was created or altered by that provider generative AI system; outputs any system provenance data detected; does not output personal provenance data; is publicly accessible, subject only to reasonable limits to address demonstrable risks to the security or integrity of the system; allows upload of content or a URL; and supports an API so the tool can be invoked without visiting the provider website. The provider must collect and act on user feedback about the tool efficacy, and must not collect or retain personal information from tool users (except contact details of users who opt in to being contacted, used only to improve the tool), must not retain submitted content longer than necessary, and must not retain personal provenance data from submitted content.

Evidence: Detection tool product documentation and API documentation; Monthly user or visitor metrics and methodology used for the threshold test; User feedback collection records and the resulting improvement iterations; Data retention and deletion policy for the tool with evidence of enforcement

A covered provider must include a latent disclosure in AI-generated image, video or audio content created by its system. To the extent technically feasible and reasonable the disclosure must convey, directly or through a link to a permanent website, the provider name, the name and version number of the system that created or altered the content, the time and date of creation or alteration, and a unique identifier. It must be detectable by the provider detection tool, consistent with widely accepted industry standards, and permanent or extraordinarily difficult to remove to the extent technically feasible. The provider must also offer the user the option to include a manifest disclosure that identifies the content as AI-generated, is clear, conspicuous, appropriate for the medium and understandable to a reasonable person, and is likewise permanent or extraordinarily difficult to remove.

Evidence: Technical design for latent disclosures identifying the industry provenance standard used; Sample disclosure payloads and end-to-end verification against the detection tool; Product interface for the manifest disclosure and records of user choices; Robustness test report evidencing removal difficulty

Model Card

If a covered provider licenses its generative AI system to a third party, it must require by contract that the licensee maintain the capability to include the latent disclosure in content the system creates or alters. If the provider knows that a licensee modified the system so that it can no longer do so, the provider must revoke the licence within 96 hours of discovery, and the licensee must cease using the system after revocation.

Evidence: Licence template and executed agreements containing the disclosure-capability covenant; Licensee monitoring mechanism and discovery records; Revocation decision and proof of delivery within 96 hours; Verification that use ceased after revocation

From 2027-01-01 a large online platform must detect whether provenance data compliant with widely adopted specifications from an established standards-setting body is embedded in or attached to content it distributes; provide a user interface disclosing the availability of system provenance data reliably indicating that the content was generated or substantially altered by a GenAI system or captured by a capture device, making clearly and conspicuously available information sufficient to identify authenticity, origin and modification history, including at least whether provenance data is available, the name of the GenAI system or capture device, and whether digital signatures are available; and allow users to inspect all available compliant system provenance data through the interface, by downloading a version with the data attached, or via a link to a provenance display page. The platform must not, to the extent technically feasible, knowingly strip compliant system provenance data or digital signatures from uploaded or distributed content. A large online platform is a public-facing social media, file-sharing, mass messaging platform or stand-alone search engine exceeding 2,000,000 unique monthly users during the preceding 12 months, excluding broadband internet access service and telecommunications service.

Evidence: Technical design and test report for the provenance detection pipeline; User interface designs and production screenshots; Engineering controls and regression tests preventing stripping of provenance data; Unique monthly user metrics and methodology used for the threshold test

From 2027-01-01 a GenAI hosting platform must not knowingly make available a GenAI system that does not place disclosures under section 22757.3. A GenAI hosting platform is an internet website or application that makes available for download the source code or model weights of a generative AI system by a California resident, regardless of compensation, which brings open-weight distribution channels and model marketplaces directly within scope.

Evidence: Listing review workflow and records verifying disclosure capability; Platform rules and developer agreement clauses imposing the disclosure requirement; Records of takedowns or refusals to list; Description of sampling and re-review mechanisms