The EU AI Act: What It Actually Means for Your Agent Stack

The EU AI Act (Regulation 2024/1689) has been in force since August 2024, but the high-risk provisions, the ones with teeth, become fully enforceable on 2 August 2026. If your agents serve EU markets or touch data about EU residents, that date applies to you regardless of where your company is incorporated.

Article 99 sets the ceiling: up to 35 million euro or 7% of total worldwide annual turnover, whichever is higher, for the most serious violations. Lower tiers apply to lesser breaches, but the number that gets a board's attention is that one. It is calculated on global revenue, not EU revenue.

Most coverage of the Act is written for policy and legal audiences. This is written for the person who has to build the thing, with the articles that translate into code separated from the ones that do not.

Does it apply to you?

The Act covers AI systems "placed on the market or put into service in the Union." If EU residents use your agent system, including employees at EU-based companies rather than only consumers, it applies. Extraterritorial reach is deliberate and works the way GDPR's does: incorporation elsewhere is not an exemption.

High-risk classification drives most of the concrete obligations. The listed categories include employment decisions, access to essential services such as credit and insurance, law enforcement, and administration of justice. Plenty of B2B agent products do not land squarely in those categories, and it is worth reading Annex III properly rather than assuming. But two things catch teams out. The general obligations around transparency and record-keeping reach further than the high-risk list. And an agent that screens CVs, scores loan applications, or routes support tickets that determine service access is closer to a listed category than its builders usually assume, because the classification follows what the system decides rather than what the product is called.

The articles that become engineering work

Four articles turn into things you build. One does not, and being clear about which is which saves a lot of wasted effort.

Article 12: record-keeping

This is the one that most often forces an architecture change. Article 12 requires high-risk systems to automatically record events over their lifetime, with logging capabilities that enable traceability of the system's operation, and it requires those records to be robust against manipulation.

That phrase is doing enormous work, and it is where most existing setups fail. A database table is not robust against manipulation. Anyone with write access can update a row, and nothing downstream can tell. Application logs shipped to a log aggregator are not robust against manipulation either: retention is a setting, deletion is an API call, and the absence of a record is indistinguishable from an event that never happened.

Robustness against manipulation has to be a property of how the record is constructed, not a policy telling people not to touch it. In practice that means each entry is cryptographically chained to the one before it, so altering an entry breaks the chain visibly, and a deletion shows up as a gap rather than as silence. The test to apply to any candidate system is simple: if someone with full database access edited one record, would anyone be able to tell? If the answer is no, it does not satisfy Article 12 no matter how thorough the logging is.

Two practical notes. First, the traceability obligation is about the system's operation, not the subset of traffic that happened to be routed through your control layer, so coverage is part of the requirement rather than separate from it. Second, retention minimums apply, and the record you are not generating today cannot be backfilled later. That asymmetry is the reason this is the article to start with.

Article 9: the one that is not your software's job

Article 9 requires a risk management system running as a continuous process across the lifecycle: identify known and foreseeable risks, evaluate them, put mitigations in place, and keep doing it.

It is worth being blunt here, because vendors are not always. Article 9 is an organizational process obligation, and no telemetry or governance product satisfies it for you. A tool can produce evidence that feeds your risk management system, and enforcement controls like allowlists and spend caps can be the technical shape of a mitigation you decided on. But the identification, the evaluation, the documentation, and the review cadence are yours. Any vendor implying their product covers Article 9 is selling you something that will not survive contact with an assessor.

obsvr maps evidence to the articles where captured telemetry genuinely answers the obligation. Article 9 is deliberately not one of them.

Article 13: transparency

Article 13 wants high-risk systems to be transparent enough that users can interpret the output and use it appropriately. For an agent, that means being able to explain not just what it did, but why - the reasoning behind the action, not only the outcome.

This is the argument for logging LLM calls with the same rigor as tool calls. The tool call is what happened. The LLM call is what the model was thinking when it decided to do it. You need both to satisfy transparency in any meaningful sense.

Article 14: human oversight

Article 14 wants humans able to intervene on the operation of a high-risk system - not review logs afterward, actually intervene while it's running.

A human approval flow wired into the point where an action would execute is the clearest way to build that. The agent pauses, someone reviews the proposed action, allows or denies it, and the decision gets logged with a timestamp that can't be quietly altered later. That's what meaningful oversight looks like in an actual system, as opposed to a policy document.

What an assessor actually asks

The gap between "we have logging" and "we can evidence Article 12" usually becomes visible in four questions. They are worth rehearsing against your own stack before someone external asks them.

Show me what this specific system decided on this specific date. Not a dashboard aggregate. One decision, reconstructed: the input, the policy in force at that moment, the outcome. This is harder than it sounds, because the model behind a stable name like gpt-4o may have been updated since, and your policy has probably changed a dozen times. If the record does not pin the resolved model version and the exact ruleset, the reconstruction is a guess.

How do you know this is all of it? A complete-looking log and a partially-bypassed one are indistinguishable from the artifact alone. Whatever answer you have needs to account for traffic that did not pass through your control layer, not just describe how well the layer records what reaches it.

Who could change this record, and would you know? The honest answer for most stacks is "anyone with production database access, and no." That is the answer Article 12 is written to make unacceptable.

Can someone verify this without trusting you? An audit trail a vendor attests to is weaker than one an auditor can check independently. If verification requires calling your API and believing the response, the vendor is inside the trust boundary of their own evidence.

Minimum posture, and the honest timeline

If your agents fall under the high-risk provisions, the floor is: tamper-evident logging that satisfies the manipulation-robustness test above, pre-call policy enforcement rather than after-the-fact detection, a real mechanism for a human to intervene during operation, and the ability to export a complete, independently verifiable trail on request.

Instrumenting a system that already exists is a days-to-weeks project. Redesigning one is not, and at this point in the calendar the redesign path has run out of room. If you are starting now, start with Article 12, because it is the only obligation with a retroactive component: oversight and transparency can be added the day you add them, but the record for the period before you started capturing it does not exist and cannot be reconstructed.

One more thing worth saying plainly, because the compliance conversation tends to obscure it. Everything above is also just a good idea. A system where you can reconstruct any decision, prove the record was not edited, and demonstrate that nothing was routed around the controls is a system you can debug, defend in an incident review, and hand to a customer's security team. The regulation sets a deadline for work that was worth doing regardless.