LLM-Bereitstellung in regulierten Branchen: HIPAA-, SOC2- und GDPR-Playbook für 2026

Die technische Herausforderung bei der Bereitstellung eines großen Sprachmodells in einem regulierten Unternehmen ist nicht primär ein Problem des maschinellen Lernens. Die Modelle existieren, sie funktionieren und sind leistungsfähig genug für ernsthafte klinische, finanzielle und versicherungstechnische Anwendungsfälle. Die Herausforderung liegt in der Architektur rund um das Modell: Wer kontrolliert die Daten, wohin sie fließen, was protokolliert wird, wer den Anbieter genehmigt hat und wie das Compliance-Team all dies einer Aufsichtsbehörde nachweisen kann.

Medtronic, mit 90.000 Mitarbeitern und FDA-regulierten Geräteportfolios, setzt KI in der Produktion ein. Innovaccer verarbeitet geschützte Gesundheitsinformationen in großem Umfang innerhalb einer gesteuerten klinischen Intelligenzplattform. Aviva, die unter der britischen GDPR operiert, nutzt KI in allen Versicherungsworkflows. Siemens Healthineers hat KI gleichzeitig in mehreren regulatorischen Gerichtsbarkeiten implementiert. Dies sind keine Machbarkeitsstudien. Es handelt sich um unternehmensweite Produktionsbereitstellungen, die die rechtliche, Compliance- und IT-Sicherheitsprüfung bestanden haben.

Die Architektur, die jede dieser Bereitstellungen ermöglichte, ist Gegenstand dieses Playbooks. Es behandelt die spezifischen regulatorischen Anforderungen für das Gesundheitswesen, Finanzdienstleistungen und Versicherungen, die technischen Entscheidungen, die diese Anforderungen bedingen, und wie eine gesteuerte, VPC-isolierte Bereitstellung in der Praxis für Teams aussieht, die sich auf denselben Genehmigungsprozess vorbereiten.

Was die KI-Bereitstellung in regulierten Branchen unterscheidet

Die Unterschiede zwischen regulierter und unregulierter KI-Bereitstellung sind nicht primär technischer Natur. Die zugrunde liegenden Modelle sind dieselben. Der Unterschied liegt in der rechtlichen Verpflichtung, der Verantwortlichkeitsstruktur und dem Prüfaufwand, und diese Faktoren verändern die Architektur-Entscheidungen von Grund auf.

• Regeln zur Datenverarbeitung werden extern festgelegt. In regulierten Umgebungen werden zulässige Datennutzungen durch Gesetze definiert, nicht durch technische Einschätzung. Ein KI-System, das Patientenakten an eine externe API sendet, kann technisch elegant sein und gleichzeitig einen HIPAA-Verstoß darstellen. Die technische Raffinesse der Implementierung ist für den rechtlichen Standard irrelevant. Entscheidend ist, wohin die Daten gelangten und ob dies autorisiert war.

• KI-Systeme fallen nun in den Geltungsbereich der behördlichen Prüfung. Aufsichtsbehörden im Gesundheitswesen, bei Finanzdienstleistungen und Versicherungen erwarten zunehmend von Organisationen, zu dokumentieren, auf welche Daten ihre KI-Systeme zugegriffen haben, welche Entscheidungen diese Systeme beeinflussten, wer die Bereitstellung autorisiert hat und wie der menschliche Überwachungsprozess aussah. Die HIPAA-Sicherheitsregel verlangt angemessene Schutzmaßnahmen, einschließlich Verschlüsselung im Ruhezustand und während der Übertragung, basierend auf einer Risikobewertung. Die Beweislast für die Einhaltung liegt jederzeit bei der Organisation.

• Ihr KI-Anbieter fällt in Ihren Compliance-Bereich. Jeder Anbieter, der geschützte Gesundheitsinformationen in Ihrem Namen erstellt, empfängt, verwaltet oder übermittelt, ist ein Business Associate gemäß HIPAA und benötigt rechtlich eine unterzeichnete BAA, bevor PHI deren Infrastruktur berührt. Die meisten standardmäßigen öffentlichen LLM-API-Angebote sind standardmäßig nicht BAA-abgedeckt und erfordern Unternehmensvereinbarungen oder alternative Bereitstellungsmodelle. AWS Bedrock und Azure OpenAI Service bieten BAA-berechtigte Optionen mit spezifischen Konfigurationsanforderungen an, aber die Berechtigung ist nicht gleichbedeutend mit Compliance.

