KPMG 這招把 SaaS 變代理人

以前是人先點 SaaS，現在是 AI 先接手流程，SaaS 退回當紀錄庫。

我盯 enterprise 軟體很久了，越看越煩。介面越做越滿，儀表板越疊越多，最後工作還是卡在五個分頁、三個簽核、外加一串沒人想接的 Slack。最怪的地方是，很多團隊把 AI 貼在舊系統上面，就說自己在做轉型。結果呢？使用者還是要自己找畫面、找資料、找流程、找人救火。這種東西不叫 AI-native，我只覺得像把霓虹燈貼在破牆上。

我會開始注意 KPMG 這份公告，是因為它講法比較老實。原始來源在這裡：KPMG and OpenAI form Strategic Alliance to Advance AI-Native Enterprise Workflows。它不是在賣一個「聊天機器人加在旁邊」的故事，而是在講 AI 變成工作入口，企業應用繼續當紀錄來源。這個切法，才像真的有做過 enterprise 的人會講的話。

別再把 AI 當功能貼紙

“The alliance is an important milestone in KPMG’s effort to help clients move beyond application-centric experiences toward a new enterprise operating model where AI becomes the system of engagement, and enterprise applications continue to serve as the systems of record.”

翻譯一下就是：舊 app 還在，但它不該是大家每天盯著看的主角。AI 變成前台入口，幫人把事情跑完；SaaS 留在後面，負責把資料記準、把規則守住。

我之前做過內部工具改版，團隊很愛先改 UI，覺得按鈕更漂亮、流程更順眼，採用率就會上去。結果完全不是。真正卡住的不是畫面，是流程。只要使用者還得記得資料在哪、表單怎麼填、哪個審批路徑走哪條，工具就已經輸了。

實操寫法很簡單：先不要問「哪裡能加 copilot」，先問「哪一段工作不該讓人再看到」。把那些步驟列出來，像是查狀態、補上下文、轉派、追簽核、補資料，然後讓 AI 去接這些動作。

我會建議你先畫兩張圖：一張是現在的使用者點擊路徑，一張是理想的任務路徑。中間少掉的每一個畫面，都是 AI 可以吃掉的空間。

系統紀錄層要穩，互動層才有戲

KPMG 把 AI 說成 system of engagement，把企業應用留作 system of record。這句話很像顧問話，但我承認它有用，因為它把責任切乾淨了。

白話講，system of record 就是 ERP、CRM、財務、案件管理這些不能亂動的東西。system of engagement 則是人跟資料、流程互動的那一層。以前這層是 portal、表單、workflow screen；現在 KPMG 的意思是，這層可以交給 AI 先處理。

這件事重要，是因為大多數員工根本不想「使用軟體」。他們只想把任務做完。軟體如果還要人自己翻來翻去、自己整理上下文、自己找下一步，那它就只是在消耗注意力。我看過太多財務流程，大家花最多時間不是做判斷，是把人話翻譯成系統語言，真的很浪費。

• 讓 AI 去理解意圖，不要只回答問題。
• 把 truth layer 留給系統紀錄，別讓 AI 亂改。
• 讓互動層負責摘要、路由、下一步建議。

實操寫法：先把你的流程拆成「真實資料在哪裡」和「人怎麼把事情做完」。如果 AI 只能碰前者就失控，那你不是在做架構，你是在賭運氣。

client-zero 才像真的要落地

這份公告裡我最在意的是 client-zero。KPMG 說它是在 OpenAI 自己的環境裡先做內部部署，拿自己的流程先跑一遍，再拿去對外推。這比漂亮簡報有說服力多了。

client-zero 的意思很直白：先拿自己當白老鼠。這樣才會早點撞到難題，像是權限怎麼切、例外怎麼處理、哪些流程其實太髒不能自動化、哪些資料不能亂碰。很多 enterprise AI 專案死掉，不是模型不行，是根本沒先在真實工作流裡挨打。

我看過太多 pilot 在 demo 裡超順，進 production 就當場翻車。原因通常很俗：例外情況沒算進去、權限沒設好、審計沒做、業務流程其實比大家嘴上講的還亂。這種坑不是靠「再優化一下 prompt」就能補的。

實操寫法：你要上 AI 前，先開一條 client-zero lane。用你自己的內部 support、採購、法務、財務或 IT 流程先跑。先把最醜的例外情境跑出來，再談外部部署。

我會把這個階段當成唯一可信的驗證。別急著對外秀成果，先證明你自己公司能活下來。

forward-deployed engineer 才是交付核心

公告裡還有一個我很買單的字眼：forward deployed engineer。KPMG 說它會把資深工程師直接嵌進 OpenAI 團隊，還會讓自家 FDE 去做 OpenAI 的訓練。這不是裝飾，這是交付模型。

原因很簡單：企業 AI 最常死的地方，不是 model quality，而是 business intent 跟 production reality 中間那段爛泥。你需要有人坐在客戶旁邊，懂流程、懂整合、懂安全審查、懂怎麼把東西塞進現有 stack 還不爆炸。這不是單純 sales，也不是純 PM，這是工程加上現場感。

我見過太多 prototype 聰明到不行，結果一到正式環境就完全不能活。FDE 的價值就在這裡：不是先做出概念，而是先想它怎麼在真實環境裡活下來。

• 工程師要跟業務一起坐，不要只跟平台團隊開會。
• 把 production constraints 拉進 discovery，不要等到最後才驚訝。
• 先想 permissions、audit logs、fallback paths、人工覆核。

實操寫法：每個 AI 專案至少分兩個 owner，一個盯 workflow，一個盯系統邊界。如果這兩件事都丟給同一個人，最後通常不是做出脆弱系統，就是做出沒人敢用的系統。

