EU AI Act 第 30 條文件核對清單：高風險 AI 供應商必須記錄的內容

EU AI Act 對高風險 AI 系統施加了最詳細的文件要求。具體而言，第 30 條涉及日誌記錄——對事件的自動、持續記錄，使主管機關能夠稽核系統行為、將決策追溯到特定輸入和模型版本，以及調查事件。

如果你在歐盟開發、部署或進口高風險 AI 系統，第 30 條適用於你。此核對清單涵蓋每項要求，解釋其實際含義，並識別造成合規風險的常見實施差距。

適用對象

EU AI Act 區分了兩種各自承擔義務的角色：

供應商是開發高風險 AI 系統並將其投放歐盟市場或投入服務的組織。如果你構建了模型或系統，你就是供應商。供應商承擔第 11 條（技術文件）和第 17 條（品質管理系統）下的主要文件負擔，以及第 12 條（輸入第 30 條用於部署者）下的日誌記錄義務。

部署者是在其專業活動過程中使用高風險 AI 系統的組織。即使你沒有構建模型，你也可能是部署者——如果你在運營中使用供應商的高風險 AI 系統，你就是部署者。第 26 條設定了部署者義務，第 30 條具體說明了部署者必須記錄的關於其使用系統的內容。

許多組織既是供應商又是部署者——他們構建 AI 系統（供應商）同時也部署他人構建的 AI 系統（部署者）。

高風險 AI 系統主要在法案附件 III 中定義。這些包括用於以下領域的系統：

• 生物特徵識別和分類
• 關鍵基礎設施管理
• 教育和職業培訓（入學、評估）
• 就業和工人管理（招聘、績效、晉升）
• 基本私人服務和公共福利獲取（信用評分、保險、社會福利）
• 執法
• 移民、庇護和邊境管控
• 司法行政和民主程序

如果你的系統在這些領域中的任何一個運行，它幾乎肯定是高風險的。有疑問時，視為高風險並諮詢法律顧問。

了解條款格局

EU AI Act 有多個文件要求，常被混淆。它們的關係如下：

第 30 條關於你在運行期間記錄什麼。它與第 11 條的技術文件要求和第 17 條的品質管理要求有所不同——且是額外要求。

適用日期

對於大多數高風險 AI 系統（附件 III 涵蓋的），完整要求於 2026 年 8 月生效。附件 I 涵蓋的系統（受監管產品如醫療設備、航空設備）有更長的過渡期。

如果你在 2026 年初閱讀此文，你在截止日期前實施合規日誌基礎設施的時間有限。

---

第 30 條合規核對清單

第 30 條第 1 款：自動事件日誌記錄

法案要求高風險 AI 系統能夠在「系統整個運行生命週期中」自動生成事件日誌。

實施要求：

[ ] AI 系統（或其周圍的部署基礎設施）能夠自動記錄事件——這不能是手動流程

[ ] 日誌記錄在系統整個運行生命週期中持續進行，而非基於樣本或僅在出錯時觸發

[ ] 日誌安全存儲，有存取控制限制誰能讀取

[ ] 有防篡改機制——哈希鏈、一次寫入存儲或等效方式——使日誌寫入後無法在不被偵測的情況下修改

[ ] 日誌記錄從部署第一天起就在生產環境中啟用，而非之後才添加

常見差距：完全依賴供應商提供 API 的組織往往假設供應商處理日誌記錄。請明確核查你的協議——許多供應商提供基本使用日誌，但不提供第 30 條要求的詳細、可歸屬於部署者的輸入/輸出日誌。你可能需要在自己的集成層中實施日誌記錄。

---

第 30 條第 2 款：可追溯性要求

日誌必須足以將事件追溯到特定輸入、特定模型版本和特定使用期間。

實施要求：

[ ] 每個 AI 輸出都記錄有：時間戳（UTC）、模型版本或識別符，以及產生它的相關輸入

[ ] 日誌包含足以識別使用期間的資訊（部署配置的開始和結束日期）

[ ] 日誌識別每個記錄事件的負責部署者（如果多個部署者共享基礎設施則相關）

