Whitepaper cerințe pentru NX AI: utilizatori, date, operare

Cerințe pentru NX AI: versiunea scurtă

Cerințele pentru NX AI sunt lucrurile pe care utilizatorii NX și Teamcenter le așteaptă de la un asistent: răspunsuri din documentație per versiune, sfaturi de metodă conform regulilor companiei, acțiuni prin NXOpen protejate de o poartă de confirmare (gate), ajutor la customizarea Teamcenter, tratarea erorilor pe bază de tichete și operare suverană. Acest whitepaper mapează 21 de așteptări reale ale utilizatorilor la capabilități și se încheie cu o listă de verificare RFP pe care inteliScience o folosește în piloții cu preț fix.

Întrebare	Răspuns într-o propoziție
De unde provin cerințele?	Administrarea CAD a unui constructor de mașini din DACH și-a întrebat utilizatorii NX și Teamcenter ce așteaptă de la un “NX AI”. Cele 21 de răspunsuri, anonimizate, formează coloana vertebrală a acestui document.
Ce își doresc utilizatorii de fapt?	Șase lucruri: răspunsuri din documentație, sfaturi de metodă, acțiuni în NX, lucrări de administrare, ajutor la customizarea Teamcenter și depanare pe bază de tichete. Alte două sunt condiții: cunoștințe specifice companiei și operare suverană.
Ce înseamnă “antrenare pe datele noastre”?	În practică, retrieval (regăsire de informații) peste documentele dvs., exporturile modelului de date, istoricul tichetelor și cod, plus acces la instrumente. Fine-tuning-ul este excepția, nu planul.
Ce este necesar pentru livrare?	Trei capabilități: cunoștințe (documentația NX per versiune plus standardele dvs.), instrumente (NXOpen și Teamcenter SOA în spatele unei porți de confirmare) și memorie a propriilor artefacte. Plus o implementare care se potrivește regulilor dvs. privind datele.
De unde să începeți?	Un pilot cu preț fix pe un singur caz de utilizare, cu metrici convenite, apoi o adoptare în faze: mai întâi răspunsuri, apoi pregătire, apoi acțiuni cu poartă de confirmare.

1. De ce acest whitepaper: o listă a utilizatorilor bate o matrice de funcții

Matricele de funcții ale furnizorilor descriu ce poate face un produs. O listă cu ceea ce așteaptă utilizatorii descrie ce trebuie să facă un produs. A doua listă este mai rară, iar când un client ne înmânează una, valorează mai mult decât orice demo.

Administrarea CAD și PLM a unui constructor de mașini din DACH le-a pus utilizatorilor săi NX și Teamcenter o singură întrebare: ce așteptați de la un NX AI? Răspunsurile au venit în șase blocuri, de la “cum dezactivez constrângerile automate în schița legacy de pe un desen” până la “hardware, instalare, operare, costuri, cloud, on-premise”. Nimeni nu a cerut un chatbot. Toată lumea a cerut un coleg care cunoaște NX, cunoaște compania și poate, la cerere, să facă ceva.

Publicăm lista aici (parafrazată, fără niciun detaliu de identificare) pentru că este cel mai bun document de cerințe pentru un AI de inginerie pe care l-am văzut în 2026. Este concretă, amestecă întrebări banale și grele așa cum o face munca reală și scoate la iveală diferența dintre un model care vorbește despre NX și un sistem care lucrează în el. Cifrele proprii ale Siemens arată cât spațiu există: Designcenter 2606, lansarea din iunie 2026 care a redenumit NX în Designcenter, livrează Designcenter Copilot, iar Siemens raportează că funcțiile sale AI sunt folosite de peste 500.000 de ori pe lună. Acele utilizări sunt răspunsuri fundamentate pe documentație. Lista utilizatorilor de mai jos cere mai mult de atât și o cere conform regulilor companiei.

Publicul acestui whitepaper este persoana care trebuie să scrie cerințele: managerul CAD, responsabilul PLM, arhitectul IT de inginerie. Dacă evaluați furnizori în loc să specificați, cadrul nostru pentru cumpărători privind evaluarea asistenților AI pentru inginerie acoperă partea de punctare; acest document acoperă criteriile față de care se punctează.

2. Șase clase de așteptări derivate din listă

Citiți cele 21 de așteptări o dată și par o colecție aleatorie. Sortați-le după ceea ce necesită un răspuns corect și apar șase clase. Clasa este mai utilă decât întrebarea, pentru că vă spune de ce capabilitate are nevoie un sistem înainte de a putea răspunde la orice întrebare de acel tip.

#	Ce au cerut utilizatorii (parafrazat)	Clasă	Capabilitate necesară
1	Activarea sau dezactivarea creării automate de constrângeri în schița legacy de pe un desen	Documentație	Documentația NX pentru versiunea instalată; căutarea setării
2	Crearea unei piese 3D dintr-o schiță și o traiectorie de schiță (sweep de-a lungul unei traiectorii)	Documentație	Documentația NX pentru versiunea instalată; căutarea comenzii
3	Unde și cum se atașează callout-ul pentru o modificare de componentă pe desen	Metodică	Standardul de desen al companiei; documentația NX
4	Crearea de legături WAVE stabile și asociative	Metodică	Ghidul de modelare al companiei; documentația NX
5	Repararea legăturilor WAVE rupte	Metodă, apoi acțiune	Documentația NX; instrument de citire peste ansamblu; instrument de relegare cu poartă de confirmare
6	“Proiectează-mi un canal de pană de tip xy în acest arbore”	Acțiune	Tabel de standard; instrumente de citire; instrument de construire NXOpen cu poartă de confirmare
7	Feature parametric “degajare DIN 509 tip E” controlat de diametrul arborelui	Administration	Tabel de standard; pregătirea expresiei și a șablonului de feature; validare de către administrator
8	Adăugarea materialului xyz în baza de date de materiale	Administration	Pregătirea intrării de bibliotecă; administratorul aplică
9	Adăugarea găurii xyz în tabelul de găuri	Administration	Pregătirea intrării de tabel; administratorul aplică
10	În rolul Standard, aplicația Modeling, fila Home, adăugarea unui buton care rulează programul xy	Administration	Pregătirea customizării; administratorul aplică
11	Programul raportează eroarea xy, ce fac?	Tichet de suport	Istoricul tichetelor; codul companiei; citirea log-urilor
12	Setarea valorii x la y în preferințe	Administration	Documentația NX; Customer Defaults; poartă de confirmare acolo unde este scriptat
13	Care preferință activează funcția …?	Documentație	Documentația NX pentru versiunea instalată
14	programare NXOpen	Acțiune (cod)	Referința API NXOpen per versiune; biblioteca de cod a companiei
15	Poate fi AI-ul antrenat pe modelul nostru de date Teamcenter, pe workflow-uri și procese?	Customizare Teamcenter	Exporturile BMIDE și ale șabloanelor de workflow ca surse de retrieval
16	Ajutor la crearea de workflow-uri și cunoașterea handler-elor	Customizare Teamcenter	Documentația handler-elor; șabloanele de workflow proprii
17	Construirea de stylesheet-uri	Customizare Teamcenter	Exporturile stylesheet-urilor proprii (XRT); documentație
18	Programare SOA	Customizare Teamcenter	Documentația SOA per versiune; codul de servicii propriu
19	Antrenare pe sistemul nostru de tichete pentru tratarea erorilor pe bază de AI	Tichet de suport	Export de tichete cu câmpul de rezolvare; reguli de acces
20	Antrenare pe datele, programele și documentația noastră	Transversal: cunoștințe	Platformă de retrieval cu cadență de reîmprospătare (capitolul 4)
21	Hardware, instalare, operare, costuri, cloud, on-premise	Transversal: operare	Opțiune de implementare și model de cost (capitolele 8 până la 10)

