On-Premise vs. Cloud-KI im Gesundheitswesen: DSGVO-Abwägung

Die Frage, wo ein KI-System im Gesundheitswesen läuft, wirkt wie eine Infrastrukturfrage: welche Server, welche Region, welcher Anbieter. In der Praxis ist sie eine Entscheidung über Data Governance, und die Infrastruktur folgt daraus. Die Frage, die die meisten Fälle entscheidet, lautet nicht „Cloud oder On-Premise?“, sondern „Welche Daten verlassen unsere Kontrolle, in welcher Form, und wer kann hinterher nachweisen, was mit ihnen geschehen ist?“ Wer diese Frage präzise beantwortet, stellt meist fest, dass sich das Deployment-Modell von selbst ergibt.

Der vorliegende Leitfaden richtet sich an Healthcare-Startups, Kliniken, Medizinsoftware-Unternehmen und Digital-Health-Teams in Europa, die KI mit sensiblen Gesundheitsdaten einsetzen möchten und unsicher sind, ob Cloud-KI zulässig ist. Er vergleicht Public-Cloud-KI, Private Cloud und On-Premise-Betrieb, zeigt, wann welches Modell vertretbar ist, und beschreibt die Architekturmuster, mit denen die meisten Teams eine Alles-oder-nichts-Entscheidung vermeiden. Der Leitfaden ist eine technische und strategische Orientierung, keine Rechtsberatung: Die Rechtsgrundlage der Verarbeitung und die abschließende Entscheidung über Datenübermittlungen gehören in die Verantwortung Ihrer Datenschutzbeauftragten und Ihrer Rechtsberatung.

Warum legen Gesundheitsdaten die Messlatte für KI-Deployments höher?

Gesundheitsdaten legen die Messlatte für KI-Deployments höher, weil die DSGVO sie in Art. 9 DSGVO als besondere Kategorie personenbezogener Daten einstuft. Ihre Verarbeitung ist untersagt, sofern nicht eine von wenigen Bedingungen greift, etwa Gesundheitsversorgung, öffentliche Gesundheit, wissenschaftliche Forschung oder ausdrückliche Einwilligung. Diese eine Einstufung wirkt sich auf jede Infrastrukturentscheidung aus. Eine umfangreiche Verarbeitung von Gesundheitsdaten erfordert in der Regel eine DSFA (Datenschutz-Folgenabschätzung) nach Art. 35 Abs. 3 lit. b DSGVO, und Gesundheitsdienstleister oberhalb der Größenschwellen fallen als Sektor mit hoher Kritikalität zusätzlich unter die NIS2-Richtlinie, die ein Cybersicherheits-Risikomanagement obendrauf verlangt. Nichts davon verbietet KI oder Cloud. Wohl aber muss jeder Weg, den Patientendaten nehmen, begründet, abgesichert und dokumentiert sein, und ein KI-System fügt typischerweise gleich mehrere neue Datenflüsse hinzu: Prompts, Embeddings, Logs, Evaluationsdatensätze und Modellausgaben. Fünf Eigenschaften entscheiden darüber, ob ein Deployment diese Anforderungen erfüllen kann.

Besondere Kategorien personenbezogener Daten

Der Status als besondere Kategorie bedeutet, dass Gesundheitsdaten vor jeder Verarbeitung sowohl eine Rechtsgrundlage nach Art. 6 DSGVO als auch eine Bedingung nach Art. 9 DSGVO benötigen, auch dann, wenn ein KI-Anbieter sie in Ihrem Auftrag verarbeitet. Der Begriff reicht weiter als Diagnosen: Terminhistorien, Verordnungen, Überweisungsschreiben und Freitextnotizen, die eine Erkrankung erwähnen, fallen alle darunter. Teams klassifizieren die offensichtlichen Felder oft korrekt und übersehen den Freitext, obwohl gerade er das ist, was Sprachmodelle verarbeiten.

