Industrial AI Copilots: Agentic Operations on the Plant Floor (2026)

Last Updated: November 2026

The dashboard era of manufacturing software rested on a quiet assumption: if you instrument every machine and plot every tag, operators will simply see the problem and act. Twenty years of historians and SCADA trend screens say otherwise. Data is everywhere, answers are buried, and the person who knows which three tags matter at 02:14 on a Sunday is about to retire. An industrial AI copilot for manufacturing changes the unit of interaction from a chart you must interpret to a question you can ask: why did line 3 trip twice last shift, and what does the SOP say to do about it?

That shift is now a product category, not a demo. Siemens, Rockwell Automation and AVEVA all ship or have announced copilot and agent features, and the vendor roadmaps in late 2026 are moving from “assistant that answers” toward “agents that orchestrate work.” That progression is exactly where plant engineers should slow down, because the failure mode changes from a wrong answer to a wrong action.

This post gives you a vendor-neutral reference architecture, the control boundary that keeps a language model advising rather than acting, a tier model that ties autonomy to required safeguards, and the failure modes that appear after go-live.

What this covers: the 2026 vendor landscape, a layered reference architecture, grounding and retrieval design, tool policy and approval gates, the NAMUR Open Architecture read path, a tiered autonomy model, evaluation and audit, cost and ROI, failure modes, and a rollout checklist.

Context and Background

For three decades the plant-floor interface has been a screen of trends, alarms and faceplates, and the operator has been the integration layer. They correlate a temperature excursion on one screen with an alarm on another and a handwritten note in a binder. A copilot targets that cognitive load. The move is from visualization (here is the data, you work it out) to assistance (here is the likely cause, the procedure in force and the evidence behind both).

It helps to separate two very different products that share the word “copilot.” Engineering copilots help people build automation: they draft PLC code, generate HMI screens, digitize P&IDs. Operations copilots run beside the live process: they answer questions about faults, retrieve procedures and summarize shifts. The first class produces artifacts a human reviews and tests before anything runs. The second class sits next to a process that moves physical mass, and its mistakes land in real time. This post is mostly about the second class, with a section on what happens when engineering and operations copilots are stitched together by agents.

What vendors have actually announced

The picture below is drawn from vendor announcements and should be read as marketing claims unless stated otherwise.

Siemens announced AI agents for its Industrial Copilot ecosystem at Automate 2025 in May 2025. In that announcement an orchestrator coordinates specialized agents that can call external tools and other agents, and Siemens stated that users choose which tasks to delegate. It described copilots across design, planning, engineering (TIA Portal, generating SCL code from natural language), operations (Insights Hub) and services (Senseye). At CES in January 2026 Siemens said it would deploy nine new copilots across software including Teamcenter, Polarion and Opcenter, offered through the Siemens Xcelerator Marketplace, and described a planned Industrial AI Operating System co-built with NVIDIA, with no release dates given. A reported 25 percent reduction in reactive maintenance time from Senseye pilots is a vendor figure, not an independent measurement, and Siemens’ “up to 50 percent” productivity statement was explicitly a vision.

Rockwell Automation announced FactoryTalk Conductor on 21 October 2026, described as an AI-native orchestration platform spanning design through operations and maintenance. At launch it connects to Studio 5000 Logix Designer, Logix Echo, Emulate3D and FactoryTalk Optix, with FactoryTalk Design Studio, Historian, Plex and Fiix planned. Customers can use hosted AI services, bring their own frontier or open-weight models, or use Rockwell-hosted models. Rockwell’s release speaks about governance only at a high level, and commercial availability is planned for Q1 2027, so treat it as announced rather than proven.

AVEVA, at AVEVA World in Milan on 20 May 2026, announced an industrial AI assistant inside Unified Engineering, agentic mapping of data sources to a standard model in its CONNECT twin builder, native C# and Python support in its HMI/SCADA platform for edge AI, and planned Model Context Protocol (MCP) integrations with no stated date. A major CONNECT release with an industrial knowledge graph is planned for Q1 2027. For the data-platform side of that story see our analysis of AVEVA and Snowflake IT/OT data architecture.

