Palantir Engineers Used NHS Internal Emails—Japanese SMEs Should Take Note of the Consequences of ‘AI Vendor Dependence’

External Vendor Engineers Had Access to Internal Directory of 1.5 Million Employees An alarming situation has emerged w

By Kai

|

Related Articles

External Vendor Engineers Had Access to Internal Directory of 1.5 Million Employees

An alarming situation has emerged within the UK’s National Health Service (NHS). Engineers from the AI company Palantir had gained access to NHS internal email accounts. From these accounts, they could access a directory containing contact information for over 1.5 million NHS staff.

Imagine the risks involved when external vendors can freely view an organization’s internal directory.

The NHS is a massive organization with its own security teams. Yet, this happened. So, what happens when small and medium-sized enterprises (SMEs) grant access to their systems to AI vendors? How much do you consider the risk of your company’s customer lists, partner information, and sales data becoming fully visible to outsiders?

This is not just a “security issue”; it is a management issue.

Three Consequences of Vendor Lock-In

“I want to implement AI, but we don’t have engineers in-house. So, let’s rely on a vendor”—this pattern is almost universal for SMEs adopting AI. This in itself is not a bad thing. The problem arises when you find it impossible to escape from the vendor you relied on.

Recently, there have been several cases illustrating the consequences of vendor dependence. Here are three examples.

Consequence 1: Palantir × NHS—When ‘Convenience’ Turns into ‘Control’

Palantir provides an AI analytics platform to the NHS. The operation of the system involves deep engagement from Palantir engineers, and the acquisition of the email accounts occurred as an extension of that involvement.

Initially, it was supposed to be “necessary access rights for efficiency.” However, before long, the external vendor had infiltrated the organization’s core. It starts with convenience, leading to dependence, and ultimately results in a loss of control. This three-step process can happen in SMEs as well.

Consequence 2: Broadcom × VMware—30,000 Companies Flee

After Broadcom acquired VMware, approximately 30,000 customers migrated to Nutanix. The reason was the changes in the licensing structure and the lack of transparency in pricing post-acquisition.

Companies that depended on VMware were unable to adapt to the sudden changes in conditions. The costs of migration were enormous. However, the costs of staying were even higher. This is a typical outcome of “vendor lock-in.”

Let’s translate this to SMEs. Suppose all your business data is hosted on an AI vendor’s platform. One day, that vendor gets acquired. The pricing structure changes. The API specifications change. Restrictions are placed on data exports. Your business data becomes a hostage.

Consequence 3: Amazon × Kindle—A Product Used for 10 Years Suddenly Becomes Useless

Amazon announced the end of support for Kindle devices made before 2012. Users lost access to the Kindle Store. A product they had used for over a decade suddenly became unusable due to the manufacturer’s decision.

This is a hardware issue, but the structure is the same for AI services. Cloud-based AI services become unusable the moment the provider shuts down their servers. Unlike on-premises software, nothing remains in the user’s hands.

Why Are SMEs More Prone to Vendor Lock-In?

Large corporations have IT departments. They have the capacity to compare multiple vendors. They have legal teams to scrutinize contracts.

SMEs lack these resources. Therefore, they often think, “It’s easier if this vendor handles everything,” consolidating their operations under one company. This may seem rational at the time of implementation. However, three years later, when you want to switch, you might be told that data migration will cost 2 million yen. At that point, you are already trapped.

Be cautious of the sales pitches from AI vendors. “Leave everything to our platform”—this phrase, when turned around, means “Please depend entirely on us.”

Four Concrete Strategies for SMEs

1. Clearly Define Data Ownership in Contracts

The most important clause when contracting with an AI vendor is “data ownership.” Clearly specify in the contract who owns the data you provide, the analysis results generated by AI, and the trained models.

Particularly important is to confirm “in what format you can export data at the end of the contract.” Ambiguous contracts can lead to future hostage negotiations.

2. Base Solutions on Open Source Models

Open-source large language models like Llama, Mistral, and Gemma are rapidly improving in performance. By choosing solutions based on these, you can continue to use the model even if you switch vendors.

You might think, “Open source seems complicated.” However, using services that host open-source models (like Together AI, Replicate, Ollama, etc.) significantly lowers the technical barriers. You can start for just a few thousand yen per month.

3. Don’t Consolidate All Operations Under One Vendor

Use different vendors for different operations—accounting with freee, customer management with HubSpot, AI analysis with another tool. If one company changes its terms, you can simply switch that part.

This strategy is known as “best of breed,” which is common among large corporations, but the mindset of “it’s easier to have everything in one place” still prevails among SMEs. You should understand that the cost of convenience is lock-in.

4. Estimate “Switching Costs” Annually

If you were to switch from your current AI vendor to another service, how much would it cost? How many days would data migration take? How long would your operations be halted?

By estimating this annually, you can visualize changes in your dependency. If switching costs are rising year by year, it is evidence of increasing lock-in. You can take action early.

“Dependency” and “Utilization” Are Different

I am not saying that you should avoid using AI vendors. It is not realistic for SMEs to develop AI in-house. It is natural to seek external help.

However, “utilization” and “dependency” are different. Utilization means using the service in a way that allows for switching at any time. Dependency means continuing to use the service in a way that makes switching impossible.

Palantir engineers used NHS internal emails. 30,000 companies fled from VMware. Kindles suddenly became unusable. All of these are outcomes of “dependency.”

Check the data clauses in your contracts. Consider open-source options. Diversify your vendors. Regularly estimate switching costs.

All of these can be done starting today. And whether you do them or not will significantly change your management freedom three years from now.

Mastering AI means not being used by AI vendors.

POPULAR ARTICLES

Related Articles

POPULAR ARTICLES

JP JA US EN