Im Juni 2026 ist INXM mit einer Pre-Seed-Finanzierung von 5,7 Millionen Euro aus dem Stealth-Modus gestartet – angeführt von Cherry Ventures und Redstone, mit Beteiligung von Angel Invest und Linden Capital. Das Berliner Startup baut mit „Orchestrator“ eine KI-Prozessausführungs-Engine für Enterprise- und Mittelstandsbetriebe, basierend auf einem neuen architektonischen Prinzip: Compiled AI. Dabei entwirft KI zunächst den optimalen Prozess, die eigentliche Ausführung übernimmt anschließend deterministische Software – auditierbar, wiederholbar, ohne Token-Kosten zur Laufzeit.

Gegründet wurde INXM von einem Team mit Wurzeln in Luft- und Raumfahrt sowie Enterprise-Software: CEO Alex Oelling war zuvor Chief Digital Officer bei Isar Aerospace und Volocopter und gründete davor Sensorberg. Im Interview erklärt er, warum klassische LLM-Ansätze bei komplexen Geschäftsprozessen an ihre Grenzen stoßen, wie Compiled AI in der Praxis funktioniert – und warum die Erfahrung aus regulierten, sicherheitskritischen Branchen für industrielle KI so entscheidend ist.

Alex, INXM ist mit einer Pre-Seed-Finanzierung von 5,7 Millionen Euro aus dem Stealth-Modus gestartet. Viele KI-Tools generieren bei jeder Ausführung neu – mit den bekannten Risiken: hohe Kosten, Halluzinationen, unvorhersehbare Ergebnisse. Wie löst INXM dieses Problem – und warum ist das gerade für industrielle Prozesse so entscheidend?

Das Kernproblem ist mathematisch. Ein LLM mit 95 % Genauigkeit kommt nach 14 Schritten auf unter 50 % korrekte Ausführung – nach 175 Schritten liegt die Erfolgswahrscheinlichkeit bei 0,01 %. Für einen Geschäftsprozess mit vielen Teilschritten, der hunderte Male läuft, ist das inakzeptabel. Hinzu kommt der Kostenfaktor: Eine Standard-SAP-Transaktion braucht mit einem konventionellen LLM-Ansatz 100.000 Tokens und mehr. Unsere kompilierte Ausführung schafft dieselbe Transaktion mit 1.000 bis 1.250 Tokens – zur Laufzeit mit null Tokens. Das ist Faktor 80 auf einem Prozess, der tausende Male am Tag läuft.

Halluzinationen sind dabei besonders gefährlich. Ein KI-System, das gelegentlich falsch liegt, reduziert kein operationelles Risiko, sondern fügt ein neues hinzu. INXM löst das nicht durch bessere Modelle, sondern durch einen Architekturwechsel: Compiled AI. Die KI baut den Prozess. Ein Mensch oder AI Agent überprüft ihn, die Ausführung übernimmt deterministische Software.

Mit „Compiled AI“ entwickelt KI zunächst einen Prozess, der anschließend deterministisch – also nach einem festgelegten Ablauf – ausgeführt wird. Wie funktioniert das in der Praxis, und wo liegen die Grenzen dieses Ansatzes?

Das Prinzip ist einfach: Lass das probabilistische System den optimalen Weg bauen. Aber lass es nicht selbst zur „Execution Engine“ werden. Am Anfang steht ein Prompt in natürlicher Sprache. Daraus erstellt der Planner einen typisierten, ausführbaren Plan. Anschließend prüft das System Schema, Sicherheit und Governance gegen Live-Schnittstellen. Im Healing Loop folgt ein Probelauf ohne Nebenwirkung. Erkennt das System eine Abweichung – etwa ein Feld in SAP, eine API-Version oder einen Statuswert –, kompiliert es den betroffenen Teilschritt neu und schlägt den korrigierten Plan zur Freigabe vor. Die KI improvisiert also nicht zur Laufzeit, sondern repariert den Plan, ohne die Determinismus-Garantie aufzugeben.