Trei observații în urma sortării.

Clasa de documentație este cea mai mică și cea mai ușoară și este cea pe care Siemens o acoperă acum bine cu Designcenter Copilot. Orice furnizor care demonstrează doar această clasă demonstrează partea problemei care este deja rezolvată.

Clasa de metodă este locul în care intră regulile companiei. Unde se pune un callout de modificare pe un desen nu scrie în manualul NX; scrie în standardul dvs. de desen. Cum se mențin stabile legăturile WAVE este pe jumătate cunoaștere NX (legare la geometrie stabilă, denumită, în loc de fețe care se regenerează) și pe jumătate ghidul dvs. de modelare. Un asistent care răspunde la întrebări de metodă doar din cunoștințe publice va fi plauzibil din punct de vedere tehnic și greșit pentru dvs.

Clasele de administrare și Teamcenter sunt cele pe care un chatbot generalist nu le poate atinge deloc, și împreună formează cel mai mare grup de pe listă: 9 din 21 de așteptări. Ele au nevoie de artefactele proprii ale companiei în buclă și de o linie clară între ce pregătește asistentul și ce aplică administratorul.

3. Modelul de capabilități: cunoștințe, instrumente, memorie

Fiecare așteptare de pe listă se reduce la una sau mai multe dintre trei capabilități. Le numim direct, pentru că limbajul furnizorilor (“copilot”, “agent”, “model antrenat”) ascunde care dintre ele este vizată.

Capabilitate	Ce este	Ce așteptări deservește	Ce nu trebuie să facă niciodată
Cunoștințe	Retrieval peste documentația NX și Teamcenter pentru versiunea instalată, plus standardele, ghidurile și șabloanele dvs., cu o citare a sursei la fiecare răspuns	1, 2, 3, 4, 12, 13, 16, 18	Să răspundă dintr-o altă versiune NX; să răspundă fără sursă
Tools	Operații NXOpen și Teamcenter SOA tipizate, expuse asistentului; instrumentele de citire libere, instrumentele de scriere în spatele previzualizării, confirmării, undo-ului și auditului	5, 6, 7, 12, 14	Să execute o scriere fără confirmare; să ruleze journal-uri în formă liberă
Memoria artefactelor dvs.	Exporturi indexate ale modelului dvs. de date (BMIDE), șabloane de workflow, stylesheet-uri, istoricul tichetelor, cod NXOpen și SOA, cu regulile de acces oglindite	7 până la 11, 15 până la 19	Să divulge un artefact unui utilizator care nu are voie să îl citească; să se învechească în tăcere

Cele trei nu sunt straturi opționale pe care le adăugați în timp, în orice ordine. Cunoștințele fără memorie răspund generic. Instrumentele fără cunoștințe acționează fără a vă cunoaște regulile. Memoria fără instrumente poate explica tichetul de anul trecut, dar nu poate verifica dacă aceeași eroare este acum pe ecranul dvs.

Recomandarea noastră clară, după fiecare proiect de acest fel: construiți mai întâi cunoștințele și memoria, livrați-le doar în citire și adăugați instrumente abia după ce utilizatorii au încredere în răspunsuri. Arhitectura care face stratul de instrumente sigur (poarta de confirmare, marcajele de undo, domeniile de rol, jurnalul de audit) este descrisă în propriul nostru whitepaper NX MCP, și nu o repetăm aici. Ceea ce adaugă acest document este perspectiva cerințelor: care așteptare are nevoie de care capabilitate și ce trebuie să însemne “antrenat pe datele noastre” pentru ca stratul de memorie să funcționeze.

4. “Antrenare specifică companiei”, explicată onest

Așteptarea 20 este cea pe care o formulează fiecare client și la care aproape fiecare furnizor răspunde vag: “antrenați AI-ul pe datele, programele și documentația noastră”. Precizia contează aici, pentru că cele două lucruri pe care le poate însemna formularea au costuri, comportament la reîmprospătare și profiluri de protecție a datelor foarte diferite.

Retrieval înseamnă că modelul rămâne așa cum a fost livrat, iar materialul dvs. este indexat. În momentul întrebării, sistemul găsește pasajele relevante (dintr-un ghid, un export BMIDE, un tichet, un fișier sursă), le transmite modelului împreună cu întrebarea, iar modelul răspunde pe baza lor, cu citarea sursei. Actualizați un document, reindexați-l, iar următorul răspuns reflectă modificarea. Nimic despre compania dvs. nu intră în ponderile modelului.

