KI-Trainingsdaten Sicherheit: Was CISOs prüfen müssen

Wenn ein Sicherheitsroboter eine Person übersieht, ist das ein Detektionsfehler. Wenn er eine Person fälschlich als Bedrohung markiert, ist das ein Prozessfehler. Beide Fehler haben dieselbe Ursache: die Trainingsdaten. Dieser Beitrag erklärt für CISOs und Sicherheitsleiter in KRITIS-Betrieben, woher die Daten kommen, wie sie geprüft werden und welche vertraglichen Punkte vor Unterschrift geklärt sein müssen.

KI-Trainingsdaten Sicherheit: Warum die Datenbasis über die Detektionsqualität entscheidet

Modelle für Personen- und Fahrzeugerkennung erreichen unter realen Bedingungen erst dann eine False-Negative-Rate unter 2 Prozent, wenn pro Objektklasse mindestens 50.000 annotierte Frames vorliegen. Darunter steigt die Fehlerquote nicht linear, sondern überproportional in Randbedingungen: Dämmerung, Regen, Teilverdeckung.

Schlechte Trainingsdaten produzieren das umgekehrte Problem. Jeder Fehlalarm bindet im Schnitt 18 Minuten Interventionsleitstand-Zeit für Sichtung, Bewertung, Eskalation und Dokumentation. Bei einer Fehlalarmrate von 12 Prozent auf einem Standort mit 200 nächtlichen Detektionsereignissen entstehen 7,2 Personenstunden Leitstandlast pro Nacht. Das ist der eigentliche Kostentreiber, nicht die Hardware.

Quarero trennt deshalb strikt zwischen Pre-Training im Werk und Site-Adaption am Einsatzort. Das Pre-Training liefert die Objektklassen-Basis. Die Site-Adaption über vier Wochen kalibriert die Anomalieerkennung auf die standortspezifische Normalität. Beides ist getrennt versioniert und getrennt prüfbar.

Trainingsdaten-Provenienz ist nach EU AI Act Artikel 10 für Hochrisiko-KI-Systeme dokumentationspflichtig. Quellen, Annotationsverfahren, Bias-Tests und Repräsentativität müssen nachweisbar sein. Kein Modell verlässt unser Werk ohne signiertes Datenblatt zu diesen Punkten. Wer keines bekommt, soll auch nicht kaufen.

Nächster Schritt: technische Spezifikation QR-2 Außenpatrouille mit thermischer Personenerkennung.

Datenquellen: Öffentliche Datasets, synthetische Generierung und Kundendaten

Die Basismodelle nutzen drei Quellen für allgemeine Objektklassen: COCO für Personen und Fahrzeuge, BDD100K für Outdoor-Szenen mit Tageszeit- und Wetterannotation, ImageNet für Feinklassen. Thermische Datasets werden lizenziert von FLIR eingebracht. Diese öffentlichen Quellen decken etwa 40 Prozent der Trainingsbasis ab.

Die übrigen 60 Prozent stammen aus synthetischer Generierung. Unity- und Unreal-Pipelines erzeugen Nachtsicht-, Regen-, Nebel- und Gegenlichtszenarien in einer Menge und Variabilität, die mit realen Aufnahmen nicht erreichbar wäre. Synthetische Daten haben den Vorteil pixelgenauer Labels und einstellbarer Edge Cases. Sie haben den Nachteil eines Realitäts-Gaps, der durch reale Validierungsdaten geschlossen werden muss.

Kundendaten fließen nicht in das Basistraining. Wenn ein Kunde explizit zustimmt, werden Site-Daten ausschließlich pseudonymisiert und ausschließlich für das Modell dieses einen Standorts genutzt. Sie wandern nicht in einen sektorübergreifenden Pool. Das ist der häufigste Einwand von CISOs, und er ist berechtigt: Wir betreiben kein Federated Learning über Kundengrenzen.

