Zum Hauptinhalt springen
Case Study

Case Study — Internes Wissensportal mit RAG: Bauträger spart 60% Onboarding-Zeit

Wie ein regionaler Bauträger in Salzburg/OÖ mit RAG, Permissions-Filter und Slack-Integration die Onboarding-Zeit neuer Projektleiter von 8 auf 3 Wochen gedrückt hat.

Von Andreas Will12 Min. Lesezeit
#RAG#Bauträger#Onboarding#Knowledge Management#Case Study

Bei einem regionalen Bauträger in Salzburg/Oberösterreich saß im Frühjahr 2025 ein neuer Projektleiter in der zweiten Woche vor seinem Laptop und suchte das aktuelle Übergabe-Protokoll für ein Wohnbau-Projekt aus 2022. Er fand drei Versionen — eine in Confluence, eine in SharePoint, eine in einem alten Fileshare, plus zwei E-Mail-Anhänge im Outlook seines Vorgängers, der seit sechs Monaten nicht mehr im Unternehmen war. Welche die aktuelle war? Niemand wusste es. Diese Szene war der Anlass für ein RAG-Projekt, das ein Jahr später die Onboarding-Zeit um 63 Prozent reduziert hat — und keinen Datenschutz-Vorfall produziert.

1. Ausgangslage — vier Quellen, drei Wahrheiten, ein Wissens-Vakuum

Der Bauträger arbeitet in Projekten zwischen 18 und 36 Monaten Laufzeit, mit 8 bis 14 parallel laufenden Bauvorhaben. Jeder Projektleiter (intern: PM) verwaltet zwei bis drei Projekte gleichzeitig. Das Wissen pro Projekt — Genehmigungen, Verträge, Bautagebücher, Übergabe-Protokolle, Mängel-Listen — verteilt sich historisch gewachsen auf:

  • Confluence für Projekt-Pages und Meeting-Protokolle (rund 4.200 Pages über sechs Jahre).
  • SharePoint für Dokumente mit Workflow (rund 22.000 Dateien).
  • Alter Fileshare für Pläne, Visualisierungen, alte Verträge (rund 180 GB).
  • Outlook-Postfächer für E-Mail-Verläufe zu Vereinbarungen, die nie ins SharePoint gewandert sind.

Die Schmerzpunkte aus den ersten zwei Workshop-Tagen:

  • Onboarding eines neuen PM: 8 Wochen bis zur eigenständigen Projekt-Verantwortung, davon mindestens drei Wochen reine Wissens-Suche und Klärungs-Fragen.
  • Im internen Slack: durchschnittlich 47 "Wer weiß noch, wo X liegt?"-Anfragen pro Woche, die Senior-PMs band.
  • Suche eines konkreten Dokuments: Median 18 Minuten, Mittelwert höher, mit Long-Tail-Fällen über eine Stunde.
  • Drei dokumentierte Vorfälle 2024, in denen veraltete Versions- Stände eingesetzt wurden — mit echten Folgekosten im Gewerk.

Klassische Knowledge-Management-Initiativen (zentralisiere alles in ein neues System) waren in den Vorjahren zwei Mal versucht worden und beide Male versandet. Die Lehre: das System der Wahrheit muss dort bleiben, wo es ist. Die Suche muss querliegend funktionieren.

2. Lösung — RAG mit Permission-Spiegelung und harten Quellen-Zitaten

Die Architektur, die wir in acht Wochen gebaut haben, hatte explizit den Anspruch: kein neues Dokumenten-System, sondern eine Such- und Beantwortungs-Schicht über die bestehenden Quellen.

Vier Bausteine:

Connectors. Anbindung an Confluence (REST API), SharePoint (Graph API), Fileshare (über lokalen Indexer). Outlook wurde bewusst ausgespart — datenschutz-rechtlich grenzwertig und in der Praxis weniger relevant, als zunächst angenommen. Indexierung läuft inkrementell, Re-Index alle 24 Stunden mit Change-Detection.

Embedding und Vektor-DB. Dokumente werden in Chunks gesplittet, über ein deutsches Embedding-Modell (multilingual-e5-large, EU-gehostet) in Vektoren überführt, in einer Postgres-pgvector-DB abgelegt. Metadaten pro Chunk: Source-System, Source-Path, Permission-Tags, Last-Updated.

