Key takeaways
- Cisco's 2026 survey of more than 1,000 OT decision-makers found that 98% call cybersecurity foundational for AI-ready infrastructure and 40% cite it as the biggest obstacle to scaling AI. These are Cisco-reported survey results, not a universal benchmark.
- CISA's joint guidance gives manufacturers four principles: understand AI, consider AI in the OT domain, establish governance and assurance, and embed oversight, safety and failsafe practices.
- The safest first architecture keeps AI on a governed read path outside direct control loops, with approved data contracts, least-privilege identities, segmented zones, human approval and deterministic safety interlocks.
- ISA/IEC 62443 provides the industrial cybersecurity lifecycle and risk-assessment foundation, while NIST SP 800-82 keeps performance, reliability and safety requirements visible alongside confidentiality and integrity.
- A credible pilot tests wrong-asset queries, poisoned or stale data, model drift, prompt injection, permission violations, network loss, rollback and manual fallback before any write action is considered.
The factory floor is not another enterprise data source
Manufacturers are connecting AI to historians, MES platforms, maintenance systems, engineering repositories, cameras, sensors and operator workflows. The opportunity is real: predictive maintenance, quality inspection, energy optimization and faster troubleshooting can all improve decisions. But an AI system that reads or acts on operational technology (OT) is not simply another enterprise application. It sits near equipment, processes and people whose safety, availability and reliability can depend on correct behavior. NIST defines OT around systems that monitor or control the physical environment and explicitly says that security must address unique performance, reliability and safety requirements. [4]
The security question is therefore broader than whether a model can be kept confidential. A manufacturer must ask whether the model can be manipulated, whether its data is trustworthy, whether its actions are bounded, whether an operator can understand and reject its recommendation, and whether the line remains safe when the model, network or supporting service is unavailable.
AI should earn permission to advise before it earns permission to act. CISA’s joint guidance says AI integration into OT can create risks to safety, security and reliability, and recommends that operators continuously monitor, validate and refine their models. [1] [6]
Why AI changes the OT threat model
Traditional OT security already has to manage vulnerable legacy devices, long asset lifecycles, remote access, vendor dependencies and strict uptime requirements. AI adds new components and new ways for a seemingly valid request to produce an unsafe result. The attack surface now includes training and retrieval data, model files, prompts, agent tools, vector indexes, APIs, orchestration services, identities, logs and the human decisions made from AI output.
CISA identifies risks that are especially important in industrial environments: manipulated data, models or deployment software; prompt injection; poor data quality; model drift; lack of explainability; operator cognitive load; interoperability problems; AI dependency; and unreliable or hallucinated output. The guide links those risks to impacts such as reduced availability, functional-safety risk, financial loss, network compromise and cascading compromise. [1]
The shift is visible in adoption data. Cisco’s 2026 State of Industrial AI survey covered more than 1,000 OT decision-makers across 19 countries and 21 sectors. Cisco reports that 61% of organizations use AI in live industrial operations, 20% have scaled, mature deployments, and 83% expect to increase AI spending. It also reports that 98% view cybersecurity as foundational for AI-ready infrastructure, 40% call cybersecurity the biggest obstacle to scaling AI, and 85% expect AI to improve their cybersecurity posture. These are Cisco-reported survey results, so they should be used as an adoption signal rather than a universal manufacturing benchmark. [2]
| Cisco 2026 survey signal | Why it matters to a plant security program |
|---|---|
| 61% report AI in live industrial operations | Security review must happen before production exposure, not after a pilot becomes operationally important. |
| 20% report scaled, mature deployments | A small but meaningful group is already dealing with lifecycle, incident and change-management requirements. |
| 98% call cybersecurity foundational | Cybersecurity is a prerequisite for AI-ready infrastructure, not an optional workstream. |
| 40% call cybersecurity the biggest scaling obstacle | Security architecture and IT/OT ownership can determine whether a use case moves beyond demonstration. |
| 85% expect AI to improve cybersecurity posture | AI can assist monitoring and detection, but its own data, model and tool paths must be governed. |
Start with CISA’s four principles
CISA, the Australian Signals Directorate’s Australian Cyber Security Centre and international partners published joint guidance in December 2025 for critical-infrastructure owners and operators integrating AI into OT. The guidance covers machine learning, large language model-based AI and AI agents, while noting that its approach can also help with statistical models and logic-based automation. [1] [6]
| CISA principle | Manufacturing interpretation |
|---|---|
| 1. Understand AI | Identify model limitations, data dependencies, drift, hallucination risk, prompt injection and the secure AI development lifecycle. Train operators and engineers on what the system can and cannot do. |
| 2. Consider AI use in the OT domain | Establish a specific business case, define the OT data boundary, evaluate integration and interoperability challenges, and make vendor responsibilities explicit. |
| 3. Establish AI governance and assurance frameworks | Add AI to existing cybersecurity and safety governance, test models continuously, document evidence and address regulatory obligations. |
| 4. Embed safety and security practices into AI and AI-enabled OT systems | Add monitoring, transparency, incident-response integration, human oversight, bounds checking and failsafe behavior before enabling operational actions. |
This is a useful sequence because it prevents manufacturers from starting with a model and working backward toward safety. The business case, data boundary and governance decision come first. The model is one component inside a controlled system.
Use ISA/IEC 62443 to organize the control system
ISA/IEC 62443 defines requirements and processes for implementing and maintaining electronically secure industrial automation and control systems (IACS). ISA describes the series as a holistic approach that bridges operations and information technology as well as process safety and cybersecurity. It covers the IACS lifecycle, common concepts and models, asset-owner security programs, risk assessment, security levels and secure product development. [3]
For an AI connection, that lifecycle view is more useful than treating security as a gateway checklist. A manufacturer can map each AI component to an owner, zone, conduit, trust boundary, security requirement and change process. The exact control selection depends on the site risk assessment, but the following matrix is a practical starting point.
| Control area | Minimum expectation before a production pilot |
|---|---|
| Asset and data inventory | Identify every PLC, HMI, SCADA, historian, MES, CMMS, document source, model, index, API, agent tool and service identity in the path. Record owner, version, location and criticality. |
| Zones and conduits | Put AI services in an explicitly designed zone. Permit only approved flows through a broker or gateway. Do not give a language model direct, unrestricted reach into controllers or engineering workstations. |
| Identity and least privilege | Use individual user identity, workload identity and role-based access. Separate read permissions from write permissions, and separate engineering, maintenance, operations and vendor roles. |
| Data contracts | Define approved asset identifiers, tags, time windows, units, quality flags, document revisions and maximum query sizes. Reject unknown or ambiguous requests. |
| Model and software provenance | Track model version, source, training or retrieval data, dependency versions, evaluation set, approval status, signing and rollback path. |
| Output and tool controls | Enforce structured output, schema validation, allow-listed tools, parameter bounds, rate limits and deterministic business rules outside the model. |
| Human approval | Require a qualified person to approve work-order drafts, set-point recommendations, procedure changes or other consequential actions. |
| Monitoring and evidence | Log user, prompt or request, retrieved sources, data quality, model version, tool calls, output, approval, correction and final action. |
| Recovery and manual fallback | Define what happens during model error, data outage, network partition, credential compromise, vendor outage or rollback. Operators must retain a safe manual path. |
NIST SP 800-82 Rev. 3 is a complementary reference because it treats OT security as a balance of cybersecurity with performance, reliability and safety. NIST’s publication page also points to a Rev. 4 draft and potential updates, so teams should record the exact revision used in their security baseline rather than citing “NIST OT guidance” generically. [4]
Keep the first AI release outside the control loop
CISA’s AI-in-OT guidance places predictive machine learning use cases primarily in Purdue levels 0–3 and describes large language models and agents more typically in enterprise and business levels 4–5, potentially using data exported from OT. It also gives examples such as anomaly detection, quality control, predictive maintenance, workflow optimization and behavioral analytics. [1]
That does not mean every ML model must be outside the plant, or that every enterprise agent is safe. It means the placement should be deliberate. A local anomaly detector may be appropriate near a line when it has a bounded purpose, a known model, deterministic thresholds and a defined safe state. A general-purpose language model that can call tools should normally sit behind a policy gateway and interact with a curated evidence layer instead of browsing raw controller endpoints.
A reference pattern is a read-first architecture:
- Approved OT sources expose data through a broker, historian API or governed export.
- A contextualization layer attaches site, area, line, asset, unit, timestamp, quality and operating-state metadata.
- A policy gateway authenticates users, validates requests, enforces query limits and removes unapproved fields.
- The AI service retrieves evidence and returns a structured answer that separates observations, calculations, hypotheses, uncertainty and recommended checks.
- A qualified human reviews the answer and, if appropriate, submits an action through an existing deterministic workflow.
- The audit layer stores evidence, model version, approvals, corrections and outcome.
The most important boundary is between recommendation and execution. The model should not invent a controller address, browse every tag, change a PLC parameter, disable an alarm or close a work order because a natural-language response sounded confident. Any write path should be a separately authorized capability with deterministic validation, transaction logging and a safe rejection state.
Threat model the data path, not only the model
An AI security review that checks only the model endpoint misses the industrial failure modes. Review the complete path from sensor or document to decision and action.
| Threat path | Example in manufacturing | Required response |
|---|---|---|
| Poisoned operational data | A compromised gateway, bad calibration or malicious historian entry makes an anomaly model learn or report a false condition. | Preserve source identity, timestamps and quality flags; detect changes; compare against independent signals; quarantine suspicious data. |
| Prompt injection | A retrieved work instruction or equipment note contains text that tries to override system policy or call an unapproved tool. | Treat documents and tool responses as untrusted data; isolate instructions from evidence; use allow-listed tools and server-side authorization. |
| Model drift | A process change, new product, sensor replacement or seasonal condition makes a previously accurate model unreliable. | Monitor performance by asset and operating regime; define drift thresholds; require revalidation and rollback. |
| Stolen or over-privileged identity | A service account can query sensitive engineering data or reach a write-capable endpoint. | Use short-lived credentials, role separation, least privilege, network restrictions and approval for elevated actions. |
| Supply-chain compromise | A model, package, connector or agent tool is replaced or updated without review. | Pin versions, verify provenance and signatures where available, scan dependencies, test updates in a representative environment and keep a rollback copy. |
| Unavailable AI service | Network loss, GPU failure or a cloud outage removes the assistant during a maintenance or production decision. | Make manual procedures current, test degraded mode, define timeout behavior and never make AI a single point of safe operation. |
| Evidence exfiltration | Prompts or retrieval results reveal recipes, engineering drawings, production data or personal information. | Classify data, enforce row and document permissions, minimize context, monitor egress and confirm residency and retention terms. |
NIST’s AI Risk Management Framework is voluntary and lifecycle-oriented. NIST says it is intended to improve the ability to incorporate trustworthiness into the design, development, use and evaluation of AI systems, from conception through ongoing use. For manufacturing, that means the same risk record should follow the system through pilot, release, model update, incident, retirement and replacement. [5]
A 90-day implementation plan
Days 1–20: define the decision and boundary. Choose one workflow such as maintenance investigation preparation, quality triage or engineering-document search. Name the accountable business owner, OT owner, security owner and approver. Inventory data sources and record a baseline for time, accuracy, escalations and expert correction. Write down what the system is not allowed to do.
Days 21–50: build the read path. Connect only approved sources. Resolve asset identity and units. Preserve source timestamps, quality states and document revisions. Put the AI service behind an identity-aware policy gateway. Test wrong-asset questions, time-window ambiguity, obsolete procedures, missing values, conflicting sources, permission violations and oversized queries.
Days 51–75: attack and evaluate the system. Create a gold set of normal and adversarial cases. Include poisoned data, prompt injection in retrieved content, model drift, stale documents, network loss, duplicate assets, tool failure and a request to perform an unsafe action. Measure source correctness, applicability, citation coverage, abstention quality, latency, operator workload and expert correction rate.
Days 76–90: operate with approval. Run the assistant in one real workflow while keeping final authority with an authorized person. Review logs and corrections weekly. Exercise incident response, credential revocation, model rollback, data-source isolation and manual fallback. Expand only when the evidence quality, security controls and operational benefit are clear.
Questions to ask before connecting AI to OT
Ask the AI vendor which model, embedding, connector and tool versions are used, where prompts, retrieved content, logs and model artifacts are stored, how data is deleted, and which features are preview. Ask how the system handles prompt injection, data poisoning, model drift, hallucination, credential compromise and a disconnected plant. Ask for a signed software bill of materials or equivalent dependency record, a vulnerability-response process, an evaluation report and a documented rollback procedure.
Ask the OT owner which systems are authoritative, which zones and conduits are involved, how the data path is segmented, what response time and availability are required, and what safe state exists if the AI is wrong or unavailable. Ask engineering how asset identity, units, operating modes and document revisions are governed. Ask the safety and compliance teams whether the proposed use can affect functional safety, regulated records or incident reporting.
Finally, ask the business owner what decision improves and how that improvement will be measured. “The answer sounds useful” is not an acceptance criterion. A production-ready pilot should show that the right user receives the right evidence, with the right uncertainty, inside an approved workflow.
Common mistakes to avoid
Connecting a chatbot directly to controllers. Natural-language convenience is not a security architecture. Put a policy gateway, approved data contract and deterministic validation between the model and any operational system.
Treating a secure network as a trustworthy data source. A network can be segmented while its tags are wrong, stale, misidentified or manipulated. Preserve quality, provenance and operating context.
Confusing local deployment with complete security. An on-premises model still needs identity, patching, dependency review, monitoring, model evaluation, access control, backup and incident response.
Allowing silent model updates. A model or retrieval change can alter behavior even when the application code is unchanged. Version, evaluate, approve and roll back models like other production components.
Measuring only accuracy. In OT, false confidence, unsafe recommendations, excessive alarms and inability to recover can matter more than an average benchmark score. Include abstention quality, operator workload, recovery time and safe fallback in the evaluation.
Automating the write path first. The first release should retrieve, explain and draft. Consequential actions should remain behind deterministic controls and explicit human approval until the system has earned a broader trust boundary.
The strategic takeaway
AI security for manufacturing is not a narrower version of enterprise application security. It combines OT availability and safety, industrial network architecture, identity and access control, data and model governance, secure development, human factors and incident recovery. ISA/IEC 62443 supplies a lifecycle and risk-assessment foundation. NIST SP 800-82 keeps OT’s performance, reliability and safety constraints visible. NIST’s AI RMF supplies lifecycle-oriented trustworthiness practices. CISA’s joint guidance makes the integration sequence explicit. [1] [3] [4] [5]
The practical starting point is modest: one decision, one asset family, one read-only path and one accountable approver. Use Cisco’s 2026 findings as a reminder that cybersecurity is now a scaling constraint and a potential AI benefit, not as permission to skip the engineering work. [2]
If the system can prove where its evidence came from, preserve uncertainty, reject unauthorized requests, remain useful during degraded connectivity and fail safely when its model is wrong, AI can strengthen the factory without becoming an uncontrolled route into it.
References
[1] [Principles for the Secure Integration of Artificial Intelligence in Operational Technology](https://www.cisa.gov/sites/default/files/2026-01/joint-guidance-principles-for-the-secure-integration-of-artificial-intelligence-in-operational-technology-508cV2.pdf), CISA, ASD’s ACSC, NSA AISC, FBI, Cyber Centre, BSI, NCSC-NL, NCSC-NZ and NCSC-UK, 3 December 2025.
[2] [Cisco Research: Industrial AI Moves into Physical Operations, Readiness Gaps Determine Scale](https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2026/m03/state-of-industrial-ai-report-2026.html), Cisco, 3 March 2026 page date; release text dated 7 April 2026.
[3] [ISA/IEC 62443 Series of Standards](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards), International Society of Automation, accessed 26 August 2026.
[4] [SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final), National Institute of Standards and Technology, September 2023.
[5] [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), National Institute of Standards and Technology, accessed 26 August 2026.
[6] [Principles for the Secure Integration of Artificial Intelligence in Operational Technology](https://www.cisa.gov/resources-tools/resources/principles-secure-integration-artificial-intelligence-operational-technology), Cybersecurity and Infrastructure Security Agency, published 3 December 2025.
*This article is an enterprise AI security and architecture guide. ISA/IEC 62443, NIST and CISA guidance do not replace a site-specific safety, cybersecurity, regulatory or engineering assessment. Validate every control, model, connector, data flow and write permission in the target plant before production use.*
