Healthcare AI Security & Compliance

Healthcare AI handles some of the most sensitive information a company can touch.

So when somebody asks us, “Is your AI HIPAA compliant?” the easy answer would be “yes.”

The more useful answer is: we build systems to comply with the regulations that apply to your project, but no piece of software can make your clinic compliant by itself.

I have worked on the clinic side as well as the software side. A surprisingly large part of security has nothing to do with encryption algorithms or the logo of your cloud provider. It is somebody sharing a password, a receptionist leaving a workstation unlocked, everyone having administrator rights because it was easier five years ago, patient exports lying in Google Drive, or a former employee whose account was never disabled.

You can build Fort Knox in AWS and then give everybody the key.

So we treat compliance as a combination of architecture, software, infrastructure and the way the clinic actually works.

What regulations apply to healthcare AI?

There is no universal “healthcare AI regulation.” The regulatory stack depends on where the clinic is, where the patients are, what data is processed, and — very importantly — what the AI actually does.

An appointment-booking agent and an AI that tells a physician which cancer treatment to choose are both “healthcare AI.” Legally and technically they are very different animals.

United States: HIPAA, HITECH and the BAA

HIPAA is the main US federal framework people usually mean when they talk about medical-data privacy.

HIPAA protects Protected Health Information — PHI handled by covered entities such as many healthcare providers, health plans and clearinghouses, and by their business associates. Its rules cover permitted use and disclosure of PHI, security safeguards for electronic PHI, and breach notification requirements.

If we handle PHI on behalf of a HIPAA-covered clinic, we may become its Business Associate. In that situation, a Business Associate Agreement — BAA — normally defines what we may do with the PHI, how it must be protected, what happens after an incident, what obligations pass to subprocessors, and what happens to PHI when the relationship ends.

So yes: where a BAA is legally required for the project, we can work under one.

But signing a BAA does not magically make the clinic HIPAA compliant. We are responsible for our part of the system. The clinic is still responsible for its own people, policies, permissions, devices, physical access, training and use of the system.

Europe: GDPR is about much more than putting a cookie banner on the website

Under GDPR, health information belongs to the specially protected categories of personal data. That includes obvious things such as diagnoses and laboratory results, but the definition is much wider. Information can become health data because it reveals something about a person’s physical or mental health.

For a healthcare AI project, GDPR affects several concrete questions:

• Where is the data stored, and why is it being processed?
• Which company is the controller, and which is the processor?
• Which third parties receive information, and is anything transferred outside the EEA?
• How much information actually needs to be sent to an AI model?
• How long is it kept, and is a Data Protection Impact Assessment needed?

This is exactly why saying “our product is GDPR compliant” without discussing the implementation does not tell you very much.

We design the actual data flow first.

The EU AI Act

The EU AI Act adds another layer. It uses a risk-based approach rather than treating every AI application the same, and healthcare can fall into the higher-risk categories depending on what the system actually does.

Again, a bot answering “what time does the clinic close?” and an algorithm making patient-specific diagnostic recommendations are not the same thing.

The more the system affects diagnosis, treatment, safety or access to important services, the more seriously the regulatory requirements need to be treated. Depending on the case, requirements may cover risk management, documentation, human oversight, data governance, logging, accuracy and post-market monitoring.

We define that boundary before we design the solution.

MDR and IVDR: when AI becomes medical software

This is the line many AI developers miss.

In the EU, software itself can be a medical device when its intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis or treatment of disease. General-purpose software merely used inside a healthcare organization does not automatically become a medical device.

Under the Medical Device Regulation, software used to provide information for diagnostic or therapeutic decisions can fall under medical-device classification, with the risk class increasing when a wrong decision could lead to serious deterioration or death.

That distinction strongly influences how we design medical AI.

A system can summarize information for a doctor, assemble source material and prepare a draft while leaving the actual clinical judgment with the physician. Move the same product a few steps further and say, “This software determines which treatment this patient requires,” and you may have entered a completely different regulatory world.

That is one of the reasons we do not casually build “autonomous AI doctors.”

What about EMA?

