「我已經刪掉那段資料了，為什麼還需要再問模型？」這句話很合理。對一般軟體來說，刪除一筆紀錄常被理解成資料從儲存處消失；對已用資料訓練的模型來說，問題還多了一層：原始檔案不見了，過去的訓練是否仍可能在模型裡留下影響？
我做 AI 治理時，很在意產品對使用者用了哪個動詞。「刪除」「停止使用」「不再收集」「撤回同意」聽起來相近，涵蓋的範圍卻未必相同。如果介面只給一個按鈕，再用一句「已完成」結案，使用者沒有辦法知道自己的選擇究竟改變了什麼。
先定義問題：你想撤回的是哪一段使用？
假設有人曾把自己的文字交給一項服務，後來不希望它再用於訓練。這裡的「假設」很重要：以下不是我本人遇到的事件，也不指向特定產品。這個請求至少可能涉及三件事：停止未來收集、移除仍被保管的原始文字，以及處理已使用那些文字訓練的模型。完成第一件事，不代表後兩件事自動完成。
也因此，討論能否「忘記」之前，應先把資料流畫出來。資料當初從哪個入口進來？經過哪些處理？是否進入訓練資料集？哪些模型版本用過它？是否還留在其他備份或衍生資料中？如果提供服務的人答不出這些問題，承諾「一鍵撤回」就缺少可檢驗的前提。
已知事實：刪掉檔案與移除模型影響是不同工作
模型訓練會依資料調整參數；對已訓練的模型，單純刪除原始紀錄，不能據此推定那筆資料的影響也已消失。研究上有「機器遺忘」這類方法，目標是移除特定訓練資料對模型的影響。有些路徑可能涉及重新訓練，有些則嘗試以較低成本處理；方法、驗證方式與可達到的程度都需要說清楚。這不是一句「我們已刪除」可以代替的技術判斷。
反過來說，也不能把困難講成永遠做不到。能採取什麼措施，取決於系統如何設計、資料與模型版本是否可追蹤，以及業者願意為撤回請求預留多少能力。我不認為使用者必須懂模型參數，才有資格問自己的資料去了哪裡；需要把限制說明白的人，是設計與營運系統的一方。
我的推論：撤回權需要一張可核對的處理清單
如果我是提出請求的人，我會想收到一份不靠行銷語言的回覆：哪一類原始資料已移除，哪一類資料將不再納入後續訓練，哪些既有模型版本受到影響，業者對它們採取了什麼處置，還有哪些範圍暫時無法確認。若答案是「目前無法完全移除既有模型中的影響」，就直接寫出這個限制，以及後續處理安排。
這種說明不必公開內部機密，也不必假裝每個請求都能立刻完成。它需要的是責任邊界。處理日期、適用版本、驗證方法、申訴窗口，都是使用者可以核對的資訊。若業者只能提供「已受理」的畫面，卻無法區分受理與完成，那個按鈕給人的安全感就超過了它實際能交付的內容。
風險：模糊承諾會把不確定性留給最沒有權力的人
撤回請求常被當成一個客服工單；但當資料已進入訓練流程，真正的問題橫跨產品、資料管理與模型管理。每個團隊都完成自己手上的一步，仍可能沒有人對整體結果負責。使用者看到的是同一項服務，沒有義務替組織內部的分工補上缺口。
我也會警惕另一種做法：把技術限制寫得過於抽象，讓人以為任何要求都是不合理的。困難可以被誠實描述，也應該促使設計改變。未來的系統若希望使用者相信「可撤回」，就要在資料進入訓練前安排追蹤、版本紀錄與處理程序，而不是等請求進來後才發現無從查起。
結論：真正的同意，包含知道退出後會發生什麼
我不會要求技術提供做不到的保證。但我會要求每一個「刪除完成」都對應清楚的範圍，每一個「不能處理」都有可檢驗的理由。願意說出限制，並設計讓限制逐步縮小的流程，比給一個漂亮卻含糊的承諾更值得信任。
資料交出去之前，我們常被問是否同意；資料想收回時，卻很少有人把流程解釋得同樣仔細。若退出的後果不透明，最初那個勾選也很難算得上充分知情。對我來說，這是 AI 訓練最基本的治理問題：人可以改變主意，系統也必須能誠實交代，改變主意之後究竟發生了什麼。