KI-fähiges Unternehmenswiki: Architektur und Aufbau

Ein KI-fähiges Unternehmenswiki ist eine gesteuerte Quelle für Organisationswissen, die Menschen bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts- und Aktualitätssignalen abrufen können. Es ist kein Chatbot vor einem Ordner. Das brauchbare System trennt kanonisches Wissen, abgeleitete Indizes, Zugriffskontrolle, Agentenzugriff und menschliche Prüfung.

Dieser Leitfaden beantwortet die Umsetzungsfrage: Wie entwirfst und beschaffst du dieses System? Unser Leitfaden zum Open Knowledge Format erklärt das Austauschformat, der OpenKB-Test bewertet einen Knowledge Compiler und die RAG-Production-Readiness-Checkliste behandelt Retrieval-Qualität. Hier verbinden wir diese Schichten zu einem unternehmensweiten Betriebsmodell.

Was macht ein Unternehmenswiki KI-fähig?

Ein Wiki wird KI-fähig, wenn dieselbe Antwort für einen Menschen und einen Agenten auffindbar, freigegeben, belegbar, aktuell und testbar ist. Semantische Suche verbessert das Finden. Sie schafft aber nicht automatisch Verantwortlichkeit, löst keine Widersprüche und bewahrt Dokumentberechtigungen nicht von selbst.

Welche Architektur funktioniert für Menschen und KI-Agenten?

Das belastbare Muster ist ein Wissenssystem mit sechs Schichten. Jede Schicht hat eine Aufgabe. So kannst du Suchmaschine oder Modell austauschen, ohne die Quelle der Wahrheit umzuziehen.

1. Quellsysteme. Bestehende Wiki-Seiten, Richtlinien, Tickets, Repositories, Datenbanken und freigegebene Gespräche bleiben Belege, kein ungefilterter Datensumpf.
2. Kanonisches Wissen. Dauerhafte Konzepte wie Preisregel, Incident-Playbook oder Kundendefinition erhalten stabile IDs, Owner, Quellen und Lebenszyklus-Metadaten.
3. Governance Control Plane. Klassifizierung, Zugriffsregel, Review-Datum, Freigabe, Aufbewahrung und Audit-Daten reisen mit dem Konzept.
4. Abgeleitete Indizes. Stichwort-, Vektor- und Graphindizes sind neu aufbaubare Projektionen. Sie sind nie die einzige Wissenskopie.
5. Auslieferung. Eine berechtigungsfähige API oder ein MCP-Server liefert den kleinsten relevanten Kontext und verweist auf die kanonische Quelle.
6. Oberflächen. Mitarbeitende lesen und bearbeiten ein Wiki; Assistenten beantworten Fragen; Agenten laden Kontext für eng begrenzte Aufgaben.

Googles Open-Knowledge-Format-v0.2-Spezifikation passt in die kanonische Schicht. Sie hält Konzepte in menschenlesbarem Markdown und ergänzt optionale Felder für Herkunft, Prüfung, Lebenszyklus und Aktualität. Retrieval, Berechtigungen und Laufzeitzugriff definiert sie nicht. Deshalb bleiben die anderen Schichten nötig.

Solltest du dein bestehendes Wiki ersetzen?

Am Anfang meistens nicht. Behandle das aktuelle Wiki als Autorenoberfläche oder Belegquelle. Baue dann eine gesteuerte Wissensschicht um einen wertvollen Arbeitsablauf. Wer vor dem Nachweis guter Retrieval-Qualität jede Seite migriert, startet ein Migrationsprojekt ohne bewiesenen Geschäftswert.

Drei Modelle für die Quelle der Wahrheit sind tragfähig:

Ein guter Pilot beginnt mit 30 bis 50 wertvollen Konzepten. Importiere nicht das ganze Firmenlaufwerk. Starte mit den Fragen, die Onboarding, Support, Vertrieb oder Incident Response verzögern, und mit den Belegen, die sie beantworten.

Wie sollen Agenten Unternehmenswissen abrufen?

Keine Retrieval-Methode gewinnt bei jeder Frage. Nutze die günstigste Methode, die Bedeutung und Belege zuverlässig bewahrt.

Die Evaluation muss unordentliche Nutzersprache enthalten. Google Clouds Beitrag zur Evaluation von Agenten-Discovery beschreibt Retrieval als Nadel-im-Heuhaufen-Problem und fragt, wie vage eine Frage werden darf, bevor Discovery scheitert. Teste im Unternehmenswiki Abkürzungen, alte Namen, unvollständige Fragen und widersprüchliche Quellen, nicht nur polierte Prompts des Projektteams.

Wie bleiben Berechtigungen und Agentenänderungen sicher?

Die Berechtigungsprüfung gehört in den Retrieval-Pfad. Eingeschränkte Dokumente in einen gemeinsamen Vektorindex zu kopieren und erst nach der Generierung zu filtern, ist zu spät. Jede Suche und jeder Lesezugriff muss die Identität des Aufrufers ableiten, mit den Quellberechtigungen schneiden und nur freigegebene Konzepte zurückgeben.

Die OWASP-Empfehlungen zu Vektor- und Embedding-Schwächen nennen Kontextlecks, vergiftetes Wissen und schwache Zugriffskontrollen als konkrete RAG-Risiken. Zu den Gegenmaßnahmen gehören berechtigungsfähige Speicher, Validierung vertrauenswürdiger Quellen, Klassifizierung und Retrieval-Logging.

Wird das Wiki über MCP bereitgestellt, bleiben Authentifizierung und Autorisierung an dieser Grenze. Die aktuelle MCP-Sicherheitsanleitung verlangt die Prüfung eingehender Requests und verbietet Token-Passthrough, weil es Kontrollen umgehen und Nachvollziehbarkeit zerstören kann. Eine Suchergebnis-ID oder ein State Handle beweist nicht, dass jemand die dahinterliegende Seite lesen darf.

