Kategorie: AI in Practice

Das Drei-Regeln-Framework #5, in der Cybersecurity: Blue, Red und Purple Team

Das Drei-Regeln-Framework in der Cybersecurity: Blue, Red und Purple Team

Dies ist der fünfte Beitrag einer Serie über das Drei-Regeln-Framework — Leerlassen erzwingen, Raten bestrafen, Quelle zeigen. Das Framework wurde bisher auf Dokumentextraktion, Worldbuilding, Szenarioplanung und Implementierung im Organisationskontext angewandt.

Dieser Beitrag wendet es auf eine Domäne an, in der die Einsätze so hoch sind wie kaum anderswo: Cybersecurity.

Das strukturelle Problem ist bekannt. KI generiert selbstbewusst klingende Sicherheitsbewertungen, die verifizierte Befunde mit Inferenzen und Annahmen vermischen — und niemand kann unterscheiden, was was ist. Ein Schwachstellen-Scan-Ergebnis steht neben einer architektonischen Inferenz neben einer ungetesteten Annahme über Netzwerksegmentierung, alles mit der gleichen Zuversicht präsentiert. Der Output sieht gründlich aus. Manches ist fundiert. Manches wurde erfunden, damit das Narrativ zusammenhält.

Bei der Szenarioplanung kostet das Planungsressourcen. In der Cybersecurity ist es ein Breach, der darauf wartet zu passieren.

Warum die Cybersecurity besonders anfällig ist

Ein Survey-Paper von 2025 über Halluzinationen in KI-gestützten Cybersecurity-Systemen identifiziert das Kernrisiko: KI-Modelle, die auf Sprachfluss optimiert sind, können sichere Aktivitäten fälschlich als Bedrohung einstufen oder tatsächliche Gefahren übersehen — und tun beides im selben selbstbewussten Ton, unabhängig davon, ob ihre Bewertung evidenzbasiert ist. Das Design-Ziel Sprachfluss vor Genauigkeit verstärkt das Problem: Modelle produzieren hochkonfidente Aussagen auch ohne faktische Fundierung.

Die OWASP Foundation listet KI-Halluzination in ihrer Ausgabe 2025 unter den Top-Risiken für LLM-gestützte Sicherheitstools. Das Problem sind nicht isolierte False Positives oder False Negatives — es ist die Vermischung von realen Befunden und fabrizierten Bewertungen in einem einzigen Output, den Menschen dann als gleichmäßig zuverlässig behandeln.

Die Lücken-Labels für Cybersecurity

Zwei Lücken-Labels gelten teamübergreifend:

  • [SICHTBARKEITSLÜCKE] — etwas, das das Team nicht sehen kann oder nicht instrumentiert hat: unüberwachte Netzwerksegmente, fehlende Log-Quellen, Schatten-IT, Cloud-Services ohne Telemetrie
  • [VALIDIERUNGSLÜCKE] — eine Kontrolle oder Erkennungsregel, die auf dem Papier oder in der Konfiguration existiert, aber nie gegen tatsächliches Angriffsverhalten getestet wurde

Die Unterscheidung ist entscheidend. Eine Sichtbarkeitslücke bedeutet: Sie haben die Daten nicht. Eine Validierungslücke bedeutet: Sie haben die Daten (oder glauben es), aber haben nicht bewiesen, dass die Erkennung tatsächlich funktioniert. Beides ist gefährlich; es erfordert unterschiedliche Maßnahmen.

Blue Team: Verteidigung

Die Wahrheitsquelle des Blue Teams ist: was über die Verteidigungslage durch direkte Evidenz bestätigt wurde — nicht was die Policy sagt, nicht was der Hersteller verspricht, nicht was wahr sein sollte.

Forschung von Mitiga legt nahe, dass traditionelle SIEMs im Durchschnitt nur etwa 21 % der MITRE ATT&CK-Techniken erkennen — das heißt, bei rund vier von fünf Technikkategorien gibt es keine validierte Erkennungsabdeckung. Dennoch berichten viele Organisationen deutlich höhere Coverage-Zahlen, weil sie konfigurierte Regeln zählen statt validierte Erkennungen. Die Kluft zwischen „Wir haben eine Regel dafür“ und „Diese Regel hat bei einem realen Angriff korrekt ausgelöst“ ist genau die Kluft, die das Framework offenlegt.

AttackIQs Analyse vom März 2026 hat es treffend formuliert: Coverage ist nicht statisch, Umgebungen ändern sich, und eine Erkennung, die letzten Monat funktionierte, kann diesen Monat still kaputtgegangen sein. Ein Teilnehmer eines Webinars brachte es auf den Punkt: Erkennungen zu haben bedeutet nichts, wenn sie kein Signal produzieren, auf das das Team reagieren kann.

Blue Team Quellen-Tags

  • (VERIFIZIERT) — bestätigt durch direkte Evidenz: getestete Kontrolle, beobachteter Log-Eintrag, validierte Konfiguration, Scan-Ergebnis mit Zeitstempel
  • (POLICY-DOKUMENTIERT) — in Policy, Konfigurationsleitfäden oder Herstellerdokumentation beschrieben, aber nicht unabhängig validiert
  • (INFERIERT) — aus indirekten Indikatoren abgeleitet. „Keine Alerts in 90 Tagen“ heißt nicht „keine Einbrüche in 90 Tagen“ — es könnte heißen, die Erkennung funktioniert nicht

Blue Team Prompt

Du bist ein defensiver Sicherheitsanalyst, der unsere Umgebung überprüft. Tagge jede Sicherheitsaussage mit ihrer Evidenzbasis:

• (VERIFIZIERT) — bestätigt durch direktes Testen, Log-Evidenz oder Scan-Ergebnisse. Nenne die konkrete Evidenz.

• (POLICY-DOKUMENTIERT) — in Policy oder Konfigurationsleitfäden dokumentiert, aber nicht unabhängig validiert. Beschreibe, wie eine Validierung aussehen würde.

• (INFERIERT) — aus indirekten Indikatoren abgeleitet. Nenne die Inferenzkette und was sie ungültig machen könnte.

• Wenn du eine Kontrolle oder einen Abdeckungsbereich identifizierst, der nicht getestet oder instrumentiert wurde, markiere ihn als [SICHTBARKEITSLÜCKE] oder [VALIDIERUNGSLÜCKE] mit kurzer Erklärung.

• Ein falsches Sicherheitsgefühl ist gefährlicher als eine bekannte Lücke. Eine bekannte Lücke wird budgetiert. Falsches Vertrauen wird gehackt. Im Zweifel markiere die Lücke.

Blue Team Beispiel-Output

Kontrolle Status Quelle Anmerkung
MFA auf VPN Aktiviert POLICY-DOKUMENTIERT Azure AD Conditional Access Policy verlangt MFA. [VALIDIERUNGSLÜCKE: kein Pentest hat Durchsetzung auf dem Cisco AnyConnect Endpoint verifiziert]
EDR-Abdeckung 94 % der Endpoints VERIFIZIERT CrowdStrike Dashboard, abgerufen April 2026
Lateral-Movement-Erkennung Aktiv INFERIERT SIEM hat Regeln für Pass-the-Hash. Kein Purple-Team-Exercise hat getestet, ob sie auslösen. [VALIDIERUNGSLÜCKE]
DNS-Exfiltration-Erkennung — SICHTBARKEITSLÜCKE Kein DNS-Logging auf internen Resolvern konfiguriert. DNS-Tunneling nicht erkennbar.

Red Team: Offensive

Die Wahrheitsquelle des Red Teams ist: was durch tatsächliche Exploitation demonstriert wurde — nicht was verwundbar sein sollte, nicht was Shodan zeigt, nicht was die CVE-Datenbank nahelegt.

Red Team Quellen-Tags

  • (BESTÄTIGT) — Schwachstelle ausgenutzt, Zugang erreicht, Daten exfiltriert — mit Evidenz (Screenshot, Hash, Artefakt, Session-Log)
  • (INDIZIERT) — starke Indikatoren für Verwundbarkeit, aber Exploitation noch nicht versucht: Versions-Fingerprint passt zu bekanntem CVE, Default-Credentials erkannt aber nicht getestet
  • (HYPOTHETISIERT) — Angriffspfad existiert theoretisch auf Basis der Architekturanalyse, aber ungetestet. Nennt die Annahmen, von denen der Pfad abhängt

Red Team Prompt

Du bist ein Red-Team-Operator, der potenzielle Angriffspfade analysiert. Tagge jedes Finding oder jeden Angriffspfad:

• (BESTÄTIGT) — Schwachstelle ausgenutzt und Zugang demonstriert. Nenne die spezifische Evidenz (Tool-Output, Artefakt, Hash).

• (INDIZIERT) — starke Indikatoren deuten auf Verwundbarkeit hin, aber Exploitation wurde nicht versucht. Nenne die Indikatoren.

• (HYPOTHETISIERT) — Angriffspfad ist theoretisch plausibel basierend auf Architektur, aber ungetestet. Nenne die Annahmen, von denen der Pfad abhängt.

• Markiere ungetestete Angriffsflächen als [UNGETESTETE FLÄCHE: Beschreibung].

• Markiere angenommene Netzwerkpfade oder Vertrauensbeziehungen als [ANGENOMMENER PFAD: welche Konnektivität oder welches Vertrauen wird angenommen].

• Eine hypothetisierte Schwachstelle, die als bestätigt gemeldet wird, verschwendet Verteidigungsressourcen auf die falsche Priorität. Wenn nicht getestet, sag es.

Red Team Beispiel-Output

