Warum KI-Antworten eine Gegenprobe brauchen

Die Demo läuft gut. Jemand tippt eine Frage ein, das Modell antwortet in sauberen Sätzen, alle im Raum nicken. Zwei Monate später steht dieselbe Funktion im Tagesgeschäft, und eine Sachbearbeiterin ruft an, weil in einem Bericht eine Zahl steht, die es so nie gegeben hat.

Das ist kein Ausreißer, sondern der Normalfall. Sprachmodelle erzeugen plausiblen Text; ob dieser Text stimmt, ist eine davon unabhängige Frage. Wer eine KI-Funktion in ein Fachsystem einbaut, baut deshalb nicht eine Komponente, sondern zwei: die, die antwortet, und die, die prüft.

Woher die falschen Zahlen kommen

Drei Ursachen sehen wir immer wieder, und sie verlangen unterschiedliche Gegenmaßnahmen.

Erstens: Das Modell antwortet aus dem Trainingswissen statt aus Ihren Daten. Fragt jemand „Wie hoch war der Materialaufwand im Juli?”, und das Modell hat keinen Zugriff auf die Juli-Zahlen, dann sagt es selten „weiß ich nicht”. Es erzeugt eine Zahl, die dem Format nach passt. Das ist keine Fehlfunktion, sondern genau das, wofür es gebaut wurde.

Zweitens: Der Kontext ist da, aber unvollständig. Retrieval liefert die sieben ähnlichsten Textabschnitte, und der achte hätte den entscheidenden Hinweis enthalten. Die Antwort ist dann nicht erfunden, sondern nur teilweise richtig — die unangenehmere Variante, weil sie sich nicht durch Nachrechnen entlarven lässt.

Drittens: Die Frage ist mehrdeutig, das Modell entscheidet still. „Umsatz letztes Quartal” kann Kalenderquartal oder Geschäftsquartal heißen, mit oder ohne Umsatzsteuer, konzernweit oder für eine Gesellschaft. Ein Mensch fragt nach. Ein Sprachmodell wählt eine Lesart und schreibt sie auf, ohne die Wahl zu erwähnen.

Die Gegenprobe gehört in die Architektur, nicht ins Prompt

Der verbreitete Reflex ist, die Anweisung zu verschärfen: „Antworte nur auf Basis der bereitgestellten Daten. Erfinde nichts.” Das hilft messbar, aber es ist eine Bitte, keine Garantie. Verlassen kann man sich nur auf Prüfungen, die außerhalb des Modells stattfinden.

In der Praxis bewährt sich eine Trennung in drei Schichten:

Die Abrufschicht entscheidet, was das Modell überhaupt zu sehen bekommt. Hier fällt die wichtigste Designentscheidung: Statt Freitextsuche über alles schränken wir hart ein — auf den Mandanten, den Zeitraum, die Belegart. Ein Modell, das nur die Juli-Daten einer Gesellschaft sieht, kann über den August einer anderen nichts Falsches sagen.

Die Antwortschicht erzeugt den Text und wird gezwungen, jede Aussage mit einem Verweis zu versehen. Nicht als Fußnote für Menschen, sondern als strukturiertes Feld: Zu jeder genannten Zahl gehört die Kennung des Datensatzes, aus dem sie stammt. Praktisch heißt das, das Modell nicht Prosa ausgeben zu lassen, sondern ein Objekt mit Feldern — Aussage, Wert, Quelle — aus dem der Fließtext danach zusammengesetzt wird.

Die Prüfschicht ist gewöhnlicher Code, kein Modell. Sie nimmt jede behauptete Zahl, schlägt sie in der Datenbank nach und vergleicht. Stimmt sie nicht, wird die Aussage nicht ausgeliefert. Das ist unspektakulär und genau deshalb verlässlich: Ein SELECT, das einen Betrag gegenprüft, halluziniert nicht.

