Self-hosted vs. cloud AI: why 43% of healthcare orgs are choosing local

Something is shifting in how healthcare organizations think about AI infrastructure. According to recent industry surveys, 43% of healthcare organizations are now experimenting with locally hosted AI models, up from single digits just two years ago. The question is no longer whether AI belongs in healthcare. It is where that AI should run.

The data sovereignty movement

For most of the past decade, the default approach to AI was straightforward: send your data to a cloud provider, get results back. OpenAI, Google Cloud, Azure, the infrastructure was someone else's problem. That model works fine for a lot of industries. It does not work well for healthcare.

Healthcare data is governed by some of the strictest privacy legislation in the world. In Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) and Ontario's Personal Health Information Protection Act (PHIPA) place explicit restrictions on how personal health information can be collected, stored, and transmitted. The moment patient data crosses a border, even to a US-based cloud server, the organization processing that data faces a new set of legal obligations it may not be equipped to handle.

This is not a theoretical risk. IBM's Cost of a Data Breach Report consistently places healthcare at the top of the list for breach costs, with the average healthcare breach now reaching US$7.4 million. That figure includes regulatory fines, legal fees, notification costs, and the long-tail reputational damage that follows. For a developmental services agency in Ontario operating on a provincial budget, even a fraction of that number could be devastating.

What "self-hosted" actually means

Self-hosted AI does not mean building a data center in your basement. It means running AI models on infrastructure that you control, whether that is a dedicated server in a Canadian data center, a private cloud instance within your own virtual network, or hardware sitting in a locked server room on-premises.

The key distinction is the data path. With cloud AI services like ChatGPT or Google Gemini, your prompts, your data, and the model's responses all travel through third-party infrastructure. The provider's terms of service govern what happens to that data. With self-hosted models, the data never leaves your network. The model runs locally, processes locally, and returns results locally. There is no external API call, no cross-border data transfer, no third-party data processing agreement to negotiate.

Modern open-weight models from Meta (Llama), Mistral, and Alibaba (Qwen) have made this practical in ways that were not possible even 18 months ago. A model capable of handling clinical documentation, summarization, and conversational AI can now run on hardware that costs less than a year of enterprise ChatGPT licenses.

Comparing the two approaches

The trade-offs between cloud and self-hosted AI are real, and they look different depending on what you need.

Cloud AI gives you access to the largest, most capable models without managing any infrastructure. You get automatic updates, broad tool integration, and minimal setup time. The downsides are data exposure, ongoing per-token costs that scale with usage, latency that depends on network conditions, and limited control over model behavior. For a healthcare organization, the data exposure issue alone can be disqualifying.

Self-hosted AI gives you complete control over the data pipeline. No information leaves your network, costs are fixed and predictable after initial setup, and you can fine-tune models to your specific domain. You handle the hardware, model updates, and maintenance. The infrastructure requirements have dropped significantly, but they are not zero.

For many healthcare organizations, the calculation has become straightforward: the cost of managing your own AI infrastructure is lower than the cost of a single breach. And unlike cloud subscriptions, the hardware is an asset you own.

Why this matters for DS agencies

Ontario's developmental services agencies handle some of the most sensitive data in the healthcare system. Resident records include personal health information, behavioral support plans, incident reports, medication histories, and detailed notes on daily care. This information is protected under both PIPEDA and PHIPA, and the consequences of a breach go beyond financial penalties.

These agencies also operate under Regulation 299/10, which sets quality assurance measures that require detailed record-keeping across multiple areas. AI tools that can help with compliance scanning, documentation review, and staff training tracking are in high demand. But agencies cannot adopt those tools if using them means sending resident data to a foreign server.

Self-hosted AI solves that problem at the infrastructure level. When the model runs on Canadian servers, within the agency's own network or a Canadian hosting provider, the data sovereignty question is settled before the first prompt is ever sent. Agencies get the efficiency gains of AI without creating new privacy risks.

The path forward

The 43% figure is notable because it represents a fundamental shift in how healthcare organizations evaluate technology. The question is no longer "should we use AI?" but "where should we run it?" For regulated industries in Canada, the answer increasingly points to local infrastructure.

This does not mean cloud AI has no role. There are use cases, particularly those involving non-sensitive data, general research, or public-facing information, where cloud services make perfect sense. But for anything touching personal health information, the risk profile of cloud AI is difficult to justify when self-hosted alternatives exist.

At Merakey, we built Sentinel specifically for this use case: AI agents that run entirely on Canadian infrastructure with no external API calls. The model, the data, and the results all stay within the organization's control. For agencies that need AI capabilities without the privacy trade-offs, that distinction is everything.