What regulators and security agencies say

In late 2025 CISA, the NSA’s AI Security Center, the FBI and cyber agencies from Australia, Canada, Germany, the Netherlands, New Zealand and the United Kingdom published joint guidance on integrating AI into operational technology. It organizes advice into four principles: understand AI, consider AI use in the OT domain, establish AI governance and assurance frameworks, and embed safety and security practices into AI-enabled OT systems. (Canadian Centre for Cyber Security summary). The architecture in this post is one way to satisfy those principles in practice, but it is not a compliance certificate, and the guidance itself should be read in full before a deployment review.

Reference Architecture: A Copilot That Advises and Cannot Actuate

An industrial AI copilot is a retrieval-grounded language interface embedded in operator workflows. It answers questions and proposes actions using plant data (historian tags, MES events, manuals, P&IDs) while a policy layer keeps it read-only by default and routes any change through a human approval gate into the existing control system. It advises; it does not close the loop.

Figure 1: Reference architecture. Every tool call passes a deterministic policy engine; read paths feed retrieval, while action intents become proposals that wait for a human.

The long-description view of Figure 1: an operator types or speaks into a copilot pane inside the HMI or MES client. An orchestrator interprets intent and plans which tools to call. Every planned call passes a policy engine that classifies it as read-only or action-bearing and checks the operator’s role and area. Read-only calls fan out to a retrieval layer that touches three corpora: a versioned document index, a live historian API and the MES. Action-bearing intents never touch a controller; they become structured proposals in a queue. Everything, including the question, the retrieved context, the proposal and the decision, lands in an audit log.

Layer by layer, and why each exists

The interface layer is deliberately thin. Putting the copilot inside the HMI or MES client the operator already uses matters more than any model choice, because a separate tool in a separate window will not be opened during a fault. The interface also carries identity: the user’s existing role and area permissions travel with every request, so the copilot never has more authority than the person asking.

The orchestrator is where the language model lives. Its job is narrow and the model is good at it: interpret a fuzzy question, decide which tools to call, and turn retrieved evidence into readable prose. It is a poor place to put rules about whether something is safe, so it holds no authority. It can request tools; it cannot grant itself access to them.

The policy engine is ordinary deterministic code. It holds allow-lists of tools, area scoping (a Line 3 session cannot query Line 7), rate limits and the read-versus-action classification. Because it is code, it can be unit tested, reviewed and validated independently of whichever model version runs above it. That separation is the core design idea of this whole post: the more consequential the action, the less discretion the model gets and the more a deterministic layer constrains it.

The retrieval layer assembles a context bundle from the plant’s systems of record. It is explained in the next section because grounding quality decides whether the copilot is trusted or abandoned within a month.

Where the model runs

Inference location drives latency, data governance and resilience. A cloud-hosted model gives access to the strongest models and the least operational burden, but ships plant context off-site, which some operators cannot accept for IP or sovereignty reasons, and a WAN drop mid-shift means no assistant. An on-premises or edge-hosted open-weight model keeps every byte inside the plant network and survives link loss, at the price of running serving infrastructure and accepting a smaller model. A hybrid keeps retrieval and policy on-premises and calls a private cloud endpoint for generation, which is a common middle ground but still sends the context bundle out.

Rockwell’s announcement explicitly supports all three postures (hosted, bring-your-own, and locally hosted open-weight models), and notes locally hosted models may reduce ongoing token cost. That is a vendor claim; measure it. For a European view of keeping industrial AI inside a jurisdiction, see our piece on sovereign industrial AI cloud reference architecture.

Latency deserves more attention than demos give it. An operator chasing an active fault will not wait fifteen seconds. Production systems cap retrieval breadth, run independent tool calls in parallel and stream tokens. The orchestrator must also fail visibly: if the historian API times out, the correct response is “I could not reach the historian,” never an answer improvised from stale or imagined data.

Grounding Design: What the Copilot Is Allowed to Know

