Zuerst muss feststehen, welches Ziel begrenzt wird

In einer Werkhalle hebt ein Roboterarm ein Bauteil zehn Zentimeter zu hoch an, korrigiert sich, setzt es ab. Ein Techniker daneben schaut nicht auf den Arm, sondern auf ein Tablet, das die letzten dreißig Sekunden protokolliert. Für ihn zählt nicht, wie geschickt der Griff war, sondern ob die Zelle in der nächsten Stunde wieder ohne ihn läuft. Genau an dieser Stelle trennen sich Fragen, die in der Physical-AI-Debatte oft unter einer Überschrift verhandelt werden.

Forschung fragt, ob eine Fähigkeit grundsätzlich funktioniert. Ein Hersteller fragt, ob sie sich in ein Produkt überführen lässt, das er in Serie bauen kann. Ein Betreiber fragt, ob die Fähigkeit unter seinen Bedingungen zuverlässig genug ist, um Personal einzusparen oder freizusetzen. Diese drei Fragen führen zu drei verschiedenen Antworten auf dieselbe Verbesserung, und ein Fortschritt, der eine davon löst, kann bei den anderen beiden folgenlos bleiben.

Keine Definition von Physical AI klärt das, sondern eine Unterscheidung: Ein Engpass ist immer ein Engpass für ein bestimmtes Ziel, zu einem bestimmten Zeitpunkt in der Entwicklung. Er sitzt selten dauerhaft an derselben Stelle, weil sich mit jeder Phase auch die knappste Ressource ändert. Was in der Forschungsphase die Fähigkeit selbst begrenzt, kann in der Pilotphase längst durch Integration ersetzt sein, und was im Pilot als größtes Problem gilt, kann sich im Rollout als Randfrage erweisen, sobald Service und Fertigungsstreuung übernehmen. Wer Fortschritt bewerten will, muss deshalb zuerst benennen, welche dieser Grenzen er überhaupt meint.

Das Modell bleibt wichtig – nur nicht zwangsläufig allein

Dass ein besseres KI-Modell zählt, bestreitet in diesem Feld kaum jemand. Ein anderer Beitrag dieses Portals behandelt auch, dass das Modell wichtig bleibt — entscheidend ist hier zusätzlich, dass es nicht in jeder Einsatzphase automatisch die aktiv wirksame Grenze ist. Beide Aussagen widersprechen sich nicht: Ein starkes Modell ist eine notwendige Bedingung für viele Aufgaben, notwendig ist aber nicht dasselbe wie hinreichend.

Wer diese Unterscheidung für Wortklauberei hält, sollte sich an die DARPA Robotics Challenge Finals vom 5. und 6. Juni 2015 erinnern. Der Roboter „Running Man“ bewältigte dort alle acht gestellten Aufgaben — eine Tür öffnen, Schutt räumen, eine Leiter besteigen, ein Ventil drehen — und fiel anschließend beim Winken zum Publikum um. Die Veranstalter selbst sprachen von einer Vielzahl von Fehlern, die zeigten, wie schwierig Robotik bleibt. Kein Integrationsproblem hat den Roboter zu Fall gebracht und keine fehlende Serviceorganisation, denn die Fähigkeit selbst war an dieser Stelle die Grenze, obwohl jede Einzelaufgabe für sich genommen bereits gelöst war.

Dieser Fall ist zehn Jahre alt und trotzdem lehrreich, denn er macht die Gegenposition konkret: Für manche Aufgaben ist die robotische Fähigkeit selbst noch nicht ausreichend, und dann lösen bessere Wartung oder ein klareres Serviceversprechen das Kernproblem nicht. Wo diese Grenze im Einzelfall liegt, muss jeweils geprüft werden — in der industriellen Praxis der letzten Jahre liegt sie häufiger woanders, als es das Modell allein vermuten lässt.

Was der BMW-Einsatz über verschobene Fragen zeigt

Beim BMW-Werk Spartanburg in South Carolina lässt sich diese Verschiebung an einem realen Fall nachvollziehen. Zehn Monate lief dort ein humanoider Roboter von Figure im Pilotbetrieb, fünf Tage die Woche in Zehn-Stunden-Schichten. In dieser Zeit bearbeitete er laut BMW über 30.000 X3-Karosserien und bewegte mehr als 90.000 Komponenten, verteilt auf rund 1.250 Betriebsstunden und etwa 1,2 Millionen Schritte.

