If your business uses AI on data from California residents, the CCPA applies to that AI. It covers the chatbot you bought, the model you fine-tuned, and the script someone vibe-coded over a weekend. The new California regulations add three

duties on top of the old ones: risk assessments, cybersecurity audits, and rules for automated decisionmaking technology (ADMT). Most ADMT duties start January 1, 2027, so the window to fix things quietly is closing.

This guide explains what changed, who is covered, what your AI systems have to be able to do, and where the work lands in your code. We write it as engineers who audit AI-built software for a living, not as your lawyer.

TL;DR

  • Businesses subject to the CCPA must meet the ADMT requirements by January 1, 2027 for significant decisions about California consumers.
  • Risk assessments for high-risk processing were due to begin January 1, 2026, with an attestation to the regulator by April 1, 2028.
  • Buying an AI tool does not hand off compliance. Without the right contract terms, you stay liable for what the vendor does with your data.
  • Auditable logs, human review and clean data flows are engineering work. Start with a code and infrastructure review, not a policy rewrite.

Table of Contents

Does the CCPA apply to your business?

The CCPA reaches for-profit companies doing business in California that meet at least one threshold. According to one 2026 applicability guide, the inflation-adjusted revenue test is annual gross revenue above $26.625 million, measured globally, not just in California. The other two tests are handling data of more than 100,000 California consumers or households, and earning more than half of revenue from selling or sharing personal data.

Two points catch founders out:

  • You do not need a California office. A Texas startup with a few thousand California users can still be covered if it crosses a threshold.
  • A small company can still be affected. If you are under every threshold, your enterprise customers may still push the same terms into your contract. Many will ask you to behave as if you were covered.

Whether you are covered is a legal question. Confirm it with a privacy attorney. The rest of this article assumes you are, or soon will be.

What changed for AI: three rule sets, three dates

In September 2025 the California Privacy Protection Agency announced that the Office of Administrative Law had approved regulations covering cybersecurity audits, risk assessments and ADMT. They are not abstract. Each one maps to something your team builds or runs.

Rule set What it asks of you Key date
Risk assessments Assess privacy risk before high-risk processing, including AI training uses Compliance began January 1, 2026; attestation and summary due April 1, 2028
Cybersecurity audits Annual independent audit for businesses whose data practices pose significant security risk Certification due April 1, 2028 (revenue over $100 million), April 1, 2029 ($50 to $100 million), April 1, 2030 (under $50 million)
ADMT Notice, opt-out or appeal, and access rights for automated significant decisions January 1, 2027

The audit dates above come from the agency’s 2025 annual report. The agency has also moved from writing rules to enforcing them, and its documentation, audit trail and risk assessment requirements are meant to force transparency into black-box AI decisions, per the same report.

The stakes are real. The agency cites statutory damages of $100 to $750 per consumer per incident for certain data breaches, and with AI systems that touch thousands of records, the multiplication gets ugly fast.

Which AI decisions count as “significant”?

ADMT rules focus on significant decisions: those that result in access to, or denial of, financial or lending services, housing, insurance, education, employment, healthcare, and essential goods, per the agency.

That includes more than a loan-scoring model. Think about:

  • A resume screener that ranks applicants before a human sees them.
  • A tool that flags insurance claims for denial.
  • A tenant-screening workflow that scores rental applications.
  • A support bot that decides who gets a refund on essential goods.

If an AI output meaningfully drives the decision, you are in ADMT territory even when a person clicks the final button. We see this constantly: a workflow that “has a human in it” where the human approves 99% of suggestions in two seconds each. A regulator will not call that meaningful review.

It is not only about decisions

A common misstep is assuming ADMT is the whole story. The agency’s materials make clear that risk assessment requirements also reach training of large language models and systems that generate deepfakes, establish identity, or profile biological traits. Whether you use an off-the-shelf tool or train your own, the deploying business carries the duty to assess and reduce privacy risk.

California law also now treats AI-era data as personal data in more ways. Since September 2024, sensitive personal information includes neural data, meaning information generated by measuring nervous system activity. If you build for wearables or health, that matters.

