I. „Wir sind Ingenieure, keine ITler." – Ein Paradoxon, das mir keine Ruhe lässt

In den letzten Monaten habe ich viele Gespräche mit Vorständen, Geschäftsführern und Engineering-Leitern geführt – v.a. im Maschinenbau und im Automobilbau. Da gab es oft ein Thema, das mir keine Ruhe lässt.

Auf der einen Seite herrscht in den Führungsetagen absolute Klarheit: Die Produktentwicklung muss schneller werden. Lieferzeiten, Kostendruck, Fachkräftemangel, geopolitischer Wettbewerb – die Gründe sind je nach Branche unterschiedlich, das Ziel ist dasselbe. Und fast alle setzen dabei große Hoffnungen auf KI, insbesondere auf Agentic AI: KI-Systeme, die nicht nur Fragen beantworten, sondern eigenständig Arbeitsschritte im Engineering übernehmen.

Gleichzeitig ist denselben Entscheidern völlig klar, dass zwei Dinge im Engineering zum Problem werden: Halluzinationen und Datenverfügbarkeit. Ein Sprachmodell, das eine plausibel klingende, aber falsche Toleranz vorschlägt, ist im Marketing peinlich, in der Konstruktion aber gefährlich. Entsprechend höre ich in manchen Vorständen inzwischen Sätze wie: „Der Knowledge Graph wird für unser Engineering absolut essentiell."

Und jetzt kommt das Paradoxon: Wenn ich mit Managern in den Unternehmen – CTO oder Head of Engineering – tiefer über Knowledge Graphen sprechen möchte, höre ich sehr oft denselben Satz: „Das Thema ist mir zu abstrakt. Wir sind Ingenieure, keine ITler."

Ich verstehe diesen Reflex. Der Begriff klingt nach Informatik-Vorlesung, die üblichen Erklärungen strotzen vor Vokabeln wie „Ontologie", „RDF" und „semantische Tripel". Aber ich bin überzeugt: Der Knowledge Graph ist nicht nur irgendein IT-Thema. Er ist ein Ingenieursthema – vielleicht das wichtigste der nächsten Jahre. Denn er beantwortet eine Frage, die jeder Konstruktionsleiter aus dem Alltag kennt: Wie machen wir das Wissen, das in unseren Produkten, Projekten und Köpfen steckt, systematisch wiederverwendbar?

In diesem Artikel erkläre ich deshalb in Ingenieurssprache, was ein Knowledge Graph ist, welches tieferliegende Problem er löst und was damit konkret möglich wird. Und zwar nicht abstrakt, sondern durchgängig an einem konkreten Beispiel: einer individuellen Montageanlage aus dem Sondermaschinenbau.

II. Das Praxisbeispiel: eine individuelle Montageanlage im ETO-Geschäft

Stellen Sie sich einen Sondermaschinenbauer für Montagesysteme vor. Sein Geschäft: kundenindividuelle Montagelinien, Engineer-to-Order. Ein Industriekunde fragt eine Montagelinie für ein neues elektromechanisches Aggregat an – sagen wir zwölf Stationen: Zuführen, Fügen, Einpressen einer Lagerbuchse mit Kraft-Weg-Überwachung, Verschrauben, Fetten, EOL-Prüfung. Dazu ein Lastenheft mit 120 Seiten und mehreren hundert Anforderungen: Taktzeit ≤ 12 Sekunden, Verfügbarkeit ≥ 98 % nach kundenspezifisch definierter Berechnung, Rückverfolgbarkeit auf Bauteilebene, eine definierte Reinraumklasse für zwei Stationen, Anbindung an das MES des Kunden.

Jede dieser Anlagen ist ein Unikat – und besteht am Ende doch zu großen Teilen aus Bewährtem. In einem Fraunhofer-Vortrag hörte ich einmal für einen konkreten Sondermaschinenbau-Kontext die Größenordnung: 80 % der Bauteile können konfiguriert, 15 % wiederverwendet und nur 5 % komplett neu konstruiert werden. Die tatsächlichen Anteile unterscheiden sich natürlich nach Produkt und Unternehmen – aber die Richtung deckt sich mit meiner Projekterfahrung: Grundgestelle, Werkstückträger, Transfersysteme, Pick-and-Place-Einheiten, Schraubspindeln, Pressen, Prüftechnik. Eine typische Linie umfasst mehrere tausend Bauteile, ein erheblicher Teil davon Zukauf, der Rest Eigenkonstruktion.

