Ein Berechnungskern für Browser und Server

Beim Tarifrechner der AXA-Autoversicherung war die Anforderung klar: Gleiche Eingaben müssen unter denselben Tarifregeln dasselbe Ergebnis liefern. Im Browser, auf dem Server und bei einer späteren Nachprüfung.

Deterministisch.

Wer solche Systeme entwickelt oder verantwortet, weiss, was daran hängt. Ein Betrag muss sich erklären lassen. Eine Abweichung braucht eine Ursache. Eine Tarifänderung muss sich vollständig und wiederholbar prüfen lassen.

KI verändert daran nichts.

Ein Kern, zwei Laufzeitumgebungen

Den Berechnungskern habe ich in reinem Java entwickelt. Die technischen Adapter lagen aussen. Die Tariflogik blieb unabhängig von Benutzeroberfläche und Serveranbindung – nach dem Prinzip der hexagonalen Architektur, auch «Ports and Adapters» genannt.

Diese Trennung hatte einen konkreten Nutzen: Derselbe Java-Quellcode lief auf dem Server und wurde mit dem Google Web Toolkit, kurz GWT, für den Browser nach JavaScript kompiliert.

Der Browser reagierte unmittelbar auf Eingaben und berechnete den Tarif neu. Für diese Berechnung war kein Serveraufruf nötig. Auf dem Server lief derselbe fachliche Kern zur Nachberechnung.

Die Tariflogik wurde einmal implementiert und in beiden Umgebungen eingesetzt.

Schnell im Browser. Nachgerechnet auf dem Server.

JavaScript läuft auf dem Rechner des Benutzers. Es lässt sich untersuchen und verändern. Obfuskation erschwert das Lesen, verhindert aber keine Manipulation. Auch ein übermittelter Betrag lässt sich verändern, ohne die Berechnung vollständig zu verstehen.

Deshalb wurde auf dem Server erneut gerechnet. Der vom Browser gelieferte Preis war keine verlässliche Grundlage für die weitere Verarbeitung.

Die lokale Berechnung sorgte für schnelle Rückmeldung. Die serverseitige Nachberechnung stellte sicher, dass ein manipulierter Browserbetrag nicht einfach übernommen wurde.

1000 Testfälle aus der Mathematik

Für den Tarifrechner habe ich aus fachlichen Anforderungen und rund 140 Excel- beziehungsweise CSV-Dateien ein Metamodell erstellt. Daraus wurden Klassen und weitere Softwareartefakte generiert.

Die fachliche Prüfgrundlage lieferte die Mathematik: eine Matrix mit 1000 Testfällen und den zugehörigen Eingabe- und Vergleichswerten. Alle 1000 Fälle wurden durch den Tarifrechner gerechnet und mit den gelieferten Ergebnissen verglichen.

Damit kamen die erwarteten Werte aus einer fachlich unabhängigen Quelle. Der Test prüfte die Umsetzung gegen die Vorgaben der Mathematik.

Entscheidend war die Festkommaarithmetik mit skalierten Ganzzahlen. Mit binären Gleitkommazahlen hatten sich über die Verrechnung der zahlreichen Tarifparameter Rundungsabweichungen aufgebaut. Die erforderliche Übereinstimmung erreichten wir damit nicht.

Deshalb wurden die Werte vor der Berechnung auf Ganzzahlen skaliert. So liessen sich Genauigkeit und Rundung gezielt beherrschen. Im Abgleich der Java- und JavaScript-Berechnungen mit den 1000 Referenzfällen der Mathematik blieb eine einzige Abweichung von einem Rappen.

Auch dieser eine Rappen war eine Abweichung. Der entscheidende Punkt war: Sie wurde sichtbar. Sie verschwand nicht zwischen manuell ausgewählten Stichproben.

Neue Tarife übernehmen – und vollständig prüfen

Das generative Framework machte diesen Ablauf wiederholbar. Neue Tarifdaten der Mathematik konnten als CSV übernommen werden. Daraus wurden die Klassen generiert und anschliessend sämtliche 1000 Testfälle ausgeführt.

So liess sich eine neue Tariflieferung in etwa zwei Stunden übernehmen und gegen die vollständige Testmatrix prüfen.

In einem anderen Team bedeutete die entsprechende Arbeit damals tagelange Kleinarbeit. Dort wurden die Tests von Hand und stichprobenhaft durchgeführt.

Der Unterschied lag im aufgebauten Verfahren: strukturierte Tarifdaten, regelbasierte Generierung und ein automatisierter Vergleich mit fachlich vorgegebenen Ergebnissen. Die Investition in dieses Verfahren zahlte sich bei jeder neuen Tariflieferung aus.

Die vollständige Ausführung der Matrix bewies dabei nicht, dass ausserhalb dieser 1000 Fälle kein Fehler möglich war. Sie stellte aber sicher, dass jeder dieser Fälle bei jedem Durchlauf geprüft wurde – mit denselben Vergleichsmassstäben.

Wo ich heute KI einsetzen würde

Bei einer vergleichbaren Aufgabe würde ich KI nutzen, um Unterlagen auszuwerten, mögliche Parameter zu identifizieren und Widersprüche aufzudecken. Auch bei der Entwicklung des Modells, des Generators und zusätzlicher Tests kann sie unterstützen.

Die Grenze liegt zwischen einem Vorschlag und einer bestätigten fachlichen Regel.

Eine von KI erkannte Abhängigkeit muss geprüft werden. Ein Parameter braucht eine fachliche Grundlage. Eine fehlende Regel darf nicht unbemerkt durch eine plausible Vermutung ersetzt werden.

Die Mathematik definiert die Tarife und liefert die fachlichen Referenzen. Die Software setzt die Regeln um. Automatisierte Tests prüfen die Ergebnisse. KI kann bei dieser Arbeit helfen; die Verantwortung und die Prüfmassstäbe bleiben bestehen.

Determinismus macht Änderungen beherrschbar

Determinismus allein garantiert keine Richtigkeit. Auch ein Fehler kann zuverlässig dasselbe falsche Ergebnis liefern. Deshalb braucht es eine unabhängige fachliche Prüfgrundlage.

Umgekehrt reicht ein einmal richtiges Ergebnis ebenfalls nicht. Es muss unter denselben Bedingungen wieder entstehen. Dafür müssen Tarifversion, Parameterstand, Zahlendarstellung und Rundungsregeln eindeutig sein.

Der gemeinsame Berechnungskern, die Generierung und die Referenzmatrix griffen beim AXA-Tarifrechner ineinander. Neue Tarife konnten übernommen, Softwareartefakte reproduzierbar erzeugt und alle gelieferten Testfälle erneut geprüft werden. Abweichungen liessen sich gezielt untersuchen.

Genau daran messe ich auch den Einsatz von KI: Hilft sie uns, solche Systeme besser zu verstehen, zu entwickeln und zu prüfen?

Der Tarif selbst muss stimmen. Deterministisch, nachvollziehbar und überprüfbar. Jedes Mal.