每套 AI 工具，都是一个新的外部连接
关于 AI 与网络安全的讨论早已司空见惯，但大家往往忽略了“架构”层面的现实。引入 AI 不仅仅是安装一套新软件，更像是为你的工厂打开了一扇又一扇新的大门。每一个连接云端的 AI 部署，都需要向外传输数据的路径、向内的 endpoints，以及签发权限凭证。
近期的行业数据确实印证了这个不容忽视的风险。根据 Dragos 2026 OT/ICS 网络安全报告，针对工业组织的勒索软件攻击，同比激增 64%，其中制造业占了所有受害者的三分之二以上。这意味着在短短一年内，共有 119 个勒索软件团伙对超过 3,300 个工业站点发动了攻击。
工厂早就成为了黑客的目标。在评估任何新的 AI 部署时，真正该问的问题只有一个：它是否扩大了工厂的攻击面？
为什么威胁模型正转向系统性的运营风险？
要回答这个问题，必须先看攻击者的行为模式发生了什么变化。
工厂 OT 网络的最高原则是持续运行与物理安全，这使得定期的系统更新几乎无法执行，导致内部充满了未修补的漏洞。因此，现场的检测能力受到极大限制。Dragos 的数据指出，高达 88% 的工业网络目前缺乏有效的主机层级检测与响应能力。攻击者深知这一点，并相应地调整了攻击策略。
TCS 的 2026 网络威胁态势报告证实：如今源自企业 IT 端的安全事件，往往被设计为直接跨越到生产线上。攻击者之所以利用 IT 网络作为进入 OT 的跳板，纯粹是因为工厂系统无法以 IT 的速度进行检测或响应。为了将破坏力最大化，他们将目标锁定在虚拟化基础设施（例如 ESXi hypervisors）上，以此同时瘫痪多个工作负载，并绕过传统的端点防护。
当系统检测能力出现结构性弱点时，防御机制就必须向源头前移，也就是从“架构”本身着手。换句话说，如果你不能指望在小偷进门后顺利抓到他，更聪明的做法是：一开始就不要安装那些你根本不需要的大门。
引入 AI 带来的三大风险敞口
那么，引入 AI 究竟打开了哪些大门？每一个 AI 部署都会引入三种不同的风险敞口（exposures），从根本上改变你的网络拓扑。
第一，对外数据流（Outbound data flows）。
当 AI 系统依赖外部计算时，高度敏感的遥测数据（例如连续的生产视频、实时 cycle time、良率指标等）就必须物理离开厂区。值得注意的是，这种持续的连接建立了一座双向桥梁。混合云的引入带来了新的攻击路径：安全研究表明，VOIDLINK 等云原生恶意框架具备云端环境中的横向移动及进一步扩展能力。虽然目前没有证据表明 VOIDLINK 已在真实攻击中从云端横向进入本地工业 OT 环境，但其能力说明，随着云与 OT 环境连接日益紧密，攻击面可能进一步从云端延伸至工业环境。
第二，对内依赖性（Inbound dependencies）。
连接云端的 AI，本质上就需要保留从外部进入的通道。为了让系统运行，工厂必须维持开启的公有云 endpoints 以及第三方供应商的远程访问权限。TCS 2026 报告点名，利用暴露于网络的应用程序漏洞与滥用远程访问服务，是侵入制造业网络最常见的路径。这是一个极严重的安全盲区。
第三，机器身份（Machine identities）。
部署自主运行的 AI Agent，等于在你的网络上创造了一个非人类的“新用户”，它需要 API keys 以及访问运营数据库的权限。每一个新身份，都是一把可能被黑客劫持的数字密钥。这种凭证扩张的速度相当惊人：根据 Make UK 引述 SailPoint 的数据，英国企业每月大约新增 10,000 个身份。根据 TCS 2026 报告，凭证窃取与 session hijacking（会话劫持）已取代恶意软件，成为行业主要的入侵手法，这些不断扩张的机器身份也因此成为企业的安全负担。在 Lumma Stealer 这类大规模窃取身份验证令牌的 infostealers 助长下，被盗用的机器凭证能让攻击者伪装成合法的网络访问，悄悄绕过安全监控工具。
最关键的是，这些漏洞并非使用 AI 的必然代价，而是“结构性的选择”。你的对外数据流、对内 endpoints 以及机器身份的多寡，完全取决于你选择的架构。
当技术风险转化为商业风险
这三大风险敞口所威胁的，不仅仅是产线的正常运行时间（uptime），更直接关系到攻击者现在如何将“工业访问权限”变现。
根据 TCS 2026 报告，攻击者正转向“勒索优先”的攻击模式。他们不再触发容易被检测的系统加密，而是优先选择悄悄窃取高价值知识产权（如工程蓝图、CAD 设计图、专有配方），并通过公开披露的威胁来施压。
在制造现场，这类数据的敏感性直接牵动商业合同与竞争优势，而不仅仅是内部的隐私问题。这些数据泄露行动锁定的核心资产包括：
- 客户产品图像：未发布产品的图像一旦外泄，将暴露 IP 并带来市场泄密的风险。
- 操作员视频：员工画面的外泄将触发严格的区域隐私法规与工会合规问题。
- 产线绩效数据：良率、cycle times 与产量数据，通常受到严格的保密协议（NDAs）保护。
对于 EMS 与 ODM 厂等特定行业而言，AI 视觉系统所接触到的生产数据，往往属于全球品牌客户，而非工厂本身。因此，将这些数据转移到第三方云端，甚至在触发安全事件之前，就已经违反了客户合同。这首先是一个合同问题，其次才是安全问题。
云端 vs. 本地：风险敞口的衡量
保护这些敏感数据，最终必须回归到网络架构。如果用这三大网络风险敞口来衡量两种主要的 AI 部署模型，其中的权衡取舍非常清晰。
云端与本地 AI 架构比较
依赖云端的系统（Cloud-dependent system）从设计上就包含了这三种风险敞口。为了提供实时洞察，它必须持续将生产视频、cycle time 数据与良率指标传输到厂外。为了维持运行，工厂必须让对内的云端 endpoints 与供应商远程访问通道保持长期开启。于是，工厂不再只需管理自身的风险；它还继承了供应商系统的所有漏洞，以及操作该系统所需的所有机器凭证。
本地架构（On-premise architecture）则完全消除了前两项风险敞口，并将第三项安全地控制在范围内。因为数据处理与 AI 推理全数在厂内的专用服务器上进行，系统不增加任何对外数据流，也不需要对内的公开 endpoints。虽然 AI 系统仍需要自己的机器身份才能运行，但这些数字密钥严格被限制在你的防火墙之内。通过部署在你现有的 OT 网段中，系统可以在完全隔离的网络上运行，确保你的数字密钥永远不会暴露给外部世界。
在本地处理是一种结构性的取舍，而非万灵药。选择本地模型，意味着工厂必须承担内部软件更新，以及确保现场边缘服务器物理安全的全部责任。但作为交换，你保留了对厂内网络大门的绝对掌控权。
HOP：专为留在厂内而打造
PowerArena 的 Human Operation Platform（HOP）是一套专为分析组装线上人工作业而设计的 AI 视觉系统。因为它处理的是工厂最敏感的图像数据，我们将它设计成完全留在厂内运行。
HOP 运行在物理部署于产线现场的专用边缘服务器上。所有视频流、cycle times 与生产指标都在本地处理并存储。AI 的运行不需要绕道云端。因为它建立在现有的 OT 网段中运行，所以不需要开通任何一个对内的公开 endpoint 就能执行任务。
必须强调的是，HOP 不是一套安全产品。它不会保护你现有的网络或修补你的防火墙。相反，它是一个具备高度能力的 AI 部署方案，只是它拒绝为攻击者开启新的大门。你可以获得自主视觉系统带来的运营可视化，却无需扩大你的攻击面。你甚至可以将 HOP 设置为仅导出汇总后的运营指标到你安全的 IT 仪表板，确保原始视频与产线层级的数据永远不会离开厂区。
治理：给工厂管理层的检查表
根据 IIoT World 的 2026 OT 网络安全指南，全球 OT 网络安全支出预计将在 2026 年达到 309 亿美元。但如果从未正视根本的架构问题，光靠砸钱解决不了问题。
根据 Make UK 的数据，目前仅有 23% 的制造业公司聘有专职的首席信息安全官（CISO）。这意味着在大多数厂区，决定是否部署一套新 AI 工具的责任，往往落在厂长或区域 IT 主管肩上。
为了确保厂区安全，这里有一份架构检查表，建议你向任何工业 AI 供应商提问：
- 数据确切的处理位置在哪里？
- 为了让系统运行，有哪些特定数据必须离开厂区？
- 你们需要哪些对内的远程访问或持续更新通道？
- 这个系统会在我们的网络上建立哪些新的机器凭证或身份？
毕竟，治理不能只是抽象的公司政策。它必须作为一道防线，在供应商评选阶段、系统部署之前就发挥作用。
架构是种战略决策，而非事后补救
能够成功驾驭下一波自动化浪潮的制造商，必定是将“架构”视为部署前的战略选择，而不是等到交出安全事件报告后才来检讨的细节。你无法控制锁定制造业的攻击次数，但你绝对可以控制你要在工厂内安装多少外部 endpoints。
当你在评估一家 AI 供应商时，“我们的数据去了哪里”在你的检查表上吗？更重要的是，在你的厂里，谁负责回答这个问题？
很好奇你们团队是怎么应对这个问题的。
延伸阅读：
Table of Contents
