Datenschutz in der Versicherungstelematik: Was Kunden zur Einwilligung bewegt (und was nicht)

Fragen Sie ein beliebiges Produktteam in einer Versicherung nach der größten Hürde bei der Telematik-Einführung, und Datenschutz landet meist unter den Top drei. Manchmal ganz oben. Selten in Frage gestellt, selten falsch — aber fast immer unvollständig.

Die Studienlage stützt die Sorge. Pew hat festgestellt, dass 81 % der US-Erwachsenen sich Sorgen darüber machen, wie Unternehmen ihre Daten verwenden.¹ Eine Studie von 2024, die sich speziell mit Autofahrern befasst hat, ermittelte 68 % als besorgt über Telematik-Tracking.² In Deutschland kam eine Bitkom-Umfrage vom Februar 2024 auf 98 % der Befragten, die volle Transparenz darüber wünschen, was ihr Fahrzeug erfasst.³ Wenn Datenschutz vor zehn Jahren noch wie eine Nischensorge wirkte, ist er das heute nicht mehr.

Was dieselbe Forschung seltener zeigt: Datenschutzbedenken und Datenschutzverweigerung sind nicht dasselbe. Über die Hälfte der Fahrer in der US-Studie gaben an, sie würden sich für Telematik entscheiden, wenn Versicherer zusagen, die Daten nicht zu verkaufen, transparent machen, was erfasst wird, und Kontrolle über die Löschung geben.² Das ist kein Datenschutzproblem. Das ist ein Designproblem.

In der Versicherungstelematik wird diese Diskussion seit zwei Jahrzehnten in unterschiedlichen Varianten geführt. Die Antworten sind schärfer geworden. Das Datenschutzrecht ist klarer, die Connected-Vehicle-Leitlinien des EDPB sind explizit, und in benachbarten Branchen läuft die Aufsicht bereits.⁴ Auch die Marktchance ist real: Der europäische UBI-Markt wurde 2024 auf rund 10 Milliarden US-Dollar geschätzt und verdoppelt sich weiterhin etwa alle vier Jahre.⁵ Die Fahrer in diesem Markt entscheiden allerdings einzeln — und sie entscheiden auf Basis dessen, was sie verstehen können.

Eine Anmerkung dazu, wo wir in dieser Diskussion stehen, bevor es weitergeht. Dolphin baut Telematik über das gesamte Architekturspektrum: vollständig anonyme Programme, Chinese-Wall-Architekturen nach den EDPB-Vorgaben, und Programme, in denen der Versicherer einen klassischen Datenfluss mit Kenntnis und Einwilligung des Nutzers wünscht. Wir haben Präferenzen, und diese Seite legt sie offen. Wir haben auch Auftragsbücher, und unsere Präferenzen beschreiben nicht jedes Programm, das wir je ausgeliefert haben. Was folgt, ist das, was wir funktionieren sehen, wenn das Ziel Adoption ist und nicht Compliance als Selbstzweck.

Diese Seite zeigt, wie man die Entscheidung denkt, die jeder Telematik-Nutzer trifft, oft bevor er je ein Prämienangebot sieht. Sie behandelt, was das Recht verlangt, wo das Recht nicht reicht, und was europäische Versicherer, die das funktionieren lassen, tatsächlich getan haben. Die Kurzfassung: Nutzer lehnen Telematik selten aus Datenschutzgründen ab. Sie lehnen sie ab, weil der Nutzen nicht sichtbar ist.

Die drei Fragen, die jeder Nutzer wirklich stellt

Wenn ein Fahrer eine Telematik-App zum ersten Mal öffnet, liest er nicht die Datenschutzerklärung. Er rechnet. Mit drei Eingangsgrößen, und die sind unabhängig vom Markt fast immer dieselben.

Was gebe ich ab? Die Frage geht nicht eigentlich um Datenkategorien. Niemand öffnet eine App und denkt in „Bewegungsvektoren“ oder „GNSS-Koordinaten“. Er denkt an zwei Dinge: ob die App ihn in irgendeinem diffusen Sinn verfolgt, und ob jemand, den er kennt, die Daten zu sehen bekommt. Beides ist adressierbar — aber nur, wenn es direkt adressiert wird. Telematikprogramme, die mit einer Sensor-Liste eröffnen, verlieren den Nutzer, bevor die Liste zu Ende ist. Programme, die mit „Dieser Dienst erkennt einen Unfall und alarmiert Hilfe — er teilt Ihren Standort mit niemandem“ starten, haben die eigentlich relevante Frage bereits beantwortet.