Das Ergebnis läuft ohne weitere Token-Kosten, ohne Varianz und vollständig auditierbar: Run 1 ist identisch mit Run 1000. Ökonomisch heißt das 80- bis 100-fach weniger Tokens; der Break-even liegt bei 17 Transaktionen. Die Kompilierungsphase unterliegt weiterhin den Kontextfenster-Limitierungen von LLMs, weshalb sehr komplexe Probleme zerlegt werden müssen. Selbst wenn Modelle künftig zuverlässiger werden, bleibt die Kostenstruktur für uns entscheidend. Aktuell finden Denken und Ausführen innerhalb des LLM statt. Wir trennen Denken und Ausführung. Die Vermutung liegt nahe, dass dies in Zukunft der Standard wird.

Euer Orchestrator soll bestehende Systeme wie ERP, PLM, MES und QMS verbinden. Welche technischen und organisatorischen Voraussetzungen müssen Unternehmen mitbringen, damit diese Integration tatsächlich gelingt?

Technisch ist die Hürde überschaubar. Der INXM Orchestrator basiert auf dem offenen MCP-Standard, verbindet bereits viele Enterprise-Systeme out of the box und ersetzt keine bestehenden Systeme – er verbindet sie. Alle Credentials verbleiben beim Kunden. SAP bleibt führend für Stammdaten, das PLM für Konstruktionsstände. Der Orchestrator wird nie zum System of Record.

Die eigentliche Hürde ist organisatorisch. Unternehmen brauchen erstens eine Datenstrategie – strukturierte und unstrukturierte Daten müssen konsolidiert, bereinigt und mit klaren Zugriffsrechten versehen sein. Zweitens Process Experts, nicht primär Software-Entwickler. Drittens den Willen, interne Champions aufzubauen. INXM konkurriert nicht mit SAP. Der Orchestrator macht SAP-Investitionen in einer KI-Welt erst wirklich nutzbar.

Gleichbleibende und überprüfbare Ergebnisse sind in Industrie und regulierten Bereichen besonders wichtig. Wie macht ihr Entscheidungen und Prozessschritte nachvollziehbar – und wann bleibt menschliches Eingreifen unverzichtbar?

Nachvollziehbarkeit ist bei uns kein Feature-Add-on, sondern Architekturprinzip. Jede Transaktion ist deterministisch: gleicher Input ergibt gleichen Output, jedes Mal. Alles wird geloggt – was lief, wo es gestoppt hat, warum. Das ermöglicht vollständige Audit-Trails und Rollback-Fähigkeit. Bei Fehlern stoppt der Orchestrator am Punkt des Scheiterns, generiert einen Lösungsvorschlag und gibt die Kontrolle an den zuständigen Menschen zurück.

Human-in-the-Loop ist kein Workaround, sondern ein Design-Prinzip. Menschliches Eingreifen bleibt unverzichtbar, wo Entscheidungen außerhalb des definierten Regelsatzes liegen, regulatorische Compliance einen expliziten Sign-off erfordert oder das System sich nicht selbst heilen kann. Diese Situationen erkennt das System aktiv und verteilt Aufgaben an die zuständigen Fachabteilungen.

Welche Abläufe eignen sich aus eurer Sicht besonders für eine Automatisierung mit KI – und bei welchen Prozessen wäre derzeit noch Vorsicht geboten?

Die einfache Formel: hohe Volumen, geringe Interpretationsspielräume, hohe Konsequenzen bei Fehlern. Das ist der Sweet Spot. Besonders eignen sich systemübergreifende Prozesse, die heute manuell koordiniert werden: Engineering Release & Change Management in PLM-Systemen, Rechnungsverarbeitung und Three-Way-Matching in der Finance, Procurement-Workflows über Supplier bis SAP oder BOM-Analyse in der Fertigung. Das sind kritische Prozesse, die niemand wirklich machen will und bei denen Verlässlichkeit nicht verhandelbar ist. Unsere bestehenden Test Use Cases zeigen gleichzeitig, dass auch strategische Wettbewerbsanalysen und vieles mehr gut abbildbar sind.

