企業 AI 治理框架怎麼建?從政策、護欄到稽核的落地藍圖

上一季我們去一家保險公司,對方很自豪地打開一份四十頁的「AI 治理框架」簡報。分類清楚、配色漂亮,還引了三個國際標準。我問了一個問題:「上週有位業務把客戶完整病歷貼進公開的聊天機器人,這份框架裡,哪一頁會擋下他?」

全場安靜。那份文件不是治理,是一篇很體面的讀後感。

這是我們踩過最多次的雷:企業把 AI 治理當成合規部門的寫作作業,寫完歸檔,然後現場照樣裸奔。真正的AI 治理框架,是一套讓「誰能用、能用到什麼程度、出事怎麼查」都有明確規則與技術強制力的制度。它不是一份 PDF,而是政策、護欄、稽核三層彼此咬合的系統:政策定義該與不該,護欄在執行當下強制攔截,稽核在事後還原每一次決策。缺任何一層,治理就只是投影片。

第一層:政策,把「該不該」寫成可判斷的句子

政策是地基,但九成的政策失敗在同一件事:寫得太抽象。「員工應審慎使用 AI 並保護公司機密」——這種句子無法判斷任何一個真實情境,等於沒寫。

可執行的政策長這樣。先做資料分級:公開、內部、機密、受規範(個資、病歷、金融交易)四類,每類明確標出「可否進入哪一級的模型」。再做用途分級:內部草稿協助、對外客戶溝通、涉及金額或健康的決策建議,風險遞增,對應的人工複核門檻也遞增。最後把每條規則綁定到一個可被觀察的動作,例如「受規範資料不得進入未簽 DPA 的外部模型」——這句話工程師能直接翻成一條攔截規則,稽核也能直接查有沒有被違反。

一個誠實的取捨:政策越細越安全,但越長越沒人讀。我們的做法是政策文件控制在能一頁看完的核心規則,細節下放到護欄去強制,而不是塞進五十頁讓所有人簽名後遺忘。

第二層:護欄,在執行當下強制,而不是事後道歉

護欄是政策的執行肌肉,也是三層裡最常被跳過的一層,因為它需要真的動工程。政策說「機密不得外流」,護欄要做的是:當那位業務把病歷貼進輸入框的瞬間,系統就偵測到受規範個資、當場遮蔽或攔下,而不是等三個月後在稽核報告裡讀到這件事。

護欄落在幾個位置。輸入端做 PII 偵測與遮蔽、DLP 攔截;模型路由層根據資料分級決定能不能走外部 API,機密資料強制走私有部署;輸出端做敏感內容過濾與幻覺標記;權限層用 RBAC 綁定角色,客服看不到風控模型,實習生調不動生產資料。

回到那家保險公司。我們沒有重寫他們的四十頁簡報,而是先在客服工作流上線一組輸入端遮蔽與外部模型阻斷。上線後兩週,系統攔下十一次原本會外流的個資貼上——這十一次,原本一次都不會有人知道。這才是護欄和政策的差別:一個在事後統計,一個在當下阻止。

第三層:稽核,每一次 AI 決策都要能被還原

如果哪天監理機關、法務或客戶問你「這個 AI 為什麼給了這個建議」,你答得出來嗎?稽核層決定的就是這件事:可還原性。

具體要留三種紀錄:誰在什麼時間、用哪個模型、餵了什麼輸入、拿到什麼輸出(完整 prompt 與 response 留存),以及過程中觸發了哪些護欄。這些日誌要是不可竄改的,而且保存期限要對齊你所在產業的法規要求。光留還不夠,要定期回放:每月抽樣重跑高風險決策、複盤每一次護欄攔截與每一次繞過嘗試。稽核不是為了審判誰,是為了讓下一版政策和護欄有真實數據可以調整——治理是個回饋迴路,不是一次性專案。

三層對照:一張可以照著蓋的藍圖

落地順序:別想一次到位

最後一個常見錯誤,是想一次把全公司所有 AI 應用都治理起來,結果三個月還在開會。別這樣。

挑一個風險最高、又真的有人在用的工作流(通常是客服或知識問答),把三層都做薄薄一層先跑起來:政策只寫這個場景的核心規則,護欄只擋這個場景最致命的洩漏,稽核只留這個場景的完整日誌。跑一個月,拿真實攔截數據回去修政策,再複製到下一個場景。治理框架是長出來的,不是規劃出來的。

我們在 Tenten 做 FDE 時,工程師是直接進場把這三層接進客戶的實際系統,而不是交一份框架文件就走。原因很單純:Demo 那天大家都點頭,但治理有沒有真的在生產線上攔下東西,只有工程師蹲在現場才看得到。