Starte beim Schreiben asymmetrisch:

• Menschen veröffentlichen, Agenten schlagen vor. Agenten erstellen Entwürfe oder Patches mit Quellen und Begründung.
• Reviewer akzeptieren ein Diff. Kritische Konzepte wie Preise, Rechtsrichtlinien und Production-Runbooks brauchen benannte Owner.
• Indizes werden nach Freigabe neu gebaut. Abgelehnter oder ungeprüfter Agentenoutput wird nie vertrauenswürdiger Retrieval-Kontext.
• Jede Antwort bleibt nachvollziehbar. Protokolliere Frage, abgerufene Konzept-IDs, Policy-Entscheidung, Antwort und Feedback, aber keine Secrets.

Cloudflares aktuelle Referenzarchitektur für einen Enterprise AI Agent Workspace verwendet dieselbe Trennung: gemeinsamer Organisationskontext wird zentral in einer versionierten, nur lesbaren Bibliothek veröffentlicht. Modellzugriff, Tools, Zugangsdaten und Ausführung bleiben außerhalb des Workspaces gesteuert.

Was gehört in jedes Wissenskonzept?

Ein Konzept soll eine dauerhafte Frage beantworten und genug Metadaten offenlegen, damit ein System seine sichere Nutzbarkeit vor dem Lesen des ganzen Inhalts beurteilen kann.

---
type: Policy
title: Eskalation bei Production Incidents
owner: team:platform
status: stable
classification: internal
generated: { by: human:platform-lead, at: 2026-08-13T09:00:00Z }
verified: { by: human:security-owner, at: 2026-08-13T11:00:00Z }
stale_after: 2026-11-13
sources:
  - id: incident-policy
    resource: https://intranet.example/policies/incidents
---

# Entscheidung

Bei einem bestätigten Severity-One-Ereignis wird der Incident Commander gerufen.

# Ausnahmen

Kundenseitig betriebene Deployments folgen dem vertragsspezifischen Runbook.

# Ablauf

1. Incident Channel öffnen.
2. Belege und Startzeit erfassen.
3. Verantwortlichen Owner rufen.

Frontmatter ersetzt keine klare Sprache. Es erlaubt Menschen, deterministischen Filtern und Agenten, ein veraltetes, abgelöstes oder nicht freigegebenes Konzept abzulehnen, bevor Zeit und Modellkontext verbraucht werden.

Wie sieht ein 30-Tage-Pilot aus?

1. Tag 1 bis 3, Workflow wählen. Nimm einen teuren Pfad wie Developer-Onboarding, Support-Eskalation oder Incident-Diagnose. Definiere Owner und Erfolgsmetrik.
2. Tag 4 bis 7, Fragenset erstellen. Sammle 25 echte Fragen, erwartete Antworten, freigegebene Quellen, berechtigte Rollen und Ablehnungsfälle.
3. Tag 8 bis 14, Wissensausschnitt kuratieren. Normalisiere 30 bis 50 Konzepte, ordne Owner zu, entferne Duplikate und erfasse Widersprüche, statt sie still zu verschmelzen.
4. Tag 15 bis 20, Retrieval und Zugriff bauen. Vergleiche Stichwort- und Hybrid-Retrieval, erzwinge Quellberechtigungen vor dem Abruf und gib mit jeder Antwort Quellenlinks zurück.
5. Tag 21 bis 25, beide Oberflächen ergänzen. Menschen können Inhalte lesen und korrigieren; ein freigegebener Agent darf über eine schmale API oder MCP-Oberfläche suchen und lesen.
6. Tag 26 bis 30, Blindtest durchführen. Miss belegte Korrektheit, Retrieval Recall, Qualität der Ablehnungen, mediane Antwortzeit, Review-Aufwand und Berechtigungsfehler gegen den bisherigen Prozess.

Skaliere nur, wenn der Pilot ein Geschäftsergebnis verbessert, ohne Zugriffskontrollen zu schwächen oder eine unbetreute Inhaltswarteschlange aufzubauen. Unser Kostenmodell für interne KI-Assistenten in DACH zeigt, warum Inhaltsaufbereitung, Berechtigungen, Evaluation und Wartung oft wichtiger sind als die Modellrechnung.

Solltest du bauen, kaufen oder erweitern?

Eine Herstellerdemo darf diese Entscheidung nicht treffen. Verlange Export, Berechtigungstest und Blindtest mit deinen Fragen. Kann das System nicht zeigen, warum eine Antwort abgerufen wurde, wer sie sehen darf und wann ihre Quelle zuletzt geprüft wurde, eignet es sich nicht als Unternehmensgedächtnis.

Abnahmekriterien für ein KI-fähiges Unternehmenswiki

1. Ein benannter Owner für jedes kritische Konzept.
2. Stabile IDs und sichtbare Links zu freigegebenen Quellen.
3. Expliziter Status, Prüfzustand und Review-Datum.
4. Quellberechtigungen werden vor dem Retrieval durchgesetzt.
5. Kanonische Inhalte und neu aufbaubare Suchindizes sind getrennt.
6. Antworten zitieren die tatsächlich abgerufenen Konzepte.
7. Agenten schlagen Änderungen als prüfbare Entwürfe oder Diffs vor.
8. Widersprüche und veraltetes Wissen werden gezeigt, nicht vermischt.
9. Ein fixes Evaluationsset deckt vage Fragen, Ablehnungen und Zugriffsgrenzen ab.
10. Inhaltsexport, Audit Logs und Modellportabilität sind vor dem Rollout getestet.