Was bekomme ich zurück? Diese Frage überspringen die meisten Datenschutzdiskussionen. Die akademische Forschung ist eindeutig zu ihrem Gewicht: Gerber und Kollegen kamen in ihrem Review zum Privacy Paradox 2018 zu dem Schluss, dass wahrgenommener Nutzen einer der stärksten Prädiktoren für die Bereitschaft zur Datenoffenlegung ist — neben Gewohnheit und konkretem Mehrwert.⁶ Capgeminis Studie 2023 mit über 3.000 europäischen Fahrzeughaltern fand nur etwa ein Drittel bereit, heute Fahrzeugdaten zu teilen — und stellte fest, dass der Hebel zur Veränderung konkreter, zweckspezifischer Nutzen ist, kein zusätzlicher Vertragstext.⁷ In der Versicherungstelematik liegt dieser Nutzen meist in einer von drei Formen: Hilfe, wenn etwas schiefgeht (Unfallerkennung, Pannenhilfe), Anerkennung, wenn etwas richtig läuft (Prämienrabatte, Belohnungen, Score-Verbesserungen), oder Einsichten, die der Nutzer aus eigenem Recht wertvoll findet (Fahrfeedback, sicherere Routenvorschläge). Programme, die mit einer dieser drei Formen führen und konkret bleiben, sehen messbar und konsistent höhere Opt-in-Raten. Programme, die mit Preislogik einsteigen, selten.

Habe ich morgen noch eine Wahl? Diese Frage trennt „Einwilligung“ von „Vertrauen“. Selbst Nutzer, die am ersten Tag gerne zustimmen, ziehen ihre Einwilligung still zurück, wenn sie später das Gefühl haben, sie könnten das nicht offen tun. Die praktische Konsequenz ist die sichtbare Kontrolloberfläche: ein Dashboard, das zeigt, was die App gerade erfasst, ein Pause-Button mit einem Tap, ein klarer Löschpfad. Die Forschung zu Voreinstellungen ist hier relevant. Johnson und Goldsteins Science-Paper zur Organspende-Einwilligung von 2003 hat gezeigt, dass Defaults Verhalten stark verankern, selbst bei vergleichbaren erklärten Präferenzen;⁸ in der Telematik ist das Pendant, dass die Default-Haltung eines Programms (Opt-in pro Dienst statt gebündelt, sichtbare statt versteckte Kontrollen) sowohl Einwilligungsrate als auch nachfolgendes Engagement prägt. Ein Programm, das Kontrolle sichtbar macht, muss sie fast nie ausüben lassen.

Drei Fragen, drei Antworten, in dieser Reihenfolge. Wenn die Antworten klar sind, folgt Adoption fast natürlich. Bleibt eine der drei vage, behandelt der Nutzer den ganzen Dienst als Glücksspiel — und mit Daten spielen die wenigsten.

Das konkrete Beispiel, das das in den meisten Versicherer-Gesprächen einrastet, ist die automatische Unfallerkennung. Sie ist wohl der datenintensivste Telematik-Dienst am Markt: kontinuierliche Bewegungsmessung, kontextuelle Interpretation von Fahrmustern und präzise Standortdaten im Moment des Aufpralls. Wäre Datenschutzbesorgnis primär eine Frage der Datendichte, müsste Unfallerkennung niedrige Opt-in-Raten haben. Hat sie nicht. In den europäischen Programmen, mit denen wir arbeiten, ist die Akzeptanz konstant hoch, weil alle drei Fragen Ein-Satz-Antworten haben. Was gebe ich ab: meine ungefähre Bewegung und meinen Standort, nur während der Fahrt. Was bekomme ich zurück: schnelle Hilfe bei einem Unfall. Habe ich noch eine Wahl: jederzeit. Die Daten sind schwer; die Entscheidung ist leicht.

Nichts davon ist für uns theoretisch. Wir sehen auch das umgekehrte Muster: Programme, in denen die drei Fragen offenbleiben, in denen die Architektur technisch konform ist, aber die nutzerseitige Geschichte vage bleibt, in denen die Opt-in-Quoten unter 10 % stagnieren und niemand genau weiß, warum. Die Antwort ist meist dieselbe. Nicht, dass die Datenerhebung falsch war, sondern dass die Erklärung gefehlt hat. Der Rest dieser Seite zeigt, wie diese Lücke geschlossen wird — welche Designentscheidungen die Antworten verlässlich schärfen, und wo die drei Dolphin-Angebote im Spektrum sitzen.

Warum Datenschutz die größte Adoptionshürde ist, die Versicherer hören

Datenschutzbedenken bei Fahrern sind breit und gut dokumentiert. Pews US-Umfrage 2023 fand 81 % der Erwachsenen besorgt darüber, wie Unternehmen ihre Daten verwenden, mit zwei Dritteln, die nach eigenem Bekunden wenig oder nichts darüber wissen, was Unternehmen tatsächlich damit anfangen.¹ Speziell auf Telematik bezogen ergab eine US-Studie 2024 einen Anteil von 68 % der Fahrer mit Tracking-Bedenken.² In Deutschland hat Bitkom Anfang 2024 über 1.000 Verbraucher befragt und festgestellt, dass 98 % volle Sicht auf das wollen, was ihr Fahrzeug erfasst, und 97 % die Möglichkeit, die Datenübertragung jederzeit zu stoppen.³

