在擴大 AI 之前，先修好背後的 operating model

什麼時候，一個管理團隊會真正意識到，問題已經不再是「AI 能不能幫忙」，而是「一旦流程開始跑起來，這條工作路徑到底由誰負責」？

這正是許多組織現在所處的位置。他們有興趣、有工具、有 pilots，也有一些早期成果。但當他們開始問：同樣的方法能不能承受真實營運流量？整個對話就會立刻變樣。Handoffs 變得模糊，exceptions 開始堆積，沒有人真正確定哪個系統擁有決策權。很多團隊也開始把還高度依賴人工協調的事情，稱作「automation」。

如果你正在評估如何把 AI & Automation 放進實際營運裡，真正重要的通常就是這個缺口。pilot 看起來成功，和系統真的可靠，差別通常不在 model 本身，而在它周圍的 operating model：ownership、orchestration、approvals、system boundaries、release discipline，以及一種能在不製造恐懼的前提下持續改善 workflow 的方式。

當 pilot 遇到真正的 production，路徑就會變得非常真實：ownership、approvals、source-of-truth conflicts，以及 exception paths 都不再只是抽象概念。

為什麼 pilot 的成功常常會誤導人

很多管理者會被建議從 pilot 開始，因為 pilot 看起來可控、成本合理、風險也相對較低。這個建議本身沒有錯，前提是所有人都要明白：pilot 能證明什麼，不能證明什麼。

Pilot 可以證明：

• model 能否把某個狹窄任務做到可接受的品質
• 某個 workflow 步驟能否被加速
• 團隊是否願意採納新的工作方式
• 某個資料來源是否足以支撐實驗
• 是否有內部 sponsor 願意繼續推進

Pilot 通常無法證明：

• 這個 workflow 在真實生產環境中能否處理髒亂的 exceptions
• 多個系統在實際吞吐量下是否還能維持一致
• approvals 與 audit 要求在日常操作上是否站得住腳
• 一旦決策出錯，責任歸屬是否明確
• 上線後能否安全地調整 workflow

所以 pilot 看起來成功，仍然可能讓公司走向失敗。Pilot 會創造信心，但它也很容易把最難的部分藏起來，例如：

• 跨系統 handoffs
• compliance 壓力
• 互相衝突的 source of truth
• 需要 policy judgment 的 exceptions
• 當 prompts、tools 或 rules 改動時的 release management
• 當業務團隊真的依賴輸出後，誰來承擔後續責任

一旦這些現實進場，問題就不再是「AI 能不能做這個任務」，而會變成「我們的組織能不能反覆、穩定、可見地運行這條 workflow」。

這才是正確的問題。

決策者真正買的是什麼

很多領導者以為自己正在評估一個 model、一個 vendor 或一個 feature。實際上，他們是在決定：能不能把一個新的 operating capability 安裝進組織裡。

這個能力必須回答五個很具體的問題：

1. 工作從 trigger 到 outcome 會沿著哪一條 route 前進？
2. 每一個 decision 與 exception 由誰負責？
3. 每一個 step 的 authoritative system 是哪一個？
4. 哪些地方 human judgment 仍然必須保留？
5. workflow 要如何改動，才不會失去控制？

如果這五個問題沒有被回答，組織買到的不是 automation，而是另一種模糊。

這也是為什麼真正好的 AI program，看起來不會像「chatbot 加幾組 prompts」。它更像一個被刻意設計過的 workforce model：

• 一個負責 routing 的 orchestrator
• 一組責任明確、範圍狹窄的 specialist agents
• 負責 exceptions、approvals 與 rule changes 的 humans
• 與 CRM、ERP、ticketing、document systems 與內部工具的清楚 interfaces
• 能讓整條 workflow 可解釋的 verification、logging 與 release controls

這就是所謂 full agentic workforce 在實務上的含義。它不是「到處都是 agents」，而是一種有結構、有邊界的 labor model。

每一個嚴肅 automation program 背後，都有一個 operating model

當領導者說他們想做 AI automation，實際上通常想要的是下列幾種結果：

