Rechtliche Rahmenbedingungen

Im FM sind KI‑Lösungen regelmäßig „Datenprojekte“. Deshalb sind die DSGVO‑Prinzipien nicht nur Formalien, sondern Architekturvorgaben: Rechtmäßigkeit/Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität/Vertraulichkeit; zusätzlich die Rechenschaftspflicht (Nachweisbarkeit). Rechtsgrundlagen müssen pro Zweck festgelegt werden (z. B. Vertragserfüllung, rechtliche Pflicht, berechtigtes Interesse, Einwilligung). Für viele FM‑Kontexte ist „berechtigtes Interesse“ (Art. 6 Abs. 1 lit. f) praxisnah, verlangt aber eine saubere Interessenabwägung und Schutzmaßnahmen; Einwilligung ist bei Beschäftigten häufig problematisch, weil Freiwilligkeit im Abhängigkeitsverhältnis schwer belegbar ist – diese Leitlinie wird in der Einwilligungs‑Guidance des EDPB detailliert unterstrichen.

Sobald biometrische Daten zur eindeutigen Identifizierung oder andere besondere Kategorien verarbeitet werden, greift das grundsätzliche Verarbeitungsverbot des Art. 9 DSGVO mit engen Ausnahmen. Im FM wird diese Schwelle häufig durch Zutrittslösungen (Gesicht, Finger, Iris), „Smart CCTV“ oder Health‑/Safety‑Monitoring berührt.

Art. 22 DSGVO gewährt Betroffenen das Recht, nicht einer Entscheidung unterworfen zu werden, die ausschließlich automatisiert erfolgt und rechtliche Wirkung entfaltet oder ähnlich erheblich beeinträchtigt.

• automatisierte Zutrittsverweigerung (z. B. biometrische Fehlentscheidung),

• automatisierte Sanktionen (z. B. Hausverbot‑Trigger),

• automatisierte arbeitnehmerbezogene Entscheidungen (z. B. Disposition/Schicht/Performance‑Folgen).

Die WP29/EDPB‑Leitlinien zu automatisierten Entscheidungen und Profiling konkretisieren, dass bei ausschließlich automatisierten Entscheidungen zusätzliche Garantien/Begrenzungen gelten und Verantwortliche die Voraussetzungen eng prüfen müssen.

Bei neuen Technologien und voraussichtlich hohem Risiko ist eine Datenschutz‑Folgenabschätzung (DSFA/DPIA) erforderlich. Im FM ist „hohes Risiko“ oft naheliegend, etwa bei Videoüberwachung, systematischer Überwachung öffentlich zugänglicher Bereiche oder bei Biometrie/Profiling‑Nähe. Die DSFA ist damit in vielen KI‑FM‑Projekten nicht Ausnahme, sondern Standardinstrument.

Art. 32 DSGVO verlangt risikoadäquate technische und organisatorische Maßnahmen (TOMs) unter Berücksichtigung Stand der Technik, Implementierungskosten und Risiko. Wird ein KI‑Dienstleister als Auftragsverarbeiter eingesetzt (typisch bei Cloud‑SaaS, Ticket‑KI, RAG‑Plattformen), muss der Verantwortliche nur mit Auftragsverarbeitern mit hinreichenden Garantien arbeiten; die Verarbeitung ist über einen Vertrag nach Art. 28 DSGVO zu regeln. Zudem ist ein Verzeichnis von Verarbeitungstätigkeiten zu führen (Art. 30 DSGVO).

Für Beschäftigtendaten ist § 26 BDSG zentral (Datenverarbeitung für Zwecke des Beschäftigungsverhältnisses). In KI‑gestützten FM‑Workflows sind Beschäftigtendaten nicht nur „HR‑Daten“, sondern häufig operative Daten: Ticket‑Bearbeitung, Zeit‑/Ort‑Bezüge, Leistungskennzahlen, Zugangsdaten, Kommunikationsdaten.

Eine zweite, praktisch zwingende Ebene ist die Mitbestimmung: Die Einführung und Anwendung technischer Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung von Arbeitnehmern zu überwachen, unterliegt dem Mitbestimmungsrecht des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG. KI‑Tools im Servicedesk, Workforce‑Management oder Qualitätssicherung sind häufig „überwachungsgeeignet“ – selbst wenn das nicht primäre Ziel ist. In der Praxis ist daher ein rechts‑ und sozialpartnerschaftlich tragfähiges „Monitoring‑Design“ (Zweck, Grenzen, Auswertungsrechte, Zugriff, Löschfristen) ein Kernartefakt.

