Ein Unternehmen so umbauen, dass KI darin möglichst gut arbeiten kann

In dieser Folge spricht Felix mit Daniel Schulze Lammers, Vorstandsvorsitzender der HDI Versicherung. Daniel verantwortet das Sachversicherungsgeschäft der HDI Gruppe in Deutschland, von der Privathaftpflicht über Kraftfahrt bis zu kleinen Unternehmen. In der Versicherung findet KI nicht neben dem Kerngeschäft statt, sondern mitten darin: bei der Frage, wie Risiken bewertet, Schäden bearbeitet und Kunden betreut werden.

Die beiden drehen die übliche Reihenfolge um. Statt mit der KI-Reise der Vergangenheit zu beginnen, fragen sie: Wie muss eine Versicherung gebaut sein, damit KI darin gut arbeiten kann? Daniels Antwort führt weg vom Denken in Systemen und hin zu Kontext, Entscheidungen und neuen Rollen. Und er erklärt, warum er das als Vorstandsaufgabe sieht.

Über den Gast

Daniel Schulze Lammers ist Vorstandsvorsitzender der HDI Versicherung und verantwortet das Sachversicherungsgeschäft der HDI Gruppe in Deutschland. Er beschäftigt sich auch persönlich intensiv mit KI und teilt seine Gedanken dazu immer wieder auf LinkedIn.

Ein Arcade-Spiel als KI-Experiment

Der Einstieg ist ein privates Projekt: Daniel wollte mit seinen Neffen einen kleinen Hackathon machen und ein Arcade-Spiel bauen. Zur Vorbereitung hat er selbst eins programmiert, an einem Nachmittag, mit Claude als Sparringspartner. Programmiert hatte er seit 20 Jahren nicht mehr.

Das Spiel stellte er als Gag in einen Teams-Kanal: Wer knackt den Highscore? Schnell fand jemand heraus, dass man den Wert direkt über die Schnittstelle ändern kann. Daraus wurde ein Wettbewerb, bei dem Daniel das Sicherheitsniveau immer weiter erhöhte und inzwischen fünf, sechs Leute mit Bots versuchen, die Schnittstelle anzugreifen. Für Daniel zeigt das, was mit KI möglich ist, und wie man sich dem Thema spielerisch nähern kann.

Für KI bleibt keine Zeit wie für Agile

Am meisten beeindruckt hat Daniel, wie schnell guter Code entsteht. Er hat die Architektur immer wieder umgebaut, was früher Monate gedauert hätte.

Das Projekt hat seinen Blick auf die Softwareentwicklung verändert. HDI arbeitet in der IT mit einem SAFe-Framework, mit zwei Wochen Sprint und dann Review. Für die Arbeit mit KI passt das aus seiner Sicht nicht mehr richtig. Und die Zeit für die Umstellung wird kürzer: Nach Daniels Erinnerung hat die Branche rund fünf Jahre gebraucht, um Agile einzuführen. So lange darf es bei KI nicht dauern.

Abschied vom Zielbild

Felix fragt nach dem Zielbild für die nächsten fünf Jahre. Daniel widerspricht dem Begriff: Niemand weiß wirklich, wo KI in fünf Jahren steht.

… der Vorstellung von Zielbildern müssen wir uns 'n bisschen verabschieden, denn es gibt nicht mehr dieses Plateau, zu dem man sich hinentwickelt

Es geht stattdessen darum, mit möglichst hoher Entwicklungsgeschwindigkeit mitzuhalten. Richtungen lassen sich trotzdem erkennen, und um die geht es im Rest der Folge.

Warum KI in heutigen Kernsystemen feststeckt

Versicherungen sind in großen Teilen um Kernsysteme herum gebaut: ein Schadensystem, eine Bestandsführung mit Vertrags- und Zahlungsdaten, Buchhaltung, ein Vertriebssystem. Um diese Systeme sind Abteilungen entstanden, darauf sitzen Prozesse.

