Filter by Category

How to Draft AI Vendor Contracts in California to Comply With the CPRA and Protect Attorney-Client Privilege

California attorneys using AI vendors must contract around CPRA “service provider/contractor” rules and privilege safeguards—missing just one required restriction can trigger “sale/share” risk. With the CPRA fully enforceable and sensitive PI rules tightening, AI workflows can create hidden disclosure and secondary-use exposure. This article explains the key CPRA clauses, privilege-preserving terms, and negotiation checklist for AI vendor agreements in California.

Why AI Vendor Contracts Are Now a California Ethics and Privacy Issue

AI tools can streamline document review, e-discovery, intake, and knowledge management—but vendor contracts often assume a consumer-tech model: broad reuse rights, permissive subcontracting, indefinite retention, and “improve our services” language that conflicts with California privacy law and the confidentiality expectations embedded in legal practice.

In California, the California Privacy Rights Act (CPRA) (codified in the California Consumer Privacy Act, as amended) is the centerpiece statute governing personal information. If your firm provides personal information to an AI vendor without the right contractual restrictions, that disclosure can be characterized as a “sale” or “sharing” (depending on the circumstances), or can trigger duties around sensitive personal information, retention, and security. Separately, privilege can be jeopardized when client information is used for vendor model training, disclosed to third parties, or accessed by people outside the privileged circle.

Well-drafted AI vendor contracts serve three goals at once: (1) preserve CPRA “service provider” or “contractor” status, (2) prevent the vendor from using your data to train or improve their models outside your engagement, and (3) protect attorney-client privilege and work product through confidentiality, access controls, and defensible incident response.

CPRA Vendor Classification: “Service Provider” vs. “Contractor” vs. “Third Party”

Under the CPRA, how you contract with the AI vendor heavily influences the legal characterization of the disclosure.

Why classification matters

If the vendor is a properly contracted service provider or contractor, the disclosure of personal information for specified business purposes is less likely to be treated as a “sale” or “sharing,” and the vendor’s use of the data is limited. If the vendor is a third party, the firm may face additional notice/opt-out obligations and greater downstream compliance risk.

Contractor vs. service provider in practice

Both concepts require contractual restrictions on the vendor’s use, retention, and disclosure of personal information. A “contractor” arrangement often includes additional structure around combining data, cross-context behavioral advertising limitations, and cooperation with compliance obligations. In AI contracts, either can work, but only if your agreement includes the CPRA-required limits and audit/verification rights in substance.

Core CPRA Contract Clauses for AI Vendors (With Practical Drafting Notes)

CPRA compliance is not achieved with a generic confidentiality clause. Your AI vendor contract should function like a tailored data processing agreement (DPA) plus privilege safeguards. Below are core provisions to include and how they typically fail in AI SaaS templates.

1) Purpose limitation: “Business purpose only” and no secondary use

What to require: The vendor may process personal information only to provide the contracted services (the “business purpose”) and for no other purpose.

Common red flag: “We may use your content to improve our services” or “for product development.” In an AI context, this can include model training, fine-tuning, evaluation datasets, or sharing with affiliates.

Drafting approach: Define “Services” narrowly and expressly prohibit: (a) training foundation models on your data, (b) using your data to develop or improve models for other customers, and (c) using your prompts/outputs as generalized training data.

2) No “sale” or “sharing” and no cross-context advertising

What to require: The vendor must not sell or share personal information, retain/use/disclose it for any purpose other than the services, or for cross-context behavioral advertising.

Practice tip: Even if your firm doesn’t run ads, the prohibition still matters. Some vendors monetize telemetry, usage analytics, or “de-identified” datasets that could be argued to be personal information depending on reidentification risk and statutory definitions.

3) Explicit limits on combining data

What to require: Contractually restrict the vendor from combining personal information received from your firm with personal information from other sources except as permitted under CPRA for narrow business purposes.

Why this is crucial for AI: “Combining” is effectively what many AI improvement pipelines do—mixing customer prompts, output logs, and feedback into broader training/evaluation sets.