The vendor trap: “we use a SaaS tool, so we’re covered”

This is the assumption we hear most from nontechnical founders. You pay a monthly fee for an AI chatbot, a transcription tool or an analytics add-on, and you assume the vendor carries the compliance burden.

It does not work that way. According to one CCPA and AI guide, a vendor counts as a service provider only if your agreement bans three things: selling or sharing your data, using it outside the business purposes in the contract, and combining it with other datasets. Without a proper data processing addendum, you remain liable for how the vendor handles that data.

A practical vendor check:

  1. List every AI tool that touches customer, employee or applicant data. Include browser extensions and plugins your staff installed themselves.
  2. Find the signed agreement for each. If it is click-through terms, check whether a DPA exists and whether you accepted it.
  3. Confirm the three bans in writing.
  4. Ask whether your inputs train the vendor’s models, and whether you can switch that off.
  5. Record where the data goes: which regions, which subprocessors.

If a vendor cannot answer step 4 in plain language, that is your answer.

The ADMT playbook: notice, opt-out, appeal

When ADMT is used for a significant decision, the regulations expect a few things. A summary of the requirements from a compliance advisory firm describes a pre-use notice before collecting personal information for ADMT. That notice covers the specific purpose and the consumer’s right to opt out, among other items.

There is a path that avoids the mandatory opt-out. As that same source explains, you can offer an appeals process involving meaningful human review by someone with real authority to overturn the machine’s decision. Do not treat that as a checkbox. It is a redesign of the workflow:

  • The reviewer needs the inputs, the output and the reasoning the system used, in one screen.
  • The reviewer needs permission to reverse the result without escalation.
  • The appeal itself needs to be logged, with timestamps.
  • Reviewers need time. If the queue is sized so that nobody can actually look, you have built theater.

This is where “reduce staff with AI” plans run into law. If your plan is to automate a decision and remove the person, the opt-out route becomes the default, and you must build that too.

Compliance as code: what your systems need to log

Policies live in documents. Regulators ask questions that only systems can answer. One practitioner checklist describes compliance as code: binding identity, notice version, policy, prompt and output to every ADMT request, so that when an audit arrives you can query by consumer, prompt, data type and endpoint instead of reconstructing history from scattered application logs.

In engineering terms, that means:

  • Request-level traceability. Every AI call that affects a consumer carries a user ID, the version of the notice they saw, the model and prompt version, and the output.
  • Immutable, queryable logs. Not a folder of text files on one server. Retention rules matter too: log what you need as evidence, but do not hoard raw personal data in prompts forever.
  • Alerting. If a model starts sending data to an endpoint it never used before, someone should know the same day.
  • Deletion that reaches everywhere. Deletion requests have to propagate to vector stores, caches, fine-tuning datasets and backups, not just the main database.
  • Environment hygiene. Secrets out of repositories, least-privilege access, and separate staging data that is not a copy of production.

The agency’s requirements for documentation and audit trails make this the part regulators can actually test. We have written about the groundwork in our guides to data governance for AI and preparing data for AI.

A worked example: the support bot that quietly became ADMT

Imagine a home-goods retailer with a California customer base. A developer connects a large language model to the helpdesk so it can draft refund replies. Over a few months, the team lets it auto-approve small refunds and auto-deny anything its confidence score flags as suspicious.

What changed? The bot began as a drafting aid. Now it decides who gets money back. Depending on the goods involved and how much the output drives the decision, that could move toward a significant-decision question. Meanwhile:

  • The prompt includes the customer’s full name, address and order history, sent to a vendor under click-through terms.
  • Nobody recorded which prompt version was live on which date.
  • A denied customer has no appeal route besides emailing support, which gets answered by the same bot.

None of this required bad intent. It required a prototype that shipped and was never revisited. We call this the prototype trap: it works, so it stays, and nobody reviews the last mile between demo and defensible production system.

The fix is a short list: define the decision boundary, strip fields the model does not need, sign the DPA, version prompts, log every decision, and build a human appeal route with real authority.

