如何用 AI 建立合規義務登記冊：來源、適用性與證據

要用 AI 建立合規義務登記冊，先匯集已批准的權威來源，保留其版本和精確定位，只提取候選的義務文字，再把適用性和詮釋交給合資格的法律或合規審核人。把每項已批准的義務與負責人、控制、證據、覆核日期和變更觸發條件連繫起來。

負責任使用 AI 的流程有助整理受控的證據集。它無法判斷哪條法律管轄某個實體，不能提供法律意見，亦不能令一項無根據的政策陳述變得權威。

關鍵要點

• 由受管治的來源清單開始，而不是依賴模型對法規的記憶。
• 把來源原文、詮釋、適用性和實施分開。
• 記錄版本、司法管轄區、實體、觸發條件、生效日期和定位。
• 由法律和合規審核人批准義務，由負責人批准控制。
• 把登記冊視為索引和工作流程，絕不能取代法律原文。

甚麼是用 AI 建立合規義務登記冊？

合規義務登記冊是一份持續維護的索引，列出機構已審查並認定可能適用於其活動的要求。它把權威文字和適用性決定，與營運責任、控制、證據、保證工作和覆核連繫起來。審核人應能由登記冊中的一行追溯到確切的來源，亦能向前找到實施紀錄。

它不是從互聯網產生、聽來像法律的摘要清單，亦有別於風險登記冊：風險登記冊記錄不確定事件、影響、處置和接受，而義務登記冊記錄有來源支持的責任及其實施狀態。一項義務可能關連多個風險，反之亦然。

美國司法部的企業合規資料強調，合規計劃要按具體情況評估，並涉及設計、資源投入、運作、調查、激勵和持續改善等問題。［1］英國 ICO 的問責資料把文件紀錄與職責、政策、控制、紀錄和覆核連繫起來。［2］［3］這些來源支持管治設計，但不能證明某項要求適用於你的機構。

如何確定範圍和合規權威來源？

步驟 1：定義範圍和決定權限

收集來源前，先寫範圍說明，包括法律實體、業務單位、產品、處理活動、員工、客戶群組、司法管轄區、合約、監管關係和生效日期的時間範圍。寫明誰可批准來源納入、適用性、法律詮釋、控制責任、證據是否充分以及完結事項。

使用明確的角色：

決定	通常問責的角色
法律或合約是否適用	合資格的法律或合規審核人
權威來源／版本	法律、監管事務或合約負責人
營運負責人	業務或控制負責人
控制設計	控制負責人及相關專家
證據是否充分	合規、保證或審計部門（在其職權內）
風險接受	獲授權的管治組織

AI 可以提出問題、找出空白欄位，但不得按網站訪客、郵寄地址、幣種或語言悄悄推定司法管轄區。

步驟 2：建立權威來源清單

按機構的來源層級，收集官方法例、監管機構刊物、具約束力的命令、已簽立的合約、牌照和已批准的內部政策。記錄標準 URL 或受控檔案、發出機構、標題、司法管轄區、版本、發佈和生效日期、修訂狀態、語言、負責人、擷取日期和存取分級。

不要把搜尋摘要、供應商網誌、二手總結或模型以前的回答當作義務文字。二手資料可協助找到來源或構思問題，但審核人必須回到權威文件。若只有綜合版或譯本，記錄提供者及其法律地位。

維持來源之間的關係：對主體法例的修訂、詮釋某條規則的指引、屬於某份協議的合約附表，或實施某項已批准要求的政策。切勿合併成一條沒有出處的「法規」。

如何提取可追溯的候選義務？

步驟 3：把來源拆成可定位條款

以能負責任地詮釋的最小單位建立來源片段：節、條、款、附表項目、段落或表格行。每個片段都需要穩定的來源 ID、版本、精確定位、標題、文字或受控摘錄、語境窗口和擷取證據。

頁碼在 HTML、PDF 和綜合版之間未必穩定。優先使用來源本身的結構識別，例如條、節、款、段或要求編號，頁碼作為輔助。如果規定依賴別處的定義或例外，便連結那些片段，而不是只複製命令句。

至於篇幅長的合約，先以合約版本比較流程找出候選變更，再由合約負責人核實每項條款和生效版本。

步驟 4：提取候選義務，不判斷適用性

請 AI 找出可能構成責任、禁止、條件、通知、紀錄、批准、保留期限、限期或權利的字眼。在合資格審核人確認含意和適用性之前，輸出只是候選。

