# How to add AI to GE Proficy (Historian and Plant Applications) on-prem > Source: https://netray.co/erp-help/private-ai-layer-ge-proficy-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Keep Proficy where it is and put a read-only AI layer beside it. The assistant reaches Historian through its documented OLE DB provider or client SDK, reaches Plant Applications through its SQL Server database or a reporting copy, and runs an open-weight model on local GPUs. No tag data leaves the site, and every question and query is logged. ## Kind advanced ## System mfg-systems ## Erp GE Proficy (Historian, Plant Applications) ## Module Proficy Historian / Plant Applications ## Query how to add AI to GE Proficy Historian on-prem ## Alternate Queries - GE Proficy AI integration without cloud - Proficy Plant Applications LLM on-prem - chat with Proficy Historian data locally - Proficy Historian OLE DB query for AI ## Applies To Proficy Historian (on-prem server editions), Proficy Plant Applications on SQL Server, Windows Server hosts. Verify object names against your installed version. ## Steps ### Reference rollout for a private AI layer on Proficy **Items:** Inventory what you actually run: Historian server and collectors (OPC, iFIX, other), Plant Applications database, and which tags and units operators and engineers ask about. Create a dedicated read-only service identity for Historian and a db_datareader-style login for a reporting copy of the Plant Applications database. Never reuse an operator or admin account. Stand up a reporting copy of the Plant Applications SQL Server database (readable secondary, log shipping or scheduled restore) so AI queries never compete with production reporting. Decide the tag scope: build an approved list of tags and calculated values the assistant may read, keyed by area, line and unit, and store it as configuration. Build a tool server (MCP or plain HTTP) that exposes a small set of approved read actions: get tag trend, get events for a unit, get downtime summary, search procedures. Index documents the system does not hold itself: SOPs, control plans, batch records, maintenance notes and tag descriptions, with the area and unit as metadata for filtering. Serve an open-weight model with vLLM or Ollama on local GPUs and let it call only the tool server. Log every prompt, tool call, query text and result row count. Pilot with one line for 4 to 6 weeks, read-only questions only, and measure answer accuracy against a list of questions an engineer already knows the answers to. ## Sections ### Real data access paths in Proficy **Body:** Proficy Historian stores time-series data in its archive files and exposes it to clients through a documented OLE DB provider, an Excel add-in and a client SDK. For an AI layer the OLE DB provider is usually the easiest route because it behaves like a SQL data source: you query raw or interpolated tag values with a tagname and a time range. Tag metadata (descriptions, engineering units, collector assignment) is available through the same provider. Plant Applications (the MES-style product that tracks events, production units, downtime, quality results and genealogy) keeps its configuration and history in a SQL Server database. Tables for events, production units, variables and test results are the ones most AI questions touch. Names differ between versions, so check the schema in your installation and build views over what you need rather than letting the model see raw tables. Prefer views and parameterised queries owned by your team. The model should choose a tool and its arguments, never write free-form SQL against the production database. **Code:** -- Historian OLE DB (verify column and sampling mode names for your version) SELECT tagname, timestamp, value, quality FROM ihRawData WHERE tagname = 'Line2.Extruder.Zone3.Temp' AND timestamp BETWEEN '2026-10-20 06:00:00' AND '2026-10-20 14:00:00' AND samplingmode = 'RawByTime' ORDER BY timestamp; -- Plant Applications reporting copy (illustrative, confirm against your schema) SELECT TOP 100 e.Event_Num, e.[TimeStamp], pu.PU_Desc FROM Events e JOIN Prod_Units_Base pu ON pu.PU_Id = e.PU_Id WHERE pu.PU_Desc = 'Line 2 Extruder' AND e.[TimeStamp] >= DATEADD(day, -1, GETDATE()) ORDER BY e.[TimeStamp] DESC; ### Reference architecture, including air-gapped **Body:** Place the AI layer in a zone that can reach Historian and the Plant Applications reporting copy but is not on the control network. Read from the reporting copy for relational data. For tags, query Historian through a read-only service account, ideally against a Historian instance or mirror that sits at the site or enterprise level rather than the one feeding the line. Components: a retrieval index over documents and tag descriptions, a tool server that wraps the approved queries, an open-weight model served by vLLM or Ollama, an identity layer and an audit log. Time-series answers should come from tool calls that return numbers, not from the model remembering values. The model explains and summarises; the query returns the facts. For an air-gapped plant, ship model weights and container images on approved media, keep the index and logs local, and disable any outbound telemetry in the serving stack. Updates become a controlled change, like any other software on the plant network. ### Permissions, write-back and honest limits **Body:** Mirror the access model you already have. Map each user to the areas, lines and units they may see, using the same groups that govern Plant Applications and Historian security. The tool server filters every query by that scope before it runs, and the retrieval index applies the same filter as metadata. If a user cannot open a unit in the Proficy clients, the assistant must not answer questions about it. Write-back should be rare. Plant Applications can be updated through its supported interfaces, so an approved action such as adding a downtime reason comment can be proposed by the assistant and executed only after a named person approves it. Never let a language model write setpoints or tag values toward the control layer. Limits: raw high-frequency data is large, so the assistant works best on aggregates and event windows, not on scanning months of one-second data. Older Proficy versions may lack interfaces you expect. If you only need trends and dashboards, the native Proficy clients are enough; the AI layer pays off for cross-system questions and for people who do not know the tag names. ### Sizing and phased rollout **Body:** A site with a few hundred daily users and a modest document set typically needs one to two inference GPUs in the 24 to 48 GB class for a 7B to 32B class model, plus a CPU server for the index and tool server. Larger models and many concurrent users raise that; use a sizing calculator with your own numbers rather than a rule of thumb. Phase 1 (weeks 1 to 6): read-only questions with cited sources and visible queries. Phase 2 (weeks 7 to 12): drafts such as shift summaries, downtime narratives and deviation write-ups for a human to edit. Phase 3: approved actions through supported APIs, each with an approval step and a log entry. Move to the next phase only when the accuracy review from the previous one is acceptable to the plant. ## Pitfalls - Letting the model write SQL against production tables. Use parameterised tools and views owned by your team. - Querying the live Historian from the AI layer at high frequency and slowing collection or client trends. - Indexing procedures without area metadata, so users see content from units they are not cleared for. - Trusting model-recalled numbers. Every number in an answer should come from a tool result shown to the user. - Putting the AI host on the control network. Keep it in a supervised zone with firewall rules limited to the sources it needs. - Skipping a baseline question set, so nobody can say whether the assistant is right. ## Ai Angle DataRay can sit over a Proficy reporting copy and document shares so engineers ask plain-language questions and see the exact query behind each answer. For deeper integration, Netray builds the tool server, retrieval index and local model serving on your hardware, with read-only defaults and human approval on anything that changes data. ## Faq ### Can an AI assistant read Proficy Historian without sending data to the cloud? **Answer:** Yes. The assistant queries Historian through a read-only service account over a documented client interface, the retrieval index lives on your server, and the model runs on local GPUs through vLLM or Ollama. Nothing needs to leave the site, and an air-gapped deployment works the same way. ### Does the model see raw tag data? **Answer:** Only what a tool call returns for that question and user. Tools return bounded aggregates or event windows, and the tool server enforces tag and unit scope. The model does not browse the archive. ### Is this safe to run near the control system? **Answer:** Keep the AI layer outside the control network, read-only, and fed from Historian or a mirror. It is advisory software, not part of a safety function, and it must never write to controllers or setpoints. ### When is the native Proficy tooling enough? **Answer:** If users only need trends, dashboards and standard reports, the Proficy clients cover it. Add an AI layer when people need questions across Historian, Plant Applications and documents, or cannot find the right tags. ### What hardware do we need? **Answer:** Usually one or two data-centre GPUs for the model plus a CPU server for retrieval and tools. The exact count depends on users, questions per day and model size, so size it from your own numbers. ## Search terms GE Proficy AI integration, Proficy Historian AI, Proficy Plant Applications AI, on-prem AI for historian, chat with historian data, Proficy Historian OLE DB, private LLM manufacturing historian, air-gapped AI plant data --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json