Ambidextrie ist eine Architekturentscheidung

Kaum ein Begriff fällt in IT-Strategierunden so oft wie Ambidextrie. Gemeint ist die Fähigkeit, das Bestehende zuverlässig zu betreiben und gleichzeitig Neues zu erproben. In der Theorie klingt das nach einer Führungs- und Organisationsfrage. Nico Bäumer, CTO und Vorstand der d.velop AG, widerspricht an einer entscheidenden Stelle: Was als Ambidextrie diskutiert wird, ist in der Praxis vor allem eine Architekturentscheidung.

Für Versicherer mit jahrzehntelang gewachsenen Systemlandschaften ist das mehr als eine akademische Unterscheidung. Wer DORA umsetzen, KI produktiv setzen und Drittparteienrisiken neu bewerten muss, steht oft vor einer Wahl, die er eigentlich nicht treffen wollte: Stillstand oder Bruch. Im Gespräch mit dem VersicherungsTech Magazin erklärt Bäumer, warum diese Wahl in der Architektur entschieden wird, wo er bei KI echten Mehrwert vom Hype trennt und was DORA wirklich verlangt, jenseits der formalen Umsetzung.

Ambidextrie ist eine Architekturentscheidung

Als CTO sind Sie täglich mit dem Widerspruch zwischen Betriebsstabilität und Innovationsdruck konfrontiert. Wie erleben Sie dieses Spannungsfeld, und lässt es sich überhaupt auflösen?

Ich erlebe das nicht als Widerspruch, sondern als zwei Versprechen, die wir unseren Kunden gleichzeitig geben müssen. Auf der einen Seite das Versprechen, dass eine Plattform, von der über Jahre geschäftskritische Prozesse abhängen, jederzeit verlässlich läuft, regulatorisch belastbar bleibt und kontrolliert weiterentwickelt wird. Auf der anderen Seite das Versprechen, dass diese Plattform in einer Welt, die sich gerade fundamental verändert, nicht stehen bleibt. Beides aufzulösen wäre falsch verstanden, es muss sich tragen.

Was ich in den letzten zwei Jahren besonders deutlich gesehen habe: Die Frage ist nicht mehr, ob Unternehmen KI einsetzen wollen, sondern ob ihre bestehende IT-Landschaft das überhaupt zulässt, und ob ein Hersteller in der Lage ist, beides gleichzeitig zu liefern. Wer eine ältere Plattform betreibt, deren Architektur Innovation nicht trägt, steht vor einer Wahl, die er eigentlich nicht treffen wollte: Stillstand oder Bruch. Genau diesen Punkt sehen wir aktuell bei vielen Versicherern, die mit gewachsenen Systemlandschaften plötzlich gleichzeitig DORA umsetzen, KI-Use-Cases produktiv setzen und ihre Drittparteienrisiken neu bewerten müssen. Das ist der Moment, in dem sich entscheidet, welche Häuser die nächste Phase aktiv gestalten und welche nur noch reagieren.

Was bedeutet Ambidextrie konkret für die IT-Infrastruktur eines Versicherungsunternehmens?

Was in der Theorie als Ambidextrie diskutiert wird, ist in der Praxis vor allem eine Architekturentscheidung. Eine Versicherungs-IT, die beides gleichzeitig leisten soll, verlässlichen Betrieb der Kernprozesse und schnelles Erproben neuer Lösungen, braucht eine Architektur, die getrennte Geschwindigkeiten zulässt. Das bedeutet konkret: stabile, regulatorisch beherrschte Systeme im Kern, daneben Schichten, in denen man experimentieren, integrieren und wieder zurückbauen kann, ohne das Fundament zu gefährden. Wer beides in einem Stack vermischt, bekommt am Ende weder Stabilität noch Tempo.