Die Lücke zwischen dieser Sorge und tatsächlicher Adoption ist die Zahl, auf die es ankommt. Consumer Reports hat 2024 mehr als 40.000 US-Versicherte befragt und festgestellt, dass nur 14 % in einem Telematikprogramm sind — und nur 28 % überhaupt wissen, dass ihr Versicherer eines anbietet.⁹ Im DACH-Markt hat HUK-Coburg, Deutschlands größter Kfz-Versicherer, sein Telematik Plus-Programm 2024 auf rund 670.000 Nutzer ausgebaut — beeindruckend in absoluten Zahlen, aber immer noch nur etwa 5 % seines 13,3-Millionen-Kundenstamms.¹⁰

Daraus folgen zwei Dinge. Erstens: Der adressierbare Markt ist groß und überwiegend uninformiert, nicht aktiv ablehnend. Zweitens: Die Hürde zwischen „weiß davon“ und „macht mit“ ist die Stelle, an der Programmdesign den Unterschied macht. Programme, die mit Daten eröffnen, bleiben tendenziell klein. Programme, die damit eröffnen, was der Dienst tatsächlich für den Nutzer leistet, wachsen.

Was eine Telematik-App tatsächlich erfasst (und was sie nicht braucht)

Vor der Kategorienliste eine Realitätsprüfung, die es wert ist, ausgesprochen zu werden. Ein Fahrer, der eine Telematik-App installiert, entdeckt nicht zum ersten Mal, dass die App Standortdaten erfasst. Die Datenschutzfrage, die er stellt, lautet nicht „Erfasst ihr Daten“, sondern „Was genau, wofür, mit wem und wie lange“. Datenschutzrecht ist so geschrieben, dass es Nutzer schützt, die diese Fragen nicht stellen — auch die schwächsten Glieder der Kette, was richtig und notwendig ist. Einen Telematikdienst zu betreiben heißt allerdings, die Fragen für die Nutzer, die sie stellen, ehrlich zu beantworten. Die Liste unten ist die ehrliche Version dessen, was eine moderne smartphonebasierte Telematik-App erfasst, und was sie absichtlich nicht anrührt.

Die funktionalen Daten gliedern sich in vier Kategorien:

• Bewegung — Beschleunigungs- und Gyroskopwerte zur Erkennung von Fahrten, Bremsungen, Kurvenverhalten, Beschleunigungen und Aufprallereignissen.
• Standort — GPS oder gleichwertige Positionierung, so oft abgetastet, wie der Dienst es benötigt, und nicht häufiger. Für Unfallerkennung und Fahrtzusammenfassungen ist das vergleichsweise leicht; für Turn-by-Turn-Coaching schwerer.
• Fahrzustand — abgeleitete Signale wie Fahrtbeginn/-ende, Verkehrsmittel (Auto vs. Beifahrer vs. ÖPNV), Handy-am-Steuer-Ereignisse.
• Gerätekontext — Betriebssystem, App-Version, Berechtigungsstand und ähnliche Metadaten, die nötig sind, um den Dienst zuverlässig über tausende Endgerätemodelle hinweg zu betreiben.

Identität sitzt in einem getrennten Bucket. In einer gut entworfenen Telematik-Architektur sind die obigen Fahrdaten nur über eine gehashte Kennung mit einem Nutzer verknüpft, die der Telematik-Anbieter nicht zurückrechnen kann. Die personenbezogenen Daten, die einen Nutzer identifizierbar machen (Name, Adresse, Telefonnummer, E-Mail, Versicherungsnummer), liegen separat beim Versicherer, mit einer Einwegabbildung zwischen beiden. Das ist die „Chinese-Wall“-Architektur, die das EDPB beschreibt, und der strukturelle Grund, weshalb Telematik-Anbieter nicht sehen müssen — und in der Regel nicht sehen können — wem ihre Daten gehören.

Was eine Telematik-App nicht braucht — und was eine gut gebaute App nicht abfragt — ist fast alles andere auf dem Telefon. Kontakte, SMS, Anruflisten, Fotos, Browserverlauf, App-Nutzung außerhalb des Diensts: nichts davon hat eine Rolle dabei zu messen, wie ein Fahrzeug bewegt wird, oder einen Unfall zu erkennen. Diese Daten abzufragen erodiert Vertrauen, ohne Dienstwert hinzuzufügen. Die eigentliche Designarbeit läuft in die andere Richtung: das Minimum aus der obigen Liste so einzusetzen, dass jede Funktion liefert, und transparent zu sein, welche Daten wohin gehen.

Was die europäische Regulierung tatsächlich verlangt

Der rechtliche Rahmen für EU-Telematik ist klarer, als oft dargestellt wird. Das Kerndokument sind die EDPB-Leitlinien 01/2020 zur Verarbeitung personenbezogener Daten im Kontext vernetzter Fahrzeuge, im März 2021 verabschiedet.⁴ Für ein Aufsichtsdokument ist es lesbar geschrieben. Seine Kernposition: Einwilligung ist die Standard-Rechtsgrundlage für das Speichern oder Zugreifen auf Daten in fahrzeugseitigen Endgeräten unter der ePrivacy-Richtlinie — und das Wort consent erscheint sechsundachtzig Mal im Dokument.

