電商做 AI 個人化不踩個資紅線:同意管理、資料最小化與跨境傳輸實務

去年有家做美妝訂閱盒的電商找上我們,想上「千人千面」的商品推薦。技術不難,難的是他們法遵長開會第一句話:「我們去年才被檢查過一次。」

這就是台灣電商做 AI 個人化的真實處境。你想用行為資料餵模型、把轉換率再擠高幾個百分點,但個資法、cookie 同意、跨境傳輸這三道關卡,任何一道沒過,罰款和商譽的損失都遠比多賺的那幾趴難看。這篇講的就是電商 AI 個資與個人化的交界:哪裡能踩、哪裡是紅線、以及我們實際幫客戶把系統推上線時,是怎麼把合規做進架構、而不是事後補的。

先分清楚:哪些個人化需要「同意」

不是所有推薦都需要用戶點頭。台灣個資法的邏輯是看「蒐集目的」與「特定性」。把個人化拆成三層,界線會清楚很多。

第一層是站內即時推薦,例如根據當下瀏覽的商品推同類。這通常落在「與當事人有契約或類似關係」的合理利用範圍,風險最低。第二層是跨 session 的行為輪廓,把你三個月的點擊、加購、退貨串成一個 profile,這已經是在建立「特徵剖析」,依《個資法》與國際趨勢(GDPR 第 22 條的自動化決策精神),應該給明確告知與拒絕的機會。第三層最敏感:把第一方資料上傳到 Meta、Google 做 lookalike,或串接第三方 CDP 做身分比對,這是「利用」加「跨境傳輸」的疊加,必須有獨立、可撤回的同意。

很多電商踩雷,是因為把這三層用同一個「我同意隱私政策」的勾選打包處理。一次同意撐全場,在稽核時最站不住腳。

同意管理:把「可撤回」做成系統能力

同意管理平台(CMP)不是裝一個 cookie banner 就結束。真正會被查的是三件事:同意有沒有分顆粒、有沒有時間戳與版本紀錄、以及用戶撤回後系統多久真正停止使用該資料。

我們踩過一個雷值得講:某客戶前端 CMP 做得很漂亮,用戶撤回同意,banner 也正確更新,但後端的推薦模型仍在用那份歷史特徵跑了快六週,因為 ETL 排程沒有把「撤回」當成一個事件回灌。合規稽核不看你前端多美,看的是資料流的實際終點。撤回必須是一條能穿透到模型特徵層的訊號,這是架構決定,不是設定選項。

資料最小化:模型不需要你以為它需要的一切

工程師的直覺是資料越多越好,但個資法的「比例原則」剛好相反:只蒐集達成目的所必需的。這對 AI 個人化其實是雙贏,因為多數敏感欄位對轉換預測的邊際貢獻很低。

實務上我們會做三件事。先做特徵層的假名化,用戶 ID 進模型前先轉成不可逆的雜湊代號,讓資料科學團隊拿不到真實身分。再來是按目的切資料表,推薦模型碰不到金流與身分證字號,這些留在另一個權限域。最後是設 TTL,行為資料放九十天滾動窗口,舊資料自動退場,既降風險也讓模型更貼近近期偏好。

一個反直覺的收穫:那家美妝客戶把輸入特徵從四十幾個砍到十九個、剔掉所有可直接識別身分的欄位後,推薦準確度只掉了不到一個百分點,但法遵長終於敢簽字上線。合規和效果不是零和,前提是你願意真的去量,而不是預設「資料全留著比較安全」。

跨境傳輸:預設路徑而非事後補件

台灣電商的資料很少真的留在台灣。你的 CDP 在新加坡、推薦 API 走美國、廣告受眾同步到 Meta 的全球節點,每一次都是跨境傳輸。個資法第 21 條允許中央目的事業主管機關限制跨境傳輸,零售與電商雖尚未有全面禁令,但「有沒有做風險評估與告知」會是稽核重點。

務實的順序是:先盤點資料實際流向(通常盤完會嚇一跳),把可以留在本地或亞太區的工作負載留下,真的要出境的,在隱私政策裡具體列出接收國與對象,而不是含糊寫「可能傳輸至海外」。若走 Meta、Google 的受眾比對,優先用他們的雜湊上傳與資料淨室(clean room)機制,讓明碼個資不出你家門。

我們的做法一向是把這些關卡在系統設計時就接進資料管線,而不是等模型跑起來才回頭補同意與稽核軌跡。Demo 那天推薦準得漂亮不算數,能撐過一次個資稽核、法遵長敢按下上線鍵、而且用戶真的在用,才算真的上線。