DSGVO und industrielles IoT: Was Predictive-Maintenance-Teams wissen müssen

Der blinde Fleck in der Compliance

Ihre Schwingungssensoren erfassen keine personenbezogenen Daten — oder doch?

Die meisten Betriebsingenieure betrachten die DSGVO als Problem von Marketing und Personalabteilung. Doch sobald Ihr Predictive-Maintenance-System Bedieneraktionen, Schichtmuster, personengebundene Anlagenzuordnungen oder auch nur IP-Adressen von IoT-Gateways protokolliert, verarbeiten Sie personenbezogene Daten gemäß Artikel 4 der DSGVO.

Eine Erhebung des Europäischen Datenschutzausschusses aus dem Jahr 2025 ergab, dass 43 % der industriellen IoT-Installationen mindestens eine DSGVO-Compliance-Lücke aufwiesen, von der sie nichts wussten. Die Bußgelder sind keine Theorie: Ein deutscher Hersteller wurde 2025 mit 1,2 Mio. € bestraft, weil ein Überwachungssystem die individuelle Bedienerleistung ohne ordnungsgemäße Einwilligung erfasste.

Wo Predictive Maintenance auf personenbezogene Daten trifft

Folgendes gilt im Kontext der vorausschauenden Wartung tatsächlich als personenbezogene Daten:

Eindeutig personenbezogen

