The EU AI Act: What Actually Applies to You

Most EU small businesses running a customer-facing AI voice agent or support chatbot are deployers of a lower-risk system, not providers of a high-risk one. That means a short, manageable set of duties: tell people they are talking to an AI, use the system as documented, keep human oversight real, and keep meeting GDPR.

A note before anything else. This article is general information written for business owners, not legal advice, and it does not create a lawyer-client relationship. Regulation is interpreted in context, national authorities and guidance evolve, and your sector may carry additional rules. Before you rely on any of this for a specific decision, consult a qualified adviser who can look at your actual deployment.

What the EU AI Act is, in plain terms

The EU AI Act is the European Union's horizontal regulation for artificial intelligence. Horizontal means it is not written for one industry. It applies across sectors, in the same way GDPR applies to a dental practice and a logistics company alike, and it is built around a single organising idea: the rules that apply to an AI system should be proportionate to the risk that system creates for people.

That framing is worth holding on to, because most of the anxiety around the Act comes from reading headlines written about frontier models and assuming they describe your appointment booking assistant. They usually do not. The obligations that make the news, the technical documentation packages, conformity assessments, quality management systems and post-market monitoring, attach to specific categories of system and to specific roles in the supply chain. A five-person plumbing firm whose phone is answered by an AI assistant is in a very different position from a company building and selling the underlying model.

What the Act does do, for practically everyone, is formalise two intuitions that good operators already had. First, people should not be deceived about whether they are talking to a machine. Second, someone identifiable should be responsible for how an AI system behaves in the real world. Almost everything a small or mid-sized service business needs to do flows from those two points.

The Act also expects organisations that provide or use AI systems to make sure the people operating them have an adequate level of understanding, which the Commission describes as AI literacy. For a small business this is not a training programme. It means the receptionist covering escalations, the practice manager, and whoever reviews transcripts each week actually understand what the assistant can and cannot do, where it tends to fail, and how to take over.

How the risk tiers work, and where a voice agent usually sits

The European Commission describes four bands. At the top sit practices of unacceptable risk, which are prohibited outright because they represent a clear threat to people's safety, livelihoods and rights. Below that is high risk, covering uses that can pose serious risks to health, safety or fundamental rights. Then comes transparency risk, which is exactly what it sounds like: uses where the main concern is that people should know what they are dealing with. At the bottom is minimal or no risk, which the Commission notes covers the vast majority of AI systems currently used in the EU.

Where does a front-office assistant land? A system that greets callers, answers questions about opening hours and services, takes a message, books or moves an appointment, and transfers anything unusual to a human is, in the ordinary case, a transparency-band system. It is not making consequential decisions about a person's access to employment, education, credit, essential services or legal rights. It is handling the same routine traffic a receptionist handles, and the principal concern is that the caller knows it is automated.

That is the ordinary case, and it is worth being precise about what could move a deployment out of it. Risk classification under the Act follows the intended purpose of the system in its context of use. If you extend a voice assistant so that it triages medical urgency and tells patients whether they need to be seen, you have moved into a domain where health outcomes depend on the system's output. If you use conversational AI to screen or rank job applicants, you are in the employment domain. If you attempt to infer a caller's emotional state and act on it, you are in territory the Act treats with particular suspicion. None of that is theoretical for a clinic or an agency that keeps adding capabilities to an assistant that started out simply answering the phone.

The practical rule is simple. Classification is not a property of the technology, it is a property of the job you give it. Write down what your assistant is for, in one paragraph, in the language of tasks rather than features. Reassess when that paragraph changes. If you are still deciding what the assistant should do, our note on what an AI receptionist actually is sets out the realistic scope of the role.

Do you have to tell callers they are speaking to an AI?

In substance, yes, and this is the obligation that will touch your business most directly. The Commission's overview of the regulatory framework puts the principle plainly: humans should be made aware that they are interacting with a machine so that they can take an informed decision. The same overview states that the transparency rules come into effect in August 2026.

The engineering here is trivial and the temptation to cheat is real. Vendors sell realism. Some businesses want callers to believe they reached a person, on the theory that disclosure kills conversion. That instinct is both a compliance problem and, in our experience, a commercial mistake. A caller who works out mid-conversation that they were misled becomes hostile, and the recovery cost is far higher than the small friction of an honest opening line.

What good disclosure looks like in a phone context:

• It comes first, before any personal information is requested, not after the caller has already given a name and a date of birth.
• It uses ordinary words. Something along the lines of the caller having reached the practice's automated assistant is understood by everyone. Terms like conversational AI agent are not.
• It is paired with an exit. Tell the caller how to reach a person, and honour that request immediately when they ask.
• It is consistent across channels. If the same business runs a web chat alongside the phone line, the same principle applies on both surfaces.

Disclosure of AI interaction is a separate question from consent to record the call. Recording is governed by data protection law and, in some member states, by additional national rules. Treat them as two announcements with two purposes, not one sentence that tries to do both jobs badly.

