Booz Allen + OpenAI 把安全 AI 做成可部署

我把 Booz Allen 與 OpenAI 的合作拆成一套可直接套用的安全 AI 上線模板，重點是治理、邊界、操作與審計。

我最近一直在看各種 AI 系統怎麼進到真的有規範、有稽核、有責任歸屬的環境。Demo 都很漂亮，真的。問題是 demo 結束後，事情才開始爛：誰能看資料、誰能改提示、log 留多久、出事誰負責、模型答錯要怎麼停。很多團隊把這些當成後話，結果就是模型很會講，系統根本不能上線。

所以我看到 ExecutiveBiz 這篇在講 Booz Allen Hamilton 跟 OpenAI 的合作時，第一個反應不是「喔好酷」，而是「終於有人把重點放在能不能部署」。這種合作如果只是在講 AI 很強，那我真的沒興趣。我在意的是，它有沒有把模型包進一個安全團隊、法遵團隊、任務負責人都能接受的外殼裡。

這篇不是新聞整理。我是拿這個合作當觸發點，拆它背後的方法論，再翻成台灣開發者能直接抄的版本。Booz Allen Hamilton 官方站在這裡：https://www.boozallen.com/，OpenAI 官方站在這裡：https://openai.com/。來源裡沒有提供觀看數、收藏數或星數，我就不亂編了。

它賣的不是 AI，是可被信任的邊界

Booz Allen Hamilton and OpenAI have announced a new partnership to advance the deployment of mission-ready artificial intelligence across national security and critical infrastructure.

翻譯一下就是：他們不是在賣一個會聊天的模型，他們是在賣一條能讓模型進到敏感環境的路。這句「mission-ready」很重要，因為它其實在講一件很現實的事：不是模型會回答就能上線，而是它能不能在限制、審核、紀錄、隔離這些條件下活下來。

我以前也踩過這種坑。團隊興沖沖把一個 LLM 接到內部流程，前端很快、體驗很好，大家都笑得很開心。然後安全同事一問：資料會不會外流？prompt 會不會被留存？誰能看輸出？模型出錯怎麼追？整個會議室瞬間安靜。那一刻我就知道，真正的產品不是模型，是信任邊界。

實操上，我會先寫一頁紙，把邊界講死，不要靠感覺。哪些資料能進系統，哪些不能；哪些角色能看 prompt、能看輸出、能看 log；哪些資料會存，存多久，存在哪個環境。你如果連這些都講不清楚，就別急著寫 agent、別急著接工具、也別急著談上線。

• 先定資料分級：公開、內部、受限、敏感，照你公司現有制度來。
• 每一級資料對應一組允許的模型行為與保存規則。
• 把「誰能批准」寫成流程，不要靠群組裡一句話放行。

合作有沒有料，先看有沒有把髒活做完

很多 AI 合作公告都愛跳過整合這件事，因為整合很醜。講「我們合作了」很帥，講「我們花六週接身份驗證、審計紀錄和政策控制」就很像在寫工單。但我跟你講，真正決定能不能部署的，九成是這些髒活。

國防、政府、關鍵基礎設施這些環境，不會因為你模型很強就對你放水。你要的是 identity-aware access、環境隔離、可稽核的 logging、還有一套不讓模型繞過流程的控制面。這些東西沒做好，聊天介面再漂亮也沒用，因為它最後都會卡在 enterprise auth、資料外洩風險、或是法遵不敢簽。

我會把 OpenAI 的 API 文件當成引擎說明，不是產品說明。引擎很強，不代表車就能上路。Booz Allen 這種夥伴的價值，通常就在於把引擎塞進能進場的車殼裡。你如果是一般公司，也是一樣：不要先問「用哪個模型」，先問「模型外面要包什麼系統」。

實操寫法很簡單：把 AI 專案當成一個受管控系統，而不是一個 prompt demo。你需要身分管理、權限控管、政策引擎、監控、紅隊測試、人工覆核、回滾機制。少一個都不行，因為少掉的通常不是功能，是責任歸屬。