Die Faustregel, die sich bei uns durchgesetzt hat: Alles, was sich rechnen lässt, wird gerechnet — nicht generiert. Das Modell formuliert, es rechnet nicht.

Was passiert, wenn die Prüfung anschlägt

Hier trennt sich brauchbare Software von Demos. Die naheliegende Reaktion — Fehlermeldung anzeigen — ist meistens die schlechteste. Sie überträgt das Problem an jemanden, der es nicht lösen kann.

Besser ist eine Abstufung:

1. Aussage weglassen, Rest ausliefern. Wenn von acht Feststellungen im Monatsbericht eine nicht belegbar ist, erscheinen sieben. Der Bericht bleibt nützlich.
2. Unsicherheit benennen, statt sie zu verstecken. „Für den Materialaufwand liegen im Juli keine gebuchten Belege vor” ist eine brauchbare Aussage. „Der Materialaufwand betrug 41.200 €” wäre in derselben Lage eine Erfindung.
3. Nachfrage statt Antwort. Bei mehrdeutigen Fragen ist die Rückfrage die richtige Ausgabe. Das kostet einen Klick und spart eine falsche Entscheidung.
4. Protokollieren, immer. Jede unterdrückte Aussage gehört ins Protokoll, mit Frage, Kontext und Grund. Diese Sammlung ist nach vier Wochen das wertvollste Dokument im Projekt — sie zeigt, wo die Daten löchrig sind.

Punkt vier wird regelmäßig unterschätzt. Wir haben mehr als einmal erlebt, dass das Protokoll der abgewiesenen Antworten ein fachliches Problem aufgedeckt hat, das nichts mit KI zu tun hatte: fehlende Buchungen, doppelt angelegte Stammdaten, ein Import, der seit Wochen still scheiterte.

Was das kostet

Eine geprüfte KI-Funktion ist teurer als eine ungeprüfte — in der Entwicklung etwa um die Hälfte, im Betrieb kaum. Der Aufschlag steckt fast vollständig in der Prüfschicht und in den Tests dafür.

Dem gegenüber steht ein Effekt, der sich schlecht beziffern, aber gut beobachten lässt: Geprüfte Funktionen werden benutzt. Ungeprüfte werden nach einigen Fehlgriffen stillschweigend gemieden — die Funktion bleibt im Menü, aber niemand klickt sie mehr an. Damit ist das gesamte Budget verloren, nicht nur der gesparte Aufschlag.

Wie wir vorgehen

Bei einem Vorhaben mit KI-Anteil klären wir vier Fragen, bevor die erste Zeile Anwendungscode entsteht:

• Welche Aussagen soll das System treffen? Nicht „Fragen beantworten”, sondern eine Liste. Aus ihr ergibt sich, was prüfbar sein muss.
• Woraus lässt sich jede dieser Aussagen herleiten? Wenn die Antwort „irgendwie aus den Dokumenten” lautet, ist die Aussage nicht produktionsreif.
• Was passiert im Zweifel? Weglassen, nachfragen oder benennen — die Entscheidung gehört ins Lastenheft, nicht in den Code.
• Wer sieht die abgewiesenen Fälle? Ein Protokoll ohne Leser ist eine Datei, die Speicherplatz kostet.

Das klingt nach viel Vorarbeit für eine Funktion, die in der Demo an einem Nachmittag stand. Der Unterschied ist, dass die Demo nach vier Wochen abgeschaltet wird und das geprüfte System nach vier Jahren noch läuft.

Kurz gefasst

Ein Sprachmodell ist ein hervorragender Formulierer und ein unzuverlässiger Zeuge. Wer beides trennt — Formulierung beim Modell, Wahrheitsprüfung im Code — bekommt eine Funktion, der Fachabteilungen trauen. Wer es nicht trennt, bekommt eine Demo mit langer Halbwertszeit im Sitzungsprotokoll und kurzer im Alltag.