EU AI Act vs CCPA ADMT Rules: Automated Decision Obligations Side by Side

Two legal structures, not two versions of one rule

The EU AI Act is Regulation (EU) 2024/1689, adopted on 13 June 2024. The European Commission describes it as risk-based rules for AI developers and deployers regarding specific uses of AI. Its obligations attach to roles (provider, deployer) and to a risk classification of the AI system. A consolidated text dated 27 July 2026 is published, so teams should work from the current consolidated version.

The CCPA ADMT rules sit inside a different framework. The California Privacy Protection Agency Board adopted a regulations package on 24 July 2025 that updates the existing CCPA regulations, implements risk assessment requirements for certain businesses, and addresses consumer opt-out of businesses' use of ADMT. The listed effective date is 1 January 2026. The California regulator, referred to as the Agency or CalPrivacy, implements and enforces the CCPA.

This difference shapes everything downstream. Under the AI Act, the question is whether a system is high-risk and which role your organization holds. Under the CCPA package, the question is whether a business's use of ADMT falls within the regulations and which consumer-facing and assessment duties follow.

Obligation-by-obligation matrix

The matrix below compares the two regimes on the dimensions most relevant to a consequential automated decision. Where the regimes use different concepts, the entries are deliberately not paired as equivalents.

• Legal structure: EU AI Act: Regulation (EU) 2024/1689, risk-based rules for developers and deployers. CCPA: regulations adopted by the California Privacy Protection Agency Board, effective 1 January 2026.
• Regulated parties: EU AI Act: providers and deployers of AI systems, with duties varying by role. CCPA: businesses, with risk assessment requirements applying to certain businesses.
• Trigger: EU AI Act: classification of the system as high-risk. CCPA: a business's use of ADMT within the scope of the regulations.
• Core requirement areas: EU AI Act (high-risk): risk management, data quality, technical documentation and record-keeping, transparency to deployers, human oversight, robustness, accuracy and cybersecurity. CCPA: consumer opt-out of ADMT use and risk assessments.
• Risk assessment: EU AI Act: continuous, iterative risk management across the system lifecycle, aimed at risks to health, safety and fundamental rights. CCPA: risk assessments for certain businesses. The two are not equivalent.
• Enforcement: EU AI Act: Union and national framework. CCPA: the California Privacy Protection Agency (CalPrivacy).

Where the regimes diverge

Scope is the first divergence. The AI Act classifies systems by risk and then assigns duties to the parties that build or use them. A single system can therefore trigger different duties for the provider and for the deployer. The CCPA package is organized around the business and its use of ADMT affecting consumers, so the same technology may be in scope for one use and out of scope for another.

Risk assessment is the second. The AI Act requires a risk-management system that runs throughout the lifecycle of a high-risk system and is aimed at health, safety and fundamental rights. The CCPA package separately implements risk assessment requirements for certain businesses. A completed assessment under one regime should not be assumed to satisfy the other, because their purposes, triggers and audiences differ.

The third is the relationship to privacy law. The AI Act states that it does not affect existing Union law on personal data processing, or the obligations of providers and deployers as controllers or processors under that law. Meeting the AI Act therefore does not replace data protection duties. Likewise, the CCPA package operates as privacy regulation and does not substitute for AI Act duties where a system is in EU scope.

The fourth is the consumer-facing mechanism. The CCPA package expressly addresses consumer opt-out of ADMT use. The AI Act's high-risk requirements are framed around human oversight and transparency to deployers. These serve related goals through different mechanisms, and a single control rarely satisfies both.

Records, logs and retention

On the EU side, providers of high-risk AI systems must keep the logs referred to in Article 12(1) that their systems automatically generate, to the extent those logs are under their control. The consolidated text requires retention for a period appropriate to the system's intended purpose and for at least six months. Union or national law may provide otherwise, in particular Union data protection law. The recitals link record-keeping and technical documentation to traceability, compliance verification, operational monitoring and post-market monitoring.

Two design points follow. First, the log duty applies to logs the system generates and to providers who control them, so deployers should confirm who holds the logs for each system. Second, the six-month figure is a minimum that interacts with data protection law, so retention settings should be reviewed against privacy obligations as well as the AI Act.

For California, record handling should be mapped from the risk assessment and ADMT opt-out obligations that apply to each business and use case. Do not assume the AI Act's logging and retention model carries across. A retention schedule that is correct under one regime can be wrong under the other.

What runtime enforcement can support, and what it cannot

Some obligations are organizational or legal by nature. Classifying a system as high-risk, determining whether you are a provider or deployer, deciding whether a use of ADMT is in scope, completing risk assessments, and setting the legal basis for retention are decisions people and counsel make. No runtime control performs them.

Other obligations depend on what actually happens when a system runs. Human oversight is only meaningful if a reviewer is in the path of the decision when it matters. Traceability depends on evidence tied to individual interactions. Controls over what a model or agent may receive, return or do with a tool can be enforced when the interaction occurs, not reviewed after the fact.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block and escalate for human approval. Enforcement produces audit-ready evidence mapped to the EU AI Act. This operates at the level of individual interactions and tool calls, and it can support selected obligations such as oversight mechanisms and traceability evidence. It does not classify systems, perform risk assessments or settle provider and deployer duties. It also is not a claim that any product delivers compliance with the CCPA ADMT rules, which remains a legal determination for each business.