將義務連結到證據

先了解系統與預定用途

「我們使用 AI」不足以判斷法律義務。說明服務、使用者、資料、決策、司法管轄區和組織角色。區分用於開發軟體的 AI，以及交付產品內使用的 AI。

例如，使用程式設計助手實作固定計算，與部署評估求職者的模型並不相同。兩者都需要適當開發流程，但運作影響與適用義務可能不同。

請具備適當資格的法務或法遵負責人評估適用性。歐盟執委會說明了 AI Act 以風險為基礎的框架。依實際用途查核現行法規與指引，不要只靠記憶中的期限。AI Act 框架。

分開記錄四個部分

義務說明必須達成什麼。控制措施說明組織如何處理該義務。證據顯示發生了什麼，或驗證了什麼。決定則記錄誰在什麼條件下接受結論。

以虛構的客戶資料匯出為例。組織政策規定，管理者只能匯出自己所屬組織的紀錄。有用的紀錄可以包含：

這個範例說明內部要求，並非宣稱一項測試就能符合某項法律。紀錄中也要保留這個區別。

將生成文件視為待審查的工作成果

AI 可以協助草擬資料流說明、找出缺少欄位，或彙整現有證據。但它也可能假設接收方、捏造控制措施，或描述沒有人測試過的備份。

對照系統查核每項重要陳述。文件若說資料已加密，就找出相關儲存位置、金鑰安排和設定證據。若說存取權經過審查，就找出流程與實際紀錄。

資料保護影響評估（DPIA）關注資料處理及其對人的影響。依 GDPR Article 35，是否需要評估，取決於可能的高風險與處理情境。產生一份有這個標題的檔案，不代表已完成評估。GDPR Article 35。

讓證據維持有效且適量

將證據綁定版本、環境和日期。較早版本的測試，可能未涵蓋已變更的授權路徑。定義哪些重大變更需要重新審查。

蒐集支持決定所需的資料。不要只為證明匯出測試執行過，就保留完整客戶紀錄。仔細設計的測試，可以使用虛構資料，並記錄必要結果。

有效的治理工具會連結要求、工作、證據和決定，但不會免除組織解釋義務或運作控制措施的責任。比較個別程式設計工具與完整交付系統時，評估這種連結是否存在。