DXC 把 Claude 變成營運系統

這篇在拆 DXC 怎麼把 Claude 包成企業營運模式，最後附可直接複製的 rollout 模板。

我看企業 AI 合作看了一陣子，老實說，大多數都一個味道：新聞稿很漂亮，講得像要改變世界，結果落地就變成 demo 工程。我最怕那種「我們和某某大廠策略合作」的句子，因為通常翻譯一下就是：先把 logo 貼上去，後面再說。DXC 跟 Anthropic 這次的說法，至少沒有那麼虛。它不是只說 Claude 能用，而是直接把 Claude 放進 mission-critical enterprise systems，還把工程師、流程、認證一起包進去。我看到這裡就知道，這不是模型合作，是營運打法。

我最在意的也不是 Claude 本身，而是 DXC 怎麼把它塞進真實企業環境。因為我見過太多團隊先把模型接上去，再被資安審查、權限管理、變更流程、舊系統相容性打回原形。最後大家都在忙著修補，沒人在做產品。DXC 這次比較像反過來：先證明自己能在內部用，再把同一套方法往外推。這種做法很土，但很實際。企業買單的從來不是「AI 很強」，而是「你能不能在我這種爛環境裡活下來」。

我這篇的拆解主要靠 DXC 6 月 11 日的 newsroom 文章：DXC and Anthropic announce multi-year global alliance。DXC 在文中提到自己是 Claude Partner Network 裡少數的 Global Premier partner，也說 Claude 已經在 DXC OASIS production 裡跑，還有超過 50 個 joint customers。這些數字是原文自己給的，我就照著它們來拆，不亂加戲。

DXC 不是在買模型，是在買一套交付方法

“Together, the companies will train a dedicated workforce of tens of thousands of forward-deployed, Claude-certified engineers and builders to bring Claude models into production inside the mission-critical technology infrastructure systems DXC operates...”

這句話很關鍵。翻譯一下就是：DXC 不把 Claude 當聊天工具，也不把它當某個 side project。它把 AI 直接塞進交付模型裡。這差很多。你如果做過 enterprise service，就知道真正難的不是讓模型回答問題，而是讓它活在 procurement、security review、change management、incident response 這些鬼東西裡面，還不把人搞瘋。

DXC 的意思其實很直白：我們會像養其他 mission-critical 團隊一樣養 AI 團隊。先訓練人，再認證人，再把人丟進客戶環境，最後讓這群人對結果負責。這才像 enterprise software 真正的進場方式，不是靠一張漂亮 slide，而是靠勞動、流程和重複。

我喜歡這個 framing，因為它講了大實話：多數 enterprise AI 失敗，根本不是 model failure，是 integration failure。模型通常沒那麼差，差的是組織沒準備好，流程沒定義，guardrail 是假的，人也沒訓練。DXC 想做的，就是把這些零碎又麻煩的東西包成一套可複製服務。

實操上，如果你也在做企業 AI，我會建議你先別賣「AI 能力」，先賣「營運方法」。把誰安裝、誰審核、誰監控、誰負責 incident、誰簽變更，全部寫清楚。這些答不出來，你就還在 demo 階段，別急著叫產品。

• 先寫服務角色，再決定模型。
• 把模型存取權和 production authority 分開。
• 把認證做成部署的一部分，不要事後補。

Customer Zero 不是口號，是唯一能讓人信的證據

“The model reflects DXC’s Customer Zero philosophy: the company validated Claude inside its own operations first, under production-grade security and compliance requirements, before bringing that capability to customers.”

這句是整份公告最像樣的地方。因為我真的被太多廠商搞過：要客戶當測試環境，還要客戶自己吞風險。這順序完全反了。你如果要我相信你的 AI 能進 regulated system，先證明你自己有用過，而且是用在跟客戶同等級的壓力底下。

DXC 還說 Claude 是他們建 DXC OASIS 的主要開發工具，這個 AI-native orchestration platform 已經在 production 裡跑。原文甚至提到 Claude 幫他們把 software delivery 加速了估計 10x，還有超過 95% 的 code 是 Claude 先生成、再由人類 review。這種數字我不會只看字面爽不爽，因為真正重要的不是「生成比例」，而是 review 層有沒有真的在抓 bug、資安問題、跟那些 enterprise 場景裡最愛冒出來的邊角案例。

我之前看過一些團隊，自稱 AI coding 很猛，結果一進 production 就露餡，因為根本沒建立 review discipline。Customer Zero 的價值就在這裡：它不是裝飾用的 slogan，而是降低買方恐懼的證據。你先把自己當白老鼠，客戶才比較願意相信你不是拿他們試刀。

