--- title: "KI-fähiges Unternehmenswiki: Architektur und Aufbau" canonical: https://wavect.io/de/blog/ai-ready-company-wiki/ language: de description: "Baue ein KI-fähiges Unternehmenswiki für Menschen und Agenten. Architektur, Berechtigungen, RAG, MCP, Governance und ein 30-Tage-Pilot." image: "https://wavect.io/img/blog/headers/header_ai-ready-company-wiki.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 Min Lesezeit · 13. August 2026 Zuletzt geprüft 13. August 2026 [**Weiter**](/de/blog/linux-for-ai-agents/) # KI-fähiges Unternehmenswiki: Architektur und Aufbau TL;DR Ein KI-fähiges Unternehmenswiki ist eine gesteuerte Quelle für Organisationswissen, die Mitarbeitende bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts- und Aktualitätssignalen abrufen können. Trenne kanonische, menschenlesbare Konzepte von neu aufbaubaren Stichwort-, Vektor- und Graphindizes. Erzwinge Quellberechtigungen vor dem Retrieval, liefere Belege mit jeder Antwort und lass Agenten geprüfte Diffs vorschlagen, statt direkt zu veröffentlichen. Starte mit einem wertvollen Workflow, 25 echten Fragen und 30 bis 50 kuratierten Konzepten. Skaliere nur, wenn ein Blindtest belegte Korrektheit, Antwortzeit oder Review-Aufwand verbessert, ohne Berechtigungsfehler zu erzeugen. **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](/de/blog/open-knowledge-format-okf/) erklärt das Austauschformat, der [OpenKB-Test](/de/blog/openkb-review-vs-rag/) bewertet einen Knowledge Compiler und die [RAG-Production-Readiness-Checkliste](/de/blog/rag-production-readiness-checklist-eu/) 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. | Signal | Gewöhnliches Unternehmenswiki | KI-fähiges Unternehmenswiki | | --- | --- | --- | | Quelle der Wahrheit | Seiten, Ordner und Anhänge | Kanonische Konzepte mit stabilen IDs und Quellenlinks | | Vertrauen | Lesende leiten Autorität aus der Seite ab | Owner, Quelle, Prüfstatus und Review-Datum sind explizit | | Aktualität | "Zuletzt bearbeitet" ohne Regel | Prüfintervall, veralteter Status und Nachfolger | | Berechtigungen | In der Wiki-Oberfläche geprüft | Beim Retrieval und Agentenzugriff erneut durchgesetzt | | Discovery | Navigation und Stichwortsuche | Navigation, Suche, Retrieval und Beziehungstraversierung | | Agenten schreiben | Oft unbeschränkt oder gar nicht möglich | Entwurf, Diff, Reviewer und Audit Trail | | Qualität | Feedback und Seitenaufrufe | Belegte Fragen, Retrieval-Tests und Arbeitsergebnisse | ## 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](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) 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: | Modell | Geeignet für | Wichtigster Trade-off | | --- | --- | --- | | Bestehendes Wiki bleibt kanonisch | Teams mit guter Nutzung und belastbaren APIs | Schnellster Pilot, aber Metadaten und Portabilität hängen von der Plattform ab | | Git-basiertes Markdown wird kanonisch | Technische Teams, die Diffs, Reviews und Portabilität schätzen | Stark für Agenten und Governance, aber Fachbereiche brauchen eine angenehme Oberfläche | | Kuratierte Wissensschicht spiegelt freigegebene Quellen | Organisationen mit vielen Systemen und gemischten Berechtigungen | Saubere Trennung von Beleg und Antwort, aber Synchronisierung und Ownership müssen betrieben werden | 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. | Methode | Geeignet für | Erwarte nicht, dass sie | | --- | --- | --- | | Hierarchie und Links | Schrittweise Navigation, Handbücher und bekannte Domänen | Jede umformulierte Frage findet | | Stichwortsuche | Namen, Fehlercodes, Richtliniennummern und exakte Begriffe | Vage oder konzeptionelle Fragen auflöst | | Vektor- oder Hybrid-RAG | Natürlichsprachliche Fragen über größere Bestände | Governance liefert oder die richtige Quelle garantiert | | Knowledge Graph | Ownership, Abhängigkeiten, Ausnahmen und mehrstufige Beziehungen | Seine Kosten bei einfacher Dokumentsuche rechtfertigt | | MCP-Ressource oder Tool | Standardisierten Agentenzugriff auf freigegebene Suche und Leseoperationen | Wissensspeicher oder Zugriffsregel ersetzt | Die Evaluation muss unordentliche Nutzersprache enthalten. Google Clouds Beitrag zur [Evaluation von Agenten-Discovery](https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance) 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](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) 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](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) 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](https://developers.cloudflare.com/reference-architecture/diagrams/ai/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](/de/blog/internal-ai-assistant-cost-dach/) zeigt, warum Inhaltsaufbereitung, Berechtigungen, Evaluation und Wartung oft wichtiger sind als die Modellrechnung. ## Solltest du bauen, kaufen oder erweitern? | Entscheidung | Wähle sie, wenn | Frage vor der Unterschrift | | --- | --- | --- | | Bestehendes Wiki erweitern | Nutzung, APIs, Berechtigungen und Reviews bereits funktionieren | Bewahrt Retrieval Seiten- und Anhangsberechtigungen für jeden Nutzer? | | KI-Wissensplattform kaufen | Standard-Connectoren und Mitarbeiter-Q&A den Großteil abdecken | Kannst du kanonische Inhalte, Metadaten, Belege und Audit Logs exportieren? | | Gesteuerte Wissensschicht bauen | Der Workflow Systeme, Sonderberechtigungen oder produktnahe Agenten umfasst | Wer besitzt Synchronisierung, Evaluation, Incidents und laufende Reviews? | | Hybrid nutzen | Menschen einen vertrauten Editor und Agenten portablen, getesteten Kontext brauchen | Welches System ist pro Konzept kanonisch, und wie werden Konflikte sichtbar? | 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. ## Häufig gestellte Fragen ### Was ist ein KI-fähiges Unternehmenswiki? Es ist eine gesteuerte Quelle für Organisationswissen, die Mitarbeitende bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts-, Ownership- und Aktualitätssignalen abrufen können. Kanonische Inhalte bleiben von neu aufbaubaren Such- und Vektorindizes getrennt. ### Braucht ein KI-fähiges Wiki RAG? Nein. Kleine, gut verlinkte Bestände können mit Hierarchie und Stichwortsuche funktionieren. RAG hilft bei natürlichsprachlichem Retrieval über größere Sammlungen, braucht aber weiterhin Quellberechtigungen, Belege, Evaluation und Content Governance. ### Ist MCP die Wissensbasis des Unternehmens? Nein. MCP kann Agenten einen standardisierten Zugriff auf freigegebene Such- und Leseressourcen geben. Quelle der Wahrheit, Berechtigungen, Retrieval-Logik und Review-Workflow liegen hinter dieser Schnittstelle. ### Dürfen KI-Agenten das Wiki automatisch aktualisieren? Sie können Änderungen vorschlagen. Der sichere Standard ist ein Entwurf oder Diff mit Quellen und benanntem Reviewer. Freigegebene Änderungen werden danach kanonisch veröffentlicht und lösen einen Index-Neuaufbau aus. ### Wie verhindern wir den Abfluss vertraulicher Informationen? Übernimm Klassifizierung und Berechtigungen der Quelle in die Retrieval-Schicht, authentifiziere jeden Request, filtere vor dem Abruf, validiere Quellen, trenne Mandanten und protokolliere Policy-Entscheidungen. Der Modellprompt darf nie die Zugriffskontrolle sein. ### Wie sollte ein Unternehmen starten? Wähle einen wertvollen Workflow, sammle 25 echte Fragen und kuratiere 30 bis 50 Konzepte. Vergleiche den Pilot mit dem bisherigen Prozess und skaliere nur bei besserer Korrektheit, Antwortzeit oder geringerem Review-Aufwand ohne Berechtigungsfehler. ## Fazit Das beste KI-fähige Unternehmenswiki hat nicht die meisten Dokumente. Es ist das kleinste gesteuerte Wissenssystem, das einen wertvollen Fragensatz für Mitarbeitende und Agenten mit denselben Belegen, Zugriffsregeln und Review-Schleifen beantwortet. Halte die Quelle menschenlesbar, behandle Indizes als ersetzbar, mache Autorisierung zum Teil des Retrievals und lass Agenten vor dem Veröffentlichen Vorschläge liefern. Diese Architektur überlebt Modellwechsel und gibt dem Unternehmen mehr als einen weiteren Chatbot: ein operatives Gedächtnis, das es prüfen und verbessern kann. ## Das könnte dich auch interessieren.. [**Open Knowledge Format: Der Enterprise-Leitfaden** So verpackt OKF v0.2 portables, menschenlesbares Wissen mit Herkunfts-, Vertrauens- und Aktualitätssignalen.](/de/blog/open-knowledge-format-okf/) [**AI Enablement vs. allgemeine KI-Beratung** Vergleiche messbare Umsetzung auf deiner Infrastruktur mit einem reinen Strategieprojekt.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [LiteLLM selbst hosten: Production-Guide 2026](/de/blog/self-host-litellm-production-2026/) - [Versieht Claude Texte mit Wasserzeichen? API-Antwort 2026](/de/blog/claude-text-watermark-api-2026/) - [OpenKB Review: Knowledge Compiler vs. RAG](/de/blog/openkb-review-vs-rag/) - [Unsloth Desktop im Test: Private lokale KI-Workstation?](/de/blog/unsloth-desktop-local-ai-workstation-review/) - [NeMo Switchyard 0.2: Agenten-Routing ohne Training?](/de/blog/nemo-switchyard-model-router/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 Min Lesezeit · 13. August 2026 Zuletzt geprüft 13. August 2026 [**Weiter**](/de/blog/linux-for-ai-agents/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/ai-ready-company-wiki/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/de/blog/ai-ready-company-wiki/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Ein KI-fähiges Unternehmenswiki ist eine gesteuerte Quelle für Organisationswissen, die Mitarbeitende bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts- und Aktualitätssignalen abrufen können. Trenne kanonische, menschenlesbare Konzepte von neu aufbaubaren Stichwort-, Vektor- und Graphindizes. Erzwinge Quellberechtigungen vor dem Retrieval, liefere Belege mit jeder Antwort und lass Agenten geprüfte Diffs vorschlagen, statt direkt zu veröffentlichen. Starte mit einem wertvollen Workflow, 25 echten Fragen und 30 bis 50 kuratierten Konzepten. Skaliere nur, wenn ein Blindtest belegte Korrektheit, Antwortzeit oder Review-Aufwand verbessert, ohne Berechtigungsfehler zu erzeugen.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur KI-fähiges Unternehmenswiki: Architektur und Aufbau TL;DR Ein KI-fähiges Unternehmenswiki ist eine gesteuerte Quelle für Organisationswissen, die Mitarbeitende bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts- und Aktualitätssignalen abrufen können. Trenne kanonische, menschenlesbare Konzepte von neu aufbaubaren Stichwort-, Vektor- und Graphindizes. Erzwinge Quellberechtigungen vor dem Retrieval, liefere Belege mit jeder Antwort und lass Agenten geprüfte Diffs vorschlagen, statt direkt zu veröffentlichen. Starte mit einem wertvollen Workflow, 25 echten Fragen und 30 bis 50 kuratierten Konzepten. Skaliere nur, wenn ein Blindtest belegte Korrektheit, Antwortzeit oder Review-Aufwand verbessert, ohne Berechtigungsfehler zu erzeugen. 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. SignalGewöhnliches UnternehmenswikiKI-fähiges Unternehmenswiki Quelle der WahrheitSeiten, Ordner und AnhängeKanonische Konzepte mit stabilen IDs und Quellenlinks VertrauenLesende leiten Autorität aus der Seite abOwner, Quelle, Prüfstatus und Review-Datum sind explizit Aktualität\"Zuletzt bearbeitet\" ohne RegelPrüfintervall, veralteter Status und Nachfolger BerechtigungenIn der Wiki-Oberfläche geprüftBeim Retrieval und Agentenzugriff erneut durchgesetzt DiscoveryNavigation und StichwortsucheNavigation, Suche, Retrieval und Beziehungstraversierung Agenten schreibenOft unbeschränkt oder gar nicht möglichEntwurf, Diff, Reviewer und Audit Trail QualitätFeedback und SeitenaufrufeBelegte Fragen, Retrieval-Tests und Arbeitsergebnisse 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. Quellsysteme. Bestehende Wiki-Seiten, Richtlinien, Tickets, Repositories, Datenbanken und freigegebene Gespräche bleiben Belege, kein ungefilterter Datensumpf. Kanonisches Wissen. Dauerhafte Konzepte wie Preisregel, Incident-Playbook oder Kundendefinition erhalten stabile IDs, Owner, Quellen und Lebenszyklus-Metadaten. Governance Control Plane. Klassifizierung, Zugriffsregel, Review-Datum, Freigabe, Aufbewahrung und Audit-Daten reisen mit dem Konzept. Abgeleitete Indizes. Stichwort-, Vektor- und Graphindizes sind neu aufbaubare Projektionen. Sie sind nie die einzige Wissenskopie. Auslieferung. Eine berechtigungsfähige API oder ein MCP-Server liefert den kleinsten relevanten Kontext und verweist auf die kanonische Quelle. 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: ModellGeeignet fürWichtigster Trade-off Bestehendes Wiki bleibt kanonischTeams mit guter Nutzung und belastbaren APIsSchnellster Pilot, aber Metadaten und Portabilität hängen von der Plattform ab Git-basiertes Markdown wird kanonischTechnische Teams, die Diffs, Reviews und Portabilität schätzenStark für Agenten und Governance, aber Fachbereiche brauchen eine angenehme Oberfläche Kuratierte Wissensschicht spiegelt freigegebene QuellenOrganisationen mit vielen Systemen und gemischten BerechtigungenSaubere", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Open-Knowledge-Format-v0.2-Spezifikation", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md" }, { "@type": "WebPage", "name": "Evaluation von Agenten-Discovery", "url": "https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance" }, { "@type": "WebPage", "name": "OWASP-Empfehlungen zu Vektor- und Embedding-Schwächen", "url": "https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/" }, { "@type": "WebPage", "name": "MCP-Sicherheitsanleitung", "url": "https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices" }, { "@type": "WebPage", "name": "Referenzarchitektur für einen Enterprise AI Agent Workspace", "url": "https://developers.cloudflare.com/reference-architecture/diagrams/ai/enterprise-ai-agent-workspace/" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "Ein KI-fähiges Unternehmenswiki ist eine gesteuerte Quelle für Organisationswissen, die Mitarbeitende bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts- und Aktualitätssignalen abrufen können. Trenne kanonische, menschenlesbare Konzepte von neu aufbaubaren Stichwort-, Vektor- und Graphindizes. Erzwinge Quellberechtigungen vor dem Retrieval, liefere Belege mit jeder Antwort und lass Agenten geprüfte Diffs vorschlagen, statt direkt zu veröffentlichen. Starte mit einem wertvollen Workflow, 25 echten Fragen und 30 bis 50 kuratierten Konzepten. Skaliere nur, wenn ein Blindtest belegte Korrektheit, Antwortzeit oder Review-Aufwand verbessert, ohne Berechtigungsfehler zu erzeugen.", "headline": "KI-fähiges Unternehmenswiki: Architektur und Aufbau", "image": "https://wavect.io/img/blog/headers/header_ai-ready-company-wiki.svg", "inLanguage": "de", "keywords": "KI-Agenten, Wissensmanagement", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/ai-ready-company-wiki/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/ai-ready-company-wiki/", "wordCount": 1993 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/ai-ready-company-wiki/", "name": "KI-fähiges Unternehmenswiki: Architektur und Aufbau | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Es ist eine gesteuerte Quelle für Organisationswissen, die Mitarbeitende bearbeiten und KI-Agenten mit denselben Berechtigungen, Herkunfts-, Ownership- und Aktualitätssignalen abrufen können. Kanonische Inhalte bleiben von neu aufbaubaren Such- und Vektorindizes getrennt." }, "name": "Was ist ein KI-fähiges Unternehmenswiki?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Kleine, gut verlinkte Bestände können mit Hierarchie und Stichwortsuche funktionieren. RAG hilft bei natürlichsprachlichem Retrieval über größere Sammlungen, braucht aber weiterhin Quellberechtigungen, Belege, Evaluation und Content Governance." }, "name": "Braucht ein KI-fähiges Wiki RAG?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. MCP kann Agenten einen standardisierten Zugriff auf freigegebene Such- und Leseressourcen geben. Quelle der Wahrheit, Berechtigungen, Retrieval-Logik und Review-Workflow liegen hinter dieser Schnittstelle." }, "name": "Ist MCP die Wissensbasis des Unternehmens?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Sie können Änderungen vorschlagen. Der sichere Standard ist ein Entwurf oder Diff mit Quellen und benanntem Reviewer. Freigegebene Änderungen werden danach kanonisch veröffentlicht und lösen einen Index-Neuaufbau aus." }, "name": "Dürfen KI-Agenten das Wiki automatisch aktualisieren?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Übernimm Klassifizierung und Berechtigungen der Quelle in die Retrieval-Schicht, authentifiziere jeden Request, filtere vor dem Abruf, validiere Quellen, trenne Mandanten und protokolliere Policy-Entscheidungen. Der Modellprompt darf nie die Zugriffskontrolle sein." }, "name": "Wie verhindern wir den Abfluss vertraulicher Informationen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Wähle einen wertvollen Workflow, sammle 25 echte Fragen und kuratiere 30 bis 50 Konzepte. Vergleiche den Pilot mit dem bisherigen Prozess und skaliere nur bei besserer Korrektheit, Antwortzeit oder geringerem Review-Aufwand ohne Berechtigungsfehler." }, "name": "Wie sollte ein Unternehmen starten?" } ] } ```