EMA — the European Medicines Agency — gets mentioned surprisingly often in conversations about European healthcare AI.

But EMA is not the general regulator for clinic software.

EMA becomes relevant when AI is used in the medicinal-product lifecycle: drug discovery, development, clinical evidence, authorization and post-authorization activities.

If you are building a reception agent for a dermatology clinic, EMA probably has nothing to do with your project. If you are building an AI platform supporting pharmaceutical development, it may.

European Health Data Space

The European Health Data Space — EHDS — is another important part of the European healthcare-data environment.

It creates a framework for electronic health-data access, exchange, EHR interoperability and secondary use of health data. Its requirements are being phased in over several years.

For many small clinic AI projects, EHDS is not the first problem we need to solve tomorrow morning. For EHR platforms, interoperability projects, large healthcare organizations and products designed for long-term EU deployment, it absolutely belongs on the architecture radar.

UK healthcare data

The UK has its own UK GDPR and Data Protection Act framework. Health data remains special-category data, and processing it requires both a lawful basis and an appropriate condition for handling special-category information.

The UK and EU frameworks are still closely related, but they should not simply be treated as identical forever. UK privacy law continues to develop separately.

Israel

For Israeli deployments, we work around the Israeli Privacy Protection Law and the Privacy Protection Regulations, including the Data Security Regulations.

Israeli rules affect how personal information is stored and secured, how databases are managed, and under what conditions personal information can be transferred abroad.

That last point matters immediately if somebody wants to connect a local clinic database to an overseas AI provider.

For other countries, we do the same exercise with the applicable local law. We have worked with clinics and healthcare projects in the US, Europe, Israel, the CIS and Asia, so “just put everything on the same US cloud account” was never a realistic architecture for us.

Where do we actually store patient data?

Where it should be stored.

For one project, the correct setup may be an EU data center. For another, data must stay inside a specific country. For a hospital, the answer may be fully on-premises.

We can also deploy inside isolated or restricted network segments where required.

And the architecture affects the AI models themselves. Sometimes using a managed model such as OpenAI, Anthropic or another external provider is absolutely reasonable. Sometimes it isn’t.

For sensitive applications we can use local models, or build a hybrid architecture where sensitive information is processed locally first and only the required anonymized or de-identified information is sent further. That’s the exact approach we used for InnMap — raw patient data reduced locally before anything anonymized reaches a public LLM.

Your project determines the infrastructure. We do not redesign the project to fit whichever cloud service happens to be fashionable this quarter.

Who can access the data?

Access should follow roles, not curiosity.

Doctor, nurse, receptionist, administrator, call-center operator and developer do not need the same information. We design role-based access with the customer and log important actions.

Our developers should not require routine day-to-day access to your production patient database in order to do their jobs.

And when AI is involved, there is another important question ordinary systems did not always have to answer: what exactly was sent to the model?

That is why auditability matters.

For production systems we can log user requests, source information, retrieved documents, tool calls, model or workflow versions, generated responses, human approvals and escalation events.

Eventually somebody will say, “The AI told a patient something strange.”

At that point I prefer having a log over organizing a séance with the development team.

What happens to the data if we stop working together?

You get it back.

The exact deletion process follows the contract, applicable legal-retention requirements and backup lifecycle, but the philosophy is straightforward:

Your patient data is not our hostage.

We also do not quietly use one clinic’s patient data to train products for everybody else. If there is ever a separate legitimate reason to use customer data outside the project, that should be explicit and separately agreed.

Our rule for healthcare AI security

We do not begin with “Which LLM should we use?”

We begin with what information we are touching, what jurisdiction applies, who needs access, what must never leave the clinic, what happens if the AI is wrong, what needs to be auditable, and whether the regulatory picture changes if the system moves from administration into clinical decision-making.

Then we choose the technology.

It is a little less sexy than putting “HIPAA + GDPR + AI Act compliant” underneath the logo.

It is also much closer to how compliance works in an actual clinic.

This page describes our general engineering approach and major regulatory frameworks. It is not jurisdiction-specific legal advice; exact requirements are determined for each project.