2026 年被⼴泛认为是制造业⼈⼯智能的关键转折年，AI 从技术试点⾛向规模化、⽣产级部署的第⼀年。继德勤（Deloitte）在 2026 年 1 ⽉发表《State of AI in the Enterprise The untapped edge》（企业⼈⼯智能发展现状：尚未挖掘的竞争优势）之后，2 ⽉份德勤中国和⾹港⼤学 AI 管理与组织中⼼（CAMO）联合发布的《2026 China AI Adoption Index：理想与现实的落差》。4 ⽉份美国的思科（Cisco）推出了两份⼯业 AI 现状的报告，⼀份是涵盖 21 个⾏业（包括制造、交通、能源、公⽤事业等）的⼯业通⽤版，另⼀份是针对制造业的。这些报告都以详尽的调查数据阐述证明了这个判断。

本文作者：彭瑜，上海⼯业⾃动化仪表研究院教授级高级工程师，PLCopen 中国组织名誉主席。

但是，有⼀组数据深刻揭示了试点成功但规模化部署缓慢的困境。2025 年 IDC 针对国内⼯业企业的调研数据显示，仅 35% 的企业能从单点 AI 试点向多环节规模化应⽤跃升，这⼀⽐例较 2024 年的 1.7% 虽有显著提升，但仍有超六成企业卡在 " 试点成功、量产停滞 " 的转型深⽔区。即便是技术领先的 " 领航⼯⼚ "，其 AI 场景渗透率超过 70%，沉淀了 6000 个垂直模型，仍普遍⾯临跨⼯序复制失效、全流程价值释放不⾜的瓶颈，形成了 " 从 0 到 1 易，从 1 到 N 难 " 的困境。

从本质上看，这是⼯业 AI 落地逻辑在不同的阶段发⽣了系统性转变：试点阶段的核⼼⽬标是 " 技术可⾏性验证 "，只需满⾜单⼀技术指标即可；但规模化量产阶段的核⼼⽬标是 " 全流程价值创造 "，要求 AI 系统能适配不同产线的⼯况差异，与现有 MES/ERP 等⼯业软件深度协同，在不影响⽣产稳定性的前提下持续优化，甚⾄能应对原料波动、订单插单等动态场景。这⼀转变直接重构了⼯业 AI 的成功衡量标准：从模型准确率转向综合设备效率 OEE 提升幅度，从技术实现难度转向运营韧性贡献度，从单⼀⼯序优化转向全⽣产链路协同价值。⼀⾔以蔽之，AI ⼯业的规模化部署是⼀个相当复杂的系统⼯程，涉及的⽅⾯远超出 AI 技术的本⾝。因此探索其中的奥妙和症结就是本⽂的追求。

影响⼯业 AI 规模化成功落地的主要因素

业界此前多将这⼀困境归因于基础设施准备不⾜、⽹络安全⻛险或系统复杂性，但 2026 年德勤中国和⾹港⼤学 AI 中国应⽤指数报告的调研数据揭示了更本质的问题：组织与⽂化障碍才是⼯业 AI 落地的最⼤阻碍（占⽐ 50%）和执⾏挑战（占⽐ 47%），显著⾼于技术基础设施（39%）、战略规划（33%）等传统显性障碍（⻅图 1）。Cisco 2026 年⼯业 AI 状态报告进⼀步量化了这⼀差异：43% 的⼯业企业存在 IT-OT 协同有限甚⾄没有效协同的问题，⽽协同隔离的企业中，90% 存在⽆线⽹络不稳定、数据采集中断等隐性技术问题，其 AI 规模化落地信⼼仅为 72%；与之相对，协同良好的企业不仅 AI 规模化信⼼⾼达 83%，其安全事件响应效率、⽣产中断恢复速度也均提升超 30%。其中 " 部⻔孤岛导致的 IT-OT 协同断裂 " 单独占⽐ 33%。

图 1 阻碍 AI 成功应⽤的关键因素

（图源 2026 年德勤中国和港⼤ AI 中国应⽤指数报告）

IT 与 OT 的协同鸿沟是⼯业 AI 从试点到规模化部署的核⼼挑战

⼯业 AI 的规模化应⽤需要信息技术 IT 与运营技术 OT 的深度融合。IT 团队负责构建数据采集和模型训练的技术底座，OT 团队负责将 AI 输出转化为实际⽣产动作。但两者分属两个完全独⽴的技术领域，⻓期在企业中垂直隔离，各⾃闭环。这种在专业背景、思维模式与⽬标优先级上的原⽣差异，形成了难以逾越的协同鸿沟。这种鸿沟并⾮简单的 " 技术接⼝不兼容 "，⽽是从语⾔体系到⻛险偏好的全⽅位错位。

IT 与 OT 团队的专业背景与知识体系的本质差异，⾸先体现在 " 语⾔体系 " 的天然割裂：IT 团队的核⼼语⾔是数据模型、算法精度、实时推理延迟。⽐如在讨论 AI 预测性维护系统时，IT ⼯程师会优先强调模型的 R ² 拟合度达到 95%、推理延迟控制在 50ms 以内；⽽ OT 团队的核⼼语⾔是⼯艺参数、设备可⽤性、订单交付周期。OT ⼯程师更关⼼这个模型能提前多久预警轴承磨损、预警后会不会影响当前批次的⽣产进度。这种语⾔体系的差异，直接导致跨部⻔沟通的效率损耗。根据⼯业互联⽹产业联盟的调研，IT-OT 跨部⻔项⽬的沟通成本较同部⻔项⽬⾼出 40%，且约 30% 的需求误解源于专业术语的认知偏差。

更深层的差异是思维模式的本质冲突：IT 团队习惯 " 概率思维 "，即接受 AI 输出的不确定性，通过迭代优化逐步提升精度，⽐如模型有 99% 的把握识别设备异常，建议安排维护；⽽ OT 团队的思维模式是 " 布尔逻辑 "，⼯业⽣产的稳定性要求决策必须 100% 可靠，任何误判都可能导致整条产线停机，因此 OT ⼯程师更倾向必须有明确的故障证据才允许停机。这种思维冲突在实际场景中屡⻅不鲜，例如某钢⼚的 AI 能耗优化模型，IT 团队测试的准确率达 92%，但 OT 团队因模型存在 8% 的误判率，担⼼误判导致的⽣产波动⻛险，最终拒绝在主⼒产线部署，导致该模型仅在⼀条备⽤产线闲置，未能实现预期的节能效益。

这⼀鸿沟进⼀步放⼤了⽬标优先级的差异：IT 团队的核⼼⽬标是构建标准化、可复⽤的技术底座，实现不同设备的数据格式归⼀化；⽽ OT 团队的核⼼⽬标是解决当前⽣产痛点，保障订单交期。这种⽬标错位直接导致资源分配的冲突。例如某汽⻋零部件企业的 IT 团队投⼊百万搭建数据中台，但 OT 团队因急需解决某⼯序的质检效率问题，⾃⾏采购了第三⽅的 AI 视觉检测系统，最终两套系统因数据接⼝不兼容，均未能实现预期价值，反⽽造成了资源浪费。

协同断裂的具体表现在从需求定义到模型迭代的全流程冲突。IT-OT 协同的断裂并⾮偶然，在需求定义阶段技术与业务的脱节；在数据采集阶段滤波需求与因果识别的⽭盾；在模型部署阶段实时响应与⽣产稳定性的平衡难题。这些都是贯穿于⼯业 AI 项⽬从需求定义到模型迭代的全⽣命周期，每⼀个环节的错位都可能导致项⽬夭折。

需求定义是⼯业 AI 项⽬的起点，也是协同断裂的重灾区。OT 团队基于⼀线⽣产经验提出的需求，往往是模糊的、场景化的。⽐如 " 解决冲压机振动导致的产品不良问题 "；但 IT 团队若缺乏对⼯艺机理的理解，会将其转化为 " 振动数据的频谱分析模型开发 " 这类技术化表述，最终的交付成果可能在技术上达标，但⽆法解决实际问题。某重⼯企业的 IT 团队曾投⼊数⼗万元，耗时 3 个⽉打通设备 IoT 与 CMMS 系统，想实现 " 设备数据⾃动联动维护⼯单 " 的功能，但全程未与 OT 团队（设备部）对⻬需求：IT 团队采集的是设备电流数据，⽽设备部判断轴承故障的核⼼指标是轴承温度；最终系统⽣成的维护⼯单全是误报，设备部不堪其扰直接弃⽤，数⼗万元投⼊完全浪费。数据是⼯业 AI 的核⼼燃料，但 IT 与 OT 团队在数据需求上存在本质冲突：OT 团队为避免⼀线操作员误判，习惯在 PLC 中设置滤波算法，⽐如将振动数据的⾼频波动进⾏平滑处理，确保为操作员显示的参数稳定；但 IT 团队需要原始数据来识别设备故障的因果关系，⽐如⾼频振动的突变恰恰是轴承早期磨损的核⼼特征，滤波后的数据会直接掩盖这⼀关键信号。这种⽭盾的直接结果是 " 数据质量陷阱 "：根据 2026 年⼯业 AI 落地调研报告，34% 的企业存在 " 数据整理责任推诿 " 问题，IT 团队认为 OT 团队应负责数据的⼯艺有效性校验，OT 团队则认为 IT 团队应负责数据的采集准确性，最终导致 AI 模型因 " 脏数据 "（如缺失关键参数、时间戳不同步、⼈⼯录⼊错误）形同虚设。某电⼦制造企业的 AI 质检模型，因训练数据中混⼊了 OT 团队滤波后的 " 平滑数据 "，其缺陷识别准确率从实验室测试的 95% 降⾄量产阶段的 70%，最终造成近百万元的返⼯损失。

模型部署是⼯业 AI 从实验室⾛向⽣产的关键⼀步，但 IT 团队的技术⽬标与 OT 团队的⽣产约束往往直接冲突：IT 团队追求 " 实时推理效率 "，⽐如将模型部署在云端以获取更强的算⼒⽀持，实现毫秒级推理；但 OT 团队的核⼼约束是 " 零停机⻛险 "，云端部署需要依赖稳定的⽹络，⼀旦⽹络出现波动，AI 输出的中断可能导致产线停机，⽽⼯业场景的停机成本极⾼。某汽⻋零部件企业的 OT 团队曾测算，⼀条主⼒产线的停机成本约为每分钟 1.2 万元，即使是 10 分钟的短暂停机，也会造成 12 万元的直接损失。某汽⻋零部件企业曾在⼀条冲压产线测试 AI 预测性维护模型，IT 团队为了实现实时推理，将模型部署在云端，但在⼀次⽹络波动中，AI 预警信号延迟 15 秒，导致冲压机因轴承磨损发⽣卡壳，最终停机 2 ⼩时，直接经济损失超 140 万元。此后，OT 团队对所有云端部署的 AI 系统均持抵触态度，要求必须 100% 满⾜ " 零停机⻛险 " 才能上线。

构建结构化的 IT-OT 协作机制

⼯业 AI 的规模化应⽤，不需要 IT 与 O 团队的⻆⾊融合，⽐如要求 OT ⼯程师掌握 Python 编程，或要求 IT ⼯程师精通 PLC 逻辑。这既不现实，也会浪费双⽅的专业优势。真正需要的是 " 结构化协同 "，通过明确的⻆⾊分⼯、统⼀的沟通语⾔以及绑定的激励机制，让双⽅的专业优势形成互补，⽽⾮相互抵消。

为此需要建⽴ " 翻译层 " ⻆⾊与混合敏捷⼯作模式。" 翻译层 " 是连接 IT 与 OT 的关键枢纽，其核⼼价值是将 IT 的技术语⾔转化 OT 的业务语⾔，将 OT 的模糊需求转化为 IT 的可落地⽅案。温州市 2026 年出台的《"AI ⾏业翻译官 " ⼯作实施⽅案》中，这类⻆⾊被明确定义为 " 既懂⼯业⼯艺机理，⼜懂 AI 技术逻辑的复合型⼈才 "。他们不是简单的 " 传声筒 "，⽽是能深⼊⼀线，将 OT 团队的模糊需求转化为可落地的 AI 场景⽅案。

在实际企业场景中，" 翻译层 " 的具体形式包括三类：第⼀类是 " ⼯业 AI 产品经理 "，其⻆⾊多由 OT 团队的资深⼯程师转型⽽来，既懂⽣产⼯艺，⼜懂 AI 技术的边界，能在 IT 与 OT 之间搭建沟通桥梁；第⼆类是 " 数字孪⽣架构师 "，负责构建与物理产线 1:1 映射的数字孪⽣模型，将 OT 团队的⼯艺参数转化为 IT 团队可识别的模型变量；第三类是 " 跨职能协同专员 "，专⻔负责协调 IT-OT 的需求冲突，⽐如当 IT 团队的技术⽅案影响⽣产稳定性时，这类专员会组织双⽅进⾏⻛险评估，找到平衡点。

与⼯业场景适配的混合敏捷⼯作模式。按照 IT 团队 " 快速迭代 " 的需求，设计了敏捷开发模式（如 Scrum），但⼯业场景的 " 连续⽣产、零停机 " 约束，决定了其⽆法直接套⽤。AI ⽐如 IT 团队的 " 每⽇站会 " 若安排在⽣产⾼峰时段，OT 团队的⼯程师根本⽆法参与。因此，⼯业场景的混合敏捷模式，必须针对 OT 团队的⽣产节奏进⾏定制化优。具体⽽⾔，这种适配包括三个核⼼要点：其⼀，迭代周期与⽣产班次对⻬。将传统的 "2 周迭代 " 调整为 "12 ⼩时迭代 "，与⼯业场景的 " 四班三倒 " 班次匹配，确保每个班次都有 OT ⼯程师参与迭代；其⼆，决策流程嵌⼊⽣产间隙，将每⽇站会安排在交接班的重叠时段，避免影响正常⽣产；其三，技术⽀援机制覆盖全时段，建⽴ "7 × 24 ⼩时 IT-OT 联合⽀援⼩组 "，OT 团队负责现场设备的应急处理，IT 团队负责系统的技术修复，确保任何时段的问题都能在 30 分钟内得到响应。

以上阐述的内容是⼯业 AI 规模化落地的 IT-OT 协同的核⼼载体和⼯作流程机制，⽤图 2 表述如下。

图 2 ⼯业 AI 规模化落地的 IT-OT 协同的

核⼼载体和⼯作流程机制

促进 IT-OT 有效协作的三⼤⽀柱：信任、语⾔与激励。要打破 IT-OT 的协同壁垒，仅靠⻆⾊和流程设计还不够，必须从⽂化层⾯⼊⼿，构建 " 信任、语⾔、激励 " 三⼤⽀柱。这是协作机制能⻓期运⾏的基础。

信任：从 " 追责⽂化 " 到 " 失败学习 " 的组织变⾰。信任是 IT-OT 协同的基⽯，⽽⼯业场景的信任建⽴，核⼼是 " 明确责任边界，包容合理试错 "。具体机制包括两类：⼀是 " 技术容错机制 "，通过技术⼿段限制 AI 的决策权限，确保其不会对⽣产造不可逆的影响，⽐如⻄⻔⼦ Industrial Copilot 的 " ⼈机共决 " 流程，设置动态安全边界（如锅炉温度控制 ± 2 ℃阈值），当 AI 输出超出范围时，3 秒内推送预警⾄现场⼯程师，由⼯程师判断是否执⾏，⽽⾮ AI 直接控制设备。⼆是 " 组织容错机制，从 " 追责⽂化 " 转向 " 失败学习 "，⽐如某汽⻋零部件企业设⽴了 AI 试点失败免责条款，只要项⽬组在试点前完成了 " ⼯艺⻛险评估 "、" 数据质量验证 ""、技术⽅案评审 " 三个环节，且失败原因是技术探索中的合理试错（⽽⾮疏忽），就不会追究团队的责任。这种机制不仅降低了 OT 团队的试错⻛险，更⿎励了跨部⻔的协作创新。譬如某企业的 AI 预测性维护项⽬，正是在三次试点失败后，最终实现了⾮计划停机减少 40% 的成效。

语⾔：联合术语库与跨职能培训的协同。共同的语⾔体系是 IT-OT 有效沟通的前提。构建这种语⾔体系，需要从 " 术语对⻬ " 和 " 能⼒互补 " 两个维度⼊⼿。其⼀，建⽴ " ⼯业 AI 联合术语库 "，由 IT-OT 团队共同定义核⼼术语的标准，⽐如明确 " 设备健康度 " 的定义是 " 基于振动、温度、电流三个参数的加权得分 "，⽽⾮ IT 团队的 " 模型输出概率 " 或 OT 团队的 " ⼈⼯经验判断 "。其⼆，实施 " 跨职能培训计划 "，IT 团队需掌握⼯业⼯艺的核⼼逻辑，OT 团队需掌握 AI 技术的基本边界。某钢铁企业的培训计划规定，IT ⼯程师需在产线实习 1 个⽉，考取 " ⼯业⼯艺基础证书 " 才能参与 AI 项⽬；OT ⼯程师需完成 "AI 技术基础 " 课程，了解模型的局限性，避免对 AI 系统提出不切实际的需求。

激励：从个体 KPI 到联合 KPI 的绑定。激励机制是 IT-OT 协作的 " 指挥棒 "，若仍采⽤个体 KPI，双⽅会优先关注⾃⾝⽬标，⽽⾮共同价值。因此，必须将 IT 与 OT 团队的激励绑定，设计 " 结果 + 过程 " 双维度的联合 KPI 体系。具体⽽⾔，这种联合 KPI 体系包括三类指标：⼀是 " 结果指标 "，如 OEE 提升幅度、⾮计划停机时间减少⽐例、能耗降低⽐例等，这类指标直接衡量 AI 项⽬的业务价值；⼆是 " 过程指标，如数据打通率、模型迭代频率、OT 团队的反馈响应时间等，这类指标衡量跨部⻔协作的效率；三是 " 协同指标 "，如跨部⻔会议的参与率、需求冲突的解决时⻓等，这类指标衡量协同的质量。某汽⻋零部件企业的联合 KPI 体系中，IT 团队的 " 模型准确率 " 与 OT 团队的 " ⽣产稳定性 " 权重各占 50%。若模型准确率达标但导致⽣产波动，双⽅都⽆法获得全额奖⾦；只有当模型准确率和⽣产稳定性同时达标时，才能拿到全额奖⾦。这种绑定机制，彻底扭转了双⽅的⾏为逻辑，从各⾃为政转向协同优化，最终该企业的 AI 视觉检测项⽬，不仅将缺陷识别率提升⾄ 99.5%，还将⾮计划停机时间减少了 35%。图 3 表示⼯业 AI 规模化落地的 IT-OT 协同的⻓效组织保障，概括了上述的⽂字说明。

图 3 ⼯业 AI 规模化落地的 IT-OT 协同的⻓效组织保障

技术债务：被忽视的规模化障碍

⼯业 AI 的技术债务是指为了快速实现试点效果，⽽采⽤的短期技术⽅案，在量产阶段带来的⻓期维护成本与⻛险。与传统软件的技术债务（如代码冗余、架构耦合）不同，⼯业 AI 的技术债务具有更强的隐蔽性，其影响不会⽴即显现，⽽是在量产阶段逐步暴露，最终导致项⽬失败。技术债务的类型与成因：

⼯业 AI 的技术债务主要源于 IT-OT 协同的缺失，其具体类型包括三类：

数据债务。数据债务是⼯业 AI 最常⻅的技术债务，主要源于 IT-OT 团队的协同断裂。IT 团队负责数据采集，但未与 O 团队协同定义数据标准，导致产⽣数据孤岛。⽐如某汽⻋零部件企业的 IT 团队采集了设备的电流、振动数据，但 OT 团队需要的是轴承温度、润滑油压⼒数据，最终采集的数据⽆法满⾜业务需求；OT 团队负责数据的⼯艺有效性，但未与 IT 团队协同进⾏数据清洗，导致 " 脏数据 "。⽐如某钢⼚的 AI 模型，因训练数据中混⼊了错误的⼯艺参数，其缺陷识别准确率从 95% 降⾄ 70%。数据债务的典型案例是某电⼦制造企业：该企业的 AI 排产模型因训练数据中混⼊了 OT 团队滤波后的 " 平滑数据 "，其排产准确率从实验室测试的 90% 降⾄量产阶段的 65%，最终导致近百万的订单交付延误损失。

模型债务。模型债务主要源于 IT 团队未充分考虑 OT 团队的⽣产约束，或 OT 团队未将⼯艺经验嵌⼊模型。IT 团队为了追求模型准确率，采⽤了过于复杂的模型（如深度学习模型），但这类模型的可解释性差，OT 团队⽆法理解模型的决策逻辑，因此拒绝信任模型输出；或者模型未与 OT 团队的⼯艺经验结合，导致模型输出不符合实际⽣产需求。⽐如某钢⼚的 AI 能耗优化模型，未将 OT 团队的 " 原料热值低于 4500 ⼤卡时，需额外增加 10% 的助燃⻛ " 的经验嵌⼊模型，最终模型输出的参数⽆法适配实际⼯况，节能效果⼤幅衰减。模型债务的典型案例是某化⼯企业的 AI 质量检测模型，该模型的准确率达 98%，但因可解释性差，OT 团队⽆法理解 " 模型为什么判定这个产品是不良品 "，最终拒绝在主⼒产线部署，仅在备⽤产线闲置。

基础设施债务。基础设施债务主要源于 IT 团队未充分考虑⼯业场景的物理约束，或 OT 团队未将设备的物理特性告知 IT 团队，IT 团队为了追求技术先进性，采⽤了不适合⼯业场景的基础设施。⽐如在⾼温、⾼湿的⻋间部署普通服务器，导致服务器频繁死机；或者未对原有系统进⾏兼容改造，导致 AI 系统⽆法与现有 MES/ERP 系统集成。⽐如某汽⻋制造企业的 AI 系统，因⽆法与运⾏了 15 年的 MES 系统集成，最终沦为 " 信息孤岛 "，⽆法实现全流程优化。基础设施债务的典型案例是某重⼯企业的 IT 团队投⼊百万搭建了数据中台，但因未考虑 OT 团队的⽼旧 PLC 设备的通信协议（如 Modbus RTU），导致数据采集中断率达 20%，最终数据中台⽆法正常使⽤，沦为 " ⾯⼦⼯程 "。

技术债务对⼯业 AI 规模化的影响：⼯业 AI 的技术债务不仅会增加项⽬的维护成本，还会直接影响 AI 系统的性能稳定性，甚⾄导致项⽬失败。2025 年 IBM 商业价值研究院的调研数据显示，忽视技术债务的企业，项⽬回报会下降 18%-29%，项⽬时间线会延⻓多达 22%。这意味着技术债务会直接吞噬⼯业 AI 的价值，让企业的投⼊⾎本⽆归。从具体量化指标来看，技术债务的影响包括三类：其⼀，维护成本上升。某企业的 AI 系统，因数据债务，维护成本从每年 210 万上升⾄ 380 万，涨幅达 80%。其⼆，系统可⽤性下降。某企业的 AI 系统，因基础设施债务，可⽤性从 99.97% 降⾄ 89%，每年因系统中断造成的损失达千万。其三，项⽬回报下降。某企业的 AI 能耗优化项⽬，因模型债务，项⽬回报从预期的 200 万元 / 年，降⾄实际的 50 万元 / 年，降幅达 75%。

更关键的是，⼯业 AI 的技术债务具有 " 传导效应 "，数据债务会导致模型债务（⽐如脏数据会导致模型准确率下降），模型债务会导致基础设施债务（⽐如模型复杂度上升会要求更强的算⼒⽀持），最终形成 " 债务雪球 "，让企业的 AI 项⽬陷⼊ " 越维护越花钱、越优化越差 " 的恶性循环。某电⼦制造企业的案例更能体现这⼀传导效应，该企业的 AI 排产模型，因数据债务（训练数据中混⼊了错误的⼯艺参数），导致模型准确率下降。为了提升准确率，IT 团队采⽤了更复杂的深度学习模型，导致模型债务（可解释性差），为了运⾏这个复杂模型，IT 团队不得不升级服务器，导致基础设施债务（成本上升）。最终该项⽬的维护成本超过了预期收益，被迫暂停。

要破解技术债务的陷阱，必须从组织层⾯⼊⼿，建⽴ IT-OT 联合治理机制，将技术债务的管理纳⼊项⽬全⽣命周期，⽽⾮仅由 IT 团队负责。联合治理机制的核⼼要点包括三类：其⼀，建⽴ " 技术债务识别与量化体系 "，由 IT-OT 团队共同识别技术债务，并量化其对业务的影响，⽐如某企业将技术债务分为 " ⾼、中、低 " 三个优先级，优先解决对业务影响⼤的债务（如数据债务）。其⼆，实施 " 分层治理策略 "，底层通过 AI 技术识别债务（如⽤ AI 分析数据质量，识别数据债务），中层运⽤⾃动化⼯具修复债务（如⽤⾃动化⼯具清洗数据，修复数据债务），⾼层建⽴债务预防机制（如在项⽬⽴项时，要求 IT-OT 团队共同评审技术⽅案，预防技术债务）。其三，将债务修复纳⼊迭代流程，采⽤ " 债务冲刺 " 机制，将债务修复纳⼊ Sprint 迭代，⽐如亚⻢逊的债务冲刺机制，要求每个迭代都要修复⾄ 10% 的技术债务，确保技术债务不会越积越多。

⽹络安全⻛险管理体现协同与隔离的差异

在⼯业 AI 规模化过程中，⽹络安全并⾮单纯的技术问题，⽽是与 IT-OT 协同深度绑定的组织问题，协同模式直接决定了安全⻛险的识别效率与响应能⼒。2025 年对 150 起制造业勒索软件攻击的复盘数据显示，92% 曾实施物理隔离的企业仍被攻破，彻底颠覆了 " 物理隔离 = 绝对安全 " 的传统认知，这并⾮物理隔离失效，⽽是隔离型企业的 IT-OT 协同断裂，导致安全防御存在盲区。

协同良好的组织与隔离型组织的核⼼差异，在于安全设计的 " 时间维度 "：前者将安全嵌⼊⼯业 AI 项⽬的全⽣命周期（⻅图 4），后者仅在项⽬上线后进⾏被动防御。

这种差异直接决定了安全⻛险的控制效果。其核⼼是 " 把安全从项⽬的收尾环节，提前到需求定义、设计、开发、测试等前置环节 "，其具体落地机制包括三类：其⼀，需求定义阶段的 " 安全需求前置 "，在项⽬⽴项时，由 IT-OT 联合团队共同识别安全⻛险，⽐如某化⼯企业的 AI 质量检测项⽬，在需求阶段就识别出 "AI 模型输出的参数可能被篡改，导致反应釜温度异常 " 的⻛险，并提前设计了 " 双重校验机制 "（AI 输出需经⼈⼯复核才能⽣效）。其⼆，设计阶段的 " 威胁建模 "，基于 ATT&CK for ICS 框架，识别 AI 系统的潜在攻击路径，⽐如有效识别出 "AI 模型训练数据被污染 " 的潜在⻛险，并设计了 " 数据溯源机制 "，对每⼀条训练数据的来源、采集时间、采集设备进⾏记录，避免恶意数据混⼊。其三，开发阶段的 "DevSecOps 融⼊ "，将安全扫描嵌⼊模型训练的 CI/CD 流程，⽐如在模型训练前会⾃动扫描训练数据的完整性，训练过程中会监控模型的鲁棒性，部署前会进⾏渗透测试，确保模型不会被恶意攻击利⽤。

图 4 将信息安全嵌⼊⼯业 AI 项⽬的全⽣命周期

针对⼯业 4.0 的动态场景，传统的 " 信任内部、不信任外部 " 的纵深防御模型已完全失效，⼯业场景的攻击⾯不再局限于外部⽹络，内部员⼯的误操作、第三⽅供应商的弱密码，都可能成为攻击⼊⼝。因此，协同良好的组织普遍采⽤零信任架构，其核⼼是 " 永不信任、始终验证、动态授权 "。⼯业场景的零信任架构，并⾮简单的 " 技术部署 "，⽽是 " 组织协作模式的重构 "，其具体落地要点包括三类：其⼀，基于⻆⾊的访问控制（RBAC），根据⽤户的⻆⾊、岗位、时间、地点等维度，动态分配访问权限，⽐如某汽⻋制造企业的 AI 系统，仅允许 OT 团队的⼯程师在⼯作时间、从⻋间终端访问模型输出，且访问权限仅为 " 查看 "，⽽⾮ " 修改 "。其⼆，微隔离技术——将⽣产⽹络划分为多个独⽴的安全域，每个安全域之间设置严格的访问控制策略每个域之间仅允许特定的协议通信，即使某个域被攻破，攻击者也⽆法横向移动到其他域，将⻛险控制在最⼩范围内。其三，持续监控与动态调整，通过 AI 技术实时监控⽤户的⾏为，若发现异常（如⾮⼯作时间访问、访问敏感数据），⽴即调整其访问权限，并向安全团队发送预警，避免数据被篡改。

⼯业场景的安全管理，核⼼⽭盾是 " 安全防御与⽣产连续性的平衡 "，安全防御过严会影响⽣产效率；防御过松会导致安全⻛险。协同良好的组织，通过 IT-OT 的协同机制，能实现两者的动态平衡。协同型组织的平衡策略，核⼼是 "IT-OT 联合决策 "，其具体机制包括三类：其⼀，" 安全停机窗⼝ " 与⽣产排程联动，将安全维护⼯作安排在产能低⾕期。其⼆，⻛险分级响应机制，根据⻛险等级，动态调整安全措施的严格程度。这种分级机制，既保障了⽣产连续性，⼜控制了安全⻛险。其三，AI 驱动的动态阈值调整，通过 AI 技术，实时调整安全阈值，根据当前的⽣产订单、设备状态、原料情况，动态调整设备的安全阈值：当⽣产⾼价值订单时，阈值会适当降低，确保产品质量；当⽣产普通订单时，阈值会适当提⾼，提⾼⽣产效率。

⼯业 AI 从试点到⽣产的规模化应⽤，其主要障碍并⾮技术本⾝，⽽是⼈员协同机制的缺失。基于 2025-2026 年的⾏业调研与典型案例，得出以下发现：

1. 协同是⼯业 AI 规模化的核⼼推动⼒：IT 与 OT 团队的有效协同，能显著提升⼯业 AI 的落地成功率。

2. 结构化协同机制是关键抓⼿：建⽴ " 翻译层 " ⻆⾊、混合敏捷⼯作模式、联合 KPI 体系，能有效打破 IT-OT 的协作壁垒，翻译层 " 能将 IT 的技术语⾔转化为 OT 的业务语⾔，混合敏捷⼯作模式能适配⼯业场景的⽣产节奏，联合 KPI 体系能将双⽅的⽬标绑定，形成协同动⼒。

3. 安全是协同的结果，⽽⾮前提：协通良好的组织，能将安全嵌⼊⼯业 AI 项⽬的全⽣命周期，实现 " 安全与效率的双赢 "。

4. 技术债务是⼯业 AI 规模化的隐形陷阱：忽视技术债务的企业，将造成项⽬回报下降，项⽬时间线会延⻓，技术债务会直接吞噬⼯业 AI 的价值，让企业的投⼊⾎本⽆归。

基于上述发现，提出以下三点建议供参考：

1. 优先构建 IT-OT 协作痛制：企业应将 IT-OT 协同机制的构建，置于⼯业 AI 项⽬的核⼼位置，设⽴ " ⼯业 AI 协同治理委员会 "，由 IT 与 OT 团队的负责⼈共同牵头，明确双⽅的责任边界与协作流程；同时，应建⽴ " 翻译层 " ⻆⾊（如⼯业 AI 产品经理），负责连接 IT 与 OT 团队，将模糊需求转化为可落地的⽅案。

2. 实施安全与零信任架构：企业应将安全嵌⼊⼯业 AI 项⽬的全⽣命周期，实施安全设计。在需求定义阶段就识别安全⻛险，在设计阶段进⾏威胁建模，在开发阶段融⼊ DevSecOps 流程；同时，应采⽤零信任架构，基于⻆⾊的访问控制、微隔离技术、持续监控与动态调整，实现 " 永不信任、始终验证、动态授权 "，应对⼯业 4.0 的动态场景挑战。

3. 建⽴技术债务治理体系：企业应将技术债务的管理纳⼊项⽬全⽣命周期，建⽴ IT-OT 联合治理机制，共同识别技术债务，量化其对业务的影响，优先解决⾼优先级债务；同时，应实施分层治理策略将债务修复纳⼊迭代流程，采⽤ " 债务冲刺 " 机制，确保技术务不会越积越多，最终吞噬⼯业 AI 的价值。