NX AI Workshop: The Short Version
An NX AI workshop is a two-day session in which a CAD team and an AI integrator analyze real parts, drawings and data sources and score candidate use cases. inteliScience, a Siemens NX and NXOpen specialist, runs it on your examples. The output is a scored use-case list, a data inventory with owners, and a costed project plan.
The Problem: Why Most AI Workshops End With a Demo
Most engineering AI workshops fail for reasons that have nothing to do with the model. Nobody looked at the data, nobody brought a real part, and the people who control storage, permissions and approval were not in the room. The result is an impressive demo and no plan anyone can sign.
Data comes first. Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data; in its survey of 248 data management leaders, 63% lacked the right data practices for AI or were unsure. In NX terms: is the hole table one master or five copies?
Examples come second: a vendor’s demo shaft is clean and parametric, yours may have arrived through a migration without feature history. People come third, and a works council that first hears about the project at rollout stops the rollout.
A DACH machine builder’s CAD team got this right. Before the joint workshop they asked us for a preparation checklist and committed to bringing examples, among them a drawing for a dimensioning analysis and migrated parts for a rebuild test. This article is that checklist, anonymized. Our position: we would rather move a workshop by two weeks than run it without examples.
How the Two Days Run
A two-day NX AI workshop has four working blocks: analysis of your data, storage locations and requirements, assessment of candidate use cases, and a project plan with a cost breakdown. Preparation calls run beforehand via Microsoft Teams, and the days can mix on-site and online sessions.
| Block | What happens | Who must attend | Result |
|---|---|---|---|
| Preparation calls (Teams) | Goals, invite list, examples, NDA and sharing route | Design lead, CAD admin | Agreed example list |
| Day 1: data analysis | Examples opened in NX, history and quality checked, first AI steps run | Designers, CAD admin | Findings per example |
| Day 1: storage and requirements | Where each source lives, owner, API access, permissions, hosting | CAD admin, PLM, IT, data protection | Draft data inventory |
| Day 2: use case assessment | Candidates scored on value, feasibility, data readiness, risk | Everyone; design lead decides | Ranked list, pilot candidate |
| Day 2: plan and cost breakdown | Phases, acceptance tests, responsibilities, effort | Design lead, budget owner, IT | Plan and cost breakdown |
The data block earns the workshop its time. inteliScience connects its AI application to a running NX session through a set of NX tools and lets it work on your examples: it reads the open work state, creates sketches, builds geometry from them and executes single steps. The results land as editable features in the part navigator, not as dumb bodies, and dimensions and hole callouts become associative PMI objects that keep their references to the geometry. Seeing that on your own part beats any slide.
The storage block is the least glamorous and the most predictive: every “where does that live?” nobody can answer becomes a line item in the plan.
Who to Invite, Including the Roles Most Teams Forget
Invite everyone who owns a decision or a data source: the design lead, two or three NX designers, the CAD administrator, a PLM owner, IT and security, and data protection. In German companies, inform the works council early if the tools could record who did what, because that capability alone can trigger co-determination.
| Role | Why they are needed | What they prepare |
|---|---|---|
| Design lead | Sets priorities, signs the plan | The three tasks that cost the most time |
| NX designers (two or three) | Know the daily work, judge usability | The examples below |
| CAD administrator | Owns defaults, libraries, tables, NX release | Defaults files, admin tables |
| PLM or Teamcenter owner | Data model and workflows for later phases | An overview of customizations |
| IT and security | Hosting, identity, technical users | Hosting constraints, API approval path |
| Data protection | Personal data in tickets and logs | A view on the ticket export |
| Works council (Germany) | Co-determines monitoring-capable systems | Early information, not a late veto |
The last row surprises many engineering teams. Section 87(1) no. 6 of the German Works Constitution Act (BetrVG) gives the works council a co-determination right over technical devices designed to monitor employee behavior or performance. The Federal Labour Court reads “designed to” objectively: on 16 July 2024 (1 ABR 16/23, para. 25) it held that objective suitability is enough and the employer’s intent does not matter. An NX assistant that logs user, tool and parameters for every action may well meet that test, and we build that audit log on purpose. Inform the works council before the workshop and let labor law counsel judge your case; this is not legal advice.
Data protection is simpler: ticket exports contain names, and whether an impact assessment under Art. 35 GDPR is needed is the controller’s call, with the data protection officer’s advice.
The NX AI Workshop Checklist: What to Bring
Bring examples of your everyday work, not your best work, because the AI will meet your everyday parts in production. This is the list we ask every CAD team for, shaped by what an NX customer’s design team prepared for their own session. Drop what does not match your candidates.
- A part for feature tests. A shaft that needs a keyway on an existing shaft, or a part that needs a parametric feature group, plus the company table the dimensions come from.
- A released drawing for a dimensioning analysis. Model, drawing and the governing guideline pages, to test automatic horizontal and vertical dimensioning against what your checker accepts.
- Three to five migrated parts without feature history. From simple (a flange, a screw) to hard, each with its source file and the history structure you want, for a rebuild with an automated comparison.
- An assembly with a component replacement. A real swap to a variant, with the rule that picks it, to see which constraints survive a replacement.
- A molded or cast part with a known toolmaker finding. Only if moldability is in scope: it shows what a live undercut check would have flagged.
- Guideline pages from your wiki. Five to ten Confluence pages designers actually use: hole rules, drawing rules, modeling conventions.
- Admin tables. Current material, hole and tolerance tables, where they live, and who maintains them.
- An anonymized ticket export sample. A few dozen closed CAD tickets with problem, resolution and NX release fields, names removed.
- NX release and customer defaults. The release in use and the next one planned, plus site- and group-level customer defaults, which NX reads from the directories set by
UGII_SITE_DIRandUGII_GROUP_DIR. Siemens announced on 23 June 2026 that Designcenter NX will be known simply as Designcenter, and its Designcenter 2612 early access program ran until 25 September 2026: plan against next year’s release. - Recurring questions and code. The preferences and error messages people keep asking about and, if NXOpen code generation is in scope, one internal template project in C#, Python or C++.
Four access questions belong to IT beforehand. Is there a read-only technical user for wiki and tickets? May parts be processed in an EU cloud, in Germany only, or on-premise? Who releases the examples, under which NDA? Is there a test system where the AI may write?
A workshop proves feasibility. What’s missing for production: write permissions, EU or on-premise hosting, SSO, audit log, works council agreement, operations. We close the gap from workshop POC to “runs in your enterprise”, starting with a fixed-scope NX AI pilot project on your own examples.
Data Readiness: Where Each Source Lives and What May Be Done With It
Data readiness drives the effort more than model choice does. A source’s structure, maintenance state, storage location and permitted processing decide how much integration work a use case needs, so the workshop asks the same questions of every source.
| Source | Usual home | Owner | Access path | Quality question | Processing question |
|---|---|---|---|---|---|
| Design guidelines | Wiki such as Confluence | Standards owner | REST API (Confluence Cloud v2: read:page:confluence scope, returns only pages the caller may view) | Current for your NX release? | Cloud processing allowed? |
| Material, hole, tolerance tables | NX libraries, spreadsheets | CAD admin | File share or database | One master or several copies? | Write access or edited copy? |
| Customer defaults | Site and group directories | CAD admin | Files | Which settings are locked? | Read only |
| Tickets | Ticket system | CAD support | API or export | Resolution field filled? | Personal data removed? |
| Migrated parts | Teamcenter or file system | Migration team | Export | History rules written down? | May parts leave the site? |
| Teamcenter data model | Teamcenter | PLM team | Services, exports | Customization documented? | Which exports are permitted? |
We connect guidelines, wikis and ticket systems through their APIs with purpose-built tools, so the AI queries current content instead of a stale copy. That is why the access column matters as much as the quality column, and why data engineering is the real AI strategy here.
Permissions need a decision per source. To change a material table or other company data, the AI needs write access. Without it, the AI reads the content and produces an edited copy, which someone transfers into the source system by hand. For shared tables we recommend the edited copy in the first phase: it costs the admin minutes and takes the hardest security question out of the pilot.
Hosting is decided per source too. Models and data can run in the EU, in Germany or on-premise, depending on data protection requirements, model choice and infrastructure. Deployment options in depth are in the deployment chapter of our NX AI requirements whitepaper.
A one-page card per source, filled in by its owner beforehand, shortens the storage block considerably:
# Data source card (template): one per source, filled in by its owner
source: Hole and thread design rules
system: Confluence # Cloud or Data Center
owner: methods team, named person
access_for_ai: REST API, read-only technical user
write_access: "no" # "no" = AI returns an edited copy, admin transfers it
permitted_processing: EU hosting approved
known_quality_issues: pages that predate the current NX releaseScoring Use Cases: Value, Feasibility, Data Readiness, Risk
Score every candidate on four criteria: value to the designers, feasibility today, readiness of its data, and risk if it goes wrong. The example uses the priorities of an NX customer’s design team: design support inside NX first, Teamcenter later, because their Teamcenter is heavily customized and that groundwork is still open.
| Candidate | Value | Feasibility today | Data readiness | Risk | Verdict |
|---|---|---|---|---|---|
| Design support: keyways, parametric feature groups | High | High: editable features in a running session | Medium: standard tables | Low | Pilot candidate |
| PMI: dimensions and hole callouts | High | High: associative, editable PMI | Medium: PMI guideline | Low | Phase 1 |
| Automatic 2D dimensioning | High | Medium: roughly 40 percent automated in current projects (our own estimate); tolerances and surface symbols are harder | Medium: drawing standard | Medium | Phase 2 |
| Rebuild of history-free migrated parts | High with a backlog | Done for flanges and screws; not guaranteed for very complex geometry | Low until history rules exist | Medium | Test on samples |
| Component replacement in assemblies | Medium | Rule-based; constraints generally kept unless referenced faces are missing | Medium: replacement rules | Medium | Phase 2 |
| Admin help: tables, preferences, errors | Medium | High as edited copies or sourced answers | Ticket quality | Low | Phase 1 |
| Teamcenter support | High long-term | Open: own data model, workflows, policies | Low until documented | Higher | Later |
For rebuilt parts, the customer’s team proposed the acceptance test and we agreed: compare each rebuilt part automatically with its source geometry, which turns “looks right” into a success rate. For replacement, we have had valves swapped automatically for matching components based on changed housing sizes and given guidelines.
Score the form too: the same capability can run as a chat, a function, a workflow, a batch process or a button, and a correct result in the wrong form goes unused.
Our clear recommendation: pilot one design-support use case. It delivers practical value fastest and does not wait for Teamcenter. The production version is described under AI-assisted geometry creation in NX.
What Comes Out of the Two Days
A good workshop ends with decisions, not impressions. If the team leaves without an acceptance criterion per use case, it has produced a wish list, however good the demo looked. These are the six outputs we work toward, delivered in writing:
- A ranked use-case list with scores and one pilot candidate.
- A data inventory with owner, location, access path and permitted processing per source.
- Access and hosting decisions: read or write, EU, Germany or on-premise, and the form per use case.
- An acceptance test per use case, such as the geometry comparison for rebuilt parts or scored NX AI acceptance test questions for knowledge use cases.
- A project plan and cost breakdown by phase, with responsibilities on both sides.
- Open items with owners: works council, data protection, NDA for further examples.
The pilot candidate then moves into the NX Proof-of-Value Sprint: one use case on your data, a running prototype evaluated against agreed metrics in two to three weeks. We advise against jumping from workshop to rollout; the sprint gives the acceptance test its first real numbers.
Frequently Asked Questions
What is an NX AI workshop?
A two-day working session in which a CAD team and an AI integrator analyze the team’s own parts, drawings and data sources, score candidate use cases and agree on a project plan. It is not a product demo: examples, data and decisions come from your side.
How should a CAD team prepare for an NX AI workshop?
Invite the owners of decisions and data, including IT, data protection and, in Germany, possibly the works council. Bring a part for feature tests, a drawing for dimensioning analysis, migrated parts without history, wiki pages, admin tables, an anonymized ticket sample, and your NX release and customer defaults.
How much does an NX AI workshop cost?
We scope the workshop in the preparation call, because effort depends on the number of use cases and data sources. The fixed-price step after it is the NX Proof-of-Value Sprint at EUR 12,900 for one use case, fully credited against the follow-up project.
Workshop or pilot first: which is the better start?
The workshop, when you have several candidates or do not know where your data lives. A pilot, when one use case is clear, its data is known and IT has approved the hosting. A pilot on the wrong use case costs far more than two days of preparation.
Does the works council have to be involved?
In Germany, quite possibly. Section 87(1) no. 6 BetrVG covers technical devices designed to monitor employee behavior or performance, and the Federal Labour Court held in 2024 (1 ABR 16/23) that objective suitability is enough. A per-user audit log can meet that test, so inform the works council early.
Next Step
Send us your candidate use cases and the examples you could bring. inteliScience engineers, delivering nearshore from Romania for DACH CAD teams, tell you which ones a workshop can assess on your data and which access questions to settle with IT first.
Related Topics
- Fixed-price NX AI pilot project
- Automating NX drawings and dimensions
- Validating CAD data after an NX migration
Sources
- Bundesministerium der Justiz, Betriebsverfassungsgesetz, § 87 Mitbestimmungsrechte (para. 1 no. 6: technical devices designed to monitor employee behavior or performance), gesetze-im-internet.de, retrieved 29 September 2026
- Bundesarbeitsgericht, decision of 16 July 2024, 1 ABR 16/23 (para. 25: objective suitability suffices, subjective monitoring intent irrelevant), bundesarbeitsgericht.de, retrieved 29 September 2026
- Art. 35 GDPR, Data protection impact assessment (para. 1; para. 2 on the advice of the data protection officer), gdpr-info.eu, retrieved 29 September 2026
- Gartner, “Lack of AI-Ready Data Puts AI Projects at Risk”, press release, 26 February 2025 (60% of AI projects unsupported by AI-ready data abandoned through 2026; 63% of 248 surveyed data management leaders), retrieved 29 September 2026
- Siemens, “Designcenter is for everyone, June 2026 release”, blogs.sw.siemens.com, 23 June 2026 (Designcenter NX to be known as Designcenter), retrieved 29 September 2026
- Siemens, “Welcome to the September 2026 Early Access Program for Designcenter” (Designcenter 2612, sessions from 31 August to 25 September 2026), resources.sw.siemens.com, retrieved 29 September 2026
- Siemens Community, “Basics of setting Group Customer Defaults and Site Customer Defaults” (UGII_GROUP_DIR, UGII_SITE_DIR, Defaults Level), and Swoosh Technologies, “How To Define the Defaults Level of Customer Defaults” (site, group and user levels, locking), retrieved 29 September 2026
- Atlassian, Confluence Cloud REST API v2, Page (scope
read:page:confluence, only pages the user may view), developer.atlassian.com, retrieved 29 September 2026
