Skip to content
Proxus 2.0.1 Licence and sign-in fixes after the 2.0 upgrade Release notes
Try free Book a demo

Platform · AI Assistant and industrial AI

Ask your plant. The AI Assistant proposes; you approve.

Proxus AI Assistant is built into the hub. Ask from any screen in plain words and it answers from the live plant, with your permissions. It prepares changes, and nothing is applied until you approve. Your own assistants and agents reach the same governed model through an MCP interface, under the same rules.

Book a demo Watch the AI Assistant
AI Assistant
Built into the hub: Monitor > AI Assistant, or Ctrl+K on any screen
Changes
Proposed on a card and made only after you approve, in your name in the audit trail
AI service
Claude, OpenAI, Azure OpenAI, Claude on Amazon Bedrock or Google Vertex AI, or a local Ollama model
MCP
A Model Context Protocol server in your deployment, for your own assistants and agents

Inside Proxus

One question, a real answer, a proposal waiting for approval.

Recorded in the product, cursor and all · 0:15Simulated plant data

Access follows the data model.

Keep consumers within their authorized scope. AI assistants use governed, permission-limited access.

Industrial data within your perimeter Equipment sends data through an edge gateway to Governed access, then to Authorized consumers. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals EDGE Proxus Edge Collect / evaluate / buffer PLATFORM Governed access Roles / paths / scope Teams &applications Authorized scope AI assistants Governed access PLANT FLOORCONSUMERS Industrial data within your perimeter Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Governed access, then to Authorized consumers. Plant floor PLCs / CNCs / robots Proxus Edge Collect / evaluate /buffer Governed access Roles / paths / scope Authorizedconsumers AI uses governed access

What it solves

What teams run into without it.

  • AI on stale exports

    An assistant answering from last quarter’s spreadsheet is confidently wrong about this morning’s line.

  • No boundary on what it can see

    Handing a model a database credential is not an access policy.

  • No record of AI access

    Without an audit trail, nobody can say who used which tool or what data left the plant.

What you get

Built in, not bolted on.

  • AI Assistant on every screen

    Ask in plain words why a device is silent, what changed or which alarms are open. Each answer names the sources it read: devices, alarms, tag history, the audit trail, the docs.

  • Your permissions, nothing more

    The AI Assistant reads with the asking user’s role and plant-area limits. Passwords, keys, tokens and licence details are never read.

  • Changes you approve

    Any record you may edit comes back as a proposal card, one at a time, several at once or as one plan. A new alarm rule is first tried on stored data, so you see how often it would have fired. An approved change is made with your permissions and logged under your name.

  • Your choice of model

    Claude, OpenAI, Azure OpenAI, Claude on Amazon Bedrock or Google Vertex AI, or a local Ollama model when no data may leave the site. Monthly budgets per service, daily token limits per role.

  • Governed MCP server

    Your own assistants and agents query the same model as tools. MCP can be switched off, restricted to administrators, limited to read methods and rate-limited; every request is logged.

  • Insights without asking

    Noisy alarms, alarms nobody owns, unstable gateway links, frozen or unusual values and expiring certificates, found by fixed background checks. No AI service is used until you ask the AI Assistant about one.

What this enables

What the capabilities add up to, in practice.

  • Ask about the plant in plain words and get answers from live data, within your permissions
  • Let the AI Assistant prepare rules and changes that are applied only after someone approves them
  • Ground AI answers in current production data instead of stale exports
  • Give an assistant a permissioned scope rather than a database credential
  • Switch AI access off, restrict it to administrators or read methods, and rate-limit it
  • Review every request by user, tool and result, like any other integration

Proven in production

Running in production at these plants.

All deployments

Questions

What teams ask before the first call.

Ask something else
What is the Proxus AI Assistant?
An assistant built into the hub. Ask in plain words from any screen (Ctrl+K) or in Monitor > AI Assistant. It answers from the plant data you may read, names the sources it used, and prepares changes as proposal cards that are applied only after you approve them, in your name in the audit trail.
Which AI model does the AI Assistant use?
The one you choose: Claude, OpenAI, Azure OpenAI, Claude on Amazon Bedrock or Google Vertex AI, or a local Ollama model, with which nothing leaves your site. Administrators set a monthly budget per service and a daily token limit per role.
What is MCP and why does it matter here?
Model Context Protocol is an open interface that lets AI assistants call defined tools instead of scraping data. It matters because it turns "give the model database access" into "give the model a permissioned, audited set of operations".
Can AI change anything in the plant?
Only what the user is already allowed to do. The AI Assistant changes nothing on its own: each change is a proposal card that is applied only after you approve it, with your permissions. Changes that create or edit records can be undone; deletes and alarm decisions cannot, and the card says so before you approve. MCP offers read tools plus one write tool for create and update operations, limited to the signed-in user’s role and namespace-path permissions; deletes are blocked by default, and MCP can be limited to reading.
Does our production data leave the network?
That depends on the AI service you choose for the AI Assistant. With a cloud service, each question sends the question, the conversation so far and the plant data the assistant read to answer it (device names and states, latest tag values, alarms), and only what the asking user may read. With a local Ollama model, nothing leaves the site. With Amazon Bedrock, Google Vertex AI or Azure OpenAI, the data stays within your own cloud account. MCP runs inside your deployment; what an AI client you connect to it sends onward is your policy.
How do we limit what an assistant can see?
The same way you limit a person: roles and namespace-path permissions. MCP can also be switched off, restricted to administrators, limited to read methods and rate-limited.
Is AI usage auditable?
Yes. A change approved from the AI Assistant is in the audit trail under your name, with the assistant and the conversation as its source; conversations are kept in the hub, and AI Assistant Usage shows answers, tokens and estimated cost per service and per user. Every MCP request is logged with user, tool and result, like any other integration.
Does the AI Assistant work without internet access?
Yes, with a local Ollama model. The documentation the assistant searches ships with the hub, so it works offline too.
What does the AI Assistant cost to run?
The assistant uses your own key or cloud identity, so your AI provider bills you directly. Administrators set a monthly budget per service and a daily token limit per role.
Can the AI Assistant be wrong?
Yes. Each answer names the sources it read, so an important one can be checked on the screen it names, and nothing changes without your approval.

Continue

Two numbers set your price: the gateways you run and the data rate they carry. See pricing

Next step

Ask the AI Assistant about your own plant.

Bring one machine and one question about it. In the demo we connect it and ask the AI Assistant, and you decide whether to approve the change it proposes.

Book a demo Talk to an engineer

  1. Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. Roll-out

    The same templates bring the next lines and sites online.