Ein Roboter vor der Tür, die ihn nicht kennt

Ein Serviceroboter steht vor einer Sicherheitstür. Seine Karte ist korrekt, der Akku reicht, die Route ist frei – und trotzdem kommt er nicht weiter. Nicht weil seine Software versagt, sondern weil das Gebäude nicht weiß, wer da vor der Tür steht.

Die Tür kennt Mitarbeiterausweise, Smartphones und Besucherkarten. Der Aufzug reagiert auf Tasterdruck. Das Brandmeldesystem warnt Menschen über Sirenen, nicht Maschinen. Der Grundriss liegt zwar als BIM-Datei vor, aber nicht als laufend gepflegte Betriebsinformation. Genau an dieser Stelle entscheidet sich, ob Physical AI im Gebäude nur demonstriert oder tatsächlich betrieben wird. Diese Situation wiederholt sich nicht nur bei einzelnen Lieferrobotern, sondern überall dort, wo Physical AI aus der Werkshalle in gemischt genutzte, für Menschen gebaute Gebäude wandert.

Der professionelle Markt für Serviceroboter wächst über Reinigung, Sicherheit, Lieferung und interne Logistik hinweg – und mit ihm die Zahl der Gebäude, die täglich mehr als eine Robotermarke gleichzeitig durchqueren sollen. Ein modernes Büro kann App-Zutritt, vernetzte Heizung, smarte Beleuchtung und Belegungssensoren besitzen und für einen Roboter trotzdem fast unbenutzbar sein, weil all das für den Menschen als primären Nutzer gebaut wurde.

Am deutlichsten zeigt sich das beim Etagenwechsel. Lieferroboter gelten als einer der größten Flaschenhälse der Indoor-Robotik, weil ein Aufzug für einen Menschen ein Verkehrsmittel ist und für eine Maschine eine geteilte Ressource mit Wartezeiten und Sicherheitszuständen. Ein Roboter muss nicht nur wissen, dass ein Aufzug existiert. Er muss ihn anfordern, die richtige Kabine zugewiesen bekommen, erkennen, wann die Tür offen ist, einfahren, ein Ziel setzen und mit einem Fehler umgehen können.

Robot-Readiness beginnt deshalb nicht bei einem cleveren Roboter, sondern dort, wo Gebäudeinformationen für Maschinen handlungsfähig werden.

Design for Robots: warum sich Komplexität besser einmal im Gebäude lösen lässt

Die klassische Robotiklogik lautet: Die Umgebung ist gegeben, also muss der Roboter besser werden – mehr Sensoren, bessere Hinderniserkennung, vielleicht sogar ein humanoider Körper, weil Türen und Treppen für Menschen gestaltet wurden. Diese Logik ist nachvollziehbar. Sie hat aber einen Preis: Jede Fähigkeit, die das Gebäude nicht bereitstellt, muss der einzelne Roboter selbst lösen, und zwar jede Robotermarke für sich.

Singapurs Bauaufsicht BCA beschreibt die Alternative in ihrem Leitfaden zur wartungsfreundlichen Gebäudeplanung ungewöhnlich klar. Sie trennt „Design of Robots“ – den Roboter an den Arbeitsraum anpassen – von „Design for Robots“: den Raum so gestalten, dass Robotik sicherer, einfacher und wirtschaftlicher funktioniert. Diese Unterscheidung ist die ökonomische Grundlage von robot-ready Buildings, denn ein Roboter, der eine schwere Tür mechanisch öffnen muss, braucht andere und teurere Hardware als einer, der autorisiert eine Türschnittstelle aufruft.

Die Frage lautet damit nicht mehr nur, wie viel Intelligenz der Roboter braucht, sondern welche Komplexität besser einmal im Gebäude gelöst wird, statt hundertfach in jedem einzelnen Gerät. Wenn jede neue Robotermarke den Aufzug erneut integriert, eigene Türhardware installiert und das Gebäude neu kartiert, bleibt jede Einführung ein Pilotprojekt. Existiert die Grundfunktion dagegen als Gebäudeplattform, integriert sich der nächste Roboter in bestehende Services – deshalb ist Interoperabilität hier wirtschaftlich wichtiger als technische Eleganz.

Der FluxLane Robot-Readiness-Stack: neun Ebenen auf einen Blick