Zwei Prinzipien aus den Leitlinien prägen, wie Telematikprogramme architektonisch aufgesetzt werden sollten.

Das erste ist Datenminimierung, am besten zu lesen als zweckangemessen statt als absolut minimal. Ein Telematikdienst, der Unfälle erkennt, braucht laufende Bewegungserfassung und präzise Standortdaten im Moment des Aufpralls; ein Dienst, der Fahrverhalten bewertet, braucht durchgehende Bewegungsdaten und fahrtbezogenen Standortkontext. Beides ist angemessen zu dem, was es tut, und beides ist genau das, was das EU-Recht erlaubt, wenn Dienst und Datenfluss aufeinander passen. Die Designfrage, die die Aufsicht stellen wird, lautet: passt das, was das Programm erhebt, zu dem, was der angegebene Dienst braucht — nicht, ob es „so wenig wie möglich“ ist.

Das zweite ist Zweckbindung. Das EDPB stellt explizit fest, dass Telemetriedaten, die zu Wartungszwecken erfasst wurden, nicht ohne neue, zweckspezifische Einwilligung an einen Versicherer für verhaltensbasierte Produkte weitergeleitet werden dürfen.¹¹ Diese Unterscheidung wird zunehmend tragend, da Fahrzeughersteller Connected-Vehicle-Daten ansammeln und neue kommerzielle Verwendungen prüfen. Ein Versicherer, der sich auf OEM-Datenflüsse stützt, statt auf ein eigenes einwilligungsbasiertes Telematikprogramm, braucht zweckspezifische Einwilligung des Nutzers — nicht die ursprüngliche Einwilligung beim Fahrzeugkauf. Ein Versicherer, der eine einwilligungsbasierte Telematik-App unter eigener Marke betreibt, hat die einfachere Geschichte zu erzählen.

Vorausblickend hat die CNIL im März 2025 ein öffentliches Konsultationsverfahren zu einer neuen Empfehlung speziell für Standortdaten vernetzter Fahrzeuge eröffnet — ein Hinweis darauf, wohin die nächste europäische Aufsichtswelle läuft.¹²

Zum Vergleich: Das US-Bild ist weniger harmonisiert, dafür streitfreudiger — und die jüngst aufgetauchten Fälle drehen sich um Einwilligungsarchitekturen, die sich von der europäischen Telematik-App-Norm deutlich unterscheiden. Im Januar 2025 hat der texanische Generalstaatsanwalt Allstate und seine Tochter Arity verklagt — wegen verdeckter Erfassung von Fahrdaten von rund 45 Millionen Amerikanern über SDKs, eingebettet in Drittanbieter-Apps. Die erste US-Vollzugsmaßnahme unter einem umfassenden Datenschutzgesetz auf Bundesstaatsebene.¹³ Im April 2025 folgte eine Sammelklage gegen Toyota und Progressive — mit dem Vorwurf, Fahrzeugtelemetrie sei ohne informierte Einwilligung über einen Datenhändler weitergegeben worden.¹⁴ Die konkreten Architekturen, die in beiden Fällen angegriffen werden (versteckte Einwilligung, Drittanbieter-SDK-Ketten, keine klare Zweckbindung), sind genau die, die die europäische Praxis seit Jahren entmutigt — und die eine sauber entworfene Versicherungstelematik-App schon konstruktiv ausschließt.

Bislang hat keine EU-Datenschutzbehörde einen Kfz-Versicherer speziell für sein Telematikprogramm bebußt. Diese Lücke wird nicht ewig bleiben, aber sie spiegelt, dass europäische Telematik überwiegend auf den einwilligungs- und zweckspezifischen Mustern aufgebaut wurde, auf die die Aufsicht achtet. Programme, die das fortführen — und gegenüber Nutzern explizit machen, was ihre App tut und warum —, sollten erwarten, auf der richtigen Seite zu landen, wenn die nächste Vollzugsentscheidung fällt.

Warum „DSGVO-konform“ keine Go-to-Market-Botschaft ist

Rechtlich konform zu sein schützt den Versicherer. Den Dienst dem Nutzer zu erklären ist eine andere Aufgabe.

Die akademische Literatur zu Datenschutzentscheidungen ist dazu seit einem Jahrzehnt konsistent. Acquisti, Taylor und Wagman beschreiben in ihrem Review im Journal of Economic Literature 2016 die Position des Verbrauchers als „unvollständige oder asymmetrische Information darüber, wann seine Daten erhoben werden, zu welchen Zwecken und mit welchen Folgen“.¹⁵ Kein Datenschutztext, wie gut er auch verfasst ist, schließt diese Asymmetrie aus eigener Kraft. Kirsten Martins Arbeit zum Privacy Paradox aus 2020 erweitert den Punkt: Sobald ein Unternehmen Daten verlangt, übernimmt es eine zugehörige Sorgfaltspflicht, deren Verletzung Misstrauen erzeugt, das mit einem unmittelbaren Sicherheitsversagen vergleichbar ist.¹⁶

