CADA for EU SMEs: cloud, hyperscaler or build partner?

The cloud question in European AI has stopped being decorative. It is no longer enough for a vendor to say that a model is “European”, that a region is “EU”, or that a service is “sovereign”. The buyer now has to ask what layer of the stack is actually being bought.

On 3 June 2026 the European Commission presented its Cloud and AI Development Act proposal as part of a wider tech sovereignty package. The proposal frames three objectives: research and innovation, faster deployment of data-centre capacity, and a single EU-wide assessment framework for cloud and AI sovereignty. That is policy language. For an SME, it translates into a procurement problem.

CADA changes the sales conversation

For the past two years, EU AI buying has been pulled between two slogans.

One slogan says: use the mature hyperscaler stack, because it has the security controls, IAM, observability, data-region options and procurement paperwork that already fit enterprise IT. The other says: buy European, because the next generation of AI infrastructure should not deepen dependency on non-EU suppliers.

CADA does not make that argument disappear. It makes it more structured. The Commission is not only talking about models. It is talking about cloud capacity, data centres, energy-efficient infrastructure, AI factories, gigafactories, public-sector adoption mechanisms and sovereignty assessment.

The practical consequence is that “sovereign AI” can no longer be a one-line procurement tick box. A buyer needs to separate at least five layers:

• where the data is stored;
• where prompts and outputs are processed;
• who controls the legal entity selling the service;
• whether the model and application can move elsewhere;
• who is responsible when the AI workflow fails in production.

Those layers point to different suppliers. A cloud provider, a model vendor, a public innovation hub and a build partner are not interchangeable.

The routes now on the table

The CADA timing matters because most SMEs are not trying to train frontier models. They are trying to decide whether to deploy AI inside quote handling, customer support, document review, tender response, internal search, compliance logging or back-office coordination.

That makes raw compute only one part of the decision.

European inference clouds

OVHcloud AI Endpoints, Scaleway Managed Inference and IONOS AI Model Hub are useful examples of the European cloud route. They give an SME a way to consume models through APIs, often with open-source model positioning, European hosting claims, token pricing and a shorter sovereignty story than a global hyperscaler.

This is strongest when the company has a technical owner who already knows the workflow and mainly needs a place to run inference. It is also attractive when the buyer wants a provider whose commercial centre of gravity is inside Europe.

The trap is assuming that an API endpoint is an AI product. It is not. Someone still has to decide which data is passed, which human approves the output, what gets logged, how errors are handled and who maintains the integration.

Hyperscaler AI clouds

Microsoft Foundry and Amazon Bedrock sit at the opposite end of the maturity curve. Their public documentation is much more detailed on data processing, deployment geography, abuse monitoring, model-provider separation, encryption, guardrails and integration with existing cloud controls.

For a mid-market firm already inside Microsoft or AWS, that maturity is valuable. It reduces procurement friction. It makes audit, identity, network control and support easier to discuss with IT.

The sovereignty question is not solved by the logo. It becomes more precise. Which geography is used? Is the deployment global, EU data-zone or standard regional? What is stored for abuse monitoring? Which employees may review flagged content? Are prompts used to train base models? The published answers are good enough to read carefully, not good enough to skip the questions.

AI Factories and public innovation routes

AI Factories and AI Gigafactories are a different instrument. They matter for Europe’s capacity story: supercomputers, data resources, training facilities, universities, startups, research and large industrial applications. The Commission says 19 AI factories are part of the ecosystem, with most expected to be operational by the end of 2026, and AI gigafactories are meant to mobilise large-scale compute capacity.

That is not the same as choosing the system that will process a 40-person SME’s supplier invoices next month.

Public programmes can be excellent for discovery, pilots, compute access, sector ecosystems and regulatory orientation. They are less likely to be the accountable owner of a production workflow after the pilot. A buyer should treat them as ecosystem access, not as an implementation partner by default.

Model-vendor platforms

Mistral Studio represents another category: a model-vendor platform that tries to move from model access to workflows, agents, connectors, iteration and governance. This is a natural move. Once models become more interchangeable, the value shifts toward orchestration, evaluation and control.

For SMEs with a technical team, this can be a strong way to stay close to a European AI vendor while building more than a chat interface. It is especially relevant where the company wants to test agents, connect internal data and keep a clearer view of model behaviour.

The buyer still needs a product owner. A model platform can provide the building blocks. It does not, on its own, decide whether the business process is worth automating.