The most important design decision is what the model may treat as true. A copilot answering from pre-training weights will invent setpoints, part numbers and procedure steps with perfect fluency. Grounding replaces that behavior with retrieval from systems of record, and in industrial settings the retrieval problem differs by data type. Treating all plant data as “documents to embed” is the most common architectural error.

Four corpora, four ingestion strategies

Unstructured documents such as equipment manuals, SOPs, batch records and work instructions are chunked, embedded and stored in a vector index, ideally combined with keyword search because part numbers and tag names are exact-match problems that embeddings handle poorly. Our notes on RAG chunking strategies and hybrid search cover the mechanics.

Diagrams are not prose. A P&ID has to be processed with symbol extraction or OCR and, critically, paired with curated tag-to-equipment mappings, so that “FIC-301” in a question resolves to the right loop, its upstream vessel and its alarm limits. Without that mapping the copilot sees a picture it cannot reason about.

Time series should not be embedded at all. The value of a tag is its recent trajectory, so the copilot queries the historian through a read API at question time. Embedding yesterday’s values produces a confidently stale answer.

MES and event records (work orders, downtime reasons, genealogy, quality holds) are structured and are queried structurally, often through the vendor API or an ISA-95-aligned model. For how the data model typically looks, see our OEE architecture and MES data model reference.

Revision discipline and temporal alignment

Two details separate a demo from a deployable system. The first is revision discipline. SOPs and recipes change, and an answer grounded in a superseded revision is a compliance defect in a regulated plant, not merely an unhelpful reply. The ingestion pipeline must carry effective date, revision and equipment applicability into the index and filter on them at query time, so the copilot retrieves the document in force now for this asset, not whatever scored highest on semantic similarity.

The second is temporal alignment. “Why did line 3 trip at 02:14?” must become a bounded historian query: the right tags, a window around the event (for example ten minutes before to a few minutes after, tuned per process), and aligned alarm and event records. A vague “fetch recent data” call either returns noise or truncates the one sample that mattered. Clock discipline matters too: if the historian, alarm server and MES disagree on time by seconds, the copilot’s causal story will be wrong in ways that look convincing.

Figure 2: A grounded query. The policy engine scopes the request before any data is touched, and the answer returns with revision-stamped citations and a confidence signal.

Figure 2 walks the happy path. The operator’s question reaches the copilot, which plans read-only calls. The policy engine confirms the session is allowed to read Line 3 and nothing else. The copilot then queries the historian for the bounded window and the alarm log, and asks the document index for the SOP revision in force for that filler. Results return, and the answer is composed with citations pointing to specific tag queries and document passages rather than to “the system.”

Retrieval quality is measurable

Grounding is not a feeling; it is a pipeline you can score. Build a golden set of real questions with known-good evidence, then track retrieval recall (did the right SOP passage appear in the top results?) and answer faithfulness (does every claim trace to retrieved context?) separately. If recall is low, fix chunking, metadata or the tag map. If recall is fine but faithfulness is low, fix prompting or the model. Conflating the two wastes months. Our guide to RAG retrieval evaluation with recall@k, nDCG and golden sets shows how to build one.

Good grounding is as much exclusion as inclusion. Pulling a neighboring unit’s tags or the wrong manual revision is how a plausible answer becomes a wrong one. Scope filters (area, asset class, effective date) belong in the retrieval query, enforced by code, not requested politely in the prompt.

Tool Policy and the Approval Boundary

The orchestration layer earns or loses the copilot’s safety case. It exposes tools to the model, and the pivotal move is to split them into two classes, with only one class directly callable.

Read-only tools versus proposals

Read-only tools such as get_tag_history, query_mes_events, search_documents and get_alarm_log can be called freely because they cannot change plant state. Action-bearing capabilities (writing a setpoint, acknowledging an alarm, changing a recipe, releasing a hold) are deliberately not exposed as callable tools. They are modeled as proposals: structured objects holding the intended change, rationale, evidence and expected effect, emitted for human review.

