Wie eine Multi-Tenant-Vektordatenbank mehrere Kunden zugleich bedient

Eine Multi-Tenant-Vektordatenbank erlaubt es einer einzigen KI-Infrastruktur, mehrere Kunden gleichzeitig zu bedienen, wobei die Daten jedes Kunden logisch getrennt bleiben und nie in fremde Suchergebnisse geraten. Statt einer eigenen Datenbank je Kunde wird eine gemeinsame Datenbank mit Metadaten-Kennzeichnung verwendet, etwa client_id oder institution_id, die bei jeder Abfrage so filtert, dass Agent oder Chatbot ausschließlich Daten sieht, zu denen der jeweilige Kunde berechtigt ist.

Warum Multi-Tenant-Architektur wichtig ist

Für Unternehmen, die eine KI-Lösung für mehrere Kunden zugleich bauen, zählt dieser Ansatz aus zwei Gründen:

• Kosten- und Wartungseffizienz – eine verwaltete Infrastruktur statt Dutzender getrennter Datenbanken senkt Betriebskosten und Verwaltungsaufwand.
• Skalierbarkeit – ein neuer Kunde bedeutet einen neuen Metadatenfilter, nicht den Aufbau neuer Infrastruktur.

Ohne sauber entworfene Architektur dupliziert ein Unternehmen entweder die Infrastruktur je Kunde, was teuer und schwer skalierbar ist, oder riskiert, dass sich Daten verschiedener Kunden in den Ergebnissen vermischen. Das ist zugleich ein Sicherheits- und ein Compliance-Risiko.

Wie die Trennung in der Praxis funktioniert

1. Kennzeichnung beim Indexieren – jedes Dokument wird beim Einfügen mit Metadaten versehen, die den Eigentümer benennen: Kunde, Institution, Abteilung oder Zugriffsstufe.
2. Filtern bei der Abfrage – stellt jemand eine Frage, ergänzt das System einen Filter nach Identität und Zugriffsrechten, bevor die semantische Suche läuft.
3. Nur berechtigte Treffer zurückgeben – selbst wenn die Datenbank Tausende Dokumente von Dutzenden Kunden enthält, stützt sich die Antwort ausschließlich auf Daten, die die fragende Person sehen darf.

Das unterscheidet sich vom einfacheren Ansatz „eine Datenbank je Kunde", der leichter umzusetzen, aber deutlich teurer und bei Dutzenden oder Hunderten Kunden schwer skalierbar ist.

Die wesentlichen Architekturentscheidungen

Die zweite Zeile ist der häufigste Fehler. Wird erst nach dem Retrieval gefiltert, sind die Dokumente eines fremden Kunden bereits im System, und Sie verlassen sich darauf, dass die Anwendung sie aussortiert. Das hängt unmittelbar mit dem zusammen, was der Artikel über Sicherheitsrisiken von LLMs behandelt.

Anwendungsfall: eine Plattform für viele gleichartige Institutionen

Der typische Fall ist ein KI-Produkt für mehrere Organisationen derselben Art: mehrere Hochschulen, mehrere Filialen einer Kette oder mehrere Kunden derselben Branche. Jede Institution hat eigene Dokumente, doch alle teilen dieselbe Anwendungslogik und Infrastruktur.

Eine Multi-Tenant-Datenbank mit Filterung nach Institution erlaubt dann:

• Einen neuen Kunden schnell aufzuschalten, ohne neue Infrastruktur zu bauen.
• Zu garantieren, dass Daten einer Institution nie bei Nutzern einer anderen erscheinen.
• Auf Dutzende Kunden zu skalieren, bei minimal steigenden Kosten je Kunde.
• Aktualisierungen zentral über alle Kunden hinweg auszurollen.

Dieses Modell ist typisch für B2B-SaaS-KI-Produkte, bei denen dieselbe Plattform an mehrere Organisationen einer Branche verkauft wird. Die darüber laufende Schicht ist meist RAG.

Sicherheitsaspekte, die sich nicht übergehen lassen

• Test der Datenisolation – vor dem Start muss geprüft werden, dass die Filterung auch in Randfällen trägt.
• Zugriffsprotokollierung – wer wann auf welche Daten zugegriffen hat, ist für Compliance wichtig, besonders in regulierten Branchen.
• Sicherung und Ausfallisolation – ein Problem bei einem Kunden darf Verfügbarkeit und Sicherheit der Daten anderer nicht berühren.

Die Isolation in einem Multi-Tenant-System muss so gründlich getestet werden wie die Antworten selbst. Ein Fehler zeigt sich hier nicht als schlechte Antwort, sondern als Antwort aus fremden Dokumenten.