Praktisch heißt das: Ein einwilligungsbasiertes Telematikprogramm kann am Vertrauen scheitern. Ein Nutzer, der den Haken unter 40 Seiten AGB setzt, erinnert sich nicht, wozu er zugestimmt hat — und wenn er das erste Mal eine Funktion erlebt, die sich anders verhält, als er erwartet hatte, fühlt sich die Einwilligung für ihn nicht mehr gültig an, ob rechtlich bindend oder nicht. Programme, die das vermeiden, behandeln Einwilligung nicht als das Ereignis, das alles Nachfolgende autorisiert, sondern als laufendes Gespräch zwischen App und Nutzer.

Das ist die Grenze, an der Compliance endet und Design beginnt. Im nächsten Abschnitt geht es um das Design.

Designentscheidungen, die wir über das Spektrum hinweg empfehlen

Die konkreten architektonischen und Interaktions-Entscheidungen, die mit höheren Opt-in-Raten korrelieren, liegen auf drei Ebenen.

Architektur. Trennen Sie die Identität des Nutzers von den Fahrdaten — das Telematik-Backend sieht einen Hash, das Bestandssystem des Versicherers sieht einen Namen, und die Brücke dazwischen ist schmal und auditierbar. Verarbeiten Sie auf dem Endgerät, was sich auf dem Endgerät verarbeiten lässt, statt alles an einen Server zu senden. Behalten Sie nur, was der Dienst braucht, und nur so lange, wie er es braucht — und definieren Sie diesen Aufbewahrungszeitraum explizit, statt ihn offen zu lassen. Nichts davon hindert einen Versicherer daran, ein attribuiertes Programm zu fahren, wenn das Produkt es verlangt. Es setzt die Defaults so, dass die Begründungslast in Richtung Mehr-Erfassen wandert, nicht in Richtung Weniger-Erfassen.

Interaktion. Fragen Sie pro Zweck einzeln statt Einwilligungen zu bündeln. Geben Sie dem Nutzer ein sichtbares Dashboard, das zeigt, was die App gerade tut — nicht nur, was die Datenschutzerklärung sie tun lassen darf. Machen Sie die Pause-Funktion zu einem Tap, und machen Sie Kontolöschung zu einem klaren Pfad statt zu einer versteckten E-Mail-Adresse. Nutzer verwenden Pause oder Löschung selten, wenn die Funktionen existieren; sie verlassen das Programm ganz, wenn die Funktionen fehlen.

Botschaft. Die wirkungsstärkste Textänderung, die wir programmübergreifend sehen, ist der Wechsel von Überwachungs- zu Service-Sprache. „Wir tracken Ihre Fahrt“ landet anders als „Wir erkennen einen Unfall und alarmieren Hilfe“. Beide beschreiben überlappende technische Fähigkeiten, aber nur die zweite Formulierung beantwortet die eigentliche Frage des Nutzers. Coaching-Sprache schlägt Bewertungs-Sprache aus demselben Grund. Programme, die Telematik als Feedback-Werkzeug rahmen statt als Überwachungsinstrument, sehen messbar höheres dauerhaftes Engagement.

Diese Entscheidungen sind die Empfehlung. Im nächsten Abschnitt sehen Sie, wo jedes der drei Dolphin-Angebote dazu steht und wie konfigurierbar es in der Praxis ist.

Die drei Dolphin-Angebote und ihre Position auf dem Datenschutzspektrum

Das Produktportfolio von Dolphin baut auf einer Telematik-Engine mit drei unterschiedlichen Verpackungs- und Betriebsmodellen auf. Sie sitzen standardmäßig an unterschiedlichen Stellen des Datenschutzspektrums, und jedes ist konfigurierbar, um sich entlang des Spektrums zu bewegen, wenn das Programm des Versicherers das verlangt.

MOVE Score App. Unsere eigene App, direkt für Endnutzer verfügbar. Die Registrierung ist hashbasiert und standardmäßig anonym: Wir fragen bei der Anmeldung nicht nach Name, E-Mail oder Versicherungsstatus, und der MOVE Score selbst ist ein Risikosignal, das aus Fahrverhalten und Exposition abgeleitet wird, ohne die Identität des Nutzers zu benötigen. Das ist das datenschutzfreundlichste Ende des Spektrums — gedacht, damit Versicherer ein Telematikprogramm testen oder einen „Try-Before-You-Buy“-Akquisefunnel betreiben können, ohne personenbezogene Daten zu onboarden, die sie noch nicht brauchen. Die App eignet sich auch als Maßstab: Sie ist die Referenzimplementierung der oben skizzierten Designprinzipien.

