← Perspectives
Perspectives

The Infrastructure Gap Slowing Claude Adoption in European Research

Why European research institutions can't easily adopt Claude — and what procurement decision-makers need to know about IT lock-in, GDPR, and AI Act compliance.

26 May 2026 ·7 min read ·Pranoti Kshirsagar
AI strategyEuropean researchprocurementClaude AIMicrosoft 365EU AI Act

I have been watching the conversation about Claude in European research circles for some time now. The discussion almost always centres on product quality — is it accurate enough, safe enough, capable enough for research use? Rarely does anyone ask the prior question: even if researchers want Claude, can they actually get it into their working environment? The barrier to Claude adoption in European research institutions is not the product. It is the vendor integration layer — the procurement frameworks, IT policy, and compliance processes that sit between researchers and new tools.

The numbers behind the lock-in

The European Parliament Research Service study on European software and cyber dependencies (EPRS ECTI_STU(2025)778576) puts Microsoft’s share of the EU higher education productivity software market at approximately 90%, with Google Workspace accounting for most of the remainder. These are not just market share figures. They represent identity infrastructure, procurement relationships, and data residency architecture that has been built up over years.

Procurement in European higher education does not happen institution by institution. It flows through national consortia: SURF in the Netherlands, DFN in Germany, Jisc in the UK — all operating under the GÉANT Cloud Framework. When a university in Utrecht or Heidelberg or Manchester needs a productivity platform, they do not evaluate vendors from scratch. They work within pre-negotiated agreements that already favour Microsoft and, to a lesser extent, Google. Anthropic has no pre-existing relationship with any of these frameworks.

This is not a criticism of Anthropic’s product strategy. It is simply the structural reality of how European academic IT is procured. The consortium model was designed to reduce cost and administrative burden — and it achieves that. The side effect is that it creates very high barriers for any vendor that is not already inside the system.

Why even a convinced user cannot just use Claude

I speak to researchers across European institutions regularly. Many of them are already using Claude personally — on their own accounts, on their own devices, for tasks that do not touch institutional data. The moment a researcher wants to use Claude in a professional capacity, using institutional data, as part of a funded project workflow, they run into a wall.

Individual intent does not override IT policy. Most European research institutions have formal approved vendor lists. If Claude is not on that list, it cannot be used for work that involves institutional data, grant-related documents, or any data covered by GDPR. The researcher who is convinced of Claude’s value has no individual authority to change that.

Compounding this, bundled AI is already in the stack for most users. Microsoft Copilot is available to every M365 user. Researchers on Google Workspace have access to Gemini and NotebookLM. The question an IT or procurement committee faces is not “should we get AI?” — it is “why would we add a separate vendor for AI when we already have it?” That is a harder question to answer than it looks.

The switching cost nobody talks about

Microsoft secured its dominance in European higher education partly through the EU Data Boundary initiative, which committed to keeping all EU customer data within EU borders. This was a deliberate response to GDPR and Schrems II concerns, and it worked. Institutions that had hesitated to move fully to cloud infrastructure found their compliance objections addressed.

Azure Active Directory runs deep in campus security architecture. Single sign-on, multi-factor authentication, device management, student identity systems — all of it flows through Microsoft’s identity layer at most European universities. The technical switching cost of moving away from this infrastructure is prohibitive. It is not a decision that gets made because a language model is impressive.

Google has historically faced harder battles in European academic IT. Several German states and French ministries have issued warnings or restrictions on Google Workspace deployments, citing data sovereignty concerns. Google’s position in European research is mostly departmental — specific labs or groups who have adopted it for particular workflows — rather than institution-wide. It is not an equivalent alternative to Microsoft at the institutional level.

For Anthropic, the consequence is stark: Claude alone is not a sufficient reason for a European research institution to migrate or extend its procurement architecture. It would need to be part of a broader value proposition, delivered through a channel the institution already trusts.

The integration trap — and why the dual stack does not save it

