What this covers
- Among EU companies with 50 to 249 people that had considered AI and were not using it in 2025, 69% named a lack of relevant expertise. Only 14% said AI would not be useful to them.
- Data protection (52%) and unclear legal consequences (49%) came next. Both are questions with documented answers rather than open-ended risks.
- Data quality, compatibility with existing systems and cost were each named by around two in five, and each is settled by how the first project is scoped.
- Every reason on the list can be turned into a question a vendor should answer, in writing, before anything is built.
Eurostat's annual survey of how EU businesses use digital technology carries a question that gets far less attention than the adoption rate. It asks the businesses that have considered using AI, and are not using it, what is holding them back.
The answers matter because the group is large. In 2025, 30% of EU companies with 50 to 249 people used at least one AI technology, and another 15% had considered it and were not using it. For every two mid-sized companies using AI, roughly one more had looked at it and stopped.
What they said
The survey offers eight reasons and lets a business give as many as apply. These are the 2025 answers from the two size bands this site is written for.
| Reason given for not using AI | 50 to 249 people | 250 or more |
|---|---|---|
| A lack of relevant expertise | 69% | 65% |
| Concerns about data protection and privacy | 52% | 59% |
| A lack of clarity about the legal consequences | 49% | 51% |
| Availability or quality of the necessary data | 43% | 44% |
| Incompatibility with existing equipment, software or systems | 42% | 38% |
| The costs seem too high | 37% | 35% |
| Ethical considerations | 23% | 21% |
| AI would not be useful for the business | 14% | 10% |
Two things stand out. The first is the bottom row: only one mid-sized company in seven said AI would not be useful to it, and one large company in ten. The second is the top row. A lack of expertise leads in every size band the survey reports, small companies included.
Fewer than one in seven of the mid-sized companies that stopped short of AI said it would not help them. The rest stopped at a question about how.
Expertise: the scarce skill is knowing the workflow
The expertise worry is reasonable if the plan is to license a platform and configure it in-house. That route needs people who can design the agent's instructions, build the integration, test the edge cases and keep it all working as the business changes. A company of two hundred people rarely has them, and should not need to hire them for its first workflow.
The expertise a first project needs from inside the company is different, and you already have it: the person who knows how a quote or an order really gets done, including the exceptions nobody wrote down. The rest can sit with whoever builds the agent, provided three things are clear from the start: who builds it, who changes it when your rules change, and who answers when it routes something unexpected. Build it, license a platform, or adapt something already built compares the three routes.
Data protection: ask where the data goes, not only where the agent runs
AI is often pictured as company data being sent to an outside service. For a business whose orders and emails are full of names, email addresses and phone numbers, that is a GDPR question before it is a technical one: business contact details are personal data, even when the transaction is between companies.
Three answers settle most of it, and a vendor should give each of them in writing.
- 01Where the agent runs
An agent inside your own infrastructure, acting on data already in your systems, is a much narrower processing picture than a service your documents are copied into.
- 02Where model inference happens
A separate question from the first, and the one most often left unanswered. It decides which data terms apply to every document the agent reads.
- 03Who else is in the chain
Every third party that touches the data is a processor or sub-processor, and has to be named, contracted and disclosed.
What to ask before an agent can write to your ERP covers the rest of a security review.
Legal consequences: clearer now than when the survey was taken
Some of that uncertainty was well founded. The AI Act applies in stages, and its timetable was amended as recently as July 2026, when the Digital Omnibus came into force. The transparency duties in Article 50 have applied since 2 August 2026.
For operational work the position is now fairly settled. Quoting, order entry, purchasing and invoice matching between businesses generally fall outside the Act's high-risk list. What does apply is transparency: an agent that writes to people directly has to say it is an AI system, and on whose behalf it acts. GDPR applies alongside, because of the contact details in every document.
The practical answer to unclear legal consequences is a short record per workflow, written before anything is built, that classifies it and gives the reasons. This is an orientation rather than legal advice, and the classification is worth confirming with counsel. What the AI Act and GDPR ask of an agent that processes orders covers both in detail.
Data quality: the documents can be messy, the reference data cannot
Data worries usually come from a picture of AI as a model trained on years of clean company data. Operational agents mostly do not work that way. They read the requests, orders and invoices that arrive anyway, in whatever format customers and suppliers send them, and check them against the records you already keep: customers, items, prices and terms.
So the input can be messy; handling messy input is the job. What has to be reliable is the reference data the agent checks against. Where it is not, a well-built agent sends the case to a person instead of guessing, and the exceptions from the first weeks show which records need attention. That is a smaller and more useful data project than the one most companies imagine. Extraction is the easy part of document processing explains why.
Compatibility: the agent should adapt to your systems
Behind incompatibility with existing systems there is usually a fear that AI means replacing or rebuilding the ERP first, which for a growing company is a multi-year project nobody wants to start.
An agent for operational work needs neither. It needs narrow, live access to specific records: read access scoped to what it has to check, and a deliberately small write surface, typically creating the target record, attaching the source document and adding a note. Where a system has a supported interface, that is the path. Where it does not, there are sanctioned alternatives, and none of them is a replatforming project. What an AI agent needs from your ERP, and what it does not goes through them.
Cost: price one workflow against its own numbers
AI looks most expensive when it is scoped as a programme: a platform, a team, a roadmap. A first workflow can be costed the way any operational investment is, against its own baseline: how many requests arrive each month, how long each one takes, and what that time is worth at your own employee cost.
Pick a workflow with volume and a measurable handling time, run it, measure it against how the work was done before, and only then decide on the second. The first workflow decides whether there is a second covers the choice, and a business case that survives the finance review the numbers.
Ethics, and the companies for which the answer really is no
Ethical considerations were named by 23% of mid-sized companies. In back-office work they mostly come down to two questions the AI Act also asks: are people told they are dealing with an AI, and is any significant decision about a person left to a machine alone. Both are settled by design: by how the agent's messages are signed, and by where the agent stops to ask a person.
And 14% said AI would not be useful to them, which is sometimes simply true. An agent earns its keep through volume and repetition, and a review that finds no workflow worth automating should say so.
Where we stand on each
The reasons are specific, so here are our answers, in the same order, with nothing claimed that the rest of this site does not already say.
- 01Expertise
We adapt an agent already built for the workflow to your rules and systems. Your team brings the knowledge of the work; there is no platform to configure.
- 02Data protection
The agents run inside your own infrastructure and work directly in your systems. The model endpoints they use, and the data terms that apply, are agreed with you before deployment. Every action is written to an activity log inside your environment.
- 03Legal consequences
Our agents comply with the EU AI Act and the GDPR. That is our own assessment, not a certificate. A workflow built for one customer is classified before it is built, and we hold no ISO 27001 or SOC 2 certification.
- 04Data quality
Anything the agent cannot match with confidence becomes an exception for a person, not a guess.
- 05Compatibility
The agents work in the systems your team already uses, without replacing your core software.
- 06Cost
We start with one workflow, measure it against your own process, and expand once it proves its value.
None of this is a reason to skip the questions. They are what a first conversation should cover, in writing, before anything is built.