Telematik-Bewertung des Fahrverhaltens & nutzungsbasierte Kfz-Versicherung

Herkömmliche Kfz-Tarife bepreisen Fahrer über Stellvertretermerkmale wie Alter, Postleitzahl und Fahrzeugtyp. Telematik misst, wie eine Person tatsächlich fährt. Sensoren im Telefon, ein kleiner Beacon, ein Plug-in-Gerät oder das Auto selbst liefern Fahrten; ML segmentiert die Fahrten, erkennt Ereignisse und verdichtet sie zu einem Risikowert, der sichere Fahrer mit einem Rabatt belohnt, riskante Fahrer coacht und Unfälle binnen Sekunden erkennt. Weil Standort- und Verhaltensdaten hochsensibel sind, ist das DSGVO-Design (Einwilligung, Pseudonymisierung, Verarbeitung auf dem Gerät) ebenso wichtig wie das Modell.

Problem & Nutzen

• Heute: Prämien werden aus statischen Tarifmerkmalen festgelegt (siehe PRED-010). Sichere junge Fahrer oder Wenigfahrer subventionieren andere; Fuhrparks erfahren von unsicherem Fahren erst nach Schäden; ein Schadenfall beginnt mit einem Anruf.
• KI-Nutzen: verhaltensbasierte Risikodifferenzierung (in der Erfahrung der Versicherer ein besserer Schadenprädiktor als statische Merkmale), Verhaltensrückmeldung, die riskantes Fahren verringert, schnellere Unfallbearbeitung und Kundenbindung zwischen den Vertragsverlängerungen.
• Vom Anbieter berichtete Effekte (nicht unabhängig geprüft): Cambridge Mobile Telematics (CMT) gibt auf seiner Website an, dass die DriveWell-Engage-Programme 20 % weniger abgelenktes Fahren, 9 % weniger hartes Bremsen und 5,5 % weniger Schäden mit Personenschaden bewirken, dass Fahrer mit Programmen bis zu 50 % bei der Kfz-Versicherung sparen können und dass DriveWell mehr als 100.000 Unfälle verhindern half [1]. Betrachten Sie dies als Marketingaussagen und prüfen Sie sie im eigenen Bestand mit einer Kontrollgruppe.
• Konkretes deutsches Tarifbeispiel: Telematik Plus der HUK-COBURG gewährt einen Startbonus von 5 % auf Haftpflicht und Kasko sowie einen fahrverhaltensabhängigen Folgebonus von bis zu 30 % pro Jahr; ein Wert von 0-100 wird aus Geschwindigkeit, Beschleunigung, Bremsen und Lenken gebildet, die erste Auswertung braucht mindestens zwei Monate und 20 Stunden Fahrzeit, und der Bonus kann nie negativ sein [2].

Varianten

• Pay-how-you-drive (PHYD) in der privaten Kfz-Versicherung: Wert → Rabatt bei Vertragsverlängerung (HUK-COBURG Telematik Plus [2], Allianz BonusDrive, das Telematik-Angebot von Generali mit Octo/Jeniot und viele Versicherer in Italien, Großbritannien, USA). In Deutschland/EU typischerweise nur Rabatt, damit schlechtes Fahren nicht direkt bestraft wird.
• Pay-as-you-drive / Preis pro Kilometer: Der Preis folgt Fahrleistung und Tageszeit; benötigt Kilometerstand oder Fahrtdaten.
• Programme für junge Fahrer und Fahranfänger: Rückmeldung an die Eltern, Ausgangssperren und Anreize nach dem Modell des Führerscheins auf Probe.
• Fuhrpark-Telematik (ohne Versicherung): Sicherheitscoaching, Fahrerranking und Versicherungsverhandlung für Logistik- und Firmenwagenflotten; die Mitbestimmung des Betriebsrats greift (siehe Risiken).
• Unfallerkennung & automatisierte Schadenmeldung (FNOL): Die Ereigniserkennung löst Notruf, Schadeneröffnung und Totalschaden-Triage aus (CMT DriveWell Crash/Claims [1]; Octo Crash and Claims Management [3]).
• OEM-/Connected-Car-Daten: Herstellerdaten, die mit Einwilligung des Fahrers über den EU Data Act und OEM-APIs genutzt werden, ohne zusätzliche Hardware.
• Private Nutzung: Fahrer können über eine kostenlose App oder die App des Versicherers einen Wert und Tipps erhalten; ein selbst gebautes Verbraucherprodukt ist darüber hinaus nicht sinnvoll.

