Physical AI: Was heute verfügbar ist und wie der Einstieg gelingt

Physical AI lässt sich bereits in Projekten einsetzen, die mit Simulation beginnen. Ob ein Roboter autonom zuverlässig arbeitet, muss sich jedoch für jede Aufgabe einzeln zeigen. Googles aktuelles Aktionsmodell Gemini Robotics 2 ist beispielsweise weiterhin nur als Private Preview zugänglich. Zugang zu einem KI-Modell zu haben und eine verlässlich arbeitende Maschine im eigenen Betrieb einzusetzen, sind zwei verschiedene Meilensteine.

Verfügbarkeit am 23. Oktober 2026 anhand der aktuellen Herstellerseiten geprüft. Googles Seite zum Aktionsmodell bestätigt diesen Preview-Status. Für Fertigung, Logistik und Handel gilt eine einfache Regel: Zuerst ein konkretes betriebliches Problem definieren und modellieren. Bevor Maschinen mehr Autonomie erhalten, müssen belastbare Nachweise vorliegen.

Was ist Physical AI?

Physical AI bezeichnet Modelle, mit denen Maschinen ihre Umgebung wahrnehmen, das Geschehen einordnen und in der physischen Welt handeln können. Ein Roboter muss berücksichtigen, wo ein Gegenstand liegt, ob sein Greifer ihn erreicht und was beim Kontakt passiert. NVIDIAs Definition von Physical AI verknüpft diese Fähigkeiten mit Daten aus der realen Welt, Simulation und der Rechentechnik, auf der autonome Maschinen laufen.

Das lässt sich mit der Probe eines Ladevorgangs vergleichen. Der Ablaufplan beschreibt, was geschehen soll. Die Probe zeigt, ob die Ausrüstung passt, das Timing stimmt und ein Hindernis einen anderen Ablauf nötig macht. Physische KI braucht genau dieses Verständnis: Jede Handlung verändert die Szene, die das System als Nächstes beobachtet.

Ein digitaler Zwilling bildet eine reale Maschine, einen Prozess oder einen Raum digital ab und bietet eine Umgebung für solche Proben. Er gehört zu den Entwicklungswerkzeugen für Physical AI, ist aber nicht automatisch ein KI-System oder eine Robotersteuerung. Ein virtuelles Anlagenlayout kann schon nützlich sein, bevor überhaupt eine Maschine autonom arbeitet.

Wie hängen physische KI und Robotik zusammen?

Die Robotik liefert Körper, Sensoren und Steuerungen; physische KI ergänzt das System um erlernte Fähigkeiten. Eine herkömmliche Maschine, die eine festgelegte Abfolge ausführt, wird durch ein neues Etikett des Anbieters noch nicht zum universell einsetzbaren KI-Roboter.

Chat-Agenten geben vor allem Antworten oder bedienen Software-Tools. Programmieragenten verändern Software. Bei Physical AI kommen Bewegung, Kontakt, Timing und die Wiederaufnahme nach Störungen in einer veränderlichen Umgebung hinzu. Auch Software-Agenten können über angebundene Systeme physische Abläufe auslösen. Die sinnvolle Abgrenzung liegt deshalb in der gesteuerten Arbeit, nicht im Aussehen der Benutzeroberfläche.

Unser Grundlagenartikel zu multimodaler KI erklärt Modelle, die Eingaben wie Text, Bilder und Ton kombinieren. Das ist ein Teil der Modellseite von Physical AI. Einen beschädigten Karton auf einem Bild zu erkennen und ihn zuverlässig aus einem Arbeitsbereich mit laufenden Bewegungen zu entfernen, bleiben unterschiedliche technische Aufgaben.

Embodied AI und Physical AI: Wo liegt der Unterschied?

Die Begriffe lassen sich als überlappende Arbeitsdefinitionen verstehen. Embodied AI betont Intelligenz, die über einen Körper mit einer Umgebung interagiert. Physical AI bezeichnet hier das umfassendere System einschließlich Weltmodellen, Simulation und Infrastruktur für den Einsatz. Bei der Beschaffung zählen die Aufgabe, die Betriebsbedingungen und das nachgewiesene Verhalten mehr als die Bezeichnung auf dem Angebot.

Was ist heute bereits verfügbar?