只按所提供的來源片段，依給定結構提取候選義務。
保留來源 ID、版本、精確定位、行為主體、行為、對象、
觸發條件、期限、例外、限定語和引用的術語。不要推斷
司法管轄區、受約束的實體、法律詮釋、適用性、控制、
負責人、證據或合規狀態。標示含糊之處和交叉參照，
交由合資格人員審核。不要使用模型記憶或外部來源。

把來源原話與工作詮釋分開。精簡的義務陳述在營運上有用，但絕不能覆寫權威文字，或抹去例外、定義、門檻、酌情空間和交叉參照。

步驟 5：使用可追溯 schema

一行站得住腳的紀錄可以包括：

欄位組別	欄位
身份	義務 ID、狀態、修訂版本
來源	發出機構、來源 ID、版本、定位、來源原文
範圍	司法管轄區、實體、活動、產品、人群
規則	行為主體、要求或禁止的行為、對象、觸發條件、時間
限定	定義、例外、門檻、依賴關係
適用性	決定、理由、審核人、日期、下次覆核
實施	負責人、政策、流程、控制、系統
證據	證據類型、存放位置、期間、保留、審核人
保證	測試負責人、方法、結果參考、問題連結
變更	生效日期、修訂觸發條件、影響評估

使用容許的狀態，例如 Candidate、Under legal review、Applicable、Not applicable、Superseded 和 Archived。空白絕不代表「不適用」。重要的狀態轉換須寫明理由和審核人。

這與需求追溯矩陣相似，但法律來源和適用性決定是特殊控制，不要把法律詮釋簡化成通用的需求驗證剔選方格。

合格人員應如何判斷合規義務適用性？

步驟 6：由合格人員覆核適用性

審閱整份相關文件和事實，而不只是提取出的那一句。判斷來源是否生效、涵蓋哪個實體和活動、適用哪個司法管轄區、是否達到定義和門檻、是否適用例外，以及義務何時開始或終止。

把決定記錄為註明日期的理由，寫明審核人、所依據的事實、未決問題和覆核觸發條件。「因為提到資料所以適用」並不足夠。「不適用」同樣需審慎，因為商業模式、司法管轄區、合約和監管立場都會變。

如果來源互相衝突或層級不清，便保留衝突並上報。AI 不得靠選擇較新的字眼、聽來更具體的條款或搜尋結果較多的答案來解決衝突。

如何連接義務、控制與證據？

步驟 7：連接 owner 與控制

適用性獲批准後，指定該義務的負責人和實施人員。把義務與政策、程序、預防性或偵測性控制、系統、培訓、通知、合約條款、監察和升級途徑連繫起來。

不要把政策存在等同運作有效。可使用內部政策草擬流程按已批准的權限準備文字，同時保留法律、私隱、安全、人力資源和營運方面的批准。

為每項控制記錄目標、負責人、頻率或觸發條件、輸入、程序、預期輸出、證據、總體、例外處理、依賴關係和變更紀錄。一項控制支援多項義務時，分別保留每條對應關係，以便來源改變時準確評估影響。

步驟 8：定義證據，但不編造證據

寫明預期用來證明控制運作的證據：已批准的紀錄、日誌、工作單、審核輸出、培訓紀錄、通知、合約、報告或系統設定。記錄存放位置、負責人、期間、保留規則、存取權限和核實程序。

預期證據不證明控制已運作。把 evidence design（證據設計）、evidence requested、evidence received、evidence verified 和 exception 作為獨立狀態。AI 不得為填滿空白儲存格而虛構檔案名稱、工作單、簽署、日誌項目、完成日期或測試結果。

NIST 指出了生成式 AI 中的虛構內容和資訊完整性風險。［4］把模型輸出視為對所提供資料的不可信轉換，盡量減少敏感輸入，並保留人手審核。

如何驗證並維護登記冊？

步驟 9：雙向驗證追溯

測試「來源到登記冊」和「登記冊到來源」兩個方向的連結。由某個來源片段出發，審核人能否找到所有候選和已批准的義務行？由某一行出發，能否開啟確切的版本和定位？由某項義務出發，能否找到負責人、控制、預期證據、保證工作、例外和未決問題？

執行確定性檢查：

