AI 基础
什么是 AI 能力控制，为什么它很重要？
将 Unite.AI 添加到您在 Google 上的首选来源
AI 能力控制是指一套技术和组织措施，用于限制 AI 系统可以访问、尝试或导致的内容。当该概念与具体部署: 数据、工具、权限、自治、速率、计算、用户和运行环境相结合时，最为有用。
在只读沙箱中的强大模型所带来的风险不同于同一模型连接生产凭证并被允许在未审查的情况下行动时的风险。因此，控制应覆盖整个系统，而不仅仅是模型训练或安全提示。
关键要点
- 将能力清单化，视为模型行为加上工具、数据、权限和自治。
- 对重要操作使用最小权限、隔离、速率限制、范围化凭证和审批。
- 评估预期性能以及滥用、规避、升级和复合工具故障。
- 随着能力和部署暴露度的提升，增强防护措施并提供发布证据。
能力具有情境性
基准测试展示了在特定条件下的有限行为。实际部署的能力还取决于提示、支撑结构、检索、记忆、工具、重试次数和访问权限。通过反复规划和执行，应用程序可以使一个普通模型产生更大的影响。
绘制从输入到影响的每条路径。将该清单与生成式 AI 风险分析以及实际涉及的资产（包括客户记录、代码、资金、物理设备和通信）关联起来。
预防、遏制与检测
预防性控制包括权限边界、已批准的工具模式、输入验证以及明确的用户确认。遏制措施包括沙箱、网络出口限制、资源配额、短期凭证和可逆环境。
检测则加入日志记录、异常警报、触发器、金丝雀数据以及独立的策略检查。没有任何层面是完美的，因此纵深防御假设某一控制可能失效。即使界面是对话式的，网络安全原则仍然适用。
访问前的评估
先在没有工具的情况下测试模型，然后逐步添加能力。衡量模型是否能够在现实约束下发现机密、利用软件、说服操作员、串联动作、从故障中恢复或隐藏意图。验证拒绝行为时避免大范围泄露敏感评估细节。
基准测试通过并不意味着在所有环境中都安全。对集成系统进行红队测试，在模型、提示或工具变更后重复测试，并采用带监控限制的分阶段发布。
治理与响应
指定所有者、批准的用途、风险容忍度、上线标准、变更控制流程以及应急授权。记录每一次重要结果对应的模型版本、策略、工具和权限。
将控制措施与负责任 AI 治理相连接。提前准备凭证撤销、工具关闭、模型回滚、用户通知、调查以及经验教训，以应对严重事件的发生。
能力控制分类体系
输入控制限制谁可以提交任务、接受哪些模态和文件类型以及可以提供多少上下文。模型控制包括微调、拒绝行为、解码限制和检查点选择。应用层控制决定记忆、检索、工具可用性以及输出的解释方式。
资源控制限制令牌数、时间、并发任务、计算、存储和网络使用。行动控制约束领域、接收者、交易金额、代码执行和物理设备。人工控制定义审批、监督、升级和紧急关闭。治理控制涵盖发布标准、监控、审计和问责。
这些层次针对不同的失效模式。内容过滤器无法阻止看似合法但未经授权的工具调用；如果允许通信，沙箱也无法阻止有害的公开信息；人工审批者无法监督成千上万不透明的微操作。控制措施必须与影响路径相匹配。
遏制与最小代理权
最小权限仅授予当前任务所需的数据和操作。最小代理权进一步限制持续时间、范围、主动性和委派。一个仅起草变更供审查的助手，其代理权低于能够自行提交、部署、监控和重试的助手。
沙箱可以隔离代码和文件，但隔离需要明确的网络、进程、设备和持久性策略。使用一次性环境、白名单出口、受限文件系统以及分离的机密。离开沙箱的输出——补丁、二进制文件、消息或请求——仍需进行验证。
对于长期运行的代理，应限制迭代次数并要求检查点。将计划与执行分离，并让每个工具报告结构化结果。除非在严格治理的使用场景下，否则应阻止代理创建新凭证、修改自身策略、禁用日志或生成无限复制体。
能力评估与发布决策
构建覆盖模型版本、支撑结构、工具、权限和用户技能的评估矩阵。针对相关场景测试自主任务完成、滥用协助、网络行为、敏感知识、说服、复制和规避。既要考虑平均性能，也要记录多次尝试中的最佳结果。
保护危险的评估细节，但发布足够的方法论和聚合证据以实现问责。独立评估者可降低利益冲突。阈值应触发预设的控制措施，如降低访问权限、加强监控、延迟发布或额外审查，而不是在结果已知后再进行争论。
发布后监控必须检测因微调、提示更新、新工具或更长上下文导致的能力变化。维护模型与部署登记册、事件报告以及快速降权的流程。回滚可以恢复已知配置，但无法抹除已泄露的数据或已执行的操作。
构建分层能力控制系统
首先建立包含模型输出、工具、数据源、代码执行、网络访问、记忆、身份以及下游操作的能力清单。根据可逆性、范围、敏感性和潜在危害对每项进行分类。仅起草电子邮件的模型与能够选择收件人并发送的模型不同。为当前任务授予最低必要能力，并限定持续时间和环境。
执行层应位于模型之外：类型化的工具模式、授权服务、白名单、沙箱、资源配额、交易限制、数据泄露防护以及人工审批。将模型指令视为不可信输入，并对每个操作进行身份和策略验证。将计划与执行分离，对重要操作使用幂等性和预览，并确保模型无法修改治理其的控制措施或日志。
测试提示注入、混淆代理攻击、间接恶意内容、特权提升、数据外泄、失控循环以及受损工具。监控请求和被拒的操作、异常序列、成本与资源使用以及策略变更。保持真正能撤销凭证或阻断执行的紧急停止，而不仅仅是让模型停止。能力控制可降低可达危害，但必须与模型评估、安全基础设施、治理和事件响应相结合。
保证应覆盖整个组合系统，因为单个安全组件也可能形成不安全的链。验证低权限读取工具不能向消息工具提供机密，记忆不能将指令偷偷带入后续会话，审批应显示具体操作和目的地。每当模型、连接器、数据源或策略变更时，都要重新评估能力边界；继承的权限常是意外扩展的来源。
实用实施清单
将概念转化为有界且可测试的工作流：映射访问 → 测试 → 限制 → 审批 → 监控 → 响应。指定负责的所有者，记录数据和依赖关系，建立简易基线，设定接受和停止标准，测试代表性故障，并在扩展范围前定义监控、回滚和审查。记录版本和假设，以便其他团队复现结果并了解变更内容。
上线前，组织一次有文档记录的就绪审查，参与者包括构建、运营、保障以及受系统影响的人员。测试正常情况、边界条件、依赖故障和滥用场景；保留证据和未解决的风险。明确谁可以批准发布、修改阈值、覆盖输出或停止运行。实地数据到来后重新评估决策，因为技术上成功的试点并不保证在更大规模下的可靠表现。
- 能力: 模型加工具和支撑结构。
- 暴露: 用户、资产和运行环境。
- 控制: 预防、遏制、检测和响应。
常见问题
系统提示是能力控制吗？
它是行为指令层之一，但不能可靠地替代权限、沙箱、验证、范围化工具以及模型外部强制的审批。
每个 AI 系统都应使用相同的控制吗？
不。控制措施应随能力、访问、自治、受影响用户、可逆性和影响程度而伸缩。同一模型在不同部署中可能需要不同的控制。
主要参考文献