So funktioniert es

1. Sensoren (Smartphone IMU+GPS | BLE-Beacon | OBD-Dongle | OEM-Signale)
2. Vorverarbeitung auf dem Gerät (Abtastung, Filterung, Fahrtbeginn/-ende, Kompression)
3. Upload (pseudonymisiert, WLAN oder Mobilfunk)
4. Stream-Aufnahme
5. Fahrtsegmentierung + Verkehrsmittel (Auto/Zug/Rad) + Erkennung Fahrer vs. Beifahrer
6. Map-Matching (Straßentyp, Tempolimit) + Ereigniserkennung (Bremsen, Kurvenfahrt, Ablenkung, Geschwindigkeitsüberschreitung)
7. Fahrtrisiko-Merkmale
8. Risikomodell (GBM/GLM kalibriert auf Schäden)
9. gleitender Fahrerwert
10. Tarifmaschine (Bonus/Prämie, Untergrenze bei 0 %) | Coaching-Feedback | Unfallalarm
11. Schadenerstmeldung
12. menschliche Prüfung von Streitfällen; aktuarielle Überwachung von Drift und Fairness

• Ereigniserkennung kombiniert physikalische Regeln und ML auf Beschleunigungs-/Gyroskopströmen; Ablenkung durch das Telefon nutzt Bildschirm- und Handhabungsereignisse des Betriebssystems. Neuere Anbietersysteme verwenden Sensor-Foundation-Modelle (CMT vermarktet DriveWell Atlas für Risiko, Unfallerkennung und Coaching [1]).
• Fahrer oder Beifahrer ist das schwierigste Labeling-Problem: Der Wert muss dem Versicherungsnehmer gehören, nicht demjenigen, der das Telefon getragen hat (Bus, Taxi, Beifahrersitz). Feste Beacons (HUK nutzt einen Windschutzscheibensensor, der mit der App gekoppelt ist [2]) lösen den größten Teil.
• Risikomodell: tabellarische Modelle (LightGBM, GLMs) auf aggregierten Merkmalen wie Ereignissen pro 100 km, Nachtanteil, Geschwindigkeitsüberschreitung und Fahrleistung; das Schadenziel ist dünn besetzt, daher mischen Versicherer Telematikwerte meist mit klassischen Merkmalen im Tarif (PRED-010).
• Mensch-in-der-Schleife (Human-in-the-Loop): Kundinnen und Kunden können Werte anfechten; Aktuare genehmigen die Abbildung von Wert auf Preis; die Schadenbearbeitung bestätigt bei schweren Fällen die durch einen Unfall ausgelöste Schadenmeldung.

Datenaufbereitung

Benötigte Daten: GPS-Spuren, Beschleunigungs- und Gyroskopsignale, OBD- oder Connected-Car-Signale, Fahrtmetadaten sowie bei Versicherern Policen-, Schaden- und Tarifdaten aus dem Bestandsführungssystem. Fuhrparks ergänzen Fahrzeugstammdaten aus Fuhrpark- oder ERP-Systemen und Fahrerzuordnungen aus dem Personalwesen. Typische Lücken sind verrauschtes oder fehlendes GPS, Sensoren mit unterschiedlicher Einbaulage, Telefone, die von Beifahrern genutzt werden, Fahrzeuge ohne Fahrerzuordnung, Schadendatensätze ohne verlässliche Unfall-Labels sowie über mehrere Systeme verstreute Einwilligungs- und Zweckangaben. Standortdaten sind personenbezogen und hochsensibel.

