Sicherheitsroboter SLA Reaktion: Vertragspflicht

Ein Service Level Agreement für Sicherheitsroboter ist kein Marketingdokument. Es ist die einzige belastbare Grundlage, auf der ein Sicherheitsleiter im Schadensfall gegenüber Vorstand, Versicherer und Aufsicht Position halten kann. Wer den Vertrag mit "schneller Reaktion" und "hoher Verfügbarkeit" unterschreibt, hat im Zweifel nichts in der Hand. Dieser Beitrag liefert die Zahlen, Messpunkte und Vertragsbausteine, die in einem operativ tragfähigen SLA stehen müssen.

Sicherheitsroboter SLA Reaktion: Was im Vertrag stehen muss

Ein verhandlungsfähiges SLA für Patrouillenroboter besteht aus fünf harten Werten, jeder mit definiertem Messpunkt.

• Detektionszeit: maximal 8 Sekunden vom Sensor-Trigger bis zur Klassifikation im Lagebild. Gemessen wird zwischen Zeitstempel des Rohsignals und Zeitstempel des klassifizierten Events im Operator-Dashboard.
• Alarmweiterleitung an die NSL: maximal 30 Sekunden ab bestätigter Detektion. Gemessen wird zwischen Klassifikation und Ticket-Eingang in der Notruf- und Serviceleitstelle.
• Eskalation an Einsatzkräfte: dokumentierter Pfad mit Namen, Telefonnummern und Backup-Kontakt. Keine generischen Verteiler. Jeder Eintrag mit Vertretung und Erreichbarkeitsfenster.
• Verfügbarkeit der Patrouilleneinheit: 98,5 Prozent pro Monat, gemessen über Telemetrie. [Quelle/Beleg einfügen] Planmäßige Wartungsfenster werden separat ausgewiesen und nicht auf die Verfügbarkeit angerechnet.
• Wiederherstellung nach Ausfall: Ersatzgerät innerhalb 48 Stunden vor Ort, Software-Rollback unter 4 Stunden.

Diese fünf Werte gehören in den Hauptvertrag, nicht in eine Anlage, die später angepasst werden kann. Wer das Robotics-as-a-Service Modell bucht, kauft genau diese Zusagen, nicht das Gerät.

Warum Standard-SLA aus dem Wachschutz nicht ausreichen

Klassische Wachdienst-SLA messen Anfahrtszeit. Der Streifenwagen ist in 15 Minuten am Tor, die Posten-Übergabe dauert 90 Sekunden, der Bericht liegt am nächsten Morgen vor. Diese Logik funktioniert für menschliche Eskalation, nicht für sensorbasierte Detektion.

Robotik verschiebt die Latenz vom Menschen zum Sensor. Die kritische Frage ist nicht mehr "Wie schnell ist der Wachmann am Ereignisort", sondern "Wie schnell erkennt das System ein Ereignis und übergibt es an einen verifizierten Operator". Das erfordert andere Messpunkte: Sensorzeitstempel, Klassifikationsdauer, Verifikationszeitfenster.

Die Falschalarmrate gehört in den SLA. In den meisten Angeboten taucht sie nur im Werbeprospekt auf. Ein Roboter mit 12 Falschalarmen pro Nacht und exzellenter MTTD-Statistik ist operativ wertlos: die NSL stumpft ab, echte Vorfälle gehen im Rauschen unter.

Die BDSW-Branchendaten weisen Personalkosten als dominanten Kostenfaktor im Wach- und Sicherheitsdienst aus. Reaktionsqualität wird in der klassischen Kalkulation nicht abgebildet, weil sie schwer messbar war. Bei RaaS ändert sich das: Sensor-Uptime und Datenintegrität müssen getrennt von der reinen Personalverfügbarkeit geregelt werden. Wer beides vermischt, bekommt Pauschalreports ohne Aussagekraft. Den vollständigen Kostenrahmen liefert der TCO-Vergleich Wachschutz.

Kennzahlen, die jede Sicherheitsleitung im SLA verankert

Operativ relevant sind genau fünf KPI. Alles andere ist Beiwerk.

1. MTTD (Mean Time To Detect): Zielwert unter 10 Sekunden für Personenerkennung im Perimeter. Bei Fahrzeugen unter 6 Sekunden, bei stehenden Objekten unter 30 Sekunden.
2. MTTA (Mean Time To Acknowledge): unter 60 Sekunden bis zur NSL-Bestätigung. Das ist die Zeit zwischen Alarm-Eingang und qualifizierter menschlicher Verifikation.
3. MTTR (Mean Time To Recover): Gerätetausch unter 48 Stunden, Software-Rollback unter 4 Stunden. Diese beiden Werte gehören getrennt ausgewiesen, weil sie unterschiedliche Auslöser haben.
4. False Positive Rate: dokumentiert pro Quartal. Schwellwert vertraglich fixiert, etwa weniger als 5 Falschalarme pro 1.000 Patrouillenstunden bei Perimetereinsatz.
5. Patrouillen-Abdeckung: Prozent der geplanten Wegpunkte pro 24-Stunden-Zyklus. Realistisch 95 Prozent, gemessen über GPS- und Lokalisierungstelemetrie.

