Engineering AI Assistant Evaluation: A Buyer’s Framework

Ein Leitfaden für Käufer: KI-Assistenten für Siemens-NX- und Teamcenter-Engineering-Teams bewerten

§ 02 — Für wen dieses Papier ist und wie Sie es nutzen

Dieses Papier richtet sich an die Person, die den Kauf freigeben muss: eine Engineering-Leitung, eine CAD/PLM-Methodenverantwortliche oder einen IT-Architekten, der beurteilen soll, ob ein Engineering-Assistent eine Budgetposition wert ist. Es setzt eine Siemens-NX- oder Teamcenter-Umgebung voraus, der Rahmen trägt aber für jede tiefe, versionierte, herstellerspezifische Werkzeugkette.

Nutzen Sie es in dieser Reihenfolge. Lesen Sie Abschnitt 4 und entscheiden Sie, welche Verankerungsebenen Ihre Fragen brauchen — das allein schließt den größten Teil des Markts aus. Lesen Sie Abschnitt 5, damit Sie eine echte Retrieval-Architektur von einer Hülle unterscheiden können. Bewerten Sie Kandidaten mit Abschnitt 7. Spielen Sie das Protokoll aus Abschnitt 8 gegen die zwei Verbliebenen durch, mit der Fragenkatalog-Methode aus Abschnitt 9. Prüfen Sie Abschnitt 10, bevor Sie über Preise sprechen, und Abschnitt 11, während Sie darüber sprechen. Die Abschnitte 12 und 13 behandeln die Fehler vor und nach der Unterschrift.

Der Branchenkontext ist einen Absatz wert und keinen mehr. Adoption ist nicht das Problem: Im Work Trend Index 2024 von Microsoft und LinkedIn, einer Befragung von 31.000 Menschen in 31 Ländern, nutzten bereits 75 Prozent der Wissensarbeiter generative KI bei der Arbeit, und 78 Prozent davon brachten eigene Werkzeuge mit. Das Problem ist die Umsetzung. MIT NANDAs The GenAI Divide: State of AI in Business 2025 fand, dass 95 Prozent der Pilotprojekte in Unternehmen keinen messbaren Ertrag erbrachten, und der Enterprise AI Agent Report 2026 von OutSystems fand 94 Prozent der Organisationen, die wildwuchernde KI als wachsende Quelle von Komplexität, technischen Schulden und Sicherheitsrisiken sehen, während nur 12 Prozent eine zentrale Plattform betreiben. Die Lücke zwischen „Leute nutzen KI“ und „das Unternehmen hat etwas davon“ ist eine Evaluierungs- und Verankerungslücke.

§ 03 — Warum allgemeine Assistenten an Engineering-Fragen scheitern

Ein allgemeiner Assistent scheitert an einer Engineering-Frage auf eine bestimmte, vorhersagbare Weise: Er antwortet flüssig aus öffentlichem Text — und Engineering-Fragen sind aus öffentlichem Text meist nicht zu beantworten. Drei Fehlermuster wiederholen sich, und jedes hat eine andere Ursache.

Versionsdrift. Siemens liefert etwa zweimal im Jahr — NX 2606 und Teamcenter 2606 kamen beide im Juni 2026, letzteres am 12. Juni. Ein Assistent, der auf einem Korpus über ein Jahrzehnt von Releases trainiert ist, antwortet selbstbewusst mit einer Methode, die vor zwei Versionen entfernt wurde, und nichts in der Antwort verrät, zu welchem Release sie gehört. Der Ingenieur merkt es erst beim Kompilieren — oder schlimmer, zur Laufzeit an einem Produktivteil. Versionsdrift ist kein Modellqualitätsproblem, sondern ein Retrieval-Problem, und es wird behoben, indem Retrieval an ein Release gebunden wird, nicht indem man das Modell um mehr Sorgfalt bittet.

