Deterministischer Kern, probabilistische Schale

Ein und derselbe Prompt, tausendmal an dasselbe Sprachmodell gestellt, bei Temperatur null – der Einstellung, die die Zufallsauswahl des nächsten Wortes abschaltet: 80 verschiedene Antworten [1]. Der Befund stammt nicht von Kritikern, sondern aus einem KI-Labor, das Ursache und Behebung gleich mitlieferte – die Antwort eines produktiv betriebenen Modells hängt an der Server-Last, weil die Rechen-Kernel je nach Auslastung anders summieren; mit batch-invarianten Kerneln wird die Ausgabe bitidentisch reproduzierbar [1]. Als Beleg, dass Sprachmodelle unbrauchbar wären, taugt das nicht – die Reproduzierbarkeit ließ sich nachrüsten. Es taugt als Hinweis, wo der eigentliche Abstand liegt: nicht in der Wiederholbarkeit, die ein Ingenieursteam herstellen kann, sondern in der Form des Nachweises, die sich nicht nachrüsten lässt. Auf der einen Seite eine Systemklasse, deren Verhalten aus Daten gelernt ist. Auf der anderen der aktuarielle Rechenkern, dessen Prüfregime diese Reihe vermessen hat – auf die definierten Stellen runden, exakt vergleichen, jede Abweichung einer Ursache zuführen (Modell-Kongruenz). Über die Frage, wo zwischen diesen Welten KI-Bausteine sitzen dürfen, wird im Aktuariat meist als Reifegrad-Frage verhandelt: Sind die Modelle schon gut genug? Die These dieses Textes ist, dass das die falsch gestellte Frage ist. Die Grenze zwischen deterministischem Kern und probabilistischer Schale ist keine Qualitätsschwelle, die bessere Modelle irgendwann überschreiten – sie ist eine Architektur-Entscheidung, die aus der Form des aktuariellen Nachweises folgt. Der folgende Text begründet das in vier Thesen, rechnet vor, was ein probabilistischer Baustein die Beweiskraft des Testens kostet, und beschreibt, wie die Grenze konstruktiv aussieht.

1 · Der Kern ist über die Form seines Nachweises definiert

Was diesen Text angeht, ist der Rechenkern kein Bauteil, sondern eine Pflichtenklasse: die Menge der Verarbeitungsschritte, deren Ergebnisse rechnungsrelevant werden – Prämie, Deckungskapital, Rückkaufswert, Rückstellung. Für diese Größen gilt, was als Fundament dieser Reihe gelegt ist: Sie sind auf definierte Stellen bestimmt, keine Schätzungen; jede Abweichung hat eine Ursache und erzeugt eine Bringschuld. Und sie werden verantwortet – gegenüber Wirtschaftsprüfer, Aufsicht und den Gremien, die der Verantwortliche Aktuar bedient.

Der Kontrollrahmen benennt die Form dieser Verantwortung. Der internationale Standard zur aktuariellen Praxis zählt zur Modellvalidierung drei Prüfungen, deren dritte hier die wichtigste ist: Das Modell passt zu seinem Zweck, es erfüllt seine Spezifikation – und seine Ergebnisse lassen sich reproduzieren oder verbleibende Differenzen erklären; validieren sollen, soweit es das Modellrisiko rechtfertigt, Personen, die das Modell nicht gebaut haben [2] – im Rechenkern rechtfertigt es das immer. Für die versicherungstechnischen Rückstellungen kennt der europäische Aufsichtsrahmen dieselbe Anforderung: Der DAV-Ergebnisbericht zur KI-Validierung referiert den Validierungsumfang nach der Delegierten Verordnung zu Solvency II einschließlich der „Angemessenheit und Reproduzierbarkeit des Ergebnisses” [3]. Reproduzierbarkeit ist hier kein Komfortmerkmal, sondern die Eintrittskarte: Was sich nicht wiederholen lässt, lässt sich nicht unabhängig prüfen – und was sich nicht unabhängig prüfen lässt, kann niemand verantworten, der es nicht selbst gebaut hat.