Organisatorisch ist die wichtigste Voraussetzung, dass diese Trennung nicht erst auf Team-Ebene entsteht, sondern in der Architektur vorgedacht ist. Teams können dann eigenständig auf ihrer jeweiligen Geschwindigkeit arbeiten, ohne sich gegenseitig zu blockieren, und Verantwortlichkeiten lassen sich klar zuordnen: Betrieb, Sicherheit und Compliance auf der einen Seite, Innovation und Produktentwicklung auf der anderen. Was zusätzlich entscheidend ist: ein gemeinsames Governance-Modell, das beide Seiten verbindet. Innovationsteams brauchen Leitplanken, die früh greifen, bei Datennutzung, Berechtigungen, Modellauswahl, sonst entstehen technische Schulden, die später ausgerechnet die Betriebsstabilität gefährden, die man eigentlich schützen wollte.

„Wer beides in einem Stack vermischt, bekommt am Ende weder Stabilität noch Tempo."

Nico Bäumer · CTO & Vorstand · d.velop AG

KI: Mehrwert vom Hype trennen

Wie trennen Sie als CTO den echten Mehrwert von KI vom Hype, und welche Kriterien legen Sie an, bevor ein KI-Projekt realisiert wird?

Mein Filter ist relativ einfach und hat mit KI selbst zunächst wenig zu tun: Lässt sich der Nutzen messbar beschreiben, ist der Prozess sauber genug, dass ein KI-System überhaupt verlässlich darauf arbeiten kann, und ist das Ergebnis im Zweifel auch ohne KI noch wirtschaftlich vertretbar? Wenn eine dieser drei Antworten ein „eher nicht" ist, ist es kein KI-Projekt, sondern ein Hype-Projekt. Gartner geht davon aus, dass bis 2027 rund 60 Prozent der KI-Projekte ihre Wertziele verfehlen, das ist in den meisten Fällen kein Modell-Problem, sondern ein Use-Case- und Architektur-Problem.

Quick Wins sehe ich heute realistisch dort, wo strukturierter Content auf wiederkehrende, gut beschriebene Prozesse trifft: in der Bearbeitung von Eingangskanälen, in der Klassifikation und Vorbereitung von Dokumenten für Sachbearbeiter, in der intelligenten Verschlagwortung und beim Auffinden von Informationen über Systemgrenzen hinweg. Das sind Felder, in denen Versicherer messbar Zeit gewinnen, ohne in regulatorisch heikles Terrain zu geraten. Grenzen sehe ich überall dort, wo Entscheidungen mit direkter Auswirkung auf Kundinnen und Kunden fallen: Schadenregulierung dem Grunde nach, Risikoeinschätzungen im Underwriting, Beitragsbemessung. Dort ist die Technologie nicht das Problem, sondern die Frage, ob Nachvollziehbarkeit, Berechtigungen und Rechenschaftspflicht so eingebaut sind, dass die Lösung in fünf Jahren immer noch tragfähig ist. Wer das nicht von Anfang an mitdenkt, baut sich seine Compliance-Probleme von morgen selbst.

Versicherungsunternehmen betreiben oft über Jahrzehnte gewachsene IT-Systeme. Wie lässt sich auf dieser Legacy-Basis sinnvoll KI einführen, ohne die Stabilität zu gefährden?

Legacy ist in der Versicherungs-IT kein Defekt, sondern oft das Ergebnis jahrzehntelanger Investitionsentscheidungen, die zu ihrer Zeit richtig waren. Die entscheidende Frage ist daher nicht, ob man diese Systeme durch KI ersetzt, sondern wie man eine Ebene dazwischen schiebt, die KI überhaupt erst wirksam macht. KI ist nur so gut wie der Content und die Berechtigungslogik, auf der sie arbeitet, und genau dort liegt in den meisten Häusern die eigentliche Baustelle. Ohne eine konsolidierte Content- und Governance-Schicht bleibt jedes KI-Pilotprojekt eine Insel, die sich nicht skalieren lässt.

