導入 AI 前先想好:你的資料要去哪裡?
導入 AI 的討論裡,資料隱私常常是最後才被想起的那題——通常是系統都快上線了,才有人問一句「欸,客戶資料這樣丟給 AI 沒問題嗎?」這個順序是反的。資料流向應該在選型之前就想清楚,因為它會直接刪掉某些選項、改變某些架構,事後補救的成本比事前規劃高一個數量級。
我們自己經營會員制電商和訂閱制 AI 產品,手上有真實的客戶資料,也真實地把 LLM 用在每天的營運裡。這篇是寫給決策者看的檢查清單——不需要技術背景,但每一題都該有答案再簽名。
第一題:資料到底流去哪裡?
把 AI 功能的資料路徑畫出來:資料從你的系統出發,經過哪些服務、落在哪個國家的機房、誰看得到。三個常見的盲點:
- 「用 AI」不等於「資料給 AI 公司訓練」:主流模型商的企業 API 方案,預設不拿你的資料訓練模型——但免費版、個人版的網頁工具就未必。同仁自己把客戶名單貼進免費聊天工具,是最常見的實際外洩路徑,比 API 串接危險得多。先發內部規範,比先做系統重要。
- 中間層也是流向:你用的 SaaS 工具如果「內建 AI 功能」,你的資料就多經過了一手。問清楚它們背後接誰、合約怎麼寫。
- 留存政策要看文件,不要聽業務講:API 資料保留多久、多久後刪除、有沒有零留存選項,各家條款不同,而且會改版。把當下的條款版本存檔,列入年度覆核。
第二題:哪些資料根本不該送出去?
比「送去哪」更前面的問題是「該不該送」。我們的原則是資料最小化:模型只拿到完成任務所需的最小資料集。實務上三個手法:
- 去識別化:客服對話進模型前,把姓名、電話、地址、身分證字號、信用卡號用程式遮罩掉,換成代號。回覆生成後再由系統換回——模型自始至終沒看過真實個資。這是工程上不難、效益極大的一步。
- 欄位白名單:不要圖方便把整筆客戶資料丟給模型,列出任務真正需要的欄位,其他一律不送。分析購買行為不需要知道客戶住哪。
- 分級處理:把資料分成「可出境」「去識別化後可用」「絕不離開自家系統」三級,寫成文件,讓每個 AI 專案開工前先對照。
資料隱私的第一原則不是「保護送出去的資料」,而是「不送出去就不用保護」。
第三題:法遵和承諾,你對得上嗎?
台灣的個資法要求蒐集個資時明確告知利用方式——你當初的隱私權政策,涵蓋「將資料提供給 AI 服務處理」嗎?多數公司的政策是好幾年前的版本,這條對不上。該做的事:更新隱私權政策、確認跨境傳輸的告知義務、如果服務對象含歐盟用戶還有 GDPR 的資料處理協議(DPA)要簽。這些不是工程問題,是文件問題,但罰單是真的。
另外一個容易被忽略的角落:AI 產生的資料也是資料。對話記錄、模型輸出、嵌入向量資料庫——這些衍生資料存哪裡、誰能查、留多久,同樣要納入管理。很多團隊把原始資料鎖得很緊,卻讓包含客戶資訊的 AI 對話記錄躺在沒人管的日誌裡。
決策者的一頁檢查清單
簽核任何 AI 專案前,確認這五件事都有白紙黑字的答案:一、資料流向圖(經過哪些服務、落地哪裡);二、模型商的訓練使用與留存條款版本;三、去識別化與欄位白名單的實作說明;四、隱私權政策是否涵蓋此利用方式;五、內部規範是否禁止同仁把客戶資料貼進個人版 AI 工具。五題都答得出來,你的 AI 專案在隱私這關就贏過市場上大多數。
這些檢查不是為了阻止你用 AI——我們自己用得很兇——而是讓你用得安穩、用得長久。如果想找人一起把資料架構和 AI 導入一次設計對,歡迎參考 AI 應用開發服務,或直接 來聊聊;導入前的整體思路,也可以先讀 企業導入 AI 的第一步。
這類問題,我們每天都在自己的產品上解
免費 30 分鐘線上諮詢・先釐清方向,不推銷・一個工作天內回覆