Videoüberwachung in öffentlich zugänglichen Räumen ist im BDSG gesondert geregelt (§ 4). Zusätzlich geben Aufsichtsbehörden Orientierung, z. B. die DSK‑Orientierungshilfe zur Videoüberwachung durch nicht‑öffentliche Stellen.

Auf EU‑Ebene liefern die EDPB‑Leitlinien zur Verarbeitung personenbezogener Daten durch Videogeräte eine detaillierte Auslegungshilfe für DSGVO‑konforme Gestaltung (u. a. Zweckbindung, Erforderlichkeit, Transparenz, Speicherdauer, Zugriffskontrollen).

• klare Zweckdefinition (z. B. Einbruchprävention vs. Prozessoptimierung),

• Erforderlichkeits‑/Verhältnismäßigkeitsprüfung,

• strikte Zugriffskontrolle und Rollenmodell,

• kurze Speicherfristen,

• Privacy‑by‑Design (Maskierung, Zonen, Edge‑Processing, Vermeidung von Identifizierung).

Die zugrundeliegenden Pflichten ergeben sich aus DSGVO‑Grundprinzipien und Rechtsgrundlagen.

• Unabhängig von Spezialregimen trifft Betreiber/Eigentümer regelmäßig eine Verkehrssicherungspflicht: Wer eine Gefahrenquelle schafft oder unterhält, muss erforderliche und zumutbare Vorkehrungen treffen, um Dritte vor Schäden zu schützen. Der dogmatische Anknüpfungspunkt liegt u. a. in § 823 BGB (Schadensersatzpflicht). Im FM konvergiert dies mit „Betreiberverantwortung“: Organisation, Dokumentation und Kontrolle der Betreiberpflichten für Gebäude, technische Anlagen und Betriebsprozesse – häufig im Zusammenspiel mit Dienstleistern.

• Technische Regeln und Richtlinien wirken hier faktisch als Sorgfaltsmaßstab: Die Richtlinie VDI 3810 adressiert Betreiberverantwortung in Gebäuden und stellt anwendungsorientierte Strukturen bereit, wie Betreiberpflichten organisiert und nachgewiesen werden können. Für KI‑gestützten Betrieb heißt das: Wenn KI Entscheidungen über Wartung, Alarmpriorisierung oder Sicherheitsmaßnahmen beeinflusst, muss die Betreiberorganisation die Kontroll‑ und Nachweisprozesse entsprechend erweitern.

Der Arbeitgeber hat nach § 5 ArbSchG durch eine Beurteilung der Arbeitsbedingungen festzustellen, welche Maßnahmen des Arbeitsschutzes erforderlich sind. KI‑Systeme, die Aufgaben zuteilen, Prioritäten setzen, Leistungskennzahlen erzeugen oder Arbeitsabläufe verändern, sind regelmäßig „Änderungen“ mit Einfluss auf psychische/organisatorische Belastungen, Qualifikationsanforderungen und Fehlerrisiken. Die DGUV‑Vorschrift 1 verpflichtet den Unternehmer, Maßnahmen zur Verhütung von Arbeitsunfällen, Berufskrankheiten und arbeitsbedingten Gesundheitsgefahren zu treffen. Die TRBS‑Systematik (z. B. TRBS 1111 „Gefährdungsbeurteilung“) konkretisiert den Stand von Technik/Arbeitsmedizin/Arbeitshygiene im Betriebssicherheitskontext und ist als Orientierung für systematische Bewertungen relevant.

Die Bundesregierung hat die Umsetzung der NIS‑2‑Richtlinie in deutsches Recht beschlossen; das Gesetz ist am 6. Dezember 2025 in Kraft getreten und erweitert Sicherheitsanforderungen sowie Meldepflichten bei Sicherheitsvorfällen – insbesondere für Unternehmen, die für die Grundversorgung relevant sind (u. a. Gesundheit, Energie, Infrastruktur).

• das Portfolio/Objekt kritische Dienstleistungen unterstützt (z. B. Krankenhäuser, Energie/Wasser‑Anlagen, Verkehr),

• FM‑IT/OT (BMS/GLT/ICS) als Teil der kritischen Servicekette betrieben wird,

• ein FM‑Dienstleister selbst in den Anwendungsbereich fällt.