• Datenresidenz kann SaaS-Optionen vollständig ausschließen. Ein europäisches Versicherungsunternehmen, das durch die GDPR abgedeckte personenbezogene Daten verarbeitet, kann diese Daten rechtlich nicht über eine US-basierte Infrastruktur leiten, ohne entweder eine Vereinbarung über Standardvertragsklauseln oder einen anderen genehmigten GDPR-Übertragungsmechanismus zu haben. Viele SaaS-KI-Gateway-Produkte sind in den USA ansässig, was bedeutet, dass die Dokumentation für den Datentransfer von der EU in die USA abgeschlossen sein muss, bevor eine technische Bereitstellung beginnt. Für einige Organisationen und bestimmte Datentypen schließt dies die SaaS-Option vollständig aus.

• Audit-Trails sind nicht optional, und strukturierte sind besser. Jeder Zugriff auf regulierte Daten, einschließlich KI-gestützter Zugriffe, muss einen Audit-Eintrag erzeugen. Für HIPAA muss dieser Eintrag Zeitstempel, Identität des Zugreifenden, die durchgeführte Aktion und einen Verweis auf die zugegriffenen PHI enthalten. KI-Systeme, die diese Einträge automatisch im strukturierten JSON-Format generieren, sind einsetzbar. Systeme, die eine manuelle Log-Korrelation im Nachhinein erfordern, schaffen Compliance-Lücken, die von Aufsichtsbehörden nicht als gleichwertig akzeptiert werden.

Gesundheitswesen: HIPAA-Anforderungen für LLM-Bereitstellungen

HIPAA deckt jedes System ab, das geschützte Gesundheitsinformationen verarbeitet. Eine LLM-Bereitstellung fällt in den Geltungsbereich, wenn das Modell PHI in Prompts empfangen kann, wenn PHI im Kontext der Retrieval-Augmented Generation, der an das Modell übergeben wird, erscheint oder wenn Modellausgaben Entscheidungen über einzelne Patienten beeinflussen. Die Zusammenfassung klinischer Notizen, die Analyse von Patientenakten, diagnostische Hilfsmittel und die Unterstützung bei der Vorabgenehmigung fallen alle in diesen Bereich.

Drei HIPAA-Regeln prägen die Architektur der LLM-Bereitstellung direkt. Die Privacy Rule regelt, wofür PHI verwendet werden darf und wer darauf zugreifen kann, einschließlich des „Minimum Necessary“-Standards, der die Datenexposition auf das für die spezifische Aufgabe erforderliche Maß beschränkt. Die Security Rule verlangt administrative, physische und technische Schutzmaßnahmen für elektronische PHI, einschließlich Zugriffskontrollen, Audit-Protokollierung und Übertragungssicherheit. Die Breach Notification Rule legt fest, was passiert, wenn Kontrollen versagen. Alle drei haben technische Implementierungsanforderungen, die sich in der Gestaltung der KI-Infrastruktur zeigen, nicht nur in den Richtliniendokumenten.

PHI-Isolation: Warum die meisten Cloud-LLM-APIs für klinische Anwendungsfälle ungeeignet sind

• Standard-API-Angebote für Endverbraucher von OpenAI, Anthropic und Google sind im Allgemeinen nicht für HIPAA-regulierte Arbeitslasten konzipiert und bieten typischerweise keine Business Associate Agreements (BAAs) für ihre öffentlichen Endpunkte an. Wenn PHI an einen Drittanbieterdienst übermittelt wird, der als Geschäftspartner agiert, ohne dass ein BAA vorliegt, stellt dies einen Verstoß gegen die HIPAA-Compliance dar. Dies ist eine der häufigsten Fehlerquellen bei frühen KI-Implementierungen in Unternehmen, die schneller voranschreiten als ihre Anbieter-Governance-Prozesse.

