我們建議的私人 AI 服務交接記錄

NIST 的 AI 風險管理框架涵蓋 AI 系統設計、開發、使用及評估過程中的可信度。[1] 運行期間亦應有相應證據。對於由試點轉為常規使用的私人 AI，我們建議採用一份交接記錄，讓接手團隊能識別安裝環境、了解其限制，並在系統故障時作出回應。

以下為我們建議的交接格式，並非經審核的客戶部署報告。此格式補充了 Software Tailor 信任中心中的技術及數據邊界資訊。每個組織應根據自身運作模式分配相關職責。

指明接收擁有人及允許的工作範圍

由一個具名角色開始，該角色承擔服務責任。記錄其聯絡方式及當常用擁有人不可用時的替代安排。供應商的支援地址有用，但組織亦需有人能決定在事件期間服務是否繼續運行。

描述獲批准用於常規操作的任務及仍限於試點階段的任務。包括獲准使用服務的群組及預期的運作時間。未解決的試點問題應保持可見，並指明擁有人及計劃決策日期；不應因安裝狀態變更而消失。

延續購買決策中使用的容量及截止假設。這讓接收團隊在工作負載變化時有理由進行調查。

記錄應用程式及伺服器版本、運行時環境及精確模型參考。通過組織的正常受控文件流程保留安裝來源及相關配置。憑證應通過其憑證管理流程存儲，交接記錄中只留參考，不複製秘密值。

Hugging Face 模型卡提供模型用途、限制及評估的文件說明。[2] 連結相關卡片及版本，並加入試點的本地發現。發行者描述與組織測試結果回答不同問題；接收團隊應能找到兩者。

系統如有可選的外部供應商，記錄啟用的路徑。描述每條路徑的預期數據邊界及誰可批准更改。避免使用如「本地」等籠統標籤，當運行配置需要更精確說明時。

對於代理整合，附上商定的工具清單及每個連接所使用的身份。OWASP 建議限制代理的功能與權限，並在下游系統中強制授權。我們的交接建議將該指引轉化為所有權問題：誰可以審查或撤銷每項授權？

包括工具呼叫整合檢查的結果，以及任何剩餘的限制。區分提出操作的權限與執行操作的權限。如需人員批准行動，請明確該批准發生的位置及失敗或放棄批准的處理方式。

接收方擁有者亦應知悉現有的診斷記錄、誰可存取及保存期限。使用已配置的政策及經驗證的範例。切勿因某組件採用無內容審計設計而推斷所有連接組件均無提示。

選擇一個商定的、非破壞性的中斷於測試環境中。由接收團隊依照復原指示操作，原實施者旁觀。記錄他們遇到的缺失資訊，並於簽署前更新指示。

此演練應確立如何識別問題、誰可停止受影響工作及如何檢查復原服務。如計劃包含回滾，請明確保留的版本及適用回滾的時點。未測試的復原假設應標示為未測試。

對於 Software Tailor 服務討論，經過編輯的配置記錄及失敗步驟的清晰說明，比無根據聲稱整個系統故障更有用。交接應說明如何透過組織核准的支援途徑收集該資訊。

以接收方擁有者的接受、日期及未解決事項作結。列明應觸發審查的變更，如不同模型、新連接器或更廣泛的允許任務。這是建議的運作紀律，而非認證計劃。

當接收團隊能利用該記錄作出決策，而無需憑記憶重建試點時，該記錄即已準備妥當。

[1] NIST。 AI 風險管理框架。框架 1.0 於 2023 年發布；背景指引。存取日期 2026-09-26。

[2] Hugging Face。模型卡。常設模型文件指引。存取日期 2026-09-26。

[3] OWASP 生成式 AI 安全專案。 LLM06:2025 過度代理權限。2025 年版。存取日期 2026-09-26。