Drei Eigenschaften bilden zusammen die Nachweisform des Kerns. Erstens die Reproduzierbarkeit des Ergebnisses: Gleiche Eingabe und gleicher Konfigurationsstand erzeugen dasselbe Resultat – nicht ein ähnliches. Zweitens die Nachvollziehbarkeit des Rechenwegs: Jeder Schritt ist mit Eingaben, Zwischenwerten und angewandten Konventionen protokollierbar; erst das macht Abweichungen lokalisierbar und gibt ihnen die lesbaren Signaturen – eine laufzeitabhängige Differenz zeigt auf die Verzinsungslogik, eine altersabhängige auf die Tafel-Anbindung. Drittens die dauerhafte Korrigierbarkeit: Ein gefundener Fehler ist an einen benennbaren Rechenweg gebunden, sein Fix ist ein lokales, versioniertes Diff, und ein Regressionstest hält den Fall geschlossen. Diese drei Eigenschaften sind keine Gütesiegel, die ein System mehr oder weniger verdienen kann. Sie sind die Form, in der Korrektheit im aktuariellen Kontrollrahmen überhaupt nachgewiesen wird. Ein Ergebnis, das richtig ist, aber nicht in dieser Form vorliegt, ist im Prüfprozess kein Ergebnis – es ist eine Behauptung.

Eine Abgrenzung gehört an genau diese Stelle. Deterministisch meint hier die Ausführungs- und Nachweisform, nicht den Verzicht auf Stochastik. Eine Monte-Carlo-Bewertung mit fixiertem Szenariensatz und dokumentierten Startwerten ist in diesem Sinn deterministisch: Der Zufall steht als Verteilungsannahme im dokumentierten Soll, die Ausführung ist exakt reproduzierbar, der Rechenweg protokollierbar, ein Fehler lokal behebbar. Probabilistisch im Sinn dieses Textes ist ein Baustein, dessen Verhalten nicht aus einem dokumentierten Soll abgeleitet ist, sondern aus Daten gelernt – und der darum in dieser Nachweisform nicht geprüft werden kann, sondern nur in einer schwächeren. Wie viel schwächer, zeigt die zweite These.

2 · Ein probabilistischer Baustein nimmt dem grünen Lauf die Beweiskraft

Was geschieht, wenn ein einzelner Schritt der Kette durch einen gelernten Baustein ersetzt wird? Die verbreitete Antwort lautet: Man testet ihn eben gründlich. Genau diese Antwort lässt sich durchrechnen – zunächst für den Betriebszustand, den der Aufmacher beschreibt: eine Ausführung, die je Aufruf streuen kann, mit Fehlerwahrscheinlichkeit q.

Der Test wechselt seine Bedeutung. Im regelbasierten Kern beweist ein grüner Testfall die Korrektheit genau dieses Rechenwegs, dauerhaft, bis eine Konfigurationsänderung den Beweis sichtbar invalidiert – und er generalisiert begründet: Der Code verzweigt explizit über fachliche Klassen, derselbe Tarif durchläuft denselben Rechenweg, die Klassenabdeckung der Testfälle ist selbst prüfbare Arbeit. Fehler können nur in unbedachten Konstellationen wohnen, und jeder Fund verkleinert diese Menge dauerhaft. Bei streuender Ausführung sitzt der Fehler nicht in Konstellationen, sondern in jeder einzelnen Ausführung: Ein grüner Fall beweist nichts Dauerhaftes, nicht einmal über sich selbst. Aus dem Beweis wird eine Stichprobe – der grüne Lauf schätzt eine Fehlerrate, statt Korrektheit festzustellen. Wie wenig eine solche Stichprobe trägt, zeigt das Rechenbeispiel.

Rechenbeispiel

Was ein grüner Testlauf beweist

Eine Testsuite prüfe $n = 400$ Fälle; ein Bestandslauf umfasse $M = 10^{6}$ rechnungsrelevante Aufrufe (200 000 Verträge × 5 Größen). Der Baustein irre je Aufruf unabhängig mit Wahrscheinlichkeit $q$. Dann sind

$$P(\text{Suite grün}) = (1 - q)^{n}, \qquad E = M \cdot q$$

die Wahrscheinlichkeit eines grünen Laufs und die erwartete Zahl falscher Werte je Bestandslauf:

q je Aufruf	P(Suite grün)	erwartete falsche Werte je Bestandslauf
10⁻³	0,67	1 000
10⁻⁴	0,96	100
10⁻⁵	0,996	10

Der Umkehrschluss ist der härtere Befund: Nach 400 grünen Fällen ist mit 95 % Konfidenz nur $q \le 3/n = 0{,}75\,\%$ belegt („rule of three”) – also bis zu 7 500 erwartete falsche Werte je Bestandslauf. Eine belegte Schranke von $q \le 10^{-6}$ (ein erwarteter Fehler je Lauf) erforderte rund drei Millionen grüne Testfälle – und belegt wäre damit eine Rate, kein Ergebnis.

