Die Landkarte ist voll, der Weg ist es nicht

Wenn Sie in einem mittelständischen Industrieunternehmen eine Robotik-Entwicklung von der Machbarkeitsstudie bis zum laufenden Betrieb verantworten, kennen Sie dieses Gefühl vermutlich schon. Eine kurze Suche zur deutschen Robotik-Förderung liefert binnen Minuten vier oder fünf klingende Namen.

Jeder trägt ein eigenes Logo, ein eigenes Programm, eine eigene Sprache. Die Frage, die für Ihr Projekt tatsächlich zählt, beantwortet keine dieser Seiten von sich aus: Wie kommt eine Idee von einem Namen zum nächsten, ohne dass Wissen, Verantwortung oder Finanzierung auf der Strecke bleiben?

Vier Bausteine tragen in Deutschland derzeit sichtbar zu dieser Frage bei, jeder mit einem anderen Auftrag. Das Robotics Institute Germany, kurz RIG, organisiert Forschung als gemeinsame Infrastruktur mehrerer Einrichtungen. RoX entwickelt ein Daten- und Diensteökosystem, das Hersteller, Integratoren und Anwender verbinden soll. AI-MATTERS betreibt über den deutschen Knoten der europäischen Testing and Experimentation Facilities eine produktionsnahe Testinfrastruktur. Und das Fraunhofer-Institut für Produktionstechnik und Automatisierung IPA hat mit seinem Reallabor eine Schnittstelle geschaffen, an der technische Erprobung und rechtliche Einordnung zusammentreffen.

Eine gut gefüllte Landkarte aus diesen vier Stationen beweist damit noch keinen reibungslosen Übergang, obwohl jede einzelne Station für sich genommen gut dokumentiert ist. Entscheidend ist, was bei jedem Wechsel von einer Station zur nächsten an Wissen, Verantwortung und Nachweisen tatsächlich mitgenommen wird — und was dabei verloren geht.

Für diese Unterscheidung verwendet dieser Beitrag zwei eigene Arbeitsbegriffe, die keinem etablierten Fachvokabular entstammen und das auch nicht behaupten sollen. „Translation Stack“ meint die Gesamtheit der vorhandenen Funktionen — sozusagen, was auf der Landkarte steht.

„Translation Pipeline“ meint dagegen den tatsächlich organisierten Weg eines konkreten Projekts durch einzelne dieser Funktionen. Der Unterschied ist wichtig, weil ein vollständiger Stack noch keine funktionierende Pipeline für Ihr Vorhaben ist — und weil umgekehrt ein einzelnes gut geführtes Projekt mehrere Stationen sinnvoll verbinden kann, ohne dass dafür eine neue zentrale Institution entstehen müsste.

Das Prüfraster: vier Stationen, vier offene Fragen

Bevor dieser Beitrag jede der vier Stationen einzeln einordnet, lohnt sich der Blick auf das Ergebnis in kompakter Form. RIG, RoX, AI-MATTERS und das Fraunhofer-Reallabor lassen sich danach ordnen, welchen Reifegrad sie adressieren, was über Kosten bekannt ist, und über welchen Weg ein Unternehmen tatsächlich Zugang findet. Für die eigene Vorhabensplanung ist dieses Raster gedacht — als Fragenkatalog, nicht als Empfehlung für eine bestimmte Station. Die Reifegrad-Spalte nennt dafür TRL-Werte (Technology Readiness Level, eine international verwendete Skala von 1 bis 9 für den technischen Reifegrad einer Entwicklung).

Von den zwölf Zellen zu Reifegrad, Kosten und Zugangsweg tragen drei eine belastbare Angabe, neun einen benannten Nullbefund. Das ist kein Rechercheversäumnis, sondern der reale Stand der öffentlich verfügbaren Angaben zum Zeitpunkt dieses Beitrags. Eine öffentlich benannte Kostenordnung für RIG-Innovation-Labs und den RoX-Datenraum liegt nach den hier ausgewerteten Quellen nicht vor, ebenso keine für das Fraunhofer-Reallabor. Auch der Zugangsweg — wer sich wie, mit welchem Vorlauf und über welche Ansprechstelle überhaupt bewerben kann — ist für keine der vier Stationen öffentlich beschrieben, weder für die beiden mit einer TRL-Angabe noch für die beiden ohne. Diese Angaben lassen sich nicht aus einer Webseite ableiten, sondern nur aus einem direkten Gespräch mit der jeweiligen Institution.