Schritte: (1) Quellen erfassen und dem Anwendungsfall zuordnen (PREP-001, PREP-002); (2) Schaden-, Policen- und Fuhrparkstammdaten per Export oder API holen (PREP-005); (3) Fahrten bereinigen (Map Matching, Kalibrierung der Einbaulage, Filterung von Beifahrern) in einer Streaming- oder Batch-Pipeline, zum Beispiel mit Python, Kafka und einer Zeitreihendatenbank; (4) Labels wie Schäden und harte Ereignisse aus vorhandenen Datensätzen gewinnen (PREP-020); (5) Fahrer-IDs pseudonymisieren und Rechtsgrundlage sowie Zweck prüfen (PREP-022, PREP-025). KMU, die ein Produkt kaufen, brauchen vor allem saubere Fahrer- und Fahrzeugstammdaten. Bei einer Eigenentwicklung entfallen etwa 30 bis 40 Prozent des Aufwands auf Datenarbeit, bei Weg A deutlich weniger. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU (Fuhrparkbetreiber): Weg A, weil ausgereifte, in der EU hostbare Fuhrpark-Telematik- und Fahrercoaching-Produkte zu KMU-Preisen existieren und der Prozess standardisiert ist.
• Unternehmen (Versicherer, große Fuhrparks): Weg C, weil das Bewertungsmodell zum Kern der Preisbildung gehört, Standortdaten hochsensibel sind und das Volumen Gebühren pro Fahrzeug oder API teuer macht.
• Entwickler: Weg C, weil Open-Source-Zeitreihen- und tabellarisches ML plus Map Matching volle Kontrolle über die Bewertungslogik geben.
• Privat (Fahrer): Weg A, weil Apps von Versicherern oder Fuhrparks und smartphonebasierte Werkzeuge für Einzelpersonen der einzig praktikable Weg sind.

Weg A — Kaufen (empfohlen für Fuhrparks und KMU)

• Telematikplattformen / Scoring-as-a-Service: Cambridge Mobile Telematics (DriveWell; USA/EU) [1], Octo Telematics (Italien; DriveAbility-Score, Unfall- und Schadenmanagement) [3], Sentiance (Belgien, EU) und Anbieter nach Art von Arity/Verisk außerhalb der EU. Prüfen: EU-Datenhaltung, Zugriff auf Rohdaten für Ihre Aktuare, Transparenz des Werts, Genauigkeit bei Fahrer/Beifahrer und wer Verantwortlicher oder Auftragsverarbeiter ist.
• Fuhrpark-Telematik: Webfleet (Bridgestone), Geotab, Samsara, Anbieter im Stil von Trackunit; Coaching und Anbindung des Fahrtenschreibers.
• A wählen, wenn: Sie Produktionsqualität in Monaten brauchen, kein Data-Science-Team für Sensor-ML haben oder ein MGA/kleiner Versicherer sind. Modellabhängigkeit und Intransparenz des Werts sind die wichtigsten Nachteile.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Mobile SDK + Cloud-Pipeline: SDK vom Anbieter oder aus eigener Entwicklung zur Sensorerfassung, Ingest über verwaltetes Streaming (Kinesis/Event Hubs/Pub/Sub oder Kafka) in EU-Regionen, Feature Store, verwaltetes ML (SageMaker, Azure ML, Vertex AI) für das Risikomodell.
• LLMs sind zweitrangig: Nutzen Sie allgemeine LLMs für kundenseitige Erklärungen der Werte, Coaching-Texte und die Zusammenfassung von Schadengesprächen, nicht für den Wert selbst.
• B wählen, wenn: Sie einen eigenen Wert und eigene Tariflogik wollen, aber keine On-Premises-Vorgabe besteht.

Weg C — Selbst betreiben (Open Source)

• Stack: Kafka (Apache-2.0) [7] für Streaming, Valhalla/Meili (MIT) [6] für Map Matching auf OpenStreetMap, MovingPandas (BSD-3) [5] für Trajektorienanalyse und Stopp-Erkennung, LightGBM (MIT) [4] oder scikit-learn für Risikomodelle, ONNX Runtime/Core ML/TFLite für Inferenz auf dem Gerät, PostgreSQL/TimescaleDB zur Speicherung.
• Hardware: überwiegend CPU (HW1); eine GPU nur, wenn Sie tiefe Sequenzmodelle für Ereigniserkennung oder Fahreridentifikation trainieren. Die eigentliche Ingenieursarbeit steckt im mobilen SDK (Akkuverbrauch, Hintergrundbeschränkungen des Betriebssystems).
• Aufwand: hoch; planen Sie ein Team mit Kompetenzen in Mobile, Daten und Versicherungsmathematik ein.

