A European AI company is not a good choice simply because it is European. A buyer still needs to identify the legal entity and contracting chain, where data is processed, which subprocessors and infrastructure are involved, what security evidence is available, how the AI use case is governed, and how the workflow can be stopped or moved to another supplier. Geography is a set of questions, not a quality mark.
My view: start with the workflow and the evidence you require, then verify the company. Not the other way round.
This avoids two shortcuts. A European registered office does not prove that the entire technical chain is European. A compliance statement does not prove that a service is appropriate for your use case. Legal, privacy and security review always depends on that use case and on the contracts. This article is not legal advice.
What is a European AI company?
The useful answer begins with another question: European in what sense? A company may be incorporated in one European country, contract through another entity, process some data elsewhere and rely on several infrastructure layers. The word “European” does not describe the product being purchased.
For a buying decision, I separate at least four things:
- the entity signing the contract and every other entity involved;
- the service actually delivered, including support and underlying models;
- the path taken by data, logs and backups;
- accountability when the workflow creates, recommends or triggers an action.
The European Union describes its AI approach in terms of excellence and trust, bringing together research capacity, innovation and rules. Its AI Factories also use EuroHPC supercomputing capacity to support AI development and innovation. That is useful ecosystem context, but it is not evidence about any individual business (European Commission).
The purchasing definition should therefore be operational: the company is one part of a chain that must be verifiable. Its location is one attribute of that chain.
Why is the registered office not enough?
A registered office answers “where is this company established?” It does not necessarily answer “who processes what, where, with which access and under which agreement?”
An AI service can include an interface, a model, a hosting provider, observability tooling, human support and backups. Each layer can change data exposure or exit conditions. ENISA's multilayer framework supports reviewing cybersecurity across the layers of an AI system, rather than treating a supplier label as sufficient proof (ENISA).
I therefore ask for documented answers, not a broad claim about sovereignty. This table turns a marketing conversation into a buying decision.
| Question | Evidence to request | Weak answer | Buying consequence |
|---|---|---|---|
| Which entity signs, and who actually delivers the service? | Agreement, entity details, roles of all parties | “We are European” | The accountability chain remains unclear |
| Where do data, logs and backups move and rest? | Data-flow diagram, processing regions, retention rules | “Hosted in Europe” with no defined scope | The pilot boundary cannot be assessed |
| Which subprocessors and components are involved? | Current list, purpose of each, change-notification mechanism | “Trusted partners” | Dependencies cannot be reviewed |
| Which security measures can be verified? | Relevant documentation, controls, reports or attestations | “Enterprise-grade security” | Risk cannot be connected to the workflow |
| How can data be retrieved and the service stopped? | Export format, timing, deletion and exit support | “Export is available” | The cost and feasibility of switching stay unknown |
What evidence should you request before a pilot?
Useful evidence is specific, current, connected to the purchased scope and reviewable by the right person. A sales page may guide the discussion. It does not replace a contractual schedule or a technical review.
Before using real data, I request at least:
- a simple diagram of the workflow, connected systems and data flows;
- the relevant entities, subprocessors, infrastructure and locations;
- retention, deletion, support-access and data-use rules;
- security material suited to the use case, plus incident and exit plans.
The required evidence changes with the data, the system's autonomy and the effect of its outputs. ENISA's framework gives a sound reason to look beyond the visible application: cybersecurity practices need to be considered across multiple system layers (ENISA).
To frame the need before selecting a product, my French guide to AI in business starts from the problem rather than the tool.
How should data and subprocessors be scoped?
I begin by drawing the journey, even if the first version is rough. What data enters? Where does it come from? Is it sent to a model, retained in logs, copied into a backup or visible to support staff? Which output returns to which system?
The document should distinguish data categories and operations. It should also show human access, connectors, test environments and deletion mechanisms. A general statement about “data residency” does not settle all of those points.
For each subprocessor, establish its purpose, the relevant data and location, how changes are announced and what choices the buyer has. The aim is not to accumulate logos or certificates. It is to connect a dependency to a practical consequence.
Three outputs should exist before the pilot begins:
- a clear list of permitted and prohibited data;
- a processing chain understood by business, technical and security owners;
- a testable stop, export and deletion procedure.
Legal, privacy and security review must fit the use case, roles and contracts. No location, certificate or sales wording creates automatic compliance.
How does the choice connect to the EU AI Act?
The EU AI Act exists as Regulation (EU) 2024/1689. The Commission describes a risk-based framework in which obligations depend on factors including the system, its use, the party's role and the level of risk (European Commission).
The practical conclusion is not “buy European”. It is to document what the workflow does, who is involved and how its effects are controlled, then have the competent functions review the specific situation. I am not classifying the reader's system or drawing conclusions about particular obligations here.
Start with four direct questions:
- Which decision or action does the system influence?
- Who supplies, deploys, configures, uses and monitors each component?
- Which people may be affected by the output?
- Which records, human checks and routes for challenge are needed?
The location of a head office answers none of them. The contract and workflow design can. Where a project involves agents, this French guide to AI agents in business extends the discussion of responsibility and safeguards.
Should you buy a tool, buy a service or build the workflow?
There is no universal answer. The choice depends on the required pace, the organisation's ability to operate the system, the level of control needed and how readily it wants to change direction.
| Option | Control | Speed | Internal ownership | Switching | Evidence to obtain |
|---|---|---|---|---|---|
| Tool | The supplier controls a significant part of the product | Setup can be more direct when the need fits | The team mainly owns configuration and the surrounding process | Depends on exports, connectors and formats | Architecture, flows, subprocessors, security, export and deletion |
| Service | Control is shared between provider and buyer | Can speed up framing and operation | Decisions need to be documented and transferred | Depends on contract, deliverables and handover | Roles, methods, access, documentation, ownership of deliverables, exit plan |
| Build the workflow | The buyer can control more orchestration while retaining chosen dependencies | Requires design and operating capability | Strong when code, decisions and operations are genuinely taken in-house | Can ease replacement when interfaces are decoupled | Component-level evidence, tests, observability, documentation and procedures |
There is no score in this matrix. A narrowly scoped tool may be easier to replace than a poorly documented internal build. Use a practical test: who can maintain the workflow in six months, and what needs to change if one component disappears?
The main takeaways are:
- Buy a measurable capability, not a geographic identity.
- Match every promise to evidence and a named reviewer.
- Treat exit as a product function from day one.
- Keep legal, privacy and security decisions tied to the use case and contract.
How can you run a reversible pilot in 30 days?
A reversible pilot does not try to prove everything. It tests whether a limited workflow delivers observable value, within bounded risk, with a workable exit already in place. Thirty days is an operating frame here, not a promise about regulatory timing or results.
Practical pilot checklist
- Define one task, one owner and one expected outcome.
- Select the minimum data and explicitly prohibit sensitive categories that are not needed.
- Map systems, processing locations and subprocessors.
- Define human validation and the conditions that stop the workflow.
- List the evidence due before any real data is used.
- Specify which observations to retain without collecting more than necessary.
- Test an export in a reusable format.
- Test access revocation and the deletion request.
- Record what will be retained, corrected or abandoned after the pilot.
- Obtain use-case and contract-specific legal, privacy and security review.
Use the first week to limit the task and data. Configure the workflow and its controls in the second. Run it on a restricted scope in the third. The final week should include the exit test, evidence review and an explicit decision to extend, correct or stop.
A successful demo without tested export or documentation is not yet a capability worth buying. Evidence of work should show both what works and its limits.
FAQ
Does a European company guarantee that data stays in Europe?
No. The registered office does not by itself describe processing regions, backups, support access, models or subprocessors. Request a data-flow diagram, relevant locations, the list of parties and contractual commitments. Then have the complete setup reviewed for your data and use case.
Does the AI Act require a European supplier?
That is not the general criterion described in the official framework. The Commission presents a risk-based regime, with obligations connected to the system, use, role and risk. The concrete case must be assessed without assuming that geographic origin creates automatic compliance (European Commission; EUR-Lex).
How can subprocessors be verified?
Request a current list, the purpose of each party, the data involved, relevant locations and the process for notifying changes. Connect every dependency to the technical diagram, the contract and security controls. A list without functions or flows is not enough.
What should be planned for a supplier change?
Plan documented export formats, return of configurations and instructions, access revocation, verifiable deletion and a contractually defined transition period. Test the exit during the pilot. If switching is reviewed only when departure is imminent, it is too late to make it a genuine buying criterion.
Choosing a European AI company can fit a strategy based on ecosystem, proximity or contractual control. The decision becomes sound only when company identity, workflow, data, evidence, governance and exit are reviewed together.