Der heutige Prozess sieht bei den meisten Unternehmen, mit denen ich spreche, so aus: Vertrieb und Projektierung arbeiten das Lastenheft manuell durch und übertragen die Anforderungen in ein Konzept – oft in Word – und eine Kalkulation – fast immer in Excel. Nach Auftragseingang beginnt die Auftragskonstruktion, und zwar häufig gefühlt „bei fast null". Ob es eine ähnliche Einpress-Station schon einmal gab, hängt am Erinnerungsvermögen einzelner Kollegen. Der Standardsatz in jedem dieser Unternehmen lautet sinngemäß: „Frag mal den Herbert, der hat sowas 2019 schon mal konstruiert." Wenn der Herbert gerade im Urlaub ist, wird neu konstruiert. Wenn der Herbert in Rente geht, wird dauerhaft neu konstruiert.

Das Ergebnis: viel manuelle Auftragskonstruktion, kaum systematische Wiederverwendung von Wissen und Bauteilen, wachsende Teilevielfalt, lange Durchlaufzeiten – und Konstrukteure, die einen erheblichen Teil ihrer Zeit mit Suchen, Nachfragen und Neu-Erfinden verbringen.

III. Was ein Knowledge Graph ist

Jeder Maschinenbauer arbeitet bereits täglich mit einem Graphen, ohne ihn so zu nennen: der Stückliste. Eine Stückliste ist ein Netz aus Knoten (Baugruppen, Bauteile) und Verbindungen zwischen ihnen. Im Kern dominiert dort eine Art von Verbindung: „besteht aus" beziehungsweise „verwendet". Die Anlage besteht aus Station 06, Station 06 besteht aus der Schraubeinheit, die Schraubeinheit besteht aus der Schraubspindel.

Ein Knowledge Graph ist nichts anderes als die konsequente Verallgemeinerung dieser Idee: ein Netz aus Knoten und Verbindungen – aber mit unterschiedlichen, domänenspezifisch und konsistent definierten Verbindungsarten. Neben „besteht aus" gibt es dann zum Beispiel: „erfüllt Anforderung", „begrenzt durch", „ist Variante von", „ist kompatibel mit", „wurde nachgewiesen durch", „ist ähnlich zu", „wurde gewählt, weil".

Konkret an unserer Montageanlage könnte ein winziger Ausschnitt des Graphen so aussehen:

Anforderung R-217 „Taktzeit ≤ 12 s" → gilt für → Montagelinie → wird heruntergebrochen auf → zulässige Stationszykluszeiten. Station 06 „Verschrauben" → hat gemessene Zykluszeit → 10,8 s → wurde nachgewiesen durch → Abnahmeprotokoll P-4711.

Station 06 → verwendet → Schraubspindel Typ EC-8. Schraubprozess SP-06 → hat Sollmoment → 8 Nm → hat zulässige Ergebnisabweichung → ± 5 %.

Station 06 → ist Variante von → Schraubstation aus Projekt M-2022-134 → wurde ausgelegt von → Konstrukteur H. → dokumentiert in → Auslegungsrechnung AR-0815.

Zwei Dinge sind daran entscheidend.

Erstens: Das Wissen steckt nicht nur in den Objekten, sondern vor allem in ihren Beziehungen, Eigenschaften, Regeln und Begründungen. Dass es eine Schraubspindel EC-8 gibt, steht auch im ERP. Dass es ein Lastenheft mit R-217 gibt, steht im Anforderungsdokument. Aber wie R-217 auf die zulässige Zykluszeit der Station 06 heruntergebrochen wurde, dass Station 06 eine Variante eines Projekts von 2022 ist und warum damals genau diese Spindel gewählt wurde – diese Verbindungen stehen heute häufig nicht durchgängig, systemübergreifend und maschinenlesbar zur Verfügung. Ein Teil davon existiert in einzelnen Systemen, ein anderer nur im Kopf des Projektleiters. Vereinfacht gesagt ist der erfahrene Projektleiter ein wandelnder Knowledge Graph – ergänzt um Erfahrung, Urteilsvermögen und implizites Wissen, das sich nie vollständig formalisieren lässt. Das Ziel ist, dieses Beziehungswissen explizit, dauerhaft und maschinenlesbar zu machen.

Zweitens: Der Graph ist abfragbar. Wer die Beziehungen explizit hat, kann Fragen entlang der Verbindungen beantworten – über mehrere, explizit definierte Zwischenschritte. „Welche Stationen in laufenden Projekten sind von der Abkündigung der Spindel EC-8 betroffen, und welche Kundenanforderungen hängen daran?" kann im Graphen – wenn die Verbindungen vollständig und aktuell sind – zu einer Abfrage von Sekunden werden. Heute ist es eine Wochenaufgabe für jemanden, der drei Systeme und vier Kollegen befragt.

Mehr ist ein Knowledge Graph im Kern nicht. Keine Magie. In der hier beschriebenen Architektur ist er keine neue Datenbank, die alles ersetzt, sondern eine Beziehungsschicht über den bestehenden Systemen, so wie die Stückliste eine Strukturschicht über den einzelnen Bauteilen ist.

IV. Das tieferliegende Problem: Das Wissen existiert – aber die Beziehungen sind nicht durchgängig verfügbar

