企業 GenAI 平台負責人的三份工作：蓋平台、帶團隊、讓組織真的用起來
如果每個部門都來問：「可以幫我們做一個 chatbot 嗎？」然後 AI 團隊一個一個接需求、各自串模型、各自接資料、各自部署——你手上不是一個平台，是一條永遠清不完的客製化專案 backlog。
第一個 bot 上線時，大家會很興奮；第五個 bot 出現時，問題就來了：身分驗證做了五次、文件切分策略有五套、prompt 散落在五個 repo、同一份敏感資料被複製到不同的向量庫。模型換版要改五次，資安規則更新也要追五次。原本想用 AI 省時間，最後只是養出一群更難維護的新系統。
所以我認為，企業 GenAI 平台負責人的核心任務，不是「做出最聰明的 AI」，而是把反覆出現的 AI 需求，收斂成一套安全、可重用、能持續交付的內部產品。
這份工作表面上在做 AI，實際上同時做三件事：蓋平台、帶團隊、讓組織真的用起來。 少了任何一件，平台都很容易停在 demo。
flowchart TB
B["Business Goal<br/>要改善哪一段工作流程？"] --> R["Roadmap & KPI<br/>先做什麼，怎麼算成功？"]
R --> K["Knowledge<br/>RAG 與企業知識"]
R --> I["Insight<br/>Data Agent 與分析"]
R --> A["Action<br/>Workflow Automation"]
K --> F["Shared Foundation<br/>Identity · Security · Eval · Observability · Cost"]
I --> F
A --> F
F --> D["Delivery Loop<br/>設計 → 實作 → 評估 → 上線 → 回饋"]
D --> E["Enablement<br/>文件 · Golden Path · 支援管道"]
E -->|"使用回饋"| R
第一份工作：蓋的不是功能，是可重用的平台
企業裡的 GenAI 需求看起來五花八門，但多半可以收斂成三種能力。
| 能力層 | 使用者想做的事 | 平台真正要提供的東西 |
|---|---|---|
| Knowledge | 從內部文件找到可信答案 | Enterprise RAG、來源引用、權限感知檢索 |
| Insight | 用自然語言查資料、找趨勢 | Data Agent、語意層、結構化與非結構化資料存取 |
| Action | 讓 AI 接手一段工作流程 | 可重用工具、workflow orchestration、human-in-the-loop |
第一層是讓 AI 知道公司的事。這不是把 PDF 丟進向量資料庫就結束，而是從 ingestion、chunking、embedding、retrieval、reranking 一路做到來源引用。企業使用者真正需要的不是一句流暢答案，而是「我能不能知道它根據哪份文件、哪個版本說的」。我在 RAG 架構實戰裡拆過整條 pipeline；到了企業場景，還得補上權限感知檢索，確保每個人只能搜到自己原本有資格看的內容。
第二層是讓 AI 看懂資料、產生洞察。這比文件問答再往前一步：agent 可能同時查詢資料表、報表和文字紀錄，再把結果組成適合當下問題的圖表或摘要。真正困難的通常不是畫出圖，而是語意定義與權限——「營收」到底用哪張表、退貨算不算、這個人能不能看到部門以外的明細？這些沒有先講清楚，AI 只會用更自然的語言講出更難察覺的錯誤。
第三層是讓 AI 採取行動。查到資料之後，可以建立工單、更新狀態、觸發審批或接續下一個流程。這時平台必須把工具分成唯讀與寫入、為高風險動作保留人工確認，並處理 timeout、retry、idempotency 和 rollback。Agent 會講錯話已經夠麻煩；當它能動手，錯誤就會真的改變外部世界。
三層共用的底座，才是平台價值最大的地方：身分與權限、tool registry、模型路由、eval、observability、audit log、成本監控。每個團隊不必再重蓋一次，而且公司只要在一個地方強化安全規則。完整的元件關係，可以對照我整理的企業 AI Agent 系統架構藍圖。
平台的價值不是「它自己有多少功能」，而是下一支團隊能不能少走一段已經走過的路。
第二份工作：把願景翻成 roadmap，也翻成可以驗收的 KPI
「我們要做企業 AI 平台」不是 roadmap，只是一個方向。真正的 roadmap 必須回答三個問題：先解哪一段流程、為什麼先解它、做到什麼程度算成功。
我不會一開始就做一個號稱什麼都能接的通用框架。比較務實的順序是：先選一個價值明確、資料邊界清楚、失敗風險可控的工作流程，做出 reference workflow；等第二、第三個場景進來，再把真正重複的部分抽成共用能力。
這和過早抽象化程式碼是一樣的道理。只看第一個 use case，你以為所有人都需要同一套設定；做到第三個才會發現，真正共用的可能只有 identity、retrieval、evaluation 和 audit，其他都該留給產品團隊自己決定。
Roadmap 的另一半是 KPI。只看「做了幾個 agent」或「模型分數多高」都不夠，我會把指標分成四層：
| 面向 | 可以追的指標 | 它回答的問題 |
|---|---|---|
| Adoption | 活躍團隊數、共用元件採用率、time-to-first-value | 別人真的用得起來嗎？ |
| Quality | grounded answer 通過率、task success rate、人工升級率 | 回答和行動值得信任嗎？ |
| Engineering | availability、p95 latency、每次成功任務成本 | 能穩定、可負擔地運作嗎？ |
| Business | 節省工時、減少人工步驟、縮短決策週期 | 對業務結果有幫助嗎？ |
每一個 KPI 都要有 baseline 和 owner。沒有導入前的處理時間，就不能證明導入後省了多少；沒有人負責品質指標，dashboard 最後只會變成一張沒人看的漂亮圖。
平台負責人的技術判斷，也包含管理 technical debt。新模型、新框架每週都在出，但不能因此每季重寫一次平台。該穩定的是介面與工程紀律：身份怎麼傳、工具怎麼註冊、eval 怎麼過關、trace 怎麼留下。框架可以替換，這些 contract 不能跟著每次流行一起翻修。
第三份工作：帶的不是一群專家，是一個 delivery system
企業 GenAI 平台通常需要 software engineer 和 ML engineer 一起工作，但「把兩種人放進同一個 Slack channel」不等於跨領域團隊。
一個 RAG 答錯，原因可能在文件 ingestion、chunking、metadata、檢索、reranking、prompt，也可能是原始資料本來就互相矛盾。Software engineer 只看 API 是否回 200，ML engineer 只看模型輸出是否流暢，都找不到完整答案。團隊需要的是共同的品質語言，以及一套每次都能重複的 delivery loop：
需求與風險盤點 → 架構／安全 review → 建立黃金題庫 → 實作
→ eval 回歸 → 上線 → 觀測 → 把線上失敗案例補回題庫 → …這個 loop 最重要的是最後那個箭頭。線上每出現一個壞案例，團隊不只修當下的答案，還要把它變成以後每次改 prompt、換模型、調 retrieval 都必須通過的測試。沒有這一步，同一類錯誤遲早換個樣子再回來。
AI 工程也不只需要 code review。Architecture review 看權限與系統邊界，prompt review 要附 eval diff，eval review 檢查題庫是否真的代表使用情境。這些做法的目的不是增加流程，而是讓團隊不必靠某個資深成員的直覺守住品質。更完整的做法，我整理在生產級 LLM 可觀測性與評估和帶領一支 AI 工程小隊兩篇裡。
管理者在這裡的工作，是讓探索和交付可以同時存在：保留實驗空間，但也清楚分開 production backlog、平台能力與技術探索。不是每個成功的 prototype 都要進平台，也不是每個新框架都值得團隊付出遷移成本。
真正決定成敗的，是讓組織用起來
平台做完卻沒人用，通常不是因為模型不夠強，而是使用門檻太高。
如果一個產品團隊想做文件問答，得先研究向量資料庫、自己接 SSO、自己發明權限 metadata、自己裝 tracing，再來理解模型費用，那它很可能乾脆直接呼叫一個 API，先做出能 demo 的版本。三個月後，企業裡就會多一個沒人敢維護的孤島。
所以平台團隊要提供 golden path：一條預設安全、可以被複製、出事找得到紀錄的最短路徑。它不只是 SDK，還包括：
- 一個能跑起來的 reference implementation，而不是只有 API 文件。
- 清楚的 tutorial，讓第一次接觸的人知道從哪裡開始。
- 預設接好 identity、權限、audit、eval 與 cost tracking。
- 有 owner 的支援管道，以及常見失敗模式的 troubleshooting。
- 明確的 escape hatch；特殊需求可以離開 golden path，但要知道自己接手了哪些責任。
Developer experience 不是把文件網站做漂亮，而是縮短一支內部團隊從「有想法」到「安全上線」的距離。如果以前要三個月、現在兩週能完成，而且沒有重蓋權限、監控與評估，平台才真的產生 leverage。
對 business stakeholder 的溝通也一樣。對方通常不在乎用了哪個 vector database 或 orchestration framework，他在乎的是：原本要兩天整理的資料現在多久完成、錯誤怎麼被攔下、每個月成本多少、出事時找不找得到原因。技術負責人的價值，就是把架構決策翻成這些能做決定的語言。
如果從零開始，我會這樣走前 90 天
這不是所有組織都適用的固定公式，但它能避免平台一開始就變成一場過度設計的大工程。
Day 1–30：先畫問題與邊界，不急著選框架
- 盤點最常出現、最值得重用的知識、分析與流程需求。
- 找出資料 owner、權限來源、風險等級與目前的人工 baseline。
- 選一個低風險、高頻率、成果容易驗收的 reference workflow。
- 定義第一版 KPI、non-goal 與需要人工確認的 action boundary。
Day 31–60：做出 reference workflow，也做出第一條 golden path
- 端到端完成 ingestion、retrieval／tool use、eval、部署與觀測。
- 不只測 happy path，也把權限錯誤、資料缺漏、模型 timeout 放進題庫。
- 和第一批內部使用者一起使用，而不是交付後才等 feedback。
- 記錄哪些元件真的被重複使用，哪些只是單一場景的產品邏輯。
Day 61–90：把重複的能力平台化
- 抽出穩定的 API、SDK、template 與 policy，不急著抽象所有差異。
- 建立 onboarding 文件、支援管道、service ownership 與 incident 流程。
- 上線 adoption、品質、可靠性、成本與 business impact dashboard。
- 用真實使用資料排下一季 roadmap，而不是用最新技術新聞排。
90 天之後最重要的產出，不是「完成了平台 1.0」，而是證明這個團隊找到了一個能反覆運轉的 loop：從問題出發、交付能力、量測結果，再把學到的東西餵回 roadmap。
這條路為什麼吸引我
回頭看自己的職涯，從第一位 Backend & DevOps 工程師、把產品後端從零建起，到後來帶團隊、做技術總監，我最常做的其實都是同一件事：把一次性的解法，整理成別人也能使用、團隊能持續維護的系統。
在從零建立醫療 SaaS 後端的那段經歷裡，難的不是選 PHP、Protocol Buffers 或 Kubernetes，而是把部署、監控、權限與開發流程一起建立起來；到了技術總監階段，工作也從「我能不能解掉問題」，變成「團隊能不能看見問題、留下知識、持續交付」。
企業 GenAI 平台把這些老問題換了一組新元件：向量檢索、agent runtime、model router、eval harness。但底層仍然是熟悉的系統工程、平台思維與技術領導。
這也是我寫完整套「從 PoC 到 Production：企業 AI Agent 系統工程」系列後，越來越確定的一件事：GenAI 平台負責人真正要交付的，不是一個很會說話的 demo，而是三個結果——
- 業務拿到的是可信任的能力，不需要理解底下每個模型。
- 工程團隊拿到的是可重用的路徑，不必重蓋安全與維運底座。
- 組織拿到的是持續交付的方法，不會因為工具改名就全部重來。
能做到這三件事，才算真的把 GenAI 從一個專案，變成一個平台。
