Whitepaper NX-KI-Anforderungen: Nutzer, Daten, Betrieb

NX-KI-Anforderungen: Die Kurzfassung

NX-KI-Anforderungen sind das, was NX- und Teamcenter-Nutzer von einem Assistenten erwarten: Dokumentationsantworten je Version, Methodenrat nach Firmenregeln, Aktionen über NXOpen hinter einem Freigabeschritt (Gate), Hilfe beim Teamcenter-Customizing, ticketbasierte Fehlerbehandlung und souveräner Betrieb. Dieses Whitepaper ordnet 21 echte Nutzererwartungen Fähigkeiten zu und endet mit einer RFP-Checkliste, die inteliScience in Festpreis-Piloten einsetzt.

Frage	Antwort in einem Satz
Woher stammen die Anforderungen?	Die CAD-Administration eines DACH-Maschinenbauers hat ihre NX- und Teamcenter-Nutzer gefragt, was sie von einer “NX-KI” erwarten. Die 21 Antworten, anonymisiert, sind das Rückgrat dieses Dokuments.
Was wollen die Nutzer wirklich?	Sechs Dinge: Dokumentationsantworten, Methodenrat, Aktionen in NX, Administrationsarbeit, Hilfe beim Teamcenter-Customizing und ticketbasierte Fehlersuche. Zwei weitere sind Bedingungen: firmenspezifisches Wissen und souveräner Betrieb.
Was bedeutet “Training auf unseren Daten”?	In der Praxis Retrieval über Ihre Dokumente, Datenmodell-Exporte, Ticket-Historie und Ihren Code, plus Tool-Zugriff. Fine-Tuning ist die Ausnahme, nicht der Plan.
Was braucht es zur Umsetzung?	Drei Fähigkeiten: Wissen (NX-Dokumentation je Version plus Ihre Standards), Tools (NXOpen und Teamcenter SOA hinter einem Gate) und Gedächtnis für Ihre eigenen Artefakte. Plus ein Deployment, das zu Ihren Datenregeln passt.
Wo anfangen?	Ein Festpreis-Pilot auf einem Use Case mit vereinbarten Metriken, dann eine phasenweise Einführung: erst Antworten, dann Vorbereitung, dann Aktionen mit Gate.

---

1. Warum dieses Whitepaper: Eine Nutzerliste schlägt jede Feature-Matrix

Feature-Matrizen der Anbieter beschreiben, was ein Produkt kann. Eine Liste dessen, was Nutzer erwarten, beschreibt, was ein Produkt können muss. Die zweite Liste ist seltener, und wenn ein Kunde uns eine überreicht, ist sie mehr wert als jede Demo.

Die CAD- und PLM-Administration eines DACH-Maschinenbauers hat ihren NX- und Teamcenter-Nutzern eine Frage gestellt: Was erwartet ihr von einer NX-KI? Die Antworten kamen in sechs Blöcken zurück, von “Wie schalte ich in der Legacy-Skizze auf einer Zeichnung die automatischen Zwangsbedingungen aus” bis “Hardware, Installation, Betrieb, Kosten, Cloud, On-Premise”. Niemand wollte einen Chatbot. Alle wollten einen Kollegen, der NX kennt, die Firma kennt und auf Nachfrage auch etwas tun kann.

Wir veröffentlichen die Liste hier (paraphrasiert, ohne jedes identifizierende Detail), weil sie das beste Anforderungsdokument für eine Engineering-KI ist, das wir 2026 gesehen haben. Sie ist konkret, sie mischt triviale und schwere Fragen so, wie echte Arbeit es tut, und sie legt den Unterschied offen zwischen einem Modell, das über NX redet, und einem System, das in NX arbeitet. Siemens’ eigene Zahlen zeigen, wie viel Raum da ist: Designcenter 2606, das Juni-2026-Release, das NX in Designcenter umbenannt hat, liefert Designcenter Copilot mit, und Siemens berichtet, dass seine KI-Funktionen über 500.000 Mal im Monat genutzt werden. Diese Nutzungen sind dokumentationsgestützte Antworten. Die Nutzerliste unten verlangt mehr als das, und sie verlangt es nach Firmenregeln.

Die Zielgruppe dieses Whitepapers ist die Person, die die Anforderungen schreiben muss: der CAD-Manager, der PLM-Verantwortliche, der Engineering-IT-Architekt. Wenn Sie Anbieter bewerten statt zu spezifizieren, deckt unser Käufer-Framework zur Bewertung von Engineering-KI-Assistenten die Bewertungsseite ab; dieses Dokument deckt ab, wogegen bewertet wird.

2. Sechs Erwartungsklassen, abgeleitet aus der Liste

Liest man die 21 Erwartungen einmal, wirken sie wie eine zufällige Sammlung. Sortiert man sie danach, was eine korrekte Antwort voraussetzt, ergeben sich sechs Klassen. Die Klasse ist nützlicher als die Frage, weil sie sagt, welche Fähigkeit ein System braucht, bevor es irgendeine Frage dieser Art beantworten kann.

#	Was die Nutzer gefragt haben (paraphrasiert)	Klasse	Benötigte Fähigkeit
1	Automatische Erzeugung von Zwangsbedingungen in der Legacy-Skizze auf einer Zeichnung ein- oder ausschalten	Dokumentation	NX-Dokumentation für die installierte Version; Nachschlagen der Einstellung
2	Ein 3D-Teil aus einer Skizze und einem Skizzenpfad erzeugen (Sweep entlang eines Pfads)	Dokumentation	NX-Dokumentation für die installierte Version; Nachschlagen des Befehls
3	Wo und wie der Callout für eine Bauteiländerung auf der Zeichnung anzubringen ist	Methodik	Firmen-Zeichnungsstandard; NX-Dokumentation
4	Stabile, assoziative WAVE-Links erzeugen	Methodik	Firmen-Modellierungsrichtlinie; NX-Dokumentation
5	Defekte WAVE-Links reparieren	Methode, dann Aktion	NX-Dokumentation; Lese-Tool über die Baugruppe; Relink-Tool mit Gate
6	“Konstruiere mir eine Passfedernut vom Typ xy in diese Welle”	Aktion	Normtabelle; Lese-Tools; NXOpen-Build-Tool mit Gate
7	Parametrisches Feature “Freistich DIN 509 Form E”, gesteuert über den Wellendurchmesser	Administration	Normtabelle; Vorbereitung von Expression- und Feature-Vorlage; Validierung durch den Admin
8	Werkstoff xyz in die Werkstoffdatenbank aufnehmen	Administration	Vorbereitung des Bibliothekseintrags; Admin wendet an
9	Bohrung xyz in die Bohrungstabelle aufnehmen	Administration	Vorbereitung des Tabelleneintrags; Admin wendet an
10	In Rolle Standard, Anwendung Modeling, Registerkarte Home einen Button ergänzen, der Programm xy startet	Administration	Vorbereitung des Customizings; Admin wendet an
11	Das Programm meldet Fehler xy, was mache ich?	Support-Ticket	Ticket-Historie; Firmencode; Log-Auswertung
12	Wert x in den Voreinstellungen auf y setzen	Administration	NX-Dokumentation; Customer Defaults; mit Gate, wo geskriptet
13	Welche Voreinstellung aktiviert Funktion …?	Dokumentation	NX-Dokumentation für die installierte Version
14	NXOpen programming	Aktion (Code)	NXOpen-API-Referenz je Version; Firmen-Codebibliothek
15	Kann die KI auf unserem Teamcenter-Datenmodell, unseren Workflows und Prozessen trainiert werden?	Teamcenter-Customizing	BMIDE- und Workflow-Vorlagen-Exporte als Retrieval-Quellen
16	Hilfe beim Erstellen von Workflows und Kenntnis der Handler	Teamcenter-Customizing	Handler-Dokumentation; eigene Workflow-Vorlagen
17	Stylesheets bauen	Teamcenter-Customizing	Eigene Stylesheet-Exporte (XRT); Dokumentation
18	SOA-Programmierung	Teamcenter-Customizing	SOA-Dokumentation je Version; eigener Service-Code
19	Auf unserem Ticketsystem trainieren für KI-gestützte Fehlerbehandlung	Support-Ticket	Ticket-Export mit Lösungsfeld; Zugriffsregeln
20	Training auf unseren Daten, Programmen, Dokumentationen	Querschnitt: Wissen	Retrieval-Plattform mit Aktualisierungsrhythmus (Kapitel 4)
21	Hardware, Installation, Betrieb, Kosten, Cloud, On-Premise	Querschnitt: Betrieb	Deployment-Option und Kostenmodell (Kapitel 8 bis 10)

