Definition: Multi-Tenant-Architektur
Multi-Tenant-Architektur ist ein Architekturmuster, bei dem eine einzelne Anwendungsinstanz und ihre Infrastruktur mehrere Kunden, sogenannte Mandanten, bedienen, während die Daten und Konfiguration jedes Mandanten logisch von denen aller anderen getrennt bleiben.
Kernmerkmale von Multi-Tenant-Architektur
Multi-Tenant-Architektur behandelt Infrastruktur als gemeinsamen Ressourcenpool statt als dedizierte Zuteilung pro Kunde, wobei die Trennung softwareseitig durchgesetzt wird.
- Gemeinsame Rechenleistung, Speicher und Anwendungscode über alle Mandanten hinweg
- Trennung über Mandanten-IDs, Datenbankrichtlinien oder mandantenspezifische Schlüssel
- Zentrale Updates und Patches gelten für alle Mandanten gleichzeitig
- Kapazität skaliert über die gesamte Kundenbasis, nicht pro Kunde
Multi-Tenant-Architektur vs. Single-Tenant-Architektur
Single-Tenant-Architektur gibt jedem Kunden eine eigene Instanz und Datenbank, ohne gemeinsamen Code-Pfad. Multi-Tenant bündelt diese Ressourcen, um Kosten zu senken, und akzeptiert dafür softwareseitige statt physische Trennung. Single-Tenant beseitigt das Risiko einer Mandantenvermischung von vornherein, erhöht aber den Betriebsaufwand, da jeder Patch pro Kunde erfolgt. Die meisten KI-Anbieter setzen standardmäßig auf Multi-Tenant und bieten Single-Tenant oder Hybrides KI-Deployment als höhere Stufe an.
Bedeutung von Multi-Tenant-Architektur im Enterprise-KI-Umfeld
Multi-Tenant-Architektur liegt nahezu jedem Enterprise-SaaS zugrunde, einschließlich der meisten KI-Plattformen, die Mittelstandsunternehmen prüfen. IDC prognostiziert, dass SaaS die größte Kategorie der Public-Cloud-Ausgaben bleibt, überwiegend über Multi-Tenant-Infrastruktur bereitgestellt, weil Anbieter so Updates ausrollen und Kapazität über die gesamte Kundenbasis hinweg skalieren können. Das Mandantenmodell prägt direkt, wie ein Anbieter Fragen zu Datenresidenz und Datensouveränität beantwortet.
Methoden und Verfahren für Multi-Tenant-Architektur
Anbieter setzen Mandantentrennung über eines von drei Datenmodellen um.
Pool-Modell (gemeinsame Datenbank, Mandanten-ID)
Die Datensätze aller Mandanten liegen in derselben Datenbank und denselben Tabellen, getrennt nur über eine Mandantenkennung, die bei jeder Abfrage geprüft wird.
- Niedrigste Kosten pro Mandant, schnellste Bereitstellung
- Trennung vollständig über Anwendungslogik und Row-Level-Security
- Erfordert strenge Tests, da ein fehlender Filter Daten offenlegen kann
Bridge-Modell (Schema pro Mandant)
Jeder Mandant erhält ein eigenes Schema innerhalb einer gemeinsamen Datenbankinstanz. Abfragen werden automatisch auf ein Schema begrenzt, aber Mandanten teilen sich weiterhin Rechenleistung und Speicher, sodass das Noisy-Neighbor-Risiko bestehen bleibt.
Silo-Modell (Datenbank oder Instanz pro Mandant)
Eine eigene Datenbank, manchmal eine eigene Instanz pro Mandant, nähert sich der Isolation von On-Premise KI an, läuft aber weiterhin auf gemeinsamer Cloud-Infrastruktur. Die meisten Anbieter kombinieren alle drei Modelle: Kunden mit geringerer Sensibilität bleiben im Pool, regulierte oder umsatzstarke Mandanten wechseln mit wachsenden Anforderungen in ein Silo.
Wichtige Kennzahlen für Multi-Tenant-Architektur
Die Steuerung von Multi-Tenant-Architektur erfordert Kennzahlen über Betrieb, Strategie und Qualität.
Operative Kennzahlen
- Testabdeckung der Mandantentrennung: 100% der Datenzugriffsabfragen
- Vorfälle mit Mandantenvermischung: keine toleriert
- Durchsetzung von Ressourcenquoten pro Mandant: bei jedem Deployment geprüft
- Bereitstellungszeit für neue Mandanten: unter 24 Stunden
Strategische Kennzahlen
Anbieter und Kunden verfolgen das Verhältnis von Pool- zu Silo-Mandanten gegenüber vertraglichen Zusagen. Da 74% der deutschen Unternehmen auf Private Cloud statt Public Cloud setzen (Bitkom Cloud-Report 2025), fragen Mittelstandskunden zunehmend nach diesem Verhältnis und einem Migrationspfad hin zu dedizierter Mandantentrennung.
Qualitätskennzahlen
Latenz und Fehlerraten sollten über alle Mandanten hinweg unabhängig von Datenbankgröße konsistent bleiben. Eine wachsende Spanne zwischen der schnellsten und langsamsten Mandanten-Antwortzeit signalisiert frühzeitig Ressourcenkonkurrenz.
Risikofaktoren und Kontrollen bei Multi-Tenant-Architektur
Multi-Tenant-Architektur bündelt spezifische Risiken.
Mandantenübergreifender Datenabfluss
Ein fehlender oder fehlerhafter Mandantenfilter in einer gemeinsamen Datenbank kann die Daten eines Kunden für einen anderen offenlegen, das von Mittelstands-IT-Verantwortlichen am häufigsten genannte Bedenken bei der Bewertung von Cloud-KI-Anbietern.
- Row-Level-Security auf Datenbankebene, nicht nur im Anwendungscode
- Mandantenspezifische Verschlüsselungsschlüssel für ruhende Daten
- Regelmäßige Penetrationstests gezielt auf mandantenübergreifende Zugriffspfade
Noisy Neighbor und Ressourcenkonkurrenz
Wenn sich Mandanten Rechenleistung und Speicher teilen, kann die Lastspitze eines Kunden die Antwortzeiten aller anderen Mandanten verschlechtern. Ein AI Gateway mit mandantenspezifischem Rate-Limiting begrenzt dieses Risiko ohne dedizierte Infrastruktur.
Regulatorisches und vertragliches Risiko
Deutsche Datenschutzbehörden und das BSI erwarten dokumentierte Kontrollen zur Mandantentrennung und ab einem definierten Schutzbedarf mandantenspezifische Verschlüsselung. Verträge in regulierten Branchen wie dem Bankwesen verlangen häufig Confidential Computing oder ein eigenes Silo, wodurch das Mandantenmodell zum Beschaffungskriterium wird.
Praxisbeispiel
Ein 140-Mitarbeiter-Hersteller für Spezialchemikalien in Nordrhein-Westfalen wollte einen KI-Agenten für den Kundenservice einführen, doch das Compliance-Team war unsicher, ob eine Shared-Cloud-Plattform die Rezepturdaten von anderen Kunden getrennt halten könnte. Der Anbieter erklärte, dass alltägliche Konversationen in einer Pool-Datenbank mit Row-Level-Isolation liefen, während die firmeneigenen Rezepturdokumente in ein eigenes Schema mit eigenem Verschlüsselungsschlüssel verschoben wurden. So konnte das Unternehmen mit der Standardstufe starten und nur den sensiblen Datensatz aufrüsten, statt eine vollständig dedizierte Bereitstellung zu bezahlen.
- Row-Level-Mandantentrennung für Bestell- und Konversationsdaten
- Dediziertes, verschlüsseltes Schema für Rezepturdokumente
- Dokumentiertes Datenflussdiagramm für Kundenaudits
- Gestufter Upgrade-Pfad von Pool- zu dedizierter Isolation
Aktuelle Entwicklungen und Auswirkungen
Drei Entwicklungen prägen aktuell, wie Anbieter Multi-Tenant-Systeme gestalten.
Mandanten-Abstufung als neuer Standard
Anbieter vergeben zunehmend Isolationsstufen pro Mandant, abhängig von Vertragswert, ähnlich wie Hybrides KI-Deployment die Infrastrukturplatzierung als Entscheidung pro Workload behandelt.
- Einstiegskunden bleiben im Pool-Modell
- Umsatzstarke oder regulierte Kunden erhalten Schema- oder Datenbankisolation
- Der Wechsel zwischen Stufen erfolgt ohne Ausfallzeit
Confidential Computing hält Einzug in Shared Clouds
Hardwarebasiertes Confidential Computing lässt Anbieter Mandantendaten auch während der Verarbeitung verschlüsseln, nicht nur ruhend und bei der Übertragung, und verkleinert so die Lücke zwischen Pool- und dedizierten Bereitstellungen.
Regulatorischer Druck hin zu nachweisbarer Trennung
Die Dokumentationspflichten der EU-KI-Verordnung und die anhaltende DSGVO-Durchsetzung zwingen Anbieter, Mandantentrennung nachzuweisen statt nur zu behaupten. Die Sorge vor Abhängigkeit von Nicht-EU-Cloud-Anbietern, von 78% der deutschen Unternehmen genannt (Bitkom, 2025), beschleunigt die Nachfrage nach Souveränitätsgarantien auf Multi-Tenant-Plattformen.
Fazit
Multi-Tenant-Architektur bleibt das wirtschaftliche Rückgrat von Enterprise-SaaS und KI-Plattformen, weil sie Anbietern erlaubt, eine Codebasis über Tausende Kunden hinweg zu skalieren. Für deutsche Mittelstandskunden entscheidet das Isolationsmodell hinter dieser Skalierung, nicht das Marketing-Etikett, ob eine Plattform zu den eigenen Compliance-Pflichten passt. Die praktische Antwort ist selten eine binäre Wahl zwischen geteilter und dedizierter Infrastruktur, sondern ein gestuftes Modell, das die Isolationsstärke an die Datensensibilität anpasst. Mit reifendem Confidential Computing und wachsender regulatorischer Prüfung wird nachweisbare Mandantentrennung zum Standard-Beschaffungskriterium.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Multi-Tenant- und Single-Tenant-Architektur?
Multi-Tenant betreibt eine gemeinsame Instanz für viele Kunden, logisch getrennt. Single-Tenant gibt jedem Kunden eine eigene Instanz und Datenbank, was mehr kostet, aber standardmäßig isoliert.
Ist Multi-Tenant-Architektur sicher genug für sensible Unternehmensdaten?
Ja, mit Row-Level-Security, mandantenspezifischer Verschlüsselung und regelmäßigen Audits. Sicherheit hängt von der Umsetzungsqualität ab, nicht allein vom Mandantenmodell.
Lohnt sich Single-Tenant-Deployment für ein Unternehmen mit 100 bis 300 Mitarbeitern?
Meist nicht durchgängig. Die meisten Mittelstandsunternehmen betreiben Standardworkflows auf einer gut isolierten Multi-Tenant-Plattform und reservieren dedizierte Schemata nur für ihre sensibelsten Datensätze, etwa Rezepturdaten oder Personalakten.
Wie wirkt sich Multi-Tenant-Architektur auf DSGVO und EU-KI-Verordnung aus?
Die DSGVO verlangt dokumentierte Maßnahmen zur Mandantentrennung, und das BSI erwartet mandantenspezifische Verschlüsselung ab bestimmten Schutzbedarfsstufen. Die EU-KI-Verordnung ergänzt Dokumentationspflichten für Hochrisikosysteme.
Brauchen wir dafür eigene IT-Ressourcen?
Nein. Die meisten Anbieter lassen Sie die Isolationsstufe pro Datensatz wählen, statt einen vollständigen On-Premise-Aufbau zu verlangen, und decken so die meisten Mittelstandsanforderungen ohne eigenes Infrastrukturteam ab.
Wie sorgen Anbieter von KI-Agenten für Mandantentrennung?
Anbieter kombinieren meist Row-Level-Mandantentrennung für alltägliche Workflows mit optionalem, dediziertem und verschlüsseltem Speicher für die sensibelsten Datensätze. Superkind etwa verbindet KI-Agenten mit den bestehenden Systemen eines Unternehmens wie CRM, ERP und E-Mail und isoliert sensible Daten entsprechend, statt alles in einem gemeinsamen Pool zu betreiben.