Fine-tuning înseamnă ajustarea ponderilor modelului pe exemple din datele dvs. Schimbă felul în care scrie modelul și ce tipare preferă. Nu îi oferă modelului o memorie fiabilă a unor fapte concrete, nu poate cita o sursă, se învechește în momentul în care se schimbă un standard și necesită ca datele dvs. să fie folosite ca material de antrenare, exact ceea ce interzic majoritatea evaluărilor de protecție a datelor.

Pentru cele 21 de așteptări de pe listă, retrieval-ul acoperă fiecare așteptare care presupune a ști ceva. Recomandăm să nu se facă fine-tuning pe datele clienților pentru asistenți de inginerie și nu o facem în implementările noastre. Singurul loc în care fine-tuning-ul merită o discuție este o sarcină de clasificare îngustă, stabilă și cu volum mare, iar cazul de rutare a tichetelor din capitolul 7 este cel mai apropiat de așa ceva de pe listă. Chiar și acolo, retrieval cu un export bun de tichete este primul lucru de încercat.

Retrieval-ul are nevoie de un corpus, de o cadență de reîmprospătare și de reguli de acces. Tabelul de mai jos este versiunea pe care o convenim cu clienții într-un pilot.

Sursă	Formatul pe care îl ingerăm	Reîmprospătare	Regulă de acces	Nu trebuie să părăsească niciodată compania
Documentația NX și Teamcenter	Documentația furnizorului pentru release-ul instalat, etichetată cu versiunea	La fiecare upgrade de release	Toți utilizatorii	Nu (material al furnizorului), dar se aplică termenii de licență
Standarde ale companiei, ghiduri, reguli de desen	PDF, Word, pagini wiki	La modificare, cel puțin lunar	ACL per document	Da
modelul de date BMIDE	Export de șablon (XML)	La fiecare deployment BMIDE	Administratori PLM, dezvoltatori	Da
Șabloane de workflow, argumente ale handler-elor	Export din Workflow Designer	La fiecare modificare de șablon	Administratori PLM	Da
Stylesheet-uri (XRT)	Export de dataset din Teamcenter	La modificare	Administratori PLM, dezvoltatori	Da
Cod NXOpen și SOA	Repository de surse	La fiecare merge	Dezvoltatori, administratori CAD	Da
Tichete de suport	Export cu câmpurile problemă, rezolvare, produs, versiune	Zilnic	Suport, administratori CAD; date personale eliminate	Da
Customer Defaults, preferințe	Fișiere de defaults exportate	La modificare	Administratori CAD	Da

Două reguli fac sau strică acest tabel. Regulile de acces se transferă: cine nu are voie să deschidă o sursă nu trebuie să primească un răspuns derivat din ea, evaluat per utilizator în momentul întrebării. Și fiecare corpus este etichetat cu versiunea: documentația NX 2412 nu trebuie să răspundă la o întrebare despre Designcenter 2606, iar un stylesheet din release-ul Teamcenter anterior nu trebuie citat ca fiind actual.

5. Partea NX: documentație, reguli ale companiei sau execuție NXOpen

Așteptările 1 până la 14 sunt întrebări NX, iar cerința utilă nu este “răspunde la întrebări NX”, ci “știe de ce fel de răspuns are nevoie fiecare întrebare”. Le sortăm în trei niveluri, pentru că fiecare nivel are un alt mod de eșec și un alt test de acceptanță.

Nivel	Întrebări din listă	Răspunsul provine din	Test de acceptanță
Se poate răspunde din documentație	1 (constrângeri în schița legacy), 2 (sweep de-a lungul unei traiectorii), 13 (care preferință)	Documentația NX pentru versiunea instalată, citată	Corect pentru release-ul instalat; precizează când o comandă s-a schimbat între release-uri
Necesită reguli ale companiei	3 (plasarea callout-ului de modificare), 4 (legături WAVE stabile), 12 (valori de preferințe)	Standardul dvs. de desen, ghidul de modelare și Customer Defaults, citate alături de documentația NX	Citează documentul companiei, nu o bună practică generică; refuză când nu există o regulă a companiei
Necesită execuție NXOpen	5 (repararea legăturilor WAVE), 6 (canal de pană), 14 (cod NXOpen)	Instrumente de citire pe piesa deschisă, apoi un instrument de construire cu poartă de confirmare sau cod generat pe care utilizatorul îl revizuiește	Previzualizare înaintea oricărei modificări; fiecare parametru trasabil; marcaj de undo și intrare de audit la aplicare

Câteva note despre întrebările individuale, cu prudența pe care o cere briefingul: acolo unde nu am verificat un comportament NX față de materialul Siemens, spunem ce trebuie să caute asistentul, în loc să afirmăm răspunsul.

Întrebarea 1 este o întrebare de setări cu o nuanță de versiune. “Create Inferred Constraints” este o setare de schiță în NX, iar firele de discuție din Siemens Community documentează că NX o poate dezactiva automat la schițe mari, cu o alertă de performanță. Un răspuns bun numește așadar setarea, precizează release-ul la care se aplică și menționează comportamentul automat, pentru că utilizatorul care întreabă “cum o activez” s-ar putea lupta cu NX care o dezactivează. Un model generalist va da prima jumătate și o va rata pe a doua.

Întrebarea 2 este cel mai curat caz de documentație. NX are o comandă Sweep Along Guide exact pentru această construcție; asistentul trebuie să găsească comanda în documentația pentru release-ul instalat, să explice selecția secțiunii și a ghidajului, și să se oprească. Fără regulă a companiei, fără acțiune.

Întrebările 4 și 5 merg împreună și sunt cea mai bună ilustrare a nivelurilor. Legăturile WAVE stabile sunt o întrebare de metodă: documentația NX explică WAVE Geometry Linker, dar dacă firma dvs. leagă la corpuri, fețe sau geometrie denumită și dacă legăturile sunt permise între nivelurile de ansamblu, asta scrie în ghidul dvs. de modelare. Legăturile rupte sunt o întrebare de acțiune: NX expune un Relinker prin NXOpen (clasa Assemblies.RelinkerBuilder poate căuta legături WAVE și expresii interpart, le poate filtra pe cele rupte și le poate relega la o sursă nouă). Un asistent care poate lista legăturile rupte din ansamblul deschis (instrument de citire) și poate propune o relegare per legătură (scriere cu poartă de confirmare) transformă o muncă manuală de două ore într-o revizuire. Un asistent care doar explică ce este o legătură WAVE a răspuns la nivelul greșit.

