Sicherheitsroboter IT-Anbindung: Leitfaden für IT/OT

Sicherheitsroboter sind keine Insellösungen. Wer sie wie autonome Spielzeuge betreibt, verstößt gegen NIS-2 Artikel 21 und §8a BSIG. Die Sicherheitsroboter IT-Anbindung entscheidet, ob ein Roboter den Posten ersetzt oder zur zusätzlichen Lärmquelle für den Leitstand wird. Dieser Text beschreibt die Schnittstellen, Protokolle und Netzwerkanforderungen, die ein IT-Leiter mit seinem OT-Verantwortlichen vor der Beschaffung klären muss.

Sicherheitsroboter IT-Anbindung: Was integriert werden muss

Fünf Integrationspunkte sind verpflichtend, nicht optional.

• Videostream über RTSP, ONVIF Profile S und Profile T in bestehende VMS-Plattformen. Milestone XProtect, Genetec Security Center und Qognify VMS sind die drei verbreiteten Systeme im DACH-Markt. Der Roboter erscheint dort als mobile Kamera mit Geo-Koordinaten.
• Event-Stream in das SIEM. Übliche Ziele sind Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel und Wazuh. Transport per MQTT, Webhook oder syslog, je nach SIEM-Konnektor.
• Zugangskontrolle. Schnittstellen zu Lenel OnGuard, Bosch Access Management System und Siemens SiPass ermöglichen Türfreigaben entlang der Patrouillenroute sowie Tour-Trigger bei Kartendurchzug.
• Leitstand-Anbindung nach ISO 22320 für Alarmübergabe an PSIM oder NSL-Gateway. Ohne strukturierte Eskalation bleibt der Roboter ein Datenproduzent ohne Empfänger.
• Identitätsmanagement aus Active Directory via SAML 2.0 oder OpenID Connect. Lokale Benutzerkonten am Roboter-Dashboard sind ein Auditbefund, kein Betriebsmodell.

Wer eines dieser fünf Felder leer lässt, verschiebt das Compliance-Problem in den nächsten Audit. Details zur Sensorebene: QR-2 Sensorprofil für 24/7-Außenpatrouille.

Netzwerkarchitektur: OT/IT-Trennung nach IEC 62443

Ein Sicherheitsroboter gehört nicht ins Office-VLAN. Punkt.

• Dediziertes VLAN auf Layer 2, isoliert vom Produktivnetz. Ausgehende Verbindungen ausschließlich über ein Application-Gateway, das Protokolle terminiert und re-initiiert.
• Purdue Level 3.5 DMZ als Datendrehscheibe zu VMS und SIEM. Keine direkte Verbindung vom Roboter ins Office-Netz, keine direkte Verbindung in die Cloud ohne Proxy.
• 5G-Standalone Slice oder privates LTE als primärer Bearer. WLAN nur als Fallback, weil 802.11-Roaming an Hallenkanten reproduzierbar versagt. Der Bearer-Wechsel muss im Roboter-Stack getestet sein, nicht erst beim Kunden.
• mTLS mit zertifikatsbasierter Authentifizierung. Statische API-Keys im Feld sind 2025 nicht mehr verhandelbar. Zertifikatsrotation läuft automatisiert, dokumentiert im SLA.
• Egress-Whitelisting auf der Firewall, dokumentiert pro Roboterserie (QR-1, QR-2, QR-3). Jede neue Firmware bringt eine aktualisierte Liste der zulässigen Ziel-FQDNs und Ports.

Die Architektur folgt IEC 62443-3-3. Wer KRITIS-Betreiber ist, prüft die Zonierung gegen das Anforderungsprofil unter KRITIS-Anforderungen für Betreiber.

Datenflüsse und Protokolle im Detail

Konkrete Zahlen, keine Marketing-Folien.

