# How to add AI to Teamcenter on-prem without moving your PLM data > Source: https://netray.co/erp-help/private-ai-layer-teamcenter-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Run an open-weight model on your own GPUs, expose a small set of read-only Teamcenter actions through a tool server that calls the Teamcenter SOA web services as the asking user, and index documents and datasets locally. Teamcenter's Access Manager keeps deciding who sees what, so the assistant cannot show a user anything their own session could not open. ## Kind advanced ## System on-prem-apps ## Erp Siemens Teamcenter (on-prem) ## Module Private AI layer / SOA / Access Manager ## Query how to add AI to Teamcenter on-prem ## Alternate Queries - Teamcenter AI integration without cloud - Teamcenter private LLM architecture - chat with Teamcenter data on-premises - Teamcenter air-gapped AI assistant ## Applies To Teamcenter 13.x, 14.x and 2312 or later, Oracle or SQL Server database, Active Workspace optional. Details vary by version and BMIDE customisation. ## Steps ### Reference build for a private AI layer on Teamcenter **Items:** Inventory what the assistant must answer: item and revision lookups, BOM questions, change status, dataset and document content, workflow tasks. Each question class maps to a Teamcenter data path. Pick the access path per class. Use the Teamcenter SOA services (Core, Query, Cad and Workflow service families) for anything permission sensitive. Use a database replica only for aggregate analytics on attributes that carry no restrictions. Stand up a tool server (MCP or plain HTTP) with a handful of read actions such as find_item, get_revision_properties, expand_bom, list_open_changes, search_documents. No free-form SQL against the production database. Build a retrieval index over dataset text (PDF, Office, text exported from the FMS volumes) and over item metadata. Store the ACL context of each chunk alongside the vector so retrieval can be filtered. Serve an open-weight model with vLLM (or Ollama for a pilot) on local GPUs, behind your own reverse proxy, with no outbound route. Keep the embedding model local too. Pass the user identity from your SSO into every tool call, so SOA calls run with that user's Teamcenter group, role and project. Log prompt, tools called, object UIDs returned and answer to an append-only audit store. Roll out in phases: read-only questions for one group, then drafted outputs (change summaries, review packages), then approved actions through supported SOA operations with a human click. ## Sections ### Real data access paths in Teamcenter **Body:** Teamcenter stores its object model in Oracle or SQL Server through the POM (persistent object manager). Item, ItemRevision, BOMView and Dataset objects sit in tables such as PITEM, PITEMREVISION and PWORKSPACEOBJECT, with files kept outside the database on FMS volumes. The schema follows your BMIDE data model, so customised properties live in extra tables and the layout differs between sites. The supported way in is the SOA layer: web services hosted in the Teamcenter web tier, exposed over a JSON REST binding as well as the Java and .NET client bindings. Operations such as saved queries, getProperties and BOM expansion enforce Access Manager rules because they run inside the user's session. Active Workspace adds a Solr based index that can serve fast search. A direct read from a replica is useful for counting and trending, but it bypasses Access Manager, ip_classification and gov_classification style checks and project scoping. Treat it as analytics only unless you rebuild those rules yourself, which is rarely worth it. **Code:** -- Read-only analytics on a reporting replica (verify names against your BMIDE model) SELECT i.pitem_id, w.pobject_name, w.pobject_desc FROM PITEM i JOIN PWORKSPACEOBJECT w ON w.puid = i.puid WHERE i.pitem_id LIKE 'A-1%' FETCH FIRST 50 ROWS ONLY; # Permission-aware read: SOA call through the web tier as the asking user # Pattern: POST /tc/JsonRestServices// # Core-2006-03-DataManagement / getProperties with the object UIDs and property names, # sent with the user's own authenticated session (SSO or login service). ### Reference architecture **Body:** Keep the layers separate. A Teamcenter web tier and Active Workspace stay as they are. Beside them sit a reporting replica (or a periodic extract), a document extraction worker that reads FMS volumes through a service account limited to released data, a vector index, a tool server and the model host. The model host holds the open-weight model on vLLM and nothing in this chain needs the internet. For an air-gapped site, import model weights and Python wheels through your normal media transfer process, pin versions, and keep the container registry local. Retrieval, embeddings, reranking, the tool server and the audit store all run on the same enclave. The AI layer then has the same network posture as the PLM itself. Change data capture is optional. Teamcenter does not give you a single clean change feed, so most sites re-index by last modified date per object class on a schedule, plus event hooks for released revisions if the team already uses workflow handlers for integrations. ### Permissions, write-back and audit **Body:** Access Manager evaluates a rule tree plus ACLs per object, then project membership and group or role. The assistant should never hold a superuser session. Resolve the caller's Teamcenter identity from SSO, call SOA as that user, and filter retrieval chunks by a stored access marker that is revalidated through SOA before text is shown. Excluded objects appear as 'not found', not as 'restricted', so existence is not leaked. Write-back stays narrow. Creating a change request draft, attaching a note or starting a workflow are all supported SOA operations. Present the exact payload to the user, require approval, execute under their identity, and log it. Do not let the model emit arbitrary SOA calls or update properties in bulk. The audit record should hold the user, timestamp, question, retrieved object UIDs and revision IDs, tool calls and answer. For controlled technical data, this record, together with the enclave boundary, is what your export control officer will want to see. ### Sizing and phased rollout **Body:** A pilot for 20 to 50 engineers with a 7B to 14B class model for routing and a 30B to 70B class model for answers typically fits one to two data-centre GPUs with 48 to 80 GB each. Departmental use for a few hundred named users often lands at two to four GPUs plus a separate smaller box for embeddings and the index. A vector index over a few hundred thousand documents is usually tens of GB, not hundreds. Phase one is read-only: where used, BOM comparison, revision history, document Q and A. Phase two drafts artefacts: ECR summaries, review checklists, supplier change notices. Phase three triggers supported actions after approval. Measure answer accuracy against a test set of questions your engineers already ask before each phase gate. ## Pitfalls - Reading production tables directly and treating the result as permission safe. Access Manager and project scoping are applied by Teamcenter, not by the database. - Indexing every dataset into one shared vector store with no access marker, so a retrieval hit can surface text a user could not open. - Giving the assistant a privileged service account for convenience. Run calls as the user, or filter strictly. - Assuming schema names are identical across sites. BMIDE customisation and version changes alter tables and property names. - Letting the model compose free-form SQL or SOA payloads. Expose named, parameterised actions only. - Ignoring CAD and binary content. Text from JT, CATIA or NX files is not retrievable by a generic text pipeline, so scope expectations. ## Ai Angle A grounded assistant on Teamcenter answers 'which open changes affect revision C of this assembly' by calling the saved query and where-used operations as the user, then explains the result and shows which calls it made. Netray builds this as a custom private AI layer, with ERPray style read-only behaviour, local models and an audit trail, delivered with PLM partners where needed. ## Faq ### Can Teamcenter AI run fully air-gapped? **Answer:** Yes. The model, embeddings, index and tool server all run on local hardware, and Teamcenter does not need internet access. Weights and software arrive through your controlled media transfer process. Updates are then a planned import, not an automatic download. ### Is Siemens' own AI enough? **Answer:** If your data and policies allow the vendor's cloud features and your questions stay inside what they cover, use them first. A private layer makes sense when data cannot leave your network, when you need ERP, MES and PLM questions answered together, or when you want to choose the model. ### Does the assistant bypass Access Manager? **Answer:** It should not. Permission sensitive reads go through SOA as the asking user, and retrieval chunks carry access markers that are rechecked before display. Direct database access is reserved for aggregate analytics on unrestricted attributes. ### How is write-back handled? **Answer:** Only through supported SOA operations, shown to the user as an exact payload and executed under their identity after approval. Nothing is written autonomously, and each action is logged with the object UIDs it touched. ## Search terms Teamcenter AI integration, Teamcenter on-prem AI, Teamcenter private LLM, Teamcenter SOA REST, Teamcenter Access Manager AI, chat with Teamcenter, air-gapped PLM AI, Teamcenter RAG, PLM AI assistant on-premises --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json