Wesentliche Bausteine für die Entwicklung sind schon erhältlich. Das betriebliche Gesamtsystem muss dennoch integriert und validiert werden. Die folgende Übersicht trennt die Funktion einer Komponente von ihrer Zugänglichkeit. Die Angebote decken verschiedene Ebenen ab; sie sind keine austauschbaren Produkte für dieselbe Kaufentscheidung.

Generative physische KI: NVIDIA Cosmos liefert Trainingsmaterial

NVIDIA Cosmos umfasst Basismodelle für die physische Welt und Entwicklungswerkzeuge für Physical AI. Ein Weltmodell lernt Muster im Verhalten von Umgebungen; synthetische Daten sind generiertes Trainingsmaterial. Die aktuelle Cosmos-Seite von NVIDIA führt Cosmos 3 Super, Nano und Edge auf. Sie bietet Modelldownloads, eine gehostete Testmöglichkeit sowie Ressourcen, um Modelle an bestimmte Umgebungen und Roboterkörper anzupassen.

Ein Entwicklungsteam in der Logistik könnte damit die Trainingsvarianten für eine Aufgabe erweitern, etwa durch unterschiedliche Umgebungsbedingungen oder Anordnungen von Gegenständen. Cosmos unterstützt außerdem das Schlussfolgern und die Erzeugung von Aktionen. Für Betreiber ist entscheidend, welche dieser Funktionen der Integrator nutzt und wie er die Ergebnisse überprüft.

Die Grenze wird ungewöhnlich deutlich benannt. Laut NVIDIAs Modellkarte für Cosmos3-Edge verfügt das Modell über keinen expliziten Physiksimulator und kann fehlerhafte Schlussfolgerungen sowie physikalisch unplausible Interaktionen erzeugen. Generierte Ergebnisse sind daher keine verlässlichen Referenzdaten für die physische Realität. Ein überzeugendes Video eines erfolgreichen Greifvorgangs belegt nicht, dass ein Greifer die eigene Verpackung tatsächlich halten kann.

Cosmos ist sinnvoll, wenn das Entwicklungsteam ein klar umrissenes Problem bei Daten oder Modellanpassung lösen muss. Der Download ersetzt weder aufgabenspezifische Daten noch Evaluierung oder Robotikentwicklung.

NVIDIA Isaac stellt die Entwicklungsumgebung bereit

NVIDIA Isaac ist die übergeordnete Plattform für die Robotikentwicklung. Ihre Komponenten übernehmen unterschiedliche Aufgaben: NVIDIA Isaac Sim erzeugt virtuelle Umgebungen für Tests und synthetische Daten; NVIDIA Isaac Lab trainiert Roboterverhalten; NVIDIA Isaac ROS liefert beschleunigte Robotiksoftware auf Basis von ROS 2, einem Framework zur Verbindung von Robotersoftware-Komponenten. NVIDIA erläutert diese Rollen auf der Isaac-Plattformseite.

Für ein Simulationsprojekt gibt es einen konkreten Einstieg. Das Framework Isaac Sim lässt sich herunterladen. Es unterstützt den Import technischer Modelle, die Zuweisung physikalischer Eigenschaften, die Konfiguration von Sensoren und Tests des Roboterverhaltens. Dabei kann simulierte Software oder reale, an die Simulation angeschlossene Hardware eingesetzt werden.

Plant ein Fertigungsbetrieb eine neue Handhabungszelle, kann der Integrator damit den vorgesehenen Roboter, die Objekte und den Arbeitsraum vor der Inbetriebnahme untersuchen. Die Schwierigkeit bleibt, die Aufgabe korrekt abzubilden: Eine ansprechend gerenderte Szene mit falschem Kontaktverhalten taugt wenig als Test.

Nicht jedes Projekt braucht sämtliche Isaac-Komponenten. Der Integrator sollte für jeden vorgeschlagenen Baustein erklären können, welchen Beitrag er zum Abnahmetest leistet.

Was ein Physical-AI-Modell beiträgt: NVIDIA Isaac GR00T

