AI 風險評估清單：治理職責與完整檢查問題

這份清單怎樣使用

本文為《可信 AI 倫理指南》2019 年版第三章中文譯文，對應印刷頁 24至31。它保留原版試用清單的全部問題，供結合具體情境閱讀，不把它呈現成現行法律檢查表或認證結果。上一部分七項要求與實現方法解釋了每組問題的理由。

第二章的核心指導是：整個生命週期滿足七項要求，結合技術與非技術方法；推動評估與實現要求的研究、創新、公眾傳播及倫理人才培養；清楚說明能力、侷限與實施方式，讓人知道自己正與 AI 互動；促進可追溯、可審計；讓各方參與並得到培訓；持續識別、評估、記錄和溝通原則與要求間的權衡。

第三章據此提供一份非窮盡的試用版清單，主要面向開發者和部署者，適用於自行開發或從第三方取得的系統，尤其是直接與使用者互動的系統。清單不處理可信 AI 的合法性部分，滿足清單不證明已經合規，也不提供法律合規指導；使用時須按用途和執行環境調整。

原版設想透過公私部門合作試用清單及治理結構。試用分兩路：定性方面，選擇具有代表性、來自不同領域和不同規模的少量組織實踐並提供深入反饋；定量方面，讓所有感興趣者參與公開諮詢。原文計劃將反饋整合到 2020 年初的修訂版，先形成跨領域基礎，再進一步發展行業或應用框架。這是原版歷史安排。

把評估納入治理

組織可以把評估納入既有治理機制，也可新增流程，選擇取決於結構、規模及資源。原文援引的組織變革研究強調，高層關注對於改變十分關鍵，而廣泛參與有助於提高新流程的接受程度及相關性。因此，應同時覆蓋日常執行與最高管理層。

使用時，不僅關注已經發現的問題，也要關注無法或難以回答的問題。一個原因可能是開發、測試團隊的技能和能力缺少多樣性，因此需要請組織內外其他人參與。

應同時用技術語言和管理語言記錄全部結果，使各層級都能理解問題解決過程。評估深度應與用途和風險相稱。清單不給每個問題預設答案，而是鼓勵思考如何落實可信 AI、下一步應做什麼。

現有法律可能已經要求某些流程或禁止某些結果，與清單重疊。例如資料保護法律規定個人資料收集處理的義務，而促進合規的內部政策也可能支援倫理處理。但滿足清單仍不等於滿足法律。組織已有非法律標準評估或軟體開發流程時，也無需另起一套孤立工作，可將清單融入其中。

一、人的能動性與監督

基本權利

• 系統可能損害基本權利時，是否開展了影響評估？是否識別並記錄不同原則與權利之間的潛在權衡？
• 系統是否與人的決策相互作用，例如推薦行動或決定、呈現選項？它是否會以非預期方式干預最終使用者的決策，影響自主性？
• 是否考慮應告知使用者：某項決定、內容、建議或結果來自演算法決策？
• 若是聊天機器人或其他對話系統，使用者是否知道正在與非人類代理互動？

人的能動性

• 系統是否進入工作或勞動流程？若是，是否考慮人與 AI 的任務分配，以確保有意義的互動及適當人工監督、控制？
• 它是否增強或擴充套件人的能力？是否採取措施，防止人在工作中過度信任、過度依賴系統？

人的監督

• 是否為具體系統和用途考慮了適當的人工控制程度？能否描述人的控制或參與水平？
• “掌握控制的人”是誰？在哪些時點、透過哪些工具能夠介入？是否有機制和措施確保人的控制或監督？
• 是否採取措施使自主性治理可被審計，並能糾正有關問題？
• 若系統具有自學習或自主能力，是否設定了更具體的控制與監督機制？建立了哪些檢測、響應機制，判斷是否可能出錯？
• 是否設有在必要時安全中止操作的停止按鈕或程式？該程式會完全終止、部分終止，還是將控制交給人？

二、技術穩健性與安全

抵禦攻擊與安全防護

• 是否評估系統可能受到哪些攻擊？是否考慮資料汙染、物理基礎設施、網路攻擊等不同性質的漏洞？
• 是否有措施或系統，保護完整性並抵禦潛在攻擊？
• 是否驗證在意外情境與環境中的行為？
• 是否考慮系統可能具有多大程度的雙重用途？若有，是否採取預防措施，包括在適當情況下不釋出研究或不部署系統？

後備方案與一般安全

• 遭遇對抗攻擊或其他意外時，是否有足夠的後備方案，例如切換技術程式，或繼續前先請求人工操作？
• 是否考慮具體用途下的風險水平？是否有測量與評估風險、安全的流程？危及身體完整時，是否提供必要資訊？是否考慮保險來應對潛在損害？
• 是否識別可預見的其他用途中的安全風險，包括意外或惡意濫用？是否有緩解或管理計劃？
• 是否評估系統對使用者或第三方造成傷害的可能性、潛在損害、受影響人群和嚴重程度？是否考慮責任及消費者保護規則？
• 是否考慮對環境、動物的潛在影響及安全風險？風險分析是否包括網路安全等安全防護問題，可能經由非預期行為轉化為人身安全風險或損害？
• 是否估計錯誤結果、系統不可用、或社會無法接受的結果（例如歧視）會帶來什麼失敗後果？
• 是否定義閾值及治理程式，觸發替代或後備計劃？後備方案是否已明確並經過測試？