Weg D — Eigenes Training

• Lohnt sich für eigene Modelle zur Ereigniserkennung und zur Unterscheidung Fahrer/Beifahrer, Risikomodelle auf Fahrtebene, die mit eigenen, mit Telematik verknüpften Schäden trainiert werden, und die Schätzung des Unfallschweregrads. Erforderlich sind Monate an Fahrten für zehntausende Policen plus Schäden mit mehr als 12 Monaten Abwicklungszeit; gelabelte Unfallereignisse sind selten, nutzen Sie also synthetische/wiedergegebene Daten und Anbieter-Datensätze für das Vortraining.

Stand der Technik (2026)

• Smartphone-basierte Telematik hat dedizierte Geräte bei neuen Programmen weitgehend verdrängt; Hardware- Beacons bleiben wegen Genauigkeit und Fahreridentifikation (HUK-COBURG ist ein Beispiel [2]).
• Sensormodelle nach Art von Foundation-Modellen (z. B. CMTs DriveWell Atlas [1]) werden für Risiko, Unfallerkennung und personalisiertes Coaching eingesetzt; unabhängige öffentliche Benchmarks gibt es nicht, daher beruhen Leistungsangaben auf Daten von Anbietern und Versicherern.
• Engagement-Programme (Rückmeldung, spielerische Belohnungen) gelten inzwischen als Teil des Produkts, nicht nur der Bewertung; die oben genannten, vom Anbieter berichteten Effekte stammen daraus [1].
• Connected-Car-Daten über OEM-Schnittstellen und den EU Data Act (anwendbar seit September 2025) ermöglichen eine hardwarefreie Bewertung, wenn der Fahrer einwilligt; die Zugangsbedingungen unterscheiden sich je OEM.
• Grenzen und Fehlerbilder: Verwechslung von Fahrer und Beifahrer; Fehlalarme bei der Telefonnutzung; schlechtes GPS in Tunneln/Straßenschluchten; Ausfälle durch Akku und Berechtigungen des Betriebssystems; Selbstselektion (sichere Fahrer melden sich an), die den Effekt auf Portfolioebene verzerrt; Werte, die stellvertretend für Straßentyp oder Schichtarbeit stehen und dadurch indirekt diskriminieren; Manipulation des Werts; dünne Schadendaten, die die Validierung begrenzen.

Gemeinsame Bausteine & Kombinationen

• PRED-010 (Risikobepreisung in der Versicherung): Der Telematikwert wird zu einem Tarifmerkmal im gleichen Tarif- und Preismodul; teilt tabular-ml und causal-inference (Uplift des Coachings).
• PRED-037 (Schadenschwere & Reservierung) und durch Unfall ausgelöste FNOL; VIS-023 Schadenbewertung anhand von Fotos im Anschluss an die FNOL.
• VIS-028 (Fahrer- und Innenraumüberwachung): Kamerabasierte Fuhrparksicherheit ist ein ergänzendes, weitaus eingriffsintensiveres Signal und hat eigene rechtliche Grenzen.
• PRED-018 (Ankunftszeitprognose), PRED-041 (Gebrauchtfahrzeugbewertung aus der Nutzung), OPT-021 (Laden von E-Fahrzeugflotten) verwenden dieselbe Pipeline für Fahrten, GPS und Map Matching erneut.
• ANOM-003 (Versicherungsbetrug) kann Fahrtdaten nutzen, um die geschilderten Unfallumstände zu prüfen, sofern vertraglich vereinbart; ROBO-005 teilt die Modellierung von Fahrzeugsensoren.
• Gemeinsame Bausteine: Streaming-Ingest, Zeitreihen-Feature-Store, Map Matching auf OSM, Edge-Inferenz auf Telefonen (edge-runtime), Consent-Management-Plattform, Pseudonymisierungsdienst. Die Hardware bleibt bei all dem HW1.

Aufwand, Kosten & Kennzahlen