Finding Schweregrad Quelle Detail
Jenkins RCE (CVE-2024-XXXX) Kritisch BESTÄTIGT Exploit via Metasploit, Reverse Shell erhalten. Artefakt: Session-Log ID 47
Lateral Movement Jenkins → DB Hoch HYPOTHETISIERT Jenkins auf VLAN 10, DB auf VLAN 20. [ANGENOMMENER PFAD: nimmt an, dass keine ACL zwischen VLANs — nicht validiert]
S3-Bucket öffentlicher Zugriff Mittel INDIZIERT Bucket-Policy erlaubt s3:GetObject für *. [UNGETESTETE FLÄCHE: kein Versuch, sensitive Inhalte herunterzuladen]
Domain-Admin via Kerberoasting Hoch INDIZIERT SPN auf Service-Account mit schwacher Verschlüsselung (RC4) gefunden. Hash noch nicht geknackt.

Purple Team: Kollaboration

Purple Teaming ist, wo das Framework seine größte Kraft entfaltet, weil der gesamte Zweck darin besteht, offensive Fähigkeiten gegen defensive Fähigkeiten zu mappen — und der Raum dazwischen genau das ist, was die Lücken-Labels sichtbar machen.

Purple Team Quellen-Tags

  • (ERKANNT) — Blue Team hat die Angriffstechnik erfolgreich erkannt und alarmiert. Nennt den spezifischen Alert, die Regel oder SIEM-Korrelation
  • (TEILWEISE ERKANNT) — Indikatoren wurden geloggt, aber nicht zu einem handlungsfähigen Alert korreliert. Die Rohdaten existieren; die Erkennungslogik nicht
  • (VERFEHLT) — Angriffstechnik war erfolgreich ohne Erkennung auszulösen. Höchstprioritäts-Finding
  • (NICHT GETESTET) — Diese MITRE ATT&CK-Technik wurde in diesem Engagement nicht ausgeübt. Erkennungsfähigkeit kann nicht bewertet werden

Purple Team Prompt

Du bist ein Purple-Team-Analyst, der Angriffsergebnisse gegen Erkennungsfähigkeiten mappt. Tagge für jede getestete Technik das Ergebnis:

• (ERKANNT) — Blue Team hat erkannt und alarmiert. Nenne die spezifische Erkennungsregel, den Alert oder die Korrelation.

• (TEILWEISE ERKANNT) — Indikatoren wurden geloggt, aber nicht zu einem Alert korreliert. Nenne, was geloggt wurde und welche Erkennungslogik fehlt.

• (VERFEHLT) — Angriff war erfolgreich ohne Erkennung. Dies ist das höchstprioritäre Finding.

• (NICHT GETESTET) — Technik wurde in diesem Engagement nicht ausgeübt. Bewerte nicht die Erkennungsfähigkeit für ungetestete Techniken.

• Für jedes VERFEHLT-Finding markiere die Ursache: [SICHTBARKEITSLÜCKE] (Daten nicht erhoben) oder [ERKENNUNGSLÜCKE] (Daten erhoben, aber keine Regel oder Korrelation vorhanden).

• Nimm nicht an, dass eine Kontrolle funktioniert, weil sie existiert. Eine SIEM-Regel, die nie gegen einen realen Angriff ausgelöst hat, ist eine [VALIDIERUNGSLÜCKE], nicht (ERKANNT).

• Eine ungetestete Technik, die als erkannt gemeldet wird, gibt falsches Vertrauen. Wenn nicht getestet, sag NICHT GETESTET — niemals extrapolieren.

Purple Team Beispiel-Output

MITRE-Technik Red-Ergebnis Blue-Ergebnis Quelle Maßnahme
T1566.001 Spearphishing Payload zugestellt Alert in 12 Min. ausgelöst ERKANNT Review: 12 Min. Mean-Time-to-Detect akzeptabel?
T1003.001 LSASS-Dump Credentials extrahiert Kein Alert VERFEHLT [SICHTBARKEITSLÜCKE: kein LSASS-Zugriffsmonitoring konfiguriert]
T1071.001 Web C2 C2-Kanal etabliert Proxy hat Traffic geloggt, kein Alert TEILWEISE ERKANNT [ERKENNUNGSLÜCKE: Beaconing-Pattern-Erkennung benötigt]
T1053.005 Scheduled Task — — NICHT GETESTET [VALIDIERUNGSLÜCKE: Persistenz-Techniken nicht im Scope]

Die Cybersecurity-Version von Regel 2

Die „Raten bestrafen“-Regel bekommt im Sicherheitskontext besondere Dringlichkeit. Bei der Dokumentextraktion verschwendet eine falsche Antwort Zeit. In der Cybersecurity kumulieren die Kosten anders:

  • Ein (HYPOTHETISIERT)-Finding, das als (BESTÄTIGT) gemeldet wird → Verteidigungsressourcen gehen an die falsche Stelle
  • Eine (POLICY-DOKUMENTIERT)-Kontrolle, die als (VERIFIZIERT) gemeldet wird → tatsächliche Exposition bleibt unbehandelt
  • Eine (NICHT GETESTET)-Technik, die als (ERKANNT) gemeldet wird → das Team glaubt, geschützt zu sein, wo es blind ist
  • Eine [SICHTBARKEITSLÜCKE], die ungetaggt bleibt → der Angreifer operiert im einzigen Bereich, den niemand beobachtet

Die Cybersecurity-Formulierung von Regel 2 ist:

Falsches Vertrauen in eine Sicherheitskontrolle ist gefährlicher als eine bekannte Lücke. Eine bekannte Lücke wird budgetiert. Falsches Vertrauen wird gehackt.

Das ist nicht hypothetisch. Das Muster „angenommene Abdeckung, tatsächliche Blindheit“ ist genau das, was große Breaches ausnutzen. Angreifer zielen nicht auf Ihre stärksten Verteidigungen — sie finden die Bereiche, in denen Sie glauben, abgedeckt zu sein, es aber nicht sind. Jede [VALIDIERUNGSLÜCKE], die das Framework offenlegt, ist ein Ort, den der Gegner sondieren würde.

Das teamübergreifende Muster

Team Wahrheitsquelle Quellen-Tags Lücken-Labels Regel-2-Formulierung
Blue Bestätigte Verteidigungslage VERIFIZIERT / POLICY-DOKUMENTIERT / INFERIERT SICHTBARKEITSLÜCKE / VALIDIERUNGSLÜCKE Eine policy-dokumentierte Kontrolle, die als verifiziert behandelt wird, ist eine offene Tür
Red Demonstrierte Exploitation BESTÄTIGT / INDIZIERT / HYPOTHETISIERT UNGETESTETE FLÄCHE / ANGENOMMENER PFAD Ein hypothetisierter Pfad, der als bestätigt behandelt wird, verschwendet Verteidigungsressourcen
Purple Validierte Erkennungsfähigkeit ERKANNT / TEILWEISE ERKANNT / VERFEHLT / NICHT GETESTET SICHTBARKEITSLÜCKE / ERKENNUNGSLÜCKE / VALIDIERUNGSLÜCKE Eine ungetestete Technik, die als erkannt behandelt wird, erzeugt falsches Vertrauen

Die Struktur ist in jedem Fall gleich: Unterscheide zwischen dem, was bewiesen wurde, und dem, was angenommen wurde, mache die Grenze sichtbar, und behandle falsches Vertrauen als schlimmer als eingestandene Unsicherheit.

Oder, in Begriffen, die jeder Sicherheitsprofi sofort versteht: Das Framework verwandelt „angenommene Abdeckung“ in „validierte Abdeckung“ — und macht alles dazwischen explizit.

Integration mit MITRE ATT&CK

Das Drei-Regeln-Framework mappt natürlich auf MITRE ATT&CK-Assessments. Die ATT&CK-Matrix liefert das Was — welche Techniken existieren. Das Framework liefert das Wie sicher — für welche Techniken Sie tatsächlich die Abdeckung validiert haben.

Eine Standard-ATT&CK-Heatmap zeigt Rot (keine Abdeckung) und Grün (Abdeckung). Das Drei-Regeln-Framework fügt die entscheidende Zwischenschicht hinzu: Grün, das validiert wurde, vs. Grün, das angenommen wurde. Wie AttackIQ feststellt, kann die Kluft zwischen einem grünen Feld und tatsächlicher Verteidigungsfähigkeit enorm sein. Abdeckung für eine Prozedur ist nicht Abdeckung für eine Technik. Eine Erkennung, die letzten Monat funktionierte, kann diesen Monat still kaputtgegangen sein.

Die Drei-Regeln-Tags zu Ihrem ATT&CK-Coverage-Assessment hinzuzufügen verwandelt es von einer Deployment-Karte in eine Konfidenz-Karte — und Konfidenz-Karten sind die Grundlage, auf der Sicherheitsentscheidungen basieren sollten.

Quellen und weiterführende Lektüre

3 Prompt AI Series #4: Kalibrierung, Governance und Trade-offs

Das Drei-Regeln-Framework umsetzen: Kalibrierung, Governance und Trade-offs

Der vorherige Beitrag dieser Serie hat ein allgemeines Framework für KI-gestützte Szenarioplanung vorgestellt: Leerlassen erzwingen, Raten bestrafen, Quelle zeigen. Das Framework produziert Output, in dem jede Behauptung als VERIFIZIERT, ANGENOMMEN oder PROJIZIERT getaggt ist und Lücken explizit markiert statt stillschweigend gefüllt werden.

Das war das Was. Dieser Beitrag handelt vom Wie — drei praktische Herausforderungen, denen jeder begegnet, der das Framework umsetzt:

  1. Kalibrierung: Sie haben etwas als ANGENOMMEN getaggt. Wie prüfen Sie, ob die Annahme vernünftig ist?
  2. Governance: Wie setzen Organisationen Tagging in tatsächlichen Workflows durch — nicht nur im Prompt einer einzelnen Person?
  3. Trade-offs: Erzeugt das ganze Tagging nicht kognitive Überlastung? Wie lesen Nicht-Experten ein Dokument voller Provenance-Labels?