Întrebarea 6, canalul de pană, este cererea de acțiune pe care toată lumea și-o amintește de pe listă. Are răspuns, dar numai atunci când asistentul adună fiecare parametru dintr-o sursă înainte de a propune ceva: diametrul arborelui din model, lățimea și adâncimea canalului de pană din tabelul standardului pentru acel diametru, lungimea și poziția de la utilizator, iar feature-ul de folosit din biblioteca dumneavoastră de feature-uri.

Un apel de instrument fără proveniență pentru fiecare parametru ar trebui să pice cerința, nu pentru că numerele sunt greșite, ci pentru că nimeni nu poate verifica dacă sunt greșite.

Întrebarea 14, programarea NXOpen, este locul în care modelele generaliste eșuează cel mai vizibil: inventează membri de API. Cerința este fundamentarea API în funcție de versiune, ceea ce înseamnă că referința NXOpen pentru release-ul instalat se află în corpusul de retrieval, iar propria bibliotecă de cod se află în stratul de memorie, astfel încât propunerile folosesc denumirile și wrapper-ele dvs. Codul generat este revizuit de un dezvoltator ca orice alt pull request; asistentul este un coleg mai rapid, nu un proces de release.

6. Partea Teamcenter: ce pregătește asistentul, ce rămâne la administrator

Așteptarea 15 pune direct întrebarea-cheie: Teamcenter este puternic customizat, poate fi AI-ul antrenat pe modelul nostru de date, pe workflow-uri și procese? Da, în sensul de retrieval din capitolul 4, și este cel mai valoros corpus pe care o echipă Teamcenter îl poate indexa, pentru că nimic despre un Teamcenter customizat nu se găsește în vreo documentație publică.

Ce poate și ce nu poate face asistentul per artefact este cerința care contează, pentru că customizarea Teamcenter este locul în care un asistent prea zelos face cele mai mari pagube.

Artefact	Asistentul poate pregăti	Rămâne la administrator sau dezvoltator
Model de date (BMIDE)	Explică tipurile dvs. de item, proprietățile, LOV-urile și relațiile din exportul de șablon; redactează o descriere a modificării; găsește unde este folosită o proprietate	Fiecare modificare BMIDE, deployment și actualizare a bazei de date
Șabloane de workflow și handlere	Explică ce face un șablon din exportul său; caută scopurile și argumentele handler-elor (action handler-ele execută acțiuni asupra unei sarcini, rule handler-ele decid dacă o sarcină poate continua); redactează un design de șablon și lista de argumente ale handler-elor	Construirea și testarea șablonului în Workflow Designer; eliberarea lui
Stylesheet-uri (XRT)	Citește stylesheet-urile dvs. existente; propune XML-ul pentru o secțiune nouă sau un bloc de proprietăți în convențiile dvs.; explică regulile de randare	Înregistrarea dataset-ului; testarea în clienți; eliberarea
Servicii SOA și ITK	Propune apeluri de servicii și cod client din documentația SOA pentru release-ul dvs. și din propria bibliotecă de servicii; explică un serviciu custom existent	Compilare, deployment, revizuirea permisiunilor
Acțiuni de runtime (pornire workflow, draft ECR, actualizări de proprietăți)	Redactează acțiunea, rezolvă elementele afectate, afișează previzualizarea	Confirmarea, executată în sesiunea și cu permisiunile proprii ale utilizatorului

Linia este consecventă: asistentul citește, explică și redactează; un om cu rolul potrivit aplică. Pentru acțiunile de runtime din ultimul rând, oferta noastră Teamcenter AI descrie asistentul care execută sub permisiunile proprii ale utilizatorului, cu o poartă de confirmare per acțiune, și se aplică aceeași regulă: nu aprobă niciodată, nu eliberează niciodată, nu modifică niciodată o definiție de workflow.

Așteptarea 16 merită o notă specială. “Cunoașterea handler-elor” este o cerere pentru ceva ce documentația Siemens oferă în principiu, dar nimeni nu citește în practică: ce handler există pentru ce sarcină și care sunt argumentele lui. Indexarea documentației handler-elor pentru release-ul dvs. și, mai important, a propriilor șabloane (care arată cum le-au combinat predecesorii dvs.) îi oferă unui administrator PLM referința pe care și-o dorea de ani de zile. Acesta este un caz de utilizare de cunoștințe doar în citire, se livrează în prima fază și este sarcina Teamcenter cu care am începe.

7. Tichetele de suport ca sursă de cunoștințe

Așteptarea 19 întreabă dacă sistemul de tichete poate antrena AI-ul pentru tratarea erorilor. Poate, ca un corpus de retrieval, și este sursa de pe listă care se amortizează cel mai repede, pentru că tichetele conțin exact perechea de care are nevoie un asistent: un simptom în cuvintele utilizatorului și o rezolvare în cuvintele administratorului.

Trei condiții decid dacă un corpus de tichete este util.

Câmpul de rezolvare trebuie să fie completat. Un tichet care se închide cu “rezolvat” nu învață pe nimeni nimic. Înainte de indexare, măsurați ponderea tichetelor cu o rezolvare substanțială; dacă este mică, pilotul începe cu administratorii scriind rezolvările cum trebuie timp de o lună, ceea ce merită făcut indiferent de AI.

Datele personale sunt eliminate înainte de indexare. Numele raportorilor, adresele de e-mail și câmpurile de text liber cu detalii personale sunt eliminate sau pseudonimizate în export. Aceasta este atât o cerință de protecție a datelor, cât și o îmbunătățire a calității, pentru că numele sunt zgomot pentru retrieval.

Câmpurile de produs și versiune sunt păstrate. O eroare NXOpen dintr-un release poate avea o altă cauză în următorul; asistentul trebuie să poată spune “aceasta s-a potrivit cu trei tichete, două dintre ele pe release-ul dvs. actual”.

Cu aceste condiții îndeplinite, așteptarea 11 (“programul raportează eroarea xy, ce fac?”) devine o întrebare de retrieval peste tichete, cod și, acolo unde asistentul are un instrument de citire, log-ul sesiunii în curs. Răspunsul citează tichetele cu care s-a potrivit. Ce nu trebuie să facă asistentul este să închidă tichetul, să schimbe o configurație sau să ruleze o reparație fără poarta de confirmare; tratarea erorilor este un sfat până când un om îl aplică.