Diese Zahlen beeindrucken, doch BMW beschreibt für die Spartanburg-Erprobung zugleich, dass zusätzliche Sicherheitsbarrieren und eine verbesserte 5G-Abdeckung der Halle nötig wurden — eine Betreiberangabe zu einem konkreten Pilotprojekt, keine allgemeine Aussage über jeden Humanoiden-Einsatz. Genau deshalb ist sie aufschlussreich: Nicht das Greifen oder das Gehen war es, das nachjustiert werden musste, sondern die Umgebung, in der beides passiert.

Wichtig ist dabei eine Einordnung, die im Eifer des Vergleichs leicht übergangen wird. Diese Anpassungen sind eine Betriebspraxis am US-Standort Spartanburg — keine CE-Kennzeichnung und kein Nachweis nach der EU-Maschinenverordnung. South Carolina liegt außerhalb des EU-Rechtsraums, und was dort als Sicherheitsmaßnahme galt, sagt nichts darüber aus, was ein Betreiber in Deutschland oder der EU nachweisen müsste.

Eine ähnliche Verschiebung zeigt sich in der Logistik. GXO Logistics und Agility Robotics haben am 27. Juni 2024 eine mehrjährige Robots-as-a-Service-Vereinbarung geschlossen, in der der zweibeinige Roboter Digit in bestehende Lagerautomation integriert wird. Dass solche Modelle real eingesetzt werden, zeigt diese Vereinbarung deutlich — welche Wartungs-, Verfügbarkeits- und Kostenrisiken im Einzelnen bei welcher Partei liegen, lässt sich aus der Ankündigung allein aber nicht ablesen.

Dieselben BMW-, Figure- und GXO/Agility-Zahlen ordnet ein anderer Beitrag dieses Portals bereits nach Kosten pro Output ein. Hier geht es um eine andere Frage: an welcher Stelle der Kette der Engpass tatsächlich sitzt, nicht darum, was die produktive Stunde kostet.

Eine schnellere Teilfunktion erhöht nicht automatisch den Durchsatz

Ein Modell, das eine Teilfunktion beschleunigt, wirkt zunächst wie ein Fortschritt, den jeder Betrieb sofort spürt. Ob das stimmt, hängt davon ab, wo die Teilfunktion in der Kette steht, denn der Rest der Kette muss mithalten können.

Ein vereinfachtes, ausdrücklich stationäres Rechenbeispiel ohne Puffer- und Ausfalleffekte macht das greifbar. Eine Zelle besteht aus drei Stationen: einer Materialzuführung, die 60 Aufgaben pro Stunde bereitstellt, einem Roboter, der 90 Aufgaben pro Stunde bewältigen kann, und einem nachgelagerten Prozess, der 75 Aufgaben pro Stunde verarbeitet. Wer nur auf den Roboter schaut, sieht ein leistungsfähiges Glied. Die Kette insgesamt verarbeitet trotzdem höchstens 60 Aufgaben pro Stunde, weil die Materialzuführung das langsamste Glied ist.

Steigt die Roboterkapazität von 90 auf 120 Aufgaben pro Stunde, ändert sich an dieser Grenze zunächst nichts. Die Materialzuführung liefert weiterhin nur 60 Aufgaben pro Stunde, und der nachgelagerte Prozess bleibt bei 75 Aufgaben pro Stunde — die Kette bleibt bei 60 Aufgaben pro Stunde stehen, obwohl ein einzelnes Glied deutlich schneller geworden ist. Erst eine Parallelisierung der Zuführung oder eine zweite Linie würde die tatsächliche Grenze verschieben, nicht eine weitere Nachkommastelle beim Roboter selbst.

Recovery kann wichtiger werden als die nächste Nachkommastelle

Modelle werden häufig an Erfolgsraten gemessen: 95 Prozent statt 92 Prozent einer Aufgabe korrekt ausgeführt. Für einen einzelnen Demo-Lauf ist das ein sinnvoller Maßstab. Für einen Betrieb mit mehreren Robotern zählt eine andere Zahl stärker, nämlich wie lange es dauert, bis ein Mensch eingreift, wenn der Roboter scheitert, und wie oft das passiert.

