Autonomes Fahren und Datenschutz – Wer weiss, wohin die Reise geht?

19. März 2026

Automatisierte Fahrzeuge sind rollende Rechenzentren. Sie sammeln, bearbeiten und übermitteln unentwegt riesige Datenmengen, um sicher navigieren zu können. Diese Entwicklung wirft grundlegende Fragen auf: Welche Daten werden erfasst? Wer hat Zugriff? Und zu welchem Zweck? In diesem dritten Teil unserer Blogserie beleuchten wir die datenschutzrechtlichen Herausforderungen des autonomen Fahrens gemäss dem schweizerischen Recht.

I. Das Fahrzeug als Datensammler

A. Von welchen Daten sprechen wir?

Um die datenschutzrechtlichen Implikationen zu verstehen, ist ein grundlegendes Verständnis der im Rahmen des Betriebs eines automatisierten Fahrzeugs anfallenden Daten unerlässlich. Auch wenn sich die konkret gesammelten Daten von Hersteller zu Hersteller oder sogar von Modell zu Modell sowie nach dem Level der Automatisierung (vgl. dazu den einführenden Beitrag dieser Serie) unterscheiden mögen, können die häufig vorkommenden Daten in folgende Kategorien unterteilt werden:

• Umgebungsdaten: Ein automatisiertes Fahrzeug nimmt seine Umgebung durch eine Vielzahl von Sensoren wahr, unter anderem durch Kameras, Light Detection and Ranging (LiDAR), Radar sowie GPS. Anhand dieser Daten erstellt das Fahrzeug bzw. das dahinterstehende System ein kohärentes Umgebungsmodell und kann Fahrentscheidungen treffen. Das Fahrzeug weiss somit zu jeder Zeit, wo es sich räumlich befindet, welche Strassen es nehmen muss, um das anvisierte Ziel zu erreichen, mit welcher Geschwindigkeit es dabei fahren darf und kann aber auch auf unvorhergesehene Situationen adäquat reagieren (z. B. Bremsmanöver, um eine Kollision mit einem anderen Verkehrsteilnehmer zu verhindern).
• Diagnosedaten: Hierbei handelt es sich um technische Informationen über den Betriebszustand und die Funktionsfähigkeit der Fahrzeugkomponenten. Interne Sensoren und Steuergeräte überwachen laufend den Zustand des Fahrzeugs. Beispiele hierfür sind nicht nur der Reifendruck oder der Batteriestatus, sondern auch Daten wie die Motor- und Getriebetemperatur, der Zustand der Bremsbeläge, Softwareversionen der Steuergeräte oder Fehlermeldungen des Bordcomputers (sog. Diagnostic Trouble Codes). Diese Daten werden primär zur Gewährleistung der Fahrzeugsicherheit und der vorausschauenden Wartung erhoben. Sie dienen aber auch dem Hersteller zur Produktverbesserung sowie zur Abwicklung von Gewährleistungs- und Haftungsfällen.
• Daten der Insassen: Diese Kategorie umfasst Daten, die durch Innenraumsensoren über den physischen Zustand und das Verhalten der Fahrzeuginsassen, insbesondere des Fahrers, gesammelt werden. Beispiele sind Aufnahmen von Innenraumkameras zur Überwachung der Aufmerksamkeit und des Lidschlags des Fahrers (Müdigkeitserkennung) oder Daten von Sitzbelegungssensoren zur Optimierung der Airbag-Auslösung. Ergänzend hierzu werden physiologische Messwerte und Umgebungsdaten im Innenraum erhoben, beispielsweise um die Sitzklimatisierung (Heizung, Kühlung, Trocknung) automatisiert zu steuern. Der Hauptzweck dieser Datenerhebung liegt in der Erhöhung der Fahrsicherheit, indem das System bei nachlassender Aufmerksamkeit des Fahrers warnen oder in Notsituationen (z.B. bei einem medizinischen Notfall) eingreifen kann. Ferner dienen sie der Personalisierung von Fahrzeugeinstellungen, der Steigerung des Insassenkomforts und der Unfallanalyse.
   

B. Sind diese Daten Personendaten?

Nach dem schweizerischen Datenschutzgesetz (DSG) sind Personendaten "alle Angaben, die sich auf eine bestimmte oder bestimmbare natürliche Person beziehen" (Art. 5 lit. a DSG).

Bei einigen Daten, wie in der Regel bei jenen über die Insassen, ist dieser Personenbezug ohne Weiteres gegeben. Daten der Müdigkeitserkennung beziehen sich direkt auf den Fahrer und auch Aufnahmen von Innenraumkameras, die das Gesicht oder Verhalten des Fahrers und der weiteren Passagiere zeigen, sind ebenfalls unzweifelhaft Personendaten.

Jedoch können selbst fahrzeugbezogene Daten, abhängig von der Zuordenbarkeit zu einer natürlichen Person und dem Verwendungszweck, zu Personendaten werden.