[ ] 對於用於特定個人（就業決策、信用決策等）的系統：日誌必須允許識別哪些個人被處理及何時

[ ] 日誌粒度足以識別系統何時在其預期目的之外或在其正常操作條件之外運行

[ ] 日誌不只記錄成功的推理，還記錄：錯誤、超時、拒絕的輸入和邊緣案例

常見差距：只記錄成功輸出而不記錄失敗的系統，錯過了最可能在事件調查中相關的事件。導致系統默默失敗的輸入——返回默認輸出而非錯誤——在沒有完整日誌記錄的情況下特別難以偵測。

---

第 30 條第 3 款：存儲和存取

日誌必須以耐久、可授權方存取且受損失保護的方式存儲。

實施要求：

[ ] 日誌存儲的期間適合預期目的和適用法規

法案本身沒有規定單一保留期——它引用了 AI 系統的預期目的。實際指引：對於做出具有重大後果的個人層面決策的系統（信用、就業、福利），考慮到適用的時效期限和監管調查時間表，至少 5 到 10 年是合理的。對於後果較輕的系統，EU AI Act 早期指引建議最少 6 個月。

[ ] 存取控制確保日誌只能被以下人員存取：授權的內部人員（稽核、合規、法律）、國家主管機關（應要求）和授權的外部稽核人員

[ ] 日誌可在不無故延遲的情況下應要求提供給國家主管機關——這裡的「要求」指監管調查，而非例行報告

[ ] 日誌受意外丟失或毀損的保護——備份程序、冗餘存儲和資料保留政策均適用

[ ] 日誌存取本身受稽核——誰存取了日誌、何時、出於什麼目的，本身也應被記錄

常見差距：組織將日誌存儲在從運營資料政策繼承的短期保留計劃系統中。確保 AI 決策日誌被單獨分類，不受一般資料生命週期管理的約束，以避免被較短計劃清除。

---

第 30 條第 4 款：部署者特定要求

即使供應商提供基礎 AI 系統，部署者對其特定部署環境也有獨立的日誌記錄義務。

實施要求：

[ ] 部署者維護涵蓋其特定部署的日誌：部署了哪個系統、在哪種配置中、用於哪種用例

[ ] 部署者日誌包括：部署開始日期、部署結束日期（或「進行中」），以及部署期間做出的任何配置更改（提示更改、閾值調整、集成更改）

[ ] 部署者日誌記錄系統健康監控事件：性能警報、錯誤率、準確性指標變化

[ ] 部署者維護所有應用的人工監督措施記錄——對於人在回路系統，這意味著每個人工審閱決策的日誌

[ ] 如果部署者相對於供應商指示修改了系統行為（不同的提示、不同的閾值、不同的輸入預處理），這要被記錄文件，其對性能的影響要被評估

常見差距：部署者有時將人工監督視為政策承諾而非已記錄的控制。「我們有人在回路」但沒有每個人工審閱決策的帶時間戳、可稽核的記錄，不滿足第 30 條第 4 款。人工審閱決策本身是必需的日誌事件。

---

附件 IV：技術文件（供應商要求）

附件 IV 規定了供應商在將高風險 AI 系統投放市場或投入服務前必須準備的技術文件。雖然這是供應商義務而非第 30 條日誌記錄要求，但從供應商處接收 AI 系統的部署者應驗證此文件是否存在。

必需的文件要素：

[ ] AI 系統的一般描述，包括其預期目的和投放市場的版本

[ ] 開發流程描述：

• 做出的設計選擇及其理由
• 訓練資料特徵：來源、標記方法論、資料準備程序、數量
• 使用的訓練和測試流程
• 性能指標和驗證結果

[ ] 系統監控、運行和控制文件：

• 技術能力和限制
• 已知或可預見的風險，包括誤用帶來的風險
• 準確性指標（適用時按相關子群體細分）
• 健壯性和網路安全措施

[ ] 此系統所需的人工監督措施：

• 需要什麼人工監督（人在回路、人在環上或其他）
• 技術和操作上如何實施人工監督
• 誰負責實施

[ ] 整個生命週期中對系統所做的更改（版本歷史）

[ ] 對基本權利和非歧視背景下的風險評估

