Technische Doku automatisieren: KI im Knowledge Management

Technische Dokumentation zu automatisieren ist kein Tool-Problem mehr, sondern eine Architektur-Frage. LLMs schreiben brauchbare Entwürfe, Embeddings erkennen veraltete Passagen, Agenten prüfen Anleitungen gegen die laufende Software. Trotzdem veraltet Doku in vielen Unternehmen so schnell wie vor zehn Jahren, weil die einzelnen Bausteine unverbunden nebeneinander laufen. Dieser Artikel ordnet die Ebenen der Doku-Automatisierung, verbindet sie zu einer Pipeline-Architektur und zeigt, wo Menschen unverzichtbar bleiben.

Warum Doku-Pflege im klassischen Modell scheitert

Der Befund ist in fast jedem Unternehmen derselbe: Die Dokumentation entsteht mit Schwung zum Projektstart und altert danach im Stillen. Verantwortlich ist selten das Werkzeug. In Wikis, die niemand pflegt haben wir gezeigt, dass Knowledge Bases fast immer am fehlenden Ownership scheitern, nicht an Confluence, Notion oder SharePoint.

Die Kosten sind real, auch wenn sie in keiner Kostenstelle auftauchen. Onboarding dauert Wochen länger, weil neue Teammitglieder Tribal Knowledge erfragen müssen. Support-Teams beantworten dieselben Fragen zum dritten Mal, weil die Antwort nirgends steht. Und Architektur-Entscheidungen werden auf Basis von Doku getroffen, die den Stand von vor zwei Jahren beschreibt.

Manuelle Pflege-Prozesse haben dieses Problem nie gelöst, weil der Aufwand linear mit der Menge an Inhalten wächst, das Budget aber nicht. Genau an dieser Stelle verändert KI die Rechnung: Der Grenzaufwand pro gepflegter Seite sinkt drastisch, wenn Erkennung und Entwurfsarbeit maschinell laufen.

Drei Ebenen der Automatisierung

Doku-Automatisierung mit KI lässt sich in drei Ebenen trennen, die unterschiedlich reif und unterschiedlich riskant sind.

Ebene 1: Erzeugen

LLMs generieren aus Code, Diffs, Tickets und Meeting-Notizen brauchbare Doku-Entwürfe. Das funktioniert heute zuverlässig für API-Referenzen, Changelogs und How-To-Gerüste. Die Falle liegt woanders: Generierte Entwürfe sehen fertig aus, sind es aber nicht. Warum polierte LLM-Texte den Review-Reflex aushebeln und wie Teams gegensteuern, haben wir in Polierte Drafts und der LLM-Review-Reflex beschrieben. Die Regel daraus: Ein generierter Entwurf ist ein Rohling und durchläuft dasselbe Review wie menschlicher Text.

Ebene 2: Aktuell halten

Der größere Hebel liegt nicht im Schreiben, sondern im Erkennen von Veraltung. Drift-Erkennung vergleicht Doku-Inhalte per Embedding mit dem aktuellen Stand von Code, UI-Texten und Release Notes. Wächst die semantische Distanz, wird die Stelle zur Prüfung gemeldet. Wie das über mehrere Ausgabeformate hinweg funktioniert, zeigt der Artikel zur Multi-Format-Doku-Aktualisierung: Quick-Start, Tutorial und Video-Transkript laufen in dieselbe Embedding-Schicht und werden gegeneinander geprüft.

Ebene 3: Prüfen

Die dritte Ebene testet Dokumentation wie Software. Ein Agent arbeitet eine Anleitung Schritt für Schritt gegen das laufende System ab und meldet, wo Doku und Realität auseinanderlaufen. Solche End-to-End-Prüfungen sind aufwendiger als Drift-Sensoren, liefern aber die härteste Aussage: Diese Anleitung funktioniert, jene nicht mehr. Sinnvoll priorisiert wird nach Nutzungsdaten, geprüft wird zuerst, was oft gelesen wird.

Docs-as-Code als Fundament

Alle drei Ebenen setzen voraus, dass Dokumentation maschinell verarbeitbar ist. Das ist der Kern von Docs-as-Code: Doku liegt als Plain Text im Git-Repository, Änderungen laufen als Merge Requests, eine CI-Pipeline baut und prüft die Inhalte. Für die Strukturfrage, wann leichtgewichtiges Markdown reicht und wann ein strukturierter Standard sich lohnt, liefert der Vergleich DITA und Markdown die Entscheidungskriterien. Für den inhaltlichen Aufbau hat sich das Diátaxis-Framework als Ordnungsraster bewährt.

In der Pipeline sieht ein Drift-Check als GitLab-CI-Job so aus:

doc-freshness:
  stage: verify
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - "src/**/*"
  script:
    - python scripts/doc_drift.py --docs docs/ --since "$CI_MERGE_REQUEST_DIFF_BASE_SHA"
    - test ! -s drift-report.md || cat drift-report.md
  artifacts:
    paths:
      - drift-report.md
    when: always

Der Job läuft in Merge-Request-Pipelines bei jeder Code-Änderung, denn nur dort ist die Basis-Revision für den Diff gesetzt, vergleicht betroffene Module mit den zugehörigen Doku-Abschnitten und legt einen Report ab. Ob daraus ein blockierender Quality Gate wird oder nur ein Hinweis im Merge Request, ist eine Team-Entscheidung. Wir starten in Projekten bewusst mit dem Hinweis-Modus, sonst wird der Check beim ersten Termindruck deaktiviert.

