KRITIS und NIS-2 im Robotereinsatz: ein Praxisleitfaden

Sie planen Serviceroboter in einer Klinik, einem Versorger oder einer anderen regulierten Einrichtung? Dann entscheiden Sie nicht nur über einen Roboter, sondern über ein zusätzliches IT-System in einer Umgebung mit erhöhten Sicherheits- und Meldepflichten. KRITIS und NIS-2 verlangen keine bestimmte Robotermarke. Sie verlangen, dass Sie wissen, wo Daten liegen, wer Zugriff hat und wie Sie im Störfall reagieren.

Diese Verschiebung wird leicht übersehen. In der Beschaffung steht der Roboter im Vordergrund: Was kann er transportieren, wie zuverlässig fährt er, was kostet er? Aus regulatorischer Sicht ist der Roboter aber nur ein Endpunkt. Entscheidend ist, was hinter ihm steht – die Steuerungssoftware, die Schnittstellen zu Türen und Aufzügen, die Datenflüsse zu Hersteller-Clouds und die Frage, wer im Ernstfall die Verantwortung trägt. Wer das früh mitdenkt, vermeidet später teure Nachrüstungen.

Worum es bei KRITIS und NIS-2 geht

Die KRITIS-Regulierung verpflichtet Betreiber kritischer Infrastrukturen, Sicherheit nach dem Stand der Technik umzusetzen und erhebliche Störungen zu melden. Die NIS-2-Richtlinie erweitert den Kreis der betroffenen Einrichtungen und stellt Anforderungen an Risikomanagement, Lieferkettensicherheit, Vorfallsmeldung und an die Verantwortung der Leitung. Wie genau die Pflichten ausfallen, hängt von der nationalen Umsetzung und davon ab, ob Ihre Einrichtung in den Anwendungsbereich fällt. Diese Einordnung sollten Sie mit Ihren Sicherheits- und Rechtsverantwortlichen klären.

Für den Robotereinsatz ist der Kern überschaubar: Ein vernetzter Roboter wird Teil Ihrer Angriffsfläche und Ihrer Datenverarbeitung. Damit gelten dieselben Grundprinzipien wie für jedes andere System in einer regulierten Umgebung.

Bemerkenswert ist vor allem die Ausweitung des Anwendungsbereichs. NIS-2 erfasst deutlich mehr Einrichtungen als die Vorgängerregelung, und sie nimmt die Lieferkette ausdrücklich in den Blick. Ein Roboter, der von einem externen Dienstleister betrieben oder ferngewartet wird, ist genau ein solcher Lieferkettenbaustein. Hinzu kommt die persönliche Verantwortung der Leitungsebene: Geschäftsführungen können für Versäumnisse beim Risikomanagement in Haftung genommen werden. Das hebt die Frage „Wie sicher ist dieses System eigentlich?“ von der IT-Abteilung auf die Vorstandsebene.

Welche Architekturentscheidungen jetzt zählen

Vier Punkte entscheiden in der Praxis, ob ein Robotervorhaben Ihre Pflichten erschwert oder unterstützt:

• Datenhaltung und Betriebsmodell. Läuft die Steuerung on-premise oder sogar offline, bleiben Betriebsdaten in Ihrer Umgebung. Das reduziert die Abhängigkeit von externen Diensten und vereinfacht die Bewertung von Datenflüssen.
• Zugriff und Nachvollziehbarkeit. Rollen, Berechtigungen und ein nachvollziehbares Protokoll darüber, wer was ausgelöst hat, sind die Basis für Audits und Vorfallsbearbeitung.
• Netz und Segmentierung. Roboter, Türen und Aufzüge sollten kontrolliert angebunden sein, nicht flach in jedes Netz. Eine gemeinsame Integrationsschicht macht diese Grenzen sichtbar und steuerbar.
• Herstellerunabhängigkeit. Wenn ein Anbieter die gesamte Kette kontrolliert, erben Sie dessen Risiken und dessen Meldewege. Eine neutrale Schicht zwischen Robotern und Ihrer IT hält die Kontrolle bei Ihnen.

Diese vier Punkte hängen zusammen. Eine cloud-gebundene Steuerung erschwert nicht nur die Bewertung von Datenflüssen, sie verlagert auch die Kontrolle über Verfügbarkeit und Aktualisierungen zum Hersteller. Eine flache Netzanbindung erleichtert zwar die Inbetriebnahme, vergrößert aber die Angriffsfläche und macht die Segmentierung im Nachhinein aufwendig. Die wirtschaftlich und regulatorisch günstigste Reihenfolge ist deshalb fast immer dieselbe: erst die Architektur klären, dann beschaffen.

