Build vs. Buy in the Age of GenAI: When Vendor Defaults Become Your Problem

Key Takeaway

The build vs. buy debate in GenAI is not about speed versus quality. It is about what you can observe, control, and defend – in an audit, in production, and when a vendor ships a default that changes where your data is processed.

1. The Case for Buying

The argument for SaaS AI has always been compelling. Microsoft Copilot, OpenAI’s ChatGPT Enterprise, Anthropic’s Claude, and their peers offer access to frontier models with minimal infrastructure overhead. For most organizations, the pitch writes itself:

• Ship a working AI assistant in weeks, not quarters
• Offload model maintenance, fine-tuning cycles, and GPU infrastructure to the vendor
• Benefit from continuous model improvements without a single internal commit
• Keep upfront investment low while validating use cases

These are real advantages. For low-risk use cases – internal knowledge search, code completion, marketing copy generation – the SaaS route often makes sound engineering and business sense. No serious practitioner should dismiss it.

The question is not whether to buy. The question is: what are you implicitly accepting when you do?

2. What April 2026 Taught Us: The Flex Routing Case

In March 2026, Microsoft introduced flex routing for Microsoft 365 Copilot. The feature is operationally sensible: when EU data center capacity is constrained, LLM inferencing – the compute step where your prompts, documents, and emails are actually processed – can be routed to Microsoft’s servers in the US, Canada, or Australia.

The rollout details matter:

• Enabled by default for new tenants from 25 March 2026
• Enabled by default for existing tenants from 17 April 2026
• Opt-out available – but communicated via a Message Centre notification (MC1269223) with a narrow window

Why is this a GDPR issue

A common misconception in the initial wave of commentary: “data at rest stays in the EU, so it’s fine.” This is technically true but legally insufficient.

Under GDPR Article 44, any transfer of personal data to a third country – including for processing – requires either an adequacy decision, Standard Contractual Clauses (SCCs), or another lawful mechanism. The location where data is stored is separate from where it is computed. When a user’s email or document is sent to a US-based inference endpoint, that is a transfer in the legal sense, regardless of whether the response is returned to the EU and no data is persisted.

4. A Framework for the Build vs. Buy Decision

There is no universal answer. The right architecture depends on your regulatory exposure, data sensitivity, workflow complexity, and organizational maturity. The table below maps the key trade-off dimensions:

Buy vs. Build decision framework across 8 key dimensions. Evaluate based on your organisation’s regulatory context, operational maturity, and AI roadmap.

The dimensions that most often tip the balance toward building are data sovereignty, auditability, and agentic workflow complexity – not because SaaS cannot provide value in these areas, but because the guarantees are implicit rather than explicit.

5. When Buying Still Makes Sense

Intellectual honesty requires stating this clearly: for many organizations and use cases, buying is the right call.

• Early-stage experimentation, where validating a use case quickly outweighs control requirements
• Non-regulated industries or internal tools where data sensitivity is low
• Teams without the engineering capacity to build and operate a custom AI platform
• Use cases where the vendor’s out-of-the-box capability is a close enough fit that customization risk exceeds its benefit

The mistake is not choosing to buy. The mistake is choosing to buy without a clear-eyed assessment of what you are delegating – and to whom.

6. When Control Becomes Non-Negotiable

For organizations operating in regulated industries, the calculus shifts. The following conditions each independently increase the risk of a pure-buy approach:

• Data residency obligations under GDPR, HIPAA, FINMA, or sector-specific frameworks
• Contractual requirements with enterprise clients specifying data processing boundaries
• Agentic workflows where AI systems act on behalf of users – reading emails, executing transactions, triggering downstream systems – creating a broader data processing footprint
• Multi-model architectures requiring orchestration across providers, which SaaS products are not designed to support
• Audit and explainability requirements where you must demonstrate exactly what data was processed, when, and where

In these scenarios, the question is not whether a SaaS product is capable. It is whether you can defend, in a regulatory conversation, that the product’s defaults and the vendor’s release cadence are consistent with your obligations. In most cases, you cannot – without significant additional contractual and technical controls that often erode the speed and cost advantages of buying in the first place.

7. The Agentic Frontier Raises the Stakes

The industry is moving from AI assistants to AI agents. The difference is consequential: agents do not just respond to queries – they plan, execute multi-step workflows, call external APIs, and operate with persistence across sessions. The data surface area expands significantly.

In an agentic architecture, an AI system might simultaneously access a document repository, a CRM, a code base, and an external data feed – orchestrating across all of them to complete a task. The inferencing step is not a single call. It is a continuous loop of retrieval, reasoning, and action.

This is where platform design matters enormously. A purpose-built enterprise agentic platform gives you:

• Explicit control over data routing at each step of an agent’s execution
• Observability into what an agent accessed, inferred, and acted on
• The ability to constrain agents to approved data sources and action boundaries
• Vendor-agnostic model selection – swap foundation models without rebuilding the platform

Unit8 has built enterprise agentic platforms for organizations where these properties were non-negotiable – including a major Swiss bank, clients in the biomedical and life sciences space, a MedTech organization, and a chemical company. In each case, the decision to build a custom platform was driven by the same factors: data sovereignty, regulatory exposure, and the need to operate AI at scale across sensitive workflows.

What these projects reinforced is that the build vs. buy question, when answered thoughtfully, is not a binary. The most resilient architectures often combine SaaS components for low-risk, high-volume tasks with custom-built orchestration and control layers for the workflows that matter most.

8. Reframing the Question

The flex routing situation is a useful forcing function. It makes visible a risk that was always present but easy to overlook when everything was running smoothly: in a SaaS model, you are one vendor decision away from a configuration that you did not review, did not approve, and may not be able to demonstrate compliance with.

The right question is not “Can we use this SaaS product?” It is: “What do we need to own?”

Own the data flows that carry regulatory exposure. Own the orchestration layer in agentic workflows. Own the audit trail. Let vendors handle the rest – and let them change their defaults on their own schedule.

That is not a conservative stance. It is an engineering discipline applied to a domain where the consequences of getting it wrong are measured in regulatory fines, client trust, and legal liability.