北京
一份由IBM商业价值研究院与迪拜未来基金会共同完成的研究，抛出两组反差强烈的数字：93%的企业高管说，数字主权必须融入业务战略；可同时，只有不到三分之一的人知道自家AI工作负载究竟跑在哪个数据中心，而拥有AI系统完整清单的比例，只有18%。共识与落地之间，隔着一道几乎断裂的可见性鸿沟。面对这道鸿沟，IBM今天抛出了一个新的工具——云主权风险概况（Cloud Sovereignty Risk Profile），试图把看不见的合规与治理，变成可监控、可举证、可审计的日常操作。
这个工具被集成在IBM安全与合规中心的工作负载保护平台里，目标很明确：持续扫描云上的工作负载，把“数据放在哪、加密到不到位、运营控制是否按预期运转”整理成一套可出示的证据链。负责开源的副总裁在介绍时，反复用到一个词——可证明性（provability）。他说，很多企业过去只能靠合同或条款声称合规，但监管机构越来越要求企业拿出“当时正在发生的证据”，而不仅仅是一份静态证书。主权风险概况在做的就是这件事：把合规从文档审核，变成持续性的监控日志。
支持的一方认为，这算是回应了一个日渐紧迫的诉求。随着AI模型跨越多个司法辖区部署，数据可能流经不同国家的公有云、私有云、边缘节点，任何一段环节脱离视线，都可能触发监管风险。IBM把新工具放在一套更宽泛的数字主权框架里，这个框架有四个支柱：可证明性、预防、隐私和可移植性。持正面态度的人喜欢“预防”这一环：IBM强调主权的起点是云提供商永远不能访问企业数据，哪怕政府来要也不行。为此他们搬出了“保留你自己的密钥”（Keep Your Own Key）技术，密钥硬件拿到了联邦信息处理标准140-3第4级认证——说直白点，就是连云服务商自己在物理层面也打不开。隐私这一条则把部署灵活性推上前台：专用多可用区区域、单租户环境、与当地运营商合作的模式，都是为了让工作负载可以稳稳地住在某个司法管辖区内。最后可移植性给了一套技术承诺：基于红帽OpenShift、Kubernetes和开放接口，客户可以在不同云之间迁移工作负载，不被绑死在一家供应商上。
但持谨慎态度的人，眼光会落在另外两组数据上。不到三分之一的高管知道AI的工作负载放在哪里，这说明大量组织对自身基础设施的拓扑认识还停留在表层。另外，只有18%的企业持有AI系统的现存清单。如果把主权战略比作一座大厦的设计图，那现在大多数公司连地基勘探报告都没有画完。反对者会问：一个监控和报告平台，真能推动组织去完成那些需要投入资源、改造流程、重新培训团队的基础性工作吗？一个工具可以自动扫描工作负载，但要准确知道“哪些数据属于AI训练任务、哪些属于推理任务”，首先得有人把这些工作负载分门别类地标注好。如果连清单都不维护，输入就是噪声，输出的“风险概况”又能信几分？
IBM显然也清楚这一点。他们在解释“可证明性”时，并不只停留于监控，而是把它跟“评估数据驻留、加密、弹性和运营独立性”结合起来。也就是说，平台既能生成审计所要求的证据，也会在风险偏好超标时发出提醒，比如某个关键数据集意外地跑到了另一个地理区域。但要兑现这个目标，需要企业自行定义策略和阈值——这恰恰也是反对方所指的功课。工具可以帮助自动化验证规则是否被执行，但规则的设定需要人对业务、法律和技术的综合判断，工具没法越俎代庖。
我的判断是，这个工具对已经下定决心要治理多国业务的企业，会是一块务实积木。它把抽象的“主权”翻译成加密密钥控制、部署地点记录、运营合规日志，让企业可以有凭有据地和监管者对话。不过同时，对面那道可见性缺口并不会自动合拢。93%的高管说主权重要，可现在只有18%维护AI系统清单，说明从“意识到重要性”到“愿意投入资源维持一份动态清单”，中间还隔着一层迟疑——可能来自成本，也可能来自对主权边界的模糊理解。IBM的工具更像是一面高亮镜，帮助企业把散落在多云环境中的问题照出来，但照出来后能否驱动持续的行动，还得看企业的内部动员。无论如何，把问题从“感觉上”变成“看得到的数据”，已经往前进了一步。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