Einfrieren hilft weniger, als es verspricht. Der nächstliegende Einwand nimmt den Aufmacher beim Wort: Man fixiere die Gewichte, wähle stets das wahrscheinlichste Wort und erzwinge batch-invariante Kernel – dann ist die Ausführung nachweislich bitidentisch wiederholbar [1], die Größe $q$ verschwindet, und mit ihr die Statistik des Rechenbeispiels. Das ist korrekt, und es stellt genau eine der drei Eigenschaften aus These 1 her: die erste. Der Testbeweis bleibt trotzdem ein Punktbeweis. Denn die Generalisierung des grünen Falls lebte davon, dass der Rechenweg explizit über fachliche Klassen verzweigt – ein gelerntes Modell kennt diese Klassen nicht: Benachbarte Eingaben können verschieden behandelt werden, die Regionen gleichen Verhaltens liegen in Koordinaten, die kein Tarifwerk kennt, empirisch kartierbar, aus dem Soll nicht herleitbar – und die Karte verfällt mit dem nächsten Modellstand. Vierhundert grüne Fälle beweisen dann vierhundert Punkte. Auch die Signaturen brechen an dieser Stelle: Die Zerlegung der beobachteten Abweichung in benennbare Anteile – $\Delta = \delta_{\mathrm{impl}} + \delta_{\mathrm{mod}}$ im Kongruenz-Argument, $\delta_{\mathrm{konv}}$ im Emulations-Argument (Emulation statt Toleranz) – funktioniert, weil jeder Anteil fachlich lesbar an Tarif, Alter oder Laufzeit hängt. Ein Anteil $\delta_{\mathrm{prob}}$ trägt keine fachlich lesbare Struktur; grobe Ausreißer fängt zwar jede deterministische Plausibilitätsschranke, doch was sie passiert, ist klein genug, um plausibel zu sein – und gerade dort braucht die Prüfung Lesbarkeit statt Rauschen.

Und der Fix wandert dorthin, wo er möglich ist: nach draußen. Einen lokalen Patch gibt es im gelernten Baustein nicht. In der Praxis wird darum anders korrigiert: Bekannte Fehlermuster werden per Regel auf feste Pfade umgeleitet, Ausgaben durch Schranken- und Plausibilitätswächter gefiltert, Einzelfälle in Override-Tabellen festgeschrieben. Jede dieser Korrekturen ist deterministische Logik um das Modell herum – mit jedem Fix wächst das regelbasierte Gerüst, und der gelernte Anteil schrumpft zur Restgröße dahinter. Die Architektur konvergiert von selbst gegen die Grenze, die dieser Text zieht; der Umweg kostet die Zeit, in der der Kern nicht nachweisfähig war. Bleibt das Nachtrainieren – der teuerste Weg: Nach einem Modell-Update ist erneut zu validieren, weil schon ein erneutes Training das Modell erheblich ändern kann [3]. Für ein Prognosemodell mit Jahresrhythmus ist das ein tragbarer Prozess. Für einen Rechenkern, der laufend gezielte, einzeln getestete Korrekturen verarbeitet, ist es keiner: Jeder Fix wäre eine Gesamtvalidierung, und kein Fix wäre je abgeschlossen.

3 · „Wenn die Modelle besser werden” ist die falsch gestellte Frage

Die Reifegrad-Debatte hat eine eingebaute Wiedervorlage: Jede neue Modellgeneration stellt die Frage neu, ob es jetzt reicht – und jede Antwort verfällt mit der nächsten Generation. Wer die Grenze über Fehlerraten zieht, verhandelt sie jährlich. Tragfähig wird sie erst, wenn man sieht, dass sich hinter der Debatte zwei verschiedene Aufgabenklassen verbergen, deren Nachweisformen nicht kompatibel sind.