Warum kann die heutige Systemlandschaft das nicht? Schließlich haben die meisten Unternehmen CAD, PLM, ERP, CRM und ein Anforderungsmanagement – oft für siebenstellige Beträge eingeführt.

Die Antwort hat aus meiner Sicht drei Schichten:

Schicht 1: Fragmentierung entlang des Prozesses. Das Wissen über die Montageanlage entsteht verteilt: Die Anforderungen liegen im Lastenheft (PDF) und vielleicht in einem Anforderungstool. Das Konzept in Word. Die Kalkulation in Excel. Die Konstruktion im CAD, verwaltet im PLM. Materialstämme und Arbeitspläne im ERP. Die Inbetriebnahme-Erkenntnisse in E-Mails und Serviceberichten. Jedes System verwaltet seine eigene Sicht mit eigenen Nummernkreisen und eigener Versionslogik. Die klassische Antwort – Punkt-zu-Punkt-Schnittstellen – skaliert nicht: Bei zehn Systemen sind es theoretisch 45 mögliche Verbindungen.

Schicht 2: Das Bedeutungsproblem. Selbst wo Daten technisch verbunden sind, meinen gleiche Wörter Verschiedenes. „Variante" heißt im Vertrieb etwas anderes als im PLM. Ein „Artikel" im ERP ist nicht dasselbe wie ein „Part" im CAD. Und dieselbe Einpress-Station heißt im Angebot „Fügen 2", in der Konstruktion „ST-06" und beim Kunden „OP 40". Ohne eine Schicht, die einmal sauber definiert, was was ist und wie es zusammenhängt, bleibt jede Integration eine fragile Mapping-Übung – und jede KI, die nur über Textähnlichkeit auf diesen Daten arbeitet, stößt bei mehrstufigen Engineering-Fragen schnell an Grenzen.

Schicht 3: Das implizite Wissen. Ein großer und besonders wertvoller Teil des Engineering-Wissens steht in gar keinem System. Warum wurde 2022 die pneumatische Presse durch eine servoelektrische ersetzt? Warum darf Werkstückträger-Typ B nicht mit dem Transfersystem C kombiniert werden? Diese Auslegungsgründe und Erfahrungsregeln sind das eigentlich Wertvolle – und sie gehen mit jedem Mitarbeiter, der das Unternehmen verlässt, unwiederbringlich verloren. Angesichts der Altersstruktur in deutschen Konstruktionsabteilungen ist das kein theoretisches Risiko.

Das tieferliegende Problem lautet also: Engineering ist ein wissensintensiver, hochvernetzter Prozess – der auf einer Systemlandschaft läuft, deren einzelne Werkzeuge für ihre jeweiligen operativen Kernaufgaben optimiert wurden. PLM verwaltet Produktstrukturen, Dateien, Freigaben und Änderungen. ERP verwaltet Materialstämme, Arbeitspläne, Beschaffung und Produktion. Aber systemübergreifendes Beziehungswissen, gemeinsame Identitäten und informelle Auslegungsgründe bilden beide meist nur teilweise ab. Die Vernetzungsstruktur hat keinen gemeinsamen, systemübergreifend nutzbaren Ort. Der Knowledge Graph gibt ihr einen.

Diese Diagnose ist übrigens keine Einzelmeinung von mir. Wissenschaftliche Übersichtsarbeiten zum Einsatz von Knowledge Graphen in der Fertigungsindustrie benennen genau diese Punkte – Heterogenität und mangelnde Interoperabilität der Datenquellen sowie Unvollständigkeit des erfassten Wissens – als die Kernprobleme, die der Graph adressiert.

V. Durchgespielt: Die Kundenanfrage mit Knowledge Graph

Wie würde der Anfrageprozess der Montageanlage mit einem gut aufgebauten Knowledge Graphen ablaufen?

Schritt 1: Kundenanforderungen werden auf Produktmerkmale gemappt