Für die praktische Bewertung eines Gebäudes hilft ein geordnetes Raster mehr als eine lange Liste einzelner Anforderungen. Wir schlagen dafür ein eigenes, redaktionelles Ordnungsmuster vor – kein offizieller Standard, sondern eine Zusammenfassung der im Folgenden beschriebenen Normen, Zertifizierungen und realen Gebäude.

Ein Gebäude lässt sich danach auf neun miteinander gekoppelten Ebenen bewerten, von der reinen Befahrbarkeit bis zum langfristigen Betrieb.

Erst das Zusammenspiel dieser neun Ebenen bestimmt, ob ein Gebäude tatsächlich robot-ready ist. Ein Haus kann auf Ebene 1 exzellent sein, mit breiten und ebenen Fluren, und auf Ebene 8 komplett fehlen, weil niemand definiert hat, was ein Roboter bei Feueralarm tun soll. Genau solche Lücken verhindern, dass aus einer beeindruckenden Demonstration ein Dauerbetrieb wird. Die Reihenfolge der neun Ebenen ist dabei keine Rangfolge der Wichtigkeit, sondern folgt eher der Wegstrecke eines Roboters durch das Gebäude – von der Bodenfreiheit bis zu der Frage, wer in zehn Jahren noch für die einzelne Schnittstelle verantwortlich zeichnet.

Türen und Aufzüge: aus Bauteilen werden Policy-Systeme

Eine Tür ist für einen Menschen ein physisches Objekt. Für ein robot-ready Building ist sie zusätzlich ein Policy-System: Darf dieser Roboter diese Tür passieren, zu welcher Uhrzeit, mit welcher Ladung – und was passiert, wenn seine Berechtigung während eines Auftrags widerrufen wird? Ein Bewegungssensor kann eine Tür öffnen, entscheidet aber nicht, ob ein Roboter in ein Medikamentenlager oder eine Büroetage darf. Japan hat dafür mit der 2026 aktualisierten Spezifikation RFA B 0002 eine eigene Robot/Security-Cooperation-Norm geschaffen, die Identität, Autorisierung und Aktuation als getrennte Funktionen behandelt – eine Trennung, die verhindert, dass Navigation und Sicherheitsentscheidung in einem undurchsichtigen Sondermodul verschmelzen.

Mehrgeschossigkeit verschärft die Aufgabe. Ein Aufzug ist für Roboter keine reine Transporttechnik, sondern eine geteilte Ressource mit Wartezeiten, menschlichen Fahrgästen und Sicherheitszuständen. NAVER hat für sein Gebäude 1784 den radikalsten Weg gewählt und mit ROBOPORT ein robotereigenes vertikales Transportsystem gebaut, das einen Teil des Roboterverkehrs vom normalen Personenaufzug trennt – für die meisten Bestandsgebäude aus Kosten- und Platzgründen aber kaum der Standardweg.

Skalierbarer ist die Integration klassischer Aufzughersteller. KONE bietet mit seiner Service Robot API eine Schnittstelle, über die Roboter Fahrten anfordern und Informationen zu bedienten Etagen, Position, Fahrtrichtung und Türstatus abrufen können. Otis verfolgt mit Integrated Dispatch denselben Grundgedanken als Cloud- oder On-Premise-Lösung mit begrenzter Zusatzhardware und einer Simulationsumgebung zum Testen. Japan bündelt diese Beziehung zusätzlich in der Norm RFA B 0001, deren zweite Fassung von 2025 auch Test- und Rehearsal-Abläufe standardisiert.

Selbst mit einer sauberen Schnittstelle bleiben betriebliche Fragen offen: Passt der Roboter in die Kabine, darf er mit Personen fahren, welche Priorität erhält ein Medikamententransport gegenüber einem Reinigungsroboter? Spätestens hier endet die reine Geräteintegration – der Aufzug wird zu einem Scheduling-Problem des ganzen Gebäudes.

Netz, Karte und Betrieb: das digitale Rückgrat

„Wir haben WLAN“ ist für einen dauerhaften Robotikbetrieb keine Anforderung, sondern eine Hoffnung. Robot-ready Planung dreht die übliche Reihenfolge um: Zuerst werden die Roboterrouten definiert, dann wird entlang dieser Routen geprüft, welche Verbindungsqualität und Ausfalllogik nötig ist – gerade in Aufzügen, Schleusen und Untergeschossen, die in normalen IT-Planungen wenig Aufmerksamkeit bekommen. NAVER 1784 nutzt dafür lokales 5G als Teil seiner Cloud-Architektur. Tokyo Midtown Yaesu zeigt, dass es auch ohne private Mobilfunklösung geht, solange das Gebäude einen definierten Kommunikationsservice für Maschinen bereitstellt. Entscheidend ist am Ende nicht die Funktechnik, sondern was passiert, wenn sie ausfällt: Bleibt der Roboter stehen, fährt er zu einem sicheren Punkt, kann die Tür trotzdem schließen? Robot-Readiness ist zu einem erheblichen Teil Failure Readiness.