Provider or deployer: which one are you?

This distinction decides which obligations land on your desk, and it is the single most useful thing for a small business owner to get straight.

A provider is, broadly, the party that develops an AI system and places it on the market or puts it into service under its own name or trade mark. A deployer is the party that uses an AI system under its own authority in the course of its activity. If you subscribe to a service that an agency or software vendor builds, hosts, maintains and updates, and you use it to answer your own phone, you are the deployer and they are the provider.

The consequence is that the heavy engineering-side obligations, technical documentation, risk management, and the conformity work that applies where a system is classified as high risk, belong to the provider. Your obligations as a deployer are operational: use the system in accordance with the instructions that come with it, keep meaningful human oversight over what it does, watch for it behaving in ways it should not, raise serious problems with the provider, and hold on to the records that let you show what happened.

Two warnings. First, the roles are not permanently fixed. Putting your own brand on a system as though you built it, or substantially changing what the system is intended to do, can pull you toward provider responsibilities. Second, and more common in practice, the roles are frequently left unstated in the contract. Ask for them to be written in. A vendor who resists defining which party is the provider is telling you something useful.

How the AI Act sits on top of your existing GDPR duties

The most common misconception we meet is that the AI Act is a replacement for GDPR, or that being AI Act aware somehow covers data protection. It does not. The two instruments answer different questions and both apply at once.

GDPR governs the personal data. The moment a caller says their name, their number, or why they are calling, you are processing personal data and every existing duty is live: a lawful basis for the processing, collection limited to what you actually need, a defined retention period rather than indefinite storage, a working mechanism for erasure requests, records of processing activities, and proper handling of any transfer outside the EU. Nothing about the processor being a model rather than a person changes this. We covered the ground in detail in our guide to GDPR and AI customer service.

The AI Act governs the system. It asks what the system is for, how risky that purpose is, whether documentation exists, whether people are told they are dealing with AI, and whether a human can meaningfully oversee and intervene.

You can fail one while passing the other, which is why they need separate checks. A deployment that discloses AI interaction perfectly on every call but pipes transcripts to a third country with no safeguards has an obvious data protection problem. A deployment hosted flawlessly inside the EU that quietly imitates a human receptionist has a transparency problem. Where the two overlap, and they overlap constantly around call audio and transcripts, sort out the data protection question first, because it is more mature, better understood by regulators, and more likely to generate a complaint from an actual customer.

A practical checklist: obligation, meaning, and owner

The table below is the working version of everything above. It assumes the ordinary case: an EU small or mid-sized service business deploying a vendor-built, customer-facing assistant that books appointments and answers routine enquiries.

Obligation area	What it means in practice	Usually owned by
AI system inventory	A one-page list of every AI system in use, what each does, which vendor supplies it, and what data it touches. Review it when anything changes.	You
System documentation and instructions for use	The provider's description of intended purpose, capabilities, known limitations and correct operating conditions. You should hold a copy, not just be told it exists.	Vendor produces, you retain
Risk classification of the use case	A written statement of what the assistant is for, and a judgement on which risk band that purpose falls into. Revisit whenever scope expands.	Shared, decided by you
Disclosure of AI interaction	A plain-language line at the start of every conversation telling the person they are dealing with an automated assistant.	You define it, vendor implements it
Human oversight and escalation	A named person responsible, a defined trigger list for handing a call to a human, and a route that works during and outside business hours.	You
Staff understanding (AI literacy)	Whoever operates or supervises the system understands its scope, its failure modes, and how to take over. Brief them, and refresh when the system changes.	You, with vendor input
Logging and record keeping	Interaction records sufficient to reconstruct what the system did and why, kept for a defined period and no longer.	Vendor provides, you set retention
Lawful basis, minimisation, erasure (GDPR)	Your existing data protection obligations, applied to call audio, transcripts and any CRM records the assistant creates.	You as controller
Data residency and transfers	Know which country your audio, transcripts and model inference actually sit in, including every sub-processor in the chain.	Vendor discloses, you verify
Monitoring and incident reporting	A habit of reviewing a sample of interactions, and a route to report serious malfunctions to the provider quickly.	Shared

None of these items requires a compliance department. Most of a first pass is a single document and one honest conversation with your vendor. The failure mode is not difficulty, it is that nobody is assigned to it.

What to ask your vendor before you sign

Regulatory posture is easiest to assess before money changes hands. These are the questions worth putting in writing, and they double as a decent test of whether a vendor is a serious operator or a reseller with a demo.

Which role does each party take, and is it in the contract?

Ask directly whether they consider themselves the provider of the AI system and you the deployer. Ask for that allocation to appear in the agreement alongside the data processing terms. Vagueness here is not neutral, it defaults the risk to whoever is easiest to reach, which is you.

Can I see the documentation, not a summary of it?

