產品團隊要怎麼設計「可審計的同意」，而不只是偷偷改掉文案？

阿哲 (A-Zhe) · 2026-05-08T11:26:15.315383+00:00

最近在看 Chrome 跟 Gemini Nano 的事，有個地方讓我蠻不舒服的。事情大概是：Chromium 的設定頁面之前有一行描述，說 on-device AI 的推理「不會把資料送到 Google 伺服器」——後來這段描述被悄悄拿掉了，頁面繼續存在，功能繼續跑，但那句保證就不見了。而且整個過程沒有任何變更通知，changelog 也查不到，就這樣。4GB 的 Gemini Nano 模型已經在使用者電腦上了，當初安裝的時候沒有人明確同意「好，我允許這個模型存在我的裝置」。我做全端，最近剛好在公司導入一個會用到 on-device 推理的功能，所以這件事讓我直接聯想到我們自己的設計。說真的，同意流程這塊我踩過很蠢的坑。我們之前做了一個「設定頁預設開啟，有說明文字」的設計，以為這樣就夠了。結果 user 測試的時候，5 個人裡面有 4 個根本沒看那段說明，直接跳過去。他們事後完全不知道那個功能在背景跑，更不知道有 on-device 這個概念。那段說明文字等於沒有。所以我現在比較懷疑的是：「有說明 = 知情同意」這個假設本身就是錯的。特別是在預設開啟的情況下，使用者的認知路徑根本不是「看說明 → 決定 → 開啟」，而是「功能已經在跑了，除非你去關掉」。這兩個根本是不同的決策框架。 Google 的問題不只是「把那行字拿掉」，而是整個流程沒有辦法被外部驗證。你沒辦法在事後 audit「當初使用者同意的是什麼版本的描述」，因為根本沒有版本記錄。如果描述可以被靜默修改，那「同意」的意義是什麼？我在想一個方式：如果要讓同意流程可審計，至少要把「使用者看到的說明文字版本」跟「使用者的同意時間點」一起存起來。不是只記 consent: true，而是記 consent_at: timestamp, consent_text_hash: xxx。說明文字有任何改動，就要觸發一個重新確認的流程，而不是靜默替換。這在法規上也說得通，GDPR 其實有類似要求，但大部分產品實作的時候都省掉了。問題是這在工程面有代價。如果說明文字改了就要重新 consent，使用者會很煩，轉化率掉，PM 會跳腳。所以實務上大家都傾向「改個字不算 material change」然後繼續沿用舊的 consent record。我目前還沒找到一個既符合「可審計」又不會把用戶搞煩的設計方案。有人在自己的產品上做過 versioned consent 嗎？如果說明文字有改動，你們是怎麼判斷要不要重新讓使用者同意的？有沒有比較具體的 threshold 或決策框架？