KI-Texte mit Belegen: Genehmigen Sie den Plan, nicht die Prosa

Die Stunde nach dem Blankoprompt ist der Moment, in dem KI-Texte ohne Halluzinationen schreiben lassen plötzlich nach Arbeit klingt: Der Text ist flüssig, die Formulierungen sitzen, und trotzdem weiss niemand, welche Behauptung trägt. Sie wollten ein Konzept. Sie bekamen Prosa.

Genau dort beginnt evidenzbasiertes KI-Schreiben. Nicht mit einem besseren Prompt, sondern mit einer anderen Reihenfolge: erst Quellen sammeln, dann den Plan freigeben, dann den Entwurf mit Belegen schreiben lassen, dann jede faktische Behauptung gegen die Quelle prüfen. Deloitte Australien vereinbarte nach AP-Berichten die teilweise Rückerstattung eines Honorars von rund A$440'000 für einen Regierungsbericht, nachdem erfundene Referenzen und ein ausgedachtes Richterzitat im Bericht standen. Das war kein besonders exotisches Modellproblem. Das war ein Freigabeproblem: Der Text wurde behandelt, als sei schöne Form ein Beweis.

Die These dieses Artikels hat zwei Stockwerke. Das erste ist Prozess: Genehmigen Sie den Plan, nicht die Prosa — und lassen Sie am Ende trotzdem einen benannten Fachexperten die Claims prüfen. Das zweite ist Maschinenbau, und es ist der Teil, den die meisten «grounded»-Versprechen schuldig bleiben: Ein Zitat darf kein String sein, der gut aussieht, sondern muss eine auflösbare Referenz sein — bis hinunter zur markierten Textstelle auf der Seite des Original-PDFs, und zwar auch dann noch, wenn der Beleg vorher durch eine mehrstufige Pipeline gewandert ist, in der Recherche-Agenten an Sprachmodelle übergeben und Sprachmodelle an weitere Sprachmodelle. Ich habe beides gebaut. Dieser Artikel zeigt den Prozess — und die Beweiskette darunter.

Was die Evidenz wirklich zeigt

Grounding ist kein Schutzschild, sondern eine Reduktion des Schadens. Die Stanford-RegLab/HAI-Studie fand 2025 in einem Legal-Research-Benchmark, dass die getesteten proprietären Rechtsrecherche-Tools trotz Retrieval 17 bis 33 Prozent der Antworten halluzinierten; GPT-4 lag im gleichen Benchmark bei 43 Prozent. Besonders unangenehm: Ein Anbieter hatte zuvor «100% hallucination-free» vermarktet. Das ist kein Detail für Juristen. Es ist der nüchterne Hinweis, dass eine Quelle im Prompt noch keinen geprüften Satz im Dokument ergibt.

Auch Suche mit Quellen ist kein verlässlicher Endzustand. Das Tow Center der Columbia Journalism Review testete im März 2025 acht AI-Search-Werkzeuge mit 1'600 Abfragen zur Identifikation von Nachrichtenquellen und fand, dass die Systeme in mehr als 60 Prozent falsch zitierten; selbst Perplexity als bester Kandidat lag bei 37 Prozent Fehlern. Der ehrliche Transfer: Das beweist nicht, dass Copilot Ihre SharePoint-Dokumente in derselben Rate falsch zitieren wird. Es beweist etwas Allgemeineres — Output, der nach Zitat aussieht, ist nicht dasselbe wie quellentreuer Output. Premium heisst dabei nicht automatisch vorsichtiger. Manchmal heisst es nur selbstbewusster falsch.

Der Grund ist tiefer als ein fehlendes Dokument. OpenAI-Forscher beschreiben Halluzinationen als teilweise strukturelles Ergebnis von Trainings- und Benchmark-Anreizen: Wer rät, kann Punkte holen; wer sauber «weiss ich nicht» sagt, wird oft nicht belohnt (Kalai et al.). Retrieval ändert diese Anreizstruktur nicht. Es gibt dem Modell Material, aber nicht automatisch Demut.

Allen diesen Befunden ist eine Sache gemeinsam, die selten ausgesprochen wird: Es sind Versagen von Systemen, in denen ein Zitat ein String ist — eine Zeichenkette, die plausibel aussieht und von niemandem eingelöst werden muss. Der Rest dieses Artikels zeigt, was es prozessual und technisch braucht, damit ein Zitat keine Zeichenkette ist, sondern eine auflösbare Referenz in ein Register mit stabilen Identitäten.

Der faire Gegenpol gehört dazu: Neue Reasoning- und RAG-Systeme können echte Gewinne bringen. Schwarcz et al. fanden in einer juristischen RCT mit Vincent AI und o1-preview Produktivitätsgewinne von 34 bis 140 Prozent, bei gleichzeitig «mixed» Accuracy. Daraus folgt für Schweizer KMU: Nutzen Sie die besseren Werkzeuge. Vertrauen Sie ihnen nicht die Schlusskontrolle an. Wer vertiefen will, warum belegbare Antworten im Chat dieselbe Disziplin brauchen, findet die Schwesterlogik in belegbaren Antworten mit Citations.