Eine ausdrücklich hypothetische Rechnung macht den Unterschied deutlich — ohne Reise-, Warte-, Diagnose- und Gleichzeitigkeitsaufwand, also mit Annahmen, keine Herstellerdaten. Bei 100 Robotern, die jeweils 40 Stunden pro Woche laufen, und einem angenommenen Fünf-Minuten-Eingriff je zehn Betriebsstunden kommt die Rechnung auf rund 33,3 Eingriffsstunden pro Woche. Das ist keine Marktzahl, sondern eine Illustration: Schon eine kleine, scheinbar harmlose Eingriffsrate summiert sich über eine Flotte zu einer Personalgröße, die geplant werden muss.

Ob ein Modell diese Eingriffsrate senkt, hängt oft weniger von der letzten Nachkommastelle der Erfolgsquote ab als davon, wie ein Fehler erkannt, gemeldet und behoben wird. Ein Roboter, der bei einem Fehlversuch sauber anhält, sich selbst diagnostiziert und einen verständlichen Hinweis gibt, kann für den Betrieb wertvoller sein als einer, der seltener scheitert, dafür aber unklar bleibt, warum. Recovery ist deshalb häufig die praktisch wirksamere Stellschraube — nicht, weil die Modellgüte unwichtig wäre, sondern weil sie an dieser Stelle der Kette nicht mehr die engste ist.

Sicherheit ist eine Bedingung des Prozesses, kein nachträglicher Abzug

Sicherheit wird in Diskussionen über Physical AI oft als letzter Posten behandelt: erst die Fähigkeit bauen, dann den Nachweis nachschieben. In der Praxis verläuft es andersherum, denn eine Sicherheitsanforderung entscheidet häufig schon während der Entwicklung, welche Lösung überhaupt in Frage kommt.

Das Forschungsprogramm des Robotics Institute Germany zu Safety, Reliability und Resilience betont entsprechend das Zusammenspiel von Fähigkeit, Integration und Nachweisen — eine universelle Zertifizierungsmethode ist daraus bisher nicht entstanden, wohl aber eine Leitidee: Assurance entsteht nicht am Ende, sondern begleitet Design und Integration von Anfang an.

Wie ein solcher Nachweis im Detail aussehen kann, behandelt ein anderer Beitrag dieses Portals ausführlich: den Sicherheitsnachweis mit seinem vierstufigen Validierungsmodell — von der Simulation über den geschlossenen Regelkreis bis zum Realbetrieb und der laufenden Überwachung. Hier zählt vor allem die Konsequenz für den Engpass. Wenn eine Fähigkeit im Labor funktioniert, aber der Sicherheitsnachweis dafür fehlt, ist die Fähigkeit vorhanden, der Einsatz aber trotzdem blockiert. Der Engpass sitzt dann im Nachweisprozess, nicht im Modell.

Integration ist kein Restposten der Entwicklung

Für kleinere und mittlere Unternehmen zeigt sich diese Verschiebung besonders deutlich, denn ihnen fehlen oft die Ressourcen, um ein neues Robotersystem in vorhandene Abläufe einzupassen.

Das Projekt RoX benennt Auswahl und Integration von Robotern und Peripheriegeräten als größte Hürde für die Automatisierung kleiner und mittlerer Unternehmen und setzt dafür auf KI-gestützte Systemkonfiguration. Das belegt den bearbeiteten Bedarf, nicht automatisch eine bereits gemessene Kostensenkung bei allen Anwendern — aber es belegt, dass die Integration selbst als das größere Problem gilt, nicht die einzelne Fähigkeit des Roboters.

Integration ist deshalb kein letzter Schritt vor dem Rollout, den man einem Systemintegrator kurz vor der Inbetriebnahme überlässt. Sie entscheidet, ob eine im Labor gezeigte Fähigkeit in der bestehenden Zellensteuerung, im vorhandenen Lagerverwaltungssystem oder in der Sicherheitsschaltung des Betriebs überhaupt ankommt. Ein Modell, das isoliert brillant funktioniert, aber keine Schnittstelle zur bestehenden Anlage findet, bleibt für den Betrieb wirkungslos, so gut seine Demo auch aussah.

Der hundertste Roboter stellt eine andere Servicefrage