• Live-Video: RTSP über TLS, H.265-Codec. Bandbreite 2–6 Mbit/s pro Stream je nach Auflösung (1080p bis 4K); Wert basiert auf H.265-Referenzmessungen gemäß ITU-T H.265. Bei drei Robotern pro Standort plant der Netzwerker mit 18 Mbit/s Peak im Uplink, Headroom inklusive.
• Telemetrie: MQTT 3.1.1 mit QoS 1, JSON-Payload. Topic-Hierarchie nach Schema site/{standort}/robot/{seriennummer}/{kanal}. So bleibt die ACL pro Mandant sauber trennbar.
• Alarmereignisse: Webhook POST mit HMAC-SHA256-Signatur im Header. Retry-Logik mit exponential backoff bis 5 Minuten, dann Eskalation auf sekundären Endpunkt. Idempotenz-Key verhindert Doppelalarme.
• Logaggregation: syslog RFC 5424 über TLS in das zentrale SIEM. Mindestaufbewahrung 90 Tage; für KRITIS-Pflichtnachweise nach §8a BSIG meist 12 Monate vertraglich vereinbart.
• LiDAR-Punktwolken beim QR-3 mit LiDAR und Drohnenerkennung: Verarbeitung lokal auf der Roboter-GPU. In die Cloud gehen Metadaten (Objektklasse, Bounding Box, Zeitstempel, Konfidenz), nicht die Rohpunktwolke. Das ist ein klares Entscheidungskriterium für Werkleiter und Datenschutzbeauftragte. Keine Geometriedaten der Anlage verlassen das Werksgelände.

Diese Trennung von Roh- und Metadaten ist die wichtigste Architekturentscheidung im Stack. Sie wird bei Vertragsabschluss schriftlich fixiert.

NIS-2 und KRITIS-Anforderungen an die Integration

Die Sicherheitsroboter IT-Anbindung steht unter zwei Regelwerken: NIS-2 für die Cybersicherheit, KritisV und das künftige KRITIS-Dachgesetz für die physische Schutzpflicht.

• Artikel 21 NIS-2 verlangt Risikomanagement für Lieferketten, das vernetzte Robotersysteme ausdrücklich einschließt. Der Roboter ist Asset und Lieferant zugleich.
• Vorfallmeldung binnen 24 Stunden als Frühwarnung, 72 Stunden Erstmeldung an das BSI über die MeldeWeb-Schnittstelle, gemäß Art. 23 NIS-2. Das gilt für sicherheitsrelevante Vorfälle, die den Roboter, das Backend oder die Patrouillendaten betreffen.
• Asset-Inventar nach BSI IT-Grundschutz CON.7. Jeder Roboter wird mit MAC-Adresse, Firmware-Stand, Verantwortlichem und Standort geführt. Excel reicht, eine CMDB-Anbindung ist sauberer.
• Patch-Management: SLA für kritische CVEs unter 7 Tagen gemäß BSI TR-03183, dokumentiert im Wartungsvertrag. Wer dieses SLA nicht im Anbietervergleich abfragt, reicht es im ersten Audit nach.
• Penetrationstests einmal jährlich, Ergebnisse Teil der KRITIS-Nachweispflicht nach §8a BSIG. Die KritisV regelt Schwellenwerte und Pflichten. Der Entwurf des KRITIS-Dachgesetzes ergänzt die physische Schutzdimension. Operative Hinweise gibt das BBK.

Eine kompakte Übersicht der Pflichten steht unter NIS-2 Compliance-Anforderungen. Wer die BBK-Meldewege noch nicht eingerichtet hat, folgt der BBK-Registrierung Schritt für Schritt.

Identität, Zugriff und Datenschutz

Der Datenschutz ist nicht der Gegner der IT-Anbindung. Er ist Teil davon.

• Rollenmodell mit vier Rollen: Operator, Supervisor, Auditor, Wartung. Berechtigungen sind getrennt im Roboter-Dashboard, Vergabe über die zentrale Identität. Operator sieht Live-Stream und Quittierungen, Auditor sieht Logs, Wartung sieht Diagnose, keiner sieht alles.
• Audit-Log unveränderlich. Entweder WORM-Speicher oder append-only Datenbank mit kryptographischer Verkettung. Aufbewahrung: 5 Jahre. Grundlage sind KRITIS-Nachweispflicht und arbeitsrechtliche Verjährungsfristen.
• DSGVO Art. 35 verlangt eine Datenschutz-Folgenabschätzung vor Inbetriebnahme, sobald systematisch Personen erfasst werden. Die DSFA ist kein Akt, sondern eine Voraussetzung. Ohne DSFA kein Go-Live.
• Maskierung von Gesichtern und Kennzeichen im Live-Stream ist konfigurierbar. Entmaskierung erfolgt nur im Vier-Augen-Prinzip, dokumentiert mit Begründung im Audit-Log. Standardbetrieb: alles maskiert, Aufzeichnung verschlüsselt.
• Betriebsratsvereinbarung nach §87 BetrVG vor Roll-out. Wer den Betriebsrat erst zwei Wochen vor Inbetriebnahme informiert, verliert vier Wochen. Muster für die Vereinbarung liegen im Kundenportal.

