行銷提出新企劃：把會員購買紀錄和客服文字交給外部 AI 服務，預測下次可能購買的商品。
工程說：「API 接得上，資料有加密，測試也沒外洩。」
法遵卻問：「為什麼需要整段客服對話？會員原本知道要拿來做這件事嗎？」
資料沒有外洩，不代表隱私風險不存在。 DPIA（隱私衝擊評估）關心的不只是防駭，還包括處理目的、必要性、資料量、對當事人的潛在影響，以及能否用更少資料完成工作。
以上為專案審查情境示意，非對某個 AI 服務的實測。
DPIA、ROPA、一般資安風險評鑑的差別
| 工具 | 主要回答的問題 | 常用輸出 |
|---|---|---|
| ROPA（處理活動紀錄） | 我們拿哪些資料？為何處理？由誰使用？流向哪裡？ | 活動、目的、類型、對象、保存與委外清冊 |
| PIA／DPIA（隱私衝擊評估） | 某項處理活動可能如何影響個人權利？能否降低影響？ | 風險情境、必要性、影響、控制與剩餘風險 |
| ISO 27001 資安風險評鑑 | 系統、資產與營運目標面臨哪些資安威脅？ | 風險清冊、處置方案、控制措施 |
三者可以互相引用，不必重複蒐集同一份事實，但分析焦點不同。
以會員資料導入 AI 客服為例
假設品牌想把電商訂單與客服歷程串接外部 AI 服務，協助客服回答配送問題。
圖解：沒有系統入侵不等於沒有隱私衝擊
第一問：處理目的是否必要？ 回答配送問題真的需要姓名、完整電話、住址、歷史購買紀錄全部傳給 AI 嗎？或只需要訂單狀態與必要的遮罩資訊？
第二問：資料流向在哪裡？ AI 供應商是否保留提示詞和輸出？是否有次委外？資料儲存及傳輸地點為何？合約允許供應商如何使用資料？
第三問：個人可能受到什麼影響？ 非必要個資揭露、錯誤建議、敏感客服紀錄洩漏、無法回應刪除請求。
第四問：能做什麼降低風險？ 遮蔽資料、限制 API 權限、縮短保留期間、禁止未授權再利用、建立人工覆核、審核供應商條款。
一張可用的簡化評估表
| 欄位 | 說明 | 範例 |
|---|---|---|
| 活動 | 本次新流程是什麼 | AI 客服查詢配送狀態 |
| 資料 | 實際傳送的資訊 | 訂單識別碼與狀態 |
| 目的／必要性 | 為什麼需要 | 縮短客服回覆時間，排除非必要欄位 |
| 權利風險 | 可能造成的影響 | 識別資料被其他服務再利用 |
| 控制措施 | 怎麼處置 | 遮罩、限制權限、合約禁止其他用途 |
| 驗證證據 | 怎麼確定有做到 | API 欄位記錄、設定截圖、契約版本 |
| 剩餘風險 | 處置後還有什麼風險 | 供應商留存方式待確認 |
| 核准／追蹤 | 誰接受、何時複查 | 個資負責窗口每季複查 |
以上僅供管理設計參考，不是對任何特定系統的真實查核結論。
圖解：先確認必要性再討論技術是否安全
什麼時候需要重做評估？
不是每個月都重填相同的表。較有價值的觸發條件是：新增資料用途、新系統或委外商、跨境傳輸變動、保留期間改變、重大事故、個資類型或資料量顯著增加。法律上是否必須進行正式 DPIA，仍依適用法域與該處理活動規定判定，不能說所有台灣電商一律有相同的 GDPR DPIA 義務。
重點不是填滿表格，而是讓導入新工具前的「必要性、風險、證據、負責人」有記錄可查。
資料來源： ISO/IEC 27701:2025、GDPR 第 35 條、台灣《個資法》。
同主題延伸閱讀：ISO 27701 課程怎麼選？2025 新版 PIMS、內稽與企業獨立認證的差異、ISO 27701:2025 差距分析怎麼做？PIMS 查核矩陣與證據範例。