IKOR is part of

rahimi-loechte-roth-chancen-risiken-ki-plattformen.jpg
Im Video-Interview skizzieren Ali Rahimi (v.l.o. im Uhrzeigersinn), Thomas Löchte und Stephan Roth Aufgaben, Chancen und Risiken beim Aufbau und Betrieb von KI-Plattformen

- Data analytics

Vom Lab zur Factory: Was Betreiber von KI-Ökosystemen beachten sollten

– ABSTRACT

KI-Factories agieren als Betriebsplattformen

 Der Plattformgedanke bei künstlich-intelligenten (KI) Ökosystemen der Finanz- und Versicherungswirtschaft steckt zwar in den Kinderschuhen. Aber heterogene Aufgaben wie spartenübergreifende Kaufwahrscheinlichkeiten, Aussagen über ideale Kündigerprävention oder Schadenregulierung bringen Bewegung in die Disziplin: Sie erfordern zunehmend KI-Factories als Betriebsplattformen. Wie es gelingt, aus einem Algorithmen-Labor eine effektive KI-Produktionsstätte aufzubauen – und was Banken und Versicherungen beachten sollten, erläutern Thomas Löchte (Geschäftsführer von IKOR Informationsfabrik), Ali Rahimi und Stephan Roth (beide Chief Product Owner bei IKOR Finsure Integration bzw. IKOR Assurance) im Video-Roundtable.

Wie exotisch sind KI-Ökosysteme im Banken- und Versicherungsumfeld tatsächlich?

Thomas Löchte: Viele Banken und Versicherungen haben bereits Use Cases mit Künstlicher Intelligenz umgesetzt – etwa bei Schadenregulierung, Customer Analytics oder zur Verbesserung der Dunkelverarbeitung. Es entstanden Algorithmen für neue Geschäftsmodelle. Allerdings ist vieles im Experimentierstadium, dem „Lab“, hängengeblieben und wurde noch nicht produktiv in die „Factory“ eingebracht (siehe Grafik).

Womit steht und fällt der Erfolg einer KI-Factory bzw. einer Plattform, die mehrere KI betreibt?

Ali Rahimi: Sie benötigen Use Cases, die strategische Ziele anpeilen, etwa den Planungsstand einer KI-Initiative in den nächsten fünf Jahren. Und Sie müssen Ihre Datenlage überblicken: Welche Informationen befinden sich bereits in den Datenbeständen? Welche Zielvariablen helfen, Marketing- oder Risikofragen zu beantworten? Wie lässt sich Wissen schöpfen? Im Lab erproben wir, ob ein Use Case funktioniert. Wir experimentieren mit Technologien und Daten und leiten einen Business-Case ab.

Löchte: Ist der Business Case positiv, wird die produktive Nutzung in einer Factory eingeleitet: In der Factory betreiben Sie Lösungen, monitoren Prognosemodelle, deren Performance und Kennzahlen.

Rahimi: Zwischen Lab und Factory sehe ich die laufende Entwicklung sogar als Zwischenstufe: Künstliche Intelligenz weist im Anfangsstadium Laborcharakter auf. Datenmodelle ändern sich kontinuierlich und müssen immer wieder an die Realität angepasst werden. Laufen die Modelle über Docker oder Kubernetes erst einmal produktiv, kommt es nicht nur zu millionenfachen Requests und durch Integrationen zu massenhaften Datenzulieferungen. Die Modelle lassen sich vor allem nur noch aufwändig retrainieren. Wie bei jeder „lebenden“ Software helfen im kontinuierlichen Verbesserungs-Prozess Machine-Learning-Operations-Ansätze – MLOps – wie MLFlow oder Kubeflow. *

Löchte: Ob ich im Labor oder in der Factory optimiere, darüber streiten sich die Experten bis heute. Ich unterscheide einerseits gern zwischen der Laborsituation, die – übrigens schnell – mit neuen Themen experimentieren kann, und der „IT- Fabrikhalle“ andererseits: In der Factory arbeiten im Idealfall unterschiedliche KI im sicheren und skalierbaren Betrieb.