Versicherern mit stark fragmentierter IT-Landschaft rate ich, in dieser Reihenfolge vorzugehen: Erstens Transparenz über die eigene Daten- und Dokumentenwelt schaffen, welche Information liegt wo, in welcher Qualität, mit welchen Berechtigungen. Zweitens eine Plattformschicht etablieren, die diese Informationen für KI nutzbar macht, ohne die Kernsysteme zu berühren, also nicht Schadenbearbeitung ablösen, sondern Schadenbearbeitung mit besseren Informationen versorgen. Drittens KI-Use-Cases bewusst klein und entlang dieser Schicht beginnen, mit klaren Ausstiegspunkten, falls ein Modell oder Anbieter sich als nicht tragfähig erweist. Die größte Gefahr für Stabilität sind nicht KI-Modelle, sondern unklare Abhängigkeiten: von Modellen, von Anbietern, von Datenflüssen. Wer das von Anfang an architektonisch sauber zieht, kann sehr schnell sehr viel Wert heben, ohne die Betriebsbasis zu gefährden.

Welche KI-Anwendungsfälle sind aus Ihrer Sicht technisch reif, und welche werden noch überschätzt?

Technisch reif ist heute aus meiner Sicht alles, was Sachbearbeiterinnen und Sachbearbeiter unterstützt, ohne ihre Verantwortung zu ersetzen: die Vorbereitung und Klassifikation von Schadenmeldungen, die strukturierte Aufbereitung von Eingangspost und E-Mail, die Anreicherung von Vorgängen mit relevanten Informationen aus angrenzenden Systemen, die Generierung von Entwurfsantworten in der Kundenkommunikation. Das sind Felder, in denen KI heute schon spürbar Zeit und Qualität bringt, und in denen Fehler korrigierbar sind, bevor sie nach außen wirken.

Überschätzt wird derzeit vor allem die Vorstellung vollautomatischer Dunkelverarbeitung in regulierungssensiblen Prozessen, etwa eine vollständig KI-gestützte Schadenregulierung dem Grunde nach oder ein autonomes Underwriting bei nicht standardisierten Risiken. Nicht weil die Modelle das in einzelnen Fällen nicht könnten, sondern weil die organisatorische, regulatorische und reputationelle Tragfähigkeit dafür heute noch nicht da ist. Auch im Bereich autonom agierender KI-Agenten sehe ich aktuell mehr Marketing als Reife. Die spannende Frage ist nicht, ob ein Agent etwas anstoßen kann, sondern ob er es auch unter den Berechtigungen tun darf, die für den konkreten Vorgang gelten. Dort liegt der eigentliche Engpass für die nächste Phase, und genau daran arbeiten wir branchenseitig gerade.

Betriebssicherheit, DORA und die Grenzen der Auslagerung

DORA stellt neue Anforderungen an die IT-Resilienz. Wie gut sind Versicherer darauf vorbereitet, und wo sind die kritischsten Schwachstellen?

Der formale Umsetzungsstand ist in vielen Versicherungshäusern inzwischen weit fortgeschritten: Verträge sind angepasst, Register sind aufgebaut, Verantwortlichkeiten sind benannt. Die operative Resilienz, die DORA eigentlich meint, ist damit aber noch nicht hergestellt. Die kritischsten Schwachstellen sehe ich nicht in den Kernsystemen selbst, sondern an den Schnittstellen: zu Dienstleistern, zu Cloud-Diensten, zu Plattformen, in deren Verfügbarkeit, Wechselbarkeit und Nachweisbarkeit man im Ernstfall sehr schnell sehr tiefe Lücken entdeckt.