NVIDIA Isaac GR00T enthält ein Robotik-Basismodell, das sich an bestimmte Roboterkörper, Aufgaben und Umgebungen anpassen lässt. Sein Vision-Language-Action-Modell, kurz VLA, verknüpft visuelle Eingaben und sprachliche Anweisungen mit Roboteraktionen. Es entscheidet damit eher über eine Bewegung, als lediglich eine Erklärung dazu zu erzeugen.

NVIDIAs GR00T-Release-Repository weist N1.7 als allgemein verfügbar aus und stellt Modellgewichte, Referenzcode sowie Abläufe für Fine-Tuning und Inferenz mit Roboterdaten bereit. Fine-Tuning bedeutet, das Modell anhand zusätzlicher Beispiele für die vorgesehene Arbeit anzupassen.

Für die Beschaffung ist ein Widerspruch in der Dokumentation relevant. Das Repository nennt den Produktiveinsatz mit kommerziellem Support. Die Produkt-FAQ beschreibt 1.7 dagegen weiterhin als Early Access und schließt diesen Support aus. Die ausdrückliche Freigabe zur allgemeinen Verfügbarkeit, kurz GA, ist hier die Grundlage für die Einordnung. Der Supportumfang für die beschaffte Version, Roboterhardware und Einsatzform sollte schriftlich bestätigt werden.

GR00T kommt infrage, wenn ein Robotikpartner eine erlernte Steuerungsstrategie anpassen und validieren kann. Eine solche „Policy“ ordnet Beobachtungen Aktionen zu. Das Modell allein belegt nicht, dass ein beliebiger Roboter einen beliebigen Prozess übernehmen kann.

NVIDIA Omniverse liefert die virtuelle Testumgebung

NVIDIA Omniverse ist eine Sammlung von Bibliotheken, APIs und Diensten, die Softwareentwickler in technische Anwendungen und Simulationssoftware einbinden. Die aktuelle Produktseite nennt neben Rendering, Physik und Sensorsimulation auch die Unterstützung für OpenUSD, ein Format zur Verknüpfung strukturierter Szenendaten.

Aus Sicht der Betriebsleitung zählt ein nutzbares Modell des Prozesses oder der Anlage, nicht ein beeindruckender virtueller Rundflug. Ein Lagerzwilling könnte helfen zu prüfen, ob eine geänderte Route Staus verursacht. Ein Fertigungszwilling könnte die Bewertung von Reichweite, Freiräumen oder Layoutänderungen unterstützen. Das sind mögliche Anwendungen, keine zugesagten Ergebnisse.

Omniverse und Cosmos haben unterschiedliche Aufgaben. Omniverse hilft, strukturierte virtuelle Umgebungen aufzubauen und zu testen. Cosmos liefert erlernte Modelle und generiertes Material für die Entwicklung. NVIDIA weist selbst darauf hin, dass einer visuell vollständigen Szene noch die für eine Simulation nötigen Eigenschaften fehlen können. Ein Zwilling wird erst glaubwürdig, wenn er mit relevanten Beobachtungen am Standort übereinstimmt.

Gemini Robotics: Unterschiedlicher Zugang zu Schlussfolgern und Handeln

Die Modellfamilie Gemini Robotics von Google DeepMind trennt das Verständnis einer physischen Aufgabe von der Ausführung einer Roboterbewegung. Diese Unterscheidung bestimmt, was der Entwicklungspartner schon heute erproben kann.

Gemini Robotics ER 2, das Modell zum Schlussfolgern in der physischen Welt, ist über Google AI Studio und die Gemini API als Public Preview zugänglich. Es unterstützt räumliches Verständnis, Planung und die Überprüfung des Aufgabenerfolgs. Seine Ausgabe ist Text; die motorische Ausführung übernimmt ein nachgeordnetes Aktionsmodell. Googles Entwicklerdokumentation beschreibt außerdem, wie sich das Schlussfolgern mit eigenen Roboterfunktionen verbinden lässt.

Das Aktionsmodell Gemini Robotics 2 verarbeitet Bild- und Texteingaben und erzeugt Aktionen. Es befindet sich in der Private Preview. Gemini Robotics On-Device 2 soll lokal auf Roboterhardware laufen und ist für ausgewählte Tester verfügbar.