• Weg A: 3-6 Monate einschließlich App-Branding, Tarifgenehmigung und Einwilligungsabläufen; SaaS-Gebühren je aktivem Fahrer.
• Weg B: 6-12 Monate; die Kosten entstehen durch SDK-Entwicklung, Cloud-Streaming/-Speicher und Mobile-Support.
• Weg C/D: 12+ Monate und ein eigenes Team; bei großen Beständen gerechtfertigt.
• Kostentreiber: SDK-Pflege über iOS-/Android-Versionen hinweg, Support bei Berechtigungs- und Akkuproblemen, Geräte und Versand (bei Beacons), Speicherung hochfrequenter Daten.
• Kennzahlen: Anmelde- und Bindungsquote, Schadenquote der bewerteten gegenüber einer passenden unbewerteten Kontrollgruppe, Gini/Lift von Wert zu Schäden, Genauigkeit Fahrer/Beifahrer, Precision/Recall der Unfallerkennung und Zeit bis zur Schadenmeldung, Veränderung der Ablenkungs- und Hartbremsereignisse pro 100 km, Beschwerde-/Einspruchsquote.

Menschen & Veränderung

Geschäftsleitung und Abteilungsleitung (Fuhrparkleitung, Underwriting) legen Ziele und Grenzen fest; die IT bindet Fahrzeuge und Apps an; die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte wird früh gebraucht, weil Standortdaten personenbezogen sind und oft Verhalten offenlegen. Eine DSFA (Art. 35 DSGVO) ist wahrscheinlich (systematische Überwachung, neue Technologie in großem Umfang), dazu ein AVV mit dem Telematikanbieter (Art. 28). Betriebsrat: kommt darauf an. Bei Fuhrparks mit angestellten Fahrern ist das System eindeutig geeignet, Verhalten und Leistung zu überwachen; daher gilt die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG, und eine Betriebsvereinbarung ist nötig (kein individuelles Ranking, begrenzte Speicherdauer, keine Nutzung für Kündigungen); bei Versicherern gilt sie für interne Werkzeuge, die Tätigkeiten der Beschäftigten protokollieren. Unterrichten Sie den Betriebsrat früh nach § 90 Abs. 1 Nr. 3.

KI-Kompetenz: Die KI-Verordnung (Art. 4) verlangt Maßnahmen zur Förderung der Kompetenz der Beschäftigten; schulen Sie Fuhrparkleitung und Underwriter dazu, was ein Wert bedeutet und wo seine Grenzen liegen. Kommunizieren Sie offen, was gemessen wird und warum, wählen Sie eine Pilotgruppe freiwilliger Fahrer und stellen Sie Coaching statt Bestrafung in den Vordergrund. Typische Bedenken: Überwachung (Datenumfang festlegen, dem Fahrer seine eigene Sicht zeigen), unfaire Werte (Einspruchsweg). Halten Sie bei Konsequenzen einen Menschen in der Schleife. Siehe GUIDE-004, GUIDE-005, GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Anhang III Nr. 5 Buchst. c führt KI zur Risikobewertung und Preisbildung für natürliche Personen in der Lebens- und Krankenversicherung als hochriskant auf [8]; die Kfz-Versicherung wird dort nicht genannt, daher ist ein Kfz-Telematikwert in der Regel nicht hochriskant, die Einstufung hängt aber von der Verwendung ab (z. B. wenn der Wert in die Preisbildung der Lebens-/Krankenversicherung einfließt oder zur Bewertung von Beschäftigten genutzt wird, was unter die Hochrisiko-Regeln für Beschäftigung fällt). Art. 5 verbietet Social Scoring und bestimmte manipulative Praktiken; vermischen Sie Fahrwerte nicht mit sachfremden Verhaltensdaten. Kamerabasierte Emotionserkennung in Fuhrparks am Arbeitsplatz ist verboten (siehe VIS-028). Die KI-Kompetenz (Art. 4) gilt.
• DSGVO / ePrivacy: Standort- und Fahrtdaten sind personenbezogene Daten und sehr aufschlussreich. Die EDSA-Leitlinien 01/2020 zu vernetzten Fahrzeugen verlangen eine wirksame Einwilligung oder eine andere Rechtsgrundlage, Zweckbindung, Datenminimierung, möglichst lokale Verarbeitung und stellen klar, dass für andere Zwecke erhobene Telemetriedaten ohne Einwilligung des Nutzers nicht zum Fahrerprofiling an Versicherer weitergegeben werden dürfen [9]. Das Auslesen von Gerätesensoren löst zudem ePrivacy Art. 5 Abs. 3 aus. Eine DSFA (Art. 35) wird erwartet; Vereinbarungen über gemeinsame Verantwortliche zwischen Versicherer und Plattformanbieter müssen dokumentiert werden (Art. 26) [9].
• Automatisierte Entscheidungen: Ein Wert, der einen Preis festlegt, kann unter Art. 22 DSGVO fallen; sorgen Sie für menschliche Prüfung, Einspruchsmöglichkeiten und eine aussagekräftige Erläuterung. Das Design der HUK-COBURG (pseudonymisierte Daten, Versicherer ohne Zugriff auf Rohfahrten, kein negativer Bonus) ist ein Beispiel für eine datenschutzfreundliche Ausgestaltung [2].
• Versicherungsaufsicht: Tarifänderungen brauchen eine versicherungsmathematische Begründung; vermeiden Sie indirekte Diskriminierung (geschlechtsneutrale Preise seit dem Test-Achats-Urteil) und halten Sie Unterlagen für die Prüfung durch BaFin/EIOPA vor.
• Beschäftigung: Die Bewertung von Beschäftigten im Fuhrpark erfordert eine Vereinbarung mit dem Betriebsrat (§ 87 BetrVG in Deutschland) und klare Regeln zur privaten Nutzung.
• Gegenmaßnahmen: Opt-in mit Design ohne Nachteile, Verarbeitung der Rohdaten auf dem Gerät, kurze Speicherdauer für rohes GPS, Kontrollen zur Fahreridentifikation, regelmäßige Fairness- und Drift-Prüfungen, Einspruchsweg mit menschlicher Prüfung.

