Herr Kotulla, Sie schreiben in einem LinkedIn-Post, dass „die Umzugskisten noch im Flur stehen“. Woran scheitert aus Ihrer Sicht aktuell die Durchorchestrierung von KI in der Versicherungsbranche konkret?

Anzeige

Axel Kotulla: Wir haben seit 2023 in jedem Versicherungsunternehmen viele KI-Experimente, meist Use Cases genannt, gesehen. Oft wurde dabei ChatGPT lokalisiert und durch Unternehmenswissen bspw. zum ERGOgpt. Darüber hinaus sehen wir allerdings viele KI-Versuche, die es nie in den Betrieb des Unternehmens schaffen. Wir schätzen, dass 70-80 Prozent aller Use Cases die Testphase nie verlassen haben.

Viele Versicherer haben KI bereits eingeführt. Was unterscheidet isolierte Leuchtturmprojekte von echtem Business Impact?

Bei KI ist für viele IT-Chefs durch den eigenen CEO oder Geschäftsführer und auch den öffentlichen KI-Hype der Druck entstanden, dabei sein zu müssen. Es wurden KI-Teams und Taskforces etabliert. Gleichzeitig haben auch Fachbereiche erkannt, dass man KI ohne die IT nutzen kann und dann selbstständig begonnen, meist LLM-basierte Tools zu bauen. Eine durchgehende unternehmensweite KI-Strategie wird erst nach und nach als notwendig erkannt und so bleibt es oft bei isolierten Verbesserungen. Echter Business Impact entsteht jedoch erst dann, wenn man gesamte Prozesse optimiert und alle Ressourcenengpässe einbezieht.



Welche konkreten Anwendungsfälle haben bei Ihren Kunden bereits messbare Geschäftsergebnisse erzielt?

Wir sehen sowohl in der IT als auch in Fachabteilungen positive Tendenzen. Kunden, bei denen wir in der Entwicklung von Individuallösungen unterstützen, sehen effektivere Programmierung durch den Einsatz von Tools wie GitHub Coilot oder Claude Code und auch beschleunigte Tests, da wir inzwischen Testfälle generieren und ausführen lassen. In den Business-Abteilungen erhalten insbesondere Anwender unserer msg Insurance Suite mit msg.ask:it und msg.process:it zwei Agenten, mit denen sie zum einen zeitaufwändige Recherchearbeiten verkürzen können und – noch viel spannender –, mit process:it ganze Prozesse vom Eingang eines Vorgangs bis zur vollständigen Verarbeitung durch unsere speziell angepasste KI verarbeiten können. 
Wichtig ist mir aber, dass wir unsere KI-Agenten nicht nur Kunden der Insurance Suite zur Verfügung stellen, sondern auch für Kunden, die noch in ihrer Legacy-Welt arbeiten.

Wo sehen Sie aktuell die größten Lücken zwischen technologischem Potenzial und tatsächlichem Business-Nutzen?

Aus meiner Sicht: „It’s all about data“. Solange es für Unternehmens-KI keinen durchgängigen Zugang zu allen Daten des Unternehmens gibt, beschneidet man sich massiv. Daher empfehlen wir, an den Anfang einer KI-Strategie immer eine Datenstrategie zu stellen und so die Voraussetzungen für eine effektive Nutzung zu schaffen. 
Darüber hinaus ist sicherlich die Ausbildung von Mitarbeitenden und dabei vor allem die Akzeptanz von KI und ihrer Geschwindigkeit enorm wichtig. Solange viele Kolleginnen und Kollegen KI als potenzielle Gefahr für den eigenen Job sehen, wird man immer wieder Argumente finden, warum das jetzt gerade nicht mit KI geht. Wir haben das interessanterweise gerade auch bei Entwicklern, die doch eigentlich technikaffin sein sollten, erlebt. Wann immer Code erzeugt wurde, der den einen oder anderen Fehler enthielt, wurde gesagt: „Ja, sowas wäre mir nie passiert, das hilft mir nicht.“
Man muss aber auch sagen, dass gerade in Deutschland die Angst von KI ausgeprägter ist als in anderen Regionen. Sicherlich sind Datenschutz, Vorurteilsfreiheit und Risikomanagement zwingend erforderlich; sie sollten aber nicht immer an erster Stelle stehen und kreative Ideen oft im Keim ersticken.

Was genau meinen Sie mit „built-in KI“? Warum ist dieser Ansatz Ihrer Meinung nach nachhaltiger als klassische KI-Add-ons?

Wenn ich von „built-in KI“ spreche, meine ich das in mindestens zwei Dimensionen:

  1. KI-Agenten sollen in die Prozesse des Versicherers „eingebaut“ sein und nicht, wie ein Tool – beispielsweise DeepL zur Übersetzung – als Teil eines Prozessschritts aufgerufen werden. Ideal ist es, wenn man unsere Insurance Suite nutzt, in der wir KI nicht nur einmalig einbauen, sondern kontinuierlich weiterentwickeln; etwas, was gerade für kleinere und mittlere Versicherer kostenmäßig gar nicht möglich ist. Aber auch ohne unsere Suiten kann man Agenten zum Teil des Prozesses machen, sie also „einbauen“.
  2. Ich fordere von meinem Team, bei jeder Tätigkeit zuerst zu fragen: „Was kann KI hier für mich übernehmen?“– also „built-in“ im Sinne davon, KI in das Denken und Handeln jedes Einzelnen einzubeziehen. Das gilt heute schon für das Schreiben von E-Mails, die Recherche oder sogar den Aufbau von Präsentationen. Wir analysieren Ausschreibungen, prüfen Fragenkataloge usw. und gewinnen so Zeit, um Angebote für Kunden individueller zu gestalten. Diese automatische Berücksichtigung von KI wird nicht nur für junge Einsteiger normal werden müssen.

Können Sie ein Beispiel nennen, wie Ihre Lösung msg.process:it KI nativ integriert. Welche Vorteile das im Alltagsbetrieb bringt?

msg.process:it ist ein neuer Bestandteil unserer Life-, P&C- und Health Factory, welches die jeweiligen Sparten-Kernsysteme unserer Insurance Suite sind. Mit process:it können wir beispielsweise alle Eingangsnachrichten von Kunden 24/7 oft fallabschließend bearbeiten. Wenn Ihnen also am Sonntag nach dem Tatort plötzlich einfällt, dass sie die Prämie für Ihre Lebensversicherung erhöhen wollten, schreiben Sie wie gewohnt eine E-Mail an Ihren Versicherer. Die Antwort oder Rückfrage – bspw. ab wann dies gelten soll, erhalten Sie jedoch nicht mehr im Laufe der Woche, sondern noch bevor Caren Miosga mit ihrem Sonntagstalk wirklich losgelegt hat. Das begeistert Kunden, ist aber nur einer von zahlreichen Prozessen, die wir automatisieren und fachlich verbessern können.

Wie begegnen Sie dem Vorurteil, dass „built-in KI“ weniger flexibel sei als modular zubuchbare Services?

Ich sehe da nicht notwendigerweise einen Widerspruch; entscheidend ist, dass auch ein zubuchbarer KI-Service in die Datenwelt und den Prozess ohne Brüche integriert werden kann. In einer modernen Service-Architektur, in der APIs – idealerweise eventgesteuert – den Austausch regeln, ist dies gegeben. Hier sind eher die Legacy-Welten bei unseren Kunden die Herausforderung