Generative KI hat in kurzer Zeit gezeigt, dass große Modelle Sprache, Code, Dokumente und Wissensbestände auf eine Weise verarbeiten können, die für viele Arbeitsbereiche nützlich ist. Auch im Engineering werden solche Systeme bereits eingesetzt, etwa zur Analyse von Anforderungen, zur Zusammenfassung technischer Dokumentation, zur Unterstützung bei Reviews oder zur Generierung von Skripten und Testfällen. Diese Anwendungen sind hilfreich, sie ändern aber nicht den grundsätzlichen Charakter technischer Entwicklungsarbeit. Engineering besteht nicht nur aus Textverarbeitung. Es beruht auf physikalischen Zusammenhängen, geometrischen Abhängigkeiten, Materialverhalten, Fertigungsgrenzen, Prüfprozessen, Normen, Änderungsständen und Systementscheidungen. Deshalb reicht es nicht aus, ein allgemeines Sprachmodell mit besseren Prompts zu bedienen.
Ein Sprachmodell wie GPT arbeitet primär mit sprachlichen Mustern. Es kann technische Begriffe korrekt verwenden, typische Zusammenhänge beschreiben und auf Basis vorhandener Informationen plausible Antworten erzeugen. Für industrielle Entwicklungsentscheidungen ist Plausibilität jedoch kein ausreichendes Kriterium. Ein Bauteil ist nicht deshalb belastbar, weil seine Beschreibung überzeugend klingt. Ein Fertigungsprozess ist nicht stabil, weil ein Modell eine passende Parametereinstellung formuliert. Eine Konstruktion ist nicht freigabefähig, weil ein Chatbot sie als sinnvoll einordnet. Technische Entscheidungen müssen sich an messbaren Größen, validierten Modellen und nachvollziehbaren Randbedingungen orientieren.
Genau an dieser Stelle entsteht der Unterschied zwischen allgemeinen Large Language Models und sogenannten Large Engineering Models. Der Begriff Large Engineering Models beschreibt KI-Systeme, die nicht nur Sprache verarbeiten, sondern technische Domänen explizit modellieren. Sie werden mit Engineering-Daten, Simulationsdaten, Prozessdaten, Geometriedaten, Materialinformationen und Prüfresultaten verbunden. Ihr Ziel ist nicht die allgemeine Konversation, sondern die Unterstützung konkreter technischer Aufgaben. Dazu gehören beispielsweise die Bewertung von Designvarianten, die Vorhersage von Simulationsgrößen, die Exploration von Prozessfenstern, die Erkennung technischer Risiken oder die Zuordnung von Anforderungen zu validierten Nachweisen.
Der zentrale Unterschied liegt im Datenraum. Ein allgemeines Sprachmodell kann erklären, was eine Spannungskonzentration ist oder warum eine Toleranzkette relevant sein kann. Ein Large Engineering Model muss dagegen mit konkreten Geometrien, Lastfällen, Materialmodellen, Randbedingungen und Fertigungsprozessen umgehen können. Es muss wissen, auf welchen Annahmen eine Berechnung beruht, welche Simulationsdaten zu welcher Bauteilversion gehören, welche Prüfstände reale Ergebnisse geliefert haben und welche Prozessparameter in der Produktion tatsächlich eingehalten wurden. Ohne diese Verknüpfung bleibt KI im Engineering auf der Ebene sprachlicher Assistenz.
Prompting ist dabei nur die Bedienoberfläche. Ein Prompt kann eine Frage präzisieren, aber er ersetzt keine technische Modellierung. Wenn ein Engineer ein System fragt, wie ein Bauteil leichter ausgelegt werden kann, hängt die Antwort nicht nur von der Formulierung der Frage ab. Sie hängt davon ab, welche Lastfälle gelten, welche Sicherheitsfaktoren vorgeschrieben sind, welche Werkstoffe qualifiziert wurden, welche Fertigungsverfahren zulässig sind, welche Bauraumgrenzen bestehen, welche Lebensdauer erwartet wird und welche Prüfungen für die Freigabe erforderlich sind. Diese Informationen müssen nicht nur erwähnt, sondern im Modell- und Datenkontext repräsentiert sein.
Ein wesentliches Problem allgemeiner KI-Systeme liegt darin, dass sie technische Randbedingungen nicht automatisch kennen. Sie können vorhandenes Wissen sprachlich kombinieren, aber sie haben ohne Anbindung an Unternehmensdaten keinen Zugriff auf den tatsächlichen Entwicklungsstand. Sie wissen nicht, welche CAD-Version gültig ist, welche Simulation mit welchem Solver und welcher Vernetzung erstellt wurde, welche Materialcharge geprüft wurde oder welche Prozessparameter in einer bestimmten Produktionslinie stabil laufen. In industriellen Umgebungen ist diese Kontextabhängigkeit entscheidend, weil kleine Unterschiede in Versionen, Randbedingungen oder Materialdaten zu anderen technischen Ergebnissen führen können.
Hinzu kommt die physikalische Bindung. Engineering ist nicht frei generativ. Ein Sprachmodell kann Vorschläge erzeugen, aber technische Systeme unterliegen Erhaltungssätzen, Materialgesetzen, Fertigungsgrenzen und normativen Anforderungen. Masse, Energie, Impuls, Wärmeleitung, Strömung, Festigkeit, Schwingungsverhalten, Verschleiß und Alterung folgen nicht sprachlicher Wahrscheinlichkeit. Ein Large Engineering Model muss deshalb entweder direkt physikalisches Wissen einbeziehen oder eng mit klassischen Simulationsmethoden, Surrogatmodellen und Validierungsdaten gekoppelt sein. In vielen Fällen wird es klassische Solver nicht ersetzen, sondern ergänzen. Es kann frühe Varianten schneller bewerten, große Designräume vorfiltern oder Approximationen liefern, während die finale Absicherung weiterhin über hochauflösende Simulationen, Tests und Freigabeprozesse erfolgt.
Für industrielle Anwendungen ist außerdem Nachvollziehbarkeit notwendig. Eine technische Aussage muss auf Daten, Annahmen und Modellständen zurückgeführt werden können. Es reicht nicht, dass ein System eine Antwort gibt. Relevant ist, welche Datenbasis verwendet wurde, ob die Antwort innerhalb des trainierten oder validierten Bereichs liegt, welche Unsicherheit besteht und welche Prüfungen die Aussage stützen. Besonders in sicherheitskritischen oder regulierten Bereichen muss klar sein, ob ein Modell nur eine Hypothese formuliert, eine bekannte Regel anwendet oder ein validiertes Ergebnis ableitet. Ohne diese Unterscheidung entsteht ein Risiko, weil sprachliche Sicherheit mit technischer Sicherheit verwechselt werden kann.
Large Engineering Models erfordern daher eine andere Architektur als einfache Chatbot-Anwendungen. Am Anfang steht ein strukturierter Engineering-Datenbestand. CAD-Modelle, CAE-Ergebnisse, Prüfstandsdaten, Materialkennwerte, Stücklisten, Requirements, Änderungsinformationen, Produktionsdaten und Qualitätsdaten müssen versioniert und miteinander verknüpft werden. Besonders wichtig sind Metadaten: Ein Simulationsergebnis ist nur dann wiederverwendbar, wenn Geometrieversion, Randbedingungen, Solver, Netzqualität, Materialmodell und Berechnungsziel bekannt sind. Ein Prüfergebnis ist nur dann als Referenz geeignet, wenn Testaufbau, Messmethode, Probenstatus und Umgebungsbedingungen dokumentiert sind.
Auf dieser Datenbasis können Modelle trainiert oder angepasst werden. Je nach Aufgabe kommen unterschiedliche Verfahren infrage. Für geometriebezogene Probleme können Graph Neural Networks, 3D-Modelle oder feldbasierte Repräsentationen relevant sein. Für schnelle Näherungen komplexer Simulationen werden häufig Surrogate Models eingesetzt. Für Aufgaben mit starkem physikalischem Bezug können physics-informed Ansätze sinnvoll sein. Für die Verknüpfung technischer Dokumente, Requirements und Änderungsinformationen bleiben Sprachmodelle nützlich. In der Praxis wird ein Large Engineering Model daher selten ein einzelnes Modell sein. Wahrscheinlicher ist eine Kombination mehrerer Modelltypen, die über gemeinsame Datenstrukturen und Schnittstellen verbunden sind.
Ein weiterer Bestandteil ist die formale Behandlung von Constraints. Technische Einschränkungen sollten nicht erst nach der Generierung einer Antwort manuell überprüft werden. Sie müssen Teil der Systemlogik sein. Dazu gehören physikalische Grenzwerte, Materialgrenzen, Fertigungsregeln, Toleranzen, Bauraumbeschränkungen, Normanforderungen, Kostenrahmen und Freigabekriterien. Viele dieser Regeln existieren in Unternehmen bereits, aber häufig in verstreuter Form: in Konstruktionsrichtlinien, Excel-Dateien, Expertenwissen, PLM-Feldern, Normtexten oder impliziten Review-Praktiken. Für ein Large Engineering Model müssen sie so aufbereitet werden, dass sie maschinenlesbar und prüfbar werden.
Die Integration in bestehende Prozesse ist ebenso wichtig wie das Modell selbst. Engineering-Entscheidungen entstehen in CAD-, CAE-, PLM-, ALM-, MES- und QMS-Systemen. Sie laufen durch Reviews, Änderungsprozesse, Validierungspläne und Freigaben. Ein KI-System, das außerhalb dieser Prozesskette steht, bleibt ein Hilfsmittel ohne verbindliche Wirkung. Erst wenn Modellvorschläge mit Anforderungen, Varianten, Nachweisen und Freigabeschritten verbunden sind, können sie produktiv genutzt werden. Dabei muss auch festgelegt sein, welche Rolle das Modell spielt. Es kann beispielsweise Varianten priorisieren, Risiken markieren oder fehlende Nachweise erkennen. Die Verantwortung für die technische Freigabe bleibt jedoch im Engineering-Prozess verankert.
Für Forschung und Entwicklung liegt der Nutzen vor allem in der schnelleren Exploration technischer Lösungsräume. Klassische Simulationen und physische Tests sind oft teuer und zeitaufwendig. Deshalb werden in frühen Phasen nur relativ wenige Varianten detailliert untersucht. Ein Large Engineering Model kann diesen Engpass entschärfen, indem es viele Varianten näherungsweise bewertet und Bereiche identifiziert, die für genauere Simulationen oder Tests relevant sind. Dadurch verschiebt sich der Aufwand: Weniger Zeit wird für offensichtlich ungeeignete Varianten verwendet, mehr Aufmerksamkeit kann auf technisch vielversprechende Bereiche gelegt werden. Entscheidend ist dabei, dass die Approximationen nicht mit finaler Validierung verwechselt werden.
Auch in der Fertigung kann ein solcher Ansatz nützlich sein. Viele Produktionsprozesse hängen von engen Prozessfenstern ab.
Änderungen an Material, Geometrie, Werkzeug, Temperatur, Druck, Geschwindigkeit oder Umgebungsbedingungen können Auswirkungen auf Qualität, Zykluszeit und Ausschuss haben. Ein Large Engineering Model kann historische Prozessdaten, Simulationen und Qualitätsdaten nutzen, um Zusammenhänge sichtbar zu machen oder Parameterbereiche vorzuschlagen. Auch hier gilt: Das Modell ersetzt nicht die Prozessfreigabe, sondern unterstützt die Analyse und Eingrenzung.
Für CTOs und technische Führungskräfte ergibt sich daraus eine klare Konsequenz. Der Aufbau von Large Engineering Models ist in erster Linie kein Prompt-Engineering-Projekt. Es ist ein Daten-, Modellierungs- und Prozessprojekt. Der Engpass liegt meist nicht bei der Formulierung der Fragen, sondern bei der Verfügbarkeit konsistenter, rückverfolgbarer und ausreichend kontextualisierter Engineering-Daten. Unternehmen, die ihre technischen Daten über Jahre in getrennten Systemen, uneinheitlichen Formaten und mit unvollständigen Metadaten abgelegt haben, können dieses Problem nicht durch ein allgemeines Sprachmodell überspringen.
Der sinnvolle Ausgangspunkt ist deshalb eine konkrete Engineering-Entscheidung. Nicht die Frage „Wo können wir KI einsetzen?“ ist entscheidend, sondern: Welche technische Entscheidung verursacht hohe Kosten, lange Wartezeiten oder wiederkehrende Fehler? Das kann die Auswahl von Designvarianten sein, die Reduktion von Simulationsaufwand, die Interpretation von Testergebnissen, die Optimierung eines Prozessfensters oder die frühere Erkennung von Fertigungsrisiken. Aus dieser Entscheidung lässt sich ableiten, welche Daten, Modelle, Constraints und Validierungsschritte erforderlich sind.
Large Engineering Models sind damit weniger als Ersatz für Engineers zu verstehen, sondern als technische Modellschicht über komplexen Entwicklungsdaten. Sie können helfen, vorhandenes Wissen besser nutzbar zu machen, Simulation und Versuch gezielter einzusetzen und technische Abhängigkeiten früher sichtbar zu machen. Ihre Qualität hängt jedoch davon ab, ob sie in die Realität des jeweiligen Engineering-Kontexts eingebettet sind. Ohne domänenspezifische Daten, ohne physikalische und prozessuale Constraints und ohne Validierung bleiben sie allgemeine Assistenzsysteme.
Der Übergang von GPT zu Large Engineering Models ist deshalb kein Wechsel von einem Chatmodell zu einem größeren Chatmodell. Es ist der Übergang von sprachlicher Unterstützung zu domänenspezifischer technischer Entscheidungsunterstützung. Prompting bleibt dabei nützlich, aber es ist nicht der Kern. Der Kern liegt in der strukturierten Abbildung technischer Realität: Daten, Modelle, Prozesse, Constraints und Nachweise. Im Engineering zählt am Ende nicht, ob ein System eine plausible Antwort gibt. Entscheidend ist, ob diese Antwort unter realen Bedingungen berechenbar, prüfbar und verantwortbar ist.