• 更短的 turnaround time
• 更穩定的營運品質
• 更少的 manual rework
• 更好的 specialist staff time 利用
• 不按人數線性擴張的 capacity 成長

這些結果都可能實現，但沒有一項是單靠 model capability 自動出現的。

在每一個真正站得住腳的 automation program 背後，都有一套 operating model 在支撐：

• 決定 workflow 何時開始的 intake rules
• 決定下一步怎麼走的 orchestration
• 明確分工的 specialist tasks，而不是模糊的「AI 會處理」
• 與風險相稱的 human gates
• system-of-record discipline
• 能把 value 與 activity 分開的 measurement
• 針對 workflow changes 的 release management

沒有這一套 operating model，團隊仍然會產出東西。但那種輸出通常很脆弱、責任不清，而且一旦出錯很難防守。

這也是為什麼在 automation 上收穫最多的組織，往往不是 pilots 最多的那一批，而是最先學會把工作路徑設計清楚的那一批。

讓 AI automation 可治理的六個承諾

當 pilot 開始碰到 live work，我通常會看六個訊號，來判斷這個組織到底是在建一套可治理的系統，還是在堆一個看起來漂亮但很脆弱的東西。

1. One workflow, one owner, one outcome

挑一條已經在耗費時間、金錢、風險或管理注意力的 workflow，然後指定一個 owner。這個 owner 需要對一個可以被明確判斷的結果負責，例如：

• 降低複雜報價的準備時間
• 縮短 onboarding packet 的完成時間
• 降低 partner operations 的 exception queue age
• 提高 compliance evidence 在 approval 前的完整性

如果一條 workflow 有三個 owner，那它其實沒有 owner。若結果也不可衡量，就沒有人能知道 automation 到底是在幫忙，還是在把工作搬來搬去。

2. One orchestration layer

一定要有人，或某個東西，來協調整條 route。Orchestration layer 不是可有可無的技術細節，它是 workflow 的脊椎。

它負責決定：

• sequence
• retries
• stop conditions
• approval checkpoints
• escalation paths
• timeout behavior
• 什麼要被記錄，以及記到哪裡

沒有單一 orchestration layer，團隊就會慢慢滑向隱形的人工協調：agent 先寫一版、某個人再轉發、另一個工具再補資料、最後有人在 chat 裡批准，事後卻沒人能說清楚這條 flow 實際上怎麼跑。

3. Specialist roles, not general wandering

最強的 agentic systems 幾乎都依靠狹窄、明確的責任分工。一個 agent 負責資料對帳，另一個負責起草結構化文件，另一個負責檢查 policy fit，還有一個負責幫人類 reviewer 整理 exception summary。

這種設計重要，因為狹窄角色更容易：

• 測試
• 審查
• 改進
• 替換
• 建立信任

角色越「通用」，越難說清楚什麼叫做好、錯誤為什麼發生、以及下次怎麼把風險降下來。

4. Human judgment with explicit thresholds

不要把 human review 藏在一句含糊的「human stays in the loop」裡。那種說法在操作上幾乎沒有意義。

必須明確定義什麼情況要人介入：

• 高價值交易
• 敏感資料類型
• 重大 policy conflicts
• 缺失文件
• 低信心抽取
• 相互矛盾的 source evidence
• 風險評分跨過門檻
• workflow change 影響 control surface

Human judgment 不是 failure state。在嚴肅的組織裡，它本來就是 architecture 的一部分。

5. System boundaries that reflect reality

真實 workflow 會碰到 CRM、ERP、ticketing、documents、inboxes 與各種內部 approvals。一定要有人說清楚：每個 step 的 authoritative system 是什麼，哪些系統只能提供 context。

這是 AI automation 裡最常被低估的設計決策之一。如果 system boundaries 不明確，人就會開始不信任輸出，因為大家不知道 truth 到底住在哪裡。

接著就會出現熟悉的 failure modes：

• duplicate truth
• shadow spreadsheets
• 發生在 chat 裡的 manual side channels
• 原本說是 temporary 的 workaround，最後變成 permanent
• 事後無法重建的 approvals