Eine reine Navigationskarte sagt, wo Wände stehen. Eine betriebliche Raumrepräsentation muss zusätzlich wissen, welche Zutrittsklasse hinter einer Tür gilt, wo Ladepunkte liegen und welche Route nachts erlaubt, tagsüber aber zu stark frequentiert ist. Die klassische Bauwelt liefert dafür bereits eine Grundlage: IFC ist ein offener, maschineninterpretierbarer Standard für Gebäudeinformationen und als ISO 16739 genormt, die ISO-19650-Reihe strukturiert das Informationsmanagement über Planung, Bau und Betrieb hinweg. Ein BIM-Modell kennt trotzdem nur Bauteile, keine Regeln – eine Tür im IFC-Modell sagt noch nicht, dass Roboter A sie von sieben bis neunzehn Uhr passieren darf und bei Feueralarm keiner. Zwischen Asset-Modell und Roboterflotte braucht es deshalb eine zusätzliche, operative Ebene: eine Art maschinenlesbare Hausordnung.

Dieselbe Lücke betrifft Laden, Parken und die Koordination mehrerer Flotten. Wenn fünf Roboter nachts im Flur stehen oder Ladekabel über den Boden laufen, entsteht ein neues Hindernis. Japan hat dafür 2026 mit der Guideline RFA GL B 0103 Park- und Bereitstellungsflächen bereits für frühe Planungsphasen standardisiert, in denen Robotermodell und Flottengröße noch gar nicht feststehen. Für die Koordination selbst ist in der Industrie VDA 5050 ein wichtiger Baustein: Die 2026 veröffentlichte Version 3.0 strukturiert die Kommunikation zwischen Leitsteuerung und mobilen Robotern, unter anderem über Zonen und Path Sharing. Der Standard ist aber keine Gebäude-API – er regelt nicht, wie ein Zutrittssystem einem externen Roboter Rechte erteilt, und ersetzt keine Aufzugsschnittstelle. Das unterscheidet die Aufgabe grundlegend von der Steuerungsschicht des vernetzten Hauses: Ein privates Zuhause koordiniert eine bekannte, kleine Zahl eigener Geräte für einen einzelnen Haushalt, während ein robot-ready Gebäude wechselnde, oft herstellerfremde Maschinen für einen unbekannten Kreis von Betreibern verwalten muss.

Sicherheit im Alarmfall und Verantwortung über Jahre

Bei Robotik wird Sicherheit oft zuerst am Gerät diskutiert: Sensoren müssen Hindernisse erkennen, Geschwindigkeit muss begrenzt werden. Im öffentlichen Gebäude reicht das nicht. ISO 31101:2023 adressiert deshalb ausdrücklich nicht nur Hardware, sondern das Safety-Management von Serviceroboter-Anwendungen in unstrukturierten Räumen wie Flughäfen, Krankenhäusern oder Restaurants – die Norm ist kein Produktstandard. Für fahrerlose Flurförderzeuge und AMR-Systeme ist zusätzlich ISO 3691-4:2023 relevant, etwa für AMR in der Krankenhauslogistik, deren Betriebszonen ähnliche Fragen aufwerfen wie ein allgemeines Bürogebäude.

Der nächste logische Schritt ist die direkte Verbindung zum Gebäude selbst. Japan hat dafür Anfang 2026 mit RFA B 0006 einen Standard veröffentlicht, der eine Schnittstelle definiert, über die Robotik Warnungen aus dem Gebäudenotfallsystem erhalten kann. Damit wird das Gebäude vom passiven Raum zum Safety-Publisher für autonome Systeme: Soll der Roboter sofort stehen bleiben, eine Fluchtroute freigeben oder in eine Parkzone fahren? Was passiert mit einem Transport von Laborproben, der gerade in einer Aufzugkabine steckt? Diese Regeln müssen vor dem Ereignis feststehen, nicht während der Evakuierung improvisiert werden.

