Vier Menschen, eine RAG-Plattform — und was sie wirklich brauchen

Produkt-Seiten zeigen Features. Aber niemand kauft ein Feature — gekauft wird die Lösung eines konkreten Problems, das eine konkrete Person hat. Für unsere Multi-Tenant-RAG-Plattform haben wir deshalb zuerst die Menschen aufgeschrieben, dann die Funktionen. Vier davon stehen hier — mit dem, was sie tatsächlich sagen, und mit dem, was die Plattform dafür tut. Wer sich in einer wiedererkennt, weiß danach, ob das Angebot zu ihm passt.

Anna will ankommen, nicht onboarden

Was die Plattform für Anna tut. Sie legt ihren Tenant selbst an, hinterlegt ihren vorhandenen OIDC-Provider — ihr Microsoft Entra — und beginnt sofort mit der Quellen-Einrichtung, ohne Gespräch mit dem Vertrieb. Ihr Confluence bindet sie über einen fertigen Connector an; nach dem ersten Push hat sie einen Chat-Endpoint mit API-Key, den sie von außen per curl ansprechen kann — ohne weitere Konfiguration. Jeder Tenant bekommt seinen eigenen Container-Stack: ein Tenant, ein Stack, ein vorhersehbarer Posten — keine Rechnung, die mit jeder indexierten Seite mitwächst. Und wo dieser Stack steht, ist Teil des Vertrags, nicht ein stiller US-Default.

Claus haftet für das, was der Bot sagt

Was die Plattform für Claus tut. Jeder Tenant hat zwei Stände: eine Stage zum Ausprobieren und den Live-Stand, den Endnutzer sehen. Claus testet Änderungen gegen die Stage — er sieht, wie der Bot mit dem neuen Text tatsächlich antwortet, bevor ihn draußen jemand zu Gesicht bekommt. Eine Diff-Vorschau zeigt, was sich gegenüber Live ändert; per Klick promotet er die Stage zum Live-Stand. Nichts erreicht einen Kunden, das Claus nicht vorher gesehen hat — und „testen wir mal live“ bleibt das, was es sein sollte: ein Test, nicht ein Risiko.

Dirk darf nichts herausgeben

Was die Plattform für Dirk tut. Für Tenants mit strengeren Anforderungen läuft der Connector als Agent in Dirks eigenem Cluster — als Container-Image, das er deklarativ ausrollt, nicht als Web-Installer, den er durchklickt. Entscheidend ist, was diesen Agenten verlässt: nur Chunks und Vektoren wandern zur Plattform, kein einziges Byte Rohinhalt. Die Antwort auf die Frage der Aufsicht — „wo gehen die Daten hin?“ — lautet damit: sie bleiben im Haus. Ein SBOM liegt bei, das Audit-Log auch lokal, und seine Konfiguration lebt als YAML in seinem GitOps-Repo, mit Vier-Augen-Review und Rollback per Revert.

Erika gibt frei — oder eben nicht

Was die Plattform für Erika tut. Sie bekommt keine Folie, sondern Unterlagen: ein Threat-Model, das benennt, welche Bedrohungen abgedeckt sind und welche nicht; einen Audit-Trail nach DSGVO-Logik; eine Sub-Processor-Liste. Weil jeder Tenant seinen eigenen Schlüssel hält, ist Löschung nachweisbar — der Schlüssel wird vernichtet, und sämtliche damit verschlüsselten Daten werden unlesbar, inklusive der Backups. Das ist ein Nachweis, der auf Mathematik beruht, nicht auf der Vollständigkeit einer Suche. Damit kann Erika ihrem Vorstand auf einer Seite erklären, wo Daten lagen, wer sie sehen konnte und wie sie wieder hinausgehen.

Warum es die Mischung braucht

Diese vier haben wenig gemeinsam — außer dass keine Lösung von der Stange sie alle bedient. Generische SaaS-RAG-Tools geben Anna ihren Self-Service, aber nicht Dirks „kein Byte verlässt das Haus“. Ein selbstgebauter Wiki-Bot gibt Dirk seine Kontrolle, aber nicht Annas Schnellstart und nicht Claus’ Vorschau. Die Lücke schließt erst die Kombination: zwei Wege, Inhalte anzubinden — ein Agent für die, die nichts herausgeben dürfen, ein Upload für die, die Komfort wollen — dazu ein eigener Container pro Tenant und der eigene Identity-Provider des Kunden. So findet jede und jeder der vier den eigenen Weg, ohne den Kompromiss der anderen mittragen zu müssen.