Engineering-Helpdesk-KI: trainiert auf Ihren CAD/PLM-Tickets

Engineering-Helpdesk-KI: die Kurzfassung

Engineering-Helpdesk-KI ist ein Assistent, der gelöste NX-, Teamcenter- und NXOpen-Tickets abruft, je neuem Ticket eine belegte Erstantwort vorschlägt und die Antwort für den CAD-Administrator vorformuliert. Es ist Retrieval über pseudonymisierte Ticket-Historie, kein per Fine-Tuning trainiertes Modell. inteliScience, Spezialisten für Siemens NX und Teamcenter, Nearshore aus Rumänien, baut sie On-Premise oder in einer EU-Cloud.

Das Problem: Dieselben NX- und Teamcenter-Fehler werden jedes Quartal neu gelöst

Kann eine KI auf unser Ticketsystem trainiert werden, um NX- und Teamcenter-Fehler zu behandeln? Diese Frage kam sinngemäß von den Anwendern eines NX-Kunden und wurde von der CAD-Administration eines Maschinenbauers aus der DACH-Region gesammelt. Es ist die praktischste Frage auf ihrer Liste, denn das gewünschte Wissen existiert bereits. Es steckt in geschlossenen Tickets, die niemand liest.

Eine CAD/PLM-Helpdesk-Queue hat eine Form. Eine Workstation wird neu aufgesetzt, und NX findet seinen Lizenzserver nicht. Ein Teamcenter-Login scheitert nach einer Passwortänderung. Ein NXOpen-Tool, das jahrelang lief, bleibt nach dem Upgrade auf Designcenter NX 2606, veröffentlicht im Juni 2026 [6], stehen. Jedes davon wurde schon einmal gelöst, von denselben zwei Administratoren, und die Lösung wanderte in ein Ticket, das geschlossen, archiviert und nie wieder geöffnet wurde. Im nächsten Quartal kommt das Ticket mit einem anderen Anfragenden zurück.

Ticket-Deflection (Ticket-Vermeidung) ist der am wenigsten glamouröse und am besten messbare Einsatz eines Engineering-Wissensassistenten, und dort würden wir anfangen. Besteht die Queue zu 40 Prozent aus Wiederholungen, gibt ein Assistent, der Wiederholungen aus der Historie beantwortet, diese Stunden den Administratoren zurück, die zusätzlich Ihre Rotation für Teamcenter Support und Managed Services stemmen. Was folgt, zeigt, wie Sie ihn ohne die zwei Fehler bauen, die wir am häufigsten sehen: ein Modell auf Roh-Tickets zu fine-tunen und Tickets zu indexieren, in denen die Namen noch stehen.

Was ein Ticket enthält und was meist fehlt

Ein geschlossenes Ticket ist ein Symptom, eine Umgebung und eine Lösung, unter Zeitdruck von zwei verschiedenen Personen geschrieben. Retrieval arbeitet auf dem Symptom; die Antwort kommt aus der Lösung; die Umgebung entscheidet, ob die Antwort noch gilt. Bevor irgendjemand etwas baut: Exportieren Sie 200 geschlossene Tickets und prüfen Sie sie gegen diese Tabelle.

Feld	Meist vorhanden	Meist fehlend	Warum es für das Retrieval zählt
Symptom (Betreff, Beschreibung, eingefügter Fehlertext)	Ja, in den Worten des Anfragenden	Der exakte Dialogtext; oft ein Screenshot statt Text	Ein neues Ticket sind die Worte eines anderen Anfragenden für dasselbe Symptom; genau das wird gematcht
Umgebung (NX- oder Teamcenter-Version, Betriebssystem, Rolle, Standort, Lizenztyp)	Teilweise, im Freitext vergraben	Version als strukturiertes Feld	Eine für NX 2312 gültige Antwort muss für Designcenter NX 2606 nicht mehr gelten
Ursache (Root Cause)	Selten dokumentiert	Die eine Zeile, die aus einem Fix Wissen macht	Ohne sie wirken zwei Tickets mit demselben Fix zusammenhanglos
Lösung	In geschlossenen Tickets, sofern der Admin sie geschrieben hat	“Telefonisch gelöst”, “behoben”, “siehe Mail”	Der Assistent kann nur vorschlagen, was festgehalten wurde
Link auf KB-Artikel oder Known-Error-Eintrag	Selten	Der Verweis, der die Antwort wartbar macht	Erlaubt dem Assistenten, den Artikel statt eines Tickets zu zitieren
Personenbezogene Daten	Immer: Name des Anfragenden, E-Mail, Hostname, Benutzername, manchmal ein Screenshot mit einem Namen darauf	Hier fehlt nichts, und genau das ist das Problem	Müssen vor dem Indexieren entfernt oder pseudonymisiert werden

