The EU AI Act entered into force in August 2024. Its provisions roll in on a staggered timeline — some obligations for high-risk AI systems apply from August 2026, with others extending to 2027. If you're deploying agents in an EU business or serving EU customers, this is now a practical consideration rather than a future one.

This isn't legal advice. We're a software company, not a law firm. What follows is our read of the regulatory landscape as it applies to the kinds of agents we build and deploy — mostly for B2B operations, in areas like procurement, finance operations, customer data processing, and internal workflow automation.

The core distinction: who is a "deployer"

The Act distinguishes between "providers" — organisations that develop or place AI systems on the market — and "deployers" — organisations that use AI systems in a professional context. If you're buying an AI agent from a vendor and using it inside your company, you're a deployer.

Most of the heavy obligations in the Act fall on providers. But deployers have their own set of requirements, and they matter.

As a deployer, your primary obligations include: conducting fundamental rights impact assessments where required, ensuring your use of the AI system complies with the instructions provided by the provider, implementing human oversight mechanisms where the system is classified as high-risk, and maintaining logs of your system's operation for the periods specified in the Act.

What counts as high-risk

This is where most organisations using agents need to spend time. The Act classifies AI systems as high-risk based on the domain they operate in and the decisions they influence. High-risk categories include: AI used in recruitment or employee management, AI used in credit scoring or insurance, AI used in determining access to public services, and AI used in critical infrastructure management.

Many of the agents we build — procurement automation, supplier evaluation, internal process routing — are not obviously in these categories. But the classification depends on what the agent actually does and what decisions it influences, not just what it's called.

An agent that routes invoices for payment approval is different from one that scores suppliers against credit criteria. An agent that summarises meeting notes is different from one that generates performance evaluations. Where exactly your agent sits depends on a careful look at the outputs it produces and how those outputs are used.

If you're not sure, the honest answer is to do the assessment. The Act requires deployers of high-risk systems to conduct fundamental rights impact assessments before deployment. Even if you conclude you're not in high-risk territory, having gone through the analysis is useful — it clarifies what your agent does, and it's a reasonable baseline for any compliance conversation.

Human oversight: what the Act actually requires

For high-risk AI systems, the Act requires that deployers implement measures allowing human oversight. The language is deliberately functional: oversight means the ability to understand, monitor, and where necessary override the system's outputs.

This maps closely to how we think about supervised agents. If you have a clear checkpoint where a human reviews the agent's proposed action before it's executed — and the human has the information they need to make a real decision, not just rubber-stamp an output — you're in roughly the right territory.

What fails this standard: a human in the loop who reviews a summary rather than the underlying data; a confirmation step where the default is "approve" and the cognitive load of reviewing makes meaningful oversight impractical; a system where the pace of throughput makes per-item human review theoretically possible but practically nonexistent.

The oversight requirement is functional, not formal. A checkbox doesn't satisfy it. The question is whether a human operator, in practice, can and does exercise meaningful judgment at the point where judgment matters.

Transparency to workers

The Act includes specific requirements about transparency when AI systems make or significantly influence decisions about workers or interact with workers in their professional tasks. Deployers must inform workers — or their representatives — that they are working alongside AI systems, and what those systems do.

This is one of the more practical near-term requirements for companies deploying internal automation. If you're rolling out an agent that handles tasks your operations team previously did manually, the affected team needs to know the agent exists, what it handles, and how to flag issues or escalate.

This isn't just compliance — it's operationally sensible. Agents that your own team doesn't understand don't get used effectively, and errors go unreported.

Record-keeping and logs

Deployers of high-risk systems must retain logs of the system's operation for defined periods — typically six months minimum, with longer periods applying in certain regulated contexts. For non-high-risk systems, there's no mandatory logging period, but having logs is still useful for debugging and audit purposes.

When we design agent systems, we build logging into the architecture by default: what tasks were run, what tools were called, what outputs were produced, and any error or escalation events. This isn't specifically for regulatory reasons — it's what good operations infrastructure looks like. The Act's requirements largely align with what sensible production engineering looks like anyway.

What this means practically

If you're deploying agents in an EU context in 2026, the practical steps are:

First, map what your agent does and what decisions it influences. Be specific. "Processes invoices" is not specific enough. "Matches received invoices to purchase orders, flags discrepancies above €500 for human review, and routes approved invoices to the payment queue" is specific.

Second, run through the high-risk classification criteria honestly. If you're anywhere near the edges, do the impact assessment.

Third, document your human oversight mechanisms. Not as a compliance exercise — as an operational one. Who reviews what, when, and with what information. If the answer is "no one reviews anything," that's a problem regardless of regulatory classification.

Fourth, make sure affected workers know what the agent does and how to raise concerns. This is a one-time communication task for most deployments, not an ongoing burden.

Fifth, talk to a lawyer who specialises in this area before making any formal compliance determinations. The Act is new, interpretation is still developing, and the specifics of your situation matter in ways a general article can't capture.

A note on the vendor landscape

There's a growing wave of vendors claiming their products are "EU AI Act compliant." Treat this cautiously. Compliance is mostly about how you use a system, not which system you buy. A vendor who claims their tool is compliant is typically saying that their tool can be used in a compliant way — which is different from saying that your deployment of it will be compliant.

The obligations that matter — impact assessments, human oversight, worker transparency, logging — are on you as the deployer. A vendor certificate doesn't discharge those.

What vendors can legitimately provide: documentation about how their system works, technical transparency about model outputs, logs and audit trails, and contractual commitments about how your data is handled. Those are useful. "We're compliant" as a selling point isn't.