1. Annahmen kalibrieren: Von „getaggt“ zu „geprüft“

Eine Annahme zu taggen ist notwendig, aber nicht hinreichend. (ANGENOMMEN: Markt wächst 15 % jährlich) ist besser als ein unmarkiertes 15 %, das in die Projektion eingebaut ist — aber es sagt Ihnen nicht, ob 15 % vertretbar sind. Das Framework legt Annahmen offen; Kalibrierung prüft sie.

Vier Kalibrierungsmethoden funktionieren gut mit dem getaggten Output:

Reference Class Forecasting: Die Außenperspektive

Daniel Kahnemans und Amos Tverskys Unterscheidung zwischen der „Innenperspektive“ (Planung basierend auf den Spezifika dieses Projekts) und der „Außenperspektive“ (was bei vergleichbaren Projekten historisch passiert ist) ist das nützlichste Einzelkonzept zur Kalibrierung von Annahmen. Die Planungsfehler-Tendenz — systematisches Unterschätzen von Kosten und Zeitplänen — ist so gut dokumentiert, dass die American Planning Association Reference Class Forecasting 2005 offiziell empfohlen hat.

In der Praxis bedeutet das: Für jeden ANGENOMMEN-Tag fragen Sie das Modell (oder sich selbst), 3–5 vergleichbare Situationen und deren tatsächliche Ergebnisse zu identifizieren. Wenn Sie 15 % Wachstum annehmen, welches Wachstum haben ähnliche Produkte in ähnlichen Märkten tatsächlich erzielt? Wenn Sie einen 6-monatigen Genehmigungszeitraum annehmen, wie lange haben vergleichbare Genehmigungen tatsächlich gedauert?

Sie können das sogar in den Prompt einbauen:

Füge für jeden ANGENOMMEN-Tag eine „Kalibrierung“ hinzu: Identifiziere 2–3 vergleichbare historische Fälle und deren tatsächliche Ergebnisse. Falls keine vergleichbaren Daten existieren, vermerke [KEINE REFERENZKLASSE].

Sensitivitätstest: Was bricht, wenn das falsch ist?

Nicht alle Annahmen sind gleich wichtig. RANDs Assumption-Based Planning nennt das „Kritikalität“ — eine Annahme ist kritisch, wenn ihr Scheitern grundlegende Änderungen am Plan erfordern würde. In der Praxis heißt das testen: Was passiert mit der Schlussfolgerung, wenn diese Annahme um 50 % danebenliegt? Wenn die Antwort „nicht viel“ ist, hat die Annahme niedrige Priorität. Wenn die Antwort „der gesamte Business Case bricht zusammen“ ist, ist das Ihr Validierungsziel mit höchster Priorität.

Das getaggte Format ermöglicht das direkt. Sie können das Modell fragen:

Nimm die drei ANGENOMMEN-Positionen mit dem höchsten Einfluss auf die Endprojektion. Berechne für jede die Projektion neu mit der Annahme bei 50 % des angegebenen Werts und bei 150 %. Zeige mir, für welche Annahmen die Schlussfolgerung am empfindlichsten ist.

Pre-Mortem: Stell dir vor, es ist gescheitert

Gary Kleins Pre-Mortem-Technik kehrt die Frage um: Statt „Wird das funktionieren?“ zu fragen, startet man mit „Es ist gescheitert — warum?“ Das ist besonders wirksam für ANGENOMMEN-Tags, weil es Fehlermodi sichtbar macht, die Optimismus verbirgt:

Nimm an, dieses Szenario ist nach 12 Monaten gescheitert. Welche der ANGENOMMEN-Positionen waren am wahrscheinlichsten der Punkt des Scheiterns? Beschreibe für jede ein plausibles Narrativ, wie diese Annahme zusammengebrochen ist.

Zeitlicher Verfall: Wann verfällt die Annahme?

Annahmen haben ein Haltbarkeitsdatum. Eine Marktgrößenschätzung aus einem Gartner-Bericht von 2025 ist 2026 noch vertretbar. Eine Wettbewerbs-Landschafts-Annahme von 2024 könnte bereits falsch sein. Eine zeitliche Dimension zu ANGENOMMEN-Tags hinzuzufügen hilft:

Füge für jeden ANGENOMMEN-Tag eine Verfallsschätzung hinzu: Wie lange ist diese Annahme voraussichtlich gültig? Markiere alles, was älter als 12 Monate ist oder auf Daten vor 2025 basiert, als [VERALTETE ANNAHME].

2. Governance: Das Framework über eine einzelne Person hinaus verankern

Das Framework funktioniert gut, wenn eine Person es in einer Chat-Session nutzt. Die Governance-Frage ist: Wie übersteht es den Kontakt mit einer Organisation — mehrere Personen, mehrere KI-Tools, mehrere Dokumente, über Monate?

Das Problem: Tags gehen in der Übersetzung verloren

Was typischerweise passiert: Ein Analyst erstellt ein schön getaggtes Szenario. Er kopiert es in eine Folienpräsentation. Die Tags verschwinden. Ein Manager liest die Folien, sieht „Umsatz Jahr 1: 310K €“ ohne jeden Hinweis, dass die Zahl PROJIZIERT ist aus zwei nicht validierten ANGENOMMEN-Inputs. Das Geisterszenario lebt wieder.

Das ist ein Wissensmanagement-Problem, kein KI-Problem. Und es hat Wissensmanagement-Lösungen.

Stufe 1: Template-Pflicht

Der einfachste Governance-Mechanismus ist ein Template. Wenn Ihre Organisation KI für Szenarioplanung nutzt, sollte das Output-Template Provenance-Spalten fest eingebaut haben. Nicht optional, nicht „bei Bedarf hinzufügen“ — strukturell erforderlich. Ein Szenario-Dokument ohne Quellen-Tags sollte genauso behandelt werden wie ein Finanzbericht ohne Belege: unvollständig.

Konkret: Erstellen Sie ein Standardtabellenformat für alle KI-gestützten Szenario-Outputs:

Variable Wert Quelle Basis / Falls falsch Geprüft von Datum
(Alle KI-generierten Szenario-Outputs müssen dieses Format verwenden)

Die Spalten „Geprüft von“ und „Datum“ sind die Governance-Ergänzungen. Sie machen aus einer Prompt-Technik eine Prüfspur. Jemand muss jede ANGENOMMEN-Position abzeichnen, bevor sie in die Planung eingeht.

Stufe 2: Review-Workflow

Für Organisationen mit strukturierteren Prozessen integrieren Sie das Tagging in den Review-Zyklus:

Schritt 1 — Generierung: KI produziert getaggten Output mit dem Drei-Regeln-Prompt.
Schritt 2 — Annahmen-Review: Ein Fachexperte prüft alle ANGENOMMEN- und PROJIZIERT-Positionen. Jede bekommt eine von drei Dispositionen: bestätigt (wird zu VERIFIZIERT umklassifiziert), hinterfragt (zur Kalibrierung geschickt) oder mit Risiko akzeptiert (bleibt als ANGENOMMEN mit dokumentierter Begründung).
Schritt 3 — Lücken-Triage: Alle DATENLÜCKE- und ANNAHMELÜCKE-Positionen werden triagiert: auflösbar (jemandem zuweisen, die Daten zu finden), irreduzibel (die Unsicherheit ist inhärent — dokumentieren und drum herumplanen) oder zurückgestellt (für diese Entscheidungsphase nicht nötig).
Schritt 4 — Entscheidungspaket: Das finale Dokument trennt „was wir wissen“ (VERIFIZIERT), „was wir glauben“ (ANGENOMMEN, mit Kalibrierungsnotizen) und „was wir nicht wissen“ (verbleibende Lücken). Entscheidungsträger sehen alle drei.

Stufe 3: System-Prompt-Standardisierung

Wenn Ihre Organisation KI teamübergreifend nutzt, standardisieren Sie den System-Prompt. Verlassen Sie sich nicht darauf, dass einzelne Analysten sich daran erinnern, die drei Regeln anzuwenden. Verankern Sie das Framework in jedem KI-Zugangspunkt — ob Claude-Projekt, Custom GPT, API-Wrapper oder n8n-Workflow. Der Prompt wird Infrastruktur, nicht persönliche Praxis.

Die kulturelle Herausforderung

Das schwierigste Governance-Problem ist nicht technisch. Es ist, dass Unsicherheit zu taggen sich nach Schwäche anfühlt. Ein Szenario voller ANGENOMMEN- und DATENLÜCKE-Labels einem Vorstand zu präsentieren wirkt weniger überzeugend als saubere Zahlen. Die organisationale Antwort darauf muss explizit sein: Ein getaggtes Szenario ist kein unvollständiges Szenario — es ist ein ehrliches. Die sauberen Zahlen waren nie sauber; sie haben nur versteckt, wo die Vermutungen waren.

Genau das zeigt Bent Flyvbjergs jahrzehntelange Forschung zu Großprojekt-Fehlschlägen: Die Projekte, die am katastrophalsten das Budget sprengten, waren nicht die mit der meisten Unsicherheit — es waren die, bei denen die Unsicherheit versteckt war. Transparenz über Annahmen ist eine Risikoreduktionsstrategie, kein Eingeständnis von Schwäche.

3. Trade-offs: Wenn Tags zu Rauschen werden