• Der zentrale Ankerpunkt für die Zuordenbarkeit ist in der Regel die eindeutige Fahrzeug-Identifikationsnummer (FIN). Obwohl die FIN selbst nur ein Fahrzeug identifiziert, können diverse Akteure wie Fahrzeughersteller, Importeure, Garagen, Versicherungen oder staatliche Behörden (z.B. Strassenverkehrsämter) sie regelmässig dem Fahrzeughalter zuordnen. Werden nun fahrzeugbezogene Daten, wie insbesondere die beschriebenen Diagnosedaten, im Kontext einer FIN erhoben, können sie damit nicht mehr nur dem Fahrzeug selbst, sondern auch dem Halter zugeordnet werden.
• Zusätzlich müssen aus den Daten Angaben über eine natürliche Person abgeleitet werden können. Zwar sind Fehlermeldungen oder die Angabe über den Reifendruck primär keine Informationen über eine natürliche Person. Allerdings können sie, in Kombination mit der FIN, verwendet werden, um das Verhalten des Fahrers im Strassenverkehr zu analysieren. Ein erhöhter Verschleiss der Bremsbeläge oder häufige Fehlermeldungen können beispielsweise auf einen aggressiven Fahrstil hindeuten. Hier zeigt sich die Relevanz der Unterscheidung zwischen Fahrzeughalter und Fahrer: Obwohl die Daten über die FIN primär dem Halter zugeordnet werden, beziehen sich die Verhaltensinformationen auf jene Person, die das Fahrzeug lenkt. Spätestens wenn es in einem solchen Fall um Garantie- oder Haftungsfälle geht, werden diese technischen Daten direkt mit dem Fahrzeughalter oder eben dem Fahrer in Verbindung gebracht, wobei die korrekte Zuordnung entscheidend ist.

Diese Beispiele zeigen, dass selbst bei fahrzeugbezogenen Informationen, die einer FIN oder einem ähnlichen Identifikator zugeordnet werden können, davon ausgegangen werden muss, dass sie potenziell dazu verwendet werden können, um Aussagen über den Halter oder eine andere natürliche Person zu machen, und daher als Personendaten zu qualifizieren sind.

C. Der Fahrmodusspeicher

Das Schweizer Strassenverkehrsgesetz (SVG) schreibt in Art. 25e Abs. 2 vor, dass Fahrzeuge mit einem Automatisierungssystem (gemeint sind damit Society of Automotive Engineers (SAE) Level 3–5; vgl. Dazu den einführenden Blog dieser Serie) mit einem Fahrmodusspeicher ausgerüstet sein müssen. Dieser Fahrmodusspeicher muss bestimmte sicherheitsrelevante Ereignisse aufzeichnen (z.B. Beginn und Ende eines Notfallmanövers, Zusammenstösse oder die Durchführung eines Manövers zur Risikominimierung), wobei die Art des Ereignisses und der allfällige Grund, das Datum, die Zeit und, bei führerlosen Fahrzeugen, die Position des Fahrzeugs dokumentiert werden müssen (Art. 7 Abs. 4 Verordnung über das automatisierte Fahren, VAF).

Eine Aufzeichnung erfolgt nur, während das Automatisierungssystem aktiviert ist, also wenn das Fahrzeug im autonomen Betrieb ist und die relevanten Fahrentscheidungen eigenständig "trifft". Der Fahrmodusspeicher darf in dieser Zeit aber nicht deaktiviert werden können (Art. 25f Abs. 1 SVG). Keine Aufzeichnung erfolgt jedoch, wenn das Fahrzeug vom Fahrer manuell bedient wird. Zugriff auf die Daten des Fahrmodusspeichers haben in erster Linie der Fahrzeughalter (über eine standardisierte Schnittstelle) sowie die zuständigen Polizei-, Justiz- und Administrativbehörden, wobei gesetzlich geregelt ist, für welche Zwecke sie diese Daten bearbeiten dürfen (Art. 25g SVG i.V.m. Art. 18 VAF). Das Zugriffsrecht des Fahrzeughalters unterliegt dabei einer spezifischen Einschränkung: Auf Daten, die während Fahrten von Dritten gespeichert wurden, darf er ohne deren Zustimmung nur zugreifen, soweit er an diesen Daten ein berechtigtes Interesse im Zusammenhang mit einem Unfall oder einer Widerhandlung gegen die Strassenverkehrsvorschriften geltend machen kann (Art. 25g Abs. 1 SVG).

Die Aufzeichnungen des Fahrmodusspeichers dienen somit primär der Dokumentation der Leistungen des Automatisierungssystems in sicherheitsrelevanten Momenten. Sie zeichnen auf, wie das Automatisierungssystem gehandelt hat, nicht jedoch das Fahrverhalten oder die Fahrentscheidungen des Fahrers (da dieser zum Zeitpunkt des aufgezeichneten Ereignisses das Fahrzeug nicht kontrollierte). Entsprechend sind diese Daten regelmässig nicht als Personendaten zu qualifizieren, selbst wenn bekannt ist, wer sich zum Zeitpunkt des sicherheitsrelevanten Ereignisses im Fahrzeug befunden hat. Hiervon bestehen aber auch Ausnahmen:

• Die aufgezeichnete Position des (führerlosen) Fahrzeugs zum Zeitpunkt des aufgezeichneten Ereignisses kann Aufschluss über den Standort der Passagiere geben, sofern deren Identität bekannt ist (was häufig der Fall sein wird, denn z. B. wird der Betreiber eines Robotaxis in der Regel wissen, wer zu diesem Zeitpunkt Gast war). Immerhin wird dies aber in der Regel keine Information sein, über welche der Fahrzeughalter nicht bereits Kenntnis hat.
• Bei Fahrzeugen mit Übernahmeaufforderung (diese verfügen über ein Automatisierungssystem, welches den Fahrer informiert, wenn es an die Grenzen seines Einsatzbereichs gelangt, also nicht mehr autonom agieren kann, z.B. Highway-Pilot; vgl. Art. 2 VAF) zeichnet der Fahrmodusspeicher diverse Ereignisse auf, die direkte Rückschlüsse auf das Verhalten der Fahrer zulassen. So zum Beispiel, wenn der Fahrer das Automatisierungssystem in bestimmten Situationen übersteuert oder wenn eine Übernahmeaufforderung ausgelöst wird, weil der Fahrer nicht verfügbar, nicht anwesend oder nicht angegurtet ist (Art. 24 Bst. c Ziff. 3 und 4 VAF). Auch hier gilt: Spätestens, wenn diese Daten zur Klärung der Verantwortlichkeiten im Rahmen eines Administrativ- oder Strafverfahrens (Art. 25g SVG) oder bei der Geltendmachung von Versicherungsansprüchen verwendet werden, werden sie mit einer natürlichen Person in Verbindung gebracht.

Für zugriffsberechtigte Personen, insbesondere Fahrzeughalter und Behörden, entsteht durch den Fahrmodusspeicher eine komplexe Datenlage: Sie erhalten Zugriff auf ein Bündel von Daten, von denen einige klar als reine Sachdaten, andere jedoch als Personendaten zu qualifizieren sind. Aufgrund dieser Vermischung und der Schwierigkeit, die Daten im Einzelfall trennscharf zu qualifizieren, ist eine sorgfältige datenschutzrechtliche Beurteilung unerlässlich.

In unserem fiktiven Sachverhaltsbeispiel (vgl. den einführenden Beitrag dieser Serie) würde der Fahrmodusspeicher somit mindestens den Zusammenstoss mit dem Fahrzeug von Herrn Grünlich sowie voraussichtlich auch den sicherheitsrelevanten Systemfehler, ausgelöst durch das fehlerhafte Update, jeweils mit Zeitstempel und der Position des Fahrzeugs, aufzeichnen. Diese Aufzeichnung wäre ein zentrales Beweismittel, um die Fehlerhaftigkeit des Automatisierungssystem der CodeDrive Solutions Inc. nachzuweisen.

II. Wer sitzt am Steuer? Die Verantwortlichkeiten im Datenverkehr

A. Die Frage nach dem "Herr der Daten"

Angesichts der Datenmengen, die in einem automatisierten Fahrzeug zu unterschiedlichen Zwecken erhoben und bearbeitet werden, stellt sich die im Datenschutzrecht sehr bedeutende Frage der Zurechnung: Wer ist eigentlich dafür verantwortlich, dass diese Daten im Einklang mit den datenschutzrechtlichen Vorgaben bearbeitet werden?

Im datenschutzrechtlichen Kontext automatisierter Fahrzeuge blicken wir auf ein komplexes Geflecht aus verschiedenen Akteuren, unter anderem bestehend aus Fahrzeughersteller, Fahrzeughalter, Software- und Komponentenlieferanten und den Fahrzeugnutzern. Wenn das Fahrzeug entscheidet, wie es wohin fährt und von wem dabei Daten erhoben werden, wer ist dann der "Herr dieser Daten"?

B. Das gesetzliche Konzept: Wer entscheidet, ist verantwortlich

Das DSG knüpft die Verantwortung nicht an das Eigentum oder die Nutzung des Fahrzeugs, sondern an die Entscheidungsgewalt über die Bearbeitung von Daten. Es differenziert dabei zwischen folgenden beiden datenschutzrechtlichen Rollen:

• Verantwortlicher (Controller): Gemäss DSG ist der Verantwortliche jene private Person oder das Bundesorgan, das "allein oder gemeinsam mit anderen über den Zweck und die Mittel der Bearbeitung entscheidet". Der Verantwortliche ist damit die zentrale Figur im Datenschutz: Er hat insbesondere sicherzustellen, dass die gesetzlich vorgegebenen Grundsätze bei der Datenbearbeitung eingehalten werden, ihm obliegen die Informationspflichten bezüglich der Beschaffung und Bearbeitung von Personendaten, und er ist es, an den Auskunftsbegehren betroffener Personen gerichtet werden können.
• Auftragsbearbeiter (Processor): Demgegenüber steht der Auftragsbearbeiter. Er bearbeitet Personendaten nur im Auftrag und nach Weisung des Verantwortlichen; er ist der "verlängerte Arm" des Verantwortlichen. Entscheidend dabei: Der Auftragsbearbeiter darf die Daten nicht für eigene Zwecke nutzen. Tut er es doch, wird er selbst zum Verantwortlichen.

Die Abgrenzung ist in der Praxis oft schwierig. Entscheidend ist, wer die wesentlichen Parameter, insbesondere den Zweck und die Mittel der Datenbearbeitung, festlegt. Wer hat die Datenbearbeitung veranlasst, bestimmt das "Warum" und damit den eigentlichen Zweck der Bearbeitung?  Wer entscheidet, welche Daten gesammelt werden, ob und wie diese gespeichert werden und welche Systeme auf sie zugreifen können? Die Antworten auf diese Fragen bestimmen, wer als datenschutzrechtlich verantwortlich gilt.

C. Akteure im Ökosystem des automatisierten Fahrzeugs

Spätestens wenn wir dieses Konzept auf die Realität des automatisierten Fahrens anwenden, löst sich die Illusion auf, es gäbe nur einen Verantwortlichen. Wir haben es mit einem Netzwerk von Akteuren zu tun, die oft gleichzeitig und parallel Daten bearbeiten. Folgende Beispielkonstellationen veranschaulichen dies (vgl. für den Beispielsachverhalt den einführenden Beitrag dieser Serie):

