California's rules on automated decisionmaking are the rare piece of AI regulation that arrives as a list of tickets rather than a policy memo. The core obligations attach on 1 January 2027. Nearly everything on the list is something somebody has to build: a notice that renders before a decision gets made, a way for a person to say no, a log detailed enough to reconstruct why the software decided what it did, and a human with the authority to overturn it.
Most teams have read a law firm summary and filed the whole thing under legal. That is how you end up in October 2026 with eleven weeks left and no plumbing.
One disclaimer before anything else, and it matters: this is a builder's read, not legal advice. Your counsel decides whether you are covered and which of your decisions count. This piece is about what engineering needs ready once they tell you.
Who this actually catches
The regulations ride on the existing CCPA definition of a business, which catches you three different ways. Any one is enough: gross annual revenue above $26,625,000 (the inflation-adjusted version of the original $25 million, in force since January 2025 and revisited every two years against CPI), or buying, selling or sharing the personal information of 100,000 or more California consumers or households in a year, or deriving 50% or more of your revenue from selling or sharing personal information.
Two traps in that. The revenue figure is generally read as total global gross revenue, not your California revenue, so a company with modest California business can clear it on the strength of everywhere else. And the other two prongs mean a company well under the revenue line can still be covered, which is the case people miss when they check only the first number and stop.
Note the geography too: what matters is where your applicants, customers and patients live, not where your office sits. A Denver company with California employees is in scope.
The definition of the technology is deliberately wide. The regs cover any technology that processes personal information and uses computation to replace, or substantially replace, human decisionmaking. Read that twice if you build internal tools. There is no threshold about model size, no carve-out for things that predate the current AI wave, and no requirement that anyone involved calls it AI. A weighted scoring sheet that ranks applicants and gets followed almost every time is squarely inside the definition. A large language model that drafts a recommendation a manager genuinely reweighs might not be.
Then there is the second filter: the decision has to be a significant one. For employers that means hiring, work assignment, compensation, promotion, demotion and termination. Outside employment the categories are the familiar ones: housing, lending and credit, healthcare, and access to education.
So the scope question is really two questions stacked. Is this tool making the call, or informing it? And is the call one of the named categories? Everything else in this article assumes you answered yes twice.
The four things you have to build
The rules give people four rights that attach on 1 January 2027: a pre-use notice, the right to opt out, the right to access information about how the technology was used on them, and the right to appeal a decision it made. Those four map onto roughly four pieces of engineering, though not one to one, because the opt-out and the appeal are partly substitutes for each other.
1. A pre-use notice that renders before the decision
Not a paragraph in the privacy policy. A notice, delivered before the technology is used on that person, that says what the tool is for, how it reaches its decisions, which categories of personal information affect the output, what the output looks like, and how that output feeds the decision. It also has to tell people they can access an explanation, opt out, and appeal.
In practice this is a versioned component keyed to a decision type, rendered at a specific moment in a flow, with a record that it was shown. The temptation is to write one notice for the whole company. Resist it. The notice has to describe the actual tool, so a generic one either says nothing useful or says something false.
2. An opt-out path, or a human appeal good enough to replace it
The rules give you two ways out of building a true opt-out, and they are different from each other.
For hiring, work assignment and compensation, you may decline an opt-out if you have verified that the tool works as intended and does not discriminate. That verification is not a vibe. It is an evaluation you have to have on file, which means somebody runs it, documents the method, and repeats it.
For the other significant decisions, the opt-out does not apply if you offer a meaningful human appeal, by which the regs mean a reviewer with real authority to reconsider the outcome.
Both roads have engineering at the end of them. Road one is an evaluation harness plus the evidence trail behind it, which is the same discipline as building an eval harness for LLM features. Road two is a queue, a reviewer role, an SLA, and a way to reverse a decision that has already propagated into other systems. That last part is the piece teams forget. Reversing a rejection is easy in the database and hard everywhere the rejection already went.
3. A decision log that can answer "why me?"
The access right is the requirement with the longest engineering tail. A person can ask what the tool was for in their case, get a description of the logic that clearly explains how their personal information was processed, see the output, and learn how it was used. Trade secrets can be withheld, but withholding them does not excuse you from giving an explanation a normal person can follow.
You cannot reconstruct this after the fact from a model and a database row. Either you captured the decision when it happened or you did not. That makes logging the one item on this list with a hard dependency on time, which is why it belongs at the top of your backlog rather than the bottom. We wrote a separate piece on what an audit trail for AI decisions needs to contain, because the shape of the log is worth its own article.
4. A place for these requests to land
Access and opt-out requests arrive through the same door as existing privacy requests, so most companies have the intake solved and the fulfilment unsolved. The gap is that a normal data request can be answered by querying tables, while an ADMT request needs a narrative about one specific decision. Somebody has to own producing that. If the answer to "who writes this" is "we will figure it out when one comes in," you have a process, not a plan.
A worked example: the résumé screener
Take a 400-person company with an applicant tracking system that scores inbound résumés. Recruiters are told to work the queue top-down and, in practice, nobody opens anything under 70.
Here is what the four builds look like for that one tool. The application form needs a notice before submission explaining that a scoring model ranks applications, what it looks at, and what rights the applicant has. Because this is hiring, the company can skip a true opt-out, but only by keeping a current evaluation showing the model does what it claims and does not skew against protected groups. Every scored application needs a log entry: the model version, the features that drove the score, the score, the threshold in force that day, and whether a human looked. And when a rejected candidate writes in nine months later asking why, someone has to be able to answer with that record in hand.
Now the failure mode. The company technically lets recruiters override the score, so leadership believes there is a human in the loop. But nobody has ever overridden it, the threshold was quietly moved from 65 to 70 in a config change with no history, and the scoring service keeps thirty days of logs. Every one of those is a mundane engineering decision. Together they mean the company cannot describe its own hiring decisions, which is the thing the rules ask it to do. The model was never the problem.
The risk assessment is an engineering document wearing a suit
Covered businesses have to run a risk assessment weighing privacy risk against benefit, across a set of prescribed factors, documented, attested by an executive, and produced within 30 days if asked. It gets refreshed at least every three years, or sooner if the processing materially changes. The stated purpose is blunt: restrict or prohibit the processing where the privacy risk to the consumer outweighs the benefits.
You need one wherever processing presents a "significant risk," which the regs spell out rather than leaving to judgement. It covers selling or sharing personal information, processing sensitive personal information, training or using ADMT for significant decisions, using biometrics for identity verification or profiling, and making automated inferences in sensitive contexts. Note the third item: training a model for these decisions triggers the requirement, not only running it.
The timing is staged, and the staging is worth putting on a whiteboard.
| Obligation | Date | Applies to |
|---|---|---|
| ADMT rights live (notice, opt-out, access, appeal) | 1 Jan 2027 | All covered businesses |
| Risk assessments for processing already running | 31 Dec 2027 | Activities predating the regs and continuing |
| First filing to the CPPA | 1 Apr 2028 | Information about 2026 and 2027 assessments |
| Cybersecurity audit due | 1 Apr 2028 | Over $100M in 2026 gross revenue |
| Cybersecurity audit due | 1 Apr 2029 | $50M to $100M |
| Cybersecurity audit due | 1 Apr 2030 | Under $50M |
Two details in that table get misread. The April 2028 filing is information about the assessments you ran, not the assessments themselves, so the deliverable is a summary rather than a document dump. And the audit tiers key off your 2026 revenue, which means the year that decides your deadline is already underway. Audit records have to be kept for at least five years, with a certification of completion going to the agency.
Legal will draft it. But the substance is yours: what data goes in, what the tool emits, which safeguards exist, and what evidence proves the safeguards are real rather than aspirational. An assessment that describes controls nobody implemented is worse than none, because now it is signed.
What to do in the next ninety days
- 1.Build the inventory. One sheet, one row per tool that touches a decision about a person. Include the spreadsheets. Most companies find between four and fifteen, and are surprised by at least two.
- 2.Pick a shape per tool. Opt-out plus manual fallback, or appeal with a reviewer who can genuinely reverse. Deciding this early changes what you build.
- 3.Turn on decision logging now. This is the only item you cannot backfill. Every month you wait is a month of decisions you will never be able to explain.
- 4.Ask counsel two questions, not twenty. Are we in scope, and which of these decisions are significant ones. Then bring engineering the answer instead of the statute.
What this means for your team
- The deadline is not really January 2027. It is whenever your logging starts, because that is the clock you cannot rewind.
- Scope creeps downward, not upward. The tools that catch you are the boring internal ones nobody thinks of as AI.
- Treat "a human reviews it" as a claim you have to prove with data, not a design you can assert. Our piece on keeping a human in the loop covers why the assertion usually fails in practice.
- Compare the shape of this with the EU AI Act's deadlines. Same direction of travel, different mechanics, and a single build can often satisfy both.
If you have a tool in scope and no idea what it logged last Tuesday, that is the honest place to start. We build the parts that have to exist inside the product: the notice, the opt-out, the decision log, the appeal path. If that is the work in front of you, tell us what you are running and we will tell you what we would build first.
Sources
- California Privacy Protection Agency: CCPA updates, risk assessments, ADMT and insurance regulations
- California Privacy Protection Agency: updated monetary thresholds
- Littler: California's final regulations on automated decisionmaking
- Thompson Coburn: California's 2026 CCPA regulations, summary and preparation guide
- Morgan Lewis: CCPA risk assessment requirements and best practices
- Ropes & Gray: California's CCPA cybersecurity audit rule takes effect