Drei Beobachtungen aus der Sortierung.

Die Dokumentationsklasse ist die kleinste und die einfachste, und es ist die, die Siemens mit Designcenter Copilot inzwischen gut abdeckt. Jeder Anbieter, der nur diese Klasse vorführt, führt den Teil des Problems vor, der bereits gelöst ist.

Die Methodenklasse ist die, in der Firmenregeln ins Spiel kommen. Wo ein Änderungs-Callout auf einer Zeichnung hingehört, steht nicht im NX-Handbuch; es steht in Ihrem Zeichnungsstandard. Wie man WAVE-Links stabil hält, ist zur Hälfte NX-Wissen (auf stabile, benannte Geometrie verlinken statt auf Flächen, die sich neu erzeugen) und zur Hälfte Ihre Modellierungsrichtlinie. Ein Assistent, der Methodenfragen allein aus öffentlichem Wissen beantwortet, wird technisch plausibel und für Sie falsch sein.

Die Administrations- und die Teamcenter-Klasse sind die, an die ein allgemeiner Chatbot überhaupt nicht herankommt, und sie stellen die Mehrheit der Liste: 12 von 21 Erwartungen. Sie brauchen die eigenen Artefakte des Unternehmens im Loop und eine klare Linie zwischen dem, was der Assistent vorbereitet, und dem, was der Administrator anwendet.

3. Das Fähigkeitsmodell: Wissen, Tools, Gedächtnis

Jede Erwartung auf der Liste lässt sich auf eine oder mehrere von drei Fähigkeiten zurückführen. Wir benennen sie schlicht, weil die Anbietersprache (“Copilot”, “Agent”, “trainiertes Modell”) verdeckt, welche davon gemeint ist.

Fähigkeit	Was es ist	Welche Erwartungen sie bedient	Was sie nie tun darf
Wissen	Retrieval über die NX- und Teamcenter-Dokumentation für die installierte Version plus Ihre Standards, Richtlinien und Vorlagen, mit einer Quellenangabe bei jeder Antwort	1, 2, 3, 4, 12, 13, 16, 18	Aus einer anderen NX-Version antworten; ohne Quelle antworten
Tools	Typisierte NXOpen- und Teamcenter-SOA-Operationen, die dem Assistenten bereitgestellt werden; Lese-Tools frei, Schreib-Tools hinter Vorschau, Bestätigung, Undo und Audit	5, 6, 7, 12, 14	Einen Schreibzugriff ohne Bestätigung ausführen; Freiform-Journale ausführen
Gedächtnis für Ihre Artefakte	Indexierte Exporte Ihres Datenmodells (BMIDE), Ihrer Workflow-Vorlagen, Stylesheets, Ticket-Historie sowie Ihres NXOpen- und SOA-Codes, mit gespiegelten Zugriffsregeln	7 bis 11, 15 bis 19	Ein Artefakt an einen Nutzer weitergeben, der es nicht lesen darf; stillschweigend veralten

Die drei sind keine optionalen Schichten, die man in beliebiger Reihenfolge nach und nach ergänzt. Wissen ohne Gedächtnis antwortet generisch. Tools ohne Wissen handeln, ohne Ihre Regeln zu kennen. Gedächtnis ohne Tools kann das Ticket vom letzten Jahr erklären, aber nicht prüfen, ob derselbe Fehler gerade auf Ihrem Bildschirm steht.

Unsere klare Empfehlung nach jedem Projekt dieser Art: Zuerst Wissen und Gedächtnis aufbauen, sie schreibgeschützt ausliefern und Tools erst ergänzen, wenn die Nutzer den Antworten vertrauen. Die Architektur, die die Tool-Schicht sicher macht (das Gate, Undo-Marken, Rollen-Scopes, Audit-Log), beschreibt unser NX MCP Whitepaper, und wir wiederholen sie hier nicht. Was dieses Dokument hinzufügt, ist die Anforderungssicht: welche Erwartung welche Fähigkeit braucht und was “auf unseren Daten trainiert” bedeuten muss, damit die Gedächtnisschicht funktioniert.

4. “Firmenspezifisches Training”, ehrlich erklärt

Erwartung 20 ist die, die jeder Kunde nennt und fast jeder Anbieter unscharf beantwortet: “die KI auf unseren Daten, Programmen und Dokumentationen trainieren”. Präzision zählt hier, weil die zwei Dinge, die die Formulierung bedeuten kann, sehr unterschiedliche Kosten, Aktualisierungsverhalten und Datenschutzprofile haben.

Retrieval bedeutet, dass das Modell so bleibt, wie es geliefert wurde, und Ihr Material indexiert wird. Zur Fragezeit findet das System die relevanten Passagen (aus einer Richtlinie, einem BMIDE-Export, einem Ticket, einer Quelldatei), übergibt sie dem Modell zusammen mit der Frage, und das Modell antwortet daraus mit einer Quellenangabe. Aktualisieren Sie ein Dokument, indexieren Sie es neu, und die nächste Antwort spiegelt die Änderung wider. Nichts über Ihr Unternehmen gelangt in die Gewichte des Modells.