MOVE SDK. Die Engine allein, in die App eines Versicherers integriert (oder in jede andere App). Das SDK bringt die Identitätstrennung architektonisch bereits mit, und es unterstützt das volle Spektrum an Telematikfunktionen, von Fahrtenerkennung und Verhaltensscoring bis hin zu automatischer Unfallerkennung. Was es nicht tut: der integrierenden App eine bestimmte Datenfluss-Architektur aufzwingen. Ein Versicherer kann das MOVE SDK in einer vollständig anonymen Konfiguration betreiben, in einer Chinese-Wall-Konfiguration, die Hashes nur dann auf Identitäten abbildet, wenn es wirklich nötig ist, oder in einer klassisch attribuierten Konfiguration, in der der Versicherer von Anfang an Fahrdaten auf Nutzerebene sieht. Alle drei werden unterstützt; die Wahl liegt beim Versicherer.

White-Label-Apps. Wir bauen die App — typischerweise auf Basis von MOVE SDK und MOVE Score — für Versicherer, die schneller starten wollen, als ein eigenes Mobile-Team es zuließe. Produkt und Onboarding werden mit Markenführung und Programmlogik des Versicherers entworfen. Die zugrundeliegende Datenschutz-Haltung ist dasselbe konfigurierbare Spektrum wie beim SDK: anonym, Chinese-Wall oder attribuiert, je nach gewählter Architektur des Versicherers.

Die Empfehlungen aus dem vorhergehenden Abschnitt sind das Muster, das wir mit Adoption korrelieren sehen. Sie sind kein Diktat. Ein Versicherer mit einem spezifischen Programmdesign, regulatorischem Umfeld oder bestehender Kundenbeziehung hat manchmal gute Gründe für eine andere Konfiguration — und wenn das so ist, bauen wir zu dieser Konfiguration, statt dagegen zu argumentieren. Was wir tun: ihm ehrlich sagen, wo wir die Opt-in-Quote landen sehen.

Wie drei europäische Versicherer das in die Praxis übersetzt haben

Die drei Case Studies auf dieser Seite decken den Großteil des Spektrums ab, in dem Versicherer operieren. Jede ist live, jede ist offen für Nutzer über den eigenen Versicherten-Bestand hinaus, und jede kombiniert die obigen Designprinzipien mit einer eigenen kommerziellen Logik.

Generali Österreich — Mobility App, gestartet Mai 2022. Die früheste der drei und der am längsten laufende Beleg. Generali hat die App als Mobilitätsprogramm positioniert, nicht als Versicherungstool: Sicheres Fahren und umweltbewusste Mobilitätsentscheidungen verdienen In-App-Belohnungen, das Engagement geht über den Verlängerungstermin hinaus. Die Privacy-First-Architektur trägt diese Positionierung; die App wurde allen Fahrern in Österreich zugänglich gemacht, nicht nur Generali-Versicherten — was in einem klassischen attribuierten Datenmodell schwerer zu rechtfertigen wäre.

Porsche Versicherung Österreich — Smart Driver, gestartet Oktober 2023. Kommerziell näher am klassischen UBI-Muster — sicheres Fahren übersetzt sich in bis zu 20 % Rabatt auf die monatliche Versicherungsprämie — bei gleicher Identitätstrennungsarchitektur. Retention war die Designpriorität: ein gamifiziertes Fahrerlebnis, das den Nutzer auch zwischen Vertragsereignissen die App öffnen lässt. Die Case Study dokumentiert die konkreten Designentscheidungen, die in diese Retention-Kurve eingeflossen sind.

UNION Biztosító (VIG) — Drivello, gestartet November 2025. Die jüngste — und das deutlichste Beispiel für das „Trust-First“-Ende des Spektrums. Drivello gibt jedem Nutzer ab dem Tag nach der Registrierung ein Jahr kostenlose Pannenhilfe, unabhängig davon, ob er eine UNION-Police abschließt, und nutzt den MOVE Score zur Unterstützung der Rabattberechtigung auf die Pflichthaftpflicht. Fahrdaten werden ausdrücklich für Coaching und Rabattkalkulation verwendet — nicht für Prämienerhöhungen oder Schadensentscheidungen. Eine Zusage, die sichtbar ist, statt in den AGB vergraben. Drivello spiegelt das Drei-Fragen-Schema in seinen UX-Entscheidungen am deutlichsten wider.

In den drei Programmen sehen wir Opt-in-, Retention- und Net-Promoter-Werte, die keines davon mit einer klassischen „Lade unsere App, um die Prämie zu senken“-Wertversprechung erreicht hätte. Die Unterschiede im Design — nicht die Unterschiede in der Datenerhebung — erklären die Kurven.

→ Die vollständigen Case Studies: Generali, Porsche, UNION Drivello.

Fragen, die Versicherungs-Produktteams uns tatsächlich stellen

Auf welche Rechtsgrundlage sollten wir uns bei der Telematik-Verarbeitung stützen — Einwilligung, Vertrag oder berechtigtes Interesse?