Drohnen-Signaturen für QR-3 für KRITIS mit LiDAR und Drohnendetektion stammen aus einer eigenen Messkampagne über 14 Monate mit 47 Drohnenmodellen. Audio-Trainingsdaten für Schussdetektion und Glasbruch werden über Foley-Aufnahmen in akustisch kontrollierten Räumen erzeugt, nicht aus realen Vorfällen. Das ist ein bewusster Verzicht auf Realdaten, weil reale Schuss- und Einbruchssignaturen ethisch und rechtlich nicht beschaffbar sind.

DSGVO und KI-Verordnung: Rechtsrahmen für Sicherheitsroboter-Trainingsdaten

Personenerkennung ist nach DSGVO Art. 9 keine biometrische Identifikation, solange keine Wiedererkennung über Sitzungen hinweg stattfindet. Quarero-Modelle erzeugen Personen-Bounding-Boxen mit Klassifikation Person/nicht-Person, ohne Identitätsattribute, ohne Gesichtsmerkmale, ohne Gangmustererkennung. Es gibt keine Gesichtserkennung im System. Das ist eine Architekturentscheidung, keine Konfigurationsoption.

Der EU AI Act stuft Perimeterüberwachung als Hochrisiko-System ein, wenn sie öffentliche Räume umfasst. Für umfriedete Werksgelände, Industrieparks und KRITIS-Standorte gilt diese Einstufung nicht automatisch, weil keine öffentliche Zugänglichkeit vorliegt. Die Risikobewertung muss pro Standort dokumentiert werden. Bei gemischten Geländen mit publikumszugänglichen Bereichen (Empfang, Besucherparkplatz) gelten die Hochrisiko-Pflichten für diese Zonen.

Der Auftragsverarbeitungsvertrag mit Quarero regelt jede Verwendung von Site-Daten für Modellverbesserung explizit als opt-in. Standardeinstellung ist: Daten bleiben am Standort, nichts wandert in unsere Trainingspipeline. Wer Modellverbesserung mit eigenen Daten wünscht, aktiviert dies vertraglich und kann es jederzeit widerrufen.

Löschfristen sind technisch erzwungen: Roh-Videodaten 72 Stunden auf dem Roboter, Metadaten zu Alarmereignissen 90 Tage, anonymisierte Statistikdaten 24 Monate. Modell-Updates werden nach 30 Tagen aus der aktiven Trainingspipeline entfernt. Die Maschinenverordnung EU 2023/1230 regelt zusätzlich die Sicherheitsanforderungen an KI-gestützte autonome Systeme. EN ISO 13482 spezifiziert Sicherheitsanforderungen für mobile Servicerobotik als Referenzrahmen (ISO 13482).

Weiterführend zur Pflichtenlage: KRITIS-Dachgesetz Checkliste 2026.

Annotation und Qualitätssicherung: Wie Quarero Trainingsdaten labelt

Annotation erfolgt in Deutschland durch sicherheitsüberprüftes Personal. Wir nutzen keine Crowdsourcing-Plattformen wie Mechanical Turk oder Scale AI für Trainingsdaten in Sicherheitskontexten. Der Grund ist banal: Wer Bilder von Werksgeländen, Patrouillenrouten und Sicherheitsinfrastruktur sieht, sollte überprüft sein. Das kostet etwa Faktor 4 gegenüber Offshore-Annotation und ist nicht verhandelbar.

Jede Annotation läuft im Vier-Augen-Prinzip. Edge Cases (Personen mit ungewöhnlichem Gepäck, Wartungspersonal in PSA, Bauarbeiter mit Werkzeug) gehen an eine dritte Prüfinstanz, die wöchentlich neue Edge-Case-Kategorien definiert. Die Annotationsfehlerrate wird wöchentlich gemessen, Zielwert unter 0,8 Prozent. Bei Überschreitung steht die Pipeline bis zur Ursachenanalyse.