Wichtig ist die Trennung zwischen Verfügbarkeits-SLA und Reaktions-SLA. Ein Roboter kann technisch verfügbar sein (Akku voll, Sensoren grün) und trotzdem operativ versagen (Klassifikation falsch, Eskalation nicht ausgelöst). In der Praxis werden beide Dimensionen ständig vermischt. Im Vertrag müssen sie getrennt geregelt und einzeln pönalisiert sein.

Eskalationsketten: vom Sensor bis zum Werkschutzleiter

Eine vertragsfeste Eskalationskette hat vier Stufen, jede mit eigenem Zeitstempel und manipulationssicherem Logging.

• Stufe 1: automatische Klassifikation und Live-Bild an die Leitstelle. Auslöser: Sensor-Trigger plus Mindestkonfidenz der Klassifikation (typisch 0,75).
• Stufe 2: menschliche Verifikation in der NSL innerhalb 30 Sekunden. Der Operator bestätigt oder verwirft. Verwirft er, wird das Ereignis trotzdem geloggt.
• Stufe 3: Anruf bei diensthabendem Werkschutz oder Polizei nach Eskalationsmatrix. Die Matrix definiert pro Ereignistyp den Adressaten und das Zeitfenster.
• Stufe 4: schriftliche Vorfallsdokumentation innerhalb 4 Stunden nach Ereignis. Format: maschinenlesbar, exportierbar, an die internen Compliance-Systeme anschlussfähig.

Jede Stufe wird mit Zeitstempel im System protokolliert und manipulationssicher abgelegt. Bei QR-2 für 24/7-Außenperimeter läuft die Stufe-1-Klassifikation direkt auf dem Gerät, die Stufen 2 bis 4 in der NSL. Bei QR-3 mit LiDAR und Drohnenerkennung kommt eine zusätzliche Sensorebene hinzu, die in der Eskalationsmatrix separat priorisiert werden muss.

Die häufigste Lücke in bestehenden Verträgen: Stufe 3 ist als Telefonliste hinterlegt, ohne Vertretungsregel und ohne Eskalation bei Nichterreichbarkeit. Wer um 03:47 Uhr den ersten Kontakt nicht erreicht, hat ohne Backup-Kontakt einen Vertrag, der vor Gericht nicht trägt.

SLA-Anforderungen unter NIS-2 und KRITIS-Dachgesetz

Die NIS-2-Richtlinie schreibt Erstmeldung sicherheitsrelevanter Vorfälle binnen 24 Stunden vor. Sicherheitsroboter sind in diesem Kontext eine technische Maßnahme nach Artikel 21 und müssen die Meldekette nachweisbar unterstützen. Das bedeutet konkret: Das SLA muss Logs liefern, aus denen sich Detektionszeit, Verifikationszeit und Eskalationszeit eindeutig ablesen lassen. Das Format muss die internen Meldeprozesse direkt befüttern.

Das KRITIS-Dachgesetz verlangt von Betreibern dokumentierte physische und organisatorische Schutzmaßnahmen. Die Wirksamkeit ist nachzuweisen. Ein SLA, das nur Status-Meldungen ("System läuft") liefert, erfüllt diese Anforderung nicht. Verlangt sind Audit-fähige Logs: Ereignis-ID, Zeitstempel, Klassifikation, Eskalationspfad, abschließende Bewertung.

Die KritisV regelt die Pflichten von Betreibern kritischer Infrastrukturen einschließlich Nachweispflichten. Auch hier gilt: ohne strukturierte Daten aus dem Robotik-System keine prüffähige Dokumentation. Die Vorstandshaftung greift bei einem SLA-Bruch, der zu einem nicht oder verspätet gemeldeten Vorfall führt. Die juristischen Mechanismen sind in Vorstandshaftung unter NIS-2 im Detail dargestellt. Eine Einordnung der Gesamtanforderungen findet sich in der NIS-2-Compliance im Überblick.

Als technische Referenz für mobile Servicerobotik dient EN ISO 13482, die Sicherheitsanforderungen für persönliche Pflegeroboter definiert. Sie ist nicht direkt einschlägig, liefert aber den Argumentationsrahmen für Risikobeurteilungen.

Pönalen und Service-Gutschriften: was marktüblich ist

Ohne Pönalen ist ein SLA eine Absichtserklärung. Marktüblich sind gestufte Service-Gutschriften, gekoppelt an die monatliche Verfügbarkeit.

