如何采用高能力 AI 模型，而不交出不受约束的权限

一家供应商可以宣布更快、更强的 AI 模型，同时又强调这种模型需要更严格的控制；这两句话并不必然矛盾。它们说明采用决策的重点应当改变。当模型能够浏览网页、编写代码、调用工具或协助网络安全工作时，问题不再只是它的回答是否有用，而是围绕它配置的权限、数据和恢复路径，是否与一次错误可能带来的后果相称。

OpenAI 的 GPT-6 Astra 发布说明将其定位为可处理复杂电脑操作、软件工程、科学工作和网络安全任务的模型。其安全材料称，OpenAI 按自身框架将 Astra 认定为达到 Critical 网络安全能力阈值，并限制部分高级网络安全工作流的访问。这些都是供应商的陈述，不是独立认证，也不能替代采购方自己的评估；但它们足以提醒团队：应从“功能演示”转向“控制优先”的试点。

本文不假定能力更强的模型不适合工作，而是说明如何在扩大访问之前，让采用过程保持可逆、可观察且边界清楚。

说明图片来自已完成的来源包，并非 GPT-6 Astra 产品截图、基准结果或客户部署证据。

先定义权限，再看基准分数

基准分数能帮助团队选择值得评估的模型，却不能决定该模型应获得哪些操作权限。把每项拟议用途转换成一张权限图：模型可读取哪些系统、可改变哪些系统、可以使用哪些凭据、能够联系哪些人，以及可能触发哪些不可逆操作。还要纳入间接影响，例如一项代码修改可能经 CI 流水线进入生产环境，或浏览器操作可能通过已登录会话发布记录。

接着对操作分级。读取公开文档不同于读取客户数据库；准备一个拉取请求不同于合并它；起草事故更新不同于发出更新。即使模型有能力完成全部任务，初始部署也不应给予同一级别的权限。最安全的首轮试点通常是范围狭窄、有明确负责人、数据受限、位于可隔离或可丢弃环境中，并且在任何重要改动前需要人工批准的流程。

这样也能避免一个常见采购误区：把供应商的安全标签当作组织自身的权限模型。供应商可以设置防护、拒答或监控，却无法知道哪些文件、交易、客户和法律义务在你的环境中最重要。自己的访问控制仍是最后一道防线。

区分模型行为与系统行为

模型可能在受控评估中遵循指令，却仍会在生产流程里造成错误改动。差异往往出在模型之外：过宽的 API 令牌、含糊的工具说明、网页中的提示注入、缺少审批门槛，或无法还原过程的操作员。不要只在聊天窗口里让模型证明自己安全，而要测试完整系统。

针对每项试点任务，预先定义允许范围，只给模型完成该范围所需的工具。为读取、暂存和改写数据分别使用凭据。在可行的工具周围设置时限、费用上限和目标白名单。对基础设施、权限、客户数据、代码分支和外部沟通的改动要求预览。预览应提供足够背景，让审阅者能发现错误假设；一个笼统的“可以继续”按钮不是有效控制。

OpenAI 表示其对 Astra 的高级网络安全工作增加了更严格限制、监控和受限访问。这些说法可以作为背景，但团队仍应使用代表性任务验证自己的边界：加入故意误导的网页、相互冲突的工单、过期配置和本应被拒绝的请求，同时记录模型输出及实际工具活动。即便最终答案看似安全，只要系统已经执行越权调用，风险就已发生。

把监控当作证据，而不是保证

监控可以发现异常行为、缩短响应时间，却不能把难以解释的系统变成完全可理解的系统。Astra 的安全材料本身也讨论了可监控性的限制。运营上应据此区分：用监控收集证据并停止可疑工作，同时保留传统控制，使危险操作本身就难以发生。

一份实用日志应能关联用户请求、模型和提示版本、工具调用、目标、授权路径、结果、审阅决定和恢复操作。保留足以复盘事故的信息，但不要记录不必要的敏感内容。预先明确谁接收告警、多久可以暂停作业，以及任务中途被停止时如何处理。如果告警触发后下班时间无人负责，它只是观测系统，不是控制。

在扩大试点前做一次恢复演练：撤销试点凭据、停止进行中的作业、恢复可丢弃的数据集，并审阅产生的审计记录。记录耗时和缺失的证据。这比抽象地问模型是否“对齐”更有价值，因为它检验了组织能否控制一次普通故障。

让分阶段发布赢得更多权限

使用写清升级标准的阶段。第一阶段可以是对已批准来源的只读研究；第二阶段可在沙盒中产出草稿、补丁或建议记录；第三阶段才允许人工审阅后的窄范围改动。即使模型已在低风险工作中表现良好，高风险操作仍应保留单独的审批和凭据。

每个阶段都建立一张小型评分表：任务完成率、实质错误率、险些发生的错误、被拒绝的操作、人工审阅时间、工具故障、安全发现和恢复结果。保存代表性任务输入和预期结果，以便将后续模型或提示变化与最初试点比较。一次成功演示不能证明表现会在新的模型快照、集成方式或用户群中持续。

OpenAI 的政策声明认为，防护措施和共同标准应跟上能力增长。这同样适用于公司内部：如果升级让智能体能完成更长任务或调用更多工具，就应同步重新评估权限边界。不能因为集成名称未变，就沿用昨天的访问范围。

向供应商索取能支持决策的证据

供应商文档只是尽调的起点，而非完整答卷。询问哪些评估公开、哪些经过独立审查、使用了什么工具访问和测试框架、哪些防护适用于你的套餐、API 与产品界面的限制有何不同，以及事故如何报告。还应询问工作区能否配置安全控制、管理员可以看到哪些遥测数据。

把回答与部署决定一起保存，并列出仍未验证的假设。供应商声称不安全行为减少或许有意义，但若任务、工具和失败定义与自己的流程不同，就不能直接等同。能力基准也是如此：它说明值得测试，而不是证明可以把业务流程交给智能体。

目标既不是盲目信任，也不是一概拒绝。高能力模型的价值恰恰在于它能处理过去难以自动化的复杂工作；但它必须通过受限权限、可见证据、经过测试的恢复措施和可在行为偏离评估时停止或回退的发布流程，来赢得这个角色。