CCPA ADMT Rules: What the January 2027 Automated-Decision Duties Require You to Build

California’s finalised automated-decision rules are not a disclosure exercise. They require consumer-facing machinery — notice, an opt-out route and an access response — wired into decision flows that, in most stacks, do not currently know they are making a decision at all.

The California Privacy Protection Agency finalised its regulations on automated decisionmaking technology, risk assessments and cybersecurity audits in 2025; they were approved by the Office of Administrative Law on 23 September 2025 and took effect on 1 January 2026. The part that matters for anyone running models against Californians has a later clock. The substantive ADMT duties — pre-use notice, the right to opt out, the right to access — apply from 1 January 2027 for uses already running, and immediately for any new use started after that date. That is the date to plan against, and it is closer than the phrasing of a privacy alert makes it feel.

Most of what is written about this treats it as a compliance-policy update. It is not. It is a set of product features you have to ship, on a fixed date, into systems that were never designed to expose them.

What actually falls in scope

The regulations define ADMT as technology that processes personal information and uses computation to replace or substantially replace human decisionmaking. The trigger for the consumer rights is narrower than the definition: the duties bite when ADMT is used to make a significant decision about a consumer. A significant decision is one that results in the provision or denial of financial or lending services, housing, education enrolment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services.

That list is the whole game. It tells you the scope is not “all our AI” and it is not “anything with a model in it”. Targeted advertising alone does not qualify. A recommendation engine surfacing products does not qualify. A credit-decisioning model, an automated tenant-screening step, a resume-ranking or candidate-scoring tool, an algorithmic pricing of a loan — those are squarely in. The first piece of work is therefore not legal. It is an inventory question: which of our automated processes produce, or materially drive, one of those enumerated outcomes for a person in California.

Most firms cannot answer that today, because their systems are catalogued by application and data flow, not by whether the output is a significant decision under a Californian definition. If you have already built a model register for the EU AI Act, you are part-way there — but the axis is different. The AI Act sorts by risk tier and system role; the CCPA sorts by decision outcome. The inventory schema that maps to the AI Act risk tiers gives you the structure; you need to add a field that flags whether a given system touches an enumerated significant-decision category, because that flag, not the risk tier, is what pulls the CCPA duties in.

The three things you have to build

1. The pre-use notice. Before you use ADMT to make a significant decision, you have to give the consumer a plain notice: the specific purpose, that they can opt out and how, that they can request access, a description of how the technology works and what feeds its output, and details of any alternative process. This is not a line in the privacy policy. It has to be presented at, or before, the point of the decision, in a way the consumer will actually encounter. That means UI work in the flow itself — the loan application, the job portal, the tenancy form — not a footer link.

2. The opt-out. The consumer can decline having the significant decision made by ADMT. You must offer at least two methods to opt out, and one of them has to match your primary channel of interaction with that consumer. Then the hard part: an opt-out is worthless without somewhere for the request to go. Opting out means the decision is routed to a genuine alternative — commonly human review with real authority to reach a different outcome. Building the button is a fortnight of front-end work. Building the human-decision pathway behind it, staffing it, and defining its service level is the actual programme.

3. The access response. On request, you must explain — in plain language — the purpose of the processing, the logic and key parameters the technology used, the outcome, and how the output affected the decision about that specific person. Trade secrets and security-sensitive detail can be withheld, but the explanation still has to be meaningful. This is a generation problem: to answer it at volume, the decision system has to log, per decision, the inputs that mattered and the output it produced, in a form you can render back to a consumer months later. If your model does not persist that today, retrofitting it is the single most expensive item on this list.

There are exceptions, and they are narrow

The opt-out is not absolute. The rules carve out limited situations — for example where the automated step supports an appeal that a human with authority will decide, and certain security, fraud-prevention and safety uses. There are specific accommodations around some hiring and admissions contexts that meet defined criteria. The mistake is to reach for these exceptions first and design the whole system around avoiding the opt-out. The exceptions are defensible edges, not a scope-out. Assume the default duties apply, build the machinery, and treat the carve-outs as a documented reason a particular flow is exempt — with the evidence to support it.

Why the lead time is tight

Three of these workstreams are not policy-team work. The inventory needs engineering to confirm what a system actually outputs. The pre-use notice needs product to place it in the flow. The access response needs a logging change at the decision layer. Each has a lead time measured in quarters once you account for design, build, review and the realities of a change freeze over year-end. Counting back from 1 January 2027, the runway to start scoping is not “next year”. It is now.

There is also a build-versus-buy fork embedded in this. Some of the machinery — consent and preference management, request intake — can be bought; some — the decision-level logging and the alternative-pathway routing — is specific to your models and has to be built. Getting that split right early is what keeps the programme affordable, and it is the same build-versus-buy decision that governs any control programme under deadline. It rewards being made deliberately rather than defaulted.

And do not read this date in isolation. The same corner of the calendar carries other fixed 1 January 2027 obligations — the Data Act switching duties land days later — and engineering capacity does not multiply to meet a crowded quarter. The firms that struggle will be the ones that discovered in October 2026 that their credit model has no idea, per applicant, which features moved the answer.