不少企业AI项目做不起来，问题不在技术，而在没人真正负责。业务说"这是IT的事"、IT说"需求你没讲清"、老板要结果却没人统筹，最后模型躺在服务器里没人用。AI落地绕不开组织这道关——它不是加几个人，而是把"谁定义场景、谁做技术、谁管运营、谁担结果"说清楚。下面把组织形态从松散到成熟拆成四档，再讲清楚各角色的权责和最常见的搭错法，让处在不同阶段的公司都能找到自己的那一层。

第一档：兼职AI小组，适合刚起步

年营收几千万、IT两三人的公司，没必要设专门部门。最务实的做法是从业务和IT各抽一人组成兼职AI小组，业务方负责提真实场景和验收，IT方负责工具和对接，每周固定半天碰进度。关键是老板要给这两人明确的"可以花时间做AI"的授权，否则会被日常救火吞掉。小组不追求大成果，先打透一两个小场景证明价值。这一档的坑是"挂名不投入"——人抽了但工时没给，等于没建。衡量标准是每月是否真有一两个场景从想法走到可用，而不是开了多少会。

第二档：业务嵌入型，适合多线试水

当AI渗入多个部门，集中小组顾不过来，就该把能力嵌回业务。做法是每个业务部门设一名"AI接口人"，由他对接技术、在本部门推动试用和反馈，技术侧保留一个小平台组做支撑。接口人通常是业务骨干而非纯IT，因为他最懂本岗痛点和验收口径。关键是接口人要有"做AI"的正式职责，写进岗位说明而非客套。这档的坑是接口人成了"传话筒"，只把需求扔给技术、不负责落地推动，场景因此半途而废。衡量看各业务线是否都有自己的在用场景，而不只是总部有一个。

第三档：AI卓越中心CoE，适合规模化阶段

当AI要变成公司级能力而非零星项目，就该建卓越中心（Center of Excellence）。CoE不直接做业务，而是定标准、供工具、训人才、管资产：统一技术栈与提示词规范、维护共享知识库和组件、给各业务线做赋能和审核。它像"内部参谋部"，让分散的尝试变成可复制的能力。关键是CoE要有对业务线的"治理权"而非只做服务，否则标准没人听。这一档适合已有十个以上在用场景、开始重复造轮子公司。坑是CoE变成新的官僚层，只写规范不下场，最终被业务线绕过。衡量看复用率和各线自主交付占比。

角色权责：业务、技术、运营三足

无论哪档组织，三个角色必须分清。业务负责人定场景和验收、对结果负责；技术负责人管模型、集成和数据；运营负责人盯使用率、反馈和迭代。很多公司把三者混给一个人，结果他既当裁判又当运动员，项目很容易偏。一个实用做法是画一张RACI矩阵，把"谁负责、谁批准、谁咨询、谁知会"写死到每个环节。权责清晰后，扯皮少一大半。组织搭错的最典型表现是"开会的人都来、出事时没人认"，RACI就是治这个的。

常见搭错法：三种最贵的组织坑

第一，只设技术岗不设业务owner，模型做出来没人用——AI是业务工程不是纯技术。第二，老板挂名不真管，资源协调时各线不配合，项目卡在跨部门。第三，把CoE当考核部门而非赋能部门，业务线为了应付合规而敷衍，能力反而退化。这三种坑踩中任意一种，前面买的算力和工具基本打水漂。对应的解法是：每个场景必须有一个业务侧责任人写进考核；老板至少每月听一次AI进展；CoE的定位是"帮业务赢"而非"管业务"。组织对了，AI落地才有承载的骨架。

AI落地的组织搭建不是加人而是分责：从兼职小组、业务嵌入、到卓越中心CoE三档递进，核心是把业务、技术、运营三角色用RACI分清。避开"只设技术岗、老板不真管、CoE变官僚"三个坑，组织这道关把住了，模型才有承载它的骨架，AI落地才不会停在演示环节。