Datenminimierung

Datenminimierung nach Art. 5 Abs. 1 lit. c DSGVO verlangt, dass die Verarbeitung auf das für den Zweck notwendige Maß beschränkt bleibt. Für KI ist das ganz konkret: Ein Modell, das Entlassbriefe zusammenfasst, braucht dafür weder den Namen noch die Versichertennummer noch die Adresse der betroffenen Person. Jedes Feld, das Sie vor der Inferenz entfernen, kann nicht abfließen, kann von keinem Anbieter gespeichert werden und braucht keine Transferprüfung.

Zugriffskontrolle

Zugriffskontrolle muss sich in einem KI-System auch darauf erstrecken, was das Modell abrufen kann, nicht nur darauf, wer sich anmelden darf. Ein klinischer Assistent, der jedes Dokument in einem Repository durchsucht, zeigt bereitwillig einen Datensatz an, für den die anfragende Fachkraft nie berechtigt war. Art. 32 DSGVO verlangt geeignete technische Maßnahmen, und in der Praxis heißt das: Die Retrieval-Schicht setzt dieselben rollenbasierten Berechtigungen durch wie das Quellsystem.

Auditierbarkeit

Auditierbarkeit bedeutet, auch Monate später rekonstruieren zu können, wer was gefragt hat, welche Daten das System verwendet hat und was es geantwortet hat. Der Grundsatz der Rechenschaftspflicht in Art. 5 Abs. 2 DSGVO erwartet, dass Sie die Einhaltung nachweisen können, und der EU AI Act schreibt in Art. 12 eine automatische Protokollierung für Hochrisiko-KI-Systeme vor, wobei Betreiber diese Logs mindestens sechs Monate aufbewahren müssen. Ein Deployment, das Sie nicht auditieren können, können Sie auch nicht verteidigen.

Datenresidenz

Datenresidenz betrifft die Frage, wo Daten gespeichert und verarbeitet werden und wessen Recht auf sie zugreifen kann. Übermittlungen personenbezogener Daten in Länder außerhalb des EWR benötigen eine Übermittlungsgrundlage nach Kapitel V DSGVO, und die beiden früheren Datenschutzrahmen zwischen EU und USA wurden 2015 und 2020 vom Europäischen Gerichtshof für ungültig erklärt. EU-Hosting verringert das Übermittlungsrisiko, klärt aber nicht alles: Muttergesellschaft, Support-Zugriffe und Unterauftragsverarbeiter eines Anbieters können trotzdem anderswo angesiedelt sein.

Was unterscheidet Cloud-KI, Private Cloud und On-Premise-Betrieb?

Cloud-KI, Private Cloud und On-Premise-Betrieb unterscheiden sich darin, wer die Infrastruktur betreibt, die mit Patientendaten in Berührung kommt, und damit darin, wem Sie vertrauen und wen Sie vertraglich binden müssen. Die drei Modelle sind Punkte auf einem Spektrum und keine konkurrierenden Lager, und die meisten Organisationen nutzen am Ende mehr als eines.

Public-Cloud-KI bedeutet, ein bei einem Anbieter gehostetes Modell über eine API aufzurufen oder einen verwalteten KI-Dienst in einer Hyperscaler-Region zu nutzen. Sie senden Daten nach außen, der Anbieter führt die Inferenz aus, und Sie erhalten ein Ergebnis zurück. Sie gewinnen Zugang zu den leistungsfähigsten Modellen, haben kaum Betriebsaufwand und können schnell iterieren; im Gegenzug hängen Sie vom Vertrag, den Aufbewahrungseinstellungen und den Unterauftragsverarbeitern des Anbieters ab.

Private Cloud bedeutet dedizierte oder Single-Tenant-Infrastruktur, typischerweise in einer EU-Region, auf der Sie das Modell selbst bereitstellen und kontrollieren: ein Open-Weight-Modell auf reservierten GPU-Instanzen in Ihrem eigenen Cloud-Konto oder ein dediziertes Deployment eines Anbieters mit isoliertem Tenant. Die Daten verlassen zwar Ihr Gebäude, nicht aber Ihre administrative Kontrolle.