RIG: ein Forschungsnetzwerk mit Verbundauftrag

Das Robotics Institute Germany ist ein nationales Verbundprojekt unter Koordination der Technischen Universität München. Das DFKI dokumentiert die aktuelle Projektlaufzeit vom 1. Juli 2024 bis zum 30. Juni 2028. RIG ist damit weder ein einzelnes Labor noch eine dauerhaft eigenständige Robotikfabrik, sondern zunächst eine organisierte Zusammenarbeit bestehender Einrichtungen. Sein eigener Beitrag liegt neben der Forschung selbst in Koordination, Management und der Vernetzung der Beteiligten.

Für die Frage nach dem Übergang in den Betrieb ist dieser Unterschied wichtig. Ein Netzwerk kann Fähigkeiten zugänglich machen, die kein einzelner Standort allein besäße, und Menschen aus unterschiedlichen technischen Bereichen zusammenbringen. Daraus folgt jedoch nicht automatisch, dass jedes angeschlossene Projekt am Ende einen vollständigen Weg bis zum Produkt erhält, denn Forschungsaustausch, Projektbetreuung und industrielle Produktverantwortung sind unterschiedliche Leistungen.

Wer mit RIG ins Gespräch geht, verhandelt zunächst über Forschungszugang und Kooperationsform, nicht über eine spätere Lieferantenbeziehung — eine Unterscheidung, die in der Praxis regelmäßig übersehen wird. Was aus der Projektlaufzeit für die Zeit nach 2028 folgt, behandelt dieser Beitrag weiter unten gesondert.

30 Innovation Labs und ein neuer Beirat

RIG nennt auf seiner Transferseite inzwischen 30 anwendungsorientierte Innovation Labs — eine Zahl institutionell beschriebenen Angebots, keine Zahl erfolgreicher Produkttransfers. Die angebotenen Kooperationen reichen laut Netzwerk von Machbarkeitsstudien über Forschungsaufträge bis zu längerfristigen Partnerschaften.

Für ein Unternehmen ist gerade diese Differenz relevant: Ein passendes Labor kann helfen, eine kritische technische Annahme zu prüfen, ersetzt dadurch aber nicht zwangsläufig den späteren Hersteller oder Integrator. Wer eine Zusammenarbeit anbahnt, fragt deshalb weniger danach, welche Roboter vor Ort stehen, als danach, welches Ergebnis das Labor tatsächlich liefern kann und welche Entscheidung dieses Ergebnis anschließend ermöglicht.

Am 14. Juli 2026 richtete RIG ein Industrial Advisory Board ein — ein belegter institutioneller Mechanismus, noch kein Wirksamkeitsnachweis. Als Aufgabe nennt das Netzwerk die frühzeitige Verbindung industrieller Anforderungen mit der Forschung und die Identifikation von Transferhürden. Ein Beirat und ein laufendes Anwendungsprojekt erfüllen dabei unterschiedliche Funktionen: Der Beirat kann wiederkehrende Themen sichtbar machen, etwa fehlende Schnittstellen oder unklare wirtschaftliche Voraussetzungen, während die konkrete Anforderung Ihrer Fabrik trotzdem in einem eigenen Projekt geklärt werden muss. Andernfalls bleibt die industrielle Perspektive auf einer strategischen Ebene, während ein Prototyp weiter unter Bedingungen entwickelt wird, die mit dem späteren Einsatz wenig zu tun haben. Auch die Industrie selbst spricht dabei nicht mit einer Stimme, denn ein großer Hersteller mit eigenen Automatisierungsteams stellt andere Anforderungen als ein kleinerer Betrieb ohne interne Robotikkompetenz.

Wie RIG Reifegrad und Verlässlichkeit selbst einordnet