Fine-Tuning bedeutet, die Gewichte des Modells an Beispielen aus Ihren Daten anzupassen. Es verändert, wie das Modell schreibt und welche Muster es bevorzugt. Es gibt dem Modell kein verlässliches Gedächtnis für konkrete Fakten, es kann keine Quelle nennen, es veraltet in dem Moment, in dem sich eine Norm ändert, und es setzt voraus, dass Ihre Daten als Trainingsmaterial verwendet werden, was genau das ist, was die meisten Datenschutzprüfungen verbieten.

Für die 21 Erwartungen auf der Liste deckt Retrieval jede ab, bei der es um Wissen geht. Wir raten von Fine-Tuning auf Kundendaten für Engineering-Assistenten ab, und wir tun es in unseren Deployments nicht. Der einzige Ort, an dem Fine-Tuning eine Diskussion verdient, ist eine enge, stabile Klassifikationsaufgabe mit hohem Volumen, und der Ticket-Routing-Fall in Kapitel 7 kommt dem auf der Liste am nächsten. Selbst dort ist Retrieval mit einem guten Ticket-Export das Erste, was man versucht.

Was Retrieval braucht, sind ein Korpus, ein Aktualisierungsrhythmus und Zugriffsregeln. Die Tabelle unten ist die Version, die wir mit Kunden in einem Pilot vereinbaren.

Quelle	Format, das wir einlesen	Aktualisierung	Zugriffsregel	Darf das Unternehmen nie verlassen
NX- und Teamcenter-Dokumentation	Herstellerdokumentation für das installierte Release, mit der Version getaggt	Je Release-Upgrade	Alle Nutzer	Nein (Herstellermaterial), aber Lizenzbedingungen gelten
Firmenstandards, Richtlinien, Zeichnungsregeln	PDF, Word, Wiki-Seiten	Bei Änderung, mindestens monatlich	ACL je Dokument	Ja
BMIDE-Datenmodell	Template-Export (XML)	Bei jedem BMIDE-Deployment	PLM-Admins, Entwickler	Ja
Workflow-Vorlagen, Handler-Argumente	Export aus Workflow Designer	Bei jeder Vorlagenänderung	PLM-Admins	Ja
Stylesheets (XRT)	Dataset-Export aus Teamcenter	Bei Änderung	PLM-Admins, Entwickler	Ja
NXOpen- und SOA-Code	Quell-Repository	Bei jedem Merge	Entwickler, CAD-Admins	Ja
Support-Tickets	Export mit den Feldern Problem, Lösung, Produkt, Version	Täglich	Support, CAD-Admins; personenbezogene Daten entfernt	Ja
Customer Defaults, Voreinstellungen	Exportierte Defaults-Dateien	Bei Änderung	CAD-Admins	Ja

Zwei Regeln entscheiden über diese Tabelle. Zugriffsregeln werden übernommen: Wer eine Quelle nicht öffnen darf, darf auch keine daraus abgeleitete Antwort erhalten, geprüft je Nutzer zur Fragezeit. Und jeder Korpus ist versionsgetaggt: Eine NX-2412-Dokumentation darf keine Designcenter-2606-Frage beantworten, und ein Stylesheet aus dem vorherigen Teamcenter-Release darf nicht als aktuell zitiert werden.

5. Die NX-Seite: Dokumentation, Firmenregeln oder NXOpen-Ausführung

Die Erwartungen 1 bis 14 sind NX-Fragen, und die nützliche Anforderung lautet nicht “NX-Fragen beantworten”, sondern “wissen, welche Art von Antwort jede Frage braucht”. Wir sortieren sie in drei Stufen, weil jede Stufe einen anderen Fehlermodus und einen anderen Abnahmetest hat.

Ebene	Fragen aus der Liste	Antwort kommt aus	Abnahmetest
Aus der Dokumentation beantwortbar	1 (Zwangsbedingungen in der Legacy-Skizze), 2 (Sweep entlang eines Pfads), 13 (welche Voreinstellung)	NX-Dokumentation für die installierte Version, mit Quellenangabe	Korrekt für das installierte Release; sagt es, wenn sich ein Befehl zwischen Releases geändert hat
Braucht Firmenregeln	3 (Platzierung des Änderungs-Callouts), 4 (stabile WAVE-Links), 12 (Werte der Voreinstellungen)	Ihr Zeichnungsstandard, Ihre Modellierungsrichtlinie und Ihre Customer Defaults, neben der NX-Dokumentation zitiert	Zitiert das Firmendokument, nicht eine generische Best Practice; lehnt ab, wenn keine Firmenregel existiert
Braucht NXOpen-Ausführung	5 (WAVE-Links reparieren), 6 (Passfedernut), 14 (NXOpen-Code)	Lese-Tools auf dem geöffneten Teil, dann ein Build-Tool mit Gate oder generierter Code, den der Nutzer prüft	Vorschau vor jeder Änderung; jeder Parameter nachvollziehbar; Undo-Marke und Audit-Eintrag beim Anwenden

Einige Anmerkungen zu den einzelnen Fragen, mit der Vorsicht, die der Auftrag verlangt: Wo wir ein NX-Verhalten nicht gegen Siemens-Material verifiziert haben, sagen wir, was der Assistent nachschlagen muss, statt die Antwort zu behaupten.

Frage 1 ist eine Einstellungsfrage mit Versionshaken. “Create Inferred Constraints” ist eine Skizzeneinstellung in NX, und Siemens-Community-Threads dokumentieren, dass NX sie bei großen Skizzen mit einem Performance-Hinweis automatisch deaktivieren kann. Eine gute Antwort nennt daher die Einstellung, gibt das Release an, für das sie gilt, und erwähnt das automatische Verhalten, weil der Nutzer, der fragt “Wie schalte ich das ein”, womöglich gegen ein NX kämpft, das es ausschaltet. Ein allgemeines Modell liefert die erste Hälfte und übersieht die zweite.

Frage 2 ist der sauberste Dokumentationsfall. NX hat für genau diese Konstruktion den Befehl Sweep Along Guide; der Assistent muss den Befehl in der Dokumentation für das installierte Release finden, Schnitt- und Führungsauswahl erklären und aufhören. Keine Firmenregel, keine Aktion.

Die Fragen 4 und 5 gehören zusammen und sind die beste Illustration der Stufen. Stabile WAVE-Links sind eine Methodenfrage: Die NX-Dokumentation erklärt den WAVE Geometry Linker, aber ob Ihr Unternehmen auf Körper, Flächen oder benannte Geometrie verlinkt und ob Links über Baugruppenebenen hinweg erlaubt sind, steht in Ihrer Modellierungsrichtlinie. Defekte Links sind eine Aktionsfrage: NX stellt über NXOpen einen Relinker bereit (die Klasse Assemblies.RelinkerBuilder kann WAVE-Links und Interpart-Expressions suchen, nach defekten filtern und sie auf eine neue Quelle umlinken). Ein Assistent, der die defekten Links in der geöffneten Baugruppe auflisten (Lese-Tool) und je Link ein Relink vorschlagen kann (Schreibzugriff mit Gate), macht aus zwei Stunden Handarbeit ein Review. Ein Assistent, der nur erklärt, was ein WAVE-Link ist, hat auf der falschen Stufe geantwortet.