On-Premise bedeutet, dass das Modell auf Hardware in Ihrem eigenen Rechenzentrum oder im Serverraum Ihres Krankenhauses läuft, innerhalb Ihres Netzwerkperimeters. Nichts verlässt das Haus, solange Sie es nicht selbst senden. Sie tragen die volle Verantwortung für Hardware, Patching, Monitoring und Modell-Updates und sind auf Modelle beschränkt, deren Lizenz den lokalen Betrieb erlaubt.

Wie schneiden Cloud-, Private-Cloud- und On-Premise-KI im Gesundheitswesen im Vergleich ab?

Cloud-, Private-Cloud- und On-Premise-KI schneiden auf jeder Achse, die im Gesundheitswesen zählt, unterschiedlich ab. Der sinnvolle Vergleich fragt deshalb nicht, welches Modell „am sichersten“ ist, sondern welche Risiken jedes Modell verlagert und auf wen. Die folgende Tabelle fasst die Abwägungen zusammen, die uns bei der Konzeption von KI-Projekten im europäischen Gesundheitswesen am häufigsten begegnen. Hybrid ist mit aufgeführt, weil die meisten Teams dort landen.

Zwei Punkte der Tabelle verdienen besondere Betonung. Erstens ist Sicherheit keine Eigenschaft des Standorts: Ein gut betriebener Cloud-Tenant ist oft besser geschützt als ein unterbesetzter Serverraum im Krankenhaus, und die für On-Premise aufgeführten Risiken sind real. Zweitens ist die Hybrid-Zeile die übliche Antwort, weshalb die Architekturmuster weiter unten in diesem Leitfaden wichtiger sind als die Grundsatzentscheidung.

Wann ist Cloud-KI für Gesundheitsdaten akzeptabel?

Cloud-KI ist für Gesundheitsdaten oft akzeptabel, wenn die Rahmenbedingungen stimmen; entscheidend ist dabei weniger die Cloud selbst als das, was sie umgibt. Europäische Aufsichtsbehörden haben die Verarbeitung von Gesundheitsdaten in der Cloud nicht für rechtswidrig erklärt, sie erwarten aber, dass der Verantwortliche sie begründet. Deutschland ist 2024 weiter gegangen und hat die Cloud-Nutzung gesetzlich geregelt: § 393 SGB V erlaubt Leistungserbringern und gesetzlichen Krankenkassen die Verarbeitung von Gesundheitsdaten in der Cloud, sofern die Verarbeitung in der EU, im EWR oder in einem Land mit Angemessenheitsbeschluss erfolgt und der Anbieter über ein aktuelles C5-Testat des BSI (Bundesamt für Sicherheit in der Informationstechnik) verfügt. Die folgenden fünf Bedingungen sind nach unserer Erfahrung diejenigen, die ein Cloud-Deployment vertretbar machen. Je mehr davon erfüllt sind, desto stärker ist die Begründung, und ein Anwendungsfall, der keine davon erfüllt, gehört in den nächsten Abschnitt.

Keine patientenidentifizierenden Daten verlassen Ihre Umgebung

Cloud-KI lässt sich am leichtesten begründen, wenn die gesendeten Daten überhaupt keine personenbezogenen Daten sind: echt anonymisierte Datensätze, synthetische Testdaten, veröffentlichte Leitlinien oder Verwaltungstexte ohne Patientenbezug. Gehen Sie mit dem Wort „anonymisiert“ vorsichtig um. Pseudonymisierte Daten bleiben nach Art. 4 Nr. 5 DSGVO personenbezogene Daten, und klinische Freitextnotizen sind notorisch schwer zu anonymisieren, weil sich die Identität in Datumsangaben, seltenen Erkrankungen und familiären Details verbirgt.

