“Are we even allowed to use AI agents under the AI Act?” is a question we hear constantly from EU businesses evaluating automation. The short answer is yes — the overwhelming majority of business AI agents (support, booking, lead qualification, internal workflow automation) fall well outside the Act’s high-risk or prohibited categories. But “probably fine” isn’t a compliance strategy, and the Act does introduce real obligations that depend on exactly what your agent does and what data it touches.
This is a practical starting point, not legal advice — for anything customer-facing, involving employment decisions, or otherwise sensitive, involve your own legal counsel. What follows is the framework we use when scoping AI agent projects for EU clients.
First: work out which risk tier your agent falls into
The EU AI Act sorts AI systems into risk tiers, and your obligations scale with the tier, not with the technology itself. Two agents built on the same underlying model can sit in completely different tiers depending on what they’re used for.
Unacceptable risk (prohibited). A narrow list of practices banned outright — social scoring, manipulative techniques designed to bypass someone’s free will, certain biometric categorisation and untargeted facial-recognition scraping. Almost no legitimate business automation use case comes close to this category; it’s worth confirming, but it’s rarely where the real work is.
High risk. This is the tier that requires genuine diligence. It covers AI used in specific listed areas — such as employment decisions (screening candidates, evaluating performance in ways that affect job outcomes), credit scoring, and certain safety-critical or essential-services contexts. If your agent influences whether someone gets hired, gets credit, or gets access to an essential service in a way that has legal or similarly significant effect on them, assume high-risk obligations apply and plan for them from the start — conformity assessment, technical documentation, human oversight, and a registered quality-management approach.
Limited risk (transparency obligations). This is where most customer-facing business agents land: chatbots, voice agents, and AI systems that interact directly with people. The core obligation is straightforward — people need to know they’re interacting with an AI system, unless it’s obvious from context. This is a disclosure requirement, not a restriction on capability.
Minimal risk. Most internal automation — an agent that triages internal tickets, drafts reports, or moves data between systems without materially affecting a person’s rights or opportunities — carries no specific obligations beyond general good practice.
The practical takeaway: before building anything, map what the agent actually decides and who it affects. An AI agent that answers customer questions and books appointments is a different regulatory conversation than one that screens job applicants.
What “limited risk” transparency actually looks like in practice
For the majority of business agents — the support bots, booking assistants, and lead-qualification agents that make up most deployments — compliance mostly comes down to disclosure done properly, not architectural restrictions:
- Tell people they’re talking to an AI, clearly and early in the interaction, unless it would be obvious to a reasonable person (a website chat widget labelled “AI Assistant” usually satisfies this on its own).
- Make the disclosure genuine, not buried. A line in a footer terms-of-service page doesn’t meet the spirit of the requirement if the interaction itself gives no indication.
- Keep a path to a human. Especially for anything with real stakes for the customer — a complaint, a refund dispute, a cancellation — the agent should be able to hand off cleanly rather than trap someone in an automated loop.
None of this requires giving up capability. An agent can still resolve most conversations end-to-end; it just needs to be honest about what it is while doing so.
Governance obligations that apply regardless of risk tier
A few practical requirements apply more broadly than the risk-tier framework suggests, and are worth building in from day one regardless of what your agent does:
- Human oversight. Someone needs to be able to monitor, intervene in, and if necessary override what the agent does — not as a theoretical safeguard, but as an actual reviewable process with logs.
- Record-keeping. Being able to show what the agent did, when, and on what basis matters both for your own debugging and for answering a regulator or customer question later.
- Vendor and model transparency. If you’re using a third-party model provider, you should be able to answer basic questions about it — what data it was trained on, where it’s hosted, whether your data trains their model — the same due diligence you’d expect for GDPR sub-processors.
- AI literacy. The Act expects organisations deploying AI to ensure staff operating or overseeing it have a reasonable understanding of how it works and its limitations — not a certification requirement, but a real internal competence, not tokenism.
How this interacts with GDPR
The AI Act and GDPR overlap heavily in practice, and most EU businesses find that a well-designed GDPR-compliant deployment already covers much of the AI Act’s spirit — lawful basis, data minimisation, human oversight for significant automated decisions. If your agent processes personal data (nearly all customer-facing agents do), both frameworks apply simultaneously, and the practical checklist — map the data flow, confirm lawful basis, get DPAs in place, keep processing EU-based where it matters, keep a human in the loop for decisions with real effect — satisfies most of both.
A practical adoption path
For most EU businesses adopting AI agents, a workable sequence looks like this:
- Classify before you build. Identify what the agent will decide and who it affects, and place it in the right risk tier before writing a line of workflow logic.
- Start with limited-risk use cases. Support, booking, lead qualification and internal workflow automation deliver strong ROI without the heavier obligations of high-risk categories — a sensible place for most businesses to start.
- Build disclosure in from the start, not as an afterthought once something ships.
- Choose vendors and infrastructure that can answer your due-diligence questions directly — data residency, sub-processor chains, model training policy — rather than vague reassurance.
- Document as you go. Keep a simple record of what the agent does, what data it touches, and who can intervene, so you’re not reconstructing this after the fact.
- Revisit as capability grows. An agent that starts as a support tool but later starts influencing hiring or credit decisions needs to be re-classified, not just extended.
None of this makes adoption slower in any meaningful way — treating it as a design constraint from the outset, the same way you’d handle GDPR, means you build once and don’t face expensive rework later. Most of our custom AI agent and AI customer support deployments for EU clients ship in the same 2–4 week timeline whether or not the Act is part of the conversation — the difference is just building it in from the start.
If you’re weighing up AI agents for your business and want a clear-eyed read on where your specific use case sits under the Act, get in touch and we’ll walk through it with you.