- data analytics
Skalierte KI-Plattformen: „Kollaboration und Integration fördern Business-Bereiche“
Auch mit kleinem Budget lassen sich Nutzen stiften und KI-Lösungen skalieren. Die Optionen sind indes vielfältig – egal ob Versicherer Low-Code- oder grafische Workflow-Tools nutzen oder gar selbst programmieren.
- •
- Kristina Schreiber
– ABSTRACT
Data-Science-Ökosysteme für KI-Anwendungen skalieren
– Fast Lane
In diesem Artikel erfahren Sie:
- Welche Dos und Don’ts bei Ausbau von KI-Ökosystemen bestehen
- Welche Rolle dabei Low-Code-Ansätze und grafische Workflow-Tools spielen
- In welchen Zyklen IT und Fachbereichen den Zeitpunkt von Modell-Tests und -Retrainings planen sollten
- Wie Versicherungen ihre plattformbasierten KI-Services in den nächsten Jahren weiterentwickeln werden
– Interview
Über die Experten
Dr. Sarah Detzler ist Competence Lead Data Science and Machine Learning bei SAP
Dr. Michael Zimmer verantwortet die Position des Chief Data Officer bei der Zurich Gruppe Deutschland
Philipp Schützbach ist Sales Engineer bei DataIku
Thomas Löchte führt die Geschäfte der IKOR-Schwester Informationsfabrik
– Fokus
Data Analytics
„Um schneller zu skalieren, brauchen Unternehmen agile, flexible und dennoch standardisierte Prozesse sowie wiederverwertbare Bausteine und fachbereichsübergreifende Kollaboration“
KI-Ökosysteme aufzubauen und diese Plattformen zu skalieren, liegt bei Versicherungen absolut im Trend. Welches sind eure wichtigsten Leitlinien und Lernfelder?
Dr. Sarah Detzler: In der Beratung starte ich immer eine Architekturdiskussion mit Fragen wie: Wo liegen die Daten? Wo packen wir das R- bzw. Python-Skript drauf, um zum Beispiel die optimale Run-Time zu erzielen? – Solche Fragen muss man den Data-Science-Teams bewusst stellen, denn nicht alle Team-Mitglieder haben so etwas auf dem Schirm. Berücksichtigt man von Anfang an die Architektur, gestalten sich Projekte sehr viel einfacher.
Dr. Michael Zimmer: Wir haben bei der Zurich eine Cloud-basierte State-of-the-Art-KI-Landschaft aufgebaut – auf Basis eines Hyperscalers. Für die Skalierung bedeutet das: Wir ziehen die Plattform hoch und bauen passende Git-Repositories für Datenbewirtschaftung und MLOps für unsere Modelle. Zusätzlich ist jede KI-Anwendung in einer Function oder einem Container gekapselt – womit wir bis zu drei unterschiedliche Versionen parallel vorhalten können. Zudem haben wir klare Namenskonventionen aufgesetzt und mit unserem Delivery Center in Barcelona Service-Level definiert. Diese analysieren zum Beispiel, ob unsere Container und Anwendungen lebendig sind. Unsere Berechtigungskonzepte sind datenschutzkonform. Alle abnehmenden Systeme werden über Schnittstellen versorgt; alle KI-Ergebnisse sind also API-fähig. Die Daten halten wir in einem Data Lake vor.
Ist das Skalieren von KI-Plattformen ressourcenseitig mit Data Scientists zu stemmen? Oder braucht es darüber hinaus die Domänenexperten?
Zimmer: Mein Bereich arbeitet interdisziplinär. Zum einen zeigen sich Versicherungen wie Corporate Insurance, Leben oder Kfz komplett unterschiedlich. Zum andern beherrschen auch technikaffine Underwriter oder Aktuare Data-Science-Methoden. Sie kommen daher mit ins Boot. Da die Fachbereiche die Regelstrukturen übernehmen müssen, sollten wir deren Teams das Leben so einfach wie möglich machen.
Worauf kommt es hier an?
Zimmer: Der Fachbereichs-Owner soll die analytischen Modelle selbst deployen; er oder sie entscheidet – und setzt die Modelle selbst produktiv. So lassen sich beispielsweise neue Versionen in wenigen Minuten durch den Owner im Fachbereich produktiv setzen. Aktuell bauen wir mehr Mitarbeiter zentral auf: Ich steuere sie, sie arbeiten aber exklusiv auf KI-Themen. Damit wollen wir Künstliche Intelligenz im Fachbereich weiter verbreiten – vor allem, weil sich die Datenlage von Bereich zu Bereich massiv unterscheidet.
In den Fachbereichen, etwa bei den Aktuaren, herrscht offenbar sehr viel Technikbegeisterung. Dort arbeiteten Menschen, die gut mit Zahlen und Methoden umgehen können …
Philipp Schützbach: Weil Versicherungen Vorhersagen treffen, sind sie grundsätzlich zahlenaffiner und weiter in der Thematik „Predictive Analytics“ als andere Industrien. Allerdings liegt der Branchenfokus häufig lediglich auf dem Mehrwert eines spezifischen Use Cases und nicht auf dem Mehrwert, den eine Plattform generieren kann. Der Plattformgedanke ist noch nicht gereift – also das Bewusstsein, dass Kollaboration, Wiederverwendbarkeit und Integration die Business-Bereiche fördern können und Unternehmen dabei helfen, von einigen hin zu hunderten produktiven Use Cases zu skalieren.
Dabei haben Assekuranzen viel Bedarf an Erklärbarkeit durch Wissen aus Daten …
Detzler: Sie müssen den Wirtschaftsprüfern Rechenschaft ablegen und möchten keine Blackbox erzeugen, die kaum nachvollziehbare Ergebnisse ausspuckt. Verantwortliche wollen wissen: Wie funktioniert das Machine-Learning-Modell? Welche Faktoren beeinflussen die Ergebnisse? Was passiert im Hintergrund? Versicherer wollen das noch viel besser verstehen.
Zimmer: Wegen des Personenbezugs in den Daten müssen wir schon aus Datenschutz- bzw. regulatorischen Gründen erklären können, warum wir beispielsweise einen Kunden ablehnen.
Viele Assekuranzen haben in den vergangenen Jahren zahlreiche KI-Use-Cases produktiv gesetzt. Wie stark ausgeprägt ist das Streben nach Skalierung von einschlägigen Ökosystemen, also Plattformen, auf denen mehrere KI laufen?
Thomas Löchte: „Alle Versicherer sind hier auf dem Weg. Denn Assekuranzen werden in Zukunft nicht mehr nur eine einstellige Zahl an KI-Lösungen betreiben, sondern eher Hunderte.“
Schützbach: Das trifft genau den Punkt: Um wettbewerbsfähig zu bleiben, müssen Unternehmen über den Plattformgedanken fähig sein, KI-Initiativen zu skalieren und so das Potenzial von KI in der Versicherungsbranche zu heben. Die Gretchenfrage lautet: Woran liegt es, wenn Assekuranzen solche Anwendungen eben nicht skalieren können?
Thomas Löchte ist KI-Experte und Geschäftsführer der Informationsfabrik:
„Versicherer werden in Zukunft Hunderte KI-Lösungen betreiben“
Welche Hemmnisse habt ihr bei der Skalierfähigkeit tatsächlich festgestellt?
Schützbach: Oft sind im Unternehmen die falschen Tools und Skills verfügbar, etwa einzig Code-basierte Tools. Viele Analysten können damit nicht oder noch nicht ausreichend arbeiten. Eine Kollaboration zwischen relevanten Stakeholdern kann so nicht stattfinden. Auch fehlen häufig die Tools, um die Risiken und den Lebenszyklus von Modellen zu managen. Last, but not least sorgen die historisch gewachsenen Silos für Probleme; Synergien bleiben auf der Stecke. Denn oft implementieren Organisationen die gleichen Use Cases in verschiedenen Bereichen und fangen immer wieder bei Null an.
Zimmer: Zudem braucht es den Fürsprecher oder die Fürsprecherin auf Top-Level-Ebene – für Aufmerksamkeit gegenüber dem Plattformgedanken. Oft ist der Impuls bei der Führung zwar da, Millionen für Plattformen und hippe Methoden auszugeben. Aber auch mit kleinem Geld ist es möglich, sehr viel Nutzen zu stiften und Lösungen zu skalieren.
Mit welchen Data-Science- und KI-Themenfeldern können Versicherer besonders viel Nutzen stiften?
Löchte: Viel Potenzial steckt in einer höheren Dunkelverarbeitungsquote und optimierten Prozessen – sei es Schaden oder Antrag. Rund um neue Geschäftsmodelle sind oft KI-Lösungen wie Telematik-, daten- und nutzungsbasierte Tarife im Einsatz. Wahrscheinlichkeiten wie „Next Best Action“ liefern nicht nur dem Marketing einen schnellen Return on Investment. Zumindest, wenn die Datenbasis dafür da ist.
„Die Plattform sollte man von Anfang an mitdenken, sonst wird KI schnell ineffizient und teuer"
Schützbach: Marketing-Beispiele sind Prognosen für Pricing, Produktempfehlungen oder den Risikobereich – von der Betrugserkennung bis hin zu Kündigungswahrscheinlichkeiten. Können entsprechende Use Cases exemplarisch Mehrwerte aufzeigen, sollten Organisationen sich mit dem Plattformgedanken befassen, denn: Sobald sich Use Cases wiederverwenden lassen, ohne dass man sie von Null hochzieht, greifen Skaleneffekte.
Zimmer: Wir nutzen zudem Inkremente, um mit den richtigen Technologien auch einmal Quick-and-Dirty-Lösungen umzusetzen und diese langfristig zu verbessern. In unserer Plattform sind wir nach einem Jahr im ersten Housekeeping, um Dinge besser zu machen und Lösungen aufzuzeigen. Wenn wir beispielsweise einen Betrug oder einen Regress identifizieren und nur um wenige Prozentpunkte besser werden, hängt daran eine große Summe. Gleichzeitig sehen wir bei der Prozessautomatisierung Systeme, die noch nicht ausgereizt sind.
Würdest du uns ein Beispiel nennen?
Zimmer: Das automatisierte Auslesen und der Abgleich von Personalausweisen ist für Versicherer wichtig, um das Geldwäschegesetz einzuhalten. Mit den Datenmustern lassen sich Prozesse, Roboter, aber auch Workflow Engines versehen. Es entsteht ein Service-Katalog. Das ist zwar kein Volumen-Case. Aber das Erwartungsmanagement mit einer 96-prozentigen Trefferquote gestaltet sich großartig: Man kann Vertrauen in Data Science aufbauen. Über Vertrauen kriegst du Momente bei den Vorständen. Meine mitunter wichtigste Botschaft lautet dort: Die Plattform sollte man von Anfang an mitdenken, sonst wird KI schnell ineffizient und teuer.
Weil Skalierung – auch für Businessstrategie und expansive Themen – eher eine Mindset-Frage ist?
Zimmer: Genau. Wir haben Anwendungen, etwa das Auslesen des Personalausweises, ausgerollt und die Lösung mit den Metastrukturen im Hyperscaler in unserer internationalen Gruppe übernommen. Weil eine Lösung nicht gleichermaßen in jedem Markt genau gleich funktioniert, definieren wir Blaupausen, die wir weltweit ausrollen – rund um Grundfunktionen wie OCR, also Texterkennung.
In welchem Umfang seid ihr hier unterwegs?
Zimmer: Wir haben gerade 3 Anwendungen live, 15 weitere sind in Deutschland in der Pipeline, weltweit sind es weitere 20. Ein Beispiel: Die Regresserkennung lässt es jetzt zu, Regresse frühzeitig in Gerichtsdokumenten zu identifizieren und schon mit wenigen Informationen zum Zeitpunkt der First Notice of Loss (FNOL) eine Regresswahrscheinlichkeit vorherzusagen. Eine ähnliche Engine führen wir mit den Kollegen im Corporate-Insurance-Bereich für Gutachten ein. Strategisch bedeutet das: Mit einem modularen Konstrukt ist es möglich, vertikal und horizontal zu skalieren.
Dr. Michael Zimmer verantwortet die Position des Chief Data Officer bei der Zurich Gruppe Deutschland.
„Durch die Weiterentwicklung von Modellen entstehen unterschiedliche Modellvarianten; sie müssen parallel betrieben werden, um damit unterschiedliche Lebenszyklen der Wertstrecken zu unterstützen“
Schätzt ihr Low-Code-Ansätze und grafische Workflow-Tools im Hinblick auf die Skalierung?
Zimmer: Ich habe noch keine Klickoberfläche gesehen, die deutlich mehr leistet als selbstgeschriebener Code. Spätestens nach einem halben Jahr fällt immer auf, dass der Teufel im Detail steckt.
Detzler: Wir hingegen nutzen nicht nur für Versicherer sowohl Low-Code- als auch No-Code-Ansätze mit vorgefertigten Bausteinen und Modellen. In unseren Lösungen sind diese Ansätze immer hervorragend dokumentiert. Man kommt damit relativ weit. Für Modelle, die sich für Low-Code-/No-Code-Anwendungen sowie grafische Selfservices eignen, bieten wir verschiedene Lösungen an.
Auf wieviel Prozent der Cases trifft diese Möglichkeit zu?
Detzler: Von den Standard-Cases kommt man in 80 Prozent der Fälle mit Low-Code-/No-Code- und grafischen Selfservices gut hin. Ansonsten ist es möglich, eigenen Code zusätzlich einzubinden – sei es über Python, R etc. Allerdings muss man bei selbst geschriebenem Code gleich zu Beginn auf Produktivsetzung und Wiederverwendbarkeit achten, um nachhaltig zu arbeiten. Ansonsten kommen keine zielführenden Ergebnisse heraus.
„Low-Code-Plattformen und Selfservices sind gut für Prozesse geeignet“
Was ist besonders erfolgskritisch an Low-Code-/No-Code-Lösungen und grafischen Workflow-Tools?
Detzler: Wir nehmen grundsätzlich die Fachbereiche mit und bieten ihnen Low-Code-Anwendungen oder Selfservice-Tools an – gerade anfangs immer mit Unterstützung der Data Scientists und der IT. Sind die Fachbereichsmitarbeiter entsprechend geschult und eingearbeitet, wenden sie die Lösungen selbst an. Bei sehr vielen Projekten müssen allerdings immer noch die Experten ran – mit maßgeschneidertem Python- oder R-Code.
Zimmer: Low-Code-Oberflächen als reine Selfservices riskieren, dass dein Programm nicht in Standard-Monitoring-Prozessen enthalten ist – und keiner merkt, wenn es nicht läuft. Gerade, wenn der Selfservice-Entwickler nicht verfügbar ist, kann dies herausfordernd sein. Durch die Weiterentwicklung von Modellen gibt es unterschiedliche Modellvarianten, die parallel betrieben werden müssen, um damit unterschiedliche Lebenszyklen unserer Wertstrecken zu unterstützen. Deshalb stellen wir auf Basis von IT-Best-Practices generell mehrere Container bereit. Für Roll-backs halten wir Repositories vor. Low-Code-Plattformen und Selfservices sind gut für Prozesse geeignet. Bei komplexeren Anwendungen fehlen indes Wartung, Betrieb und Infrastruktur für das Monitoring. Und Performance, Robustheit, Stabilität und Effizienz erhalten eine zusätzliche Bedeutung.
Schützbach: Dennoch möchte ich eine Lanze für Data-Science-Plattformen brechen, die auch Low Code und grafische Workflows beinhalten können. Diese können sowohl bei CI bzw. CD als auch Versionierung mithalten und darüber hinaus als zentrale Plattform – gerade mit Blick auf die Wartbarkeit – einen großen Vorteil generieren, wenn hunderte Projekte produktiv betrieben werden.
Detzler: Zudem baut nicht ein einzelner Mitarbeiter über Low-Code und Co. Lösungen zur Automatisierung auf. Kapazitätsengpässe fängt ein mehrköpfiges Team auf. Die Fachbereiche setzen die Lösungen um, die ihnen zunächst den größten Mehrwert bringen; die IT kann unterdessen planen und Lösungen vernünftig produktiv setzen. Unsere Lösungen bieten zudem Wartung, Betrieb und Monitoring im Standard an.
Dr. Sarah Detzler, Competence Lead Data Science and Machine Learning bei SAP:
„Eine gewachsene IT-Infrastruktur mit vielen Silos lässt sich nicht ohne weiteres auf eine Data-Science-Plattform heben; zudem haben sich bisher viele Unternehmen wenig Gedanken über Methodiken für Data-Science-Projekte gemacht“
Für Versicherungen läuft es auch auf eine saubere Dokumentation hinaus, sobald deren Mitarbeiter selbst programmieren. Dann steigt aber auch die Gefahr, Schaden anzurichten …
Schützbach: Der klassische Data Scientist gilt zwar als fähigster Nutzer bei der Implementierung von Use Cases. Ihm oder ihr fehlt jedoch oft das Domänenwissen über die Daten. Daher sollten Nutzer aus den Fachbereichen und Data Scientists eng bei der Implementierung von Use Cases zusammenarbeiten. Dazu müssen verschiedene Nutzerprofile sowohl in Low Code als auch Full Code befähigt werden, mit den Daten zu arbeiten, – und das in einem gemeinsamen, kollaborativen Tool.
„Ein Machine-Learning-Modell ist kein ,Selbstläufer‘"
Noch etwas weiter gefasst: Was passiert, wenn Modelle nicht mehr funktionieren und sich Bias entwickeln – insbesondere im Hinblick auf Prüfung, Korrektur, Anpassung und begrenzte Mitarbeiterressourcen?
Detzler: Gegebenheiten ändern sich, es kommen neue Daten hinzu und ein Modell kann plötzlich ein paar Prozentpunkte schlechter performen als am Anfang. Man muss hinterfragen, in welcher Geschwindigkeit neue Daten hinzukommen und wann sich gewisse Prozesse ändern. Auf dieser Grundlage kann man das Modell neu trainieren und auf die neue Datenlage anpassen.
Schützbach: Genau, ein Machine-Learning-Modell ist kein „Selbstläufer“. Wer ein solches produktiv setzt, muss zum einen den Lebenszyklus des Modells aktiv managen, sprich: wann und wie ein Modell neu trainiert werden muss. Zum anderen sollte er oder sie auch verstehen, warum sich das Modell so verhält wie es sich verhält. Ein Entscheidungsbaum lässt sich sehr gut nachvollziehen. Man kann aber auch in einem Neuronalen Netz analysieren, ob bezüglich bestimmter Populationen Bias vorliegen.
In welchen Zyklen plant ihr mit der IT und den Fachbereichen den Zeitpunkt von Modell-Tests und -Retrainings?
Detzler: Tests, die Bias abfangen, sollte man regelmäßig durchführen. Oft testen wir quartalsweise neu einlaufende Kundendaten. Darüber stellen wir fest, ob Modelle tatsächlich neu trainiert werden müssen. Bei einigen Use Cases lohnt sich ein monatliches Retraining. Arbeitet man, wie in der Industrie, mit Sensordaten, sollte man die Lösungen bei Bedarf wöchentlich neu trainieren. Bei anderen Cases genügt wiederum ein jährlicher Zyklus.
Schützbach: Bei der Analyse auf Verzerrungen hinterfragen wir: Wie verhält sich das Modell und warum tut es das? Für eine gleichbleibend hohe Modell-Performance empfehlen sich Checks im Produktivbetrieb. Diese lösen, möglichst automatisiert, Modell-Retrainings aus, sollte es Schwierigkeiten geben – etwa durch einen Drift in den Daten oder bei der Performance des Modells.
Wie kann ein solcher automatisierter Check in der Praxis aussehen?
Schützbach: Im sogenannten Supervised-Bereich ist das problematisch. Hier labelt man nicht kontinuierlich neue Daten. Ändert sich die Datenstruktur über die Zeit hinweg, performt das Modell nicht mehr zwingend genauso gut. Daher müssen wir entweder neue Daten labeln, um die Performance des Modells zu validieren, oder wir vergleichen die Unterschiede der neuen Daten mit den ursprünglichen Trainingsdaten, sprich: den Datendrift. Sobald es eine statistische Abweichung gibt, fordert der Workflow einen Mitarbeiter auf, neue Trainingsdaten zu labeln und das Modell zu retrainieren. Oder der Workflow übernimmt dies automatisiert.
Zimmer: Sowohl der Data Drift als auch die Accuracy sind Kernbestandteile sauber aufgesetzter Plattformen. Entscheidend ist es, einen Mitarbeiter automatisiert zu benachrichtigen, wenn die Modelle abweichende Ergebnisse liefern oder nicht mehr treffsicher funktionieren. Einen semiautomatischen Prozess benötigen wir immer, sonst erhalten wir unentdeckte Bias. Auch aus regulatorischer Sicht ist dies zwingend zu vermeiden.
Aus IT-Sicht ist die Vorgabe, eine Vielzahl von Lösungen in eine Plattform zu integrieren, eine Mammutaufgabe. Wie ist es in der Versicherungsbranche aktuell um die zentrale Verwaltung und das Monitoring aller KI-Projekte unter einem virtuellen Dach bestellt?
Löchte: Die einschlägigen Plattformen warten mit allen Funktionalitäten auf, um das Monitoring durchzuführen, das Deployment zu unterstützen und wartbar zu sein. Standardkonzepte gibt es allerdings noch nicht; diese baut jedes Unternehmen für sich. Denn die Datenanforderungen unterscheiden sich von Versicherer zu Versicherer. Ist alles hart kodiert, bedroht das jedoch die Flexibilität.
Detzler: Eine gewachsene IT-Infrastruktur mit vielen Silos kann man außerdem nicht ohne Weiteres auf eine Data-Science-Plattform heben. Zudem sind die meisten Versicherungen Mindset-seitig noch nicht so weit. Nach dem Motto: Agil ist ein Thema. Aber man hat sich noch wenig Gedanken über Methodiken für Data-Science-Projekte gemacht. Ein Mindset-Shift muss sich langsam und kontinuierlich entwickeln.
„Um schneller zu skalieren, brauchen Unternehmen agile, flexible und dennoch standardisierte Prozesse sowie wiederverwertbare Bausteine und fachbereichs-übergreifende Kollaboration“
Was würdet ihr einer Versicherung zur Art und Weise raten, ihre KI-Plattform zu skalieren?
Löchte: Jedes Unternehmen muss seinen eigenen Weg finden. Use Cases sichtbar zu machen und Nutzen zu stiften, Menschen mitzunehmen und Know-how aufzubauen, hilft dabei, Plattformen zu entwickeln. Das ist ein langer, individueller Weg. Außerdem gestalten sich die technologischen Grundlagen vielfältig: angefangen vom Code in Python und der Containerisierung über die Nähe am Kernsystem SAP oder Guidewire bis hin zur Data-Science-Plattform, wie sie etwa DataIku bereitstellt.
Stellt euch vor, wir schreiben das Jahr 2025 und jede Versicherung versucht, smarte KI-Plattformen zu betreiben. Sind wir dann schon am Ende der Möglichkeiten angelangt?
Zimmer: Das Ganze lebt von den eingesetzten KI-Services – am besten welche, die ich warten kann und von denen ich weiß, dass sie keinen Bias aufweisen. Ich möchte die Services über Repositories allgemein zugänglich machen: Nutzt eine Organisationseinheit KI-Services, wird mein Team informiert. Dann können wir unseren Schieberegler für die Performance hochfahren. Allmählich sind wir in der Lage, Service-orientierte Architektur tatsächlich zu nutzen. Unsere Services dokumentiert, wartbar und zukunftsfähig zu halten, ist noch ein weiter Weg. Aber eins ist sicher: KI wird in jedem Versicherungsprozess stecken.
Schützbach: Sowohl zunehmende Verfügbarkeit großer Datenmengen als auch Fortschritte bei Rechenleistung und Skalierbarkeit durch Hyperscaler werden zu einer zunehmenden Nutzung von KI führen. Um schneller zu skalieren, brauchen wir in Unternehmen jedoch agile, flexible und dennoch standardisierte Prozesse sowie wiederverwertbare Bausteine und fachbereichsübergreifende Kollaboration.
„Künftig wird man mehr fertige Modelle für Spezialaufgaben erhalten“
Würdet ihr bitte ein Beispiel nennen?
Löchte: Standardmodelle für Übersetzung oder Handschrifterkennung decken künftig ein deutlich breiteres Feld ab. Das führt dazu, dass man künftig mehr fertige Modelle für Spezialaufgaben erhält. Aktuell muss man diese in der Regel erst noch für die eigene Plattform entwickeln.
Ist die Versicherungsbranche hier besser als ihr Ruf?
Absolut. Es wird mehr unternehmensübergreifende Lösungen geben – als Ökosystem und mit Kooperationspartnern. Damit kommen weitere Optimierungsmöglichkeiten auf die Branche zu: Über gemeinsame datenbasierte Lösungen lässt sich weiteres Potenzial heben. In fünf Jahren werden wir genau an diesen Themen arbeiten.
Ansprechpartner
Dr. Sarah Detzler
Competence Lead Data Science and Machine Learning
SAP
communications@ikor.one
+49 40 8199442-0
Dr. Michael Zimmer
Chief Data Officer
Zurich Gruppe Deutschland
communications@ikor.one
+49 40 8199442-0
Philipp Schützbach
Sales Engineer
Dataiku
communications@ikor.one
+49 40 8199442-0
