OpenAI Astra for Law 能处理客户机密吗？2026 试点验收

⚠️ 症状： 你已经看到了 Astra for Law 的法律搜索、Trusted Access、插件和 Codex 入口，但还无法证明客户文件不会进入错误的数据路径。
✅ 最快解法： 可以做受控试点，但不能仅凭法律专用模型或 Zero Data Retention（ZDR）直接放行客户机密；先确认机构资格、合同范围和真实入口，再从可追溯的低风险事项开始，插件、Codex 与未来 API 分开验收。

谁该看这篇：
律所 IT 与安全负责人，需要判断哪些案件资料可以进入 Astra for Law，并保存足够的审计证据。
法律科技开发团队、合伙人和创新负责人，则需要在插件、Codex 或未来 API 上线前，决定是小范围试点、继续等待，还是暂缓接入。

最后更新于 2026 年 9 月 18 日，数据核实自 OpenAI Astra for Law 帮助页、数据控制文档、插件文档与企业隐私说明。

先把“能看到入口”与“有资格处理案件”分开

最容易出现的错误，是把产品名称、模型选择器和机构准入混为一件事。OpenAI 当前帮助页把 Astra for Law 描述为基于 GPT-6 Astra、结合 Legal Search Index 的法律工作模型，并说明初期面向美国部分律所，通过 Trusted Access、ChatGPT 与 Codex 提供，API 仍是即将开放状态。(help.openai.com)

这意味着至少有三层状态需要分别记录：

1. 产品已发布： 官方已经介绍 Astra for Law 的定位和法律搜索能力。
2. 机构具备申请资格： 你的律所可能可以联系账户团队或销售申请早期访问。
3. 具体账号已获权限： 管理员后台、模型选择器、合同附件和组织设置都必须能证明实际可用。

如果你只有第二层，没有第三层，就只能做公开资料评估或使用脱敏测试集。不要把客户合同、未公开诉讼材料、内部法律意见或含有身份信息的文件上传进去。

建议你建立一份“准入记录”，至少保存账号截图、管理员确认、适用合同、数据区域、模型名称和访问日期。对于 GPT-6 Astra Law，模型名称出现在下拉框里，只能说明产品入口存在，不能自动证明该入口适用于所有事项。

法律搜索更强，不等于意见可以直接交付

Astra for Law 的法律搜索覆盖美国判例、法规、行政决定和法院规则，官方也要求用户在依赖答案前检查回答和引用来源。(help.openai.com) 这解决的是检索效率问题，不是律师复核、职业责任或客户授权问题。

你需要把一次法律研究任务拆成可审计的证据链：

• 原始问题和案件事实是否经过脱敏；
• 模型引用的是哪个司法辖区；
• 引用材料是否仍然有效，是否存在后续判决、撤销、区分或不利依据；
• 输出是否把“可能适用”写成了确定结论；
• 执业律师是否独立复核了关键规则和引用段落；
• 错误发生后，是否能找到原始输入、模型输出、人工修改和最终版本。

这里不要把基准测试结果外推为单个案件的准确率。即使模型在法律研究验证集上表现良好，也不能证明它理解你所在州的最新程序规则，更不能证明它已经承担律师的判断责任。

对于首轮试点，优先选择公开法条摘要、已公开判例的结构化比较、内部培训材料或不涉及具体客户身份的研究任务。涉及诉讼策略、交易底价、未公开证据和利益冲突判断的任务，应该继续由律师和既有法律数据库完成最终确认。

ZDR 与客户机密之间，至少隔着四条数据路径

把 Zero Data Retention 理解成“所有内容都不会留下”，是第二种错误放行。OpenAI 的 API 数据控制文档明确区分了模型训练使用、滥用监控日志、应用状态以及客户自建存储；符合条件的组织可以申请 ZDR，但具体端点和能力仍可能存在应用状态限制。(platform.openai.com)

你应该逐项核对以下四层：

1．模型训练使用

企业和 API 数据默认不用于训练模型，但“默认不训练”与“客户文件不会被任何组件处理”不是同一件事。OpenAI 的企业隐私页面说明，企业数据默认不用于改进模型，同时提供访问控制、加密、数据留存和数据驻留等不同层级的管理能力。(openai.com)

2．滥用监控日志