Die Validierungsliteratur dokumentiert beide Maßstäbe bereits. Der DAV-Ergebnisbericht definiert Modellstabilität für KI-Modelle als die Eigenschaft, „zuverlässig und konsistent ähnliche Vorhersagen für ähnliche Eingaben” zu liefern – und nennt das Reproduzierbarkeit [3]; derselbe Bericht führt an anderer Stelle die klassische Ergebnis-Reproduzierbarkeit des Validierungsrahmens [3]. Das ist kein Widerspruch, sondern – zu Recht – ein Maßstab je Objekt: Ein Storno- oder Schadenhäufigkeitsmodell schätzt eine Größe, deren wahrer Wert selbst unbeobachtbar ist; dort ist Ähnlichkeit unter Störung genau die Robustheit, die man verlangen kann. Zur selben Schätzklasse gehören längst auch maschinell gelernte Werkzeuge mitten in Solvency II – Proxy-Modelle im internen Modell, die eine unpraktikabel teure Simulation durch eine Näherung ersetzen und über Fehlerschranken gegen die Referenz-Simulation validiert werden. Nichts an diesem Text spricht gegen sie: Ihr Soll ist eine Schätzung, ihr Maßstab ist Ähnlichkeit, die Nachweisform passt zur Aufgabe. Die Nachrechnung eines Tarifwerks gehört nicht zu dieser Klasse. Ihr Soll ist kein latenter Parameter, sondern ein definierter Wert; ihr Maßstab ist Identität auf den definierten Stellen – $\varepsilon = 0$ nach erhobenen Konventionen. Wer einen gelernten Baustein in den Kern setzt, wechselt darum nicht das Werkzeug, sondern unbemerkt den Maßstab: Er behandelt eine Nachweis-Aufgabe als Schätz-Aufgabe. Die Grenze verläuft nicht zwischen klassischer und maschineller Methode – sie verläuft zwischen zwei Soll-Typen.

Die Aufsichtsperspektive stützt die Asymmetrie. Die EIOPA-Stellungnahme zu KI-Governance erwartet – wohlgemerkt für KI-Systeme unterhalb der Hochrisiko-Schwelle des AI Act – Aufzeichnungen zu Daten und Methodik, die Reproduzierbarkeit und Rückverfolgbarkeit ermöglichen [4]. Wo die Erklärbarkeit eines Systems begrenzt ist, folgt sie einer Proportionalitäts-Logik: Für Anwendungen ohne geeignete Alternativen können kompensierende Maßnahmen – stärkere Leitplanken, mehr menschliche Aufsicht – den Mangel ausgleichen [4]; auch statistische statt deterministischer Erklärungen lässt sie zu, sofern begründet und dokumentiert. Die Folgerung ist nun die dieses Textes, nicht der Aufsicht: Im Rechenkern trägt diese Begründung nicht, denn dort existiert die Alternative nicht nur – sie ist der Stand der Technik, deterministische Rechenwerke mit protokolliertem Rechenweg. Wer KI in den Kern setzt, wählt die begründungs- und kompensationsbedürftige Architektur an der einen Stelle, an der die nachweisfähige verfügbar ist. Dieselbe Stellungnahme nennt als einen Weg zu erklärbaren Ergebnissen, komplexe KI-Systeme nur zum Challenging und Feinjustieren traditioneller mathematischer Modelle einzusetzen [4] – KI als Herausforderer des Kerns, nicht als sein Ersatz.

Deshalb bleibt auch das eingefrorene, fehlerarme Modell draußen. Das ist der Punkt, an dem das Struktur-Argument die Reifegrad-Debatte endgültig verlässt. Angenommen, ein gelernter Baustein wäre bitidentisch reproduzierbar und träfe praktisch immer das richtige Ergebnis – woran würde man das nachweisen? These 2 hat es gezeigt: nicht am Testlauf, denn ohne fachliche Klassenstruktur beweist er nur Punkte. Bliebe der erschöpfende Abgleich gegen ein regelbasiertes Rechenwerk – Punkt für Punkt, über einen Eingaberaum, der mit Beiträgen, Stichtagen und Vertragshistorien kombinatorisch nicht abschließbar ist. Und selbst wo man ihn hinreichend dicht absuchte, stünde am Ende dies: Die Referenz, gegen die zertifiziert wird, muss vollständig existieren, gepflegt und versioniert werden – sie ist der Kern, den man zu ersetzen vorgab. Ein gelernter Baustein an dieser Stelle wäre die zweite, unlesbare Kopie eines Systems, das man bereits hat: zusätzliche Validierungslast ohne einen einzigen zusätzlichen Nachweis. Die Frage „Ist das Modell gut genug für den Kern?” verwechselt Trefferquote mit Nachweisform. Die richtige Frage lautet: Für welche Aufgaben ist eine Schätzung das angemessene Instrument? Das sind die Aufgaben der Schale.

4 · Die Schale ist kein Zugeständnis, sondern der Arbeitsort der KI

