AI 供應商合約怎麼談？版本變更、SLA、事故通知與退場
AI 供應商合約常寫有高可用、持續改善、合理通知與企業級安全，但真正上線後，模型別名可能改變，限流可能只在尖峰出現，事故定義可能不含品質或資料處理，而取消服務時又發現提示、評測、日誌和工作紀錄無法移轉。談判重點不是追求一份看起來最嚴格的條款，而是讓重要承諾能被量測、通知、驗證並在失敗時採取行動。
NIST SP 800-161 Rev. 1 提供科技供應鏈風險識別、評估與處理指引；NIST SP 1326 則以供應商盡職調查支持取得與持續使用決定。NCSC 安全 AI 開發指引 也建議監測 AI 供應鏈並為任務關鍵系統考量 failover。這些資源能幫助提出問題，但不構成台灣契約條款、法律意見或適用所有服務的固定 SLA 數字。
把服務承諾寫成可重算的分母
可用性要說明測量端點、地區、模型、期間、分母、錯誤碼、維護與排除；支援要定義優先級、初次回應、持續更新與升級窗口。品質不能只用「準確」，應連到公司的代表案例、重大錯誤與人工覆核。容量要包含配額、並發、token／檔案上限、限流與臨時擴容流程。
不要直接複製別人的百分比。先用AI 評測指標資料庫選出會改變 go／no-go 的品質、安全、營運與成本指標，再依工作影響和人工替代能力設定公司門檻。契約承諾、供應商 dashboard 與公司端監控三者要能對帳。
模型、條款與資料處理變更都要通知
變更範圍應包含模型／別名、端點、輸出格式、內容政策、配額、價格、資料用途、保存、區域、子處理者、關鍵相依與安全控制。通知要有可聯絡窗口、最少內容、提前期或緊急例外、受影響版本、測試期、舊版支援和客戶選項。只有更新網頁、不指出影響，無法支持內部重驗。
公司收到通知後，也要有自己的路由：供應商 Owner 建立變更單，技術固定版本與影響範圍，品質重跑代表集，資料與資安核對設定，業務決定限縮、延後或接受。可用AI 系統變更資料庫與AI 變更影響分析器建立重測和回復起點。
事故通知不能只涵蓋已確認外洩
先定義會影響公司的事件：未授權存取、資料用途或區域錯誤、跨租戶、模型／服務重大異常、關鍵子處理者中斷、未預期版本變更、錯誤外部動作與重要證據不可得。初報可以是不完整但及時的事實，後續再更新影響、範圍、暫時措施、客戶動作、證據與根因；不要要求供應商在完全調查前才通知。
把 24x7 升級、雙方窗口、保全、停用、撤權、資料刪除、更正與復原放進桌上演練。通知任何主管機關或受影響者的義務需由有權法律、隱私與事件角色依事實判斷，不能交給本站工具或供應商單方決定。可先從AI 事故類型資料庫挑選適用情境。
SLA 失敗後要有營運選項
服務點數不是唯一補救。依工作重要性，可要求問題升級、容量調整、替代端點、資料匯出、延後重大變更、終止協助或其他協議選項；公司端則需能切到人工、規則、唯讀或替代模型。補救要對應真實損害與恢復需求，仍須由採購與法務依談判條件判斷。
演練限流、逾時、空回應、模型撤除和主要區域中斷，觀察 queue、重試、冪等、人工負荷、恢復時間與復原後對帳。若替代供應商共用同一上游模型或雲端，不能假定它是真正獨立備援。
退場能力要在簽約前測
列出可匯出的原始資料、提示、系統政策、RAG 文件與中繼資料、評測案例、模型／微調工件、日誌、權限、工作流與未完成 queue。確認格式、API、費用、速率、唯讀期、終止協助、舊憑證撤銷、刪除完成與備份例外。合成專案至少做一次完整匯出與替代流程導入，不能只看文件說「支援 CSV」。
用AI 供應商盡職調查資料庫檢查契約與退場四個面向，再用AI 供應商評估規劃器產生變更、事故、連續性與移轉清單。若退場成本或殘留未知，應寫入風險台帳並限制鎖定，而不是假定未來再處理。
建立契約、設定、測試三方對照表
每項重要承諾記錄契約依據、產品設定、公司監控／測試、Owner、缺口、補救與重驗觸發。續約前重新核對實際方案、模型、區域、子處理者、資料用途、事故與已發生 SLA 差異。這份對照表不是供應商評分或合規證書，而是讓業務、採購、法務、技術與事件團隊在同一個可驗證事實上決策。