EU AI Act 審計準備：你的 AI 執行時能交出證據嗎

先給結論：審計查的不是你的模型，而是你的執行時能否為每個 AI 動作交出“誰授權、動了什麼、證據在哪”——而可審計性補不上，只能在動作發生時就記下。

設想一個會議室。

一家在歐洲展業的保險公司，請了外部審計做 AI Act 的合規預演。審計員坐下，開啟電腦，沒有寒暄，問了第一個問題：

“把上個月那筆被 AI 自動標記為’高欺詐風險’、因而被拒賠的理賠，完整經過調出來給我看——誰觸發的、AI 依據哪些資料、用了哪條規則、誰複核了、客戶申訴走了什麼流程。”

然後房間安靜了。

不是因為這筆拒賠一定錯了，而是因為這筆決定裡 AI 參與的那一段，在系統裡沒有一個完整、連續、不可抵賴的地方能調出來。理賠資料在一個系統，AI 的打分服務在另一個，複核記錄在第三個，而且和人工操作不在一本賬上。要拼出審計員要的那條線，得三個團隊翻三天日誌，還不保證拼得齊。

這家公司當時沒被罰——那只是預演。但 AI Act 對高風險 AI 系統的罰則，是按全球營業額的百分比計的，量級足以讓任何一家公司認真對待。而預演暴露的問題，是幾周後真審計會原樣再問一遍的。

這個安靜的會議室，就是很多企業在 AI 治理審計中會面對的場景。

倒計時是真的，而且很近

按歐盟官方時間線，AI Act 於 2024 年 8 月 1 日生效，多數規則將在 2026 年 8 月 2 日開始適用；部分義務按系統型別和條款分階段推進。對在歐洲有業務、或服務歐洲客戶的企業，關鍵不是背日期，而是先問：如果今天抽查一筆 AI 參與的業務動作，你能不能把證據鏈當場調出來？

很多團隊不是不想合規，而是真到那個會議室裡，答不上來。

審計查的不是模型，是執行時

很多團隊為合規做的第一件事是評估模型——有沒有認證、會不會輸出有害內容。這些重要，但不是審計的主戰場。監管真正要的，是你能否為每一次 AI 觸碰業務的動作說清三件事：

審計員會問	它在查什麼	答不上來的後果
這些資料處理得合法嗎？	資料在哪、誰能讀、有沒有出過歐盟	資料駐留違規，CLOUD Act 暴露
這個動作誰授權 AI 做的？	拒賠、放款這類動作按誰的許可權算	責任無法歸屬，動作不可控
AI 參與的那步留痕了嗎？	能否拿出完整、不可抵賴的證據鏈	審計直接失敗

沒有一個問題是關於模型的。它們全都關於模型之外那一層——承載資料、強制許可權、記錄證據的執行時。

AI Act 對”高風險系統”到底要什麼

這不是抽象的”要合規”。AI Act 對高風險 AI 系統（理賠、信貸、招聘、關鍵基礎設施這類）點名列了幾項硬義務，值得一條條對照——因為它們幾乎全部落在執行時，不在模型：

AI Act 的要求	落在哪一層	模型能提供嗎
自動記錄事件日誌（可追溯）	執行時的審計賬	不能，模型不留痕
人類監督（關鍵決策可介入、可推翻）	執行時的審批與流程	不能，要靠流程強制
決策可解釋（依據了什麼）	執行時記錄的輸入與規則	部分，但不可抵賴的記錄在執行時
資料治理（來源、許可權、駐留）	執行時的許可權與部署	不能

你會發現，模型再強，這張表它一欄都打不了勾。這正是那麼多團隊”模型選得很認真、合規卻過不了”的根因——他們在錯的那一層用功。監管要的東西，結構性地長在執行時上。

買個合規工具不就行了？

最自然的反應是：市面上有一堆”AI Act 合規平臺”，供應商也都在宣傳自己合規，籤個 DPA、拿份認證，不就把這事外包了？

這條路能解決一部分，但解決不了那個會議室裡的問題。

合規工具和認證做的是記錄與背書：它告訴監管”我們有流程、有文件、有資料處理協議”。但審計員要的不是”你有沒有流程”，是”把這一筆的完整經過調出來”。文件證明不了某一次具體動作的合法性，DPA 也回答不了’這筆拒賠是 AI 依據哪條許可權做的、誰複核的’。 這類證據只能由真正執行那個動作的執行時，在動作發生的當下記下來。買工具能幫你管住”制度層”，管不住”動作層”——而審計追到最後，問的總是某一個具體動作。

可審計性，是補不上的

這就引出一個很多人沒意識到的硬道理：合規不是一份你在 Q3 趕出來的文件，而是一個系統要麼具備、要麼不具備的屬性。