You want the intended purpose, the operating conditions, and the known limitations. The limitations section is the most informative page a vendor can hand you. A document that claims no meaningful limitations describes a product nobody has tested honestly.

Who is in the chain behind you?

Speech recognition, the language model, telephony, transcript storage and any analytics layer are frequently four different companies. You need the list, because your data protection obligations follow the data, not the invoice. The vendor questions specific to call data are covered in our note on AI voice agent security.

How does human escalation actually work?

Ask them to walk you through a live transfer, a message taken outside hours, and a caller who says the word complaint. Oversight is a design property, not a policy statement. If handover is clumsy in the demo, it will be worse at eight in the evening.

What happens if I leave?

Export format for transcripts and call records, deletion timeline, and written confirmation when deletion is done. Ask before signing, because after signing you have no leverage.

Where small businesses get this wrong

Three patterns recur, and none of them involve reading the regulation incorrectly.

Treating compliance as a launch task. The inventory gets written the week before go-live and never touched again. Six months later the assistant has been given three new capabilities, a second phone line, and access to a patient management system, and the document describes none of it. Scope creep is the normal life of a working system. Diarise a quarterly review, keep it to fifteen minutes, and update the one page.

Assuming the vendor has it covered. Vendors carry real obligations, and a good one will hand you documentation without being chased. But the deployer duties are structurally yours: oversight, correct use, disclosure in your own words, retention decisions, and your GDPR position as controller. No supplier contract moves those.

Over-deploying because the tool is capable. This is the one we push back on most with clients. A voice assistant that reliably handles booking, rescheduling, opening hours, directions, service questions and message taking is a genuinely valuable system operating well inside the low-risk band. The same underlying technology pointed at clinical triage, applicant screening or debt collection is a different regulatory object with a much heavier burden. Capability is not permission. Keeping the assistant deliberately narrow is a compliance strategy, and it also happens to be how you get better performance, which is the point we make in our guide to training an AI voice agent.

The honest summary is that for the great majority of EU service businesses, the AI Act is not the obstacle it is made out to be. The work is small, largely administrative, and mostly overlaps with things a well-run business should already have: know what systems you use, be straight with your customers, keep a human accountable, and hold your suppliers to written answers. The businesses that struggle are the ones that never wrote any of it down.

Frequently asked questions

Does the EU AI Act apply to a small business with ten employees?

The Act is organised around what an AI system does and how it is used, not around company size. A ten-person clinic that uses an AI voice agent to answer calls is within scope as a deployer, even though the heaviest obligations sit with providers of higher-risk systems. In practice a small business with a low-risk, customer-facing assistant faces a short list of duties: disclose that callers are speaking to an AI system, use the system in line with the vendor's instructions, keep a basic record of what you run, and keep meeting your existing GDPR duties. The Act also contains support measures aimed specifically at smaller organisations.

Do I have to tell callers they are talking to an AI?

Yes, in substance. The European Commission's own overview of the regulatory framework states that people should be made aware they are interacting with a machine so they can take an informed decision. For a phone assistant the practical implementation is simple: say it in the opening line, in plain language, before any information is collected. A short sentence such as stating that the caller is speaking to the practice's automated assistant is enough. Burying it in a privacy policy is not.

Am I a provider or a deployer of the AI system?

If you buy or subscribe to an AI system that someone else builds, maintains and places on the market, and you use it under your own authority for your own business, you are almost always a deployer. The vendor is the provider. The distinction matters because the two roles carry different obligations. It is not permanent, though. If you rebrand a system as your own, or change what it is fundamentally intended to do, you can take on provider responsibilities. Get the role written into the contract rather than assumed.

Does the AI Act replace GDPR?

No. They sit side by side and cover different questions. GDPR governs the personal data flowing through the system: your lawful basis, data minimisation, retention, the right to erasure, records of processing and transfers outside the EU. The AI Act governs the system itself: how risky its intended use is, what documentation exists, whether people are told they are dealing with AI, and whether meaningful human oversight is in place. A deployment can satisfy one and fail the other, so both need checking.

What should I ask an AI vendor before signing a contract?

Ask which role each party takes under the AI Act and get it in writing. Ask for the system documentation and instructions for use, the list of sub-processors and model providers, where audio and transcripts are stored, how long they are kept, and whether your data is ever used to train the vendor's or a third party's models. Ask how human escalation works and how you would export or delete everything if you left. A vendor that cannot answer these in writing is not ready for a regulated market.

What happens if my AI receptionist gives a caller wrong information?

The regulation does not remove your ordinary responsibility to your customers, which is exactly why human oversight is treated as a real obligation rather than a formality. Design for it: keep the assistant inside a narrow, defined scope, hand off to a person whenever the conversation moves outside it, log every interaction so a mistake can be reconstructed, and review a sample of transcripts regularly. An assistant that says it does not know and transfers the call is safer than one that improvises.