Ein Dokument, in dem jeder Satz ein Provenance-Label trägt, ist anstrengend zu lesen. Das Framework erzeugt realen kognitiven Overhead, und so zu tun als wäre das nicht so, wäre unehrlich. Die Frage ist nicht, ob es Kosten gibt — die gibt es —, sondern wie man sie steuert.

Das Überlastungsproblem

Stellen Sie sich ein 20-Variablen-Szenario vor mit Quellen-Tags, Kalibrierungsnotizen und „Falls falsch“-Anmerkungen an jeder ANGENOMMEN-Position. Für den Analysten, der es erstellt hat, ist das wertvoll — er sieht genau, wohin er seine Aufmerksamkeit richten muss. Für die Führungskraft, die darauf basierend entscheiden muss, ist es eine Wand von Einschränkungen, die das Ergebnis verdeckt.

Beide Perspektiven sind berechtigt. Die Lösung ist nicht, sich für eine zu entscheiden — sondern beide mit verschiedenen Sichten auf dieselben zugrundeliegenden Daten zu bedienen.

Lösung: Geschichtete Darstellung

Das getaggte Szenario sollte in mindestens zwei Schichten existieren:

Schicht 1 — Entscheidungszusammenfassung: Eine Seite. Kernschlüsse, Kernzahlen, Kernrisiken. Keine Tags im laufenden Text. Stattdessen ein einzelner Abschnitt „Konfidenzprofil“ am Ende:

Dieses Szenario stützt sich auf 14 verifizierte Datenpunkte, 6 genannte Annahmen und 3 Projektionen. Zwei Datenlücken sind ungelöst (marktspezifischer CAC, regulatorischer Zeitplan). Die Annahme mit dem höchsten Einfluss auf nachgelagerte Ergebnisse ist [X] — bei 50 % Abweichung verschiebt sich der projizierte Umsatz von 310K € auf 180K €.

Das ist die Führungskräfte-Sicht: Wie viel davon ist solide, wie viel ist unsicher, und was konkret könnte es zum Kippen bringen.

Schicht 2 — Vollständige getaggte Analyse: Der komplette Output mit allen Provenance-Tags, Kalibrierungsnotizen, Lücken-Labels und Sensitivitätsanalyse. Das ist das Arbeitsdokument. Der Analyst nutzt es, der Reviewer zeichnet es ab, und es wird archiviert. Es ist die Prüfspur.

Die Beziehung zwischen den Schichten ist wie die zwischen einem Jahresabschluss und seinen Fußnoten. Der Abschluss zeigt die Zahlen; die Fußnoten zeigen, worauf die Zahlen ruhen. Beides existiert. Verschiedene Leser nutzen verschiedene Schichten.

Wie Nicht-Experten Tags lesen

Für Teams, in denen nicht jeder das Tagging-System beherrscht, vereinfachen Sie die visuelle Sprache. Drei Farben funktionieren besser als drei Akronyme:

  • VERIFIZIERT → als normaler Text dargestellt (keine besondere Markierung nötig — es ist die Baseline)
  • ANGENOMMEN → hervorgehoben oder mit einem visuellen Signal markiert (z. B. kursiv, farbige Seitenleiste oder ein einfaches ⚠-Symbol)
  • DATENLÜCKE → als explizite Leerstelle mit kurzem Hinweis

Die Kernbotschaft, die Nicht-Experten verinnerlichen müssen, ist einfach: Unmarkierter Text ist fundiert; markierter Text ist unsicher; Leerstellen sind ehrlich. Das ist ein Zehn-Sekunden-Briefing. Wer eine Wettervorhersage lesen kann, die „aktuelle Temperatur“ von „Morgenprognose“ unterscheidet, kann ein getaggtes Szenario lesen.

Wann weniger Tags reichen

Nicht jeder Anwendungsfall braucht volle Provenance. Der richtige Tagging-Grad hängt von den Einsätzen ab:

Einsatz Tagging-Grad Beispiel
Niedrig Nur Lücken taggen Internes Brainstorming, frühe Ideenfindung
Mittel Lücken + Annahmen taggen Projektvorschläge, Budget-Entwürfe, Team-Planung
Hoch Volles Tagging + Kalibrierung Vorstandspräsentationen, Investitionsentscheidungen, regulatorische Einreichungen

Bei einem lockeren Strategie-Brainstorming VERIFIZIERT/ANGENOMMEN/PROJIZIERT auf jede Zeile zu verlangen, würde den kreativen Fluss töten. Bei einer 2-Millionen-Euro-Investitionsentscheidung für den Vorstand ist alles unter vollem Tagging unverantwortlich. Passen Sie die Intensität des Frameworks an die Konsequenzen der Entscheidung an.

Das Framework-Reifegradmodell

Zusammengenommen können Organisationen, die das Drei-Regeln-Framework einführen, die Umsetzung in drei Stufen denken:

Stufe 1 — Individuelle Praxis: Eine Person nutzt den Drei-Regeln-Prompt in ihren eigenen KI-Gesprächen. Getaggter Output bleibt in ihrem Workspace. Nutzen: persönliche Qualitätskontrolle. Kosten: nahezu null.

Stufe 2 — Team-Standard: Der Prompt wird in gemeinsame KI-Workspaces eingebettet (Claude-Projekte, Custom GPTs). Templates erzwingen das Tabellenformat. Annahmen bekommen informelles Peer-Review. Nutzen: gleichbleibende Qualität im Team. Kosten: Template-Erstellung, kurzes Training.

Stufe 3 — Organisationale Governance: Das Framework wird in Planungsprozesse integriert. Annahmen-Review ist ein formaler Workflow-Schritt. Kalibrierung (Referenzklasse, Sensitivität, Pre-Mortem) ist Standardpraxis. Entscheidungspakete trennen Konfidenzschichten. Nutzen: systematische Risikoreduktion. Kosten: Prozessänderung, kultureller Wandel.

Die meisten Teams sollten bei Stufe 1 beginnen und sofort Ergebnisse sehen. Ob man zu Stufe 2 oder 3 fortschreitet, hängt davon ab, wie viel auf dem Spiel steht, wenn KI-generierte Szenarien reale Entscheidungen informieren. Je höher die Einsätze, desto mehr zahlt sich die Governance-Investition aus.

Limitierungen und bekannte Lücken

Das Drei-Regeln-Framework ist ein Praktiker-Muster, keine peer-reviewte Methode. Es verdient dieselbe kritische Prüfung, die es Nutzer auf KI-Output anwenden lässt. Hier sind die Dinge, die es nicht löst — und die Wege, auf denen es missbraucht werden kann.

1. Nicht empirisch validiert

Es gibt keine kontrollierten Experimente, keine Vorher/Nachher-Fehlerratenmessungen und keine Nutzerstudien hinter diesem Framework. Forschung zeigt, dass Provenance-Tagging und strukturiertes Prompting Halluzinationen reduzieren können — manchmal erheblich —, aber das wurde für spezifische Tagging-Schemata unter kontrollierten Bedingungen nachgewiesen, nicht für das exakte VERIFIZIERT/ANGENOMMEN/PROJIZIERT-Muster, das hier vorgeschlagen wird. Behandeln Sie das Framework als eine Engineering-Heuristik, die in vielen Fällen wahrscheinlich hilft, nicht als etwas, dessen Wirksamkeit Sie ohne eigene Messung voraussetzen können. Wenn Sie es einführen, verfolgen Sie, ob es Ihre Outputs tatsächlich verbessert.

2. Der Prompt ist ein Hebel, nicht der einzige

Das Framework stützt sich stark auf Prompt-Design als primären Mechanismus zur Steuerung des Modellverhaltens. In der Praxis können Prompts Halluzinationen reduzieren, aber Modelle verletzen Anweisungen dennoch unter Druck — besonders wenn Optimierung, Reward-Modelle oder Fine-Tuning auf Sprachfluss und Vollständigkeit drängen. Für Produktionssysteme sollten Prompt-Regeln durch architektonische Kontrollen ergänzt werden: Retrieval-Augmented Generation (RAG) zur Verankerung von Outputs in tatsächlichen Daten, regelbasierte Filter zum Abfangen unbelegter Aussagen, Enthaltungsmechanismen, die die Generierung verweigern, wenn die Konfidenz niedrig ist, und menschliche Review-Workflows. Der Prompt ist der nutzer-zugängliche Hebel. Er ist nicht der einzige, und in Hochrisiko-Deployments ist es fragil, sich allein darauf zu verlassen.

3. VERIFIZIERT bedeutet „belegt“, nicht „unfehlbar“

Die Tag-Hierarchie des Frameworks impliziert einen Konfidenz-Gradienten: VERIFIZIERT = solide, ANGENOMMEN = fragil, PROJIZIERT = abgeleitet. Aber „verifizierte“ Daten können selbst erhebliche Probleme enthalten. Historische Zahlen können Messfehler widerspiegeln. Marktdaten können Anbieter-Annahmen oder Stichprobenverzerrungen kodieren. Finanz-Ist-Werte können nicht-stationär sein — eine Q4-2024-Umsatzzahl kann für Q4-2026-Projektionen in einem Post-Schock-Markt irreführend sein. Das Framework verfolgt Provenance (woher kommt diese Zahl?), nicht Qualität (ist diese Zahl noch ein zuverlässiger Leitfaden?). Nutzer sollten der Versuchung widerstehen, VERIFIZIERT als „gesichert“ zu behandeln. Datenfundamentalismus — die Annahme, dass belegte Daten korrekte Daten sind — ist ein anderer Fehlermodus als Halluzination, kann aber gleichermaßen schlechte Entscheidungen antreiben.

4. Tags legen Inputs offen, nicht strukturelle Validität