• Fahrzeughersteller: Der Hersteller (die "Sentinel Motors Corp.") ist in der Regel nicht bloss ein Lieferant von Hardware. Bei modernen, vernetzten Fahrzeugen bleibt er tief in die Datenbearbeitung involviert. Er definiert in der Regel, welche Sensoren verbaut sind und welche Daten diese wie erfassen. Er nutzt Diagnosedaten regelmässig zur Entwicklung oder Verbesserung seiner Produkte, wird sie bei Bedarf aber auch zur Abwehr von Haftungsansprüchen heranziehen. Da der Hersteller dabei über das "Ob" und "Wie" dieser Datenbearbeitungen entscheidet und diese oft eigenen Zwecken (z.B. Forschung, Entwicklung, Qualitätssicherung) dienen, ist er in Bezug auf diese Bearbeitungstätigkeiten Verantwortlicher. Er ist kein Auftragsbearbeiter des Fahrzeughalters, da er nicht weisungsgebunden agiert – der Halter schreibt dem Hersteller nicht vor, wie er seine Algorithmen zu trainieren hat.
• Fahrzeughalter / Flottenbetreiber: In unserem Beispielsachverhalt ist dies die "Innovate Mobility AG". Sie betreibt die Shuttles, um Personen zu transportieren. Sie entscheidet, dass die Fahrzeuge auf bestimmten Routen fahren und dabei Daten erfassen. Sie wird bestimmte Daten für das Flottenmanagement, die Abrechnung und die Sicherheit der Passagiere nutzen. Bei den damit zusammenhängenden Bearbeitungen von Personendaten ist damit auch die Innovate Mobility AG Verantwortliche: Sie bestimmt den Zweck (Personentransport, Flottensteuerung) und nutzt die Fahrzeuge als Mittel dazu. Dass sie die technische Infrastruktur (das Fahrzeug) nicht selbst gebaut hat, ändert daran nichts, denn sie entscheidet über deren Einsatz. Soweit die vom Fahrmodusspeicher aufgezeichneten Daten Personendaten darstellen – etwa, weil sie Rückschlüsse auf die Position eines Passagiers zum Zeitpunkt eines sicherheitsrelevanten Ereignisses zulassen –, ist der Halter/Flottenbetreiber für deren Bearbeitung im Rahmen seiner Zugriffsbefugnisse ebenfalls datenschutzrechtlich verantwortlich.
• Lenker: Der Fahrzeuglenker ist in erster Linie die betroffene Person, deren Daten bearbeitet werden. Er kann nicht zum Verantwortlichen für die Bearbeitung seiner eigenen Fahr- oder Verhaltensdaten werden. Allerdings kann der Lenker (anders als beispielsweise ein reiner Passagier) in gewissen Konstellationen durch seine Handlungen selbst zum (Mit-)Verantwortlichen werden. Dies ist der Fall, wenn er aktiv über die Bearbeitung von Daten Dritter bestimmt, beispielsweise indem er eine Innenraumkamera, welche auch die anderen Passagiere filmt, aktiviert.
• Software- und Komponentenlieferant: Unternehmen, die Kamerasysteme, LiDAR-Sensoren oder Infotainment-Software entwickeln, definieren oft die technischen Spezifikationen der Datenerfassung ihrer Bauteile. Wenn die damit verbundenen Datenbearbeitungen (auch) eigenen Zwecken dieser Lieferanten dienen, werden sie ebenfalls zu Verantwortlichen. Dies zeigt sich in zwei Szenarien des Beispielsachverhalts:
  • Szenario A (Auftragsbearbeiter): Soweit die "CodeDrive Solutions Inc." beispielsweise Fehlercodes im Auftrag der Innovate Mobility AG extrahiert und aufbereitet, ohne die Daten für eigene Zwecke (z.B. Training eigener KI-Modelle) zu nutzen, agiert sie als Auftragsbearbeiterin.
  • Szenario B (Verantwortlicher): In der Praxis dürften Softwareanbieter jedoch oft sicherstellen wollen, Realdaten aus dem Fahrbetrieb zu nutzen, insbesondere, um ihre Algorithmen weiterentwickeln zu können. Sobald CodeDrive beispielsweise die Daten des Unfalls (z.B. Aufzeichnungen der Bildsensoren der roten Ampel) nutzt, um ihre Bilderkennungssoftware generell zu verbessern (und nicht nur, um den Bug für Innovate Mobility zu beheben), tut sie dies für einen eigenen Zweck. Damit wird sie zur (Mit-)Verantwortlichen.
• Anbieter von Drittdiensten: Beispielsweise sind App-Anbieter im Infotainment-System (z.B. für Musik-Streaming oder Parkplatzsuche) oder Versicherungen mit "Pay-as-you-drive"-Tarifen für die Daten, die sie über ihre eigenen Dienste erheben, in der Regel selbst die Verantwortlichen.
• Garagen und Wartungsbetriebe: Für die Bearbeitung von Personendaten im Rahmen eines Reparatur- oder Serviceauftrags wird die Garage in der Regel Verantwortliche sein. Im Zusammenhang mit automatisierten Fahrzeugen ist etwa an die Bekanntgabe von Diagnosedaten an den Hersteller zu denken, beispielsweise für Garantieabwicklungen.
   

D. Spannungsfeld der gemeinsamen Verantwortlichkeit

