NTT DATA：让 9,000 名员工把任务交给 Codex

增长方式先撞墙，工具才被推上台面

NTT DATA Group 总部位于日本，业务横跨咨询、系统开发和运营，是典型的人力密集型全球 IT 服务公司。这类公司的营收结构长期建立在一个简单等式上：接到更多项目，就招更多人。当 AI 开始重塑客户所处的商业环境，这个等式先在内部失效了——继续靠增加人头扩张，既跟不上客户的变化节奏，也无法向客户证明自己有能力交付 AI 转型。

公司因此把增长模型的方向改成通过 AI 创造更大价值。这是一个战略层面的表述，落到执行上会立刻遇到一个具体冲突：一家 IT 服务公司里，最懂技术的工程师和大量非技术岗位的员工，对 AI 的期待完全不同。工程师关心它能不能真正接管工作，非技术员工关心自己会不会连门都进不去。

2025 年 5 月与 OpenAI 建立全球战略合作后，公司先做的不是挑一个高价值场景做试点，而是把 ChatGPT Enterprise 铺到全公司，并配套推出帮助员工把 AI 变成日常工作一部分的项目。顺序值得注意：先让所有人习惯与 AI 对话，再谈把任务交给 AI 执行。今天技术与非技术岗位的团队已经不只是用对话探索想法，也开始把定义清楚的任务交给 AI 完成。

先铺对话，再铺执行：地基是怎么打的

全公司部署 ChatGPT Enterprise 之后，公司设立了内部 OpenAI Center of Excellence，也就是 CoE。它承担的不是宣传角色，而是一组具体职能：许可分配、技术验证、活动组织、用例开发、使用情况监控、知识资源，以及员工要用好 AI 所需要的配套系统。把许可发放和技术验证放在同一个团队手上，意味着「谁能用」和「怎么用才安全」是同一批人回答的问题。

结果是 ChatGPT Enterprise 成为集团日常工作的主要 AI 工具之一。内部调查中，超过 96% 的受访者表示满意，超过 95% 的受访者报告生产力有所提升。这两个数字需要连着它们的口径一起读：它们来自内部调查，属于员工自报，官方材料未披露样本量、调查时间和问卷措辞。它们能说明工具被接受的程度，不能当作产出效率的客观测量。

真正被公司当作地基的，是员工在日常使用中积累的经验。研究资料、写作、内容创作这些工作反复做下来，员工形成了与 AI 协作的习惯和判断力——知道什么样的指令有用，什么样的输出不能直接信。这些习惯为下一步做了准备：把定义清楚的任务委派给 Codex。

一次事故分析，把智能体推到高管面前

让 Codex 获得公司注意力的第一件事，是一个关键系统的复杂事故分析被自动化了。这项工作原先需要 5 名资深工程师、耗时 3 天；用 Codex 后，整个流程在 30 分钟内完成。它之所以有说服力，不在于加速倍数，而在于任务性质——Codex 不是补全代码，而是根据一条指令自主调查、执行、测试并修正。

AI 技术部的 Hiroaki Sato 的判断是，Codex 改变了全公司对 AI 的想法，「AI 可以主导推进工作」这个观念带来的冲击类似当年 ChatGPT 的出现。全球 AI 办公室负责人 Yuji Shono 则把它定位为一种新工作方式的入口：让 AI 去研究、组织、执行和验证工作，每个员工都能重塑自己处理本职工作的方式。

公司随后靠 Client Zero 方法把这种能力扩散出去：把自己的组织当成第一个客户，鼓励员工在日常工作里测试 AI。非技术员工已经在用 Codex 搭轻量工具、整理大批文件、分析 Excel 数据和总结文档——那些人人都想自动化、但手工做又太耗时的活。

两个用例能说明扩散的方向。一个是从信用卡账单里提取交通费用并转入差旅费用表格，Codex 需要跨多个文件工作、理解每张表的结构和填写规则，还要协助核对转录结果。另一个是分析报告：过去要先在商业智能工具里准备数据再搭仪表盘，现在员工可以直接分析原始数据、做出自己需要的报告，对专门工具和专业技能的依赖随之下降。此外，团队用 Playwright 自动化内部系统操作，压缩日常重复任务的耗时，并把自动化打包成 Skills 供全组织复用。

治理不是事后补的，是扩展的前置条件

公司要的不是让少数团队或个别员工用起来，而是让所有人都能放心用。这个目标改变了问题性质：一家服务众多行业客户的 IT 公司，内部怎么用 AI，本身就是对客户的示范。于是在扩大范围之前，OpenAI CoE 先制定并推行了安全指南，配上可操作的采用指引。

指南要回答的是六件很具体的事：哪些数据可以用、Codex 可以连接哪些系统、网络流量如何管理、该用哪种沙箱模式、多高的自动化程度是合适的、哪些环节必须有人工复核。把这些边界写清楚，反而放开了探索空间——技术和非技术岗位的员工不必自己猜什么算越界。今天 Codex 正逐步成为约 9,000 名员工日常工作的一部分。

这个约 9,000 人是 Codex 的使用覆盖规模，不是活跃使用人数，也不是任务处理量。官方材料未披露这批人里的日活、周活和岗位分布，也未披露安全指南全文、审批流程、是否出现过违规事件，以及沙箱模式的实际配置。同样未见公开的还有企业级部署成本、模型调用量，以及从早期试点扩展到这个规模实际花了多长时间。

三组结果，三种不同的口径

官方列出的结果里，最容易被误读的是那个 30 分钟。它对应一个早期的关键系统事故分析用例，是单次任务的对比，不是全部任务的平均效率，更不是全公司的效率提升幅度。原文也未披露这次分析的输入规模、复核方式和结果准确性——换句话说，30 分钟内完成的产出质量与 5 名工程师 3 天的产出是否等价，公开材料无法回答。

第二组是周活跃用户增长到 1.4 倍，条件是发布使用指南并开展实操培训之后。这是一个相对变化量：官方未披露绝对人数、观察周期，也未说明同期是否还有其他推广活动在跑。因此它能支持的结论是「指南加培训与活跃度上升同时发生」，不足以证明这个倍数完全由这两项动作造成。

第三组是 Playwright 自动化内部系统操作后日常重复任务耗时下降，并通过打包成 Skills 实现全组织采用。这项结果只有方向，没有量级——官方未给出节省时长或覆盖任务数。三组结果放在一起看，共同点是它们都由公司自己测量、由供应商发布，未见独立第三方审计。

换个组织，这套做法还成立吗

这个案例真正可迁移的部分不是工具选择，而是顺序：先让全员在低风险的对话场景里建立与 AI 协作的手感，再把明确任务交给智能体执行。前提是组织确实有一批人愿意在日常工作中试，而且有一个像 CoE 这样同时握着许可分配和技术验证的团队——这两件事分给不同部门，安全边界和使用范围就容易互相拖住。

治理先行的做法也有适用条件。把可用数据、可连系统、网络管理、沙箱模式、自动化程度和人工复核位置逐项写明，成本不低，值得付的场景是 AI 要接触内部系统并执行动作，而不只是生成文本。如果只用对话式功能，这套六项边界会显得过重。

需要谨慎对照的是那个 30 分钟。它成立于一家 IT 服务公司、一个有明确技术边界的事故分析任务、一批本身就是资深工程师的对照组。换成流程更模糊、判断更依赖行业经验的场景，同样的加速幅度没有公开证据支持。想复现这类项目，DataHub 建议先验证三件事：任务是否可以被清晰定义、产出能否被人快速判断对错、以及出问题时有没有明确的复核和回退位置——后两项在这份官方材料里都没有展开。