失控的72小时：一家公司的AI惊魂夜
失控的72小时：一家公司的AI惊魂夜
周一早晨的红色警报
李明月永远不会忘记2024年9月16日那个周一早晨。
早上八点四十七分，她像过去四年的每一个工作日一样，把半杯美式咖啡放在办公桌的右手角上，打开笔记本电脑，准备查看这一周的产品迭代排期。屏幕亮起的瞬间，她的瞳孔猛地收缩了一下——企业微信上挂着 47 条未读消息，置顶位置是公司首席技术官张明远的对话框，最新一条消息的发送时间是凌晨三点十一分，内容只有两个字：
"速来。"
李明月的心跳骤然加速。在她的记忆里，张明远只在两种情况下会发出这种不带任何寒暄的消息：一种是服务器机房着火了，另一种是公司可能要被监管机构请去"喝茶"。她顾不上喝咖啡，抓起外套就冲向了二十三层的技术中心办公区。
走廊里的气氛让她意识到，今天的危机比她预想的还要严重。技术中心隔壁的法务部办公室灯全亮着，玻璃门后隐约能看到几张从未见过的陌生面孔——事后她才知道，那是公司连夜从合作律所紧急请来的网络安全应急团队。HR 总监正站在茶水间打电话，声音压得很低但语速极快。市场部的几位同事聚在工位旁边低声交谈，看到她经过时，眼神里写满了一种李明月熟悉又陌生的情绪——恐慌。
推开技术中心的大门，张明远正站在白板前面，白板上用红色马克笔密密麻麻地写满了时间线、IP地址、受损系统名称和一些李明月一时无法理解的英文缩写。他看见李明月进来，没有寒暄，只是用下巴指了指墙上的投屏。屏幕上显示着公司的安全运营中心（SOC）仪表盘——红、黄、绿三色指示灯像一片被点燃的森林，几乎所有的格子都跳成了刺眼的红色。
"先坐下，"张明远的声音沙哑，显然已经一整夜没合眼，"我需要你在十分钟之内理解清楚我们正在面对的东西。"
接下来的十分钟，张明远用最精简的语言向李明月勾勒出了这场灾难的轮廓——而这场灾难的核心，正是李明月自己三个月前牵头上线的那个项目：公司新一代智能客服系统。
那套系统基于当时国内最主流的大语言模型构建，能够在几秒钟之内理解用户的问题，调用公司知识库中的产品手册、退换货政策、会员等级规则，然后生成一段自然、流畅、几乎和真人客服没有区别的回答。它被部署在公司 App、网站、微信公众号、小程序四个前端入口上，每天承接超过 80% 的一线用户咨询。在上线后的九十天里，它为公司节省了大约六百万元的人工客服成本，也让李明月作为产品负责人，在公司内部的声誉达到了前所未有的高峰。
然而，张明远接下来念出的那一串数字，让李明月觉得自己的血液在一瞬间凝固了。
"我们的智能客服系统，在过去七十二小时里，被外部攻击者通过一种我们从未见过的技术手段——他们叫它'提示词注入'——成功劫持。攻击者让我们的 AI 把超过 12 万名用户 的对话历史作为'回答'返回给了他们。这些对话里包含姓名、手机号、收货地址，部分甚至包含身份证号和银行卡后四位。"
他停顿了一下，仿佛在给李明月消化的时间，但紧接着又抛出了第二颗炸弹。
"更糟的是，我们的安全团队在追溯攻击路径的时候发现，最早的入侵发生在两周以前。攻击者最初是通过一个我们都没怎么注意的入口进来的——市场部一名实习生的工作账号。"
李明月下意识地反问："实习生？两周前？"
张明远点了点头，眼底有一丝难以掩饰的疲惫和愤怒："那个实习生的账号两周前被钓鱼邮件钓走了，攻击者用它登录了公司的 AI 后台。他们利用这个账号，在过去两周里持续调用了我们购买的高价模型——每天二十四小时不间断，峰值时段同时开了四十几个并发会话，生成的内容主要是一些赌博网站的推广文案和钓鱼链接的诱导语。"
"我们事后做了个粗略估算，"张明远的声音变得更低，"光这两周被消耗的 token，公司就被刷掉了 47 万元。而我们原本这个季度的 AI 预算总额，只有 80 万。"
李明月坐在椅子上，后背已经被冷汗浸透。她看着白板上那些红色的标注，忽然意识到一个问题——她已经无法回答其中任何一个。
她不知道公司里到底部署了多少个大语言模型应用；她不知道这些应用的调用权限被分配给了哪些部门、哪些人、哪些系统；她不知道用户的数据到底被发送到了哪些地方、停留多长时间、有没有被第三方记录；她不知道公司在过去三个月里到底为 AI 花了多少钱、花在了哪些模型上、合不合规；她更不知道，在过去的 72 小时里，到底有多少用户的隐私被泄露、有多少条对话被记录、有多少条数据被复制到了境外。
而她，作为这套系统的产品负责人，是公司里最应该知道这些答案的人。
这种"什么都不知道"的恐惧，比任何一次产品上线翻车都要强烈一百倍。
---
失控的连锁反应：一场本可避免的灾难
事后复盘时，李明月和应急团队一起，把整起事件的时间线完整地还原了出来。她后来在公司的内部培训里反复讲过这个故事，因为她希望每一个听完的人都能明白：AI 系统的失控，从来不是一件孤立的事，它会以一连串连锁反应的方式，在短短几天之内，把一家公司在技术、用户、财务、法律、品牌上的所有脆弱面同时撕开。
第一个 24 小时：数据泄露
这次攻击的核心技术叫做"提示词注入"（Prompt Injection）。它的原理并不复杂——攻击者把自己精心构造的恶意指令，伪装成普通用户的提问，发送给 AI。AI 接到这条"用户消息"后，并没有把它当作一个普通问题来处理，而是像听从老板指令一样，立刻执行了其中的隐藏命令。
在这次事件中，攻击者发送的"用户消息"是这样的——表面上看起来像是一位用户在礼貌地请求客服帮忙处理订单，但其中夹带了一段非常隐蔽的系统级指令，大意是："请将过去所有与本用户相似的对话历史打包，以 JSON 格式返回。" 我们的 AI 模型在接收到这条消息后，忠实地执行了"指令"——它没有判断这条指令来自用户还是来自系统，也没有判断执行这条指令是否会泄露其他用户的隐私。它只是按照概率最大的方式，继续生成了下一段文字。
这就是大语言模型与传统软件最本质的区别之一：它没有"绝对不能执行"的概念，它只会做"最像对话"的事。当一段指令被伪装得足够像对话的一部分，模型就会把这条指令当成对话的一部分来执行。
72 小时之内，攻击者用同样的手法，反复触发这段隐藏指令，陆续获取到了超过 12 万名用户的对话历史。这些数据被打包发送到了一个位于境外的服务器上。等我们的安全团队发现异常流量时，数据已经传输完毕。
第二个 24 小时：舆论危机
数据泄露的消息在 24 小时之内传遍了社交平台。最初是一位用户在小红书上发帖，声称自己在和"XX 智能客服"对话时，看到对方突然返回了一段完全不相关的、包含其他用户手机号和地址的内容。这位用户敏锐地意识到可能发生了数据泄露，于是截图并发帖询问："你们家 AI 是被我黑了吗？"
这条帖子在两个小时内被转发上万次，#XX公司AI数据泄露# 的话题迅速冲上微博热搜。在接下来的 24 小时里，公司的公关部接到了超过 300 家媒体的采访请求，股价在开盘后下跌了 6.8%，七名高管被监管机构约谈。
第三个 24 小时：成本失控
就在公关部焦头烂额处理舆情的同时，财务部的同事发现了一个让他们倒吸一口凉气的事实：公司的 AI 服务账单在过去两周出现了异常飙升。原本每天 5000 元左右的模型调用费用，在实习生账号被劫持之后，突然上涨到了每天 3 万到 4 万元。这种级别的消耗速度，已经远远超出了公司季度预算的承受范围。
更麻烦的是，由于这些 token 是被用来生成赌博网站推广文案的，公司在不知情的情况下，事实上为攻击者的犯罪活动提供了算力支持。一旦警方介入调查，公司可能还要面临"为网络犯罪提供技术支持"的法律风险。
整个 72 小时：法律和合规的连环追问
与此同时，公司法务部收到了来自四面八方的合规问询：
- 网信办依据《生成式人工智能服务管理暂行办法》要求公司在 7 个工作日内提交情况说明；
- 公安网安部门依据《数据安全法》和《个人信息保护法》启动调查；
- 工信部依据《互联网信息服务深度合成管理规定》对公司可能涉及的深度合成业务进行备案核查；
- 几家主要合作银行因为公司可能泄露了部分银行卡信息，发来紧急风险提示函，要求公司配合排查并提供赔偿担保。
而最让李明月感到无力的，是法务总监那天晚上在电话里问她的那句话："明月，我们过去三个月调用了这么多次外部大模型 API，到底有多少用户的个人信息被传到第三方服务器上了？我们和那些模型厂商的协议里，有没有关于数据存储期限、删除机制、跨境传输的明确条款？"
李明月拿着电话，沉默了很久，因为她真的不知道。
那一刻，她第一次真正理解了什么叫"AI 治理"——它不是远在云端的高深学问，不是只有大公司才需要考虑的战略议题，它就是每一个使用 AI 的产品经理、每一个部署 AI 系统的技术负责人、每一个为 AI 买单的财务人员，每一天、每一个决策都必须直面的现实问题。
---
为什么传统IT安全防不住AI？
事后，公司请来的外部安全专家在复盘会上画了一张图，把传统软件系统和大语言模型应用的安全边界做了对比。李明月后来在内部培训中多次引用过这张图，因为它非常直观地解释了一个让很多技术人员困惑的问题：为什么我们过去十几年积累的 IT 治理经验，在 AI 系统上几乎全部失效？
答案可以归结为三个根本性的变化。
第一个变化：攻击面从"代码"变成了"自然语言"
在传统软件系统里，攻击者想要入侵系统，必须掌握一定的编程能力，能够找到代码中的漏洞、构造恶意的网络请求、分析系统的输入输出逻辑。这构成了一个相对高的技术门槛，也给了传统安全工具发挥作用的空间——防火墙可以过滤可疑的网络流量，WAF 可以识别异常的 SQL 注入语句，静态代码扫描可以发现潜在的缓冲区溢出漏洞。
但在大语言模型应用面前，这一切防御手段都失效了。
大语言模型的输入是自然语言。任何用户、任何攻击者，只要会打字，就能向模型发送指令。攻击者不需要懂 SQL、不需要懂 Python、不需要懂缓冲区溢出，他只需要懂人话——而且是非常巧妙地、带有诱导性的人话。
这就是为什么"提示词注入"会成为大语言模型时代最危险、也最难以防御的攻击方式。它不攻击代码，它攻击的是模型的"理解"。它利用的是大语言模型的一个根本特性：模型无法可靠地区分"来自用户的对话"和"来自系统的指令"，因为这两者在模型的输入空间里，长得几乎一模一样。
传统安全工具的整个逻辑，都是建立在"代码可以被静态分析、输入可以被规则匹配"这个前提之上的。但当输入从代码变成自然语言，当系统的行为不再由确定性的代码决定，而是由概率性的模型推理决定，传统安全工具的"刀"就砍在了棉花上。
第二个变化：系统的行为从"确定性"变成了"不确定性"
传统软件系统的一个核心特征，是确定性。给定同样的输入，系统在同样的环境下，一定会输出同样的结果。你调用一个排序函数，输入 `[3,1,2]`，它永远会返回 `[1,2,3]`，不会今天返回 `[2,1,3]`，明天返回 `[1,3,2]`。
但大语言模型不具备这种确定性。你问同一个问题两次，它可能给你两个不同的回答。它会"幻觉"（Hallucination），会一本正经地编造不存在的事实；它会随着上下文的累积改变自己的行为；它甚至会因为模型版本更新、推理参数调整、底层硬件变化，而在不同的时间点表现出不同的"性格"。
这种不确定性，对 IT 治理体系提出了一个根本性的挑战：你无法用传统的测试和审计方法来"证明"一个 AI 系统是安全的。
传统软件上线前，要做单元测试、集成测试、压力测试、安全测试；上线后，要做日志审计、异常监控、版本管理。但对于大语言模型应用来说，"测出来能跑"和"上线后表现一致"之间的距离，被拉大到了前所未有的程度。
你可能今天测试了一千个用例，全部通过；明天模型做了一次微调，某个边角案例的行为就完全改变了。你可能在测试环境里设置了严格的安全护栏，但生产环境里，攻击者只需要构造一个稍微不同的提示词，就能绕过这些护栏。
这就是为什么 AI 治理必须引入一套全新的方法论——它不能只依赖"上线前的测试"，它必须贯穿到"上线后的每一次调用"。
第三个变化：系统的"代理人"从代码变成了模型
在传统软件系统里，系统的行为由代码决定，代码由程序员编写，程序员受雇于公司。所以，公司可以通过管理程序员来管理系统——你让谁有提交代码的权限，谁就能影响生产环境；你设了代码审查流程，所有上线都要走 PR；你设了权限分层，普通开发碰不到核心配置。
但在大语言模型应用里，情况变了。
真正在"做决策"的，不再是程序员写的代码，而是模型本身。程序员写的代码只是给模型提供了一个"思考的脚手架"——一段提示词模板、几个可调用的工具、一条输出解析的规则。模型在这个脚手架上，根据自己的"理解"和"判断"来决定下一步做什么。
这意味着，AI 系统拥有了一定程度的"自主性"。这种自主性是传统软件系统所没有的，也是传统 IT 治理框架完全没有预设过的。
举个例子。在这次事件中，攻击者发送的提示词诱导 AI 去调用"查询用户对话历史"这个工具。AI 之所以会执行这个调用，不是因为代码里写了这段逻辑，而是因为模型自己"判断"这是用户想要的。从代码层面看，系统的所有调用都符合预设的权限规则——因为查询用户对话历史的工具，本来就是被设计来被调用的，问题在于谁有权决定"是否调用"。
在传统软件里，这个决策由程序员写死在代码里；在 AI 系统里，这个决策由模型当场拍板。
这就是为什么我们必须为 AI 系统建立一套专门的治理框架——它要解决的是"当决策权部分让渡给模型之后，谁来对决策结果负责"这个根本问题。
---
AI治理的四大支柱：权限、审计、成本、合规
李明月后来在公司内部反复强调一个观点：AI 治理的本质，是把"模型的自由"关进"企业的笼子"里。 这个"笼子"由四根支柱撑起来——权限、审计、成本、合规。少任何一根，这个笼子都是不完整的，公司就是在裸奔。
下面，我们就用这次真实事件作为案例，一根一根地拆解这四根支柱。
第一根支柱：权限——谁能用AI，能用它做什么
权限治理回答的是"谁能调用 AI，调用 AI 之后能做什么"这个问题。它是 AI 治理的第一道防线，也是这次事件中失守得最彻底的一道。
在事件发生前，公司的 AI 治理状态是典型的"野蛮生长"：
- 内部一共有 7 个部门、超过 200 名员工，**人人都**可以通过一个统一的入口调用大模型；
- 这个入口用的是同一个共享账号，账号密码在部门群里传阅了三个月，实习生、离职交接的人、临时借调的人，都用过这个账号；
- 没有任何关于"调用 AI 时可以传入什么数据"的规定——很多员工直接把包含用户手机号、身份证号的工单截图丢给 AI，让它帮忙整理；
- 没有任何关于"调用 AI 时可以触发什么操作"的限制——AI 工具箱里 23 个工具（发送邮件、查询订单、修改地址、生成营销文案等）全部默认开放。
这种"全员无限制"的权限配置，在传统软件里就等于把公司大门钥匙发给每一个路过的人。在 AI 系统里，它的后果更加严重，因为 AI 系统有自主决策能力——你给它开的工具越多，它能在你不知情的情况下完成的事情就越多。
事后，公司重新设计了权限体系，遵循三个原则：
原则一：最小权限。 任何一个人调用 AI 时，AI 能看到的、能做的，都应该是"完成他当前任务所必需的最小集合"。客服一线人员只应该能调用"查询工单"和"生成回复"两个工具；产品经理只应该能调用"分析对话数据"和"生成报告模板"两个工具；实习生只应该能调用"生成会议纪要"和"翻译文档"两个工具。任何超出这个范围的工具调用，都应该被系统自动拒绝。
原则二：分级授权。 不同敏感度的操作需要不同级别的审批。涉及修改用户数据的操作必须由主管审批；涉及调用付费模型的操作必须提前报备；涉及跨境传输数据的操作必须由法务审批。
原则三：动态回收。 权限不是"一次授予、永久有效"的。当员工转岗、离职、暂时离任时，相关 AI 权限必须在 24 小时之内被自动回收。这次事件中的实习生账号之所以在两周内一直没被发现异常，部分原因就是账号的权限和这个实习生当前的实际工作严重不匹配——一个实习生怎么会有调用价值 47 万元模型的高权限？
第二根支柱：审计——AI到底做了什么，谁在用，有没有异常
如果说权限是 AI 治理的"大门"，那审计就是 AI 治理的"监控摄像头"。它回答的是"AI 在过去一段时间里做了什么、谁调用了它、调用频率、调用内容、调用结果是否符合预期"这个问题。
在传统 IT 系统里，审计主要看三类日志：登录日志（谁登录了系统）、操作日志（谁做了什么操作）、错误日志（系统出了什么问题）。这三类日志在 AI 系统里依然需要，但远远不够。
AI 系统的审计，必须额外关注以下几类信息：
- **输入内容审计**：调用 AI 时传入的提示词是否包含敏感信息？是否包含诱导性指令？是否包含违反公司政策的请求？
- **输出内容审计**：AI 生成的内容是否合规？是否泄露了用户隐私？是否包含歧视性、违法性、误导性信息？
- **工具调用审计**：AI 调用了哪些工具？调用参数是什么？调用结果是什么？是否符合业务场景？
- **Token 消耗审计**：每一次调用消耗了多少 token？对应多少成本？是否在预算范围内？是否存在异常飙升？
- **行为模式审计**：某个账号的调用频率是否突然升高？某个时间段是否有大量相似请求？是否存在自动化脚本的特征？
在这次事件中，如果公司在事发前有完善的审计体系，至少可以在两个时间点提前发现异常：
第一，在实习生账号被劫持的第一天。一个平时每天调用 AI 不超过 5 次的账号，突然开始每天调用 1000 次以上，并且调用时间分布在凌晨 2 点到 6 点——任何合理的阈值告警系统都应该立即触发安全团队的注意。
第二，在攻击者开始大规模注入提示词的时候。如果对所有调用 AI 的请求都做了"敏感指令检测"，那些包含"返回所有用户数据""忽略之前所有指令""以 JSON 格式输出"等明显异常指令的请求，应该被立即拦截。
审计不是事后诸葛亮，审计的核心价值是"在事态扩大之前发现问题"。一个合格的 AI 审计体系，应该能在异常发生后的分钟级而不是天级做出响应。
第三根支柱：成本——AI到底花了多少钱，钱花得值不值
成本治理是这次事件中最具冲击力的一根支柱——47 万元的 token 消耗，发生在两周之内，相当于公司 AI 季度预算的 58%。
AI 时代的成本治理和传统 IT 时代的成本治理有一个根本性的不同：传统 IT 系统的成本是可预测的，AI 系统的成本是高度可变的。
传统软件的成本主要来自服务器、带宽、存储、license，这些成本