6. Change control

Agent behavior 是 production concern。當 prompts、tools、business rules、thresholds 或 model versions 改變時，workflow 就需要：

• versioning
• testing
• verification
• release notes
• rollback mindset

太多團隊把 workflow logic 當成普通內容編輯看待。它不是。如果一個改動會影響 evidence assembly、risk scoring，或何時把 case 升級給 human review，那它就是 production change。

實務上，agentic workforce 長什麼樣子

「agentic workforce」這個詞聽起來很抽象，直到你把它映射到真實工作。

以 compliance packet assembly、supplier onboarding、quote package preparation，或多系統之間的 delivery request 為例。一個可治理的 agentic workforce 可能會像這樣：

• intake layer 接收 trigger 並驗證必要輸入
• orchestration layer 決定 route
• reconciliation role 從被批准的 systems 收集資料
• drafting role 產出第一版結構化 artifact
• policy-check role 尋找缺失 evidence 或 threshold breaches
• summary role 為 human review 準備 decision packet
• human reviewer 進行 approval、rejection 或要求補充
• execution step 把核准結果寫回正確的 system of record
• audit layer 記錄發生了什麼以及原因

請注意這個畫面裡缺少什麼：幻想。

這裡沒有「AI 自己就會搞定」的魔法時刻。這裡只有一套被設計好的 labor system，角色清楚、控制點清楚。正因如此，它才可能擴大。

這樣的設計也讓領導團隊能用 labor，而不只是 technology 的角度來思考：

• 哪些工作重複性夠高，值得 automation？
• 哪些工作仍然高度依賴 judgment？
• 哪些角色需要 subject-matter expertise？
• 哪些 queues 正在成為 bottlenecks？
• 哪些地方 human team 還在做低價值 clerical work？

一旦能回答這些問題，automation 就不再只是 vendor demo，而會變成 operating model 討論。

給 steering group 的簡單 readiness table

如果管理團隊想快速判斷 workflow 是否準備好導入 AI automation，像下面這樣的表格，通常比再開一場 brainstorming meeting 更有用。

這時候，管理層的對話通常才會真正變得有價值。大家不再只是問下一個要 pilot 哪個 feature，而是開始問：這條 workflow 真的準備好承接真實流量了嗎？

最好的 first wins 長什麼樣子

好的第一個 implementation，通常有三個特徵：

• 它處理的是重要 workflow，不是花俏但無關緊要的任務
• 它有清楚的 handoffs，讓 orchestration 可以真正減少摩擦
• 它的成效可以不帶爭議地衡量

所以最好的 first wins 常常出現在：

• onboarding
• claims preparation
• document review
• partner operations
• implementation handoffs
• internal service workflows
• compliance evidence gathering
• structured customer support escalations

這些 workflow 夠重要、夠有結構、也夠有邊界，因而適合治理。

差的 first use case 則剛好相反：不是太小不值得做，就是政治上太模糊，根本無法治理。很常見的一種情況，是在 ownership、escalation 與 review 都還沒談清楚之前，就把 AI 直接鋪進高風險 customer workflow。

你真正想從 first win 拿到的，不應該只是省下幾分鐘，而是證明組織能同時做到四件事：

1. coordinate agents across systems
2. preserve auditability
3. keep human judgment where it belongs
4. improve the workflow every week without creating fear

如果這四件事還證明不了，那你擁有的最多只是一個有前景的實驗，不是一個可以負責任擴大的 operating capability。

為什麼 handoffs 才是 automation program 最常壞掉的地方

大多數 AI automation 的失敗，並不是 model 忘了一個事實，而是 workflow 從來沒有被設計成能承受 handoff points。

想想工作通常在哪裡斷掉：

• 一個 system 存商業 truth，另一個 system 存營運 truth
• reviewer 期待的 context 根本沒被 capture
• downstream team 收到一個既不信任也無法採取行動的輸出
• exceptions 太晚才被發現，因為沒有人定義什麼叫 exception
• staff 因為不相信主 route，於是另外保留一套 manual side process