Ein einzelner Pilotroboter lässt sich von einem Techniker begleiten, der ohnehin in der Halle ist. Bei hundert Robotern ist das keine Blaupause mehr, denn es entsteht eine eigene Servicefrage: Wer diagnostiziert, wer ersetzt Verschleißteile, wer reist zu welchem Standort, und wie schnell muss das gehen, bevor eine Linie stillsteht?

Genau deshalb setzen Anbieter wie Agility Robotics zunehmend auf Robots-as-a-Service-Modelle, bei denen die Wartung Teil des Vertrags ist und nicht Sache des Kunden — sichtbar an der mehrjährigen Vereinbarung mit dem Logistiker GXO. Das verschiebt die Servicefrage vom einzelnen Betrieb zum Anbieter, löst sie aber nicht auf, denn irgendjemand muss weiterhin dafür sorgen, dass hundert Roboter an verschiedenen Standorten innerhalb einer vertretbaren Zeit wieder laufen.

Ein Modell, das im Labor mit einem einzelnen Gerät überzeugt, sagt über diese Frage nichts aus. Die Fähigkeit skaliert oft besser als die Organisation, die dahinterstehen muss. Wandert der Engpass in dieser Phase, verschiebt er sich von der Fähigkeit zur Serviceorganisation, ohne dass sich am Roboter selbst etwas geändert hätte.

Fertigung verändert den Gegenstand der Prüfung

Ein weiterer Ort, an dem sich der Engpass verschiebt, ist die Fertigung des Roboters selbst. Ein System, das in einer Werkstatt von Ingenieuren gebaut wird, unterliegt anderen Prüfmaßstäben als eines, das in Serie entstehen soll, denn Serienfertigung bringt Streuung mit sich, die ein Einzelstück nicht kennt.

Figure benennt in der eigenen Rückschau zum Spartanburg-Einsatz den Unterarm als wesentlichen Hardware-Fehlerpunkt und beschreibt daraus abgeleitete konstruktive Änderungen für die nächste Generation — ein quantitativ belegter Zuverlässigkeitsgewinn dieser neuen Generation liegt bisher nicht vor. Bemerkenswert ist weniger das einzelne Bauteil als die Reihenfolge: Der reale Betrieb hat eine Schwachstelle offengelegt, die im Entwicklungslabor offenbar nicht in derselben Häufigkeit auftrat, und diese Erkenntnis fließt zurück in die Konstruktion.

Wer nur die Software-Iteration zählt, übersieht damit eine zweite, langsamere Feedbackschleife. Jede neue Fertigungsgeneration eines Roboters muss erneut zeigen, dass sie so robust ist wie versprochen, unabhängig davon, wie gut das zugrunde liegende Modell inzwischen geworden ist. Der Prüfgegenstand ändert sich mit jeder Hardware-Revision — und damit auch die Frage, ob der Engpass gerade im Modell, in der Konstruktion oder in der Fertigungstoleranz liegt.

Wirtschaftlichkeit beginnt beim tatsächlich nutzbaren Ergebnis

Wirtschaftlichkeit wird in Vorstellungen von Physical AI oft an der Investitionssumme oder am Stundenlohn gemessen, den ein Roboter angeblich ersetzt. Näher an der Praxis liegt eine andere Rechnung: was jede tatsächlich erfolgreich verarbeitete Aufgabe kostet, nicht jede versuchte.

Ein bewusst vereinfachtes Beispiel zeigt den Unterschied. Bei angenommenen Jahreskosten von 100.000 Euro und 400.000 tatsächlich erfolgreich verarbeiteten Aufgaben ergeben sich rechnerisch 25 Cent pro Aufgabe. Gelingen wegen häufigerer Ausfälle oder Recovery-Zeiten nur 200.000 Aufgaben, verdoppeln sich die Stückkosten auf 50 Cent — bei identischer Anschaffung und identischem Modell. Die Rechnung trifft keine Aussage über branchenübliche Preise, sondern zeigt nur, weshalb die tatsächliche Nutzleistung zählt, nicht die theoretische.

Ein leistungsfähigeres Modell kann diese Rechnung verbessern, wenn es die Erfolgsquote der einzelnen Aufgabe erhöht. Es kann sie aber auch unverändert lassen, wenn der Engpass woanders sitzt — bei der Recovery-Zeit, bei der Verfügbarkeit von Ersatzteilen oder beim Personal, das im Störfall eingreifen muss. Wirtschaftlichkeit ist damit kein Attribut des Modells allein, sondern ein Ergebnis der ganzen Kette aus Fähigkeit, Integration, Sicherheit, Service und Fertigung.