Für die meisten nutzerseitigen Telematikfunktionen ist die Einwilligung nach EU-Recht die konservative Voreinstellung. Die EDPB-Leitlinien 01/2020 stellen das ausdrücklich so fest, und für Funktionen, die sensible Daten berühren (laufende Standortverfolgung, Fahrstilprofiling), ist sie die einzige Option, die einer aufsichtsrechtlichen Prüfung verlässlich standhält. Insurance Europe hat argumentiert, dass auch Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) für telematikbasierte Produkte verfügbar sein sollte,¹⁷ doch die Einwilligung bleibt die Position, die in den meisten Vollzugsszenarien Bestand hat. Welche Antwort für ein konkretes Programm richtig ist, hängt vom Funktionsumfang, der Jurisdiktion und der breiteren Datenschutzstrategie des Versicherers ab — ein Gespräch, das mit dem DSB geführt werden sollte, bevor die Architektur festgezurrt ist.

Wie wählen wir zwischen einer Anonymous-by-Design-Architektur und einer Chinese-Wall-Architektur?

Die Entscheidung läuft meist darauf hinaus, wofür das Programm die Nutzeridentität tatsächlich braucht. Wenn der Versicherer Fahrdaten mit einer konkreten Police verknüpfen muss (Prämienrabatt, Schadensabgleich, Vertragskommunikation), passt eine Anonymous-by-Design-Architektur nicht — die Chinese-Wall-Architektur ist dann die richtige strukturelle Antwort. Geht es primär um Kundengewinnung oder Engagement — ein eigenständiger Fahranalysedienst, ein Try-Before-You-Buy-Funnel — ist Anonymous-by-Design einfacher und aus Datenschutzsicht stärker. Die MOVE Score App von Dolphin steht in der zweiten Kategorie; die meisten White-Label- und SDK-Integrationen in der ersten.

Welche Opt-out-Mechanik sollte unsere Telematik-App bieten, und wie granular sollte sie sein?

Mindestens: ein Ein-Klick-Pause für den gesamten Dienst, zweckgebundene Schalter für einzelne Funktionen (Fahrtenerfassung, Unfallerkennung, standortbasierte Dienste) und ein klarer Pfad zur Kontolöschung mit definierter Aufbewahrungsfrist für Restdaten. Granulares Opt-out wird gelegentlich als Risiko für die Dienstintegrität gesehen; in der Praxis sehen Programme, die es anbieten, niedrigere harte Opt-out-Raten — die Nutzer behalten das Gefühl von Kontrolle, das sie sonst ganz aus dem Programm hinaustreibt.

Wie sollte unser Onboarding die Datenerhebung erklären, ohne Ablehnung auszulösen?

Funktionen zuerst, Daten danach. Beschreiben Sie den Dienst, den der Nutzer erhält, dann beschreiben Sie, was der Dienst dafür verwendet, und zeigen Sie schließlich die Kontrollen, mit denen er das steuern kann. Halten Sie jeden Schritt kurz und konkret. Vermeiden Sie generische Datenschutz-Formulierungen im Onboarding selbst — die 40-seitige Datenschutzerklärung kann an ihrem Ort bleiben, das Onboarding sollte die drei Fragen beantworten, die der Nutzer wirklich stellt: Was gebe ich ab, was bekomme ich zurück, kann ich später noch umentscheiden.

Welche Aufbewahrungsfrist sollte unser Telematikprogramm verwenden?

Definiert, spezifisch und an einen erklärten Zweck pro Datenkategorie gebunden. Rohe GPS-Spuren sollten in der Regel über Wochen, nicht über Jahre aufbewahrt werden; aggregierte Fahrscores können länger gespeichert werden, wenn das Programm historisches Feedback oder Trendanalysen anbietet. Open-ended-Aufbewahrung zieht am ehesten regulatorische Aufmerksamkeit auf sich und ist am schwersten unter dem Speicherbegrenzungsgrundsatz der DSGVO zu rechtfertigen.

Hält Hashing dem Re-Identifikationsrisiko in einem Telematik-Datensatz tatsächlich stand?

Das Hashing einer Nutzerkennung ist notwendig, aber nicht hinreichend. Telematikdaten sind hochdimensional — Fahrtmuster, Wohn- und Arbeitsort, Tagesablauf — und können von jemandem mit Zugang zu Hilfsdaten auch dann re-identifiziert werden, wenn direkte Identifikatoren entfernt sind. Die architektonische Antwort ist, gehashte Fahrdaten und Identitätsabbildung in getrennten Systemen zu halten, mit Zugriffsrechten, die das Zusammenführen beider zu einer bewussten, protokollierten Handlung machen statt zu einer ständig verfügbaren Möglichkeit. Das ist die strukturelle Eigenschaft, die unter Druck hält; Hashing allein nicht.

Wie briefen wir die Aufsichtsbehörde am besten zu unserem Telematikprogramm vor dem Start?

