# How to Add AI to the AVEVA PI System On-Prem, Without Moving Data to a Cloud

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

## Short answer

Put a read-only tool server in front of PI Web API, index the PI AF asset model plus your SOPs and shift logs, and serve an open-weight model on local GPUs. The model asks tools for bounded summaries instead of raw tag data, and every call runs with the asking user's PI identity and is logged.

## Kind

advanced

## System

on-prem-apps

## Erp

AVEVA PI System (OSIsoft PI)

## Module

PI Data Archive / PI AF / PI Web API

## Query

how to add AI to AVEVA PI System on-prem

## Alternate Queries

- PI System AI integration without cloud
- chat with PI historian data using a local LLM
- PI Web API read-only service account for AI assistant
- air-gapped AI for OSIsoft PI

## Applies To

PI Data Archive 2018 and later, PI AF 2018 and later, PI Web API 2018 and later. AVEVA PI Server and PI Vision on Windows, on-prem or private cloud.

## Steps

### Reference build, in order

**Items:**

- Stand up a read-only service identity in PI (a PI Identity mapped to a Windows group) with read access to the points and AF branches in scope, and nothing else.
- Put PI Web API behind a reverse proxy on the same network zone as the AI servers. Use Kerberos or the auth mode your site already allows; do not open it to the internet.
- Export the PI AF hierarchy (elements, templates, attributes, units, descriptions, categories) on a schedule and index it so the assistant can map a plain-language question to the right WebIds.
- Index documents that explain the process: SOPs, alarm rationalization sheets, MOC records, shift logs, lab results exports. Keep the source ACL with each chunk.
- Write a small tool server (MCP or plain HTTP) with approved read tools: current value, recorded values with a point cap, summary by interval, event frames in a window, element search.
- Serve an open-weight model with vLLM or Ollama on local GPUs and give it only those tools. Do the arithmetic in the tools, not in the model.
- Log every question, tool call, WebId, time range and row count to an append-only store the security team can read.
- Roll out in three phases: read-only questions, drafted shift summaries and event frame annotations, then approved write-backs to the systems that support them.

## Sections

### Where the data actually lives and how you reach it

**Body:**

The PI Data Archive stores time-series values per PI point (tag). PI Asset Framework (PI AF) adds the model on top: elements built from templates, attributes whose data references point to PI points, event frames for batches, downtime and excursions, and analyses. The AF database itself sits in SQL Server, but supported access goes through the AF SDK (.NET) or PI Web API rather than direct SQL.

PI Web API is the natural integration layer for an AI service because it is plain REST over HTTPS and returns WebIds that you can cache. For BI-style access you also have PI SQL Client or PI OLEDB Enterprise over AF, and PI Integrator for Business Analytics to publish PI data to a relational target. Pick one read path per use case and stick to it.

The first design decision is granularity. A language model should never receive a million raw samples. Ask the tool for a summary (average, min, max, count, time in range) over an interval, or for the last N recorded values, and let the model reason over that.

**Code:**

# 1. Resolve a tag to a WebId (read-only)
GET https://pi-web.plant.local/piwebapi/points?path=\\PIARCH01\FIC-101.PV

# 2. Hourly averages for the last 24 hours
GET https://pi-web.plant.local/piwebapi/streams/{webId}/summary?startTime=*-24h&endTime=*&summaryType=Average&summaryDuration=1h

# 3. Last 200 recorded values, capped by the tool server
GET https://pi-web.plant.local/piwebapi/streams/{webId}/recorded?startTime=*-8h&endTime=*&maxCount=200

# 4. Event frames in a window for an AF database
GET https://pi-web.plant.local/piwebapi/assetdatabases/{dbWebId}/eventframes?startTime=*-7d&endTime=*&searchMode=Overlapped

### Reference architecture, including the air-gapped option

**Body:**

Keep the AI stack on the business side of your network and do not point it at the control-level archive. A common pattern is a business-level PI Data Archive fed by PI to PI from the plant-level collective, so a runaway query lands on a replica and not on the server your operators depend on. PI Web API, the tool server, the vector index and the model server then live in one zone with a firewall rule set that allows only the tool server to reach PI Web API.

The retrieval index has two halves. One is the AF model and tag metadata (names, descriptions, engineering units, categories), which is how the assistant finds the right signal. The other is unstructured text: SOPs, MOC packages, shift handover notes. Rebuild the first nightly and the second on change.

