Wissen verteilt auf E-Mails, Wiki und PDFs
Neue Mitarbeitende brauchen Wochen, um relevante interne Informationen zu finden. Wiederkehrende Fragen landen im Support, weil Antworten vorhanden, aber nicht auffindbar sind.
FIKTIVES BEISPIELPROJEKT · KEIN ECHTER KUNDE
So würde bei uns ein interner Wissensassistent entstehen.
Kein Kundenprojekt, kein Referenzlogo – sondern die reale BAIS-Methodik aus dem Projektablauf, Schritt für Schritt an einem erfundenen Beispiel durchgespielt. So sehen Sie, was tatsächlich passiert, bevor ein echtes Projekt beginnt.
EVIDENCE POLICY
Fiktives Beispiel, echte Methodik.
Firma, Personen, Zitate und Zahlen auf dieser Seite sind erfunden und dienen ausschließlich der Illustration. Es handelt sich nicht um ein beauftragtes Kundenprojekt und nicht um ein Leistungsversprechen für ein bestimmtes Ergebnis. Echte Kundenreferenzen veröffentlicht BAIS ausschließlich nach realer Umsetzung und ausdrücklicher Freigabe – siehe Demos & Referenzarchitekturen.
AUSGANGSLAGE (FIKTIV)
Eine erfundene Ausgangslage.
Wir nennen sie hier „Beispiel GmbH" – rund 120 Mitarbeitende, verteiltes Wissen, kein echtes Unternehmen.
Quellenbasierter interner Assistent
Ein Assistent, der Fragen zu freigegebenen internen Dokumenten beantwortet – mit nachvollziehbarer Quelle, Rollen- und Zugriffskontrolle, und ohne erfundene Antworten.
Was bewusst ausgeschlossen ist
Keine automatische Entscheidungsfindung, kein Zugriff auf besonders schützenswerte Personaldaten, keine externe Veröffentlichung von Antworten ohne Review.
ABLAUF
Die fünf Schritte aus dem Projektablauf – angewendet.
Dieselbe Struktur wie bei jedem BAIS-Projekt: jeder Schritt hat einen Owner, ein Ergebnis und ein Review.
1 · DiscoveryWorkshop mit Fachbereich und IT: welche Dokumente zählen, wer sie besitzt, wie sensibel sie sind. Erfolgskriterium: jede Testfrage bekommt entweder eine belegte Antwort oder ein ehrliches „nicht auffindbar".
2 · ArchitectureEntscheidung für eine RAG-Architektur mit EU-gehostetem Modell, Dokumenten-Ingestion-Pipeline, Rollen-zu-Zugriff-Mapping und klaren Sicherheitsgrenzen zwischen Assistent und Quellsystemen.
3 · BuildIngestion eines ersten Testdokumentensatzes, Aufbau von Retrieval und Zitatanzeige, iteratives Testen gegen eine Liste realistischer Fragen, Review-Gate vor jeder Erweiterung.
4 · AcceptanceAbnahme-Session mit Fachbereich: Testprotokoll wird gemeinsam durchgegangen, offene Risiken (z. B. Verzögerung bei sehr neuen Dokumenten bis zum nächtlichen Reindex) dokumentiert, Freigabe erteilt.
5 · HandoverRunbook für das Hinzufügen neuer Dokumentquellen, Monitoring-Einrichtung, definierte Supportgrenze zwischen BAIS und interner IT, kurze Schulung für die Admin-Rolle.
DELIVERABLES
Was am Ende übergeben würde.
Dieselben Artefakte wie bei jedem BAIS-Projekt – hier auf das Beispiel bezogen.
Scope Canvas
Dokumentierte Ziele, Nicht-Ziele, Datenarten, Rollen und die vereinbarten Erfolgskriterien für den Assistenten.
Architektur & Testprotokoll
Komponentenübersicht, Ingestion-Pipeline, Konfiguration und die Ergebnisse der Testfragen mit Quellenabgleich.
Security Review
Zugriffskonzept, Datenflüsse zwischen Assistent und Quellsystemen, geprüfte und dokumentierte Restrisiken.
Handover Package
Runbook für neue Dokumentquellen, Monitoring, Ansprechpersonen und die vereinbarte Supportgrenze.
EINORDNUNG
Ihr Vorhaben sieht anders aus?
Das ist der Normalfall – jedes echte Vorhaben hat andere Daten, Systeme, Risiken und Zeitrahmen. Dieses Beispiel zeigt die Methodik, nicht ein fertiges Angebot. Der erste echte Schritt ist immer ein Discovery-Gespräch.