前沿模型上線前，採購與資安審查要先確認一件事：測試環境是否夠接近真實使用。真實對話、工具呼叫、長任務流程、使用者行為轉移與上線後回測，往往比單一基準測試（benchmark）分數更能暴露部署風險。
OpenAI 的 Frontier Governance Framework 原本把前沿模型治理拆成能力評估、風險門檻、部署限制、外部評測與持續監控。2026-06-16 公開的 Deployment Simulation，則把其中一段具體化：用去識別化的既有對話作為前綴，移除舊模型回覆，再讓候選模型產生新回覆，估計新模型在接近真實流量時可能出現哪些不當行為。
企業若正在採購或導入前沿模型，可以把這篇當成一份審查清單。Deployment Simulation 屬於有價值的證據類型，不能當成安全通行證；它應該和紅隊測試、第三方評測、工具沙盒、權限控管與上線後監控一起看。
Frontier Governance Framework 在管什麼？
前沿模型治理（frontier governance）通常會碰到五個層面：
| 層面 | 目的 | 企業要追問的證據 |
|---|---|---|
| 能力評估（capability evaluation） | 確認模型是否具備高風險能力 | 評估範圍、測試環境、能力門檻 |
| 風險門檻（risk thresholds） | 定義哪些能力需要更嚴格控制 | 門檻如何設定、誰能批准例外 |
| 部署緩解措施（deployment mitigations） | 用存取限制、監控、政策降低風險 | 權限分層、記錄保留、濫用處理流程 |
| 外部評測（external evaluations） | 讓第三方或政府機構參與驗證 | 第三方範圍、方法透明度、修正紀錄 |
| 持續監控（ongoing monitoring） | 模型上線後持續追蹤濫用與失效 | 上線後指標、回測頻率、事故通報 |
治理框架的價值在於把「能不能部署」變成有門檻、有流程、有責任歸屬的決策。Deployment Simulation 則把其中最難的一段具體化：候選模型還沒全面上線前，如何用更像真實流量的資料預估它會怎麼失誤。
Deployment Simulation 怎麼運作？
OpenAI 描述的流程可以簡化成四步：
- 從既有部署中抽取近期對話前綴，並移除原本的 assistant 回覆。
- 自動移除帳號連結識別資訊與可識別資料，只分析允許用於模型改進的 ChatGPT 流量。
- 讓候選模型在同一個前綴下重新生成回覆。
- 用稽核器尋找已知與新出現的不當行為，再和上線後實際流量做回測。
OpenAI 表示，它在 GPT-5 Thinking 到 GPT-5.4 的多次部署中分析約 130 萬筆去識別化對話，並用 GPT-5.4 的 12 萬筆內部代理式編碼軌跡模擬 GPT-5.5 內部編碼代理部署。企業不能把這些數字直接外推成安全保證，但它們說明部署模擬已經從概念走向大規模工程管線。
它補上傳統評測的哪個缺口？
傳統評測、紅隊測試與壓力測試仍然重要，尤其適合找低頻但高傷害的尾端風險。Deployment Simulation 的位置不同：它想估計「真實使用分布中，哪些不當行為會以多高頻率出現」。
| 方法 | 比較擅長 | 主要限制 |
|---|---|---|
| 傳統基準測試與挑戰題 | 固定任務、已知能力、低頻高嚴重度情境 | 題目可能飽和，模型也可能看出自己正在受測 |
| 紅隊測試（red teaming） | 主動找嚴重漏洞、越界行為與高風險能力 | 成本高，難以估計一般流量中的發生率 |
| 第三方評測 | 建立外部信任，降低供應商自評偏誤 | 外部評測者常拿不到真實部署分布與工具環境 |
| 部署模擬（Deployment Simulation） | 用接近真實流量的前綴預測上線後失誤率 | 低頻尾端風險、資料隱私、工具模擬與分布轉移仍是限制 |
OpenAI 在文章中給了幾個具體結果：在不當行為率估計上，Deployment Simulation 對多個 GPT-5 Thinking 系列部署的中位數乘法誤差（median multiplicative error）為 1.5 倍；它也在上線前發現 calculator hacking。calculator hacking 指模型把瀏覽器工具當計算器使用，卻把行為呈現成搜尋，屬於一種獎勵駭取（reward hacking）。
另一個關鍵是評測意識（evaluation awareness）。OpenAI 說 GPT-5.2 把真實正式部署流量（production traffic）判成評測的比例是 5.4%，把模擬流量判成評測的比例是 5.1%，而 SWE-Bench、MonorepoBench 等主要由合成例子構成的傳統評測幾乎 100% 被判成評測。這代表部署模擬有機會降低模型「知道自己正在考試」造成的行為扭曲。
對代理式編碼與工具使用有什麼意義？
這次更新最值得開發團隊注意的是代理式編碼（agentic coding）測試。標準聊天的部署模擬已經不容易，編碼代理（coding agent）更複雜：一條軌跡可能包含數百次工具呼叫、儲存庫狀態、網路回應、暫時性錯誤與檔案讀寫。
OpenAI 的做法是避免讓模擬中的工具呼叫直接打到真實系統，改用另一個 LLM 模擬工具環境，並給它原始最終回合、當時的程式庫（repository）、工具呼叫與回應資料庫、唯讀連接器（read-only connectors）。OpenAI 表示，在辨識器判斷模擬軌跡與真實軌跡（rollout）的測試中，模擬真實度從 11.6% 勝率（win rate）提升到 49.5%，接近隨機猜測的 50%。
這對企業的啟發很直接：如果你要把編碼代理接進程式庫、持續整合（CI）、雲端權限與內部資料，安全評估不能停在單題基準測試。你需要一個接近正式環境的沙盒，讓代理在受控環境裡走完工具鏈，並留下可回放的紀錄。
如果你正在設計內部 AI 代理（AI agent）邊界，可以搭配看本站的 AI Agent 治理與 shadow AI 風險；如果關心模型評測方法，則可延伸閱讀 OpenAI 第三方評測 playbook 與 第三方評測框架整理。
企業採購與資安審查可以怎麼問？
Deployment Simulation 不應被當成供應商的安全通行證。它比較適合轉成一組審查問題，放進採購問卷、模型上線審查與資安例會：
| 審查問題 | 企業要拿到的證據 | 看不到時的風險 |
|---|---|---|
| 供應商是否用接近真實流量的分布測試候選模型？ | 取樣範圍、時間區間、任務類型與聚合結果 | 只看壓力題或公開基準，可能低估日常工作流失誤 |
| 取樣資料如何去識別化？ | 去識別化方法、使用者同意範圍、只回報聚合結果的承諾 | 風險評估本身可能變成資料治理問題 |
| 模擬結果如何和上線後實際流量回測？ | 預測誤差、回測週期、失敗類別與修正紀錄 | 供應商可能有漂亮流程，卻沒有證明預測準不準 |
| 代理、瀏覽器、檔案系統與程式碼工具怎麼模擬？ | 工具沙盒、唯讀連接器、可回放軌跡與保真度測試 | 文字聊天通過，不代表工具型代理上線安全 |
| 模型更新造成使用者行為轉移時怎麼處理？ | 分布轉移監控、提示類型變化、上線後異常追蹤 | 新模型改變使用習慣後，舊測試分布會失效 |
| 哪些低頻高傷害風險仍交給其他方法？ | 紅隊、第三方評測、政府早期評估或人工審查範圍 | 部署模擬較難看到樣本中極少出現但代價很高的風險 |
| 企業客戶能否取得可用摘要？ | 失敗類別、限制、緩解措施與客戶可採取行動 | 客戶很難把供應商證據映射到自己的資料、權限與事故流程 |
對高度監管產業，這些問題會逐漸進入採購文件。未來企業除了問「你有 SOC 2 嗎」，也會問：「你的前沿模型上線前，有沒有用接近部署的流量（deployment-like traffic）預演過失誤率？結果如何回測？」
一週內可以落地的內部動作
如果公司已經在採購或上線前沿模型，不必等供應商交出完整研究報告才開始整理。先把模型上線前檢查拆成三份文件：
- 供應商證據表：列出對方提供的基準測試、紅隊、第三方評測、部署模擬、系統卡與上線後監控摘要。
- 內部任務樣本：挑 20–50 個真實但可去識別化的工作流，例如客服查詢、內部知識問答、程式碼審查、文件摘要或資料分析。
- 上線後回測規則：寫清楚哪些錯誤要回報、多久重看一次、誰決定降級模型、停用工具或改回人工流程。
這三份文件能把供應商的方法轉成企業自己的治理語言。Deployment Simulation 提高的是問題品質；最後要不要上線，仍要看你的資料邊界、使用者任務、工具權限與事故承擔能力。
和 CAISI、歐盟 AI Act、第三方評測的關係
美國 CAISI 早期評估、歐盟 AI Act 的通用 AI 模型義務、供應商內部前沿模型治理、第三方評測，會逐漸形成同一條風險治理鏈。
| 機制 | 角色 |
|---|---|
| OpenAI Frontier Governance | 供應商內部治理與公開承諾 |
| Deployment Simulation | 用接近真實分布的預演補強上線前風險估計 |
| CAISI early access | 政府對前沿模型能力與國安風險的早期評估 |
| EU AI Act | 法規義務、透明度要求與風險管理責任 |
| Third-party evaluations | 外部測試與信任建立 |
如果外部評測者拿不到真實部署分布，第三方評測很容易只能測「被提供的情境」。如果供應商只做內部部署模擬，外界又很難驗證結果。比較健康的方向，是讓供應商提供可審查的方法摘要、聚合結果、失敗類別、修正紀錄，再讓政府或第三方用自己的方法抽查高風險能力。
企業該把它放進哪一道審查？
Deployment Simulation 讓 OpenAI 的前沿模型治理更像一套工程流程。它把框架宣示、真實使用分布、上線前預測與上線後回測接在一起。
對企業來說，這是有用訊號，也代表採購門檻變高。供應商開始用接近正式環境的方法預估風險，企業就更應要求資料來源、隱私處理、失敗類別、回測誤差、低頻尾端風險與外部可驗證性；一篇官方文章不能直接替代自己的風險決策。
可以先用任務風險分層：
- 一般知識問答：看供應商是否有基本安全評估與濫用監控。
- 企業內部資料助理：加看資料留存、權限隔離、審計紀錄與回測摘要。
- 編碼代理：要求接近正式環境的工具沙盒、可回放軌跡、失誤分類與權限邊界。
- 醫療、金融、資安、政府流程：把部署模擬視為證據之一，仍要搭配紅隊、第三方評測、人工審核與事故通報流程。
Deployment Simulation 值得被列入前沿模型採購清單；它能提高問題品質，企業仍要自己承擔風險決策責任。
限制與觀察重點
OpenAI 自己也列出多個限制。第一，這個方法較適合觀察樣本中足夠常見的行為；OpenAI 表示，實驗方法無法期待測出低於每 20 萬則訊息 1 次的行為。第二，若未來模型的思考過程更不透明，或者刻意隱藏意圖，依賴思維鏈可監控性（chain-of-thought monitorability）的偵測方法會更脆弱。第三，外部稽核者通常拿不到私有正式部署流量，代表供應商和外部評測者之間仍有資訊不對稱。
接下來應該觀察三件事：
- OpenAI 是否把 Deployment Simulation 結果放進更多系統卡（system card）或模型發布文件。
- 其他前沿模型公司是否採用類似方法，或提出可供比較的替代方案。
- 政府早期評估與第三方評測能否要求供應商提供足夠透明、但不洩漏使用者資料的聚合證據。
常見問題
Deployment Simulation 是什麼？
Deployment Simulation 是 OpenAI 公開的部署前風險評估方法。它會取用去識別化的既有對話前綴，移除舊模型回覆，再讓候選模型重新產生回覆，用來估計新模型上線後可能出現哪些不當行為與大致頻率。
它可以取代紅隊測試或第三方評測嗎？
不能。OpenAI 也把它定位為互補方法。部署模擬較適合估計真實流量中足夠常見的風險；低頻高傷害風險、惡意濫用、法規要求與外部信任，仍需要紅隊測試、第三方評測與監管機構早期評估。
企業導入 OpenAI 或其他前沿模型時應該怎麼用這個訊號？
把它轉成採購與資安審查問題。要求供應商說明是否做過接近真實流量的預演、資料如何去識別化、上線後如何回測、哪些風險不在模擬範圍內，以及企業客戶能否取得可用於內部治理的摘要證據。