先區分對話紀錄、工作狀態與長期記憶
企業 AI 常把「記憶」當成單一資料表，實際上至少有三種不同用途。對話紀錄保存使用者與模型說過的內容，主要用於追蹤、除錯或稽核；工作狀態保存目前任務所需的暫時資訊，例如案件編號、已選條件與流程進度；長期記憶則保存跨工作階段仍有價值的偏好、角色、授權範圍或經確認的事實。三者若使用同一套保留政策，通常會不是存得太多，就是刪得太早。
工程上的第一個原則，是不要把完整逐字稿直接當作長期記憶。原始對話容易混入個人資料、商業機密、錯誤推論與已失效資訊。較穩健的做法，是在任務結束時抽取候選記憶，再依資料類型、來源、可信度與用途決定是否保存。例如「使用者偏好繁體中文」可以成為可編輯的偏好；「客戶下季將採購某產品」若未經確認，就不應變成永久事實。
用資料分類表決定保存內容與期限
每一類記憶都應有明確目的。若團隊無法說明某欄位將支援哪個功能、由誰使用，以及何時不再需要，就不應預設長期保存。保留期限也不該只看儲存成本，而要同時考慮業務必要性、資料敏感度、更新頻率、法規或契約義務，以及刪除後能否從其他系統重新取得。
- 原始對話：適合短期保存以支援除錯、申訴與品質檢查；若沒有明確需求，應儘早刪除或去識別化。
- 任務摘要：只保留後續流程需要的決策、待辦與引用來源，避免複製整段對話；完成任務後可自動到期。
- 使用者偏好：例如語言、通知方式與常用輸出格式，可保存較久，但必須讓使用者查看、修改與清除。
- 企業知識引用：記錄文件識別碼、版本及權限即可；不要把受控文件內容再次複製到不受控的記憶欄位。
- 上傳檔案與衍生向量：檔案、文字切片、摘要與嵌入向量應共享生命週期，不能只刪原始檔而留下可被檢索的衍生資料。
- 稽核事件：保存誰在何時執行了什麼操作及政策結果，避免在稽核紀錄中重複存放完整敏感內容。
實作時可為每筆記憶附上 purpose、source、owner、sensitivity、created_at、expires_at、legal_hold 與 policy_version 等中繼資料。這些欄位讓排程刪除、權限檢查與政策變更可自動化。期限到期時應由系統執行，而不是等待人工整理；需要延長時，也應留下原因與核准紀錄。
刪除必須涵蓋所有副本與衍生資料
「資料庫顯示已刪除」不代表資料真的消失。一次對話可能同時存在於主資料庫、向量資料庫、物件儲存、搜尋索引、快取、分析管線、應用程式日誌與備份中，也可能已送往外部模型或可觀測性服務。設計階段就要建立資料流清冊，標示每個處理者的保存政策、刪除介面與責任邊界。
刪除流程通常需要先立即停止使用，再非同步清除實體副本。收到刪除要求後，可先建立 tombstone，讓查詢、RAG 檢索與背景工作立即排除該資料；接著刪除原文、摘要、附件、向量、索引與快取。備份若無法逐筆修改，應設定有限保存週期，並確保還原時會重新套用刪除清單，避免已刪資料因災難復原再次出現。
系統也要保存最小化的刪除證據，例如請求識別碼、涵蓋範圍、完成時間與各儲存區的處理結果，而不是把被刪內容留在證明中。若存在法務保全、調查或契約限制，應把「暫停刪除」與一般保留分開管理，限定存取者並記錄原因；保全解除後，原本的到期政策必須恢復執行。
把保留政策做成可測試的系統能力
保留與刪除不應只寫在隱私政策中。工程團隊需要可執行的政策引擎、排程工作、權限隔離與管理介面。對外提供清除對話或關閉記憶的控制時，介面應說明影響範圍：只是隱藏畫面、刪除單次對話，還是連同長期偏好與上傳檔案一起移除。管理員也不應能以一般搜尋功能任意查看所有逐字稿。
測試要從一筆帶有附件、摘要與向量的測試對話開始，追蹤它是否能在所有儲存區被找到，再執行到期或刪除流程，確認線上查詢立即失效、背景工作最終完成、失敗可以重試，且備份還原後不會復活。政策版本更新時，還要測試舊資料是否套用新規則，以及跨租戶的刪除工作是否可能誤刪其他企業的資料。
最實用的起點是預設少存、縮短原始對話期限，並只讓經確認且有明確用途的資訊進入長期記憶。之後再根據實際任務失敗、客服需求與稽核要求調整，而不是先建立一個永久資料湖。若系統橫跨 LINE、ERP、CRM、雲端與多家模型服務，整合團隊的價值就在於把同一套生命週期政策落實到每一個資料副本。