CCPA AI Risk Assessment: The CPPA Workflow for ADMT and LLM Processing
The CPPA risk-assessment regulations require covered businesses to assess specified processing before it starts, compare privacy risks with benefits, document operational facts and safeguards, involve relevant employees, and update the assessment after material change. AI teams need to separate the broad risk triggers from the narrower ADMT rules, then connect each approved safeguard to a test and operating record.

The California Privacy Protection Agency made risk assessment a before-launch control. A covered business first identifies a processing activity in section 7150, then documents its purpose and data. It also records operations and benefits, along with negative impacts and safeguards, before starting the activity. A score added to a procurement ticket after launch misses the sequence.
I prefer a marked-up request trace over a red-and-amber heat map. The trace forces privacy and product teams to agree with security and engineering on what the model actually receives.
TL;DR
- The CPPA rules require a risk assessment before covered processing starts, including sensitive-data processing and ADMT used for a significant decision.
- The report must describe purpose and data categories, operational elements and benefits, negative impacts and safeguards, and the final go-or-stop decision.
- Employees involved in the processing must participate. External experts and affected stakeholders may contribute.
- Review occurs at least every three years, with an update within 45 calendar days after a material change.
- Assessments completed in 2026 and 2027 feed the first CPPA submission due April 1, 2028.
Scope starts with the processing trigger
The CPPA's approved regulation text lists the activities that present significant risk to consumers' privacy. Section 7150 covers sale or sharing. It also covers sensitive-data processing subject to a narrow employment-administration exception, plus ADMT for a significant decision. Specified profiling and personal information used to train defined technologies create additional triggers.
An LLM can enter scope through several routes. A benefits chatbot may process health information. A hiring workflow may use model output to decide who advances. A training pipeline may use personal information to train ADMT intended for significant decisions. A vendor classification such as "copilot" settles none of these questions.
Create one scoping record per use case. Name the business and affected consumers, purpose and personal-information categories, model route and output, and downstream action and applicable section 7150 trigger. Link the conclusion to the product owner and approval date. The CCPA controls mapping then connects each triggered duty to an operating control.
ADMT is narrower than the full risk-assessment scope
The regulations define ADMT as technology that processes personal information and uses computation to replace or substantially replace human decisionmaking. Substantial replacement exists when the business uses the output to make a decision without qualifying human involvement. The reviewer must know how to interpret the output and review relevant information. The reviewer must also have authority to make or change the decision.
A significant decision results in the provision or denial of financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services.
This definition creates a clean fork. A summarization tool processing sensitive personal information may require a risk assessment under section 7150 while sitting outside Article 11's significant-decision ADMT duties. A loan-decision model can trigger both. Keep those findings separate, because the risk-assessment triggers are broader than the ADMT consumer-rights package.
The California AI law guide places this CPPA regime beside California's developer and content-transparency statutes.
The report follows the actual data flow
Section 7152 requires a specific purpose rather than a generic phrase such as improving services. It then requires the personal-information categories, including sensitive categories, and the minimum information necessary to achieve that purpose.
The operational description carries much of the assessment's value. Describe collection and use, plus disclosure and retention. Identify the sources. Add the way the business interacts with people and the approximate population. Record the disclosures those people receive. Name the service providers and every other recipient, including contractors or third parties. For ADMT used in a significant decision, the report also identifies the logic and its assumptions or limitations, the output, and how the business uses that output.
Draw one request on the page. Show the authenticated caller at the left and the application assembling context. Then show the model endpoint and returned output, followed by the human or system acting on it. Mark every retained copy with its owner and retention rule. That picture usually finds a provider log or evaluation store absent from the original inventory.
Benefits and negative impacts need evidence
The assessment compares privacy risks with benefits to consumers and the business. It also considers other stakeholders and the public. Section 7152 rejects generic benefits. State the measurable operational outcome and identify who receives it.
Negative impacts include unauthorized access or disclosure and discrimination. They also include impaired consumer control. The list reaches economic and physical injury. It also covers damage to reputation and psychological wellbeing. For an LLM use, add the mechanism behind each impact. A prompt may disclose health data to an unapproved endpoint. An inaccurate output may influence a compensation decision. A broad context window may exceed the minimum data needed for the stated purpose.
Record likelihood and magnitude, along with the affected population and evidence. Link the impact to a source-flow step and an owner. The regulations ask the business to restrict or prohibit processing when privacy risks outweigh benefits. My view is blunt: an assessment that cannot produce a rejected use or a narrowed design is probably a product description with a risk score attached.
Safeguards become credible through tests
Section 7152 requires the planned safeguards. The regulation names encryption and segmentation as examples. It also names logical access controls and change management, along with monitoring and data-integrity measures. The assessment should explain which negative impact each safeguard addresses and where the safeguard operates.
For model traffic, test the control rather than restating a policy. Send a seeded sensitive-data payload to an approved route and verify its classification. Attempt the same payload against a prohibited endpoint and preserve the refusal. Exercise the ADMT opt-out path through submission and enforcement. Confirm that an authorized human reviewer can inspect the relevant information and change the result. Query the record by consumer and timestamp.
The CCPA audit-evidence guide describes the artifacts. A useful assessment links each safeguard to a control owner and test case. It records the expected result and latest evidence, along with residual risk and the approver. Keep the failed tests beside the remediation plan. Green cells supported only by policy text hide the work still open.
Stakeholder approval and vendor inputs
Section 7151 requires employees whose duties include participating in the covered processing to join the assessment process. That means the engineer who constructs prompts and the product owner who defines the decision contribute facts. The privacy lead interpreting the consumer impact contributes too. The business may also include service providers and contractors, bias experts and consumers, or advocacy groups.
Vendor documentation supplies model limitations and retention terms. It also supplies security controls and subprocessor facts. It remains one input among the operational records and business decisions. The business still decides the purpose and data minimum. It also decides the consumer disclosure and significant-decision use, plus safeguards in its own environment.
End the report with a named person who has authority to participate in deciding whether processing begins. Preserve the approved version and the rejected alternatives. One situational detail helps here: put the approval date beside the production change ticket, rather than leaving it buried on slide 47 of a privacy deck.
Timing, updates, retention, and CPPA submission
The CPPA rulemaking page confirms the regulations took effect on January 1, 2026. Section 7155 requires the assessment before covered processing begins. Continuing activities that started before the regulations' January 1, 2026 effective date must be assessed by December 31, 2027. Reviews occur at least once every three years.
A material change requires an update as soon as feasibly possible and within 45 calendar days. The regulation describes changes that create new impacts or weaken safeguards. It also covers changes that increase the likelihood or magnitude of impacts. A new purpose or broader data set should enter the change-control screen. So should a different model destination or longer retention period. A new decision use belongs in the screen as well.
Risk assessments remain retained while processing continues or for five years after completion, whichever is later. Section 7157 requires the first submission of prescribed summary information for assessments conducted in 2026 and 2027 by April 1, 2028. The Agency or Attorney General may request the reports themselves, with a 30-calendar-day production period in the regulation.
DeepInspect
DeepInspect can implement and evidence technical safeguards on deliberately routed HTTP traffic between authenticated users or agents and LLM endpoints. It evaluates application-supplied identity and role together with content classification. It also evaluates the destination and model authorization against organizational policy before forwarding a request.
Its per-decision record can show that a prohibited data class was blocked or that an approved request used the policy version accepted in the assessment. Purpose definition and stakeholder involvement remain with the business. So do benefit analysis and consumer notice. The business also retains human review, residual-risk acceptance, and CPPA submission. Local processing and browser sessions sit outside its evidence boundary. Model traffic that bypasses the proxy does too.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does every LLM deployment require a CPPA risk assessment?
Scope turns on section 7150 processing. Common triggers include sensitive personal information and sale or sharing. They also include ADMT used for a significant decision, specified profiling, and personal information used to train defined technologies. A drafting assistant using synthetic data may sit outside those triggers. A clinical assistant processing health information can trigger an assessment even when it makes no significant decision.
- Can one assessment cover several model uses?
Section 7156 permits one assessment for a comparable set of processing activities presenting similar risks. The shared assessment still has to contain every required fact. Customer support and employee monitoring often differ from lending decisions. Their purposes and affected people may differ, as may their data, outputs, and impact. Keep use-case annexes under a shared infrastructure section when those differences matter.
- Can an existing DPIA satisfy the California requirement?
The regulations allow a risk assessment prepared for another purpose when it contains the section 7152 information or is paired with the missing information. Perform a field-level crosswalk against every required California element before approval. Add California-specific operational elements and submission fields, including decision authority, rather than renaming the existing document.