What California's ADMT regulations actually are (and aren't)

California's new Automated Decisionmaking Technology rules are not a new AI statute. They're a rulemaking under the existing California Consumer Privacy Act, finalized by the California Privacy Protection Agency on September 23, 2025, with the regulatory text taking legal effect January 1, 2026 (CPPA announcement). That distinction matters more than it sounds. Colorado and Texas passed dedicated AI statutes that create new causes of action around algorithmic discrimination. California instead extended its privacy law to cover any "automated decisionmaking technology" that touches personal data and a "significant decision" about a consumer or employee.

The practical effect is the same regardless of the legal mechanism: if you use software, including machine learning models, scoring systems, or ranking tools, to help decide who gets hired, who gets a loan, who gets approved for an apartment, or who gets access to care, you're probably in scope. The CPPA's final text defines ADMT broadly as any technology that processes personal information using computation to replace or substantially replace human decisionmaking (full regulatory text, PDF). That language explicitly sweeps in predictive scoring, automated ranking, and AI-assisted profiling, not just fully autonomous systems making decisions with zero human in the room.

Skadden's summary of the rule puts the scope in plain terms: ADMT covers decisions touching finance, housing, employment, and health, the categories California regulators consider carry real consequences for people's lives (Skadden client alert). If your AI touches any of those four areas and processes personal data about a California resident, this rulemaking is relevant to you, whether you built the system in-house or bought it from a vendor.

What counts as a "significant decision"?

A significant decision under California's ADMT rules is one that denies or affects access to employment, finance, housing, healthcare, or education, the five buckets regulators treat as high-stakes enough to require notice, opt-out, and access rights. That's the plain-language version. The formal text frames it as a decision that produces a legal or similarly significant effect.

In practice, this reaches further than most operators expect. It's not just "did we deny this applicant a loan." It's hiring decisions (who gets interviewed, who gets an offer, compensation band assignment, performance scoring, termination recommendations), credit and lending decisions (approval, pricing, limits), housing decisions (tenant screening, rental approval, pricing adjustments based on risk scores), healthcare access decisions (eligibility for services, care authorization), and education admissions. If your AI system contributes meaningfully to any of these outcomes, even as one input among several, you're likely covered.

The word "substantially replace" in the definition is the trap. A lot of companies assume that because a human technically clicks "approve," they're outside the rule. The CPPA didn't write it that way, and that nuance is the whole subject of the next section.

The compliance timeline you actually need to track

There are three dates that matter, and they're not the same date, which is where a lot of confusion comes from in the current wave of client alerts.

• January 1, 2026: the regulatory text is in legal effect. This is the "the rule exists now" date, not the enforcement date.

• January 1, 2027: full enforcement of consumer and employee ADMT rights begins, including pre-use notice, the right to opt out, and the right to access the logic behind a decision. This is the date operators should be building toward.

• 2028 through 2030: phased deadlines for submitting cybersecurity audit certifications and risk assessment summaries to the state, staggered by business size and data volume.

Littler's breakdown frames this as a sequence of seven practical steps employers need to work through before January 2027, starting with inventorying every system that touches a significant decision (Littler, seven steps for employers). That inventory step is the one most companies skip, because nobody owns a single list of every AI tool touching hiring, credit, or housing decisions across departments. We've seen this pattern across regulated clients regardless of which state law is driving the project: the compliance gap isn't usually bad intent, it's that no one in the building can produce a complete list of what's actually deciding what. One more date worth flagging separately: California's SB 947, the "No Robo Bosses Act," takes effect July 1, 2027, and bans employers from relying solely on an automated system to discipline or terminate an employee without independent human review (WSGR summary). It's a separate statute from the CPPA's ADMT rulemaking, passed through the legislature rather than agency rulemaking, but it covers overlapping territory in employment and will get conflated with ADMT in a lot of internal compliance memos. Treat them as two requirements, not one.

The human-review loophole that isn't one

Putting a human in the loop only exempts you from ADMT obligations if that human has actual authority to overturn the system's output, not just visibility into it. This is the single most misunderstood part of the whole rulemaking, and it's the part vendors are least likely to tell you honestly. Thompson Coburn's analysis of the human-involvement exception is worth reading in full, because it spells out exactly what "meaningful" means here: the reviewer has to understand how the system arrives at its output, has to have the authority to change the outcome, and actually has to exercise independent judgment rather than rubber-stamping the model's recommendation (Thompson Coburn, human-involvement exception). A hiring manager who glances at an AI ranking tool's top five candidates and picks from that list isn't exercising meaningful human involvement under this standard. Neither is a loan officer who approves 98% of what the scoring model recommends, because the pattern itself suggests the human isn't functioning as an independent check. This matters architecturally, not just legally. If your system is designed so the human reviewer only sees the model's conclusion, you've built something that will fail this exception even if a person technically signs off every time. A compliant design needs the reviewer to see the inputs, understand the reasoning, and have a documented, exercised ability to deviate from the recommendation. That's a UI and workflow decision, not just a policy decision, and it's exactly the kind of requirement that gets missed when a company buys an off-the-shelf scoring tool and treats the review step as a formality.

What this means if you bought your AI instead of building it

If your hiring, lending, or tenant-screening AI runs on a third-party vendor's platform, you are still the business responsible for ADMT compliance, and most vendor contracts weren't written with this rule in mind. The CPPA's rules place the compliance obligation on the business making the decision, not on the software provider, which means liability doesn't transfer just because you're renting the model instead of building it.

This creates a specific, checkable problem: can your vendor actually produce what the law requires? Four things to ask before you renew or sign anything:

• Can the vendor produce an audit log showing exactly what data and logic drove a specific decision, on request, for a specific individual?

