80%已用AI、仅10%在治理：智能体该有一套响应分级

一个能读邮件、查CRM、调用外部工具并连续执行多步任务的智能体，出现偏差时，已经不是“回答错了一句”那么简单。它可能在几秒内把不该访问的信息带到不该出现的系统里。AWS在9月2日发布的智能体安全框架中给出一组值得企业警醒的观察：约80%的组织已经采用AI，但只有10%进行了治理。采用速度和治理成熟度之间，正在形成一段危险的空档。

我认为，企业接下来不该只问“这条规则写好了没有”，而要补上另一个问题：一旦智能体的行为越过预期，系统会在多快时间内、由谁、按什么级别把它停住或升级？规则是静态边界，响应能力才是运行中的安全感。

智能体为什么不能只做上线前审查

传统软件更接近确定性系统：同样输入，通常产生同样输出；权限、依赖和异常也相对稳定。智能体却会在不同上下文中选择不同工具、组合不同动作，还会接触用户输入、外部网页和持续变化的数据。一次测试通过，不等于下一次运行仍然安全。AWS因此建议把检测和响应从一次性检查，转成持续、可观测的运行机制。

对智能体而言，风险往往不在某一次调用本身，而在“读取敏感数据、接触不可信内容、又能向外行动”这三种能力被同时拼到了一起。

这也解释了为什么只做提示词过滤不够。真正需要被持续观察的是行为链：它代表谁在行动、用了什么临时凭证、访问了哪些资料、调用了什么工具、准备把结果交给谁。每一步单看都可能“有权限”，连起来却可能偏离原本委托。

把“发现异常”变成三档响应，而非一个总开关

AWS提出，机器速度的风险需要自动化且分层的响应：有些行为应立即控制，有些则需要人来判断。企业不必等到有复杂的安全中台才开始，可以先把每条高价值工作流的异常处理写成三档：

关键不在于把所有异常都交给人工。那样只会把智能体重新变成昂贵的表单。关键在于提前划清：哪些后果可自动止损，哪些需要业务判断，哪些可以让系统从中学习。响应越具体，团队越敢把工作流交给智能体，而不是只让它停留在演示和问答。

STARBOX视角：把响应剧本放进每一次委托

在STARBOX的“组织—BOX—智能体”结构里，我更愿意把这套能力理解为一张“响应剧本”。组织层不只定义谁可以用AI，还要定义风险等级、自动止损线、升级人和业务恢复责任；BOX层沉淀场景目标、数据范围、允许工具、异常样本、处置记录和复盘结论；智能体层则只在当前任务的边界内行动，并把每一次暂停、拦截和人工改写带回系统。

这和DDABC闭环也天然吻合：Define时先写清响应档位，Deploy时记录实际行为，Analyze时找出异常模式，Benchmark比较拦截率、人工接管量和返工成本，Calibrate再把有效处置更新进下一版工作流。安全因此不是发布前盖一个章，而是让每次运行都留下可改善的经营证据。

真正成熟的企业AI，不会承诺“永不出错”。它会让团队在错误刚露出苗头时，知道系统会怎么停、谁来接、怎样恢复，并把这次经验变成下一次更稳的边界。敢于让智能体走进核心工作，靠的不是更大胆，而是有一套随时能启动的响应剧本。

来源：AWS Security Blog《Agentic security: Detection and response at machine speed》（2026-09-02）；AWS《Scaling agentic AI: Enterprise patterns without vendor lock-in》（2026-08-20）。文中80%与10%为AWS引用的组织采用与治理观察，未外推为所有企业的普遍比例。