ER bietet damit einen Einstieg für die Evaluierung durch Entwickler. Die vollständige Robotersteuerung wird dadurch noch nicht zu einem fertig kaufbaren Gesamtsystem. Hinzu kommt eine wesentliche Nutzungsgrenze: Die Modellkarte zu ER 2 schließt sicherheitskritische Anwendungen aus, bei denen eine Fehlfunktion absehbar Verletzungen, Todesfälle oder Sachschäden verursachen könnte. Bevor der Partner einen Einsatz zusagt, muss er klären, ob die geplante Nutzung mit diesen Bedingungen vereinbar ist.

Physical AI in der Praxis: Produktiveinsatz, Pilotprojekte und Entwicklung

Die belastbarsten Nachweise für den Produktiveinsatz können Planungssoftware betreffen, während das Roboterverhalten noch entwickelt wird. Bei der Bewertung einer Anbieterreferenz müssen diese Aussagen getrennt bleiben.

BMW gibt an, für alle 30+ Werke digitale Zwillinge entwickelt zu haben. Die Planungsteams nutzen demnach Omniverse, um Produktionsprozesse gemeinsam zu entwerfen. Das ist ein konkreter Nachweis für digitale Planung im Betrieb. Es belegt nicht, dass ein universell einsetzbares Robotermodell diese Werke autonom betreibt. BMWs Produktionsübersicht beschreibt die Arbeit direkt.

NVIDIAs Mitteilung zur Weiterentwicklung der Isaac-Plattform beschreibt, dass Humanoid Verhaltensweisen vor industriellen Pilotprojekten entwickelt und validiert. Separat wird erläutert, wie Bear Robotics GR00T für Lager-, Retouren- und Industrieabläufe anpasst. Das sind konkret benannte Entwicklungsarbeiten. Keine der beiden Aussagen darf als Beleg für dauerhaft stabile Produktionsleistung bei der eigenen Aufgabe ausgelegt werden.

Google DeepMind nennt Agile Robots, Apptronik und Boston Dynamics als Forschungspartner. Eine Forschungspartnerschaft belegt Zusammenarbeit, keine Kundenabnahme eines vollständigen Systems.

Für jedes Angebot sollte derselbe Maßstab gelten: Eine Demonstration zeigt eine Fähigkeit; ein Pilotprojekt prüft einen begrenzten Anwendungsfall; Nachweise aus dem Produktivbetrieb zeigen wiederholbare Leistung unter realen Betriebsbedingungen. Entscheidend ist, was davon die Referenz tatsächlich belegt und welche Unterschiede zwischen dem Referenzstandort und dem eigenen Betrieb bestehen.

Mit dem digitalen Zwilling einer einzelnen Aufgabe beginnen

Das erste Projekt sollte eine betriebliche Frage beantworten, bevor die Entscheidung für eine Roboterflotte fällt. Bei einer neuartigen Automatisierungsaufgabe gibt ein klar begrenztes Simulationsprojekt dem Entwicklungsteam etwas Konkretes, das es validieren kann.

In der Fertigung könnte es darum gehen, ob eine Handhabungszelle mit der tatsächlichen Mischung aus Teilen und Behältern zurechtkommt. In der Logistik wäre eine mögliche Frage, ob eine geplante Fahrtroute auch bei gesperrtem Gang funktioniert. Im Handel bietet sich für den Einstieg ein kontrollierter Retouren- oder Auftragsabwicklungsbereich an, in dem sich Objekte, Zugänge und Abläufe zur Störungsbehebung klar festlegen lassen.

Diese Beispiele veranschaulichen mögliche Projektumfänge. Keines setzt einen humanoiden Roboter voraus. Manche Aufgaben lassen sich womöglich besser mit herkömmlicher Automatisierung oder einer Prozessänderung lösen.

1. 1

   Aufgabe und Abnahmenachweise festlegen

   Ausgangszustand, gefordertes Ergebnis, zulässige Objekte, Arbeitsbereich und Ausnahmefälle beschreiben. Die heutige Leistung erfassen. Festlegen, wie Aufgabenerfüllung ohne menschlichen Eingriff, Taktzeit, Qualitätsmängel und Aufwand zur Störungsbehebung gemessen werden. Die Erfolgskriterien mit den Prozessverantwortlichen vereinbaren, bevor die Demo gezeigt wird.