• AWS und Microsoft bieten beide HIPAA Business Associate Agreements an, die bestimmte berechtigte Dienste innerhalb ihrer Plattformen abdecken. AWS schließt berechtigte Dienste in sein Standard-BAA ein, während Microsoft den Schutz über sein Online Services Data Protection Addendum bietet. Die Compliance hängt jedoch davon ab, dass nur die relevanten Dienste genutzt und korrekt konfiguriert werden. Verschlüsselung im Ruhezustand und während der Übertragung, Audit-Protokollierung und IAM-Kontrollen nach dem Prinzip der geringsten Rechte sind erforderlich. Die Unterzeichnung eines BAA ist eine Voraussetzung, nicht der Endzustand der Compliance.

• Für klinische Anwendungsfälle, die PHI betreffen, bietet die VPC-isolierte oder selbst gehostete Modellbereitstellung die sauberste architektonische Abgrenzung. Wenn Modelle innerhalb des eigenen Cloud-Kontos der Organisation ausgeführt werden, bleibt PHI innerhalb des Unternehmensperimeters und wird externen Modell-Anbietern nicht zugänglich gemacht. Dies macht ein separates BAA mit einem Drittanbieter für Modell-APIs überflüssig, obwohl ein BAA mit dem zugrunde liegenden Cloud-Anbieter (z. B. AWS oder Azure) als Teil der gesamten Compliance-Strategie weiterhin erforderlich ist.

• Für Organisationen, die externe Modell-APIs in begrenzten Szenarien nutzen müssen, kann Datenmaskierung oder De-Identifizierung ein praktikables Muster sein. Sensible Felder werden entfernt oder tokenisiert, bevor die Anfrage gesendet wird, und erst nach Erhalt der Antwort innerhalb der kontrollierten Umgebung rekonstruiert. Damit dies konform ist, muss die Transformation sicherstellen, dass keine identifizierbaren PHI dem externen Dienst zugänglich gemacht werden, und der Prozess muss dokumentiert, validiert und für Auditoren als Teil der Compliance-Kontrollen der Organisation nachweisbar sein.

HIPAA-Anforderungen an Audit-Protokolle für KI-Systeme

• Die HIPAA-Sicherheitsregel verlangt von abgedeckten Einheiten und Geschäftspartnern die Implementierung von Audit-Kontrollen, die Aktivitäten in Systemen, die elektronische PHI verarbeiten, aufzeichnen und überprüfen. In der Praxis bedeutet dies, dass Systeme Protokolle generieren müssen, die Zugriffsereignisse so erfassen, dass sie Untersuchungen und Rechenschaftspflicht unterstützen. Obwohl die Verordnung keine exakten Felder vorschreibt, umfassen branchenübliche Implementierungen Zeitstempel, Benutzer- oder Systemidentität, die durchgeführte Aktion und die aufgerufenen Daten oder das System. Für LLM-Implementierungen erstreckt sich dies auf die Erfassung, welcher Benutzer oder Agent eine Anfrage initiiert hat, welches Modell sie verarbeitet hat und ausreichenden Kontext, um das Geschehene zu rekonstruieren. Aggregierte Nutzungsmetriken allein reichen nicht aus, um Audits oder Vorfalluntersuchungen zu unterstützen.

• HIPAA verlangt, dass Dokumentationen zu Sicherheitskontrollen, einschließlich Audit-Aufzeichnungen, wo zutreffend, für mindestens sechs Jahre aufbewahrt werden. Darüber hinaus müssen Systeme Integritätskontrollen implementieren, um Protokolle vor unbefugter Änderung oder Löschung zu schützen. In der Praxis wird dies oft durch manipulationssichere Speichermechanismen wie Write-Once-Read-Many (WORM)-Konfigurationen, strenge Zugriffskontrollen und zentralisierte Protokollverwaltungssysteme erreicht, die eine Änderung durch operative Teams verhindern.