Zwei Befunde aus diesem Audit entscheiden das Projekt. Tragen weniger als die Hälfte der geschlossenen Tickets eine brauchbare Lösung, ist das erste Deliverable eine Abschlussvorlage mit Pflichtfeld für die Lösung, kein Assistent. Steckt der Großteil des Fehlertexts in Screenshots, braucht die Pipeline zuerst OCR auf Anhängen. Beides lernt man jetzt günstiger als in Woche fünf eines Piloten.

“Auf Tickets trainiert” heißt Retrieval, nicht Fine-Tuning

Anwender sagen “trainiert die KI auf unseren Tickets”. Was sie brauchen, ist ein Assistent, der zu einem neuen Ticket die gelösten Tickets findet, die dasselbe Symptom beschreiben, und seine Antwort daraus aufbaut, mit Angabe des Quelltickets. Das ist Retrieval-Augmented Generation (RAG), und wir raten davon ab, für diese Aufgabe ein Modell auf Tickettext zu fine-tunen.

Fine-Tuning ändert, wie ein Modell schreibt; es gibt ihm keine verlässliche Erinnerung daran, welches Ticket was gesagt hat, und es kann keine Ticket-ID zitieren. Retrieval hält das Wissen außerhalb des Modells, in einem Index, den Sie einsehen, korrigieren und aus dem Sie löschen können. AWS’ eigener Erklärtext formuliert es genauso: RAG “erweitert die ohnehin leistungsfähigen Fähigkeiten von LLMs auf spezifische Domänen oder die interne Wissensbasis einer Organisation, ganz ohne das Modell neu trainieren zu müssen”, und “die Ausgabe kann Zitate oder Verweise auf Quellen enthalten” [1]. Die viel zitierte Übersichtsarbeit von Gao et al. listet genau die Fehlermodi, die Ticketdaten auslösen, Halluzination, veraltetes Wissen und nicht nachvollziehbare Schlussfolgerungen, und beschreibt RAG als den Ansatz, der “kontinuierliche Wissensaktualisierungen und die Integration domänenspezifischer Informationen” erlaubt [2]. Tickets werden täglich aktualisiert. Ein per Fine-Tuning trainiertes Modell ist ein Snapshot.

Es gibt einen zweiten Grund, und er betrifft den Datenschutz. Ein auf Roh-Tickets fine-getuntes Modell hat Namen aufgesogen, und für einen Namen in Modellgewichten gibt es keine Löschoperation. Ein Index hat eine.

Das Modell selbst ist die am wenigsten interessante Entscheidung. Aktuelle Claude-Modelle wie claude-opus-5-5, veröffentlicht am 22. September 2026 [3], oder ein Open-Weight-Modell auf Ihren eigenen GPUs schreiben beide eine gute Erstantwort aus drei gut gewählten Tickets. Was einen nützlichen Assistenten von einer Demo unterscheidet, sind die Retrieval-Schicht und die Evaluation darum herum, weshalb unser Framework zur Bewertung von Engineering-KI-Assistenten mehr Seiten auf Grounding-Schichten als auf Modelle verwendet.

Die Pipeline: vom Ticket-Export zum angebundenen Assistenten

Der Aufbau des Korpus sind sieben Schritte, und die Schritte zwei bis vier kosten die meiste Zeit. Jeder Schritt läuft dort, wo die Ticketdaten liegen.