API 文档说明，滥用监控日志默认最长可保留 30 天，符合条件的客户可以申请 ZDR 或 Modified Abuse Monitoring。(platform.openai.com) 这个数字只能帮助你核对 API 日志策略，不能直接套用到 ChatGPT 会话、插件服务商、Codex 工作区或律所自己的文档系统。

3．应用状态

同一份文档还说明，部分功能会保存应用状态；例如 Responses API 的 store 行为、后台模式、文件输入、提示缓存和工具能力，都需要按端点逐项判断。启用 ZDR 后，某些状态行为会改变，但“不符合 ZDR 资格的能力”不会因此自动变成无状态。(platform.openai.com)

4．客户自建存储与外部插件

文件最终可能进入案件管理系统、文档管理系统、向量库、插件缓存、审计平台或本地下载目录。ZDR 不会替你审查这些系统。你还需要结合客户授权、职业保密义务、内部信息分类、跨境传输和所在司法辖区要求作出判断。

如果合同条款、项目级设置和真实请求路径无法互相对应，验收结论应直接标记为“不通过”，而不是写成“理论上满足 ZDR”。

插件的权限边界，比 ChatGPT 工作区权限更复杂

法律插件通常会连接文档管理、案件管理、法律检索或知识库系统。OpenAI 的插件文档明确说明，插件安装、应用连接、工作区设置、提供商账户授权和具体读写动作是分开的；安装插件不会绕过外部系统权限。(help.openai.com)

因此，你不能只测试“能否搜到文件”，而要分别测试：

• 只读检索：是否只返回当前事项和当前律师有权访问的内容；
• 文件保存：草稿是否能写入正确的 matter 文件夹；
• 内容修改：插件是否能覆盖原文件，是否需要人工批准；
• 跨事项搜索：一个案件的关键词能否意外命中另一个案件；
• 权限撤销：断开账号后，新的请求是否立即失败；
• 审计记录：谁发起了查询、访问了什么、写入了哪里，能否导出。

官方还提醒，连接外部应用时，使用的账户必须真正拥有目标数据权限；连接个人账户，并不会自动获得工作账户里的文件和记录。(help.openai.com)

这对利益冲突墙尤其重要。插件可能遵循提供商账户的授权，却不一定理解你律所内部的事项隔离、临时团队权限或伦理墙规则。无法解释数据去向、无法及时撤权，或无法区分事项边界的插件，不应进入客户机密试点。

Codex 的文件执行权限，不能与普通法律研究共用工作区

Astra for Law 负责模型回答、法律检索和写作，不等于 Codex 的文件操作、外部工具调用和操作系统权限。你需要把这几个层级拆开验收：

1. 模型能读取什么；
2. Codex 工作目录能读取什么；
3. 临时凭据能访问什么；
4. 网络出口允许连接什么；
5. 插件或 MCP 能执行什么；
6. 任务结束后哪些文件、令牌和日志会被清理。

Codex 或连接应用产生的会话数据也不能只靠“断开连接”处理。官方说明，断开应用会阻止未来访问，但不会自动删除已经被会话引用的数据；要移除留在账户中的相关内容，需要删除对应会话。(help.openai.com)

所以，涉及批量文档处理、内部法律 Agent 或自动生成交易文件时，应该使用独立测试环境：

• 测试目录与正式案件文件系统分离；
• 使用临时凭据，不复用生产密钥；
• 默认关闭写入和外部网络；
• 每一次写操作都需要人工批准；
• 任务结束后清理临时文件、缓存和会话；
• 通过故障注入验证异常中断后的恢复行为。

你可以参考 MacPull 的控制与远程环境管理说明，先把测试设备、登录身份和正式文件系统拆开，再决定是否接入法律工作流。这里的云端 Mac 只是隔离执行环境，不会替代 OpenAI、插件服务商或律所本身的数据合同。

未来 API 先做适配层，不要提前假设生产能力

当前官方 Astra for Law 帮助页只说明 API “即将提供”，没有给出可用于生产排期的确定上线日期、价格、配额或最终字段。因此，开发团队现在可以做的是准备，而不是上线。

建议先完成以下工作：

• 用接口适配层隔离模型名称和请求字段；
• 给公开资料、内部资料、低敏客户资料、高敏客户资料建立分级；
• 准备可重复的法律研究评测集；
• 保存引用、司法辖区、时效性和不利依据；
• 为 API 不可用、结果不完整或权限异常准备回退路径；
• 把插件能力设计成可关闭、可替换的模块。