Unterschätzt wird vor allem ein Punkt: dass DORA Drittparteienrisiken nicht als separate Disziplin, sondern als integralen Bestandteil des ICT-Risikomanagements behandelt. Viele Häuser haben das vertraglich und auf dem Papier sauber abgebildet, aber die technische und architektonische Wechselbarkeit nicht. Wenn ein kritischer Dienstleister ausfiele, wäre der formale Prozess klar, der Weg, das Geschäft tatsächlich auf eine Alternative zu verlagern, in den meisten Fällen nicht. Das zweite, was unterschätzt wird, ist die Wechselwirkung mit dem AI Act und dem Data Act: Resilienz, KI-Governance und Datenportabilität sind keine drei Themen, sondern eines, und wer sie organisatorisch trennt, baut sich systematisch Lücken in die eigene Steuerungsfähigkeit.

Cyberangriffe auf Versicherungen nehmen zu. Muss man heute zwischen Sicherheit und Innovationstempo wählen?

Cyberangriffe haben in den letzten Jahren weniger die Frage verändert, ob man Sicherheit ernst nimmt, das tun heute alle, sondern wo sie in der Architektur verankert sein muss. Sicherheit als nachgelagerte Schicht, die man am Ende über eine fertige Plattform legt, funktioniert nicht mehr. Sie muss in die Grundannahmen der Architektur eingebaut sein: in Identitäts- und Berechtigungsmodelle, in die Trennung von Datenflüssen, in das Logging jeder relevanten Operation, in die Wechselbarkeit von Komponenten. Die gute Nachricht dabei: Genau diese Disziplin macht Plattformen nicht langsamer, sondern stabiler, und damit innovationsfähiger.

Die Wahl zwischen Sicherheit und Innovationstempo ist eine falsche Alternative. Wer schnell innovieren will, braucht eine Plattform, auf der er sich nicht bei jedem Schritt fragen muss, ob er gerade etwas Bestehendes kompromittiert. Genau das leistet eine Architektur, in der Sicherheit als Voraussetzung gedacht ist, nicht als Bremse. Was in der Praxis das Tempo bremst, ist nicht Sicherheit, sondern fehlende Architekturdisziplin: also die nachträgliche Reparatur dessen, was man am Anfang nicht sauber gezogen hat. Das gilt für klassische Cybersecurity genauso wie für KI-Sicherheit. Wer Berechtigungen, Logging und Nachvollziehbarkeit erst dann einzieht, wenn der Use Case schon produktiv ist, hat den teuersten Weg gewählt.

Viele Versicherer lagern IT-Funktionen zunehmend aus. Wo liegen die Grenzen sinnvoller Auslagerung?

Auslagerung ist ein legitimes und in vielen Fällen wirtschaftlich richtiges Mittel. Das Risiko entsteht nicht durch das Auslagern selbst, sondern dort, wo Häuser Auslagerung mit dem Abgeben von Steuerungsfähigkeit verwechseln. Wenn ein Versicherer kritische Funktionen so weit nach außen verlagert, dass er weder die Architektur, noch die Modellwahl, noch die Wechseloptionen aktiv steuern kann, wird Auslagerung zum Resilienz- und zum strategischen Problem. DORA macht genau diese Grenze sichtbar: Steuerbarkeit, Nachweisbarkeit und Exit-Fähigkeit sind nicht verhandelbar.

Eine tragfähige Make-or-Buy-Strategie unterscheidet aus meiner Sicht zwischen drei Ebenen: Erstens Kompetenzen, die ein Versicherer selbst beherrschen muss, weil sie über Wettbewerbsfähigkeit entscheiden, dazu zähle ich die eigene Datenstrategie, die Steuerung der Informationsarchitektur und die zentralen Berechtigungs- und Governance-Konzepte. Zweitens Plattformen und Spezialdienste, die ein Versicherer beziehen sollte, weil ein Hersteller sie wirtschaftlicher und schneller liefert, hier ist die entscheidende Frage nicht make or buy, sondern mit wem und unter welchen Wechselbedingungen. Drittens reine Commodity-Leistungen, bei denen Auslagerung die offensichtliche Wahl ist. Die größte Gefahr in der Praxis sehe ich, wenn Häuser diese drei Ebenen vermischen, also entweder zu viel selbst bauen, was sie nicht differenzieren müssen, oder zu viel abgeben, wovon ihre Steuerungsfähigkeit abhängt.