Perspective: where we see AI privacy go wrong

We spend our days reading AI-generated and AI-assisted codebases, and the privacy problems are rarely exotic. They are boring. API keys in the repo. Customer records pasted into prompts because it was the fastest way to get a demo working. Logging that captures everything or nothing. Nobody asked the model to be non-compliant. Nobody asked it to be compliant either.

Our view is simple. Compliance is not a memo you write once. The new rules treat AI as a persistent exposure surface, so the evidence has to be generated continuously by the system itself. That is an engineering problem, and it is solvable when you catch it early and miserable when you catch it in an audit.

Perspective: where we see AI privacy go wrong — overview diagram

Two habits help most. First, minimize: if the model does not need a field, it does not get the field. For sensitive workloads, a local model that keeps data in your environment can shrink the vendor question dramatically, though it brings its own security duties. Second, keep the person real: if a human is your safeguard, design the screen, the authority and the time budget so they can actually catch mistakes.

And a note for founders who built something with AI tools and are not sure what is inside: that is common, not shameful. Get someone to look before a customer, an investor or a regulator does.

— Chad

A 60-day plan before January 1, 2027

From today (October 22, 2026), you have roughly ten weeks. A realistic sequence:

Weeks 1 to 2: inventory

Map every AI system, model, plugin and script that touches California consumer, applicant or employee data. Mark which ones feed decisions about money, housing, jobs, insurance, education, health or essential goods.

Weeks 3 to 4: contracts and data flows

Collect DPAs, confirm the three service-provider bans, and diagram where each data field travels. Cut fields the models do not need.

Weeks 5 to 7: engineering fixes

Add request-level logging, prompt versioning, alerting and deletion propagation. Fix the secrets, access and environment problems your inventory surfaced. A professional code audit of AI-built components is often the fastest way to find them, and an application security assessment covers the surrounding infrastructure.

Weeks 8 to 10: notices, appeals and documentation

Draft pre-use notices with your attorney, build the appeal route with real reviewer authority, and write down the risk assessment: the logic, assumptions and limitations, expected outputs, benefits against privacy harms, and the safeguards in place, as the agency describes in its annual report.

If your business sits in California, our California AI integration page shows how we work with teams there. In regulated sectors, the same discipline applies as in our guides for health AI and model risk management.

How Bowtie helps

We are not a law firm and we do not give legal advice. We do the engineering side: finding what your AI-built or AI-assisted software actually does with data, and fixing it.

For ongoing work, our Ship Shape Service starts at $1,850 per month and Crew Service at $2,950 per month, both described on the vibe code review page. Our AI agent and workflow automation work is quoted per project, with no published price.

FAQ

Does the CCPA apply to AI systems?

Yes. The CCPA covers personal information however it is processed, and California’s new regulations add specific rules for automated decisionmaking, risk assessments and cybersecurity audits. The agency’s materials say risk assessment duties reach LLM training and certain profiling systems too. Whether your business is covered depends on the thresholds, so confirm it with a privacy attorney.

When do the ADMT rules take effect?

Businesses must comply with the ADMT requirements for significant decisions by January 1, 2027. Risk assessment duties began January 1, 2026, and attestations and summaries are due to the agency by April 1, 2028. Cybersecurity audit certifications follow a schedule from 2028 to 2030 based on revenue.

If I use a third-party AI tool, who is responsible?

You are, unless your contract makes the vendor a true service provider. That means banning selling or sharing your data, use outside the contracted purposes, and combining it with other datasets. Get a signed DPA and keep it on file.

Can I avoid offering an opt-out for automated decisions?

Potentially, by offering an appeal with meaningful human review by someone with authority to overturn the decision. The review has to be genuine. Have your attorney confirm that your design meets the standard.

Is a vibe-coded app a compliance risk?

It can be. AI-generated code often works but skips logging, access controls and data minimization, which are the things audits ask about. A code review before launch or before January 2027 is cheap compared with fixing it under pressure.

Sources