先把政策文字改寫成可判定的條件
「個人資料只保留於業務所需期間」是合理的政策語句，卻不是管線能執行的規則。工程端需要知道資料屬於哪一類、從哪個事件開始計時、保存多久、什麼條件會暫停刪除，以及到期後要刪除、匿名化或封存。若這些欄位沒有明確定義，不同系統通常會各自解讀，最後出現 CRM 已刪除、資料倉儲仍保留、RAG 索引還能搜尋的情況。
可執行規則應採用機器可讀的形式，例如版本化設定檔或治理資料表，而不是把天數寫死在程式碼中。每條規則至少要包含資料分類、適用範圍、保留起點、期限、處置方式、例外條件與政策版本。保留起點尤其重要：帳戶建立日、交易完成日、合約終止日與最後互動日會產生完全不同的刪除結果。
建立涵蓋衍生資料的生命週期地圖
盤點不能只列正式資料庫。資料在整合流程中會被複製到訊息佇列、物件儲存、分析表、搜尋索引、向量資料庫、快取、日誌與備份。AI 助理還可能把文件切成片段並產生 embedding；即使原始檔已刪除，片段文字、摘要、提示紀錄或向量中繼資料仍可能保留可識別內容。
實務上可為每種資料建立 lineage 與處置清單，並指定負責系統。至少回答以下問題：
- 來源：資料由使用者、LINE、ERP、CRM、IoT 裝置或外部 API 的哪個事件產生？
- 識別鍵：刪除要求要用客戶編號、帳戶 ID、裝置 ID，還是跨系統對照鍵傳播？
- 副本：哪些資料集、索引、快取、匯出檔及測試環境持有完整或部分內容？
- 衍生物：哪些報表、特徵、摘要或 embedding 可以回推到原始主體？
- 處置：到期時要硬刪除、去識別化、降低精度、移至冷儲存，或因法定義務保留？
在寫入時攜帶生命週期，在到期時集中執行
穩定的設計不是每天用大型查詢猜測哪些資料應刪除，而是在資料進入管線時就附上分類、政策版本、保留起點與 expires_at。下游轉換必須繼承這些欄位；若多筆來源合併，通常應採用最嚴格的到期條件，除非資料擁有者核准另一種規則。缺少分類或到期時間的資料應進入隔離區或觸發告警，不宜默認永久保存。
執行層可依儲存特性選擇 TTL、分割區淘汰、批次刪除、事件驅動 tombstone 或匿名化作業。高流量事件資料適合依日期分割並整批淘汰；需要逐一處理刪除請求的客戶資料，則需要穩定的主體識別鍵與冪等工作。管線重跑時不得讓舊資料獲得新的到期日，也不能因下游暫時失敗便將刪除事件視為完成。
刪除是一段流程，不是一個 SQL 指令
跨系統刪除應被視為有狀態的工作流程：接受請求、解析身分、找出副本、執行處置、驗證結果，再產生不可竄改的稽核紀錄。每個步驟都要能重試，並以 request_id 或 subject_id 維持冪等性。若某個 SaaS 或離線系統無法即時刪除，工作狀態應保持待處理，而不是因主要資料庫成功就回報全部完成。
備份需要不同做法。任意修改歷史備份往往會破壞完整性或復原能力，因此政策可明訂備份自然到期時間、存取限制，以及還原後必須重新套用 tombstone 的程序。法律保全也不應直接覆寫原規則；較安全的方式是記錄保全範圍、依據、核准者與解除條件，並在保全結束後重新計算應有的處置。
用證據驗證規則，而不是相信排程有執行
監控不能只確認刪除排程成功啟動。團隊還要追蹤待刪除佇列的最老項目、各系統失敗與重試狀態、缺少 expires_at 的資料量、政策版本分布，以及已到期但仍可被查詢的紀錄。對 RAG 系統，驗證應同時涵蓋原始文件、文字片段、向量索引、引用快取與對話紀錄。
上線前可使用合成主體做端到端測試：讓一組可辨識但不含真實個資的資料走過所有整合，再觸發到期或刪除請求，確認每個副本都依規則消失或匿名化。政策變更則應像資料庫遷移一樣進行影響分析、版本審查、預演與回滾設計。若組織需要整合團隊協助，最有價值的交付物不是另一份政策文件，而是一套能測試、監控並提出完成證據的生命週期控制機制。