• HIPAA verlangt Mechanismen zur eindeutigen Identifizierung und Authentifizierung von Benutzern, die auf Systeme mit ePHI zugreifen. Folglich müssen Audit-Protokolle in der Lage sein, Zugriffsereignisse einer bestimmten Person oder Systemidentität zuzuordnen. Implementierungen, die sich ausschließlich auf gemeinsam genutzte Dienstkonten oder API-Schlüssel ohne Benutzerzuordnung verlassen, schaffen Lücken in der Rechenschaftspflicht und erschweren die Erfüllung von Audit- und Untersuchungsanforderungen. In modernen KI-Systemen erfordert dies typischerweise die Integration identitätsbasierter Zugriffskontrollen, damit über Agenten oder Gateways ausgeführte Aktionen dem ursprünglichen Benutzer zugeordnet werden können.

Anforderungen an die Zugriffskontrolle

• HIPAA verlangt, dass der Zugriff auf PHI durch technische und administrative Schutzmaßnahmen kontrolliert wird, einschließlich eindeutiger Benutzeridentifikation, Authentifizierung und rollenbasierter Zugriffskontrollen. Darüber hinaus setzt die Datenschutzregel den „Minimum Necessary“-Standard für die Nutzung und Offenlegung von PHI durch. In der Praxis bedeutet dies, dass der Zugriff über einen dokumentierten Prozess bereitgestellt und verwaltet werden muss, wobei die Berechtigungen an die Rolle des Benutzers angepasst sind. Für KI-Systeme hat dies zwei Implikationen. Erstens sollte der Zugriff über den Identitätsanbieter der Organisation an individuelle Identitäten gebunden sein, nicht an gemeinsam genutzte API-Schlüssel, die nicht bestimmten Benutzern zugeordnet werden können. Zweitens müssen rollenbasierte Kontrollen sicherstellen, dass Benutzer nur auf KI-Funktionen zugreifen können, die ihrer Funktion entsprechen, z. B. die Trennung von Abrechnungs-Workflows von klinischen Workflows mit unterschiedlicher PHI-Exposition.

• Der „Minimum Necessary“-Standard gilt für die Verwendung von PHI innerhalb eines Systems, nicht nur dafür, welcher Benutzer den Zugriff initiiert. In KI-Systemen erstreckt sich dies auf die Daten, die in Modell-Prompts und Kontext enthalten sind. Das Übergeben vollständiger Patientenakten, wenn nur eine Untermenge strukturierter Felder erforderlich ist, entspricht möglicherweise nicht dem „Minimum Necessary“-Prinzip. Obwohl HIPAA nicht explizit definiert, wie dies auf KI-Prompts anzuwenden ist, wird von Organisationen erwartet, die PHI-Exposition auf das für die Aufgabe erforderliche Maß zu beschränken. Die Durchsetzung auf der Infrastrukturebene, beispielsweise durch ein KI-Gateway, das kontextsensitive Datenrichtlinien basierend auf Benutzerrolle und Anwendungsfall anwendet, ist ein Ansatz, um eine konsistente Einhaltung sicherzustellen, anstatt sich auf eine Implementierung auf Anwendungsebene zu verlassen.

Finanzdienstleistungen: SOC2 und regulatorische Anforderungen für LLM-Implementierungen

Finanzdienstleistungsunternehmen, die LLMs einsetzen, stehen vor einem vielschichtigen regulatorischen Umfeld. SOC2 Typ II-Anforderungen gelten für die Technologieinfrastruktur. Die Leitlinien von OCC, Federal Reserve und FINRA zu KI und Modellrisiko gelten für Modelle, die bei Finanzentscheidungen verwendet werden. Und die Bestimmungen des EU-KI-Gesetzes für Hochrisiko-KI-Systeme, die für EU-Operationen ab August 2026 durchsetzbar sind, fügen eine weitere Ebene für internationale Organisationen hinzu. Diese Rahmenwerke überschneiden sich auf eine Weise, die spezifische Architekturanforderungen für KI-Gateway- und Modellbereitstellungsinfrastrukturen schafft.

SOC2 Typ II-Kontrollen für KI-Infrastruktur