Frage 6, die Passfedernut, ist die Aktionsanfrage, die sich jeder von der Liste merkt. Sie ist beantwortbar, aber nur, wenn der Assistent jeden Parameter aus einer Quelle zusammenträgt, bevor er irgendetwas vorschlägt: den Wellendurchmesser aus dem Modell, Breite und Tiefe der Passfedernut aus der Normtabelle für diesen Durchmesser, Länge und Position vom Nutzer und das zu verwendende Feature aus Ihrer Feature-Bibliothek.

Ein Tool-Aufruf ohne Herkunftsnachweis für jeden Parameter sollte die Anforderung nicht bestehen, nicht weil die Zahlen falsch sind, sondern weil niemand prüfen kann, ob sie stimmen.

Frage 14, NXOpen-Programmierung, ist die Stelle, an der allgemeine Modelle am sichtbarsten versagen: Sie erfinden API-Member. Die Anforderung ist versionsbewusstes API-Grounding, das heißt: Die NXOpen-Referenz für das installierte Release liegt im Retrieval-Korpus und Ihre eigene Codebibliothek in der Gedächtnisschicht, sodass Vorschläge Ihre Namenskonventionen und Ihre Wrapper verwenden. Der generierte Code wird von einem Entwickler geprüft wie jeder andere Pull Request; der Assistent ist ein schnellerer Kollege, kein Freigabeprozess.

6. Die Teamcenter-Seite: Was der Assistent vorbereitet, was beim Admin bleibt

Erwartung 15 stellt die Schlüsselfrage direkt: Teamcenter ist stark angepasst, kann die KI auf unserem Datenmodell, unseren Workflows und Prozessen trainiert werden? Ja, im Retrieval-Sinn von Kapitel 4, und es ist der wertvollste Korpus, den ein Teamcenter-Team überhaupt indexieren kann, weil nichts über ein angepasstes Teamcenter in irgendeiner öffentlichen Dokumentation steht.

Was der Assistent je Artefakt tun kann und was nicht, ist die Anforderung, die zählt, denn im Teamcenter-Customizing richtet ein übereifriger Assistent den größten Schaden an.

Artefakt	Der Assistent kann vorbereiten	Bleibt beim Administrator oder Entwickler
Datenmodell (BMIDE)	Ihre Item-Typen, Properties, LOVs und Relationen aus dem Template-Export erklären; eine Änderungsbeschreibung entwerfen; finden, wo eine Property verwendet wird	Jede BMIDE-Änderung, jedes Deployment und jedes Datenbank-Update
Workflow-Vorlagen und Handler	Aus dem Export erklären, was eine Vorlage tut; Zweck und Argumente von Handlern nachschlagen (Action-Handler führen Aktionen an einer Task aus, Rule-Handler entscheiden, ob eine Task weitergehen darf); ein Vorlagendesign und die Handler-Argumentliste entwerfen	Bau und Test der Vorlage in Workflow Designer; Freigabe
Stylesheets (XRT)	Ihre bestehenden Stylesheets lesen; das XML für einen neuen Abschnitt oder Property-Block in Ihren Konventionen vorschlagen; Rendering-Regeln erklären	Registrieren des Datasets; Test in den Clients; Freigabe
SOA-Services und ITK	Service-Aufrufe und Client-Code aus der SOA-Dokumentation für Ihr Release und Ihrer eigenen Service-Bibliothek vorschlagen; einen bestehenden Custom-Service erklären	Kompilieren, Deployen, Berechtigungsprüfung
Laufzeitaktionen (Workflow-Start, ECR-Entwurf, Property-Updates)	Die Aktion entwerfen, betroffene Items auflösen, die Vorschau zeigen	Bestätigung, ausgeführt in der eigenen Sitzung und mit den eigenen Berechtigungen des Nutzers

Die Linie ist konsistent: Der Assistent liest, erklärt und entwirft; ein Mensch mit der passenden Rolle wendet an. Für die Laufzeitaktionen in der letzten Zeile beschreibt unser Angebot Teamcenter AI den Assistenten, der unter den eigenen Berechtigungen des Nutzers mit einem Bestätigungs-Gate je Aktion ausführt, und dieselbe Regel gilt: Er genehmigt nie, gibt nie frei und ändert nie eine Workflow-Definition.

Erwartung 16 verdient eine eigene Anmerkung. “Kenntnis der Handler” ist der Wunsch nach etwas, das die Siemens-Dokumentation im Prinzip liefert, aber in der Praxis niemand liest: welcher Handler für welche Aufgabe existiert und welche Argumente er hat. Die Handler-Dokumentation für Ihr Release zu indexieren und, wichtiger noch, Ihre eigenen Vorlagen (die zeigen, wie Ihre Vorgänger sie kombiniert haben), gibt einem PLM-Admin die Referenz, die er sich seit Jahren wünscht. Das ist ein reiner Wissens-Use-Case, wird in der ersten Phase ausgeliefert und ist die Teamcenter-Aufgabe, mit der wir anfangen würden.

7. Support-Tickets als Wissensquelle

Erwartung 19 fragt, ob das Ticketsystem die KI für die Fehlerbehandlung trainieren kann. Es kann, als Retrieval-Korpus, und es ist die Quelle auf der Liste, die sich am schnellsten bezahlt macht, weil Tickets genau das Paar enthalten, das ein Assistent braucht: ein Symptom in den Worten des Nutzers und eine Lösung in denen des Administrators.

Drei Bedingungen entscheiden, ob ein Ticket-Korpus nützlich ist.

Das Lösungsfeld muss gefüllt sein. Ein Ticket, das mit “behoben” schließt, lehrt nichts. Messen Sie vor dem Indexieren den Anteil der Tickets mit einer substanziellen Lösung; ist er niedrig, beginnt der Pilot damit, dass die Administratoren einen Monat lang Lösungen ordentlich dokumentieren, was sich unabhängig von KI lohnt.

Personenbezogene Daten werden vor dem Indexieren entfernt. Namen der Melder, E-Mail-Adressen und Freitextfelder mit persönlichen Angaben werden im Export entfernt oder pseudonymisiert. Das ist sowohl eine Datenschutzanforderung als auch eine Qualitätsverbesserung, weil Namen für das Retrieval Rauschen sind.

Produkt- und Versionsfelder bleiben erhalten. Ein NXOpen-Fehler unter einem Release kann im nächsten eine andere Ursache haben; der Assistent muss sagen können: “Das passt zu drei Tickets, zwei davon auf Ihrem aktuellen Release”.

Sind diese Bedingungen erfüllt, wird Erwartung 11 (“Das Programm meldet Fehler xy, was mache ich?”) zu einer Retrieval-Frage über Tickets, Code und, wo der Assistent ein Lese-Tool hat, das Log der laufenden Sitzung. Die Antwort zitiert die Tickets, die sie gefunden hat. Was der Assistent nicht tun darf: das Ticket schließen, eine Konfiguration ändern oder eine Reparatur ohne das Bestätigungs-Gate ausführen; Fehlerbehandlung ist Rat, bis ein Mensch ihn anwendet.

