Private KI-Bereitstellung für regulierte Branchen

Mit KI verfasst, vom Xinity-Team geprüft.

Regulierte Organisationen befinden sich in einer Zwickmühle. KI ist mittlerweile so nützlich, dass Teams sie nutzen werden, unabhängig davon, ob die IT-Abteilung sie bereitstellt oder nicht. Und die Standardmethode zur Nutzung – das Senden von Prompts an eine öffentliche API – bedeutet, dass sensible Daten auf der Infrastruktur eines Dritten zu dessen Bedingungen verarbeitet werden. Für eine Bank, ein Krankenhaus oder eine Anwaltskanzlei ist das oft der Punkt, an dem das Gespräch mit der Compliance-Abteilung endet.

Dieser Leitfaden legt dar, was eine private KI-Bereitstellung bedeutet, was sie über das Modell selbst hinaus erfordert und wie Organisationen im Banken- und Gesundheitswesen, in der Rechtsberatung und im öffentlichen Sektor ihre Optionen bewerten können.

Was „private KI-Bereitstellung“ bedeutet

Der Begriff umfasst drei verschiedene Architekturen, und die Unterschiede sind entscheidend, wenn die Compliance-Abteilung fragt, wohin die Daten fließen.

Öffentliche API mit einem Auftragsverarbeitungsvertrag (AVV). Die Daten gehen an einen externen Modellanbieter, der sich vertraglich verpflichtet, wie mit ihnen umgegangen wird. Die Compliance stützt sich auf den Vertrag, nicht auf die Architektur. Die DSGVO erlaubt dies über das Konstrukt des Auftragsverarbeiters, aber die Daten verlassen dennoch die Organisation. Für Informationen, die dem Berufsgeheimnis unterliegen – wie das Bankgeheimnis, die ärztliche Schweigepflicht oder das Anwaltsgeheimnis –, reicht ein Auftragsverarbeitungsvertrag unter Umständen nicht aus.

Dedizierte Cloud- oder VPC-Bereitstellung. Das Modell läuft in einer Umgebung, die von anderen Mandanten isoliert ist, aber der Anbieter besitzt und betreibt weiterhin die Hardware, den Hypervisor und die Software-Lieferkette. Die Daten können in einer ausgewählten Region verbleiben, aber die Kontrolle über den Stack liegt nicht bei Ihnen.

On-Premise- oder private Infrastruktur. Das Modell läuft auf Hardware, die die Organisation besitzt oder direkt kontrolliert, innerhalb ihres eigenen Netzwerks. Während der Inferenz gelangen keine Daten über ein externes Netzwerk. Dies ist die Architektur, die strengen Anforderungen an Datenlokalisierung, Air-Gaps und die Lieferkette gerecht wird.

Organisationen mit den strengsten Anforderungen landen meist bei der dritten Option. Die Frage ist dann, was die Plattform um das Modell herum bieten muss.

Was regulierte Organisationen über das Modell hinaus benötigen

Das Ausführen eines Open-Weight-Modells auf dem eigenen Server ist ein Anfang, keine Lösung. Das Modell selbst übernimmt keine Zugriffskontrolle, führt kein Protokoll darüber, wer was gefragt hat, und setzt keine Richtlinien durch. Das muss die Plattform um das Modell herum tun.

Zugriffskontrolle und Identität

Jede Anfrage sollte einer Person, einem Service-Konto oder einer Abteilung zugeordnet werden können. Wenn ein Auditor fragt, wer Zugriff auf das Modell hatte, das eine Kundenakte verarbeitet hat, ist „jeder mit der Endpoint-URL“ keine Antwort. Eine rollenbasierte Zugriffskontrolle auf API-Ebene, die an den bereits von der Organisation genutzten Identity-Provider angebunden ist, ist die Mindestvoraussetzung für den Produktivbetrieb.

Richtliniendurchsetzung

Verschiedene Teams benötigen unterschiedliche Regeln. Ein Rechtsteam, das mit vertraulichen Transaktionsdokumenten arbeitet, benötigt andere Einschränkungen als ein Serviceteam, das öffentliche Produktinformationen zusammenfasst. Diese Regeln gehören in die Plattformschicht, wo sie für jede Anwendung auf dieselbe Weise angewendet werden, anstatt von jedem Entwicklungsteam neu erstellt zu werden.