Starke vertragliche Absicherung

Starke vertragliche Absicherung beginnt mit einem Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, muss bei KI aber auch das Modellspezifische abdecken: dass Ihre Eingaben und Ausgaben nicht für Training verwendet werden, wie lange Prompts und Completions gespeichert werden und ob das Abuse Monitoring Inhalte zur menschlichen Prüfung speichert. Viele KI-Dienste für Unternehmen bieten auf Anfrage keine oder nur eine kurze Speicherung an. Lassen Sie sich das schriftlich zusichern, und zwar für genau den Dienst, den Sie tatsächlich aufrufen.

EU-Hosting und Datenresidenz

EU-Hosting sollte bedeuten, dass sowohl die Speicherung als auch die Inferenz in einer EU-Region stattfinden, nicht nur die Ablage ruhender Daten. Prüfen Sie den Verarbeitungsstandort des Modell-Endpoints selbst, denn manche Dienste leiten Anfragen dorthin, wo gerade Kapazität frei ist. Hat ein Anbieter seinen Hauptsitz außerhalb der EU, fragen Sie, wie er mit behördlichen Zugriffsersuchen umgeht, denn EU-Hosting verringert dieses Risiko, beseitigt es aber nicht. Halten Sie die Antwort in Ihrem Transfer Impact Assessment fest.

Klare Bedingungen für Auftragsverarbeiter und Unterauftragsverarbeiter

Klare Bedingungen für Auftragsverarbeiter und Unterauftragsverarbeiter bedeuten, dass Sie jedes Unternehmen kennen, das mit den Daten in Berührung kommen kann, und Art. 28 Abs. 2 DSGVO gibt Ihnen das Recht, Änderungen zu widersprechen. KI-Dienste verketten häufig mehrere Anbieter: Ein Anwendungsanbieter ruft einen Modellanbieter auf, der wiederum bei einem Hyperscaler läuft. Fordern Sie die vollständige Liste der Unterauftragsverarbeiter an und klären Sie, wie Sie über Änderungen informiert werden und wo jede Partei ansässig ist. Kann ein Anbieter nicht benennen, wer die Inferenz betreibt, haben Sie Ihre Antwort.

Menschliche Prüfung und Logging

Menschliche Prüfung und Logging machen ein Cloud-Deployment auch im Nachhinein vertretbar. Binden Sie bei allem, was die Versorgung beeinflusst, eine klinische Fachkraft ein, und protokollieren Sie jede Anfrage, die betroffenen Datenkategorien, die Modellversion und die Ausgabe in einem Speicher, den Sie selbst kontrollieren, nicht nur in der Konsole des Anbieters. Der EU AI Act erwartet genau das für Hochrisiko-KI-Systeme nach Art. 12 und 14, und auch weit unterhalb dieser Schwelle ist es gute Praxis.

Wann ist ein On-Premise- oder Private-Cloud-Betrieb von KI vorzuziehen?

Ein On-Premise- oder Private-Cloud-Betrieb von KI ist vorzuziehen, wenn die Daten, die Organisation oder der Workflow eine externe Verarbeitung schwer begründbar machen und nicht bloß unbequem. Die Abwägung gehört offen auf den Tisch: Sie verzichten auf den einfachsten Zugang zu Frontier-Modellen und übernehmen Hardware und Betrieb. Open-Weight-Modelle haben den Abstand allerdings deutlich verringert. Ein Modell mit 7 bis 8 Milliarden Parametern läuft auf einer einzelnen Rechenzentrums-GPU, und ein Modell mit 70 Milliarden Parametern passt mit 4-Bit-Quantisierung auf einen einzelnen Beschleuniger mit 80 GB. Für viele klinische Extraktions-, Klassifikations- und Zusammenfassungsaufgaben reicht diese Leistungsfähigkeit aus. Fünf Situationen sprechen nach unserer Erfahrung am häufigsten für einen lokalen oder privaten Betrieb.