安全 AI 其實是營運問題，不是模型問題

大家很愛盯模型準不準，但在受管控環境裡，能不能上線通常是營運決定的。像是 secret 怎麼管、環境怎麼切、prompt 怎麼記、事故怎麼處理、版本怎麼控，這些才是會讓專案活下來的東西。模型答得再好，只要營運包裝亂七八糟，最後還是不能碰正式流程。

我見過很多團隊把 AI 當成「更聰明的查詢框」，結果忘了它其實是一個新的風險面。它會吃資料、會吐資料、會接工具、會被提示注入、會在 log 裡留下痕跡。你如果沒有把這些風險當成產品的一部分處理，那你做出來的不是助手，是一個很會講話的責任炸彈。

所以我現在會直接照 production ops 的標準來寫 AI ops。誰是 owner、誰收 alert、哪些錯誤要停、哪些情況要降級、哪些輸出一定要人工看，全部先定好。不要等上線後才問。上線後再補，通常都補得很醜。

• 把模型存取放在你原本就信任的 identity provider 後面。
• prompt 和 output 要能被 review，但不能把更多敏感資料一起洩出去。
• 訓練資料、telemetry、對話紀錄都要有明確 retention 規則。
• 整個功能要有 kill switch，不是只有單筆 request 的 timeout。

我自己最常用的心法是：每一次 AI 呼叫都當成外部依賴。timeout、retry、circuit breaker、observability，這些不是加分項，是基本盤。你如果把它想成「一個聰明功能」，你就會漏掉它其實也是一個會壞、會漂、會失控的服務。

國安場景要的是工具感，不是人格感

這點我很有立場。很多 AI 產品都在做「很像人」的體驗，講話要親切、要會接話、要像同事。這在消費級產品也許還行，但在國安、醫療、金融、基礎設施這種地方，最重要的不是可愛，是可預期。系統要像設備，不要像一個情緒穩定度不明的同事。

也就是說，介面要收斂，輸出最好結構化，拒答條件要明確，升級處理要清楚。模型不是來跟你交朋友的，是來幫你完成受控任務的。你給它越多自由，它越容易在你最不想出事的地方出事。這不是模型壞，是你把它放在錯的位置。

OpenAI 這邊有幾個文件很值得看，像是 function calling 跟 structured outputs。這兩個東西的價值，不是讓 demo 更炫，而是讓模型輸出變成下游系統能處理的格式。Booz Allen 這種合作如果真的落地，重點也會在這裡：把模型變成可控元件，而不是聊天玩具。

實操上，我會先把能結構化的輸出全結構化。能用 JSON 就不要用散文，能用 schema 就不要讓模型自由發揮。需要人工審核的決策，直接做成 workflow 節點，不要幻想模型會自己「小心一點」。它不會。它只會照你給的規則做，或是照你沒寫清楚的地方亂做。

真正值錢的是把專業包成可複用的交付物

這種合作公告最容易被忽略的一點是：值錢的常常不是模型本身，而是包裝模型的那層專業。Booz Allen 長期處理的是流程、政策、任務脈絡；OpenAI 提供的是能力。兩者湊在一起，真正有意思的問題變成：能不能把這些能力包成一套別人不用重造輪子的交付方式？

我很吃這一套，因為大多數組織在 AI delivery 上都很爛。每個 team 都自己寫 prompt、自己定 log 規則、自己做審批流程，最後大家都以為自己很特別，其實只是各自重複造輪子。結果就是治理碎掉、維運碎掉、知識也碎掉。這種專案看起來很多，真正能複用的很少。

如果你想抄這個方向，我會建議你直接做 reference stack。不要只寫一份簡報，真的做一套基線：模型存取、政策控制、logging、人工覆核、部署目標，全都放進去。然後規定新專案先從這個基線開始，除非他能清楚說明為什麼要偏離。這樣才不會每個案子都變成一次性實驗。