Das läuft als POC. Was für die Produktion fehlt: DSGVO-Konformität, SSO/Entra, Skalierung, Monitoring, Betrieb. Wir schließen die Lücke von “läuft auf meinem Rechner” zu “läuft im Unternehmen”: Umfang eines NX-KI-Pilotprojekts zum Festpreis festlegen.

8. Deployment-Optionen: Cloud-API, EU-Region, Private, On-Premise, Air-gapped

Erwartung 21 zählt die Betriebsfragen in einem Atemzug auf: Hardware, Installation, Betrieb, Kosten, Cloud, On-Premise. Die erste Entscheidung ist, wo das Reasoning-Modell läuft, denn sie bestimmt alles Weitere. 2026 gibt es vier Optionen, und alle vier sind real; die Unterschiede liegen bei Datenresidenz, Modellwahl und der Frage, wer die Betriebslast trägt.

Ein Fakt verankert die Tabelle. Ein Frontier-Modell bedeutet nicht mehr zwangsläufig einen einzigen Anbieter-Endpunkt. Anthropic führt Claude Opus 5.5 (Modell-ID claude-opus-5-5, veröffentlicht am 22. September 2026) als verfügbar über die Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry und Claude Platform on AWS, und Amazon Bedrock dokumentiert regionale Endpunkte für die EU, die den Verkehr für Datenresidenz-Anforderungen durch eine bestimmte Geografie leiten, mit 10 Prozent Aufschlag gegenüber globalen Endpunkten. Auf der Open-Weight-Seite ist OpenAIs gpt-oss-120b unter Apache 2.0 veröffentlicht und für den Betrieb auf einer einzelnen 80-GB-GPU ausgelegt, und Mistral Small 3.1 (24B) ist Apache 2.0 mit etwa 55 GB VRAM bei bf16 oder einer einzelnen Consumer-GPU, wenn quantisiert. Souveräner Betrieb ist eine Konfigurationsentscheidung, kein Kompromiss bei der Leistungsfähigkeit.

Option	Datenresidenz	Modellwahl	Betriebsaufwand	Wer patcht was	Passt, wenn
Anbieter-Cloud-API	Bedingungen und Regionen des Anbieters	Frontier-Modelle, die neuesten zuerst	Am niedrigsten: kein Modellbetrieb	Anbieter patcht Modell und API; Sie patchen Assistent, Connector und Index	Unkritische Korpora; schnellster Start; Datenschutzprüfung akzeptiert die Bedingungen des Anbieters
Hyperscaler in einer EU-Region (Bedrock, Vertex AI, Foundry)	Ihr Tenant, EU-Region wählbar; regionale Endpunkte für garantiertes Routing	Frontier-Modelle mit kurzem Verzug gegenüber der Anbieter-API	Niedrig: Tenant-, IAM- und Netzwerk-Setup	Hyperscaler patcht die Modell-Runtime; Sie patchen Assistent, Connector und Index	Die meisten DACH-Hersteller mit bestehendem Cloud-Tenant und Residenzanforderung
Private Cloud oder On-Premise mit Open-Weight-Modellen	Ihre Infrastruktur, Ihr Netzwerk	Open-Weight-Modelle (gpt-oss, Mistral, andere)	Mittel bis hoch: GPU-Server, Inferenz-Runtime, Modell-Updates	Sie (oder Ihr Partner) patchen alles: Runtime, Modellversionen, Assistent, Index	Teiledaten oder Normen dürfen das Haus nicht verlassen; vorhandene GPU-Kapazität oder Bereitschaft, sie zu kaufen
Air-gapped	Keinerlei externe Verbindung	Nur Open-Weight-Modelle, Aktualisierung per physischem Transfer	Am höchsten: alles offline, einschließlich Dokumentations-Updates	Sie patchen alles, nach Zeitplan, von verifizierten Datenträgern	Verteidigung, exportkontrollierte Programme, IP-kritische Entwicklung

Unsere Position für das DACH-Maschinenbauer-Profil auf der Liste: Die Hyperscaler-Option in einer EU-Region ist der Standard, den man zuerst bewertet, weil sie das Frontier-Modell behält, die Residenz erfüllt und Connector, Index, Audit-Log und alle Teiledaten auf Kundenseite lässt. Volles On-Premise ist die richtige Antwort, wenn die Sicherheitsprüfung es sagt, nicht weil es sicherer klingt; es bringt Betriebspflichten mit, die eine CAD-Abteilung selten will. Air-gapped ist eine Kategorie für sich, und unsere Seite zu souveräner, Air-gapped Engineering-KI für die Verteidigung beschreibt, was sich ändert, wenn selbst Dokumentations-Updates auf einem Datenträger ankommen.

Welche Option auch immer, eine Anforderung ändert sich nicht: Der NX-seitige Connector, die Tool-Schicht, der Retrieval-Index und das Audit-Log laufen dort, wo die Teile sind. Das Modell kann entfernt sein; das Gate nicht. Das weitere Argument steht in unserem Beitrag zu souveräner agentischer KI in der europäischen Fertigung.

9. Hardware und Betrieb: Was die Dimensionierung treibt und wer was tut

Hardwarefragen bekommen häufiger erfundene Antworten als jedes andere Thema in diesem Feld. Wir geben keine. Was wir geben können, ist die Liste der Variablen, die die Dimensionierung treiben, damit Sie einen Anbieter nach Zahlen zu Ihren Werten fragen können, statt eine generische GPU-Anzahl zu akzeptieren.

Die Dimensionierung wird von fünf Variablen getrieben. Gleichzeitige Nutzer in der Spitzenstunde, nicht lizenzierte Nutzer, weil ein Assistent stoßweise genutzt wird. Kontext je Anfrage: wie viele abgerufene Chunks plus Tool-Ergebnisse mit jeder Frage mitreisen; eine Frage zum Teamcenter-Datenmodell trägt mehr als das Nachschlagen einer Voreinstellung. Größe des Retrieval-Index: Chunks mal Embedding-Dimension, was bei einem Dokumentenkorpus neben dem Modell selbst klein ist, die Ingestion-Rechenlast in der ersten Woche aber nicht. Modellgröße und Präzision, die die Speicheruntergrenze setzen; die beiden Apache-2.0-Modelle oben zeigen die Spanne von einer einzelnen Consumer-GPU (quantisiertes 24B) bis zu einer einzelnen 80-GB-Rechenzentrums-GPU (gpt-oss-120b). Und das Latenzziel: Ein Lese-Tool, das in NX in Gesprächsgeschwindigkeit antwortet, braucht Reserven, die ein nächtlicher Batch nicht braucht.