Wer die Grenze so zieht, hat KI nicht klein gemacht, sondern richtig platziert – denn ein großer Teil aktuarieller Arbeit ist kein Rechnen, sondern Übersetzung: Tarifwerke und Geschäftspläne in Konfiguration überführen, gewachsene Excel-Rechenwerke entziffern, Abweichungslisten triagieren, Befunde für Gremien aufbereiten. Das ist die Aufgabenklasse der Sprachmodelle. Die Architekturfrage ist nicht, ob sie dort arbeiten dürfen, sondern wie ihre Arbeit den Kern erreicht, ohne dessen Nachweisform zu beschädigen. Die Antwort hat zwei Richtungen und eine Regel.

Einwärts: Der Vorschlag wird zur Konfiguration, und die Konfiguration wird geprüft wie jede andere. Ein Sprachmodell, das ein Tarifdokument liest und eine Rechenkonfiguration vorschlägt, setzt dort an, wo Tarif-Onboarding seine Zeit kostet. Entscheidend ist das Artefakt zwischen Vorschlag und Wirkung: Der Vorschlag mündet in eine deklarative, diff-fähige, versionierte Konfiguration – dasselbe Format, das ein Aktuar von Hand schriebe. Die tragende Sicherung ist dabei nicht die menschliche Durchsicht; sie trägt die Verantwortung, nicht die Prüfung. Die Prüfung ist deterministisch und existiert schon: Die generierte Konfiguration durchläuft denselben Abgleich gegen Referenzwerte und Testfälle wie jede von Hand erstellte. Diese Anordnung konvertiert die Fehlerklasse – und das ist ihr eigentlicher Witz: Ein durchgerutschter Vorschlagsfehler ist kein streuender Modellfehler mehr, sondern ein Umsetzungsfehler im deterministischen Kern – reproduzierbar, tarifweit konstant, mit lesbarer Signatur, exakt die Fehlerart, für die das Prüfregime des Abgleichs gebaut ist. Die Softwaretechnik hat dieses Muster früh formalisiert: Schon bei den Program-aided Language Models bleibt dem Sprachmodell die Zerlegung des Problems als einzige Lernaufgabe, während das Lösen an den Interpreter delegiert wird [5] – das Modell formuliert, das Werkzeug rechnet.

Einwärts · Vorschlag → Artefakt → Freigabe

Auswärts: Fakten aus dem Protokoll, Sprache aus dem Modell. In der Gegenrichtung liefert der Kern protokollierte Fakten – welcher Rechenschritt zu einer Abweichung beiträgt, mit welchem Betrag, unter welcher Konfiguration –, und ein Sprachmodell verdichtet sie zu dem, was ein Gremium tatsächlich liest: eine Erzählung des Befunds, jeder Satz rückführbar auf Positionen im Rechen-Nachweis. Es erklärt nicht anstelle des Nachweises – es macht ihn lesbar; fällt die Verdichtung falsch aus, steht der Nachweis unverändert daneben.

Auswärts · Fakten → Verdichtung → Rückverweis

Die Regel, auf einen Satz gebracht: In den Kern führt kein Weg außer über ein deterministisch prüfbares Artefakt; aus dem Kern heraus trägt jede Aussage eine protokollierte Fundstelle. Alles Weitere – welches Modell, welcher Anbieter, welche Generation – ist unterhalb dieser Regel austauschbar, und genau das ist ihre Stärke: Die Architektur überlebt die Modellzyklen, über die die Reifegrad-Debatte stolpert.

Die Schale erbt ihre Belastbarkeit vom Kern. Zum Schluss gehört die Abhängigkeit ausgesprochen, die beide Hälften verbindet: Der Konfigurations-Vorschlag ist nur prüfbar, weil ein deterministischer Abgleich ihn gegen Referenzwerte halten kann; die Befund-Erzählung ist nur belastbar, weil ein Rechen-Nachweis ihre Fakten liefert. Eine KI-Schale um einen ungeprüften Kern automatisiert die Erzeugung von Zahlen, denen niemand trauen kann – schneller falsch, eloquenter unbelegt. Erst die Arbeit am Kern, von der Modell-Kongruenz bis zur Konventions-Erhebung, schafft das Fundament, auf dem probabilistische Werkzeuge produktiv werden. Die Reihenfolge ist darum keine Geschmacksfrage: erst der Kern, dann die Schale.

In unserer Beratungspraxis steht diese Grenzziehung am Anfang eines KI-Vorhabens – vor der Modellwahl, vor der Plattformfrage; wie wir dabei vorgehen, beschreibt die Seite Aktuarielle Automatisierung.