Ein Szenario kann perfekt getaggt sein — jede Zahl belegt, jede Annahme markiert, jede Lücke gekennzeichnet — und dennoch fundamental irreführend sein, weil das zugrundeliegende Kausalmodell falsch ist. Kundenabwanderung als preisunabhängig behandeln. Rückkopplungsschleifen zwischen Marketingausgaben und Markenwahrnehmung ignorieren. Lineare Skalierung annehmen, wo die realen Dynamiken nichtlinear sind. Das Framework fängt faktische Halluzinationen (falsche Inputs) ab, aber nicht strukturelle Fehler (falsches Modell davon, wie die Inputs zusammenhängen). Die Kalibrierungsmethoden — Sensitivitätstest, Pre-Mortem — helfen teilweise, testen Annahmen aber isoliert, nicht die Beziehungen zwischen ihnen. ABP- und Szenarioplanungs-Literatur betonen strukturelles Denken und die Exploration alternativer Logiken. Dieses Framework fokussiert auf Tagging und Lückenmarkierung, nicht auf die Qualität des mentalen Modells. Ein gut getaggtes schlechtes Modell ist immer noch ein schlechtes Modell.

5. Labels legen nicht offen, wessen Annahmen kodiert werden

Die Kategorien VERIFIZIERT/ANGENOMMEN/PROJIZIERT können einen Anschein von Objektivität vermitteln, der Machtdynamiken verbirgt. Management kann optimistische Wachstumsziele als ANGENOMMEN kodieren, ohne den politischen Druck hinter der Zahl offenzulegen. Die Marktgrößenschätzung eines Anbieters, als VERIFIZIERT getaggt, kann dessen kommerzielle Interessen einbetten. Die PROJIZIERT-Berechnung eines Analysten kann ein Modell verwenden, das institutionelle Voreingenommenheit zugunsten bestimmter Ergebnisse widerspiegelt. Das Framework verlangt weder vom Modell noch vom Menschen offenzulegen, wessen Annahmen kodiert werden oder wie sie entstanden sind. Die Frage ist nicht nur „ist das belegt oder angenommen?“, sondern „wessen Interessen haben diese Annahme geformt?“ Das Framework beantwortet diese Frage nicht — und zu behaupten, es tue es, wäre eine Form derselben falschen Zuversicht, die es verhindern soll.

6. Zu viele Lücken können Entscheidungen lähmen

Das Framework bestraft Raten explizit und ermutigt das Modell, bei jeder Gelegenheit [DATENLÜCKE] und [ANNAHMELÜCKE] zu markieren. In Hochunsicherheits-Domänen — was die meiste strategische Planung betrifft — kann das zu Outputs führen, die von Lücken und Vorbehalten dominiert werden. ABP-Literatur betont, dass manche Annahmen „für Planungszwecke“ gemacht werden müssen, oder Planung kann nicht fortschreiten. Die Stakes-basierte Skalierungstabelle weiter oben adressiert dies teilweise, aber die zugrundeliegende Spannung bleibt: Das Framework fördert eine Norm, in der „stille Erfindung schlimmer ist als markierte Unsicherheit“, ohne explizit zu diskutieren, wann zu viel Unsicherheitssignalisierung die Entscheidungsfindung untergräbt. Passen Sie die Intensität des Frameworks nicht nur an die Entscheidungseinsätze an, sondern auch an die Risikobereitschaft und Entscheidungszeitpläne der Organisation.

7. Domänenspezifische Anpassung erforderlich

Die Serie behauptet, das Framework sei domänenübergreifend portabel — Dokumentextraktion, Worldbuilding, Szenarioplanung, Cybersecurity, wissenschaftliches Arbeiten. Aber diese Domänen haben sehr unterschiedliche Einsätze, epistemische Strukturen und regulatorische Umgebungen. In der Medizin ist etwas als ANGENOMMEN zu taggen bei Weitem nicht ausreichend, um es sicher zu machen — existierende Richtlinien erfordern RAG, externe Verifikation und menschliche Aufsicht. In der juristischen Arbeit kann ein individuelles Label-Schema mit etablierten Zitationsstandards kollidieren oder von Gerichten fehlinterpretiert werden. In regulierten Branchen können Compliance-Frameworks eigene Provenance-Anforderungen haben. Das allgemeine Muster bietet eine Ausgangsstruktur; domänenspezifische Anpassung und Validierung sind erforderlich, bevor man sich in regulierten oder Hochrisiko-Umgebungen darauf verlässt.

Diese Limitierungen entkräften das Framework nicht — sie begrenzen es. Die drei Regeln sind eine erhebliche Verbesserung gegenüber dem Default (keine Provenance, keine Lückenmarkierung, keine Bestrafung für Raten), aber sie sind keine vollständige Lösung. Sie sind der Beginn einer Praxis, nicht ihr Ende.

Quellen und weiterführende Lektüre

Das Drei-Regeln-Framework #3: Von der Dokumentextraktion zur Szenarioplanung

Dies ist der dritte Beitrag einer Serie über einen kleinen Satz von Prompt-Regeln mit überraschend großer Reichweite.

Im ersten Beitrag habe ich gezeigt, wie drei Regeln — Leerlassen erzwingen, Raten bestrafen, Quelle zeigen — KI davon abhalten, beim Extrahieren von Daten aus Verträgen und Rechnungen stillschweigend zu raten. Im zweiten Beitrag habe ich sie für Alternate-History-Worldbuilding angepasst, wo dieselben Regeln Lore konsistent und die reale Geschichte korrekt halten.

Dieser Beitrag macht den letzten Schritt: Die drei Regeln werden zu einem Framework verallgemeinert, das für Szenarioplanung im Business funktioniert — strategische Planung, KPI-Entwicklung, Projekt-Risikobewertung, Finanzmodellierung, Markteintrittanalyse und jeden anderen Kontext, in dem Sie KI nutzen, um über die Zukunft nachzudenken.

Warum Szenarioplanung anfällig für dasselbe Problem ist

Szenarioplanung hat eine lange intellektuelle Geschichte. RAND entwickelte die Assumption-Based Planning (ABP) Methodik für die US-Armee in den 1990er-Jahren. Shell war Pionier der unternehmerischen Szenarioplanung in den 1980ern unter Peter Schwartz. Der Oxford Scenario Planning Approach, beschrieben in einem MIT-Sloan-Artikel vom Dezember 2025, integriert inzwischen generative KI in den Prozess selbst.

All diese Methoden teilen ein Kernprinzip: Annahmen explizit machen. RAND definiert eine Annahme als „eine Aussage über eine Eigenschaft der Zukunft, die den aktuellen Operationen oder Plänen einer Organisation zugrunde liegt“. Jeder Plan enthält sie. Die meisten sind unsichtbar. Die unsichtbaren sind die, die zu Scheitern führen.

Was passiert nun, wenn Sie Ihre Geschäftsdaten einer KI geben und sie bitten, ein Szenario zu bauen? Das Modell tut genau das, was es bei Verträgen und Fiktion tut: Es füllt Lücken. Umsatzwachstum im Q4? Das Modell wählt eine plausible Zahl. Wettbewerberreaktion auf Ihren Markteintritt? Das Modell erfindet eine. Zeitplan für die behördliche Genehmigung? Das Modell schätzt. Kundenabwanderung unter der neuen Preisstruktur? Das Modell generiert eine Kennzahl.

Jede einzelne davon ist eine Annahme. Keine davon wird als solche gekennzeichnet. Das Szenario liest sich wie eine kohärente Analyse, gestützt auf Daten — aber manche „Daten“ sind real, manche abgeleitet und manche wurden fabriziert, um das Narrativ zusammenzuhalten. Welche welche sind, ist nicht erkennbar.

Es ist dasselbe Problem in seiner dritten Inkarnation. Und es reagiert auf dieselben drei Regeln.

Das allgemeine Muster

Über drei Domänen hinweg wiederholt sich dieselbe Struktur:

Domäne Kanon (Wahrheitsquelle) Quellen-Tags Lücken-Labels
Dokumentextraktion Das Dokument EXTRAHIERT / ABGELEITET LEER
Worldbuilding Reale Geschichte + Lore HISTORIE / LORE-BELEGT / LORE-INFERIERT HISTORISCHE LÜCKE / LORE-LÜCKE
Szenarioplanung Verifizierte Daten + Etablierte Rahmenbedingungen VERIFIZIERT / ANGENOMMEN / PROJIZIERT DATENLÜCKE / ANNAHMELÜCKE

Die zugrundeliegende Logik ist immer dieselbe: Unterscheide, was bekannt ist, von dem, was erfunden wurde, und mache die Grenze sichtbar.

Für Business-Szenarien hat der „Kanon“ zwei Schichten — genau wie beim Worldbuilding:

  1. Verifizierte Daten — Dinge, die Sie aus tatsächlichen Messungen kennen: Vorjahresumsatz, aktuelle Mitarbeiterzahl, unterzeichnete Verträge, gemessene KPIs, Marktdaten aus glaubwürdigen Quellen
  2. Etablierte Rahmenbedingungen — Dinge, die entschieden sind, nicht spekuliert: Budgetgrenzen, regulatorische Vorgaben, vertragliche Fristen, vom Vorstand genehmigte Ziele

Alles andere — Marktwachstumsschätzungen, Wettbewerberverhalten, Kundenadoptionsraten, Technologie-Reifegrad-Zeitpläne — ist eine Annahme. Und Annahmen gibt es in zwei Varianten: solche, die Sie durchdacht haben und verteidigen können (auch wenn sie unsicher sind), und solche, die die KI einfach erfunden hat, weil das Szenario eine Zahl brauchte.

Die drei Regeln existieren, um diese Kategorien zu trennen.

Die drei Regeln für die Szenarioplanung