Permission-Layer. Das war der kritischste Baustein. Jede Quell-Permission (wer darf welche Confluence-Page sehen, welche SharePoint-Bibliothek, welchen Fileshare-Ordner) wird beim Indexing auf den Chunk übertragen. Bei jeder Suche wird der aktuelle Permission-Stand des suchenden Users gegen den Permission-Tag des Chunks geprüft — Suche und Antwort filtern auf Permission- Match. Praktisch bedeutet das: ein Junior-Vertriebler sieht in den Antworten nur, was er auch direkt im SharePoint sehen würde.

LLM-Schicht und Slack-Integration. Antwortgenerierung über Claude Sonnet (EU-Region, DPA-konform). Jede Antwort enthält Quellen-Links mit klickbarem Verweis auf das Ursprungs-Dokument. Slack-Bot als primäre UI — Anfrage als Slash-Command, Antwort als Threaded-Reply mit Quellen.

Kein Datenschutz-Vorfall in 4 Monaten

Permissions-Layer 1:1 auf Source-Permissions abgebildet — kein 'Anyone-with-the-link'-Bypass möglich, jede Anfrage prüft Live-Permissions, nicht Index-Stand

3. Umsetzung — acht Wochen, mit Fokus auf Permission-Sauberkeit

Das Projekt lief als Mid-Complexity-Sprint:

Wochen 1–2: Quellen-Audit und Permission-Mapping. Die brutalste Phase. Wir mussten verstehen, wie die Permissions in den drei Quell-Systemen tatsächlich gesetzt waren — und sie waren unterschiedlich gepflegt. Confluence: relativ sauber. SharePoint: gemischt, mit etwa 12 Prozent "geöffneter" Bibliotheken ohne klare Rollen-Logik. Fileshare: ein Chaos mit historischen NTFS-Permissions aus 2017. Die ersten zwei Wochen waren primär Bestandsaufnahme — und wir haben dem Kunden eindeutig empfohlen, das Fileshare-Permission-Modell vor dem RAG-Rollout aufzuräumen. Hat er gemacht. Das war eine der besten Vorab-Investitionen.

Wochen 3–5: Bau der Connectors und Embedding-Pipeline. Standard- Arbeit, drei Connectors, Embedding-Pipeline, Permission-Tagging pro Chunk. Hier war wichtig: jeder Chunk trägt mehrere Permission- Tags (Gruppen, Rollen, expliziter User), nicht einen einzigen "Public/Internal"-Flag.

Wochen 6–7: LLM-Schicht, Slack-Bot, Quellen-Zitierung. Prompt- Templates pro Rolle (PM, Bauleiter, Vertrieb haben unterschiedliche Frage-Muster und brauchen unterschiedliche Antwort-Tonalität). Hard- Constraint im Prompt: jede Antwort muss Quellen-Links enthalten, sonst antwortet der Bot mit "Ich habe dazu keine eindeutige Quelle, bitte direkt mit X klären".

Woche 8: Pilot, Permission-Stress-Test, Rollout. Drei Tage gezielter Permission-Test — ein "Junior-Vertriebler"-Account versuchte, an Geschäftsführungs-Inhalte zu kommen, ein "Buchhaltungs"-Account an Kundenakten. In beiden Fällen lieferte das System "keine Treffer" oder eskalierte. Go-Live: Januar 2026, mit Roll-Out auf alle 120 Mitarbeitende in zwei Wellen.

4. ROI nach 4 Monaten

Stand Mai 2026, gut vier Monate nach Go-Live:

  • Onboarding-Zeit neuer PMs: 8 → 3 Wochen (−63 Prozent). Gemessen an der Zeit bis zur ersten eigenverantwortlichen Projekt-Übernahme.
  • Slack-"Wer-weiß-was?"-Anfragen: −65 Prozent. Senior- PMs werden deutlich weniger unterbrochen.
  • Median-Suchzeit: von 18 min auf 90 Sekunden. Bei komplexen Fragen (Mehrfach-Quellen) ist die Suchzeit immer noch oft im Minuten-Bereich — aber mit ehrlichen Quellen-Verweisen statt "vermutlich liegt's hier".
  • Investment: €52.000 Implementierung, €1.400/Monat laufende Kosten (LLM-API, Postgres-Hosting, Connector-Maintenance).
  • Amortisation: rechnerisch 8 bis 10 Monate, primär über reduzierte Onboarding-Zeit und Senior-PM-Entlastung.
  • Datenschutz: kein Vorfall in vier Monaten. Quartals-Audit hat den Permission-Layer geprüft, keine Auffälligkeiten.