Acesta rulează ca un POC. Ce lipsește pentru producție: Conformitate GDPR, SSO/Entra, scalare, monitorizare, operare. Închidem decalajul de la “rulează pe mașina mea” la “rulează în enterprise”: definiți scopul unui proiect-pilot NX AI cu preț fix.

8. Opțiuni de implementare: API cloud, regiune UE, privat, on-premise, air-gapped

Așteptarea 21 enumeră întrebările operaționale dintr-o suflare: hardware, instalare, operare, costuri, cloud, on-premise. Prima decizie este unde rulează modelul de raționament, pentru că ea determină tot restul. Există patru opțiuni în 2026, și toate patru sunt reale; diferențele sunt rezidența datelor, alegerea modelului și cine poartă sarcina operațională.

Un fapt ancorează tabelul. Un model frontier nu mai implică un singur endpoint al unui furnizor. Anthropic listează Claude Opus 5.5 (ID model claude-opus-5-5, lansat pe 22 septembrie 2026) ca disponibil pe Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry și Claude Platform on AWS, iar Amazon Bedrock documentează endpoint-uri regionale pentru UE care rutează traficul printr-o geografie specifică pentru cerințe de rezidență a datelor, cu o primă de 10 la sută față de endpoint-urile globale. Pe partea open-weight, gpt-oss-120b de la OpenAI este publicat sub Apache 2.0 și este proiectat să ruleze pe un singur GPU de 80 GB, iar Mistral Small 3.1 (24B) este Apache 2.0, cu aproximativ 55 GB de VRAM la bf16, sau un singur GPU de consum când este cuantizat. Operarea suverană este o alegere de configurare, nu un compromis asupra capabilității.

Opțiune	Rezidența datelor	Alegerea modelului	Efort de operare	Cine aplică patch-uri la ce	Se potrivește când
API cloud al furnizorului	Termenii și regiunile furnizorului	Modele frontier, cele mai noi primele	Cel mai mic: fără operarea modelului	Furnizorul aplică patch-uri modelului și API-ului; dvs. aplicați patch-uri asistentului, conectorului și indexului	Corpusuri nesensibile; cel mai rapid start; evaluarea de protecție a datelor acceptă termenii furnizorului
Hyperscaler într-o regiune UE (Bedrock, Vertex AI, Foundry)	Tenant-ul dvs., regiune UE selectabilă; endpoint-uri regionale pentru rutare garantată	Modele frontier cu o mică întârziere față de API-ul furnizorului	Mic: configurarea tenant-ului, IAM și a rețelei	Hyperscaler-ul aplică patch-uri runtime-ului de model; dvs. aplicați patch-uri asistentului, conectorului și indexului	Majoritatea producătorilor din DACH cu un tenant cloud existent și o cerință de rezidență
Cloud privat sau on-premise cu modele open-weight	Infrastructura dvs., rețeaua dvs.	Modele open-weight (gpt-oss, Mistral, altele)	Mediu spre mare: servere GPU, runtime de inferență, actualizări de model	Dvs. (sau partenerul dvs.) aplicați patch-uri la tot: runtime, versiuni de model, asistent, index	Datele de piese sau standardele nu pot părăsi clădirea; capacitate GPU existentă sau disponibilitatea de a o cumpăra
Air-gapped (izolat de rețea)	Fără nicio conexiune externă	Doar modele open-weight, actualizate prin transfer fizic	Cel mai mare: totul offline, inclusiv actualizările de documentație	Dvs. aplicați patch-uri la tot, după un calendar, de pe medii verificate	Apărare, programe cu control al exporturilor, dezvoltare critică pentru IP

Poziția noastră pentru profilul de constructor de mașini din DACH de pe listă: opțiunea de hyperscaler în regiune UE este varianta implicită de evaluat mai întâi, pentru că păstrează modelul frontier, satisface rezidența și lasă conectorul, indexul, jurnalul de audit și toate datele de piese de partea clientului. On-premise complet este răspunsul corect atunci când evaluarea de securitate o cere, nu pentru că sună mai sigur; aduce sarcini operaționale pe care un departament CAD rareori și le dorește. Air-gapped este o categorie aparte, iar pagina noastră despre AI de inginerie suveran și air-gapped pentru apărare acoperă ce se schimbă atunci când până și actualizările de documentație sosesc pe un disc.

Oricare ar fi opțiunea, o cerință nu se schimbă: conectorul de pe partea NX, stratul de instrumente, indexul de retrieval și jurnalul de audit rulează acolo unde sunt piesele. Modelul poate fi la distanță; poarta de confirmare nu. Am expus argumentul mai larg în articolul nostru despre AI agentic suveran în producția europeană.

9. Hardware și operare: ce determină dimensionarea și cine ce face

Întrebările despre hardware primesc răspunsuri inventate mai des decât orice alt subiect din acest domeniu. Noi nu dăm niciunul. Ce putem oferi este lista variabilelor care determină dimensionarea, astfel încât să puteți cere unui furnizor cifre față de valorile dvs., în loc să acceptați un număr generic de GPU-uri.

Dimensionarea este determinată de cinci variabile. Utilizatorii concurenți în ora de vârf, nu utilizatorii licențiați, pentru că un asistent are sarcină în rafale. Contextul per cerere: câte chunk-uri regăsite plus rezultate de instrumente călătoresc cu fiecare întrebare; o întrebare despre modelul de date Teamcenter poartă mai mult decât o căutare de preferință. Dimensiunea indexului de retrieval: chunk-uri înmulțite cu dimensiunea embedding-ului, care pentru un corpus de documente este mică pe lângă modelul în sine, dar calculul de ingestie din prima săptămână nu este. Dimensiunea și precizia modelului, care stabilesc pragul minim de memorie; cele două modele Apache 2.0 de mai sus ilustrează intervalul de la un singur GPU de consum (24B cuantizat) până la un singur GPU de centru de date de 80 GB (gpt-oss-120b). Și ținta de latență: un instrument de citire care răspunde în NX la viteză conversațională are nevoie de o rezervă pe care un batch nocturn nu o are.

