Mandantenfähigkeit (Multi-Tenancy)

Mandant, Benutzer und Rolle sind verschiedene Dinge

Ein Benutzer ist eine zugreifende Identität. Eine Rolle beschreibt erlaubte Tätigkeiten. Der Mandant ordnet diese Tätigkeiten und Daten einem Kunden- oder Organisationskontext zu. Ein Partner kann beispielsweise für zwei Kunden tätig sein, ohne dass deren Mitarbeitende gegenseitig ihre Gesprächsprotokolle sehen dürfen. Dafür reicht eine erfolgreiche Anmeldung allein nicht aus.

AWS beschreibt Tenant Isolation ausdrücklich als eigene Anforderung neben Anmeldung und Berechtigungen. Jede relevante Operation muss den zulässigen Mandantenkontext berücksichtigen. Das betrifft nicht nur sichtbare Listen, sondern auch einzelne Datensätze, Dateien und Hintergrundverarbeitung. Ein Zugriff darf nicht allein deshalb zulässig werden, weil jemand eine gültige Objektkennung kennt.

Welche Betriebsmodelle sind möglich?

Mandanten können Teile der Anwendung und Infrastruktur gemeinsam nutzen oder stärker getrennt betrieben werden. Zwischen einer vollständig gemeinsamen Umgebung und einer eigenen Bereitstellung pro Kunde liegen Mischformen. Die Architektur muss deshalb benennen, welche Komponenten geteilt werden und an welcher Stelle die Trennung durchgesetzt wird. Das Wort mandantenfähig beschreibt diese Ausgestaltung noch nicht vollständig.

Gemeinsame Ressourcen vereinfachen bestimmte Betriebsaufgaben, können aber gegenseitige Lastwirkungen verursachen. Getrennte Datenbanken oder Bereitstellungen verändern Wartung, Kosten und Wiederherstellung. Microsoft behandelt diese Abwägungen als eigene Architekturentscheidungen. Mehr Trennung ist nicht pauschal die richtige Antwort für jeden Prozess; Anforderungen, Zuständigkeiten und überprüfbare Schutzmaßnahmen müssen zusammenpassen.

Warum ist die Trennung bei Voice AI besonders relevant?

Ein Telefonassistent verarbeitet mehr als eine Rufnummer. Wissen, Gesprächsergebnisse, Weiterleitungsziele und Zugangsdaten zu angebundenen Systemen müssen zum vorgesehenen Kunden gehören. Wenn ein IT-Systemhaus mehrere Kunden betreut, darf etwa ein Aufruf zur Ticketerstellung nicht versehentlich die Verbindung eines anderen Kunden verwenden. Auch die Suche in einer Wissensbasis muss innerhalb des erlaubten Kontexts bleiben.

Ein zweckmäßiger Test nutzt zwei getrennte Testkunden mit klar unterscheidbaren Beispieldaten. Anschließend wird geprüft, ob Nutzer von Kunde A weder Inhalte noch Dateien oder Ergebnisse von Kunde B abrufen können. Derselbe Testgedanke gilt für Exporte und Hintergrundaufgaben. Das ist ein Prüfverfahren für die konkrete Anwendung, keine Behauptung über einen bereits durchgeführten Kundentest.

• Wissenszugriff: Antworten und Suchtreffer bleiben im freigegebenen Kundenkontext.
• Integrationen: Zugangsdaten und Zielsystem gehören zum vorgesehenen Mandanten.
• Administration: Partnerrechte und Kundenrechte sind nachvollziehbar getrennt.
• Betrieb: Export, Löschung und Wiederherstellung berücksichtigen Kundengrenzen.

Was sollten Partner vor einem Rollout klären?

Für ein Partnerangebot sollten technische Trennung und organisatorische Verantwortung gemeinsam beschrieben werden. Wer darf einen Kunden anlegen, Wissen freigeben, Integrationen ändern oder Ergebnisse exportieren? Welche Rechte benötigt der laufende Support? Solche Fragen lassen sich an konkreten Tätigkeiten prüfen und sind aussagekräftiger als ein allgemeines Versprechen vollständiger Kontrolle.

White-Label und Mandantenfähigkeit beantworten unterschiedliche Fragen. White-Label betrifft den Auftritt unter eigener Marke; Mandantenfähigkeit betrifft die gemeinsame Nutzung und Abgrenzung von Kundenkontexten. Die smao Partnerseite erklärt das Partnerangebot, die Architekturseite die grundlegenden Daten- und Betriebswege. Diese Produktinformationen ersetzen nicht die Prüfung der für ein einzelnes Kundenprojekt benötigten Rollen und Abläufe.