Regel 1: Leerlassen erzwingen → Unbekannte Variablen markieren

Wenn die KI auf eine Variable trifft, für die sie keine Daten hat, soll sie es sagen — nicht einen plausiblen Wert erfinden.

Die Lücken-Labels für Business-Szenarien teilen sich in zwei Typen:

  • [DATENLÜCKE] — ein faktischer Input, den das Szenario braucht, der aber nicht bereitgestellt oder nicht verfügbar ist. Beispiel: „Diese Projektion benötigt die Kundenakquisitionskosten (CAC) für die DACH-Region; keine Daten wurden bereitgestellt.“
  • [ANNAHMELÜCKE] — eine strategische oder verhaltensbezogene Annahme, auf die sich das Szenario stützt, die aber nicht explizit validiert wurde. Beispiel: „Dieses Szenario setzt voraus, dass Wettbewerber X die Preise nicht senkt. Diese Annahme wurde nicht validiert.“

Hier konvergieren RANDs ABP-Framework und die drei Regeln am direktesten. Dewar und seine Kollegen bei RAND argumentieren, dass jeder Plan ein „Geisterszenario“ hat — den impliziten, unausgesprochenen Satz von Annahmen über die Zukunft, für den der Plan zugeschnitten ist. Die gefährlichsten Annahmen sind die, von denen niemand wusste, dass sie sie machten. Die KI zu zwingen, Lücken zu markieren, ist eine praktische Methode, das Geisterszenario sichtbar zu machen.

Regel 2: Raten bestrafen → Eine stille Annahme ist schlimmer als ein bekanntes Unbekanntes

Die Business-Version von „Eine falsche Antwort ist 3× schlimmer als ein leeres Feld“ lautet:

Eine versteckte Annahme, die in die Analyse eingebaut ist, ist schlimmer als eine explizit markierte Unsicherheit. Wenn Daten fehlen, markiere die Lücke — fülle sie nicht mit einer plausibel klingenden Zahl.

Warum ist das bei Szenarien gefährlicher als bei der Dokumentextraktion? Weil Szenarien kumulieren. Eine einzige unmarkierte Annahme über Marktwachstum fließt in Umsatzprojektionen, die in Personalplanung fließen, die in Budgetallokation fließt, die in Vorstandspräsentationen fließt. Bis die Annahme scheitert, basieren sechs Monate Planung darauf.

ABP nennt diese „tragende Annahmen“ — solche, deren Scheitern fundamentale Änderungen am Plan erfordern würde. Das Drei-Regeln-Framework legt sie offen, bevor sie Last tragen.

Regel 3: Die Quelle zeigen → VERIFIZIERT / ANGENOMMEN / PROJIZIERT

Jede Zahl, jeder Trend, jede Verhaltensaussage im Szenario bekommt einen von drei Tags:

  • (VERIFIZIERT) — basiert auf tatsächlichen Daten, die Sie bereitgestellt haben: Finanzberichte, unterzeichnete Verträge, gemessene KPIs, zitierfähige Drittquellen
  • (ANGENOMMEN) — eine Überzeugung über die Zukunft, auf die sich das Szenario stützt und die falsch sein könnte. Das Modell muss die Annahme explizit nennen: „Nimmt 15 % Jahreswachstum in Segment X an, konsistent mit dem Trend 2023–2025″
  • (PROJIZIERT) — ein Wert, der aus verifizierten Daten und genannten Annahmen berechnet oder abgeleitet wird. Das Modell muss die Herleitung zeigen: „Projiziert aus den Q1–Q3-Ist-Werten bei aktuellem Run Rate“

Die kritische Unterscheidung zwischen ANGENOMMEN und PROJIZIERT: Eine Annahme ist eine Überzeugung, die Sie in das Szenario einbringen; eine Projektion ist eine Berechnung, die das Modell mit Ihren Daten und Annahmen als Input durchführt. Annahmen können hinterfragt werden („Was, wenn das Wachstum 5 % statt 15 % beträgt?“). Projektionen können geprüft werden („Zeig mir die Berechnung“).

Der kombinierte Prompt

Hier das vollständige Framework als System-Prompt. Ersetzen Sie die Platzhalter mit Ihrem spezifischen Kontext.

Du bist mein Szenario-Planungs-Analyst. Wir erstellen ein(e) [TYP: Businessplan / Marktanalyse / Projekt-Risikobewertung / KPI-Framework / Budget-Szenario] für [KONTEXT: Unternehmen, Projekt, Produkt, Markt].

Deine Aufgabe ist es, Analysen zu erstellen, die transparent darlegen, was sie wissen, was sie annehmen und was sie nicht wissen. Befolge diese Regeln strikt:

Regel 1 — Unbekannte Variablen markieren:
• Wenn das Szenario Daten erfordert, die nicht bereitgestellt wurden, erfinde keinen plausiblen Wert. Verwende [DATENLÜCKE: Beschreibung welche Daten fehlen und warum sie relevant sind].
• Wenn das Szenario auf einer strategischen oder verhaltensbezogenen Annahme beruht, die nicht explizit validiert wurde, markiere sie mit [ANNAHMELÜCKE: Beschreibung der unausgesprochenen Annahme].

Regel 2 — Lücken nicht stillschweigend füllen:
• Eine versteckte Annahme in der Analyse ist schlimmer als eine explizit markierte Unsicherheit.
• Wenn Daten fehlen, markiere die Lücke. Generiere keine plausibel klingende Zahl.
• Wenn ein Ergebnis von Annahmen über Wettbewerberverhalten, Marktdynamik, regulatorische Entscheidungen oder Kundenreaktion abhängt, nenne die Annahme explizit statt sie als Fakt einzubauen.

Regel 3 — Quellenkennzeichnung:
Kennzeichne jede wesentliche Behauptung, Zahl oder Schlussfolgerung mit ihrer Quelle:
• (VERIFIZIERT) — basiert auf tatsächlichen Daten, die ich bereitgestellt habe, oder glaubwürdigen, zitierten Drittdaten
• (ANGENOMMEN) — eine Überzeugung über die Zukunft, von der das Szenario abhängt. Nenne die Annahme und worauf sie basiert.
• (PROJIZIERT) — berechnet oder abgeleitet aus verifizierten Daten und genannten Annahmen. Zeige oder beschreibe die Herleitung.
• Für jedes ANGENOMMEN-Tag: Nenne kurz, was sich ändern würde, wenn die Annahme falsch ist.

Beispiel: Markteintritt-Szenario

So sieht der Output aus, wenn die Regeln aktiv sind. Stellen Sie sich vor, Sie bitten die KI, einen SaaS-Produktlaunch in einem neuen Markt zu bewerten:

Variable Wert Quelle Anmerkung
Aktueller ARR 2,4 Mio. € VERIFIZIERT Q4-2025-Finanzbericht
Zielmarktgröße (DACH) 340 Mio. € VERIFIZIERT Gartner-Bericht 2025, zitiert
Marktanteil Jahr 1 — DATENLÜCKE Keine vergleichbaren Launch-Daten für dieses Segment vorhanden
CAC (DACH-Region) — DATENLÜCKE Aktueller CAC gilt nur für US-Markt; Akquisitionskosten DACH nicht bereitgestellt
Preismodell 49 €/Platz/Monat VERIFIZIERT Vom Vorstand genehmigte Preisentscheidung, März 2026
Wettbewerberreaktion Keine Preissenkung ANGENOMMEN Nimmt an, dass Incumbent-Wettbewerber aktuelle Preise beibehält. Bei 20 % Rabatt sinkt die projizierte Marge von 68 % auf ca. 51 %
Umsatzprojektion Jahr 1 180K–420K € PROJIZIERT Spanne basiert auf 30–70 Enterprise-Seats zum genannten Preis. Untere Grenze ohne Channel-Partner; obere mit 2 Reseller-Vereinbarungen (ANNAHMELÜCKE: keine Reseller-Gespräche bestätigt)

Vergleichen Sie das mit dem, was dasselbe Modell ohne Regeln produzieren würde: eine einzelne, selbstbewusste Umsatzprojektion von 310K €, ein spezifischer Marktanteil, ein angenommener CAC, der wie Daten aussieht, und kein Hinweis darauf, welche Zahlen real und welche erfunden sind.

Die getaggte Version braucht dreißig Sekunden länger zum Lesen. Sie spart Wochen der Planung auf falschen Fundamenten.

Anwendungen über die Strategie hinaus

KPI-Entwicklung: Beim Definieren von KPIs für eine neue Initiative jeden Zielwert taggen als VERIFIZIERT (auf historischer Baseline basierend), ANGENOMMEN (auf Industrie-Benchmarks oder Management-Erwartungen basierend) oder PROJIZIERT (aus verifizierten Inputs berechnet). Jeden KPI ohne verlässliche Baseline mit [DATENLÜCKE] markieren.

Projekt-Risikobewertung: Für jedes identifizierte Risiko Wahrscheinlichkeit und Auswirkung taggen als VERIFIZIERT (auf historischen Vorfallsdaten basierend), ANGENOMMEN (auf Expertenmeinung oder Analogie basierend) oder PROJIZIERT (aus einem Modell abgeleitet). Risiken ohne Daten- oder Expertenbasis mit [ANNAHMELÜCKE] markieren.

Budget-Szenarien: Jede Budgetposition taggen. Fixkosten aus unterschriebenen Verträgen sind VERIFIZIERT. Personalabhängige Kosten basierend auf geplantem Recruiting sind PROJIZIERT (mit dem Einstellungsplan als genannte Annahme). Umsatzabhängige Positionen sind ANGENOMMEN, wenn Umsatzziele nicht gegen Pipeline-Daten validiert wurden.