準確性

• 是否在具體系統與用途下，確定準確性的定義和所需水平？是否評估怎樣測量、保證準確性？
• 是否確保資料足夠全面、及時更新？是否有措施判斷是否需要額外資料，例如為改善準確性或消除偏差？
• 是否驗證不準確預測會造成何種傷害？
• 是否有辦法測量錯誤預測是否已經多到不可接受？
• 是否建立逐步提高準確性的措施？

可靠性與可復現性

• 是否有策略監測和測試系統是否滿足目標、目的及預定用途？
• 是否測試為了復現，需要考慮哪些特定情境或條件？
• 是否建立驗證方法，測量和確保可靠性與可復現性的不同方面？
• 是否有流程描述系統在哪類條件下失敗？是否清楚記錄這些流程，並將其用於可靠性測試和驗證？
• 是否有溝通機制，使最終使用者瞭解系統可靠性的保障？

三、隱私與資料治理

尊重隱私與資料保護

• 是否按用途建立機制，讓他人能指出訓練、執行資料收集及處理過程中的隱私或資料保護問題？
• 是否評估資料集的資料型別與範圍，例如是否包含個人資料？
• 是否考慮不使用、或儘量少使用敏感和個人資料來開發系統或訓練模型？
• 是否按用途設定個人資料告知與控制機制，例如在適用時取得有效同意，並允許撤回？
• 是否透過加密、匿名化、聚合等措施加強隱私？
• 設有資料保護官時，是否在早期就讓其參與？

資料質量與完整性

• 日常資料管理與治理是否符合相關標準，例如 ISO、IEEE，或廣泛採用的協議？
• 是否建立資料收集、儲存、處理、使用的監督機制？
• 是否評估對外部資料來源質量有多大控制能力？
• 是否有保證質量和完整性的流程？是否考慮過其他流程？如何驗證資料沒有遭到篡改或攻擊？

資料訪問

• 採用了哪些協議、流程、程式來管理並確保適當的資料治理？
• 是否評估誰能在什麼情況下訪問使用者資料？
• 是否確保訪問者具有資格、確有需要，並具備理解資料保護政策細節的能力？
• 是否有監督日誌，記錄誰在何時、何地、以何種方式、為何目的訪問資料？

四、透明度

可追溯性

• 是否建立可追溯措施，記錄演算法系統的設計與開發方法？對於規則系統，記錄程式設計或建模方法；對於學習系統，記錄訓練方法，以及收集、選擇了哪些輸入資料、如何完成。
• 是否記錄測試與驗證方法？對於規則系統，記錄採用的情境和案例；對於學習模型，記錄用於測試、驗證的資料。
• 是否記錄演算法的結果與決定，也考慮不同情形下的其他可能決定，例如面對不同使用者子群時會產生什麼結果？

可解釋性

• 是否評估 AI 的決定與結果能夠被理解到什麼程度？
• 是否評估系統決定在多大程度上影響組織決策？為什麼在這一領域部署這個特定系統？它的商業模式是什麼，例如怎樣為組織創造價值？
• 對於系統為何作出某種選擇、導致某種結果，是否提供所有使用者都能理解的解釋？
• 是否從設計之初考慮可解釋性？是否研究並嘗試採用適合該用途、儘可能簡單且可解釋的模型？
• 是否能分析訓練和測試資料，並隨時間改變、更新它們？
• 是否能在訓練開發後檢查可解釋性，或訪問模型內部工作流程？

溝通

• 是否透過說明或其他方式，告知最終使用者正在與 AI 而非人互動？系統是否清楚標為 AI？
• 是否有機制說明結果背後的理由與判斷標準？說明是否清楚易懂，適合目標讀者？
• 是否有流程接收反饋，並用反饋調整系統？是否溝通了潛在或被感知到的風險，例如偏差？是否按用途考慮向其他受眾、第三方或公眾說明？
• 是否澄清系統目的，誰或什麼會從產品服務中受益？是否明確使用場景，並清楚溝通，使預期受眾能夠理解且認為適當？
• 是否按用途考慮人的心理與侷限，例如困惑、確認偏誤、認知疲勞？
• 是否清楚傳達系統特徵、侷限及潛在缺陷？開發者是否向將它部署進產品服務的人說明，部署者是否向最終使用者或消費者說明？

五、多樣性、不歧視與公平

避免不公平偏差