Das Muster: Recherche → Outline-Freigabe → belegter Entwurf → Zitatprüfung

Ganz verhindern lassen sich Halluzinationen nicht, auch nicht mit Retrieval oder Grounding. Belastbar wird ein KI-Text durch einen Prozess in vier Schritten: Recherche mit Quellen, Freigabe der Gliederung durch einen Menschen, Entwurf mit Beleg pro Behauptung, und Zitatprüfung durch einen benannten Fachexperten. Die Schritte machen diese Prüfung bezahlbar; sie ersetzen sie nicht.

Der Unterschied zum Blankoprompt ist nicht Kosmetik. Beim Blankoprompt entsteht zuerst Sprache und danach beginnt die Beweislast. Im Vier-Schritte-Muster entsteht zuerst die Beleglage: Welche Quellen gibt es, was tragen sie, wo sind Lücken, und welche Behauptungen dürfen daraus überhaupt folgen? Danach prüft ein Mensch die Outline, solange eine Änderung noch billig ist. Erst dann schreibt das Modell.

Praktisch sieht das so aus:

1. 1Recherche: Quellen sammeln und schwache Beleglage sichtbar machen.
2. 2Outline-Freigabe: Umfang, Reihenfolge, Claims und Lücken prüfen.
3. 3Belegter Entwurf: Jede faktische Behauptung trägt einen Quellenanker.
4. 4Zitatprüfung: Ein Mensch prüft, ob die Quelle wirklich sagt, was der Satz behauptet.

Ich kann das mit ungewöhnlicher Sicherheit sagen, weil das Muster nicht mein Wunschbild ist, sondern die exakte Knotenfolge meines geshippten Writing-Assistant-Graphen: Recherche-Agenten, Outline-Generierung, eine Evidenz-Verifikation der Outline, der menschliche Freigabe-Interrupt, dann Ein-Pass-Entwurf, deterministische Nachverarbeitung und optionale Zitatprüfung. Drei Details daraus sind übertragbar, egal ob Sie bauen oder manuell arbeiten. Erstens: Die Outline wird maschinell vorgeprüft, bevor der Mensch sie sieht — ein analytischer, bewusst unkreativer LLM-Schritt bindet jedem Gliederungspunkt seine Belege an und stuft die Beleglage pro Punkt als stark, mittel oder schwach ein. Der Mensch genehmigt also keine Stichwortliste, sondern eine Gliederung mit ausgewiesener Beweislage. Zweitens: «Mehr Recherche» ist ein eigener Rückkanal, keine Ablehnung — wer einen dünn belegten Abschnitt sieht, kann gezielte Nachrecherche genau dafür anfordern, und der Flow dreht eine Recherche-Schleife, bevor irgendein Entwurf entsteht. Drittens, der ehrliche Teil: Eine echte Ablehnung ist bei mir ein Neustart, kein sanftes Zurückblättern — und der Freigabe-Interrupt selbst ist konfigurierbar; wer ihn überspringt, hat sich bewusst gegen den Kontrollpunkt entschieden.

Das Muster ist werkzeugunabhängig. Es lässt sich mit Copilot, SharePoint-Quellen und Disziplin fahren; es lässt sich auch als Pipeline bauen. Der Architekturschritt beginnt nicht mit «wir brauchen einen Agenten», sondern mit der Frage, welches Arbeitsziel entsteht. Genau diese Übersetzung von Use Case zu Architektur behandelt der Artikel vom Use Case zur Architektur.

Die unbequeme Wahrheit: Es beginnt bei der Quellenordnung, nicht beim Prompt

Schritt 1 heisst Recherche — aber Recherche worin? Für die Geschäftsleitung ist das die eigentliche Frage, und sie ist keine Schreibfrage, sondern eine Governance-Frage: Was gilt bei Ihnen als freigegebene Quelle? Wem gehört sie? Welche SharePoint-Ordner sind vertrauenswürdig, was passiert mit veralteten PDFs, dürfen Sales-Decks als Beleg dienen, sind Teams-Chats zitierfähig? Wer diese Fragen nicht beantwortet hat, bekommt vom besten Schreibprozess nur schöner belegte falsche Sätze.

Eine praktikable Ordnung hat drei Stufen:

• Autoritative Quellen dürfen Behauptungen tragen: unterschriebene Verträge, verabschiedete Policies, auditierte Berichte, freigegebene Produktdokumentation.
• Kontextquellen dürfen informieren, aber nicht allein beweisen: Sitzungsnotizen, E-Mails, Projektnotizen, Sales-Decks. Nützlich für die Outline, zu schwach als einziger Anker einer kundengerichteten Zahl.
• Unsichere Quellen gehören gar nicht in den Recherche-Korpus: alte Offerten mit überholten Konditionen, PDF-Duplikate unklarer Herkunft, unkontrollierte Exporte, ungeprüfte Web-Schnipsel.

Diese Unterscheidung ist auch die ehrliche Grenze jeder technischen Beweiskette, die dieser Artikel später beschreibt: Sie bewahrt die Identität einer Passage, nicht ihre Qualität. Ein perfekt auflösbares Zitat auf ein veraltetes PDF ist perfekt auflösbar — und trotzdem falsch. Quellentreue ist nicht Wahrheit; welche Quellen überhaupt zählen, bleibt eine menschliche Vorentscheidung.

