If your company already runs OneTrust, the first question about California's automated decisionmaking technology (ADMT) rules is usually whether the platform covers them. Part of the answer is yes. Part of it can't be, because some of what the rules require happens inside the software that makes the decision, not inside a privacy tool. This post maps that split as we read it: what a privacy platform is built to hold, what your engineers still have to build, and where the two have to meet.
This isn't a case against OneTrust. Most businesses facing these rules will want both a platform and some engineering. We're an engineering firm, we don't sell or resell OneTrust, and ivector has no affiliation with it (the name is its owner's trademark). What this post says about OneTrust comes from OneTrust's own website as of 24 October 2026, linked where it's used. Ask OneTrust which of these pieces its products cover for your stack; their answer beats our reading of their marketing.
What the rules require, briefly
From 1 January 2027, a business already using ADMT for a significant decision has to comply with the ADMT rules in the California Consumer Privacy Act (CCPA) regulations (section 7200(b)). A significant decision is one about financial or lending services, housing, education, employment or healthcare (section 7001(ddd)). The people affected get four rights: a pre-use notice, the right to opt out, the right to access information about the decision, and the right to appeal. Whether your system counts as ADMT at all is a narrower question than most teams assume, and the definition never mentions AI. Your counsel decides coverage; the free checker is a reasonable first pass before that conversation.
What OneTrust says it does here
OneTrust has been publishing on these rules for a while, and its material is a fair guide to where a platform helps.
- It publishes a checklist aimed squarely at consent platforms, ADMT Compliance Checklist: 10 Capabilities Your CMP Needs Before 2027.
- Its marketing operations guide to California ADMT says cookie banners and cookie controls are not, on their own, an acceptable ADMT opt-out mechanism, and that the pre-use notice can't be embedded in or replaced by a cookie banner or preference center.
- Its post on enforcing ADMT choices with its consent suite argues that an ADMT opt-out has to stay associated with the individual and reach the systems responsible for the processing.
- It sells a Data Subject Request (DSR) Automation product for receiving and fulfilling privacy requests.
The third point is the useful one, because OneTrust is describing the boundary itself. A platform can capture the choice and route it. The systems responsible for the processing then have to act on it, and those systems are yours.
The split, right by right
This is our reading of where the work sits for each of the four rights. The left column is what privacy platforms in general are built to hold. It isn't a claim about any one product's feature list.
| Right | What a privacy platform is built to hold | What has to exist in your own software |
|---|---|---|
| Pre-use notice | The notice text, its versions, and a record of who was shown which version | A notice that renders before the decision is made, in the flow where it's made (the build guide) |
| Opt-out | Request intake, identity handling, a record of the person's choice | A stop the decision system actually reads, within 15 business days, plus notice to every vendor that touched the person's data (the opt-out handler) |
| Access | Request intake, verification, deadline tracking | A decision log detailed enough to answer "why me?": inputs, output, logic and the reviewer's role, retrievable per person (what the response must contain) |
| Appeal | Somewhere for the appeal to land and be tracked | A human reviewer with authority to overturn the decision, and a way to reverse one that has already flowed downstream |
Read down the right-hand column and you'll notice none of it is configuration. Each item is a change to the code that scores, ranks or screens people, and a privacy team usually can't make that change on its own.
Why the engineering half is the one that slips
Here's the opinion we'd defend on a call with a privacy lead: the platform half will be ready first, and that's exactly the risk. A consent platform can be configured by the privacy team on their own timetable. The engineering half competes with the product roadmap, so it gets scheduled late, and it's often discovered late too, because nobody owns the boundary.
The failure looks quiet. The opt-out form works and the request is recorded, verified and marked complete. Meanwhile the scoring service keeps running for that person, because nothing in the scoring service reads the flag. On paper the request was honoured. In the system that made the decision, nothing changed. That gap won't show up in a demo of either half. It shows up when someone asks what happened to a specific person.
A worked example: one opt-out, end to end
Picture a hiring-software vendor with California customers (an invented example, not an ivector client). Its product ranks job applicants, and several of its customers run OneTrust.
An applicant opts out of automated ranking through the employer's privacy page. The employer's platform records the choice and starts its clock. Now the employer has to stop using the ranking for that person, and when someone opts out, section 7221(n)(2) requires the business to notify every service provider and contractor it shared their information with for that ADMT. The vendor is one of those. Its product has to accept that notice, take the applicant out of automated ranking, hand them to whatever non-automated process the employer uses instead, and log that it did so, in a form the employer can show later.
No setting in the employer's privacy platform can reach into the vendor's ranking code. The vendor has to build that intake, the exclusion, and the log. That's why our ADMT feature pack exists for SaaS vendors: their customers' compliance runs through code only the vendor can change. Our post on what California requires in an AI vendor's contract covers the contract side of the same chain.
When you don't need engineering help for this
Plenty of businesses won't, and it's worth saying who.
- The ADMT is a vendor's tool, and the vendor ships the notice, opt-out handling and logs. Your work is the contract and the configuration, and a platform plus counsel may be enough.
- Your reviewers genuinely clear the human-involvement test. If a person really makes the decision, the system may not be ADMT at all. That's a finding we'd rather you reach early.
- Your own engineers have the capacity. The build guides linked above are written so they can do it themselves.
- You're not covered. The checker and your counsel will tell you.
Where we fit is the opposite case: your own software makes the decision, the date is fixed, and your team has a roadmap already. We don't give legal advice; your counsel decides what you owe. We start with a fixed-scope, two-week readiness sprint that inventories every automated decision touching the five categories and hands counsel a gap list and an implementation plan sequenced against 1 January 2027, then build the notice, opt-out, decision log and appeal path into your stack, not bolted alongside it. If a platform is part of that stack, the build has to meet it.
If you're not sure the rules reach you, start with the ADMT checker. If they do, see what we build or tell us what you run.
Sources
- California Privacy Protection Agency: CCPA regulations, Title 11 Division 6 Chapter 1, effective 1 January 2026
- OneTrust: ADMT Compliance Checklist, 10 Capabilities Your CMP Needs Before 2027, as of 24 October 2026
- OneTrust: From ADMT Pre-use Notices to Optouts, a marketing ops guide to California ADMT compliance, as of 24 October 2026
- OneTrust: Beyond Consent Capture, enforcing DNS and ADMT choices with OneTrust CMP Suite, as of 24 October 2026
- OneTrust: Data Subject Request (DSR) Automation, as of 24 October 2026