Das Lastenheft wird eingelesen, und jede Anforderung wird einem Knoten im Graphen zugeordnet – nicht als Volltext-Ähnlichkeit („klingt so ähnlich wie"), sondern als typisierte Verbindung zu den Merkmalen des eigenen Produktbaukastens. „Taktzeit ≤ 12 s" verbindet sich mit dem Merkmal Taktzeit der Objektklasse Montagelinie, „Einpressen mit Kraft-Weg-Überwachung" mit der Stationsklasse Fügen/Pressen und deren Merkmalen Presskraft, Überwachungsverfahren, Dokumentationspflicht. Anforderungen, die kein Gegenstück im Baukasten haben, fallen automatisch als „ungedeckt" heraus – und genau diese Liste ist Gold wert: Sie ist die ehrliche Antwort auf die Frage, wie viel Sonder in diesem Sonderprojekt wirklich steckt.

Heute macht diese Übersetzung ein erfahrener Projektierer über Tage, und das Ergebnis lebt in seinem Kopf und einer Excel. Im Graphen ist sie explizit, prüfbar und bleibt dem Projekt dauerhaft zugeordnet – bis in die Abnahme, wo jede Anforderung über ihre Verbindungen zum Prüfprotokoll nachweisbar ist.

Schritt 2: Konfiguriert wird, was konfigurierbar ist

Für alle Anforderungen mit Gegenstück im Baukasten greifen jetzt die Konfigurationsregeln – und hier zeigt sich eine Stärke des Graphen, die ich besonders unterschätzt finde: Variantenmanagement. In den meisten Unternehmen leben Kompatibilitäten und Auswahlregeln in gepflegten (oder eben nicht mehr gepflegten) Excel-Matrizen und in den Köpfen: Werkstückträger B passt nicht zu Transfersystem C; ab Presskraft 20 kN ist Rahmenklasse 3 nötig; Reinraumanforderung schließt Pneumatik-Baugruppe X aus.

Als Matrix ist dieses Regelwerk zweidimensional und zerfällt bei jeder neuen Baureihe. Als Graph ist es das, was es in Wahrheit ist: ein Netz. „Ist kompatibel mit", „schließt aus" und „erfordert ab Grenzwert" werden zentral und versioniert beschrieben. Der Graph stellt dafür Komponenten, Merkmale und Abhängigkeiten bereit. Darauf setzt eine Regel- oder Konfigurationslogik auf, die gültige Kombinationen ableitet und Verstöße erkennt. Eine Regel ändern heißt dann nicht mehr: fünf Excel-Matrizen suchen und hoffen, dass keine vergessen wurde. Sie wird an einer zentralen Stelle geändert und gilt nachvollziehbar für jede künftige Konfiguration. Für die Anlage heißt das: Grundgestell, Transfersystem, Werkstückträger und Standard-Stationen werden regelbasiert zusammengestellt – inklusive automatischer Prüfung, dass keine Kombination gegen eine freigegebene Kompatibilitätsregel verstößt.

Schritt 3: Wiederverwendet wird, was schon einmal gelöst wurde

Jetzt bleiben die Umfänge, die weder Standard noch konfigurierbar sind – klassischerweise der Punkt, an dem die Neukonstruktion beginnt. Hier kommt die Ähnlichkeitssuche ins Spiel, und zwar in zwei Richtungen.

Die erste Richtung ist die funktionale Ähnlichkeit auf Basis des Graphen: „Gab es dieses Konstruktionsproblem schon einmal?" wird zur Abfrage über Funktionen und Wirkprinzipien statt über Dateinamen. Gesucht wird nicht „Einpressstation_final_v3.prt", sondern: eine Station, die fügt, mit Kraft-Weg-Überwachung, für ein Bauteil mit Presssitz H7/s6 im relevanten Durchmesserbereich, bei Taktzeit unter 12 s. Weil im Graphen frühere Projekte mit genau diesen Merkmals-Verbindungen hängen, kann ein Ähnlichkeitsmodell bewerten, wie stark frühere Lösungen hinsichtlich Funktion, Randbedingungen und Merkmalen übereinstimmen – und findet die Schraub- und Pressstationen von 2019 und 2022 – auch wenn der Konstrukteur von damals längst nicht mehr im Haus ist.

Die zweite Richtung ist die geometrische Ähnlichkeit über 3D-Modelle und 2D-Zeichnungen: Für Eigenfertigungsteile – Aufnahmen, Adapterplatten, Greiferfinger – wird der Bestand nach geometrisch ähnlichen Teilen durchsucht, bevor irgendetwas neu angelegt wird. Wie das technisch funktioniert und warum dabei auch die 2D-Zeichnung als Datenquelle unverzichtbar ist, habe ich in meinen letzten Artikeln beschrieben. Wichtig für den Zusammenhang hier: Geometrische Ähnlichkeit und funktionale Ähnlichkeit ergänzen sich. Die Geometrie findet das ähnliche Teil; der Graph liefert dazu den Kontext – zugehöriger Arbeitsplan, verwendete Toleranzen, damalige Auslegungsgründe, bekannte Probleme aus der Inbetriebnahme.

Das Ergebnis: Nur ein Bruchteil der Sondermaschine ist wirklich neu

Am Ende dieses Prozesses steht eine ehrliche Aufteilung des Projekts: ein großer Teil konfiguriert, ein weiterer Teil aus früheren Projekten adaptiert – und nur ein vergleichsweise kleiner Rest muss wirklich komplett neu konstruiert werden. Wichtig dabei: Bauteilanteile sind nicht dasselbe wie Aufwandsanteile. Wenige neue Schlüsselkomponenten können einen erheblichen Teil der Engineering-Arbeit und des Projektrisikos ausmachen. Genau dort gehört die knappe Konstrukteurszeit hin: an das echte Sonder, das den Kunden differenziert. Nicht an die achte Neukonstruktion einer Adapterplatte.

VI. Warum Knowledge Graphs ein starkes Kontextfundament für verlässliche Agentic AI im Engineering sind

Zurück zum Paradoxon vom Anfang: Alle wollen Agentic AI im Engineering, alle fürchten Halluzinationen. Ein Knowledge Graph kann genau das Bindeglied zwischen beidem sein:

Ein Sprachmodell, das lediglich über Textähnlichkeit auf Dokumente zugreift, stößt bei Engineering-Fragen schnell an Grenzen. Denn Engineering-Fragen sind fast nie Ein-Schritt-Fragen. „Welche Spindel für Station 06?" verlangt eine Kette: Anforderung → Station → Drehmomentbereich → Kompatibilität mit der Steuerung → Lieferstatus. Textähnlichkeit („dieses Dokument klingt relevant") kann solche Ketten allein nicht zuverlässig abschreiten. Ein Graph kann die dafür notwendigen Abhängigkeiten explizit bereitstellen. Die KI beantwortet die Frage dann nicht nur aus ihrem „Bauchgefühl", sondern indem sie relevante Pfade und Teilgraphen gezielt abfragt – und bei Bedarf zusätzlich Datenbanken, Berechnungen oder Engineering-Tools nutzt. Und sie kann diesen Pfad als Begründung mitliefern: Diese Antwort stützt sich auf Anforderung R-217, Kompatibilitätsregel K-88 und Abnahmeprotokoll P-4711. Jeder Befund ist nachvollziehbar und prüfbar – dieselbe Eigenschaft, die ich schon bei der Zeichnungsprüfung als nicht verhandelbar beschrieben habe.