Dazu gehören Rollen mit Namen, nicht Zuständigkeiten im Ungefähren: Ein Auftraggeber definiert Zweck, Zielgruppe und No-Go-Claims. Ein Quellenverantwortlicher pflegt den freigegebenen Korpus und sortiert Veraltetes aus. Ein Fachexperte prüft die Behauptungen gegen die Quellen. Ein Freigeber trägt die Verantwortung für das Dokument. In einem kleinen KMU sind das vielleicht zwei Personen — aber die Hüte müssen benannt sein. Sprechen Sie intern deshalb weniger über «Halluzinationen», als wäre das ein Wetterphänomen, und mehr über Behauptungs-Verantwortung: Wer steht für diesen Satz, gestützt auf welche Quelle?

Genehmigen Sie den Plan, nicht die Prosa

Fertige KI-Prosa zu korrigieren ist die teuerste Art, einen Denkfehler zu entdecken. Der Text hat bereits Rhythmus, Übergänge und scheinbare Sicherheit; jede Korrektur fühlt sich an, als würde man ein fertiges Möbelstück wieder in Bretter zerlegen. Eine recherchierte Outline ist anders. Sie zeigt die Logik, bevor sie Charme bekommt.

Was der Mensch in meinem Flow konkret freigibt, ist deshalb mehr als eine Gliederung. Jeder Outline-Punkt trägt typisierte Evidenz-Referenzen — maschinenlesbare Verweise auf konkrete Belegstellen aus der Recherche, nicht Fussnoten-Prosa. Gefüttert wird der Outliner von einem Recherche-Dossier, das auch das Unbequeme ausweist: alle Recherchefragen inklusive derer, die keine Evidenz ergaben, eine Karte des durchsuchten Korpus und explizite Warnflaggen für dünnes Terrain. Der Freigabe-Moment ist damit keine rhetorische Geste («wurde gegen Quellen geprüft»), sondern ein Blick auf ein Artefakt, in dem jede geplante Behauptung ihre Belege bereits bei sich trägt — oder sichtbar keine hat.

Die externe Evidenz stützt diesen Punkt, aber sie trägt ihn nicht weiter, als sie tragen darf. LongEval berichtet bei planbasierter Generierung deutlich höhere Kohärenzwerte als bei Direktgenerierung (arXiv:2502.19103); STORM zeigt, dass Pre-Writing-Qualität und Finalqualität zusammenhängen (Shao et al.). Beide Linien messen Struktur und Organisation, nicht die faktische Belastbarkeit von Schweizer Geschäftsberichten. Genau darum ist die Outline-Freigabe nur der frühe Kontrollpunkt. Die Schlussprüfung bleibt.

Wer Human-in-the-Loop als Freigabemechanik tiefer bauen will, landet bei denselben Fragen wie in Approval-Gates und Audit-Trails: Was sieht der Mensch, was darf er ändern, was wird protokolliert, und was passiert bei Ablehnung?

Zitate als Vertrag: accurate, overstated, unsupported

Ein Zitat ist kein Schmuck am Satzende. Es ist ein Vertrag: Diese Quelle trägt genau diese Behauptung. Wer KI-Texte prüfen will, darf deshalb nicht nur fragen, ob die Quelle existiert. Die bessere Frage lautet: Sagt die Quelle das wirklich, in dieser Stärke, mit dieser Einschränkung?

Die gefährlichste Fehlerklasse ist die echte Quelle, die falsch dargestellt wird. Eine SIGIR-ICTIR-Studie trennt Citation correctness von Citation faithfulness und fand, dass bis zu 57 Prozent der Zitationen post-rationalisiert sein können. Die Quelle passt irgendwie, aber sie war nicht wirklich die tragende Basis des Claims. Für den Leser sieht das seriös aus. Für den Prüfer beginnt dort die Arbeit.

Die drei Verdikte in der Zwischenüberschrift sind übrigens keine didaktische Erfindung für diesen Artikel. Es ist wörtlich das strukturierte Ausgabeschema meines Prüf-Passes: accurate, overstated, unsupported — plus eine vierte Kategorie, die viele vergessen: Behauptungen, die gar kein Zitat tragen, obwohl sie eines bräuchten. Diese unbelegten Claims greifen das Post-Rationalisierungs-Problem von der anderen Seite an: Das System markiert nicht nur falsche Anker, sondern auch fehlende.

Ein fiktives Mini-Beispiel: In einer Offerte zu «Wuxi Bearings» steht, ein Lieferant habe «nachweislich alle Audit-Mängel geschlossen». Die Quelle sagt aber nur, dass ein Korrekturplan eingereicht wurde. Das ist nicht erfunden. Es ist schlimmer für die Freigabe: Es klingt belegt und ist trotzdem überzeichnet.

