The EU AI Act and AI Agents: What It Means When You Deploy Them

The EU AI Act, Europe’s regulation on artificial intelligence, does not ask you to prove your AI is perfect. It asks you to know what you are deploying, classify it by its risk, document how it works, and tell affected people that an AI is involved. If you deploy agents in your internal operations, this is not a distant formality: it is a list of obligations that depend on what you use the agents for, and worth looking at before you put an agent in charge of decisions about people or money.

A note on method: I describe the framework in general, verifiable terms. I do not cite numbered articles or specific application dates, because the detail shifts and a precision error is costly, and the statute itself is where the exact wording lives. What I can give you is the lens an executive should read it through.

The risk-tiered approach

The core idea of the regulation is simple: not every AI application is treated the same. Obligations grow with the risk of the use, not with the sophistication of the technology. The same model can fall into different categories depending on what you use it for. Broadly, the framework separates prohibited uses, high-risk uses with demanding obligations, uses carrying transparency duties, and minimal-risk uses with light requirements.

The practical consequence is that the first question is not technical, it is a business one. It comes down to what this agent decides, and about whom. An agent that reconciles internal invoices and one that influences a person’s access to a job, a loan or an essential service are not on the same regulatory plane, even if under the hood they use the same class of model. Most of the back-office agents I work with fall into the low-risk or transparency categories, but that has to be determined case by case, not assumed.

Transparency: saying there is an AI

One of the most cross-cutting obligations in the framework is transparency. When a person interacts with an AI system, or when a decision affecting them was made with help from one, they have a right to know. For a company deploying agents, that translates into concrete things: a customer talking to your support should know whether an agent is handling them, an employee should know when an internal process is run by an AI, and that information should not be buried in a clause.

Transparency is not only outward-facing. It is inward too: whoever operates the system has to understand what it does, within what limits, and when it escalates to a person. An agent acting in ways no one in the house can explain is, on top of an operational risk, a compliance problem. The human in the loop is not just good engineering: it is the piece that makes the system explainable.

Documentation: being able to prove what you do

The second large block is documentation and record-keeping. The framework expects whoever deploys AI, especially in higher-risk uses, to be able to describe what the system does, with what data, under what controls and with what human oversight, and to keep records of its operation. The logic is that of any regulated activity. Complying is not enough, you have to be able to prove it.

This is where engineering and compliance meet. The traceability I recommend for operational reasons —every agent action with its context, the rule applied and the reason— is exactly what lets you answer an auditor. If the system already records what it did and why, regulatory documentation stops being a separate exercise and becomes a query against what you already hold. How that evidence is built case by case is in auditing AI agent decisions, and the controls that produce it are in agent permissions and controls.

Who is responsible

The question boards raise most is who answers to the regulator if the agent fails. The framework distinguishes roles along the chain. Simplified, whoever builds and places an AI system on the market carries one set of obligations, and whoever deploys it for a specific use in their organization carries another. That second role, the company using the agent in its operation, is yours.

Having a provider behind the system does not transfer your responsibility as the company using it. You choose the use, set the limits, supervise, and answer to your customers and to the authority for what happens in your operation. That is why I insist so much on owning the operating architecture. The rules, controls and traces that define how your agent behaves should be yours and documented, not locked inside a third party’s box. That separation, which I treat in data privacy and GDPR from the data angle, is also what underpins AI Act compliance.

What to do today, without waiting for the fine print

You do not need a full legal opinion to start being on the right side. These steps cover the part that depends on you as the deploying company:

• Inventory your AI uses. Which agents you have, what they decide, and about whom. Without this map you cannot classify risk, and classification is the first duty. The shadow AI circulating uncontrolled is precisely what breaks this inventory.
• Classify by use, not by technology. Separate what touches people and sensitive decisions from what is bounded internal back office.
• Document and record by design. Traceability, limits and human oversight written down before deployment, not after an inspection.
• Set transparency toward customers and employees. Make it known when an AI is involved.

This work is not an obstacle to deployment, it is part of serious deployment. It fits inside the AI agent governance framework, rests on the encoded operating model, and is part of what I review in prepare your company for agents. The rest of the risks surrounding this one, from the silent error to vendor dependency, are laid out in AI risks for business. And the entry point to all of it is in AI agents for business.

Frequently Asked Questions

Does the EU AI Act affect my company if I only use agents in internal processes?

Yes, internal use is not exempt. Obligations depend on the risk of the use, not on whether it is internal or external: an agent deciding about employees or sensitive data can carry demanding requirements even if it never speaks to a customer. Most back office falls into lighter categories, but that has to be determined by classifying each use, not by assuming it.

Who is liable if an AI agent makes a mistake, the provider or my company?

The framework splits obligations between whoever builds the system and whoever deploys it for a specific use. As the company using the agent in its operation, you choose the use, set the limits and supervise, so you answer to your customers and to the authority for what happens. Having a provider behind you does not transfer that responsibility, and that is why the controls and traces should be yours.

What is the first thing I should do to comply with the AI Act?

Inventory your AI uses and classify them by risk. You cannot comply with what you do not know you have, and uncontrolled employee use breaks that inventory before you start. With the map in hand, you prioritize documentation, traceability and transparency in the higher-risk uses.

Do I need specialized lawyers to deploy agents?

For the fine classification of sensitive uses and for your sector, advice is worthwhile. But much of compliance depends on engineering you control: documenting what the agent does, recording its decisions, setting limits and oversight, and informing affected people. If that is designed in from the start, the legal work operates on something orderly instead of on an opaque system.