Das ist nicht nur meine Einschätzung. Aktuelle Untersuchungen stützen die Richtung:

• Mehrere aktuelle Untersuchungen zeigen, dass ein großer Teil der GenAI-Piloten nicht in messbar wertschöpfende, skalierte Anwendungen übergeht. Als wiederkehrende Ursachen gelten unter anderem fehlende Integration in die Prozesse und unzureichender Zugriff auf den jeweiligen Unternehmenskontext. Die Modelle sind oft nicht das eigentliche Problem; ihnen fehlt der Zusammenhang der Unternehmensdaten.

• In einem Enterprise-QA-Benchmark stieg die Antwortgenauigkeit durch eine Knowledge-Graph-Repräsentation der Datenbank von 16 auf 54 Prozent. Das ist ein starkes Ergebnis für das untersuchte Szenario, aber kein allgemeingültiger Faktor für jede LLM-Anwendung. Microsoft Research berichtet für seinen GraphRAG-Ansatz je nach Abfrageebene von 26 bis über 97 Prozent weniger Kontext-Tokens als bei der Vergleichsmethode; der Spitzenwert galt für stark verdichtete globale Zusammenfassungen. Die Grundidee bleibt dieselbe: Der Graph führt die KI gezielter zu den relevanten Zusammenhängen, statt sie durch Dokumentenberge suchen zu lassen.

• Gartner prognostiziert, dass über 40 % der Agentic-AI-Projekte bis Ende 2027 wieder abgebrochen werden – vor allem wegen steigender Kosten, unklarem Geschäftswert und unzureichender Risikokontrollen. Meine zusätzliche These für das Engineering lautet: Ein weiterer entscheidender Faktor wird sein, ob die Agenten auf einem belastbaren Kontextfundament arbeiten.

Ein Knowledge Graph ist dabei kein Wahrheitsautomat. Er beseitigt Halluzinationen nicht automatisch. Er kann Antworten besser begründen und Abhängigkeiten explizit machen – aber nur innerhalb der Qualität und Aktualität des modellierten Wissens. Deshalb gehören Quellen, Versionen, Vertrauenswerte und fachliche Freigaben zum System.

Man kann es auf eine einfache Formel bringen: Sprachmodelle werden zur Commodity. Der Graph des eigenen Produktwissens nicht. Jeder Wettbewerber kann dasselbe Modell mieten. Was niemand mieten kann, ist das formalisierte Wissen darüber, wie die eigenen Anlagen funktionieren, warum sie so ausgelegt sind und was zueinander passt. Für ein ETO-Unternehmen ist der Knowledge Graph damit nicht IT-Infrastruktur – er ist die digitale Form des eigentlichen Betriebskapitals.

VII. Wer das schon macht – und wie weit die Industrie wirklich ist

Berechtigte Ingenieursfrage: Ist das erprobt oder Zukunftsmusik?

