症狀：你看到 Astra for Law 能做法律搜尋，又看到 Zero Data Retention（ZDR）選項，就準備把客戶文件匯入試用。
最快解法：先不要放行；只有符合資格、完成合約與資料路徑驗證的律所，才應從可追溯的低風險事項開始受控試點。
這篇文章適合三類人：
- 律所 IT 與安全負責人：你要判斷哪些案件資料可以進入 Astra for Law，並保存足夠的審計證據。
- 法律科技開發團隊：你準備透過 Codex、插件或未來 API 建立法律 Agent，需要先劃清資料與執行邊界。
- 合夥人及創新負責人：你要在有限試點、繼續等待與擴大部署之間作決定，而不是只看模型基準。
截至 2026 年 9 月 18 日，OpenAI 已確認 Astra for Law 於 9 月 17 日發布，初期面向美國部分律所，透過 Trusted Access、ChatGPT 與 Codex 提供；API 仍屬即將開放狀態。這是產品範圍判斷，不是全面 GA 或客戶機密自動獲准的證明。你應以官方 Astra for Law 說明與合約文件作最後依據。
先分清有限開放與可用資格
錯誤假設：產品已發布，所以任何律所都能使用。
官方公告中的「向部分律所開放」至少包含三個不同層次：產品是否已發布、你的機構是否符合 Trusted Access 申請或邀請資格，以及具體管理員帳戶是否真的看得到入口。這三者不能互相替代。
你要把以下資料保存到試點紀錄，而不是只截取產品頁面：
| 驗收項目 | 你要確認的證據 | 未通過時的動作 |
|---|---|---|
| 機構資格 | OpenAI 書面通知、合約範圍、適用地區與帳戶條件 | 只做公開資料評估 |
| 產品入口 | 管理員畫面、可用工作區、成員權限與啟用日期 | 不匯入客戶事項 |
| 功能範圍 | ChatGPT、Codex、Trusted Access 各自可用的能力 | 分開建立測試計畫 |
| API 狀態 | 官方端點文件與帳戶實際可見權限 | 不把未開放 API 設計成生產依賴 |
Astra for Law 現在對哪些律所開放？
目前能確認的是美國部分符合資格的律所，而不是所有地區、所有律所或所有工作區。你還要取得管理員確認：目前使用的是 Astra for Law 實際入口，還是一般 ChatGPT、Codex 或內部測試功能。若沒有書面資格、產品入口和帳戶範圍三項紀錄，結論只能是「公開資料試用」，不能進入客戶事項。
GPT-6 Astra Law 這類搜尋詞，也不應被當作另一個已確認的獨立產品名稱。試點文件應記錄實際產品名稱、工作區和端點，避免把市場討論或內部代稱寫成合約能力。
ZDR 與客戶保密不是同一層保護
錯誤假設：啟用 ZDR，就等於客戶文件不會被留存，也等於完成律師保密義務。
你至少要拆開四條資料路徑：模型訓練使用、濫用監控與操作記錄、應用程式狀態，以及律所自行控制的儲存位置。ZDR 只可能影響其中指定入口與指定資料處理條件，不能自動改變插件、外部儲存或律所內部備份的行為。
OpenAI 的企業資料控制說明可用來核對企業資料處理原則；API 端則要另外檢查官方端點資料使用政策。不要用銷售簡報或「法律專用」產品名稱代替專案級證據。
客戶文件上傳到 Astra for Law 會不會被留存？
不能用一句「不會」回答。你要先確認實際入口是否適用 ZDR，再確認檔案上傳、對話狀態、錯誤記錄、插件快取和律所自建儲存的分工。即使某條模型資料路徑不作訓練用途，也不代表外部插件沒有保存副本，更不代表你的客戶授權、職業責任和地域要求已經滿足。
把驗收結果分成以下狀態較可靠：
- 已證實：合約條款、管理員設定和真實請求路徑彼此一致。
- 待確認：產品文件提到條件，但你的工作區尚未看得到或測不到。
- 不得推定：只有口頭承諾、產品名稱或未指定入口的 ZDR 描述。
法律搜尋正確，不等於意見可以直接交付
錯誤假設：模型找到看似正確的判例，所以研究結果可直接成為法律意見。
法律研究的風險不只在答案是否流暢，還在引用是否屬於正確司法管轄區、判決是否仍有效、後續歷史是否改變結論，以及模型是否遺漏不利依據。官方驗證集或產品展示只能說明某種測試表現，不能外推成單一案件的可靠性承諾。
你應把每項代表性任務保存成可重播紀錄：
- 原始問題與案件背景的資料分級；
- 模型列出的來源、引用段落與司法轄區；
- 律師對關鍵依據的獨立核對結果；
- 被發現的錯誤、修正內容與誰批准交付；
- 最終輸出是否只作研究草稿，而非直接對客戶發出的意見。
如果團隊無法在模型輸出之外獨立驗證關鍵法律依據，Astra for Law 就只能定位為研究輔助。這項限制同樣適用於以 Codex 編排的法律 Agent；程式能自動整理資料，不代表整理結果具備法律效力。
插件連線範圍，比工作區權限更難看清
錯誤假設：ChatGPT 工作區看不到某事項，外部文件管理或法律檢索插件就一定看不到。
插件可能各自持有獨立的登入狀態、資料快取、寫入權限和撤銷流程。你要逐個還原文件管理、案件管理及法律檢索系統的讀取、寫入、快取與刪除路徑，而不能把 ChatGPT 工作區成員權限直接等同於外部系統權限。
OpenAI 的連接與管理 ChatGPT 應用程式帳戶說明可作為帳戶連線核對起點，但你的實際插件仍需獨立驗收。
| 測試動作 | 你要觀察的結果 | 放行條件 |
|---|---|---|
| 只讀檢索 | 是否只回傳獲授權事項的內容 | 不跨事項、不突破倫理牆 |
| 儲存檔案 | 副本存在哪裡、保存多久、誰能取用 | 有明確保留與刪除證據 |
| 修改內容 | 是否需要人工批准、能否復原 | 預設禁止直接覆寫正式文件 |
| 跨事項搜尋 | 是否混入其他客戶或團隊資料 | 權限按事項繼承並可稽核 |
| 撤銷授權 | 撤銷後舊工作階段是否仍能讀取 | 能及時失效，且有測試記錄 |
Astra for Law 的 ZDR 是否覆蓋插件資料？
不能直接推定。你要取得插件自身的資料處理條款、實際授權範圍和請求記錄，再對照 Astra for Law 工作區的設定。若你無法說明資料從哪個系統出去、在哪裡暫存，以及撤銷後多久失效，就不應讓它接觸機密事項。
Codex 的檔案操作，會把風險推進執行環境
錯誤假設：Codex 只是回答法律問題，所以與作業系統檔案權限無關。
當 Codex 參與文件批次處理或內部法律 Agent 時，風險已不只在模型答案，而會延伸到工作目錄、臨時憑據、網路出口、外部工具和作業系統權限。你需要把 Astra for Law 的模型回答、Codex 程式與檔案操作、插件呼叫及 Mac 執行環境分開記錄。
第一步：建立不含真實客戶資料的測試工作區，使用合成文件驗證讀取、分類、重新命名和失敗恢復。
第二步：將正式案件檔案系統與一般開發工作區分離，不共用登入狀態、密鑰、快取目錄或同步資料夾。
第三步：限制工作目錄與網路出口，並把外部工具改為白名單；需要寫入時，先設成人工批准。
第四步：檢查任務結束後的臨時檔案、環境變數、日誌和憑據是否清除，不能只關閉聊天視窗。
第五步：故意測試權限錯誤、插件中斷、網路失敗和部分寫入，確認可以停止、回復及追蹤責任人。
第六步：對 Codex 對話與工作紀錄建立保存期限及刪除流程。OpenAI 提供了封存與刪除 Codex 對話的說明，但這不會自動替你清理外部工作區、作業系統暫存檔或律所備份。
需要雲端 Mac 作測試時，先閱讀MacPull 的雲端 Mac 方案資訊與價格頁面，再把測試環境視為獨立執行面，不要把租用環境直接宣稱為法律資料合規方案。
API 未普遍開放，先做適配層而不是先做生產系統
錯誤假設：既然 API 即將開放，現在就可以按照預想欄位、配額和日期開發完整法律 Agent。
截至本文核實日期，官方只確認 API 屬於即將開放，沒有在本次資料中確認普遍可用日期、地區、價格、配額或插件替代能力。你現在可以做的是介面適配層、資料分級、評測集、人工回退和記錄格式；不要虛構模型欄位，也不要讓正式案件流程依賴尚未取得的端點。
API 開放後，再逐項重跑：
- 你的帳戶是否真的具備端點資格；
- ZDR 是否適用於該端點及任務類型；
- 狀態保存、檔案處理和刪除由誰負責；
- 原有插件是否能被安全替代；
- 每次任務的完整成本與人工審核成本；
- 失敗時能否退回人工研究或非機密資料流程。
你可以用以下清單形成決策紀錄：
- [ ] 已保存 Astra for Law 的機構資格、帳戶入口與合約範圍。
- [ ] 已確認實際入口的 ZDR 條件，而非只引用產品名稱。
- [ ] 已分開測試模型回答、插件資料、Codex 檔案操作與作業系統權限。
- [ ] 已對代表性法律研究任務保存來源、引用、律師核對與糾錯記錄。
- [ ] 已在合成資料環境測試撤權、刪除、失敗恢復和跨事項隔離。
- [ ] 已為 API 未開放期間設置人工回退，不讓預測日期成為上線條件。
- [ ] 已由安全、法律科技與案件負責人共同簽署試點結論。
評分時不要只給模型能力分數，可以按四個維度各自記錄「通過、待補證據或不通過」：資格與合約、資料路徑、法律研究可核驗性、執行環境隔離。只要資料路徑或撤權能力是不通過，就算回答品質很高，也應暫停客戶事項試點。
最後的分流可以很簡單：
- 僅公開資料試用：資格或資料控制仍未完成，只測公開判例與合成文件。
- 受限客戶事項試點：合約、入口、資料路徑和人工核驗均有證據，且只限低風險、可追溯事項。
- 暫緩接入：插件去向不明、Codex 可直接寫入正式檔案、無法撤權，或關鍵法律依據無法獨立驗證。
如果你已經完成 Astra for Law 的入口與資料邊界核對，下一步不是立即擴大權限，而是把敏感文件 Agent、Codex 工作區和插件撤權流程放進獨立測試環境。相較於直接把機密資料放進共享 ChatGPT 工作區，現有的本地電腦或一般雲端主機常見問題是權限難以按事項隔離、臨時檔案與憑據清理不一致，以及團隊難以重現同一套執行環境；Hackintosh 類方案則還有硬體維護、系統更新與正式支援邊界不清的代價。若你的目標只是短期試點、敏感文件驗收或 Codex 權限測試，租用 MacPull 的獨立雲端 Mac 環境會比改造現有辦公設備更容易拆分工作區與回收資源；但長期固定重負載、必須掌握實體介面或已有成熟機房治理的律所，仍應先比較自購設備與既有雲端方案，而不是為了試點盲目租用。需要部署前的連線、帳戶和環境核對，可再參考MacPull 的支援說明。