Where AI & Privacy Intersect: 10 Myths About ADM(T)

As our clients prepare for automated decision-making (ADM) requirements beginning in 2027 in California, Colorado, and Connecticut, we’d like to clear up a few myths about ADM. For this article, we use “ADM” as shorthand to include ADMT under California’s CCPA regulations, ADMT under Colorado’s SB 26-189 (which repealed and replaced the Colorado AI Act), automated employment-related decision technology (AEDT) under Connecticut’s Public Act 26-15 (formerly SB 5), and automated decision-making under the EU’s GDPR Article 22. We also briefly discuss the EU DSA where automated content or account restrictions overlap with GDPR obligations.

Myth #1: There are no real AI laws in the U.S.

When companies think of AI laws in the U.S., they’re often focused on targeted, narrow topics that usually don’t significantly affect most companies: chatbot disclosures, frontier models, training data transparency, sector-specific laws. But ADM requirements are among the widest-reaching de facto AI laws we have in the U.S. right now, because they impact ubiquitous business relationships, such as with job applicants or employees, certain payment-related financial services (including transmitting or exchanging funds), and independent contracting opportunities.

Myth #2: All AI is the same for ADM purposes.

Different types of AI vary in interpretability and predictability and can have different legal implications for ADM. For illustration, consider the following overlapping categories which often become more open-ended or autonomous and may produce less predictable outputs as you move down the list:

• Traditional machine learning (ML) is commonly used for fraud detection, pricing, lead scoring, ad targeting, and risk scoring.
• Large language models (LLMs) generate or transform content and are used in chatbots, copilots, and content generation applications.
• Agentic systems, often built around LLMs, can plan and execute multi-step tasks with varying degrees of autonomy, including in customer support, coding, and workflow automation.

As a system’s outputs become harder to anticipate, reproduce, and attribute, it can become more challenging to document whether and how the outputs materially influenced a decision, accurately describe the system’s role in required notices, and explain an individual result for access, correction, or appeal purposes. This uncertainty in turn translates to ambiguities in determining applicability of U.S. privacy and AI laws.

Myth #3: It’s all a black box, so why bother explaining anything.

There is a longstanding concern that AI models are “black boxes” that can’t be fully explained, especially as LLMs (including agentic ones) take on more intermediate steps in business processes and decision-making becomes more unpredictable or opaque, even when traditional ML models or rules engines are still making the final decision. Privacy laws with ADM requirements (and certain high-risk AI decisions under the EU AI Act, to the extent the GDPR doesn’t already apply) commonly require businesses to explain their ADM. Some require an individualized, decision-specific explanation or statement of reasons. They may require you to explain the parameters (the data or factors that matter) and the logic (how the system makes a decision).

But how do you comply if you can’t explain the decision? The Dutch AP has offered one of the strictest positions to date. Its April 2026 consultation draft on the right to an explanation suggests that where an opaque LLM is used, compliant ADM may be practically impossible. Even so, the laws generally do not require perfect explainability; they don’t require disclosure of source code, model weights, or a perfect technical reconstruction of every computational step. Even if you can’t predict an outcome with certainty, you can still explain the data used, the governing policies, the applicable model version, the controls applied to the system, how the model was validated, and what opportunities for human review exist. Businesses should be prepared to explain what they can and determine whether that mitigates risk to an acceptable level.

Myth #4: The U.S. will interpret ADM concepts the same way as Europe.

Although we have yet to see how U.S. regulators will enforce the new state ADM requirements, Europe already has a substantial body of regulatory guidance, case law, and enforcement involving automated decision-making under GDPR Article 22. That experience is useful, but it is not controlling and not necessarily predictive of how U.S. regulators will interpret differently worded statutes and regulations. While U.S. state ADM requirements have borrowed some concepts from Europe, they may not prioritize or interpret the same concepts in the same way. For example, the state laws contain specific exclusions or opt-out exceptions that have no direct GDPR analogue (e.g., California’s opt-out exceptions for qualifying hiring and work allocation uses and Colorado’s exclusions for content moderation and specified fraud prevention activities).

Myth #5: U.S. state ADM requirements apply to hiring / don’t apply to hiring / only apply to hiring.

We’ve seen various categorical hiring-related statements that don’t hold up across all U.S. ADM requirements. For example:

ADM applies to hiring: California has important exceptions to the ADMT opt-out requirements for hiring and allocation/assignment of work and compensation. In some ways, this reflects practical realities for modern AI-enabled hiring processes and gig work assignments involving thousands of decisions that must be made every day or even every hour.

