Anbieter bewerten und Build-versus-Buy abwägen

# Anbieter bewerten und Build-versus-Buy abwägen

Drei Anbieter kommen zu einem Einkaufstermin. Alle drei behaupten, ihre KI erkenne Subrogationspotenziale, also Fälle, in denen Ihr Versicherer einen Schaden bezahlt hat, aber eine andere Partei (ein fahrlässiger Fahrer, ein Handwerksbetrieb, ein Produkthersteller) letztlich zahlen müsste. Alle drei zeigen eine Demo mit beeindruckenden Recall-Werten. Nur einer hat jemals ein Schadensystem angebunden, das so unaufgeräumt ist wie Ihres. Diese Lektion gibt Ihnen die Checkliste, um sie auseinanderzuhalten.

Warum Subrogationserkennung ein guter Testfall ist

Subrogation ist der Prozess, bei dem ein Versicherer, der einen Schaden bezahlt hat, Erstattung von der tatsächlich verantwortlichen Partei verlangt. Verpasste Subrogation ist reiner Margenverlust: Der Schaden ist bezahlt, die Akte geschlossen, und niemand geht je zurück, um das Geld zu holen. Branchenschätzungen (Stand 2024, Quellen variieren) legen nahe, dass US-amerikanische Sach- und Unfallversicherer deutlich weniger als die Hälfte der theoretisch erzielbaren Subrogationsbeträge realisieren, häufig genannt wird eine Spanne von 30 bis 50 % je nach Geschäftsfeld.

KI-Modelle kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Subrogationskandidaten markieren, indem sie Sachbearbeiternotizen, Polizeiberichte und Schadenmetadaten (Schadenart, Verletzungscodes, Haftungsindikatoren) auswerten und Muster sichtbar machen, die ein ausgelasteter Sachbearbeiter übersehen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnte. Damit ist es ein realistischer, abgegrenzter Use Case für den Anbietervergleich, kein Moonshot.

Die Bewertungsübung mit drei Anbietern

Stellen Sie sich vor, Sie bewerten Anbieter A (ein spezialisiertes Insurtech-Startup), Anbieter B (ein Modul, das an einen großen etablierten Claims-Platform-Anbieter angeflanscht ist) und Anbieter C (eine generalistische KI-/Analytics-Beratung, die einen Custom Build anbietet). Bewerten Sie jeden mit 1 bis 5 auf den folgenden Kriterien.

Kriterium 1: Datenzugang und Integrationsaufwand

Fragen Sie konkret: Liest der Anbieter nur strukturierte Schadendaten oder auch unstrukturierten Text (Sachbearbeiternotizen, PDFs, Gesprächstranskripte)? Subrogationssignale verstecken sich oft im Freitext, deshalb bleibt ein Modell, das auf strukturierte Felder begrenzt ist, hinter den Erwartungen.

• Anbieter A (Startup): hat APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen →-Konnektoren für große Schadensysteme gebaut (z. B. Guidewire, Duck Creek), aber noch nie Ihren Legacy-Mainframe-Extrakt angefasst. Integrationsaufwand: mittel bis hoch, Terminrisiko.
• Anbieter B (etabliertes Modul): sitzt bereits in Ihrer bestehenden Plattform, nahezu kein Integrationsaufwand, aber das zugrunde liegende Modell ist ein generisches Add-on, das nicht speziell auf Subrogation getunt ist.
• Anbieter C (Beratung): baut eine Custom PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → exakt auf Ihren Daten, das bedeutet aber Monate Data Engineering, bevor irgendein Modelloutput kommt.

Kriterium 2: Anforderungen an Explainability

Explainability bedeutet die Fähigkeit, in menschlich verständlichen Begriffen zu zeigen, warum ein Modell ein bestimmtes Ergebnis geliefert hat. In der Versicherung ist das nicht optional. Viele US-Bundesstaaten verlangen, dass nachteilige Entscheidungen gegenüber Versicherungsnehmern erklärbar sind, und Regulierer wie die NAIC (National Association of Insurance Commissioners) haben Leitlinien zur Model Governance beim KI-Einsatz in der Versicherung veröffentlicht. Subrogationsflags speisen Entscheidungen in der Schadenbearbeitung, und wenn das Flag die Reservebildung oder die Prozessstrategie beeinflusst, werden Ihre Rechts- und Compliance-Teams fragen: „Warum sagt das Modell das?“