d.velop: Stabilität und Innovation in einer Plattform

Wie managt d.velop die Dualität, einerseits stabile Plattformlösungen zu liefern und andererseits kontinuierlich zu innovieren?

Wir haben für uns früh eine Entscheidung getroffen, die für viele Hersteller untypisch ist: Wir trennen Stabilität und Innovation nicht in zwei Organisationen, sondern in zwei Schichten einer gemeinsamen Plattform. Der Kern, von dem die geschäftskritischen Prozesse unserer Kunden abhängen, läuft in einem Takt, der auf Verlässlichkeit, Sicherheit und langfristige Betreibbarkeit optimiert ist. Darüber liegen Schichten, für KI-Komponenten, neue Integrationen, neue Interaktionsformen, die deutlich schneller getaktet sind und in denen wir bewusst auch wieder zurückbauen können, wenn sich eine Richtung als nicht tragfähig erweist. Das verhindert das klassische Problem: dass das, was im Innovationsteam entsteht, nie produktiv wird, weil es zur Kernarchitektur nicht passt.

Bewährt haben sich dabei drei Dinge. Erstens ein gemeinsames Governance-Modell, das beide Geschwindigkeiten von Anfang an verbindet, also Berechtigungen, Logging und Nachvollziehbarkeit nicht als nachgelagerte Compliance-Übung, sondern als Voraussetzung jeder neuen Komponente. Zweitens echte Wahlfreiheit auf den Ebenen, an denen Kunden sie heute brauchen: Betriebsmodell, Modellanbieter, Integrationen. Drittens, und das ist vielleicht der unterschätzteste Punkt, Teams, die explizit den Auftrag haben, nicht nur zu bauen, sondern auch zu entscheiden, was nicht gebaut wird. In einer Welt mit hundert möglichen KI-Initiativen ist das die wichtigere Disziplin geworden.

Welche Technologieentscheidung haben Sie in den letzten zwei Jahren bewusst gegen den Mainstream getroffen, und warum?

Die wichtigste Architekturentscheidung der letzten Jahre war für uns, unsere Plattform auf einer einzigen Code-Basis aufzubauen, über On-Premises, Hybrid und Cloud hinweg. Das ist im Markt unüblich, weil es viel Disziplin in der Entwicklung verlangt und kurzfristig teurer ist als getrennte Stränge. Für unsere Kunden bedeutet diese Entscheidung aber drei Dinge gleichzeitig: dieselbe Tiefe, dieselbe Innovationsgeschwindigkeit und einen einfachen Übergang zwischen den Betriebsmodellen. Die Frage, ob ein Versicherer heute On-Premises startet und morgen in eine souveräne Cloud wechselt, ist damit keine Migrations-, sondern eine Konfigurationsfrage. Diese Entscheidung lässt sich nicht ohne Schmerzen revidieren, sie wirkt tief in die Architektur hinein. Wirtschaftlich war sie kurzfristig teurer, langfristig zwingend.

Die logische Konsequenz daraus ist, dass wir dieses Prinzip auf jede neue Technologieebene übertragen. Bei der Cloud bedeutet es die freie Wahl zwischen mehreren Anbietern, ohne dass sich für unsere Kunden an der Plattform etwas ändert. Bei KI bedeutet es Modell- und Infrastruktur-Agnostik als Architekturprinzip: Welches Sprachmodell für welchen Anwendungsfall sinnvoll ist, entscheiden unsere Kunden, nicht wir als Hersteller. In einem Markt, in dem sich die KI-Landschaft alle zwölf Monate verschiebt, ist Wechselbarkeit kein Komfort, sondern Resilienz. Etwas, das ich rückblickend nicht anders, aber früher getan hätte: stärker mit Versicherern und anderen regulierten Branchen darüber zu sprechen, wie sich diese Architekturentscheidungen in ihren eigenen Häusern übersetzen lassen. Das Prinzip haben wir früh richtig gewählt, die Übersetzungsarbeit in die Anwenderdomänen hätten wir früher beginnen können.

