摘要当 AI 热潮席卷企业跨国 CISO 却普遍回答AI 不归我管。本文揭示AI 风险既非技术风险也非合规风险而是嵌入业务流程的业务流程风险治理者必须能介入流程。传统云责任共担由厂商画好边界而 AI 的责任边界需CISO 牵头自画——把产品、技术、法务、隐私的责任组织成一套能跑的流程无需立项与预算审批。CISO 不再说这不归我管才是守住 GenAI 底线的起点。前一阵子龙虾盛行但没几天事件又反转很多企业高调发禁令、切断对接外部 AI 平台、贴公告。我想起我的几个在企业里做 CISO 的朋友于是想着跟他们聊聊这波 AI 热潮对公司信息安全带来的挑战。前一阵子“龙虾”盛行但没几天事件又反转很多企业高调发禁令、切断对接外部 AI 平台、贴公告。我想起我的几个在企业里做 CISO 的朋友于是想着跟他们聊聊这波 AI 热潮对公司信息安全带来的挑战。第一个朋友放下筷子悠悠地说AI 不归我管。我以为是个例结果去问了第二个朋友、第三个朋友、第四个朋友得到的都是同一个答复。这让我不禁困惑起来:我是不是对 CISO 这个 title 有什么误解。I 到底代表什么?Information,还是 Innocent?或者是 Ignorance?恍惚过后,我突然想起几件我旁观过的事:有一次。 某 CISO 先于公司领导层嗅到了 AI 兴起带来的治理隐患,于是他打算提前布局防范风险,立项启动 AI 治理项目。申请提到领导层后被驳回了,理由是:公司尚未批准部署 AI 应用,该风险治理项目缺乏治理目标和充分理由,不予批准。还有一次。 某 CISO 注意到公司的年度重点项目是AI 赋能营销平台,他听说这个平台会利用大量销售数据做模型算法,他觉得这里涉及商业决策带来的公平性问题,但他又转念一想——这是典型的商业风险,他无权过问。又有一次。 某 CISO 无意间通过公司内部全员公告发现某明星业务部门启动了他们自己的 AI 赋能项目,他感到隐隐不安,很担心数据泄露的风险。但是,这个 AI 赋能项目是这个业务线自己牵头的,又是独立部署,与公司现有 IT 系统无集成。从公司角度,他只能负责 IT 部门出资并负责设计和实施的系统。甚至要不是他认真阅读了最近三天的通知邮件,他可能都不知道有这样一个项目的存在。当我把这三件事串联在一起后再去回想 CISO 的那句不归我管,我对他们的态度从一开始的费解迅速转变成了理解。然而,这件事并不是理解了就完事了。AI 新兴技术给传统公司信息安全边界带来的巨大冲击和影响,也并不是当没看见就真的可以当作没发生。总要有一个人站出来做预警,做风控。而最该做的,是先把下面这两件事搞明白:第一:搞清楚 AI 风险究竟是什么类型的风险有人会问,怎么判断 AI 安全应该给谁负责?这是个很好的问题。市面上大部分公司会从以下三条路线里选:路线 1:把 AI 安全纳入安全团队的责任。 但是安全团队不懂 AI 专有技术,不能深入理解风险是什么、在哪里、怎么整改——最终安全审核沦为走过场。路线 2:把 AI 安全融入 AI 技术团队。 但是 AI 团队一天到晚为业务需求研发模型算法,早已想破了脑袋,他们绝对不可能为安全浪费一秒钟——最终 AI 安全沦为一个不落地的概念。路线 3:公司内部成立虚拟的 AI 治理委员会,从好多个相关部门派代表进这个委员会商讨事项。但众所周知,“当一件事的负责人大于 1 时就等于没人负责”——最终 AI 安全还是没人管。这三种做法的共同问题是——它们都在回避一个核心问题:AI 风险到底属于什么类别的风险?我的判断是:AI 风险既不是技术风险,也不是合规风险——它是业务流程风险。这意味着,治理它的人必须能介入业务流程。这也意味着,治理它的不可能是一个人或者一个团队——因为流程是团队协作才能跑起来的。第二:基于职能归属,牵头建立责任共担模型嵌入到业务流程的 AI 安全治理到底应该怎么做?借用一个客户这边的最佳实践来举例:需求阶段: 产品团队提出想用 AI agent 做客服自动回复——这一步必须过隐私评估问卷(由隐私团队设计、产品团队填写)。问卷看似简单,但回答它的过程会让产品经理意识到,这个功能设计会把客户对话喂给 AI,这意味着数据出境、合同条款、用户告知都要重新走。设计阶段: 技术架构师提出技术方案——这一步必须过应用安全评估(由应用安全团队主导)。重点不是技术细节,而是 prompt 里包含什么数据?response 存哪里?异常输出怎么处理?开发阶段: 写代码的工程师必须用统一的 API 网关——网关层面做日志、脱敏、限流。不允许工程师直接调用外部 AI 的 API。测试阶段: 用合成数据测试,不能用真实客户数据。发布阶段: 每个 AI 功能上线前过最终合规 review——由 DPO、CISO、法务联合签字。看到这里你可能发现了——AI 责任共担模型,根本不是什么新发明,跟云平台的责任共担在本质上是一回事。唯一的区别在于:云的责任边界是云厂商画好了给你的,你只需要照着接。AI 的责任边界,得你自己画。而画这条边界的人,只能是 CISO。最后,让我们回到这个问题的起点:AI 的安全治理风险,CISO 到底该不该管?我的回答是:该管。 但不是要 CISO 一个人扛起公司所有的 AI 安全责任,他要做的是站在更广阔的视角上,把分散给产品、技术、法务、隐私、采购的责任,组织成一套能跑的流程。这套AI 责任共担模型,不需要立项、不需要预算审批,不需要等领导层点头。它需要的只是一件事——CISO 不再说这不归我管。正文结束────────────── 免责声明本文所有案例均源于作者在跨国项目交付与合规落地中的行业观察与机制复盘。为恪守职业操守与保密协议文中情境已进行彻底脱敏、抽象与多源融合不指向任何特定企业、团队或个人。写作初衷仅为探讨安全治理的共性机制与流程优化旨在揭示系统性设计漏洞非针对具体个体或业务线。文中观点仅代表作者个人专业思考不代表任何雇主、客户或项目合作方立场。欢迎聚焦议题理性交流。
摘要当 AI 热潮席卷企业跨国 CISO 却普遍回答AI 不归我管。本文揭示AI 风险既非技术风险也非合规风险而是嵌入业务流程的业务流程风险治理者必须能介入流程。传统云责任共担由厂商画好边界而 AI 的责任边界需CISO 牵头自画——把产品、技术、法务、隐私的责任组织成一套能跑的流程无需立项与预算审批。CISO 不再说这不归我管才是守住 GenAI 底线的起点。前一阵子龙虾盛行但没几天事件又反转很多企业高调发禁令、切断对接外部 AI 平台、贴公告。我想起我的几个在企业里做 CISO 的朋友于是想着跟他们聊聊这波 AI 热潮对公司信息安全带来的挑战。前一阵子“龙虾”盛行但没几天事件又反转很多企业高调发禁令、切断对接外部 AI 平台、贴公告。我想起我的几个在企业里做 CISO 的朋友于是想着跟他们聊聊这波 AI 热潮对公司信息安全带来的挑战。第一个朋友放下筷子悠悠地说AI 不归我管。我以为是个例结果去问了第二个朋友、第三个朋友、第四个朋友得到的都是同一个答复。这让我不禁困惑起来:我是不是对 CISO 这个 title 有什么误解。I 到底代表什么?Information,还是 Innocent?或者是 Ignorance?恍惚过后,我突然想起几件我旁观过的事:有一次。 某 CISO 先于公司领导层嗅到了 AI 兴起带来的治理隐患,于是他打算提前布局防范风险,立项启动 AI 治理项目。申请提到领导层后被驳回了,理由是:公司尚未批准部署 AI 应用,该风险治理项目缺乏治理目标和充分理由,不予批准。还有一次。 某 CISO 注意到公司的年度重点项目是AI 赋能营销平台,他听说这个平台会利用大量销售数据做模型算法,他觉得这里涉及商业决策带来的公平性问题,但他又转念一想——这是典型的商业风险,他无权过问。又有一次。 某 CISO 无意间通过公司内部全员公告发现某明星业务部门启动了他们自己的 AI 赋能项目,他感到隐隐不安,很担心数据泄露的风险。但是,这个 AI 赋能项目是这个业务线自己牵头的,又是独立部署,与公司现有 IT 系统无集成。从公司角度,他只能负责 IT 部门出资并负责设计和实施的系统。甚至要不是他认真阅读了最近三天的通知邮件,他可能都不知道有这样一个项目的存在。当我把这三件事串联在一起后再去回想 CISO 的那句不归我管,我对他们的态度从一开始的费解迅速转变成了理解。然而,这件事并不是理解了就完事了。AI 新兴技术给传统公司信息安全边界带来的巨大冲击和影响,也并不是当没看见就真的可以当作没发生。总要有一个人站出来做预警,做风控。而最该做的,是先把下面这两件事搞明白:第一:搞清楚 AI 风险究竟是什么类型的风险有人会问,怎么判断 AI 安全应该给谁负责?这是个很好的问题。市面上大部分公司会从以下三条路线里选:路线 1:把 AI 安全纳入安全团队的责任。 但是安全团队不懂 AI 专有技术,不能深入理解风险是什么、在哪里、怎么整改——最终安全审核沦为走过场。路线 2:把 AI 安全融入 AI 技术团队。 但是 AI 团队一天到晚为业务需求研发模型算法,早已想破了脑袋,他们绝对不可能为安全浪费一秒钟——最终 AI 安全沦为一个不落地的概念。路线 3:公司内部成立虚拟的 AI 治理委员会,从好多个相关部门派代表进这个委员会商讨事项。但众所周知,“当一件事的负责人大于 1 时就等于没人负责”——最终 AI 安全还是没人管。这三种做法的共同问题是——它们都在回避一个核心问题:AI 风险到底属于什么类别的风险?我的判断是:AI 风险既不是技术风险,也不是合规风险——它是业务流程风险。这意味着,治理它的人必须能介入业务流程。这也意味着,治理它的不可能是一个人或者一个团队——因为流程是团队协作才能跑起来的。第二:基于职能归属,牵头建立责任共担模型嵌入到业务流程的 AI 安全治理到底应该怎么做?借用一个客户这边的最佳实践来举例:需求阶段: 产品团队提出想用 AI agent 做客服自动回复——这一步必须过隐私评估问卷(由隐私团队设计、产品团队填写)。问卷看似简单,但回答它的过程会让产品经理意识到,这个功能设计会把客户对话喂给 AI,这意味着数据出境、合同条款、用户告知都要重新走。设计阶段: 技术架构师提出技术方案——这一步必须过应用安全评估(由应用安全团队主导)。重点不是技术细节,而是 prompt 里包含什么数据?response 存哪里?异常输出怎么处理?开发阶段: 写代码的工程师必须用统一的 API 网关——网关层面做日志、脱敏、限流。不允许工程师直接调用外部 AI 的 API。测试阶段: 用合成数据测试,不能用真实客户数据。发布阶段: 每个 AI 功能上线前过最终合规 review——由 DPO、CISO、法务联合签字。看到这里你可能发现了——AI 责任共担模型,根本不是什么新发明,跟云平台的责任共担在本质上是一回事。唯一的区别在于:云的责任边界是云厂商画好了给你的,你只需要照着接。AI 的责任边界,得你自己画。而画这条边界的人,只能是 CISO。最后,让我们回到这个问题的起点:AI 的安全治理风险,CISO 到底该不该管?我的回答是:该管。 但不是要 CISO 一个人扛起公司所有的 AI 安全责任,他要做的是站在更广阔的视角上,把分散给产品、技术、法务、隐私、采购的责任,组织成一套能跑的流程。这套AI 责任共担模型,不需要立项、不需要预算审批,不需要等领导层点头。它需要的只是一件事——CISO 不再说这不归我管。正文结束────────────── 免责声明本文所有案例均源于作者在跨国项目交付与合规落地中的行业观察与机制复盘。为恪守职业操守与保密协议文中情境已进行彻底脱敏、抽象与多源融合不指向任何特定企业、团队或个人。写作初衷仅为探讨安全治理的共性机制与流程优化旨在揭示系统性设计漏洞非针对具体个体或业务线。文中观点仅代表作者个人专业思考不代表任何雇主、客户或项目合作方立场。欢迎聚焦议题理性交流。