Pentru opțiunile cloud, hardware-ul nu este problema dvs., iar costul devine tokeni (capitolul 10). Pentru on-premise, cereți furnizorului să dimensioneze față de cele cinci valori ale dvs. și să precizeze modelul, precizia și runtime-ul de inferență pe care le presupune cifra.

Instalarea și operarea se separă curat odată ce componentele sunt numite. Acesta este tabelul pe care îl convenim în fiecare rollout și este totodată o anexă utilă la RFP.

Componentă	Instalează	Operează zi de zi	Patch-uri și upgrade-uri	Deține datele
Conector pe partea NX	Partenerul de integrare împreună cu administratorul CAD	Administrator CAD	Partenerul de integrare, testat per release NX	Clientul
Strat de instrumente (server MCP, client Teamcenter SOA)	Partenerul de integrare	Administrator CAD/PLM	Partenerul de integrare; clientul pentru instrumente adăugate după predare	Clientul
Index de retrieval și joburi de ingestie	Partenerul de integrare	IT de inginerie	IT de inginerie (joburi), partenerul (modificări de pipeline)	Clientul
Curatoria cunoștințelor (standarde, șabloane, calitatea tichetelor)	Administrator CAD/PLM	Administrator CAD/PLM, responsabilul de standarde	Continuu	Clientul
Runtime de model, cloud	Hyperscaler sau furnizor	Hyperscaler sau furnizor	Hyperscaler sau furnizor	Datele din tenant-ul clientului, conform contractului
Runtime de model, on-premise	IT de inginerie împreună cu partenerul	IT de inginerie	IT de inginerie (runtime), partenerul (teste de versiune de model)	Clientul
Identitate și acces (SSO, domenii de rol)	IT de inginerie	IT de inginerie	IT de inginerie	Clientul
Jurnal de audit	Partenerul de integrare	Manager CAD	Partenerul de integrare	Clientul

Două rânduri sunt subestimate în fiecare buget inițial. Curatoria cunoștințelor este o sarcină permanentă pentru administrarea CAD, pentru că asistentul citează cu fidelitate standarde învechite, iar luna de pilot tinde să scoată la iveală mai multe documente învechite decât anul de revizuire anterior. Iar rândul de runtime de model pentru on-premise este o sarcină a IT-ului de inginerie, cu o cadență de release proprie; dacă nimeni din organizație nu vrea acel rând, alegeți o opțiune cloud.

10. Modelul de cost și de ce un pilot cu preț fix vine primul

Costurile de pe listă (“costuri, cloud, on-premise”) nu pot primi un răspuns sub formă de cifră înainte ca opțiunea de implementare și scopul să fie fixate. Pot primi un răspuns sub forma unui model de factori determinanți, ceea ce are nevoie un responsabil de buget pentru a compara oferte.

Factor de cost	Opțiuni cloud	On-premise și air-gapped	Ce îl influențează
Acces la model	Tokeni per cerere, tarifați per milion de tokeni de intrare și de ieșire	Hardware GPU, energie, runtime de inferență; fără taxă per token	Utilizatori concurenți, context per cerere, lungimea răspunsului
Hardware	Nimic dincolo de tenant	Servere GPU dimensionate în capitolul 9	Dimensiunea modelului, precizia, ținta de latență
Integrare	Conector NXOpen, strat de instrumente, mapare Teamcenter SOA, SSO	La fel, plus configurarea runtime-ului	Numărul de instrumente, feature-uri custom și tipuri de obiecte Teamcenter mapate
Curatoria cunoștințelor	Pregătirea corpusului, maparea regulilor de acces, curățarea tichetelor	Același	Dimensiunea și calitatea corpusului; numărul de grupuri de acces
Operațiuni	Reîmprospătarea indexului, monitorizare, revizuirea auditului	La fel, plus patch-uri pentru model și runtime	Cadența de reîmprospătare, numărul de surse, sarcinile on-premise
Licențe	Licențele NX și Teamcenter neschimbate: asistentul rulează sub licența și permisiunile proprii ale utilizatorului	Același	Nimic, cu excepția cazului în care un produs al unui furnizor adaugă licențe

Observația onestă este că integrarea și curatoria cunoștințelor, nu accesul la model, domină primul an pentru un mediu Teamcenter customizat. Facturile de tokeni sunt vizibile și ușor de disputat; săptămânile petrecute mapând tipurile de obiecte BMIDE și curățând rezolvările tichetelor sunt locul unde se duc banii, și tot de acolo vine și valoarea.

De aceea insistăm pe un pilot cu preț fix ca prim pas, cu scopul și metricile convenite înainte de a construi ceva. Fiecare asistent din familia noastră de asistenți NX AI are un proof of concept cu scop fix, iar NX Sprint costă 9.900 € preț fix pentru un caz de utilizare selectat împreună cu părțile interesate din organizația dumneavoastră, un prototip funcțional evaluat față de metrici convenite în două până la trei săptămâni, fiecare soluție putând rula complet on-premise, inclusiv air-gapped.

Ce trebuie să măsoare un pilot este mai important decât cât costă. Patru cifre, pe întrebările dvs. și pe piesele dvs.:

Rata răspunsurilor fundamentate pe surse. Ponderea răspunsurilor cu o citare corectă a materialului dvs. sau a documentației furnizorului pentru release-ul instalat. Includeți intenționat întrebări fără răspuns; “nu se găsește în materialul dvs.” este un răspuns corect.
Acuratețea versiunii. Ponderea răspunsurilor din documentație care sunt corecte pentru release-ul NX sau Teamcenter instalat, nu pentru unul învecinat.
Acceptanța pregătirii. Pentru drafturile de administrare și Teamcenter, ponderea acceptată de administrator fără rework și minutele economisite per draft acceptat.
Comportamentul porții de confirmare. Pentru orice nivel de acțiune din scop, ponderea previzualizărilor acceptate, editate și respinse, precum și rata de rollback după confirmare.

Un pilot care raportează numărul de utilizări în loc de aceste patru cifre nu a fost evaluat.

11. Lista de verificare a cerințelor pentru un RFP

Lista de mai jos este scrisă astfel încât să poată fi copiată într-un document de cerințe. Fiecare punct este testabil; mai multe sunt traducerea directă a unei așteptări a utilizatorilor din capitolul 2.

