California CCPA Regulations: Risk Assessments for Using Personal Information to Train AI

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Which training activities trigger a CCPA risk assessment

Training triggers an assessment when the intended model either makes or substantially replaces human judgment in a significant decision, or identifies, verifies or profiles people from physical or biological traits [3]. The final rules list training alongside other risky processing (selling or sharing personal information, processing sensitive personal information, and using ADMT for significant decisions) as activities that require an assessment [2][3]. As of October 2026, read the exact trigger wording in the official text in Title 11 of the California Code of Regulations (sections 7150 onward), not a summary; the commentary we rely on paraphrases it [3].

Two definitions do most of the work. ADMT, in the final rules, means technology that processes personal information and uses computation to replace, or substantially replace, human decisionmaking [2]. A "significant decision" covers financial or lending services, housing, education, employment or independent-contracting opportunities and compensation, and healthcare services, as summarized by practitioners [2][3]. Earlier drafts reached further (for example, behavioral advertising and generative model training generally); the final package narrowed those, so do not build your trigger logic on 2024 draft language [3].

The practical consequence for data buyers: the trigger attaches to the purpose for which you process the data, not to the data type. The same call-center transcripts can be out of scope when used to train a summarization assistant and in scope when used to train a model that scores loan hardship applications.

Illustrative example: invented to show structure; it does not describe an available dataset.

What a CCPA training risk assessment must record

The assessment is a documented record of purpose, data, operations, benefits, harms and safeguards, approved by named people and kept on file [2][3]. Practitioner summaries of the final rules describe these required elements, which map closely to what a training pipeline already knows about itself [2][3]:

• Specific purpose: "train a hardship-triage model for consumer loans," not "improve our services."
• Categories of personal information, including sensitive categories, and why each is necessary for the purpose (data minimization).
• Operational elements: collection method and source (first-party, licensed from a supplier, service provider), retention period, the technology and model logic, recipients, and approximate number of consumers.
• Benefits to the business, consumers and others.
• Negative impacts to consumers, such as discrimination, loss of control over personal information, re-identification, unauthorized access, and economic or psychological harm.
• Safeguards: de-identification or pseudonymization, access controls, bias testing, human review and contract terms with suppliers.
• Decision and sign-off: whether the processing will proceed, who contributed, who approved it, and the dates.

The regulations frame the test as whether the risks to consumers' privacy outweigh the benefits; if they do, the business should not proceed with the processing as designed [2]. Keep the assessment current: practitioner summaries describe periodic review and updates after material changes, such as adding a new data source or changing the model's decision scope [3][4].

How the compliance dates phase in

As of October 2026, risk assessment obligations have applied since 1 January 2026, and the first submission of attestations and summary information to the CPPA is due 1 April 2028 for assessments conducted in 2026 and 2027 [2][5]. Processing that started before 2026 and continues afterward needs a completed assessment by 31 December 2027, per practitioner reading of the rules [5]. ADMT consumer-facing duties (pre-use notice, opt-out with exceptions, and access requests) apply from 1 January 2027 [2].

Cybersecurity audit certifications are phased separately by revenue: 1 April 2028 for businesses above $100 million, 2029 for $50 to $100 million, and 2030 below $50 million [2]. Sources describe later submission cadence slightly differently, so confirm annual deadlines after 2028 against the official text [5]. The CPPA announcement is the authoritative reference for what was approved [1].

Where acquired training data changes the analysis

Licensed or purchased data does not move the assessment duty to the supplier: the business that processes the personal information for the triggering training purpose owns the assessment [3]. What changes is the evidence you need. Your assessment's "source," "categories," "consent and notice" and "safeguards" fields depend on facts only the supplier has, so collect them at intake rather than reconstructing them later.

Ask suppliers for: the original collection context and privacy notice; whether the data was sold or shared under the CCPA (and whether opt-outs were honored); field-level inventories that flag sensitive personal information such as account log-in credentials, precise geolocation, biometric data and health information; the de-identification method and its test results; and the contractual uses permitted. The training data risk assessment before acquisition guide shows how to score those answers before you sign.

Service-provider structures also matter. A vendor processing data as your service provider may use it to build or improve the quality of its own services, but may not use it to build or modify consumer profiles for providing services to another business, or to correct or augment data acquired from another source [7]. If a vendor proposes to train its own models on your customers' data, that is a contract and assessment question, not a default right.

When deidentification takes training data out of scope

