TL;DR
Data residency laws mean something different for sensitive data in healthcare and insurance than they do in banking, and the stakes are rarely comparable. Healthcare data breaches have cost more than any other industry for 13 years straight, and the newest figure, $6.64 million on average, is still the highest of any sector even after falling from last year’s number. Insurers answer to state regulators that fintechs never have to deal with. This piece builds on our guide to data residency rules for fintech, adding what financial services never had to solve: keeping the AI itself, not just the data, inside a defensible legal boundary. HIPAA, the NAIC's Insurance Data Security Model Law, and sovereign AI infrastructure all show up here, along with questions worth asking any AI vendor before patient or policyholder data leaves your control.
Key terms
Data residency: The physical location where data is stored and processed, usually set by a contract, an internal policy, or a specific regulation.
Data sovereignty: The principle that more than one country’s laws can apply to the same data at once, typically the country where it was collected, the country where it’s stored, and the country where the company handling it is headquartered.
Sovereign AI infrastructure: AI compute, models, and data management pipelines kept under the legal and operational control of the jurisdiction whose data they process, covering where the hardware sits and who can access or export the data and the model weights.
Cross-border data transfer: Moving personal or regulated data outside the country or region where it was collected, one of the most common international transfers, which triggers a separate legal basis under the applicable laws in most data protection regimes.
Protected health information (PHI): Individually identifiable health data covered by HIPAA, including anything tied to a patient's care, payment, or health status.
Data privacy and data residency compliance both get harder the moment healthcare or insurance data touches an AI model. Instead of one thing to locate, you now have two: the data and the system that processes it. In the US, a clinician’s notes fall under the Health Insurance Portability and Accountability Act (HIPAA), and a claims adjuster’s file falls under state insurance law. If the patient or policyholder is in the European Union (EU) or elsewhere in the European Economic Area (EEA), the General Data Protection Regulation (GDPR) applies on top of whatever customer data is already protected. Once that data goes into a hosted AI model, you also need to know where the model runs, who operates it, and whether a regulator can reach the data and the operator if something goes wrong.
Our companion piece on data residency rules for fintech covers GDPR, the Digital Operational Resilience Act (DORA), and the Payment Card Industry Data Security Standard (PCI DSS) for financial firms choosing a cloud provider. Healthcare and insurance carry the same cross-border data compliance and data flows as financial services. They also face two additional layers: health data has special protected status under most privacy laws, and AI use cases such as clinical decision support and claims triage fall into territory regulators are only starting to address.
This piece covers what changes for healthcare and insurance specifically, and what sovereign AI infrastructure means once AI, not just storage, is part of the compliance picture.
Data sovereignty vs. data residency: why healthcare and insurance treat them differently
Data sovereignty and data residency are often used interchangeably, which muddies real data residency concerns with jurisdictional ones, but they answer different questions.
Data residency is about location: a law, contract, or internal policy requires patient records to be stored in Germany, for example. Data sovereignty is about jurisdiction: which countries’ laws can reach the data, and more than one often can at the same time. The collection country, the storage country, and the country where the handling company is headquartered can each have a legitimate claim on the same record.
Each layer narrows the question and widens what a vendor has to prove.
Both sectors hold sensitive personal data that triggers extra legal protection beyond standard privacy rules. A payment record and a diagnosis are both personal data, but most privacy laws treat health information as a separate, higher-risk category. Insurance claims data often combines financial data with that same higher-risk category, since a claims file often includes treatment notes, diagnoses, and billing codes alongside payment details.
Whether a record counts as medical data by default decides what a vendor contract needs to cover. A residency clause that only names a storage region, such as Frankfurt, leaves open which courts, regulators, and disclosure laws can reach a health record stored there, including those in the provider’s home country.
What makes healthcare data residency requirements different from other industries?
Healthcare data sovereignty starts with a number worth sitting with: healthcare data breaches cost an average of $6.64 million each in 2026, down 10.5% from the year before, according to IBM’s 2026 Cost of a Data Breach Report. Healthcare’s drop ran against the trend: the global average rose 12% to a record $4.99 million. Healthcare still led every other sector, for the 13th year running.
Given those stakes, many healthcare teams assume HIPAA requires patient data to stay in the US, but it doesn’t. The US Department of Health and Human Services (HHS) confirms that HIPAA allows PHI to be stored overseas, "provided the covered entity or business associate enters into a HIPAA-compliant business associate contract or agreement (BAA) with the CSP that will be creating, receiving, maintaining, or transmitting electronic protected health information (ePHI) on its behalf, and otherwise complies with the HIPAA Rules”
The cloud provider becomes a business associate the moment it touches PHI. It must comply with HIPAA's Security Rule whether or not a BAA is signed.
What HIPAA requires is a risk analysis that accounts for where the data sits. HHS notes that risk to overseas PHI "may vary greatly depending on its geographic location." That puts the burden on both the covered entity and the provider.
Both have to evaluate a specific country’s legal environment, rather than assume any region is automatically safe. That’s still a lower bar than GDPR, which restricts transfers of personal data outside the EU unless specific safeguards are in place. A signed BAA doesn’t replace that analysis. If the provider stores data in a country with weak enforcement or broad government access laws, those risks still have to be identified and addressed.
Healthcare data residency requirements get harder once AI enters the stack. A model fine-tuned on patient data, or an AI tool summarizing clinical notes, now processes PHI in a new location: wherever that model runs.
Cross-border data adds its own version of this problem, separate from HIPAA: Svitla work on the MSBase Foundation's MS patient registry shows the scale it can reach. The Australia-based registry integrates real-world patient data and IoT device data, including volumetric MRI metrics, from 45 countries. Each contributing country’s own data protection law governs its share of that data, independent of HIPAA. Once predictive models are built on that data, the registry has to track where each model runs, not just where each data input is stored.
How insurance adds another layer of data obligations
Insurance adds its own layer on top of general data protection law. Unlike HIPAA, the model law places responsibility on the licensee rather than the vendor, so the insurer must oversee the security of any third party that stores its data. The National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law requires licensees to build and maintain a risk-based security program. It also requires them to investigate cybersecurity events and notify the state insurance commissioner when one occurs. Licensees that already comply with HIPAA are exempt from the security program requirement, though not from the investigation and notification rules.
As of August 2025, 28 US jurisdictions have adopted it. An insurer operating across state lines is already managing a patchwork of state-level security obligations before a single AI vendor enters the picture.
Both stacks apply before an AI vendor is even in the picture.
Cross-border data transfers carry the highest stakes in claims processing, because claims files are among the most sensitive records an insurer holds. Even an auto claim can include medical records from an injury, alongside financial details and sometimes legal filings. Insurers increasingly route that data through third-party administrators, offshore processing centers, or AI-assisted triage tools to manage volume. Each handoff to a third-party administrator, offshore center, or AI tool becomes a new cross-border data transfer once the data leaves its country of origin. Under GDPR, each of those transfers needs its own transfer mechanism, such as an adequacy decision or standard contractual clauses (SCCs). A general outsourcing agreement doesn’t cover it.
The EU adds a layer many insurers don't expect. DORA applies directly to most insurance and reinsurance undertakings, and to insurance intermediaries larger than small and medium-sized enterprises. That's the same regulation our fintech piece covered for banks. An EU insurer evaluating an AI vendor for claims automation likely falls under the same compliance rules a bank already answers to when choosing a cloud provider. Those rules fall under DORA’s Information and Communication Technology (ICT) risk management and third-party oversight regime. DORA’s definition of an ICT third-party provider is broad enough to reach AI-based services, even though the regulation doesn’t name AI vendors specifically.
What is sovereign AI infrastructure, and why does healthcare and insurance AI need it?
Sovereign AI infrastructure goes a step further than data residency. Gartner puts it this way: sovereign AI "is shifting from data residency to control of compute capacity." For healthcare and insurance, that means asking who controls the GPUs, the model weights, and the pipeline that turns patient or policyholder data into a prediction, not just where the data sits.
A cloud region setting doesn't answer who can access a model's training data, export its weights, or shut off access during a dispute. A few concrete examples show what sovereign AI infrastructure looks like once vendors build for it, instead of just advertising a regional data center:
- Microsoft's EU Data Boundary keeps data processed by its AI services for EU customers within the EU, addressing data residency. Microsoft itself is still a US company, though, so the Data Boundary alone doesn’t settle sovereignty. A Sovereign Landing Zone, which is a preconfigured set of Azure policies and controls for regulated workloads, applies specific compliance controls on top of that.
- National partner clouds run Microsoft technology but are operated by local companies (Germany’s Delos Cloud is an SAP subsidiary, and France’s Bleu is a joint venture of Orange and Capgemini). Delos is built to the requirements of Germany’s BSI, the country’s federal cybersecurity authority, and Bleu is built to SecNumCloud, the security certification issued by ANSSI, France’s national cybersecurity agency.
- Azure Local extends the same idea on-premises, running AI models on local hardware with a local control plane. This lets a hospital network or insurer keep inference entirely inside its own facility when regulation or contract terms demand it.
To meet AI data residency requirements, a healthcare system or insurer needs to ask an AI vendor four questions beyond storage location: where training happens, where inference happens, who can access the underlying model, and what happens to the data and model weights when the contract ends.
Does using a cloud AI vendor transfer your compliance responsibility?
It’s shared, not fully retained. Signing a BAA with an AI vendor satisfies the business-associate requirement under HIPAA, and makes the vendor directly liable under HIPAA’s Security Rule too. Signing a BAA with an AI vendor satisfies the business-associate requirement under HIPAA. It doesn't remove the covered entity’s obligation to conduct its own risk analysis, covering where the vendor’s models run and which subcontractors, such as a foundation model provider, process the data.
The same logic applies on the insurance side. In states that have adopted the NAIC model law, the insurance commissioner holds the licensee accountable for investigating and reporting a cybersecurity event, even when it occurs at an AI vendor or subcontractor. Outsourcing the infrastructure doesn't outsource the liability.
What should a healthcare or insurance company ask an AI vendor before deployment?
One question is answered in the data residency clause in vendor contracts. The table below covers the rest.
| Question to ask | Why it matters |
| Where does training happen, and where does inference happen? | These can be different locations, and both matter for jurisdiction. |
| Who can access the model's training data and weights? | Determines exposure if the vendor is compelled to disclose data under another country's law. |
| Is there a signed BAA (healthcare) or equivalent data processing agreement (insurance)? | Required under HIPAA, and expected under most state and EU frameworks. |
| What subprocessors does the vendor use, and where are they located? | Each subprocessor is a new potential cross-border data transfer. |
| What happens to data and model weights if the contract ends? | Determines whether deletion is verifiable or only promised. |
| Can the vendor support a fully on-premises or single-region deployment if required? | Confirms whether sovereign AI infrastructure is available, not just marketed. |
Can cloud-based AI models comply with strict local data residency requirements?
Often, yes, but it depends on what the vendor built, not what the sales page claims. A general-purpose hosted AI service with no regional controls typically can’t guarantee where your data is processed during fine-tuning or inference. A vendor can offer a sovereign landing zone, in-region inference, or an on-premises deployment option, provided the contract names which of those applies. Ask for evidence, such as architecture documentation, third-party audit reports, or certifications that cover the specific deployment you’ll use.
Compliance is an architecture decision
Data residency compliance in healthcare and insurance was already more demanding than in most industries before AI entered the picture. HIPAA allows PHI to be stored overseas, but the risk analysis it requires is easy to underestimate. Insurance regulators hold licensees accountable no matter how many vendors sit between them and the data. GDPR’s health-data protections and DORA’s third-party oversight regime apply on top of both, whenever a patient or policyholder sits in the EU.
Add an AI model to the stack, and three new questions take over: where the model runs, who controls it, and whether that control survives a regulator’s scrutiny or a contract dispute.
Treating sovereign AI infrastructure as a detail to settle after the pilot works leads to a bad outcome. Healthcare and insurance teams end up explaining a shortfall to a regulator, instead of avoiding one. Teams should prioritize vendor location, access control, and data residency requirements as part of the architecture decisions. These should be settled those before the first patient record or claims file ever reaches the model, the same way our cloud solutions team approaches infrastructure for any regulated workload.