Audit Trail (Prüfpfad)

Jede Anfrage sollte eine Aufzeichnung darüber hinterlassen, wer sie gestellt hat, welches Modell und welche Konfiguration sie beantwortet hat und wann. Diese Aufzeichnung ist die Art und Weise, wie die Organisation die Einhaltung von Vorschriften im Nachhinein gegenüber einem internen Prüfungsausschuss, einer Datenschutzbehörde oder einem Gericht nachweist. Protokollierungen, die nur im Anwendungscode stattfinden, können von jeder Anwendung, die sie weglässt, umgangen werden, weshalb sie in die Bereitstellungsschicht (Serving Layer) gehören.

Validierte, stabile Modelle

Regulierte Organisationen können keine Modelle betreiben, deren Verhalten sich ohne Vorankündigung ändert. Das Testen einer bestimmten Modellversion anhand der eigenen Anwendungsfälle der Organisation, bevor sie in die Produktion geht, und das Beibehalten dieser Version, bis die nächste Version dieselben Tests bestanden hat, ist ein Governance-Schritt, der vom ersten Tag an in den Bereitstellungs-Workflow gehört.

Sektorspezifische Überlegungen

Banken und Finanzdienstleistungen

DORA macht das IKT-Drittparteienrisiko zu einer aufsichtsrechtlichen Angelegenheit, und Aufsichtsbehörden wie die FMA in Österreich und die BaFin in Deutschland erwarten, dass Auslagerungsvereinbarungen dokumentiert, kontrolliert und ausstiegsbereit sind. Das Bankgeheimnis, in Österreich geregelt unter § 38 BWG, schützt Kundeninformationen zusätzlich zur DSGVO. Die Infrastruktur, auf der Modelle ausgeführt werden, sollte wie jedes andere kritische IT-System behandelt werden: änderungsgesteuert, mit Zugriffsprotokollierung und in der Lage, auf Anfrage Nachweise zu erbringen.

Gesundheitswesen

Gesundheitsdaten fallen unter die besondere Kategorie gemäß Artikel 9 DSGVO, und darüber hinaus gilt die ärztliche Schweigepflicht. IT-Teams in Krankenhäusern, die KI für Dokumentation, Verwaltung oder klinische Unterstützung einsetzen, müssen sicherstellen, dass die Patientendaten während der Verarbeitung innerhalb der Infrastruktur der Einrichtung verbleiben. Die Überprüfbarkeit ist auch für die klinische Governance von Bedeutung: Das Krankenhaus muss nachweisen können, welche Informationen der KI vorlagen, als sie ein bestimmtes Ergebnis lieferte.

Rechtsberatung

Anwaltskanzleien gehen mit dem Anwaltsgeheimnis unterliegenden Mitteilungen und vertraulichen Geschäftsinformationen um, und die Pflicht zur Verschwiegenheit erstreckt sich auch auf die Systeme, mit denen diese verarbeitet werden. Das Senden von Mandantenunterlagen an eine öffentliche API, selbst im Rahmen einer Auftragsverarbeitung, bindet einen Dritten in die Kette ein. Die Verschwiegenheitspflichten und Mandatsbedingungen vieler Kanzleien machen dies schwer rechtfertigbar.

Öffentlicher Sektor

Öffentliche Stellen in Österreich und in der gesamten EU arbeiten sowohl unter dem nationalen Datenschutzgesetz als auch unter der DSGVO und oft unter ihren eigenen Beschaffungs- und Datenlokalisierungsregeln. Der Betrieb von KI auf einer Infrastruktur, die von einem Nicht-EU-Anbieter kontrolliert wird, wirft Fragen auf, die über den Datenschutz hinausgehen: die Abhängigkeit von einer ausländischen Lieferkette und die Fähigkeit, öffentliche Dienstleistungen unabhängig aufrechterhalten zu können.

Bewertung einer Plattform für die private KI-Bereitstellung

Fünf Fragen helfen dabei, die Versprechen der Anbieter zu durchleuchten:

1. Läuft die Inferenz vollständig in meinem Netzwerk ohne ausgehende Aufrufe? Eine Plattform, die während der Inferenz einen Lizenzierungsserver, einen Telemetrie-Endpunkt oder ein externes Modell-Repository kontaktiert, ist nicht vollständig privat.

2. Wird die Zugriffskontrolle auf API-Ebene erzwungen und ist sie an mein Verzeichnis angebunden? Die Integration mit LDAP, SAML oder OIDC ist hierbei der praktische Test.

3. Gibt es ein Protokoll für jede einzelne Anfrage in der Plattformschicht? Es sollte Identität, Modell, Konfiguration und Zeitstempel aufzeichnen, abfragbar sein und vor nachträglichen Änderungen geschützt sein.

4. Kann ich eine Modellversion fixieren und neue Versionen nach meinem eigenen Zeitplan einführen? Governance in der Produktion bedeutet, Versionen dann einzufrieren, zu testen und freizugeben, wenn die Organisation es entscheidet, nicht wenn der Anbieter liefert.

5. Wie wird die Plattform On-Premise unterstützt? Wenn der Support Fernzugriff auf die Produktionsumgebung benötigt, prüfen Sie dies vor der Vertragsunterzeichnung anhand Ihrer Netzsegmentierungsrichtlinie.

Das Problem der Schatten-KI

Organisationen, die keine konforme KI-Option anbieten, verhindern die Nutzung von KI nicht. Sie drängen sie in private Konten, Browser-Erweiterungen und nicht genehmigte SaaS-Tools ab, wo die IT-Abteilung sie nicht sehen kann und keine Richtlinien greifen. Eine kontrollierte private Option geht dieses Problem direkt an: Teams erhalten die Tools, die sie wollen, unter Kontrollen, die die Organisation verteidigen kann.

Starten einer Bereitstellung

Für die meisten Organisationen ist der praktischste erste Schritt ein abgegrenztes Pilotprojekt: eine definierte Anzahl an Anwendungsfällen, eine kleine Benutzergruppe und ein kurzes Evaluierungsfenster. Es testet die Architektur anhand der eigenen IT- und Compliance-Anforderungen der Organisation, bevor sich jemand zu einem vollständigen Rollout verpflichtet.

Vor dem Start des Pilotprojekts:

• Definieren Sie die betroffenen Anwendungsfälle und klassifizieren Sie die Daten, mit denen sie in Berührung kommen

• Bestätigen Sie die Umgebung (On-Premise-Server, Private Cloud oder Hybrid) und prüfen Sie, ob die Hardware die Anforderungen des Modells erfüllt

• Verknüpfen Sie die Zugriffskontrolle mit dem bestehenden Verzeichnis

• Stimmen Sie das Format und den Speicherort des Audit-Logs mit dem Compliance- oder Datenschutzteam ab

• Legen Sie den Prozess für die Validierung und Freigabe neuer Modellversionen fest

Ein Pilotprojekt, das diese Schritte überspringt, führt oft zu einer Bereitstellung, die technisch zwar funktioniert, aber von der Compliance oder der Rechtsabteilung nicht freigegeben werden kann und daher nie die Produktionsreife erreicht.

Zusammenfassung

Die private KI-Bereitstellung ist in erster Linie eine Frage der Architektur und erst danach eine Frage des Anbieters. Die Daten müssen während der Inferenz unter der Kontrolle der Organisation bleiben, jede Anfrage muss zuordenbar und protokolliert sein, und das Modellverhalten muss den Richtlinien entsprechen, die die Organisation durchsetzen kann.

Wenn Sie zuerst die Architektur richtig aufsetzen, schrumpft die engere Auswahl schnell auf Plattformen zusammen, die tatsächlich On-Premise laufen, den Zugriff kontrollieren und einen Prüfpfad (Audit Trail) lückenlos dokumentieren.

Xinity ist die Schicht um das Modell. Es stellt Open-Weight-Modelle auf einer von Ihnen kontrollierten Infrastruktur bereit, verwaltet und prüft sie – mit integriertem SSO/LDAP, rollenbasierter Zugriffskontrolle und Audit-Protokollierung. Wenn Ihre Organisation eine private KI-Bereitstellung prüft, ist das 30-tägige Pilotprogramm der strukturierte Weg für den Einstieg.