Gebäude leben länger als Roboterprodukte – wahrscheinlich die wichtigste Lifecycle-Frage des gesamten Themas. Ein Bürogebäude wird über Jahrzehnte betrieben, Robotikplattformen und Funktechnik wechseln deutlich schneller. Ein robot-ready Building darf deshalb nicht an eine einzige proprietäre Lösung gekettet sein: Es braucht dokumentierte Schnittstellen und geklärte Verantwortlichkeiten dafür, wer die Karte nach einem Umbau pflegt, wer die digitale Identität eines ausgemusterten Roboters widerruft und wer entscheidet, ob eine neue Robotikfirma Zugriff auf das Sicherheitssystem erhält. ISO 19650-5 liefert für den sicherheitsbewussten Umgang mit sensiblen Gebäudedaten einen Ansatz, der hier zwar nicht ausreicht, aber in die richtige Richtung zeigt: Räumliche und technische Gebäudedaten sind Betriebs- und Sicherheitsinformation und müssen entsprechend behandelt werden. Die EU-Cyberresilience-Verordnung (VO (EU) 2024/2847) sieht für vernetzte Produkte mit digitalen Elementen eine gestufte Update- und Meldepflicht vor: Die Meldepflicht bei aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen gilt bereits seit dem 11. September 2026, die Vorgaben für notifizierte Stellen seit dem 11. Juni 2026, vollständig anwendbar wird die Verordnung ab dem 11. Dezember 2027. Eine Robotik-Gebäude-Schnittstelle, die dauerhaft Software erhält und mit dem Internet verbunden ist, kann je nach Einordnung darunterfallen – auch das gehört beim Betrieb über Jahre mitgedacht, nicht erst bei der Inbetriebnahme geprüft. Genau diese Fragen – wer eine Tür öffnet, wer eine Route pflegt, wer für einen Ausfall haftet – hat FluxLane bereits für den engeren Fall der Integration von Klinikrobotern in Türen, Aufzüge und Flotten untersucht; robot-ready Buildings setzen dieselbe Logik eine Ebene höher an, für das ganze Gebäude statt für einen einzelnen Robotertyp.

Neubau und Bestand: NAVER 1784, Tokyo Midtown Yaesu und drei staatliche Antworten

NAVER 1784 in Seongnam ist die bekannteste Referenz für den Neubauansatz. Das Unternehmen bezeichnet das 2022 eröffnete Gebäude als weltweit erstes robot-friendly Building, in dem Robotik, Cloud, Digitaler Zwilling und Gebäudeinfrastruktur von Beginn an gemeinsam gedacht wurden. Sichtbarster Teil ist ROBOPORT, wichtiger ist aber die Softwareebene: ARC dient als Multi-Robot-Intelligence-System, digitale Gebäudedaten unterstützen Lokalisierung und Routenplanung. Nach eigenen Angaben berichtete NAVER nach 1.000 Betriebstagen von rund 100 täglich betriebenen Robotern und mehr als 60.000 abgeschlossenen Lieferungen – Unternehmensangaben, die keine allgemeine Wirtschaftlichkeit belegen, aber zeigen, dass ein robot-friendly Building über Jahre als realer Betrieb funktionieren kann. Ein eigener Roboteraufzug bleibt für die meisten Hotels, Kliniken oder Bürogebäude allerdings unrealistisch; der Erkenntnisgewinn liegt weniger in ROBOPORT selbst als in der Planungslogik, Robotik als Nutzeranforderung des Gebäudes zu behandeln statt als nachträgliches Gewerk.

Für europäische Bestandsimmobilien strategisch wichtiger ist deshalb Tokyo Midtown Yaesu. Das Mischnutzungsgebäude mit Büros, Gastronomie und Hotel wurde nicht als Testlabor gebaut. Trotzdem starteten Mitsui Fudosan, NTT East und NAVER Cloud dort am 21. Juli 2026 einen regulären Roboterlieferdienst: Vier Roboter verbinden zunächst bestimmte Restaurants mit Bürobereichen über mehrere Etagen, der Service integriert Aufzüge und Sicherheitstüren, ein Cloud-Digital-Twin liefert die räumliche Grundlage. Der eng geschnittene Use Case – nicht das ganze Gebäude auf einmal, sondern eine einzige Wertschöpfungskette von Bestellung über Aufzug bis Übergabe – ist die realistischere Retrofit-Strategie als ein kompletter Neubau. Da dasselbe Gebäude auch Hotelflächen einbindet, berührt der Fall die Fragen, die FluxLane bereits für Serviceroboter im Hotel beschrieben hat – dort aus Sicht des einzelnen Gastbetriebs, hier aus Sicht der gesamten Gebäudeinfrastruktur mehrerer Nutzungsarten.