2. 2

   Daten für ein belastbares Modell zusammenstellen

   Vermessene Layouts oder technische Zeichnungen, Anlagengeometrie, Roboter- und Greiferspezifikationen, Kamerapositionen und relevante physikalische Eigenschaften zusammentragen. Hinzu kommen der tatsächliche Produktmix, Verpackungsvarianten, Videos der Aufgabe und Fehlerprotokolle. Ein Lernprojekt kann außerdem aufgezeichnete Roboterdemonstrationen benötigen. Mit dem Integrator klären, welche fehlenden Daten einen aussagekräftigen Test verhindern würden.

3. 3

   Aufgabe modellieren und Modell überprüfen

   Den Integrator den kleinstmöglichen sinnvollen Zwilling erstellen lassen. Seine Vorhersagen mit Beobachtungen aus dem bestehenden Prozess oder einem kontrollierten Test vergleichen. Relevante Bedingungen variieren, etwa Objektposition, Sichtbarkeit und Hindernisse. Generierte Daten als zusätzliches, prüfbedürftiges Trainings- oder Testmaterial behandeln; sie belegen nicht, dass die reale Aufgabe gelingen wird.

4. 4

   Vor der Ausweitung einen begrenzten Praxistest durchführen

   Mit der vereinbarten Aufgabe, den festgelegten Bedingungen und dem vorgesehenen Ablauf zur Störungsbehebung arbeiten. Jeden Versuch protokollieren, einschließlich Eingriffen und gescheiterten Wiederanläufen. Die Ergebnisse mit dem Ausgangswert und den Erwartungen aus der Simulation vergleichen. Erst ausweiten, wenn das gemessene Ergebnis die Abnahmekriterien erfüllt. Andernfalls Modell, Aufgabe oder vorgeschlagene Ausrüstung überarbeiten.

Integration passend zur Aufgabe beschaffen

Als Anbieter kommt meist ein Robotik-Systemintegrator, ein Integrator für Industriesoftware oder ein Automatisierungshersteller mit passender Anwendungserfahrung infrage. Ein Systemintegrator verbindet Hardware, Software, Standortanbindungen und Inbetriebnahme zu einer funktionierenden Anlage.

Bei einem Projekt, das mit dem digitalen Zwilling beginnt, braucht es einen Partner, der technische Modelle mit Betriebsdaten verknüpfen und die Simulation validieren kann. Für einen Robotertest ist zusätzlich Erfahrung mit dem gewählten Roboter, Greifer, den Steuerungen und den angrenzenden Abläufen nötig. Für Inbetriebnahme, Wiederanlauf nach Ausnahmefällen, Wartung und Änderungen nach der Übergabe müssen die Verantwortlichkeiten klar sein.

Betreiber sollten jetzt handeln, wenn ein konkreter Engpass, ein Prozessverantwortlicher und nutzbare Daten vorhanden sind. Entwicklungsteams sollten jetzt Modelle evaluieren, wenn sie einen Testaufbau erstellen und Ergebnisse vergleichen können. Mit einer umfassenden Beschaffung von Robotern sollte gewartet werden, solange die Aufgabe unklar ist oder das Angebot die Integrations- und Abnahmearbeiten nicht benennt. Unternehmen, die Fragen zu Dokumenten beantworten oder Softwareanfragen weiterleiten wollen, können weiterhin digitale Agenten evaluieren, ohne ein Physical-AI-Projekt aufzusetzen.

Welche Erwartungen an Physical AI sind überzogen?

Überzogen ist das Versprechen, ein leistungsfähigeres Modell mache den Rest der Installation zur Routine. Die Herstellerdokumentation zeigt das Gegenteil: Daten, Anpassung, Simulation und die technische Umsetzung des Einsatzes bleiben eigenständige Aufgaben.

Eine generierte Welt ist nicht automatisch ein verlässlicher Physiktest. Eine herunterladbare Steuerungsstrategie passt nicht automatisch zu Roboterkörper, Sensoren und Aufgabe. Eine erfolgreiche Demonstration belegt keine Leistung über eine ganze Schicht, erst recht nicht, wenn Angaben zu Fehlern und Eingriffen fehlen.

