Open Source Wissensmanagement im KI-Zeitalter aufbauen

Wer heute Wissensmanagement neu aufsetzt, steht vor zwei sich widersprechenden Anforderungen. Auf der einen Seite KI-Fähigkeit: Inhalte sollen von internen Agenten gefunden, zusammengefasst und in Workflows eingebettet werden. Auf der anderen Seite Datenhoheit: Sensible Wissensbasen gehören nicht in jede US-Cloud, schon gar nicht ungefiltert in proprietäre LLM-APIs. Open-Source-Komponenten lösen beide Anforderungen, wenn sie sauber kombiniert werden.

Dieser Artikel beschreibt einen pragmatischen Open-Source-Stack für KI-fähiges Wissensmanagement im Mittelstand. Komponenten sind erprobt, die Architektur ist DSGVO-tauglich, und die Investition skaliert mit der Reife der Organisation.

Warum Open Source jetzt der pragmatische Weg ist

Vor drei Jahren bedeutete KI-fähige Wissensbasis fast zwangsläufig: Inhalte in eine US-Cloud kippen, OpenAI-API anbinden, hoffen, dass die Datenschutz-Folgenabschätzung trägt. Heute ist diese Abhängigkeit nicht mehr nötig.

Vector-Datenbanken laufen lokal mit produktiver Reife. Wissens-Plattformen wie BookStack oder Outline bieten APIs, die in eigene Pipelines passen. Sprach-Modelle sind über Ollama oder vLLM auf eigener Hardware betreibbar. Die Lücke zwischen Frontier-Modellen und Open-Weight-Modellen ist klein genug, dass für viele interne Anwendungsfälle das Open-Source-Modell ausreicht. Wir haben den allgemeinen Trend in unserem Artikel zu Self-Hosted-Infrastruktur statt SaaS und in Open Source für KMU ausführlich eingeordnet.

Die vier Schichten eines pragmatischen Stacks

Ein produktionsreifer Open-Source-Stack besteht aus vier klar abgegrenzten Schichten.

Schicht eins: Die Wissens-Plattform. Hier leben die Inhalte. BookStack ist für die meisten Mittelständler eine pragmatische Wahl: PHP-Stack, einfaches Setup, klare Bücher-und-Kapitel-Struktur, API für Auto-Pflege. Outline ist die elegantere Alternative für Teams, die Notion-ähnlichen Komfort suchen. MediaWiki bleibt für sehr große Wissensbasen mit komplexen Berechtigungs-Strukturen relevant.

Schicht zwei: Der Embedding-Layer. Inhalte werden in Vektoren überführt, um semantisch durchsuchbar zu werden. Open-Source-Embedding-Modelle wie BGE-M3 oder jina-embeddings-v3 erreichen für Deutsch und Englisch produktive Qualität. Die Berechnung läuft auf eigener GPU oder in einer DSGVO-konformen Hetzner- oder OVH-Umgebung.

Schicht drei: Die Vector-Datenbank. Weaviate, Qdrant und Milvus sind die drei produktiven Optionen. Qdrant punktet mit Einfachheit und gutem Dokumentations-Stand, Weaviate mit reicher Filter-Logik, Milvus mit Skalierung in den hohen Millionen-Bereich. Für die meisten KMU-Wissensbasen reicht Qdrant.

Schicht vier: Die Reasoning-Schicht. Hier entscheidet die Antwort. Lokale LLMs über Ollama oder vLLM bedienen die meisten internen Anfragen. Wo höhere Reasoning-Tiefe nötig ist, kann ein Hybrid-Modell mit kontrolliertem Anruf zu einer EU-gehosteten Frontier-API funktionieren, sofern die Datenschutz-Folgenabschätzung trägt.

Konkrete Architektur in Beispiel-Form

Ein einfacher Aufbau für ein Unternehmen mit 50 bis 200 Mitarbeitenden:

wissensbasis:
  plattform: BookStack
  hosting: eigener Server oder Hetzner Cloud
  zugriff: SSO via Keycloak

embedding_pipeline:
  trigger: Webhook bei BookStack-Änderung
  modell: BGE-M3 (lokal über vLLM)
  chunking: 500 Tokens, 50 Overlap

vector_store:
  engine: Qdrant
  hosting: gleicher Server, separate Container
  backup: tägliches Snapshot in S3-kompatibles Storage

retrieval_augmented_generation:
  reasoning_modell: Llama 3.3 70B via Ollama
  kontext_layer: internes Glossar (YAML), Brand-Voice-Style-Guide
  fallback: kontrollierte EU-API für komplexe Anfragen

agenten_oberflaeche:
  protokoll: MCP
  clients: interne Web-UI, Mattermost-Bot, IDE-Plugin

Diese Architektur lässt sich mit einem kleinen Team innerhalb von vier bis acht Wochen produktiv setzen, abhängig von Ausgangslage und Daten-Volumen. Die zugrundeliegenden Glossar-Mechaniken bauen auf RAG-Systemen auf.

Was Open Source wirtschaftlich verändert

Drei Hebel machen den Stack rechnerisch attraktiv.

