一句话看懂：大多数企业的”影子 AI”治理停在盘点阶段，TechRadar 指出，企业管理 AI 的真正难点不是发现有多少 AI 在运行，而是能否在 AI 动手的那一刻拦截、降权、审批或终止它。
事件核心：发生了什么
TechRadar 刊文讨论企业 AI 治理从”发现”走向”强制管控”的路径。文中引用微软 2026 年 2 月 Cyber Pulse 研究的数据：企业平均运行约 37 个 AI 智能体（agent），但超过一半没有安全监督或日志记录。文章认为，绝大多数企业只完成了第一步——用表格盘点出内部 AI 数量，随后项目就停滞了。真正的”强制管控”是指在 AI 动作执行过程中改变其结果，具体包括四种干预方式：阻止工具运行、缩小其可触达范围、对特定操作加审批门禁、以及在执行中途终止进程。
为什么重要
网络层屏蔽 AI 域名的做法正在失效：本地模型不产生出站请求，嵌入在授权软件里的 copilot 流量看起来和原厂商一样，IDE、命令行智能体和 localhost 上的 MCP 服务器根本不经过企业可控的网络边界。更棘手的是权限问题——智能体通常借用人类员工的身份和权限执行操作，现有身份系统只会判断”这个账号是否有权做这件事”，答案往往是”有”，却无法回答”这个人是否真的授权了软件代他做这件事”。这也是 AIUC-1 等新兴标准把”未授权智能体行为””访问权限执行””不安全工具调用”列为独立控制项的原因。文章主张，管控必须落在动作真正执行的那一点，因为指令层的输入过滤和提示词护栏是概率性的，而执行点的拦截是确定性的。
对用户/开发者/创作者的影响
对企业开发者而言，这意味着安全投入的重心会从网络边界转向终端与运行时——几乎所有 AI 交互最终都会变成设备上的一个进程，本地模型、嵌入式 copilot 和浏览器标签页在运行时都只是”代码在执行”。对采购方，评估 AI 安全产品时应关注它能否在动作执行点做确定性拦截，而不是只看域名黑名单和事后日志。文章给出的落地顺序值得参考：先选一个品类而非全部清单、以监控模式运行两周、为每个智能体指定负责人，再开启最小范围的阻断并测量投诉率。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 AIUC-1 等标准能否被主流身份与终端安全厂商实际采纳；二是端点运行时管控类产品会不会成为企业 AI 采购的标配；三是”先监控、再阻断”的推进节奏在真实企业环境中是否可行，尤其是无主智能体的清理进度。
来源：TechRadar