Genau das macht KI-Optimierung schwer. Wie andere hat HDI zuerst die bestehenden Prozesse optimiert, kam aber über Daten auslesen, Daten einspielen und Zusammenfassungen kaum hinaus. Ein Schaden kommt per E-Mail oder Brief, es fehlen Informationen, ein Brief geht raus, und das wiederholt sich. So dauert eine Schadenbearbeitung oft mehrere Wochen.

Deshalb dreht Daniel die Frage um: Was braucht KI eigentlich, damit sie gut funktioniert, und wie muss man das Unternehmen dafür aufbauen?

Kontext ist das A und O

Die erste Richtung ist Kontext. Bei allen starken Use Cases von HDI war das der Erfolgsfaktor: viel mehr Kontext bereitstellen als vorher, und zwar nicht strukturiert, sondern so, wie der Schaden reinkam, mit dem echten Polizeibericht und der Schadenmeldung des Kunden.

Oft ist dieser Kontext aber nicht da. Deshalb braucht es einen Context Layer, der den Kontext aus dem ganzen Unternehmen zugänglich macht. Daniels Beispiel: Hat ein Marder das Kabel durchgebissen, erkennt eine KI schnell, welche Versicherung greift. Dafür muss sie aber den Brief des Kunden sehen.

In Entscheidungen denken

Die zweite Richtung: in Entscheidungen denken. Eine Versicherung trifft fünf, sechs wirklich große Entscheidungen in hoher Frequenz. Zahlen wir den Schaden aus? Versichern wir den Kunden? Versichern wir ihn zu diesen Konditionen weiter?

Diese Entscheidungen kann KI sehr gut vorbereiten, wenn der Kontext da ist und die Prozesse auf die Entscheidung hinlaufen. Davor liegen viele Schritte, bei denen KI hilft: Liegt der Polizeibericht vor, gibt es ein Gutachten, fehlt ein Teil der Unfallbeschreibung? Entscheiden tut bei HDI am Ende ein Mensch, aus regulatorischen und vielen anderen Gründen.

Mit Entscheidungsbäumen ist Daniel vorsichtig: Die Kunst ist herauszufinden, wie viel Regelwerk es braucht und wie viel Freiraum möglich ist.

Ergebnis vorgeben, aber mit klarem Rahmen

Felix beobachtet bei seiner eigenen Arbeit: Gibt er einer KI jeden Schritt vor, werden die Ergebnisse schlechter. Besser ist es, Auslöser, erwartetes Ergebnis, Kriterien, Schnittstellen und Kontext vorzugeben und den Weg dazwischen dem Modell zu überlassen.

Daniel sieht dieselbe Tendenz, mit zwei Einschränkungen. Bei der Softwareentwicklung ist KI weiter. Bei der Frage, welche Informationen eine Schadenprüfung genau braucht, verirren sich die Modelle noch. Und die Branche ist hoch reguliert: Man darf nicht zu wenig oder zu viel auszahlen, weil eine KI etwas falsch gemacht hat. Deshalb braucht es einen klaren Rahmen und immer wieder deterministische Schritte, an denen jemand draufschaut.

Trotzdem verschiebt sich viel. Vor einem Jahr hätte man noch alles deterministisch abgebildet und nur die Datenextraktion mit KI gemacht. Heute sagt man eher: Schau dir die 800 Dokumente in diesem Fall an und erklär, was der Sachverhalt ist.

Regeln und KI-Agenten trennen, Oberflächen zuletzt

HDI denkt in einem deterministischen und einem probabilistischen Block. Regelwerke, Vorgaben und Prozessschritte werden getrennt von dem, was ein KI-Agent tut. So lässt sich prüfen, ob beides zusammenpasst, und Regeln lassen sich ändern, ohne den Rest umzubauen.

Die Oberfläche kommt bei HDI zuletzt. Heute beginnt man oft mit der Maske im Prozess. Daniel beginnt mit der Frage, was im Use Case zu tun ist und an welchen Stellen ein Mensch in oder über der Schleife sitzen soll. Erst dann wird die Oberfläche für genau diese Aufgabe gebaut.

