AI 轉型背後那些看不見的工作
為甚麼 AI 轉型大部分其實是營運工作：梳理 workflow、來源、權限、ownership、review point，以及自動化邊界。
重點摘要
- AI 轉型主要不是採用模型，而是令組織清楚到軟件可以負責任地幫手。
- 看不見的工作，是梳理 workflow、來源、權限、負責人、review point，以及準備與行動之間的邊界。
- 只有當組織有足夠 context、control 和 evidence，讓人和 agent 都知道下一步應該怎樣做，自動化才真正有用。
在這篇文章裏，我們把 AI transformation 定義為：令一個組織清楚到 AI 可以協助真實工作的那套工作。
這是刻意收窄的用法。它不是說每個 AI programme 都要重建整間公司。它是說，如果想在營運上認真使用 AI，單有模型使用權是不夠的。
這個定義很實際。它不是由模型開始，而是由組織開始：工作在哪裏發生、證據在哪裏、誰擁有決定、哪些系統是權威來源、用戶或 agent 可以看見甚麼，以及軟件甚麼時候應該停下來交給人 review。
在這個意思上，AI transformation 依賴 organisational context。
多數 AI programme 從外面看都比裏面實際情況更簡單。團隊可以很快買到強模型的 access，可以做 pilot、產生 summary、draft email、連接幾個工具。更難的是令營運環境變得可讀。沒有這些工作，AI 仍然只是一個被指向不清楚 context 的通用 assistant。
這就是「hidden work」的意思。它不一定出現在 launch deck 裏，也不一定像模型 demo 那樣容易展示，但它決定 AI 能否從個人工具走向可靠 workflow。當組織想讓 AI 接觸客戶、金錢、合規、交付或跨部門 decision，這些看不見的 mapping 和 boundary work 就會變成核心工作。
對香港的專業買家和營運負責人來說，這一點尤其實際。很多風險不是來自模型答得不夠漂亮，而是來自它不知道哪份文件作準、哪個 partner 仍要過目、哪個 client constraint 只在會議裏講過，以及哪個系統只反映流程的一半。這些東西不先被整理清楚，AI 就只是在不完整的營運圖上加速。
AI 轉型就是令組織可讀
Organisational legibility 指的是：工作的即時狀態可以被人和軟件讀懂。
在這篇文章裏，我們用這個詞指一件具體的事：workflow、來源、權限、負責人、review point 和自動化邊界都要清楚到 AI 系統可以取回正確 context、使用正確工具，並留在正確限制之內。
這和 governance 接近，但不是同一件事。Governance 說明誰負責、適用哪些規則。Legibility 則把這些規則變成營運結構。它令組織在工作真正流動的層面可以被檢查。
NIST 的 AI Risk Management Framework 把 AI 風險管理視為 socio-technical practice，而不只是模型質素練習。它指出 AI 系統由技術設計、用戶，以及部署所在的社會 context 共同塑造，並把風險工作組織成 governance、mapping、measurement 和 management（NIST AI RMF 1.01）。這是 transformation 的正確起點：在 AI 可以安全行動之前，組織要先理解行動會發生的 context。
由模型使用權到營運 context
常見錯誤，是把 AI transformation 當成接入一個更聰明的 interface。組織給員工一個模型，連上 document store，然後期待 productivity 自然出現。
這可以幫到個人工作，但不會改變組織的 operating system。困難問題仍然存在：
- 當系統之間有矛盾，哪個來源具權威性？
- 哪個角色可以看見客戶、員工、matter、財務或 vendor 資料？
- 當 workflow 跨部門，誰擁有下一步？
- 哪些 evidence 支持一項 recommendation？
- 哪些 action 可以自動化、可以準備、或只可以建議？
- 系統寫回紀錄之前，review 在哪裏發生？
這些不是細微 implementation details。這些就是工作本身。
如果這些問題沒有答案，AI 仍然可以產生文字，但那只是流暢的表面。真正的 transformation，是讓系統能夠分辨哪個 source 有 authority、哪個 decision 仍然 open、哪個 action 只是 preparation，以及哪個 action 會改變組織狀態。
換句話說，transformation 的早期成果不一定是一個更炫目的 interface，而是一套更清楚的責任關係：資料從哪裏來、誰可以用、誰負責判斷、甚麼情況下可以寫回系統，以及甚麼必須留給人決定。
為甚麼問題會存在
現代組織軟件很多，但 context 很少。
Business intelligence 可以收集、管理和分析數據作決策（IBM: Business Intelligence）。兩者都有用。但它們都不會自動解釋一份文件、一個 task、一段會議紀錄、一項續約、一個 approval、一個 exception 或一個 client commitment 的營運意義。
工作分散在不同系統，是因為每個系統都有本地目的。CRM 放 account。財務工具放 spend。文件系統放 file。task board 放 assignment。inbox 放 informal decision。calendar 放 commitment。meeting transcript 放那些從未變成欄位的 context。
人靠記憶、習慣和判斷去跨過這些縫隙。AI 不會自然繼承這些 tacit operating knowledge。如果 context 沒有被代表出來，模型就只好猜、過度概括，或者要求用戶在 prompt 裏重新建構整個組織。
AI 會暴露 ownership 不清
AI 令 ownership gap 更明顯。如果有人要求 agent 準備一段 client update，agent 需要知道相關 project、目前狀態、曾作出的 promises、risks、source documents、tone、reviewer 和 approval rule。如果沒有任何系統知道這些關係，agent 仍然可以寫出流暢文字。只是它不知道那些文字是否負責任。
Anthropic 關於 building agents 的指引，把預先定義的 workflows 和較自主、會動態指揮自己使用工具的 agents 分開。它亦強調可靠 agentic work 需要來自環境的 ground truth、checkpoints、stopping conditions 和清楚的 tool interfaces（Anthropic: Building Effective Agents2）。這些要求聽起來技術化，但其實依賴組織結構：系統需要一個可靠環境去觀察。
實際做法
實際做法，是在期望深層自動化之前，先建立營運層。
這一層不一定要是一個大型系統。它可以由一個工作範圍的結構化模型開始：哪些 object 重要、它們怎樣相關、誰擁有它們、哪些來源餵入它們、哪些權限適用，以及哪些 action 可能發生。
組織需要有意識地讓營運訊號進入系統：documents、emails、meeting notes、forms、calendars、tickets、finance records、case systems、databases 和 user updates。這不應該代表不加選擇地收集一切。每個 signal 都需要 source type、source owner、permission、date、related work 和 confidence。一份過時 policy、一份 draft contract、一份已批准 board minute 和一段 informal Slack message，不應該被當成同等事實。
材料之後要被結構化成組織真正使用的概念：client、matter、vendor、owner、approval、risk、renewal、obligation、evidence、task、deadline、review 和 exception。它亦需要 deduplication、normalisation、permissioning、lineage 和 reconciliation。如果兩個工具以不同方式描述同一個 client，營運層需要有方法呈現差異，而不是把它藏起來。
產生出來的狀態要存放在 durable、queryable 的地方：databases、indexes、document stores、knowledge graphs、vector stores、workflow logs 和 audit records。
NIST SP 800-53 把 security 和 privacy controls 視為可彈性定制、用於全組織風險流程的 controls，其中包括 access control 以及 audit and accountability（NIST SP 800-53 Rev. 55）。對 AI transformation 來說，這些概念重要，因為 operating layer 需要記住的不只是 content，還有 authority：誰可以看、誰改過、以及系統為甚麼使用它。
人和 agents 之後需要受控方式去互動：search、summaries、APIs、editors、queues、review screens、approval flows 和 write-back tools。
只有 retrieval 而沒有 tools，AI 仍然只是 adviser。只有 tools 而沒有 governance，則會製造風險。有用的一層會結合兩者：系統可以找出相關 context、準備工作、route 工作，並記錄發生過甚麼。
這不是甚麼
這不是說每個 workflow 都應該自動化。
有些工作應該留給人，因為它涉及判斷、關係風險、專業責任、敏感性或不完整 evidence。有些工作可以由 AI 準備，但要由 accountable owner review。有些工作可以自動化，因為條件穩定而後果較低。Legibility 的意義，就是知道分別在哪裏。
這也不是說公司要先做一個沉重的 transformation programme 才可使用 AI。小團隊可以由 focused tools、retrieval、templates 和 narrow automations 得到價值。當 AI 被期望跨系統、用戶、權限、客戶、金錢、compliance 或 external commitments 運作，legibility 問題才會變得急切。
ISO/IEC 42001 描述了一個供提供或使用 AI 系統的組織採用的 AI management system standard（ISO/IEC 420016）。不論團隊是否正式採納這套 standard，方向都有用：AI 應該透過 responsibilities、objectives、controls、evaluation 和 continual improvement 管理，而不是單靠熱情。
實際上會是甚麼樣子
Client services
Client-services agent 不應只靠 prompt 去 draft updates。它需要目前 project state、agreed scope、latest deliverables、open risks、prior commitments、client preferences 和 review owner。看不見的工作，是在生成 draft 之前先連接這些紀錄。
Operations
Operations workflow 從外面看可能很簡單：把 exceptions route 給正確的人。但 routing 需要 exception type、severity、customer impact、service-level deadline、owner、backup owner 和 escalation rule 的模型。只有當這些邊界存在，AI 才能幫手分類和準備 route。
Leadership reporting
Leadership summary 只有在能分清 facts 和 interpretation 時才有用。系統需要 source links、date stamps、open assumptions、missing data 和 since last review 的 changes。否則 AI 只會產生一段似是而非、證據不足的 narrative。
Internal automation
Renewal reminder 可以自動化。Vendor cancellation 可能需要 finance approval、legal review、operational handover 和 client-risk checks。分別不在模型，而在 operating context。
資料來源
/ 開始
先由一個營運範圍開始，再逐步擴展。
由一個清晰的審閱節奏、工作流程或團隊開始，找出更好的營運背景能即時改善準備和判斷質素的地方。