Bei den Cloud-Optionen ist Hardware nicht Ihr Problem, und Kosten werden zu Tokens (Kapitel 10). Bei On-Premise bitten Sie den Anbieter, gegen Ihre fünf Werte zu dimensionieren und Modell, Präzision und Inferenz-Runtime zu nennen, die die Zahl voraussetzt.

Installation und Betrieb trennen sich sauber, sobald die Komponenten benannt sind. Das ist die Tabelle, die wir in jedem Rollout vereinbaren, und sie ist auch eine nützliche RFP-Anlage.

Komponente	Installiert	Betreibt im Alltag	Patcht und aktualisiert	Besitzt die Daten
NX-seitiger Connector	Integrationspartner mit CAD-Admin	CAD-Admin	Integrationspartner, getestet je NX-Release	Kunde
Tool-Schicht (MCP-Server, Teamcenter-SOA-Client)	Integrationspartner	CAD/PLM-Admin	Integrationspartner; Kunde für Tool-Ergänzungen nach der Übergabe	Kunde
Retrieval-Index und Ingestion-Jobs	Integrationspartner	Engineering-IT	Engineering-IT (Jobs), Partner (Pipeline-Änderungen)	Kunde
Wissenskuratierung (Standards, Vorlagen, Ticket-Qualität)	CAD/PLM-Admin	CAD/PLM-Admin, Normenverantwortlicher	Laufend	Kunde
Modell-Runtime, Cloud	Hyperscaler oder Anbieter	Hyperscaler oder Anbieter	Hyperscaler oder Anbieter	Tenant-Daten des Kunden gemäß Vertrag
Modell-Runtime, On-Premise	Engineering-IT mit Partner	Engineering-IT	Engineering-IT (Runtime), Partner (Tests der Modellversionen)	Kunde
Identität und Zugriff (SSO, Rollen-Scopes)	Engineering-IT	Engineering-IT	Engineering-IT	Kunde
Audit-Log	Integrationspartner	CAD-Manager	Integrationspartner	Kunde

Zwei Zeilen werden in jedem ersten Budget unterschätzt. Wissenskuratierung ist eine Daueraufgabe der CAD-Administration, weil der Assistent veraltete Normen getreu zitiert und der Pilotmonat meist mehr veraltete Dokumente zutage fördert als das vorherige Prüfjahr. Und die Modell-Runtime-Zeile für On-Premise ist eine Engineering-IT-Pflicht mit eigenem Release-Rhythmus; wenn niemand in der Organisation diese Zeile will, wählen Sie eine Cloud-Option.

10. Das Kostenmodell, und warum ein Festpreis-Pilot an erster Stelle steht

Die Kosten auf der Liste (“Kosten, Cloud, On-Premise”) lassen sich nicht mit einer Zahl beantworten, bevor Deployment-Option und Umfang feststehen. Sie lassen sich mit einem Treibermodell beantworten, und genau das braucht ein Budgetverantwortlicher, um Angebote zu vergleichen.

Kostentreiber	Cloud-Optionen	On-Premise und Air-gapped	Was ihn bewegt
Modellzugang	Tokens je Anfrage, bepreist je Million Eingabe- und Ausgabe-Tokens	GPU-Hardware, Strom, Inferenz-Runtime; keine Gebühr je Token	Gleichzeitige Nutzer, Kontext je Anfrage, Antwortlänge
Hardware	Nichts über den Tenant hinaus	GPU-Server, dimensioniert in Kapitel 9	Modellgröße, Präzision, Latenzziel
Integration	NXOpen-Connector, Tool-Schicht, Teamcenter-SOA-Mapping, SSO	Dasselbe, plus Runtime-Setup	Anzahl der Tools, Custom-Features und gemappten Teamcenter-Objekttypen
Wissenskuratierung	Korpus-Aufbereitung, Mapping der Zugriffsregeln, Ticket-Bereinigung	Gleich	Korpusgröße und -qualität; Anzahl der Zugriffsgruppen
Operations	Index-Aktualisierung, Monitoring, Audit-Review	Dasselbe, plus Patchen von Modell und Runtime	Aktualisierungsrhythmus, Anzahl der Quellen, On-Premise-Pflichten
Lizenzen	NX- und Teamcenter-Lizenzen unverändert: Der Assistent läuft unter der eigenen Lizenz und den eigenen Berechtigungen des Nutzers	Gleich	Nichts, es sei denn, ein Anbieterprodukt bringt zusätzliche Lizenzen mit

Die ehrliche Beobachtung ist, dass Integration und Wissenskuratierung, nicht der Modellzugang, das erste Jahr in einer angepassten Teamcenter-Umgebung dominieren. Token-Rechnungen sind sichtbar und leicht zu diskutieren; die Wochen, die für das Mapping von BMIDE-Objekttypen und das Bereinigen von Ticket-Lösungen draufgehen, sind der Ort, wo das Geld hingeht, und sie sind auch der Ort, wo der Wert herkommt.

Deshalb bestehen wir auf einem Festpreis-Pilot als erstem Schritt, mit Umfang und Metriken, die vereinbart sind, bevor irgendetwas gebaut wird. Jeder Assistent in unserer NX-KI-Assistenten-Familie hat einen Proof of Concept mit festem Umfang, und der NX Proof-of-Value Sprint auf der Pilot-Angebotsseite kostet €12,900 fest für einen mit Ihren Stakeholdern ausgewählten Use Case: ein lauffähiger Prototyp, in zwei bis drei Wochen an vereinbarten Metriken gemessen, vollständig auf das Folgeprojekt angerechnet, wobei jede Lösung vollständig On-Premise laufen kann, einschließlich Air-gapped.

Was ein Pilot messen muss, ist wichtiger als das, was er kostet. Vier Zahlen, auf Ihren Fragen und Ihren Teilen:

1. Rate belegter Antworten. Anteil der Antworten mit korrekter Quellenangabe auf Ihr Material oder die Herstellerdokumentation für das installierte Release. Nehmen Sie absichtlich unbeantwortbare Fragen auf; “nicht in Ihrem Material” ist eine korrekte Antwort.
2. Versionsgenauigkeit. Anteil der Dokumentationsantworten, die für das installierte NX- oder Teamcenter-Release korrekt sind, nicht für ein benachbartes.
3. Akzeptanz der Vorbereitung. Für Administrations- und Teamcenter-Entwürfe der Anteil, den der Administrator ohne Nacharbeit übernimmt, und die gesparten Minuten je übernommenem Entwurf.
4. Gate-Verhalten. Für jede Aktionsstufe im Umfang der Anteil der Vorschauen, die akzeptiert, bearbeitet und verworfen wurden, sowie die Rollback-Rate nach Bestätigung.

Ein Pilot, der statt dieser vier Zahlen Nutzungszählungen berichtet, wurde nicht evaluiert.

11. Anforderungs-Checkliste für ein RFP

Die Liste unten ist so geschrieben, dass sie in ein Anforderungsdokument eingefügt werden kann. Jeder Punkt ist prüfbar; mehrere sind die direkte Übersetzung einer Nutzererwartung aus Kapitel 2.