Der RIG-Bereich für KI-gestützte Industrierobotik beschreibt eine Transfer-Roadmap im Bereich TRL 3 bis 7 — welche Projekte tatsächlich welchen Reifegrad erreichen, bleibt offen. Diese Selbstdarstellung belegt, dass Forschung und Anwendungsreifung im Netzwerk bewusst miteinander verknüpft werden sollen. Sie ist jedoch kein Nachweis dafür, dass ein bestimmtes Vorhaben diese Spanne tatsächlich durchläuft, denn die Roadmap beschreibt einen Rahmen, kein Versprechen für den Einzelfall.

Eine weitere Funktion betrifft die Qualität der Nachweise selbst. RIG beschreibt Arbeiten an einem Dependability Benchmark — zum Recherchezeitpunkt ein Entwicklungsvorhaben, kein anerkannter Prüfstandard —, der über reine Aufgabenleistung hinaus auch Sicherheit, Robustheit, Zuverlässigkeit und Resilienz berücksichtigen soll: Ein Roboter kann eine Aufgabe häufig richtig ausführen und trotzdem schwer einsetzbar sein, sobald seine Fehler unvorhersehbar sind oder die Wiederherstellung lange dauert. Solange dieser Benchmark in Entwicklung ist, ersetzt er keine Zertifizierung.

RoX: ein Datenökosystem statt eines weiteren Roboters

RoX verfolgt einen anderen Schwerpunkt als RIG. Das Projekt beschreibt ein dezentrales Daten- und Diensteökosystem für Entwicklung, Einführung und kontinuierliche Verbesserung KI-gestützter Robotik und verweist auf die Zusammenarbeit mit Manufacturing-X und europäischen Cloud-Edge-Initiativen. Die DFKI-Projektbeschreibung nennt eine Laufzeit vom 1. September 2024 bis zum 28. Februar 2027. Für die Übergabefrage liegt der mögliche Nutzen genau in den Informationen zwischen den Organisationen: Ein Betreiber entdeckt einen Fehler, der Hersteller benötigt Daten zur Diagnose, ein Komponentenlieferant könnte daraus eine Verbesserung ableiten.

In seinem Konzept zur Messe Automatica 2025 beschreibt RoX beispielsweise die Verbindung von Komponentenbeschreibungen, Datenfreigabe und KI-Diensten, bei der ein Vision-Modell anhand realer Anwendungsdaten verbessert werden soll, während Nachvollziehbarkeit und Kontrolle über die Daten erhalten bleiben. Das ist ein konkreter beschriebener Demonstratoransatz — nicht gleichzusetzen mit einem bereits breit ausgerollten, unabhängig validierten industriellen Datenmarkt.

Ohne geregelte Schnittstellen und Nutzungsbedingungen bleibt der Kreislauf von Fehlerbild über Diagnose bis Verbesserung leicht unterbrochen, denn das Problem betrifft nicht nur die Übertragbarkeit der Daten, sondern auch ihre Bedeutung und ihre zulässige Verwendung. Wie sich ein Datenmarkt für Robotikdaten insgesamt entwickelt, ordnet ein eigener Beitrag zum Datenmarkt für Robotikdaten vertieft ein; für die Übergabefrage in diesem Beitrag zählt vor allem, dass ein Demonstrator und ein etablierter Markt zwei unterschiedliche Reifegrade sind.

Warum Datenaustausch keine Systeminteroperabilität ist

An RoX lässt sich eine Grenze erklären, die für Ihr Vorhaben wichtiger sein dürfte als der Name des Projekts selbst. Zwei Organisationen können Daten erfolgreich austauschen, ohne dass ihre robotischen Systeme deshalb unmittelbar zusammenarbeiten. Eine maschinenlesbare Komponentenbeschreibung sagt noch nicht, dass ein bestimmter Greifer für Ihre konkrete Sicherheitsarchitektur geeignet ist, und der Zugang zu Fehlerbildern macht ein Modell nicht automatisch robuster.