• KI-Gateways und Modellbereitstellungsplattformen, die Finanzdaten verarbeiten, fallen in den Geltungsbereich von SOC2 Typ II-Bewertungen, wenn sie Daten oder Systeme berühren, die vom Audit abgedeckt sind. Die relevanten Trust Service Criteria sind CC6 (logische und physische Zugriffskontrollen), CC7 (Überwachung des Systembetriebs), CC8 (Änderungsmanagement) und CC9 (Risikominderung). Jedes Kriterium erfordert spezifische technische Kontrollen, die im oder neben dem KI-Gateway vorhanden sein müssen.

• Der häufigste SOC2-Befund bei KI-Gateway-Implementierungen ist eine unzureichende Zugriffskontrolle auf API-Ebene: gemeinsam genutzte Dienstkonten, die den Zugriff nicht einzelnen Personen zuordnen können, in Quellcode gespeicherte API-Schlüssel oder KI-Plattformen, die die von CC6 geforderten feingranularen Zugriffskontrollen nicht unterstützen. Die Wahl einer Plattform, die sich in den Identitätsanbieter des Unternehmens integriert und RBAC auf Modell- und Teamebene durchsetzt, eliminiert diese Befunde, bevor der Audit-Zeitraum beginnt.

• SOC2 Typ II erfordert einen kontinuierlichen Nachweis des Kontrollbetriebs über den Audit-Zeitraum, typischerweise sechs bis zwölf Monate. Das bedeutet, dass Audit-Protokolle kontinuierlich generiert und über den gesamten Zeitraum aufbewahrt werden müssen, nicht nur bei Bedarf, wenn Auditoren sie anfordern. KI-Gateway-Plattformen, die vom ersten Tag der Bereitstellung an strukturierte, kontinuierliche Protokolle erzeugen, sind wesentlich einfacher zu prüfen als Systeme, bei denen die Protokollierung nachträglich hinzugefügt wurde. Der Audit-Nachweis muss zeigen, dass die Kontrollen während des gesamten Zeitraums konsistent funktionierten, nicht nur zum Zeitpunkt des Audits.

Modellrisikomanagement (SR 11-7) für LLMs

• Die Leitlinie SR 11-7 von OCC und Federal Reserve zum Modellrisikomanagement gilt für KI- und LLM-Modelle, die bei Kreditentscheidungen, Risikobewertungen und anderen regulatorisch relevanten Prozessen eingesetzt werden. Die Leitlinie fordert drei Dinge für jedes relevante Modell: Dokumentation von Zweck, Trainingsdaten und Testmethodik; unabhängige Validierung anhand definierter Leistungsstandards; und kontinuierliche Überwachung mit Leistungsverfolgung und Drift-Erkennung.

• Für LLMs in Finanzdienstleistungen erstreckt sich die SR 11-7 Dokumentationspflicht auf die Infrastruktur, auf der das Modell läuft. Welches LLM von welchen Teams für welche Entscheidungen, zu welchen Kosten, mit welcher Latenz und welchem beobachteten Ausgabeverhalten verwendet wird, muss alles dokumentiert und für die behördliche Prüfung verfügbar sein. Ein KI-Gateway, das diese Daten automatisch im Rahmen seiner Standardprotokollierung erfasst, erstellt die Nachweise für die Modell-Dokumentation als Nebenprodukt des normalen Betriebs. Dies reduziert den sonst erheblichen manuellen Dokumentationsaufwand für jedes betroffene Modell.

Versicherung: Datenresidenz und DSGVO-Anforderungen

Versicherungsunternehmen, die in mehreren Rechtsräumen tätig sind, sehen sich Beschränkungen der Datenresidenz und des grenzüberschreitenden Datentransfers gegenüber, die KI-Architekturentscheidungen direkt einschränken. Die DSGVO, UK-DSGVO und die Datenschutzgesetze der US-Bundesstaaten enthalten alle Bestimmungen, die beeinflussen, wo und wie Kundendaten verarbeitet werden dürfen, einschließlich der Frage, ob sie zur Inferenz an eine KI-Modell-API gesendet werden dürfen.