• Anbieter A: liefert Erklärungen auf Feature-Ebene (welche Wörter oder Felder das Flag ausgelöst haben), brauchbarer Audit Trail.
• Anbieter B: Black-Box-Score mit generischem Konfidenzprozentsatz, schwache Explainability.
• Anbieter C: vollständig individuell, Explainability ist also genau das, was Sie im Vertrag festlegen, aber diese Spezifikationsarbeit liegt bei Ihnen.

Kriterium 3: Track Record und Validierung

Fragen Sie nach einem aktiven Referenzkunden in Ihrem Geschäftsfeld (Kfz, Workers' Comp, Sach), nicht nur nach einem Logo auf einer Folie. Fragen Sie, wie der Anbieter Genauigkeit gemessen hat: gegen einen zurückgehaltenen historischen Datensatz oder nur gegen die eigenen Trainingsdaten (ein Warnsignal für überzeichnete Performance).

Eine einfache Scoring-Tabelle

| Kriterium (Gewicht) | Anbieter A | Anbieter B | Anbieter C |

|---|---|---|---|

| Datenzugang / Integration (30 %) | 3 | 5 | 2 |

| Explainability (30 %) | 4 | 2 | 3 (falls spezifiziert) |

| Track Record (20 %) | 3 | 4 | 2 |

| Kosten / Time to Value (20 %) | 3 | 4 | 1 |

Durchgerechnet (gewichteter Score, von 5):

• Anbieter A: (3×0,3) + (4×0,3) + (3×0,2) + (3×0,2) = 0,9 + 1,2 + 0,6 + 0,6 = 3,3
• Anbieter B: (5×0,3) + (2×0,3) + (4×0,2) + (4×0,2) = 1,5 + 0,6 + 0,8 + 0,8 = 3,7
• Anbieter C: (2×0,3) + (3×0,3) + (2×0,2) + (1×0,2) = 0,6 + 0,9 + 0,4 + 0,2 = 2,1

Anbieter B gewinnt bei dieser Gewichtung, aber nur weil Integration und Kosten zusammen mit 50 % gewichtet wurden. Wenn Ihr Rechtsteam darauf besteht, dass Explainability mit mindestens 40 % gewichtet wird (üblich bei Use Cases nahe der Schadenbearbeitung), zieht Anbieter A an B vorbei. Der Sinn der Übung ist nicht die Rechenoperation, sondern Ihr Team zu zwingen, die Gewichte explizit zu benennen, *bevor* es die Anbieterdemos sieht, damit nicht der Sales-Pitch Ihre Prioritäten setzt.

Build versus Buy: die echten Tradeoffs

„Build“ heißt selten, ein Large Language ModelLarge Language ModelEin Large Language Model ist ein KI-System, das auf riesigen Textmengen trainiert wurde, um Sprache vorherzusagen und zu erzeugen. Damit sind Aufgaben wie Schreiben, Zusammenfassen und Beantworten von Fragen möglich.Vollständige Definition ansehen → von Null zu bauen, das macht praktisch kein Versicherer. Es heißt, eine Custom PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → zu bauen (Datenextraktion, Feature Engineering, ein fine-getuntes oder geprompteles Modell, ein Review-Workflow) auf Basis bestehender KI-Infrastruktur (Cloud-Provider-APIs, Open-Source-Modelle).

Buy ist sinnvoll, wenn:

• Der Use Case branchenweit verbreitet ist (Subrogationserkennung, First-Notice-of-Loss-Triage), sodass Anbieter ihn bereits an den Daten vieler Kunden verfeinert haben.
• Ihrem Team die interne ML-Engineering-Kapazität fehlt, um ein Modell über die Zeit zu pflegen.
• Time to Value wichtiger ist als perfekter Fit; ein mittelmäßiges Tool, das in Q2 live ist, schlägt ein perfektes Tool, das in Q4 nächsten Jahres live geht.

Build ist sinnvoll, wenn:

• Ihre Daten oder Prozesse wirklich ungewöhnlich sind (eine Nischen-Spartenlinie, eine proprietäre Schadentaxonomie).
• Der Use Case zum Wettbewerbsvorteil gehört und keine Commodity-Funktion ist.
• Sie aus anderen Projekten bereits eine MLOpsMLOpsMachine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.Vollständige Definition ansehen →-Fähigkeit haben (Machine Learning OperationsMachine Learning OperationsMachine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.Vollständige Definition ansehen →, also die Praktiken für Deployment und Monitoring von Modellen in Produktion).

Ein häufiger Mittelweg: das Basismodell eines Anbieters kaufen, aber Zugang verhandeln, um es auf Ihren eigenen historischen Schadendaten fine-zutunen. Das bringt Geschwindigkeit plus ein Stück Anpassung, zum Preis höherer vertraglicher Komplexität.

Ein minimaler technischer Sanity Check

Auch nicht-technische Bewerter sollten Anbieter bitten, eine Confusion Matrix auf einem zurückgehaltenen Testset zu zeigen, nicht nur eine Gesamtgenauigkeit. Beispiel für das, was Sie anfordern sollten:

                Predicted: Subrogation   Predicted: No Subrogation
Actual: Subrogation         420 (TP)             180 (FN)
Actual: No Subrogation      90 (FP)             9,310 (TN)

Daraus: Precision = TP/(TP+FP) = 420/510 ≈ 82 %. Recall = TP/(TP+FN) = 420/600 = 70 %. Ein Anbieter, der nur „95 % Accuracy“ auf einem Datensatz nennt, in dem Subrogationsfälle selten sind (ein klassisches Class-Imbalance-Problem), versteckt hinter einer irreführenden Kennzahl wahrscheinlich einen schwachen Recall-Wert. Fragen Sie Precision und Recall immer getrennt ab.

Checkliste für Governance und Einkauf

Bestätigen Sie vor Vertragsschluss, dass der Anbieter diese Punkte schriftlich beantworten kann:

1. Wo werden Trainings- und Inferenzdaten gespeichert, und überschreiten sie Grenzen? Relevant für die DSGVO (Datenschutz-Grundverordnung, EU), wenn Sie in Europa tätig sind, und für die Datenschutzgesetze der US-Bundesstaaten.

2. Wer besitzt die Modelloutputs und alle Modellverbesserungen, die aus Ihren Daten entstehen?

3. Wie sieht der Prozess aus, um ein Subrogationsflag des Modells zu bestreiten oder zu überstimmen?

4. Kann der Anbieter Bias-Tests über Antragsteller-Demografien nachweisen? Regulierer, darunter mehrere US-Versicherungsaufsichten der Bundesstaaten, haben begonnen, Bias-Audits für schadenbezogene KI zu verlangen.

Für eine breitere Grundlage zu Frameworks des KI-Risikomanagements, die für die Anbieterbewertung relevant sind, ist das NIST AI Risk Management Framework eine solide, kostenlose Referenz, die weit über die Versicherung hinaus genutzt wird.

🎬 [VIDEO: „How Insurers Are Using AI for Claims and Fraud Detection“ - youtube.com - suchen Sie nach aktuellen Branchen-Paneldiskussionen zum Einsatz von KI in der Schadenbearbeitung, nützlich, um Anbieterdemos kritisch und nicht im Verkaufskontext diskutiert zu sehen]

Wichtigste Erkenntnisse

• Bewerten Sie Anbieter anhand expliziter, gewichteter Kriterien (Datenzugang, Integrationsaufwand, Explainability, Track Record), die *vor* den Demos festgelegt werden, nicht danach.
• Explainability ist bei schadenbezogener KI kein Nice-to-have; Regulierer und interne Rechtsteams werden sie einfordern.
• Fragen Sie immer Precision und Recall getrennt ab, nicht eine einzelne Accuracy-Zahl, besonders bei der Erkennung seltener Ereignisse wie Subrogation.
• Kaufen Sie bei Commodity- und gut ausgetretenen Use Cases; bauen (oder anpassen), wenn Ihre Daten oder Prozesse wirklich differenziert sind.
• Ein hybrider Weg, ein Basismodell zu kaufen und auf eigenen Daten fine-zutunen, ist 2026 oft der realistische Mittelweg.