The Agent Regulation Stack: Operating Under Four Regimes at Once

TL;DR

One agent can sit inside four or five regulatory regimes at once, and almost all of them end up asking for the same evidence: an action-level log naming both the agent and the human it acted for. That convergence is the finding worth keeping.

The EU AI Act's high-risk deadline just moved sixteen months, to December 2027. Anyone who spent 2025 designing an agent's audit trail to the Act's six-month retention floor built to the wrong number, because that floor was never the binding one. MiFID II, FINRA and HIPAA never deferred anything, and their clocks run five to seven years.

This isn't an argument for waiting it out. Human oversight, action-level logging and risk classification tied to an agent's tool set are the pieces an engineering team genuinely has to build differently for something that acts rather than answers. Registering a system in an EU database or maintaining ISO paperwork is real work, but it's legal and compliance work, not a rewrite of the runtime.

Work out which regime sets your agent's longest retention clock before anyone chooses a deletion policy. That's the one decision here you can't undo after the fact.

Overview

We've written about the EU AI Act on its own terms, and about getting ready for agent compliance regulation in general. This one is about the collision: what happens when several regimes attach to the same agent at the same time, each wanting a different piece of evidence about the same action.

That's the ordinary case, not the exotic one. Take a single agent reconciling trade breaks for a European asset manager. It sits inside the EU AI Act as a deployer, if the use case is high-risk. It's inside MiFID II's record-keeping obligations too, and inside whatever the firm's ISO/IEC 42001 certification scope committed to, inside NIST AI RMF because the firm's US entity relies on it, and inside at least one US state statute keyed to where the affected individuals live. None of those regimes knows the others exist. Whether it satisfies any of them comes down to artifacts your engineering team did or didn't produce.

This is genuinely hard, and not for one reason. The timeline everyone spent 2025 planning around moved in mid-2026, and a lot of published guidance is now wrong about dates. More fundamentally, none of these frameworks was designed for systems that act. Every one assumes a model that produces an output, which a human then uses. An agent taking four thousand consequential actions a day with no human in the path breaks that assumption in the human-oversight rules, in the logging rules, in risk management, in incident reporting.

Four Layers, Different Kinds of Force

The four things people lump together as "AI regulation" are not the same kind of object, and treating them as interchangeable is the first mistake.

The EU AI Act is binding regulation with penalties. It classifies systems by risk, imposes obligations on providers and deployers separately, and is enforced by market surveillance authorities. It is the only layer that can fine you.

NIST AI RMF is a voluntary methodology. Released as AI RMF 1.0 in January 2023, it organizes AI risk work into four functions (GOVERN, MAP, MEASURE, MANAGE) and a set of outcomes under each, with a Generative AI Profile (NIST AI 600-1) added in 2024. It mandates nothing on its own. It is load-bearing in the US anyway, because state legislatures have started referencing it. Texas's TRAIGA, effective 2026-01-01, gives a rebuttable presumption of reasonable care (Sec. 552.105(c)) and a liability shield (Sec. 552.105(e)) where a violation is caught through an internal review process backed by substantial compliance with NIST's Generative AI Profile, named in the statute by title as AI 600-1, or another nationally or internationally recognized AI risk framework. A voluntary framework that buys a statutory defense isn't really voluntary.

ISO/IEC 42001 is a certifiable management-system standard. Its requirements sit in Clauses 4 through 10, with Annex A providing 38 reference controls across nine categories, justified by your own risk and impact assessments rather than ticked off as a list. Its distinctive requirement, the one with no ISO 27001 equivalent, is the AI system impact assessment, established at 6.1.4 and performed at 8.4. The practical value in a multi-regime world is that it produces third-party-audited evidence that a management system exists and operates, and other regimes tend to accept that as a proxy for diligence. What it is not, yet, is a European harmonised standard. CEN-CENELEC's JTC 21 has its own AI management-system work in progress, and only a standard cited in the Official Journal confers a presumption of conformity with the AI Act.

US state law is a patchwork keyed to where your users live, not to where you operate. It's the layer most likely to catch a platform team off guard, because it doesn't follow product boundaries at all.

Not all four cost engineering the same amount. The AI Act's logging and oversight duties land on the runtime: somebody has to build the log schema and the approval flow. US state law's residency trigger is a data-model problem, because nothing else in most stacks currently records where an affected person lives, and that field has to exist before anyone can answer whether a given action was in scope. NIST and ISO are mostly not engineering work at all. They're documentation and audit exercises that consume evidence the other two already produced, which is why they're worth doing and not worth designing the system around.

Figure 1 — Jurisdictional overlap. Six regimes of three different kinds, one agent, and substantial convergence on the evidence they each want.

What Moved in 2026

Anyone writing about the AI Act before mid-2026 was working from a timeline that no longer holds, so this needs to be precise.

