KI-gestützte Informationssysteme für Technische Redakteure

Abgrenzen heißt, dass die Grenzen des Wissens eines Systems festgelegt werden, bevor es antwortet – und nicht erst entdeckt werden, wenn es falsch antwortet.

Technische Redakteure müssen fragen:

• Welche Produkte, Versionen und Varianten deckt das System ab?
• Welche Fragen darf es beantworten, und welche muss es an einen Menschen weitergeben?
• Welches Wissen ist sicherheitskritisch und darf nur unverändert weitergegeben werden?
• Was darf das System nie selbst ableiten, schätzen oder kombinieren?
• Wie sagt das System, dass es etwas nicht weiß?
• Wer validiert Antworten in den Bereichen, in denen die Grenze eng ist?

Eine Maschine ohne Grenze füllt jede Lücke. Sie beantwortet Fragen zu Produkten, die sie nicht abdeckt, kombiniert Werte aus verschiedenen Varianten und macht aus Unsicherheit überzeugte Sätze.

Eine Grenze ist eine Dokumentationsentscheidung. Sie benennt den Umfang, die Inhalte, die nur so wiedergegeben werden dürfen, wie sie sind – Warnungen, Grenzwerte, sicherheitsrelevante Werte –, und die Stellen, an denen das System aufhören und auf einen Menschen oder die Betriebsanleitung verweisen muss.

Für die Dokumentation heißt das: Umfang und Grenzen des Wissens werden so sorgfältig aufgeschrieben wie das Wissen selbst.

• Nicht wissen ist eine gültige Antwort.
• Eine Grenze schränkt die Qualität nicht ein. Sie gehört zu ihr.
• Sicherheitsinformationen werden wiedergegeben, nicht umschrieben.

Ein System, das nicht weiß, wo sein Wissen endet, hält dort nicht an.

Verankern heißt, dass jede Antwort, jede Seite und jede abgeleitete Ausgabe auf eine gesteuerte Quelle zurückgeführt werden kann, die maßgeblich bleibt.

Technische Redakteure müssen fragen:

• Wo liegt die maßgebliche Fassung dieses Wissens?
• Wer verantwortet sie, und wer darf sie ändern?
• Welche Ausgaben werden daraus abgeleitet: Seiten, PDFs, Antworten, Produkttexte?
• Was geschieht mit den abgeleiteten Ausgaben, wenn sich die Quelle ändert?
• Ist ein erzeugter Text eine Quelle oder nur ein Vorschlag dafür?
• Welche Inhalte darf die Maschine nutzen: nur freigegebene oder auch Entwürfe?

In vielen Organisationen gibt es dasselbe Wissen an mehreren Orten: in der Betriebsanleitung, in Schulungsfolien, auf der Website, im Serviceportal und jetzt in den Antworten eines KI-Assistenten. Jede Kopie entfernt sich von den anderen.

Verankern kehrt das Verhältnis um. Die gesteuerte Quelle ist maßgeblich, alles andere wird daraus abgeleitet und mit ihr abgeglichen, wenn sie sich ändert. Die spezifikationsgetriebene Softwareentwicklung beschreibt denselben Gedanken für Code: Der Code dient der Spezifikation. In der Dokumentation dient die Antwort der Quelle.

Für die Dokumentation heißt das: Die Quelle bleibt über das ganze Produktleben die Quelle. KI-Ausgaben werden aus ihr abgeleitet – sie ersetzen sie nie stillschweigend.

• Ein erzeugter Text ist keine Quelle.
• Eine Kopie ist keine Version.
• Freigegeben ist nicht dasselbe wie verfügbar.

Die Antwort dient der Quelle.

Bedeutung modellieren heißt, dass aufgeschrieben wird, wofür ein Begriff steht, wie er mit anderen Begriffen zusammenhängt und welche Einschränkungen gelten – statt es dem Leser oder der Maschine zu überlassen.

Technische Redakteure müssen fragen:

