Mandantentrennung für RAG und Agenten

Ein Pilot läuft. Der Index ist einer. Der Prompt ist einer. Der zweite Kunde kommt. Plötzlich liegen zwei Akten im selben Raum. Ohne Mandantentrennung bleibt das ein Einzelkunde.

Was getrennt sein muss

Nicht nur die Oberfläche. Der Retrieval-Pfad:

eigener Filter oder eigener Index pro Mandant

keine Chunks über die Grenze, auch nicht „ähnlich“

Secrets und Keys nicht im gemeinsamen Repo-Default

Agent-State, der nicht den anderen Mandanten mitschleppt

Ein gemeinsamer Vektorraum mit Hoffnung auf Metadata-Filter ist der häufigste Fund. Der Filter fehlt einmal. Die Antwort zitiert den Nachbarn.

Der Filter muss im Code sitzen, nicht in der Absicht. So sieht das bei uns aus: Tenant kommt aus dem Auth-Kontext, nie aus dem Prompt.

def retrieve(query: str, tenant_id: str, store, embed, k: int = 8):
    if not tenant_id:
        raise ValueError("tenant_id missing")

    hits = store.search(
        embed(query),
        k=k,
        filter={"tenant_id": tenant_id},
    )
    return [h for h in hits if h.metadata.get("tenant_id") == tenant_id]

Der zweite Check nach der Suche ist Absicht. Metadata-Filter in Milvus oder pgvector können fehlen, wenn jemand den Index neu aufsetzt. Dann filtert die zweite Zeile. Fehlt sie, zitiert der Nachbar.

Zwei Bilder aus der Praxis

Der KI-Workspace für Lebensmitteltechnologen war von Anfang an multi-tenant. Sonst bleibt er ein Team-Pilot.

Die ÖPNV-Plattform hat 20+ Instanzen. Dort ist Trennung Betrieb, nicht Feature: Pipeline und Rollback pro Mandant. Dieselbe Idee gilt für RAG. Ein Index für alle ist das Swarm-Skript für alle.

Was der Check daraus macht

Tag 4 im LLM-Readiness-Check ist Betrieb, Kosten, Mandanten. Ein Pilot ohne Trennung ist kein Go-Live für den zweiten Kunden.

Verwandt: Hybrid-RAG, Evaluation. Leistung: KI-Engineering. Wer die Plattformseite sucht: Cloud und Kubernetes und das Migrations-Assessment.