Bias-Tests sind vor jedem Modell-Release verpflichtend. Die Detektionsrate muss über alle Demografieklassen (Geschlecht, geschätzte Altersgruppe, Hautton nach Fitzpatrick-Skala) innerhalb von 3 Prozent liegen. Liegt die Spreizung höher, wird der Datensatz neu gewichtet und das Training wiederholt. Das ist aufwändig und verzögert Releases, ist aber sowohl rechtlich (AI Act Art. 10) als auch operativ erforderlich.

Adversarial Testing prüft synthetisch generierte Tarnungs- und Verdeckungsszenarien vor Produktivfreigabe. Dazu gehören Anti-Detection-Muster auf Kleidung, Mehrfachverdeckung und Wettereffekte, die menschliche Konturen verfremden.

Edge-Inferenz statt Cloud: Datenminimierung als Architekturprinzip

Die Inferenz läuft vollständig auf dem Roboter. NVIDIA Jetson Orin mit 275 TOPS bei QR-2 und QR-3 reicht für gleichzeitige RGB-Detektion, thermische Auswertung und Anomalieklassifikation in Echtzeit. Kein Videostream verlässt den Standort. Nur Metadaten (Klassifikation, Zeitstempel, Position) und Alarmframes werden an den Kundenleitstand übertragen.

Diese Architekturentscheidung hat Konsequenzen. Sie verhindert Cloud-basierte Analytik mit kontinuierlichen Streams, was manche Wettbewerber als Verkaufsargument nutzen. Sie reduziert dafür den Datenschutz-Angriffsvektor erheblich: Was nicht hochgeladen wird, kann nicht abgegriffen werden. Für KRITIS-Betriebe unter NIS-2 Compliance ist das die einfachere Risikobewertung.

Modellupdates werden signiert per Delta-Update verteilt. Der Roboter verifiziert die Signaturkette vor Anwendung. Unsignierte oder manipulierte Updates werden abgelehnt und gemeldet. Es gibt kein Federated Learning, jeder Standort bleibt datenseitig isoliert. Lokale Speicherung ist mit AES-256 verschlüsselt, Schlüsselrotation alle 90 Tage automatisch.

Standortadaption: Vier Wochen Site-Training nach Auslieferung

Phase 1 (Woche 1) ist regelbasiert, kein ML-Training. Geofencing wird konfiguriert, Patrouillenrouten werden angelernt, Ausschlusszonen werden definiert. Der Roboter operiert in dieser Phase mit den Werkseinstellungen und logged alle Detektionen für Phase 2.

Phase 2 (Woche 2 bis 3) ist das eigentliche Site-Training. Das System lernt erwartete Bewegungsmuster: Stapler-Routen, Mitarbeiter-Schichtwechsel, regulärer Lieferverkehr, Reinigungspersonal, externe Dienstleister mit ihren Zeitfenstern. Das ist kein neues Trainieren der Personen-Erkennung, sondern Kalibrierung der Anomalieklassifikation auf Basis der vorhandenen Detektionen.

Phase 3 (Woche 4) finalisiert die Anomalieerkennung. Die Fehlalarmrate sinkt typischerweise von 12 Prozent (Werksauslieferung) auf 1,8 Prozent (kalibriert). Das ist der Hauptgrund, warum ein Pilot über weniger als 30 Tage keine belastbare Aussage zur Detektionsqualität liefert. Wer einen 7-Tage-Pilot anbietet, zeigt die uncalibrierte Maschine.

Site-Daten bleiben physisch im Roboter und auf dem Kunden-NAS. Sie wandern nie in eine Quarero-Cloud. Bei Vertragsende werden alle Site-spezifischen Modellgewichte nachweislich gelöscht, das Löschprotokoll geht an den Kunden. Im Robotics-as-a-Service Modell ist diese Klausel Vertragsbestandteil, nicht Verhandlungspunkt.

Ergänzend: Perimeterschutz im Industriepark.

Risiken: Data Poisoning, Modell-Diebstahl und Adversarial Attacks

