Vor zwei Jahren erkannte jeder Reviewer einen frühen Doku-Entwurf in Sekunden. Schreibfehler, schiefe Sätze und fehlende Übergänge waren das verlässliche Signal: Hier muss noch gearbeitet werden. Mit dem Einzug von LLMs in den Schreibprozess ist dieses Signal verschwunden. Erste Drafts kommen heute sprachlich poliert. Genau das ist die neue Falle.
Dieser Artikel beschreibt, wie sprachlich saubere LLM-Entwürfe neue Probleme im Reviewprozess schaffen können, welche Praktiken die alte Sorgfalt zurückbringen und wie sich Content-Ops in Teams aufstellen, die produktiv mit LLMs arbeiten.
Warum die Form das Urteil verzerrt
Reviewer sind trainiert auf Form-Signale. Schreibfehler, Stilbrüche und holprige Übergänge waren über Jahrzehnte zuverlässige Marker für unfertige Inhalte. Wenn ein Text diese Marker zeigt, weiß jeder Reviewer: Dieser Text ist noch lange nicht fertig.
LLMs eliminieren diese Marker. Der erste Draft kommt schon mit korrekter Grammatik, sauberen Übergängen und einem Stil, der professionell wirkt. Der Reviewer schaltet auf “passt schon” und überfliegt den Text. Inhaltliche Lücken, sachlich falsche Aussagen, Halluzinationen über Funktionen oder Konfigurationen werden bei einem Überflug nicht zuverlässig erkannt.
Nicht nur dass der Content so aussieht als wäre er schon in Review gewesen, zusätzlich spielt auch der Fluency-Bias eine Rolle: Leichte Lesbarkeit wird unbewusst als inhaltliche Korrektheit wahrgenommen. Bei klassischen Drafts war dieser Bias unproblematisch, weil Form und Inhalt korrelierten. Bei LLM-Drafts entkoppelt sich diese Korrelation. Die Form ist gut, der Inhalt schwankt.
Ein reales Beispiel aus der Praxis: Bei einer Smartphone-App, die ich betreut habe, konnte es vorkommen, dass User ihre Inhalte in einer anderen Sprache angezeigt bekamen, als in der für die UI eingestellten Sprache. Um die User an die Hand zu nehmen, sollte sich nun selbstständig ein Alert öffnen, der die User fragt, ob sie das mit Absicht so eingestellt hätten oder ob sie gerne in das entsprechende Untermenü in den Einstellungen weitergeleitet werden würden. So der Plan.
Da ein solcher Alert auch für Fehlermeldungen verwendet wird, schlich sich aber der Begriff “error message” in das zugehörige Jira-Ticket ein, obwohl inhaltlich nicht von einem Fehler die Rede war. Der Entwickler ließ sich von einem AI-Tool zu einem sauberen englischen Text verhelfen mit der Überschrift “An Error Occurred in Your Settings”. Und in den Release Notes schlug es sich in folgendem Eintrag nieder: “We fixed an error in which your content was displayed in the wrong language.” Niemand störte sich daran, es klang ja oberflächlich plausibel. Erst kurz vor Release fiel eher zufällig auf, dass die Texte umgeschrieben werden mussten.
Was noch alles schief gehen kann
Drei weitere Fehler tauchen in produktiven Beobachtungen häufig auf:
Halluzinierte Funktionen Ein LLM beschreibt einen Workflow mit einem Schritt, den die Software so nicht anbietet. Der Schritt klingt plausibel, ist aber nicht ausführbar. Wer den Text überfliegt, übernimmt die Halluzination in die finale Doku.
Veraltete Defaults LLMs sind trainiert auf Daten mit einem bestimmten Cutoff. Eine Beschreibung kann technisch akkurat für einen früheren Software-Stand sein, für die aktuelle Version aber falsch.
Falsche “Stimme” Ein generelles Modell ohne Kontext zum Brand-Voice Style-Guide produziert einen kompetent klingenden, aber inkonsistenten Ton. Irgendwann wirkt der komplette Content wie billig zusammengestückelt.
Praktiken, die den Review-Reflex zurückbringen
Drei Praktiken haben sich als wirksam erwiesen.
Praktik eins: Der vielleicht offensichtlichste Weg ist die Verfolgung des Status. Ein Draft muss klar als solcher gekennzeichnet sein. Wie so häufig erfordert der offensichtlichste Weg in der Praxis große Disziplin. Wenn Markierungen zum Status nicht durchgehend sauber gepflegt werden, funktioniert es nicht. Bei integrierten Schreibtools sollten KI-Drafts automatisch markiert sein: Ein Frontmatter-Feld oder ein Banner zeigt, dass ein Entwurf maschinell generiert ist. Wenn KI-Texte in das Tool hineinkopiert werden, muss jedoch darauf Verlass sein, dass der Kollege dies auch von Hand als Draft markiert.
Praktik zwei: Quellenanker im Entwurf. Jeder Doku-Abschnitt referenziert die Quelle, aus der der Inhalt stammt. Pull-Request-Beschreibung, Ticket-ID, Release-Note. Reviewer können gezielt prüfen, ob der Entwurf die Quelle korrekt wiedergibt. Diese Disziplin haben wir auch in unserem Artikel zu Glossaren als RAG-Layer als Pflege-Pattern beschrieben.
Praktik drei: Doku-E2E-Tests gegen die laufende Software. Was sich automatisiert prüfen lässt, sollte automatisiert geprüft werden. Halluzinierte Schritte fallen in einer durchklickenden Test-Pipeline schnell auf. Wir haben den Aufbau dieser Pipelines im Artikel zu Doku-E2E-Tests mit KI-Agenten skizziert.
Was das für Content-Ops-Teams bedeutet
Drei Verschiebungen prägen Content-Ops, die produktiv mit LLMs arbeiten.
Reviewer-Rollen verschieben sich von Korrektur zu Validierung. Sprachliches Lektorat wird seltener nötig, inhaltliche Prüfung gegen Quellen häufiger. Wer früher als Korrektor profilierter war, muss inhaltliche Quellenarbeit aufbauen.
Tooling muss Quellenanker explizit unterstützen. Ein CMS, das Pull-Requests, Tickets und Release-Notes als Referenzen verlinkt, erleichtert die neue Validierungs-Disziplin. Manuelle Verlinkung in Fließtext-Form skaliert nicht.
KI-Disziplin gehört in den Style-Guide. Welche Modelle werden verwendet, welche Prompts gelten als Standard, welche Marker zeigen einen KI-Entwurf an? Diese Antworten gehören in eine maintainte Style-Guide-Variante, nicht in mündliche Verabredungen.
Eine englische Fassung dieses Artikels gibt es unter Polished drafts and the review reflex, den ergänzenden Org-Blick in Wikis nobody maintains.
Fazit
LLMs heben das Eingangsniveau jedes Drafts. Genau das fordert die Review-Praxis heraus, weil die alten Formsignale nicht mehr zuverlässig sind. Wer Inhaltschecklisten, Quellenanker, klare Markierung und automatisierte Tests einsetzt, holt die alte Sorgfalt zurück, ohne den Geschwindigkeitsgewinn aufzugeben. Die Disziplin ist neu, der Hebel ist groß.
EverBright IT begleitet Content-Ops-Teams beim Aufbau LLM-resilienter Review-Praktiken. Mehr zu unseren KI-Services oder direkt Kontakt aufnehmen.
Häufige Fragen
Wie erkennt man einen LLM-generierten Doku-Entwurf?
Verlässlich erkennen lässt er sich oft nicht mehr durch Sprache. Indikatoren bleiben: leicht generischer Ton, vermeintlich plausible aber schwer überprüfbare Detail-Aussagen, mehrfach verwendete Standard-Phrasen, fehlende Quellenanker. Die ehrlichste Lösung ist nicht Erkennung, sondern explizite Markierung im Workflow. Wer einen KI-Draft erzeugt, kennzeichnet ihn als solchen.
Welche Inhalte sollten nicht von LLMs vorgeschrieben werden?
Sicherheitshinweise, regulatorische Aussagen, Compliance-Pflichtangaben und exakte Konfigurationsanleitungen verlangen menschliche Erst-Hand. Hier ist das Risiko von Halluzinationen besonders hoch und der Schaden bei Fehlern besonders groß. Beschreibende Texte, Marketing-orientierte Einleitungen und FAQ-Antworten lassen sich dagegen mit LLM-Hilfe pragmatisch beschleunigen.
Verändern LLMs den Personalbedarf in Content-Ops-Teams?
Ja, aber nicht primär durch Reduktion. Reviewer-Profile verschieben sich Richtung inhaltliche Validierung und Quellen-Recherche. Reine Korrektorate werden seltener, fachliche Reviews gewinnen an Gewicht. Realistisch braucht es ein Quartal Umstellungszeit, in dem Teams ihre neue Aufgabenverteilung sortieren und Tools entsprechend anpassen.
Sind Brand-Voice-Drift und Halluzinationen auch in mehrsprachigen Doku-Workflows ein Problem?
Stärker als in einsprachigen Workflows. Übersetzungsmodelle erben die Halluzinationen aus dem Original und addieren eigene. Brand-Voice-Drift verstärkt sich, weil jede Sprachversion eigene Trainingsspuren des Modells trägt. Wer mehrsprachig arbeitet, sollte Quellenanker und Dokutests besonders konsequent einsetzen, weil die Validierungslast pro Variante steigt.