你可以參考的框架有 NIST AI Risk Management Framework、NIST Cybersecurity Framework，以及 Open Policy Agent。我不是要你照抄文件，我是要你借它們的語言，讓工程、資安、法遵講同一套話。

我會抄的，是框架，不是公關詞

我會抄這個合作的 framing：mission-ready、secure deployment、critical infrastructure。這些字眼如果只是拿來貼在首頁，當然很空。但如果它們逼你去回答資料邊界、控制面、責任歸屬，那它們就很有用。因為它們把問題從「模型多厲害」拉回「系統能不能活」。

我不會抄的，是那種一看就知道很像公關稿的樂觀語氣。那種東西最便宜。真正貴的是把風險列清楚，把失敗模式寫清楚，把回滾機制做出來。安全 AI 不是比較會講故事，而是比較能承受現實。

如果我現在要帶一個團隊做這種東西，我會先做四件事：定任務、定資料、定控制、定退出條件。四個都不清楚，就先不要談上線。這不是保守，這是避免你之後花三倍時間收爛攤子。

而且我會把人放在流程中心。敏感環境裡，AI 的角色應該是減少摩擦，不是拿掉責任。它可以幫你草擬、摘要、分類、建議，但最後那個決定，還是要有人簽。這不是限制，這是能部署的代價。

可抄的模板

# 安全 AI 交付模板：從 demo 變成可部署系統

## 1. 任務定義
- 這個 AI 服務支援哪個任務或流程？
- 它要幫忙的是哪個決策或哪個步驟？
- 明確不做什麼？

## 2. 資料邊界
- 允許輸入：
  - 公開資料
  - 內部資料
  - 受限資料
  - 其他：__________
- 禁止輸入：
  - __________
- 保存規則：
  - prompts：__________
  - outputs：__________
  - logs：__________
  - retention：__________

## 3. 權限與信任控制
- Identity provider：__________
- 可使用系統的角色：__________
- 可查看 logs 的角色：__________
- 可批准變更的角色：__________
- 必須人工覆核的情況：
  - 高風險輸出
  - 對外分享
  - 會影響營運的決策

## 4. 模型行為規則
- 輸出格式：
  - 自由文字
  - JSON
  - Schema：__________
- 拒答條件：
  - 敏感資料
  - 上下文不足
  - 與政策衝突
  - 其他：__________
- 拒答後的升級處理：
  - __________

## 5. 營運控制
- Timeout：__________
- Retry policy：__________
- Circuit breaker：__________
- 監控指標：
  - error rate
  - latency
  - refusal rate
  - human override rate
- Kill switch owner：__________

## 6. 稽核與審查
- 會記錄什麼：__________
- 誰審查 logs：__________
- 審查頻率：__________
- Incident response owner：__________
- Audit trail 存放位置：__________

## 7. 上線檢查清單
- [ ] 資料分級已核准
- [ ] 權限控管已串好
- [ ] Logging 已給資安看過
- [ ] 人工覆核流程已測過
- [ ] 失敗模式已測過
- [ ] Rollback plan 已寫好
- [ ] Kill switch 已測過
- [ ] 上線負責人已指派

## 8. 退出條件
如果出現以下情況，就停用或重做：
- __________
- __________

## 9. 一頁式核准單
核准人：
- Mission owner：__________
- Security：__________
- Legal / compliance：__________
- Engineering：__________

日期：__________

## 10. 最後原則
- 模型是元件，不是決策主體
- 先有邊界，再有功能
- 先能稽核，再談擴大使用
- 先能停機，再談自動化

這份模板的目的不是讓 AI 變慢，是讓它變得可以被交付。你如果能把這些欄位填完，通常就代表你已經從「有個 AI 想法」走到「有個能進流程的系統」。填不完也沒關係，至少你知道自己現在卡在哪。

原始來源是 ExecutiveBiz 這篇，另外我也參考了 Booz Allen Hamilton、OpenAI、OpenAI 文件、NIST AI RMF。上面的拆解跟模板是我自己整理的，合作本身與公告內容則屬於 Booz Allen Hamilton 和 OpenAI。