AI Assistant

QUBIQ includes an AI assistant that can answer questions about your plant and draft configuration. Its defining property is that it proposes changes rather than making them: a human approves before anything is applied.

It appears in three places, and they are not equivalent — see realms:

Where	Who is asking
The platform assistant	An engineer, at a keyboard
An AI Chat widget on a screen	An operator, on a panel anyone on shift can reach
An AI node in a pipeline	Nobody — the input is a webhook, an MQTT payload or an email body

This page is about governing it. Four companion pages cover the rest:

Page	Answers
Skills & fences	What an assistant is allowed to do, and what narrows it
Playbooks	How to write an answer procedure down once
Specialists	Saved sub-assistants it can hand a sub-question to
External systems	Letting it look something up in an ERP or a CMMS

Configuration

The assistant is configured in Settings → AI Assistant. Reading and changing its configuration — the model, its credentials, and which connections it may reach — requires Manage AI settings. Using it requires Use the AI assistant.

Manage AI settings is super-admin only by default, because it exposes billable API credentials and the assistant's kill switch.

Governing what it can reach

Per-connection access

Each connection is individually allowed or denied to the assistant. A connection the assistant cannot see does not appear in its context at all.

Deny by default and allow deliberately. The assistant does not need your ERP.

Read-only credentials

SQL, MongoDB and QuestDB connections can carry a second, read-only credential the assistant uses instead of the primary one.

Connection "MES"
  primary:  qubiq_rw    (used by pipelines)
  AI:       qubiq_ro    (used by the assistant — SELECT only)

Test it separately with Test AI credential on the connection (needs Edit connections) — the normal test only validates the primary login.

If the assistant may explore a production database, give it an account that cannot write. Enforce it at the database, not by instruction.

The propose-and-approve model

For anything that changes the system, the assistant produces a proposal. A human reviews it and approves or rejects.

Listing, approving, rejecting and abandoning proposals all require Use the AI assistant.

Proposals cover views, pipelines, alarms, named queries, tag relationships, file writes, tag writes and database writes. Nothing in that list is applied without approval.

Review proposals properly. A plausible-looking alarm setpoint or SQL statement is exactly the kind of thing that reads fine and behaves badly. The approval step is only worth something if it is a real review.

The capability switchboard

Settings → AI Assistant carries one switch per capability, applying to every assistant on the installation. Anything that did not exist in an earlier release arrives off, so an upgrade never silently widens what your assistants can do.

Reads

Capability	Default
Read tag values · Browse namespace · Read historian · Read alarms	On
Read files	Off
Search knowledge base	Off
Calculate playbook checks	Off
Ask specialists	Off
Let the assistant call external systems	Off

Proposals — every one of these produces a proposal a human approves, never a change:

Capability	Default
Propose tag writes · saved queries · views · pipelines · alarms · tag relationships · file writes	Off

Database read and write are not on that list. They are decided per connection, in a matrix, because "may read the MES, may not read the ERP" is the question people actually have.

Turning a capability off is the kill switch for it: it is withdrawn from every assistant, every widget and every pipeline node at once.

→ Skills & fences for how a capability combines with an assistant's skills, its realm and the asker's own permissions.

What it works from

The assistant is given the generated component catalog and the scripting API reference, kept in lockstep with the product, so it works from the real surface rather than plausible invention. Tag search uses your tag descriptions — another reason to write them.

Conversations

Chatting, and listing, reading or deleting past conversations, all require Use the AI assistant. Conversations are per user.

Throughput

Settings → AI Assistant → AI Throughput & Limits bounds how much AI work runs at once, and shows whether the current limits are holding — in use, peak, and whether a limit is the thing you are hitting.

Limit	Set it
Concurrent chat turns	People are usually reading, not asking — concurrency is far lower than user count.
Concurrent AI node runs	Below chat turns, on purpose: someone waiting at a keyboard should win.
Concurrent tool calls	Above the other two combined — one turn can make a dozen lookups.

Concurrent specialist runs is observed rather than set. A specialist is a whole second conversation, so it is bounded per person as well as overall: one operator asking three at once cannot use the pool up.

Audit attribution

Every AI-originated action is recorded with both identities: the assistant as the origin, and the human whose proposal it acted on as the actor.

An AI-initiated change is never anonymous, and the audit journal answers "who approved this" as well as "what made this change".

→ Audit journal

Data leaving the plant

Using a hosted model means plant context leaves your network — tag names, descriptions, schema detail, query results.

Before enabling it, decide:

• Is that acceptable to your security policy and your customer's?
• Which connections may be included? (Deny by default.)
• Do tag descriptions contain anything confidential?
• Is a self-hosted or on-premise model required?

On an air-gapped network the assistant simply will not reach a hosted provider, which is the correct outcome rather than a fault.

Governance checklist

• Manage AI settings held by administrators only
• Use the AI assistant granted deliberately, not to everyone
• Connections denied by default, allowed one at a time
• Read-only AI credentials on every permitted database
• Every instance's fences set explicitly — a fence is fail-closed, so an unset one reaches nothing, and * reaches everything
• No pipeline node fenced to * on connections or external systems
• External systems reviewed: a real pattern on every parameter, and the master switch off unless something needs it
• Runtime roles that carry an AI widget given an AI profile, or their operators get an assistant that can do nothing
• Proposals reviewed by someone competent to judge them
• Data-egress implications signed off
• Audit journal configured, so AI actions are attributable

Disabling it

Revoke Use the AI assistant from every role, or deny every connection. The kill switch lives behind Manage AI settings, so the assistant cannot be re-enabled by a user who merely uses it.

Next

→ Skills & fences — what an assistant is allowed to do

→ Playbooks · Specialists · External systems