Entscheidend ist die asymmetrische Behandlung der Verdikte, und sie ist eine dokumentierte Engineering-Entscheidung: Ein unsupported-Zitat wird deterministisch aus dem Text entfernt — der Anker war falsch, weg damit. Ein overstated-Claim wird dagegen nie automatisch umgeschrieben; der Prüf-Pass liefert einen Abschwächungsvorschlag als Annotation an den Menschen. Der Grund steht sinngemäss im Code: Regex-Umbau von Prosa ist fragil, und falsche Sicherheit ist teurer als sichtbare Arbeit. Automatische Verifier bestätigen diese Vorsicht: Galtea zeigte 2025 an einem GPT-4.1-Faithfulness-Judge, dass ein generischer Prompt 0 von 9 Halluzinationen erkannte, obwohl er 20 von 21 faithful responses korrekt passieren liess. Und volle Transparenz: Dieser Batch-Prüf-Pass ist bei mir opt-in, nicht Default — wer ihn aktiviert, bekommt das beschriebene Verhalten; wer ihn nicht aktiviert, hat keine semantische Prüfung bestellt.

Neben dem Batch-Auditor gibt es ein zweites, schärferes Werkzeug: einen Zitat-Inspektor im Editor. Klick auf ein Zitat, «Check claim» — und das System zerlegt den Satz in atomare Behauptungen (Subjekt, Prädikat, Objekt, Geltungsbereich, Zeitraum) und vergleicht zuerst die Behauptung mit der zitierten Passage: deckungsgleich, überzeichnet, ungestützt oder mehrdeutig. Danach durchsucht es die gesamte persistierte Projekt-Recherche nach Bestätigung und Widerspruch — inklusive gezielter Gegenbeweis-Abfragen, die das Prädikat invertieren («gestiegen» → «gesunken», «unverändert»), und der Nachbar-Chunks der zitierten Stelle. Die Disziplin dabei ist die eigentliche Pointe: Ein Konflikt heisst nur dann Konflikt, wenn Subjekt, Prädikat, Objekt, Geltungsbereich und Zeitraum übereinstimmen — sonst «möglicher Konflikt». Und das Resultat sagt «keine stärkere Quelle in diesem Projekt gefunden», nie «es existiert keine stärkere Quelle». Das ist die operationalisierte Version der Frage von oben: Sagt die Quelle das wirklich, in dieser Stärke, mit dieser Einschränkung — Behauptungs-Atom für Behauptungs-Atom. Für die Messlogik dahinter passt Tracing und Evals für Agenten.

Die Beweiskette: damit ein Zitat klickbar bleibt

Ein klickbares Zitat ist das Ende einer Lieferkette. Wenn in einem fertigen Dokument eine Zahl steht und ein Klick darauf das Original-PDF an der markierten Stelle öffnet, dann hat eine Kette von Systemen die Identität dieser Passage über jeden einzelnen Übergabepunkt bewahrt — vom SharePoint-Scan bis zum Overlay auf der Seite. Juristen haben dafür ein Wort: Beweiskette. Jedes Glied, das die Identität verliert, macht alle Glieder danach wertlos. Das ist der Teil, den «unsere KI liefert Quellenangaben» im Datenblatt verschweigt, und er besteht aus drei Problemen.

Erstens: Eine Passage braucht eine Geometrie. Damit ein Zitat auf eine markierte Stelle zeigen kann, braucht jedes Dokument eine kanonische, unveränderliche Seiten-Geometrie. Deshalb wird bei mir alles, was kein PDF ist, zuerst zu einem PDF — Office-Dokumente per Konvertierung, Text- und Tabellenformate per Headless-Browser-Rendering — und dieses kanonische PDF wird gehasht und dauerhaft aufbewahrt. Die Layout-Analyse (Azure Content Understanding) läuft auf genau dieser Darstellung, und der Viewer zeigt später genau sie: Die Koordinaten, die bei der Analyse entstanden, bleiben für immer gültig, und Abweichungen zur inzwischen weiterbearbeiteten Live-Datei sind über den Hash erkennbar. Das klingt pedantisch, ist aber eine dokumentierte Kehrtwende: Der erste Versuch, Layout-Analyse direkt auf Word und HTML laufen zu lassen, produzierte fehlende Dimensionen und kaputte Markierungen. Ohne stabile Geometrie kein Overlay. Audio und Video brauchen keine Seiten und ankern stattdessen über Zeitmarken.

Zweitens: Eine Passage braucht eine Identität. Die kleinste zitierbare Einheit ist bei mir weder «das Dokument» noch «der Chunk», sondern ein Block: ein Absatz, eine Tabellenzelle, ein Bildverweis — mit Seite, Polygon und einer inhaltsadressierten ID, einem Hash über Dokument, Revision, Anker und Textinhalt. Dieselbe Passage bekommt bei jedem Re-Index dieselbe ID; eine neue Dokumentversion bekommt eine neue. Und der entscheidende Kniff sitzt im Text selbst, den das Modell zu sehen bekommt: Jede Zeile des Beleg-Texts beginnt mit ihrer Block-ID. Das Modell liest seinen Zitierschlüssel im Material, bevor es ihn verwendet — es muss keine Referenz erfinden, es muss nur abschreiben. Im Suchindex gilt dazu eine harte Regel: Von drei Index-Ebenen (Dokument, Abschnitt, Beleg) ist nur die Beleg-Ebene zitierfähig; die oberen zwei sind Navigation. Das erzwingt die Datenschicht, nicht ein Prompt.

