Standortdaten mit einer Zweckbindung, die Sie verteidigen können.

Wenn Sie den Zweck nicht in einem Satz sagen können, sind Sie nicht bereit, Menschen zu taggen. Viele Programme laufen auf Equipment und anonymisierten Zählungen.

Siehe DSGVO & RTLS und klinischer Bereich.

Benannte Standorttrails brauchen rollenbasierten Zugriff, Retention-Uhren und betriebsratsfähige Dokumentation. Wir designen das Evidence Pack mit Ihnen, nicht nach Go-Live.

Cloud-Ortungsplattformen und OEM-Tunnel sind Auftragsverarbeiter. Wir mappen sie vor Architektur-Lock-in, damit Sie nicht mit einer unvollendbaren DPIA stecken.

Personenortung ist nach DSGVO oft mit hohem Risiko verbunden. Reine Asset-Programme sind es oft nicht. Hybride Umgebungen brauchen eine klare Trennung: welche Tags eine Person identifizieren, welche Ausrüstung, und wie lange jede Klasse aufbewahrt wird. Wir klassifizieren vor der Wahl der Funktechnik, damit Sie nicht nach der Architekturfestlegung noch eine DSFA abschließen müssen.

Wir behandeln die DSFA als Eingangsgröße der Architektur, nicht als nachträgliche Formalität. Zweck, Rechtsgrundlage, Aufbewahrungsfristen, Zugriffsrollen und Auftragsverarbeiter-Übersichten werden mit Ihnen entworfen, bevor Tags bestellt werden. Wo anonymisierte Zählungen den Bedarf decken, bevorzugen wir sie und dokumentieren, wann eine Identifizierung wirklich nötig ist.

Betriebsräte und Personalvertretungen sind bei personennahen Programmen ab der ersten Woche Stakeholder. Überraschende „Produktivitäts-Heatmaps“ sind ein Designfehler.

Optionen zur Datenresidenz, Unterauftragsverarbeiter-Listen, Löschung und Export beim Ausstieg, und keine dauerhaften OEM-Tunnel, die Ihre Zugriffsrichtlinie umgehen. Wir nehmen diese Anforderungen in das SOW auf, damit die Datenschutzarchitektur nicht vom Cloud-Standard eines Resellers diktiert wird. Siehe DSGVO & RTLS und CISO.

Wenn der Standort eine Person identifizieren kann (Ausweis, Telefon oder Wearable), greifen die DSGVO und oft Betriebsratsregeln. Kaufkriterien für Datenschutzbeauftragte:

• Zweckbindung zuerst: Sicherheit, Sammelstellen, klinischer Ablauf oder reine Asset-Ortung; Produktivitätsüberwachung ist eine andere und schwierigere Grundlage.
• DSFA vor der Skalierung: Risiken, Maßnahmen, Aufbewahrung und Überprüfungsplan, mit dem Verantwortlichen abgestimmt und unterschrieben.
• Realistische Rechtsgrundlage: Die Einwilligung von Beschäftigten ist selten freiwillig. Berechtigte Interessen brauchen eine dokumentierte Interessenabwägung.
• Datenminimierung durch Architektur: Tag-IDs wo möglich von der HR-Identität trennen, Rohereignisse kurz aufbewahren, RBAC für Abfragen.
• Transparenz bei Auftragsverarbeitern: Unterauftragsverarbeiter, Übermittlungsmechanismen und Prüfrechte im Vertrag.

Lieferanten liefern Standardeinstellungen mit Dauertracking aus. SIs aktivieren sie für Demos. Aufgabe des Datenschutzbeauftragten ist es, Zweck, Aufbewahrung und Zugriff in das Design zu zwingen, nicht als nachträgliches Richtlinien-PDF.

• Personenortung wird mit „Sicherheit“ begründet, während Vorgesetzte die Wege zur Leistungsbewertung nutzen.
• Unbefristete Aufbewahrung roher Koordinaten.
• Weit gefasste Admin-Rollen in der Cloud des Anbieters.
• Einbindung des Betriebsrats erst nach der Vertragsunterzeichnung, in DACH, Frankreich oder den Niederlanden.
• Ein Asset-Programm wird stillschweigend ohne neue DSFA auf Personen ausgeweitet.

• Welche Kategorien personenbezogener Daten gibt es, und können wir nur Assets orten, ohne identifizierbare Personen?
• Welche Standard- und einstellbaren Aufbewahrungsfristen gelten für rohe und abgeleitete Ortungsdaten, mit automatischer Löschung?
• Wer kann die Bewegung einer einzelnen Person rekonstruieren, und wird jede Abfrage protokolliert?
• Liste der Auftragsverarbeiter und Unterauftragsverarbeiter sowie internationaler Übermittlungen.
• Unterstützen Sie unsere DSFA und die Unterlagen für den Betriebsrat mit genauen technischen Beschreibungen?

Wir behandeln Datenschutz als Designvorgabe für Lokalisierungsprogramme. Unabhängig von Hardwarelieferanten helfen wir, Personen und Assets früh zu klassifizieren, eine DSFA-fähige Architektur zu entwerfen und Funktionen abzulehnen, die den Zweck ohne Governance ausweiten. Kein SKU-Anreiz, das Tracking zu maximieren.

Die meisten RTLS-Plattformen kommen mit durchgehender Ortung, langer Aufbewahrung und weit gefassten Admin-Rollen: praktisch für Demos, schwierig unter der DSGVO. Anbieter sagen, das Produkt sei „DSGVO-ready“. Systemintegratoren schalten ein, was den Pilot gut aussehen lässt. Die Artikel-29-Datenschutzgruppe und die Aufsichtsbehörden stufen die systematische Überwachung von Beschäftigten als hohes Risiko ein. Rechnen Sie mit einer DSFA, einer Prüfung von Notwendigkeit und Verhältnismäßigkeit, transparenten Hinweisen und der Einbindung des Betriebsrats, wo nationales Recht das verlangt.

Eine Einwilligung ist selten eine tragfähige Grundlage für die Ortung von Beschäftigten. Berechtigte Interessen für die Sicherheit können mit Interessenabwägung und Schutzmaßnahmen tragen. Für Produktivitätsanalysen gilt das meist nicht. Architekturentscheidungen zählen mehr als Richtlinien im PDF: Tag-Identität wo machbar von der HR-Identität trennen, Rohkoordinaten nur kurz aufbewahren (oft Tage, nicht Jahre) und privilegierte Rekonstruktionen von Bewegungen protokollieren.

Ordnen Sie früh ein: Anonyme Belegungsdaten und reine Asset-Tags können ohne personenbezogene Daten auskommen. Programme mit Ausweisen am Körper nicht. Den Zweck später ohne neue Bewertung zu erweitern, ist ein klassischer Compliance-Fehler.

TRACIO unterstützt Programmverantwortliche dabei, Zweck, Aufbewahrung und Zugriff in das Ortungsdesign zu schreiben, bevor Funkkomponenten gekauft werden. Da wir weder Tags noch Plattformen verkaufen, können wir frei reine Asset-Umfänge, kürzere Aufbewahrung oder On-Prem-Enklaven empfehlen, wenn die DSFA das verlangt. Außerdem übersetzen wir die technische Realität in betriebsratsfähige Beschreibungen, damit die Mitbestimmung auf dem beruht, was das System tatsächlich tut.