Where your CRM AI actually runs is a question that finally has good answers, and European revenue teams are in a stronger position on it than most of them realise. Over the past eighteen months the three platforms that carry the bulk of European B2B revenue have closed much of the distance between where customer records sit and where the model reasoning over them does its thinking. Salesforce processes EU customer data for a vetted product set, the Agentforce 360 Platform included, inside its Hyperforce EU Operating Zone, with in-region support attached. Microsoft extended its EU Data Boundary to cover AI services, Copilot interactions, telemetry and confidential computing, and is rolling in-country processing of Microsoft 365 Copilot interactions out across fifteen countries, with Germany, Italy, Poland, Spain, Sweden and Switzerland in the 2026 wave. HubSpot offers EU data hosting on paid tiers. None of that existed as a documented, purchasable commitment when the first generation of CRM AI features shipped.
Brussels has now added the piece that was missing, which is a shared vocabulary. The Cloud and AI Development Act, proposed on 3 June 2026, grades cloud sovereignty into four levels rather than treating it as a single yes or no. That matters more to a CRM buyer than it might sound, because a graded scale is something you can procure against, negotiate against and design against. It turns a philosophical argument about jurisdiction into a specification line.
The practical upshot is that a European organisation buying or extending CRM AI in late 2026 can specify where inference happens, get that commitment in writing, and still choose from the full field of platforms. This piece covers what the new framework actually says, how to read your own platform’s answer, and why the exercise of finding out tends to leave the underlying architecture in better shape than it started.
Europe has given AI buyers a graded vocabulary
The Cloud and AI Development Act, usually shortened to CADA, is the European Commission’s proposal for harmonised rules on cloud and AI development, published on 3 June 2026 as part of the wider Tech Sovereignty Package alongside a second Chips Act. Its most consequential element for buyers is an autonomy framework built on four Union assurance levels. Level one requires EU-based processing and functions as the floor for public sector procurement. The levels above it add progressively stricter conditions on third-country control, EU ownership, supply-chain transparency, personnel clearance and independent audit, with level four requiring that neither the provider nor its software supply chain sits under the effective control of a third country. Final adoption is scheduled for the end of 2027.
Two design decisions in the proposal are worth appreciating. The first is that it grades rather than excludes. The approach is risk-based and procurement-driven, which means global hyperscalers can continue to serve European customers subject to enhanced obligations, so buyers are not being pushed toward a smaller field of suppliers. The second is that it comes with capacity behind it: the proposal aims to triple the EU data centre market within five to seven years and to meet European business and public administration demand by 2035. That is a response to a real gap, given that the EU providers’ share of the European cloud market fell from 29 per cent in 2017 to roughly 15 per cent in 2022, while three non-European hyperscalers came to hold more than 70 per cent of it.
Reception has been mixed, and the file has a long parliamentary road ahead of it. For a CRM team, though, the useful part is available immediately and does not depend on the outcome. The four levels are already a better way to frame a vendor conversation than the binary most procurement documents still use.
What is the difference between data residency and data sovereignty?
Data residency is a question about location: in which country or region are the records physically stored and processed. Data sovereignty is a question about control and jurisdiction: whose law governs the data, who can be compelled to hand it over, and who can make operational decisions about it. The two often move together, but they are not the same commitment. A record stored in a Frankfurt data centre satisfies residency while remaining within reach of a provider incorporated elsewhere, and that is precisely the distinction CADA’s higher assurance levels are built to grade. For CRM buyers there is a third question that neither term settles automatically, which is where AI inference happens.
Separating those three questions is what makes the conversation productive. Most European organisations already have a defensible answer on residency, often set years ago during a GDPR programme. Sovereignty is a legal and contractual conversation with a clear owner, usually the general counsel or the data protection officer. Inference location is the newest of the three and the one where the platforms have made the most visible progress, so it rewards asking about directly rather than assuming it follows from the other two.
Where does your CRM AI processing actually happen?
In most CRM platforms today, the setting that governs where your records are stored is configured separately from where AI features send prompts for processing, so the two can differ. The encouraging development is that all three major vendors now publish this clearly enough to check. Salesforce’s Hyperforce EU Operating Zone stores and processes EU data strictly within the EU region for a vetted set of products spanning Sales Cloud, Service Cloud, the Agentforce 360 Platform and several industry clouds, with generative AI traffic passing through the Einstein Trust Layer; Agentforce also holds second-level compliance with the EU Cloud Code of Conduct. Microsoft’s EU Data Boundary now covers AI processing, Copilot, telemetry and confidential computing. HubSpot offers EU data hosting for CRM records on paid tiers, and Breeze AI features are worth confirming separately against the same standard rather than assuming they inherit the hosting choice.
The value here is that the answer is now readable rather than inferred. Eighteen months ago a European CIO asking where a CRM assistant’s prompts were processed was often met with a general assurance. Today the answer arrives as documentation with product scope and regional commitments attached, which is exactly what an assurance level needs to be evidenced against. That shift is what allows a European team to treat inference location as a specification rather than a hope.
The right question to put to a platform is therefore narrower than the usual one. Not whether the vendor is compliant, which invites a marketing answer, but which specific products in your subscription carry the in-region processing commitment, whether the AI features you have actually enabled sit inside that scope, and what happens when one outside it is switched on. Vendors answer that version well, because they built the product boundaries to make it answerable.
What is shadow AI, and why does it govern your real posture?
Shadow AI is the use of AI tools and assistants that an organisation has not approved, reviewed or contracted for, typically consumer chatbots that employees paste work into because they are convenient. It matters to sovereignty because the residency and inference commitments you negotiate inside the CRM only govern work that happens inside the CRM. Okta’s AI Agents at Work study, published on 27 May 2026 from 292 executives and 492 knowledge workers across seven countries, found that 52 per cent of employees use unapproved AI tools while 90 per cent of executives were confident in their visibility over AI use. That gap is the difference between a documented posture and an actual one.
The good news is that this is the cheapest of the gaps to close, because the fix is a product decision rather than a policy one. Employees reach for unapproved tools mostly for ease of use and because a colleague did it first, which means a capable assistant inside the CRM, switched on and actually taught, removes most of the incentive. Organisations that have invested in in-platform AI adoption tend to find their shadow AI problem shrinks without a single new rule, and they gain a usage record they can audit. That is a rare case where the governance answer and the productivity answer are the same answer.
Answering the question improves the architecture anyway
To say with confidence where your CRM AI runs, you need three artefacts: an inventory of the integrations that move customer data in and out of the platform, a named owner for each of those flows, and a record of which fields are exposed to prompts. Teams often expect that to be the tedious part of the exercise. In practice it is the part that pays for itself, because those same three artefacts are what unblock lead routing, make reporting reconcile and cut the onboarding time for new administrators.
This is where the sovereignty conversation intersects usefully with CRM technical debt, meaning the accumulated undocumented customisations, dormant automations, orphaned integrations and duplicated fields that build up in a platform over years of change. Debt of that kind is what makes the question hard to answer, since an undocumented integration is by definition an unmapped data flow. Working through it in order to answer a sovereignty question gives the cleanup a sponsor, a deadline and a business case, which is usually what such projects lack. Several of the most productive data quality programmes we see start life as a compliance question and end up being justified on operational grounds alone.
How should a European CRM team sequence this?
The most useful move is to set an assurance target per workload rather than per organisation. A single company-wide sovereignty level is expensive and almost always overshoots, because the sensitivity of a marketing contact list and a regulated client file are not comparable. Segmenting first means most of the estate can sit comfortably at the lower levels while attention and budget concentrate on the smaller share of data that genuinely warrants the stricter conditions. That segmentation is also reusable: it is the same classification the AI Act’s high-risk obligations, applicable since 2 August 2026, expect an organisation to be able to produce.
From there the sequence is straightforward. Map the AI features currently switched on and check each against the in-region product scope your subscription actually covers, which is usually a short exercise and often reassuring. Put inference location into the standard vendor questionnaire so it becomes a default rather than a special request. Give each high-sensitivity data flow a named owner, since an unowned flow is the one that drifts. And set a review date twelve months out, because vendor regional coverage is expanding quickly enough that a workload which cannot meet its target today may well be able to next year.
Timing favours the organisations that start now. CADA is not due for final adoption until the end of 2027, so there is real runway, and the teams that use it will be specifying against a framework their competitors are still reading about. That is a comfortable position, and it costs a mapping exercise most CRM estates need regardless.
The Sirocco perspective
We work across Salesforce, HubSpot and Microsoft Dynamics 365, and the honest observation from that vantage point is that all three have moved further and faster on European AI processing than the public debate gives them credit for. As an independent CRM partner, our role in these conversations is not to steer a client toward a platform but to make the comparison legible: which products in a given subscription carry an in-region commitment, where the assurance level lands for each workload, and what it would take to raise it. That is a considerably more useful output than a verdict on which vendor is most European, and it is the kind of question a partner with no licence quota to defend can answer plainly.
What we would encourage most is treating sovereignty as a design input rather than a review gate. Teams that ask where the inference happens at the point of designing an agent, rather than in a security review six weeks before launch, consistently ship faster and with fewer compromises, because the constraint shaped the architecture instead of arriving to argue with it. The vocabulary now exists, the vendor commitments are documented, and the mapping work improves the platform whatever the regulation eventually says. European CRM teams have rarely had a better moment to answer this question well.
If you are planning CRM AI work and want a clear view of where your processing sits today and what your options are across platforms, schedule a consultation with our team.
Get in Touch
If you are weighing where your CRM AI should run, across Salesforce, HubSpot or Dynamics 365, tell us which platform you are on and we will map your current processing and assurance options.