Interoperabilität hat deshalb mehrere Ebenen, die sich einzeln prüfen lassen. Technisch müssen Formate und Schnittstellen funktionieren, fachlich müssen beide Seiten dieselbe Bedeutung verstehen, organisatorisch müssen Verantwortliche reagieren können, und rechtlich muss die Nutzung erlaubt sein. Erst wenn diese vier Ebenen zusammenkommen, wird aus einem Datenfluss ein verlässlicher Verbesserungsprozess. Fehlt eine davon, kann ein formal erfolgreicher Austausch praktisch folgenlos bleiben — ein Risiko, das sich leicht übersieht, weil die Datenverbindung selbst technisch einwandfrei funktioniert.

Ein Beispiel macht das greifbar: Ein Sensor-Datensatz kann technisch tadellos übertragen werden und trotzdem nutzlos bleiben, wenn niemand dokumentiert hat, unter welcher Beleuchtung, an welcher Maschine und mit welcher Softwareversion er entstanden ist. Genau diese Kontextinformation, nicht der reine Datentransfer, entscheidet darüber, ob eine Übergabe zwischen zwei Stationen Ihrer eigenen Pipeline tatsächlich etwas wert ist.

AI-MATTERS und die europäischen TEF als Testinfrastruktur

Die europäischen Testing and Experimentation Facilities richten sich an die Erprobung reiferer KI-Technologien einschließlich robotischer Hardware. TEFs adressieren laut Kommission den Bereich TRL 6 bis 8 und ersetzen nach eigener Programmbeschreibung keine Zertifizierungsstellen.

Für die Fertigung ist AI-MATTERS der einschlägige Verbund; der deutsche AI-MATTERS-Knoten umfasst vier genannte Einrichtungen — Fraunhofer IPA, die Universität Stuttgart, ARENA2036 und die Physikalisch-Technische Bundesanstalt. Für förderfähige kleine und mittlere Unternehmen werden bedingte Rabatte bis 50 Prozent genannt, keine allgemeine Kostenfreiheit.

Diese Infrastruktur bearbeitet einen anderen Übergang als ein Grundlagenlabor, denn sie soll untersuchen, ob eine Technik in einer repräsentativeren Umgebung trägt. Dabei ist die Ähnlichkeit zur späteren Anwendung selbst eine Prüfaufgabe: Ein sauberer Hallenboden, definierte Objekte oder eine stabile Netzwerkinfrastruktur können relevante Unterschiede zum späteren Betrieb darstellen, und „realitätsnah“ sollte deshalb beschrieben und nicht nur behauptet werden. Bevor Sie eine Erprobung anfragen, lohnt sich deshalb die eigene Klärung, welche Entscheidung diese Erprobung tragen soll — die Auswahl einer Architektur, die Prüfung einer Integrationsannahme oder eine dokumentierte Leistung für einen bestimmten Prozess. Diese Unterscheidung beeinflusst Testaufbau, Daten und Ergebnisformat unmittelbar. Ein Testzentrum ist am nützlichsten, wenn die offene Frage präzise gestellt ist; eine unklare Geschäfts- oder Produktidee lässt sich durch Messungen allein nicht vervollständigen.

Das Fraunhofer-Reallabor: wo Technik auf Recht trifft

Fraunhofer IPA stellte am 30. April 2026 ein Reallabor vor — ein Unterstützungsangebot, keine pauschale Rechtsfreigabe jedes untersuchten Systems. Der Ansatz verbindet technologische Erprobung mit der Einordnung rechtlicher Anforderungen; genannt werden unter anderem humanoide Robotik und KI-basierte Anwendungen sowie technische und regulatorische Kurzanalysen. Technische Entscheidungen haben dadurch rechtliche Folgen: Wird eine Funktion verändert, kann sich auch ändern, welche Risiken betrachtet werden müssen und wer welche Verantwortung trägt.

