Google 一边教企业管 AI 风险，一边暴露了平台自己的新风险

一个很讽刺的场景：Google Cloud 高管正在提醒企业，AI 安全不能事后补票；与此同时，Google Cloud 自己的开发者生态里，有人因为 API key 触发 Gemini 调用，被打出五位数账单。

这事最值得看的不是“AI 安全很重要”。这句话已经说到没味了。真正值得看的，是平台商一边要求客户治理 AI 风险，一边也在把不透明的权限扩张、默认配置和计费机制，变成新的风险源。

AI 安全现在难在哪里

Google Cloud COO Francis de Souza 的判断其实很实在：企业没有单独的 AI 策略。AI 策略必须和数据策略、安全策略绑在一起。安全不能后补，也不能交给员工各自发挥。

他点了几个企业现在最容易低估的坑：

这套判断不只是 Google Cloud 广告。de Souza 明确说到 multicloud：哪怕企业自称只选一家云，业务软件、合作伙伴、供应链也会把你拉进多云现实。

他给出的方向，是用 AI-native、agentic defense 去对抗机器速度的攻击。也就是让防御系统本身更自动化，让人从“逐条处理告警”变成“监督机器防御”。

这个方向合理，但还谈不上成熟答案。它更像过渡期的应急路线：用更快的机器压住更快的机器。问题是，agent 本身也会扩大权限、移动数据、触发工具调用。防御者不是坐在高地上，它也在泥水里。

矛盾出在平台边界

麻烦的是，平台自己的边界也没那么清楚。

The Register 近几周报道了多起 Google Cloud 开发者遭遇高额账单的案例。报道称，一些原本用于 Google Maps 的 API key，因为权限范围变化，后来能够调用 Gemini 模型；开发者称这些调用未经授权，或者他们并未主动启用相关服务。

两个数字很刺眼：Prentus CEO Rod Danan 称，大约 30 分钟产生了 10138 美元账单；悉尼开发者 Isuru Fonseka 称，醒来后发现约 17000 澳元费用，而他以为自己设置了 250 美元支出上限。

这里要谨慎说：现有材料显示的是开发者指控和媒体报道，不等于 Google 已承认故意扩大权限或恶意收费。也不能推成所有 Google Cloud 用户都在受害。

但它暴露的问题已经足够严重。

API key 这种东西，本来就是云时代最危险的“小钥匙”。过去它可能只开一扇门，比如地图服务。平台一旦调整权限范围，它可能突然能开另一扇门，比如大模型调用。门变多了，账单也会跟着变厚。

“天下熙熙，皆为利来。”这句话放在云平台上很合适。云厂商当然希望服务被更顺滑地调用，模型被更低摩擦地接入，开发者少一点配置阻力。但少一步确认，往往就是多一层风险。便利和控制，从来不是免费兼得。

我不太买账的是平台商常说的那种轻描淡写：客户要做好治理。是，客户当然要做。但如果平台默认权限、账单上限、服务启用、审计日志都不够可理解，治理就会变成一场猜谜。

企业安全负责人最怕的不是功能多，而是不知道功能什么时候多出来。

分水岭不是模型强不强

这件事对企业技术负责人和开发者的提醒很直接。

别只问模型调用效果。要问这些更无聊、也更要命的问题：

• API key 默认能访问哪些服务？以后会不会被平台扩权？
• 新模型服务是否需要显式启用，而不是默认可用？
• 预算上限到底是硬刹车，还是事后提醒？
• 日志能不能追到具体 key、具体服务、具体时间段？
• agent 能访问哪些旧系统、旧文档、旧权限？

AI 安全的分水岭，不在模型参数多大，也不在安全宣传册写得多漂亮。它在默认权限、审计能力、成本控制和平台责任能不能制度化。

平台商有资格提醒客户别乱用 AI。但平台商也必须接受同一套审视：你的默认配置是否克制，你的计费机制是否可控，你的权限变化是否提前、清楚、可回滚。

AI 时代的安全不是一堵墙，而是一套账。谁能访问什么，谁触发了什么，谁为后果买单。账算不清，安全就只是口号。

开头那个反常点，其实就是今天云和 AI 的共同现实：大家都在实时摸索，连 Google 也一样。区别只在于，大平台的一次默认变化，可能就是开发者的一张五位数账单。