Erfundene API-Oberfläche. Das ist messbar und nicht anekdotisch. In einer arXiv-Studie von 2026, die unsere ChatGPT-Analyse zusammenfasst, erfinden Spitzenmodelle 4 bis 6 Prozent der Paket- und API-Namen, und die Rate steigt bei Nischen-APIs wie NXOpen, wo das öffentliche Trainingsmaterial dünn ist. Ein halluzinierter Methodenname ist schlimmer als keine Antwort: Er übersteht das Review, weil er exakt wie ein echter aussieht — korrekte Schreibweise, plausibler Namensraum, sinnvolle Argumente — und kostet einen Ingenieur eine Stunde, um ihn zu widerlegen. Mal ein Team gerechnet, ist der Assistent unterm Strich negativ.

Kein Zugriff auf das, was Ihnen gehört. Jede NX-Installation von einigem Alter trägt eine Schicht, die niemand außerhalb des Unternehmens kennt: eigene Makros von jemandem, der längst gegangen ist, VB.NET-Automatisierung aus drei NX-Versionen zuvor, hauseigene APIs ohne Dokumentation, Attribut- und Namenskonventionen, die nur in Köpfen existieren, und die Prüfregeln, die entscheiden, ob ein Teil freigebbar ist. Nichts davon ist öffentlich, also steckt nichts davon in einem Basismodell. Ein Assistent kann darin nicht verankert sein, solange es ihm nicht jemand bewusst gibt.

Nichts davon behebt ein besseres Modell. Alle drei werden durch Verankerung behoben — und Verankerung ist eine Architektur, kein Häkchen auf einer Funktionsliste.

§ 04 — Die vier Verankerungsebenen

Jeder Assistent am Markt deckt eine Teilmenge von vier Ebenen ab. Sie zu benennen macht aus einem vagen Vergleich eine kurze Checkliste — und erklärt, warum zwei gute Produkte in einer Demo völlig verschieden aussehen können.

Die Ebenen sind unabhängig voneinander, und genau darauf kommt es an. Ein PLM-Assistent kann auf Ebene 4 hervorragend sein und auf den Ebenen 2 und 3 nichts haben — Siemens’ eigener Teamcenter Copilot hat genau diesen Zuschnitt, absichtlich und nicht aus Versehen, weil er in Teamcenter-Datensätzen und Teamcenter-Dokumentation verankert ist. Ein code-orientierter Assistent kann auf 1 und 2 stark und auf 4 blind sein. Der Fehler ist nicht, das falsche Produkt zu wählen; der Fehler ist, nicht zu bemerken, welche Ebenen Ihre Fragen brauchen.

Eine Diagnose, die zwanzig Minuten dauert. Nehmen Sie die letzten zwanzig Engineering-Fragen, die Ihre Leute einander im Chat oder am Arbeitsplatz gestellt haben, und ordnen Sie jeder die Ebene zu, die sie beantwortet. Die Verteilung ist Ihre Anforderung — geschrieben von Ihrer eigenen Organisation statt von einem Anbieter. In den NX-Teams, mit denen wir arbeiten, dominieren die Ebenen 2 und 3, und Ebene 3 ist die, die fast niemand einplant. Ist Ihre Verteilung Ebene-4-lastig, kaufen Sie einen PLM-Assistenten und hören Sie auf, Vergleiche CAD-seitiger Produkte zu lesen.

§ 05 — Was hinter einem verankerten Assistenten tatsächlich steckt

Diesen Abschnitt gibt es, weil „wir nutzen RAG“ aufgehört hat, eine Information zu sein. Jeder Anbieter sagt das. Was sich unterscheidet, ist die Architektur darunter, und fünf konkrete Entscheidungen darin bestimmen, ob der Assistent bei Engineering-Inhalten vertrauenswürdig ist. Fragen Sie jede einzelne beim Namen ab.

Und das Antwortformat. Quellenangabe ist keine Deko. Eine Ingenieurin, die sieht, aus welchem Dokument und welchem Release eine Antwort stammt, prüft sie in Sekunden; wer das nicht sieht, muss von vorn prüfen — und dann hat der Assistent nichts gespart. Behandeln Sie Quellenangabe als funktionale Anforderung.