Asistentul răspunde la întrebări din documentația NX și Teamcenter pentru release-ul instalat și precizează release-ul pentru care a răspuns.
Fiecare răspuns poartă o citare a documentului, tichetului, fișierului de cod sau standardului din care a fost derivat; răspunsurile fără sursă sunt refuzate, nu improvizate.
Standardele, ghidurile și regulile de desen ale companiei sunt indexate și au prioritate față de bunele practici generice atunci când intră în conflict.
Regulile de acces din sistemele-sursă sunt evaluate per utilizator în momentul întrebării; niciun utilizator nu primește răspunsuri derivate din material pe care nu are voie să îl deschidă.
Fiecare corpus este etichetat cu versiunea de produs căreia îi aparține; corpusurile unor release-uri diferite nu sunt niciodată amestecate într-un singur răspuns.
Cadența de reîmprospătare per sursă este documentată (release, la modificare, zilnic), iar reîmprospătarea este incrementală.
Nicio dată a clientului nu este folosită pentru a antrena sau a face fine-tuning vreunui model, și niciun prompt sau răspuns nu este reținut de o terță parte dincolo de perioada convenită contractual.
Modelul de date Teamcenter (export BMIDE), șabloanele de workflow, documentația handler-elor și stylesheet-urile pot fi indexate și explicate; asistentul pregătește modificările, dar nu le implementează (deploy).
Tichetele de suport pot fi indexate cu datele personale eliminate și cu câmpurile de rezolvare, produs și versiune păstrate.
Instrumentele de citire peste piesa NX deschisă și sesiunea Teamcenter sunt disponibile fără confirmare și sunt primul nivel livrat.
Fiecare scriere în NX sau Teamcenter este previzualizată, necesită confirmare explicită, setează un marcaj de undo sau echivalent și este înregistrată în jurnal cu utilizator, marcaj de timp, instrument, parametri și rezultat.
Fiecare parametru dintr-o acțiune propusă poartă proveniență (citire din model, tabel de standard, regulă a companiei sau intrare a utilizatorului).
Nicio execuție de journal sau script în formă liberă de către asistent; operațiile de scriere sunt instrumente tipizate, cu unități inginerești.
Acțiunile în Teamcenter se execută în sesiunea și cu permisiunile proprii ale utilizatorului solicitant; asistentul nu deține niciun cont de serviciu privilegiat și nu aprobă și nu eliberează niciodată.
Accesul la instrumente delimitat pe roluri este impus prin furnizorul de identitate al companiei (SSO).
Opțiunea de implementare (API al furnizorului, hyperscaler în regiune UE, on-premise, air-gapped) este selectabilă, iar conectorul, stratul de instrumente, indexul și jurnalul de audit rulează pe infrastructura clientului în fiecare opțiune.
Modelul este înlocuibil fără rescrierea stratului de instrumente sau a indexului (integrare bazată pe protocol, independentă de model).
Dimensionarea pentru operarea on-premise este precizată față de utilizatorii concurenți ai clientului, contextul per cerere, dimensiunea indexului și ținta de latență, cu modelul și precizia presupuse numite explicit.
Responsabilitățile de instalare, operare și aplicare a patch-urilor sunt listate per componentă înainte de semnarea contractului.
Pilotul are preț fix și scop fix și raportează cele patru metrici din capitolul 10 pe întrebările proprii ale clientului.

Punctul 2 singur elimină majoritatea demo-urilor. Punctul 12 este cel pentru care managerii CAD ne mulțumesc mai târziu.

12. Traseul de adoptare în faze

Așteptările de pe listă pot fi livrate într-o ordine care construiește încredere înainte de a construi risc. Ordinea este aceeași în fiecare opțiune de implementare; doar duratele fazelor se schimbă odată cu calitatea corpusului.

Fază	Scop din listă	Livrează	Criteriu de ieșire
0. Corpus și reguli (săptămânile 1 până la 2)	Așteptările 20, 21	Opțiune de implementare aleasă; standarde, documentație și un export Teamcenter indexate cu reguli de acces; metrici de pilot convenite	Corpusul se construiește reproductibil; maparea accesului verificată de IT
1. Răspunsuri (săptămânile 2 până la 5)	1, 2, 3, 4, 12, 13, 15, 16, 17, 18	Asistent doar în citire care răspunde la întrebări NX și Teamcenter cu citarea surselor, pentru un grup pilot	Rata răspunsurilor fundamentate și acuratețea versiunii măsurate pe întrebările reale ale echipei
2. Pregătire (săptămânile 4 până la 8)	7, 8, 9, 10, 11, 19	Drafturi de administrare și Teamcenter (specificații de feature, intrări de bibliotecă, pași de customizare, liste de handlere, blocuri de stylesheet); tichete indexate	Rata de acceptanță a pregătirii măsurată împreună cu administratorii
3. Instrumente de citire (săptămânile 6 până la 9)	5 (listarea legăturilor rupte), 14 (fundamentarea API)	Asistentul vede piesa deschisă și sesiunea Teamcenter; propuneri NXOpen din biblioteca dvs.	Proiectanții folosesc zilnic instrumentele de citire; zero scrieri până acum
4. Acțiuni cu poartă de confirmare (din săptămâna 9)	5 (relegare), 6 (canal de pană), 12 (defaults scriptate), acțiuni de runtime Teamcenter	Un singur nivel îngust de scriere pe rând, fiecare cu previzualizare, confirmare, undo și audit	Comportamentul porții de confirmare măsurat per instrument; managerul CAD semnează rollout-ul
5. Rollout	Toate	Domenii de rol, SSO, monitorizare, joburi de reîmprospătare predate IT-ului de inginerie; sarcini de curatorie la administrarea CAD	Tabelul de responsabilități (capitolul 9) semnat

Faza 1 este locul în care utilizatorii de pe listă primesc cea mai mare parte din ce au cerut, și nu implică niciun risc de scriere. Faza 4 este locul în care se proiectează canalul de pană, și ar trebui să vină abia după ce fazele 1 până la 3 au justificat-o. Dacă un furnizor propune să înceapă la faza 4, demo-ul va fi impresionant, iar managerul CAD nu îl va semna.

Întrebări frecvente