公共部門最缺的是少一點 portal

KPMG 也提到它會把這套合作放進公共部門 SaaS，像 KRIS Connected 這類工具，目標是讓機關從 siloed legacy systems 走向連動的 case management、service delivery 跟 decision support。這段我特別有感，因為政府軟體長期都在重複同一種毛病：再多一層入口，卻沒少一個步驟。

公共部門真正需要的不是更多表單，而是減少民眾、承辦、主管來回切換的次數。如果 AI 能幫忙做案件分流、摘要歷史、找缺件、加速轉派，那才叫有用。若只是把聊天框貼在爛流程上，大家只會更煩。

公告裡還說這些 AI 解法可以用 incremental 的方式現代化，降低風險，加快 time to value。這句我很認同。政府專案最怕 big-bang rewrite，因為那種東西通常不是上線，是爆炸。

我看過機關被大平台替換案坑過，說要一次清乾淨，結果一年都在救火。比較務實的做法，是先包一層 intelligence 在外面，先把高摩擦步驟削掉，再一段一段換掉底層。

實操寫法：先挑一個最痛的公共流程，比如 intake、triage、status lookup。先讓 AI 幫你少掉手動轉接和重複輸入，紀錄系統先別動。

資安場景才看得出 AI 有沒有真本事

KPMG 也把合作接到 OpenAI Daybreak Cyber Partner Program，想把 AI 用在 threat detection、security operations、AI-powered cybersecurity。這塊我反而比較不排斥，因為 security 本來就活在大量 alert、summary、triage 裡面。

資安團隊最需要的是更快的 pattern recognition、更好的優先順序、還有少一點低訊號噪音。如果 AI 能在可信邊界裡幫忙整理、關聯、排序，那它就不是裝飾，是實際工作的一部分。

但我還是保留。資安是最愛講得很滿、做得很虛的地方。如果模型講不清楚自己為什麼 flag 某件事，或是流程讓 analyst 更慢，那這工具最後只會變成另一個要人照顧的東西。

實操寫法：先把 AI 放在 summarization、correlation、prioritization，不要一開始就讓它自己下動作。先讓 analyst 願意用，再談半自動化回應。

我會把資安當成驗證場景，因為它最容易看出 AI 是在幫忙，還是在製造新工作。

我會直接偷走的做法

這份 KPMG x OpenAI 合作最值得偷的，不是標題，而是架構語言。AI 當 system of engagement，應用當 system of record，client-zero，forward-deployed engineers，incremental modernization。這些字眼都很務實，因為它們在講交付，不是在講夢話。

如果我明天要做一個 enterprise AI 專案，我會直接照這個骨架走：先定義紀錄層，再重畫互動層；工程師貼近流程；先拿內部營運測；最後才碰客戶或民眾。這樣做很不帥，但比較像真的會上線。

很多人習慣從 model 開始往回推，我比較想反過來。先看 workflow，再問哪個 model 該插在哪裡。這樣少掉很多幻覺，也少掉很多 demo 失敗的尷尬。

• 先拆 workflow，再選模型。
• 先保住紀錄層，再改互動層。
• 先內部驗證，再外部擴張。

可抄的模板

# AI-native enterprise workflow template

## 1) 定義分工
- System of record：主資料、稽核紀錄、簽核、合規控制
- System of engagement：AI 層，負責理解意圖、抓上下文、路由工作、摘要與草擬下一步

## 2) 選一條流程
挑一條符合這些條件的流程：
- 步驟重複
- 例外情況明確
- 延遲可量化
- 最後仍需要人工覆核

範例：
- 案件受理
- 財務申請路由
- 事件分流
- 員工支援
- 供應商 onboarding

## 3) 畫出現在的痛點
列出：
- 哪些地方一直在點
- 哪些資料一直在複製貼上
- 哪些簽核一直卡住
- 哪些上下文一直遺失
- 哪些例外一來流程就壞

## 4) 設計 AI 互動層
AI 層應該：
- 理解使用者意圖
- 從紀錄層抓上下文
- 摘要重點
- 提議下一步
- 草擬給人覆核的動作
- 記錄每一步

AI 層不該：
- 變成真實資料來源
- 悄悄修改關鍵紀錄
- 跳過審批規則
- 隱藏不確定性

## 5) 跑 client-zero
正式對外前先做這些：
- 用你自己的內部流程
- 測真實例外，不測 demo 案
- 拉進 security、legal、ops
- 量測省時與失敗模式

## 6) 配交付角色
至少要有：
- 一個 workflow owner
- 一個 systems owner
- 一個 security reviewer
- 一個貼近業務的 engineer

## 7) 先輔助，再自治
Phase 1：
- 摘要
- 分類
- 路由
- 草擬

Phase 2：
- 建議
- 預填
- 驗證

Phase 3：
- 有限自動動作 + 人工覆核

## 8) 量你真的在乎的東西
追蹤：
- 完成時間
- handoff 次數
- 錯誤率
- 例外率
- 使用者滿意度
- 分析師或客服負載

## 9) 漸進上線
一次只換一個步驟。
不要整條流程一起重寫。

## 10) 讓紀錄層保持無聊
AI 層掛掉時，紀錄層還要能運作。
如果紀錄層掛掉，先停下來修那個。

這段就是我會真的拿去改的版本。其他都可以先放旁邊。

來源是 KPMG 的原始公告：kpmg.com/us/en/media/news/kpmg-openai-strategic-alliance.html。上面這篇拆解裡，架構翻譯、實操方式、模板整理都是我自己延伸出來的。