The AI Act's high-risk obligations were originally scheduled to apply from 2026-08-02 for standalone Annex III systems and 2027-08-02 for high-risk AI embedded in products already regulated under Union safety legislation. The Commission published the Digital Omnibus on AI on 2025-11-19 proposing to defer those dates. A provisional political agreement was reached in the trilogue that concluded on 2026-05-07 and was confirmed by Member State representatives on 2026-05-13. The European Parliament took its final vote on 2026-06-16, approving the package 423 votes to 57 with 174 abstentions. The Council gave final approval on 2026-06-29. The amending act was signed on 2026-07-08 and published in the Official Journal on 2026-07-24 as Regulation (EU) 2026/1744, entering into force on the third day after publication.

The result:

• Standalone high-risk systems listed in Annex III: obligations now apply from 2027-12-02, a sixteen-month deferral.
• High-risk AI embedded as safety components in Annex I products (medical devices, machinery, toys and similar): 2028-08-02.
• National regulatory sandboxes: deadline for Member States to establish them pushed to 2027-08-02.

What still lands on 2026-08-02 is the Article 50 transparency package: telling people they are interacting with an AI system, and marking AI-generated content, with a grace period to 2026-12-02 for machine-readable marking of systems already on the market. A new Article 5 prohibition covering AI-generated child sexual abuse material and non-consensual intimate imagery applies from 2026-12-02. Registration in the EU database for systems the provider has self-assessed as not high-risk was retained with simplified administrative requirements.

One caveat to carry: published summaries describe the deferral as covering "the high-risk obligations" without itemizing every article. The obligations that matter most for agents are the Articles 8 to 15 requirements: Article 12 record-keeping, Article 16 and 17 provider duties, Article 19 log retention, Article 26 deployer duties, Article 27 fundamental-rights impact assessments (which bind only public bodies, private providers of public services, and deployers of certain Annex III credit and insurance systems), and Article 73 serious-incident reporting. All of them sit inside the high-risk regime and move with it, on that reading. Confirm against the Official Journal text before you rely on any specific article's date.

The US Patchwork

The US has no federal AI statute, so the operative law is state law, and 2026 was a year of churn rather than consolidation.

Texas brought TRAIGA into effect on 2026-01-01, with the NIST-referencing liability shield noted above. California's SB 53, the Transparency in Frontier Artificial Intelligence Act, took effect 2026-01-01, though its incident-reporting mechanism and the Attorney General's annual report are keyed to 2027-01-01; AB 2013's training-data disclosure duty attached "on or before January 1, 2026." Separately, the California Privacy Protection Agency's automated decision-making technology regulations took effect 2026-01-01, with significant-decision compliance required by 2027-01-01 under § 7200(b) and the first risk-assessment submissions and cybersecurity audit reports due 2028-04-01. Colorado, which passed the first comprehensive state AI act, delayed it and then replaced it before it ever applied: SB 24-205's applicability was pushed to 2026-06-30 by SB25B-004 in August 2025, and SB26-189 then repealed and reenacted the provisions as a narrower automated-decision-making-technology law, signed 2026-05-14 and effective 2027-01-01, with Attorney General rulemaking due by the same date. Illinois, Utah and New York have their own instruments, several of them amended during 2026.

For an engineering team the detail that matters is the trigger. These statutes generally attach to the residence of the affected individual and to whether the system materially influences a consequential decision about them: employment, credit, housing, insurance, healthcare, education. That is not a product boundary and it is not a tenant boundary. A single agent serving a single application can be simultaneously in scope in Texas and out of scope in a neighbouring state, and the only way to know is to have recorded, per action, who the affected individual was. That's a schema change, not a legal opinion, and it's engineering's to make.

Singapore Names It

On 2026-01-22 Singapore's Infocomm Media Development Authority launched the Model AI Governance Framework for Agentic AI, which is, as far as we can establish, the first governance document from a national authority written specifically about systems that act autonomously rather than about models that produce outputs. NIST has agent-specific material, but it is security and red-teaming guidance rather than governance. The IMDA framework is guidance rather than regulation, and IMDA is explicit that "as deployers, organisations and humans remain accountable for the decisions and actions of agents." It was revised to version 1.5 on 2026-05-20 after industry feedback, with a further update on 2026-06-05.

It's organized around four dimensions, and the guidance under each one is more concrete than anything above it:

• Assess and bound risks upfront, with mitigations including restricting the agent's tool access, running it in a sandboxed environment, and establishing fine-grained identity controls.
• Make humans meaningfully accountable, with defined roles from product teams to executive oversight, human-in-the-loop gates for high-stakes actions, and explicit attention to automation bias in the supervising human.
• Implement technical controls and processes, with testing extended beyond output accuracy to cover tool usage, policy compliance and workflow reliability, and with graduated rollouts and continuous anomaly monitoring after deployment.
• Enable end-user responsibility, meaning users are trained on and told what the agent is permitted to do.