對於接收供應商系統的部署者：在部署前向你的供應商索取附件 IV 文件包。無法為高風險系統提供此文件的供應商尚未完成其在法案下的義務。這個差距需要你來管理——在沒有文件的情況下部署使你與供應商一起面臨監管風險。

---

實際實施指引

什麼算作日誌記錄目的的「事件」

法案使用了「事件」一詞，但沒有窮舉定義。基於監管背景，以下內容至少應被記錄：

針對不同資料類型構建日誌保留策略

AI 決策日誌通常包含個人資料——模型的輸入可能包括姓名、財務資料、健康資訊或其他個人識別資訊。這在 EU AI Act 的日誌記錄要求與 GDPR 的資料最小化和存儲限制原則之間造成了張力。

實際解決方法：

1. 將運營日誌與決策日誌分開。運營日誌（性能指標、錯誤率、延遲）可以按較短計劃保留。決策日誌（輸入、輸出、模型版本、人工審閱決策）需要更長的保留期，必須在特定法律依據下管理。

2. 在可能的情況下對決策日誌進行假名化。記錄假名案例識別符而非直接個人識別符。在具有適當存取控制的地方單獨維護映射表。這降低了日誌的 GDPR 敏感性，同時保持可追溯性。

3. 記錄日誌保留的法律依據。根據 GDPR，你需要處理日誌中個人資料的法律依據。對於受監管用途（信用、就業、福利），法律依據通常是遵守法律義務（EU AI Act 本身）。在你的資料處理記錄中明確記錄這一點。

資料主權問題

第 30 條日誌本身可能包含個人資料，觸發 GDPR 關於該資料可以存儲在哪裡的義務。如果你的 AI 系統處理歐盟居民的資料，這些處理的日誌通常應存儲在歐盟內——或有充分性決定的司法管轄區——除非你有有效的轉移機制。

這對使用雲端日誌基礎設施的組織有實際影響：在部署前而非在主管機構詢問後，確認你的日誌存儲區域符合你的資料駐留承諾。

---

連接到實施

從頭開始實施第 30 條合規需要在集成層（你的應用程式調用 AI 系統的地方）進行監測，一個帶適當存取控制和保留政策的日誌存儲系統，以及一個在結構化、可查詢的日誌中記錄人工監督決策的審閱流程。

Ertas Data Suite 直接從資料處理管道生成與 EU AI Act 第 30 條兼容的稽核日誌。每次轉換都記錄有時間戳和操作員 ID。日誌是防篡改的，可以結構化格式匯出用於監管提交。對於在本地運行的組織（資料不能離開機構的氣隙環境），Data Suite 的原生桌面架構意味著日誌在本地生成和存儲——沒有資料離開你的基礎設施。

預約與 Ertas 的探索通話 →

合規核對清單摘要

在 2026 年 8 月截止日期前將此用作準備狀態評估：

基礎設施： [ ] 在生產環境中啟用自動日誌記錄（非手動，非基於樣本） [ ] 防篡改日誌存儲就位 [ ] 保留政策設置（最少 6 個月；具有重大後果的決策更長） [ ] 存取控制實施並受稽核 [ ] 日誌資料的備份和恢復程序

內容： [ ] 每次推理都記錄有：時間戳、模型版本、輸入、輸出 [ ] 每個決策的人工監督決策均已記錄 [ ] 配置更改已記錄 [ ] 錯誤和邊緣案例已記錄

治理： [ ] 從供應商處收到附件 IV 技術文件（或對你開發的系統在內部生成） [ ] 日誌保留的資料處理法律依據已記錄 [ ] 日誌資料駐留已確認（歐盟或充分性司法管轄區） [ ] 可在可接受時間框架內向主管機關提供對日誌的存取

部署者特定： [ ] 部署開始/結束日期和配置更改已記錄 [ ] 人工審閱決策已按要求記錄 [ ] 與供應商指示的偏差已記錄文件

已完成此核對清單的組織在第 30 條方面處於可辯護的位置。尚未完成的組織應優先處理基礎設施項目——日誌基礎設施需要時間才能正確實施，而過去決策的事後日誌記錄是不可能的。