KI- und Python-Tools im Aktuariat: So gelingt der Weg in den Regelbetrieb

Wo endet das Aktuariat, wo beginnt die IT? Lange war die Antwort einfach: Das Aktuariat legt fest, was gerechnet wird, und die IT sorgt dafür, dass die Software läuft. Python, offene Bibliotheken und generative KI verwischen diese Grenze. Aktuar:innen entwickeln Modelle selbst, IT-Teams gestalten die Fachlogik mit, und KI erzeugt Code für beide Seiten. Wer heute ein Tool baut, sollte deshalb zwei Fragen stellen: Wer steht für das Ergebnis ein? Und was macht das Tool zum Asset statt zur Spielerei? Der Artikel folgt dem Lebenszyklus eines Tools, von der Idee über Bau und Betrieb bis zur Freigabe.

1. Idee: Vom Werkzeug zum Asset

Ein KI-gestütztes Tool ist in wenigen Tagen entwickelt. Ob es dauerhaft betrieben wird, entscheidet sich aber schon bei der Konzeption. Wer nur die Funktion im Blick hat, schafft eine Insellösung, die später nicht in Bestandsführung, Rechnungswesen oder Reporting passt.

Deshalb gehört die Systemlandschaft von Beginn an in die Überlegungen. Welche führenden Systeme liefern die Daten? Wohin fließen die Ergebnisse? Dispositive Systeme wie Bestandsführung, Rechnungswesen, Controlling und Reporting sind dabei der wichtigste Prüfstein. Ein Werkzeug ohne Anschluss erzeugt Doppelarbeit und zusätzliche Abstimmungsschleifen.

Vor dem Prototyp sollten daher fünf Fragen geklärt sein:

1. Woher kommen die Daten, und stammen sie aus einem führenden System?
2. Wohin fließen die Ergebnisse, und wer übernimmt sie?
3. Wer betreibt das Tool nach dem Go-live?
4. Welche Kennzahl oder Entscheidung verbessert sich messbar?
5. Lässt sich das Tool in bestehende Freigabe-, Berechtigungs- und Archivierungsprozesse einfügen?

Betriebskosten über mehrere Jahre, etwa für Wartung, Validierung und Know-how, werden häufig unterschätzt. Ein Tool mit klarer Datenherkunft, definierten Schnittstellen und benanntem Owner wird Teil der Steuerung. Ohne diese Antworten bleibt es eine Spielerei, auch wenn die Technik beeindruckt.

2. Bau: Rollen und Verantwortung

Der Bau teilt sich in drei Zonen. Die Fachlogik, also Rechnungsgrundlagen, Tarifmechanik und Annahmen, gehört zum Aktuariat. Umsetzung und Betrieb, also Architektur, Datenflüsse und Versionierung, liegen bei der IT. Dazwischen liegen Testfälle, Validierung, Datenqualität und Dokumentation. Hier entscheidet sich, ob die Grenze trägt.

Aktuar:innen können Modelle und Werkzeuge in Python selbst entwickeln. Dafür müssen sie nicht Softwareentwickler:innen werden, sollten aber Code lesen, Tests schreiben und Ergebnisse technisch prüfen können. Die IT stellt den Rahmen bereit: Entwicklungsumgebung, Versionsverwaltung, Zugriffe, Hosting und Freigabewege. Diese Rahmenbedingungen sind keine Bremse, sondern die Voraussetzung dafür, dass fachlich entwickelte Tools im Konzern betrieben werden dürfen.

Die Rollen verändern sich dabei. Aktuar:innen werden stärker zu Modellverantwortlichen, die Code bewerten können. Die IT wird fachlicher und braucht ein Gespür für Rechnungsgrundlagen, Stichtage und Ausnahmen im Bestand. Eine Schnittstellenrolle, etwa als Product Owner für Aktuarsoftware, übersetzt zwischen beiden Seiten.

KI-generierter Code braucht Referenzdatensätze und Regressionstests, die bei jeder Änderung laufen. Code, Annahmen und Ergebnisse gehören in ein gemeinsames Versionsmanagement. Jede Änderung an einer Rechnungsgrundlage wird mit Fachfreigabe dokumentiert.

Die Verantwortung lässt sich in einem Satz festhalten: Das Aktuariat spezifiziert, was richtig ist, die IT setzt es um, und beide prüfen die Ergebnisse gemeinsam. Die fachliche Spezifikation liegt beim Aktuariat, die IT übernimmt die Umsetzung. Referenzrechnungen und Testfälle verantwortet das Aktuariat, die IT unterstützt bei der technischen Umsetzung. Beim Code-Review prüft die IT-Struktur und Logik, das Aktuariat bewertet die fachliche Wirkung. Wer den Code schreibt, sollte die Freigabe nicht allein erteilen.