5. Was wir gelernt haben

Erstens: Permission-Spiegelung ist nicht optional. Wir hatten in einem früheren RAG-Projekt 2024 einen "Index alles, Permission später"-Ansatz versucht — das endete in einer panischen Korrektur- Schleife. Hier war Permission ab Tag 1 im Architektur-Diagramm. Das ist die Sicherung gegen Datenschutz-Vorfälle.

Zweitens: Quellen-Zitierung diszipliniert das Modell. Sobald jede Antwort mit klickbaren Quellen versehen sein muss, neigt das LLM weniger zur Halluzination — es zitiert lieber konservativ als zu erfinden. Nutzer-Feedback nach drei Monaten: Quellen- Links sind das meistgenutzte Feature, deutlich vor "Folgefragen- Vorschläge".

Drittens: Slack-UI schlägt Web-UI für interne Tools. Wir hatten parallel ein Web-Frontend gebaut. Nutzungs-Verhältnis nach drei Monaten: 87 Prozent Slack, 13 Prozent Web. Lehre: dorthin, wo die Leute eh sind, nicht in ein neues Browser-Tab.

Viertens: Re-Index-Frequenz braucht Augenmaß. Wir starteten mit stündlichem Re-Index, das war zu teuer und in den meisten Fällen unnötig. 24-Stunden-Re-Index mit manuellem Trigger für zeit-kritische Dokumente hat sich bewährt.

6. Was das für andere Mittelstand-Setups bedeutet

Aus diesem und vier weiteren RAG-Projekten 2025/26 lässt sich ein Muster ableiten:

  • RAG funktioniert für interne Wissens-Portale am verlässlichsten, wenn die Quell-Permissions bereits halbwegs sauber sind. Wenn nicht, gehört eine Permission-Bereinigung in den Projekt-Plan — entweder vorgelagert oder eng begleitend.
  • Die Wirkung steigt überproportional mit der Anzahl der angebundenen Quellen. Ein-Quellen-RAG ist meist nicht den Aufwand wert; ab drei Quellen wird's interessant.
  • Quellen-Zitierung ist die mit Abstand wirksamste Halluzinations- Bremse.
  • DSGVO-Sauberkeit ist kein Add-on, sondern Eintritts-Voraussetzung. Wer mit Public-LLMs ohne DPA und ohne EU-Hosting startet, kann die Compliance-Schicht später nicht "nachreichen".

Häufige Fragen

Was IT-Leiter und Geschäftsführer zu RAG-Wissensportalen fragen.