Hochsensible Patientendaten

Hochsensible Patientendaten, etwa psychiatrische Aufzeichnungen, Daten zur sexuellen Gesundheit, genetische Daten oder Daten Minderjähriger, haben bei einer Offenlegung schwerere Folgen, und Ihre DSFA wird das auch so festhalten. Genetische Daten bilden nach Art. 9 DSGVO eine eigene besondere Kategorie. Wird das Restrisiko nach allen Cloud-Schutzmaßnahmen weiterhin als hoch eingestuft, ist lokale Inferenz die direkteste Gegenmaßnahme und gegenüber Patientinnen, Patienten und Aufsichtsbehörden am leichtesten zu erklären.

Krankenhäuser mit strengen IT- und Sicherheitsvorgaben

Krankenhäuser mit strengen IT- und Sicherheitsvorgaben entscheiden die Frage oft schon vor jeder Architekturprüfung: Viele untersagen, dass klinische Daten das Netzwerk verlassen, oder verlangen für jeden neuen externen Auftragsverarbeiter eine monatelange Sicherheitsprüfung. Gegen diese Vorgaben anzukämpfen kostet mehr Zeit, als innerhalb ihrer Grenzen zu bauen, und ein On-Premise-System, das die Prüfung in wenigen Wochen besteht, schlägt meist ein Cloud-System, das ein Jahr lang in der Beschaffung feststeckt.

Workflows in der medizinischen Bildgebung

Workflows in der medizinischen Bildgebung sprechen aus praktischen Gründen ebenso sehr für lokale Inferenz wie aus rechtlichen. Eine einzelne CT-Untersuchung kann Hunderte Megabyte umfassen, ein Whole-Slide-Image aus der Pathologie mehr als ein Gigabyte, und die Daten liegen bereits im PACS des Krankenhauses. Sie für die Inferenz nach außen zu verlagern, bringt Latenz, Bandbreitenbedarf und eine weitere Kopie, die verwaltet werden muss. Auch DICOM-Header und eingebrannte Annotationen enthalten Identifikatoren, die leicht übersehen werden.

Interne klinische Wissenssysteme

Interne klinische Wissenssysteme, etwa Assistenten, die Fragen zu lokalen Protokollen, Arzneimittellisten und Patientenakten beantworten, benötigen Retrieval über Daten, die zugleich sensibel und berechtigungsgesteuert sind. Laufen Retrieval-Index und Modell innerhalb des Netzwerks, bleibt das Berechtigungsmodell einfach: Das System übernimmt die bestehenden Verzeichnisberechtigungen und muss Datensätze nie in einen externen Speicher replizieren, nur um sie durchsuchbar zu machen.

Daten, die die Umgebung nicht verlassen dürfen

Daten, die die Umgebung nicht verlassen dürfen, sind manchmal eine vertragliche Tatsache und keine Risikoabwägung. Forschungsdaten, die einem Ethikvotum unterliegen, Daten aus einer Krankenhauspartnerschaft oder Datensätze, die unter nationale Regeln zur ärztlichen Schweigepflicht fallen, können ausdrückliche Beschränkungen für externe Verarbeitung mit sich bringen. Steht die Antwort durch Vertrag oder Gesetz fest, bleibt als einzige Architekturfrage, wie sich innerhalb dieser Grenze nützliche KI umsetzen lässt.

Welche Architekturmuster machen KI im Gesundheitswesen zugleich nützlich und DSGVO-bewusst?