Drittens — und das ist der Teil, an dem die meisten Architekturen scheitern: Die Identität muss den Graphen überleben. In einem komplexen Lauf recherchieren mehrere Agenten parallel, ein Synthese-Schritt fasst Zwischenergebnisse zusammen, ein weiterer baut darauf auf, und am Ende schreibt ein letztes Modell die Antwort. Jede dieser Übergaben ist eine Gelegenheit, Provenienz zu verlieren. Meine Antwort darauf ist eine Quellen-Registry, die als Teil des Graph-Zustands mitreist: Jeder Recherche-Knoten registriert jeden Treffer im Moment des Findens, mit einer hash-stabilen ID aus dem kanonischen Quellschlüssel — finden zwei parallele Agenten dieselbe Passage, kollabiert sie deterministisch zu einer Quelle mit einer Nummer. Parallele Zweige des Graphen werden verlustfrei zusammengeführt (gleiche Quelle: erster Eintrag gewinnt; Zähler: Maximum), sodass auch ein verzweigter Lauf am Ende ein konsistentes Quellenverzeichnis hat. Jedes Modell im Graphen sieht seine Belege im selben Vertragsformat — Quellennummer, Block-IDs, voller Wortlaut — und der Prompt-Vertrag verlangt Inline-Zitate direkt hinter der gestützten Aussage, mit exakt den vergebenen Nummern. Reicht ein Synthese-Schritt seine Prosa an den nächsten weiter, wandern die Inline-Zitate mit, plus ein Anhang mit dem Wortlaut jedes zitierten Blocks — das nachgelagerte Modell kann weiterzitieren, ohne neu zu suchen und ohne dass die Herkunft verwässert.

Und am Schluss das Misstrauen, das den Unterschied macht: Dem Modell wird nie geglaubt, dass seine Zitatliste stimmt. Die Zitate werden nach der Generierung per Parser aus der Prosa extrahiert und einzeln gegen die Registry aufgelöst: Existiert die Nummer? Validiert der Block? Führt die Quelle zu gespeichertem Text samt Geometrie? Ein Zitat, das sich nicht auflösen lässt, wird verworfen — laut, mit Warnung im Log, nicht leise. Was übrig bleibt, ist per Konstruktion einlösbar: Klick, Original-PDF, Seite, markierte Stelle. Parallel schreibt der Lauf sein komplettes Quellenregister in die Datenbank — der Freigabe-Klick der Projektleiterin ist keine UI-Geste, sondern eine versionierte Zeile neben der Outline, die sie gesehen hat, und der Evidenz, die dahinterstand.

Zwei Grenzen dieser Garantie gehören dazu, weil sie den Unterschied zwischen Engineering und Marketing ausmachen. Die Kette garantiert Validität: Jedes überlebende Zitat löst sich zu einer echten, gespeicherten, geometrisch verorteten Passage auf. Sie garantiert nicht Abdeckung: Ob jede Behauptung ein Zitat trägt, erzwingt der Prompt-Vertrag und prüft der Auditor — mechanisch beweisbar ist es nicht. Validität wird erzwungen, Abdeckung bleibt ein Versprechen. Und die Kette garantiert Auflösbarkeit, nicht Wahrheit: Ob die zitierte Passage die Behauptung wirklich in dieser Stärke trägt, ist die semantische Frage aus dem letzten Abschnitt — dafür gibt es den Prüf-Pass und den Inspektor, und am Ende den benannten Menschen. «Klick-prüfbar» und «claim-geprüft» sind zwei verschiedene Eigenschaften. Systeme, die beides in einem Atemzug versprechen, verkaufen die zweite meistens gar nicht.

Ich habe es zuerst kompliziert gebaut – und nach zwei Tagen ersetzt

Wer die Beweiskette liest, könnte vermuten, hier sei jemand der Komplexität verfallen. Die Geschichte lief umgekehrt — und sie ist datiert.

Meine erste Version war das, was man baut, wenn man zu viel Respekt vor dem Problem hat: sieben Phasen, sechs Schreib-Archetypen, rund 140 geplante Dateien, Zwischenmodelle für Argumente, Sektionen, Kritik, Reader Simulation und Assembly. Die Spezifikation datiert vom 9. Februar 2026. Auf dem Papier sah das sorgfältig aus. In der Praxis war jede Zwischenschicht ein neuer Ort, an dem Stimme, Beleg und Absicht auseinanderdrifteten.

Am 11. Februar — zwei Tage später, beide Dokumente sind datiert — ersetzte ich diesen Entwurf durch die Gegenposition: «the model is the writer, the system is the research librarian». Die zweite Spec reduzierte den Flow auf drei Phasen und einen Ein-Pass-Entwurf, mit Begründungen, die brutal genug waren, um hängen zu bleiben: «every abstraction layer between evidence and prose is a place where quality degrades» und, als Arbeitsregel, «Minimize transformations. Evidence should travel from search results to the writer's prompt with as few intermediate representations as possible.» Ich habe mich also nicht von einfach zu komplex vorgearbeitet, sondern von komplex zurück zu tragfähig.