Information meeting the CCPA definition of "deidentified" is not personal information, so training on it does not trigger the risk assessment provision [6]. The definition in Civil Code 1798.140(m) requires that the information cannot reasonably be used to infer information about, or be linked to, a particular consumer, and that the business holding it takes reasonable measures to prevent re-identification, publicly commits not to re-identify, and contractually binds recipients to the same [6].

The failure modes are predictable. Free-text fields in tickets and call transcripts leak names and account numbers that column-level masking misses; voice and face data are inherently identifying and rarely deidentifiable for identity-verification training; and joining a "deidentified" set with your own first-party records can recreate personal information. See CCPA deidentified data obligations for buyers and re-identification risk assessment methods for the controls to request.

A risk assessment record for a training dataset

A useful assessment record is structured so each field can be filled from supplier diligence and your model card, and re-run when either changes. The template below is a working skeleton your privacy team can adapt; it is not the regulatory form, and the CPPA submission fields should be taken from the official text.

Illustrative example: invented to show structure; it does not describe an available dataset.

assessment_id: RA-2026-014
processing_activity: "Train hardship-triage model for consumer loan servicing"
trigger: "Training ADMT for a significant decision (financial or lending services)"
model:
  name: hardship-triage-v2
  decision_role: "Scores hardship requests; human reviewer approves all denials"
  substantially_replaces_human: false   # document the reasoning
data_sources:
  - source: "Licensed servicing records, US lender (supplier)"
    collection_context: "Customer servicing calls and forms, 2021-2025"
    notice_reviewed: true
    sold_or_shared_status: "Licensed under written agreement; opt-out list applied"
    pi_categories: [name, account_number, income, hardship_reason_text]
    sensitive_pi: []   # an account number alone is not sensitive PI unless paired with access credentials
    minimization: "Names and account numbers replaced with tokens; free text redacted"
    deidentified_under_1798_140m: false
consumers_approx: 120000
retention: "Training copy deleted at end of license term; features retained 24 months"
benefits: ["Faster hardship routing", "Consistent criteria across agents"]
negative_impacts: ["Disparate denial rates", "Re-identification from free text", "Loss of control"]
safeguards: ["Bias test by protected-class proxies", "Human review of adverse outcomes", "Access limited to ML team"]
outcome: proceed_with_safeguards
contributors: [privacy_counsel, ml_lead, model_risk]
approved_by: "Chief Privacy Officer"
approved_on: 2026-09-30
next_review: "On new data source or scope change"

How this fits with Colorado, AB 2013 and other training-data records

California's risk assessment is one of several overlapping records a training team will maintain, and one supplier intake can feed all of them. Colorado's SB26-189, signed 14 May 2026, requires ADMT developers from 1 January 2027 to give deployers documentation that includes categories of training data [8]; see Colorado SB 26-189 training data documentation. California's AB 2013 already required generative AI developers to post training-data documentation by 1 January 2026 [9], covered in California AB 2013 disclosures.

Treat the risk assessment as the deepest of these records: it holds the "why" and the safeguards, while disclosure regimes publish a subset. The state AI law tracker and the AI training data compliance hub list the adjacent obligations, and the AI data buyer library indexes every guide. For commercial licensing of business records under California law, see CCPA and licensing business data.

What to ask a data supplier before training an in-scope model

Buyers should make the assessment inputs a condition of acquisition, because gaps found after training are expensive to close. A short request list:

1. Collection context, privacy notice text and date for each source system.
2. A field inventory marking personal and sensitive personal information, including free-text fields.
3. The de-identification or pseudonymization method, who applied it, and how a sample was checked.
4. CCPA sale/share status and how opt-out and deletion requests were applied before release.
5. Permitted uses in the license, especially whether training for significant decisions or identity technologies is allowed.
6. A point of contact for refreshing these facts when the dataset is updated.

SourceX sources operational datasets, such as support, sales, finance and legal workflow records, from US companies on request, and personal details like names, emails, phones and account numbers are removed or replaced before delivery with the method recorded and a sample checked, although no method is perfect. Buyers can describe the data they need through the SourceX buyer intake.

Sourcing training data for an assessed use case

If your model falls inside a CCPA risk assessment trigger, the quality of your supplier evidence decides how defensible the assessment is. SourceX rights-reviews every dataset for ownership and consents, prepares diligence materials per dataset, and delivers under a license defining records, uses, term and delivery; every release is approved by the supplying company. Describe the data you need at https://sourcex.si/buyers.