KI, die Betriebsführung, Vorfallbearbeitung oder Automatisierung in OT/ICS‑nahen Umgebungen unterstützt, muss in ein Informationssicherheitsmanagement eingebettet werden (Policies, Risikomanagement, Incident Response, Lieferkettensteuerung). Das deckt sich sachlich mit den Anforderungen, die die KI‑VO für Hochrisiko‑Betreiber zu Monitoring/Protokollen/Unterbrechung bei Risiko vorsieht.

• Neben Cyberpflichten tritt die physische Resilienz kritischer Einrichtungen stärker in den Vordergrund. Die CER‑Richtlinie (EU) 2022/2557 zielt auf Mindestvorschriften zur Resilienz kritischer Einrichtungen.

• Der Deutsche Bundestag hat das KRITIS‑Dachgesetz zur Umsetzung der CER‑Richtlinie und zur Stärkung der Resilienz kritischer Anlagen im Januar 2026 beschlossen; es adressiert u. a. Identifizierung/Registrierung, Risikoanalysen/Risikobewertungen, Resilienzmaßnahmen und ein Meldewesen für Vorfälle.

• Für FM heißt das: Bei KRITIS‑Objekten ist KI‑Einsatz (z. B. Videoanalytics, Zutrittsautomatisierung, automatische Alarm‑/Einsatzdisposition) nicht nur eine Daten‑/KI‑Compliance‑Frage, sondern Teil des Resilienz‑Nachweises: Prozesse müssen ausfalltolerant sein, menschliche Fallbacks existieren, Veränderungen werden kontrolliert.

• Für FM‑Betreiber relevant ist zudem, dass sich die Produktsicherheits‑/Cyberanforderungen für vernetzte Produkte verschärfen: Der Cyber Resilience Act als EU‑Verordnung (EU) 2024/2847 schafft Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen über den Lebenszyklus. Auch wenn Betreiber nicht Hersteller sind, wird das in der Beschaffungspraxis wirksam: Betreiber müssen Lieferketten‑ und Patchmanagement, Update‑Policies und Schwachstellenprozesse vertraglich und operativ absichern.

• Für OT/ICS‑nahe Umgebungen ist außerdem einschlägig, dass die Normenreihe IEC 62443 einen ganzheitlichen Ansatz für Cybersecurity in Industrial Automation and Control Systems beschreibt – für Betreiber, Integratoren und Hersteller.

• Als praktikabler Referenzrahmen im Betrieb kann die ISO‑27001‑Zertifizierung auf Basis von IT‑Grundschutz (BSI) dienen, um Sicherheitsmanagement systematisch nachzuweisen.

• Die KI‑VO ist primär ein Markt‑ und Compliance‑Regime mit Pflichten und Sanktionen. Sie enthält eigene Bußgeldrahmen auch bei Missachtung des Verbots (Art. 5) bzw. Pflichtverstößen (u. a. Betreiberpflichten Art. 26, Transparenz Art. 50). Zivilrechtliche Haftung (Schadensersatz) richtet sich jedoch typischerweise nach nationalem Recht (vertraglich/deliktisch), ergänzt durch Produkthaftungsrecht.

• Relevanter Trend: Die neue EU‑Produkthaftungsrichtlinie (EU) 2024/2853 modernisiert die verschuldensunabhängige Produkthaftung ausdrücklich auch vor dem Hintergrund neuer Technologien wie KI; der Begriff „Produkt“ soll u. a. Software einschließen. Die Richtlinie gilt für Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden; die bisherige Richtlinie wird mit Wirkung zum 9. Dezember 2026 aufgehoben, bleibt aber für vorherige Produkte relevant. Für FM‑Betreiber bedeutet das indirekt: Wenn KI als Teil eines Produkts (z. B. Sicherheitssensorik, Robotik, Zutrittssysteme) eingesetzt wird, steigen die Anforderungen an Nachweisbarkeit, Update‑Kontrolle und Lieferkettentransparenz – und die Betreiber müssen im Schadenfall mit komplexeren Regress‑/Beweislinien rechnen.

• National gilt in Deutschland weiterhin das Produkthaftungsgesetz (ProdHaftG) als Kern des Produkthaftungsrahmens, bis Anpassungen an EU‑Vorgaben umgesetzt sind. Für Betreiberverantwortung im laufenden Betrieb bleibt zudem § 823 BGB (inkl. Verkehrssicherung als Unterlassenspflicht bei Gefahrenquellen) ein zentraler Haftungsanker.