Das komplexe Zusammenspiel der verschiedenen Akteure führt dazu, dass die klare Zuweisung einer alleinigen Verantwortlichkeit oft nicht möglich ist. Stattdessen muss im Einzelfall geprüft werden, ob eine gemeinsame Verantwortlichkeit (Joint Controllership) vorliegt oder ob mehrere Akteure als je eigenständige, alleinige Verantwortliche für unterschiedliche Bearbeitungsschritte agieren.

Eine gemeinsame Verantwortlichkeit entsteht, wenn mehrere Akteure gemeinsam über die Zwecke und Mittel einer Datenbearbeitung entscheiden. Dies kann insbesondere bei der initialen Datenerhebung der Fall sein, wo die Interessen von Hersteller, Softwarelieferant und Flottenbetreiber oft untrennbar miteinander verknüpft sind. So kann beispielsweise die technische Ausgestaltung der Sensoren durch den Hersteller direkt den Zwecken des Flottenbetreibers (z.B. Routenoptimierung) und des Softwareanbieters (z.B. Algorithmentraining) dienen. In solchen Konstellationen, in denen die Bearbeitungen für die Erreichung der jeweiligen Ziele untrennbar sind, ist eine gemeinsame Verantwortlichkeit naheliegend.

Liegt eine gemeinsame Verantwortung vor, so hat dies insbesondere aus Vertrags- und Haftungssicht Folgen. Zwar verlangt das DSG, anders als die im Europäischen Wirtschaftsraum geltende Datenschutz-Grundverordnung (EU-DSGVO), keinen formalen Vertrag bei gemeinsamer Verantwortlichkeit. Entsprechende Vereinbarungen werden unter den gemeinsamen Verantwortlichen dennoch üblich sein – sei es, weil die Akteure selbst oder bestimmte Datenbearbeitungen der EU-DSGVO unterliegen und die Akteure deshalb ohnehin zu vertraglichen Regelungen verpflichtet sind, sei es, weil die Akteure die Zuständigkeiten und Verantwortlichkeiten untereinander ausdrücklich regeln wollen, auch ohne dazu verpflichtet zu sein. Das ist in aller Regel sinnvoll, denn gegenüber der betroffenen Person (z.B. dem Unfallopfer) haften grundsätzlich alle involvierten Verantwortlichen, wenn eine Persönlichkeitsverletzung vorliegt.

Im Aussenverhältnis sind die gemeinsamen Verantwortlichen demnach für die gesamte (gemeinsame) Datenbearbeitung solidarisch verantwortlich. Dies gilt mitunter auch hinsichtlich der Pflicht, betroffene Personen über die Beschaffung und Bearbeitung ihrer Daten zu informieren, und auf Anfrage weitere Auskünfte darüber zu erteilen. Eine betroffene Person kann sich also z.B. in Bezug auf ihr Auskunftsrecht an jeden der gemeinsam verantwortlichen Akteure wenden, und es ist deren Sache, entsprechende Betroffenenanfragen intern zu koordinieren und zu beantworten.

Dies gilt auch für diverse Bearbeitungstätigkeiten im Sachverhaltsbeispiel: Soweit beispielsweise die Innovate Mobility AG als Fahrzeughalter und die Sentinel Motors Corp. als Fahrzeughersteller beide ein Interesse an bestimmten Fahrdaten haben (der eine für das Flottenmanagement, der andere für die Fahrzeugdiagnose) und die technische Infrastruktur so ausgestaltet ist, dass die Daten automatisch an beide fliessen, liegt eine gemeinsame Verantwortlichkeit nahe – mitsamt der hiervor beschriebenen Konsequenzen.

Gleichwohl ist dies nicht für sämtliche Datenbearbeitungen der Fall. Häufig liegen auch parallele, aber getrennte Verantwortlichkeiten vor: So kann der Hersteller für die Nutzung von Diagnosedaten zur Produktverbesserung allein verantwortlich sein, während der Flottenbetreiber die alleinige Verantwortung für die Nutzung derselben Daten zur Abrechnung mit dem Passagier trägt. Die Vorstellung vom "einen" Verantwortlichen für das gesamte Ökosystem ist zwar unzutreffend; die Analyse muss jedoch differenziert erfolgen und kann je nach Bearbeitungszweck zu unterschiedlichen Ergebnissen führen.

Für den Fahrzeuglenker, einen Passagier (wie Linda Pünktlich) oder involvierte Dritte (wie das Unfallopfer Herr Grünlich) sind die tatsächlichen Verantwortlichkeiten oft undurchsichtig. Datenschutzrechtliche Vorgaben versuchen diesem Umstand insofern Rechnung zu tragen, als der Begriff des Verantwortlichen weit gefasst wird: Jeder, der einen entscheidenden Einfluss auf die Datenbearbeitung hat, kann grundsätzlich datenschutzrechtlich in die Pflicht genommen werden. 

III. Grünes Licht für die Bearbeitung der Daten – Was muss beachtet werden?

Die bisher behandelten Fragen nach anfallenden Daten und den Verantwortlichkeiten hinsichtlich der Bearbeitungstätigkeiten sind im Kontext automatisierter Fahrzeuge durchaus komplex. Im Grunde sind es jedoch typische datenschutzrechtliche Fragestellungen, wie sie sich im Zusammenhang mit datengetriebenen Innovationen stellen. Dies gilt ebenso für die folgende Auswahl an weiteren datenschutzrechtlichen Themenfeldern:

• Die Vielzahl an relevanten Akteuren im Ökosystem des automatisierten Fahrens führt datenschutzrechtlich zu diversen Herausforderungen. Eine davon ist, wie jene Akteure, die zwar als (allein oder gemeinsam) Verantwortliche Personendaten bearbeiten, aber keinen direkten Kontakt zur betroffenen Person haben, ihre datenschutzrechtlichen Informationspflichten erfüllen, sprich, wie sie ihre jeweiligen Datenschutzerklärungen den betroffenen Personen zur Verfügung stellen. So werden beispielsweise die Daten aus dem Navigationssystem und den Fahrzeugsensoren (z.B. Position, Geschwindigkeit, Bremsvorgänge) nicht nur vom Fahrzeughersteller, sondern auch vom Anbieter des integrierten Kartendienstes bearbeitet, um Echtzeit-Verkehrsinformationen zu generieren und die Kartenqualität zu verbessern. Da dieser Anbieter die Daten auch für eigene Zwecke zur Verbesserung seines Dienstes für alle seine Kunden nutzt, wird er gemeinsam mit dem Hersteller zum Verantwortlichen. Diese Akteure im Hintergrund haben jedoch keine direkte Beziehung zum Fahrer und somit keine praktische Möglichkeit, ihm im Moment der Datenerhebung eine Datenschutzerklärung zukommen zu lassen. Die Erfüllung der Informationspflicht wird für sie faktisch verunmöglicht.
  Als Lösungsansatz muss der Fahrzeughersteller als zentrale und für die betroffene Person sichtbare Instanz agieren. In den Verträgen zwischen den relevanten Akteuren sollte sichergestellt werden, dass er die Transparenz über das gesamte Daten-Ökosystem sicherzustellen hat. Dies bedeutet nicht zwingend, dass er die Datenschutzerklärungen aller Partner vollständig in sein eigenes Dokument integrieren muss. Ein pragmatischerer und nutzerfreundlicherer Ansatz besteht darin, dass der Hersteller in seiner Datenschutzerklärung die verschiedenen Akteure (wie z. B. den Anbieter des Kartendienstes) und die an sie übermittelten Datenkategorien klar benennt. Zusätzlich stellt er sicher, dass die detaillierten, eigenen Datenschutzerklärungen dieser Partner für den Nutzer leicht zugänglich sind, beispielsweise indem er sie im Infotainmentsystem zur Verfügung stellt. Der Hersteller agiert somit als Kurator der Datenschutzinformationen. Er erfüllt seine eigene Informationspflicht und ermöglicht gleichzeitig den anderen Verantwortlichen, ihre Pflichten zu erfüllen, indem er den notwendigen Zugangspunkt für den Nutzer schafft. Für externe betroffene Personen wie Fussgänger könnte zudem ein QR-Code am Fahrzeug auf eine Webseite mit den entsprechenden Datenschutzinformationen verweisen. Allerdings dürfte hier der praktische Nutzen in Zweifel gezogen werden, da Fussgänger in der Regel einen solchen QR-Code an einem vorbeifahrenden Fahrzeug gar nicht scannen können.
• Im Ökosystem des automatisierten Fahrens bearbeiten zahlreiche Akteure riesige Datenmengen für vielfältige Zwecke. Der Grundsatz der Zweckbindung fungiert hier als zentraler Schutzmechanismus gegen eine unkontrollierte Ausweitung der Datenbearbeitung. Er schreibt vor, dass Personendaten nur zu dem Zweck bearbeitet werden dürfen, der bei ihrer Erhebung angegeben wurde, mit diesem Zweck vereinbar ist oder durch eine gesetzliche Bestimmung vorgesehen ist.
  Die besondere Gefahr liegt in der sekundären Zweckentfremdung: Daten, die für einen legitimen Zweck erhoben wurden, werden nachträglich für neue, ursprünglich nicht vorgesehene Zwecke genutzt. So könnte die Innovate Mobility AG die Bewegungsdaten von Linda Pünktlich, die primär für die Durchführung der Fahrt und die Abrechnung erhoben wurden, analysieren, um ihr personalisierte Werbung für Cafés, Restaurants oder ähnliche Angebote entlang ihrer üblichen Routen anzuzeigen. Eine solche Weiterbearbeitung wäre nur mit der Einwilligung von Linda Pünktlich zulässig. Aufgrund der erhöhten Intensität des Eingriffs in die Persönlichkeit von Linda Pünktlich wäre ihre Einwilligung in diesem Beispiel wohl ohnehin vorauszusetzen.
  Für alle Akteure ist es daher unerlässlich, die Bearbeitungszwecke von Beginn an präzise zu definieren und in ihren Datenschutzerklärungen klar und verständlich zu kommunizieren. Gerade diese Forderung nach einer klaren Zweckdefinition stösst in der Praxis jedoch häufig auf erhebliche Schwierigkeiten, da sich insbesondere bei neuen Technologien nicht alle zukünftigen Bearbeitungen von vornherein abschliessend bestimmen lassen.