Die Servicerobotik folgt der Sicherheitsgrundnorm EN ISO 13482. Diese Norm ist für persönliche Assistenzroboter formuliert und dient mangels einer dedizierten Norm für Sicherheitsroboter als Referenz.

Implementierungsplan: 14 Tage von Kickoff bis Go-Live

Ein realistischer Zeitplan, wenn die Vorbedingungen erfüllt sind: VLAN-Designentscheidung getroffen, VMS-Lizenz vorhanden, Betriebsrat informiert.

• Tag 1–3: Netzwerk-Assessment vor Ort. VLAN-Konfiguration auf Switches, Firewall-Regeln in der Change-DB dokumentiert und vom Change Advisory Board freigegeben. Bearer-Tests für 5G und WLAN-Fallback an den kritischen Routenabschnitten.
• Tag 4–6: VMS-Integration mit einer Testkamera, bevor der Roboter live geht. Event-Mapping ins SIEM mit drei Beispielszenarien: Türöffnung außerhalb Schicht, Personendetektion in Sperrzone, Verbindungsabbruch über 60 Sekunden. Korrelationsregeln dokumentiert.
• Tag 7–9: Roboter-Onboarding. Patrouillenrouten in der 3D-Karte angelegt, Geofences und Sperrzonen definiert. Probefahrten ohne Alarmweiterleitung, um Fehlalarme zu kalibrieren.
• Tag 10–12: Eskalationsketten zum Leitstand getestet. NSL-Anbindung mit Live-Alarmen geprüft, einschließlich Quittierungszeit und Rückkanal. Vertretungsregeln dokumentiert.
• Tag 13–14: Abnahmetest mit unterschriebenem Protokoll. Schulung Operator (4 Stunden) und Supervisor (8 Stunden, inklusive Auswertung und Audit-Log-Recherche). Übergabe in den Regelbetrieb.

Wer nach 14 Tagen nicht live ist, hat in der Regel ein Firewall-Freigabeproblem oder eine offene Betriebsratsfrage, nicht ein technisches Problem mit dem Roboter.

Wirtschaftlichkeit und Betriebsmodell

Die Sicherheitsroboter IT-Anbindung kostet Geld in der Einrichtung und spart Geld im Betrieb. Konkrete Zahlen:

• RaaS-Modell ab 3.200 €/Monat pro Roboter (Listenpreis Stand Q1 2025, Details unter Robotics-as-a-Service Modell). Inkludiert Wartung, Firmware-Updates, 24/7-Support und SIM-Datenvolumen. Hardware bleibt Eigentum des Anbieters, der Betreiber zahlt für Verfügbarkeit.
• Vergleich zum Wachposten: 15.000–25.000 €/Monat für 24/7-Besetzung in DACH, abhängig vom Manteltarifvertrag und Zuschlägen (Quelle: BDSW Lohnstrukturerhebung 2024). Der Roboter ersetzt nicht den Menschen vollständig, er übernimmt die Streife. Eine vollständige Rechnung steht im TCO-Vergleich Wachschutz versus Robotik.
• Integration in die bestehende Konsole reduziert Schulungsaufwand. Wenn der Operator den Roboter im selben Milestone-Client sieht wie die Festkameras, fällt die Lernkurve auf wenige Stunden.
• Skalierung modular. Ein weiterer Roboter ist binnen 48 Stunden einsatzbereit, die IT-Anbindung ist identisch. Das gilt für QR-1, QR-2 und QR-3, weil sie dieselben Schnittstellen sprechen.
• Vertragsmindestlaufzeit 24 Monate. Exit-Klauseln sind im Vertrag dokumentiert. Kein Vendor-Lock-in: offene Protokolle (RTSP, ONVIF, MQTT, syslog, SAML) erlauben den Anbieterwechsel. Die Backend-Infrastruktur bleibt unverändert.

Was funktioniert: Roboter für Streife in großflächigen, dünn besetzten Arealen (Logistikhöfe, Solarparks, Werksgelände nachts). Was nicht funktioniert: Roboter als Ersatz für Posten an einer Pforte mit Publikumsverkehr. Diese Trennung muss vor der Beschaffung feststehen. Sonst entstehen Erwartungen, die kein Anbieter erfüllen kann.

Der nächste Schritt ist die Architekturskizze für Ihren Standort: VLAN-Plan, Firewall-Regeln, VMS- und SIEM-Konnektoren, Eskalationsketten. Wir prüfen die Vorbedingungen in einem 60-minütigen Workshop und liefern ein dokumentiertes Integrationskonzept. Termin vereinbaren unter Integrationsworkshop buchen.