Unternehmens-RAG — eine berechtigungsgesteuerte Wissensplattform für ~500 interne Nutzer
Eine UK-Gruppe für Bauinstandsetzung, Wartung und Sanierung (unter NDA) wickelte ihr Bid- und Commercial-Geschäft auf Terabytes vergangener Projekte ab, verteilt auf SharePoint. Kalkulatoren brauchten regelmäßig ~15 Minuten, nur um den einen vergleichbaren Auftrag zu finden, mit dem sie eine neue Anfrage scopen und bepreisen konnten. Wir haben eine berechtigungsgesteuerte RAG-Plattform auf AWS Kendra, Bedrock und OpenFGA gebaut, die daraus eine Frage und eine Antwort gemacht hat. Dann fragten andere Abteilungen sie ebenfalls an.
Kunde
Eine UK-Gruppe für Bauinstandsetzung, Wartung und Sanierung (unter NDA). Das Projekt wurde für die Bid- und Commercial-Abteilung umgesetzt, mit rollenbasiertem Zugriff für ~500 interne Nutzer über Abteilungen hinweg.
Engagement
Discovery → PoC → vollständiges internes Portal → Ausbau auf weitere interne Anwendungsfälle. Ausgeliefert als selbst gehostete Plattform im AWS-Estate des Kunden (eu-west-1 / eu-west-2).
Terabytes an Projekthistorie — und keine davon auffindbar, wenn ein Angebot tickt.
Das Bid-Team scoped und bepreist Instandsetzungs-, Wartungs- und Sanierungsleistungen in ganz Großbritannien. Jede neue Anfrage eines Kunden ist in der Praxis eine Frage gegen die eigene Firmenhistorie: Haben wir diesen Gebäudetyp in dieser Region in dieser Größenordnung schon einmal gemacht — und was hat das gekostet, wie ist es gelaufen? Die Antwort lag immer irgendwo in SharePoint: in Ausschreibungsunterlagen, Leistungsverzeichnissen, Baustellenprotokollen, Abnahmeprotokollen, Sitzungsprotokollen, Schreiben, Fotopaketen. Die Kalkulatoren konnten sie schlicht nicht im Zeitbudget eines Angebots finden.
Zwei Randbedingungen haben aus „eine RAG-Demo bauen" ein echtes Engineering-Problem gemacht. Erstens: Berechtigungen. Nicht jeder Kalkulator darf jedes Projekt sehen. SharePoint kodierte bereits einen ACL-Graphen nach Abteilung, Rolle und Ordner — und die Plattform musste ihn respektieren. Ein RAG-System, das Inhalte zurückgibt, die der Nutzer nicht sehen darf, ist kein Produktivitätstool, sondern ein Datenleak. Zweitens: Nachvollziehbarkeit. Eine Preisentscheidung auf Basis eines halluzinierten vergangenen Projekts ist schlimmer als gar keine Antwort. Jede Aussage musste auf ein konkretes Dokument auf einer konkreten Seite in SharePoint verweisen — hinter demselben Login, den der Nutzer ohnehin schon nutzt.
Berechtigung vor Retrieval. ReAct-Agent mit CRAG-Grading. Schema-typisierte Antworten mit SharePoint-Belegen.
Fünf Schichten — jede an einen spezifischen Fehlertyp von „RAG über SharePoint" im echten Unternehmensalltag gekoppelt.
Identität und Autorisierung, nicht nur ein API-Key. Jede Anfrage läuft über Keycloak-SSO (den bestehenden IdP des Kunden). Auf Keycloak setzen wir OpenFGA für feingranulare Autorisierung auf: Nutzer gehören zu Abteilungen, Abteilungen erhalten Zugriff auf Anwendungen und Dokumentumfänge, und Rollen (admin, member, super_admin) regeln Schreib- vs. Lesezugriff. Das Retrieval wird gefiltert, bevor das LLM überhaupt etwas sieht — Kendra-Ergebnisse werden mit dem FGA-Entscheidungsgraphen für den aktuellen Nutzer geschnitten.
Strukturierte Ingestion realer Office-Dokumente. Vergangene Projekte liegen als PDFs, PPTX-Foliendecks, DOCX-Angebotsantworten, XLSX-Kostenmodelle und E-Mail-Archive vor. Wir haben eine AWS-Lambda-Ingestion-Pipeline mit eigenen Layern pro Format gebaut (pdf-parse / pdf-lib für PDF, node-pptx-parser für Folien, LibreOffice für Legacy-Formate, ein XLSX-Layer für Kostenmodelle). Dokumente landen in S3, werden mit erhaltenen Metadaten (Abteilung, Projekt-ID, Dokumenttyp, SharePoint-URL, Eigentümer, Stand) in Kendra geparst und bleiben aus SharePoint re-synchronisierbar.
Retrieval als ReAct-Agent, nicht ein einzelner Embedding-Aufruf. Jede Frage durchläuft einen Intent-Klassifikator (knowledge_query, small_talk, clarification, off_topic, meta, ambiguous) und einen Query-Analyzer, der Komplexität bewertet, Entitäten extrahiert und zeitliche Bezüge identifiziert. Komplexe mehrteilige Fragen werden über einen Query-Decomposer geroutet, der geordnete Teilanfragen mit Abhängigkeitstypen (sequenziell, bedingt, kontextuell) ausgibt. Der ReAct-Agent führt dann Thought–Action–Observation-Schleifen über Kendra aus, mit einem Document-Grader im CRAG-Stil, der jeden Kandidaten als highly_relevant / partially_relevant / not_relevant kennzeichnet und entweder fortfährt, die Anfrage umschreibt und erneut versucht, oder nichts zurückgibt.
Schema-typisierte Antworten mit Inline-Zitaten. Die Generierung läuft auf AWS Bedrock (Anthropic Claude Sonnet, eu-west-1) via Vercel AI SDK. Die Antwort ist ein Zod-typisiertes Objekt mit zwei Feldern: aiAnswer — Text mit Inline-Zitatmarkern [1] [2] plus einer Referenzliste aus (Titel, SharePoint-URL, Seitenzahl) — und documentResults — die Belegdokumente mit Typ (MSA / SOW / Vertrag / Angebot / Bericht), Eigentümer, Stand und Relevanzprozentsatz. Die UI rendert Zitate als klickbare SharePoint-Links, die dieselbe Keycloak-Session respektieren — Nachvollziehbarkeit ist einen Klick entfernt, hinter derselben Autorisierung, die der Nutzer ohnehin schon hat.
Qualitätsguards auf dem Hin- und Rückweg. Eine Prompt-Injection- / Input-Sanitization-Schicht schützt den Prompt-Pfad. Nach der Generierung gleichen ein Response-Validator und ein Hallucination-Checker jede Aussage gegen die abgerufenen Belege ab und bewerten die Verankerung pro Aussage. Die gesamte Pipeline ist an einen promptfoo-Eval-Harness angeschlossen — 30+ Anwendungsfälle (Dokumentensuche, E-Mail zusammenfassen / beantworten / verfassen, SOW-Generator, Business-Case-Autor, Social Posts, Pressemitteilungen etc.) mit Rubrik-als-Code-LLM-Judge-Assertions, die bei jeder Änderung laufen.
Architektur (Datenfluss)
Die Dokumentensuche kollabierte von ~15 Minuten auf Sekunden — auf einer berechtigungsgesteuerten Quelle, nach der danach der Rest des Unternehmens fragte.
Schnellere Dokumentensuche
Von ~15 Minuten Ordnerwühlen auf eine belegte Antwort in Sekunden — gemessen am ersetzten Kalkulator-Workflow.
Interne Nutzer
Rollenbasierter Zugriff in der Bid- und Commercial-Abteilung sowie angrenzenden Funktionen. Jedes Retrieval wird über OpenFGA gegen Abteilungszugehörigkeit und Dokumentfreigaben des Nutzers gefiltert.
Indexiertes Korpus
Ausschreibungsunterlagen, LVs, Verträge, Angebote, Berichte, Sitzungsprotokolle, Schreiben und E-Mail-Archive — synchron zu SharePoint, an einer einzigen Such- und Chat-Oberfläche.
Ausgelieferte Use Cases
Dokumentensuche war der Einstieg. E-Mail-Zusammenfassung / -Antwort / -Verfassen, SOW-Generator, Business-Case-Autor, Aufwandsschätzer, Sitzungsprotokoll-Refiner, Pressemitteilungen, Social Posts und Jira-Ticket-Erstellung folgten.
Berechtigungsumgehungen
Das Retrieval wird mit dem FGA-Entscheidungsgraphen geschnitten, bevor das LLM einen Chunk sieht. Nutzer sehen nur, was sie in SharePoint ohnehin sehen durften.
Eval-Gates bei jeder Änderung
promptfoo führt LLM-Judge-Rubrik-Assertions über die Use-Case-Bibliothek bei jeder Pipeline-Änderung aus. Qualitätsregressionen werden vor dem Deployment erkannt.
Die meisten „Enterprise RAG"-Demos sterben in der Sekunde, in der echte Berechtigungen ins Spiel kommen. Diese Plattform war das gegenteilige Engineering-Problem zu den öffentlichen RAG-Benchmarks: Identität, Autorisierung und Nachvollziehbarkeit kamen zuerst, und die Retrieval-Architektur musste innerhalb dieser Randbedingung leben. Genau dort liegt der Wert.
Fünf Entscheidungen, die die Plattform den Kontakt mit dem realen Geschäft überleben ließen.
1. Autorisieren, bevor man retrievt. OpenFGA ist keine nachträgliche Schicht über einem Suchindex — es ist das Gate, das entscheidet, was Kendra für diesen Nutzer überhaupt zurückgeben darf. Der Entscheidungsgraph spiegelt die Abteilungs- und Ordner-ACLs aus SharePoint, sodass die juristische / HR-Frage „wer darf was sehen" nie in den Prompt des LLMs wandert.
2. Den Dokumentbestand als System behandeln, nicht als Ordner. Reale Enterprise-Korpora sind PDFs, PPTX-Decks, DOCX-Angebote, XLSX-Kostenmodelle, .msg-E-Mail-Archive und nur-bildhafte Scans. Eigene Lambda-Layer pro Format (inklusive LibreOffice für Legacy-Konvertierung) ergeben eine einheitliche Pipeline in Kendra, ohne Tabellen, Foliennotizen oder Seitenhierarchie zu verlieren.
3. ReAct mit CRAG, nicht One-Shot-Retrieval. Ein Document-Grader, der „dieses Ergebnis ist nur teilweise relevant, versuch eine Umformulierung" sagen kann, schlägt höheres Top-k und längeres Kontextfenster. Die meisten Produktionsfehler, die wir gesehen haben, sind Retrieval-Fehler, die sich als Generierungsfehler tarnen.
4. Schema-typisierte Antworten mit klickbarer Nachvollziehbarkeit. Ein Zod-Schema, das aiAnswer + references[] + documentResults[] mit SharePoint-URLs vorschreibt, zwingt jede Aussage, irgendwohin zu zeigen, wo ein Mensch sie verifizieren kann. Genau das hat Bid & Commercial dem System genug vertrauen lassen, es tatsächlich zu nutzen.
5. Use Cases als Portfolio mit CI-Gates. Dokumentensuche war der Einstieg, nicht das Ziel. promptfoo-Evals auf jedem Prompt / Use Case ließen uns SOW-Generierung, E-Mail-Verfassen, Jira-Ticket-Erstellung, Social Posts und Sitzungsprotokoll-Refining hinzufügen, ohne die Suchqualität still zu regredieren.
Discovery → PoC → Plattform → Ausbau.
- Discovery
Quellen, Berechtigungen und Rollen
SharePoint-Quellen, ACL-Struktur, Abteilungs-/Rollenhierarchie und den Bid-Workflow gemappt, den die Plattform ersetzen sollte. OpenFGA-Schema und Evaluierungsset entworfen.
- PoC
Kendra + Bedrock Baseline auf einem realen Ausschnitt
Kendra (eu-west-2) und Bedrock (eu-west-1) aufgesetzt, Keycloak + OpenFGA verdrahtet, einen repräsentativen Korpus-Ausschnitt indexiert und End-to-End-Retrieval plus Autorisierung vor der Skalierung validiert.
- Plattform
Internes Portal, Multi-Use-Case-Backend
NestJS-11-Backend mit Intent-Klassifikator, Query-Analyzer, Decomposer, CRAG-Grader, ReAct-Agent und Zod-typisierter Generierung. React 19 + Vite Frontend mit einem eigenen
useRagChat-Hook für strukturierte Antworten. Lambda-Ingestion-Pipeline. AWS SES für transaktionale E-Mails, Jira-API für Ticket-Erstellung, md-to-pdf / remark-docx / pdf-lib für Dokumentengenerierung. promptfoo-Eval-Harness in CI. - Ausbau
Von Bid-Support in breitere interne Anwendungsfälle
Dokumentensuche war der Einstieg. Die Plattform absorbierte danach E-Mail-Zusammenfassung / -Antwort / -Verfassen, SOW-Erstellung, Business-Case-Verfassen, Social Posts, Pressemitteilungen, Aufwandsschätzung, Sitzungsprotokoll-Refining und Jira-Ticket-Erstellung — jeder Use Case ausgeliefert als evaluierter Anwendungsfall hinter derselben Auth- und Nachvollziehbarkeitsschicht.
Gleiche Engineering-DNA, andere Probleme.
Wir haben diese Plattform einmal gebaut. Wir können sie für Sie bauen.
Bringen Sie uns Ihren Dokumentbestand, Ihren Auth-Provider und den Workflow, den Sie komprimieren wollen. Wir liefern Architektur, Evaluierungsset und Kosten für Aufbau und Betrieb.