The May 2026 update added the parts that only appear once you have operated these systems: risks arising from multi-agent configurations and from third-party agents; a distinction between platform providers and system developers for accountability purposes; guidance on choosing between structural, rule-based controls and model-based or prompt-layer controls at each stage of the lifecycle; change management to stop small modifications cascading; and, in the single most telling recommendation in any of these documents, monitoring human override rates and response times. The framework's own reasoning is worth quoting directly: a low override rate "may signal rubber-stamping behaviours," and a shorter human response time "may signal automation bias or review fatigue."

That last one is what a regulator writes when it has understood the actual failure mode. An approval gate where the human approves 99.4% of requests in under two seconds doesn't amount to oversight, only to a log entry claiming oversight took place.

Built for Answers, Not Actions

The central practical problem with the stack is that its assumptions predate the systems it now governs. Three obligations show the mismatch clearly.

Human oversight. Article 26(2) of the AI Act requires deployers to "assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." Written for a system that produces an output (a credit score, a triage recommendation), this is coherent: a named, competent person reviews the output before it is used. Now apply it to a reconciliation agent taking four thousand actions a shift. Assigning a natural person to oversee it is either meaningless, if the person cannot possibly review the actions, or it destroys the automation, if they can. The reinterpretation that actually satisfies the intent is oversight of the authorization envelope rather than of individual actions: a human decides and periodically reviews what classes of action the agent may take, which thresholds escalate, and what the override statistics look like. Singapore's override-rate metric is the closest thing to an official acknowledgement of this reframing, and it's also the one item on this list that is unambiguously engineering's problem, not legal's: nobody ships an override dashboard by writing a policy memo.

Logging. Article 12 requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system" (a capability obligation, not a recording one), and Articles 19 and 26(6) require the resulting logs to be retained. For a model, the natural log record is an inference: inputs, output, model version, timestamp. For an agent, that record is close to worthless. The consequential unit is the action: which tool was called, against which system, with what parameters, under whose authority, with what result, and whether it was permitted or denied. An inference log tells a supervisory authority that the model said something. An action log tells them what happened to a customer's account. Nothing in the frameworks says "log actions." ISO/IEC 42001's A.6.2.8 asks for AI system event logs, which for an agent isn't the same thing. When these instruments were drafted, there were no actions yet to log.

Risk management and incident reporting. Article 9 assumes risk can be characterized for a system with a defined intended purpose. An agent's risk profile is a function of its tool set, and its tool set changes when someone adds an MCP server. Article 73's serious-incident reporting assumes an incident is discrete and identifiable. An agent that has been quietly making a subtly wrong classification for six weeks across ten thousand records is not shaped like an incident, and the AI Act's reporting clock starts from awareness. Cataloguing an agent's risk therefore has to be tied to change control on its capabilities rather than done once at approval, which is exactly the "change management" point in Singapore's May update. That tie-in is a CI hook, not a filing cabinet.

Retention and Evidence, Side by Side

Regimes below are listed with the artifact each demands, the retention clock, and what it means for designing an agent audit log.

The payoff is a single engineering rule. Retention is not per-regime. It is per-log-store. If one agent in a shared platform touches investment services and another touches protected health information, the store that holds their action logs inherits a five-year clock from one and a six-year documentation clock from the other. If you cannot separate them cleanly, design for the longest clock that touches the store. Designing to the AI Act's six-month floor and discovering later that a healthcare use case has been running on the same platform is an expensive, retroactively unfixable mistake, because you cannot manufacture logs you deleted. Confirm the specific period with counsel before you set a deletion policy. The point here is only that six months is the wrong starting assumption.

Figure 2 — Compliance-evidence map. Each regulatory requirement resolves to specific fields on a single action record; the overlap is why this work is done once.

What to Produce Now

Because the requirements converge, the artifact list turns out to be short and largely regime-independent. What follows covers most of what any of these frameworks will ask for, and building it is squarely engineering's job, not legal's; classifying and retaining it is the other way around.

An inventory with regulatory classification per agent. Not a list of agents, but agents annotated with which regimes each one is in scope for, and why. Which are deployers of Annex III systems. Which touch investment services, protected health information, or consequential decisions about residents of a state with an ADMT statute. This is where every audit starts, and almost nobody has it done.

Action-level logs tied to two identities, not one. One record per consequential action, carrying the agent's identity and the human's identity on whose authority it acted, the tool, the target system, the parameters, the outcome, and whether the action was permitted or denied. Denied actions matter as much as permitted ones. They're the evidence that a control existed and functioned.

