企業 AI 治理清單，是企業在同時導入多家 AI 服務時，用來逐項檢查金鑰發放、模型權限、資料邊界與預算歸帳是否到位的檢核工具，服務對象是平台團隊、資安法務，以及所有要為 AI 費用簽字的人。
先講結論：治理的最小單位是「專案」。金鑰掛在專案上、預算掛在專案上、每一筆請求紀錄也掛在專案上——只要一專案一金鑰成立，下面 12 個檢查項就有一半會自動成立。清單分成四組，依「先止血、再上軌道」排序，可以直接帶進導入會議逐條打勾；想先看費用端怎麼讀，可搭配怎麼讀懂 AI 帳單的三層讀法一起看。
一、金鑰與身分
1. 一個專案一把金鑰——金鑰跟著專案走，不跟著人走
同事離職或轉組時，收回的是那個專案的權限，而不是急著更換全公司共用的鑰匙。共用金鑰是治理裡最貴的技術債：出事時你只知道「有人」，不知道「是誰」。
2. 金鑰只顯示一次，並集中保管——可停用、可回查
發出去的金鑰要能隨時停用；停用之後，還要能從請求紀錄回頭確認它曾經服務哪些系統、影響範圍多大。
3. 區分正式與測試環境——測試額度低到燒完也不心疼
測試金鑰的額度上限，應該低到任何人誤用都不會變成月底的驚嚇。正式金鑰則走發放流程，留下核可紀錄。
二、模型與資料邊界
4. 建立模型白名單——換模型是決策，不是改一行程式碼
不是每個專案都需要最強的模型。白名單讓「換模型」成為需要說明理由的決策；平台上有哪些模型可選、各自的計價模式，可以先看模型清單。
5. 定義資料分級——工程師不該每次自行判斷
哪些資料可以送進外部模型、哪些必須先去識別化，寫成一頁文件。參考架構可以對照 NIST 的 AI 風險管理框架，把分級落到欄位層級。
6. 記錄各家服務的資料保留政策——集中在同一份文件
法務與資安要查的時候，答案不應該躺在某個人的信箱裡。
三、預算與歸帳
7. 在專案層級設定預算上限——先告警、再截斷
超標的第一次通知，不應該是月底的帳單。
8. 保留逐請求紀錄——回答「這筆錢是誰、為了什麼花的」
每一筆呼叫都對應到專案、金鑰、模型與 token 數，費用才有辦法稽核。欄位細節可見用量與費用文件。
9. 每月以同一種單位對帳——看趨勢，不只看總額
把各家服務的用量換算成同一種單位（例如點數），趨勢比絕對數字更早暴露問題。
四、流程與稽核
10. 新服務的接入流程標準化——多一家服務只是多一列設定
評估、白名單、金鑰、預算四步走完才上線，而不是誰先申請到帳號誰先用。
11. 建立事件應變劇本——金鑰外洩時知道先關哪裡
停用金鑰、回查紀錄、換發金鑰三步，寫成劇本並演練一次。
12. 每季盤點與權限回收——治理是週期，不是一次性專案
每季重跑一次盤點：哪些專案還活著、哪些金鑰三十天沒有流量、哪些權限可以收回。
依企業規模怎麼套用
10 人以下：先做第 1、7、8 項
小團隊不需要委員會，只需要專案金鑰、預算上限與逐請求紀錄——三件事都是設定，不是流程。
50 到 200 人：補上白名單與資料分級
跨部門用量開始分化，第 4、5 項讓「誰能用什麼模型」有據可查。
500 人以上：流程與稽核全上
第 10 到 12 項成為重點，治理從設定升級為週期性制度，並納入內部稽核範圍。
依產業情境的三種導入場景
軟體與網路業：速度優先，靠預設值治理
用測試環境低額度加上正式環境白名單，讓實驗跑得快、上線守得穩。
金融與法遵敏感產業：資料邊界先行
第 5、6 項先做滿，再逐步開放模型使用範圍；每筆請求可稽核，是內外部稽核的共同語言。
製造與客服現場：用量歸帳決定成敗
大量重複性請求讓成本歸屬特別重要，第 8、9 項直接決定 AI 預算能不能續編。
更現代的做法：把清單變成系統的預設值
以上 12 項，傳統做法是寫成規章、靠人執行；更現代的做法是讓治理平台把它們變成預設值。以 ATP Token 為例：組織、工作區到專案的階層本身就是第 1 項；專案金鑰天生帶白名單與額度，涵蓋第 4、7 項；每筆請求自動寫入紀錄，第 8、9 項不需要任何人記得去做。介面相容 OpenAI、Anthropic 與 Gemini 格式，接入只需更換 base_url 與金鑰。
延伸閱讀
治理做得好的樣子是安靜的：實驗照跑、帳單看得懂、稽核有得查。從盤點開始，把金鑰、白名單與預算收進同一個管理平面，剩下的交給預設值。