1. Der Assistent beantwortet NX- und Teamcenter-Dokumentationsfragen für das installierte Release und nennt das Release, für das er geantwortet hat.
2. Jede Antwort trägt eine Quellenangabe auf das Dokument, Ticket, die Codedatei oder die Norm, aus der sie abgeleitet wurde; Antworten ohne Quelle werden abgelehnt, nicht improvisiert.
3. Firmenstandards, Richtlinien und Zeichnungsregeln sind indexiert und haben Vorrang vor generischer Best Practice, wenn sie im Widerspruch stehen.
4. Zugriffsregeln aus den Quellsystemen werden je Nutzer zur Fragezeit ausgewertet; kein Nutzer erhält Antworten, die aus Material abgeleitet sind, das er nicht öffnen darf.
5. Jeder Korpus ist mit der Produktversion getaggt, zu der er gehört; Korpora verschiedener Releases werden nie in einer Antwort vermischt.
6. Der Aktualisierungsrhythmus je Quelle ist dokumentiert (Release, bei Änderung, täglich), und die Aktualisierung ist inkrementell.
7. Keine Kundendaten werden zum Trainieren oder Fine-Tuning irgendeines Modells verwendet, und keine Prompts oder Antworten werden von einem Dritten über den vertraglich vereinbarten Zeitraum hinaus aufbewahrt.
8. Das Teamcenter-Datenmodell (BMIDE-Export), Workflow-Vorlagen, Handler-Dokumentation und Stylesheets können indexiert und erklärt werden; der Assistent bereitet Änderungen vor, deployt sie aber nicht.
9. Support-Tickets können indexiert werden, mit entfernten personenbezogenen Daten und erhaltenen Feldern für Lösung, Produkt und Version.
10. Lese-Tools über das geöffnete NX-Teil und die Teamcenter-Sitzung sind ohne Bestätigung verfügbar und sind die erste ausgelieferte Stufe.
11. Jeder Schreibzugriff auf NX oder Teamcenter wird als Vorschau gezeigt, erfordert eine explizite Bestätigung, setzt eine Undo-Marke oder Gleichwertiges und wird mit Nutzer, Zeitstempel, Tool, Parametern und Ergebnis protokolliert.
12. Jeder Parameter in einer vorgeschlagenen Aktion trägt einen Herkunftsnachweis (Modell-Lesung, Normtabelle, Firmenregel oder Nutzereingabe).
13. Keine Ausführung von Freiform-Journalen oder Skripten durch den Assistenten; Schreiboperationen sind typisierte Tools mit technischen Einheiten.
14. Aktionen in Teamcenter laufen in der eigenen Sitzung und mit den eigenen Berechtigungen des anfragenden Nutzers; der Assistent hat kein privilegiertes Service-Konto und genehmigt oder gibt nie frei.
15. Rollenbasierter Tool-Zugriff wird über den Identity Provider des Unternehmens (SSO) durchgesetzt.
16. Die Deployment-Option (Anbieter-API, Hyperscaler in EU-Region, On-Premise, Air-gapped) ist wählbar, und Connector, Tool-Schicht, Index und Audit-Log laufen in jeder Option auf der Infrastruktur des Kunden.
17. Das Modell ist austauschbar, ohne Tool-Schicht oder Index neu zu schreiben (protokollbasierte Integration, modellagnostisch).
18. Die Dimensionierung für den On-Premise-Betrieb wird gegen die gleichzeitigen Nutzer, den Kontext je Anfrage, die Indexgröße und das Latenzziel des Kunden angegeben, mit Nennung von angenommenem Modell und Präzision.
19. Die Verantwortlichkeiten für Installation, Betrieb und Patching sind vor Vertragsunterzeichnung je Komponente aufgelistet.
20. Der Pilot hat Festpreis und festen Umfang, berichtet die vier Metriken aus Kapitel 10 auf den eigenen Fragen des Kunden, und sein Preis wird auf den Rollout angerechnet.

Punkt 2 allein eliminiert die meisten Demos. Punkt 12 ist der, für den CAD-Manager uns später danken.

12. Einführungspfad in Phasen

Die Erwartungen der Liste lassen sich in einer Reihenfolge liefern, die Vertrauen aufbaut, bevor sie Risiko aufbaut. Die Reihenfolge ist in jeder Deployment-Option dieselbe; nur die Phasenlängen ändern sich mit der Korpusqualität.

Phase	Umfang aus der Liste	Liefert	Abschlusskriterium
0. Korpus und Regeln (Wochen 1 bis 2)	Erwartungen 20, 21	Deployment-Option gewählt; Standards, Dokumentation und ein Teamcenter-Export mit Zugriffsregeln indexiert; Pilot-Metriken vereinbart	Korpus baut reproduzierbar; Zugriffs-Mapping von der IT verifiziert
1. Antworten (Wochen 2 bis 5)	1, 2, 3, 4, 12, 13, 15, 16, 17, 18	Schreibgeschützter Assistent, der NX- und Teamcenter-Fragen mit Quellenangaben beantwortet, für eine Pilotgruppe	Rate belegter Antworten und Versionsgenauigkeit an den echten Fragen des Teams gemessen
2. Vorbereitung (Wochen 4 bis 8)	7, 8, 9, 10, 11, 19	Administrations- und Teamcenter-Entwürfe (Feature-Spezifikationen, Bibliothekseinträge, Customizing-Schritte, Handler-Listen, Stylesheet-Blöcke); Tickets indexiert	Akzeptanzrate der Vorbereitung mit den Administratoren gemessen
3. Lese-Tools (Wochen 6 bis 9)	5 (defekte Links auflisten), 14 (API-Grounding)	Assistent sieht das geöffnete Teil und die Teamcenter-Sitzung; NXOpen-Vorschläge aus Ihrer Bibliothek	Konstrukteure nutzen Lese-Tools täglich; bisher null Schreibzugriffe
4. Aktionen mit Gate (ab Woche 9)	5 (Relink), 6 (Passfedernut), 12 (geskriptete Defaults), Teamcenter-Laufzeitaktionen	Eine enge Schreibstufe nach der anderen, jede mit Vorschau, Bestätigung, Undo und Audit	Gate-Verhalten je Tool gemessen; CAD-Manager zeichnet den Rollout ab
5. Rollout	Alle	Rollen-Scopes, SSO, Monitoring, Aktualisierungsjobs an die Engineering-IT übergeben; Kuratierungspflichten bei der CAD-Administration	Verantwortlichkeitstabelle (Kapitel 9) unterzeichnet

Phase 1 ist die, in der die Nutzer auf der Liste das meiste von dem bekommen, was sie verlangt haben, und sie trägt kein Schreibrisiko. Phase 4 ist die, in der die Passfedernut konstruiert wird, und sie sollte erst kommen, wenn die Phasen 1 bis 3 sie verdient haben. Schlägt ein Anbieter vor, bei Phase 4 zu starten, wird die Demo beeindruckend sein, und der CAD-Manager wird sie nicht abzeichnen.

