How to Draft a California AI Policy That Complies With the CPRA and Protects Trade Secrets
California businesses using AI must comply with the CPRA’s notice, purpose-limitation, and vendor-contract rules—especially when AI touches personal information and sensitive personal information. In practice, the highest risk comes from training, prompting, and sharing data with AI vendors in ways that expand “use” and “disclosure” beyond what was disclosed to consumers and employees. This article explains how to draft a California AI policy that aligns with CPRA obligations while preserving trade-secret protections in your models, prompts, and datasets.
Why California AI policies now have to be “privacy-and-trade-secret” documents
For California organizations, an internal AI policy is no longer just an HR guideline about acceptable tools. When AI systems ingest, generate, or route personal information, the policy becomes a compliance control under the California Consumer Privacy Act as amended by the California Privacy Rights Act (CPRA), enforced by the California Privacy Protection Agency (CPPA) and the California Attorney General. At the same time, AI workflows can quietly leak competitive information—training data, proprietary code, customer lists, pricing models, product roadmaps, and even “prompt libraries” can qualify as protectable trade secrets if handled correctly.
A well-drafted California AI policy therefore needs to do two things at once:
(1) CPRA alignment—tie AI use to disclosed purposes, define when personal information (PI) or sensitive personal information (SPI) can be processed, and impose vendor/contract guardrails; and
(2) Trade-secret preservation—impose reasonable secrecy measures (access limits, labeling, logging, contractual restrictions, and incident response) so proprietary AI assets remain protectable under California’s Uniform Trade Secrets Act (CUTSA).
Step 1: Define scope, ownership, and what counts as “AI” in your organization
Start with definitions and scope because CPRA and trade-secret controls depend on consistent classification.
Recommended policy definitions
“AI Tools”: Include generative AI (chatbots, copilots), ML analytics, OCR/vision, and automated decision tools used for HR, marketing, fraud, or customer support.
“AI Inputs”: Prompts, uploaded files, chat transcripts, logs, code snippets, tickets, emails, images, and datasets.
“AI Outputs”: Generated text, code, summaries, recommendations, embeddings, and model artifacts.
“Personal Information” / “Sensitive Personal Information”: Cross-reference your CPRA definitions and examples relevant to your business (e.g., IDs, precise geolocation, account logins, health/biometric data, union membership).
“Confidential Information”: Align with your confidentiality policy and explicitly include model weights (if internal), prompt libraries, customer lists, pricing, roadmaps, nonpublic financials, security details, and proprietary datasets.
Assign program ownership
Designate an AI Governance Owner (often legal/privacy, security, or compliance) and require cross-functional review (privacy + security + procurement + HR). Specify that any new AI tool or new AI use case must be reviewed before production use.
Step 2: Map AI use cases to CPRA purposes, notices, and data categories
CPRA compliance starts with aligning processing activities to disclosed purposes and limiting secondary use. Your AI policy should require a lightweight “AI intake” that maps:
Use case (e.g., summarizing support tickets; drafting marketing copy; screening resumes)
Data categories (PI/SPI? employee vs consumer? minors?)
Purpose (e.g., customer support operations; security; product improvement)
Disclosure (which vendors/subprocessors receive it)
Retention (how long prompts/logs are stored)
Human review (especially for HR or other high-impact decisions)
Trade-secret sensitivity (does it expose proprietary strategy, code, or datasets?)
Example: If employees paste customer emails into a public chatbot to draft responses, you’ve created a new disclosure channel and possibly a new purpose. A compliant AI policy should prohibit that unless (a) the tool is approved, (b) vendor terms prevent training on your data, (c) the privacy notice covers this processing, and (d) you’ve implemented redaction/minimization.
Step 3: Build CPRA guardrails into day-to-day AI use (what employees can and cannot do)
Most AI risk arises from unmanaged employee behavior. Your policy should be specific and operational.
Prohibit or restrict high-risk inputs
At a minimum, prohibit entering the following into non-approved AI tools, and restrict even approved tools unless necessary:
SPI (e.g., SSNs, driver’s license numbers, precise geolocation, health data, biometrics, log-in credentials)
Authentication secrets (API keys, passwords, private keys)
Nonpublic customer lists and pricing
Source code or security architecture unless tool is approved for secure code handling
Protected HR data (performance reviews, discipline, accommodation info)
Require data minimization and redaction
CPRA embeds a principle of limiting collection, use, and retention to what is reasonably necessary and proportionate for disclosed purposes. Translate that into employee rules:
Use placeholders (e.g., “Customer A”), remove direct identifiers, and paste only the excerpt needed. Where feasible, route content through internal tools that tokenize or redact before it reaches the model.
Address accuracy, bias, and human oversight
Even when privacy is managed, AI outputs can cause legal exposure (false statements, discrimination, misleading advertising). Require:
Human review for customer communications, HR actions, and legal/financial statements
Citations or source-checking for factual claims
No automated adverse employment decisions without legal review and documented validation
Step 4: Control “training,” “fine-tuning,” and prompt logging—where CPRA and trade secrets collide
The most common CPRA mistake is allowing vendors to use business data to train or improve their models. The most common trade-secret mistake is failing to impose reasonable secrecy measures around proprietary datasets and prompt libraries.
Policy rule: no training on business data without written approval
Your policy should state:
Default: AI vendors may not use company inputs/outputs to train, fine-tune, or improve models (including “product improvement” or “service analytics”) unless expressly approved by legal/privacy and memorialized in the contract.
Exception process: If you deliberately train on internal data (e.g., a private support bot), require an assessment documenting (a) data categories, (b) purpose alignment with notices, (c) retention, (d) access controls, and (e) deletion capability.
Prompt and chat retention limits
Many tools store prompts and chat logs. Your policy should require:
Retention set to the shortest practical period;
Role-based access to logs;
Export controls and encryption; and
A documented deletion process to honor CPRA deletion requests when applicable.
Step 5: Draft vendor and contractor requirements that satisfy CPRA and protect secrets
CPRA compliance often hinges on how you contract with AI providers. Your AI policy should require procurement to route AI tools through a standard checklist and contract addendum.
Key CPRA-aligned vendor terms to require
Use limitation: Vendor processes PI only for specified business purposes and only on documented instructions.
No “sale” or “sharing”: Contract should forbid selling or sharing PI (including for cross-context behavioral advertising) and restrict downstream disclosures.
Subprocessor controls: List subprocessors or require notice and the ability to object.
Security measures: Administrative/technical safeguards appropriate to the data; breach notification timelines; audit rights or assurance reports (e.g., SOC 2).
Assistance with consumer requests: Vendor must support access, deletion, correction, and limitation of use of SPI where applicable to your role and processing.
Data return/deletion: At termination and upon request; include backup deletion timelines.
Trade-secret and IP terms that matter in AI contracts
Confidentiality scope: Explicitly include prompts, outputs, embeddings, fine-tuning data, and usage analytics.
Non-training covenant: Express prohibition on using your data to train any model not exclusively for you.
Output ownership / license clarity: Address whether you own outputs, whether vendor can reuse them, and whether outputs may contain third-party content.
Restrictions on reverse engineering: If you provide proprietary models or weights, prohibit extraction and model-stealing techniques.
Step 6: Address CPRA notices, employee privacy, and internal transparency
An AI policy should not replace your CPRA notices, but it must align with them. Include a section requiring periodic review of:
Consumer privacy notice: Does it disclose AI-related purposes and categories of PI collected and disclosed? Does it accurately describe analytics, profiling, and service providers?
Employee/privacy at work notices: If AI tools monitor productivity, analyze communications, or assist with hiring/performance, ensure the employee notice covers those categories and purposes.
“Do Not Sell or Share”: If any AI-related data flows could be construed as “sharing” for cross-context behavioral advertising, route through privacy counsel.
Sensitive PI limitation: If you use SPI, confirm whether you must offer and honor limitation rights and ensure policy prohibits unnecessary SPI processing.
Step 7: Put trade-secret “reasonable measures” directly into the AI policy
Trade-secret protection depends on whether the business took reasonable steps to maintain secrecy.





