• Wer hat die Zweckbestimmung gesetzt? (kann Anbieterrolle auslösen).

• Wer steuert Updates/Änderungen? (Change‑Control entscheidet über wesentliche Veränderungen und neue Risiken).

• Wer überwacht im Betrieb und reagiert auf Fehlverhalten? (Betreiberpflichten: Monitoring, Aussetzen bei Risiko, Incident‑Information).

• Wer ist datenschutzrechtlich Verantwortlicher und wer Auftragsverarbeiter? (Art. 28‑Verträge, Weisungen, TOMs).

• Wer ist Arbeitgeber und wer muss Mitbestimmung/Information leisten? (BetrVG/Art. 26 KI‑VO‑Arbeitsplatzinformation).

Die nachfolgenden Klausel‑/Bausteinbereiche sind produktneutral formuliert und zielen auf Betreiber‑Risikominderung. Sie knüpfen an objektive Pflichten aus KI‑VO/DSGVO an und machen diese „liefer‑ und prüfbar“.

• Zusicherung des Lieferanten, welche Rolle er übernimmt (Anbieter/Importeur/Händler) und dass er die einschlägigen KI‑VO‑Pflichten erfüllt (inkl. Bereitstellung der Betriebsanleitungen, erforderlicher Dokumentation, ggf. Konformitätsnachweise).

• Verpflichtung zur Bereitstellung von „AI‑System Cards“/Technikdokumentation in prüffähiger Form, inkl. Zweckbestimmung, Grenzen, Datenanforderungen, Human‑Oversight‑Design.

• Pflicht zur Vorab‑Ankündigung von Modellen/Updates/Parameteränderungen, inkl. Risikoeinschätzung.

• Abnahmeprozess: Updates erst nach Test/Abnahme in produktive Steuerungsprozesse.

• Regelung, wer bei Customizing/Fine‑Tuning Anbieterpflichten übernimmt (Rollenwechsel vermeiden oder bewusst übernehmen).

• SLA für Fehlfunktionen, definierte Incident‑Kategorien (Safety, Security, Datenschutz, Compliance).

• Pflicht zur unverzüglichen Information über schwerwiegende Vorfälle; abgestimmte Meldeketten.

• Zusicherung, dass Logs erzeugt/zugänglich sind; Regelung zur Aufbewahrung und Zugriff (bei Hochrisiko mind. 6 Monate, soweit kontrollierbar).

• AV‑Vertrag nach Art. 28 DSGVO mit klaren TOMs, Subprozessor‑Kette, Audit‑Rechten und Löschkonzept.

• Verbot/Begrenzung von Training mit Betreiber-/Mitarbeiterdaten ohne explizite schriftliche Freigabe; getrennte Umgebungen (Prod/Test).

• Regeln zu Drittlandtransfers und Transparenz zu Datenflüssen.

• Verpflichtung zur Unterstützung der Arbeitgeberpflichten: Informationsmaterial für Beschäftigte, Erklärbarkeit/Transparenz, Reporting‑Funktionen, Deaktivierung von „verdeckter Leistungsüberwachung“.

• Use‑Case‑Register (Zweck, Daten, Automationsgrad, Betroffene, Rechtsgrundlagen).

• Risikoklassifizierung nach KI‑VO inkl. Verbotsscreening und Annex‑III‑Check.

• DSFA‑Standardprozess für KI‑Use‑Cases mit hohem Risiko, inkl. Video/Biometrie.

• Human‑Oversight‑SOPs: Wer darf was entscheiden, wann muss ein Mensch übernehmen, wie wird abgeschaltet.

• Qualitäts-/Bias‑/Richtigkeitskontrollen (insb. bei Generativer KI: Halluzinations‑, Quellen‑ und Aktualitätskontrollen).

• Security‑Baseline (ISMS/IT‑Grundschutz‑Orientierung, Patch‑/Vulnerability‑Management, Segmentierung in OT/ICS).

• Nachweisführung („Compliance Evidence“): Logs, Abnahmen, Schulungen (AI Literacy), Betriebsvereinbarungen, Auditberichte.

Damit entsteht ein belastbarer „Audit‑Trail“, der sowohl behördliche Nachfragen (KI‑VO/DSGVO) als auch zivilrechtliche Sorgfaltsnachweise (Betreiberverantwortung/Verkehrssicherung/Arbeitsschutz) unterstützt.