What makes an AI vendor a service provider under the CCPA?

Two things together: a written contract containing the required restrictions, and actual conduct consistent with them. The contract must prohibit the recipient from selling or sharing the personal information, from retaining, using or disclosing it for any purpose other than the specified business purposes, from using it outside the direct business relationship, and from combining it with personal information received from other sources — with narrow exceptions. A vendor that signs that paper and then trains a general model on your data is not a service provider, whatever the agreement is titled.

Does letting an AI vendor use our data to improve their model break service provider status?

Improving the vendor's own general product for the benefit of its other customers is use for the vendor's own purpose, not for your specified business purpose, so it falls outside the service provider restrictions. The narrow permitted case is building or improving the quality of the services the vendor provides to you, which does not extend to a model shipped to everyone else. If the improvement is customer-specific and stays customer-specific, the analysis is different from a shared general model — and the contract has to say which one you bought.

If the vendor is not a service provider, have we sold personal information?

Possibly. A sale is a disclosure to a third party for monetary or other valuable consideration. Where the consideration is the vendor getting training data — value flowing back for something other than the contracted service — the disclosure can meet that definition even though you were the one paying. Where the use is cross-context behavioural advertising, it is a share regardless of consideration. Either classification pulls in an opt-out right, a Do Not Sell or Share link, honoring the Global Privacy Control, and disclosure in your privacy policy.

Are model weights personal information?

The safer working assumption for compliance purposes is that a model trained on identifiable data may retain information about the individuals in that data, and that deletion from a source table is not deletion from a model. That does not resolve every legal question, but it changes the contract you should want: rather than debating the ontology of weights, require that personal information is not used for training at all unless you have specifically enabled it, and require a documented process for what happens on a deletion request if it is.

What do we actually have to do to check this?

For each AI tool that touches personal information, answer four questions in writing: does the contract contain the required restrictions, is training on customer data on or off by default, is data combined across customers, and how long are prompts and outputs retained and who can read them. The answers come from the contract and the technical documentation, not from the sales team. Any tool where a question cannot be answered from a document is the tool you investigate first.

Your AI Tool Is Probably Not a Service Provider Under CCPA

Why This Is the First Question, Not a Detail

Almost every downstream CCPA obligation for an AI deployment hangs off one binary. If the vendor is a service provider or contractor, the disclosure to it is not a sale or a share, it does not trigger an opt-out, and the vendor is contractually bound to help you answer consumer requests. If it is a third party, the same data flow becomes a disclosure you have to disclose, with a consumer right to stop it.

Businesses tend to resolve this by looking at what the contract is called. The statute resolves it by looking at what the recipient is permitted to do and actually does. Those two methods produce different answers surprisingly often in AI procurement, because the product behaviours that create vendor value — learning from usage, improving a shared model, retaining interaction histories — are exactly the behaviours the restrictions prohibit.

The Four Restrictions, Read Against an AI Product

No selling or sharing. Straightforward on its face and usually satisfied. Watch for vendors whose own analytics or advertising stack sits inside the product surface, because the sub-processor list is where this restriction quietly fails.
No retaining, using, or disclosing for any purpose other than the specified business purposes. This is the clause model improvement collides with. "We use customer data to make the product better" is a purpose of the vendor's, and a purpose of the vendor's is not one of your specified business purposes.
No use outside the direct business relationship. A benchmark suite built from customer prompts, a public case study containing real records, or a support corpus reused for another account all land here.
No combining with personal information from other sources. Multi-tenant AI products combine by design. Combination is permitted only in narrow circumstances, and a shared embedding index built across customers is not obviously one of them.

Read those four together and a pattern appears: the restrictions describe a vendor that processes your data, for you, and gets nothing out of it except the fee. Many AI tools are not that. That is not a scandal — it is a classification, and the classification has consequences you can plan for once you admit it.

The Three Behaviours That Break It

1. Training on customer data for a general model

The permitted case is improving the quality of the services provided to you. A general model shipped to every customer is a different artefact. The test that matters commercially is whether the improvement can be turned off per-customer and whether it is off by default for enterprise plans — and whether the default for your plan is documented anywhere other than a blog post the vendor can edit.

2. Combining across customers