實操寫法很簡單：先拿內部 support queue、codebase、ops backlog 任一個真實流程試跑。不要選最簡單的 toy problem，要選會真的卡人的那種。把失敗模式、人工補救、審核節點全部記下來。等你要對外講方案時，拿這份紀錄出來，而不是拿一張「AI 提升效率」的圖。那種圖現在沒人信了。

Forward-deployed engineers 才是這套打法的核心

“At the center of the alliance, DXC is establishing a dedicated team of forward-deployed engineers to work directly inside customer environments.”

我一直對那種「平台先行」的故事很有戒心，尤其當客戶真正需要的是「有人能把這玩意兒運起來」。DXC 這次算是把話講老實了：真正的價值不只在 Claude，也不只在 DXC 的服務，而是在一群能翻譯 model、enterprise stack、business process 的人。沒有這層人，AI 很容易變成一個很貴的擺設。

Anthropic 也有參與。DXC 說這些工程師會透過 Anthropic Partner Academy 在 90 天內訓練和認證，還能每天用 Claude，並一路往更高難度的 proficiency level 走。這不是在堆證照而已，這是 control mechanism。因為 enterprise 客戶最怕的不是你沒有 AI，而是你的人根本不知道什麼時候模型可以動、什麼時候只能建議、什麼時候應該閉嘴。

我自己看這種模式，最有感的是它承認一件事：AI 進到 operations 之後，一定需要人站在中間。不是為了拖慢速度，而是為了讓系統在真實環境裡不會亂炸。Forward-deployed engineer 其實就是人形的翻譯器，把「我們想要 AI」翻成「我們能活著上 production」。

實操上，如果你也要做 AI services motion，不要把 product 跟 deployment 切得太乾淨。你需要 field layer，需要能進客戶現場的人。小團隊可能是一個 solutions engineer 加一個 domain specialist；大一點的公司就設正式 deployment team。重點不是名字，是你有沒有真正在客戶環境裡調整系統的能力。

• 從原本就懂營運環境的人裡面招。
• 不要拿 toy prompt 當認證內容。
• 讓 field team 有權限改系統，不然只是在陪跑。

DXC OASIS 不是配角，是整個故事的證明

“Claude is already powering DXC OASIS, the company’s AI-native orchestration platform for managed services, now in production with more than 50 joint customers.”

這句話一出來，我對整份公告的判斷就變了。OASIS 不是未來式，不是某個 roadmap 上的願景，它是 DXC 已經在跑的東西。意思就是：他們不是先畫餅再找模型，而是先有一套 operational system，現在把 Claude 塞進去，然後再跟 Anthropic 一起放大。

DXC 把 OASIS 描述成 managed services 的 AI-native orchestration platform，Claude 則是 default foundation model。我翻成白話：他們想把 managed services 裡一部分重複、繁瑣、但又不能亂來的工作自動化，而且不是假裝全自動。這才是比較正常的 agentic AI。系統可以協調任務、草擬動作、路由工作，但最後的大決定還是人負責。

我看過很多團隊把 orchestration 當成 prompt 外掛，這真的很危險。Orchestration 不是「問模型、拿答案」這麼簡單，它是 policy、routing、state、escalation、auditability 的總和。企業 AI 到底有沒有用，常常就卡在這裡。DXC 的賭注是：Claude 可以坐在 control plane 中間，而且真的幫得上忙。

實操寫法：如果你在做 AI ops platform，先設計 state machine，再設 escalation path，再定義哪些東西要 log、哪些要 block，最後才選模型。順序反過來通常都會很慘。模型如果是第一個決定，你八成已經在做錯事。

他們只挑幾個產業下手，這反而比較像真的

“Initial focus areas include insurance, cybersecurity, and application services, where DXC brings significant domain and operational expertise...”

這點我反而放心。很多廠商一講 AI 就想包山包海，好像只要貼上 enterprise 兩個字就能賣所有行業。DXC 這次只挑 insurance、cybersecurity、application services，我覺得是對的。因為這幾個領域夠髒、夠難、夠能驗證價值，但又不是完全沒脈絡的亂戰場。DXC 本來就有 domain knowledge，這樣才有機會把 AI 真的塞進流程裡。

它列的 use case 也很有意思。在 insurance，它說要做跟客戶 operating model 對齊的 agentic solutions；在 modernization as a service，它想讓 Claude 幫忙分析、refactor、transform legacy codebase；在 cybersecurity，它想把 AI-driven resilience 放進 SOC；在 application services，它想把 Claude 直接嵌進 maintenance 和 management 環境。

這不是一坨 AI 點子，這是一個有邏輯的服務組合。我會把它理解成：企業 AI 最容易先從既有 service wrapper 裡長出來。你不一定要創一個新類別，你只要把一個原本就有人付錢的服務做得更快、更穩、更省人力，就已經很有機會了。