Care sunt cerințele pentru NX AI pe care o echipă de inginerie ar trebui să le includă într-un RFP?

Răspunsuri din documentație adaptate versiunii, cu citarea sursei; standarde ale companiei indexate cu reguli de acces per utilizator; retrieval peste exporturile Teamcenter și tichete; instrumente de citire înaintea instrumentelor de scriere; o poartă de confirmare (gate) cu previzualizare și confirmare, cu undo și audit la fiecare scriere; proveniență pentru fiecare parametru; execuție sub permisiunile proprii ale utilizatorului; o opțiune de implementare selectabilă, cu conectorul și indexul pe infrastructura dvs.; și un pilot cu preț fix, cu metrici convenite. Capitolul 11 listează toate cele douăzeci de puncte în formă gata de copiat.

Poate fi un AI antrenat pe documentația noastră NX, pe modelul de date Teamcenter și pe sistemul nostru de tichete?

Da, în sensul care contează: documentația dvs., exporturile BMIDE, șabloanele de workflow, stylesheet-urile, codul și tichetele sunt indexate, iar asistentul răspunde pe baza lor, cu citarea sursei. Acesta este retrieval, nu fine-tuning. Fine-tuning-ul modifică ponderile modelului, nu poate cita, se învechește și necesită datele dvs. ca material de antrenare; nu îl folosim pe datele clienților. Retrieval-ul acoperă fiecare așteptare legată de cunoștințe de pe listă și se reîmprospătează atunci când un document se schimbă.

Cât costă un pilot NX AI?

NX Sprint-ul nostru costă 9.900 € preț fix pentru un caz de utilizare: un prototip funcțional evaluat față de metrici convenite în două până la trei săptămâni. Costul implementării depinde apoi în principal de profunzimea integrării și de curatoria cunoștințelor, nu de accesul la model.

Cloud sau on-premise pentru un NX AI: care este mai bun?

Pentru majoritatea producătorilor din DACH, un tenant de hyperscaler într-o regiune UE este prima opțiune de evaluat: păstrează un model frontier actual, precum Claude Opus 5.5, satisface rezidența datelor prin endpoint-uri regionale și lasă conectorul, indexul, datele de piese și jurnalul de audit de partea dvs. On-premise cu un model open-weight sub Apache 2.0, precum gpt-oss-120b, este alegerea corectă atunci când datele de piese sau standardele nu pot părăsi clădirea, și aduce operarea modelului și a runtime-ului în IT-ul de inginerie. Air-gapped (izolat de rețea) este o categorie separată pentru apărare și proiecte cu control al exporturilor.

Poate asistentul să modifice de unul singur modelele noastre NX sau datele din Teamcenter?

Nu. Instrumentele de citire sunt libere; fiecare scriere este previzualizată, aplicată doar după confirmare explicită, încadrată într-un marcaj de undo și înregistrată în jurnal. În Teamcenter, acțiunile rulează în sesiunea și cu permisiunile proprii ale utilizatorului solicitant, iar asistentul nu aprobă, nu eliberează și nu modifică niciodată o definiție de workflow sau modelul de date. Ce nu aveți voie să faceți în Teamcenter, nu poate face nici el pentru dvs.

Pasul următor

Trimiteți-ne propria versiune a listei: întrebările pe care utilizatorii dvs. NX și Teamcenter le-ar pune mai întâi unui asistent. Vom mapa fiecare întrebare la o clasă și la o capabilitate, vă vom spune la care poate răspunde un pilot în trei săptămâni și care au nevoie mai întâi de curățarea standardelor dvs.

Discutați cu inginerii noștri despre cerințele dvs. pentru NX AI

Surse

Siemens, “Designcenter is for everyone, June 2026 release”, blogs.sw.siemens.com, 23 iunie 2026 (Designcenter 2606, Designcenter Copilot, funcții AI folosite de peste 500.000 de ori pe lună), accesat la 24 septembrie 2026
Anthropic, “Models overview” și “Claude Opus 5.5” (ID model claude-opus-5-5, lansat pe 22 septembrie 2026; disponibilitate pe Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry, Claude Platform on AWS), platform.claude.com, accesat la 24 septembrie 2026
Anthropic, “Claude on Amazon Bedrock” (endpoint-uri globale versus regionale, endpoint-uri regionale UE pentru rezidența datelor, primă de 10 la sută), platform.claude.com, accesat la 24 septembrie 2026
OpenAI, gpt-oss-120b model card (Apache 2.0, 117B parametri cu 5.1B activi, proiectat pentru un singur GPU de 80 GB), huggingface.co, accesat la 24 septembrie 2026
Mistral AI, Mistral Small 3.1 24B Instruct model card (Apache 2.0, aproximativ 55 GB VRAM la bf16, un singur RTX 4090 sau un Mac cu 32 GB când este cuantizat), huggingface.co, accesat la 24 septembrie 2026
Siemens, NXOpen .NET Reference Guide, NXOpen.Assemblies.RelinkerBuilder (căutarea și relegarea legăturilor WAVE și a expresiilor interpart, filtru pentru legături rupte, opțiune de rupere a legăturii WAVE), docs.sw.siemens.com, referință API NX 1926, accesat la 24 septembrie 2026
Siemens Community, “How do I stop NX from automatically disabling Create Inferred Constraints on a sketch?” și “Sweep along guide question”, community.sw.siemens.com, accesat la 24 septembrie 2026
Siemens, Teamcenter Gateway generic configuration guide, “Workflow rule handler documentation” (rule handler-ele returnează EPM_go sau EPM_nogo), docs.plm.automation.siemens.com, și Siemens Community, “Workflow handlers” (fir de discuție), accesat la 24 septembrie 2026
DIN 509 (forme de degajare E, F, G, H) și DIN 6885-1 (pene paralele și canale de pană), referențiate ca standarde; valorile din tabele trebuie preluate din textul licențiat al standardului pentru revizia instalată
inteliScience, pagina de ofertă “NX AI Pilot Project” (NX Sprint, 9.900 € preț fix, 2 până la 3 săptămâni), hub-ul de servicii “NX AI Assistants & Chatbots”, “NX MCP Whitepaper” (arhitectura porții de confirmare), “Engineering AI Assistant Evaluation” (cadrul pentru cumpărători), inteliscience.net, 2026