Die Architekturmuster, die KI im Gesundheitswesen zugleich nützlich und DSGVO-bewusst machen, folgen alle derselben Idee: Legen Sie fest, welche Daten jede Komponente tatsächlich braucht, und ziehen Sie die Grenze Ihrer Kontrolle genau dort. Art. 25 DSGVO nennt das Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, und dieses Prinzip lässt sich vom ersten Tag an weit leichter einbauen als nachrüsten, nachdem eine DSFA darauf hingewiesen hat. Art. 32 DSGVO nennt Pseudonymisierung und Verschlüsselung ausdrücklich als geeignete Sicherheitsmaßnahmen, und das erste der folgenden Muster baut direkt auf der Pseudonymisierung auf. Diese fünf Muster decken den Großteil dessen ab, was wir für Teams im Gesundheitswesen und in der Medizinsoftware bauen, und sie sind darauf ausgelegt, kombiniert statt gegeneinander ausgespielt zu werden.

De-Identifizierung vor der Cloud-Verarbeitung

De-Identifizierung vor der Cloud-Verarbeitung entfernt oder ersetzt direkte Identifikatoren innerhalb Ihrer Umgebung, sendet nur den reduzierten Text an ein Cloud-Modell und fügt die Identifikatoren auf dem Rückweg lokal wieder ein. Namen, Datumsangaben, Adressen und Aktennummern werden zu konsistenten Platzhaltern, sodass das Modell über ein ganzes Dokument hinweg weiterhin über „Patient A“ schlussfolgern kann. Behandeln Sie den De-Identifizierer als sicherheitskritisch und messen Sie seinen Recall an Ihren eigenen Dokumenten, denn ein übersehener Name ist eine Offenlegung.

Retrieval-augmented generation über kontrollierte Dokumentenspeicher

Retrieval-augmented generation (RAG) hält klinisches Wissen in einem Dokumentenspeicher, den Sie kontrollieren, und übergibt dem Modell zum Zeitpunkt der Anfrage nur die wenigen relevanten Passagen, statt mit den Daten zu trainieren. Im Gesundheitswesen hat das drei Vorteile: Nichts Sensibles wird in die Modellgewichte eingebacken, die Zugriffskontrolle greift beim Retrieval, und jede Antwort kann die verwendeten Quellpassagen zitieren, was die Ausgaben für klinisches Personal und Auditoren gleichermaßen nachvollziehbar macht.

Lokale Inferenz für sensible Workflows

Lokale Inferenz für sensible Workflows betreibt ein Open-Weight-Modell auf Ihrer eigenen Hardware oder in Ihrem privaten Tenant für die Schritte, die identifizierbare Daten berühren: Extraktion aus Überweisungsschreiben, Kodierunterstützung, Triage-Zusammenfassungen. Unsere Fallstudie aus dem Gesundheitswesen ist ein Beispiel dafür, eine vollständig On-Premise betriebene Document-Intelligence-Pipeline, die strukturierte Daten aus medizinischen Dokumenten extrahiert, sie an die richtige Abteilung weiterleitet und sich in das bestehende Krankenhausinformationssystem integriert.

Hybride Architekturen

Hybride Architekturen leiten jede Aufgabe an den am wenigsten exponierten Ort, der sie gut erledigen kann. Eine typische Aufteilung: Identifizierbare Dokumente werden lokal verarbeitet, de-identifizierter Text geht für komplexes Reasoning an ein stärkeres Cloud-Modell, und nicht patientenbezogene Inhalte wie Leitlinien und interne Richtlinien nutzen Cloud-Dienste ohne Einschränkung. Die Routing-Regel muss explizit, getestet und protokolliert sein, denn genau an der Grenze zwischen beiden Seiten scheitern hybride Systeme.

Audit-Logs und rollenbasierter Zugriff

Audit-Logs und rollenbasierter Zugriff halten das gesamte Design zusammen. Jede Anfrage sollte Nutzer, Rolle, betroffene Datenkategorien, abgerufene Dokumente, Modell und Version sowie die Ausgabe erfassen, und zwar in einem Append-only-Speicher mit eigener Aufbewahrungsrichtlinie. Rollen sollten aus dem Identitätssystem der Organisation übernommen und nicht neu erfunden werden. Wie lange was aufzubewahren ist, erläutert unser Leitfaden zur Dokumentenaufbewahrung bei KI-Systemen nach DSGVO und EU AI Act.