Die ehrliche Pointe kam später, und sie schärft die These, statt sie zu beschädigen: Geshippt sind heute nicht die geschätzten ~18 Dateien der schlanken Spec, sondern rund 44. Gewachsen ist aber nicht die Prosa-Orchestrierung — gewachsen sind genau die Dinge, die dieser Artikel beschreibt: das Recherche-Dossier, die deterministische Suchmaschine, die Evidenz-Verifikation der Outline, der Zitat-Inspektor. Die Einfachheit an der Prosa-Schicht hat Raum gekauft für Strenge an der Evidenz-Schicht. Das ist die präzisere Lektion als «einfacher ist besser»: Sparen Sie Komplexität dort, wo sie Qualität frisst, und investieren Sie sie dort, wo sie Qualität beweisbar macht.

Das heisst nicht: langer Ein-Pass-Entwurf ist magisch sicher. Zhao et al. zeigen mit «facts exhaustion», dass längere Antworten factual precision verlieren. Gerade deshalb muss die Einfachheit an der richtigen Stelle sitzen: Kontext sauber zusammenstellen, Claims eng an die Outline binden, Belege blockgenau mitgeben, danach prüfen. Mehr Orchestrierung ist kein Qualitätsersatz. Manchmal ist sie nur ein sehr fleissiger Weg, den Fehler besser zu verstecken.

Warum die Recherche hier keinen Agenten bekommt

Für Recherche, deren Ergebnis ein Mensch freigibt, ist Wiederholbarkeit kein Luxus. Sie ist Teil der Governance. Deshalb kompiliert in meinem Writing-Assistant ein LLM ein Suchprogramm mit Facetten und Query-Varianten; danach führt eine deterministische Engine die Suche aus. Kein frei laufender ReAct-Loop, der unterwegs selbst entscheidet, welche Spur als Nächstes spannender wirkt.

Drei Präzisierungen, damit der Satz hält. Erstens gibt es innerhalb der Engine genau einen begrenzten LLM-Einsatz: einen Gap-Strategen, der nur dann aufgerufen wird, wenn die Abdeckungsprüfung zwischen zwei Suchpässen scheitert — er darf diagnostizieren und nachjustieren, aber nicht frei navigieren. Das ist kein Widerspruch zur These, sondern ihre Verfeinerung: Ein LLM darf im Suchpfad denken, aber nicht steuern. Zweitens gilt die Aussage für die Wissensdatenbank-Recherche dieses Schreib-Flows — der Web-Recherche-Zweig nutzt ein agentisches Deep-Research-Produkt, und die Chat-Seite derselben Anwendung fährt bewusst autonome Retrieval-Agenten. Der Unterschied ist kein Stilbruch, sondern genau das Kriterium dieses Artikels: Deterministisch, wo das Ergebnis eine menschliche Freigabe füttert; agentisch, wo Exploration zählt. Drittens ist auch die deterministische Variante nicht automatisch gut — sie ist nur auditierbar, und der Audit hat geliefert.

Mein eigener Query-Audit fand drei konkrete Schwächen: Ein einziger Query-String treibt Stichwortsuche, Vektorsuche und Semantic Ranker zugleich; zu knappe k=20-Einstellungen liessen den Semantic Ranker verhungern; und die dokumentierte bessere Query-Fusion war nicht umgesetzt. Stand heute ist eine davon auf dem Schreibpfad behoben — dedizierte Suchprofile mit k=50 und grosszügigerem Text-Recall —, zwei sind offen und dokumentiert. Genau das ist der Punkt: Eine deterministische Pipeline, die ihre offenen Befunde ausweisen kann, ist das beste Argument für sich selbst. Einen Agenten kann man auch beobachten, aber sein Entscheidungsraum ist breiter, und «welche Suchabsicht führte zu welchem Beleg» ist nachträglich schwerer zu rekonstruieren. Für KMU ist die Frage nicht «modern oder alt», sondern: Wo brauchen wir Freiheit, und wo brauchen wir Reproduzierbarkeit? Die Entscheidungsmatrix dazu liegt in Workflow oder Agent; die Retrieval-Tiefe gehört in RAG, das in Produktion hält.

Rechnet sich das überhaupt?

Der ehrlichste Satz in jedem KI-Schreibprojekt lautet: Vielleicht nicht für diese Aufgabenklasse. Wenn die Zitatprüfung regelmässig länger dauert als Selberschreiben, stoppen Sie den KI-Einsatz dort. Nicht überall. Dort.

Die Produktivitätsevidenz ist kein Werbeplakat, sondern ein Schalterkasten. METR fand 2025 in einer RCT mit erfahrenen Open-Source-Entwicklern, dass diese mit AI-Tools 19 Prozent länger brauchten, obwohl sie nachher glaubten, 20 Prozent schneller gewesen zu sein. METR selbst stuft dieses Resultat inzwischen als historisch ein: Das Update vom Februar 2026 hält fest, dass neuere Daten wegen Selektionseffekten schwer zu deuten sind, aber eher auf einen grösseren Speedup hindeuten als 2025. Die Lehre daraus ist deshalb nicht «KI bremst». Die Lehre ist: Gefühlter Produktivitätsgewinn ist ohne saubere Messung unzuverlässig — die Entwickler lagen um fast 40 Prozentpunkte neben ihrer eigenen Wahrnehmung. Der Transfer von Software auf Geschäftsschreiben ist ohnehin eine Inferenz, kein Beweis. Aber die Warnung trägt: Gefühlter Speedup ist keine Kostenrechnung.