• Does the vendor's system support a genuine opt-out path, routing the consumer to a human-reviewed alternative rather than just suppressing the output?

• Can the vendor isolate and export the specific personal data used for one individual's decision, to satisfy an access request within the statutory window?

• Does the contract assign responsibility for conducting the pre-use risk assessment, or does it leave that obligation implicitly with you while the vendor retains the only technical visibility into how the model works?

Our internal vendor risk assessment checklist covers this ground in more depth, but the short version is that a vendor who can't answer the audit-log and data-isolation questions in writing is handing you legal exposure disguised as a SaaS subscription. This is also why, for clients in regulated industries, Genta AI Solutions often recommends self-hosted open-source models running on the client's own infrastructure with zero data retention: when the auditability requirement is non-negotiable, owning the full stack is frequently simpler than negotiating it into someone else's product roadmap.

How to architect for pre-use notice, opt-out, and access rights from day one

The four rights the regulation creates (pre-use notice, opt-out, access to the decision logic, and a pre-launch risk assessment) are architecture requirements as much as legal ones, and retrofitting them onto a system that wasn't built for logging is expensive and slow. Building them in from the start is comparatively cheap.

Decision logging needs to capture more than a pass/fail outcome. It needs to capture which model version made the call, what inputs it used, what confidence score or output it produced, and whether a human reviewer changed anything, with a timestamp and reviewer identity attached. Without this, you can't produce the access-request response the law requires, and you can't prove the human-review exception applies even if it genuinely does.

Explainability hooks don't require a fully interpretable model. They require that someone in your organization, not just the vendor, can translate "the model scored this applicant 0.31" into a plain-language reason a consumer can actually read. If nobody internally can generate that explanation without calling the vendor's support line, you've outsourced a legal obligation to a party that has no contractual deadline to answer you.

Opt-out routing needs a real destination, not a dead end. A consumer who opts out of automated decisionmaking needs an alternative path to the same outcome, reviewed by a person with actual decision authority. Building that path after the fact, once volume has scaled past what a human team can handle manually, is where a lot of companies discover their original automation business case assumed zero opt-outs.

Data minimization matters here in a way it doesn't in most AI projects: the access-request obligation means you need to know, for any individual, exactly what data fed their decision. Systems that pull broad feature sets from a data lake without tracking provenance per-decision make this close to impossible to answer accurately within the statutory timeframe.

How California's ADMT rules compare to Colorado, Texas, NYC, and the EU AI Act

California regulates ADMT through privacy law (consumer rights over automated processing), while Colorado and Texas created standalone AI statutes built around developer and deployer duties, and the EU AI Act uses a risk-tiered product-safety model. If you operate in multiple jurisdictions, these frameworks don't map cleanly onto each other, and treating one as a proxy for the others is a common and costly mistake. New York City's Local Law 144 is the closest sibling, since it also targets automated hiring tools specifically, requiring bias audits and candidate notice (see our NYC Local Law 144 compliance guide). But LL144 is narrower in scope (hiring only) and its audit requirement is independent and public, whereas California's risk assessment is submitted to the state rather than published. Colorado's AI Act, covered in our Colorado AI Act breakdown, imposes affirmative duty-of-care obligations on both developers and deployers of "high-risk" systems, a different legal theory than California's consumer-rights approach. Texas's TRAIGA, detailed in our Texas AI compliance guide, focuses more narrowly on government use and intentional discrimination, with lighter private-sector obligations than California's rule. The EU AI Act, by contrast, classifies systems into risk tiers before deployment and requires conformity assessments for high-risk categories, closer to a product safety regime than a privacy regime. A company operating in California, Colorado, and the EU simultaneously needs three separate compliance tracks, not one unified checklist, because the underlying legal theories (consumer privacy rights, deployer duty of care, and product risk classification) don't harmonize automatically just because they're all labeled "AI regulation."

If you're working through this decision, this is exactly what Genta's Discovery phase maps out before any engineering starts, and we're happy to compare notes on what your specific systems need to meet the January 2027 deadline.

Frequently asked questions

What counts as a "significant decision" under California's ADMT regulations?

A significant decision is one affecting access to employment, credit or lending, housing, healthcare, or education. This includes hiring, compensation, performance review, loan approval and pricing, tenant screening, care authorization, and school admissions. If your AI meaningfully contributes to any of these outcomes, you're likely covered, even if a human technically signs off at the end.

When do California's ADMT rules actually take effect?

The regulatory text took legal effect January 1, 2026. Full enforcement of consumer and employee rights, including notice, opt-out, and access, begins January 1, 2027. Phased deadlines for cybersecurity audit certifications and risk assessment filings run from 2028 through 2030, staggered by business size.

Does having a human review AI output get us out of the ADMT requirements?

Only if that human genuinely understands how the system reached its conclusion and has real authority to change or overturn it. A reviewer who only sees the model's recommendation and approves it most of the time doesn't satisfy the exception. The regulation calls this "meaningful human involvement," and passive review doesn't qualify.

Is California's ADMT rule the same as the EU AI Act or Colorado AI Act?

No. California regulates ADMT through consumer privacy law, granting individuals rights over automated processing. Colorado's AI Act imposes developer and deployer duty-of-care obligations under a standalone statute. The EU AI Act classifies systems by risk tier before deployment, closer to product safety regulation. Compliance with one does not satisfy the others.

If we use a third-party AI vendor for hiring or lending decisions, who is liable under ADMT, us or the vendor?

You are. The CPPA's rules place compliance obligations on the business making the decision, regardless of whether the underlying technology was built in-house or licensed from a vendor. Vendor contracts should explicitly address audit logs, data access, and risk assessment responsibility, because the liability doesn't transfer just because the software does.