隨著企業AI計劃從試點階段走向規模化,跨職能團隊的結構與治理維度成為決定性成功因素。早期採納AI的組織如今面臨二階挑戰:如何將跨職能協作制度化,同時避免製造官僚主義障礙。本文基於蜂啟諮詢在亞太地區的諮詢實踐,探討區分2026年高績效AI團隊的組織模式、問責框架與治理機制。這是我們關於構建能夠創造複利價值而非一次性實驗的AI團隊系列文章的第二部分。
2026年AI團隊結構是如何演進的?
過去十八個月,圍繞AI團隊結構的討論發生了根本性變化。2025年,大多數組織正在組建第一批跨職能AI團隊——通常包括一名資料科學家、一名資料工程師、一名產品經理和一名業務發起人。這些團隊以特別專案模式運作,刻意與組織約束隔離,以快速證明價值。當時的任務很簡單:證明AI能夠推動某項業務指標,並贏得擴張的權利。
2026年,挑戰已從組建轉向規模化。組織同時運營多個AI團隊,每個團隊嵌入不同業務單元,但共享基礎設施、資料平台和治理框架。從單團隊到多團隊運營的轉變,暴露了此前不存在的結構性矛盾:誰擁有共享特徵儲存?運算成本如何在團隊間分配?當A團隊部署的模型消費了B團隊準備的資料並產生錯誤輸出時,誰應承擔責任?這些問題無法由單個特別專案小組回答,它們需要一套運營模型。
最成功的組織採用了我們稱之為「中心輻射」的模式。中央AI卓越中心——即中心——負責平台工程、治理標準、模型風險框架和人才發展。業務單元團隊——即輻射端——負責用例識別、領域特定模型微調和運營部署。這一模式平衡了業務單元快速行動所需的自主性與企業風險管理所需的一致性。關鍵在於,中心並非把關者,其角色是賦能:提供共享基礎設施、可復用元件和治理護欄,團隊自願採納這些要素,因為它們減少摩擦而非增加摩擦。
檢驗你的結構是否有效的實用方法是只問一個問題:一個新業務單元能否在一個季度內,無需向中央團隊提交工單,就上線一個生產級的AI用例?如果答案是否定的,那麼你的中心正作為瓶頸而非加速器在運作。2026年勝出的組織把中心當作一個產品組織來運營,其內部客戶是各業務單元輻射端——並且它們衡量中心的標準是採用率,而不是控制力。
真正有效的治理模型是什麼樣的?
AI治理仍然是企業AI中最被誤解的維度之一。許多組織已建立AI治理委員會——通常出於監管壓力——但這些機構往往成為瓶頸而非賦能者。加速交付的治理與阻礙交付的治理之間的差異,歸結為我們在每個客戶專案中都應用的三條設計原則。
第一,治理應分層。並非每個AI用例都需要相同程度的審查。回答內部HR查詢的聊天機器人與自動信用決策模型承擔的風險根本不同。按風險等級對治理進行分層——最小、有限、高和不可接受,呼應歐盟AI法案的框架——使組織能夠按比例分配審查資源。根據我們的經驗,約70%的企業AI用例屬於最小或有限風險等級,可通過自動化或輕量級審查流程推進。僅剩餘30%需要完整的委員會級審查。大多數組織犯的錯誤是對每個用例套用高風險流程,結果讓委員會淹沒在低風險的審查中,真正有風險的模型反而得不到應有的關注。
第二,治理應嵌入開發流程,而非事後附加。模型卡片、資料血緣文件和偏差測試應作為CI/CD流程的一部分自動生成,而非在委員會審查前數週手動編寫文件。將治理嵌入MLOps工具鏈的組織,其審查週期比依賴手動文件的組織快五倍。關鍵洞察在於:合規產物是良好工程實踐的副產品,而非獨立的工作流。當資料科學家提交一個訓練流水線時,模型卡片應當作為該次提交的副作用自動生成——而不是每季度為了應付審計而手忙腳亂地拼湊。
第三,問責必須明確。生產環境中的每個AI系統都應有指定的業務所有者——不是技術所有者,而是對結果負責的業務領導者。此人審批用例、簽署風險評估並監控部署後性能。沒有明確的業務所有權,AI系統會漂移到無人負責的灰色地帶。我們建議為每個生產模型建立單頁問責章程,由業務所有者簽署並每季度審查。章程寫明所有者、模型被授權推動的指標、模型退化時的回退行為,以及審查節奏。它刻意只有一頁,這樣忙碌的高管才會真正去讀。
有效的治理模型還需要一個逃生艙。當模型在生產中的行為發生變化——新的資料分佈、監管變動、被檢測到的偏差——必須預先約定一個終止開關,以及有權按下它的具名責任人。治理不僅是批准上線,同樣是關於安全地停止那些已經超出授權期限的系統的能力。
如何避免破壞跨職能AI團隊的常見陷阱?
我們的諮詢工作發現了幾個反覆出現的失敗模式,這些模式削弱了跨職能AI團隊的效能。理解這些陷阱對於希望將AI能力擴展到初始實驗之外的組織至關重要,因為每一個陷阱都會悄悄地把一個有前景的試點變成永久停滯的計劃。
最常見的陷阱是「資料科學孤島」。在許多組織中,資料科學家孤立工作,從業務利益相關方接收需求並將模型交給工程團隊。這種線性交接模式——類似於困擾軟體開發數十年的瀑布方法——在每個介面處造成錯位。資料科學家構建工程團隊無法部署的模型,業務利益相關方獲得不匹配運營現實的解決方案,原型與生產之間的差距隨每次迭代不斷擴大。解決方案是圍繞產品而非職能組建團隊。跨職能AI產品團隊應包括資料科學、資料工程、軟體工程和產品管理,從開始就協同工作。這並不意味著每個人都什麼都做——專業化仍然重要——但確實意味著所有視角在規劃、設計和審查期間都得到體現。團隊擁有的是一個結果,而不是一次交接。
第二個陷阱是將AI治理視為合規演練而非能力。純粹將治理視為勾選活動的組織——製作文件以滿足監管者——錯失了將治理建設為競爭優勢的機會。穩健的治理通過提供清晰的護欄使團隊能夠自主運作,從而加速實驗。當團隊了解邊界時,可以在邊界內進一步推進。將治理重新定義為賦能者而非約束的組織,其表現始終優於將治理視為負擔的組織。我們見過一些團隊,僅僅通過提前公佈規則並自動化檢查,就把十四週的審批週期縮短到兩週以內。
第三個陷阱是對更廣泛組織AI素養的投資不足。技術團隊可以構建卓越的系統,但如果業務領導者缺乏提出正確問題、批判性解讀輸出和做出明智決策的素養,影響將大打折扣。最成功的組織投資於結構化AI素養專案,覆蓋範圍超越技術團隊,包括高管、中層管理和運營人員。這些專案不是教每個人寫Python——而是培養判斷力,以區分可信的AI輸出與聽起來合理但實際無價值的內容,以及培養技術團隊能夠據此行動的詞彙來闡述業務需求。一個能讀懂混淆矩陣的業務領導者,對AI專案的價值超過三名無法影響任何決策的額外資料科學家。
第四個陷阱,也是我們在2026年見得最多的「平台悖論」:組織資助了幾十個單點解決方案——一個用於向量搜索,一個用於評估,一個用於可觀測性——卻沒有連貫的平台戰略,隨後又奇怪為什麼團隊之間無法共享工作成果。中心的職責是精選少量、有明確主張的共享工具,讓物流團隊能夠複用金融團隊構建的元件。沒有這種精選,每個團隊都在重複造同一個輪子,企業永遠無法形成複利。
跨職能AI團隊應包含哪些角色?
客戶最常問的一個問題就是:團隊裡到底應該坐誰。最小可行團隊需要結合四種視角,大多數成熟團隊在成長過程中會再增加兩到三個角色。四個基礎角色是:負責建模與評估的資料科學家;負責流水線與特徵品質的資料工程師;負責部署、API與可靠性的軟體工程師;以及負責業務結果與待辦清單的產品經理。在這個核心之外,最高效的團隊還會嵌入一名兼職的領域專家、一名在中心無法提供工具時的機器學習平台工程師,以及面向高風險等級用例的風險或合規夥伴。
最常被遺漏的角色是擁有真正業務權限的產品經理。太多AI團隊由一名技術過硬的個體貢獻者領導,而此人無權改變任何業務流程。結果就是一個漂亮的模型永遠無法投入運營,因為沒有任何人為周邊的流程變革負責。我們建議客戶指派一名向業務單元而非技術職能匯報的產品經理,這樣團隊才對一個業務指標負責,而不是對一個模型準確率分數負責。
同樣重要的一點是構建者與翻譯者的比例。隨著團隊擴大,陷入困境的組織往往是那些每次對話都需要資料科學家為非技術利益相關方解釋結果的公司。投資於能夠在這兩種角色之間翻譯的分析師和具備AI素養的業務夥伴,可以減輕稀缺技術人才的負擔,並加速從洞察到行動的閉環。
如何保持跨職能AI團隊的問責制?
問責制來自一個單一的、共享的「完成定義」,它包含業務影響,而不只是模型交付。跨職能團隊應當被衡量的是:它所被授權推動的那個指標是否真的移動了。這迫使資料、工程和業務成員在模型部署很久之後仍保持對齊。當只有技術團隊被問責時,模型上線了,價值卻蒸發了。
第二個抓手是「設計即治理」,而非「事後治理」。在構建的每個階段放置一個輕量級審查檢查點,為模型風險指定具名所有者,並隨時記錄決策。這樣團隊既能快速前進,又不會積累一筆必須在計劃擴張前由某人清理的合規債務。
第三個抓手是成本與價值的透明化。每個團隊都應在一張儀表板上報告它消耗的運算與資料支出,以及它創造的業務價值。當成本與價值並排呈現時,對話會從「AI有用嗎?」轉變為「我們下季度該資助十二個用例中的哪一個?」這是一個成熟AI組織才會有的對話,而它只有在問責被嵌入運營節奏、而非每年績效評估時宣稱一次的情況下才可能實現。
應如何衡量跨職能AI團隊的影響力?
衡量是大多數AI計劃悄悄失敗的地方,因為它們報告的是活動——訓練了多少模型、產出了多少筆記本、交付了多少儀表板——而不是影響。跨職能團隊應當對照其章程中寫明的業務指標來接受衡量:縮短的周期、預防的缺陷、受到影響的收入,或避免的成本。我們指導客戶在寫第一行代碼之前就定義好該指標,並把「上線了卻沒有推動任何指標」的模型視為一次失敗的交付,而不是成功。
除了主指標,我們建議跟踪三個能預示影響能否複利的先行指標:複用率(其他團隊是否在採用該團隊的元件?)、素養(業務夥伴是否在做出更好的AI驅動決策?)、速度(從想法到生產的時間是否在下降?)。這三者告訴你團隊是在建設持久能力,還是在生產一次性製品。一個交付了高精度模型卻三項指標無一改善的團隊,是一個成本中心;一個讓三項指標都適度改善的團隊,正在為接下來的十個用例打基礎。
如何從一支AI團隊擴展到一支AI團隊艦隊?
從一支團隊到一支艦隊的轉型,是結構與治理要麼兌現、要麼崩塌的地方。有效的模式是把第一支團隊當作參考實現:記錄它的工作方法,將可復用元件代碼化,並讓它負責人晉升為中心角色,去幫助搭建下一支團隊。每支新團隊都不應重新設計運營模型——它應當繼承這套模型,然後把自己的改進回饋給共享手冊。
規模化還需要刻意管理中心的容量。一個被要求用四人的團隊支持十個輻射端的中心,會變成我們早先警告過的瓶頸。中心的預算應當隨輻射端數量一同擴大,並且中心的授權應當被明確設限:它擁有平台與標準,而不是用例。當中心開始擁有用例時,業務單元就停止建設自己的能力,整個模型退化回集中式交付——而這恰恰是被中心輻射模式設計來避免的結果。
最後,規模化需要人才戰略。大多數AI艦隊面臨的約束不是工具或資料,而是能夠領導跨職能團隊的資深人才。成功規模化的組織會建設一條領導梯隊:他們讓優秀的個體貢獻者輪崗擔任團隊負責人,給予業務培訓,並以成果而非模型來獎勵。沒有這條梯隊,每支新團隊都由首次擔任領導的人組建,他們會重複同樣可避免的錯誤,艦隊永遠達不到巡航速度。
重點問答
一支跨職能AI團隊應該有多少人?
最小可行團隊需要結合四種視角:資料科學家、資料工程師、軟體工程師,以及擁有業務結果的產品經理。大多數成熟團隊會再增加一名兼職領域專家、一名在中心無法提供工具時的機器學習平台工程師,以及面向高風險等級用例的風險或合規夥伴。規模通常落在六到十人之間;超過這個規模,團隊就應按產品線拆分,而不是繼續膨脹成一個難以協作的龐大集團。
企業中誰應該擁有AI治理?
治理由雙方共同擁有:中央職能設定分層標準並運行高風險用例的審查委員會,而每個生產模型都有一名對結果負責的具名業務所有者。業務所有者——而非技術負責人——審批用例、簽署風險評估並監控部署後表現。這種分工在保持監督一致性的同時,不把問責從真正受益的人身上移走。
如何防止AI專案在試點後停滯?
停滯通常源於把交付當作終點線。防止它的辦法是:在寫任何代碼之前就定義好業務指標,圍繞產品而非交接來組建團隊,把治理嵌入流水線使上線預設安全,並以指標是否真的移動來衡量團隊。一個包含業務影響的單一共享「完成定義」,能讓資料、工程和業務成員在模型上線很久之後仍保持對齊。
什麼是AI團隊的中心輻射模式?
這是一種運營模型:中央AI卓越中心——即中心——負責平台工程、治理標準、模型風險框架和人才發展,而業務單元團隊——即輻射端——負責用例識別、領域特定微調和運營部署。中心賦能而非把關,提供共享基礎設施與護欄,輻射端自願採納,因為它們減少摩擦。它在業務單元的速度與企業級一致性之間取得平衡。
關鍵要點
- 採用中心輻射模式:中央賦能與業務單元自主性結合,實現更快速、有治理的交付
- 按風險等級分層治理,按比例分配審查資源,避免瓶頸
- 將治理嵌入CI/CD流程,而非視為獨立的文件工作
- 為每個生產AI系統指定明確的業務所有者,並每季度進行問責審查
- 圍繞產品而非職能組建團隊,並在更廣泛組織中投資AI素養
- 以業務影響以及複用率、素養、速度這三個先行指標來衡量團隊,而不是以交付的模型數量
結論
跨職能AI團隊是實現AI價值的組織單元。2026年成功的組織已超越初始實驗,建立了可重複的結構、嵌入式治理和明確的問責制。從特別專案到規模化的轉型並不光鮮,但這是區分AI領導者與AI遊客的關鍵工作。今天構建正確的團隊結構,決定了您的AI投資是隨時間複利增長,還是在最初幾個用例後停滯不前。把治理當作賦能、把問責當作共享、把衡量當作影響的那些團隊,將在下一波AI能力到來時依然屹立——並且依然在複利增長。