實操上，我會建議你只挑一個你最有把握的 vertical、一個最常卡住的 workflow、還有一個客戶本來就會看的 metric。然後把 AI 方案圍著這三件事做。不要再講「企業通用智能」了，沒人買。大家買的是少做人工、少出 incident、加快 modernization、縮短 response time。

Anthropic 的角色是信任加分發，不只是 API

“DXC becomes one of the few Global Premier partners in the Claude Partner Network.”

這一段從 Anthropic 的角度也很值得看。它不是單純把模型賣出去，而是透過一個已經深扎企業營運的夥伴去擴散 Claude。這不只是 distribution，也是一種 trust play。DXC 有合約、有 compliance posture、有 operational footprint；Anthropic 提供模型和 safety 故事。兩邊各拿自己最強的東西。

Anthropic 的 CCO Paul Smith 還提到，DXC 是先在自己內部、用跟客戶相同的 security 和 compliance 要求驗證 Claude。這句話很重要，因為它直接回答企業買家最常問的問題：你自己有沒有真的在真實環境裡用過？如果有，對話就比較像討論落地；如果沒有，對話就會變成風險表演。

我覺得這類合作最有意思的地方，是它不是 marketplace 式的模型曝光，而是 delivery capacity、certification、embedded engineering 的組合。這種東西比較難假裝，也比較有用，尤其當你真的想把 AI 從試驗室推進 operations 時。

實操寫法：如果你是 model company，不要只想 API access，還要想誰能 deploy、govern、support。你如果是 services company，也不要只想轉售模型，重點是你能在客戶世界裡多加什麼 implementation muscle。這才是合作有沒有料的分界線。

可抄的模板

# 企業 AI rollout 模板：把模型變成營運能力，而不是 demo 工具

## 1) 我們到底在賣什麼
我們不是在賣一個模型 demo。
我們是在賣一套能進 mission-critical systems 的營運方法。

## 2) Customer Zero 證明
對外 rollout 之前，我們先做內部驗證：
- 先部署到內部真實流程
- 至少跑一個真的工作流
- 定義 review / approval 步驟
- 記錄 failure modes 和人工介入點
- 文件化 security、compliance、audit 要求

## 3) Field team
我們建立一個 forward-deployed 團隊，成員包含：
- domain expert
- platform engineer
- security / compliance reviewer
- implementation lead

每個人都要能回答：
- 模型在哪些情況可以直接動作
- 哪些情況只能建議
- 哪些情況一定要人工批准
- incident 要怎麼升級處理

## 4) 認證路徑
認證內容應該涵蓋：
- model behavior basics
- workflow design
- prompt 與 tool 使用
- logging 與 audit trail
- security 與 data handling
- rollback 與 incident response

建議節奏：
- Day 1-15：環境與政策訓練
- Day 16-45：guided implementation
- Day 46-70：supervised production work
- Day 71-90：certification review 與 signoff

## 5) Production controls
每個 deployment 必備：
- access control
- approval gates
- observability
- audit logs
- fallback paths
- incident owner
- rollback plan

## 6) Use case 選擇
先從一個窄場景開始：
- insurance operations
- cybersecurity operations
- application maintenance
- code modernization

挑選標準：
- 工作重複
- 痛點清楚
- 有既有流程 owner
- 有可量化節省
- 風險可控

## 7) Launch checklist
上線前確認：
- 內部 proof 已完成
- 客戶流程已畫清楚
- security review 已過
- human review 步驟已文件化
- escalation path 已測試
- success metrics 已定義

## 8) 對客戶的承諾
我們會幫你：
- 減少人工操作
- 加快營運任務
- 加速 legacy modernization
- 保持人類控制權
- 在真實企業限制中運行 AI

## 9) 一句定位
我們用 certified engineers、production controls、Customer Zero rollout model，把 AI 帶進 mission-critical systems。

這份模板不是照抄 DXC 的新聞稿，而是我把它背後的營運邏輯抽出來後，寫成你可以直接拿去用的版本。你如果今天也想把 AI 做進 regulated enterprise environment，這份骨架比一百句「我們很懂 AI」有用多了。

我最想保留的是 proof、certification、field deployment 這三件事。最想拿掉的是任何過度吹 autonomy 的話術。企業客戶真的不需要詩，他們要的是：這東西上 production 之後，會不會把我搞死。

原始來源是 DXC newsroom 的 公告頁。我這篇前半是原創拆解，後半模板是我根據原文與 Anthropic、Claude Partner Network、以及 DXC 官網 的公開資訊整理出來的可抄版本。