那條審計員想要的證據鏈，必須在動作發生的那一刻就被記下來。如果執行時當時沒記，8 月之前再怎麼突擊，也變不出上個月那筆拒賠的真實經過——你只能”重建”，而重建出來的記錄，審計員一眼就知道不能採信。

這就是為什麼”先上 AI、合規以後再說”在 2026 年是個危險賭注：你賭的是審計不會問到那些當時沒記的動作。一旦問到，那段時間的所有 AI 決策就成了一片無法舉證的空白。

去審計室之前，先用這五個問題自查——任何一個答不出”是”，那一項就是你的風險點：

隨便挑一筆 AI 參與的業務動作，能不能當場調出它的完整經過？
許可權是執行時強制的，還是寫在提示詞裡的？
人和 agent 的動作，是不是記在同一本審計賬上？
這些資料和處理過程，落在誰的管轄權之下？
出了問題，能不能一鍵停下某個 agent 或某類動作？

為什麼”把規則寫進提示詞”過不了這一關

不少團隊其實做了治理，只是做錯了地方——寫進了提示詞。“你只能查當前使用者有許可權的資料""高風險理賠要人工複核”，平時看著也管用。但它過不了審計，兩條原因都致命：

第一，提示詞是建議，不是控制。 它靠模型”願意聽話”生效，一次越獄、一個沒覆蓋的邊界就被繞過。審計員問”你怎麼保證某類理賠一定經過人工複核”，“我們在提示詞裡寫了”不是能簽字的答案。

第二，提示詞不產生記錄。 審計要的是結構化、不可抵賴的證據，提示詞給不了。

合規真正要求的，是把治理從”提示詞裡的建議”挪到”執行引擎裡的強制”——許可權在每次讀寫時被執行時核驗，審計是動作的天然副產品。

CADA 之後，“資料在哪”成了硬指標——但自託管不是免罪符

歐盟圍繞雲、AI 和資料主權的討論，把另一件事推到臺前：你的資料和 AI 處理過程，究竟在誰的管轄權之下？這一問直接指向部署形態。把讀取真實業務資料的 AI 執行時交給一個你無法審視內部的外部 SaaS，合規簽字會變得更難。自託管能改善資料駐留、第三方暴露和可見性——要自託管的不一定是模型，而是承載物件、許可權、工具、審批和審計證據的那個執行時。

但要誠實地說一句：自託管不是免罪符，它是一筆交易。 當執行時跑在你自己的基礎設施上，打補丁、輪換金鑰、保證日誌不丟、出事一鍵熔斷——這些操作和舉證責任，也一起落到你頭上。你換來的是控制權，代價是責任。反過來，若你希望讓別人替你擔這份責任，通常意味著把資料也交給他。這筆賬沒有白拿的一邊，得看哪邊的代價你擔得起、簽得了字。

一個能被簽字的執行時，長什麼樣

把上面的要求倒過來，就是驗收清單。最直接的檢驗，不是看產品介紹，是看它能不能當場吐出審計員要的那條記錄。在 ObjectOS 上，開頭那筆拒賠調出來是這樣一條：

{
  "event": "claim.decision.update",
  "actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
  "object": "ins_claim/CLM-88231",
  "decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
  "model_evidence": ["device_mismatch", "velocity_anomaly"],
  "permission_checked": "claims_adjuster → allowDecide: true",
  "human_review": { "rule": "fraud_high → 必須人工複核", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
  "timestamp": "2026-05-12T09:31:02Z"
}

這條記錄裡，誰、做了什麼、AI 依據什麼、命中哪條許可權、誰複核的、何時——全在。它不是事後補的工程，是 agent 以受監督身份呼叫受治理工具時，執行時順手落下的一筆。人和 agent 走同一套許可權引擎、記同一本賬。業務定義（物件、許可權、複核流程）則是你倉庫裡可 diff、可追溯的後設資料——審計員問”哪類理賠必須人工複核”，答案不在某人腦子裡，在流程定義裡寫著。

結語

離 2026 年 8 月 2 日已經很近。回到那個會議室：如果審計員現在就坐下，問你要上個月某筆 AI 決策的完整經過，你的系統能不能在那一刻、不靠三個團隊翻三天日誌，把它吐出來？

答不上來，幾乎從不是因為模型不行，而是因為治理被放錯了層——放進了提示詞、外包給了制度文件，而不是落進執行時。把它挪回執行時，那條證據鏈才會在你需要之前就已經在那裡。這件事補不上，只能現在就讓它成立。

npm i -g @objectstack/cli && os start

讓一個 agent 以某個使用者的身份去改一條資料，然後翻開審計記錄——你會看到審計員想要的那條線，本來就在。