Ändert ein On-Premise-Betrieb Ihre Pflichten nach dem EU AI Act?

Ein On-Premise-Betrieb ändert Ihre Pflichten nach dem EU AI Act nicht, weil der AI Act KI-Systeme nach ihrer Zweckbestimmung einstuft und nicht danach, wo sie laufen. Ein Tool zur Diagnoseunterstützung, das nach der MDR als Medizinprodukt der Klasse IIa oder höher gilt, ist ein Hochrisiko-KI-System, ob es nun im Keller eines Krankenhauses oder in einer Hyperscaler-Region läuft. Nach den Änderungen durch den Digital Omnibus gelten die Pflichten für KI in regulierten Produkten wie Medizinprodukten ab dem 2. August 2028, die Pflichten für Anwendungsfälle nach Anhang III, etwa die Triage von Notfallpatienten, ab dem 2. Dezember 2027. Was das Betriebsmodell tatsächlich verändert, ist, wie leicht Sie die Anforderungen erfüllen können: Logging, menschliche Aufsicht und Data Governance lassen sich einfacher nachweisen, wenn Sie den gesamten Stack kontrollieren. Wo DSGVO und AI Act in unterschiedliche Richtungen ziehen, etwa bei der Datenminimierung gegenüber der Forderung des AI Act nach repräsentativen Daten, beleuchtet unser Vergleich von DSGVO und EU AI Act das Spannungsfeld, und der Beitrag worauf sich KI-Teams im Gesundheitswesen vorbereiten müssen behandelt die Pflichten. Unsere Arbeit zur EU AI Act Compliance beginnt mit der Einstufung.

Wie sollten Sie zwischen Cloud- und On-Premise-KI im Gesundheitswesen entscheiden?

Die Entscheidung zwischen Cloud- und On-Premise-KI im Gesundheitswesen gelingt am besten als strukturierte Bewertung eines konkreten Anwendungsfalls, nicht als Grundsatzdebatte über die Cloud im Allgemeinen. Dieselbe Organisation kann Triage-Zusammenfassungen mit gutem Grund lokal betreiben und einen Leitlinien-Assistenten in der Cloud. Ein AI Readiness Audit beantwortet die Frage in einer festen Reihenfolge:

1. Den Datenfluss abbilden. Klären Sie, welche Datenkategorien der Anwendungsfall braucht, wo sie heute liegen und wohin sie überall gelangen würden: in Prompts, Retrieval-Indizes, Logs und Evaluationsdatensätze.
2. Minimieren, bevor Sie wählen. Entfernen Sie jedes Feld, das die Aufgabe nicht braucht, und testen Sie, ob de-identifizierte Eingaben noch akzeptable Ergebnisse liefern. Allein dieser Schritt verschiebt einen Anwendungsfall oft von On-Premise in die Cloud.
3. Die harten Rahmenbedingungen prüfen. Maßgeblich sind IT-Richtlinien des Krankenhauses, Verträge, Ethikvoten und nationale Vorschriften, die die Antwort unabhängig von Präferenzen festlegen.
4. Kandidatenmodelle mit Ihren eigenen Daten vergleichen. Benchmarken Sie ein Open-Weight-Modell gegen ein Cloud-Modell auf einer repräsentativen Stichprobe und nutzen Sie dabei die Methodik aus unserer Checkliste zur Validierung medizinischer KI. Erreicht das lokale Modell den Schwellenwert, verliert das Argument für den Datenversand deutlich an Gewicht.
5. Die Betriebskapazität bewerten. Benennen Sie, wer ein lokales System im zweiten Jahr patcht, überwacht und aktualisiert. Ein On-Premise-Deployment ohne klare Zuständigkeit ist ein Sicherheitsrisiko und keine Schutzmaßnahme.
6. Die Entscheidung dokumentieren. Halten Sie die Begründung in der DSFA und in der Architekturdokumentation fest, damit sich die Wahl verteidigen und neu bewerten lässt, wenn sich Modelle oder Regeln ändern.