Vorsicht ist geboten, wo klare Erfolgsregeln fehlen: Entscheidungen ohne belastbare Datenbasis, kreative Arbeit mit offenem Ergebnisraum, Prozesse ohne vorhandene Systemintegration oder Situationen, in denen Ergebnisverantwortung nicht klar zugeordnet ist.

Das Gründerteam bringt Erfahrungen aus Luft- und Raumfahrt, Deep Tech und Unternehmenssoftware mit. Welche Erkenntnisse daraus lassen sich auf industrielle KI übertragen – und welche nicht?

Vier Gründer, vier Branchen – und wir alle sind über dasselbe Problem gestolpert, nur aus unterschiedlichen Richtungen. Bei einer Rakete gibt es keinen Spielraum: Einen Fehlstart kann man nicht nachträglich korrigieren. Bei einem Lufttaxi muss jeder Schritt zertifizierbar sein. In der Fertigung zählt Verlässlichkeit in der Serie. Ich selbst war Chief Digital Officer bei Isar Aerospace und Volocopter und habe davor Sensorberg gegründet. Unser CTO Matthias Kainer bringt über 25 Jahre Softwareerfahrung mit, CPO Jesper Bylund kommt aus Designrollen bei Volocopter und n8n, CSO Kamil Klüber aus über 20 Jahren Engineering- und Fertigungserfahrung, davon knapp sieben Jahre bei Siemens.

Übertragen lässt sich vor allem eines: Wir halten Unschärfe an den kritischen Stellen nicht aus. Ein System, das manchmal funktioniert und manchmal nicht, ist ein Risiko – beim Raketenstart genauso wie bei einer SAP-Buchung über zehn Millionen Euro. Übertragen lässt sich außerdem, in Anforderungen statt in Lösungen zu denken: Wer schreibt die Anforderungen? Wer trägt die Verantwortung? Wer gibt frei? Nicht übertragen lässt sich das Zeitgefühl regulierter Branchen: Zertifizierungen dauern Jahre. Enterprise-Software muss schneller lernen.

INXM wurde in der Hauptstadtregion Berlin-Brandenburg gegründet und richtet sich an europäische Industrieunternehmen. Welche Stärken bietet die Region für diesen Ansatz? Was braucht es, damit daraus international erfolgreiche Enterprise-KI entstehen kann?

Berlin-Brandenburg ist für uns kein zufälliger Standort: Hier liegen unsere Wurzeln und unser Netzwerk. Hier sind Verbindungen entstanden, aus denen heute Partnerschaften, Kundenkontakte und Teamzugänge werden. Wir bauen etwas, das es so noch nicht gibt – dafür braucht es ein Umfeld, das Industrie, Forschung und Kapital zusammenbringt. Die Region gibt uns Zugang zu Investoren, Entscheidern und Veranstaltungen, auf denen echte Gespräche entstehen. Unsere ersten Partnerschaften sind durch persönliche Begegnungen entstanden.

Dazu kommen Deep-Tech-Forschung wie der DLR-Standort für Luft- und Raumfahrt in Adlershof, industrielle Ansiedlungen wie die Tesla Gigafactory in Grünheide, Deutschlands aktivstes Startup-Ökosystem, die Nähe zur Bundespolitik und gute Verbindungen in den süddeutschen Industrieraum. Das prägt auch die Anforderungen: Europäische Industriekunden erwarten Datensouveränität, Compliance by Design und Betriebsratstauglichkeit. INXM will die Infrastrukturschicht werden, auf der europäische Industrie läuft. Unsichtbar, wenn alles funktioniert. Unverzichtbar, wenn es darauf ankommt.

Vielen Dank für das tolle Gespräch.