Das deutsch-schweizerische Startup Sphere argumentiert, dass Industrieunternehmen in die falsche KI-Schicht investieren. Wer Workflow-Tools kauft, beschleunigt Papierkram. Wer seine Ingenieurdaten zu trainierbarer Intelligenz aufbereitet, baut laut Sphere einen Vorsprung, den kein Wettbewerber per API-Vertrag einholen kann.

Ein Bearbeitungszentrum verliert jedes Jahr an Wert. Das weiss jeder Produktionsleiter, der eine Abschreibungstabelle lesen kann. Aber was, wenn die Daten, die diese Maschine in zwanzig Jahren erzeugt hat, genau das Gegenteil tun? Wenn Simulationsergebnisse, Prüfberichte und Stücklisten ein Vermögenswert sind, der mit jedem Produktzyklus wächst?

Das deutsch-schweizerische Startup Sphere, gegründet von zwei Uni Zürich und ETH-Zürich-Absolventen und mit Wurzeln in der Batterieforschung, hat ein Whitepaper vorgelegt, das diese Frage architektonisch durchdekliniert. Der Titel: «The Two Layers of Enterprise AI». Die These: Die Industrie investiert ihre KI-Budgets in die falsche Schicht. Die Argumentation richtet sich an CTOs und Entwicklungsleiter in der Fertigungs- und Produktindustrie.

Sechs Schichten, zwei davon gemietet

Sphere unterteilt den KI-Stack eines Unternehmens in sechs Schichten. Die unteren zwei werden gemietet: Rechenleistung (Nvidia, Hyperscaler) und Foundation Models (GPT, Claude, Llama, Mistral, Gemini), konsumiert via API. Beide Schichten seien notwendig, aber kein Differenzierungsmerkmal.

Die oberen vier Schichten baut das Unternehmen selbst: Daten (proprietäre Datenbestände, KI-tauglich aufbereitet), Intelligenz (domänenspezifische Modelle), Workflow (Orchestrierung, Agenten, Tool-Integrationen) und Applikation (Copiloten, Benutzeroberflächen). Das Neue an dieser Architektur sei, so Sphere, dass trainierte Modelle auf Basis proprietärer Daten als eigene Ebene erscheinen: eine Ebene, die sich über die Zeit aufwertet.

Wo das Geld hinfliesst, und warum es dort versickert

Die meisten KI-Budgets, so das Papier, fliessen in die Workflow-Schicht. In Copiloten, die ein Pflichtenheft aus einem Lastenheft entwerfen. In Agenten, die Anfragen über Systeme hinweg routen. In Retrieval-Pipelines, die das richtige Dokument aus einer Million Seiten Lieferantenspezifikationen fischen. Das seien nützliche Fähigkeiten, schreibt Sphere, und jedes Unternehmen, das darauf verzichte, verschenke Produktivität. Aber es sei auch die Schicht, in der Differenzierung am schnellsten verschwinde: Jedes Framework hier habe in sechs Monaten drei ebenbürtige Alternativen.

Ingenieurarbeit ist kein Textproblem

Der schärfste Satz im Papier: «Engineering is not a language-shaped problem.» Sprachmodelle funktionieren, wo die Aufgabe sprachförmig ist: Pflichtenheft aus Lastenheft generieren, Testpläne templaten, Review-Zyklen durch Zusammenfassungen verkürzen.

Aber wenn ein Batterieingenieur die Kathodenbeschichtung für eine neue Zelle dimensioniert, geht es um Elektrochemie, Fertigungsprozess und Degradationsphysik über tausend Zyklen. Wenn ein Konstrukteur ein Halterungsteil für einen Fahrzeugrahmen spezifiziert, geht es um Lastpfade, Schweisszugänglichkeit und die Kostendifferenz zwischen Stanzteil und Schmiede-Aluminium. Kein Text. Kein Sprachmodell der Welt produziere das zuverlässig, schreibt Sphere, egal wie geschickt die Workflow-Schicht den Prompt formuliere.

Ein Copilot, der ein Pflichtenheft schreibe, löse die sprachförmigen zehn Prozent des Ingenieurproblems. Die restlichen neunzig Prozent bräuchten ein Modell, das die firmeneigenen Ingenieurdaten kennt. Die Workflow-Schicht könne die Frage weiterleiten. Beantworten könne sie sie nicht.

Die Schicht, die sich aufwertet