For a fully air-gapped site, ship model weights and container images in on approved media, run the embedding model locally too, and keep the audit log on the same isolated network. Nothing in this design needs an outbound connection.

### Permissions: mirror PI security, do not replace it

**Body:**

PI security is layered: PI Identities and PI Mappings tie Windows principals to access, points carry their own data access permissions, and AF objects have security descriptors per element and database. The assistant must not become a side door around that model.

The cleanest route is to call PI Web API as the end user (Kerberos with constrained delegation, where your IT team supports it) so PI itself denies what the user cannot read. If that is not practical, use a service account but filter the tool results and the retrieval index against a copy of the user's group membership and a per-role allow list of AF branches.

Test this explicitly. Ask the same question as a process engineer and as a contractor account, and confirm the contractor gets an honest 'I cannot see that' rather than a partial answer.

### Write-back, sizing and a realistic rollout

**Body:**

PI is mostly a system of record for history, so most value comes from read access. Where writes make sense (adding an annotation to an event frame, recording a manual lab value), do it through PI Web API with a human approving the exact payload. Never let an AI service write setpoints or commands toward the control system, directly or through PI.

Sizing is driven by concurrent questions, not by data volume. As a rough range, a single 24 to 48 GB GPU running a 7B to 32B class model can serve a department of tens of users who ask a few questions each per day; a few hundred active users usually means two to four GPUs plus headroom for long contexts. The retrieval index for tens of thousands of documents is a few GB to low tens of GB.

Phase 1 is read-only questions and trend summaries for one unit. Phase 2 adds drafted shift reports and excursion write-ups that a person edits. Phase 3 adds approved annotations and ticket creation in your maintenance system.

### Honest limits and when you do not need this

**Body:**

A language model is poor at reading dense, high-frequency signals and at noticing slow drift, so do not use it as a replacement for PI Vision displays, PI Analysis Service rules or PI Notifications. It is good at finding the right signal from a vague question, explaining context from documents, and drafting write-ups from summaries you computed.

Poor tag hygiene limits quality. If points are named with legacy cryptic codes and have empty descriptions, expect a metadata cleanup phase before answers get good. If you only need trends and alerts and your staff already use PI Vision and AF analyses well, adding an assistant may not pay back. AVEVA also offers its own cloud analytics options; they are a reasonable choice if cloud is acceptable for the data in question.

## Pitfalls

- Letting the assistant query PI directly with a broad admin account, which silently bypasses point and AF security.
- Returning raw samples to the model instead of summaries, which wastes context and produces confident but wrong arithmetic.
- Pointing heavy queries at the plant-level archive during production instead of a business-level replica.
- Indexing tag names without descriptions and units, then wondering why the assistant picks the wrong signal.
- Treating PI as a control path. PI is not the place to write setpoints, and an AI service must not be given that ability.
- Skipping the audit log because 'it is read-only'. Security teams will still ask who looked at what.

## Ai Angle

ERPray and Netray's custom builds connect this PI layer to your ERP, so a question like 'why was line 3 scrap high on Tuesday night' can combine PI excursions with work orders, lots and quality records, with the tool calls shown to the user. DataRay covers the document half on-prem.

## Faq

### Does the AI need access to every PI point?

**Answer:** No. Give the service identity read access only to the points and AF branches in scope for the first use case, and expand deliberately. A smaller catalog also gives better answers because there are fewer look-alike tag names to confuse retrieval.

### Can it work with PI Web API only, without the AF SDK?

**Answer:** Yes. PI Web API covers points, streams, summaries, AF elements and attributes, and event frames, which is enough for a read-only assistant. The AF SDK is useful for heavy bulk jobs but is Windows and .NET only.

### Is a local model accurate enough for plant questions?

**Answer:** For retrieval, summarising and drafting, current open-weight models in the 7B to 70B range are usable when they are given good tools and sources. Quality depends more on metadata and tool design than on model size. Measure it on your own question set before rollout.

### What about AVEVA Data Hub or other cloud options?

**Answer:** They are valid if your data policy allows cloud. This page is for sites that cannot or will not send process data off site, such as defense, aerospace and regulated plants.

## Search terms

AI for AVEVA PI System, PI System on-prem AI, PI Web API AI integration, chat with PI historian, OSIsoft PI local LLM, air-gapped PI System AI, PI AF retrieval augmented generation, private AI for process historian, PI Web API read-only service account, MCP server PI System

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