Die regulatorische Landschaft lässt sich dabei nicht auf das Etikett „KI-Roboter“ reduzieren. Die Änderungsverordnung 2026/1744 verlagert den Maschinenbezug im AI Act von Anhang I Abschnitt A nach Abschnitt B und sieht eine sektorale statt pauschale Einbindung vor — ein Roboter wird nicht allein durch Form oder KI-Einsatz automatisch zum identisch regulierten Hochrisikosystem. Maßgeblich ist nach dem Verordnungstext, ob das System als Hochrisiko-KI-System nach Artikel 6 Absatz 1 der KI-Verordnung gilt und dabei als Sicherheitsbauteil einer Maschine wirkt oder selbst eine Maschine bildet — nur dann greift die sektorale Einbindung über die Maschinenverordnung anstelle einer pauschalen Doppelprüfung. Für ein konkretes Produkt müssen Funktion, Einstufung und anwendbare Anforderungen weiterhin geprüft werden, wie es auch ein eigener Beitrag zur Maschinenverordnung und ihren Fristen vertieft — eine Einordnung, die dieser Beitrag im Schlussteil noch einmal ausdrücklich als redaktionell und nicht als Rechtsberatung kennzeichnet.

Für ein mittelständisches Unternehmen ohne eigene Rechtsabteilung kann ein solches Reallabor deshalb eine sinnvolle erste Anlaufstelle sein, um technische und rechtliche Fragen nicht getrennt, sondern im selben Gespräch zu klären. Das ersetzt jedoch nicht die spätere Prüfung durch die eigene oder eine externe Rechtsberatung, sobald ein konkretes Produkt tatsächlich in den Verkehr gebracht werden soll.

Was nach dem Ende der Förderlaufzeit offen bleibt

Die dokumentierten Projektlaufzeiten machen eine weitere Frage sichtbar: Was bleibt institutionell bestehen, wenn die aktuelle Förderung endet? Für RIG ist der 30. Juni 2028, für RoX der 28. Februar 2027 als Projektende angegeben. Aus den Projektlaufzeiten folgt weder eine sichere Beendigung noch eine bereits gesicherte Fortführung nach Förderende. Einen vollständigen, öffentlich dokumentierten gemeinsamen Weiterbetriebsmodus konnten wir aus den hier ausgewerteten Quellen nicht ableiten.

Bei den TEFs verlangt die Kommission in der Programmkonzeption bereits einen tragfähigen Plan für den Betrieb nach der EU-Förderung. Das ist eine relevante Anforderung an die Infrastruktur selbst, belegt aber nicht automatisch, dass jede Einrichtung später wirtschaftlich unabhängig arbeitet, denn Geschäftsplan, tatsächliche Nachfrage und langfristige Finanzierung bleiben unterschiedliche Größen. Ein Teststand kann physisch erhalten bleiben, während zuständiges Personal fehlt. Wer einen mehrjährigen Entwicklungspfad plant, sollte die Verfügbarkeit von Testverfahren, Ansprechpartnern und Daten deshalb vor Projektbeginn direkt bei der jeweiligen Institution erfragen.

Der angekündigte Dialog zwischen RIG und RoX

RIG und RoX haben für den 28. und 29. Oktober 2026 einen gemeinsamen Dialog von Robotikforschung und Industrie in Frankfurt angekündigt — das belegt Zusammenarbeit, nicht bereits eine vertraglich geschlossene Entwicklungskette. Diese Zurückhaltung ist keine Abwertung der Ankündigung, denn Kooperation beginnt häufig damit, dass unterschiedliche Akteure ein gemeinsames Problem beschreiben. Für eine Einordnung wie diese sollten Absicht, Angebot und Ergebnis jedoch getrennt bleiben. Ein angekündigtes Treffen kann relevant sein; ob daraus weniger Integrationsaufwand oder mehr erfolgreiche Anwendungen für Betriebe wie den Ihren entstehen, verlangt andere, spätere Nachweise.

Umgekehrt darf fehlende öffentliche Dokumentation nicht als Beweis fehlender Zusammenarbeit gelten. Einzelne Projekte können gut organisiert sein, ohne dass ihre Verträge, Datenwege oder wirtschaftlichen Ergebnisse veröffentlicht werden. Der zutreffende Befund lautet dann, dass sich ein bestimmter Zusammenhang anhand öffentlicher Unterlagen nicht vollständig nachweisen lässt — nicht, dass er unmöglich oder nicht vorhanden wäre. Für die weitere Beobachtung lohnt sich deshalb weniger die Ankündigung selbst als das, was danach folgt: ob aus dem Termin ein dokumentiertes gemeinsames Projekt wird, das sich auf eine der vier hier beschriebenen Funktionen bezieht, oder ob es bei einer einmaligen Veranstaltung bleibt.

