企業 AI 資安檢查清單:資料、模型、權限與稽核的 5 大控制點

去年底我們幫一家中型壽險公司做 AI 上線前的資安體檢。他們的核保 Copilot 做得很漂亮,Demo 那天連法遵長都點頭。我們接手第一件事不是看模型,是看它能讀到哪些資料。結果發現:那顆 RAG 向量庫,把全公司的保單掃進去建索引時,連含身分證字號、病歷摘要的欄位一起吃了進去,而且任何有帳號的內勤,問對問題都調得出來。系統沒壞。是沒人畫過那條線。

這就是我們反覆看到的模式。企業導入 AI 時,大家把心力放在「準不準」,卻很少有人系統性檢查「安不安全」。所以我們把踩過的雷,整理成一份可勾選的企業 AI 資安檢查清單。它不是理論框架,是我們每次進場前真的會逐條問客戶的東西,分成五個控制點:資料、模型與 prompt、權限、稽核、供應鏈。

這份企業 AI 資安檢查清單在檢查什麼

先給一個可以直接引用的定義:企業 AI 資安,指的是在資料進入模型、模型產生輸出、輸出被人或系統採用的整條鏈路上,確保機密不外洩、權限不越界、行為可追溯的一套控制。它不等於買一個「安全的模型」,而是把控制點鋪在你自己的資料與流程上。

下面這張表是五大控制點的自檢重點,你可以直接拿去對照現況。

資料分級與模型 prompt:守住入口與出口

第一關是資料分級,也是最多人跳過的一關。做法很土,但有效:在資料進 AI 之前,先把欄位分成公開、內部、機密、個資四級,機密與個資要嘛脫敏、要嘛根本不進索引。台灣落地時特別要留意《個人資料保護法》對特種個資(病歷、健康檢查、犯罪前科)的規範,金融業還疊了主管機關的委外與雲端規範。我們的原則是:能不進模型的敏感資料,就不要進;非進不可的,做欄位級遮罩。

第二關是模型與 prompt 風險。這裡最現實的威脅是 prompt injection——使用者(或被污染的文件)用一句話,誘導模型吐出它不該說的內容,或執行不該做的動作。檢查點有三:使用者輸入與系統指令要在結構上隔離、模型的輸出在寫回資料庫或觸發動作前要過一層校驗、Agentic 工作流的每個工具呼叫都要有白名單。我們寧可讓 Agent 少幾個能力,也不讓它在沒有護欄的情況下直接動生產系統。

權限、稽核與供應鏈:讓行為可控、可查、可追

第三關,存取控管。這是開頭那家壽險公司踩的雷:AI 用一組高權限服務帳號讀所有資料,於是使用者本來看不到的東西,透過 AI 一問就繞過去了。正確做法是讓 AI 的資料存取「繼承使用者身分」——你在原系統看不到的資料,AI 幫你查也查不到。這在 RAG 系統要靠 document-level 的權限過濾,實作麻煩,但這是機密外洩與否的分水嶺。

第四關,稽核軌跡。很多團隊只記了 API 呼叫次數,出事時完全還原不了現場。我們建議至少留存:提問者身分、時間、輸入內容、檢索到的來源文件、模型輸出、以及後續被採用與否。這不只是為了查資安事件,金融、醫療產業被主管機關稽核時,「AI 為什麼給出這個建議」是遲早要回答的問題。留好軌跡,是把未來的麻煩先付清。

第五關,供應鏈。你用的每一個第三方模型、每一個外掛,都是一條資料出口。要確認的很具體:資料會不會被用於訓練、資料落地在哪個地區、合約有沒有 DPA、模型供應商的資安認證是否齊全。台灣企業常忽略跨境傳輸這條,尤其把資料送到境外 API 時,個資法的告知與同意義務不會因為「這是 AI」就消失。

這五關逐條走完,你會發現多數風險不在模型本身,而在它跟你資料、流程的接縫處。我們在 Tenten 做 FDE 前線部署時,資安檢查不是上線後補的文件,而是工程師進場第一週就跟業務流程一起畫的線——因為 Demo 再漂亮,一旦洩了一筆病歷,那個專案就結束了。