Die Wissensbasis als RAG-Layer

Gepflegte Doku zahlt doppelt ein, wenn sie als Retrieval-Basis für interne KI-Assistenten dient. Die Architektur dafür, von Chunking über Embeddings bis zur Antwort-Generierung, steht im Artikel zu RAG-Systemen im Unternehmenseinsatz. Wer den kompletten Stack ohne Cloud-Abhängigkeiten aufbauen will, findet in der Open-Source-Wissensbasis mit KI-Stack eine erprobte Kombination aus BookStack, Qdrant und Ollama.

Der Zusammenhang ist strategisch wichtiger, als er zunächst wirkt. Ein RAG-System macht Doku-Qualität unmittelbar sichtbar: Veraltete Inhalte produzieren falsche Antworten, und zwar dort, wo Mitarbeitende täglich fragen. Damit bekommt Doku-Pflege erstmals eine direkte Feedback-Schleife. Ein sauber gepflegtes Glossar verstärkt den Effekt zusätzlich, weil einheitliche Begriffe die Retrieval-Treffer messbar verbessern.

Pragmatischer Einstieg in drei Schritten

Schritt eins ist ein Inventar mit Ownership. Welche Doku-Bestände existieren, wer verantwortet sie, welche werden tatsächlich genutzt? Bestände ohne Owner und ohne Nutzung werden archiviert statt automatisiert. Automatisierung von totem Content ist verschwendetes Budget.

Schritt zwei sind Drift-Sensoren auf dem wichtigsten Bestand. Ein wöchentlicher Embedding-Vergleich zwischen Doku und Code-Stand, Meldungen landen im Backlog des Doku-Owners. Das ist mit überschaubarem Aufwand umsetzbar und liefert sofort ein ehrliches Bild der Veraltung.

Schritt drei sind Update-Pipelines mit Mensch im Loop. Änderungen an der Quelle erzeugen automatisch Doku-Entwürfe als Merge Request, ein Mensch reviewt und merged. Erst wenn dieser Kreislauf läuft, lohnt sich der Ausbau in Richtung E2E-Prüfung und Multi-Format-Synchronisation.

Bewusst nicht auf der Liste: ein neues Doku-Tool. Die Automatisierungs-Ebenen funktionieren mit fast jedem bestehenden System, solange die Inhalte als Text exportierbar sind. Ein Tool-Wechsel ist gelegentlich sinnvoll, aber fast nie der erste Schritt.

Fazit

Technische Dokumentation, die sich selbst pflegt, ist keine Utopie, sondern eine Frage der Architektur: Docs-as-Code als Fundament, Drift-Erkennung als Sensorik, generierte Entwürfe mit menschlichem Review als Pflege-Prozess und RAG als Feedback-Schleife. Die Ownership-Frage löst keine dieser Komponenten, sie wird durch Automatisierung nur bezahlbar.

EverBright IT baut solche Doku- und Knowledge-Pipelines gemeinsam mit Teams auf, von der ersten Drift-Erkennung bis zur produktiven Wissensbasis. Mehr dazu unter KI & Automatisierung oder direkt Kontakt aufnehmen.

Häufige Fragen

Was bedeutet Docs-as-Code konkret?

Docs-as-Code behandelt Dokumentation wie Quellcode: Inhalte liegen als Plain Text in Git, Änderungen laufen über Merge Requests mit Review, eine CI-Pipeline baut, prüft und veröffentlicht die Doku. Der Ansatz macht Dokumentation versionierbar, nachvollziehbar und maschinell verarbeitbar, was die Voraussetzung für jede KI-gestützte Automatisierung ist.

Kann KI technische Dokumentation vollständig automatisch pflegen?

Nein. KI erkennt Veraltung zuverlässig, erzeugt Update-Entwürfe und prüft Anleitungen gegen die laufende Software. Die Entscheidung, was fachlich korrekt ist, welche Inhalte strategisch wichtig sind und wer Verantwortung trägt, bleibt menschlich. Realistisch ist eine spürbare Reduktion des Pflege-Aufwands, keine Vollautomatisierung; wie groß sie ausfällt, hängt davon ab, wie viel der Doku überhaupt aus maschinenlesbaren Quellen ableitbar ist.

Wie erkennt man veraltete Dokumentation automatisiert?

Der verbreitetste Ansatz ist Drift-Erkennung über Embeddings: Doku-Abschnitte und zugehörige Code-Module werden semantisch verglichen, wachsende Distanz signalisiert Veraltung. Ergänzend prüfen Agenten Anleitungen Schritt für Schritt gegen das laufende System. Einfache Signale wie Änderungsdaten und tote Links liefern zusätzlich schnelle Treffer ohne KI-Aufwand.

Welche Tools eignen sich für den Einstieg?

Für Docs-as-Code reichen Git, Markdown und ein Static Site Generator wie Astro oder MkDocs. Drift-Erkennung lässt sich mit Open-Source-Embeddings über Ollama und einer Vektordatenbank wie Qdrant aufbauen. Wer eine komplette Wissensbasis sucht, kombiniert BookStack für Inhalte mit einem RAG-Layer für Suche und Assistenz.