AI 供應商安全證據怎麼看？文件、設定、測試與紅旗
企業評估 AI 供應商時，很容易收到一疊政策、認證與信任中心連結，最後卻仍答不出：這些資料是否涵蓋所買的產品、方案、區域與模型？公司租戶現在的設定是否相同？控制遇到跨租戶、撤權、限流或版本變更時真的有效嗎？採購證據的重點不是文件越多，而是每項主張能連到實際範圍、設定與測試結果。
NIST SP 1326 將 ICT 供應商盡職調查描述為蒐集與分析相關資訊，以支持取得或持續使用的決定，並提出所有權與控制、來源、韌性、基礎資安實務及供應鏈層級等面向。NIST SP 800-161 Rev. 1 則說明科技供應鏈的識別、評估與風險處理。這些是可裁剪的參考，不代表每家台灣企業都受相同要求，也不會替公司作成採購、法律或資安結論。
先確認文件適用哪個產品與期間
每份證書、稽核報告、滲透測試摘要或安全白皮書，都要記錄法人、產品、服務範圍、區域、方案、模型與涵蓋期間。若公司買的是 API，但報告只涵蓋協作 SaaS；或目前模型在報告期間後才加入，文件就只能支持一部分判讀。詢問未涵蓋項目如何補件、何時更新，以及重大缺口如何通知。
不要把「有認證」直接改寫成「產品安全」。證書可支持管理制度或特定控制在指定範圍受過評估，但不能證明客戶自己的提示、RAG、權限與 Agent 工具已正確設計。可先用AI 供應商盡職調查資料庫逐項記錄證據範圍，再把未知項目列成限制、補件或停止條件。
文件、設定與測試要形成三層證據
文件回答供應商「怎麼說、怎麼設計」；管理台匯出、API 回應與契約附件回答「公司實際買到、啟用什麼」；失敗案例測試回答「控制在實際條件下是否工作」。例如資料不作訓練的政策，仍需核對目前租戶、方案、區域與端點的設定；租戶隔離的架構聲明，仍需用合成租戶測搜尋、分享、快取、匯出與撤權。
英國 NCSC 的安全 AI 開發指引 建議在生命週期中評估與監測供應鏈，並從可驗證第三方取得有安全性與文件的模型、資料、函式庫、框架和 API。對公司而言，實務做法是為每項高影響主張指定可接受的文件、可核對設定與最低測試，而不是只在試算表填「是」。
用實際租戶與方案核對
相同品牌的免費版、企業版、區域端點與特殊功能可能有不同保存、日誌、金鑰、SSO 或資料使用選項。把供應商回答綁定帳戶 ID、方案、地區、端點與核對日期；重要設定以機器可讀匯出、API 或帶版本紀錄保存，不能只截一張無日期畫面。再用AI 稽核證據資料庫建立證據 ID、Owner、位置、保護方式與過期條件。
測試只用合成或已授權資料，不把真實 token、個資或機密貼進客服工單。跨租戶、權限、秘密、錯誤訊息和刪除案例要在有權環境執行，先寫明停止條件。若要規劃正常、邊界與安全案例，可從AI 測試案例庫挑選，再依公司系統裁剪。
紅旗不是自動淘汰，但必須改變決策
常見紅旗包括：文件無日期或版本、報告範圍不含所購產品、只用行銷頁回答資料用途、無法說明子處理者、重大變更不通知、客戶不能做合理測試、事件窗口不可聯絡，以及刪除或匯出只有口頭承諾。紅旗不一定等於立即淘汰；它可能導向補件、縮小資料與權限、只做 read-only PoC、加入人工批准、提高監控，或選擇替代方案。
最危險的做法是把未知填成低風險。未知就是缺口，應指定 Owner、期限、補件方式與在未解決前的限制。可用AI 風險初篩工具先辨識影響與資料範圍，再用AI 供應商評估規劃器產生證據、測試與停止條件起點。
把證據接到批准與定期重驗
採購決定要記錄所評估版本、用途、資料、缺口、補償控制、批准條件與重新審查觸發。供應商、模型別名、區域、子處理者、資料用途、契約、方案或事故狀態改變，都可能讓舊證據失效。不要只設年度提醒；重大變更通知、異常監控與續約也要觸發重驗。
最後由業務、採購、技術、資料、資安、隱私／法務與有權風險角色依實際情境判斷。這份方法不是法律意見、合規或資安認證，也不是供應商排名；它的價值是讓「我們相信」變成「我們知道哪些已被證明、哪些仍未知、因此採取什麼限制」。
採購會議可直接帶走的清單
- 每份證據的產品、方案、區域、模型、期間與例外是什麼？
- 哪些主張已核對實際租戶設定，誰在何時核對？
- 哪些控制已用合成失敗案例測過，結果與剩餘缺口是什麼？
- 哪些未知會限制資料、權限、自動化或正式上線？
- 什麼變更會讓證據過期，供應商如何通知，公司由誰重驗？
搭配既有的AI 供應商評估清單確認訪談範圍，再用可驗證證據完成採購記錄。