IL 202 完成的存取矩陣是特定時間點的快照。從 Readiness Review 核准到 IL 301 Pilot 開始，帳號可能離職、角色可能調整、系統可能升級。技術與資料審查的第一步，是重新用目前實際帳號測試一次權限，而不是假設矩陣仍然正確。
| 項目 | 重新驗證方式 |
|---|---|
| 帳號仍然存在且啟用 | 逐一確認 Pilot 團隊成員與 AI 工具服務帳號目前狀態 |
| 角色權限範圍不變 | 用實際帳號登入測試，確認仍是唯讀或原核准的最小權限 |
| 撤權機制仍然有效 | 重新演練一次撤權，確認撤權後立即生效，不是延遲數小時 |
| 第三方或委外帳號 | 若牽涉委外廠商帳號，確認委外合約與資料使用範圍仍然有效 |
注意
資料範圍蔓延（scope creep）常常不是刻意違規，而是團隊在解決眼前問題時，順手多接了一個資料來源、多存了一份日誌。技術與資料審查要主動找出「現在實際用到的資料」是否超出 IL 202 資料盤點核准的範圍。
| 項目 | 說明 |
|---|---|
| 資料來源清單 | 對照 IL 202 資料盤點，逐一確認目前實際串接的來源是否都在核准清單內 |
| 新增欄位或日誌 | 檢查是否為了除錯或監測，新增了未經核准的個資欄位或詳細日誌 |
| 資料保存期間 | 確認目前的保存與刪除設定，是否符合核准的保存政策 |
| 對外傳輸 | 確認資料是否被傳送到未經核准的外部服務（例如除錯用的第三方監控工具） |
技術團隊為了除錯方便，把完整的客服對話紀錄（含客戶姓名、電話）另外存了一份到除錯用的試算表，方便快速搜尋問題案例。
IL 202 Readiness Review 的 conditional 狀態代表「附條件就緒」，每一項都應該有明確的結案證據。IL 301 開始前，必須逐一核對這些條件是否真的結案，而不是只看狀態欄位寫著「已結案」。
| 原始缺口 | 結案宣稱 | 重新驗證方式 |
|---|---|---|
| API key 撤權延遲 | 技術管理員宣稱 3/15 已完成並重新演練 | 要求提供演練紀錄與撤權耗時的具體數字，而不是只看「已完成」勾選 |
| 隱私準備度個資標註缺口 | 隱私負責人宣稱已完成標註並重新評估 | 抽查資料流向圖，確認個資標註確實涵蓋客戶姓名、聯絡方式等欄位 |
團隊發現技術人員為了除錯方便，把含客戶姓名與電話的完整對話紀錄另存到一份未核准的除錯試算表。依照本模組的原則，最適當的處理方式是什麼？