這些都不是「AI 問題」，它們是 operating model 問題。

這也意味著，領導者真正應該花時間討論的，往往是：

• 工作在哪裡交接？
• 哪些 evidence 必須跟著一起走？
• 哪個 threshold 會觸發 escalation？
• 一旦 exception 出現，誰負責 recovery？
• 哪個團隊核准 rule change？

當這些答案被寫清楚後，技術設計通常就容易得多。反過來說，如果這些事沒說清楚，再強的技術實作也會讓人覺得不穩，因為大家不信任 route。

怎麼保留真正重要的 human judgment

AI automation 最常見的誤區之一，就是把 human involvement 當成系統不夠強的象徵。在嚴肅的組織裡，human judgment 不是弱點，而是 architecture 對風險的尊重。

通常應該由 humans 擁有的是：

• policy interpretation
• material exceptions
• 敏感 outcome 的最終核准
• workflow rules 的改動
• 定期檢查系統正在學習的 edge cases
• 涉及法規或重大合約影響時的 sign-off

通常應該交給系統的是：

• 重複性的 preparation work
• structured data reconciliation
• templated drafting
• evidence assembly
• queue routing
• consistency checks
• reminders 與 follow-up triggers

這種分工不是要讓人變慢，而是要把人的注意力保留給真正有價值的 judgment moments。

真正快的團隊，通常不是把 humans 完全移除的團隊，而是停止把人的時間浪費在低價值 coordination 上的團隊。

領導團隊應該量測什麼

如果 leaders 是認真想 scale，就需要一套能把 business value 與 theater 分開的 measurement set。

Value metrics

用來看 workflow 是否真的產生了有意義的改變：

• turnaround time
• 從 trigger 到 approved outcome 的 cycle time
• completion rate
• queue age
• resolved without rework 的比例
• 每個 specialist team 的 throughput

Control metrics

用來看 workflow 是否仍然可治理：

• approval trace completeness
• exception rate
• cases 是否在該升級時被正確 escalated
• workflow steps 的 system-of-record clarity 比例
• release verification pass rate
• workflow changes 的 rollback 或 recovery readiness

Friction metrics

用來看 operating model 還在哪裡漏工：

• 每個 case 的 manual touchpoints 數量
• duplicate data entry
• unresolved exception backlog
• reviewers 回報的 context gaps
• handoff delays between teams
• 完成工作時使用 off-workflow side channels 的次數

真正重要的是把這些指標一起看。Workflow 可能在 throughput 上看起來更有效率，卻悄悄變得更難治理；也可能控制變多了，卻沒真的減少 labor。領導團隊需要同時看到這兩面。

一份 kickoff 之後仍然有用的 tracker

如果 steering group 想要一個簡單、真正可操作的工具，可以維持像下面這樣的 weekly tracker：

這不應該變成另一個報表負擔，而應該是 leaders 最少需要看到的營運視圖，用來辨識誰在擁有 route、摩擦又在哪裡累積。

如果沒有人擁有 friction，它不會消失，只會躲進 inbox、spreadsheet、Slack thread，或突然變成沒有人願意認領的 queue。

AI automation program 的常見失敗模式

當 AI automation 讓人失望時，模式通常都很可預測。

Failure mode 1: 組織優化的是 demo，不是營運

這種情況發生在 workflow 之所以被選中，是因為它看起來亮眼，而不是因為它在營運上真的重要。

Symptoms:

• demo 看起來很好，但沒有人想接手後續 ownership
• use case 太淺，撐不起真正的 process change
• workflow 無法被清楚衡量

Better approach:

• 選有明確成本、延遲或品質痛點的 workflow
• 在 build 前先把 ownership 定清楚
• 用 operational terms 定義 success，而不是用掌聲

Failure mode 2: 系統產出很多內容，但沒有真正推進工作

這是最常見的陷阱之一。Workflow 會產生 drafts、summaries 或分析，但整個組織仍然得做跟以前幾乎一樣多的協調。

Symptoms:

• staff 仍然要把輸出 copy-paste 到 downstream tools
• reviewers 還是得花時間重建 context
• queue age 或 cycle time 沒有下降

Better approach:

• 設計 end-to-end route
• 降低 handoffs 的數量
• 把輸出寫回正確 systems

Failure mode 3: 把 exception handling 當成補充細節

只有 happy path 的 automation 根本不夠。Production reality 其實都活在 exceptions 裡。

Symptoms:

• 少一份文件或資料互相衝突時，整條 flow 就開始失效
• reviewers 不知道 case 為什麼被 escalated
• edge cases 逼出 shadow workflows

Better approach:

• 早期就把 exceptions 分類
• 定義 escalation rules
• 在 launch 前先設計 fallback path

Failure mode 4: 沒有人講得清楚 system-of-record boundaries

這會造成最糟糕的一種組織混亂，因為 automation 看起來像是有在運作，卻同時在慢慢腐蝕信任。

Symptoms:

• 不同團隊各自引用不同版本的 truth
• approval history 分散在不同工具裡
• downstream teams 不願意依賴這些輸出

Better approach:

• 針對每一個 major step 明確標示 system ownership
• 決定哪些 tools 可以 write、哪些只能 read
• 把 route 寫進工作文件裡，而不是留在口頭

Failure mode 5: Change management 太隨意

當團隊在沒有 release discipline 的情況下更新 prompts、rules 或 thresholds，就算出發點是合理的改善，也可能引入新的風險。

Symptoms:

• 大家不敢調整 prompts 或 thresholds
• incident 很難追溯到是哪一次改動造成
• 團隊停止改善，因為他們不信任 release path

Better approach:

• 對 workflow logic 進行 versioning
• release 前先測試
• 記錄 changed what and why
• 即使 workflow 很多是 configuration，也要保有 rollback mindset

Failure mode 6: 領導團隊量的是 effort，不是 outcomes

這就是 automation program 開始顯得忙碌卻不可信的時候。工作一直在做，dashboard 也一直在長，但沒有人能清楚說出：這家公司的 operating model 是否真的變好了。

Symptoms:

• dashboard 只看 task counts
• 沒有人追蹤 rework 或 queue age
• 整個 program 聽起來很忙，但缺乏可信度

Better approach:

• 把 value metrics 與 control metrics 配對看
• 用 decision-friendly 的語言報告 progress
• 把 reduced friction 當成真正的 outcome

如何安全地引入 AI automation：一條實際 rollout path

很多 leaders 問的其實是同一件事：怎麼在不製造 chaos 的情況下引入 automation？最安全的路徑通常是分階段的。

Stage 1: 在 automation 之前，先把 workflow 畫清楚

這個階段團隊會發現，自己到底是不是真的理解 route。先把這些東西文件化：

• trigger conditions
• required inputs
• system-of-record boundaries
• handoffs
• exception classes
• approval thresholds
• current pain points

如果這一步被跳過，automation 只會繼承原本隱藏的模糊。

Stage 2: 先 automate preparation，不要先 automate authority

先從高槓桿、低風險的工作開始：

• evidence gathering
• structured drafting
• consistency checking
• 幫 reviewers 做 summarization
• routing 與 follow-up triggers

這個階段是組織學會 orchestration、logging 與 review mechanics 的最好時機。

Stage 3: 先把 review layer 做強，而不是做弱

不要一開始就想把 humans 移出流程。先把 review 變得更好：

• 更好的 decision packets
• 更清楚的 escalation reasons
• 更可見的 thresholds
• 更快的 review queues
• 更結構化的 evidence

更強的 review layer 往往正是規模化的前提。reviewers 不再花時間重建 context，組織也不再把速度和控制看成互斥。

Stage 4: 只有在 route 值得信任之後，才擴大

只有 workflow 穩定之後，leaders 才應該考慮更廣的 automation authority 或更複雜的 use cases。到那時，組織至少已經有：

• known owners
• tested thresholds
• credible metrics
• change management discipline
• trust in the route

這個順序很重要。很多團隊一開始就想直接做 Stage 4，最後都得在壓力下回頭補基礎。