• DSGVO-Grundlage für die Datenverarbeitung: KI-Systeme, die personenbezogene Daten verarbeiten, müssen eine dokumentierte Rechtsgrundlage gemäß Artikel 6 DSGVO aufweisen. Für die meisten KI-Anwendungsfälle im Versicherungsbereich ist die Grundlage entweder ein berechtigtes Interesse oder die Erfüllung eines Vertrags. Beide erfordern, dass die Verarbeitung dokumentiert, verhältnismäßig zum Zweck und in der Datenschutzerklärung der Organisation offengelegt wird. KI-Systeme, die personenbezogene Daten ohne dokumentierte Rechtsgrundlage verarbeiten, schaffen ein direktes regulatorisches Risiko in einem Rahmen, in dem Bußgelder bis zu 4 % des weltweiten Jahresumsatzes erreichen können.

• Beschränkungen des grenzüberschreitenden Datentransfers: Die Übermittlung personenbezogener Daten von EU-Bürgern an Nicht-EU-KI-Infrastrukturen erfordert entweder eine Vereinbarung auf Basis von Standardvertragsklauseln oder einen anderen genehmigten DSGVO-Übertragungsmechanismus. Viele KI-SaaS-Anbieter haben ihren Sitz in den USA. Die Compliance-Dokumentation für den Datentransfer zwischen der EU und den USA muss unter Einbeziehung der Rechtsabteilung abgeschlossen werden, bevor die technische Implementierung beginnt. Für bestimmte Datentypen und Risikotoleranzen von Organisationen erfordert diese Anforderung effektiv eine europäische oder vollständig VPC-isolierte Bereitstellung, bei der keine Daten die Jurisdiktionsgrenzen überschreiten.

• Verzeichnis von Verarbeitungstätigkeiten gemäß Artikel 30: Die DSGVO verlangt von Organisationen, Verzeichnisse von Verarbeitungstätigkeiten zu führen, die KI-Systeme umfassen und den Verarbeitungszweck, Datenkategorien, gegebenenfalls internationale Übermittlungen und angewandte Sicherheitsmaßnahmen beschreiben. Audit-Logs von KI-Gateways liefern die Rohdaten für diese Verzeichnisse, müssen jedoch so konfiguriert werden, dass sie die erforderlichen Felder, einschließlich Datenkategorie, Verarbeitungszweck und Übertragungsziel, in einem Format erfassen, das das Compliance-Team auf Anfrage einem Regulierer vorlegen kann.

• Recht auf Erklärung bei automatisierten Entscheidungen: Artikel 22 der DSGVO schränkt vollautomatisierte Entscheidungen ein, die Personen erheblich beeinträchtigen, und gewährt Einzelpersonen das Recht auf eine aussagekräftige Erklärung, wie die Entscheidung zustande kam. KI-Systeme im Versicherungsbereich, die bei der Underwriting- oder Schadenbearbeitung unterstützen, müssen von vornherein mit einer menschlichen Überprüfungsfunktion und der Generierung von Erklärungen in den Workflow integriert werden und dürfen nicht nachträglich hinzugefügt werden. Die Architekturentscheidung, wie KI-Empfehlungen an menschliche Entscheidungsträger gelangen, ist eine Compliance-Entscheidung und nicht nur eine Produktgestaltungsentscheidung.

Die VPC-isolierte Architektur: So sieht sie in der Praxis aus

Die VPC-isolierte LLM-Bereitstellung ist das Architekturmuster, das gleichzeitig die breiteste Palette von Anforderungen regulierter Branchen erfüllt. Die PHI-Isolation für HIPAA, Datenresidenz für die DSGVO, Netzwerksicherheitskontrollen für SOC2 und die operative Verantwortlichkeit für Finanzdienstleistungsregulierungsbehörden ergeben sich alle aus einer ordnungsgemäß implementierten VPC-Bereitstellung. Zu verstehen, was dies tatsächlich beinhaltet, ist das, was Compliance-, Infrastruktur- und Sicherheitsteams vor einem Genehmigungsgespräch benötigen.