Wettbewerbsanalyse: Jede Aussage über Strategie, Preise oder Marktposition eines Wettbewerbers taggen. Öffentliche Finanzdaten sind VERIFIZIERT. Schlüsse aus Stellenanzeigen oder Patentanmeldungen sind PROJIZIERT. Annahmen über künftige Züge sind ANGENOMMEN — mit expliziter „Falls falsch“-Anmerkung.

Das Framework als Muster

Über alle drei Beiträge hinweg lässt sich das allgemeine Framework in einem Absatz formulieren:

Wenn Sie KI in einer Domäne einsetzen, in der Quellentreue zählt, wenden Sie drei Regeln an: (1) Geben Sie dem Modell explizit die Erlaubnis, nicht zu wissen, mit beschrifteten Lücken; (2) machen Sie die Kosten einer stillen Erfindung höher als die Kosten einer markierten Unsicherheit; (3) verlangen Sie, dass jede Behauptung einen Provenance-Tag trägt, der zeigt, ob sie aus verifiziertem Quellmaterial stammt, aus genannten Annahmen oder aus der eigenen Inferenz des Modells. Die konkreten Labels ändern sich je nach Domäne, aber die Struktur ist universell.

Regel 1: Leerlassen Regel 2: Raten bestrafen Regel 3: Quelle zeigen
Extraktion LEER + Begründung Falsche Antwort 3× schlimmer EXTRAHIERT / ABGELEITET
Worldbuilding HISTORISCHE LÜCKE / LORE-LÜCKE Falsche Erfindung schlimmer als Lücke HISTORIE / LORE-BELEGT / LORE-INFERIERT
Szenarien DATENLÜCKE / ANNAHMELÜCKE Versteckte Annahme schlimmer als bekanntes Unbekanntes VERIFIZIERT / ANGENOMMEN / PROJIZIERT
Allgemein [LÜCKE: Typ + Erklärung] Stille Erfindung > markierte Unsicherheit QUELLE / ABGELEITET / INFERIERT

Die untere Zeile ist die portable Version. Sie funktioniert für juristische Recherche, medizinische Zusammenfassungen, akademische Literaturreviews, Code-Refactoring, Übersetzung — jede Aufgabe, bei der das Modell nützlich sein soll, ohne unehrlich zu sein.

RANDs James Dewar schrieb 2002, dass jeder Plan ein „Geisterszenario“ hat — den unausgesprochenen Satz von Annahmen über die Zukunft, für den der Plan unbewusst zugeschnitten ist. Das Drei-Regeln-Framework ist im Kern ein Geisterszenario-Detektor. Es zwingt das Unsichtbare, sichtbar zu werden — egal ob der Plan ein Lieferantenvertrag, ein fiktives Universum oder eine Fünf-Jahres-Geschäftsstrategie ist.

Die Modelle werden jedes Quartal schlauer. Sie ehrlich zu machen, liegt nach wie vor an uns.

Quellen und weiterführende Lektüre

  • Dewar, J.A. et al. (1993/2002): „Assumption-Based Planning.“ RAND Corporation. Die grundlegende Methodik zur Identifikation, Prüfung und Planung um kritische Annahmen herum. Überblick bei MindTools.
  • Lambdin, C. (2024): „Assumption-Based Planning.“ Exzellenter Deep-Dive in ABP mit dem „Geisterszenario“-Konzept.
  • Ramírez, R. et al. (Dezember 2025): „A Faster Way to Build Future Scenarios.“ MIT Sloan Management Review. Über die Integration generativer KI in den Oxford Scenario Planning Approach.
  • Schwartz, P. (1991): „The Art of the Long View: Planning for the Future in an Uncertain World.“ Der Grundlagentext zur unternehmerischen Szenarioplanung.
  • Vorherige Beiträge in dieser Serie:
    ChatGPT und Claude wurden schlauer. Nicht ehrlicher. — Die ursprünglichen drei Regeln für Dokumentextraktion.
    Von der Vertragsanalyse zur Alternate History — Anpassung der Regeln für Worldbuilding.

Von der Dokumentenanalyse zur Alternate History: Warum die drei Ehrlichkeits-Regeln auch fürs Worldbuilding funktionieren

Vor ein paar Wochen habe ich über drei Prompt-Regeln geschrieben, die KI davon abhalten zu raten, wenn sie Daten aus Dokumenten extrahiert. Die Regeln — Leerlassen erzwingen, Raten bestrafen, Quelle zeigen — waren für unspektakuläre Geschäftsprobleme gedacht: Verträge mit widersprüchlichen Klauseln, Meetingnotizen mit mehrdeutigen Zusagen, Rechnungen mit fehlenden Feldern.

Aber je mehr ich sie anwandte, desto stärker fiel mir etwas auf: Dieselben Regeln lösen ein völlig anderes Problem — eines, das mit Geschäftsdokumenten nichts zu tun hat.

Sie lösen Worldbuilding.

Das Problem: KI als Continuity Editor

Jeder, der versucht hat, ein LLM für längerfristige kreative Arbeit zu nutzen, kennt das Muster. Sie bauen eine alternative Zeitlinie, eine Fantasy-Welt, ein Science-Fiction-Universum, eine Pen-and-Paper-Kampagne. Sie haben hunderte Seiten Lore geschrieben. Sie geben sie an Claude oder ChatGPT und stellen eine Frage dazu, wie Ihre fiktive Welt funktioniert.

Und das Modell erfindet etwas.

Es konstruiert eine Fraktion, die nicht existiert. Es ordnet eine Technologie der falschen Epoche zu. Es „erinnert sich“ an einen Charakter, der nie in Ihren Notizen stand. Es platziert ein fiktives Ereignis selbstbewusst in einer realen historischen Periode — und bekommt dabei noch die reale Geschichte falsch. Der Output klingt plausibel, in sich konsistent, schön geschrieben — und widerspricht allem, was Sie aufgebaut haben.

Das ist dasselbe strukturelle Problem wie im vorherigen Post, nur in einer anderen Domäne. Das Modell ist darauf trainiert, vollständigen, kohärenten Output zu produzieren. Wenn Ihre Lore eine Lücke hat, füllt das Modell sie — weil Lücken füllen genau das ist, worauf es optimiert wurde. Ob die Lücke „Wie lauten die Zahlungsbedingungen in Abschnitt 4?“ ist oder „Was geschah im Imperialen Senat nach dem Divergenzpunkt?“, der Instinkt ist identisch: Etwas erfinden, das richtig klingt.

Die Forschung hat dafür im Fiction-Kontext einen eigenen Begriff: „Charakter-Halluzination“ (Wu et al., 2024) — wenn eine KI, die eine Rolle spielt, die etablierte Identität dieser Rolle verletzt. Das IJCAI-2025-Tutorial zu LLM-Rollenspielen nennt die allgemeine Herausforderung „controlled hallucination“: Das Modell muss innerhalb der etablierten Regeln einer fiktiven Welt kreativ erfinden, sich aber rigoros weigern, Dinge zu erfinden, die diese Regeln verletzen. Die Grenze zwischen produktiver Kreativität und lore-brechender Konfabulation ist genau die Grenze, die die drei Regeln ziehen sollen.

Die Anpassung: Worldbuilding hat zwei Kanons, nicht einen

Bei der Vertragsanalyse gibt es eine Quelle der Wahrheit: das Dokument. Extrahiere, was da ist, markiere, was fehlt, erfinde nichts.

Bei Alternate History gibt es zwei gleichzeitig wirkende Wahrheitsquellen:

  1. Reale Geschichte — alles, was in unserer Welt passiert ist, bevor die Geschichte von ihr abweicht
  2. Ihre Lore — alles, was Sie darüber etabliert haben, was nach der Divergenz passiert

Beides ist kanonisch. In beidem darf die KI nichts erfinden. Und die Grenze zwischen beidem ist scharf: der „Divergenzpunkt“ (Point of Divergence, POD), der Moment, in dem Ihre fiktive Zeitlinie von der realen Geschichte abbricht.

Vor dem POD muss die KI ein Historiker sein. Sie kann auf reale Personen, reale Technologien, reale Schlachten, reale Ereignisse verweisen — aber nur auf Dinge, die tatsächlich passiert sind. Eine Schlacht zu erfinden, die nicht stattgefunden hat, oder eine Person, die nicht existierte, ist genauso schlimm wie eine Vertragsklausel zu erfinden.

Nach dem POD muss die KI ein Continuity Editor sein. Nur die Dinge existieren, die in Ihrer Lore etabliert sind. Alles andere ist eine Lücke — und Lücken sollten markiert, nicht gefüllt werden.

Hier kommen die drei Regeln ins Spiel, fast unverändert.

Die drei Regeln, angepasst

Regel 1: Leerlassen erzwingen → Lücken markieren

Bei der Dokumentextraktion lässt das Modell ein Feld LEER, wenn die Daten fehlen, und begründet warum. Beim Worldbuilding gilt dasselbe Prinzip mit zwei Labels statt einem — weil es zwei Arten von Lücken gibt:

  • [HISTORISCHE LÜCKE] — für Ereignisse vor dem Divergenzpunkt, bei denen das Modell nicht sicher ist. Keine Biografie eines römischen Konsuls erfinden; die Lücke markieren.
  • [LORE-LÜCKE: Dazu gibt es bisher keine etablierten Vorgaben] — für Entwicklungen nach dem Divergenzpunkt, die Ihre Lore nicht abdeckt. Keine neue Fraktion, Technologie oder Großereignis erfinden; die Lücke markieren.

Der entscheidende Schritt ist derselbe wie zuvor: Dem Modell explizit die Erlaubnis geben, nicht zu wissen. Ohne diese Erlaubnis überschreibt der Vervollständigungsinstinkt des Modells seine Unsicherheitserkennung, und Sie bekommen selbstbewusst geschriebene Halluzinationen, die sich anfühlen wie Kanon, es aber nicht sind.