Südkorea versucht inzwischen, solche Einzelprojekte in ein reproduzierbares Modell zu überführen. Die Smart City Association betreibt mit REEC eine Zertifizierung, die laut eigenen Angaben vier Bereiche prüft: räumliche und bauliche Umgebung, Netz- und Systeminfrastruktur, Betriebsmanagement und die tatsächliche Serviceumsetzung; als zertifizierte Referenzen führt die Organisation unter anderem NAVER 1784 und das KT Pangyo Building. Das koreanische Infrastrukturministerium hat zusätzlich ein Forschungsprogramm für robot-friendly Building Design, Construction, Operation and Management von 2025 bis 2028 aufgesetzt, das nach Programmangaben rund 18 Milliarden Won umfassen soll – eine Zahl, die sich bei Redaktionsschluss nicht über eine zweite, unabhängige Quelle absichern ließ und deshalb mit Vorbehalt zu lesen ist. Als Erprobungsstandorte werden unter anderem zwei Krankenhäuser und ein Terminal genannt; Robot-Readiness wird damit ausdrücklich zur Bau- und Betriebsdisziplin statt zum reinen Robotikproblem.

Japan verfolgt eine andere Route und baut seit mehreren Jahren einen modularen Standardbaukasten der Robot Friendly Alliance auf, statt einen einzigen großen „Robot Building Standard“ zu formulieren: einzelne Spezifikationen für Aufzugskooperation, Sicherheitskooperation, physische Umgebung, Flottenkoordination, gemeinsame visuelle Marker, Notfallanbindung und Parkflächen. Singapurs BCA verankert „Design for Robots“ als eigenen Abschnitt ihres Leitfadens zur wartungsfreundlichen Gebäudeplanung – ein Ansatz, der weniger auf Zertifizierung als auf frühzeitige Entwurfsentscheidungen setzt. Für deutsche Planerinnen und Planer sind diese drei Modelle vor allem als Bibliothek zu lesen, aus der sich einzelne Bausteine – etwa eine Türkooperationsnorm oder ein Park-Guideline – schon heute unabhängig von einer eigenen Zertifizierung übernehmen lassen. Europa startet dabei nicht bei null: ISO 18646-2 misst die Navigationsleistung mobiler Serviceroboter, ISO 3691-4 regelt AMR-Sicherheit, DIN 18040 strukturiert barrierefreie Wege, ISO 19650 und IFC strukturieren Gebäudedaten, VDA 5050 löst einen Teil der Flottenkommunikation – dieselbe Normenlandschaft, gegen die sich auch die CE-Konformität von Industrierobotern und Cobots heute schon einordnen muss. Nach dem hier geprüften Stand vom September 2026 gibt es aber keinen einzelnen ISO-, EN- oder DIN-Standard, der Fahrweg, Aufzug, Zutritt, Digital Twin, Netz, Energie, Orchestrierung, Notfall und Betrieb als einheitliche Zertifizierung abdeckt. Das ist keine Aussage über technisches Unvermögen, sondern eine Lücke in der Systemintegration.

Was Robot-Readiness kostet – und was deutsches Recht dazu verlangt

Öffentliche, belastbare Preise für eine vollständige Robot-Readiness-Nachrüstung lassen sich derzeit kaum seriös angeben. Aufzughersteller veröffentlichen Schnittstellen und Produkte, aber keine universelle Projektpauschale, und selbst die japanischen Forumstandards zeigen, wie stark jede Integration von der bestehenden Infrastruktur abhängt. Eine Zahl „X Euro pro Quadratmeter“ wäre deshalb Scheingenauigkeit. Einen groben Anhaltspunkt für die Größenordnung, in der Staaten das Thema finanziell ansetzen, liefert das oben genannte koreanische Forschungsprogramm: Rund 18 Milliarden Won über drei Jahre – nach heutigem Kurs ein niedriger zweistelliger Millionenbetrag in Euro – sind ein staatliches Forschungsbudget für mehrere Demonstrationsstandorte, keine Kostenangabe für ein einzelnes Gebäude. Als Näherung zeigt die Zahl trotzdem, dass Regierungen das Thema im zweistelligen Millionenbereich verorten und nicht im Bereich einzelner Pilotinvestitionen. Wirtschaftlich aussagekräftiger als eine einzelne Kennzahl bleibt ohnehin die Zerlegung des Projekts in Bausteine – bauliche Nachrüstung, Aufzug- und Türintegration, Netz und Ortung, Raumdaten, Roboter-Middleware, Inbetriebnahme und laufender Betrieb – und die Frage, wie viele Robotergenerationen diese Investition überlebt. Wer sie mit dem Gesamtkosten eines Serviceroboters vergleicht, erkennt schnell, dass die Gebäudeseite eine eigene, meist unterschätzte Kostenposition ist und keine Randnotiz zum Robotereinkauf.