Warum die Übergabe zählt, nicht die Zahl der Stationen

Aus den dokumentierten Angeboten ergibt sich ein differenziertes Bild. RIG bearbeitet Vernetzung, Anwendungslabore und Nachweismethoden. RoX konzentriert sich auf Daten und Dienste über Organisationsgrenzen hinweg. AI-MATTERS stellt produktionsnahe Erprobung bereit. Das Fraunhofer-Reallabor verbindet technische Arbeit mit regulatorischer Einordnung — vier Funktionen, die sich konzeptionell ergänzen, aber nicht automatisch Teile eines einzigen ausführenden Systems sind.

Für ein konkretes Vorhaben liegen die kritischen Fragen deshalb zwischen den Stationen, nicht in ihnen selbst. Wer bezahlt die Überarbeitung nach einem fehlgeschlagenen Test? Welcher Partner besitzt die neu entstandene Software? Wer pflegt den Nachweis, wenn später ein anderer Sensor eingebaut wird? Darf ein Integrator die Daten an einen Modellanbieter weitergeben? Eine gezeichnete Prozesskette bleibt unvollständig, solange diese Fragen nicht für Ihr konkretes Vorhaben beantwortet sind — unabhängig davon, wie viele Stationen auf dem Papier beteiligt wären.

Ein durchgängiger Projektverantwortlicher könnte helfen, diese Fragen zusammenzuhalten, muss aber nicht zwangsläufig jede Aufgabe selbst leisten. Seine Aufgabe wäre eine gemeinsame Anforderungsbasis, ein offenes Risikoregister und eine nachvollziehbare Historie der Änderungen — Instrumente, die organisatorisch weniger sichtbar sind als eine neue Testhalle, aber darüber entscheiden, ob vorhandene Angebote für ein konkretes Projekt überhaupt zusammen nutzbar werden. Genau das ist die praktische Bedeutung hinter der Unterscheidung zwischen einem vollständigen Translation Stack und einer tatsächlich organisierten Translation Pipeline.

Was das für die eigene Vorhabensplanung heißt

Deutschlands Robotik-Transferlandschaft lässt sich damit weder auf ein fehlendes Angebot reduzieren noch durch die vorhandene Infrastruktur für vollständig erklären. Der entscheidende Untersuchungsgegenstand liegt dazwischen, an den Übergaben selbst. Eine Forschungsidee muss nicht an einem Ort bis zum fertigen Produkt entwickelt werden; ihr Wissen, ihre Nachweise und ihre Verantwortlichkeiten müssen jedoch die Orts- und Organisationswechsel überleben. Für Ihr eigenes Vorhaben bedeutet das, das Prüfraster aus diesem Beitrag nicht als Auswahlliste zu lesen, sondern als Fragenkatalog an jede Station, mit der Sie tatsächlich sprechen.

Zu diesem Fragenkatalog gehört ausdrücklich auch die rechtliche Einordnung, etwa entlang der Verschiebung, die die Verordnung 2026/1744 im AI Act vorgenommen hat, oder entlang der Fördervoraussetzungen einzelner Programme. Diese Einordnung in diesem Beitrag ersetzt keine Rechts- oder Förderberatung im Einzelfall — für die konkrete Einstufung des eigenen Vorhabens ist die zuständige Stelle oder eine Rechtsberatung zu konsultieren. Was am Ende zählt, ist deshalb weniger die Zahl der Logos auf einer Landkarte als die Zahl der Übergaben, die Sie für Ihr eigenes Projekt tatsächlich geklärt haben, bevor die erste Zelle bestellt wird. Genau dort entscheidet sich, ob aus einem verteilten Angebot eine belastbare Verbindung für Ihr Vorhaben wird.