Servicerobotik ohne Datenabfluss: on-premise und offline betreiben

Ein Roboter, der Wege abnimmt, soll Ihren Alltag entlasten, nicht Ihre Daten exportieren. In Kliniken, bei Versorgern und in anderen sensiblen Umgebungen ist die Frage, wohin Betriebsdaten fließen, oft entscheidend dafür, ob ein Vorhaben überhaupt startet. Die gute Nachricht: Servicerobotik lässt sich so betreiben, dass Daten in Ihrer Umgebung bleiben. Diese Entscheidung treffen Sie aber nicht erst beim Go-live, sondern bei der Architektur. Wer sie verschiebt, vererbt sich die Defaults des Herstellers.

Das Problem mit Cloud-gebundenen Robotern

Viele Roboter sind auf die Cloud ihres Herstellers ausgelegt. Karten, Aufträge, Telemetrie und teils sensible Umgebungsdaten laufen über externe Dienste. Für Privathaushalte mag das genügen. In regulierten Umgebungen entstehen daraus drei Probleme: Sie verlieren die Kontrolle über Datenflüsse, Sie sind von der Verfügbarkeit eines externen Dienstes abhängig, und Sie binden sich an einen Anbieter.

Diese drei Punkte hängen zusammen. Wer nicht weiß, welche Daten ein Gerät nach außen sendet, kann sie auch nicht im Verarbeitungsverzeichnis führen oder einem Datenschutzbeauftragten erklären. Wer auf einen externen Dienst angewiesen ist, übernimmt fremde Wartungsfenster, Preisrunden und Verfügbarkeitszusagen in den eigenen Betrieb. Und wer einen Roboter an genau eine Cloud koppelt, kann ihn später kaum gegen ein günstigeres oder besser passendes Modell tauschen, ohne die gesamte Integration neu zu bauen. Ein scheinbar harmloses Detail in der Beschaffung wird so zur langfristigen Abhängigkeit.

Was on-premise und offline konkret bedeuten

On-premise heißt: Die Steuerung läuft in Ihrer Umgebung, auf Ihrer Infrastruktur. Offline-fähig heißt: Der Betrieb funktioniert auch ohne durchgehende Internetverbindung, etwa in Bereichen, in denen kein externer Datenverkehr erwünscht ist. In der Praxis ist es selten Schwarz-Weiß. Häufig läuft die zeitkritische Koordination lokal, während ausgewählte, unkritische Funktionen bewusst nach außen freigegeben werden. Entscheidend ist, dass Sie diese Grenze setzen, nicht der Roboterhersteller.

Konkret bedeutet das eine bewusste Trennung: Die Aufgabensteuerung, das Routing und die Anbindung an Türen oder Aufzüge sind zeitkritisch und gehören nach innen. Ein optionales Dashboard für Auswertungen oder ein Software-Update kann dagegen kontrolliert nach außen führen, wenn Sie es wollen. Der Unterschied zu einem rein cloudgebundenen Aufbau ist nicht nur technisch. Er verschiebt die Beweislast: Statt zu hoffen, dass ein Hersteller keine sensiblen Daten abgreift, definieren Sie aktiv, was Ihr Haus verlassen darf, und können das auch belegen.

Wie Axiona das ermöglicht

Axiona ist die Schicht zwischen Robotern und der Außenwelt und auf gekapselten, nachvollziehbaren Betrieb ausgelegt. Die Aufgabenkoordination, die Tür- und Aufzugsintegration und die Anbindung an Drittsysteme laufen über eine gemeinsame Integrationsschicht, die Sie on-premise oder offline betreiben. Roboter binden Sie über Adapter an, statt sie an eine fremde Cloud zu koppeln. So entscheiden Sie, welche Daten lokal bleiben und welche überhaupt nach außen gehen.

Das Adaptermodell hat einen praktischen Nebeneffekt: Es entkoppelt die Hardware von der Steuerlogik. Sie können einen Roboter ersetzen oder einen zweiten Typ ergänzen, ohne die darüberliegenden Abläufe neu aufzusetzen. Genau dieser Punkt entscheidet oft darüber, ob ein Pilotprojekt skaliert oder in einer Insellösung stecken bleibt.

Ein realistischer Hinweis: Welche Modi möglich sind, hängt vom Produkt, von der Compliance-Anforderung und vom konkreten Robotermodell ab. Wir ordnen das pro Vorhaben ein, statt pauschale Versprechen zu geben. Und ebenso ehrlich: Software macht niemanden automatisch KRITIS- oder NIS-2-konform. Ein on-premise betriebenes System ist eine notwendige Grundlage für Datensouveränität, ersetzt aber weder eine saubere Betriebsorganisation noch die rechtliche Einordnung Ihres Hauses. Wir sagen Ihnen, was die Technik leistet, und was Sie organisatorisch ergänzen müssen.

Beleg aus dem Echtbetrieb

Die Technik stammt aus dem Forschungsprojekt SMART FOREST 5G Clinics an der TH Deggendorf und ist seit 2023 im Echtbetrieb in zwei Kliniken. Dort steuert die Plattform unter anderem Aufzugintegrationen on-premise, etwa eine GWH-LiSA10-Anbindung für einen Keenon W3. Welche Modelle offline- und aufzugfähig sind, können Sie in unserem Serviceroboter-Vergleich nachsehen.

Der Unterschied zwischen Demo und Echtbetrieb ist gerade beim Thema Datenfluss erheblich. Im Dauerbetrieb zeigt sich, ob eine lokale Aufzugintegration auch dann zuverlässig arbeitet, wenn die Internetverbindung kurz wegbricht, und ob der Betrieb ohne ständige Rückfragen an eine externe Cloud weiterläuft. Belastbar ist eine On-premise-Aussage erst, wenn sie diese Bedingungen über Monate erfüllt hat, nicht im kontrollierten Messeumfeld.

Worauf Sie bei der Beschaffung achten sollten

Wer Datensouveränität ernst meint, prüft sie vor dem Kauf, nicht danach. Drei Fragen helfen, Marketing von Substanz zu trennen: Erstens, welche Daten verlassen das Haus im Normalbetrieb, und lässt sich dieser Datenverkehr vollständig abschalten, ohne dass die Kernfunktion ausfällt? Zweitens, läuft die zeitkritische Steuerung nachweislich lokal, oder hängt sie an einem externen Dienst? Drittens, sind die Roboter über offene Adapter angebunden, sodass Sie das Modell später wechseln können, ohne die Integration zu verlieren?

Diese Punkte gehören in das Lastenheft und in die Verträge, nicht in ein nachträgliches Gespräch. Datensouveränität, die erst beim Audit auffällt, ist meist teurer nachzurüsten als von Anfang an einzuplanen. Mehr zu unserem Ansatz und den dahinterliegenden Prinzipien finden Sie unter Souveränität und Sicherheit.

Nächster Schritt

Wenn der Verbleib Ihrer Daten ein Kriterium ist, sollten Sie das Betriebsmodell früh festlegen. Sprechen Sie mit uns über Ihre Anforderungen, oder vertiefen Sie unseren Ansatz unter Souveränität und Sicherheit.