A robot that takes over journeys should relieve your daily work, not export your data. In hospitals, at utilities, and in other sensitive environments, the question of where operational data flows often decides whether a project starts at all. The good news: service robotics can be run so that data stays inside your environment. But that decision is made at the architecture stage, not at go-live. Postpone it, and you inherit the vendor's defaults.
The problem with cloud-bound robots
Many robots are built around their vendor's cloud. Maps, tasks, telemetry, and sometimes sensitive environmental data travel through external services. For private households that may be fine. In regulated environments it creates three problems: you lose control over data flows, you depend on the availability of an external service, and you tie yourself to one vendor.
These three points are connected. If you do not know what data a device sends outward, you cannot record it in a processing register or explain it to a data protection officer. If you depend on an external service, you import someone else's maintenance windows, pricing rounds, and availability promises into your own operation. And if you couple a robot to exactly one cloud, you can hardly swap it later for a cheaper or better-suited model without rebuilding the entire integration. A seemingly harmless detail in procurement thus becomes a long-term dependency.
What on-premise and offline actually mean
On-premise means control runs in your environment, on your infrastructure. Offline-capable means operation works even without a continuous internet connection, for example in areas where no external traffic is wanted. In practice it is rarely black and white. Often the time-critical coordination runs locally while selected, non-critical functions are deliberately exposed outward. What matters is that you set that boundary, not the robot vendor.
In concrete terms this means a deliberate separation: task control, routing, and the connection to doors or elevators are time-critical and belong inside. An optional dashboard for analytics, or a software update, can in turn lead outward in a controlled way if you want it to. The difference from a purely cloud-bound setup is not only technical. It shifts the burden of proof: instead of hoping that a vendor does not siphon off sensitive data, you actively define what is allowed to leave your premises, and you can demonstrate it.
How Axiona enables this
Axiona is the layer between robots and the outside world, built for encapsulated, auditable operation. Task coordination, door and elevator integration, and the connection to third-party systems all run through a common integration layer that you operate on-premise or offline. You connect robots through adapters instead of coupling them to a foreign cloud. So you decide which data stays local and which leaves at all.
The adapter model has a practical side effect: it decouples the hardware from the control logic. You can replace a robot or add a second type without rebuilding the workflows above it. That very point often decides whether a pilot scales or gets stuck as an isolated solution.
A realistic note: which modes are possible depends on the product, the compliance requirement, and the specific robot model. We assess that per project rather than making blanket promises. And just as honestly: software makes no one automatically KRITIS- or NIS-2-compliant. An on-premise system is a necessary foundation for data sovereignty, but it replaces neither sound operational organisation nor the legal classification of your institution. We tell you what the technology delivers, and what you have to add organisationally.
Evidence from real operation
The technology comes from the SMART FOREST 5G Clinics research project at Deggendorf Institute of Technology and has been in real operation since 2023 in two hospitals. There the platform drives elevator integrations on-premise, for example a GWH LiSA10 connection for a Keenon W3. You can check which models are offline- and elevator-capable in our service robot comparison.
The difference between a demo and real operation is significant precisely on the question of data flow. In continuous operation you find out whether a local elevator integration still works reliably when the internet connection briefly drops, and whether operation continues without constant calls back to an external cloud. An on-premise claim only becomes dependable once it has met these conditions over months, not in a controlled trade-fair setting.
What to look for in procurement
If you take data sovereignty seriously, you test it before purchase, not after. Three questions help separate marketing from substance. First, what data leaves your premises in normal operation, and can that traffic be switched off entirely without the core function failing? Second, does the time-critical control demonstrably run locally, or does it hang on an external service? Third, are the robots connected through open adapters, so that you can change the model later without losing the integration?
These points belong in the specification and in the contracts, not in a later conversation. Data sovereignty that only surfaces at audit time is usually more expensive to retrofit than to plan from the start. You can read more about our approach and the principles behind it under sovereignty and security.
Next step
If where your data lives is a criterion, set the operating model early. Talk to us about your requirements, or go deeper on our approach under sovereignty and security.