Die Herausforderungen sind mit Sicherheit mannigfaltig ...

Löchte: Genau. Wer den Change begleitet, muss diese Modelle nicht nur technisch einbinden, sondern den Change auch bei der Nutzung begleiten. Nur so lassen sich Customer-Analytics-Daten, die ansonsten in Fachabteilungen zu versanden drohen, auch übergreifend einsetzen. Spartenübergreifende Kaufwahrscheinlichkeiten sind intensiver nutzbar und valide Daten tragen zu mehr Effizienz im Sales-Bereich bei.

Stephan Roth: Mit SAP Hana sind – etwa für die Vertriebssteuerung auf In- und Exkasso-Daten – Realtime-Auswertungen möglich, die zuvor nur aufwändig zu berechnen waren. Chancen liegen jedenfalls darin, Produkte auf Basis von Wissen innovativer zu gestalten. Bezogen auf die Kernsysteme von Versicherungen lassen sich hierzu SAP-Tools und -Produkte sinnvoll ergänzen

Welche Anforderungen, Dos und Don’ts kommen Data-Analytics-seitig auf Banken und Versicherungen zu?

Rahimi: Mit den richtigen Daten und neuronalen Netzen können Versicherer selbst das Fahrverhalten ihrer Neukunden binnen weniger Kilometer einschätzen. Integrationen mit Telematik-Anbietern sind heute dank niedriger Einstiegshürden zwar etabliert – mit Hilfe von ODM-Dongles mit Bluetooth, Storage, Computer-Clouds und „Rundum-sorglos“-Paketen. Setzten sich bei diesem Konstrukt die Dienstleister aber direkt zwischen Kunde und Versicherer, gehen der direkte Kanal und die Reaktionsfähigkeit für Veränderungen verloren.

Apropos Veränderungen ...

Rahimi: Das Fahrverhalten etwa ändert sich über die Jahre, die Modelle müssen also an diese Veränderungen angepasst werden, um dauerhaft richtige Ergebnisse zu liefern.

Löchte: Fatal ist, dass sich Fehler oft langsam und fast unbemerkt festsetzen und Modelle schleichend degenerieren können.

Stichwort Lernen als wichtige KI-Aufgabe. Welche Rolle spielt hier Transfer Learning? Und wie weit ist der Markt?

Rahimi: Transfer Learning funktioniert darüber, dass Sie Ihre KI auf einem allgemeinen, großen Datenstamm vortrainieren und einen geringeren, gelabelten Anteil an spezifischen Datensätzen hinterherschieben – etwa Trainingsdaten zur Bilderkennung für Schadenmeldungen. Vortrainierte KI können Banken und Versicherer kostenlos, etwa bei Huggingface, herunterladen oder bei Azure oder AWS Marketplace * einkaufen und auf ihren spezifischen Use Cases nachtrainieren. Ein Beispiel: Sie bringen der KI mit Bildern typische Schäden an spezifischen Automodellen bei. Die KI soll Schäden – heruntergebrochen auf Automodelle – selbst auswerten und einordnen lernen.

Der Proof of Concept markiert die Nahtstelle vom Lab zur Factory:

Ein Prototyp wird innerhalb einer übergreifenden KI-Lösung entwickelt, produktiv gesetzt und im Idealfall immer wieder geprüft. 

ai-lab-to-factory.png
Quelle: IKOR

Wenn mehr solcher Use Cases entstehen: Was empfehlen Sie beim Verwalten unterschiedlicher KI-Lösungen innerhalb einer Factory?

Löchte: Ich rate erstens zu einem Use-Case-Management, das bereits im Labor Ideen bewertet. Es untersucht, inwieweit sich aus Daten verwertbares Wissen im Sinne der Unternehmensstrategie und der Ableitung von Handlungsfeldern generieren lässt. Zweitens müssen Sie den Bereich und die Expertise von Data Science inhouse aufbauen. Drittens sollte der Datenzugriff zum Sammeln und Aufbereiten von Informationen einfach gestaltet sein – etwa durch Datalake-Lösungen –, die Rohdaten zur Verfügung stellen.