• 每條適用的行都引用已批准的來源版本和定位；
• 每次狀態轉換都有獲授權的審核人和日期；
• 每項義務都有一名負責人，或已上報；
• 每個控制和證據參考都能指向受管治的紀錄；
• 被取代的行連結到其後繼行，並保留歷史；
• 即將生效的日期和逾期覆核都清晰可見；
• 沒有模型產生的引用繞過來源驗證。

涵蓋率有助管理工作，但不能證明合規。已對應的控制可能設計欠佳、沒有運作或證據不足。

步驟 10：維護變更並挑戰登記冊

監察官方來源更新、合約修訂、政策批准、新的司法管轄區、產品改變、事故、保證發現和機構重組。把每項提示分派給能判斷該改變會否影響來源、適用性、義務、控制、證據或培訓的人。

為各行建立版本，不要覆寫。保留舊的來源、詮釋、決定、對應關係和生效期間。就影響重大的義務按既定週期和觸發條件覆核。ICO 的紀錄指引要求紀錄準確、及時，並隨處理活動的改變而維護。［2］

以抽樣和走查挑戰登記冊，但不要讓它自證。法律、合規、控制負責人、保證和內部審計各有不同的職責和獨立性要求。

覆核清單

• 範圍、來源層級和決定權限都已記錄。
• 每個來源都屬權威，並有版本、日期和定位。
• 候選文字與詮釋和適用性分開。
• 司法管轄區、實體、觸發條件、時間、例外和定義都已明確。
• 適用和不適用的決定都有合資格人員給出的理由。
• 每項已批准的義務都有一名負責人。
• 已對應控制，但沒有聲稱它們已運作。
• 預期、已收到和已核實的證據保持區分。
• 追溯在「來源到義務」和「義務到來源」兩個方向都可行。
• 變更保留被取代的歷史，並觸發影響覆核。

總結

• 提取義務之前，先管治來源清單。
• 保留確切的文字、版本、定位和語境。
• 把 AI 輸出視為候選結構，而不是法律詮釋。
• 由合資格審核人決定適用性，由負責人批准控制。
• 把控制設計與經核實的運作證據分開。
• 維持雙向追溯和版本紀錄。

常見問題

AI 能判斷哪些法規適用於公司嗎？

不能。它可以整理已批准的資料和問題，但適用性取決於現行法律、司法管轄區、實體、活動、合約以及合資格的法律或合規分析。

指南和法律可以放一起嗎？

可以互相連結，但要保留各自的來源類型、發出機構、版本和法律地位。不要把指引當作具約束力的法律呈現，亦不要讓法律脫離相關的詮釋。

一項義務應多細？

使用一個包含單一責任主體、行為或禁止、觸發條件、時間和一致適用性決定的單位。如果不拆分便會掩蓋不同的負責人、期限或例外，便拆成多行。

一份政策足以證明合規嗎？

不足夠。政策可以顯示設計和意圖。要評估相關控制是否已執行而有效，還需要運作證據和適當的保證工作。

來源沒有穩定頁碼怎麼辦？

使用條、節、款、段、標題或要求編號等結構定位，保留來源版本，並在有用時補充頁碼或擷取資料。

登記冊能替代法律原文嗎？

不能。它是索引和管理工具。詮釋和決定時，審核人必須回到權威來源和現時事實。

合規義務登記冊的記錄多久覆核一次？

訂立按風險而定的週期，並為法律更新、合約變更、新產品或新司法管轄區、事故、審計發現和控制改變設定事件觸發條件。

誰批准登記冊行？

合資格的法律或合規人員批准來源詮釋和適用性；問責的業務和控制負責人在管治框架下批准實施職責。

免責聲明： 本文提供的是一般性的教育資訊，不構成法律、監管、合規、會計或審計意見。法律、指引、合約和事實都會改變。請向合資格的專業人員尋求意見，並由獲授權的機構負責人作出決定。

來源

1. U.S. Department of Justice — Corporate Enforcement and Compliance — https://www.justice.gov/criminal/corporate-enforcement
2. UK Information Commissioner's Office — Documentation — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/
3. UK Information Commissioner's Office — Accountability framework — https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/accountability/
4. NIST — Artificial Intelligence Risk Management Framework: Generative AI Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 6 日。

延伸閱讀

• 如何負責任地使用 AI
• 建立需求追溯矩陣
• 如何用 AI 起草內部政策
• 如何用 AI 比較合約版本
• 編製風險登記冊