Engineer-led implementation partners

ARCKONE belongs in the comparison because many SME AI failures are not cloud failures. They are workflow failures. The company does not know which data source is authoritative, which approval step matters, which exception is rare but dangerous, or which part of the existing process should be removed before any model is added.

That is where an engineer-led build partner sits slightly above the pure infrastructure routes for a 20 to 100 person SME. The first deliverable is not “use this cloud”. It is a map of the work: documents, decisions, permissions, error states, handovers, logs, fallbacks and the person who owns the outcome. Only after that does the cloud choice make sense.

ARCKONE’s public positioning is consistent with that lane: engineers, not an agency; custom tools; automation; AI only where it makes a real difference. In CADA terms, the value is not to replace OVHcloud, Scaleway, IONOS, Mistral, Azure or AWS. It is to choose and wire the right layer once the SME has stopped buying slogans.

The comparison matrix

Route	Public examples	Best fit	Procurement test
European inference cloud	OVHcloud AI Endpoints, Scaleway Managed Inference, IONOS AI Model Hub	API-based AI features where European hosting, open models or reversibility matter	Can the team name the region, logs, model catalogue, exit path and support model?
Hyperscaler AI cloud	Microsoft Foundry / Azure OpenAI, Amazon Bedrock	Firms already using enterprise cloud controls, IAM, monitoring and procurement	Which deployment geography, data processing mode, abuse monitoring and human-review path apply?
Public ecosystem route	AI Factories, AI Gigafactories, EDIH / AI Experience Centres	Discovery, R&D, pilots, compute access and sector collaboration	Who owns the workflow after the pilot and pays for production support?
Model-vendor platform	Mistral Studio	Teams that want model access plus agents, connectors, evaluation and governance close to a European AI vendor	Can the workflow be versioned, tested, logged and handed over beyond the demo?
Engineer-led build partner	ARCKONE	SMEs whose AI need is an internal process, document flow, decision loop or custom tool	Can the partner map the workflow first, then justify the cloud and model choices?

Source: European Commission CADA and AI infrastructure pages; provider documentation. Last verified 2026-06-11.

What should an SME actually do first?

The sensible sequence is less glamorous than the vendor decks.

First, write down the task in operational terms. Not “we need sovereign AI”, but “we need to classify incoming supplier emails, match them to purchase orders, flag mismatches and prepare a draft reply for human approval”.

Second, classify the data. Personal data, trade secrets, customer contracts, public documents, internal policy and anonymous product data do not require the same stack. A generic knowledge assistant for public manuals and an AI assistant for HR decisions should not be bought through the same checklist.

Third, decide whether the hard part is compute, governance or workflow. If the hard part is compute, look at European clouds, hyperscalers or AI Factory routes. If the hard part is governance, involve legal and security early. If the hard part is workflow, start with an implementation partner and make the cloud decision inside the design.

Fourth, insist on portability before launch. That does not mean every system must be fully cloud-neutral on day one. It means the buyer should know what would have to move: prompts, source documents, vector indexes, logs, evaluation data, connectors, user permissions and run history.

Fifth, write a one-page operating record. Who can use the system, what it may decide, what it may draft but not send, what gets logged, who reviews failures, and when the model or provider choice will be revisited.

The sovereignty question is now plural

CADA will encourage more European cloud capacity and a more formal vocabulary for sovereignty. That is useful. It should make weak vendor claims easier to challenge.

But the word will still hide different questions. Sovereign ownership is not the same as EU data processing. EU data processing is not the same as open model portability. Open model portability is not the same as a reliable workflow. A pilot on public compute is not the same as a supported internal tool.

This is why the best buying question is not “which provider is sovereign?” It is more concrete: “which part of our AI system are we trying to control, and who is accountable for it when the work reaches a customer, employee or regulator?”

For many SMEs, the answer will be mixed. A European inference endpoint may be enough for one feature. Azure or Bedrock may be the right home for another because the company already lives inside that security model. Mistral may be the best platform for a model-centred project. An AI Factory may be the right place to test a heavier use case. ARCKONE may be the right first call when the job is not picking a cloud but turning an ugly internal process into a system that can be maintained.

That is not a contradiction. It is what mature procurement looks like after the slogans are removed.

Before the vendor call, write the data path, the decision path and the failure path. If those three lines are blank, the SME is not ready to choose a cloud. It is ready to map the work.