稽核軌跡不是系統日誌的加強版
許多團隊一開始會把 AI 稽核設計想成一般 log：記錄請求時間、使用者、模型回應與錯誤訊息。這些資訊有用，但不足以回答企業真正會問的問題。例如某個採購建議是根據哪份供應商資料？哪一版提示詞要求模型優先考慮交期？系統是否查過 ERP 的即時庫存？答案送出前是否經過人工核准？如果只能看到最後輸出，就很難判斷問題來自模型、檢索資料、工具呼叫、權限設定，還是使用者輸入本身。
我們通常會把稽核軌跡定義成一條可驗證的事件鏈，而不是一段文字紀錄。事件鏈至少包含使用者請求、身份與權限狀態、提示詞模板版本、模型與參數、RAG 檢索結果、工具呼叫、外部系統回傳、政策檢查、最終輸出，以及後續是否被複製、送出、寫回系統或人工覆核。這樣設計的好處是，當輸出被質疑時，工程團隊可以沿著鏈條定位責任點，而不是只能說模型當時就是這樣回答。
重點不是追求絕對完整，而是讓每一個會影響輸出的關鍵因素都有穩定識別碼與版本。提示詞要有版本，知識文件要有版本，向量索引要能回推來源文件與段落，工具呼叫要有 request id，外部系統資料最好能留下查詢條件與回傳摘要。少了這些，事後重播就會變成猜測。
先決定要追溯哪一種責任
可追溯設計需要從使用情境反推。客服 AI、內部知識助理、財務報表摘要、設備異常判讀、LINE 官方帳號自動回覆，對稽核的要求不同。客服重點可能是話術一致性與個資處理；財務與法務重點是引用來源、版本與人工審核；IoT 平台重點是感測資料時間窗、資料品質與告警規則。若一開始沒有定義責任問題，最後常會留下大量難以使用的日誌，卻缺少真正需要的證據。
工程上可以先把追溯需求分成幾類。第一是來源追溯：AI 回答用了哪些文件、資料列、API 回傳或使用者輸入。第二是決策追溯：系統如何選擇工具、套用規則、過濾內容與組合答案。第三是操作追溯：AI 輸出後是否觸發寄信、建立 CRM 紀錄、更新 ERP 欄位或通知 LINE 使用者。第四是責任追溯：誰啟動流程、誰核准、誰覆寫、誰讀取過敏感輸出。
- 低風險問答可以記錄輸入、輸出、檢索文件 id、模型版本與錯誤狀態，避免過度增加成本。
- 中風險內部流程應加入提示詞版本、工具呼叫參數、權限檢查結果、資料來源版本與使用者動作。
- 高風險自動化需要不可竄改紀錄、人工核准事件、輸出雜湊、外部系統寫入結果與清楚的回滾資訊。
- 含個資或機敏資料的流程要同時設計遮罩、加密、留存期限與查閱權限，因為稽核紀錄本身也可能變成敏感資料庫。
RAG 系統的可追溯重點在資料版本
RAG 系統常見的錯誤是只顯示引用連結，卻沒有保留可重建的檢索脈絡。使用者看到來源連結，不代表工程團隊可以事後知道當時向量資料庫裡是哪一版文件、切 chunk 的方法是什麼、檢索參數如何設定、有哪些候選段落被排除。文件若後來被更新，單純保存 URL 也無法證明模型當時看到的內容。
比較穩健的做法是把知識生命週期納入稽核設計。每份文件進入索引時產生 document id、version id、chunk id 與內容雜湊；每次回答保存實際命中的 chunk id、排序分數、rerank 結果與送入模型的上下文摘要。若文件來自 Google Drive、Confluence、CRM、ERP 或內部檔案系統，也要記錄來源系統、同步時間、權限快照與同步工作版本。這不只是為了稽核，也能幫助排查為什麼某些答案引用了過期資訊。
這裡有一個重要取捨：保存完整 prompt 與完整上下文最方便重播，但也最容易累積敏感資料；只保存 id 與雜湊比較安全，但除錯與稽核時需要回查原始資料。實務上常用分層策略：短期保存完整上下文供除錯，中長期保留結構化事件、版本 id、雜湊與必要摘要，並對敏感欄位做遮罩或加密。留存策略要和法務、資安與資料擁有者一起決定，不能只由工程端預設。
讓紀錄可查、可控、可重播
稽核資料若只能由工程師進資料庫查詢，營運與管理單位很難真正使用。好的設計通常會提供不同層級的檢視：客服主管看對話、來源與處理狀態；資安人員看存取、權限與異常行為；工程師看 trace id、retrieval id、tool call、latency 與錯誤堆疊；資料管理者看文件版本與同步狀態。這些檢視可以共用同一批事件資料，但權限與遮罩規則必須不同。
可重播能力也要務實看待。AI 回答不一定能完全重現，因為模型服務、參數、外部資料與時間狀態都可能改變。因此我們比較重視可解釋重播，而不是保證逐字相同。系統應能重建當時使用了哪些輸入、哪些檢索片段、哪些工具結果與哪些政策檢查，再用相同或替代模型跑一次，協助判斷問題來源。若業務流程要求高度一致性，則應降低模型自由度，將關鍵決策交給規則、工作流或人工核准，而不是期待生成模型自行維持一致。
最後，要把稽核設計放進交付流程，而不是等上線後補。資料表、事件命名、保留期限、管理介面、告警條件與權限模型都需要在架構階段討論。對多系統整合專案來說，AI 的輸出通常會連到 LINE、ERP、CRM、雲端資料庫與內部 API；越早把 trace id 穿過這些邊界，越容易在問題發生時找到真相。這也是企業 AI 專案很適合由熟悉整合、資安與維運的團隊一起設計的原因。