EU AI Act und Cloud-Infrastruktur: Warum Datenisolation keine Kostenfrage mehr ist
Multi-Tenancy, also die gemeinsame Nutzung von Anwendung und Datenbank durch mehrere Kunden, ist im SaaS-Markt der Standard. Für regulierte Branchen im Gesundheitswesen, bei Versicherungen und bei Finanzdienstleistern ist dieses Modell durch die Entwicklungen der letzten Jahre jedoch zunehmend unter Druck geraten, sowohl durch dokumentierte Vorfälle als auch durch verschärfte aufsichtsrechtliche Anforderungen.
Dieser Beitrag analysiert, warum geteilte Infrastruktur in regulierten AI-Workflows keine tragfähige Option mehr ist und welche architektonischen Konsequenzen sich daraus ergeben.
Shared Infrastructure: Kostenersparnis mit strukturellem Restrisiko
In einer Multi-Tenant-Architektur nutzen mehrere Kunden dieselbe Anwendungsinstanz und dieselbe Datenbank. Die Trennung der Kundendaten erfolgt logisch, über Regeln auf Software-Ebene. Solange diese Regeln greifen, bleibt das Modell unauffällig. Greifen sie nicht, sind die Daten aller Kunden auf einen Schlag betroffen.
Die OWASP-Foundation formuliert diese Diagnose klar: In einer Multi-Tenant-Architektur kann eine einzelne Schwachstelle die Daten aller Kunden exponieren, Fehlkonfigurationen können Daten über Kundengrenzen hinweg leaken, und Ressourcenkonflikte können die Verfügbarkeit beeinträchtigen.
Dass dieses Risiko nicht theoretisch ist, zeigen mehrere prominente Vorfälle der letzten Jahre. Im September 2025 veröffentlichte der niederländische Sicherheitsforscher Dirk-jan Mollema eine Schwachstelle in Microsoft Entra ID (CVE-2025-55241), dem zentralen Identitätsdienst für Azure und Microsoft 365. Mollema konnte nach eigener Darstellung in jedem öffentlich zugänglichen Entra-ID-Tenant weltweit die Rolle eines globalen Administrators übernehmen. Die Schwachstelle erhielt mit CVSS 10.0 den höchstmöglichen Kritikalitätswert und beruhte auf einer fehlenden Tenant-Validierung in einer internen Microsoft-API. Ein Jahr zuvor, im Jahr 2024, wurde die Cloud-Data-Plattform Snowflake zum Zentrum eines der größten Datenvorfälle des Jahrzehnts. Nach Analysen von Mandiant, dem Threat-Intelligence-Arm von Google Cloud, wurden rund 165 Organisationen kompromittiert, darunter AT&T, Santander und Ticketmaster, mit Auswirkungen auf hunderte Millionen Menschen.
Diese Vorfälle teilen ein Muster. Sie sind nicht das Ergebnis exotischer Angriffstechniken, sondern das vorhersehbare Ergebnis einer Architektur, in der die Datentrennung von der Fehlerfreiheit aller beteiligten Komponenten abhängt. Und sie zeigen, dass selbst Anbieter mit Sicherheitsbudgets in Milliardenhöhe Multi-Tenancy nicht zuverlässig beherrschen.
Warum das für Human Oversight besonders kritisch ist
Gerade im Kontext menschlicher Aufsicht über AI-Systeme spitzt sich diese Problematik zu. Human-Oversight-Software hat einen sehr spezifischen operativen Charakter, der sie von klassischen SaaS-Anwendungen unterscheidet. Vier Eigenschaften sind dafür bestimmend, und jede einzelne von ihnen schärft die Frage nach der Datentrennung weiter:
Jede Entscheidung ist auditpflichtig. Ein Operator prüft einen Fall, trifft eine Entscheidung, und dieser Vorgang muss mit Zeitstempel, Identität und Kontext nachvollziehbar dokumentiert sein. Artikel 14 des EU AI Acts verlangt einen nachweisbaren Audit-Trail menschlicher Prüfentscheidungen, Artikel 12 verlangt manipulationssicheres Logging. In einer geteilten Architektur entsteht dieser Audit-Trail im selben Log-Strom wie die Daten anderer Kunden. Die Abgrenzung erfolgt über Software-Regeln, genau dieselben Regeln, die bei den oben beschriebenen Vorfällen versagt haben.
Die bearbeiteten Inhalte sind personenbezogen und besonders sensibel. Versicherungsfälle, medizinische Bewertungen, Kreditentscheidungen, Fraud-Prüfungen: Was ein Operator zu sehen bekommt, ist regelmäßig das, was die strengsten Kategorien des Datenschutzrechts berührt. Eine Oversight-Plattform ist damit automatisch eine der sensibelsten Stellen in der Datenverarbeitung des Kunden, nicht eine der peripheren.
Die Plattform wird kontinuierlich und in Echtzeit genutzt. Operatoren arbeiten parallel, bearbeiten Fälle, übergeben an Kollegen. Die Daten bewegen sich nicht nur einmal durch das System, sondern sind permanent in Bearbeitung. Jeder dieser Zugriffe ist ein potenzieller Fehlerpunkt, an dem Kundengrenzen durchlässig werden können.
Der Kunde muss Aufsichtsbehörden selbst Rechenschaft ablegen. Nicht der Anbieter der Oversight-Plattform wird vom Regulierer befragt, sondern das regulierte Unternehmen, das sie einsetzt. Ein Vorfall beim Plattformanbieter wird damit unmittelbar zum Vorfall des Kunden, dokumentationspflichtig, meldepflichtig, haftungsrelevant.
Die Summe dieser vier Eigenschaften verändert die Risikoabwägung gegenüber einem klassischen SaaS-Produkt grundlegend. Ein Produktivitätstool, bei dem Multi-Tenant-Risiken akzeptabel sein mögen, und eine Oversight-Plattform, bei der ein Vorfall zur regulatorischen Krise des Kunden wird, sind nicht dieselbe Kategorie von Software.
Dedizierte Instanzen: Datentrennung durch Architektur
Die Alternative ist eine dedizierte Instanz pro Kunde. Jeder Kunde erhält eine eigene, vollständig separierte Umgebung. Es gibt keine gemeinsam genutzten Komponenten, über die Daten zwischen Kunden überhaupt fließen könnten.
Der Unterschied zu Multi-Tenancy ist nicht gradueller, sondern prinzipieller Natur. Multi-Tenancy macht Datentrennung bestenfalls wahrscheinlich. Eine dedizierte Instanz macht sie zur Eigenschaft der Architektur. Das ist die stärkste Form der Sicherheitszusage, die eine Infrastruktur geben kann: nicht „es wird überwacht", sondern „es entsteht nicht erst die Möglichkeit".
Diese Differenz ist regulatorisch entscheidend. In Deutschland und der EU hat sich Mandantentrennung in den letzten Jahren von einer technischen Empfehlung zu einem expliziten Prüfkriterium entwickelt. Der BSI-Kriterienkatalog C5:2026, im März 2026 veröffentlicht, adressiert Mandantentrennung gezielter als jede Vorgängerversion. Für das Gesundheitswesen gilt seit Inkrafttreten des § 393 SGB V am 1. Juli 2024: Gesundheits- und Sozialdaten dürfen nur dann in der Cloud verarbeitet werden, wenn ein aktuelles C5-Testat vorliegt. Die EU-Verordnung DORA, seit dem 17. Januar 2025 verbindlich, verpflichtet über 22.000 Finanzunternehmen zu einem umfassenden Management von IKT-Drittparteienrisiken. Und die BaFin verlangt für wesentliche Cloud-Auslagerungen uneingeschränkte Informations- und Prüfrechte, einschließlich des Zugangs zu Rechenzentren und Servern des Dienstleisters.
Ein weiterer Vorteil in sich geschlossener Systeme zeigt sich jenseits der reinen Datenisolation: Sie lassen sich sauber in die Netzwerkumgebung des Kunden einbetten. Eine dedizierte Instanz kann in einem privaten Netzwerksegment, einer Virtual Private Cloud oder on-premise betrieben werden, ohne dass Verkehr über das öffentliche Internet geführt werden muss. Die Kommunikation zwischen der AI-Infrastruktur des Kunden und der Oversight-Plattform erfolgt dann ausschließlich innerhalb der vom Kunden kontrollierten Netzwerkzone. Für Unternehmen mit strengen Netzwerk-Policies, Perimeter-Anforderungen oder Datenresidenz-Vorgaben ist das häufig die Voraussetzung, unter der eine externe Komponente überhaupt angebunden werden darf. In einer Multi-Tenant-Architektur ist dieser Zuschnitt per Definition nicht möglich: Der Anbieter müsste für jeden Kunden eine separate Netzwerktopologie betreiben, was den wirtschaftlichen Kern des Multi-Tenancy-Modells aufhebt.
Warum die Plattformwahl nicht neutral ist
Dedizierte Infrastruktur zu betreiben, ist die eine Hälfte der Aufgabe. Die andere ist die Wahl der technischen Grundlage, auf der diese Infrastruktur läuft. Die vier im vorigen Abschnitt beschriebenen Eigenschaften von Human-Oversight-Software müssen in der Plattform abgebildet sein, sonst tragen die Versprechen der dedizierten Architektur in der Praxis nicht.
Das schließt nicht aus, dass sich diese Eigenschaften auf anderen Plattformen umsetzen lassen. Erfahrene Teams können in ausgereiften Enterprise-Stacks wie Java oder .NET Systeme bauen, die kontinuierliche Echtzeit-Interaktion, exklusive Fallbearbeitung und hohe Verfügbarkeit zuverlässig liefern. Die Frage ist, zu welchem Preis. Jede dieser Eigenschaften wird in diesen Stacks durch eine eigene Bibliothek, einen eigenen Zusatzdienst oder einen eigenen Konfigurationsaufwand abgedeckt. Die Summe dieser Komponenten ergibt einen Stack, in dem die Kernanforderungen von Human-Oversight-Software nachgerüstet sind, nicht eingebaut.
Die Folgen sind konkret: höhere Komplexität in Entwicklung und Betrieb, mehr potenzielle Ausfallpunkte, mehr Einzelkomponenten, die in einer regulierten Umgebung dokumentiert, geprüft und gewartet werden müssen. Was auf einer nativ passenden Plattform ein Implementierungsdetail ist, wird auf einem nachrüstbaren Stack zu einem eigenen Teilprojekt. Diese Komplexität ist nicht nur ein Kostenfaktor, sondern ein Risikofaktor. Jede zusätzliche Komponente ist eine weitere Schnittstelle, die ausfallen, falsch konfiguriert oder im Fehlerfall missverstanden werden kann.
Elixir auf der BEAM: Architektur statt Nachrüstung
HumanSeal ist in Elixir auf der BEAM-Plattform implementiert, der Laufzeitumgebung, die ursprünglich von Ericsson für Telekommunikationsinfrastruktur entwickelt wurde. Diese Plattform ist nicht für Oversight-Software konzipiert worden. Sie ist für einen Anwendungsfall entworfen, der ihr strukturell sehr ähnlich ist: sehr viele nebenläufige, langlebige, zustandsbehaftete Interaktionen, die in Echtzeit koordiniert werden müssen, bei unterbrechungsfreier Verfügbarkeit und mit Fehlertoleranz auf Prozessebene.
Die BEAM hält im laufenden Betrieb sehr viele voneinander isolierte Vorgänge parallel, ohne dass wartende Vorgänge ins Gewicht fallen. Echtzeit-Kommunikation, die Koordination nebenläufiger Nutzer und die Exklusivität einzelner Bearbeitungsvorgänge sind in der Plattform selbst verankert, nicht in separaten Bibliotheken oder Diensten. Was auf anderen Stacks durch eigene Komponenten abgebildet werden muss, ergibt sich hier aus den Grundeigenschaften der Laufzeitumgebung.
Ausfallsicherheit ist in der BEAM keine Ergänzung, sondern Grundeigenschaft. Die Plattform wurde für eine Verfügbarkeit von 99,999 Prozent entwickelt, entsprechend weniger als fünfeinhalb Minuten Ausfall pro Jahr. Fehlertoleranz, automatische Wiederherstellung einzelner Komponenten und unterbrechungsfreie Code-Aktualisierung sind Eigenschaften, aus denen die Plattform besteht. Dass diese Architektur auch unter hoher Last trägt, ist in der Praxis belegt: Discord betreibt seine gesamte Echtzeit-Chat-Infrastruktur in Elixir und berichtete im November 2023 über die Skalierung des Midjourney-Servers auf eine für diese Plattform bislang unerreichte Dimension gleichzeitig verbundener Nutzer.
Gerade regulierte Großkunden mit hohem Durchsatz an Prüfentscheidungen profitieren von dieser Grundauslegung. Steigendes Fallvolumen, wachsende Operator-Teams und zusätzliche Workflow-Typen führen nicht zu einer Neubewertung der Architektur; sie führen dazu, dass die bestehende Architektur mehr leistet. Kunden, die heute mit einem definierten Anwendungsfall starten und in zwei Jahren deutlich größere Volumina verarbeiten, arbeiten auf derselben technischen Grundlage weiter.
Abschluss
Die Debatte um Multi-Tenancy in SaaS-Produkten wird häufig als wirtschaftliche Abwägung geführt. Geteilte Infrastruktur senkt Kosten, dedizierte Infrastruktur erhöht sie. Diese Abwägung ist für regulierte AI-Workflows nicht mehr die richtige. Die aufsichtsrechtliche Entwicklung der letzten Jahre hat Mandantentrennung als Mindestanforderung etabliert, deren Nachweis gegenüber Aufsichtsbehörden erbracht werden muss. Die dokumentierten Vorfälle derselben Jahre, vom Snowflake-Vorfall 2024 bis zur Entra-ID-Schwachstelle von 2025, haben gezeigt, dass selbst Hyperscaler mit unvergleichbaren Sicherheitsbudgets Multi-Tenancy nicht zuverlässig beherrschen.
Die Konsequenz ist doppelt. Eine Oversight-Plattform für regulierte Branchen muss jedem Kunden eine dedizierte Instanz mit eigener Datenbank zur Verfügung stellen. Und sie muss auf einer technischen Grundlage betrieben werden, die die spezifischen Anforderungen dieses Anwendungsfalls, Echtzeit-Interaktion, Exklusivität der Bearbeitung, Effizienz bei wartenden Prozessen und hohe Verfügbarkeit, nicht durch Nachrüstung, sondern in ihrer Architektur abbildet. Beides zusammen ist die Voraussetzung für eine Infrastruktur, die ein Audit besteht und gleichzeitig die operative Last trägt, die regulierte AI-Workflows erzeugen.
Die eigentliche Frage für regulierte Unternehmen ist damit nicht, ob sie sich dedizierte Infrastruktur leisten können. Die Frage ist, ob sie sich das Risiko geteilter Infrastruktur noch erlauben können.