AI 可追溯性從奢侈品變成基礎設施
Runtime provenance enforcement 把 AI 回應的可追溯性從可選功能變成系統必備，這反映了 AI 應用從試驗到生產的轉變。
問題不在答案，在來源
用 AI 系統的人現在面臨一個尷尬的局面：模型給出的答案可能很有用，但你無法解釋它是怎麼來的。不是「為什麼這樣回答」的哲學問題，而是字面上的——這個回應引用了哪些資料、經過了哪些處理步驟、在哪個環節做出了什麼決定。
Dokis 提出的 runtime provenance enforcement 改變了這個遊戲規則。它在推理過程中強制記錄每一步的來源，讓可追溯性不再是可選項，而是系統架構的一部分。
從可選到必要
過去，大多數 AI 系統的思路是先讓模型工作，如果用戶問「你怎麼知道的」，再試著回溯。結果通常很尷尬——你能看到最終答案，但中間發生了什麼是個黑盒。
Runtime provenance enforcement 翻轉了這個邏輯。每一次查詢、每一次計算、每一次決策，系統都在同步記錄它的來源。這解決了實際問題：
- 當 AI 給出錯誤答案時，你能定位到具體是哪一步出了問題
- 在受監管的領域（金融、醫療），可追溯性本身就是合規要求
用戶信任的基礎變成「我能驗證」，而不是「我相信模型」。
架構層面的含義
這不只是加一個日誌系統那麼簡單。Runtime provenance 要求在推理過程中嵌入追蹤機制。
性能會有代價。每一步都記錄來源，必然增加計算開銷和存儲成本。但這是有意識的權衡——你在用性能換取可信度。
系統設計變得更複雜。不只要管理推理邏輯，還要管理推理過程中的元數據。這對工程師來說是額外的負擔，但對用戶和監管者來說是必要的透明度。
為什麼現在變成必要條件
AI 模型越來越被用在關鍵決策上。一個推薦系統出錯，用戶體驗差一點；一個醫療診斷系統出錯，後果可能很嚴重。在這種背景下，「我不知道為什麼」已經不是可接受的答案。
監管環境也在變化。歐盟的 AI 法案、各國的 AI 治理框架，都在要求系統能夠解釋自己的決策。這不是可選的企業美德，而是法律要求。
Dokis 的做法抓住了這個轉折點：不是把可追溯性當成事後補救，而是從一開始就設計進去。這樣做的成本更高，但換來的是真正的透明度，而不是假裝透明。
實務上的問題還沒解決
Runtime provenance enforcement 是對的方向，但它也帶來新的難題。當系統涉及多個模型、多個數據源時，怎麼保證追蹤的完整性？用戶真的會看這些追蹤信息嗎，還是只有在出問題時才會翻出來？追蹤信息本身的準確性怎麼驗證？
這些不是技術無法解決的問題，但它們說明一件事：可追溯性從架構問題變成了組織和治理問題。
現在的選擇已經很清楚了。你可以繼續用黑盒模型，接受「我不知道為什麼」的風險；或者從一開始就投入成本，讓每一個決策都有據可查。隨著 AI 應用的深化，第二條路會越來越成為標準配置。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。