自建、外采与联合共建：企业 AI 能力的三条获取路径

自建、外采与联合共建，说的是企业拿到 AI 能力的三种方式：自己组队做、把需求交给外部服务商、两边各出一部分并共同承担。很多讨论一上来就比价格，于是永远比不出结论 —— 因为这三条路径卖的根本不是同一样东西：外采买的是当下的结果，自建买的是长期的调整能力，联合共建买的是过程中的知识转移

三条路径各自交付什么

• 自建：交付的是团队与可复用的底座 —— 数据接入、权限模型、评测集与发布流程都留在企业内部，代价是前期投入与招人周期。
• 外采：交付的是可用的结果 —— 用较短的时间拿到一个能跑起来的场景，代价是边界与调整节奏受服务商约束。
• 联合共建：交付的是过程能力 —— 外部团队负责起步与方法，内部团队在项目中接手，代价是双方都要投入真正的人，而不是挂名配合。

按能力分层，而不是整体三选一

更可执行的做法是把能力拆成四层分别决策，而不是给整个项目选一条路。同一家企业完全可能底座自建、场景联合共建、部分运维外采 —— 关键在于每一层的责任归属是否写清。

• 底座（部署形态、身份与权限、审计）：必须自建或至少自控 —— 这三样决定边界，交出去等于把边界交给别人。
• 模型层：通常不自己训 —— 能用成熟模型解决的部分没有自研价值，除非有明确的独占数据与稳定任务。
• 场景层（把业务流程翻译成 AI 能执行的动作）：适合联合共建，因为这里最需要的是企业内部才有的业务知识。
• 运维层（索引更新、评测复跑、版本升级）：可以外采，但责任必须有人兜，且要能随时收回。

判断依据：四个问题

• 数据能不能出域：不能出域的部分没有外采选项，讨论到此为止。
• 这个场景会不会变：变化快的场景需要自己保留调整能力，否则每次改动都要走一遍采购流程。
• 失败时谁承担后果：承担业务后果的人，必须对上线与回滚有决定权。
• 两年后这份能力归谁：如果目标是内部能力沉淀，合同里就该有知识转移与接手条款，而不是一句口头承诺。

三种路径最常见的错配

• 把底座外采，再把场景自建：边界不在自己手里，场景做得越多，风险敞口越大。
• 把场景自建，却没人定义验收：技术团队按相似度自评，业务方到最后才发现答案不可用。
• 联合共建只挂名：内部团队全程旁观，项目结束，能力也随外部团队一起离场。

起步顺序

合理的顺序是：先把边界与权限握在自己手里，再挑一个读写最轻的场景试水，最后才决定哪些部分长期自己做。这个顺序的好处是每一步都能单独验证 —— 边界可以用越界请求被拒绝来验证，场景可以用业务评测集来验证，能力沉淀可以看第一个接手的人是否真的独立跑通过一遍

反过来的顺序（先买一个场景，再回头补边界）在小范围试点时看不出问题，一到多场景并行就会卡住：每个新场景都要重新谈一次数据边界，而此前的场景已经按另一套规则上线了。