3. Betrieb: Klassische IT-Themen nicht vergessen

Ein schnell gebautes Tool läuft oft zuerst auf einem Laptop oder in einer Testumgebung. Damit es in den Regelbetrieb überführt werden kann, werden auch bei KI-Lösungen klassische IT-Themen relevant. Dazu gehören Aspekte, die im Projekt leicht untergehen:

• Hosting und Cloud-Betrieb: Wo läuft das Tool, wer administriert die Umgebung, und wo liegen die Daten?
• CI/CD, Deployment und Release-Management: Wie kommt eine Änderung in den Produktivbetrieb, mit welchem Test, welcher Freigabe und welchem Rückweg?
• Monitoring und Betriebsüberwachung: Wer erkennt Ausfälle, Fehlläufe oder auffällige Ergebnisse, und wer reagiert?
• Zugriff und Berechtigungen: Wer darf Code, Daten und Parameter ändern?
• Backup und Wiederanlauf: Was passiert bei einem Ausfall, und wie schnell ist das System wieder verfügbar?
• Abhängigkeiten und Lizenzen: Welche Bibliotheken und Dienste werden genutzt, und wer pflegt sie?

Das Aktuariat bleibt in der fachlichen Verantwortung und legt fest, welche Verfügbarkeit, Genauigkeit und Kennzahlen gelten. Die IT betreibt die Lösung. Für jedes Tool braucht es einen benannten Service-Owner, der nach dem Go-live erreichbar ist. In der Praxis fehlt dieser Service-Owner häufig. Das Tool geht dann ohne Ansprechpartner in den Betrieb und es entsteht genau die Spielerei, die am Ende nicht nachhaltig genutzt werden kann.

4. Freigabe: Regulatorik und Nachweise

Die regulatorischen Anforderungen gelten von Beginn an. Die Nachweise entstehen deshalb während der Entwicklung und nicht erst am Projektende. Wer sie nachträglich erstellen muss, verliert Zeit und Vertrauen.

• DORA gilt seit 17. Januar 2025. IKT-Risikomanagement, Änderungsmanagement und Drittdienstleister betreffen auch Aktuarsoftware.
• Solvency II verlangt die Validierung interner Modelle. Die Versicherungsmathematische Funktion äußert sich zu Rückstellungen und Zeichnungspolitik.
• MaGo verlangt klare Zuständigkeiten, Funktionstrennung und die Steuerung ausgelagerter Tätigkeiten.

Hinzu kommen konzerninterne Vorgaben, die oft strenger sind als die externen Mindestanforderungen:

• Informationssicherheit: Einstufung von Daten und Systemen, Zugriffskonzepte und Schutz von Modellen und Parametern vor unberechtigter Änderung.
• Architekturvorgaben: zulässige Technologien und Hostingstandorte, Anbindung über zentrale Plattformen und ein Architekturreview vor dem Go-live.
• Datenschutz: Umgang mit personenbezogenen Daten in Testumgebungen und bei externen KI-Diensten.
• Sourcing und Auslagerung: Freigabe externer Entwickler, Dienstleister und KI-Anbieter, einschließlich der vertraglichen Vorgaben.
• Dokumentation und Archivierung: einheitliche Ablage von Spezifikation, Testprotokollen und Freigaben über die gesamte Aufbewahrungsfrist.

Wer diese Vorgaben erst bei der Abnahme berücksichtigt, baut ein Tool, das im Konzern nicht betrieben werden darf. Sie gehören deshalb in die Anforderungsphase.

Die Verantwortung für die Freigabe knüpft an den Bau an und erweitert ihn um den Betrieb. Der Modell-Owner im Aktuariat gibt jeden Modellstand frei, unterstützt von der Versicherungsmathematischen Funktion. Hosting, Deployment und Monitoring liegen überwiegend bei der IT, wobei das Aktuariat die fachlichen Anforderungen an Verfügbarkeit, Datenhaltung und Kennzahlen vorgibt. Versionierung und Dokumentation tragen Modell-Owner und IT gemeinsam.

Autor: Max Hopperdietzel,​ erfahrener Lead Business Analyst bei Convista in der Umsetzung nationaler und internationaler Projekten in der Versicherungsbranche. Mit seinem fundierten Wissen stellt er die Schnittstellenkompetenz für fachliche, technologische und aktuarielle Themen in diversen Sparten.