Für deutsche Betreiber kommt zur Technik- und Kostenfrage eine rechtliche hinzu, die im internationalen Diskurs über robot-ready Buildings kaum vorkommt. Ein Zutritts- oder Trackingsystem, das erfasst, wo sich ein Roboter – und indirekt auch, wo sich Beschäftigte im selben Bereich – aufhalten, kann eine technische Einrichtung sein, die zur Überwachung von Verhalten oder Leistung geeignet ist. Für solche Systeme sieht das Betriebsverfassungsgesetz ein Mitbestimmungsrecht des Betriebsrats vor; ob und in welchem Umfang es im Einzelfall greift, hängt von der konkreten Ausgestaltung ab und ist ohne Prüfung des jeweiligen Systems nicht pauschal zu beantworten.

Sobald ein Zutrittssystem Mitarbeiterausweise mit Roboterberechtigungen koppelt, entstehen zudem personenbezogene, im Fall biometrischer Merkmale besonders geschützte Daten im Sinne der DSGVO. Je nach Umfang der Verarbeitung – etwa bei einer systematischen, flächendeckenden Bewegungsprotokollierung – kann eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich werden. Nutzt das System zur Identifikation Gesichtserkennung oder andere KI-gestützte biometrische Verfahren, kann zusätzlich der EU AI Act einschlägig sein, dessen Vorgaben für bestimmte biometrische Anwendungen strenger ausfallen; auch das ist eine Frage des Einzelfalls, keine pauschale Aussage. Und auch die Anbindung eines Roboters an die Brandmeldeanlage ist kein rein technisches Detail: Eingriffe in eine sicherheitsrelevante Anlage dieser Art können je nach Landesbauordnung einer Abnahme oder Freigabe durch die zuständige Behörde oder einen Prüfsachverständigen bedürfen, bevor die Schnittstelle produktiv geschaltet wird. Sobald ab dem 20. Januar 2027 die EU-Maschinenverordnung (VO (EU) 2023/1230) vollständig anwendbar wird, dürfte sie zudem für sicherheitsrelevante Bauteile der Gebäudeseite selbst relevant werden, etwa für eine Türsteuerung oder Aufzuganbindung, die durch die Roboterintegration neue Sicherheitsfunktionen übernimmt – eine CE-Kennzeichnung bleibt dabei stets eine Herstellererklärung und kein Gütesiegel. Diese Punkte ersetzen keine Rechtsberatung im Einzelfall, gehören aber – anders als in den internationalen Standards dieser Analyse – von Anfang an auf die Planungsliste jedes deutschen Retrofit-Projekts.

Humanoide Roboter im robot-ready Gebäude: ein Paradox

Ein häufiges Argument für humanoide Roboter lautet: Unsere Welt ist für Menschen gebaut, also ist ein menschenähnlicher Körper besonders kompatibel. Das stimmt für manche Aufgaben – ein Roboter mit Händen kann theoretisch eine Türklinke greifen oder mit Werkzeugen interagieren, die nie für Maschinen entwickelt wurden. Robot-ready Buildings zeigen aber die Gegenrichtung: Wenn Türen digital freigegeben werden, braucht ein Lieferroboter keinen Arm zum Öffnen. Wenn Aufzüge eine sichere API besitzen, muss er keinen Taster bedienen. Wenn Karten und Zonen maschinenlesbar sind, sinkt ein Teil des Wahrnehmungsaufwands, den sonst jeder einzelne Roboter selbst tragen müsste.

