要用 AI 起草私隱影響評估，先繪製真實處理活動，逐項核實數據流和 authority，再把脫敏證據目錄與固定模板交給模型。AI 能整理事實、暴露缺項，卻不能決定文件是否充分、處理是否合法或項目能否繼續；這些決定屬於私隱專業人員、DPO、法律顧問、風險 owner 與業務負責人。

這是項目級起草工作流，並繼承負責任使用 AI的安全輸入邊界。它不是私隱政策、供應商問卷、通用風險登記冊、法律意見或自動 DPIA 判定。

關鍵要點

起草前先篩查法域要求的 DPIA 或其他評估流程。

從經核實、有版本的數據流 inventory 建立草案。

分開記錄目的、必要性、authority、對人的傷害、控制與 residual risk。

只給 AI 最小化、脫敏證據，並要求未知和衝突保持可見。

批准、諮詢和高風險判斷交給具備權限的專業人員。

PIA 是甚麼，DPIA 有何不同？

Privacy impact assessment 是系統審查項目如何影響私隱的廣義名稱。不同法域、監管機構、合同或組織政策可能定義不同觸發條件、流程和批准角色。歐盟 GDPR 第 35 條規定，某類處理可能給個人權利與自由帶來高風險時，需要執行數據保護影響評估，並規定最低內容。［1］

英國 ICO 指南解釋 DPIA 篩查、諮詢、處理描述、必要性與比例性、風險及降低措施。該頁面目前提示部分內容正因英國立法變化接受審查，因此必須覆核當前法域文本，不能把舊模板當作永久法律。［2］

篩查欄位	記錄內容
Project/version	穩定身份、owner、階段與日期
Jurisdictions	涉及人員、機構、系統與傳輸地區
Authority	法律、監管、政策、合同或自願實踐
Indicators	規模、敏感性、監控、匹配、自動化、弱勢人群和新技術
Evidence	系統設計、數據圖、法律意見和產品事實
Decision	PIA、DPIA、其他評估、合併流程或無需評估
Decision owner	DPO、privacy counsel 或政策指定角色
Re-screen	目的、數據、人員、技術、接收者、規模或法域變化

AI 不得判斷活動依法豁免。authority 或範圍不清時應保留問題並取得合格意見。

步驟 1：凍結項目、目的和決定邊界

寫明系統、功能、流程、環境、owner、設計版本、擬上線時間與評估 cutoff，並說明評估要支持批准、重設計、限定 pilot、增加控制、諮詢還是取消。

從獲批業務和法律來源寫具體目的。「改善服務」太寬，無法判斷必要性和兼容再使用。目的應說明服務、受影響人員、預期結果和運營範圍，不應假定所有可能有用的處理都已獲授權。

列出相鄰系統和排除項。身份、分析、支持、支付、雲服務或 AI provider 可能參與處理，但只有部分流發生變化。說明本評估覆蓋甚麼、引用哪些現有評估、哪些依賴另有 owner。這也把 PIA 與內部政策草案分開：政策定義長期 authority，PIA 把規則應用到一個項目。

步驟 2：建立經核實的數據流 inventory

訪問產品、工程、安全、私隱、法律、營運和供應商方面的負責人。把設計文件與已實作的 schema、API、事件定義、保留工作、存取控制、支援程序、合約和實際部署設定逐一核對。

每條數據流都要記錄：

資料當事人及其與機構的關係；
資料類別、敏感程度、來源，以及是否必須提供；
收集介面，以及時間戳或生命週期事件；
目的和獲授權的用途；
系統、儲存地區、格式和識別碼關連；
內部存取角色和外部接收方；
處理者、次處理者，以及經審查的控制者／處理者角色；
自動化決策、分析側寫、推斷或人手覆核；
保留觸發條件、期限、刪除方式、備份處理和法律保全；
適用時的跨境轉移路徑和已批准的保障措施；
附有證據參考的安全和私隱控制。

按證據繪製數據流圖，而不是按口耳相傳的架構印象。如果客戶端把某個識別碼傳送到 API，API 把它寫進日誌，隊列複製了它，數據倉庫由此推導出某個屬性，客戶支援又可以搜尋它，那麼這些用途全都屬於 inventory。把不確定的分支標為 VERIFY；不要讓 AI 揀選看來最合理的路徑。

步驟 3：在使用 AI 前最小化證據包

起草通常只需要 metadata 和獲批描述，不需要個人數據。把姓名、郵箱、帳號、IP、精確位置、自由文本、credentials 和生產記錄替換為穩定合成標識，刪除 secret 與無關商業資料。