Auf der anderen Seite stehen echte Gewinne. Noy und Zhang fanden bei professionellen Schreibaufgaben 40 Prozent weniger Zeit und 18 Prozent höhere Qualität. Brynjolfsson, Li und Raymond fanden im Kundensupport 15 Prozent mehr gelöste Fälle pro Stunde, mit grösseren Gewinnen bei weniger erfahrenen Mitarbeitenden. Das ist kein Widerspruch, sondern Segmentierung: Aufgabe, Erfahrung und Prüflast entscheiden. Ein 2'000-Wörter-Konzept mit Marktbehauptungen, Kundennutzen und Rechtsnuancen ist eine andere Liga als eine enge Zusammenfassung mit klarer Quelle. Auch die laufenden Kosten sind übrigens Engineering, keine Hoffnung: In meiner Pipeline hat jeder Verarbeitungsschritt ein deklariertes Token-Budget — Evidenz bekommt den Platz, Dekoration nicht.

Praktisch wird die Stop-Regel erst, wenn sie nach Dokumenttyp differenziert:

• Frei einsetzen für Struktur, Umformulierung, Zusammenfassungen und erste Outlines — dort ist die Prüflast minimal und der Hebel gross.
• Mit Claim-Prüfung einsetzen für Offerten, Kundenberichte, VR-Memos und Policy-Entwürfe — der Prozess dieses Artikels ist genau für diese Klasse gebaut.
• Nicht als Hauptautor einsetzen für Rechtsberatung, sicherheitskritische Anleitungen, HR-Entscheide und regulierte Finanzaussagen, solange kein formalisiertes Fachexperten-Review dahintersteht.

Darum ist die Stop-Regel kein Pessimismus. Sie schützt Budget.

So machen Sie das ab Montag – auch nur mit Copilot

Sie brauchen für den Anfang keine eigene Pipeline. Sie brauchen eine andere Arbeitsanweisung an sich selbst und an das Modell.

AP, NYT und Reuters behandeln AI in Redaktionskontexten ähnlich vorsichtig: hilfreich für Recherche, Struktur, Transkription oder erste Fassungen; Verantwortung und Verifikation bleiben bei Menschen. Für ein KMU ist das keine Medienethik, sondern eine Betriebsregel. Ein Kundenbericht, eine Offerte oder ein Verwaltungsratsmemo darf nicht deshalb durchgehen, weil ein Text angenehm klingt.

So kann es bei Ihnen aussehen: Eine Projektleiterin erstellt am Morgen eine Quellenliste aus SharePoint, lässt daraus eine Outline für eine Offerte bauen und gibt nur die Abschnitte frei, deren Belege tragen. Der Entwurf entsteht danach schnell. Die gesparte Zeit fliesst nicht in mehr Text, sondern in die Prüfung der fünf Sätze, die morgen beim Kunden nachgefragt werden. Und in der Ausbaustufe mit Beweiskette geht die Szene einen Schritt weiter: Beim Kunden klickt sie auf die Zahl in der Offerte, und das Original-PDF öffnet sich an der markierten Stelle. Alles in diesem Artikel funktioniert ab Montag mit Copilot und Disziplin — und ab dem Punkt, wo Sie pro Behauptung auf die Textstelle im Original klicken wollen, beginnt der Maschinenbau aus dem Beweisketten-Abschnitt.

Wenn Sie dieses Vier-Schritte-Muster im eigenen Team verankern wollen, mit Ihren Dokumenttypen, Quellen und Freigabewegen, ist ein PowerLeap-Inhouse-Training genau dafür gedacht: mehr als Prompt-Training, nämlich Entscheidungsfähigkeit darüber, was produziert wird, welche Quellen zählen und wo die Prüfung hingehört.

Was das heisst, wenn Sie so etwas kaufen oder bauen wollen

Damit Sie Angebote einordnen können — die eigenen Ambitionen eingeschlossen — hilft eine ehrliche Dreiteilung.

Stufe 1: Copilot plus Disziplin. Der Montag-Workflow oben. Kostet nichts Zusätzliches, funktioniert sofort, und die Verifikation ist Handarbeit. Zitate sind Dokumentnamen und Absatzangaben, die ein Mensch nachschlägt. Für viele Dokumenttypen ist das genug — und es ist der richtige Startpunkt, weil er das Muster etabliert, bevor Geld fliesst.

Stufe 2: RAG mit Quellenlinks. Eine Suche über die eigenen Dokumente, Antworten mit Links auf Dokument- oder URL-Ebene. Das ist es, was die meisten Anbieter als «grounded» verkaufen. Der Evidenz-Abschnitt am Anfang dieses Artikels dokumentiert, warum das allein noch keine belastbaren Texte ergibt: Die Quelle existiert, aber niemand erzwingt, dass sie den Satz trägt — und niemand kann auf die Stelle klicken.