Daraus folgt keine Aussage gegen humanoide Systeme insgesamt. Manipulation, Treppen und viele wechselnde Aufgaben an menschlichen Arbeitsplätzen können den humanoiden Formfaktor weiterhin rechtfertigen. Für Delivery-, Reinigungs-, Sicherheits- und Logistikaufgaben gilt aber tendenziell: Je robot-readier das Gebäude, desto weniger muss der Roboter den Menschen imitieren. Das kann wirtschaftlich entscheidend sein, weil ein Roboter, der eine standardisierte Aufzugfahrt anfordert, mechanisch und softwareseitig deutlich einfacher bleibt als einer, der jeden Aufzug über Bildverarbeitung und Arm selbst bedienen muss.

Sieben Schritte für den Retrofit im Bestand

Der größere Markt liegt nicht im Neubau, sondern im Bestand – deshalb braucht es einen Ansatz, der nicht versucht, jedes Gebäude sofort auf die höchste Integrationsstufe zu heben. Sieben Schritte haben sich aus den hier beschriebenen Referenzen als praktikabel herausgeschält.

Am Anfang steht nicht der Roboter, sondern der Prozess: „Material von Lager A zu Station B, 80 Fahrten pro Tag, drei Etagen, zwei Sicherheitstüren“ lässt sich prüfen, „wir wollen Serviceroboter“ nicht. Darauf folgt ein vollständiges Routenaudit, das jede Schwelle, jede Tür, den Aufzug, die Funkabdeckung, Wartungsflächen und Übergabepunkte erfasst – nicht nur den Grundriss. Im dritten Schritt werden die benötigten Gebäuderessourcen klassifiziert: Aufzüge, Türen, Schranken, Ladepunkte, Netz und Alarmzustände.

Im vierten Schritt sollten dokumentierte Schnittstellen gegenüber roboterspezifischer Sonderhardware bevorzugt werden, wo immer das sinnvoll ist – nicht weil APIs per se besser wären, sondern weil ihre Verantwortung, Versionierung und Zugriffskontrolle sauberer planbar sind. Fünftens braucht es ein digitales Betriebsmodell, das nicht nur einmal kartiert, sondern Umbauten und temporäre Sperrungen laufend pflegt; ohne diese Pflege veraltet die Karte schneller als jede Roboterflotte, die sich auf sie verlässt. Sechstens gehören Ausfallszenarien vor den Go-live: Netzausfall, blockierter Aufzug, niedriger Akkustand, Brandalarm, ein Mensch, der einen Wagen in die Engstelle stellt. Bleiben diese Fälle ungetestet, ist das Projekt nicht betriebsbereit. Erst danach, siebtens, folgt die Skalierung – ein vollständig integrierter Servicefluss ist die bessere Grundlage für den nächsten Roboter als fünf halbfertige Pilotprojekte gleichzeitig.

Fazit: Das Gebäude wird zum Co-Roboter

Robot-ready Buildings wirken auf den ersten Blick wie ein Nischenthema für Lieferroboter im Foyer. Das unterschätzt die Entwicklung. Sobald autonome Systeme dauerhaft in Kliniken, Hotels, Büros, Einkaufszentren und Produktionsgebäuden arbeiten sollen, wiederholen sich dieselben Fragen: Kann das System fahren, kann es hinein, kann es die Etage wechseln, bleibt es verbunden, kennt es den Raumzustand, kann es laden, teilt es knappe Ressourcen mit anderen Robotern, kennt es den Alarmzustand – und wer betreibt diese Verbindungen über Jahre?

Südkorea beantwortet diese Fragen zunehmend mit Zertifizierung, Japan mit modularen Schnittstellenstandards, Singapur mit früher Entwurfsintegration. Europa besitzt viele Normbausteine, aber noch keinen durchgehenden Robot-ready-Gebäudestack – und in Deutschland kommen Mitbestimmung, Datenschutz und Bauordnungsrecht als eigene Ebene hinzu, die international kaum diskutiert wird, hierzulande aber über jedes Projekt mitentscheidet. Ein Roboter kann immer intelligenter werden, bessere Kameras, bessere Modelle und bessere Hände bekommen. Aber wenn jede Maschine erneut lernen muss, wie sie eine Tür überlistet, einen Aufzug improvisiert und einen Platz zum Laden findet, skaliert nicht das System – es skaliert nur die Komplexität. Ein robot-ready Building macht den Roboter deshalb nicht überflüssig. Es sorgt dafür, dass seine Intelligenz dort eingesetzt wird, wo sie Wert schafft, statt grundlegende Gebäudefunktionen immer wieder neu zu erfinden.