• Hat jeder wichtige Begriff eine Vorzugsbenennung und eine Definition?
• Welche Synonyme, Abkürzungen und veralteten Benennungen verweisen auf denselben Begriff?
• Welcher Begriff ist übergeordnet, untergeordnet oder nur verwandt?
• Welche Einschränkungen gelten: nur in dieser Betriebsart, nur mit dieser Komponente, nie zusammen?
• Welche Fragen muss das Modell beantworten können?
• Ist die Bedeutung dort gespeichert, wo die Maschine sie lesen kann, oder nur in einem Styleguide?

Menschen lösen Mehrdeutigkeit mit Kontext und Erfahrung. Eine Maschine löst sie statistisch. Hat eine Sache drei Namen, behandelt das System sie womöglich als drei Sachen. Teilen sich zwei Sachen einen Namen, legt es sie womöglich zusammen.

Semantische Struktur gibt dem System Halt: kontrollierte Terminologie, ausdrückliche Beziehungen, Taxonomien, Ontologien. Je ausdrücklicher die Bedeutung, desto weniger muss das System raten. Ich nenne das semantische Schwerkraft – je stärker die Struktur, desto näher bleiben die Antworten an dem, was gemeint ist.

Für die Dokumentation heißt das: Terminologiearbeit, Beziehungen und Einschränkungen sind kein Zusatz für die Lokalisierung. Sie sind die Bedeutungsarchitektur, aus der die Maschine antwortet.

• Ein Begriff ist kein Wort. Er ist ein Konzept mit einem Namen.
• Eine Synonymliste ist kein Modell.
• Was für Menschen selbstverständlich ist, ist für eine Maschine unsichtbar.

Je stärker die Bedeutungsstruktur, desto weniger muss die Maschine raten.

Einheiten bilden heißt, dass Wissen in Einheiten gegliedert wird, die jeweils einem Zweck dienen und für sich verstanden, gefunden und wiederverwendet werden können.

Technische Redakteure müssen fragen:

• Welchen einen Zweck hat diese Einheit?
• Ist sie ohne die Seite davor verständlich?
• Nennt sie ihren eigenen Kontext: Produkt, Aufgabe, Zielgruppe?
• Ist die Warnung Teil der Einheit, zu der sie gehört, oder steht sie woanders auf der Seite?
• Ergibt die Einheit noch Sinn, wenn eine Maschine sie herausschneidet und allein zeigt?
• Ist die Einheit zu groß, um genau gefunden zu werden, oder zu klein, um verstanden zu werden?

Leser, die über die Suche kommen, landen mitten in der Dokumentation. Mark Baker hat das in „Every Page is Page One“ beschrieben: Jede Seite muss als erste Seite funktionieren. Die Maschine ist, wenn sie eine Passage abruft, der extremste dieser Leser. Sie sieht nur die Einheit, nichts darum herum.

Eine Einheit, die sich auf das vorige Kapitel stützt, eine Warnung zwei Seiten vorher oder eine Tabelle ohne Überschrift wird zur falschen Antwort, sobald sie allein abgerufen wird. Topic-basierte Strukturen wie DITA und die Informationseinheiten von iiRDS wurden für die Wiederverwendung gebaut; dieselbe Disziplin macht Einheiten für den Abruf nutzbar.

Für die Dokumentation heißt das: Die Einheit, die ein Mensch allein liest, und die Einheit, die eine Maschine allein abruft, sind dieselbe Einheit. Sie muss ihren Kontext und ihre Sicherheitsinformationen mitbringen.

• Ein Chunk ist kein Topic, solange ihn niemand als Topic gestaltet hat.
• Eine Einheit ohne Kontext ist ein Fragment.
• Eine Warnung außerhalb ihrer Einheit schützt niemanden, der nur die Einheit sieht.

Jede Einheit ist Seite eins – für Menschen und für Maschinen.

Kontext beschreiben heißt, dass jede Einheit die Metadaten trägt, die ein System braucht, um sie für das richtige Produkt, die richtige Variante, Rolle und Situation auszuwählen.

