AMDT AI Companion: The AI Features in octovision and How to Govern Them

The AMDT AI Companion is a natural-language chat that lets engineers, maintenance leads and security staff ask questions of their OT data: which controllers on line 3 run firmware below a given version, which sites have failing backup jobs, which assets carry critical vulnerabilities. AMDT introduced it as an “AI chat” in octoplant’s Spring Release 107 in April 2026, promising “clear answers based on your operational data”. It is one of four AI features AMDT describes on its innovation page, under a stated principle: “AI is optional. Control is not.”

This page explains what each AI feature does, where it is said to run, what AI on OT data is good and bad at, and what a plant should ask before switching it on. It sits under the octovision overview in the AMDT cluster.

What the AMDT AI Companion and related features do

Feature	What AMDT says it does	Where it runs	Human role
Companion	Lets users “interrogate OT data in natural language” and turns complex operational information into accessible answers	Not specified per deployment in public material	Asks the question, judges the answer
AI vulnerability guidance	Converts vulnerability findings into contextual next steps using available information and best practices	Designed for secure on-premises deployment	Decides patch, compensate or accept
AI lifecycle intelligence	Uses AI agents to build and maintain obsolescence and lifecycle data at the intelligence layer	At the intelligence layer, not on production devices	Verifies before budgeting on it
Controlled AI framework	“A reusable foundation for connecting approved AI models with specific data sources and applications”	Emphasises data sovereignty and on-prem options	Chooses which models are approved

Sources: AMDT innovation page and About octovision, as of October 2026. The vulnerability guidance is covered in context on the vulnerability management page, and the lifecycle data on the lifecycle and obsolescence page.

“AI is optional. Control is not.”

This is the most important line in AMDT’s AI positioning, and it is the right one for OT. AMDT states that its core capabilities work without AI, that AI is an additional analytical layer rather than a dependency, and that AI-supported functions “assist people with insight and guidance rather than autonomously changing production equipment”.

For a plant, that has three practical consequences:

• Nothing breaks if the AI is off. Backup, compare, change detection and inventory remain the system of record.
• There is no AI write path to the controller. As AMDT describes it, a device changes only through octoplant’s normal check-out and check-in cycle in the native engineering tool.
• The plant chooses the policy. A pharma site can leave AI disabled pending validation while a discrete plant in the same company enables it.

The data foundation argument

AMDT’s broader pitch is a data foundation for industrial AI, opening with the line “Industrial AI has a data problem before it has an AI problem.” The argument is that operational context sits in fragmented, proprietary formats across PLCs, SCADA and engineering tools, and that octoplant’s versioned history, structured by octovision, is the trusted context AI needs.

We think the argument is sound, with a qualifier. Version-controlled configuration data is exactly what an AI assistant needs to answer “what is running and how did it change?” But it is one part of plant context. Process values, alarms, downtime reasons and quality results live in historians, MES and the unified namespace if the plant has one. An AI that sees only configuration will answer configuration questions well and production questions poorly.

What AI on OT data is good at, and bad at

Good at:

• Retrieval across sites. “Which robots at the two Ohio plants have not had a successful backup in 30 days?” is a fair question for a chat interface over a structured inventory.
• Summarising long lists. Turning 600 CVE matches into a readable briefing for a plant manager.
• First-draft guidance. Suggesting the usual mitigations for a class of vulnerability, for an engineer to check.
• Lowering the skill barrier. A maintenance planner can ask without learning the report builder.

Bad at, or risky for:

• Knowing what it does not see. If 30% of assets are unmanaged, the answer is confidently incomplete.
• Plant-specific judgement. It does not know that a “low criticality” mixer feeds the only line with a customer audit next week.
• Precision where wording is ambiguous. Firmware naming and vendor lifecycle terms vary, and a fluent answer can hide a wrong match.
• Accountability. An auditor will accept a reasoned decision by a named engineer. They will not accept “the assistant suggested it”.

Governance questions before enabling the AMDT AI Companion

1. Which AI models does each feature use, and who approves a model change?
2. Where does inference run in our deployment, and does any prompt, answer or data leave the site?
3. What data can Companion read, and can access be scoped by site or role?
4. Are prompts and answers logged, and for how long?
5. Can each AI feature be disabled independently, per site?
6. How does the assistant signal low confidence or missing data?
7. For regulated sites: what is the validation position, and does AMDT provide documentation for it?

A framework to hang the answers on. The NIST AI Risk Management Framework, released in January 2023, organises AI risk work into four functions: Govern, Map, Measure and Manage. Questions 1, 5 and 7 are governance; 2 and 3 map where data flows; 4 and 6 are how you measure and manage the assistant in use. NIST released a concept note in April 2026 for an AI RMF profile aimed specifically at critical infrastructure operators, so expect more specific guidance for plants to follow.

None of these answers are published in detail as of October 2026, which is normal for features this new. Asking them up front, and getting written answers, is what makes “control is not optional” real at your site. Where AI touches the boundary between plant systems and corporate IT, the questions belong in the same review as any other IT/OT integration.

What a sensible first use looks like. In our view, the safest place to start is read-only questions that a person can check against a report: “list the controllers at site B with a failed backup job this month” or “summarise the critical vulnerabilities on line 2”. If the answer matches the report, trust grows on evidence. If it does not, the gap usually points at a data problem worth fixing anyway. Keep AI out of regulated decisions until the validation position above is written down.

How AMDT’s AI compares

Vendor	AI feature	What the AI works on
AMDT	Companion, vulnerability and lifecycle guidance	Questions about the installed base: assets, versions, CVEs, lifecycle
Copia Automation	Copia AI	Documenting and translating PLC code held in Git
Software Defined Automation	Factory Agent, AI code generation	Multi-vendor engineering: generating and analysing code
Siemens	Industrial Copilot	Engineering assistance on Siemens tools, with output flowing into ServiceNow workflows

The split is clear. Copia, SDA and Siemens point AI at writing or explaining code. AMDT points it at understanding the estate. Plants with a large mixed-vendor installed base and a security mandate will find AMDT’s angle more immediately useful; plants doing a lot of new engineering will look harder at the others. The broader comparison is on octoplant vs Copia.

Where it gets hard

• New features, thin documentation. Companion shipped in April 2026. Expect behaviour to change between releases.
• Answers inherit data gaps. Coverage, stale jobs and imported rows all flow straight into the answer.
• Policy lags capability. Many plants have no written rule for AI on OT data, so the default becomes whatever the first user does.
• Validation in GxP plants. Using AI output in a regulated decision needs a documented position before first use.

---

Related: octovision overview · octovision Asset Inventory · Asset Lifecycle and Obsolescence · AMDT hub