Exportieren. Ziehen Sie geschlossene Tickets mit Lösung, Statushistorie und Anhängen aus dem Ticket-Tool (Jira Service Management, ServiceNow, OTRS oder ein Export aus dem Herstellerportal), einschließlich der Felder Produkt und Version, auch wo sie leer sind.
Bereinigen. Tickets ohne Lösung verwerfen, Signaturen, zitierte E-Mail-Verläufe und Auto-Antworten entfernen und Fehlertext per OCR aus Screenshots holen.
Pseudonymisieren. Namen, E-Mail-Adressen, Benutzernamen und Hostnamen durch Platzhalter ersetzen, bevor der Text die Ticketdatenbank verlässt; die Zuordnung im Ticketsystem behalten, nicht im Index.
Je Ticket chunken. Ein Ticket ist eine Retrieval-Einheit, Symptom und Lösung bleiben zusammen. Chunks fester Größe trennen die Frage von ihrer Antwort, das Eine, was nicht passieren darf.
Lösungen verknüpfen. Tickets gruppieren, die mit demselben Fix endeten, den KB-Artikel oder Known-Error-Eintrag anhängen, wo vorhanden, und je Gruppe ein kanonisches Ticket markieren.
Indexieren. Den Symptomtext einbetten, Produkt, Version, Datum und Lösungsgruppe als Metadaten speichern und zur Abfragezeit darauf filtern, damit eine NX-2312-Antwort nicht für eine 2606-Umgebung angeboten wird.
An das Ticket-Tool anbinden. Ein Webhook bei Ticketerstellung schickt das neue Ticket an den Assistenten, der seinen Vorschlag als internen Kommentar zurückschreibt. Keine automatische Antwort an den Anfragenden.

Die Schritte zwei und drei können als Skript beginnen. Dieses liest eine Ticket-CSV, entfernt E-Mail-Adressen und Login-IDs mit regulären Ausdrücken, behält nur geschlossene Tickets mit schriftlicher Lösung und gruppiert sie nach Lösung. Nur Standardbibliothek; passen Sie das Login-Muster an Ihre Namenskonvention an.

import csv
import re
from collections import defaultdict

EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
LOGIN = re.compile(r"\b[a-z]{2}\d{4,6}\b")  # adapt to your login pattern, e.g. ab12345

def clean(text):
    text = EMAIL.sub("<email>", text or "")
    text = LOGIN.sub("<user>", text)
    return re.sub(r"\s+", " ", text).strip()