§ 06 — Die deterministische Grenze

Das ist eine Doktrin und kein Kriterium, und wir halten daran in jedem Projekt fest: Ein Assistent darf einem Menschen bei einer Entscheidung helfen und darf niemals selbst etwas entscheiden, das belastbar sein muss.

Warum das Aktualisierungsmodell schwerer wiegt als die Sprache, haben wir in NXOpen gegen Knowledge Fusionbeschrieben; für KI gilt dieselbe Logik. Was der Assistent sehr wohl tun soll, ist alles rund um diese Grenze: erklären, warum eine Prüfung fehlschlug, den Code entwerfen, der eine Regel umsetzt, die passende Richtlinie finden, dreißig Seiten Spezifikation zusammenfassen, einer neuen Ingenieurin erklären, was eine Named Reference ist. Das ist eine große und wertvolle Fläche, und nichts davon verlangt, dem Assistenten ein Urteil anzuvertrauen.

Fragen Sie jeden Anbieter, wo er diese Grenze zieht. Ein Anbieter, der sein Modell in einer Freigabeentscheidung haben will, hat entweder nicht über Prüfbarkeit nachgedacht oder hofft, dass Sie es nicht getan haben.

§ 07 — Zwölf bewertete Kriterien

Bewerten Sie jeden Kandidaten je Kriterium mit 0, 1 oder 2. Unter 16 von 24 ist für eine Engineering-Umgebung kein ernsthafter Kandidat; eine 0 bei einem als kritisch markierten Kriterium ist unabhängig von der Gesamtpunktzahl disqualifizierend.

§ 08 — Das Testprotokoll: zehn Fragen, ein Nachmittag

Spielen Sie diese gegen jeden Kandidaten durch, mit identischem Wortlaut, und schreiben Sie die Antworten auf. Lassen Sie nicht den Anbieter die Sitzung führen. Die Fragen 2 und 8 sind die, an denen die meisten Produkte scheitern — und die, die in einer Demo am häufigsten fehlen.

Notieren Sie bestanden, teilweise oder durchgefallen in Worten, mit je einem Satz Beleg. Bewerten Sie nicht allein mit Farben — drei Wochen später sind die Notizen das, womit Sie argumentieren, und ein Urteil muss als Wort lesbar sein.

§ 09 — Den eigenen Fragenkatalog aufbauen

Das Protokoll oben ist die anbieterunabhängige Hälfte. Die andere Hälfte sind zwanzig Fragen, die nur Ihre Organisation schreiben kann — und wie Sie sie schreiben, entscheidet darüber, ob die Evaluierung überhaupt etwas bedeutet.

Holen Sie sie aus der Realität, nicht aus der Vorstellung. Ziehen Sie die letzten zwanzig Engineering-Fragen aus dem Chatverlauf, der Helpdesk-Warteschlange oder dem Postfach einer Methodenverantwortlichen. Fragen, die Menschen tatsächlich gestellt haben, haben die richtige Schwierigkeitsverteilung; für eine Evaluierung erfundene Fragen sind systematisch zu leicht oder zu exotisch.

Ordnen Sie jeder ihre Verankerungsebene zu. Das ist die Diagnose aus Abschnitt 4 — und zugleich Ihr Anforderungsdokument.

Schreiben Sie die Musterantwort, bevor Sie irgendetwas laufen lassen. Halten Sie je Frage fest, was eine korrekte Antwort enthalten muss — die Kernfakten, nicht die Formulierung. Ohne vorab geschriebene Musterantwort wird die Bewertung zur Debatte über Tonfall, und die lauteste Person im Raum gewinnt.

Legen Sie fest, wer bewertet — und wie viele. Zwei unabhängige Bewertende auf denselben Antworten, Abweichungen werden besprochen und nicht gemittelt. Wenn Sie prüfen wollen, ob Ihre Bewertung überhaupt verlässlich ist: Die Forschungskonvention liegt bei einem gewichteten Kappa über etwa 0,6 zwischen zwei Bewertenden oder Krippendorffs Alpha bei mindestens 0,8 bei mehr als zweien.