The natural response to this analysis is: fine, so Anthropic should integrate with M365 and Google Workspace rather than trying to replace them. And that is partly right — Anthropic is already pursuing this route, with Claude available through Amazon Bedrock (including EU Frankfurt region) and increasingly through Microsoft Azure. But integration is not the same as adoption.

European research institutions already run what I would call a dual stack. The M365 layer handles administration, email, HR systems, and student-facing processes. The research layer is more fragmented: Overleaf for LaTeX manuscript preparation, Google Sheets and Drive APIs for data pipelines, institutional repositories for outputs, specialised tools for specific disciplines. This fragmentation looks like an opportunity for Claude — and in some respects it is.

The difficulty is that IT policy does not only govern the core suite. Every tool that connects to institutional data, grant data, or research outputs is subject to the same vendor approval, data processing agreement, and compliance review process. Adding Claude as an integration into the research workflow layer is not a plugin install. It is a procurement event, requiring a data processing agreement, a GDPR Article 28 assessment, an AI Act compliance review, and sign-off from whoever holds institutional risk appetite for new AI vendors. That is a sustained organisational initiative — not a one-time implementation, but an ongoing maintenance commitment.

Organisations are already struggling with internal AI adoption in general. Adding a new vendor outside the core stack means adding another change management initiative, another budget line, and another layer of governance. For most institutions, the question is not whether Claude is good enough. It is whether the organisation has the capacity to absorb another AI vendor.

Where Anthropic can realistically win

None of this means Claude cannot enter European research. It means the entry point matters.

The most realistic near-term opening is in API-native research groups — teams that are already building custom workflows, accessing data programmatically, and have IT environments that can accommodate a new API vendor with appropriate data governance in place. Computational biology groups, digital humanities labs, legal and regulatory compliance teams within research organisations, and AI safety researchers are all plausible early adopters.

The Sparkle partnership with Anthropic, distributing Claude through AWS Bedrock into European enterprises, is a meaningful signal. AWS has established EU data residency credentials and existing relationships with European institutional IT. This is a more viable entry route than a direct Anthropic sales relationship with individual institutions.

But a compliance and procurement wrapper still needs building before Claude can scale in European research at the institutional level. That means GÉANT framework positioning, GDPR Article 28 template agreements, EU AI Act compliance documentation, and relationships with national consortium procurement teams. Without these, even a research institution that wants Claude faces significant internal process to justify the decision.

What this means if you are making AI procurement decisions now

If you are a research manager or IT decision-maker at a European institution evaluating AI tools right now, the honest framing is this: the safe choice is to use what is already in your stack. Copilot or Gemini, depending on your suite. They are already approved, already compliant, already paid for. The switching and compliance cost is zero.

The strategic choice is different. If you believe — as I do — that Claude’s capabilities in complex reasoning, long-document analysis, and research-adjacent tasks offer something that bundled AI does not, then the question is whether your procurement architecture can absorb a new vendor. That means assessing your DPA capacity, your IT policy review timeline, and your change management bandwidth — not just evaluating the product.

Ask three questions before adding any new AI vendor outside your existing stack:

  1. Do we have an existing data processing agreement template that covers this vendor’s model? If not, how long does it take to create one?
  2. Does this vendor’s EU data residency commitment meet our Schrems II and GDPR obligations? For Claude via AWS Bedrock EU region, the answer is increasingly yes. For direct Anthropic API, it requires scrutiny.
  3. Is this a one-time integration or an ongoing operational commitment? If the latter, who owns it after implementation?

The product is strong. The question is whether your institution is ready to do what it takes to use it properly.

If you are navigating AI vendor decisions at a European research institution and want a structured way to think through procurement readiness, get in touch →

This piece accompanies The Knowledge Work Automation Gap in European Research — which covers the broader automation readiness gap in European research organisations and why the tools are often the least of the problem.

Sources

Browse all Perspectives or get in touch →

Found this useful? Share it or read more perspectives.

← More perspectives Work with me →