Wie beurteilen Sie die Rolle von Plattformökosystemen und APIs, und welche Gefahren entstehen durch zu starke Plattformabhängigkeiten?

Plattformökosysteme und offene APIs sind nicht eine Option unter anderen, sondern die zentrale Antwort auf eine Realität, in der ein Versicherer heute mit Dutzenden Spezialdiensten, externen Datenquellen und KI-Komponenten arbeiten muss. Wer das alles weiterhin punkt-zu-punkt integrieren will, baut die Komplexität von morgen auf und beschränkt sich auf das, was er selbst beherrscht. Plattformen bündeln diese Komplexität, machen Wechselbarkeit organisierbar und schaffen die Voraussetzung, dass KI in einem Versicherungskontext überhaupt skalieren kann.

Die Gefahr liegt nicht in Plattformen an sich, sondern in Plattformabhängigkeiten, die nicht reversibel sind. Wer sich heute auf ein Ökosystem festlegt, in dem er weder Datenflüsse, noch Berechtigungslogik, noch das Modell-Backend selbst kontrolliert, baut sich genau die Lock-ins, die DORA und der Data Act zu verhindern versuchen. Mir geht es dabei nicht nur um Versicherer als Plattformnutzer, ich sehe einen größeren Trend, der über Unternehmensgrenzen hinausreicht. Ein wachsender Teil der Wertschöpfung passiert nicht mehr innerhalb einer Organisation, sondern zwischen Organisationen: zwischen Versicherer und Vermittler, zwischen Versicherer und Rückversicherer, zwischen Versicherer und Kundin. Genau dort fehlt heute eine souveräne, europäische Interaktionsebene, die diese Übergänge kontrolliert und nachvollziehbar macht. Daran arbeiten wir, weil wir glauben, dass darüber die nächste Phase der Versicherungs-IT entschieden wird.

Ausblick: Drei Entscheidungen für die nächsten zwei Jahre

Was sind die drei wichtigsten technologischen Entscheidungen, die ein Versicherer in den nächsten zwei Jahren treffen muss?

Erstens: die Entscheidung für eine konsolidierte Content- und Berechtigungsschicht zwischen den Kernsystemen und der KI-Welt. Versicherer, die in den nächsten zwei Jahren diese Schicht sauber etablieren, werden KI-Use-Cases produktiv skalieren können, die anderen werden sich in Pilotprojekten verlieren, die nie aus der Insel-Phase herauskommen. Das ist heute eine architektonische Investition, die in fünf Jahren über Geschwindigkeit, Compliance-Fähigkeit und Wirtschaftlichkeit entscheidet.

Zweitens: die Entscheidung für Wechselbarkeit als Architekturprinzip. Konkret heißt das, sich heute bewusst nicht auf einen einzelnen Cloud-Anbieter, einen einzelnen Modellanbieter oder eine einzelne Plattform festzulegen, sondern Architekturen so zu bauen, dass die Wahl in zwei Jahren noch eine Wahl bleibt. In einer Welt, in der sich Anbieter, Modelle und regulatorische Anforderungen jährlich verschieben, ist diese Freiheit kein Komfort, sondern eine Voraussetzung für Resilienz und Innovationsfähigkeit. Drittens: die Entscheidung, Datenstrategie, KI-Strategie und Governance nicht länger getrennt zu denken. Solange diese drei Themen in unterschiedlichen Vorstandsressorts mit unterschiedlichen Zielen geführt werden, entstehen genau die Lücken, die DORA, der EU AI Act und der Data Act eigentlich schließen sollen. Versicherer, die diese drei Stränge in den nächsten zwei Jahren operativ zusammenführen, schaffen die Voraussetzung, in fünf Jahren wirklich souverän zu agieren, statt nur konform zu sein.