證據目錄至少包含 evidence ID、安全描述、owner、version/date 和 approved use。原件保留在授權系統，只給模型最小必要摘錄。VPN 能保護網絡路徑，但不會讓個人數據自動適合上載到第三方 AI；應另行按AI 私隱風險指南檢查平台保留、訪問和訓練設置。

證據 ID	安全描述	負責人	版本或日期	獲准用途
`E-01`	使用合成欄位名稱的已審核流程圖	Privacy Engineering	`v3`	草擬 PIA
`E-02`	只含 schema 的事件定義	Data Platform	`2026-04-12`	欄位清單
`E-03`	已批准的保留計劃摘錄	Records Owner	目前版本	保留分析
`E-04`	經合約審核的處理方事實	Procurement	已簽署版本	接收方映射

步驟 4：分析必要性、比例性和 authority

針對每個目的，詢問處理是否確實需要、是否存在侵入性更低的方案、數據量和精度是否成比例、保留與訪問是否受限，並記錄被拒絕的替代方案和證據。

Legal basis、consent、notice、rights、purpose compatibility、兒童、員工與行業義務都是法域相關法律判斷。AI 可以格式化已經批准的結論和指出空欄位，不得自行選擇法律依據。

GDPR 第 35 條要求系統描述處理和目的、評估必要性與比例性、評估個人權利與自由風險，並說明應對措施。［1］這些分析彼此關聯但不能互相替代；傳輸加密不能證明收集本身必要。

步驟 5：從個人視角評估私隱傷害

不要只寫公司損失。傷害可能包括失去控制、意外披露、歧視、排斥、操縱、監控、名譽或財務損失、人身危險、寒蟬效應、無法行使權利和錯誤推斷造成的後果。

風險陳述使用 cause-event-impact，再記錄 existing controls、evidence gap、additional action 和 owner。AI 不得發明 likelihood、severity、risk appetite 或控制有效性；組織批准的方法和授權人分別評估 inherent risk、control effectiveness、residual risk 與 acceptance。

要素	合成例子
原因	客戶服務可廣泛查閱精確位置記錄
事件	未獲授權的員工搜尋前伴侶記錄
對個人的影響	被跟蹤風險及人身安全受損
現有控制	角色限制、審批、查詢日誌及警報
證據缺口	尚未演練警報回應
補充行動	執行受控的偵測及回應測試
負責人	Security Operations 角色

NIST Privacy Framework 提供識別和管理私隱風險的企業風險方法，可用於連接處理、治理、溝通、保護與覆核，而不把私隱縮減成保密性。［3］

步驟 6：把控制映射到風險與證據

就每項風險，記錄現有控制、它們如何改變風險成因或影響、負責人、設計和運作方面的證據、局限，以及計劃中的改善。控制可以包括資料最小化、本機處理、匯總、分隔、存取限制、加密、日誌、審核、可申訴性、更正、刪除、通知、同意、人手介入、速率限制和濫用應對。

避免裝飾性的控制清單。傳輸加密解決不了過度收集；保留政策不能證明刪除工作確實執行；合約亦不能證明處理者的技術設定。把每項控制對應到具體的風險機制和證據。

供應商方面的問題可以透過盡職調查問卷工作流程收集。只把經審核的答案和合約事實匯入 PIA。不要讓模型把宣傳說法或未獲回答的問題變成已確認的控制。

步驟 7：用 AI 起草私隱影響評估的嚴格契約

提供範本、已去識別化的證據索引、已批准的術語和責任矩陣：

只使用所提供的證據 ID 草擬 PIA 各節。
逐字保留項目、系統、資料、目的、接收方、保留期限和負責人等事實。
不得推斷法律依據、司法管轄區、控制者角色、必要性、同意、
可能性、嚴重程度、控制成效、剩餘風險或批准。
無根據的欄位寫 [VERIFY]，互相衝突的說法分開保留。
把每段事實追溯到證據 ID，並傳回審核問題。
不得索取或重現個人資料、登入憑證或正式環境紀錄。

要求模型提供一張來源表，說明每節由哪些證據支持。請它找出遺漏的資料當事人、接收方、刪除路徑、權利要求處理和重新篩查觸發條件。在負責的審核人確認之前，把每項擬議的風險、控制或法律陳述都視為候選內容。

NIST 的生成式 AI 設定檔指出了私隱、虛構內容、資訊完整性和人機配置方面的風險。［4］因此，審核流程既要檢查被評估的項目，亦要檢查因使用 AI 草擬評估而新增的資料處理。

步驟 8：由不同領域 owner 分別覆核

分開進行審核，而不是作一次籠統的批准：

