決定我們接哪些工作的運營限制
當一個 $50M-$1B 區間的中端市場 IT 團隊開始與我們討論 AI 運營合作時,第一道技術過濾器並不是「這個工作流程能不能自動化?」—— 大部分都可以。第一道過濾器是:這個工作流程是否能被儀器化以輸出稽核證據?
如果答案是否定的,我們就不接。原因不是這個工作流程沒有價值,也不是我們蓋不出來。是因為一個沒有稽核證據輸出機制的工作流程,其運營成本會以無法在初期 SOW 中顯示的方式逐季複利累積 —— 整個合作架構在那種拖累下會崩壞。
這就是我們說稽核證據輸出是 運營成本底線 時的真正意思。不是錦上添花。不是 Phase 2 的交付項。而是工作流程在經濟上根本不值得運營的那條底線。
這篇文章梳理我們為什麼堅守這條線、「能被儀器化以輸出稽核證據」在基底層 (substrate) 究竟長什麼樣,以及我們真實接過、拒絕過、延後過的三種工作流形態。
為什麼有這條底線
在我們的客戶區間中,每個 AI 工作流程都同時承受三股壓力:
董事會壓力。董事會想要在一張季度幻燈片上看到:AI 估産正在做什麼、不在做什麼、哪裡出過事、修復了沒。「相信工程團隊,他們掌握住了」這種答案大約在 2024 年就不再是可接受的回應。
稽核壓力。SOC 2 Type II、EU AI Act 合規評估、NIST AI RMF 度量控制、HIPAA BAA 續約、ISO/IEC 42001 管理系統稽核 —— 每一項都用不同術語問同一個問題:證明 AI 做了什麼、在何時、依誰的授權、用了什麼數據、針對哪條政策。
監管 + 客戶採購壓力。採購 AI 服務的企業客戶需要證據鏈。受監管的產業(醫療、金融、政府、法律)依法強制要求。這條門檻不會降低。
無法輸出稽核證據的工作流程同時失守三條陣線。運營這種工作流程的團隊最終會在期限壓力下逆向重建證據 —— 翻 Slack 歷史記錄、截圖 CRM 記錄、向 LLM 供應商詢問其隱私政策沒有承諾的保留窗口。這項工作比一開始就建好儀器化要貴。它在防禦上也更弱:重建出來的證據在結構上比直接輸出的證據要薄。
工程主導的 IT 團隊能買到最便宜的保險,就是拒絕運營任何無法按需輸出證據的工作流程。這條拒絕,就是運營成本底線。
「能被儀器化以輸出稽核證據」究竟是什麼意思
「你有稽核日誌嗎?」這問題有個誘人的答案:有的,我們有 logs 表;每個動作都生一筆紀錄。 這是 SaaS 開關式答案,在我們這個客戶區間結構上不夠用。
稽核證據儀器化有四項屬性,按架構份量排序:
1. 歸因到具名 actor —— 包括 agent 本身。 每個動作記錄誰發起(人類使用者、排程觸發器,或是哪個具體的 AI agent)。每個 agent 自有身份是最多平台搞錯的部分:如果「AI 做的」全部歸到一個稽核主體,你就無法回答「週六凌晨 2:47 是哪個工作流程修改了客戶記錄?」十層治理框架把這列為 Layer 1 是有道理的。
2. 從輸出回溯到輸入 + Prompt + 模型版本的可追溯性。 當 AI 產生一個動作時,六個月後需要能重建三件事:AI 看到的輸入數據、Prompt 模板版本(不是渲染出的字串 —— 是模板)、產生輸出的模型版本。少了任何一項,你就無法重放這個決策,也就無法為它辯護。
3. 雜湊鏈完整性 (或等效的篡改偵測)。 僅追加的稽核表是必要但不充分。對於 SOX、FDA、EU AI Act 的證據場景,證據完整性需要在密碼學上可驗證 —— 每筆日誌用你的資安團隊掌控的金鑰做 HMAC 簽章,或者跑 Merkle 風格的雜湊鏈。重點不是要做到密碼學完美;是要讓篡改變得「可被偵測」,而不是「悄然可能」。
4. 可匯出到你的資安團隊已運作的 SIEM 格式。 鎖在供應商 UI 裡的稽核證據在運營上沒用。證據必須流到你既有的資安基礎設施 —— Splunk、Sentinel、syslog、OCSF —— 落到你的團隊調查非 AI 事件時已使用的同一個調查介面。如果你的 CISO 為了調查 AI 工作流程要學新儀表板,這就不是可用的證據;這是合規劇場 (compliance theater)。
任何一項屬性失守的工作流程就失守底線。我們不運營。
三個例子 —— 以及這個模式
以下都是運營匿名化的;客戶特定細節已遮蓋。重要的是架構模式。
例子 A:Day 1 就運營的工作流程。 從收件郵件抽取發票、依 ERP 結構化、經過審批閘門後過帳。稽核證據輸出直接:郵件來源有 Message-ID;抽取步驟記錄 Anthropic Sonnet 4.6 + Prompt 模板 v2.3 + 結構化輸出;審批者的決策與完整上下文成為一筆雜湊鏈紀錄;ERP 寫入是冪等的並有自己的 correlation ID。四項屬性都到位。在 Phase 1 上線。
例子 B:我們沒接的工作流程。 在一個未審核的聊天頻道上做客服回覆生成,該 LLM 供應商沒有暴露 Prompt 模板版本控制、該聊天平台不在重試時保留 message ID、客戶端的技術堆疊裡沒有可落地證據的僅追加稽核基底。我們能不能蓋繞道方案?能 —— 外掛日誌、第二系統對帳、截圖式證據。我們拒絕。重建開銷會在穩態運作中佔總運營成本的 40-60%。客戶兩個季度內就會停掉,而我們會在收尾期間吸收運營一個無法稽核工作流程的聲譽風險。
例子 C:我們延後到儀器化成熟才做的工作流程。 預約排程的外撥語音,雖然轉錄可用,但客戶端的語音 agent (Vapi) 還沒提供我們需要的每通話證據輸出。Phase 1 的範圍框在相鄰的工作流程上(經由非同步管道做進線分流 + 排程),讓語音基底再成熟兩個季度,然後在 Phase 2 加入語音 —— 此時證據管線已閉環。同一個工作流程,延到底線達成才做。
三個例子的共同模式:底線決定一個工作流程是加入運營基底,還是留在外面。「我們之後再加稽核」就是失敗模式。等「之後」到來,證據債務已累積到無法乾淨清償。
CIO 通常問什麼 vs 應該問什麼
評估 AI 運營合作夥伴時,最常被問的問題是某種版本的:「你們有沒有 SOC 2 合規?」 —— 這必要,但把合規當成狀態(打勾)而非基底層架構承諾。
更好的問題,有經驗的 CIO 在跟 AI 供應商過完一輪稽核週期後會問的:
- 每個 agent 在運行時記了什麼 —— 我能匯出 schema 嗎? (測試歸因是真的還是嘴上說。)
- 帶我從某個輸出決策追到 Prompt 模板版本與模型版本。 (測試可追溯性。)
- 帶我看雜湊鏈驗證路徑。你的金鑰託管故事是什麼? (測試完整性。)
- 你的 SIEM 匯出形態長什麼樣?能秀一筆 Splunk 格式的範例事件嗎? (測試 SIEM 可匯出性。)
- 講一個你們因為稽核基底不到位而推掉的工作流程。 (測試運營成本底線是真的還是行銷文案。)
最後一題是診斷題。如果答案是「我們從沒推掉過工作流程」,那底線就不存在。如果答案具體 —— 包含工作流程形態、缺的儀器化、決策本身、替代方案 —— 那底線就是結構性的。
Phase 1 SOW 承諾
我們的 Phase 1 合約在 SOW 中明文寫下底線承諾:任何加入運營基底的工作流程必須輸出符合上述四項屬性的稽核證據;任何無法符合的工作流程,要麼排除在範圍之外,要麼延到未來某個 phase 並附帶明確的儀器化里程碑。我們公開這個承諾,因為我們希望它具有診斷性 —— 既對我們(它約束我們的範圍決策)也對客戶(它告訴他們應該對任何 AI 運營合作夥伴期待什麼,不管是不是我們)。
你可以在我們的 Reference Architecture 頁面看到輸出這些證據的基底(§5 專門講稽核軌跡元件,§6 講信任邊界)。你可以在 /10-layer-assessment 用十層治理框架為自己組織的稽核證據態勢做基線評估 —— Layer 2 (稽核軌跡) 是相關段落,但 Layer 1、3、6、10 也形塑「可被儀器化」在實務上的意義。
底線不是供應商的宣稱。它是讓合作經濟學在雙方都成立的結構性限制。能輸出證據的工作流程是我們能在不複利累積風險下運營的工作流程;不能輸出證據的工作流程則是在合作費用 (engagement-fee) 規模下不值得運營的工作流程。
底線以下的東西還不是工作流程。它是一份等候儀器化的工作流程草稿。