Häufig fehlt die Messung des Aufwands nach einer Störung. Bewältigt ein System den Normalfall, muss aber immer wieder von einem Menschen zurückgesetzt werden, gehört diese Arbeit in die Bewertung. Eine plakative Erfolgsquote ohne Angaben zum Aufgabenmix, zur Definition eines Eingriffs und zu den Betriebsbedingungen zeigt nicht, ob der Prozess tatsächlich besser wird.

Einen allgemeingültigen Countdown bis zum Einsatz von Physical AI gibt es nicht. Entscheidend ist, ob ein bestimmtes System eine bestimmte Aufgabe unter Bedingungen erfüllen kann, die sich beschreiben und überprüfen lassen.

Welche Fragen sollte ein Physical-AI-Anbieter beantworten?

Gefordert sind Nachweise, die sich auf die eigene Aufgabe beziehen. Mit diesen Fragen wird der vorgeschlagene Leistungsumfang konkret:

• Welche Modellversion, welcher Roboterkörper, welche Sensoren und welcher Greifer sind enthalten? Welche Bestandteile sind allgemein verfügbar, welche nur als Preview?
• Welcher namentlich genannte Kunde nutzt genau diesen Ablauf? Beschreibt die Referenz eine Demonstration, ein Pilotprojekt oder den laufenden Betrieb?
• Können Sie Versuchsprotokolle, Eingriffe, Fehler und Wiederanlaufzeiten für den von uns erwarteten Produktmix und die vorgesehenen Bedingungen vorlegen?
• Welche Daten müssen wir bereitstellen, wie werden sie genutzt und wer darf sie speichern? Was geschieht, wenn sich Verpackung oder Layout ändern?
• Wie gleichen Sie den Zwilling mit dem realen Standort ab? Welche physikalischen Effekte oder Fehlerfälle bildet das Modell nicht ab?
• Wer verantwortet Integration, Schutzfunktionen, Inbetriebnahme, Wartung und Support? Welche schriftlich vereinbarten Abnahmekriterien müssen für die Übergabe erfüllt sein?

Der nächste Schritt für Montag: Prozessverantwortliche, Fachleute für Steuerungstechnik und den möglichen Integrator anhand einer gemeinsamen Aufgabenbeschreibung zusammenbringen. Dazu gehören die Ausgangswerte und repräsentative Ausnahmefälle. Zuerst eine Machbarkeitsprüfung mit überprüfbarem Umfang beauftragen, dann eine umfassende Roadmap für den Robotereinsatz anfordern.

Häufige Fragen

Was ist ein Beispiel für Physical AI?

Ein Roboter, der ein Bauteil per Kamera lokalisiert, seinen Griff anpasst und anschließend prüft, ob die Bewegung erfolgreich war, veranschaulicht das Konzept. Ein digitaler Zwilling kann die Umgebung liefern, in der dieses Verhalten entwickelt und getestet wird. Der Zwilling selbst belegt keinen autonomen Betrieb.

Ist physische KI heute schon möglich?

Ja. Die beschriebenen Entwicklungswerkzeuge und Zugänge zu Modellen gibt es bereits. Ob eine konkrete Anlage zuverlässig arbeitet, muss für die jeweilige Aufgabe technisch geklärt und validiert werden.

Welche Unternehmen arbeiten an Physical AI?

NVIDIA bietet Cosmos, Isaac, GR00T und Omniverse an. Google DeepMind stellt die Modellfamilie Gemini Robotics bereit. Roboterhersteller und Integratoren verbinden Komponenten zu Systemen. Jede Aussage über eine Partnerschaft oder einen Einsatz benötigt eigene Nachweise.

Wie weit ist Physical AI?

Es gibt keinen einheitlichen Starttermin. Digitale Planung im Betrieb, verfügbare Entwicklungsframeworks, veröffentlichte Modelle und eingeschränkt zugängliche Previews existieren nebeneinander. Entscheidend sind der Zugangsstatus und die nachgewiesene Leistung genau des Systems, das benötigt wird.

Ist Physical AI der nächste große Technologietrend?

Für Betreiber zählt, ob ein begrenztes Projekt einen messbaren Prozess verbessert. Die Aufmerksamkeit für das Thema ist kein Grund, einen Roboter zu kaufen, bevor Aufgabe und Abnahmekriterien feststehen.

Für fundierte Entscheidungen zum KI-Einsatz den Newsletter abonnieren.