统一协作平台和 AI 中台，是组织能力基础，还是新的官僚机构与单点故障？

多个部门各自建设 AI，会重复采购、重复接入和重复踩坑。企业于是希望统一中台解决一切。过一段时间，中台也可能变成所有需求排队、业务绕开、故障影响全公司的中心。

AI 中台应该提供可复用的共性服务，业务团队继续对场景和结果负责。它有没有价值，要看复用、交付速度、可靠性和替代能力。

先把中台写成服务目录

共性服务 中台负责 业务团队负责

身份与权限 统一接入、策略与审计 明确角色、对象和业务范围

模型与工具 接入、路由、注册和成本控制 选择适用能力并验证效果

数据与知识 通用框架、权限和追溯 提供口径、内容和业务所有者

评测与发布 工具、环境、回归和灰度能力 样本、标准、难例和上线决定

监控与治理 日志、告警、供应商与安全底线 运营、接管和业务结果

中台不应替业务定义问题、正确答案和用户运营。离一线太远的团队，很难独自判断场景价值。

四个指标防止中台官僚化

第一，接入一个新场景需要多久。第二，共用能力被多少真实场景持续复用。第三，业务团队通过中台减少了多少重复建设。第四，中台故障与流程排队给业务造成多少影响。

只统计接入数量，很容易鼓励强制统一。业务开始大量使用影子工具绕开，也可能说明服务已经不适配真实需求。

单点故障要提前处理

身份、模型网关和工具注册一旦集中，故障影响会扩大。关键能力需要容量、隔离、降级和恢复，场景之间不能互相拖垮。

数据、应用和评测资产还要保持可迁移。某项中心服务不可用时，关键业务至少能够降级到人工或安全模式。

用产品方式运营，而非审批方式管理

明确服务目录、接口、成本、支持承诺和反馈入口。根据真实复用与业务结果决定投入，不适合统一的场景允许采用受控例外，低价值服务及时下线。

好的中台让业务少做重复建设，坏的中台让业务多走一道审批。

本问行动：用接入时间、真实复用、重复建设和故障影响四项复盘中台，别只报“接入了多少项目”。