EU AI Act's High-Risk Rules Meet the AI Agent Boom

EU AI Act high-risk rules and AI agent governance — monochrome illustration of gears arranged inside a frame, a metaphor for governance and control

AI & Software · 2026-07-08 · 7 min

AI agents are moving from 'can we build it' to 'can we govern it.' With the EU AI Act's high-risk rules approaching, we walk through the design assumptions behind our own automation practice.

In an August 2025 press release, Gartner predicted that 40% of enterprise applications would embed task-specific AI agents by the end of 2026, up from under 5% in 2025.

Around the same time, in a separate press release, Gartner made a second prediction that gets quoted far less often: more than 40% of agentic AI projects will be canceled by the end of 2027.

Adoption is accelerating, and failure is expected to run at roughly the same rate. That is the honest state of enterprise AI agents in mid-2026.

This article looks at why “can we build it” has largely stopped being the hard question, and “can we govern it” has taken its place — through the lens of how we run our own automation.

When Regulation Turns From Aspiration Into a Deadline

The clearest signal is the EU AI Act’s high-risk provisions.

AI systems used for specific purposes — credit scoring, employment decisions, insurance underwriting among them — are classified as “high-risk,” and their obligations are expected to become fully applicable on August 2, 2026 (as of this writing in July 2026; EU institutions are discussing possible adjustments to the timeline, so the final scope and date could still change).

Covered organizations are expected to face requirements such as conformity assessments, human oversight mechanisms, log retention of at least six months, and fundamental rights impact assessments.

These rules read as an EU-specific concern, but in practice, requirements like this tend to shape the design baseline for services that operate globally.

Most companies that wanted to build a working AI agent have largely managed to do so over the past couple of years.

What’s being tested over the coming months is a level up from that: can you explain what the agent did, and can you show who was authorized to delegate what to it.

Infrastructure Vendors Are Building for Governance, Too

This shift shows up on the vendor side as well.

On June 29, 2026, Anthropic introduced the Claude apps gateway — a self-hosted control plane for organizations running Claude Code at scale.

Instead of distributing per-developer credentials, it integrates with corporate single sign-on and lets organizations set role-based access and spend limits centrally, by user, group, or organization.

The notable part isn’t the feature list itself — it’s that usage tracking and spend caps are now offered as built-in infrastructure rather than something each team bolts on with individual API keys.

As we read it, this reflects a broader move: what an AI agent is allowed to do is becoming a matter of organizational policy design, not individual judgment call by whoever happens to be using it.

In short, the unit of governance is shifting from the person to the system.

What We Assume in Our Own Automation Practice

We build and run our own automation — including the content pipeline behind this blog, and our day-to-day bilingual publishing workflow — with Claude Code at the core.

The starting assumption we work from is simple: automation you can’t explain is automation you can’t safely stop.

If you can’t trace why an automated process produced a given output, or which steps it went through, you also can’t tell what to fix when something goes wrong.

That assumption shows up in a few concrete design choices:

  • Every generated output goes through a two-pass detect-and-fix-and-reverify cycle before moving to the next step
  • Even in unattended runs, outputs are saved as drafts, and a human makes the final call to publish (human-in-the-loop by default)
  • Each step’s decisions — what was adopted, what was set aside — are kept as a record

We didn’t design this to satisfy a regulator.

It’s a plain design principle for making our own automation something we’re comfortable delegating to.

As it turns out, though, it lines up fairly closely with what the EU AI Act asks for in terms of human oversight and log retention.

Before diving into the details of any specific regulation, it’s worth first checking whether your own automation can already explain what it did — that alone tends to shrink the compliance burden considerably.

Monochrome illustration of a steering-wheel-like control dial connected to small orbiting gears, a metaphor for human oversight of automated agents

Practical Checkpoints Before You Roll Out

Regardless of which regulation applies to you, here are a few concrete things worth checking before expanding what an AI agent is allowed to do.

Decide “who” and “how far” before anything else

Design permissions around roles, not individual discretion.

Prep work and public-facing decisions call for very different levels of delegation, even within the same workflow.

Skip this step and you tend to end up, months later, unable to say who authorized what — usually the first thing that breaks.

Design logs for accountability, not just incident response

Don’t just keep logs for debugging outages — keep them at a level of detail that lets you explain, to someone outside the team, why a given output came out the way it did.

Generative AI outputs aren’t fully reproducible, so without a record of what went in and which steps it passed through, there’s no real way to reconstruct an explanation after the fact.

Build the “off switch” before you scale up

Expanding scope before permissions and logging are in place means there’s no clean way back if something goes wrong, and the blast radius grows with the scope.

We make a point of deciding how to detect and roll back an anomaly before widening any automation’s reach, not after.

Treat regulation as a prompt to reassess, not a finish line

Rules like the EU AI Act are binding deadlines for the organizations they cover, but even for companies outside their scope, they’re a useful benchmark for how far competitors are building out their own governance.

The regulatory floor doesn’t have to become your target.

We think it’s more useful as a prompt to audit how explainable your own automation already is, using the regulation’s bar as the yardstick.

Common Misconceptions

“It’s too late to start with AI agents now” — we don’t think that’s true.

Gartner’s 40% figure cuts both ways: it also means well over half of companies haven’t started yet.

And the same research firm’s other prediction — that over 40% of agentic AI projects get canceled — is a reminder that being early hasn’t guaranteed success either.

Expanding scope quickly isn’t valuable on its own; what matters is whether the scope you delegate is matched by the governance design behind it.

“Building governance slows down the whole point of AI agents, which is speed” — this is also only half right, in our view.

Permission design and logging genuinely add upfront overhead.

But that overhead converts into a different kind of speed: the ability to identify a cause quickly and roll back cleanly when something goes wrong.

In our experience, automation that scaled without governance in place is the kind that eventually loses speed anyway — because nobody can tell what’s happening well enough to stop it.

“Compliance is legal’s job, not engineering’s” — not really, for the parts that matter here.

Permission design, logging design, and shutdown procedures are the kind of thing that’s hard to retrofit once a system is already built; they need to be part of the implementation from day one.

Keeping legal’s bar in view from the early implementation stages tends to mean far less rework later.

Takeaway

If there’s one way to summarize where enterprise AI agents stand in the second half of 2026, it’s a shift in center of gravity: from “can we build it” to “can we govern it.”

A regulatory deadline like the EU AI Act’s, and the governance infrastructure vendors are starting to ship, both point in the same direction.

The assumptions we apply to our own automation — detect-fix-reverify, human-in-the-loop, a design that can always be stopped — weren’t built for regulatory compliance in the first place.

But as regulation and industry norms catch up, we’re finding that these fairly unglamorous design principles are getting validated from an unexpected direction.

Before expanding what your AI agents are allowed to do, we’d suggest starting with a simple question: can you currently explain what your automation is doing, how far its reach extends, and why?

Note: Statements about regulation and statistics in this article reflect information available as of July 2026. The scope and timeline of the EU AI Act may still change as the underlying process continues. Please confirm the latest official guidance before making any compliance decisions.

Back to articles