- 先確認資料落地位置與是否被用於訓練
- 個資最小化：能遮罩就不要傳完整欄位
- 存取紀錄要能回答「誰、什麼時候、看了什麼」
- 地端與雲端不是二選一，可依資料層級混合部署
先問清楚，再簽約
資安團隊擋下 AI 導入案，通常不是因為反對 AI，而是因為提案裡沒有寫清楚資料會流到哪裡。以下六件事，建議在選型階段就白紙黑字寫下來。
一、資料落在哪個地理位置
不同的服務商、不同的方案，資料處理的所在地可能不同。對於受金管會、個資法或客戶合約約束的產業，這一項通常是硬條件。要確認的不只是「主要處理位置」，還包括備援、記錄檔與人工審核流程各自在哪裡。
二、資料會不會被用於模型訓練
企業方案通常會承諾不將輸入內容用於訓練，但個人方案與免費方案往往不同。實務上最大的風險來源不是公司採購的系統，而是員工私下用個人帳號把內部文件貼上去。
因應方式有兩層：技術上提供合規的內部入口，讓員工不需要繞道；管理上把「不得將 L2 以上資料輸入未授權的外部服務」寫進資訊安全規範，並實際說明什麼算 L2。
禁止員工使用 AI 不會降低風險，只會讓使用行為變得看不見。可行的路線是提供一個好用到不需要繞道的內部管道。
三、個資最小化怎麼落實
大部分業務場景其實不需要完整的個資欄位。Agent 需要知道「這位客戶是三年以上的舊客、買過三次、上次反映過出貨慢」，不需要知道他的身分證字號與完整住址。
實作上有三種常見手法：欄位遮罩（只留後三碼）、代號替換（以內部 ID 取代姓名）、聚合呈現（只給統計結果不給名單）。導入時應逐一場景確認採用哪一種，而不是全系統一刀切。
四、存取紀錄要留到什麼程度
稽核時真正會被問到的問題是：某一天某一筆資料，是誰、透過哪一個 Agent、為了什麼任務被讀取的。要能回答，紀錄至少要包含：時間、觸發者（人或 Agent）、檢索範圍、命中的文件、以及該次任務的識別碼。
保存期限則依產業規範而定，通常一到三年。重點是導入時就設計進去，事後補建的難度極高。
五、地端還是雲端
這題常被當成二選一，但實務上多半是混合。合理的切法是依資料層級決定：
- L1 公開資料：雲端處理，效能與成本最佳。
- L2 內部作業：雲端企業方案，搭配合約與區域限制。
- L3 客戶資料：遮罩後上雲，或在內網處理。
- L4 營業秘密：地端部署，必要時完全離線，資料不出廠區。
高機密製造業與金融業常見的做法是核心資料走地端小模型，一般文書與對外內容走雲端大模型，兩者之間有明確的資料閘門。
六、出事時的處理流程
最後一項最容易被跳過：如果 AI 輸出了不該輸出的內容，或有人發現越權存取，處理流程是什麼？誰負責通報？多久之內？要不要通知當事人？
把這份流程寫下來的價值不只在於合規。它會逼團隊在導入前就想清楚哪些環節可能出錯，而這通常會回頭改善系統設計本身。
寫下來，比想清楚更重要
以上六項，每一項的答案都不需要很長，但一定要有書面版本，並且讓資安、法務與業務單位都看過。導入 AI 真正的阻力很少來自技術，多半來自沒有人敢在沒有文件的情況下承擔責任。
先分清楚三種不同的風險
資安討論之所以常常卡住，是因為大家把三種性質完全不同的風險混在一起講。拆開之後，每一種的解法其實都不一樣。
一、資料外洩風險
公司的資料流到了不該去的地方。這是最常被討論的，解法偏技術與合約：資料落地位置、是否用於訓練、傳輸與儲存加密、廠商的資安認證。
二、輸出錯誤風險
AI 給出了錯的答案，而有人照著做了。這跟資料外洩無關，但實務上造成的損失往往更大——報錯價、答錯保固條件、給錯法規解釋。解法是引用出處、拒答機制與人工確認關卡。
三、權責不清風險
出事之後沒有人說得清楚是誰的責任。這是管理問題，解法是流程文件與存取紀錄。很多公司在前兩項做得不錯，卡在這一項，因為沒有人願意在沒有紀錄的情況下承擔責任。
導入前把這三種分開列，你會發現需要說服的對象、需要的證據、需要的解法都不同。混在一起談，通常的結果是「那我們先不要用」。
資料分級之後，權限怎麼設計
分級只是第一步，真正影響安全性的是權限怎麼實作。這裡有一個關鍵的架構選擇：權限是做在提示詞層，還是做在檢索層。
提示詞層的做法是：把所有資料都給模型，然後告訴它「不要說出 L3 以上的內容」。這種設計把安全性寄託在模型的服從度上，而模型的服從度不是安全機制——只要有人用對的問法，它就可能說出來。
檢索層的做法是：客服 Agent 的檢索範圍在技術上就只包含 L1 的索引，L3 的內容它根本取不到，不需要「忍住不說」。這種設計的差別不只是安全，還有可稽核性——你只要檢查那個 Agent 的檢索紀錄，就能證明它從來沒有碰過那些資料。
判斷一套系統的權限設計是否可靠，問一個問題就夠：如果模型完全不聽話，它最多能拿到什麼？答案應該是「還是只有它被授權的那些」。
地端部署要先想清楚的事
地端不是把雲端的東西搬進機房那麼簡單。決定走地端之前，以下幾件事要先有答案。
硬體規劃看尖峰不看平均
推論所需的運算資源要用尖峰併發估算。月底結帳、活動檔期、稽核期間的瞬間負載常常是平常的好幾倍，用平均值規劃的結果是關鍵時刻卡住。
模型更新的流程要先設計
隔離環境沒辦法自動更新。模型有新版本、發現漏洞需要修補時，走什麼流程、誰核准、多久做一次——這件事上線後才想，通常會變成長期不更新。
地端不等於比較安全
資料留在自己機房，但如果權限沒設計好、沒有存取紀錄、沒有人負責維護修補，風險不見得比用企業級雲端方案低。地端解決的是資料落地與主控權的問題，不會自動解決其他問題。
混合架構通常最務實
常見的切法是核心資料走地端小模型、一般文書與對外內容走雲端大模型，中間有明確的資料閘門。這樣既滿足法遵要求，又不必為了所有場景都付地端的成本。
員工使用規範怎麼寫才有人遵守
大多數公司的 AI 使用規範寫完之後沒有人看，因為它們長得像法律條文，而且只有禁止事項。可行的規範通常有三個特徵。
- 用實際例子講，不用抽象分類。不要寫「不得輸入營業秘密」，而是寫「不要把成本表、未公開的報價策略、客戶完整名單貼進外部 AI 工具」。員工看得懂具體的東西。
- 同時說明可以做什麼。只有禁止事項的規範會被當成「公司不准用 AI」，然後大家私下用。要明確寫出哪些場景鼓勵使用、內部有哪些合規管道。
- 提供比繞道更方便的選項。這是最關鍵的一點。如果內部管道又慢又難用，規範寫得再嚴都沒有用。降低風險最有效的投資，其實是把內部工具做好用。
出事的時候：一份可以照著跑的流程
事故處理流程建議在導入時就寫好，並且演練過一次。基本骨架如下：
- 發現與通報。誰可以通報、通報給誰、多久之內。要有一個所有人都知道的單一窗口。
- 影響範圍界定。調閱存取紀錄，確認哪些資料被讀取、被誰、在什麼任務下。這一步能不能做得到，完全取決於當初有沒有留紀錄。
- 止血。暫停相關 Agent、收回權限、必要時關閉服務。要事先決定誰有權喊停——這個授權如果不明確，實務上會拖很久。
- 對外處理。是否需要通知當事人、主管機關、客戶，依產業規範與事件性質決定。這一段要法務先擬好模板。
- 回溯改善。事故轉成一則測試案例，加進迴歸測試組，確保同樣的問題不會再發生。
寫下這份流程的價值不只在合規。它會逼團隊在導入前就想清楚哪些環節可能出錯，而這通常會回頭改善系統設計本身——很多潛在問題是在寫這份文件時被發現的，而不是在事故發生時。
給資安團隊的一份提問清單
如果你是要去說服資安或法務的那個人，把下面這幾題準備好，會議會順利很多：資料處理與備援分別在哪個地理位置；輸入內容是否用於模型訓練，合約第幾條寫明；哪些資料層級會進入系統，哪些不會，技術上如何隔離；存取紀錄保存多久，包含哪些欄位；模型版本更新的通知與驗證機制；事故通報的窗口與時限；委外廠商的資安認證與稽核權。
每一題的答案都不需要很長，但都要有書面版本。導入 AI 真正的阻力很少來自技術，多半來自沒有人敢在沒有文件的情況下簽字。
