EU AI Act vs US State AI Laws: Which Runtime Controls Satisfy Both?

Why organize the comparison by control objective

The EU AI Act and US state AI laws are written differently, but both group duties by function. The EU Act is binding in its entirety and directly applicable in all Member States. A consolidated text dated 27 July 2026 is current as of November 2026. For high-risk systems it sets requirements for risk management, data set quality and relevance, technical documentation and record-keeping, transparency and information to deployers, human oversight, and robustness, accuracy and cybersecurity.

State legislation tracks a narrower field. Lawmakers primarily focus on AI used in consequential decisions affecting livelihood and life opportunities, in sectors such as employment, education, housing and financial services. A central goal is mitigating algorithmic discrimination, through prohibitions or a duty of reasonable care. Common developer and deployer obligations are transparency and disclosures, assessments, and AI governance.

Because both sets of duties reduce to a handful of objectives, a compliance team can design controls per objective and reuse them across jurisdictions. A runtime control acts on an individual interaction or tool call. That is the level at which it can enforce policy and produce evidence. Anything that must be decided, written or approved outside that moment sits outside its reach.

Where one control set serves both regimes, and where it does not

The strongest overlap is in oversight, records and data handling. An escalation-for-approval control produces the same underlying artifact for any regime: who or what was escalated, who decided, and when. A redact or block decision is likewise a record of what the system was allowed to do. If evidence is generated once at enforcement time, each jurisdiction's documentation can draw from the same store.

The regimes diverge on scope, roles and classification. The EU Act is sector-agnostic and applies an intended-purpose test to high-risk systems. State laws center on consequential decisions in named sectors. A single policy applied everywhere is therefore too coarse. Controls need scoping rules per use case, so that a hiring workflow and an internal coding assistant are treated differently.

Roles also differ. The EU text assigns duties to providers and refers to operators, while state frameworks refer to developers and deployers. An enterprise may hold different roles in different deployments, which changes where controls belong and what evidence it must hold. Tagging evidence by jurisdiction, use case and role lets one record set answer different requests without separate programs.

Evidence readiness matters in practice. If a market surveillance authority finds non-compliance, it must without undue delay require corrective action, withdrawal or recall. The period it sets is in any event the shorter of 15 working days or what the relevant Union harmonisation legislation provides. Evidence that can be retrieved quickly, by system and by period, is part of the design.

What runtime enforcement cannot satisfy on its own

Runtime enforcement supports organizational governance. It does not replace it. The EU Act lists risk management, technical documentation and accuracy as separate requirement categories, and state laws list assessments and governance as separate duties. A runtime control cannot write an impact assessment, run a risk management system, complete a conformity assessment or issue a consumer notice.

It also cannot establish that a system is accurate. Accuracy, robustness and cybersecurity are lifecycle properties tied to intended purpose and the generally acknowledged state of the art. Block and rate limit controls may support robustness at the point of use, but they do not show that a model performs as intended. Whether runtime controls can address algorithmic discrimination duties is likewise an open question that assessments must answer.

Serving incident duties needs a process. Providers of high-risk systems placed on the Union market must report any serious incident to the market surveillance authorities of the Member States where it occurred. That is an organizational reporting decision. Runtime records can help detect and document an incident, but a named role must decide and report.

Accountability stays with the provider, developer, deployer or operator named in the law. A tool cannot transfer it. This page is not legal advice, and each jurisdiction's obligations should be confirmed with counsel.

Trussed as an example of enforcement in the execution path

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, using allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. Enforcement generates continuous audit-ready evidence mapped to the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed is a runtime control product. It is not an AI governance platform or a GRC platform, so impact assessments, documentation and organizational governance programs remain the customer's work. NIST AI RMF can serve as a shared reference when teams reconcile the evidence across regimes.