• Anmeldedaten und Sitzungsprotokolle von Bedienern
• Namentliche Schichtzuordnungen
• Arbeitsauftragszuweisungen („Bediener Schmidt hat Lager an Anlage 41 gewechselt")
• Push-Benachrichtigungstoken der mobilen App
• E-Mail-Adressen für Alarmweiterleitung

Die Grauzone

• Maschinenbetriebsparameter während bestimmter Schichten (können Bediener indirekt identifizieren)
• Wartungsprotokolle mit Technikernamen
• Zutrittskartendaten in Korrelation mit Anlagenereignissen
• Videoaufnahmen aus Maschinenbereichen (auch wenn sie der Anlagenüberwachung dienen)

Keine personenbezogenen Daten

• Rohe Schwingungs-, Temperatur- und Druckmesswerte von Sensoren
• ML-Modellvorhersagen und Anomalie-Scores
• Anlagenzustandsindizes
• Aggregierte Produktionskennzahlen

Sechs Grundsätze für DSGVO-konforme vorausschauende Wartung

1. Datenminimierung — Erfassen Sie nur, was Sie brauchen

Das Prinzip: Es dürfen nur personenbezogene Daten verarbeitet werden, die dem Zweck angemessen und erheblich sowie auf das notwendige Maß beschränkt sind (Artikel 5 Absatz 1 Buchstabe c).

In der Praxis:

• Sensordaten benötigen keine Bedienerzuordnung. Ein Schwingungsmesswert von Pumpe 7A betrifft die Pumpe, nicht die Person, die sie bedient.
• Wenn Ihre CMMS-Integration Bedienernamen in Arbeitsaufträge übernimmt, entscheiden Sie: Benötigen Sie den Namen für die vorausschauende Wartung oder nur die Tatsache, dass eine Wartung durchgeführt wurde?
• Entfernen Sie IP-Adressen aus MQTT/OPC-UA-Verbindungsprotokollen, es sei denn, Sie benötigen sie für Sicherheitsaudits.

Prevlys Ansatz: Sensormesswerte werden ausschließlich mit asset_id und tenant_id gespeichert. Zeitreihendaten enthalten keine Bedieneridentität. Arbeitsaufträge referenzieren Rollen, nicht Einzelpersonen, sofern der Kunde die Personalerfassung nicht explizit aktiviert.

2. Zweckbindung — Definieren Sie das Warum

Sensordaten, die für die vorausschauende Wartung erhoben wurden, dürfen nicht ohne separate Rechtsgrundlage für die Überwachung der Bedienerleistung zweckentfremdet werden. Das klingt offensichtlich, geschieht aber ständig, wenn:

• Ein Werksleiter fragt: „Welche Schicht hat mehr Anlagenausfälle?"
• Die Personalabteilung Wartungsprotokolle anfordert, um Reaktionszeiten von Technikern zu bewerten
• Die Versicherung bedienerbezogene Vorfallsdaten verlangt

Best Practice: Dokumentieren Sie Ihre Verarbeitungszwecke in einem Verzeichnis der Verarbeitungstätigkeiten (VVT) vor der Inbetriebnahme. Prevlys Auftragsverarbeitungsvertrag (AVV) beschränkt die Verarbeitung ausdrücklich auf die Vorhersage des Anlagenzustands und die Wartungsoptimierung.

3. Speicherbegrenzung — Horten Sie keine Daten

Das Prinzip: Personenbezogene Daten dürfen nicht länger als erforderlich gespeichert werden (Artikel 5 Absatz 1 Buchstabe e).

Die Herausforderung bei PdM: ML-Modelle verbessern sich mit mehr historischen Daten. Ein Weibull-RNN zur Vorhersage der Restnutzungsdauer profitiert von über zwei Jahren Ausfallhistorie. Aber brauchen Sie zwei Jahre Bedienerprotokolle?

Gestufte Aufbewahrungsstrategie: | Datentyp | Hot Storage | Cold-Archiv | Löschung | |---|---|---|---| | Sensormesswerte | 90 Tage | 2 Jahre (S3 Parquet) | Nach Ablauf des Archivs | | ML-Vorhersagen | 1 Jahr | 3 Jahre | Nach Ablauf des Archivs | | Audit-Protokolle (mit User-IDs) | 90 Tage | 1 Jahr | Pflichtlöschung | | Bediener-Arbeitsaufträge | 30 Tage | Gemäß gesetzlicher Anforderung | Gemäß Richtlinie | | Aggregierte Statistiken | Unbegrenzt | — | Nie (anonymisiert) |

4. Multi-Tenancy-Isolation — Ihre Daten bleiben bei Ihnen

Bei Multi-Tenant-SaaS ist das größte DSGVO-Risiko kein Hacker — es ist ein Softwarefehler, der Daten von Mandant A an Mandant B weitergibt.

Anforderungen für DSGVO-konforme Isolation:

• Row-Level Security (RLS): Jede Datenbankabfrage wird automatisch auf den authentifizierten Mandanten beschränkt. Keine Filterung auf Anwendungsebene — datenbankerzwungen.
• Verschlüsselung im Ruhezustand: Mandantenspezifische Verschlüsselungsschlüssel (oder mindestens mandantenspezifische logische Isolation mit AES-256).
• Netzwerkisolation: Premium-Mandanten können dedizierte Infrastruktur verlangen (die DSGVO schreibt dies nicht vor, aber risikoscheue Branchen fordern es).
• Audit-Trail: Wer hat wann auf welche Daten zugegriffen. SOC 2 Type II liefert dies als Nebeneffekt.

5. Grenzüberschreitende Übermittlung — Wo befinden sich Ihre Daten?

Nach Schrems II erfordert die Übermittlung personenbezogener Daten außerhalb der EU Standardvertragsklauseln (SVK) oder einen Angemessenheitsbeschluss.

Für industrielles IoT ist dies relevant, wenn:

• Ihr Cloud-Anbieter Rechenzentren außerhalb der EU betreibt
• Ihr PdM-Anbieter Daten in einer Nicht-EU-Region verarbeitet
• Edge-Geräte Diagnosedaten an das US-basierte Supportsystem eines Anbieters senden

Lösung: Wählen Sie eine Plattform mit EU-Datenresidenzoptionen. Prevlys Infrastruktur läuft standardmäßig in EU-Regionen, mit vertraglich garantierter Datenresidenz im AVV.

6. Betroffenenrechte — Ja, auch für Ingenieure

Ihre Instandhaltungsingenieure haben das Recht auf:

• Auskunft über ihre personenbezogenen Daten (Artikel 15)
• Berichtigung unrichtiger Daten (Artikel 16)
• Löschung („Recht auf Vergessenwerden") ihrer Daten (Artikel 17)
• Datenübertragbarkeit — Export ihrer Daten in einem maschinenlesbaren Format (Artikel 20)

Wenn ein Ingenieur das Unternehmen verlässt und die Löschung verlangt, kann Ihr PdM-System seinen Namen aus historischen Arbeitsaufträgen entfernen und gleichzeitig die Wartungshistorie bewahren?

Planen Sie dies von Anfang an ein. DSGVO-Konformität nachträglich einzubauen ist erheblich aufwändiger als sie von Beginn an mitzudenken.

Die Checkliste

Vor der Einführung von Predictive Maintenance in der EU:

• [ ] VVT-Eintrag für die PdM-Datenverarbeitung. Erstellen Sie einen dedizierten Eintrag in Ihrem Verzeichnis der Verarbeitungstätigkeiten, der alle PdM-bezogenen Daten abdeckt: Sensormesswerte, ML-Vorhersagen, Arbeitsaufträge und alle bedienerbezogenen Daten. Geben Sie die Rechtsgrundlage an (typischerweise berechtigtes Interesse für die Anlagenüberwachung, Einwilligung für Bedienererfassung), Datenkategorien, Empfänger und Aufbewahrungsfristen. Dies ist nach Artikel 30 für Unternehmen mit 250+ Mitarbeitern verpflichtend und wird kleineren Unternehmen dringend empfohlen.

• [ ] AVV mit Ihrem PdM-Anbieter unterzeichnet. Ihr Auftragsverarbeitungsvertrag muss die Rolle des Anbieters (Auftragsverarbeiter), die Arten verarbeiteter Daten, Sicherheitsmaßnahmen, die Offenlegung von Unterauftragsverarbeitern und Datenlöschungsverfahren bei Vertragsende festlegen. Gemäß Artikel 28 dürfen Sie nur Auftragsverarbeiter mit hinreichenden Garantien einsetzen. Fordern Sie den aktuellsten SOC 2 Type II-Bericht oder das ISO 27001-Zertifikat als Nachweis an.

• [ ] Datenflussdiagramm, das zeigt, wohin Sensor- und personenbezogene Daten fließen. Dokumentieren Sie jeden Übertragungsschritt: Sensor → Edge-Gateway → Cloud-Ingestion → Datenbank → ML-Pipeline → Alert Engine → Benachrichtigungskanäle. Notieren Sie für jeden Schritt, ob personenbezogene Daten vorhanden sind, welche Verschlüsselung beim Transport verwendet wird (TLS 1.2+) und ob die Daten Landesgrenzen überschreiten. Dieses Diagramm ist sowohl für die DSFA als auch für Anfragen der Aufsichtsbehörde unerlässlich.

• [ ] Aufbewahrungsrichtlinie mit automatischer Löschung personenbezogener Daten. Verlassen Sie sich nicht auf manuelle Bereinigung. Konfigurieren Sie automatische Aufbewahrungsregeln: Sensordaten nach 90 Tagen archiviert, Audit-Protokolle mit User-IDs nach 12 Monaten gelöscht, Bedienerreferenzen in Arbeitsaufträgen bei Offboarding anonymisiert. Testen Sie den Löschprozess — führen Sie ihn in einer Staging-Umgebung aus und überprüfen Sie, dass personenbezogene Daten tatsächlich innerhalb eines definierten Zeitraums aus Backups entfernt werden (die DSGVO verlangt keine sofortige Backup-Löschung, aber Sie brauchen einen dokumentierten Zeitplan).

• [ ] RLS verifiziert — Multi-Tenant-Isolation getestet, nicht nur dokumentiert. Führen Sie Penetrationstests durch, die gezielt auf mandantenübergreifenden Datenzugriff abzielen. Das bedeutet: Authentifizieren Sie sich als Mandant A, versuchen Sie über jeden API-Endpunkt, jede direkte Datenbankverbindung und jede Exportfunktion auf Daten von Mandant B zuzugreifen. Row-Level Security auf Datenbankebene sollte dies unabhängig von Anwendungsfehlern unmöglich machen. Dokumentieren Sie die Testergebnisse.

• [ ] Cookie-Einwilligung auf allen Web-Dashboards. Ja, das Wartungsdashboard zählt auch. Wenn es im Browser läuft und Cookies setzt oder Analytics nutzt (auch interne Analytics), benötigen Sie ein DSGVO-konformes Consent-Banner mit granularen Zustimmungs-/Ablehnungsoptionen. „Unbedingt erforderliche" Cookies (Session-Authentifizierung) erfordern keine Einwilligung; Analytics- und Tracking-Cookies schon.

• [ ] Meldeverfahren bei Datenverletzungen — 72-Stunden-Frist zur Meldung an die Aufsichtsbehörde. Definieren Sie die Eskalationskette: Wer erkennt die Verletzung, wer bewertet den Schweregrad, wer informiert den DSB, wer meldet an die Aufsichtsbehörde. Die 72-Stunden-Frist beginnt, sobald Sie von der Verletzung „Kenntnis erlangen" — nicht erst nach Abschluss der Untersuchung. Halten Sie die Meldevorlage mit den von Ihrer Aufsichtsbehörde geforderten Feldern vorab bereit.

• [ ] DSFA durchgeführt, wenn Verarbeitung im großen Maßstab oder automatisierte Entscheidungsfindung vorliegt. Eine Datenschutz-Folgenabschätzung ist gemäß Artikel 35 verpflichtend, wenn die Verarbeitung ein hohes Risiko birgt — dazu gehört die großflächige Überwachung (Tausende Sensoren, mehrere Standorte) und automatisierte Entscheidungen, die Personen betreffen (z. B. Arbeitsauftragszuweisungen, leistungskorrelierte Kennzahlen). Die DSFA sollte Risiken, Gegenmaßnahmen und die Akzeptanz des Restrisikos dokumentieren.

Häufige Fehler

Drei Muster verursachen regelmäßig DSGVO-Probleme bei industriellen IoT-Installationen:

Alle Sensordaten standardmäßig als nicht personenbezogen behandeln. Rohe Schwingungsdaten sind tatsächlich nicht personenbezogen. Aber sobald Sie sie mit Schichtplänen, Bedieneranmeldungen oder Wartungszuweisungen verknüpfen, werden sie durch die Zuordnung zu personenbezogenen Daten. Der sicherste Ansatz: Halten Sie Sensordaten und Personaldaten in getrennten Datenspeichern, die nur bei explizitem Bedarf und mit dokumentiertem Zweck zusammengeführt werden.

Auf Zugriffskontrolle auf Anwendungsebene vertrauen. Wenn Ihre Multi-Tenant-Isolation im Anwendungscode erzwungen wird („WHERE tenant_id = ?"), reicht ein einziger Bug, um alle Mandanten offenzulegen. Row-Level Security auf Datenbankebene ist der DSGVO-konforme Standard — sie erzwingt die Isolation auf der Abfrage-Ausführungsebene, unabhängig von der Anwendungslogik. Jede Abfrage, jeder API-Aufruf, jeder Export wird durch die Datenbank selbst auf den Mandanten beschränkt.

Keine Löschfunktion für personenbezogene Daten. Viele PdM-Systeme sind als Append-only-Zeitreihenspeicher konzipiert, was für das ML-Training hervorragend, für das DSGVO-Recht auf Löschung jedoch problematisch ist. Gestalten Sie Ihr Schema so, dass Bediener-Identifikatoren in Arbeitsaufträgen und Audit-Protokollen anonymisiert (durch „deleted_user_" ersetzt) werden können, ohne die Wartungshistorie zu zerstören, die Ihre ML-Modelle benötigen.

Das Fazit

Die DSGVO ist nicht innovationsfeindlich. Sie ist ein Rahmenwerk, das Sie zwingt, über Datenarchitektur nachzudenken — was Sie bei einem produktiven PdM-System ohnehin tun sollten. Die Unternehmen, die Compliance als Designvorgabe behandeln (nicht als Nachgedanken), erhalten sauberere Architekturen, bessere Data Governance und Systeme, denen ihre Kunden tatsächlich vertrauen.

Prevly wurde DSGVO-first entwickelt: Row-Level Security, gestufte Aufbewahrungsfristen, EU-Datenresidenz, einwilligungsgesteuerte Analytics und Datenexport-APIs. Denn im industriellen IoT ist Vertrauen keine Option — es ist die Voraussetzung für Ihr erstes Pilotprojekt.

Weiterführende Artikel: On-Premise vs. Cloud-PdM · PdM für die Medizintechnik · Schreibgeschütztes OPC-UA-Monitoring