Health data in an AI knowledge base: what GDPR compliance actually means

The GDPR distinguishes between ordinary personal data and special categories. Health data belongs to the second group. Under Article 9 it is subject to a general prohibition on processing with narrowly drawn exceptions, which in commercial practice usually means the explicit consent of the data subject.

The difference is not a formality. With ordinary data, a supervisory authority asks whether a legal basis exists. With health data it additionally asks whether one of the exceptions applies, and whether consent was really explicit, freely given, and granted for precisely this purpose.

This does not only concern medical practices, studios and treatment facilities. An industrial company holds health data too: in occupational reintegration files (BEM), in occupational health screening records, in reintegration agreements. Anyone building a knowledge base there faces the same question.

This article is not a substitute for legal advice.

This is where two roles separate that often get blurred. You are the controller under the GDPR. We are the processor. That means we process your data exclusively on your documented instructions.

The legal basis stays with you. Whether a customer has validly consented, whether that consent also covers analysis by an AI system, whether the purpose is still the same as at the point of collection: we cannot decide that for you, and we do not pretend we can.

If a vendor tells you their product makes you GDPR-compliant, that is not true. A product creates technical preconditions. The lawfulness of the processing arises with you.

What we contribute: a data processing agreement under Article 28 is a mandatory part of every contract with us, not a document handed over on request. It names health data explicitly as a possible subject of processing and lists our sub-processors by name.

You upload the form, as a photo or a file. It is stored on dedicated bare-metal hardware at Hetzner in Nuremberg and Falkenstein. We do not use generic cloud infrastructure, meaning neither Azure nor AWS nor Google Cloud. As things currently stand, this means there is no access under the US CLOUD Act.

For processing by the language model we work with Mistral AI in Paris. Two technical terms for that: embedding converts text into a mathematical form so the system can find passages that match in meaning. Inference is the model's actual answering step.

In practice: your data sits in Germany, the AI processing happens in the EU. In standard operation, personal data does not leave the European Economic Area, and no transfer to the United States takes place.

When you ask a question, the system finds the relevant passages in your own material and passes only those to the model. The model has no access to your database. The requests are short-lived; nothing is permanently stored at the provider.

Neither we nor the model provider train on your data. That is excluded contractually, not a setting someone could flip by accident.

When a data subject demands deletion, the instruction comes from you as the controller to us. In the production systems we normally carry it out within 24 to 48 hours.

Backups are a second step. There, a deleted record remains until the next rotation. That is standard across the industry and hard to solve differently in technical terms. We would rather write it down than claim "immediately and without a trace".

When the contract ends, we delete your data within 30 days across all systems, including production systems, backups and log data, as far as it carries personal references. We confirm the deletion in writing on request. Before that, you can request a complete export at any time.

With health data, internal access is often the bigger practical risk than hosting. A receptionist does not need to see the same records as the person providing treatment.

hAiner works with role-based access controls: whoever is allowed to see a given piece of information sees it here too. Every answer cites its source, so it stays traceable where a piece of information came from.

Data belonging to different customers is separated by distinct database structures. For the sake of precision: that is a logical separation, not physically separate hardware per customer. Transmission and storage are encrypted.

A few limits we would rather name up front than afterwards.

hAiner is not intended for medical, diagnostic or therapeutic decisions. The system makes a medical history form findable and surfaces connections. It does not assess treatment, and nobody should use it for that. No automated decision-making within the meaning of Article 22 takes place.

Whether you need a data protection impact assessment is your decision, not ours. The German supervisory authorities point out that this obligation can arise when AI applications are deployed. For the obligations under Articles 32 to 36 we support you with the information available to us.

And we are not currently certified to ISO 27001 or BSI C5. Both are in preparation. Until then we lay our security architecture open in conversation rather than advertising a seal we do not yet hold.

More on this on our topic page GDPR-compliant AI for mid-sized companies. If you would like to discuss your specific case: arrange an initial conversation.