• Im Kontext des autonomen Fahrens werden zunehmend kamerabasierte Systeme eingesetzt, die den Fahrer überwachen. Dabei ist datenschutzrechtlich entscheidend, ob diese Systeme biometrische Daten im Sinne des Gesetzes erheben und bearbeiten. Gemäss Art. 5 lit. c DSG sind biometrische Daten solche, die die eindeutige Identifizierung einer natürlichen Person ermöglichen. Diese Unterscheidung hat weitreichende Konsequenzen. Eine reine Müdigkeitserkennung, die lediglich Verhaltensmuster wie die Lidschlagfrequenz oder die Kopfhaltung analysiert, um auf den Zustand des Fahrers zu schliessen, generiert in der Regel keine biometrischen Daten. Ihr Zweck ist nicht die Identifikation, sondern die Zustandsanalyse. Die Bilddaten können lokal und flüchtig verarbeitet werden, ohne dass eine Person eindeutig wiedererkannt wird. Anders verhält es sich bei einem Gesichtsscan, der dazu dient, den Fahrer zu identifizieren, um beispielsweise das Fahrzeug zu starten oder persönliche Einstellungen zu laden. Hier ist die eindeutige Identifizierung der Zweck der Bearbeitung, weshalb die erzeugten Daten als biometrische Daten und somit als besonders schützenswerte Personendaten gelten.
  Entgegen einer weit verbreiteten Auffassung ist jedoch nicht in jedem Fall ein Rechtfertigungsgrund für die Bearbeitung von besonders schützenswerten Personendaten, wie biometrische Daten, erforderlich. Selbst wenn ein Rechtfertigungsgrund erforderlich ist, so muss es nicht immer die Einwilligung sein. Ist die biometrische Identifikation für die Erbringung einer vom Kunden gewählten Funktion systemimmanent und untrennbar mit der Vertragsabwicklung verbunden, kann sich der Hersteller auf dieses überwiegende Interesse stützen – vorausgesetzt, er informiert den Nutzer transparent darüber. Eine ausdrückliche Einwilligung wird jedoch unumgänglich, sobald die Daten für andere Zwecke genutzt oder an Dritte bekanntgegeben werden. Die kommerzielle Nutzung der biometrischen Merkmale für Marketing oder der Verkauf an Versicherungen wäre ohne ausdrückliche Einwilligung klar widerrechtlich. Zudem löst die grossflächige Bearbeitung biometrischer Daten in der Regel die Pflicht zur Durchführung einer Datenschutz-Folgenabschätzung aus (Art. 22 DSG). Aus kommerzieller Sicht und im Sinne eines datenschutzfreundlichen Designs ist es für Hersteller aber ohnehin ratsam, Kunden eine nicht-biometrische Alternative (z.B. PIN-Eingabe) anzubieten, um die Akzeptanz zu erhöhen und rechtliche Risiken zu minimieren.
• Ein Blick auf unseren Beispielsachverhalt zeigt eine Realität, die für moderne IT-Infrastrukturen typisch ist: Die von den Sensoren des Fahrzeugmodells "Sentinel Pod" erfassten Daten bleiben nicht lokal im Fahrzeug oder auf Schweizer Servern. Sie werden zur Analyse an die Herstellerin, die Sentinel Motors Corp., in die USA übermittelt.
  Das DSG folgt dem Grundsatz, dass Personendaten grenzüberschreitend nur dann bekanntgegeben werden dürfen, wenn die Gesetzgebung des Empfängerstaates einen angemessenen Schutz gewährleistet. Ist dies nicht der Fall – und die USA gelten grundsätzlich als Land ohne angemessenes Datenschutzniveau –, müssen in der Regel besondere Schutzmassnahmen ergriffen werden. Hier kommt Bewegung in die Rechtslage, die für Unternehmen wie die Innovate Mobility AG entscheidend ist. Mit dem "Swiss-U.S. Data Privacy Framework" (DPF), das der Bundesrat im Jahr 2024 anerkannt hat, wurde eine wichtige Brücke geschlagen. US-Unternehmen können sich unter diesem Framework zertifizieren lassen. Ist die Sentinel Motors Corp. auf der offiziellen Liste des DPF als zertifiziert eingetragen, dürfen Personendaten ohne zusätzliche Bewilligungen oder komplexe Verträge an sie übermittelt werden. Der Bundesrat hat mit seinem Angemessenheitsbeschluss bestätigt, dass für solche zertifizierten Unternehmen – trotz allfälliger Zugriffsmöglichkeiten von US-Behörden – ein hinreichender Schutz besteht.
  Doch was, wenn der US-Partner nicht zertifiziert ist? In der Praxis verfügen viele US-Unternehmen nicht über eine solche Zertifizierung. In diesem Fall muss die Innovate Mobility AG auf vertragliche Garantien zurückgreifen. Die in der Praxis am weitesten verbreitete Lösung hierfür besteht in der Vereinbarung der Standardvertragsklauseln der Europäischen Kommission (Standard Contractual Clauses, SCC). Diese sind vom Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) anerkannt, sofern gewisse von ihm verlangte Anpassungen an die konkreten Verhältnisse vorgenommen werden. Durch den Abschluss dieser Klauseln verpflichtet sich der US-(Daten-)Importeur vertraglich zur Einhaltung europäischer Datenschutzstandards.
  Ursprünglich war der Einsatz von SCC mit einer hohen Hürde verbunden: Es musste stets in einem aufwendigen "Transfer Impact Assessment" (TIA) geprüft werden, ob US-Behördenzugriffe den Datenschutz aushöhlen könnten (Schrems-II-Problematik). Hier brachte der Angemessenheitsbeschluss des Bundesrates zum DPF im Ergebnis eine Erleichterung, auch soweit die SCC verwendet werden: Zwar muss rechtlich immer noch ein TIA durchgeführt werden. Da der Bundesrat jedoch festgestellt hat, dass die US-Rechtslage grundsätzlich mit schweizerischen Rechtsstaatsprinzipien vereinbar ist, können sich (Daten-)Exporteure bei ihrer Risikoabschätzung faktisch auf diese behördliche Einschätzung stützen.
  Für unseren Beispielfall bedeutet dies: Die Innovate Mobility AG würde prüfen, ob die Sentinel Motors Corp. unter dem DPF zertifiziert ist. Ist sie es nicht, wird die Innovate Mobility für die Datenbekanntgabe in der Regel auf die SCC zurückgreifen, d.h. diese mit Sentinel Motors vereinbaren müssen.