• KI-Gateway innerhalb des Perimeters: Das Gateway läuft als containerisierter Dienst innerhalb der VPC der Organisation. Alle LLM-API-Aufrufe werden über dieses interne Gateway geleitet. Keine Anwendung kommuniziert direkt mit einem externen Modell-Anbieter. Das Gateway ist die einzige Komponente mit Egress-Fähigkeit zu externen APIs, und dies nur, wenn die bereitgestellte Architektur den Zugriff auf externe Modelle für spezifische Anwendungsfälle erlaubt, die keine regulierten Daten betreffen. Bei vollständig isolierten Bereitstellungen ist selbst dieser Egress nicht vorhanden.

• Modellbereitstellung innerhalb des Perimeters: Für HIPAA und strenge Anforderungen an die Datenresidenz läuft das LLM selbst innerhalb der VPC. AWS Bedrock, das innerhalb desselben AWS-Kontos aufgerufen wird, Azure OpenAI Service innerhalb eines Azure-Abonnements mit entsprechender BAA-Abdeckung oder selbst gehostete Open-Source-Modelle auf GPU-Infrastruktur innerhalb des Cloud-Kontos erfüllen alle diese Anforderung. Bei vollständig isolierten Bereitstellungen verlassen keine Modellinferenzdaten zu keinem Zeitpunkt des Anfragelife-Cycles die Cloud-Kontogrenze der Organisation.

• Audit-Logs in kundeneigenem Speicher: Alle Audit-Logs werden in die eigene Logging-Infrastruktur der Organisation geschrieben: CloudWatch, Azure Monitor, Splunk oder ein vom Kunden spezifiziertes SIEM. Protokolldaten, die selbst regulierte Informationen enthalten können, werden niemals an den SaaS-Logging-Dienst eines Anbieters übertragen. Aufbewahrungsrichtlinien, Zugriffskontrollen und manipulationssichere Speicherkonfigurationen werden vom Compliance-Team der Organisation verwaltet, ohne von den Aufbewahrungseinstellungen eines Anbieters abhängig zu sein.

• Kein Anbieterzugriff auf den Produktionsdatenverkehr: Bei einer ordnungsgemäß implementierten VPC-isolierten Bereitstellung verbleiben der Inferenz-Traffic im Produktionsbetrieb, Prompt-Inhalte und Modellantworten in der Cloud-Umgebung des Kunden, anstatt über die vom Anbieter verwaltete Infrastruktur geleitet zu werden. Dies reduziert die externe Sichtbarkeit sensibler Datenflüsse erheblich und entspricht den Anforderungen an Datenresidenz und Datenschutz. Der Support-Zugriff wird bei Bedarf über kontrollierte, zeitlich begrenzte „Break-Glass“-Verfahren mit ausdrücklicher Kundenzustimmung geregelt, anstatt über einen dauerhaften Zugriff. Diese Architektur minimiert das Risiko für den Anbieter in Bezug auf regulierte Daten im Produktionspfad, obwohl die Anbieterbeziehung für Plattformsoftware und Support im gesamten Compliance-Umfang der Organisation verbleibt.

Wie TrueFoundry die LLM-Bereitstellung in regulierten Branchen löst

TrueFoundry wird vollständig im Cloud-Konto des Kunden auf AWS, Azure oder GCP bereitgestellt. Keine Produktionsdaten, einschließlich Prompt-Inhalten, Modellantworten, MCP-Tool-Aufrufparametern oder Audit-Log-Daten, verlassen die Unternehmensgrenzen, um die Infrastruktur von TrueFoundry zu erreichen. Dies ist keine Bereitstellungsoption. Es ist die Standardarchitektur für Unternehmensbereitstellungen, kein Premium-Tier.

• VPC-isolierte Bereitstellung standardmäßig: TrueFoundry wird mithilfe von Infrastructure-as-Code im eigenen Cloud-Konto des Kunden bereitgestellt. Das AI-Gateway, MCP-Gateway, die Management-UI und der Audit-Log-Speicher laufen alle innerhalb der Kundengrenzen. Vier Bereitstellungsoptionen decken das gesamte Spektrum ab, von vollständig verwaltetem SaaS ohne Infrastrukturkosten bis hin zu einer vollständigen Control Plane plus Gateway Plane innerhalb des Kundenkontos mit Infrastrukturkosten von ca. 800 bis 1.000 US-Dollar pro Monat. Für regulierte Workloads stellen die Optionen 3 und 4 sicher, dass keine Daten die Infrastruktur von TrueFoundry durchlaufen. Der TrueFoundry-Supportzugriff erfolgt über dokumentierte Break-Glass-Verfahren mit Kundenzustimmung.