Rahimi: Zwar sitzen Versicherungen auf enormen Datenschätzen. Dennoch und viertens kommen auch sie nicht umhin, externe Datentöpfe in ihre Berechnungen einfließen zu lassen: etwa statistische Informationen zu Sterblichkeit, Geburten, Wetter und Entwicklung an den Finanzmärkten. Außerdem Daten zu Regionalität, Bebauungsstrukturen, Gartenanteil und viele Datenpunkte mehr. Ganzheitliche Integrationsplattformen, die neben Bestandsinformationen auch Social-Media-Daten, Geoinformationen und weitere externe Daten in ihrer Factory nahezu in Echtzeit verfüg- und verarbeitbar machen, sind ein weiterer Erfolgsfaktor.

Roth: In- und externe Daten helfen einzukreisen, wo Konsumenten mit Kundenpotenzial wohnen, wo Versicherer mit Stürmen und erhöhten Gefahren durch Umweltkatastrophen rechnen müssen und wo besondere Produkte aufgrund aktueller Gegebenheiten möglich sind. Außenstände im Zahlungsverkehr lassen sich gut visualisieren; Institute bleiben handlungsfähig. Richtig interessant wird es, wenn Banken und Versicherer prognostizieren, welche individuellen Bedürfnisse bei der Behandlung von Außenständen notwendig sind.

Welchen Lösungsansätze helfen dabei, KI-Anwendungen in einer Factory zu betreiben?

Löchte: Use Cases zu priorisieren, die schnell einen hohen Nutzen entfalten, hilft Unternehmen enorm bei der Entwicklung einer KI-Infrastruktur: Um in ihren Labs funktionierende Use Cases aufzubauen, sollten Finanzdienstleister und Versicherungen zunächst marketingrelevante Algorithmen entwickeln – etwa für die Abwanderungswahrscheinlichkeit von Kunden sowie für den erfolgreichen Umgang mit Nichtzahlern. Nach und nach sollten sie weitere Prognosemodelle aufbauen, die bei wichtigen strategischen Entscheidungen und Risikoeinschätzungen unterstützen. Organisationen müssen sich dann jedoch ihrer strategischen Fragen und Zielvariablen bewusst sein.

Und im zweiten Schritt?

Löchte: Alle Banken und Versicherer wollen ihre KI-Herausforderungen für ihre spezifischen Anforderungen skalieren. KI-Lösungen auf Legacy-Systemen aufzusetzen, ist jedoch aufwändiger.

Roth: Zudem können Sie keine Echtzeitdaten mit einem alten Host verarbeiten, der Batch-basiert ist. Befinden sich obendrein mehrere Systeme im Haus, bremst eine Stapelverarbeitung die Arbeitssteuerung weiter aus.

Löchte: Der Markt bietet verschiedene Ansätze, um erprobte Datenmodelle etwa als Workflow- oder Container-basierte Plattformen (siehe Tabelle) zu betreiben: Die Programmierung in Python oder R wird zum Beispiel auf einer KI-Plattform in Container gepackt und produktiv gesetzt. Wir arbeiten aber auch gern mit Lösungen, die grafische Oberflächen bereitstellen, etwa Microsoft ML Studio oder DataIku. Sie können damit auf Plattformen in Echtzeit viele KI-Modelle abbilden und, etwa im Inkassoprozess, immer den „Next best Action“ anzeigen. Die Zukunftschancen dieser Ansätze sind enorm. Es gilt, die für das Unternehmen passenden Use Cases zu finden und diejenigen Technologien einzusetzen, welche die Mitarbeiter beherrschen. So kann immer mehr Business-Potenzial genutzt werden.

Lösungen

Vorteile

Nachteile

Stand-alone-Lösungen suchen nach dem besten Algorithmus bzw. Prognosemodell:

Gut für Modellauswahl und Optimierung einsetzbar

Unterstützt Datenaufbereitung und Feature Engineering nur rudimentär

Einfacher Zugang auch durch Cloud-Lösungen