Wie ist der Permission-Layer technisch genau gelöst?
Jeder Chunk im Vektor-Index trägt eine Liste von Permission-Tags (Gruppen, Rollen, explizite User-IDs), abgeleitet aus der Quell-Permission zum Zeitpunkt der Indexierung. Bei jeder Suche werden zwei Dinge gemacht: erstens, der Identity-Token des suchenden Users wird gegen das aktive Identity-Provider-System (hier: Azure AD) verifiziert. Zweitens, die Suche filtert auf Chunks, deren Permission-Tags mit dem aktiven Group-Membership des Users matchen. Das passiert vor dem Embedding-Match, nicht danach — sonst leakt Information über die Antwort-Verteilung. Zusätzlich gibt es einen Live-Permission-Check vor jeder Antwort gegen die Quell-API, für Fälle, in denen Permissions kurzfristig entzogen wurden.
Was passiert, wenn die Quell-Permission falsch gesetzt ist?
Dann zeigt der RAG-Bot exakt das, was auch in der Quell-Anwendung zu sehen wäre. Das System repliziert die Permission, es korrigiert sie nicht. Genau deshalb war die Permission-Aufräum-Phase vor dem RAG-Rollout so wichtig. Wir empfehlen jedem Kunden ein laufendes Permission-Audit alle 6 Monate, mit Stichproben — das ist ohnehin DSGVO-Hygiene und schützt auch außerhalb des RAG-Kontexts.
Welches LLM wurde eingesetzt, und wie passt das zur DSGVO?
Claude Sonnet von Anthropic über die EU-Region (Frankfurt/Paris-Routing), mit unterzeichnetem Auftragsverarbeitungs-Vertrag, ohne Modell-Training auf Kundendaten. Embedding-Modell ist multilingual-e5-large, in einer EU-Region selbst gehostet. Alle Anfragen und Antworten werden geloggt (Aufbewahrung 90 Tage, dann automatisch gelöscht). Datenschutzbeauftragter hat das Setup vor Go-Live geprüft, eine DPIA wurde durchgeführt — kein Hochrisiko-Use-Case nach AI Act, da rein internes Wissens-Tool ohne automatische Entscheidungen über Personen.
Wie genau sieht die Quellen-Zitierung in der Antwort aus?
Jede Antwort enthält am Ende eine Liste von 1 bis 5 Quellen, jede mit Source-System (Confluence, SharePoint, Fileshare), Titel/Dateinamen, Last-Updated-Datum und klickbarem Direktlink. Im Slack-Bot sind die Links direkt anklickbar und führen den Nutzer ins Quell-System — wo dann nochmals die Live-Permission geprüft wird. Wenn das Modell sich auf eine Quelle nicht eindeutig stützen kann, weigert es sich (per Prompt-Constraint), eine konkrete Antwort zu geben, und verweist stattdessen auf manuelles Nachfragen.
Was, wenn das RAG-System trotzdem Daten leakt?
Wir haben drei Schutzebenen — und einen vierten Plan-B. Erstens: Permission-Filter vor dem Embedding-Match (hard filter). Zweitens: Live-Permission-Check vor Antwort-Ausgabe. Drittens: vollständiges Audit-Logging jeder Anfrage und Antwort für 90 Tage. Wenn trotz aller Maßnahmen ein Leak passiert — was in vier Monaten nicht der Fall war — gibt es einen dokumentierten Incident-Response-Workflow: Bot sofort offline schalten (Slack-Slash-Command vom IT-Lead), Logs analysieren, betroffene Daten und Personen identifizieren, Meldung an Datenschutzbehörde innerhalb 72 Stunden falls erforderlich. Diese Schritte sind in der internen Wissens-Policy festgeschrieben und wurden zum Go-Live einmal als Trockenübung durchgespielt.

Was als Nächstes?

Wenn du in einem mittelständischen Setup mit gewachsener Wissens- Landschaft sitzt und merkst, dass Onboarding und interne Such- Zeiten ein echter Engpass sind — der saubere Einstieg ist ein Audit M mit Fokus auf Quellen-Audit, Permission-Hygiene und Connector-Machbarkeit. Drei bis vier Wochen, klare Architektur- Empfehlung, ehrliche Aussage, welche Quellen ans Netz dürfen und welche erst aufgeräumt werden müssen. Discovery-Call dauert 30 Minuten und kostet nichts.

Mehr lesen.

Tactical

Dein erstes KI-Audit selbst durchführen — Template inkludiert (2026)

Sechs-Schritte-Worksheet für das KI-Self-Audit. Konkrete Fragen, Zeitschätzungen, Priorisierungs-Matrix. Für Geschäftsführer, die erst selbst schauen wollen.

Tactical

Wie du KI-Outputs systematisch testest — Eval-Frameworks für Production

Tech-Anleitung für Eval-Pipelines in Production: 4-Layer-Strategy mit deterministischen Tests, LLM-as-Judge, Golden-Datasets und Drift-Monitoring.

Strategie

EU AI Act 2026 — Was österreichische Unternehmen jetzt tun müssen

Konkreter Compliance-Leitfaden zum EU AI Act für Geschäftsführer in Österreich. Mit Risikoklassen, Strafen, Fristen und einer 12-Schritte-Checkliste.

Bereit für eine ehrliche Einschätzung?

Discovery-Call kostet 30 Minuten — und kann euer 2026 entscheiden.