Technische Redakteure müssen fragen:

• Für welches Produkt, welche Variante und welche Version gilt diese Einheit?
• Für welche Rolle: Bediener, Servicetechniker, Monteur, Entwickler?
• Für welche Lebenszyklusphase und Betriebsart?
• Welche Art von Information ist es: Konzept, Handlung, Referenz, Warnung, Fehlerbehebung?
• Welche Metadaten sind Pflicht, und wer prüft sie?
• Nutzen die Metadaten dasselbe Vokabular wie die Produktdaten?

Ein menschlicher Leser sieht oft am Deckblatt, am Layout oder am Produktfoto, ob eine Seite gilt. Die Maschine kann das nicht. Sie wählt nach dem aus, was aufgeschrieben ist – und wo nichts aufgeschrieben ist, nach Ähnlichkeit.

Metadaten machen Gültigkeit für eine Maschine prüfbar. Standards wie iiRDS beschreiben Produkt-, Funktions- und Verwaltungsmetadaten genau zu diesem Zweck: die richtige Information für das richtige Produkt und die richtige Situation bereitzustellen.

Für die Dokumentation heißt das: Metadaten sind keine Ablageinformation für die Redaktion. Sie sind der Kontext, nach dem das System auswählt – und weglässt.

• Ähnlich ist nicht zutreffend.
• Fehlende Metadaten sind auch eine Entscheidung – getroffen von der Maschine.
• Gültigkeit ist Inhalt, nicht Verwaltung.

Was die Metadaten nicht sagen, wird die Maschine raten.

Mit dem Produkt verbinden heißt, dass Dokumentationseinheiten über stabile Kennungen an die realen Elemente des Produkts gebunden sind – seine Zustände, Fehlercodes, Komponenten, Schnittstellen und Konfigurationen.

Technische Redakteure müssen fragen:

• Zu welchem Fehlercode, Zustand oder Bauteil gehört diese Einheit?
• Ist diese Verbindung als Kennung gespeichert oder nur im Text erwähnt?
• Woher kommen die Produktdaten: aus der Konstruktion, dem PLM, der Steuerungssoftware?
• Was geschieht mit der Dokumentation, wenn sich das Produkt ändert?
• Kann das System erkennen, welche Konfiguration der Leser tatsächlich hat?
• Wer wird informiert, wenn eine Produktänderung eine Einheit betrifft?

Dokumentation beschreibt das Produkt in mitteilbarer Form. Ist sie mit den eigenen Daten des Produkts verbunden, kann die Maschine aus dem Zustand antworten, in dem das Produkt ist, aus dem Fehlercode, den es zeigt, und aus der Konfiguration, die es hat – nicht aus einer allgemeinen Beschreibung.

Ein digitaler Zwilling der Informationsumgebung, wie Michael Iantosca und andere ihn beschreiben, verbindet Dokumentation, Terminologie und Produktstruktur in einem Modell. Die Verbindung trägt nur so weit, wie die Kennungen stabil und gemeinsam genutzt sind.

Für die Dokumentation heißt das: Die Verbindung zwischen einer Einheit und dem Produkt wird gepflegt wie der Inhalt. Eine gebrochene Verbindung erzeugt eine Antwort für ein Produkt, das es nicht gibt.

• Ein Fehlercode im Text ist keine Verknüpfung.
• Die Produktwirklichkeit ändert sich vor der Dokumentation.
• Eine gemeinsame Kennung ist mehr wert als eine lange Beschreibung.

Dokumentation, die mit dem Produkt verbunden ist, kann für das Produkt vor dem Leser antworten.

Abrufen und anpassen heißt, dass das System für eine Frage die richtigen Einheiten auswählt, nur aus ihnen antwortet und die Antwort an Rolle, Zustand, Aufgabe und Risiko anpasst – ohne wegzulassen, was bleiben muss.

Technische Redakteure müssen fragen:

