AI and HIPAA: why on-premises removes the exposure.

A plain-English guide for teams handling regulated health data.

Health data is some of the most useful material to put an AI to work on, and some of the most tightly governed. If your work touches protected health information, the question is not only "will the AI help," it is "what happens to the PHI the moment it reaches the tool." This is a guide to what HIPAA actually cares about here, why cloud AI creates a new surface, and how running on-premises removes it, along with an honest account of what that does not do.

What HIPAA actually governs

At its center, HIPAA is about the disclosure and safeguarding of protected health information. It cares about who your PHI is shared with, under what agreements, and how it is protected wherever it goes. Two ideas do most of the work in this context. The first is the business associate: an outside company that handles PHI on your behalf, which generally has to be bound by a business associate agreement and its own safeguards. The second is the simple fact that every place PHI travels is one more place you have to secure and account for.

Why cloud AI creates a new surface

Send PHI to an outside AI service and, in most arrangements, that vendor is now handling protected health information on your behalf. That pulls them into scope as a business associate, requires a business associate agreement, and makes the vendor's retention, logging, staff access, and sub-processors part of your compliance perimeter. Even where a vendor offers the right agreement and the right controls, you have still added a party, a copy, and a surface that did not exist before, on behalf of every patient whose data passed through.

How on-premises removes the third-party vector

An on-premise AI changes the picture at the root. When the model runs on a system inside your own environment, with no outbound path to a vendor, PHI is read and answered on that machine and never leaves. There is no transmission to an outside company, so there is no new business associate to add, no third-party retention to govern, and no external copy to secure or breach. You are back to protecting data you already hold, under the controls you already run.

The honest limit

Here is the part a careful reader should insist on: no single tool makes an organization HIPAA compliant, and we will not pretend otherwise. Compliance is a program, spanning your policies, access controls, workforce training, audit, and physical security. An on-premise AI does not discharge any of that. What it does is remove one specific, significant exposure, the third-party disclosure of PHI that cloud AI introduces, so that the AI stops being the part of your stack that reaches outside your walls. The rest of the program remains yours, which is exactly where it should sit.

How to evaluate it

The questions are the same ones that protect any confidential work. Where does the model actually run? Is there any outbound network path once it is installed, and can you watch it? Who holds access after setup, including the people who built it? And the physical check settles it: a genuinely isolated system keeps working with the network unplugged, which means the PHI you loaded was never going anywhere. See what a Garnet build can and cannot see, and for the strict settings, what air-gapped means and how to prove it.

How a commissioned build gets there

A private AI you would run regulated data through is a real build: sizing the system, tuning a capable local model to your work, hardening the boundary so nothing phones home, and leaving something that keeps working after the people who set it up have gone. A Garnet build installs that system inside your own environment, network-isolated by default, with no standing access for anyone, including us, after handover. For how this is scoped for institutions, see on-premise AI for regulated and in-house teams; for the underlying file work, confidential document review and private documents.