監控資料跟稽核證據，中間有一段距離

前四週建立的日誌、Trace、Metrics，工程團隊看得懂，但稽核單位要的往往是另一種東西：「請證明你們的 AI 系統做的每一個影響客戶的決策，都有紀錄、可追溯、且有適當的人工監督。」 這篇處理怎麼把工程用的監控資料，轉化成能回答這類問題的稽核證據。

稽核單位通常會問的四類問題

可追溯性：某個特定客戶在某個時間點的請求，Agent 做了什麼、為什麼？ → 對應 Week 2 的結構化日誌（尤其 decision_summary）與 Week 3 的 Trace。這也是為什麼 Day 8 強調要記錄決策理由而非只記錄動作——只有動作紀錄，回答不了「為什麼」。

人工監督：哪些決策有人工審核？審核紀錄在哪？ → 需要在日誌中明確標記人工介入的節點，且紀錄要包含審核者身分與審核結果。

資料保護：客戶的個資有沒有被適當保護？ → 對應 Day 11 的敏感資訊處理政策。這裡要能提出的證據包括：遮罩機制的設計文件、存取控制設定、保存期限政策。

完整性：這些紀錄有沒有可能被竄改？ → 需要說明日誌的存取控制與保存機制。

設計原則：稽核需求要前置

最容易踩的坑是等到稽核前才發現資料不夠。例如稽核要求「證明每一次高風險決策都有人工審核」，但日誌裡根本沒有標記哪些是高風險決策、也沒記錄審核者是誰——這時候只能人工回溯拼湊，非常痛苦，而且往往拼不完整。

務實的做法是在 Week 2 設計日誌欄位時，就把稽核需求納入考量（呼應 Day 8 提過的「先列出未來想回答的問題」）。稽核單位想問的問題，就是那些「未來想回答的問題」的一部分。

跟法規框架的對應

如果你也在追團隊的 GCP Security 系列，那邊 Day 4 與 Day 29 談過台灣數位發展部的《人工智慧風險分類框架》，其中「缺乏透明性或可解釋性」這類風險項目，正是可觀測性能直接對應的——可觀測性不只是工程實務，它同時是治理框架裡「透明性」要求的技術落地方式。

待實測提醒：不同產業的稽核要求差異很大（金融、醫療、公部門各有規範），本文提供的是通用框架。實際導入時建議直接跟你們的稽核或法遵單位確認他們會問什麼，再反推需要保留哪些資料。

這篇的檢查清單

• [ ] 日誌欄位設計時是否已納入稽核需求，而非事後才補？
• [ ] 人工審核節點是否有明確標記，含審核者身分與結果？
• [ ] 是否能證明日誌的完整性（存取控制、保存機制）？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。