• Welche Einheiten muss das System für diese Frage finden?
• Bleibt die Antwort bei dem, was die Einheiten sagen, oder fügt sie etwas hinzu?
• Was darf sich mit der Rolle ändern: Tiefe, Reihenfolge, Terminologie?
• Was darf sich nie ändern: Warnungen, Grenzwerte, Voraussetzungen, Abbruchkriterien?
• Wie zeigt die Antwort ihre Quelle und ihre Gültigkeit?
• Was geschieht, wenn das Risiko der Aufgabe steigt?

Retrieval-Augmented Generation lässt die Maschine aus der Dokumentation antworten statt aus dem, was ihr Sprachmodell zufällig enthält. Grounding heißt, dass die Antwort bei den abgerufenen Quellen bleibt. Beides funktioniert nur so gut wie die Einheiten, die Bedeutung und der Kontext dahinter.

Angepasste Ausgabe ist der Punkt, an dem KI-gestützte Dokumentation für den Leser sichtbar wird: Die Antwort für den Servicetechniker unterscheidet sich von der Antwort für den Bediener. Anpassung ist eine Dokumentationsentscheidung. Sie braucht Regeln, was gekürzt, umgestellt oder erklärt werden darf – und einen Sicherheitsvorrang, der im Zweifel schließt: Wenn es unklar ist, werden die vollständigen Sicherheitsinformationen gezeigt, nie weniger.

Für die Dokumentation heißt das: Die Redakteurin entscheidet im Voraus, was eine Antwort anpassen darf und was sie unverändert tragen muss. Anpassung lässt nie sicherheitsrelevante oder vorgeschriebene Benutzerinformationen weg.

• Relevant ist nicht vollständig.
• Angepasst ist nicht gekürzt.
• Ein Sicherheitsvorrang, der im Zweifel öffnet, ist kein Vorrang.

Eine angepasste Antwort ist nur so sicher wie die Regeln dafür, was sie nicht verändern darf.

Nachvollziehen heißt, dass der Weg von einer Antwort zurück zu der Einheit, der Version, der Prüfung und der Produktanforderung, auf der sie beruht, sichtbar und überprüfbar bleibt.

Technische Redakteure müssen fragen:

• Welche Einheiten und Versionen hat diese Antwort genutzt?
• Wer hat diese Einheit geprüft, und wann?
• Zu welcher Produktanforderung, Änderung oder Prüfung gehört sie?
• Welche Teile des Produkts sind noch nicht dokumentiert?
• Welche Einheiten sind dokumentiert, passen aber nicht mehr zum Produkt?
• Kann ein Auditor nachvollziehen, was das System zu einem bestimmten Zeitpunkt geantwortet hat?

Nachverfolgbarkeit kennt man aus dem Requirements Engineering: von der Anforderung über den Entwurf zur Prüfung. In der spezifikationsgetriebenen Softwareentwicklung wird sie bis zum Code verlängert – jeder Anwendungsfall zeigt, ob Code und Tests dazu existieren. Dokumentation braucht dieselbe Linie von der Produktänderung über die Einheit zur Antwort.

Nachvollziehen macht zwei Arten von Lücken sichtbar: Wissen, das das Produkt hat, die Dokumentation aber nicht, und Dokumentation, zu der das Produkt nicht mehr passt. Beide sind in einer einzelnen Antwort unsichtbar.

Für die Dokumentation heißt das: Quellenangaben, Versionen und Prüfnachweise sind Teil des Informationssystems, kein Archiv daneben. Eine Antwort, die sich nicht zurückverfolgen lässt, lässt sich nicht korrigieren.

• Plausibel ist nicht geprüft.
• Eine Quellenliste ist keine Nachverfolgbarkeit.
• Abdeckung ist eine Frage, keine Annahme.

Was sich nachvollziehen lässt, lässt sich prüfen. Was sich prüfen lässt, verdient Vertrauen.

Steuern heißt, dass Regeln, Rollen und Freigaben entscheiden, was die Maschine vorschlagen darf, was Menschen prüfen müssen und was den Leser erreicht.

