# How to add AI to ENOVIA and on-prem 3DEXPERIENCE

> Source: https://netray.co/erp-help/private-ai-layer-enovia-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Read ENOVIA data through supported interfaces: MQL and the Java API (matrix.db.Context, JPOs) on the kernel, or the 3DSpace web services where deployed, always in the context of the asking user's person and security context. Serve an open-weight model on local GPUs and index documents locally, so Dassault's role and policy model keeps deciding what is visible.

## Kind

advanced

## System

on-prem-apps

## Erp

Dassault ENOVIA (on-prem)

## Module

Private AI layer / MQL / 3DSpace

## Query

how to add AI to ENOVIA on-prem

## Alternate Queries

- ENOVIA AI integration without cloud
- ENOVIA MQL query for AI assistant
- 3DEXPERIENCE on-prem private LLM
- chat with ENOVIA data on-premises

## Applies To

ENOVIA V6 and on-prem 3DEXPERIENCE (R20xx releases) with Oracle or SQL Server. Cloud 3DEXPERIENCE on Dassault's platform follows a different path.

## Steps

### Reference build for a private AI layer on ENOVIA

**Items:**

- List question classes: part, document and engineering item lookup, structure and where-used, lifecycle state and policy, change actions, and content Q and A over attached documents.
- Choose the interface per class. Use JPOs or Java API reads for custom schema, and the 3DSpace web services for standard modelers where they are deployed and secured on your platform.
- Build a tool server with named read actions that open a Context for the asking user, run bounded MQL or API calls and return structured results with object ids.
- Extract text from document files held in ENOVIA file stores via a worker, store type, name, revision, policy and state with every chunk, and keep an access marker.
- Serve a local open-weight model with vLLM, local embeddings and a local vector index. No outbound route from the model host.
- Carry the user's identity and security context into every call. Log all tool calls and the bus object ids returned.
- Phase in read-only Q and A first, then drafted change actions and review summaries, then supported lifecycle promotes and creates after approval.

## Sections

### Data access paths in ENOVIA

**Body:**

ENOVIA's kernel stores business objects (types, names, revisions), relationships, attributes, policies with states, and person, role and security context definitions. The native query language is MQL, and the Java API exposes the same model through classes such as matrix.db.Context and BusinessObject. Custom behaviour is usually written as Java Program Objects (JPOs) invoked by the kernel.

Do not read the underlying Oracle or SQL Server tables directly. The storage layout is internal to the kernel and bypasses access rules. On 3DEXPERIENCE platforms, the 3DSpace web services provide REST access to standard modelers behind 3DPassport authentication, and 3DSearch can provide index driven retrieval where deployed.

**Code:**

temp query bus Part * * where "current==Released" limit 50 select id name revision description current dump |;

// Java sketch: open a context as the asking user and run a bounded MQL read
Context ctx = new Context(serverUrl);
ctx.setUser(userName);
ctx.connect();
String out = MqlUtil.mqlCommand(ctx, "temp query bus Part A-10045 * select id revision current dump |");

### Reference architecture

**Body:**

Place the components in the same enclave as the ENOVIA application server: a tool server using the Java API or web services, a document extraction worker, a vector index, a GPU host and an audit store. Optionally use a reporting copy of the database for aggregate questions you have validated against MQL results, since schema meaning depends on your data model customisation.

Change feeds are not standard. Plan scheduled re-indexing by modification date per type, plus triggers or event hooks for lifecycle promotions if your team already maintains triggers for integrations. In an air-gapped site everything, including weights and packages, enters by controlled media.

### Permissions, security contexts and write-back

**Body:**

ENOVIA authorises users by person, role, organisation and project in a security context, then applies policy state access, ownership and any ABAC style rules your implementation adds. Opening a Context for the real user with the right security context makes the kernel enforce this, which is why the tool server must not use a shared administrator login.

For writes, use the same Java API or web service operations the applications use: create a change action, add a note, or promote a state through supported calls so triggers and policy checks fire. Show the user the exact payload, run under their identity, and log the resulting object. Do not let the model run raw MQL that modifies objects.

### Sizing, limits and honest trade-offs

**Body:**

A pilot for 25 to 60 engineers typically fits one to two GPUs of 48 to 80 GB. Wider rollout to several hundred named users plans two to four GPUs, separate CPU capacity for extraction, and an index of tens of GB for a few hundred thousand documents. Treat these as planning ranges and validate with a concurrency test.

Limits: heavy customisation means object names and attributes differ per site, so tool actions must be written against your model. Geometry and simulation data are not readable by a text model. If your users are already on cloud 3DEXPERIENCE and can use Dassault's own assistants, those may be enough; the private layer pays off when the platform is on-prem and the data cannot leave.

## Pitfalls

- Using one super-user Context for the integration and losing per-user security.
- Running free-form MQL composed by the model. Offer parameterised, read-only actions.
- Ignoring policy and state when quoting content, so an In Work revision looks like a released one.
- Querying kernel tables directly. Their layout is internal and bypasses access control.
- Assuming type and attribute names from a demo database. Production models are customised.
- Forgetting that triggers run on writes. Test write actions in a non-production environment first.

## Ai Angle

A grounded assistant on ENOVIA answers 'which released parts are affected by this change action' by running bounded reads as the user and presenting the objects with state and revision. Netray builds this as a private layer with local models, mirrored security and an audit log, delivered with Dassault-skilled partners where the data model is heavily customised.

## Faq

### MQL, JPO or web services: which should I use?

**Answer:** Use web services for standard modelers if they are deployed and secured on your platform, and MQL or JPOs for custom schema and exact control. Whichever you pick, wrap it in a named action in the tool server and keep it read-only.

### Does this apply to cloud 3DEXPERIENCE?

**Answer:** Not directly. This design targets on-prem ENOVIA and 3DEXPERIENCE where you operate the servers and control the data boundary. Cloud deployments have different APIs, tenancy and data residency questions.

### How are security contexts handled?

**Answer:** The tool server opens a Context for the real user with the matching security context, so the kernel applies its normal checks. Indexed chunks hold type, policy and state, and are re-verified by a live read before display.

### Can the assistant promote lifecycle states?

**Answer:** Only as a proposed action that the user approves, executed through supported calls under their identity so triggers and checks fire. Autonomous promotion is not recommended for controlled design data.

## Search terms

ENOVIA AI integration, ENOVIA MQL query, ENOVIA on-prem LLM, 3DEXPERIENCE on-prem AI, ENOVIA Java API JPO, chat with ENOVIA, ENOVIA private AI, ENOVIA RAG

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json