This is a boundary you can reason about. If the model hallucinates a tool call, the worst outcome with read-only tools is irrelevant data and a wrong answer, which is bad but recoverable. It cannot, by construction, move an actuator. A proposal schema also gives you something to validate: allowed parameters, engineering limits, rate-of-change caps and the asset it targets, all checked by code before a human ever sees the proposal.

The industry’s drift toward agents and protocols such as MCP makes this boundary more important, not less. An MCP server that wraps a historian is a read tool; an MCP server that wraps a write path is an actuation tool, and exposing it directly to a model collapses the boundary. If you adopt MCP, treat each server’s tool list as an attack surface and review it as such. Our MCP server security threat model covers tool poisoning and confused-deputy risks, which matter more when the tools sit near a plant.

The human approval gate

Figure 3: Approval flow. Out-of-scope proposals are blocked and logged; approved proposals are signed and executed through the same path a human would use.

Figure 3 shows the contract. A proposal is first checked for scope and engineering limits. An out-of-scope or out-of-limit proposal is blocked and logged, never shown. An in-scope proposal is rendered to the operator with its citations. The operator approves or rejects. Only on approval is a signed record created and the change applied through the existing SCADA change path, the same route a human operator uses, so existing role permissions, interlocks and write-confirmation behavior still apply. The PLC safety logic remains the sole authority over physical outcomes, and the result is verified and logged.

Note what the copilot never has: a service account that can write to a controller. Wiring it as a direct writer, even “just for low-risk setpoints,” makes the model’s judgment part of the safety case, and a language model’s judgment is not certifiable in the way a bounded function is.

Choosing the approval granularity

Approval fatigue is the quiet failure of this pattern. If operators must click through forty proposals a shift, they will approve reflexively and the gate becomes a rubber stamp. Tune granularity deliberately: batch low-consequence proposals, require richer evidence and a second approver for high-consequence ones, and measure rejection rate and approval time. A rejection rate near zero with approval times of one second is a warning sign, not a success metric.

Placing the Copilot in the Automation Hierarchy

ISA-95 (IEC 62264) divides an enterprise into levels, from Level 0 (the physical process) through Levels 1 and 2 (sensing, control and supervision) to Level 3 (manufacturing operations management) and Level 4 (business planning). A copilot belongs at Level 3 and above. Control and safety functions at Levels 0 to 2 are outside its reach. Keeping the copilot above the control boundary, and bridging into live OT data through a read-only mechanism, stops an IT-class component from becoming an OT-class hazard.

The NAMUR Open Architecture read path

The cleanest published pattern for that bridge is NAMUR Open Architecture (NOA). NOA adds a second communication channel for monitoring and optimization alongside the classic automation pyramid, so production data from field devices can reach monitoring applications without affecting the automation system itself, per NAMUR’s own description. NAMUR’s concept is documented in NE 175, with related recommendations for the information model (NE 176), security zones and gateway (NE 177), verification of request (NE 178) and an aggregating server (NE 179). See the NAMUR NOA overview for current status; some of these building blocks were described by NAMUR as still being published, so check which are final before citing them in a design document.

NOA matters here for a precise reason: a copilot fed from a NOA-style monitoring channel inherits visibility without write authority. Even if the model, the orchestrator and the policy engine all misbehave, the data path physically offers no route back into the controller. Where a plant lacks NOA, an equivalent is a unidirectional gateway or a read-only historian replica, and the same principle holds: the safest write path is the one that does not exist.

Identity, secrets and the OPC UA edge

Many plants will feed the copilot through an OPC UA server or a historian with OPC UA access. Treat the copilot’s connection like any other IT/OT integration: a dedicated read-only identity, certificate-based authentication, explicit security policies, and a trust-list owned by OT. Our OPC UA security certificates and trust list reference explains the mechanics. For plants still on Modbus, the brownfield Modbus to Unified Namespace retrofit shows one way to expose data cleanly before any model touches it.

Agentic Operations and the Capability-Tier Model

“Agentic” in vendor material generally means an orchestrator that decomposes a goal, calls tools and other agents, and iterates. Siemens describes an orchestrator coordinating specialized agents. Rockwell’s FactoryTalk Conductor links engineering tools and workflows from natural-language task requests. AVEVA applies agentic mapping to build digital twin data models. These are meaningfully different risk profiles, and lumping them together hides where the danger sits.

Where agents are safe, and where they are not

Agents are comparatively low-risk when their output is an artifact a human reviews before it runs: a draft of PLC code that goes through simulation and code review, a proposed tag-to-asset mapping that an engineer confirms, a shift summary. Rockwell’s integration with emulation tools such as Logix Echo and Emulate3D points at the right pattern, which is to put a simulated plant between a generated change and the real one. Our overview of agentic digital twins for industrial analysis covers that pattern.

Agents become hazardous in the runtime path, because multi-step autonomy compounds error. An agent that chains five tool calls with 95 percent reliability each completes the chain correctly roughly 77 percent of the time, which is simple multiplication and illustrative only, since real step reliabilities are correlated and unmeasured until you test. The practical implication is that autonomy should be earned by evidence per workflow, not granted per product. See AI agent trajectory evaluation patterns for how to measure that, and multi-agent orchestration with MCP and A2A for the coordination patterns.

The tier model

Figure 4: Each step up in autonomy adds required controls. No tier removes the PLC safety loop, and no tier puts an unsupervised LLM in the control loop.

Tier	What the copilot does	Controls required before deployment
0: Read-only advisory	Answers questions, summarizes alarms, retrieves SOPs and trends	Retrieval grounding, citations, confidence signal, query audit log, area scoping
1: Guided action	Proposes a specific action with rationale; a human executes through existing controls	All of Tier 0, plus mandatory approval gate, limit checks, signed audit record
2: Supervised autonomy	Executes narrowly bounded, pre-approved actions under continuous human supervision	All of Tier 1, plus tightly bounded scope, tested abort path, rate limits, a rule that the safety loop is never bypassed

The table has no Tier 3. This is an opinion, but a defensible one: on a line that moves hot metal, pressurized fluid or heavy mass, an unsupervised LLM in the loop is not a capability level, it is an unmanaged hazard. The CISA-led guidance points the same way by asking owners to establish governance and embed safety practices before introducing AI into OT.

Most plants should live at Tier 0 for the first year and use Tier 1 selectively. Tier 2 deserves a formal hazard analysis (HAZOP or equivalent) of each specific action, because “supervised” must mean someone is actually watching with the ability and time to intervene. A supervisor who gets a notification after the action has executed is supervising nothing.

Evaluation, Audit and Lifecycle

Guardrails are why the model is allowed near the plant at all. They fall into three families: actuation controls (above), hallucination controls and accountability controls.

Hallucination controls

The antidote is grounding plus transparency. Each substantive answer should carry citations to the specific manual passage, tag query or MES record it rests on, so the operator verifies instead of trusting. A coarse confidence signal derived from retrieval quality and answer consistency tells the operator when to be skeptical. When retrieval returns nothing relevant, the correct behavior is refusal: “I could not find a grounded answer” is far safer than a plausible setpoint. Make that response a first-class, visible outcome and count it as a success metric, because teams that penalize refusals train their copilots to bluff.

Accountability controls

Log the question, retrieved context, answer, proposal, decision, approver and outcome. Capture the retrieved context specifically: it is what lets a quality engineer reconstruct, weeks later, why the copilot said what it said. In a regulated environment such as pharma or food, the signed approval record (who, when, on what evidence) is the artifact an auditor asks for, and in a 21 CFR Part 11 context an architecture unable to produce it is not deployable regardless of answer quality. Whether Part 11 applies to a given copilot use is a regulatory judgment for your quality team; do not assume either way.

Evaluation drift and the regression set

A copilot validated against last quarter’s documents degrades silently as SOPs change, equipment is added, or the model vendor updates weights behind an alias. The control that works is a standing regression set: a fixed battery of real plant questions with known-good grounded answers, re-run on every model, prompt, index or tool change, with failures gating rollout. Pin model versions where the provider allows it, and treat a model upgrade as a change request. The NIST Generative AI Profile (NIST AI 600-1), a companion to the AI Risk Management Framework, is a useful vocabulary for the risks (confabulation, information security, human-AI configuration) and for structuring this lifecycle.

Include adversarial cases. Documents in the index are an injection channel: a maintenance note or a vendor PDF containing instructions can steer a model that reads it. Test with planted instructions, and keep action capability out of reach so that a successful injection can only produce a wrong answer, not a wrong action.

Roles and ownership

Assign owners. Someone in OT owns the tag map and the policy allow-lists. Someone in quality owns document currency and revision metadata. Someone in IT owns the model endpoint and logs. A copilot with shared ownership has no ownership, and the first symptom is a quietly stale index that nobody notices until an operator follows a retired procedure.

Cost, ROI and Realistic Expectations

The durable value is in time-to-diagnose and onboarding, not headcount cuts. A copilot that turns a long hunt through binders and trend screens into a short grounded answer compounds across every shift and every fault. A new operator backed by a copilot that has absorbed the plant’s SOPs reaches competence faster. Treat any percentage in a vendor deck as illustrative until you measure it on your own line; the honest metrics are mean time to diagnose, first-time fix rate, escalation rate to engineering and time to competency, all baselined before rollout.

The cost side vendors underweight

There is a recurring inference bill, or the capital and operating cost of self-hosted GPUs. There is corpus maintenance: someone must keep SOPs, tag maps and equipment hierarchies current, or the copilot rots. There is validation cost: the regression suite and re-validation on every model change. There is integration cost for read-only gateways, identity and logging. None are prohibitive, but all are ongoing, so the honest framing is “run a copilot as a maintained system whose benefit must keep outrunning its carrying cost.”

Gartner’s prediction quoted in AVEVA’s May 2026 announcement, that organizations will abandon 60 percent of AI projects unsupported by AI-ready data through 2026, is a forecast from a vendor press release, not a measured outcome. It is directionally consistent with experience, though: the bottleneck is nearly always data quality, naming consistency and documentation currency, not model capability.

A pilot that can actually prove value

Pick one painful, well-instrumented problem, such as recurring trips on a bottleneck line or changeover troubleshooting on a packaging cell. Baseline the metric for at least a month. Deploy Tier 0 only, to a small group of operators and one maintenance planner. Review every refused or low-confidence answer weekly, because those are your documentation gaps. Expand only when the regression set passes and the metric moves for reasons you can explain.

Trade-offs, Gotchas, and What Goes Wrong

Tribal knowledge gaps. The most valuable plant knowledge is often unwritten: the trick a veteran uses on a finicky changeover. Ask the copilot and it will answer from the nearest documented thing, which may be wrong. Treat this as a content problem. Capture expert knowledge deliberately, tag it with provenance, and let the copilot say “no documented answer.”

Tag and naming chaos. Plants with inconsistent tag conventions, duplicated equipment names across lines or missing hierarchy break entity resolution. The copilot picks the wrong “FIC-301” from another unit. A unified namespace or consistent asset model is a precondition, not a nice-to-have.

Stale or contradictory documents. If three SOP versions sit in a shared drive, retrieval can surface any of them. Revision filtering fixes this only if the metadata is trustworthy, and in many plants it is not.

Automation bias. Operators trust fluent text. A copilot that is right 95 percent of the time trains people to stop checking, and the remaining 5 percent arrives with full credibility. Citations, visible uncertainty and periodic drills where the copilot is deliberately shown to be wrong are cheap countermeasures.

Alarm-flood interaction. During a plant upset, operators have the least attention and the highest need. A copilot that produces long answers during a flood adds load. Tune for terse output and a prioritized next step in abnormal-situation mode.

Model and vendor churn. A hosted model alias can change behavior without notice. Pin versions, keep the policy engine model-agnostic, and make sure prompts and tools are version-controlled so you can roll back.

Latency and availability. If the copilot becomes the first place operators look and the WAN drops, you have created a dependency. Plan for degraded mode: the HMI and procedures must work exactly as they did before the copilot arrived.

Security of the integration itself. The copilot concentrates read access to many systems. Compromise of its service identity is a reconnaissance gift. Least privilege, short-lived credentials, network segmentation per IEC 62443 zones and conduits, and monitoring of its own queries are required. For utilities see our NERC CIP and IEC 62443 mapping.

Practical Recommendations

Start by deciding which class of copilot you are buying: engineering or operations. They have different risk, different owners and different success measures, and vendor bundles blur them. For operations, begin at Tier 0, behind a read-only path, with citations mandatory and refusal allowed. Spend your first quarter on data hygiene (tag map, asset hierarchy, document revisions) because that work pays off whichever model you pick.

Keep the policy engine, the proposal schema and the audit log under your control even if the model and orchestration are vendor products. If a platform does not let you inspect and test the tool allow-list, ask why. Rockwell’s Conductor, Siemens’ orchestrated agents and AVEVA’s planned MCP integrations were all announced with high-level governance language; ask each vendor for the specifics (tool scoping, approval hooks, log format, model pinning) in writing before a proof of concept.

Treat autonomy as something each workflow earns. Escalate from Tier 0 to Tier 1 only after the regression set passes, rejection and approval metrics look healthy, and a hazard review covers the specific actions. Do not skip to Tier 2 because a demo looked smooth.

Checklist before go-live:

Copilot reaches OT data only through a read-only path (NOA-style channel, unidirectional gateway or read replica).
No tool exposes a controller write; actions are proposals only.
Policy engine enforces role, area and rate limits in code, with unit tests.
Retrieval filters on document revision and effective date; tag map is reviewed by OT.
Every answer carries citations; refusals are visible and tracked.
Audit log stores question, context, proposal, approver and outcome.
Regression set exists, gates model and corpus changes, includes injection tests.
Degraded-mode procedure is written and rehearsed.
Named owners exist for tags, documents, model endpoint and logs.
Baseline metrics were captured before launch.

Frequently Asked Questions

What is an industrial AI copilot in manufacturing?

An industrial AI copilot is a language-model interface, usually embedded in an HMI, MES or engineering tool, that answers questions and drafts or proposes actions using plant data such as historian tags, MES events, manuals and SOPs. Good ones are retrieval-grounded, cite their sources and keep write access to controllers outside the model’s reach. Vendors split into engineering copilots, which help build automation, and operations copilots, which assist live running.

Can an AI copilot control a PLC or change setpoints?

It should not do so autonomously. The defensible design keeps the copilot read-only and turns action intents into proposals that a human approves, after which the change travels through the existing SCADA path with its interlocks intact. PLC safety logic stays the final authority. Narrowly bounded supervised actions are possible at higher tiers, but only after a formal hazard analysis of each action.

How is a copilot different from an agent?

A copilot responds to a user’s question or request. An agent plans multiple steps, calls tools and sometimes other agents toward a goal with less per-step supervision. Vendors increasingly blend the terms. The practical test is autonomy: how many consequential steps happen before a human sees a result, and whether any of those steps can change plant state.

How do you stop a plant-floor copilot from hallucinating?

You cannot eliminate hallucination, so you constrain its impact. Ground answers in retrieved plant data, filter by document revision and area, require citations, allow refusal when evidence is missing, and keep a regression set that is re-run on every model or corpus change. Most importantly, make sure a wrong answer cannot become a wrong action by keeping actuation behind human approval.

Where should the model run: cloud, edge or hybrid?

It depends on data sensitivity, latency tolerance and your ability to operate serving infrastructure. Cloud models are strongest and easiest but send context off-site and depend on the WAN. Edge or on-premises open-weight models keep data local and survive outages but are usually smaller. Hybrid keeps retrieval and policy local with a private cloud model endpoint. Whichever you choose, design and rehearse a degraded mode.

What does NAMUR Open Architecture have to do with AI copilots?

NOA defines a second channel for monitoring and optimization data alongside the core automation system, so applications can read plant data without affecting control. Feeding a copilot from a NOA-style channel gives it visibility without write authority, which is the property you want. NAMUR’s NE 175 describes the concept, and related recommendations cover information model, security gateway and aggregation.