Regel 2: Raten bestrafen → Eine falsche Erfindung ist schlimmer als eine Lücke

Die Geschäftsversion dieser Regel lautet: „Eine falsche Antwort ist 3× schlimmer als ein leeres Feld. Im Zweifel lass es leer.“

Die Worldbuilding-Version ist noch strenger, weil die Konsequenzen gravierender sind. Ein falscher Zahlungsbegriff in einer Tabelle wird korrigiert. Ein falsches Lore-Detail, das in Ihren Kanon aufgenommen wird, weil es richtig klang, kann hunderte Stunden weiterer Arbeit vergiften. Jede spätere Referenz baut darauf auf. Jeder Charakter interagiert damit. Bis Sie es bemerken, ist es durch Ihre Welt gewoben.

Also wird aus der Regel:

Eine falsche Erfindung ist schlimmer als das Eingestehen einer Lücke im Worldbuilding.

Kein Multiplikator nötig. Die Asymmetrie ist total. In kreativer Arbeit ist eine Lücke eine Einladung, Ihre Lore zu Ihren eigenen Bedingungen auszubauen. Eine schlechte Erfindung ist ein Bug, der in Produktion geht.

Regel 3: Die Quelle zeigen → Drei Provenance-Tags statt zwei

Bei der Dokumentextraktion ist jeder Wert entweder EXTRAHIERT (direkt aus der Quelle) oder ABGELEITET (berechnet oder hergeleitet). Beim Worldbuilding brauchen Sie drei Tags, weil Sie zwei kanonische Quellen plus Ihre eigene Extrapolation haben:

  • (HISTORIE) — reale historische Fakten vor dem Divergenzpunkt
  • (LORE-BELEGT) — genau so in Ihren Lore-Texten enthalten
  • (LORE-INFERIERT) — eine logische Konsequenz, die das Modell aus Ihrer Lore ableitet, mit einsätziger Begründung

Das dritte Tag ist, wo die Magie passiert. Sie wollen, dass das Modell extrapoliert — genau das macht es fürs Worldbuilding nützlich. Eine etablierte Technologie muss Konsequenzen haben; eine etablierte Fraktion muss mit anderen Fraktionen interagieren; ein etabliertes Ereignis muss Folgewirkungen haben. Aber Sie wollen diese Extrapolationen markiert, damit Sie sie prüfen und entscheiden können, ob sie zu Ihrer Vision passen. Eine markierte Inferenz, der Sie widersprechen, korrigieren Sie in dreißig Sekunden. Eine unmarkierte Inferenz, die still zum Kanon wird, auseinanderzufieseln dauert drei Sessions später Stunden.

Der kombinierte Prompt

Hier ist die vollständige Adaption, strukturiert als System-Prompt, den Sie in jeden länger laufenden Chat zu Ihrer fiktiven Welt kopieren können. Ersetzen Sie die Platzhalter mit Ihrem eigenen Setting.

Wir bauen eine alternative Zeit, die im Jahr [JAHR] beginnt mit [ÄNDERUNG / DIVERGENZPUNKT]. Du bist mein Historiker und Continuity Editor für dieses Alternate-History-Universum. Deine Aufgabe ist es, Texte, Antworten und Lore-Konzepte zu erstellen, die absolut widerspruchsfrei sind.

Die wichtigste Grundregel (der Divergenzpunkt): Das Jahr des Divergenzpunktes ist [JAHR].

Regel 1 — VOR dem Divergenzpunkt (strikte Historie):
• Alles, was vor diesem Datum passiert ist, MUSS zu 100 % der realen, verifizierbaren irdischen Geschichte entsprechen.
• Erfinde keine historischen Personen, Technologien, Schlachten oder Ereignisse.
• Wenn du ein historisches Detail nicht sicher weißt, erfinde es nicht. Nutze stattdessen den Platzhalter [HISTORISCHE LÜCKE].

Regel 2 — NACH dem Divergenzpunkt (strikter Lore-Kanon):
• Alles, was nach diesem Datum passiert, darf AUSSCHLIESSLICH auf den von mir bereitgestellten Lore-Texten basieren.
• Erfinde keine neuen Fraktionen, Hauptcharaktere, Großereignisse oder fundamentalen Technologien, die nicht in meinen Texten etabliert wurden.
• Wenn du nach Entwicklungen gefragt wirst, zu denen meine Lore keine Angaben macht, antworte mit [LORE-LÜCKE: Dazu gibt es bisher keine etablierten Vorgaben]. Eine falsche Erfindung ist schlimmer als das Eingestehen einer Lücke im Worldbuilding.

Regel 3 — Quellen- und Logik-Kennzeichnung:
Um das Worldbuilding sauber zu halten, markiere am Ende jedes Absatzes oder bei jeder wichtigen Behauptung in Klammern, woher die Information stammt:
• (HISTORIE) für reale historische Fakten vor dem Divergenzpunkt
• (LORE-BELEGT) für Fakten, die exakt so in meinen Texten stehen
• (LORE-INFERIERT) für logische Schlussfolgerungen aus meiner Lore (z. B. wie sich eine etablierte Technologie auf den Alltag auswirkt). Wenn du etwas inferierst, erkläre in einem kurzen Satz, woraus du das ableitest.

Jahr einsetzen, Divergenzereignis einsetzen, Lore-Dokumente anhängen — und Sie haben einen Continuity Editor, der sich aktiv weigert, Sie anzulügen.

Was das ermöglicht

Die Workflow-Änderung ist erheblich. Ohne diese Regeln müsste jeder KI-generierte Absatz gegen die reale Geschichte und Ihre eigenen Notizen geprüft werden — was niemand tatsächlich tut, was bedeutet, dass Fehler sich still ansammeln. Mit den Regeln geht Ihre Aufmerksamkeit genau dahin, wohin sie gehört: zu den Lücken (wo Sie entscheiden, was Ihre Welt als Nächstes tut) und zu den Inferenzen (wo Sie die Extrapolation des Modells freigeben oder verwerfen).

Ein paar Beobachtungen aus der Praxis:

Die Lücken sind oft der interessanteste Output. Wenn das Modell [LORE-LÜCKE] markiert, ist das der Moment, in dem Sie erkennen, dass Ihre Lore ein Loch hat — und oft ist dieses Loch genau das Nächste, was Sie entwickeln sollten. Das Modell versagt nicht beim Antworten; es sagt Ihnen, wo Ihre Welt mehr Arbeit braucht.

Inferenzen legen die Implikationen Ihrer Lore offen. Ein gut markierter (LORE-INFERIERT)-Absatz bringt oft Konsequenzen zutage, die Sie nicht durchdacht hatten. „Sie haben etabliert, dass Fraktion X die Handelsroute in Y kontrolliert; daraus folgt, dass Hafenstadt Z wirtschaftlich abhängig wird, was Spannungen mit Nachbar W nahelegt.“ Das ist nützlich, selbst wenn Sie die konkrete Extrapolation ablehnen — sie zeigt Ihnen eine logische Konsequenz Ihres eigenen Setups.

Reale Geschichte hält die Fiktion geerdet. Alternate History funktioniert am besten, wenn das „Vorher“ korrekt ist. Wenn Ihre Zeitlinie 1914 divergiert und das Modell die Welt vor 1914 falsch darstellt, verliert die ganze Divergenz an Bedeutung. Erzwungene (HISTORIE)-Labels — und die Pflicht, [HISTORISCHE LÜCKE] bei Unsicherheit zu markieren — halten das Fundament solide.

Das tiefere Muster

Was ich bemerkenswert finde, ist, dass dieselben drei Regeln in zwei Domänen funktionieren, die nichts gemeinsam zu haben scheinen. Geschäftliche Dokumentextraktion und kreatives Worldbuilding teilen kein Vokabular, keine Zielgruppe, keinen Workflow. Aber sie teilen eine Struktur: In beiden Fällen muss der Nutzer, dass die KI zwischen was etabliert ist und was erfunden wurde unterscheidet und diese Grenze klar kennzeichnet.

Diese strukturelle Ähnlichkeit ist es wert, ernst genommen zu werden. Sie legt nahe, dass die drei Regeln nicht wirklich spezifisch für Verträge oder Fiktion sind — sie betreffen das allgemeine Problem, KI in jedem Kontext einzusetzen, in dem Quellentreue wichtiger ist als Sprachfluss. Juristische Recherche. Code-Refactoring gegen einen Styleguide. Historische Forschung. Medizinische Zusammenfassungen. Übersetzung gegen ein Glossar. Technische Dokumentation gegen eine Spezifikation. Literatur-Review im akademischen Bereich.

In all diesen Fällen arbeitet das Default-Verhalten der KI — einen selbstbewussten, vollständigen, kohärenten Output produzieren — gegen das eigentliche Bedürfnis des Nutzers: zu wissen, welche Teile des Outputs gestützt sind und welche die eigene Beigabe des Modells sind. „Leerlassen erzwingen“ gibt ihm die Erlaubnis, nicht zu wissen. „Raten bestrafen“ verschiebt das Kalkül zugunsten der Ehrlichkeit. „Die Quelle zeigen“ macht die Grenze zwischen Quelle und Erfindung sichtbar.

Drei Regeln. Je zwei Sätze. Anwendbar überall, wo Quellentreue zählt.

Die Alternate-History-Version ist nur eine Adaption. Ich bin neugierig, in welche anderen Domänen dieses Muster passt — wenn Sie eine finden, hören Sie es mir gerne sagen.

Quellen und weiterführende Lektüre