Technische Redakteure müssen fragen:

• Welche Ausgaben darf das System selbst erzeugen, und welche nur als Vorschlag?
• Was ist nie erlaubt: Warnungen ändern, Werte erfinden, über den Umfang hinaus antworten?
• Wer prüft einen Vorschlag, und nach welchen Kriterien?
• Wer darf ihn freigeben, und wie wird die Freigabe festgehalten?
• Wie werden Fehler gemeldet, korrigiert und zurückgeführt?
• Welche Entscheidungen bleiben bei Menschen, gleich was das System kann?

KI macht es leicht, Text zu erzeugen. Sie macht es nicht leicht, Verantwortung dafür zu übernehmen. Steuerung hält beides zusammen: KI-Ausgaben kommen als Vorschlag, ein Mensch prüft sie gegen Quelle und Regeln, und nur eine freigegebene Änderung wird Teil der Quelle.

Dasselbe Prinzip gibt es in der spezifikationsgetriebenen Softwareentwicklung, in der erzeugter Code als Pull Request ankommt, den jemand prüft und übernimmt. In der Dokumentation umfasst die Prüfung Inhalt, Terminologie, Metadaten und Sicherheitsinformationen.

Für die Dokumentation heißt das: Die Redakteurin legt die Regeln fest, denen das System folgt, und bleibt diejenige, die freigibt. Steuerung unterstützt die menschliche Aufsicht; sie ersetzt nie die Risikobeurteilung des Herstellers oder die Verantwortung für die Benutzerinformation.

• Ein Vorschlag ist keine Entscheidung.
• Schnelle Ausgabe ist keine schnelle Freigabe.
• Verantwortung geht nicht auf das Modell über.

KI darf vorschlagen. Menschen entscheiden.

Weiterentwickeln heißt, dass das Wissensmodell aus Belegen seiner Nutzung verbessert wird – in einer gesteuerten Schleife, nie durch stille Selbstveränderung.

Technische Redakteure müssen fragen:

• Welche Fragen erhält das System, die das Modell nicht ausdrücken kann?
• Welche Begriffe oder Beziehungen fehlen, und wie bemerken wir das?
• Wer schlägt eine Änderung am Modell vor, und in welcher Form?
• Wie zeigen wir, dass die Änderung die Antworten besser macht, nicht nur anders?
• Wer übernimmt eine geprüfte Änderung in das gesteuerte Modell?
• Wie halten wir den gesteuerten Kern stabil, während das Modell wächst?

In meinem Artikel „EvoOntology vs. iiRDS“ habe ich die Spannung zwischen sorgfältig gesteuerten Ontologien und Modellen beschrieben, die sich aus Erfahrung weiterentwickeln. Michael Iantosca hat das im Whitepaper „From knowledge graphs to adaptive semantics“ weitergedacht: Inferenz erweitert, was der Knowledge Graph weiß; Ontologie-Evolution erweitert, was er darstellen kann.

Das Paper stellt eine adaptive semantische Rückkopplungsschleife um den gesteuerten Kern vor: lernen, wie KI-Agenten das Modell nutzen, Lücken erkennen, die es nicht ausdrücken kann, einen neuen Begriff, eine Beziehung oder Regel vorschlagen, bewerten, ob die Antworten besser werden, und steuern, indem geprüfte Änderungen in das Unternehmensmodell übernommen werden. Der KI-Agent wird zur Quelle von Belegen, nicht zum Bearbeiter des Modells.

Für die Dokumentation heißt das: Das Modell ist nie fertig, und es ändert sich nie von selbst. Lücken werden zu Vorschlägen, Vorschläge zu Entscheidungen, und nur Entscheidungen ändern den gesteuerten Kern.

• Weiterentwicklung ist keine Drift.
• Eine Lücke ist ein Beleg, kein Versagen.
• Der gesteuerte Kern wächst durch Entscheidung, nicht durch Zufall.

Ein Wissensmodell, das unter Steuerung lernt, wird besser, ohne Vertrauen zu verlieren.