• 是否針對輸入資料和演算法設計，建立避免產生或強化不公平偏差的策略或程式？
• 是否評估並承認資料集組成的侷限？是否考慮資料中使用者的多樣性與代表性，並測試特定人群或容易出問題的用途？
• 是否研究和使用可用技術工具，改善對資料、模型和表現的理解？
• 是否在開發、部署、使用階段設定測試和監測潛在偏差的流程？
• 是否按用途設定機制，讓他人能提出偏差、歧視或表現不佳的問題？是否清楚說明向誰、怎樣提出？除最終使用者外，是否考慮間接受影響者？
• 是否評估相同條件下決定仍可能變化？若會變化，可能原因是什麼？是否有機制測量或評估這種變化對基本權利的潛在影響？
• 是否為設計採用適當、可操作的“公平”定義？該定義是否常用，選擇前是否考慮其他定義？
• 是否用定量分析或指標，測量並測試採用的公平定義？是否有保障公平的機制，也考慮過其他可能機制？

可訪問性與通用設計

• 系統是否適應廣泛的個人偏好與能力？
• 是否評估有特殊需要、殘障或被排斥風險的人能否使用？這些考慮怎樣進入設計，又怎樣驗證？
• 系統資訊是否也能被輔助技術使用者獲取？開發時是否邀請這些群體參與或諮詢？
• 是否考慮對潛在受眾的影響？開發團隊是否代表目標使用者，也代表更廣泛人群及可能間接受影響的其他群體？
• 是否評估某些人或群體會否不成比例地承受負面影響？是否從其他背景、經驗的團隊或群體獲取反饋？

利益相關者參與

• 是否有機制，讓不同利益相關者參與系統開發和使用？
• 在組織引入 AI 前，是否提前告知並讓受影響勞動者及其代表參與，為引入做好準備？

六、社會與環境福祉

可持續與環境友好

• 是否有機制測量開發、部署和使用的環境影響，例如資料中心使用什麼能源？
• 是否採取措施減少整個生命週期的環境影響？

社會影響

• 系統直接與人互動時，是否評估它會否鼓勵人對系統產生依戀與共情？
• 是否清楚表明社互動動是一種模擬，系統不具有人類意義上的“理解”與“感受”能力？譯註：這裡保留 2019 年原文的判斷與措辭，不將流暢對話本身作為心智或感受的證據。
• 是否充分理解社會影響，例如失業或勞動者技能退化的風險？採取了哪些應對步驟？

社會與民主

• 是否評估超出個別最終使用者的更廣泛社會影響，包括可能間接受影響的利益相關者？

七、問責

可審計性

• 是否建立有利於審計的機制，例如確保流程與結果可追溯、留有日誌？
• 涉及基本權利，包括安全關鍵應用時，是否確保系統可以被獨立審計？

減少並報告負面影響

• 是否開展風險或影響評估，考慮直接與間接受影響的不同利益相關者？
• 是否提供支援問責實踐的培訓和教育？涉及哪些勞動者或團隊職能，是否超出開發階段？是否講解潛在適用法律框架？
• 是否考慮設立倫理 AI 審查委員會或類似機制，討論整體問責、倫理實踐及不明確的灰色地帶？
• 除內部措施外，是否安排外部指導或審計，監督倫理與問責？
• 是否有流程讓供應商、消費者、分銷商、銷售商等第三方及勞動者報告潛在漏洞、風險或偏差？

記錄權衡

• 是否有機制識別系統涉及的利益、價值及潛在權衡？
• 怎樣決定這些權衡？是否確保決定被記錄？

獲得救濟的能力

• 出現傷害或不利影響時，是否有足夠的救濟機制？
• 是否透過機制向最終使用者和第三方說明可以怎樣獲得救濟？

原版結語：清單應怎樣繼續改進

原文邀請所有利益相關者在實踐中試用，並反饋清單是否可實施、完整、適合具體應用或領域，以及它與既有合規、評估流程有何重疊或互補。原文計劃依據反饋在 2020 年初向委員會提出修訂版。

本章的關鍵指導是：開發、部署和使用 AI 時，採用並按具體用途調整清單；始終記住清單不會窮盡所有問題。可信 AI 不是打勾，而是在整個生命週期中持續識別要求、評估解決方案、改善結果，並讓各方參與。

繼續閱讀應用機會、關鍵關切與術語。若要聯絡業務流程，可以回到可信 AI 與倫理框架，對照原來的反思問題。

參考與延伸閱讀

原文：Ethics Guidelines for Trustworthy AI，2019 年 4 月 8 日，European Union，印刷頁 24至31。歐盟數字戰略原文入口。本頁是非官方中文翻譯，保留試用版問題及歷史計劃，調整分篇、分組、術語和版式；問題不是現行認證要求。

依據歐盟再利用說明，原資料採用 CC BY 4.0，本頁譯文按相同許可提供，不表示原機構認可。

編輯補充：GDPR 官方原文用於獨立查詢資料保護要求；NIST AI 風險管理框架是另一套公開框架，可比較其治理、情境識別、測量與管理方法，不能據此把兩套清單視為等價。