Häufig gestellte Fragen

Welche NX-KI-Anforderungen sollte ein Engineering-Team in ein RFP aufnehmen?

Versionsgenaue Dokumentationsantworten mit Quellenangaben, indexierte Firmenstandards mit nutzerbezogenen Zugriffsregeln, Retrieval über Teamcenter-Exporte und Tickets, Lese-Tools vor Schreib-Tools, ein Gate mit Vorschau und Bestätigung samt Undo und Audit bei jedem Schreibzugriff, Herkunftsnachweis für jeden Parameter, Ausführung unter den eigenen Berechtigungen des Nutzers, eine wählbare Deployment-Option mit Connector und Index auf Ihrer Infrastruktur sowie ein Festpreis-Pilot mit vereinbarten Metriken. Kapitel 11 listet alle zwanzig Punkte in kopierfähiger Form.

Kann eine KI auf unserer NX-Dokumentation, unserem Teamcenter-Datenmodell und unserem Ticketsystem trainiert werden?

Ja, in dem Sinn, der zählt: Ihre Dokumentation, BMIDE-Exporte, Workflow-Vorlagen, Stylesheets, Ihr Code und Ihre Tickets werden indexiert, und der Assistent antwortet daraus mit Quellenangaben. Das ist Retrieval, kein Fine-Tuning. Fine-Tuning verändert Modellgewichte, kann keine Quellen nennen, veraltet und braucht Ihre Daten als Trainingsmaterial; wir setzen es auf Kundendaten nicht ein. Retrieval deckt jede Wissenserwartung auf der Liste ab und aktualisiert sich, sobald sich ein Dokument ändert.

Was kostet ein NX-KI-Pilot?

Unser NX Proof-of-Value Sprint kostet €12,900 fest für einen Use Case: ein lauffähiger Prototyp, in zwei bis drei Wochen an vereinbarten Metriken gemessen, vollständig auf das Folgeprojekt angerechnet. Die Rollout-Kosten hängen danach vor allem von Integrationstiefe und Wissenskuratierung ab, nicht vom Modellzugang.

Cloud oder On-Premise für eine NX-KI: Was ist besser?

Für die meisten DACH-Hersteller ist ein Hyperscaler-Tenant in einer EU-Region die erste Option zur Bewertung: Sie behält ein aktuelles Frontier-Modell wie Claude Opus 5.5, erfüllt die Datenresidenz über regionale Endpunkte und lässt Connector, Index, Teiledaten und Audit-Log auf Ihrer Seite. On-Premise mit einem Apache-2.0-Open-Weight-Modell wie gpt-oss-120b ist richtig, wenn Teiledaten oder Normen das Haus nicht verlassen dürfen, und holt Modell- und Runtime-Betrieb in die Engineering-IT. Air-gapped ist eine eigene Kategorie für Verteidigung und exportkontrollierte Arbeit.

Kann der Assistent unsere NX-Modelle oder Teamcenter-Daten eigenständig ändern?

Nein. Lese-Tools sind frei; jeder Schreibzugriff wird als Vorschau gezeigt, erst nach expliziter Bestätigung angewendet, in eine Undo-Marke eingebettet und protokolliert. In Teamcenter laufen Aktionen in der eigenen Sitzung und mit den eigenen Berechtigungen des anfragenden Nutzers, und der Assistent genehmigt nie, gibt nie frei und ändert nie eine Workflow-Definition oder das Datenmodell. Was Sie in Teamcenter nicht dürfen, kann er nicht für Sie tun.

Nächster Schritt

Schicken Sie uns Ihre eigene Version der Liste: die Fragen, die Ihre NX- und Teamcenter-Nutzer einem Assistenten als Erstes stellen würden. Wir ordnen jede einer Klasse und einer Fähigkeit zu, sagen Ihnen, welche ein Pilot in drei Wochen beantworten kann und welche zuerst bereinigte Standards bei Ihnen brauchen.

Sprechen Sie mit unseren Ingenieuren über Ihre NX-KI-Anforderungen

Verwandte Themen

• NX-KI-Pilotprojekt zum Festpreis
• Case Study: Privater KI-Wissensassistent
• Wo Siemens’ Teamcenter Copilot hilft und wo er aufhört

Quellen

• Siemens, “Designcenter is for everyone, June 2026 release”, blogs.sw.siemens.com, 23. Juni 2026 (Designcenter 2606, Designcenter Copilot, KI-Funktionen über 500.000 Mal im Monat genutzt), abgerufen am 24. September 2026
• Anthropic, “Models overview” und “Claude Opus 5.5” (Modell-ID claude-opus-5-5, veröffentlicht am 22. September 2026; Verfügbarkeit über Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry, Claude Platform on AWS), platform.claude.com, abgerufen am 24. September 2026
• Anthropic, “Claude on Amazon Bedrock” (globale versus regionale Endpunkte, regionale EU-Endpunkte für Datenresidenz, 10 Prozent Aufschlag), platform.claude.com, abgerufen am 24. September 2026
• OpenAI, gpt-oss-120b model card (Apache 2.0, 117B Parameter mit 5.1B aktiv, ausgelegt für eine einzelne 80-GB-GPU), huggingface.co, abgerufen am 24. September 2026
• Mistral AI, Mistral Small 3.1 24B Instruct model card (Apache 2.0, etwa 55 GB VRAM bei bf16, eine einzelne RTX 4090 oder ein 32-GB-Mac, wenn quantisiert), huggingface.co, abgerufen am 24. September 2026
• Siemens, NXOpen .NET Reference Guide, NXOpen.Assemblies.RelinkerBuilder (WAVE-Links und Interpart-Expressions suchen und neu verlinken, Filter für defekte Links, Option zum Trennen von WAVE-Links), docs.sw.siemens.com, NX-1926-API-Referenz, abgerufen am 24. September 2026
• Siemens Community, “How do I stop NX from automatically disabling Create Inferred Constraints on a sketch?” und “Sweep along guide question”, community.sw.siemens.com, abgerufen am 24. September 2026
• Siemens, Teamcenter Gateway generic configuration guide, “Workflow rule handler documentation” (Rule-Handler geben EPM_go oder EPM_nogo zurück), docs.plm.automation.siemens.com, und Siemens Community, “Workflow handlers” Thread, abgerufen am 24. September 2026
• DIN 509 (Freistichformen E, F, G, H) und DIN 6885-1 (Passfedern und Passfedernuten), als Normen referenziert; Tabellenwerte sind dem lizenzierten Normtext für die installierte Ausgabe zu entnehmen
• inteliScience, Angebotsseite “NX AI Pilot Project” (NX Proof-of-Value Sprint, €12,900 fest, 2 bis 3 Wochen, vollständig angerechnet), Service-Hub “NX AI Assistants & Chatbots”, “NX MCP Whitepaper” (Gate-Architektur), “Engineering AI Assistant Evaluation” (Käufer-Framework), inteliscience.net, 2026