Typische Stolpersteine in der Praxis

In Gesprächen mit Einrichtungen begegnen uns immer wieder dieselben Muster. Erstens die stillschweigende Cloud-Abhängigkeit: Ein Roboter funktioniert nur, solange er mit der Cloud des Herstellers verbunden ist. Fällt die Verbindung aus oder ändert der Anbieter seine Bedingungen, steht der Betrieb still – ein Risiko, das in regulierten Umgebungen schwer wiegt. Zweitens fehlende Protokolle: Ohne nachvollziehbare Aufzeichnung darüber, wer welche Aktion ausgelöst hat, lässt sich ein Vorfall im Nachhinein kaum rekonstruieren und entsprechend kaum melden. Drittens die Vermischung von Netzen: Roboter, die direkt mit klinischen oder betrieblichen Kernsystemen sprechen, weil es bei der Inbetriebnahme einfacher war. Solche Abkürzungen rächen sich beim ersten Audit.

Keiner dieser Punkte ist exotisch. Sie sind die Robotik-Variante von Anforderungen, die in jeder anderen IT-Beschaffung längst selbstverständlich sind. Der Unterschied: Bei Robotern sind die Schnittstellen physisch – Türen öffnen sich, Aufzüge fahren – und damit ist die Sicherheitsfrage zugleich eine Betriebssicherheitsfrage.

Wie Axiona dabei hilft

Axiona ist die herstellerunabhängige Schicht zwischen Robotern und der Außenwelt. Sie ist auf gekapselten, nachvollziehbaren Betrieb ausgelegt und lässt sich on-premise oder offline betreiben, je nach Betriebsmodell. Roboter, Türen, Aufzüge und Drittsysteme binden Sie über Adapter an, statt sie fest miteinander zu verdrahten. Zugriffe laufen über Rollen und Richtlinien.

Der Adapteransatz ist hier mehr als eine technische Bequemlichkeit. Er macht die Grenzen zwischen den Systemen explizit: Jede Verbindung ist benannt, kontrollierbar und austauschbar. Ein Hersteller lässt sich ersetzen, ohne die gesamte Integration neu aufzusetzen, und ein einzelnes kompromittiertes Gerät bleibt auf seinen klar umrissenen Wirkungsbereich begrenzt. Genau diese Sichtbarkeit braucht es, um Datenflüsse zu dokumentieren und Vorfälle einzugrenzen.

Wichtig zur Einordnung: Software macht Sie nicht automatisch KRITIS- oder NIS-2-konform. Compliance ist ein organisatorischer Prozess. Axiona ist so gebaut, dass es diesen Prozess unterstützt, statt ihm im Weg zu stehen, indem es Datenhaltung, Zugriff und Integration unter Ihrer Kontrolle hält. Die Verantwortung für Geltungsbereich, Meldewege und Risikobewertung bleibt bei Ihrer Organisation – die Architektur kann diese Arbeit erleichtern, aber nicht ersetzen.

Beleg aus dem Echtbetrieb

Die zugrunde liegende Technik ist aus dem Forschungsprojekt SMART FOREST 5G Clinics an der TH Deggendorf hervorgegangen und seit 2023 im Echtbetrieb in zwei Kliniken, der Arberlandklinik Viechtach und den Kliniken am Goldenen Steig in Freyung. Dort werden Serviceroboter mit Tür- und Aufzugsintegration koordiniert, on-premise betreibbar. Die datenschutzrechtliche Bewertung sprachgesteuerter Systeme im Krankenhaus haben wir gemeinsam mit Forschenden publiziert.

Der Unterschied zwischen einer Demonstration und einem belastbaren Betrieb zeigt sich erst über die Zeit. Ein System, das seit 2023 in zwei Häusern im realen Klinikalltag läuft, ist mit genau den Reibungen konfrontiert worden, die in einem Pilotprojekt selten auftauchen: wechselnde Anforderungen, Wartungsfenster, Ausnahmen im Tagesgeschäft. Diese Erfahrung ist in die Architektur eingeflossen – und sie ist der Grund, warum wir bei Datenhaltung, Zugriff und Integration so konsequent auf Kontrollierbarkeit setzen.

Nächster Schritt

Wenn Sie Robotik in einer regulierten Umgebung planen, lohnt sich der Architekturblick vor der Beschaffung. Sprechen Sie mit uns über Ihr Vorhaben, oder lesen Sie mehr über unseren Ansatz zu Souveränität und Sicherheit.