Viele größere Industrieunternehmen wie Siemens, Bosch oder die Automotive OEMs arbeiten schon länger an dem Thema. Man muss aber ehrlich sagen: In der Breite des Maschinenbaus ist der Umsetzungsstand dünn. Die meisten Unternehmen, mit denen ich spreche, stehen zwischen „noch nie strukturiert damit beschäftigt" und „ein Proof of Concept, der nie produktiv wurde". Das liegt nach meiner Erfahrung selten an der Graphtechnologie selbst – und sehr häufig an zwei vermeidbaren Fehlern: Entweder wurde das Thema als IT-Großprojekt aufgesetzt („wir modellieren erst mal zwei Jahre das ganze Unternehmen"), oder es wurde als Forschungsspielwiese behandelt, ohne einen Use Case mit hartem Nutzen. Interessanterweise beschreibt auch Siemens die eigene Erfolgslogik genau andersherum: klein anfangen, mit zwei, drei Datenquellen und einem werthaltigen Anwendungsfall, und den Graphen von dort wachsen lassen – als verbindende Schicht über den bestehenden Systemen, nicht als deren Ersatz.

Für den Mittelstand ist das eine gute Nachricht: Man braucht keinen Unternehmens-Graphen, sondern einen Anwendungsfall – zum Beispiel genau den Anfrageprozess aus Abschnitt V.

VIII. Die Hürden

Aber natürlich gibt es auf dem Weg auch Herausforderungen:

Erstens: Das Wissensmodell muss von Ingenieuren kommen. Die Frage, welche Objektklassen, Merkmale und Beziehungsarten es im eigenen Produktspektrum gibt – was eine Station ist, wovon eine Presskraft abhängt, wann zwei Komponenten kompatibel sind – kann keine IT-Abteilung und kein externer Berater beantworten. Das ist Konstruktionsmethodik, kein Programmieren. Wer sagt „wir sind Ingenieure, keine ITler", nennt also genau den Grund, warum das Thema in die Konstruktionsleitung gehört und nicht (nur) in die IT. Die gute Nachricht: Ein großer Teil des Befüllens ist heute automatisierbar (dazu gleich mehr); die Modellierung selbst ist überschaubar, wenn man mit einem Use Case beginnt.

Zweitens: Der Graph deckt die eigene Datenrealität gnadenlos auf. Doppelte Materialstämme, drei Benennungen für dasselbe Bauteil, verwaiste Zeichnungen. Manche schließen daraus: „Erst Datenqualität, dann KI." Ich halte das für die falsche Reihenfolge – warum, habe ich in einem eigenen Artikel begründet. Kurzfassung: Der Graph ist nicht das Opfer schlechter Datenqualität, sondern ihr wirksamstes Aufräumwerkzeug, weil er Dubletten und Widersprüche sichtbar und priorisierbar macht.

Drittens: Wissen braucht Version, Gültigkeit und Herkunft. Im Engineering reicht es nicht zu wissen, dass zwei Dinge zusammenhängen. Entscheidend ist, für welche Produktversion, welchen Projektstand und welchen Zeitraum die Aussage gilt – und aus welcher Quelle sie stammt. Eine Spindel kann heute freigegeben und morgen abgekündigt sein. Eine Kompatibilitätsregel kann erst ab Softwarestand 4.2 gelten. Ein Abnahmeprotokoll belegt den As-built-Stand eines konkreten Projekts, nicht automatisch jede spätere Variante. Ein produktiver Knowledge Graph muss deshalb nicht nur Beziehungen speichern, sondern auch Revisionen, Freigabestatus, Herkunft und Verantwortlichkeiten.

IX. Die gute Nachricht: Der Graph wird heute teilautomatisiert erzeugt – und von Ingenieuren validiert und ergänzt

An dieser Stelle kommt in Gesprächen fast immer derselbe Einwand: „Klingt gut – aber wer soll das alles pflegen? Meine Konstrukteure haben keine Zeit, Wissensmodelle zu befüllen." Der Einwand wäre vor wenigen Jahren berechtigt gewesen. Das manuelle Erfassen von Wissen ist genau der Grund, warum frühere Anläufe in diese Richtung – Stichwort Wissensdatenbanken der 2000er – regelmäßig eingeschlafen sind. Die nahe Zukunft sieht anders aus: Der Graph wird nicht mehr vollständig manuell erfasst. Große Teile können aus den vorhandenen Daten teilautomatisiert vorgeschlagen oder erzeugt werden – und Ingenieure modellieren, validieren und ergänzen das entscheidende Domänenwissen.

Aus dem PLM und ERP kommen Artikel, Stücklisten und Projektzuordnungen. Aus den Lastenheften und Angebotsdokumenten extrahieren Sprachmodelle die Anforderungen samt Grenzwerten und ordnen sie den Merkmalen des Produktbaukastens zu. Aus 3D-Modellen und 2D-Zeichnungen erzeugen Analyseverfahren typisierte Merkmale und „ist ähnlich zu"-Verbindungen quer über den Teilebestand. Und aus alten Projektordnern, Auslegungsrechnungen und Prüfprotokollen lassen sich die Verbindungen rekonstruieren, welche Station welche Anforderung erfüllt hat und womit sie nachgewiesen wurde. Für die Montageanlage heißt das: Ein großer Teil der strukturellen Grunddaten und bestimmte Beziehungsvorschläge entstehen, ohne dass ein Konstrukteur ein zusätzliches Formular ausfüllt. Die fachlich besonders wertvollen oder mehrdeutigen Beziehungen – warum etwas gewählt wurde, unter welchen Randbedingungen es funktioniert und wann eine Ausnahme gilt – müssen aber validiert oder explizit ergänzt werden. Automatisierung kann den manuellen Erfassungsaufwand erheblich reduzieren; die fachliche Prüfung bleibt trotzdem ein wesentlicher Teil der Arbeit.

Aber – und das ist der entscheidende Punkt – teilautomatisiert heißt nicht unbeaufsichtigt. Ein automatisch erzeugter Graph enthält Vorschläge: Deshalb ändert sich die Rolle der Konstrukteure und Arbeitsvorbereiter: Sie erfassen nicht mehr jeden Zusammenhang von Hand, sondern validieren und ergänzen gezielt. In der Praxis sieht das so aus: Das System legt dem Fachmann die extrahierten Verbindungen mit einer Verlässlichkeitseinschätzung vor – „Anforderung R-217 wird auf die zulässige Zykluszeit von Station 06 heruntergebrochen, sicher erkannt", „Station 06 ist vermutlich eine Variante von M-2022-134, bitte prüfen". Der Konstrukteur bestätigt, korrigiert oder verwirft mit wenigen Klicks. Der Arbeitsvorbereiter prüft, ob die aus dem Arbeitsplan abgeleiteten Fertigungs-Verbindungen stimmen. Statt jeden Zusammenhang manuell neu einzutragen, prüft der Fachmann vor allem die automatisch vorgeschlagenen und fachlich unsicheren Fälle – eingebettet in die Arbeit, die ohnehin ansteht, etwa bei der Angebotsprüfung oder der Konstruktionsfreigabe.

Dass dieses Zusammenspiel aus Maschine und Fachmann trägt, ist inzwischen doppelt belegt – wissenschaftlich und in der Praxis. Auf der wissenschaftlichen Seite hat eine 2025 in Information Processing & Management erschienene Studie genau diese Frage systematisch untersucht: Die Autoren verglichen neun Arbeitsteilungen zwischen Sprachmodellen und Domänenexperten bei der Validierung von Wissensgraphen – von vollautomatisch bis rein manuell: In der untersuchten wissenschaftlichen Knowledge-Graph-Pipeline lieferten hybride Workflows, in denen die Maschine vorprüft und der Experte gezielt die unsicheren Fälle entscheidet, die beste Kombination aus Qualität und Aufwand. Das unterstützt das Human-in-the-Loop-Prinzip – auch wenn es natürlich noch kein pauschaler Nachweis für jede industrielle Engineering-Domäne ist. Ein spannendes Beispiel aus der Praxis: Bosch hat in mehreren Forschungs- und Praxisarbeiten Ontologien und Knowledge Graphs eingesetzt, um heterogene Produktions-, Labor- und Simulationsdaten aus dem Widerstandspunktschweißen einheitlich zu beschreiben. Über vorbereitete Wissensbausteine – Bosch nennt sie Ontologie-Templates – bringen Schweiß- und Prozessexperten ihr Domänenwissen strukturiert ein, ohne die zugrunde liegende semantische Technologie selbst programmieren zu müssen.

Ein weiterer wichtiger Aspekt ist die Annotation: Genau an den Stellen, an denen der Fachmann etwas weiß, das in keinem Dokument steht, ergänzt er es als Verbindung – „wurde gewählt, weil der Kunde X vorgeschrieben hat", „nie wieder mit Transfersystem C kombinieren, Inbetriebnahme-Problem 2021". Das dauert Sekunden, landet aber dauerhaft und auffindbar im Graphen.

X. Wie das bei wailand zusammenhängt

Wer unsere letzten Veröffentlichungen verfolgt hat – 3D-Ähnlichkeitsanalyse, 2D-Zeichnungsanalyse, Workflowautomatisierung, Standardintegrationen – fragt sich vielleicht, wie das alles zusammenhängt.

Die Antwort ist dieser Artikel. Alles, was wir bauen, sind Bausteine genau der Architektur, die ich hier beschrieben habe – und der Knowledge Graph ist ihr Zentrum. In unserer Plattform heißt das konkret:

Der Integration Layer verbindet die bestehenden Systeme – CAD, PLM, ERP, MES, Excel – über standardisierte Konnektoren. Er liefert dem Graphen die Rohknoten: Artikel, Projekte, Anforderungen, Dokumente, Arbeitspläne. Ohne Integrationen bliebe der Graph eine leere Landkarte. Und umgekehrt gilt: Wir ersetzen keines der vorhandenen Engineering-Tools – der Graph ist die Beziehungsschicht zwischen ihnen.

Die KI-Services im Service Layer – allen voran die 3D-Ähnlichkeitsanalyse und die 2D-Zeichnungsanalyse – sind die Sinnesorgane des Graphen. Sie erzeugen genau die Knoten und Verbindungen, die in keinem Quellsystem stehen: Die Zeichnungsanalyse zerlegt eine Zeichnung in typisierte Features mit eindeutig referenzierbaren IDs – die Bohrung Ø63 H7 wird ein Knoten, ihre Toleranz, ihr Bezugssystem und die zugehörige Norm werden Verbindungen. Die 3D-Analyse erzeugt bewertete „ist ähnlich zu"-Verbindungen samt Ähnlichkeitsscore und Herkunft quer über den gesamten Teilebestand. Jede analysierte Zeichnung, jedes eingelesene Modell macht den Graphen dichter – und damit jede spätere Abfrage besser.

Der Knowledge Layer ist der Graph selbst: das vernetzte Produktwissen über Systemgrenzen hinweg – Anforderungen, Merkmale, Komponenten, Regeln, Normen, Projekte und ihre Beziehungen. Er liefert der KI expliziten, nachvollziehbaren Kontext sowie modellierte Abhängigkeiten und Begründungszusammenhänge, statt sie nur über Textähnlichkeit suchen zu lassen.

Der Workflow Layer macht daraus Automatisierung. Der Anfrageprozess aus Abschnitt V ist eine Kette von Workflow-Schritten: Lastenheft einlesen → Anforderungen auf Merkmale mappen → konfigurieren → Ähnlichkeitssuche → Ergebnisliste mit den ungedeckten Rest-Umfängen für den Konstrukteur. Wo Urteilsvermögen gefragt ist, entscheidet der Ingenieur; wo Fleißarbeit anfällt, der Workflow – und wo KI-Agenten eingesetzt werden, arbeiten sie auf dem Graphen, auf freigegebenen Regeln und auf den vorhandenen Engineering-Werkzeugen – statt nur auf Vermutungen.

Die Reihenfolge unserer Veröffentlichungen folgt dabei einer bewussten Logik: Zuerst die Bausteine, die sofort und einzeln Nutzen stiften und nebenbei den Graphen befüllen (Ähnlichkeit, Zeichnungsanalyse, Integrationen) – dann die durchgängige Automatisierung, die auf dem gewachsenen Wissensnetz aufsetzt. Man könnte sagen: Wir bauen den Knowledge Graphen nicht als Vorleistung, für die der Kunde zwei Jahre in Vorkasse geht, sondern als mitgeplanten Output von Automatisierungen, die sich einzeln rechnen.

XI. Mein Fazit

Der Knowledge Graph ist kein abstraktes IT-Thema. Er ist ein explizites Modell der Beziehungen, die heute nur in den Köpfen der besten Leute existieren – zwischen Anforderungen, Merkmalen, Komponenten, Regeln und Projekten. Für Engineer-to-Order-Unternehmen wie Sondermaschinenbauer – aber auch für Configure-to-Order-Unternehmen entscheidet genau dieses Beziehungswissen darüber, ob eine Kundenanfrage in Wochen oder in Tagen zu einem belastbaren Konzept wird – und ob die Konstrukteure am echten Sonder arbeiten oder Adapterplatten zum achten Mal erfinden.

Und er kann zu einem zentralen Baustein dafür werden, dass die großen Hoffnungen auf Agentic AI im Engineering nicht in Halluzinationen enden. Wer KI-Agenten will, die im Engineering verlässlich arbeiten, muss ihnen zuerst explizites, überprüfbares Wissen geben – und zusätzlich freigegebene Regeln, Berechnungen und Werkzeuge, auf denen sie arbeiten können.

Der Graph schafft damit eine explizite, systemübergreifende und überprüfbare Wissensgrundlage, auf der Suche, Konfiguration, Regeln, Workflows und KI-Agenten wesentlich zuverlässiger arbeiten können.

Deshalb mein Appell an jeden Engineering-Verantwortlichen, der sich bisher mit „wir sind Ingenieure, keine ITler" aus dem Thema herausgenommen hat: Genau weil Sie Ingenieur sind, ist es Ihr Thema. Die IT kann den Graphen betreiben. Modellieren, was Ihr Produkt ausmacht, können nur Sie.

Wenn Sie diskutieren möchten, wie ein erster, eng geschnittener Anwendungsfall in Ihrem Unternehmen aussehen könnte – vom Anforderungs-Mapping bis zur Ähnlichkeitssuche –, freue ich mich auf den Austausch.