一個強的 delivery partner 應該帶來什麼

如果你在評估外部夥伴，標準不應該只是「他們懂 AI」。

真正好的 partner，應該能同時做到三件事：

• 把 workflow 設計成 operating model
• 在真實 systems 之間安全地 build automation
• 幫你的團隊建立可以持續運作的 governance

所以對方應該能談得很實際，而不只是講願景，包括：

• workflow ownership
• systems integration
• QA 與 verification
• release discipline
• exception handling
• security 與 least privilege
• observability 與 traceability

這也是為什麼 on-demand development, QA, and DevOps/DevSecOps capacity 常常很有用。你買的不是一個 pilot，而是能把 workflow 跑起來、驗證它、並持續改善而不失去信任的能力。

Leaders 可以直接問這些問題：

• 你們怎麼定義 orchestrator boundary？
• 你們怎麼分類 exceptions？
• 你們怎麼決定哪些地方 human review 仍然必須保留？
• workflow changes 怎麼安全 release？
• specialist roles 怎麼測，而不被設計得過度 general？
• 上線後怎麼證明整條 route 正在正常運作？

如果答案聽起來很模糊，production 裡大概率也會很模糊。

FAQ

保留 humans in the loop 會不會讓組織變慢？

如果系統設計得當，不會。差的 workflow 會把人力浪費在 clerical recovery、重複檢查與不清楚的 approvals 上。好的 workflow 會把人的注意力保留給 policy、judgment 與 exceptions。這通常反而會更快，因為剩下的 route 變得更可靠。

最容易開始的地方是哪裡？

從一條已經明顯在痛、而且有足夠結構可以治理的 workflow 開始。Internal service workflows、onboarding packets、partner operations、structured document review，以及 preparation-heavy approval routes，通常都是好候選。

我們怎麼知道一條 workflow 是否「準備好」導入 automation？

如果你能明確指出 owner、system of record、approval thresholds、常見 exceptions 與 success metrics，你大致上就在可行範圍內。若這些事情仍然模糊，先修 operating model。

前九十天應該要完成什麼？

前九十天不應該試圖 automate everything，而是要把 route 建立起來、把 handoffs 證明清楚、把 review thresholds 說明白，並建立 weekly improvement loop。一個 modest 但 governable 的 first win，比一個 flashy 卻不穩定的 rollout 有價值得多。

如果領導團隊更擔心風險，而不是效率，怎麼辦？

這通常反而是好訊號。重點不是消除這種擔心，而是用 architecture 回答它：explicit thresholds、traceable approvals、system boundaries、release controls 與 measurable outcomes。對風險敏感的 leaders，通常在 workflow 變得可解釋之後，反而會成為很強的 sponsor。

什麼時候才值得談「full agentic workforce」？

當組織已經能清楚描述 specialist roles、human control points 與 orchestration boundaries，而且這些描述是 operational 的，不是簡報口號時，這個詞才真正有意義。它應該指向一個被設計好的 labor system，而不是一張 ambition slide。

給 leadership teams 的一個實際 next step

如果你的組織真的在認真考慮 AI automation，最值得開的下一場會議通常不是「我們該買哪一個 model」，而是：

• 哪一條 workflow 重要到值得投入設計？
• 現在的 handoffs 斷在哪裡？
• 今天哪些 systems 才是 authoritative？
• 哪些 thresholds 必須保留 human judgment？
• 一個安全的 first release 實際上長什麼樣子？

這樣的對話比 brainstorm 有價值得多，因為它會產生一條真正的 route。

而當 route 被看清楚之後，組織才能回答 AI strategy 討論背後真正的問題：automation 是否不只是可能，而是能不能成為一種可信的 operating capability。

這就是好看 demo reel 和一個星期一早上就能真正運作的 program 之間的差別。

如果你想從一個務實的下一步開始，歡迎預約諮詢。我們會把第一次對話整理成書面的 project pipeline、draft SoW(s)，以及你的團隊真的可以拿去內部評估的官方 quotation。