Stufe 3: Die Beweiskette bis zur Passage. Kanonische PDFs, inhaltsadressierte Blöcke, ein Beleg-Index mit Geometrie, eine Registry durch den Graphen, Verifikation als Schema. Die Azure-Bausteine dafür kann man einkaufen — Layout-Analyse, Suche mit Semantic Ranker, Datenbank, Identitäts- und Berechtigungsdienste. Was man nicht im Portal zusammenklicken kann, sind vier Design-Entscheidungen: ein Identitäts-Schema für Passagen (inhaltsadressiert, revisionsbewusst), ein Registry-Kontrakt, der Übergaben zwischen Agenten und Modellen verlustfrei übersteht, zwei getrennte Berechtigungsmodelle — die Ingestion darf breit lesen, das Retrieval wird pro Nutzer getrimmt, denn ein Zitat ist nur verteidigbar, wenn die Person es auch hätte abrufen dürfen — und Verifikation als Schema statt als Bauchgefühl. Das ist Wochen bis Monate Engineering, kein Wochenende. Dafür ist es die einzige Stufe, auf der «prüfbar» eine Eigenschaft des Systems ist und nicht ein Appell an die Sorgfalt.

Auf den Microsoft-Stack übersetzt, nach Situation statt nach Produktnamen:

Die richtige Stufe ist die tiefste, die Ihre Prüflast trägt. Eine interne Wissensnotiz braucht keine Polygon-Overlays. Eine Offerte mit haftungsrelevanten Behauptungen, die drei Abteilungen durchläuft, vielleicht schon.

Ehrlichkeits-Box + Compliance

Stand: 7. Juli 2026

Ein glaubwürdiger Artikel über KI-Texte mit Belegen muss sagen, was nicht gemessen ist. Für den hier beschriebenen Workflow gibt es keine Produktions-Telemetrie, die «≥95 Prozent Zitatgenauigkeit» beweist; solche Zahlen sind Designziele, keine Resultate — ein Eval-Harness ist eine dokumentierte offene Lücke. Präzise ist auch der Status der Verifikation: Die semantische Zitatprüfung (accurate/overstated/unsupported) ist opt-in, nicht Default; wenn sie läuft, werden unbelegte Zitate automatisch entfernt und überzeichnete nur annotiert, nie umgeschrieben. Davon zu trennen ist die strukturelle Garantie der Beweiskette — jedes Zitat löst sich zu einer echten Passage auf oder wird verworfen —, die überall mechanisch erzwungen ist. «Klick-prüfbar» ist immer wahr; «claim-geprüft» nur, wo die Prüfung bestellt wurde. Weitere ehrliche Ränder: Web-Zitate sind nur blockgenau, wenn ein archivierter Snapshot samt validiertem Wortlaut existiert, sonst URL-genau; Tabellenzitate auf Zellen-Ebene sind im Schema vorbereitet, aber die Ingestion konvertiert Excel heute zu PDF. Und niemand hat sauber gemessen, ob eine Stunde Outline-Review bei Schweizer Geschäftsdokumenten mehr bringt als dieselbe Stunde Draft-Review.

Die Compliance-Lage ist ebenfalls enger und praktischer, als viele Vendor-Texte klingen. EU AI Act Art. 50 trifft AI-generierten Text vor allem dort, wo er zur Information der Öffentlichkeit veröffentlicht wird; bei menschlicher redaktioneller Verantwortung gibt es wichtige Ausnahmen (Art. 50). Der genaue Zeitplan und Code-of-Practice-Status gehören vor Publikation nochmals geprüft. Für gewöhnliche Kundenberichte und Offerten ist die Frage meist weniger «müssen wir labeln?» als «können wir belegen, wer was geprüft hat?» — und genau diese Frage beantwortet die Beweiskette wörtlich: Freigaben, Outline-Versionen, Quellenregister und Modell-Aufrufe liegen als Audit-Spur in der Datenbank, nicht in der Erinnerung der Beteiligten.

Für die Schweiz gilt Stand heute: Es gibt kein horizontales Pendant zum EU AI Act in Kraft; Datenschutz-, Berufs- und Haftungsregeln greifen trotzdem. Der Relevanzdruck ist real: Bitkom meldete 2026, dass 41 Prozent der deutschen Unternehmen AI aktiv nutzen; Text und Übersetzung gehören zu den sichtbarsten Anwendungsfällen.

Der Schluss ist derselbe wie am Anfang, nur mit mehr Boden unter den Füssen: Kein Tool, kein Grounding und kein Prozessschritt ist der Safety Case. Belastbar wird ein KI-Geschäftstext erst, wenn ein benannter Mensch sagen kann: Diese Behauptungen habe ich gegen diese Quellen geprüft. Die Beweiskette macht diese Prüfung zum Klick statt zur Recherche — aber sie nimmt sie niemandem ab. Ab morgen können Sie genau dort anfangen: nicht mit einem besseren Blankoprompt, sondern mit einem Plan, den Sie freigeben können.