Diese fehlende Schicht nennt Sphere «Intelligence Layer»: domänenspezifische Modelle, trainiert auf firmeneigenen Simulationsergebnissen, Testdaten und Konstruktionsdaten. Surrogatmodelle etwa, die Crashverhalten oder Zellalterung in Sekunden vorhersagen, wofür eine vollständige Simulation Tage bräuchte. Oder Retrieval-Systeme auf firmeneigener Ontologie und den Unterschied kennen zwischen kalendarischer und zyklischer Degradation.

Drei Eigenschaften unterscheiden diese Schicht laut Whitepaper von allen anderen. Sie kumuliert: Ein Foundation Model werde einmal trainiert, ausgeliefert und verliere an Wert, sobald ein besseres erscheine. Ein Intelligence-Layer-Modell werde mit jedem Produktzyklus schärfer, weil jedes Programm neue Daten liefere. Der Vermögenswert werte sich auf, er schreibe sich nicht ab.

Sie kodiere zudem Ingenieurwissen implizit. Die tausend kleinen Entscheidungen, die erfahrene Ingenieure jede Woche treffen, steckten in den Daten, die sie erzeugen. Ein darauf trainiertes Modell lerne, was die Ingenieure tatsächlich tun. Das sei etwas anderes als ein Chatbot, der Fragen über Ingenieurwissen beantworte.

Und sie sei nicht commoditisierbar. Foundation Models konvergierten, weil sie auf denselben öffentlichen Daten trainiert würden. Workflow-Frameworks seien standardmässig Open Source. Der Intelligence Layer könne nicht konvergieren, weil die Daten, auf denen er aufbaue, nirgendwo sonst existierten.

Das V wird flacher

Am konkretesten wird das Papier beim V-Modell, das seit vierzig Jahren definiert, wie Ingenieurorganisationen Produkte entwickeln. Links die Dekomposition: Lastenheft, Pflichtenheft, Systemarchitektur, Komponenten. Rechts die Verifikation: Komponententest, Integrationstest, Systemtest, Validierung. Jede Stufe links hat ein Spiegelbild rechts. Der Zweck: Fehler früh finden, weil späte Fehler um Grössenordnungen teurer sind.

Workflow-KI beschleunige die Dokumente, die über dieses V wandern: ein Pflichtenheft in Stunden statt Wochen, ein Testplan automatisch vorausgefüllt, ein Review-Zyklus verkürzt. Das ändere das Tempo, aber die Form des V bleibe.

Intelligence-Layer-KI ändere die Form. Der linke Arm kollabiere teilweise, weil ein Modell, das frühere Lastenhefte, die zugehörigen Komponenten, Materialien, Lieferanten und Kostenergebnisse kennt, die Dekomposition abkürze. Spezifikation informiere Design direkt. Der rechte Arm rücke vor, weil physikbasierte Surrogatmodelle Testergebnisse in der Designphase vorhersagten, statt sechs Monate später in der Verifikation. Und jeder Produktzyklus, der durch das transformierte V laufe, speise seine Daten zurück ins Modell. Das nächste Programm starte klüger als das letzte.

Die ungeliebte Vorarbeit

Das Whitepaper verschweigt nicht, dass der Aufbau eines Intelligence Layers aufwändig ist. Der Grossteil der Arbeit sei unspektakulär: Datenprotokolle aus Testsystemen erfassen, Simulationsergebnisse und BOM-Daten aus SAP integrieren, Lieferantenspezifikationen aus PDFs extrahieren, alles unter einer semantischen Schicht normalisieren. «Garbage in, garbage out» sei kein neues Konzept, schreibt Sphere, aber eines, das in der Cloud-Ära leise aus der Mode gekommen sei. Die Schwierigkeit sei keine Steuer auf den Intelligence Layer. Sie sei der Burggraben.

Sphere positioniert sein Produkt Vetta als «AI Operating System», das die drei mittleren Schichten (Daten, Intelligenz, Workflow) zu einer einheitlichen Architektur verbindet. Das Whitepaper ist, das muss man dazusagen, ein Verkaufsdokument: Jedes Kapitel läuft auf Vetta zu. Konkrete Kundenbeispiele, Benchmarks oder Vorher-Nachher-Vergleiche zur V-Modell-Transformation enthält es nicht.

Was es aber darüber hinaus noch überzeugend liefert, ist ein Denkrahmen: die Unterscheidung zwischen sprachförmigen Problemen und solchen, die es nicht sind.