Human in the Loop und Human on the Loop

HDI braucht beides. Alle relevanten Entscheidungen treffen Menschen: Wird der Schaden ausgezahlt, wird der Kunde versichert, wie reagiert man auf ein verändertes Risiko? Das ist der Human in the Loop, und Daniel hält das für richtig.

Die Rolle des Human on the Loop entsteht gerade erst. Diese Person schaut in die Agenten hinein: Welcher macht gute Vorschläge, welcher braucht mehr oder anderen Kontext, und wie hält man das System am Leben? Dafür braucht es technisches Wissen und tiefes Fachwissen zugleich.

Das kommt ja heute noch in keiner Arbeitsbeschreibung vor, irgendwie Human on the Loop zu sein.

In der Rolle verschmelzen Aufgaben, die früher auf Business Owner, Business Analyst, Entwicklung und Test verteilt waren.

Ein Unternehmen, in dem KI-Profis arbeiten können

Felix macht die Frage noch greifbarer: Wie gestaltet man ein Unternehmen, damit KI-Profis gut darin arbeiten können? Daniel erinnert sich: Vor zwei Jahren hat HDI gute Leute gewonnen, die dann in einem Gerüst steckten, in dem wenig möglich war. Es fehlten saubere Daten, Entwicklungsumgebungen und ein Technologiestack, mit dem man ernsthaft entwickeln kann. Einige waren kurz davor zu sagen, dass das so keinen Sinn macht:

Textextraktion ist nett, aber dafür bin ich hier nicht angetreten.

Erst als HDI grundsätzlicher überlegte, wie alle Daten bereitgestellt werden und wie die Organisation lernt, dass das wichtig ist, wurde es besser. Jetzt merkt Daniel, wie die Hebelwirkung Einzelner wächst, weil sie die Werkzeuge haben.

Drei Bereiche: Produktivität, Code und Business AI

HDI teilt das Thema in drei Bereiche. Erstens Personal Productivity mit Copilot und Frage-Antwort-Anwendungen, eingeführt wie bei den meisten. Zweitens Code Development: HDI entwickelt inzwischen Code, der von vornherein Compliance-Richtlinien, Vorgaben und Corporate Design einhält. Eine Code Factory ist das noch nicht. Die Technik ist dabei nicht die Hürde, sondern die Organisation, die nicht mehr in die klassische agile Welt passt.

Drittens Business AI, wo der größte Ehrgeiz liegt. HDI baut nicht zwei Jahre Infrastruktur, um dann den ersten Use Case zu haben, sondern baut die Infrastruktur Use Case für Use Case mit auf.

jeder Use Case, den wir haben, muss sich nicht nur rechnen, sondern muss sich auch sehr deutlich rechnen.

Das klappt, weil die ersten Use Cases viel Nutzen bringen. Ein Beispiel ist die Risikosituation von Kunden: Bei jemandem, der seit 20 Jahren versichert ist, kommen leicht sehr viele Dokumente zusammen, von Korrespondenz über Besichtigungsberichte bis zu Brandschutzkonzepten. Allein das aufzubereiten zeigt, wo man mit dem Kunden reden sollte. Eine solche Domänentransformation mit neuer Infrastruktur macht HDI bisher in zwei Bereichen: Schaden und Firmenkundengeschäft.

Wie der Context Layer entsteht

Einen Context Layer kann man nicht als Standardsoftware kaufen. Es beginnt beim Input Management: Wie werden Dokumente gescannt, E-Mails eingelesen und Dateien sauber abgelegt? HDI baut eine eigene Schicht über dem Archiv, eng damit verbunden, mit Formaten wie JSON und Markdown.

