An AI agent in a hospital can be GDPR compliant without living in your own data centre

Ask around a hospital about automation and you will hear that an AI agent in a hospital can only be GDPR compliant if it never leaves the building. That holds for some workflows. For most of them it is expensive caution. The regulation asks first which data a process touches at all, and only then where the computing happens.

So every hospital project we take on starts by sorting workflows by their data, before anyone talks about technology. Sort them that way and you find that several of the most worthwhile workflows never need a patient name.

What decides whether an AI agent in a hospital is GDPR compliant

Three decisions settle it, and all of them are made before the first line of code.

The field list matters most. An agent receives exactly the fields its task requires, and the export is built so the rest never travels with it. You cannot retrofit that as a setting later, it sits in the way the thing is built.

Next comes the processing chain. For every workflow we put in writing which providers are involved, where their machines stand, and that your data is not used for training there. We bring the data processing agreement with us, and European infrastructure is our default.

Then there is the trail that daily operation leaves behind. How long a case stays in the processing history, and who may search it, gets fixed the same way retention is fixed in the source system. Hospitals add medical confidentiality on top, which reaches further than the regulation and decides the question outright for some data.

Three data classes, three ways to build

Sort the workflows we run for clients by their data and three groups appear. Each has its own answer, ready before the project starts.

Workflows without personal data

Automated ordering of medication, implants and endoprostheses, stock reconciliation, early detection of unusual movements in the pharmacy. The agent works with article numbers, quantities, dates and supplier data. A workflow like this runs against a provider API on European infrastructure, because nothing leaves that could be traced to a person.

Workflows that can be pseudonymised

Bed management, reporting for ward managers, scheduling staff appraisals. These need a reference to the individual case, but no name attached to it. The agent works with the case number, and the table that turns a case number back into a person stays in the building. This is the group where the internal discussion tends to stop earlier than it needs to.

Workflows with free text and speech from the record

Dictated nursing reports belong here. A recording at the bedside contains names, diagnoses, observations and often a third person in the background, and none of that can be trimmed away without losing the point. Here the model runs on a dedicated server in a European data centre or on your own hardware in house, and the data stays inside your network. What the three locations cost, and at what volume your own hardware pays for itself, we worked through in a separate article.

Bed management, played through field by field

The example below is constructed. We have no released client references so far, so this is a built example rather than a case study.

Suppose the bed management desk of a general hospital plans the day's occupancy each morning: admissions from the emergency department, planned admissions, transfers, discharges, plus beds blocked for isolation or cleaning.

From the hospital information system the agent receives six items per case: case number, department, admission date, expected discharge date, isolation flag, and sex, because it governs which room a case can go into. Names, dates of birth, addresses, insurance numbers and diagnosis text are not laboriously masked, the export never asks for them.

Out of that comes an occupancy proposal: which case to which ward, which beds should stay free, where it gets tight in the afternoon. Every line carries the reason it exists, a department, an isolation flag, a discharge date.

The desk sees the proposal inside the system it already uses, and there the names sit next to it again, because the matching happens in house and not at the model. Who actually gets moved where is still decided by the desk. The proposal is its draft.

Cases the agent cannot place with confidence, an isolation without a recorded reason, or a transfer between two departments on the same day, go onto a short clarification list. That list is the most important part of the whole workflow, because it determines whether anyone has to clean up behind the proposals.

For your data protection officer the workflow then fits into four lines: six fields, one purpose, one recipient, one retention period. We supply that description, and it doubles as input for your data protection impact assessment.

What we bring to these questions

The data processing agreement is standard with us, as is a written description per workflow covering fields, purpose, recipients and retention. Access is logged so it stays traceable afterwards who saw and approved which case.

Every automation comes with a maintenance agent that watches operation and checks the input and output of each interface for changes. For data protection that is a practical asset: if an export suddenly delivers one field more after an update, the agent reports it instead of quietly passing it along. It is included in the fixed price.

Whatever sits on your side, involving the works council or clearing an access, we go through together beforehand in the automation check. That is preparation and does not count as build time.

Sophera Consulting builds these agents for each hospital individually, at a fixed price and without a subscription, and puts the field list, the processing location and the retention period in writing before anything is built. Which workflow in your hospital comes first, and which of the three groups it falls into, is what we clarify in the free automation check.

The recommendation

Take five workflows from your administration and sort them into the three groups. Start with one that has no personal data in it. That agent is built in one to two days, the test with real cases runs in the same week, and your hospital sees on a real case how an agent works before anyone debates the sensitive part.

For the next workflow from the middle group, ask to see the field list before anything is built. It is the shortest version of the data protection question your hospital has to answer, and it fits on half a page.