Was braucht ein CTO oder IT-Leiter heute als wichtigste Fähigkeit jenseits von technischem Know-how?

Die wichtigste Fähigkeit jenseits des Technischen ist heute, Entscheidungen unter Unsicherheit zu treffen, und sie im Vorstand, gegenüber Aufsicht und gegenüber den eigenen Teams so zu vertreten, dass sie tragfähig bleiben. Technologische Landschaften verschieben sich gerade so schnell, dass auf vollständige Information zu warten gleichbedeutend mit Stillstand ist. Gleichzeitig sind die Konsequenzen vieler dieser Entscheidungen tiefgreifend und nur schwer revidierbar. Diese Kombination, schnell entscheiden, langfristig verantworten, ist die eigentliche Anforderung an die Rolle heute.

In den letzten Jahren hat sich die Position von einer primär liefernden Funktion zu einer primär gestaltenden gewandelt. Es geht heute weniger darum, eine fertige Strategie technisch umzusetzen, sondern darum, die Strategie mitzudefinieren, weil Geschäftsmodell, Architektur und Regulatorik so eng zusammengewachsen sind, dass eine Trennung nicht mehr möglich ist. Wer als CTO oder IT-Leiter nicht im Vorstand ankommt und dort als strategischer Sparringspartner gehört wird, läuft Gefahr, die Entscheidungen technisch ausführen zu müssen, die andere ohne ausreichendes Verständnis getroffen haben. Das ist für ein Versicherungsunternehmen heute ein Resilienz-Risiko erster Ordnung.

Wenn Sie einem Versicherungsvorstand heute einen einzigen Ratschlag zur digitalen Transformation geben dürften, welcher wäre das?

Behandeln Sie digitale Souveränität nicht als regulatorische Nebenbedingung, sondern als Teil Ihres Geschäftsmodells. Wer heute Daten-, Cloud- und KI-Architektur getrennt voneinander denkt, baut Abhängigkeiten schneller auf, als er sie wieder loswird, und stellt damit eine Frage, die in fünf Jahren entscheidend wird: Wer steuert die digitale Transformation Ihres Hauses tatsächlich noch? Sie selbst, oder die Anbieter, auf die Sie sich heute festlegen? Souveränität ist dabei keine Einschränkung. Sie ist die Voraussetzung dafür, dass Sie überhaupt schnell und zugleich verantwortbar innovieren können. Was kurzfristig nach Mehraufwand aussieht, Wechselbarkeit, transparente Berechtigungen, eine konsolidierte Content- und Governance-Schicht, ist mittelfristig genau das, was Ihre Innovationsgeschwindigkeit ermöglicht.

Diese Verbindung sehe ich in vielen Versicherungshäusern noch zu wenig: Souveränität, Resilienz und Innovationsfähigkeit sind keine konkurrierenden Ziele, sondern Ausprägungen derselben Architekturdisziplin. Wer diese Verbindung versteht und in seinem Haus operativ umsetzt, wird die nächste Phase der Versicherungs-IT nicht überstehen, er wird sie gestalten. Und mein zweiter Gedanke: Denken Sie diese Disziplin heute schon über die Grenzen Ihres eigenen Hauses hinaus. Ein wachsender Teil Ihrer Wertschöpfung passiert nicht mehr innerhalb Ihrer Organisation, sondern zwischen Organisationen, zwischen Ihnen und Vermittlern, Rückversicherern, Dienstleistern und nicht zuletzt Ihren Versicherten. Heute fehlt für diese Übergänge eine souveräne, europäische Interaktionsebene, die Identität, Berechtigungen und Nachvollziehbarkeit über Organisationsgrenzen hinweg trägt. Wer diese Ebene mitdenkt, baut sich die Position, die digitale Transformation seines Hauses in den nächsten Jahren nicht nur zu überstehen, sondern aktiv zu gestalten.