Das Ergebnis ist ein empfohlenes Betriebsmodell je Anwendungsfall, mit benannten Gründen und Restrisiken, bereit zur Prüfung durch Datenschutzbeauftragte und Sicherheitsteam. Lautet die Antwort Pilotprojekt, erläutert der Beitrag zur Konzeption eines Proof of Value in 30 bis 90 Tagen, wie Sie ihn gegen einen Schwellenwert testen. Unser Service KI-Integration baut die gewählte Architektur anschließend in Ihre bestehenden Systeme ein, und unsere KI-Praxis für das Gesundheitswesen beschreibt die weitere Arbeit mit Teams aus Medizin und Digital Health.

Häufig gestellte Fragen

Dürfen Sie Cloud-KI-Dienste unter der DSGVO mit Patientendaten nutzen?

Ja, die Nutzung von Cloud-KI mit Patientendaten kann rechtmäßig sein, aber nicht automatisch. Sie benötigen eine Bedingung nach Art. 9 DSGVO für die Verarbeitung von Gesundheitsdaten, einen Auftragsverarbeitungsvertrag, der Training und Aufbewahrung regelt, einen Verarbeitungsort in der EU oder einen anderweitig rechtmäßigen Standort und in der Regel eine DSFA. Chat-Tools für Endverbraucher erfüllen diese Bedingungen selten, entsprechend konfigurierte Enterprise-Dienste können es. Lassen Sie die konkrete Konfiguration von Ihrer oder Ihrem Datenschutzbeauftragten bestätigen, bevor Patientendaten gesendet werden.

Ist On-Premise-KI automatisch DSGVO-konform?

Nein. Ein On-Premise-Betrieb beseitigt Fragen zur Übermittlung an Dritte, doch jede andere Pflicht aus der DSGVO gilt weiterhin: Rechtsgrundlage, Datenminimierung, Zugriffskontrolle, Sicherheit nach Art. 32 DSGVO, Speicherbegrenzung und die Rechte der Patientinnen und Patienten. Ein schlecht gesicherter lokaler Server kann riskanter sein als ein gut betriebener Cloud-Tenant. Der Standort ist eine Kontrollmaßnahme unter vielen, kein Compliance-Status.

Macht Pseudonymisierung Patientendaten sicher für den Versand in die Cloud?

Pseudonymisierung senkt das Risiko, nimmt die Daten aber nicht aus dem Anwendungsbereich der DSGVO heraus. Nach Art. 4 Nr. 5 DSGVO bleiben pseudonymisierte Daten personenbezogen, solange die Mittel zur Re-Identifizierung existieren, selbst wenn nur Sie diese besitzen. Pseudonymisierung ist dennoch eine wertvolle Schutzmaßnahme, die die DSGVO ausdrücklich fördert, und sie verkleinert, was ein Anbieter offenlegen könnte. Behandeln Sie sie als Risikominderung innerhalb eines rechtmäßigen Cloud-Setups, nicht als Weg daran vorbei.

Können lokal betriebene Open-Weight-Modelle bei klinischen Aufgaben mit Cloud-KI mithalten?

Bei vielen eng umrissenen Aufgaben können lokal betriebene Open-Weight-Modelle mithalten. Extraktion, Klassifikation, Kodierunterstützung und Zusammenfassung klinischer Dokumente bewältigen sie oft gut, besonders in Kombination mit Retrieval. Bei komplexem, offenem Reasoning liegen Frontier-Modelle aus der Cloud weiterhin vorn. Verlässlich klären lässt sich das nur, indem Sie vor der Entscheidung beide Varianten auf einer repräsentativen Stichprobe Ihrer eigenen Dokumente benchmarken.