AI Assistant & Wizards
The Mirox platform includes a built-in AI assistant you can chat with about your plants, plus a set of guided wizards that carry out concrete work for you — onboarding a new plant from its paperwork, verifying plant information, sorting and tagging files, and proposing a safe fix for a misbehaving plant VPN. Your organization stays in control of which AI powers it — the built-in service, your own Anthropic or OpenAI account, or a model you host yourself — and can see exactly how the assistant is being used and what it costs.
Concept
The AI features come in two complementary shapes:
- The chat assistant is conversational. You ask questions, it answers, and — when you allow it — it uses the same tools and data you already have access to. It is a companion for everyday work: understanding a plant's state, finding the right setting, or drafting a follow-up.
- The wizards are agentic. Instead of just answering, a wizard runs a short, supervised workflow toward a specific outcome and proposes the resulting changes for you to review and accept. Each wizard run keeps its full reasoning transcript so you can see exactly how it reached its proposals.
Everything the assistant does respects your existing permission system: the AI only ever sees and changes what you yourself are allowed to see and change. Cross-plant access through cooperations is honored just as it is everywhere else in the platform.
Info
The AI assistant and the wizards are the user-facing surface for working with AI inside the platform. For programmatic access to your data from your own scripts, use a scoped API token with the metrics export API and MiroxQL.
The Chat Assistant
Conversations
Each user has their own private conversations. You can create a new chat, rename it, browse your history, and delete conversations you no longer need. Conversations are personal to you — other members of your organization do not see your chats.
After your first exchange, the assistant automatically gives the conversation a meaningful title so your history stays easy to scan, without you having to name every chat by hand.
Transparency
You can control how much of the assistant's "thinking" you see. Three preferences are yours to set:
- Reasoning — show or hide the model's chain-of-thought as it works through an answer. On by default.
- Tool calls — show or hide the individual actions the assistant takes on your behalf (looking something up, fetching a value), so you can verify what it actually did. On by default.
- Per-turn statistics — show or hide timing and token figures for each response. Off by default.
Reasoning and tool calls are shown by default on purpose. Without them an answer arrives from nowhere, and you cannot tell whether the assistant actually consulted your data or simply sounded confident. Seeing which tools ran is what makes an answer checkable. Turn them off if you prefer a cleaner conversation — the setting follows you across devices.
Choosing How Hard It Thinks
Beside the message box you can set the reasoning depth for your next question — from a quick answer to deep analysis, or off entirely. Deeper reasoning takes longer and costs more tokens; a short factual lookup rarely needs it. The setting applies to the next message you send, so you can raise it for one hard question and drop it again afterwards.
Choosing Who Answers
If your organization has configured more than one AI provider, you can also pick which model answers, right next to the reasoning selector. The picker lists only models your organization has enabled and that have been verified to work, grouped by provider.
- The choice applies to your next message, so you can switch mid-conversation without interrupting an answer in progress.
- Your pick is remembered per conversation — reopening a chat resumes on the model it was using.
- When a conversation has been answered by more than one model, each message shows which one produced it.
If your organization has only one model available, the picker is hidden entirely — there is nothing to choose, and naming the model would only add noise.
Attachments
You can attach files to a conversation — a datasheet, a screenshot, a document — and ask the assistant about them. Attachments are stored securely and tied to your conversation.
Your Usage at a Glance
You can see your own AI usage for any time window: how many requests you made, how many tokens went in and out, and the resulting spend. This keeps the cost of the assistant transparent at the individual level.
Tips
A bulk cleanup is available: you can clear all of your own chat conversations and their attachments in one step. This only removes the chats you started yourself — it leaves any wizard-driven runs in your history untouched.
Wizards
A wizard is a guided, AI-driven workflow aimed at a single concrete outcome. You start a run, optionally provide source documents, and let it work. The wizard then either proposes a set of changes for you to review — accept or reject each one, or accept them all at once — or produces one structured result it applies for you. Throughout, a live transcript shows you what the AI is doing, and you can cancel a run at any time.
Every wizard run is preserved after it finishes, not just shown live. Each run keeps its complete reasoning transcript together with every action it proposed and the decision you made on each one, so you can return later and review exactly what the AI did and what you approved. Automated, agent-driven flows run as wizards too — so there is no AI activity without a reviewable record.
The platform currently offers five wizards you can start yourself:
| Wizard | What it does | Documents needed |
|---|---|---|
| Onboard a New Park | Reads one or more source documents, extracts the plant's metadata, and proposes the actions to create and fill in the new plant — which you review before applying. | Yes |
| Verify Park Information | Reads a plant's already-uploaded documents and proposes metadata corrections (basics, dates, business details, components, contacts) wherever the documents support a value. | No |
| Upload File | Analyzes the files you upload, then tags and sorts them into document storage so they are easy to find again later. | Yes |
| VPN Auto-Heal | Analyzes a direct plant VPN's recent connection logs and proposes a safe configuration fix — it never regenerates keys or certificates. | No |
| Auto-Tag a File | Takes a file already in your document storage and derives its category, a short summary, and keywords from its content. | No |
Review Before It Counts
The wizards that change your data work in propose-then-apply style: nothing is written until you approve it. You stay the decision-maker — the AI only does the preparation and suggests the result.
Reviewing AI Work in the Audit Trail
Some automated AI work runs on your behalf in the background rather than as a wizard you start — most notably the short activity summaries you see on browser-proxy sessions. You do not launch these directly; they appear as part of the access audit trail. The wizard list above covers everything you start yourself.
Organization AI Configuration
Your organization decides which AI runs the assistant. Out of the box that is the Mirox AI infrastructure and nothing needs configuring. Beyond that, an organization can connect its own AI accounts — as many as it likes — and choose which of their models members may use.
Bringing Your Own AI
Three kinds of provider can be added, and an organization can run several side by side:
| Provider | What it is | You supply |
|---|---|---|
| Mirox AI | The built-in service. Always present, nothing to configure. | Nothing |
| Anthropic (Claude) | Your organization's own Anthropic account. | Your API key |
| OpenAI (ChatGPT) | Your organization's own OpenAI account. | Your API key |
| Your own endpoint | Any OpenAI-compatible service you operate or subscribe to — a self-hosted model server, a gateway, or a regional provider. | Endpoint address + key |
Adding several is deliberately supported: you might keep the built-in service for everyday questions, add a frontier model for hard analysis, and point a third entry at a model running on your own infrastructure. Members then choose per conversation, and one provider is marked as the organization's default for new chats.
More Providers Over Time
The provider list is designed to grow. Because the platform's capabilities are exposed to any model through the same interface, supporting a new vendor is a matter of adding its connection — not of rebuilding the assistant. Anything speaking the OpenAI-compatible protocol can already be connected today through Your own endpoint, without waiting for a dedicated entry.
The Organization's Access Key
Each provider you add carries its own key, scoped to your organization.
- The key is encrypted before it is stored and is never shown again — not to members, not to other administrators, not through any API response. You can replace it at any time; you cannot read it back.
- It is used only to talk to that provider on your organization's behalf. It is never sent to another vendor, never embedded in a page, and never handed to the model itself.
- Removing the provider removes the key with it.
Because the key is your organization's, that provider's usage is billed to your account with them, not through Mirox.
Choosing Which Models Members May Use
Adding a provider does not expose everything it sells. An administrator curates the list:
- Discover — the platform asks the provider which models the key can reach and lists them.
- Enable — you tick the models you want available to members.
- Verify — as you enable each one, it is actually tested against your key before it becomes selectable.
That third step is the point. Providers publish long catalogs, and a given key may not be entitled to every entry — some models are unavailable on your plan, some cannot use tools at all. A model that fails verification is not offered, with the reason shown inline.
Why Verification Matters
The assistant is only useful when it can actually reach your data, which means the model must support tool calling. Rather than trusting a vendor's catalog, the platform confirms each model works with your key before members can pick it. You never see an option that would fail when you use it.
If a provider becomes unreachable or a key is revoked, the platform reports it plainly instead of failing silently, and members fall back to what still works.
Who Can Configure This
Adding providers, storing keys, curating models, and setting the organization default are reserved for organization Administrators and Moderators. Other roles — including the technical and commercial asset-manager roles — use the assistant under that configuration and never see the keys.
Organization Usage Overview
Administrators also get an organization-wide view of how the AI is being used over any time window:
- Total successful and failed requests, input/output tokens, and spend.
- The top members by usage and spend.
- The top plants by usage and spend.
- The total number of conversations across all members.
This makes it easy to understand adoption and keep AI cost predictable across the whole organization. An administrator can also clear every member's chat conversations from the organization's AI settings view when needed.
Where Your Data Goes
By default the assistant runs on the Mirox AI infrastructure: models hosted on Mirox-operated infrastructure in Germany (EU). This is a fixed, off-the-shelf model that is never trained or fine-tuned on your data. When the assistant gets more capable over time, that comes from better platform integration — new tools and tighter data access — not from learning on anything you do. Using the Mirox AI infrastructure is included in your plan.
If your organization connects its own provider, the content of your requests goes to whoever you chose, under their terms, and their token usage is billed to your account with them.
| Mirox AI (default) | Anthropic / OpenAI | Your own endpoint | |
|---|---|---|---|
| Where requests are processed | Mirox-operated infrastructure in Germany (EU) | That provider's infrastructure, under its terms | Wherever you run or buy it |
| Training on your data | Never — fixed, off-the-shelf model | Governed by your agreement with the provider | Governed by your own setup |
| Cost | Included in your plan | Paid to the provider per token | Your own arrangement |
| Who configures it | — | Organization Administrator or Moderator | Organization Administrator or Moderator |
Choosing a provider changes where requests are processed — never which features are available. Every AI surface runs through the same platform capability layer, so a frontier model and the built-in one reach exactly the same tools, under exactly the same permission checks.
What an External Provider Actually Receives
This is the distinction that matters for a security review, and it is a deliberate design decision.
When you use an external provider, it receives your conversation — your questions, and the results of any tools the assistant ran to answer them. It does not receive access to your platform.
- Tools always run from Mirox. When a model decides it needs data, it does not fetch anything itself. It says which capability it wants, Mirox executes that call under your permissions, and only the result is sent back into the conversation.
- No provider is ever given a key to your account. The credential that authorizes platform capabilities never leaves Mirox. A model cannot use it, replay it later, or reach anything you did not ask about in that turn.
- Your platform is never exposed to the provider's network. There is no inbound path from a model vendor into Mirox.
The practical consequence: swapping providers, or a provider having a bad day, cannot widen what the AI is able to reach. The permission boundary is enforced on our side of the conversation, not trusted to the model's.
Why Not Let the Model Connect Directly?
Some AI vendors offer to connect to a customer system themselves, which removes a round trip. Doing that would mean handing that vendor a standing credential to your platform data — and it only works for vendors that offer it, which would quietly break the promise that every provider reaches the same capabilities. Mirox keeps execution on its own side instead: slightly more work per answer, and one consistent, auditable boundary regardless of which AI you choose.
What the AI Can Never Do
For a plant operator weighing whether remote AI is safe, the limits matter as much as the features. By design, the assistant cannot:
- Send commands to plant equipment. It has no capability to operate or control inverters, PLC/SPS controllers, network switches, routers, or dataloggers. Its capability catalog contains read tools and propose-only draft tools — there is no field-device command tool anywhere in it.
- Connect to your plant network. The AI never opens a connection into a plant's local network. It only reads data the platform has already collected and stored.
- See keys, credentials, or secrets. VPN keys, certificates, pre-shared keys, API tokens, and passwords are never exposed to the model. The VPN Auto-Heal wizard, for example, proposes a configuration correction without ever seeing the underlying keys.
- Write anything without your approval. Every data change is staged as a proposal and applied only after you explicitly accept it (see Wizards).
- Exceed your own permissions. The AI inherits your exact access. It can never reach a plant, portfolio, document, or organization you yourself are not authorized for — and never another customer's data.
Where AI Is Used in Mirox
Mirox uses AI in a few distinct places. The table below is the complete inventory, marking which are something you start and which run automatically. The automatic ones only enrich metadata — they never change your records' substance — and what they did is visible afterwards in the relevant history or audit trail.
| Surface | How it runs | What it does |
|---|---|---|
| Chat assistant | You start it | Conversational help across your data, within your permissions. |
| Guided wizards | You start it | Multi-step workflows that propose changes for your review (onboarding, verification, file sorting, VPN auto-heal). |
| External AI tools (MCP) | You start it | Your own AI client, connected with your token, working under your permissions — see Agentic Access (MCP). |
| File auto-tagging | Automatic | Derives a category, summary, and keywords for a newly uploaded document; visible in the file's history. |
| Access-session summaries | Automatic | Writes a short, plain-language summary of a browser-proxy access session; visible in the audit trail. |
| Device identification | Automatic | Helps label devices found during network discovery from packaged fingerprint evidence; it receives evidence, not live network access. |
The automatic helpers are non-destructive: they add descriptive metadata so things are easier to find and review later. None of them issues commands, opens connections, or changes a record's core data.
Security and Control
- Same permissions as you. The assistant and the wizards operate strictly within your own access rights. They can read and change only the plants, portfolios, and documents you are authorized for, and cooperations are honored exactly as elsewhere.
- You approve changes. Wizards that modify data propose their work for your review; nothing is written without your acceptance.
- Personal by default. Your conversations are private to you. The organization-wide views show usage figures and let an administrator wipe chats — they are not a window into the content of other people's conversations from the everyday chat surface.
- Encrypted keys. Every provider key your organization stores is encrypted at rest, scoped to your organization, and never readable back — by anyone, through any surface.
- The provider never holds your access. External models receive the conversation, never a credential to your platform; capability calls are executed by Mirox under your permissions (see What an External Provider Actually Receives).
Restricting the AI
There is no separate "AI off" switch, and there does not need to be: the AI has no access of its own. It only ever borrows the permissions of the person using it. That means you restrict the AI by restricting the person — narrow a user's organization role or per-plant job roles, pause their membership, or set an account to External with no default access, and the AI follows the same limits the moment they take effect. The mechanics are exactly those of the permission system and member permissions. At the organization level, an administrator or moderator can also decline to connect any external provider, in which case requests only ever reach the Mirox AI infrastructure.
What It Costs
Using the Mirox AI infrastructure is included in your plan — there is no separate AI charge for it. If your organization connects its own provider, that provider bills your organization directly for its token usage, on top of your Mirox plan; the same applies to an endpoint you operate yourself. The usage views above make spend visible either way, per member and per plant.
Because a model's cost varies enormously, letting members pick per conversation is a cost lever as much as a quality one: a quick lookup can run on the included service while a hard analysis runs on a frontier model.
Related Features
- Agentic Access (MCP) — connect your own external AI agent under your exact permissions, using the same tools the assistant uses
- API Tokens — scoped, revocable credentials for programmatic access to reporting and time-series data
- Permission System — the roles and cooperations that bound everything the assistant can see and do
- Audit Logging — where automated AI activity summaries surface alongside VPN and proxy access records
- Onboarding — the onboarding checklist where the park-onboarding wizard fits in
- Resources — document storage, which the file wizards tag and organize for you
- AI FAQ — common questions about AI safety, data handling, and control