• Strukturierte Audit-Logs konform mit HIPAA, SOC2 und GDPR: Jeder LLM-Aufruf generiert einen strukturierten JSON-Audit-Log-Eintrag über den X-TFY-LOGGING-CONFIG-Header. Auf Gateway-Ebene stellt REQUEST_LOGGING_MODE: ALWAYS bei selbst gehosteten Bereitstellungen sicher, dass jede Anfrage ohne Konfigurationsdrift erfasst wird. Die Log-Felder umfassen Benutzeridentität, Modell, Token-Anzahl, Latenz, Kosten, Richtlinienentscheidung und Ausgabe. Logs werden über OpenTelemetry an Grafana, Datadog, Splunk oder jedes OTLP-kompatible SIEM exportiert. Bei selbst gehosteten Bereitstellungen werden Log-Daten im Parquet-Format mit konfigurierbarer Aufbewahrungsdauer in den eigenen AWS S3, GCS oder Azure Blob Storage des Kunden geschrieben. S3 Object Lock im WORM-Modus erfüllt die HIPAA-Anforderung an manipulationssichere Aufbewahrung für das Sechs-Jahres-Minimum.

• SSO-Integration mit klinischen und Unternehmens-Identitätssystemen: TrueFoundry integriert sich mit Okta, Azure Active Directory, PingFederate und jedem SAML 2.0- oder JWKS-kompatiblen Identitätsanbieter. Die Zugriffsverwaltung folgt dem standardmäßigen Identitäts-Lebenszyklusmanagementprozess der Organisation. Entwickler, die einem Team beitreten, erhalten über denselben IdP-Workflow Zugriff auf das AI-Gateway, der auch ihre anderen Systeme bereitstellt. Entwicklern, die das Unternehmen verlassen, wird der Zugriff über denselben Offboarding-Workflow entzogen. Es gibt kein separates AI-Gateway-Anmeldesystem, das unabhängig gewartet oder geprüft werden müsste.

• Katalog genehmigter Modelle für regulierte Workloads: Plattformadministratoren definieren, welche Modelle für welche Datentypen und Anwendungsfälle zugelassen sind. Ein klinisches Team kann keine PHI-haltigen Prompts an ein nicht BAA-berechtigtes Modell weiterleiten, da das Gateway Modell-zu-Anwendungsfall-Richtlinien auf der Routing-Ebene durchsetzt, bevor die Anfrage die Perimeter verlässt. Diese Richtliniendurchsetzung erfolgt am AI-Gateway, nicht auf der Anwendungsebene, was bedeutet, dass sie konsistent angewendet wird, unabhängig davon, welche Anwendung oder welcher Agent die Anfrage initiiert.

• Verifizierte Produktionsbereitstellungen in regulierten Branchen: Medtronic, mit FDA-regulierten Medizinprodukteportfolios, betreibt TrueFoundry im Produktionsbetrieb. Siemens Healthineers setzt es in globalen Medizintechnik-Operationen mit regulatorischer Exposition in mehreren Jurisdiktionen ein. Innovaccer verarbeitet monatlich etwa 17 Millionen klinische KI-Inferenzanfragen innerhalb von AWS GovCloud unter HIPAA, wobei keine Daten ihre Cloud-Grenzen verlassen, und nutzt dabei das TrueFoundry-Gateway mit OpenTelemetry zur Speisung von Grafana-Dashboards. Aviva betreibt TrueFoundry für britische Versicherungsgeschäfte unter GDPR. ResMed nutzt es für digitale Gesundheitsanwendungen. Dies sind Produktionsbereitstellungen im Unternehmensmaßstab mit behördlicher Compliance-Freigabe, keine Pilotprojekte.