產品負責人確認目的、範圍、決策和替代方案；
工程確認已實作的數據流、系統、存取、保留和刪除；
安全確認威脅、控制、測試證據和應變；
數據負責人確認欄位、資料沿襲、質素和容許的用途；
供應商和採購負責人確認接收方和合約事實；
私隱和法律顧問確認法律依據、權利、通知、跨境轉移和必需的程序；
DPO 或政策指定的權力方質詢高風險處理和諮詢需要；
在適當時，由代表或針對受影響人士的研究協助識別可能的傷害。

記錄分歧及其解決方法。項目負責人不能只因急於推出便批准一項法律結論，模型亦不能把互相衝突的審核意見合併成一段更順暢的文字。

如果 AI 代理會執行操作而不只是草擬文字，便以 AI Agent 安全流程檢查權限、工具存取、提示注入、審批、日誌和還原。這些控制應在 PIA 中以真實的系統證據呈現，而不是以承諾的形式出現。

步驟 9：決定 residual risk、諮詢和批准

控制已實施或作出承諾之後，按已批准的方法重新評估剩餘風險（residual risk）。記錄假設、未完成的行動、期限、負責人、推出條件、監察、事故應變，以及誰有權接受餘下的風險。

如果適用法律規定在高風險處理之前須諮詢監管機構或其他機構，便把它保留為阻斷條件。AI 不能斷定控制已把風險降得足夠低，亦不能斷定無須諮詢。

最終紀錄應區分建議、批准、有條件批准、否決和升級處理，並寫明具名角色、日期、條件和證據。不要把未完成的行動藏在文字中，亦不要因為日後有負責人便把它標為已完成。

步驟 10：版本化並定義覆查觸發器

把已批准的評估及其證據參考存檔，並與確切的設計和實作版本連繫。保留變更紀錄，而不是在推出後覆寫原來的描述。

當目的、資料類別、涉及的人士、規模、地域、接收方、處理者、保留、推斷、自動化決策、模型、權限、安全架構或法律環境改變時，重新篩查。發生事故、投訴、權利要求、意外傷害、控制失效或重大審計發現之後，亦要覆查。

監察應檢驗支撐這項批准的假設。量度控制的運作情況、存取模式、刪除完成情況、錯誤率和申訴率、事故、投訴和意外用途。PIA 並不會因為推出前簽了一份文件便算完成。

批准前應通過哪些檢查？

總結

選擇模板前先篩查所需評估類型。
凍結項目並建立經核實的數據流 inventory。
向 AI 提供最小化、脫敏證據。
分開判斷必要性、authority、傷害、控制和 residual risk。
法律、DPO、安全和風險批准由人工負責。
處理或證據變化時重新評估。

常見問題

PIA 總是等同於 GDPR DPIA 嗎？

不是。PIA 是廣義名稱，DPIA 可能是有特定觸發條件和內容的法定流程。應由私隱或法律專業人員判斷項目與法域適用的程序。

AI 能判斷是否必須做 DPIA 嗎？

不能。它可以整理篩查問卷和指出缺項，卻不能可靠決定法域、法律門檻、例外或組織權限。

哪些資料不應放進 AI prompt？

除非獲批環境和明確必要性允許，否則排除個人數據、credentials、生產記錄、精確標識、敏感自由文本、secret 和無關機密；優先 metadata、合成示例與證據引用。

數據流圖足以構成 PIA 嗎？

不足。PIA 還需要 purpose、authority、necessity、proportionality、對個人的風險、控制、證據、rights 處理、residual risk、諮詢、批准、監控和覆查觸發條件。

誰應批准草案？

按法律與組織政策確定，常見角色包括產品 owner、私隱團隊、DPO、法律顧問、安全、數據與風險 owner 和負責管理層，各自職責應分開。

強安全控制能消除全部私隱風險嗎？

不能。安全可降低未授權訪問或篡改，但不能獨自證明收集、目的、保留、推斷、公平性和個人自主影響是正當的。

Reviewer 意見衝突怎麼辦？

記錄各方立場、證據、決定權限、解決方式、條件及必要的異議。不能讓 AI 選擇最流暢或最利於上線的說法。

PIA 多久覆查一次？

以事件觸發為主。目的、數據、人群、規模、接收者、技術、權限、保留、transfer、法律、事故或已觀察傷害發生實質變化時重新篩查。

本文只提供一般資訊，不構成法律建議。私隱義務會隨法域和時間變化，應向 DPO、私隱專業人員和合格法律顧問獲取當前意見。

來源

EUR-Lex, Regulation (EU) 2016/679, Article 35 — https://eur-lex.europa.eu/eli/reg/2016/679/art_35/oj
UK Information Commissioner's Office, Data Protection Impact Assessments — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
NIST, Privacy Framework — https://www.nist.gov/privacy-framework/privacy-framework
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 起草私隱影響評估：由核實數據流到 DPO 與法律覆核