Jeder neue Agent greift auf den Wissensstand zu, den die Agenten vor ihm erzeugt haben. Der erste erkennt eine Schadenmeldung, der zweite stellt fest, dass Daten fehlen, der dritte holt sie ein. So wächst das Wissen über den Fall. Ist eine klare Entscheidung getroffen, etwa eine Auszahlung, wird sie ins System of Record geschrieben und gebucht. So bleibt klar, was am Ende entschieden wurde.

Alles auf einmal aufzuschreiben, wäre aussichtslos. Deshalb der Vorgehensplan mit zwei Bereichen. Das Wichtigste bleibt das Lernen, auch aus Entwicklungen in die falsche Richtung.

Warum KI Vorstandsaufgabe ist

Felix erlebt selten CEOs in dieser Größenordnung, die so tief im Thema stecken. Daniel hört oft von KI-Verantwortlichen, die gegen ihr Board anarbeiten müssen. KI ist für ihn anders als frühere Technologien wie Robotics oder die erste Welle der Digitalisierung: Sie verändert das Unternehmen grundlegend und mit hoher Geschwindigkeit. Wenn der Vorstand nicht zumindest grob verstanden hat, wohin es gehen muss, kann die Mannschaft die nötige Veränderung gar nicht einleiten.

Er ist überzeugt, dass Wissen heute so verfügbar ist wie nie zuvor: Man kann sich an einem Wochenende tief genug in ein Thema einarbeiten, um auf gutem Niveau mitzudiskutieren. Den richtigen Weg zu finden und die Verantwortung dafür zu übernehmen, ist für ihn Führungsaufgabe. Zum Schluss lädt er alle ein, sich zu melden, die bei HDI mitgestalten wollen.

Kernaussagen

1. Mithalten statt Zielbild: Feste Zielbilder passen nicht mehr. Es geht darum, mit hoher Entwicklungsgeschwindigkeit mitzuhalten.
2. Vom Bedarf der KI her denken: Statt bestehende Prozesse zu optimieren, sollte man fragen, was KI braucht, um gut zu funktionieren.
3. Kontext ist das A und O: Kontext war der Erfolgsfaktor aller starken Use Cases bei HDI.
4. In Entscheidungen denken: Eine Versicherung trifft fünf, sechs große Entscheidungen in hoher Frequenz. KI kann sie vorbereiten, entscheiden tut der Mensch.
5. Saubere Architektur zuerst: Regeln und KI-Agenten getrennt halten und die Oberfläche zuletzt bauen.
6. Eine neue Rolle entsteht: Der Human on the Loop ist eine neue, anspruchsvolle Rolle, die Technik und Fachwissen verbindet.
7. Infrastruktur wächst mit dem Nutzen: Infrastruktur entsteht Use Case für Use Case, und jeder Use Case muss sich deutlich rechnen.
8. KI gehört in den Vorstand: KI ist Vorstandsaufgabe, weil sie das Unternehmen grundlegend verändert.

Fazit und Takeaways

Daniel zeigt, wie eine Versicherung über KI nachdenken kann, wenn sie nicht beim nächsten Tool beginnt, sondern bei der eigenen Bauweise: Kontext, Entscheidungen, klare Regeln und Menschen, die das System steuern. Ein festes Zielbild gibt es dabei nicht, wohl aber Richtungen, in die es geht.

Für Führungskräfte

• Setz dich selbst mit KI auseinander, auch ganz praktisch. Ohne eigenes Verständnis kann dein Team die Veränderung nicht einleiten.
• Erwarte von jedem Use Case einen deutlichen Nutzen und finanziere die Infrastruktur darüber mit.

Für KI- und Transformationsverantwortliche

• Frag zuerst, welche Entscheidungen dein Bereich trifft und welchen Kontext KI dafür braucht.
• Trenne Regeln von dem, was Agenten tun, und bau die Oberfläche erst zum Schluss.

Für Fachbereiche

• Sorg dafür, dass Originaldokumente wie Briefe, Berichte und Mails für KI zugänglich sind.
• Bereite Leute auf die Rolle des Human on the Loop vor, die Fachwissen und Technik verbindet.