Reine Prognosemodelle für Supervised ML, keine Apps etc.

Code und UI kann genutzt werden

Hält Marketingversprechen nicht ein: Data Scientists werden weiterhin benötigt

Workflow-basierte Plattformen bieten den Anwendern neben der Möglichkeit zur Programmierung auch grafische Oberflächen – etwa um Prozesse zu modellieren. So adressieren sie eine größere Anwenderbandbreite:

Gute Unterstützung des gesamten Entwicklungs-Workflow

Vendor-Lock-in bei manchen Plattform-Angeboten

Grafische Entwicklung möglich, Programmierkenntnisse nicht zwingend erforderlich

Akzeptanz bei programmiernahen Data Scientists gering

Containerisierung und Anbindung an Computercluster möglich (teilweise)

Spezielle Anforderungen nicht immer umsetzbar

Gute Kollaboration zwischen den Beteiligten

 

Container-basierte Lösungen bieten meist klassische Code-Entwicklungsansätze mit Cloud-Fokus. Produktivsetzungen erfolgen über Git oder andere Versionsverwaltungen und Container-Bildung zum Übertrag in die entsprechenden Systemumgebungen. Ursprünglich stammt dieser Ansatz aus der klassischen Software-Entwicklung. Das zergliederte Verpacken einer KI-Anwendung in mehrere Container (Modularisierung bis auf Modellebene) hilft den Betrieb für die IT zu erleichtern:

Hohe Flexibilität durch maßgeschneiderten Tool Stack

Eigenleistungen (evtl. Software-Entwicklung) für Plattformaufbau notwendig (kein SaaS)

Gute Integration in bestehende Infrastruktur

Heterogenität erfordert mehr Expertenwissen für Infrastruktur und Lösungen

Lose Kopplung der Komponenten vermindert Technologie-Risiken

Wartung der Lösungen kann umfangreicher ausfallen (aufgrund der Heterogenität)

Gute Integration mit bestehenden CI-/CD- und Change-Prozessen

 
PDF

So funktioniert der Betrieb von KI-Ökosystemen. Das Interview und die Tabelle können Sie hier als PDF downloaden. Die Inhalte sind als Gastbeitrag im Sapport Magazin 06/21 erschienen.

Ansprechpartner

Ali Rahimi ist Chief Product Owner bei IKOR Finsure

Ali Rahimi

Chief Product Owner
Dock Finsure Integration
info-finsure@ikor.one
+49 40 8199442-0

thomas-löchte-informationsfabrik.jpg

Thomas Löchte

Geschäftsführer
Informationsfabrik GmbH
communications@ikor.one
+49 251 9199790

stephan-roth-ikor-assurance.jpg

Stephan Roth

Chief Product Owner
Dock Assurance
assurance@ikor.one
+49 40 8199442-0

kristina-schreiber-ikor-communications.jpg

Kristina Schreiber

Communications Manager
Anchor Circle Governance
communications@ikor.one
+49 40 8199442-0

Empfehlungen

Empfehlungen

Hinweise zum Datenschutz

Ein Unternehmen der IKOR Gruppe wird Ihre E-Mail-Adresse nutzen, um das von Ihnen angeforderte Whitepaper an Ihre E-Mail-Adresse zuzustellen. Ihre Daten und Ihr Nutzerverhalten werden elektronisch gespeichert und zum Zweck der Verbesserung der Kundenservices ausgewertet und verarbeitet. Ihre Daten werden zu diesem Zweck an einen Dienstleister in die USA übermittelt und dort verarbeitet werden.

Ein Unternehmen der IKOR Gruppe wird Ihre E-Mail-Adresse außerdem dazu verwenden, Ihnen Marketing-E-Mails zuzusenden. Weitere Informationen zur Datenverarbeitung im Zusammenhang mit unserem E-Mail-Marketing finden Sie hier.

Ihre Einwilligung ist freiwillig. Sie können sie jederzeit per E-Mail an info@ikor.one widerrufen. Im Falle eines Widerrufs werden Ihre Daten nicht weiterverarbeitet.