The EU AI Act Will Grade Your Logs, Not Your Model

A compliance lead at a regulated company asks the team running their AI agent one thing: for the agent touching our HR and finance systems, show me every action it took last quarter.

Most teams can answer half of that. They have the model version, the prompt, and the framework the agent runs on. What they often can’t produce is a per-action record of what the agent read and what it wrote — which system, which record, when, and under whose review.

On August 2, 2026, that question stops being a courtesy and becomes law.

What actually becomes enforceable on August 2

The EU AI Act’s obligations for high-risk systems take effect on August 2, 2026. If you deploy an AI agent in a professional capacity inside a regulated function and don’t substantially modify the underlying model, you are almost certainly a “deployer” under the Act, and the deployer obligations land on you.

There has been noise about a delay. A vote to push the high-risk deadline to December 2027, part of the Digital Omnibus package, reached a provisional agreement in May 2026 and passed Parliament. It still needs Council adoption, so it isn’t law. Until it is, August 2 is the operative date, and the relevant logs are not something you can backfill the week before an audit.

The penalty for primary high-risk violations runs up to €15 million or 3% of global annual turnover, whichever is higher. That is large enough that “we’ll sort out logging later” is not a strategy.

The law asks what your agent did, not how smart it is

Three articles do most of the work here, and none of them describe a model.

Article 26 is the deployer’s core duty. It requires you to keep the automatically generated logs your high-risk system produces for at least six months, to assign human oversight to the system, and to use it within the provider’s documented instructions.

Article 12 sits on the provider side and requires the system to generate those logs in the first place. It is record-keeping by design.

Article 14 requires human oversight to be built into how the system is used, not bolted on after deployment.

Read together, the obligation is a record of behavior: every action the agent took, against which system, and who could see it. That is not a property of GPT-5, Claude, or Gemini. You could swap the model tomorrow and your compliance position would not change, because the law is grading the trail your agent leaves, not the intelligence that produced it.

This is where the gap shows up in real deployments. Teams instrument the model heavily. They version prompts, track token spend, run evals, and log completions. The action layer, where the agent actually writes to an ATS, updates a CRM record, or pulls a payroll field, is where logging is thinnest, and it’s exactly the part Article 26 cares about.

Human oversight is more than an approval prompt

Article 14’s requirement for human oversight is easy to misread as “add an approval step.” Wire a confirmation prompt in front of the agent’s writes and call it oversight.

That control degrades fast. We’ve written before about why human-in-the-loop fails as an AI agent guardrail: when a person approves the same routine request fifty times a day, the fifty-first gets rubber-stamped too. Oversight that depends on sustained human attention is the first thing to break under volume.

The version of oversight that holds up is structural. Scope each action to what the agent is allowed to touch, gate the genuinely risky ones, and write every call to a log a reviewer can read later. A human reviewing a clean, queryable record after the fact is doing real oversight. A human clicking “approve” on autopilot is not, and an auditor will see the difference.

There’s a related identity problem underneath all of this. As the Fedora rogue-agent incident showed, if your systems can’t tell an agent’s actions apart from a human’s, you can’t audit them afterward either. A six-month log is only useful if each entry names the actor.

Compliance lives at the action layer

The practical consequence is that EU AI Act readiness for an agent is mostly an integration and logging question, not a model-selection question.

You need three things to be true at the point where the agent acts:

• The credential is scoped to that agent and that action, not a shared key with full access
• Every call is recorded with enough detail to reconstruct what happened
• High-risk actions can be held for review without depending on someone watching a queue all day

Scoping the credential to the agent rather than handing it a shared key is the foundation, which is why owning the OAuth app behind an AI agent matters: the agent gets scoped permission to act without ever holding the password. If those three things hold, the compliance lead’s question has an answer before anyone asks it. If they don’t, no amount of model quality closes the gap.

This is the layer we build at StackOne. An agent acts as itself, every action is scoped and checked before it runs, and every call is logged across 410+ connected systems, with the permission check completing in under a millisecond. Read access and write access are granted separately, so “list candidates” and “delete a record” are different permissions rather than one blanket grant. The point isn’t that this makes you compliant on its own. It’s that the record an auditor wants is produced as a byproduct of how the agent acts, rather than reconstructed under deadline pressure.

For deployers in HR, finance, and other regulated functions, that distinction is the whole game. Under the Act, an agent whose actions you can reconstruct on demand matters far more than one that tops a benchmark.

Where to start

If you run agents inside regulated functions, the useful question before August 2 isn’t which model to use. It’s whether you could produce six months of per-action logs today, and whether your scoping and oversight live below the agent or depend on people remembering to look. If the audit trail is something you’d have to assemble after the fact, that’s the work to do now.

StackOne’s documentation covers how scoped actions and per-action logging work across connected systems, if you want to see how the action layer fits your stack: docs.stackone.com.