API 真正开放后，再重新核对端点是否支持 ZDR、是否保存应用状态、是否允许文件与后台任务、插件是否有替代路径，以及单个法律 Agent 任务的完整成本。不要因为代码已经写好，就把尚未确认的 API 当成生产端点。

OpenAI 的合规平台文档显示，合规日志平台默认保留 30 天，如果组织需要更长时间，应该持续下载并按照自身政策保存。(help.openai.com) 这说明“平台有日志”与“律所已经拥有可用于审计的长期证据”仍然是两件事。

中部 FAQ：把搜索意图转换成准入判断

上面的几个问题，最终都要落到“哪些数据可以进入、哪些数据必须留在本地或既有系统”上。对于高敏事项，建议先阅读 MacPull 的企业 AI 权限与远程管理帮助，再把产品权限、操作系统权限和文档系统权限分别登记。

FAQ 不应替代合同审查，但可以帮助你快速排除错误假设：

• 哪些律所目前能拿到 Astra for Law 的访问权限？ 目前是美国部分律所的有限开放，不是全面 GA；申请资格、账号权限和合同覆盖范围必须分别留证。
• ZDR 是否覆盖插件数据？ 不能直接覆盖；插件和外部应用有独立的数据处理、授权、缓存和撤销路径。
• 客户文件上传后会不会留存？ 取决于入口、应用状态、文件能力、会话设置和合同，必须用真实测试请求验证。
• API 何时接入法律 Agent？ 官方尚未提供确定日期；现在做适配层和评测，API 开放后重新验收。

试点评分：三档方案与停止条件

下面的评分不是 OpenAI 的官方认证，而是给你的内部项目委员会使用。每项 0 分表示没有证据，1 分表示有配置但未完成真实测试，2 分表示有合同、配置和可复现记录。

评分建议：

• 10—12 分： 可进入受限客户事项试点，但只允许已批准任务和人工复核。
• 6—9 分： 仅限公开资料或脱敏资料，继续补齐合同、插件和执行隔离证据。
• 0—5 分： 暂缓接入，不得导入客户机密。

上线前可勾选的验收清单

• [ ] 已确认律所是否属于当前 Astra for Law 的实际开放范围。
• [ ] 已保存管理员确认、账号可见性、合同范围和访问日期。
• [ ] 已把 ChatGPT、GPT-6 Astra Law、Codex、插件和外部系统列成不同数据路径。
• [ ] 已确认目标入口是否适用 ZDR，而不是只查看组织级宣传材料。
• [ ] 已测试上传、检索、写入、删除、归档和断开连接后的行为。
• [ ] 已对代表性法律问题保存来源、引用段落、律师复核和纠错记录。
• [ ] 已关闭或限制跨事项搜索，并验证利益冲突墙不会被插件绕过。
• [ ] 已为 Codex 使用独立工作目录、临时凭据和人工审批。
• [ ] 已验证任务中断、异常恢复和任务结束清理。
• [ ] 已为未来 API 准备适配层、评测集和回退方案，但没有虚构生产端点。
• [ ] 已由 IT、安全、法律科技和执业律师共同签署试点结论。

结尾前的方案对比：当前方案、受限试点与隔离 Mac

如果你继续使用普通办公电脑、共享开发工作区或直接把案件资料放进现有云端 Agent，真实缺点通常不是模型回答速度，而是身份混用、文件路径不清、插件权限过宽和异常后难以回溯。把 Codex 与正式案件系统放在同一工作区，还会让临时凭据、缓存文件和普通开发任务互相污染。

完成 Astra for Law 的访问与数据边界核对后，你可以再根据任务风险选择环境。下面三张表放在一起，便于项目委员会做最终分流。

如果你的目标只是处理公开法律资料，本地 Mac 或普通企业工作区可能已经足够；如果目标是验证 Codex 批量处理敏感文件、插件写入和法律 Agent 的隔离边界，独立云端 Mac 试点通常比把正式案件系统直接接入更容易回滚。你可以先通过 MacPull 的远程 Mac 方案入口了解可用的隔离方式，再决定是否租赁测试环境，而不是先采购长期设备。

Astra for Law 值得评估，但“法律专用”不是保密义务的自动保证，ZDR 也不是插件、Codex 和操作系统执行环境的全链路删除证明。对大多数律所来说，当前最稳妥的结论是：公开资料可以先试，低风险客户事项可以在证据完整后受限试点，高敏正式事项必须等合同、数据路径和隔离能力都能独立验收。

常见问题