US / United States / revised 6 Nov 2026
HIPAA and AI Inference: Why Covered Entities Route PHI US-Only
HIPAA governs who may use protected health information and under what safeguards; it says nothing about where a server must sit. Yet most covered entities that put PHI into a model keep the whole inference path inside the United States. The reasons are contractual and practical: what each business associate agreement actually covers, which providers will sign one, state laws that do localise health records, and a risk analysis OCR can ask to see.
- Citation
- 45 CFR Parts 160 and 164 (Security Rule, Subpart C; Breach Notification Rule, Subpart D; Privacy Rule, Subpart E); HITECH Act of 2009
- Regulator
- HHS Office for Civil Rights (civil enforcement), the Department of Justice (criminal enforcement) and state attorneys general under the HITECH Act
- In force
- 14 April 2003 (Privacy Rule compliance date); 20 April 2005 (Security Rule compliance date)
- Maximum penalty
- Civil money penalties in four culpability tiers under 45 CFR 160.404, adjusted annually for inflation and capped per calendar year for identical violations; criminal penalties under 42 U.S.C. 1320d-6 of up to USD 250,000 and 10 years' imprisonment
Covered entities, business associates and the AI supply chain
The Privacy and Security Rules apply to covered entities (health plans, health care clearinghouses, and health care providers that conduct standard electronic transactions) and to their business associates. Under 45 CFR 160.103, a business associate is a person that creates, receives, maintains or transmits protected health information on behalf of a covered entity, and the definition reaches subcontractors all the way down the chain. Since the 2013 Omnibus Rule, business associates are directly liable for Security Rule compliance and for uses and disclosures the Privacy Rule does not permit.
A model provider that receives prompts containing PHI in order to generate completions is a business associate of the covered entity, or a subcontractor of one. So is a gateway that inspects those prompts to apply policy. OCR's cloud computing guidance goes further: a cloud service provider that maintains electronic PHI is a business associate even if it stores only encrypted data and holds no decryption key. The conduit exception is narrow, covering transmission services with no more than transient storage, and does not fit a service that reads the prompt to produce an answer.
Business associate agreements and their scope
Sections 164.502(e) and 164.504(e) require a written agreement before PHI flows to a business associate, and 164.308(b) and 164.314(a) carry the same requirement into the Security Rule. The agreement must limit uses and disclosures to those it permits, require appropriate safeguards, require reporting of breaches and security incidents, flow the same terms down to subcontractors, provide for return or destruction of PHI at termination where feasible, and make books and records available to HHS.
In practice the agreement is narrower than the vendor. Large cloud and model providers usually offer a BAA only for a published list of eligible services, and sometimes only for specific configurations or retention settings. A model endpoint outside that list, or a feature such as file storage or batch processing that the BAA excludes, is not covered, even when the same vendor signed the agreement. That scoping, more than geography, decides where PHI may go.
Minimum necessary and de-identification
Under 164.502(b) and 164.514(d), a covered entity must make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of a use, disclosure or request. The standard does not apply to disclosures to a health care provider for treatment or to the individual, but it does apply to most operational AI uses, such as summarising claims correspondence or drafting prior authorisation letters.
Data de-identified under 164.514(b) is no longer PHI. The Safe Harbor method requires removing 18 identifiers of the individual and of relatives, employers and household members, with no actual knowledge that the remainder could identify anyone; the alternative is a documented expert determination. Section 164.514(c) allows a re-identification code, provided it is not derived from information about the individual and the re-identification mechanism is not disclosed, which is the pattern a local pseudonymisation vault follows.
- Names, and geographic subdivisions smaller than a state, apart from the first three ZIP code digits where that area holds more than 20,000 people
- All elements of dates except the year for dates directly related to the individual, and ages over 89
- Telephone and fax numbers, email addresses, URLs and IP addresses
- Social Security, medical record, health plan beneficiary, account, certificate and licence numbers
- Vehicle and device identifiers and serial numbers, biometric identifiers and full-face photographs
- Any other unique identifying number, characteristic or code
Security Rule safeguards and breach notification
The Security Rule requires an accurate and thorough risk analysis of risks to electronic PHI (164.308(a)(1)(ii)(A)), risk management to reduce them, audit controls that record activity in systems containing ePHI (164.312(b)), integrity controls, and transmission security (164.312(e)(1)). Encryption is an addressable specification: it must be implemented where reasonable and appropriate, or the alternative documented. Security Rule documentation must be retained for six years (164.316(b)(2)).
HHS published a proposed overhaul of the Security Rule on 6 January 2025 that would, among other changes, make encryption and multi-factor authentication generally required and add a technology asset inventory and network map. At the time of writing it had not been finalised, and the current rule is the one OCR enforces. Under the Breach Notification Rule, affected individuals must be notified without unreasonable delay and no later than 60 calendar days after discovery; HHS must be notified, and breaches affecting more than 500 residents of a state or jurisdiction also require notice to prominent media outlets.
Where the US-only requirement actually comes from
HIPAA has no data localisation rule. OCR's cloud guidance confirms that covered entities may use a cloud provider that stores electronic PHI outside the United States under a BAA, while noting that the risks can vary greatly with the country involved and belong in the risk analysis. The US-only requirement most health systems impose comes from other sources, and they stack.
Texas SB 1188 also permits practitioners to use AI for diagnostic purposes within the scope of their licence, provided they review AI-generated records under Texas Medical Board standards and tell patients that AI was used. That makes the AI path itself a documented part of the patient record in Texas, not only a storage question.
- BAA scope: providers commonly limit their BAA to named services and regions, and covered entities write US-only processing and US-based support into their own BAAs with vendors
- Texas SB 1188: from 1 January 2026, covered entities must ensure that electronic health records containing patient information, including records held by cloud providers, are physically maintained in the United States or its territories
- Florida Statutes section 408.051: since 1 July 2023, health care providers using certified EHR technology must keep patient information stored offsite, including in the cloud, physically in the continental United States, its territories or Canada
- DOJ Data Security Program (28 CFR Part 202), effective 8 April 2025: restricts transactions that give countries of concern or covered persons access to bulk US sensitive personal data, with personal health data of 10,000 or more US persons in scope
- Payer, government programme and research agreements that add offshore restrictions or attestations of their own
- 01
BAA scope as an endpoint attribute
Record on every endpoint the BAA reference, the eligible service name, the model, and any configuration the BAA depends on, such as a zero-retention setting. A provider being on the BAA is not enough; the specific service and feature must be in scope, and the policy should check that on every request. - 02
Masking to minimum necessary in the data path
Detect Safe Harbor identifiers in-path, including Social Security numbers, medical record numbers, health plan beneficiary numbers, dates of service and street addresses, and replace them with vault tokens before the prompt reaches a model. Keep the clinical content the task needs; the goal is the minimum necessary, not an empty prompt. - 03
Storage-bearing features carry the localisation risk
State EHR laws reach stored records most clearly: vector stores built from chart notes, uploaded files, batch jobs, saved conversation history and fine-tuning data. Whether transient inference alone is covered is less settled, so most covered entities keep both on US infrastructure and treat each storage feature as needing its own approval. - 04
Who can reach the system, not only where it is
Some covered entity contracts, and some readings of state EHR laws, restrict offshore access as well as offshore storage. Record where each provider's support and operations staff can reach the service from, and treat an endpoint with offshore administrative access as out of scope for tenants whose contracts forbid it. - 05
Audit evidence for the risk analysis
OCR enforcement actions frequently cite a missing or inadequate risk analysis. A per-request receipt naming the endpoint, the BAA reference and the masking outcome, retained with the Security Rule documentation for six years, shows which systems processed PHI and under which agreement.
| # | Rule | Legal rationale |
|---|---|---|
| 01 | PHI-labelled requests resolve only to endpoints with an executed BAA whose scope names the exact service and model. | Sections 164.502(e) and 164.308(b) require satisfactory assurances before PHI is disclosed; a BAA that does not cover the service gives none. |
| 02 | PHI resolves to US-located endpoints only, and failover stays inside the US pool. | Meets the US-only clauses in covered entity contracts and state EHR localisation laws without relying on each application to check. |
| 03 | Mask Safe Harbor identifiers the use case has not been approved to send, and record which were masked on the receipt. | Applies the minimum necessary standard of 164.502(b) at the point of disclosure, where it can be enforced mechanically. |
| 04 | Deny storage-bearing operations (files, batch, vector stores, stored conversations) on PHI unless the tenant has approved that feature and its US location. | These features create records that laws such as Texas SB 1188 require to be physically maintained in the United States. |
| 05 | Deny any endpoint whose operator or parent is located in a country of concern under 28 CFR Part 202. | Personal health data of 10,000 or more US persons is in scope of the DOJ rule, and AI workloads reach that volume quickly. |
us-hipaa-only
The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.
Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.
How the policy engine workspackage yttsecunet.policies.us_hipaa_only
import rego.v1
baa := data.hipaa.baas[input.endpoint.provider_id]
baa_covers if {
baa.status == "executed"
input.endpoint.service in baa.covered_services
input.endpoint.model in baa.covered_models
}
countries_of_concern := {"CN", "HK", "MO", "CU", "IR", "KP", "RU", "VE"}
storage_ops := {"files", "batch", "vector_store", "stored_conversation"}
deny contains "PHI requires an executed BAA covering this service and model" if {
input.request.phi
not baa_covers
}
deny contains "PHI must be processed on US-located endpoints" if {
input.request.phi
input.endpoint.country != "US"
}
deny contains "storage feature not approved for PHI" if {
input.request.phi
input.request.operation in storage_ops
not input.tenant.approved_storage_ops[input.request.operation]
}
deny contains "operator in a country of concern (28 CFR Part 202)" if {
input.endpoint.operator.hq_country in countries_of_concern
}
deny contains "operator in a country of concern (28 CFR Part 202)" if {
input.endpoint.operator.parent_hq_country in countries_of_concern
}
default allow := false
allow if count(deny) == 0Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.
Does HIPAA require PHI to stay in the United States?
No. HIPAA requires business associate agreements and Security Rule safeguards, and OCR's cloud guidance accepts offshore storage under a BAA when the risk analysis accounts for it. US-only processing usually comes from BAA scope, covered entity contracts and state laws such as Texas SB 1188 and Florida's section 408.051.
Is a model provider a business associate if it keeps nothing?
Yes. It receives and processes PHI on the covered entity's behalf to produce the output, so it receives and transmits PHI even if it retains none afterwards. Zero retention reduces risk; it does not remove the need for a BAA.
Is YTT Secunet a business associate?
Yes. The gateway reads request content to evaluate policy and mask identifiers, so it is not a conduit. YTT Secunet signs a BAA for Enterprise Sovereign and Sovereign Dedicated tenants whose PHI traffic is restricted to US-only routes such as the us-hipaa-only pack.
Does masking make a prompt de-identified?
Only if what remains meets 164.514(b): all 18 Safe Harbor identifiers removed with no actual knowledge that the rest could identify the person, or an expert determination. Most clinical prompts keep some identifiers the task needs, so treat masked prompts as PHI and keep the BAA and US-only rules in place.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.