Einen Engpass identifizieren heißt, eine überprüfbare Hypothese bilden

Wenn der Engpass je nach Ziel und Phase woanders sitzt, wie findet man ihn dann für den eigenen Fall? Die nüchterne Antwort lautet: nicht durch Zuschauen bei einer Vorführung, sondern durch eine überprüfbare Annahme, die sich an echten Betriebsdaten widerlegen lässt.

Das National Robotics Engineering Center der Carnegie Mellon University stellt bei kommerziellen Robotikprojekten das Geschäftsproblem ausdrücklich an den Anfang des Entwicklungsprozesses. Daraus lässt sich kein universeller Rentabilitätsmaßstab ableiten, wohl aber eine Reihenfolge: zuerst festlegen, welches wirtschaftliche oder organisatorische Problem gelöst werden soll, dann prüfen, ob die technische Machbarkeit an dieser Stelle überhaupt die engste Grenze ist.

Eine Hypothese in diesem Sinn könnte lauten: Sinkt die Recovery-Zeit pro Störfall um die Hälfte, sinkt auch die benötigte Eingriffszeit über die Flotte in einem messbaren Umfang. Diese Annahme lässt sich an echten Betriebsdaten prüfen — anders als der allgemeine Eindruck, ein Roboter sei „noch nicht reif genug“. Wer den Engpass so formuliert, kann ihn widerlegen oder bestätigen. Wer ihn nur spürt, kann ihn nur behaupten.

Ein Pilot kann den eigentlichen Engpass verdecken

Ein Pilot ist naturgemäß eine Umgebung, in der vieles besser läuft als im Regelbetrieb. Er hat aufmerksames Personal, kurze Kommunikationswege zum Hersteller und meist eine überschaubare Aufgabenmenge — Bedingungen, die im späteren Alltag selten alle gleichzeitig vorliegen.

Das ist kein Vorwurf an die beteiligten Unternehmen, sondern eine Eigenschaft der Situation. Läuft ein Pilot erfolgreich, weil ein Ingenieur ständig in Rufweite ist, dann hat der Pilot die Serviceorganisation stillschweigend mitgelöst, ohne dass das im Ergebnis sichtbar wird. Der eigentliche Engpass — eine belastbare Serviceorganisation für viele Standorte ohne ständige Herstellerpräsenz — taucht dann erst auf, sobald der Pilot in eine Fläche überführt wird.

Deshalb sagt eine Pilot-Erfolgsmeldung wenig darüber aus, welche Grenze als Nächstes verschoben werden muss. Sie zeigt, dass etwas unter den Bedingungen des Piloten funktioniert hat, nicht, dass diese Bedingungen im Regelbetrieb ebenfalls gelten. Wer aus einem gelungenen Pilot auf einen gelösten Engpass schließt, verwechselt eine Momentaufnahme mit einem Dauerzustand.

Fortschritt ist die Verschiebung einer realen Grenze

Am Ende dieser Kette bleibt eine einfache, aber unbequeme Feststellung: Fortschritt in Physical AI zählt nur dort, wo er die gegenwärtig wirksame Grenze tatsächlich verschiebt. Ein leistungsfähigeres Modell, eine schnellere Teilfunktion, eine höhere Erfolgsquote — jedes davon kann ein echter Fortschritt sein und trotzdem am tatsächlichen Engpass eines Betriebs vorbeigehen.

Translation ersetzt keine Forschung: Für manche Aufgaben ist die robotische Fähigkeit selbst noch nicht ausreichend, und dann lösen bessere Wartung oder ein klareres Serviceversprechen das Kernproblem nicht. Ebenso gilt die Umkehrung — für viele Aufgaben ist die Fähigkeit längst vorhanden, und der Engpass liegt in Sicherheit, Integration, Service oder Fertigungsstreuung, also in Bereichen, die selten in einer Produktvorführung auftauchen, weil sie sich schlecht in ein Video fassen lassen.

Wer die nächste Ankündigung aus diesem Feld liest, kann sich deshalb eine einzige Frage vornehmen: Löst der beschriebene Fortschritt tatsächlich die Grenze, die den eigenen Fall gerade begrenzt — oder liegt diese Grenze längst woanders?