Read California's definition of automated decisionmaking technology and count how many times it says "artificial intelligence." The answer is zero. Now count how many times it says "spreadsheets." Once, in the list of things that are excluded, followed immediately by the words "provided that they do not replace human decisionmaking."
That proviso is why most companies will scope this rule wrong. The compliance work everyone talks about (the pre-use notice, the opt-out, the decision log) cannot start until you know which systems are in scope, and the question teams reach for first, "where do we use AI?", is not the question the regulation asks.
What the definition actually says
Section 7001(e) of the adopted regulations, effective 1 January 2026, defines ADMT as "any technology that processes personal information and uses computation to replace human decisionmaking or substantially replace human decisionmaking."
Three things follow from that sentence. Technology is not limited to machine learning, and the definition never narrows to it. The test is replacement of a human decision, not sophistication of the method. And the exclusion list at 7001(e)(3) covers web hosting, domain registration, networking, caching, website-loading, data storage, firewalls, anti-virus, anti-malware, spam and robocall filtering, spellchecking, calculators, databases and spreadsheets, every one of them qualified by that same phrase: provided they do not replace human decisionmaking.
So the exclusions are conditional, not categorical. A spreadsheet is exempt right up until it is the thing deciding, at which point it isn't. Your scoping question is not "where do we use AI." It's "where does a computation decide something a person used to decide."
The human-in-the-loop test most teams assume they pass
The phrase carrying the most weight is "substantially replace," and the regulations define it precisely at 7001(e)(1): a business "uses the technology's output to make a decision without human involvement."
Then comes the part worth reading twice. Human involvement requires the human reviewer to know how to interpret and use the technology's output, to review and analyze that output and any other information relevant to make or change the decision, and to have the authority to make or change the decision based on that analysis. All three.
Most teams believe they clear this because someone approves the result. Often they don't. A recruiter working down a ranked shortlist, in order, without opening anything the ranking didn't surface, is not reviewing other relevant information. A reviewer who can technically overturn an output but has to escalate to a manager to do it does not plainly have the authority. A reviewer who has never been told what the score means cannot interpret it.
Here's the opinion I'd defend on a call: the human-review route is the escape hatch nearly every company will reach for, and it is the one most likely to fail under examination, because passing it is an organisational change rather than a product change. Giving a reviewer genuine authority and enough time to look past the score costs headcount and slows a queue somebody is measured on. That is a harder sell internally than building a notice, and it is the piece I'd get an honest answer on before designing anything around it.
Only five kinds of decision count
The rule doesn't apply to every automated decision, and this narrows the work usefully. Section 7001(ddd) defines a "significant decision" as one resulting 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.
That's the whole list. Your recommendation engine, your churn model, your ad targeting and your fraud scoring are not significant decisions under this definition, whatever else governs them. Teams routinely over-scope here and burn a quarter inventorying systems the rule never touched.
They also under-scope, because "employment" is broader than hiring. The definition covers allocation or assignment of work, and compensation including incentive pay. A scheduling optimiser that decides who gets which shifts is deciding about employment. So is a tool that computes bonus eligibility. Neither looks like a hiring system, and neither tends to appear on a list of "AI systems."
Where the in-scope systems actually hide
They are not in your model registry, because most of them were never models. In practice they turn up in five places: a feature inside vendor software that somebody enabled without reading closely (applicant ranking in an ATS is the common one), a rules engine written years ago by someone who has left, a third-party scoring API called from one backend service, a spreadsheet maintained by a team outside engineering, and a threshold sitting in a config file where a number quietly does the deciding.
Which points at the method. Do not inventory systems and ask which ones make decisions. Start from the five decision categories, list every significant decision your company makes about a person, and trace backwards to whatever produces the output. A systems-first pass misses the spreadsheet in HR every time, because nobody thinks of it as a system. A decisions-first pass cannot miss it, because the decision is what you started from.
A worked example: no AI, four candidate systems
Picture a 900-person home care agency. Counsel has told them the ADMT rules apply to their business. Engineering gets asked which of their systems use AI, answers "none, we don't have any models," and everyone moves on.
Then somebody runs the pass in the other direction, starting from decisions about people rather than from systems:
- Hiring. Their applicant tracking system ranks candidates with a vendor-supplied match score. Recruiters work down the list. Nobody on staff configured the scoring, and no one can say what goes into it.
- Shift allocation. A scheduling tool assigns visits to carers using an optimiser. Allocation of work is inside the employment definition.
- Incentive pay. A spreadsheet computes bonus eligibility from productivity metrics. A manager signs off on the output.
- Care hours. An assessment tool scores client acuity, and the score determines how many authorised hours each client receives, which lands in healthcare services.
Zero AI systems. Four candidates, and three of them turn on how people behave rather than on what the code does. Whether the recruiter, the manager and the assessor each meet the three-part involvement test is a question about working practice that no code review will answer, which is why this is an interview exercise before it is an engineering one.
The spreadsheet is the instructive case. It sits in the exclusion list, but only where it isn't replacing the decision. A manager reading a computed eligibility number and signing it looks different from a manager using the file to organise their own judgement, and the difference lives entirely in behaviour that nobody has written down. Where that line falls is your counsel's call, not ours. Engineering's job is to surface that the file exists and describe, accurately, how it is actually used, because counsel cannot rule on a system nobody mentioned.
What the inventory produces, and the dates it has to beat
The deliverable is a row per candidate decision, and the columns matter more than the format: the decision stated in the language of the five categories, the system or vendor producing the output, the personal information going in, precisely what the reviewer sees and what else they see, whether they can overturn it without escalating, and who owns it.
That reviewer column is what sizes everything downstream. Where the human clears the involvement test, the build may be small. Where they don't, you are building the pre-use notice and opt-out, the decision log, and a path to reverse a decision that has already propagated, which is the notice and opt-out work and the audit trail respectively. The four things the rules require you to build covers that downstream shape in full.
The calendar is the reason this is urgent rather than interesting. Section 7200(b) requires a business already using ADMT for a significant decision to be in compliance by 1 January 2027. Risk assessments for processing that began before 1 January 2026 and continues past it must be documented no later than 31 December 2027, with the required information submitted to the Agency no later than 1 April 2028. Everything downstream sits on the inventory, and the inventory is slower than the builds, because it moves at the speed of getting time with the people who actually run these processes.
If you are starting this and the honest answer to "how many automated decisions do we make about people" is "we're not sure," that is the normal starting position and the reason the first engagement is a scoped inventory rather than a build. Tell us which of the five categories your business touches and we'll tell you what a readiness pass would cover and what it would leave alone. If it turns out your reviewers genuinely clear the involvement test, that is a much cheaper thing to learn in 2026 than in 2028, and we'd rather say so early.
Sources
- California Privacy Protection Agency: CCPA regulations, Title 11 Division 6 Chapter 1, effective 1 January 2026 (sections 7001(e), 7001(ddd), 7200)
- California Privacy Protection Agency: CCPA updates, cybersecurity, risk assessment and ADMT rulemaking record