Ein Vorab-Briefing — wo die Haltung der Behörde das zulässt — ist die Investition in der Regel wert. Bringen Sie die Architektur mit, die Datenflüsse, die Aufbewahrungspläne und die nutzerseitige Einwilligungsmechanik; erwarten Sie Fragen zur Begründung der Datenminimierung und zur gewählten Rechtsgrundlage je Verarbeitungstätigkeit. Programme, die früh mit der Aufsicht ins Gespräch gehen, kommen tendenziell schneller zum Launch — die aufgeworfenen Fragen wären dem Programm ohnehin begegnet, und sie vor dem Launch zu adressieren ist günstiger als sie hinterher zu beheben.

Wo das hingeht

Die CNIL-Empfehlung 2025 zu Standortdaten vernetzter Fahrzeuge¹² ist die sichtbarste kurzfristige regulatorische Entwicklung — ähnliche Leitlinien anderer EU-Datenschutzbehörden sind in den nächsten 12–24 Monaten wahrscheinlich. Die erste EU-Bußgeldentscheidung gegen einen Kfz-Versicherer speziell wegen seines Telematikprogramms ist keine Ob-Frage, sondern eine Wann-Frage. Programme, die Datenschutz schon jetzt als Produktdesign behandeln — die die Antworten auf die drei Fragen in Architektur und UX einbacken statt in AGB —, werden diejenigen sein, die unbeschadet bleiben, wenn dieser Vollzug landet.

→ Verwandtes: Datenschutz, Vertrauen und Telematik · Datenschutz in der Versicherungstelematik (Podcast) · Glossar: UBI, PAYD, PHYD.

Über den Autor

Harald Trautsch ist Mitgründer und CEO von Dolphin Technologies, dem Wiener Telematikunternehmen, das er 2001 gegründet hat — nach einem Jahrzehnt im Aufbau von Sicherheits- und Unfallerkennungssystemen für die Automobilindustrie. Eines dieser frühen Unfallerkennungsgeräte alarmierte die Rettungskräfte zu einem Paar, dessen Auto über eine Straßenböschung gerollt war; beide wurden geborgen. Der Vorfall hat Dolphins Richtung für die folgenden zwei Jahrzehnte gesetzt: Telematik als Werkzeug für Prävention und Hilfe, nicht nur für Tarifierung.

Zwischen 2008 und 2012 leitete Harald die internationale Marktentwicklung bei Octo Telematics und verhandelte im Auftrag des österreichischen Verkehrsministeriums die EU-eCall-Richtlinie in Brüssel — eine Arbeit, die mitgeprägt hat, wie Connected-Vehicle-Daten heute im europäischen Recht behandelt werden. Nach einem Management-Buy-out kehrte er 2014 zu Dolphin zurück und führt das Unternehmen seither international.

Er moderiert den Insurance Telematics Podcast, spricht regelmäßig auf europäischen Versicherungs- und Insurtech-Konferenzen und hat mit Versicherern wie Generali, Porsche Versicherung, Vienna Insurance Group und Kooperativa zusammengearbeitet.

LinkedIn: linkedin.com/in/trautsch

Quellen

1. Pew Research Center, „How Americans View Data Privacy“ (Oktober 2023) — Quelle
2. AutoInsurance.com, „Many Drivers Skip Auto Insurance Tracking Apps Over Privacy“ (2024) — Quelle
3. Bitkom, Connected-Car-Umfrage (Februar 2024) — Quelle
4. EDPB, Leitlinien 01/2020 zur Verarbeitung personenbezogener Daten im Kontext vernetzter Fahrzeuge (2021) — Quelle
5. Data Bridge Market Research, Europe Usage-Based Insurance Market Report (2024/2025) — Quelle
6. Gerber, N., Gerber, P., Volkamer, M. (2018), „Explaining the privacy paradox“ — Quelle
7. Capgemini Research Institute, „Monetizing Vehicle Data“ (2023) — Quelle
8. Johnson, E.J. & Goldstein, D. (2003), „Do Defaults Save Lives?“ Science 302 — Quelle
9. Consumer Federation of America / Consumer Reports Telematik-Studie (2024) — Quelle
10. Autohaus, „Bilanz 2024: HUK-Coburg hat jetzt 14 Mio. Fahrzeuge unter Vertrag“ (2025) — Quelle
11. EDPB, Leitlinien 01/2020, Abschnitt 1.5 (Zweckänderung von Telemetriedaten) — Quelle
12. Covington Inside Privacy, CNIL-Entwurf 2025 zu Standortdaten vernetzter Fahrzeuge — Quelle
13. Texas Attorney General Pressemitteilung, Paxton v. Allstate/Arity (Januar 2025) — Quelle
14. Insurance Journal zur Toyota/Progressive-Sammelklage (April 2025) — Quelle
15. Acquisti, A., Taylor, C.R., & Wagman, L. (2016), „The Economics of Privacy“, Journal of Economic Literature — Quelle
16. Martin, K. (2020), „Breaking the Privacy Paradox“, Business Ethics Quarterly — Quelle
17. Insurance Europe, Stellungnahme zur EDPB-Konsultation zu vernetzten Fahrzeugen (2020) — Quelle