Data Poisoning ist der Versuch, durch manipulierte Trainings- oder Adaptionsdaten das Modellverhalten gezielt zu verschlechtern. Schutz dagegen: Der Update-Server signiert jedes Modell mit einem Hardware-Sicherheitsmodul. Der Roboter lehnt unsignierte oder mit ungültiger Signatur versehene Updates ab. Trainingsdaten-Eingang in die zentrale Pipeline läuft über mehrere Validierungsstufen mit statistischen Drift-Tests.

Modell-Diebstahl wird durch Trusted Execution Environment auf dem Jetson Orin adressiert. Modellgewichte werden im verschlüsselten Bereich gehalten und nicht im normalen Hauptspeicher entpackt. Physischer Zugriff auf den Roboter erlaubt keine Extraktion der Gewichte ohne Bruch des TEE, was nach aktuellem Stand kommerziell unwirtschaftlich ist.

Adversarial Patches sind das praktisch relevanteste Angriffsszenario. T-Shirts mit Anti-Detection-Mustern können bestimmte Modellgenerationen täuschen. Wir testen diese Angriffsklasse jedes Quartal mit kommerziell verfügbaren und akademisch publizierten Patches. Gegenmaßnahmen (Detection-Layer für die Patches selbst, Ensemble-Klassifikation) werden in regulären Modellupdates ausgerollt.

Die Trainingsdaten-Pipeline ist nach BSI IT-Grundschutz auditiert mit jährlicher externer Prüfung (BSI/BBK). Incident Response bei Verdacht auf Data Poisoning ist definiert: Rollback auf das letzte verifizierte Modell innerhalb von 4 Stunden, parallel forensische Analyse der Trainingspipeline der letzten 30 Tage.

Was Sicherheitsleiter vor Vertragsschluss prüfen sollten

Sechs Punkte gehören in jede Due Diligence vor Unterzeichnung eines RaaS-Vertrags für Sicherheitsroboter.

Erstens: Trainingsdaten-Datenblatt anfordern. Es muss Quellen, Annotationsstandort, Annotationsverfahren und Bias-Testergebnisse enthalten. Wer kein Datenblatt liefert, hat es entweder nicht oder will es nicht zeigen. Beides ist Ausschlusskriterium.

Zweitens: AVV-Anhang prüfen. Ist die Verwendung von Site-Daten für Modellverbesserung opt-in oder opt-out? Bei opt-out ist die Frage, was bei Stillschweigen passiert. Standard sollte opt-in sein.

Drittens: Klärung, ob Roh-Videodaten den Standort jemals verlassen. Die Antwort sollte Nein sein. Wenn doch (für Support-Fälle, Modelldiagnose), unter welchen Bedingungen, mit welcher Aufbewahrung und mit welcher Anonymisierung.

Viertens: Löschnachweis bei Vertragsende vertraglich zusichern lassen. Das Löschprotokoll soll alle standortspezifischen Modellgewichte, Site-Daten und Konfigurationen umfassen.

Fünftens: Pilot mit definierter False-Positive- und False-Negative-Messung über 30 Tage vereinbaren. Kürzere Piloten messen die unkalibrierte Maschine und produzieren bessere oder schlechtere Zahlen als der spätere Regelbetrieb. Eine ehrliche Messung braucht die volle Site-Adaption plus zwei Wochen Regelbetrieb.

Sechstens: Referenzkunden im gleichen Sektor zur Detektionsqualität befragen, nicht nur zum Vertriebsprozess. Die operativ relevante Frage ist: Wie viele Fehlalarme pro Nacht nach Monat 3? Wie viele bestätigte Detektionen pro Monat? Welche Edge Cases haben Probleme gemacht?

Für die wirtschaftliche Bewertung gegen klassischen Personalwachschutz hilft der TCO-Vergleich Wachschutz. Für eine konkrete Spezifikation Ihres Standorts und ein Datenblatt-Muster vereinbaren Sie ein technisches Vorgespräch über die Kontaktseite. Wir senden vorab den Standard-AVV-Anhang und ein Beispiel-Trainingsdaten-Datenblatt, damit Ihre Datenschutz- und Rechtsabteilung vor dem Gespräch parallel prüfen kann.