Shared retrieval indexes, cross-tenant fraud signals, and aggregated behavioural baselines all combine personal information received from one business with personal information received from others. Vendors frequently describe this as aggregate or anonymised. Whether it is depends on the CCPA's de-identification standard, which is stricter than the engineering sense of the word and carries its own obligations to maintain the state.

3. Retaining prompts and outputs for the vendor's own use

Prompt and output logs are the highest-value asset an AI vendor accumulates and the least discussed part of the contract. Ask three questions: how long, who can read them, and are they used for anything other than serving you. A thirty-day abuse-monitoring window read only on incident is a defensible business purpose. An indefinite retention feeding an internal evaluation set is not one of your purposes at all, and it is also the thing that makes a deletion request impossible to fulfil honestly.

What Changes If the Answer Is "Third Party"

Reclassification is not a catastrophe; it is a different compliance posture, and it is workable if you do it deliberately rather than discovering it during an inquiry.

Disclose it. The categories of personal information disclosed, sold, or shared and the categories of recipients go in the notice at collection and the privacy policy.
Offer the opt-out. A Do Not Sell or Share My Personal Information mechanism, and processing of opt-out preference signals including the Global Privacy Control.
Suppress downstream. An opt-out is only real if the data flow actually stops for that consumer — which means the vendor integration needs a per-consumer suppression path, and most do not have one built.
Fix the contract anyway. Disclosures to third parties still require contractual terms about the limited purpose and compliance obligations. Third party is not a contract-free category.
Re-check sensitive categories. If the data includes sensitive personal information, the limit-use right sits on top of everything above.

The Classification Worksheet

One row per AI tool that receives personal information. Six columns, and every cell must cite a document rather than a conversation.

Tool and data categories — what it is and what reaches it, including free-text fields nobody classified.
Contract clause — the specific section number containing the four restrictions, or blank.
Training default — on, off, or contractually prohibited; and where that is written.
Combination — does the product combine across customers, in any subsystem, including safety and abuse tooling.
Retention — prompts, outputs, and logs, with the period and the internal access rule.
Conclusion — service provider, contractor, or third party, with the date and the person who decided.

Most organisations running this for the first time find two or three tools that everyone assumed were service providers and are not, and at least one tool nobody had on the register because it was bought on a card. The second finding is usually the more expensive one, and it is also the one a standing procurement questionnaire prevents from recurring.

Frequently Asked Questions

Our vendor's DPA says they are a service provider. Isn't that enough?

The contract is necessary and not sufficient. The statutory structure requires both the terms and conduct consistent with them, and a recipient that uses the information outside the permitted purposes is not a service provider with respect to that use no matter what the agreement recites. Where the product documentation and the DPA disagree, the documentation is describing what the software does, and the software is the thing an enforcement question will examine.

Is paying the vendor 'consideration' that makes this a sale?

Money flowing from you to them is payment for a service, not consideration flowing to you. The sale question arises when value flows back the other way — most commonly the vendor obtaining data it can use to build its own product. That is why the model-training clause is load-bearing: it is frequently the entire basis on which a disclosure could be characterised as a sale.

What about internal AI features built on a foundation model API?

Same analysis, one layer down. The API provider is a recipient of personal information whenever personal information appears in a prompt, and the relevant facts are the enterprise terms, the training default for that tier, and the retention window for prompts and completions. Teams building internally often never run this check because it feels like infrastructure rather than a vendor disclosure.

Does an employee-facing tool count?

Yes. California employee and applicant data is within scope of the CCPA, so an internal productivity or HR tool that receives employee personal information raises exactly the same classification question as a customer-facing one. Internal tools also tend to have the weakest contracts, because they were procured as software rather than as data processing.

How often should the worksheet be re-run?

At every renewal, and on any vendor announcement that changes data handling — a new AI feature, a new sub-processor, a changed default. Vendors ship model-training changes as product news rather than as contract amendments, so the trigger for review has to be your calendar and your monitoring of their release notes, not their legal team's notice obligations.

Run It on Three Tools This Week

Do not start with a full inventory — start with the three AI tools that touch the most personal information, and fill six cells each from documents. The exercise takes an afternoon and produces a defensible answer to the question every CCPA inquiry opens with: who did you give it to, and on what terms.

Where a cell cannot be filled, you have found the real finding. A vendor that will not put its training default and retention period in writing has told you the answer.