• Eine besondere Herausforderung kann die korrekte Zuordenbarkeit der erhobenen Daten darstellen. Das Problem entsteht beispielsweise, wenn der Fahrzeughalter nicht der Fahrer ist – ein alltäglicher Fall, wenn das Fahrzeug verliehen, vermietet oder von einem Familienmitglied genutzt wird. Die Systeme des Fahrzeugs verknüpfen die anfallenden Fahr- und Verhaltensdaten typischerweise über die FIN mit dem Halter. Dies kann zu potenziell problematischen Fehlzuordnungen führen. Beispielsweise könnte ein aggressiver Fahrstil des Entleihers fälschlicherweise dem Halter zugeschrieben werden und dies wiederum zu unzutreffenden Schlussfolgerungen durch den Hersteller (z.B. bei Garantieansprüchen) oder durch Versicherungen (z.B. bei der Prämienkalkulation für "Pay-how-you-drive"-Modelle) führen.
  Streng genommen müssten insbesondere die Fahrzeughersteller Mechanismen vorsehen, die eine klare Trennung und korrekte Zuordnung von Daten zu den jeweiligen Fahrern ermöglichen, beispielsweise durch fahrerspezifische Profile. Dies ist aktuell häufig nicht der Fall.
   

IV. Key Takeaways

Dieser Beitrag verdeutlicht, dass automatisiertes Fahren nicht nur eine technische und verkehrsrechtliche Revolution ist, sondern auch eine datenschutzrechtliche Herausforderung darstellt. Werfen wir einen abschliessenden Blick auf die wichtigsten besprochenen Themenfelder und den Bezug zum Beispielsachverhalt:

• Fast alle Daten sind Personendaten: Selbst technische Fahrzeugdaten wie Reifendruck oder Fehlermeldungen werden durch die Verknüpfung mit der Fahrzeug-Identifikationsnummer (FIN) zu Personendaten. Sie können Rückschlüsse auf das Verhalten des Fahrers oder Halters ermöglichen und unterliegen damit dem DSG. Die Unterscheidung zwischen Halter und Fahrer wird dabei zur zentralen Herausforderung.
• Der Fahrmodusspeicher: Der gesetzlich vorgeschriebene Fahrmodusspeicher zeichnet Ereignisse während des autonomen Betriebs auf. Viele dieser Daten, etwa rein technische Systemmeldungen, sind keine Personendaten. Sobald die Aufzeichnungen jedoch Rückschlüsse auf das Verhalten einer Person zulassen – beispielsweise die Reaktion (oder Nicht-Reaktion) eines Fahrers auf eine Übernahmeaufforderung –, werden sie zu Personendaten. Die praktische Konsequenz: Zugreifende Parteien wie Fahrzeughalter oder Behörden müssen erkennen, dass sie ein gemischtes Datenset erhalten, und sind verpflichtet, für den Teil der Personendaten die Vorgaben des DSG vollständig einzuhalten
• Komplexe datenschutzrechtliche Verantwortlichkeiten: Die Vorstellung eines einzigen datenschutzrechtlichen Verantwortlichen passt nicht zur Realität des autonomen Fahrens. Hersteller, Flottenbetreiber, Fahrzeughalter, Softwarelieferanten und weitere Akteure entscheiden regelmässig gemeinsam über Datenbearbeitungen und gelten folglich als gemeinsam Verantwortliche. Dies wirkt sich beispielsweise auf die Geltendmachung von Betroffenenrechten aus, indem diese grundsätzlich gegenüber jedem der gemeinsam Verantwortlichen geltend gemacht werden können.
• Zweckbindung als Leitplanke: Daten dürfen nur für die bei der Erhebung klar definierten und kommunizierten Zwecke verwendet werden. Den involvierten Akteuren ist zu empfehlen, die notwendigen und gewünschten Datenbearbeitungen so klar wie möglich vorgängig zu definieren und diese den betroffenen Personen in ihren Datenschutzerklärungen (oder durch eine anderweitige Information) zu kommunizieren.
• Datenübermittlungen ins Ausland: Datenflüsse machen vielfach nicht an Landesgrenzen halt – erst recht nicht im Kontext des automatisierten Fahrens. Dabei müssen die datenschutzrechtlichen Vorgaben für Bekanntgaben ins Ausland beachtet werden. Für Datenbekanntgaben in die USA stehen hierzu mit dem "Swiss-U.S. Data Privacy Framework" und den Standardvertragsklauseln der Europäischen Kommission (inklusive Anpassungen gemäss dem EDÖB) anerkannte Instrumente bereit.

Mehr dazu erfahren Sie auch bei unserem Event "Autonomous driving – navigating the legal complexities":
https://lunchandlearn2026.events.vischer.com/

Autoren: Jonas Baeriswyl, Sarah Bischof