resolved = []
with open("tickets_export.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        if row["status"] != "closed" or not row["resolution"].strip():
            continue  # open tickets and closed-without-resolution teach nothing
        resolved.append({
            "id": row["id"],
            "product": row["product"],   # NX, Teamcenter, NXOpen tool, licence, install
            "version": row["version"],
            "symptom": clean(row["subject"] + " " + row["description"]),
            "resolution": clean(row["resolution"]),
        })

# Group tickets that ended in the same resolution: one knowledge unit, many symptoms
by_resolution = defaultdict(list)
for t in resolved:
    by_resolution[t["resolution"].lower()].append(t)

with open("knowledge_units.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.writer(f)
    w.writerow(["resolution", "tickets", "ticket_ids", "products", "versions", "sample_symptoms"])
    for res, group in sorted(by_resolution.items(), key=lambda kv: -len(kv[1])):
        w.writerow([
            res,
            len(group),
            ";".join(t["id"] for t in group),
            ";".join(sorted({t["product"] for t in group})),
            ";".join(sorted({t["version"] for t in group})),
            " | ".join(t["symptom"][:160] for t in group[:3]),
        ])

Die Gruppierung über exakte Übereinstimmung ist bewusst grob; in der echten Pipeline werden nahezu gleiche Lösungen per Embeddings zusammengeführt, und ein Mensch bestätigt die Zusammenführung. Trotzdem ist die nach Ticketzahl sortierte Ausgabe das nützlichste Dokument, das eine CAD-Administration im ganzen Jahr erzeugt: die Fixes, die wiederkehren, mit Belegen daran. Im Projekt für einen privaten KI-Wissensassistenten aus unserer Case Study hat dieses Korpus-Audit die Architektur stärker geprägt als die Modellwahl.

Was der Assistent bei einem neuen Ticket tut

Bei jedem neuen Ticket tut der Assistent vier Dinge und stoppt vor dem fünften: Er ruft ähnliche gelöste Tickets ab, schlägt eine Erstantwort mit Quellen vor, entwirft die Antwort in der Stimme des Administrators und markiert das Ticket als unbekannt, wenn nichts in der Historie passt. Er sendet nie. Die KI schlägt vor, ein Mensch validiert.

So sieht es aus, generisch aufgeschrieben. Die Ticket-IDs sind illustrativ; der Fehlertext ist die Meldung, die NX zeigt, wenn der Lizenz-Client seinen Server nicht erreicht, wie in Threads der Siemens Community dokumentiert [4] (ältere Releases nennen die Variable UGS_LICENSE_SERVER).

NEW TICKET  T-2318  (requester: <user>, site: Plant 2)
"NX won't start on my new workstation. Dialog says: License Error:
Cannot connect to license server system. The server (lmgrd) has not
been started yet, or SPLM_LICENSE_SERVER is set to the wrong port@host."

SIMILAR RESOLVED TICKETS (3 of 3 above threshold)
  T-1907  reimaged workstation, SPLM_LICENSE_SERVER still pointed at the
          old server name                       -> resolved, KB-041 linked
  T-2044  licence service stopped after server patching, restarted
          Siemens PLM License Server service     -> resolved
  T-1622  VPN profile blocked the licence port   -> resolved, KB-058 linked

PROPOSED FIRST-LINE ANSWER  (sources: T-1907, KB-041)
  New workstation + this exact message = most often the environment
  variable. Check SPLM_LICENSE_SERVER on the client, expected format
  port@host, against the current licence server name in KB-041.
  If the value is right, check the licence service (T-2044) and the
  VPN profile (T-1622).

DRAFT REPLY FOR ADMIN  (edit, then send)
  Hi, this message usually means the workstation is looking for the
  licence server under an old name. Could you open System Properties >
  Environment Variables and send me the value of SPLM_LICENSE_SERVER?
  It should read port@host with our current server (see KB-041) ...

UNKNOWN-ERROR FLAG: no

Drei Details zählen. Die Ursachen sind danach gereiht, wie oft sie dieses Symptom in der Historie dieses Unternehmens gelöst haben, nicht danach, was ein öffentliches Forum sagt. Jede Zeile verweist auf ein Ticket oder einen KB-Artikel, den der Administrator mit einem Klick öffnen kann. Und der Entwurf fragt nach der einen Information, die zwischen den drei Ursachen entscheidet, statt alle drei aufzulisten.

Findet das Retrieval nichts über dem Schwellenwert, sagt der Assistent das und setzt das Flag. Dieses Flag ist das zweite Produkt des Systems: die Liste der Fehler, die Ihre Historie nie gelöst hat, und damit der Input für die Known-Error-Liste. Lässt man den Assistenten trotzdem antworten, produziert er eine selbstbewusste Vermutung aus einem öffentlichen Forum. In der Praxis geht das selten gut aus.

Das läuft als POC. Was für die Produktion fehlt: Pseudonymisierung, die ein Audit übersteht, SSO und Rechtespiegelung, die Ticket-Tool-Integration, eine Feedback-Schleife, die täglich neu indexiert, Monitoring und Betrieb. Wir schließen die Lücke von “läuft auf meinem Rechner” zu “läuft im Unternehmen”, mit einem Read-only-, Citation-first-Chatbot auf Ihrer Infrastruktur. Starten Sie mit dem NX Knowledge Chatbot Pilot.

Metriken und Pilotdesign

Eine Engineering-Helpdesk-KI wird mit den Zahlen gemessen, die der Helpdesk bereits hat, plus zwei, die der Assistent hinzufügt. Jede Metrik braucht eine Baseline aus dem Quartal vor dem Pilot, sonst beweist der Pilot nichts. Wir nennen keine Benchmark-Zahlen, weil es für Ihre Queue keine gibt; die Tabelle zeigt, was zu messen ist und wie.

Metric	Definition	Baseline-Quelle	Was der Pilot vergleicht
Zeit bis zur ersten Antwort	Zeit von der Ticketerstellung bis zur ersten substanziellen Antwort	Zeitstempel im Ticket-Tool, letztes Quartal	Median für Tickets mit Vorschlag vs. ohne
Erstlösungsquote (First-Contact Resolution)	Anteil der Tickets, die nach der ersten Antwort geschlossen werden, ohne Rückfrage	Statushistorie	Dasselbe, für Tickets, bei denen der Admin den Entwurf genutzt hat
Deflection (Ticket-Vermeidung)	Anteil der potenziellen Tickets, die der Self-Service-Chatbot beantwortet, bevor ein Ticket eröffnet wird	Vor dem Pilot nicht messbar; Chatbot-Sitzungen zählen, die ohne Ticket enden	Sitzungen ohne Ticket vs. Sitzungen gesamt
Eskalationsrate	Anteil der Tickets, die vom First Level an den NX- oder Teamcenter-Spezialisten weitergegeben werden	Zuweisungshistorie	Vor vs. während des Piloten
Entwurfsakzeptanz	Anteil der Antwortentwürfe, die unverändert oder leicht bearbeitet versendet werden	Neu; vom Assistenten protokolliert	Trend über die Pilotwochen
Rate belegter Antworten	Anteil der Vorschläge, deren zitierte Tickets die angegebene Lösung tatsächlich enthalten	Neu; wöchentlich von einem Administrator stichprobenartig bewertet	Vor dem Pilot vereinbartes Ziel
Unknown-Error-Rate	Anteil der Tickets, die als nicht in der Historie markiert werden	Neu; vom Assistenten protokolliert	Sollte sinken, wenn die Known-Error-Liste wächst

Pilotdesign in einem Absatz: eine Queue (NX- und Teamcenter-First-Level), die geschlossenen Tickets der letzten zwei bis drei Jahre, ein Administrator, der pro Woche zwanzig Vorschläge gegen den tatsächlichen Ausgang des Tickets bewertet, vier bis sechs Wochen, und eine Go-oder-No-Go-Entscheidung anhand von Entwurfsakzeptanz und Rate belegter Antworten statt anhand des Gefühls in der Demo. Unsere klare Empfehlung: Bewerten Sie die Rate belegter Antworten auf Tickets, die der Assistent nie gesehen hat, darunter einige mit absichtlich verstümmeltem Fehlertext, denn “weiß, wann er es nicht weiß” entscheidet, ob Administratoren ihn in Woche drei noch nutzen.

Tickets sind personenbezogene Daten. Jedes Ticket nennt einen Anfragenden und einen Administrator, die meisten enthalten eine E-Mail-Adresse, viele einen Hostnamen, der einen Arbeitsplatz identifiziert, manche einen Screenshot mit dem Namen eines Kollegen in der Titelleiste. Der Korpus ist eine DSGVO-Verarbeitungstätigkeit, bevor das erste Embedding berechnet wird, und drei Artikel prägen das Design.

Art. 4 Abs. 5 DSGVO definiert Pseudonymisierung als Verarbeitung personenbezogener Daten in einer Weise, dass sie “ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können”, wobei diese Informationen gesondert aufbewahrt werden [5]. Das ist die Trennung in Schritt drei: Platzhalter im Index, die Zuordnung im Ticketsystem unter der bestehenden Zugriffskontrolle. Art. 5 Abs. 1 lit. c DSGVO, Datenminimierung, ist der Grund, warum der Index Symptom, Umgebung und Lösung enthält und sonst nichts. Art. 28 DSGVO greift in dem Moment, in dem ein Anbieter irgendeinen Teil des Systems hostet: ein Auftragsverarbeitungsvertrag, der benennt, was gespeichert wird, wo, wie lange und wer die Logs lesen darf.

Beim Hosting ist unsere Position dieselbe wie bei jedem Engineering-Assistenten, den wir bauen: On-Premise oder in einer EU-Cloud unter Ihrer Kontrolle, mit aus dem Ticket-Tool gespiegelten Berechtigungen. Ein gehostetes Frontier-Modell, erreicht über die EU-Region eines Hyperscalers, ist für viele DACH-Fertiger akzeptabel; ein Open-Weight-Modell auf Ihren eigenen GPUs ist die Antwort, wo Tickets exportkontrollierte Programme berühren. Die Referenzarchitektur steht in unserem Beitrag zu souveräner agentischer KI für die europäische Fertigung, und das Betriebsmodell, das eine solche Plattform nach dem Pilot am Leben hält, ist Thema unserer Case Study zur Enterprise-GenAI-Plattform.

Der Audit-Trail macht aus einem Chatbot ein Helpdesk-Werkzeug. Jeder Vorschlag speichert, aus welchen Tickets und KB-Artikeln er gebaut wurde, welche Modellversion den Entwurf geschrieben hat und ob der Administrator ihn angenommen, bearbeitet oder verworfen hat. Die Self-Service-Ebene legt offen, dass sie ein KI-System ist, wie es die Transparenzpflichten nach Art. 50 der EU-KI-Verordnung (AI Act) seit dem 2. August 2026 verlangen. Und wird ein Ticket nach einer Aufbewahrungsregel oder auf einen Löschantrag hin gelöscht, geht der Indexeintrag im selben Job mit. Retrieval macht daraus eine Zeile. Fine-Tuning hätte es unmöglich gemacht.

Häufig gestellte Fragen

Kann eine KI wirklich auf unserem Ticketsystem trainiert werden, um NX- und Teamcenter-Fehler zu bearbeiten?

Ja, wenn “trainiert” heißt: für das Retrieval indexiert. Der Assistent ruft geschlossene Tickets ab, deren Symptom zu einem neuen Ticket passt, schlägt eine aus deren Lösungen gebaute Antwort vor und zitiert sie. Wiederkehrende Fehler werden bearbeitet; neue Fehler werden markiert, nicht geraten. Die Obergrenze setzt die Zahl der geschlossenen Tickets mit schriftlicher Lösung.

RAG oder Fine-Tuning: Was ist für Ticketdaten richtig?

RAG, aus drei Gründen: Tickets ändern sich täglich, und ein Index wird in Minuten aktualisiert, während ein per Fine-Tuning trainiertes Modell ein Snapshot ist; RAG kann das verwendete Ticket zitieren, Fine-Tuning nicht; und personenbezogene Daten in einem Index lassen sich löschen, ein in die Modellgewichte aufgesogener Name nicht. Fine-Tuning hat nur für den Ton eine Rolle, nie für das Wissen.

Welche Daten braucht eine Engineering-Helpdesk-KI aus unseren Tickets?

Symptom, Umgebung und Lösung je Ticket, mit personenbezogenen Daten durch Platzhalter ersetzt; Produkt und Version als Metadaten; ein Link auf einen KB-Artikel oder Known-Error-Eintrag, wo vorhanden. Anhänge zählen, wenn der Fehlertext in Screenshots steckt, was in CAD-Helpdesks häufig der Fall ist. Offene Tickets und ohne Lösung geschlossene Tickets bleiben außen vor.

Was kostet der Aufbau einer Engineering-Helpdesk-KI?

Der Festpreis-Pilot auf unserer Seite zum NX Knowledge Chatbot ist der Referenzpunkt: Kernkorpus indexiert, Citation-first-Chatbot live für eine Pilotgruppe auf Ihrer Infrastruktur, ein Bericht zur Antwortqualität auf echten Fragen, vier bis sechs Wochen. Der größere, weniger sichtbare Kostenblock liegt auf Ihrer Seite: den Ticket-Export bereinigen, Pseudonymisierungsregeln mit dem Datenschutzbeauftragten abstimmen und das Ticket-Tool anbinden. Planen Sie diese Tage vor der Lizenz ein.

Antwortet der Assistent den Anfragenden direkt und schließt Tickets?

Nicht in unserem Design. Er antwortet im Self-Service-Chatbot, bevor ein Ticket existiert; bei einem offenen Ticket schreibt er einen internen Vorschlag und einen Antwortentwurf, den der Administrator versendet oder verwirft. Tickets auf Basis einer KI-Antwort automatisch zu schließen, entfernt die menschliche Prüfung, die die Rate belegter Antworten ehrlich hält.

Nächster Schritt

Sprechen Sie mit unseren Ingenieuren über einen Assistenten auf Ihrer Ticket-Historie

Referenzen

Amazon Web Services, “What is RAG (Retrieval-Augmented Generation)?”, https://aws.amazon.com/what-is/retrieval-augmented-generation/, abgerufen am 24. September 2026.
Yunfan Gao et al., “Retrieval-Augmented Generation for Large Language Models: A Survey,” arXiv:2312.10997, v5, 27. März 2024, https://arxiv.org/abs/2312.10997, abgerufen am 24. September 2026.
Anthropic, “Introducing Claude Opus 5.5,” 22. September 2026, https://www.anthropic.com/news/claude-opus-5-5, abgerufen am 24. September 2026.
Siemens Digital Industries Software Community, “NX License Error: Cannot connect to license server system. The server (lmgrd) has not been started yet, or UGS_LICENSE_SERVER is set to the wrong port@host,” https://community.sw.siemens.com/s/question/0D54O000061wpw6SAA/nx-license-error-cannot-connect-to-license-server-system-the-serverimgrd-has-not-been-started-yet-or-ugslicenseserver-is-set-to-the-wrong-port-host-15, abgerufen am 24. September 2026.
European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation),” Art. 4 Abs. 5, Art. 5 Abs. 1 lit. c und Art. 28, https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng, abgerufen am 24. September 2026.
Siemens, “Designcenter is for everyone: June 2026 release,” Designcenter-Blog, 23. Juni 2026, https://blogs.sw.siemens.com/designcenter/designcenter-is-for-everyone-june-2026-release/, abgerufen am 24. September 2026.