Zum Bewerten per LLM. Es funktioniert besser, als die meisten erwarten — veröffentlichte Auswertungen sehen LLM-Judges bei 80 bis 90 Prozent Übereinstimmung mit menschlicher Bewertung zu einem Bruchteil der Kosten — und es ist das richtige Werkzeug für eine große Regressionssuite später. Für die Kaufentscheidung ist es das falsche, weil ein Judge die blinden Flecken dessen erbt, was er bewertet. Der Konsens der Literatur 2025 bis 2026: Judges ergänzen die menschliche Prüfung, sie ersetzen sie nicht, und Menschen schauen auf die markierten Fälle. Bei zwanzig Fragen und zwei Kandidaten bewerten Sie selbst.

Behalten Sie den Katalog. Er wird Ihre Regressionssuite. Jedes Release des Assistenten und jedes NX-Upgrade ist ein Anlass, ihn erneut laufen zu lassen — und genau so merken Sie, wenn ein Produkt still schlechter wird.

§ 10 — Betrieb, Sicherheit und Regulierung

Klären Sie diese Punkte vor dem Preis, denn jeder einzelne kann das Gespräch beenden. Zwei Punkte dieser Liste haben sich 2026 geändert und sind auch dann lesenswert, wenn Sie letztes Jahr schon evaluiert haben.

Wenn es innerhalb Ihrer Mauern laufen muss. On-Premise ist nicht mehr exotisch, und die Dimensionierungsrechnung ist öffentlich: Kalkulieren Sie etwa 0,5 GB VRAM je Milliarde Parameter bei 4-Bit-Quantisierung oder 2 GB bei 16 Bit, reservieren Sie weitere 20 bis 40 Prozent für den Key-Value-Cache und Aktivierungen, und validieren Sie bei Ihrer echten Parallelität statt an einem Einzelnutzer-Benchmark. Die Serving-Stacks — vLLM, NVIDIA NIM, SGLang, TensorRT-LLM — sind produktionsreif und nicht experimentell. Ein echt air-gapped Aufbau heißt: Modellgewichte, Embedding-Modell, Vektordatenbank und Orchestrierung liegen alle auf lokaler Hardware ohne ausgehenden Weg — machbar. Die ehrliche Einschränkung ist, dass die meisten Unternehmen die GPU-Kapazität nicht im Haus haben, weshalb ein hybrides Muster — Ihre Infrastruktur, Ihre Compute-Server über eine kontrollierte API erreicht — der übliche Mittelweg ist.

§ 11 — Was das über drei Jahre kostet

Wir drucken hier keinen Preis, weil jede Zahl, die wir erfinden, für Ihre Situation falsch wäre. Was wir geben können, ist die Struktur — damit Ihr Business Case die richtigen Zeilen enthält und nicht nur die sichtbare.

Zwei Beobachtungen aus unseren Projekten. Erstens ist die Lizenz selten der entscheidende Kostenblock, und sie zu optimieren, während man Aufnahme und Betrieb ignoriert, ist der Weg, auf dem ein günstiges Produkt zu einem teuren Programm wird. Zweitens: Wenn Sie On-Premise erwägen, ist der Break-even real, aber lastabhängig — veröffentlichte Richtwerte setzen Einstiegs-Hardware für privates Serving bei etwa zehntausend US-Dollar an, mit Gleichstand zu Cloud-API-Ausgaben binnen Monaten bei hohem Anfragevolumen und nie bei niedrigem. Rechnen Sie Ihr eigenes Volumen durch, bevor Sie sich festlegen.

Die Zeile, die wir in einer Budgetrunde am härtesten verteidigen würden, ist die Evaluierung. Ein Fragenkatalog, der je Release erneut läuft, kostet sehr wenig und ist der einzige Mechanismus, der Ihnen sagt, ob das Gekaufte noch das ist, was Sie haben.