Erste Schritte

1. Das Produkt festlegen: PHYD nur mit Rabatt, kilometerbasiert, für junge Fahrer oder Fuhrparkcoaching, und mit der Rechtsabteilung Rechtsgrundlage, DSFA und Verantwortlichkeitsrollen abstimmen.
2. Einen Anbieter-Pilot (CMT, Octo, Sentiance oder ein Fuhrparkanbieter) mit 1.000-5.000 Freiwilligen und einer passenden Kontrollgruppe durchführen; Zugriff auf Rohmerkmale und Genauigkeitswerte für Fahrer/Beifahrer verlangen.
3. Werte über mindestens ein volles Versicherungsjahr mit Schäden verknüpfen und die Abbildung von Wert auf Tarif gemeinsam mit Aktuaren kalibrieren (Untergrenze bei null Nachteil, wenn Sie ein verbraucherfreundliches Design wollen).
4. Einwilligungs-, Widerrufs- und Einspruchsabläufe vor dem Start in die App einbauen.
5. Unfallerkennung / FNOL erst ergänzen, nachdem die Fehlalarmraten in Ihrer Population gemessen wurden.

Quellen

1. Cambridge Mobile Telematics — DriveWell products and results (accessed 2026-10) — https://www.cmtelematics.com/
2. HUK-COBURG — Telematik Plus tariff description (accessed 2026-10) — https://www.huk.de/fahrzeuge/kfz-versicherung/telematik-plus.html
3. Octo Telematics — OCTO Motor Insurance, DriveAbility, crash and claims management (accessed 2026-10) — https://www.octotelematics.com/
4. LightGBM (MIT) — https://github.com/microsoft/LightGBM
5. MovingPandas (BSD-3) — https://github.com/movingpandas/movingpandas
6. Valhalla routing engine with Meili map matching (MIT) — https://github.com/valhalla/valhalla
7. Apache Kafka (Apache-2.0) — https://github.com/apache/kafka
8. EU AI Act Annex III (point 5 essential services) — https://artificialintelligenceact.eu/annex/3/
9. EDPB Guidelines 01/2020 on connected vehicles and mobility-related applications — https://www.edpb.europa.eu/system/files/documents/2021-03/edpb_guidelines_202001_connected_vehicles_v2.0_adopted_en.pdf
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj