过去十八个月里,你在 AI 工具、试点和供应商合同上花费了 5 万到 50 万欧元。可你无法用数字告诉我,这些投入是否真的奏效。对工业运营方而言,这道鸿沟更为尖锐:如果 OT/IT 边界尚未梳理、传感器数据管道未经验证、安全体系(ISO 26262、IEC 61508、IEC 62443)尚未评估,AI 可能永远无法落到工厂车间、车载技术栈或变电站。这是 Hyperion Lifecycle 的 Discover 阶段,压缩为两周,以固定费用计价。我已审计过 30 多个 AI 项目,并交付了 10 个 AI 创业项目,其中包括 Auralink(170 万行生产代码,arXiv 2603.08736)以及自主物理系统方面的工作。失败模式反复重演。我清楚哪些缺口是物理部署的拦路虎,哪些可以放到第二波再处理。
OT/IT 边界尚未梳理,你的 AI 无法安全跨越。工业运营方拥有从未为 AI 推理流量设计过的生产网络——PROFINET 环网、隔离子网上的安全 PLC、有着严苛时序预算的车载 CAN 总线。你的 IT 团队批准了一家云端 AI 供应商,你的 OT 团队却没有。这两个域不共享同一套数据治理框架、同一套事件响应协议,也不具备 IEC 62443 监管方所能接受的网络安全态势。一个在 IT 区域里运行良好的 AI 试点,一旦需要跨越 OT 边界去读取传感器或写入执行器,就会陷入停滞。
传感器数据管道从未为 AI 训练做过验证。历史数据库的日志看起来很完整。但实际上,3 号产线上的热传感器存在 200ms 的时间戳偏移,振动数据的采样率与规格书所述不符,而标注规范在 2022 年悄然变更却没有任何迁移记录。基于这些数据训练出的模型,一旦投入生产,就会带有无人能解释的偏差。工业 AI 中的数据质量问题是系统性的——它需要一次专门的审计,而非抽查。
边缘推理就绪度尚未评估。在 Jetson、Intel NUC 或嵌入式 ECU 上运行模型,与在云端容器里运行是截然不同的工程问题。量化、延迟预算、内存占用、传感器故障下的确定性行为、网络分区时的优雅降级——这些在你现有 AI 供应商的合同里都没有记录,也没有一项在你实际的生产硬件上做过测试。
安全体系成熟度未知。你所在的行业几乎必然有一套主导的功能安全或网络安全标准——汽车领域的 ISO 26262(ASIL)、工业领域的 IEC 61508(SIL)、OT 网络安全领域的 IEC 62443、机器人领域的 ISO 10218。你的 AI 试点从未对照其中任何一项来界定范围。在一个物理 AI 系统从试点走向生产之前,安全工程师需要拿到 AI 审计团队尚未产出的证据。这次审计会准确告诉你缺失的是哪些证据,以及补齐缺口需要多长时间。
这是一项固定费用、固定范围、固定截止期的服务。第一周用于发现与技术评估——OT/IT 架构、传感器管道、边缘硬件、安全体系文档。第二周用于综合分析与撰写交付物。访谈之间我以异步方式工作,你的团队不会因为等我而被阻塞。
与工厂厂长或工程副总裁、OT/SCADA 负责人、ML 或数据团队负责人、安全或认证工程师,以及两名每日在生产环境一线工作的运维工程师,进行结构化的 60 分钟访谈。我同时审阅你的网络架构图、当前 AI 试点文档、供应商合同,以及任何已有的安全评估或 IEC 62443 / ISO 26262 差距分析。
围绕 physical-AI 的四个维度进行深度评估:(1)OT/IT 边界——网络分段、数据流路径、IEC 62443 区域与通道模型;(2)传感器数据管道——时间戳完整性、采样率一致性、标注溯源、历史数据库数据质量;(3)边缘推理就绪度——目标硬件评估、延迟与内存预算、量化可行性、连接分区行为;(4)安全体系成熟度——适用哪套标准、存在哪些工件、生产部署还缺哪些工件。
每一个缺口都按四个层级排序:物理部署拦路虎(没有它,AI 无法迁移到生产硬件)、安全体系拦路虎(缺少这一证据,认证工程师将驳回部署)、OT 集成拦路虎(没有它,AI 无法从运营技术栈读取或写入)、加固待办(从一个站点扩展到五个站点之前需处理)。每一项都附带工作量估算和负责人建议。
一份 90 天路线图——具体项目、负责人、成功指标——经过排序,使 OT/IT 边界工作和安全证据工作与任何模型改进工作并行推进。以 90 分钟的汇报形式呈交给你的领导团队。你离场时将带走一份文档:工程负责人可以执行,安全官可以审阅。
制造企业、汽车 OEM、能源公用事业及基础设施运营方的工厂厂长、工程副总裁和运营负责人——他们在 IT 区域里跑着一个 AI 试点,却无法让它跨越 OT 边界、落到生产硬件上。需要独立视角来了解 ML 团队尚未产出哪些证据的安全或认证工程师。正在为第三或第四季度的 physical-AI 部署承诺做准备、并希望在签下一份供应商合同前获得外部评估的工业或汽车企业 CAIO。这项服务不适合没有任何物理运营的纯 SaaS 公司——那类组织需要通用的 AI 就绪度审计路径。它也不适合尚未部署任何 AI 的组织;本次审计假定存在可供评估的对象。
因为你的 OT/IT 团队懂得网络拓扑,却没有从 AI 推理数据流、模型更新管道和安全体系证据要求的视角去评估它。这次审计不是网络安全评估——它评估的是你的 OT/IT 架构能否在生产规模上支撑一个物理 AI 部署,而这需要一个曾经把 AI 落地到物理系统的人。
评估范围界定为主导你所在行业的那些标准:汽车领域的 ISO 26262 和 SOTIF(ISO 21448)、工业领域的 IEC 61508(SIL)、OT 网络安全领域的 IEC 62443、机器人领域的 ISO 10218,以及面向高风险自主与工业系统的 EU AI Act 附件 III。审计会识别出适用哪套标准、当前存在哪些证据、生产部署还缺什么。我不会把网络安全标准(UNECE R155/R156)与功能安全标准(ISO 26262/IEC 61508)混为一谈——它们主导不同的失效域,需要不同的证据。
那么报告会如实写明,以书面形式,并记录下具体缺口。大约每四次工业 AI 审计中就有一次得出结论:关键路径是 OT/IT 集成工作——而非模型——若不加以解决就贸然推进,将以高昂代价换来一次失败的部署。这个发现很有价值:它能避免一个为期 16 周的物理部署项目在第八周撞上结构性拦路虎。
供应商的就绪度评估,目的是让你符合其下一笔产品销售的资格。这次审计的目的,是告诉你物理 AI 部署究竟需要什么——包括可能建议你不要续签某份供应商合同的发现。审计之后我没有任何产品要卖给你;交付物就是那份排序。
30 分钟。我会诊断你的处境，坦诚告诉你这项服务是否合适——如果不合适，什么才合适。