§ 12 — Fünf Beschaffungsfehler

Anhand der Fragen des Anbieters evaluieren. Eine Demo ist ein kuratierter Bestfall. Bringen Sie Ihre eigenen zwanzig Fragen aus Abschnitt 9 mit, sonst bewerten Sie ein Verkaufsskript und kein Produkt.

Fähigkeiten ohne Vertragsbedingungen kaufen. Datenresidenz, Aufbewahrung, Haftungsfreistellung, Unterlagen zur EU-KI-Verordnung und Ausstieg gehören in dieselbe Entscheidung wie die Antwortqualität — nicht in eine spätere juristische Prüfung, die einen Blocker findet, wenn das Budget steht und der Fürsprecher seine Glaubwürdigkeit daran gehängt hat.

Keine Ausgangsmessung. Wenn Sie nicht sagen können, was eine Frage heute kostet — Minuten bis zur Antwort, Eskalationen pro Woche, wie oft ein Junior einen Senior unterbricht —, können Sie später nicht zeigen, was sich verändert hat. Das Verlängerungsgespräch wird dann Ansichtssache, und Ansichten verlieren gegen Tabellen.

Den Verweigerungstest auslassen. Ein Assistent, der nie „das weiß ich nicht“ sagt, ist nicht selbstsicher, sondern unverankert. Siehe Protokollfrage 2 — und behandeln Sie eine flüssige Antwort auf eine erfundene Methode als Ausschlusskriterium, nicht als Kuriosität.

Ebene 3 nicht einplanen. Die eigenen Makros, Standards und Konventionen in den Assistenten zu bekommen, ist meist der größte Posten — und der, der im Business Case fehlt. Dort liegt zugleich der größte Teil des Werts, was das Weglassen doppelt teuer macht: Das Projekt sieht günstig aus, liefert zu wenig und bekommt die Schuld der Technik zugeschoben.

§ 13 — Nach dem Kauf: der Teil, der über den Erfolg entscheidet

Die Beschaffung endet mit der Unterschrift; der Wert beginnt später. Drei Dinge trennen einen Rollout, der bleibt, von einem, der still nicht mehr genutzt wird.

Bringen Sie ihn dorthin, wo gearbeitet wird. Ein Assistent in einem separaten Browser-Tab konkurriert mit dem Termindruck der Ingenieurin und verliert. In der CAD- oder PLM-Sitzung wird er zum Reflex. Deshalb gehört die Sitzungsintegration zu den Arbeitsablauf-Kriterien und nicht auf eine Liste von Annehmlichkeiten.

Machen Sie das Onboarding zu einem Weg, nicht zu einem Projekt. Wenn ein neuer Anwendungsfall oder ein neuer Dokumentbestand jedes Mal das Plattformteam braucht, wird das Plattformteam zum Engpass — und ein Engpass ist von einer Richtlinie, die Nein sagt, nicht zu unterscheiden. Fragen Sie vor der Unterschrift, was eine Fachabteilung tun muss, um eigenes Material zu ergänzen.

Benennen Sie einen Verantwortlichen und einen Prüfrhythmus. Jemand verantwortet die Wissensbasis, jemand genehmigt neue Quellen, jemand lässt den Fragenkatalog je Release erneut laufen. Ohne diese drei Namen verfällt der Assistent: Der Bestand veraltet, die Antworten driften, und niemand merkt es, bis eine Ingenieurin ihm nicht mehr traut. Das ist dieselbe Lehre, die wir aus dem Aufbau einer unternehmensweiten GenAI-Plattform für einen großen Hersteller gezogen haben — die Architektur war nie der schwierige Teil, das Betriebsmodell schon.

§ 14 — Offenlegung: wo Vision4NX steht

Weiterführend: Unsere Besprechung dazu, warum ChatGPT bei Siemens NX falsch liegt beschreibt die Messung hinter Ebene 2.