Lizenzkosten entfallen. Was in proprietären Knowledge-Lösungen pro Nutzer pro Monat anfällt, wird zur Hosting- und Betriebskosten-Frage. Bei 100 Nutzern liegt die Ersparnis schnell im fünfstelligen Bereich pro Jahr.

Datenhoheit wird zum strategischen Asset. Wer interne Wissensbasen auf eigener Infrastruktur hält, hat keine Datenschutz-Diskussionen mehr mit Rechtsabteilung oder Betriebsrat. Bei sensiblen Branchen wie Versicherung, Healthcare oder Public Sector ist diese Klarheit oft die Eintrittsbedingung.

Anpassbarkeit ohne Vendor-Anfragen. Wer einen neuen Workflow integrieren will, schreibt Code gegen offene APIs, statt Roadmap-Anfragen an einen Hersteller zu richten. Die Geschwindigkeit interner Innovation steigt deutlich.

Diese Argumente kennen wir aus der Cloud-Diskussion. Im Wissensmanagement greifen sie genauso, wie wir es im Beitrag zu OpenDesk als souveräner Arbeitsplatz für die Bürowelt beschrieben haben.

Ehrliche Grenzen

Drei Aspekte sollten in jeder Open-Source-Strategie offen benannt werden.

Erstens Betriebsaufwand. Eigener Stack heißt eigene Verantwortung für Updates, Backups, Monitoring, Security. Wer kein DevOps-Know-how im Haus hat, braucht entweder Schulung oder einen Partner.

Zweitens Reasoning-Tiefe. Open-Weight-Modelle haben in den letzten Quartalen massiv aufgeholt, aber Frontier-Modelle bleiben in komplexen Reasoning-Aufgaben oft führend. Für die meisten internen Wissens-Anfragen reicht das Open-Source-Modell, für Spezialfälle ist eine kontrollierte API-Brücke pragmatisch.

Drittens Tool-Reife im Fein-Tuning. Wer Modelle auf eigene Domäne trainieren will, betritt einen Bereich, der weniger ausgereift ist als der reine Inferenz-Stack. Hier lohnt sich eine ehrliche Aufwand-Nutzen-Rechnung, bevor das Projekt startet.

Eine englische Fassung dieses Artikels findet sich unter Open Source knowledge management in the AI era, die organisatorische Verantwortungs-Frage in Wikis nobody maintains.

Fazit

KI-fähiges Wissensmanagement ist kein Privileg von Großkonzernen mit eigenen Cloud-Verträgen mehr. Mit BookStack, Qdrant, Ollama und einem Glossar-Layer setzen Mittelständler heute Stacks auf, die DSGVO-konform sind, intern skalieren und Lizenzkosten gegen Hosting-Kosten tauschen. Die Entscheidung ist seltener technisch als organisatorisch: Wer übernimmt Betrieb, wer übernimmt Pflege, wer trägt die Verantwortung für Aktualität.

EverBright IT begleitet KMU beim Aufbau souveräner, KI-fähiger Wissensbasen mit Open-Source-Komponenten. Mehr zu unserer Cloud-Beratung oder direkt Kontakt aufnehmen.

Häufige Fragen

Welcher Open-Source-Stack passt für ein Unternehmen mit 50 Mitarbeitenden?

BookStack als Wissens-Plattform, Qdrant als Vector-Store, Llama 3.3 8B oder vergleichbar via Ollama als Reasoning-Schicht reichen für die meisten internen Anwendungsfälle. Hosting auf einem soliden Hetzner- oder OVH-Server, Backup in einen separaten Bucket. Initialer Aufbau zwischen 15 und 25 Personentagen, laufender Betrieb mit weniger als einem halben Tag pro Monat.

Reicht ein Open-Source-Modell für interne Anfragen wirklich aus?

Für die meisten Wissensbasis-Anfragen ja, vor allem wenn sauberes Retrieval mit Glossar-Anreicherung vorgeschaltet ist. Komplexe Reasoning-Aufgaben wie mehrstufige Schlussfolgerungen oder Code-Generierung profitieren weiterhin von Frontier-Modellen. Hybrid-Setups mit kontrollierter API-Brücke sind realistisch, sofern die Datenschutz-Bewertung trägt.

Wie geht man mit Updates und Sicherheit im Open-Source-Stack um?

Container-basierte Deployments mit klaren Versions-Tags, automatisierte Vulnerability-Scans und ein Update-Rhythmus von etwa zwei Wochen für Sicherheitspatches sind Standard. Wer interne DevOps-Kapazität nicht aufbauen will, beauftragt einen Partner für Betrieb. Beide Modelle funktionieren, die Disziplin ist wichtiger als die Wahl.

Wann lohnt sich der Wechsel von einer SaaS-Wissensbasis zu Open Source?

Zwei Auslöser dominieren. Erstens steigende Lizenzkosten ab etwa 50 bis 100 Nutzern, ab denen sich der Eigenbetrieb rechnerisch trägt. Zweitens regulatorische Anforderungen, bei denen Datenhoheit zur Pflicht wird. Wer beides nicht hat, kann in der bestehenden SaaS-Lösung bleiben und nur die KI-Schicht eigenständig betreiben.