ADM doesn’t apply to hiring: Under the California CCPA ADMT regulations, some interpret the hiring exception too broadly. Yes, there is a hiring exception, but there are two important caveats. First, the exception only applies to the opt-out requirement. While that may be the most onerous requirement, it doesn’t save you from pre-use notices, requests to access ADMT, or risk assessments. Second, there are exceptions to the opt-out exception. If the ADMT’s assessment of a job applicant doesn’t work for the business’s purposes, is unrelated to the applicant’s ability to perform the job, or discriminates based on protected characteristics, the exception no longer applies.

ADM only applies to hiring: Some public commentary suggests Colorado’s SB 26-189 limits the scope of employment ADMT to solely hiring, but the better reading is that the provision reaches employment more broadly. “Consumer” expressly includes current employees; a “covered domain” includes “employment” as well as an “employment opportunity”; and the definition of “consequential decision” includes decisions concerning compensation in a covered domain.

Myth #6: ADM is just about sectoral decisions like employment, credit/financial services, or healthcare.

Beyond privacy laws, the EU DSA creates a parallel, de facto ADM-type regulatory layer for certain content and account restrictions. The DSA is sometimes described as a “backdoor” for GDPR enforcement because it can apply to some of the same activities, but it’s often a blind spot for privacy professionals because it’s not enforced by privacy regulators. DSA Article 17 applies when a hosting service (including an online platform) restricts the visibility of user-provided information, monetization, service access, or an account because it considers that information illegal or incompatible with its terms and conditions. Unlike GDPR Article 22, DSA Article 17 doesn’t depend on whether the decision was automated: it applies to covered restrictions regardless of how they were imposed, but requires disclosure of any role played by automated means.

If you’re making automated decisions that restrict user content, monetization or monetary payments, service access, or accounts, you could be triggering both the GDPR and DSA for the same decisions and may need to provide explanations under the GDPR and statements of reasons under the DSA.

Myth #7: If there’s a human in the loop, there’s no ADM.

This is where the GDPR and CCPA ADMT regulations diverge on paper, but less so in practice. The GDPR uses “solely” automated, while the CCPA regulations use “substantially replace human decisionmaking.” Based on EU regulatory guidance and some court decisions, you end up largely in the same place, because to avoid “solely” under the GDPR, you need meaningful human involvement in the decision. A human who rubber-stamps automated decisions is not enough. The CCPA regulations make this explicit: both the definition of human involvement (for purposes of determining whether a system is ADMT) and the human appeal exception to the opt-out requirement require reviewing the output, knowing how to use it, and having authority to change the decision. If a human formally makes the final decision but never departs from the system’s recommendation, that may support an inference of rubber-stamping.

Colorado and Connecticut go further: even genuine, independent human review doesn’t necessarily remove a system from scope if its output materially influences, or is a substantial factor in, the decision.

Myth #8: If there’s no AI, there’s no ADM.

ADM and profiling are often carried out using AI. However, software that is not AI-based can also apply decisions automatically based on predefined rules, thresholds, scoring rubrics, or screening criteria. If these tools process personal data and replace human decision-making or materially influence a covered decision, they can still trigger ADM requirements even if they would not ordinarily be described as AI.

Myth #9: Recommendations or scores are not “decisions.”

In Europe, the CJEU held in SCHUFA that an automatically generated credit score could itself qualify as a decision where the score played a determining role in a third party’s decision to grant credit.

The U.S. state laws generally distinguish between a model’s output and the regulated decision. But that distinction doesn’t make recommendations or scores irrelevant. Colorado and Connecticut expressly cover recommendations, rankings, scores, and classifications that materially influence decisions. California can cover an output-driven process when the business uses it to make a significant decision without qualifying human involvement. A recommendation or score doesn’t need to be the final decision for the surrounding decision process to fall within scope.

Myth #10: The vendor assessed the tool, so our ADM work is done.

Vendor diligence is necessary, but ADM laws generally regulate a system as it’s actually deployed, not just the software as it was delivered. A vendor may be able to document intended uses, known limitations, and available testing (e.g., fairness testing or red team results). It usually can’t determine how much weight your personnel give the output, whether your configuration choices change the system’s behavior, whether your notices accurately describe your use, or whether you can provide any required explanation and support access, correction, appeal, or human review rights. So the ADM work includes the model, but it also extends to the data, the surrounding rules, the humans, and the resulting decision process.