• Service-Gutschrift von 10 Prozent der Monatsrate bei Verfügbarkeit unter 98 Prozent.
• Gutschrift von 25 Prozent bei Verfügbarkeit unter 95 Prozent in einem Monat.
• Sonderkündigungsrecht ab drei aufeinanderfolgenden Monaten mit SLA-Bruch.
• Pauschalierter Schadenersatz bei nicht erfolgter Eskalation: vertraglich definieren, typisch 5.000 bis 25.000 Euro pro Ereignis, abhängig vom Standortrisiko. [Quelle/Beleg einfügen]
• Keine Pönale ohne klare Messmethodik und beidseitig zugänglichem Reporting.

Die Höhe der Pönale muss zum Schadensrisiko des Standorts passen. Eine pauschale 10-Prozent-Klausel bei einem KRITIS-Standort mit potenziellem Achtstellenschaden ist symbolisch. Umgekehrt sind sechsstellige Vertragsstrafen für einen Logistikhof unverhältnismäßig und werden im Streitfall nicht durchgesetzt.

Pönalen brauchen einen Auslöser. Der Auslöser ist die dokumentierte Abweichung im monatlichen SLA-Report, nicht eine subjektive Einschätzung des Sicherheitsleiters.

Messtechnik: wie SLA-Erfüllung tatsächlich nachgewiesen wird

Ein SLA ist nur so gut wie seine Messmethodik. Telemetrie aus dem Roboter liefert die Sensorzeitstempel, die NSL liefert die Bearbeitungszeitstempel. Beide Datenquellen müssen per NTP auf Millisekundenebene synchronisiert sein. Sie laufen in einem gemeinsamen Reporting zusammen.

• Monatlicher SLA-Report mit allen Vorfällen, Reaktionszeiten und Abweichungen. Format strukturiert, nicht PDF-only.
• Dritte-Partei-Audit auf Anforderung des Kunden, mindestens einmal jährlich. Auditor wird vom Kunden benannt, Kosten je nach Vertrag geteilt oder vom Anbieter getragen.
• Datenexport in offenen Formaten (JSON, CSV), keine proprietären Black-Box-Reports.
• Kunden-Dashboard mit Echtzeit-KPIs und historischer Trendanalyse. Lesezugriff für mindestens drei benannte Personen pro Standort.

Quarero stellt dieses Dashboard standardmäßig bereit. Es zeigt MTTD, MTTA, MTTR, False Positive Rate und Patrouillen-Abdeckung tagesgenau und historisiert. Wer für die monatliche KPI-Sitzung keine eigenen Zahlen aus dem System ziehen kann, hat den falschen Anbieter.

Vertragsverhandlung: die häufigsten Fehler

Aus über 200 begleiteten RaaS-Verträgen wiederholen sich fünf Fehler. [Quelle/Beleg einfügen]

1. SLA ohne Messpunkt. "Schnelle Reaktion", "hohe Verfügbarkeit", "branchenübliche Qualität" sind keine vertraglichen Zusagen. Jeder Wert braucht Definition, Messpunkt und Messintervall.
2. Pönalhöhe ohne Bezug zum Schadensrisiko des Standorts. Eine Risikoanalyse vor Vertragsschluss bestimmt die sinnvolle Pönalhöhe, nicht der Standardvertrag des Anbieters.
3. Fehlende Regelung für planmäßige Wartungsfenster. Wartung muss angekündigt, befristet und gesondert ausgewiesen sein. Andernfalls höhlt quartalsweise "geplante Wartung" die 98,5-Prozent-Zusage aus.
4. Keine Definition der Eskalationshoheit im Ausfall. Wenn der Roboter ausfällt und die NSL keinen Standortzugriff hat: wer übernimmt? Welcher Wachdienst springt ein? Diese Übergaberegelung muss schriftlich fixiert sein.
5. Höhere Gewalt nicht klar eingegrenzt. Ein zu weit gefasster Force-Majeure-Paragraf hebelt jeden SLA-Anspruch aus. Streik, Lieferengpässe und Cyberangriffe sind keine höhere Gewalt im engeren Sinne. Die Klausel muss eng definiert sein.

Ein sechster, weniger beachteter Punkt: das Reporting-Format muss vertraglich festgelegt sein. Wer akzeptiert, dass der Anbieter "in geeigneter Form" berichtet, bekommt am Ende ein PDF, das keine maschinelle Auswertung erlaubt.

Nächster Schritt

Ein operativ tragfähiges SLA entsteht nicht aus dem Standardvertrag, sondern aus einer Risikoanalyse des konkreten Standorts und einer Verhandlung über die hier dargestellten Kennzahlen. Wer den Schritt vom klassischen Wachschutz zum sensorgestützten Patrouilleneinsatz geht, verhandelt nicht über Stundensätze, sondern über Reaktionszeiten, Verfügbarkeit und Logqualität.

Die vollständigen Vertragsbausteine, KPI-Definitionen und ein Musterreport sind Teil des Robotics-as-a-Service Modells. Wer die Werte für einen konkreten Standort durchrechnen will, kann eine Pilotanfrage stellen.