AI and Data Licensing · Memo

CCPA/CPRA and AI Inference: When AI Outputs Become Personal Information

The CCPA's inference language and the CPPA's ADMT rulemaking together create a real obligation for AI deployments handling California data. I will lay out where the rule actually bites and where it is still moving.

Cal. Civ. Code section 1798.140(v)(1)(K) defines personal information to include inferences drawn from any of the information identified in the section to create a profile about a consumer reflecting the consumer's preferences, characteristics, psychological trends, predispositions, behavior, attitudes, intelligence, abilities, and aptitudes. The drafting was specific and the reach is broad. When an AI model takes personal information about a California resident and produces an output that is itself a profile, the output is, on the face of the statute, personal information. The output's status as personal information triggers the consumer's rights to know, to delete, to correct, and (in many cases) to opt out of sale or sharing.

The operational consequences are not yet broadly internalized in AI deployments. A model that infers a customer's likelihood to churn, a candidate's job-fit score, a borrower's credit risk, a patient's adherence to treatment, or a student's likelihood of academic success is producing output that, when the input is personal information about a Californian, falls within the CCPA's reach. The CPPA has signaled that this is the agency's reading. Counsel for businesses deploying inference-producing AI should not assume otherwise.

The CPPA ADMT rulemaking

The CPPA's draft regulations on Automated Decision-Making Technology have been through multiple drafts since 2023. As of the date of this memo, the regulations have not been finalized. The agency has signaled the structural elements. The regulations would impose pre-use notice obligations on businesses using ADMT for significant decisions (employment, housing, insurance, education, financial services, healthcare, essential services), grant a right of access to information about the ADMT used, grant a right to opt out of ADMT use in some categories, and impose risk-assessment obligations on businesses using ADMT.

I am going to flag uncertainty here. The rulemaking is not done. The final text will likely differ in detail from the drafts. Counsel should track the CPPA's published regulatory packages directly rather than rely on summaries (including this one). The structural posture, however, is unlikely to change. Businesses that deploy AI to make consequential decisions about Californians will have notice, access, and opt-out obligations. Build the operational infrastructure now; the rule details can be retrofitted.

What 'inference' means in practice

The statutory text reaches inferences drawn from personal information to create a profile. The interpretive questions:

• Does the inference have to be specifically labeled as such? No. The CPPA's published guidance has been clear that the analysis is functional. If the output is an assessment of the consumer's preferences, characteristics, or behavior, the output is an inference regardless of how the business labels it internally.
• Does the inference have to be 'profile-like' in some special sense? The statute uses the term 'profile' but the agency's reading is broad. A score, a classification, a recommendation, a risk rating, a propensity estimate, a content match, a fraud alert, and many other AI outputs can fall within the definition.
• Does the inference have to be stored? The statute does not require storage. The transient inference produced and used in real time can still be personal information for purposes of disclosure obligations, even if it is not retained.
• Does the inference have to be accurate? No. The statute applies regardless of accuracy. An inaccurate inference is still personal information; it is also the basis for the consumer's right to correct under section 1798.106.

The downstream obligations

If the inference is personal information, the downstream obligations attach. The business must:

1. Disclose at or before collection that inferences are being created and the purposes for which they will be used. The privacy notice has to be specific enough that a consumer can understand the categories of inferences involved.
2. Honor consumer requests to know what inferences exist about the consumer, with reasonable verification.
3. Honor consumer requests to delete inferences, subject to the statutory exceptions for security, fraud detection, and limited internal use.
4. Honor consumer requests to correct inaccurate inferences. This is the harder obligation operationally because AI inferences are usually probabilistic and what 'accurate' means in that context is contested.
5. Treat the inference as personal information for purposes of sale, share, and limit-use rights. If the business sells or shares inferences with third parties (advertising platforms, data brokers), the consumer's right to opt out applies.

Cross-jurisdictional considerations

The CCPA inference rule is one data-protection regime among many. The GDPR's Article 22 on automated decision-making, the Colorado Privacy Act's profiling provisions, and the EU AI Act's risk classifications all reach similar conduct with different framings. Counsel deploying AI for inferences about consumers across jurisdictions should map the obligations against each regime, not just California. The good news is that the structural elements (notice, access, correction, opt-out) overlap substantially. The implementation differs.

For AI vendors that serve businesses subject to multiple regimes, the contract obligation is to provide sufficient information about the model and its inferences that the business can meet its compliance obligations. The vendor's first draft typically does not include this. The customer should push for explicit access to model documentation, inference categories, accuracy metrics, and operational support for consumer-request handling.

The right-to-correct problem

Section 1798.106 grants consumers the right to correct inaccurate personal information that a business maintains. For AI inferences, the application is hard. The inference is not 'inaccurate' in a determinate way; it is a probabilistic output of a model based on inputs. A consumer who disagrees with an inference (the model thinks I am a high-churn-risk customer, I disagree) has a real but unfocused complaint. The statute does not address what 'correction' means in this context.

The operational approaches I have seen:

• Allow consumers to mark inferences as disputed. The inference is not deleted, but the consumer's disagreement is recorded and downstream uses are flagged. This is consistent with the FCRA model for credit-report disputes.
• Allow consumers to submit additional information. The model can be rerun with the additional input. This treats correction as a re-inference rather than a deletion.
• Delete the inference and decline to re-run. The inference is treated as personal information and the right to delete is honored, but the business retains the right not to make a new inference if the consumer has objected.

The CPPA has not specified which approach satisfies section 1798.106. The drafting strategy: build the operational infrastructure to support multiple approaches and let the rulemaking and the agency's enforcement guidance settle which one is adequate.

What I would not assume

The CCPA's reach to AI inferences is statutorily clear. The CPPA's ADMT rulemaking is in process. Counsel should not rely on prior practice from the pre-CPRA era. The 2018 CCPA was lighter on inferences. The 2023 CPRA and the 2024-2025 ADMT rulemaking have changed the framework substantially. Deployments built on the 2019 compliance posture are not current. The audit work for AI deployments handling California data is significant and should be on counsel's annual calendar.

Operational checklist before sign-off

For counsel signing off on an inference-producing AI deployment for a California-facing business, the minimum operational artifacts I expect to see in 2026:

• A data-flow map showing every place personal information enters the model, every category of inference the model produces, and every downstream system that receives the inferences.
• A privacy notice that discloses, in plain language, that inferences are being created, the categories of inferences, the purposes for which they will be used, and any third parties with whom they are shared.
• A consumer-request runbook with documented procedures for handling access, deletion, and correction requests as applied to inferences.
• A risk assessment, in a form contemplated by the CPPA's draft ADMT regulations, that documents the model's accuracy, error patterns, disparate-impact analysis, and mitigation measures.
• A retention schedule for inferences, with a defined deletion or de-identification trigger and a documented basis for any longer retention.
• A vendor-management record covering any third-party vendor whose model produces the inferences, including the DPA, the CCPA service-provider clauses, and the operational support for consumer requests.

The artifacts above will not appear from documentation alone. The data-flow map in particular requires engineering work that should not be outsourced to a privacy team in isolation. Counsel should be in the room when the map is built; otherwise the legal posture will not match the operational reality.

Sergei Tokmakov, Esq., CA Bar #279869. This memo is attorney commentary on legal questions and is not legal advice. Reading it does not create an attorney-client relationship. Past matter outcomes depend on facts and the responding party; nothing here is a prediction of result.