Documented human-oversight design. Written down: which action classes require human approval, who the assigned overseers are, what escalation looks like, and what the override rate and response time actually are. The measurements are what turns a policy document into evidence.

A risk classification per agent, tied to change control. The classification is a function of the agent's tool set, so it has to be re-evaluated when the tool set changes. An agent whose risk assessment predates its last three tool additions doesn't really have a risk assessment.

Change records. What changed, when, who approved it, and what the evaluation results were before and after. This satisfies ISO/IEC 42001's management-system expectations, the AI Act's quality-management and post-market-monitoring logic, and the "prevent small modifications from cascading" recommendation in Singapore's framework, all at once.

Of these five, the first two are pure engineering: nobody but the platform team can wire up per-agent classification tags or a two-identity log schema. The last two are shared, because engineering produces the evaluation results and the tool-set diff that legal then classifies. Only the oversight design genuinely splits down the middle. Legal decides who's accountable and what escalates. Engineering builds the dashboard that proves it happened.

At Agentic Fabriq the parts of this we build directly are the identity and evidence layers: two identities carried on every request so an action record can name both the agent and the user it acted for, action-level permissions enforced in the backend rather than described in a prompt, and audit logging backed by BigQuery and GCS with dashboard filters and NDJSON export through the API. Retention policy and regulatory classification remain yours to set, but the log field an auditor asks for is easier to produce when it was recorded at the enforcement point.

Conclusion

Nothing here is converging into a single standard, and planning as if it will is the mistake most teams are currently making. What keeps converging, regime after regime, is the evidence. Every one in the table above, whether it's binding law or just guidance, ultimately asks some version of the same three questions: what did this system do, on whose authority, and how would you prove it. An action-level log carrying agent identity and user identity, retained to the longest clock that touches it, answers all three.

The EU's high-risk deadline moved to 2027-12-02 for standalone Annex III systems and 2028-08-02 for embedded ones, so the AI Act is very likely not your binding constraint. Sectoral retention law already is, and has been for years. Singapore's is the only framework we've been able to find from a national authority written about systems that act rather than models that answer, which is why its recommendations read as operational advice while the others read more like translation exercises.

Sources

• Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI), OJ L, 2026/1744, 24.7.2026 — EUR-Lex
• Article 12: Record-Keeping — EU Artificial Intelligence Act
• Article 19: Automatically Generated Logs — EU Artificial Intelligence Act
• Article 26: Obligations of Deployers of High-Risk AI Systems — EU Artificial Intelligence Act
• Article 16: Obligations of Providers of High-Risk AI Systems — EU Artificial Intelligence Act
• EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes — Gibson Dunn, 2026-05-27
• EU AI Act unpacked #34: The final Digital Omnibus on AI — Freshfields
• Digital Omnibus on AI — European Parliament Legislative Train Schedule
• Digital Omnibus on AI — EPRS Briefing, European Parliament Think Tank
• Digital Omnibus on AI: Parliament Votes, Deadlines Redrawn — Dastra
• Singapore Launches New Model AI Governance Framework for Agentic AI — IMDA, 2026-01-22
• Model AI Governance Framework for Agentic AI, v1.5 (published 2026-05-20, updated 2026-06-05) — IMDA (PDF)
• Singapore Introduces New Model AI Governance Framework for Agentic AI — Bird & Bird
• Singapore: IMDA updates Model AI Governance Framework for Agentic AI — Baker McKenzie, June 2026
• Governing AI That Acts: Singapore's New Framework for Agentic AI — AI Asia Pacific Institute
• AI Risk Management Framework — NIST
• NIST AI Agent Security: Red-Teaming Guidance and Enterprise Compliance — Cloud Security Alliance
• ISO/IEC 42001 — Artificial intelligence management system
• What Are ISO 42001 Requirements? — Schellman
• Texas HB 149 (TRAIGA) — enrolled text, Sec. 552.105 presumption and liability shield
• CCPA updates: approved regulations text on ADMT, risk assessments and cybersecurity audits (§ 7200(b)) — California Privacy Protection Agency
• Colorado SB26-189: Automated Decision-Making Technology (signed 2026-05-14, effective 2027-01-01) — Colorado General Assembly
• State AI Laws — Where Are They Now? — Cooley, 2026-04-24
• AI Legislation: 2026 Legislative Wrap-Up — Epstein Becker Green
• FINRA Rule 4511: General Requirements (4511(b), six-year default) — FINRA
• 17 CFR 240.17a-4 — Records to be preserved by certain exchange members, brokers and dealers
• Regulation (EU) No 600/2014 (MiFIR), Art. 25 — five-year order and transaction records — EUR-Lex
• Directive 2014/65/EU (MiFID II), Art. 16(6)–(7) — EUR-Lex
• 45 CFR 164.316 — Policies and procedures and documentation requirements