4) Subprocessors: approval, flow-down terms, and location control

What to require: Written authorization for subprocessors (at least via an updated list with notice and a right to object), plus contractual flow-down of the same CPRA and confidentiality duties.

Negotiation point: Require disclosure of where data is stored/processed, whether any human reviewers can access it, and whether any subprocessors provide annotation, QA, or model evaluation services.

5) Security obligations aligned to the risk (and to legal practice reality)

What to require: “Reasonable security procedures and practices” appropriate to the nature of the information—operationalized through a security exhibit (e.g., encryption in transit/at rest, role-based access controls, logging, vulnerability management, and secure SDLC).

Example clause concept: Vendor will maintain a written information security program, conduct regular penetration testing, and provide SOC 2 Type II or equivalent assurance on request.

6) Assistance with consumer requests and compliance cooperation

What to require: Vendor must assist with CPRA obligations, including responding to requests to know/delete/correct and limiting the use of sensitive personal information where applicable.

AI-specific detail: Include a mechanism to search and delete customer content from logs, prompt histories, and derived datasets—especially if the vendor stores conversation transcripts.

7) Retention limits and deletion/return at termination

What to require: Retention limited to what is necessary for the services; deletion or return upon request/termination; and deletion from backups within a defined period.

Common failure: “We may retain data for as long as necessary to comply with legal obligations” without bounding what that means, or “indefinite” retention for analytics.

8) Audit/verification rights (practical versions)

What to require: A right to verify compliance—often satisfied with (a) annual SOC 2 reports, (b) security questionnaires, (c) summaries of independent audits, and (d) the ability to audit in the event of a material incident or suspected breach.

Tip: Vendors resist broad audits; propose a tiered approach: paper audits annually, on-site audits only for cause.

Privilege and Work Product: Contracting to Avoid Waiver and Unintended Disclosure

CPRA compliance does not automatically preserve privilege. Privilege risk arises when client communications or attorney work product are disclosed to a third party in a manner inconsistent with confidentiality—or when humans outside the privileged relationship can access the substance of those materials.

1) Confidentiality that expressly covers prompts, outputs, and metadata

Define “Confidential Information” to include: (a) all prompts, files, and uploads; (b) outputs; (c) usage logs and metadata that could reveal client strategies; and (d) any embeddings or derived representations. Vendors often treat “Customer Content” narrowly and exclude “usage data,” which can still be sensitive in litigation.

2) No human review without authorization

If the vendor uses human reviewers for safety, debugging, or quality assurance, require: (a) explicit opt-in, (b) role-based restrictions, (c) confidentiality training, and (d) reviewer location controls. For legal practice, default should be no human access unless the firm consents for a documented support ticket.

3) Model training prohibition (and define training broadly)

Privilege protection often hinges on ensuring the vendor is not using client-related inputs to improve general models. Draft “Training” to include fine-tuning, reinforcement learning from human feedback, evaluation datasets, red-teaming datasets, prompt caching for future responses, and any “improve our services” use not strictly necessary to provide your instance of the service.

4) Segregation and tenant isolation

Require logical segregation of your firm’s data, tenant isolation controls, and restrictions preventing outputs from being influenced by other customers’ confidential data. Where available, negotiate for a dedicated tenant or enterprise environment.

5) Incident response that accounts for litigation realities

Include: (a) rapid notice obligations, (b) cooperation and forensic support, (c) preservation of evidence, (d) limitations on vendor communications about the incident, and (e) defined responsibility for notification costs when the vendor is at fault. For attorneys, also require that incident communications be treated as confidential and, where appropriate, subject to common interest or similar protections.

High-Risk AI Use Cases and How to Contract Around Them

Different AI workflows carry different risk. Draft to the actual use case instead of relying on a one-size-fits-all DPA.

Client intake chatbots

Risk: Collection of sensitive personal information and potential inadvertent attorney-client relationship signals; storing transcripts indefinitely.

Contract focus: Retention limits; no training; clear subprocessor list; transcript deletion; security; and prohibitions on using conversation data for analytics beyond providing the tool.