先分清三类需求：员工想用、部门要买、单位得建

合集第 3 篇：多数选型立项第一天就埋了雷——把三种完全不同的需求，混成了一个采购动作。

前两篇讲了约束线和筛漏斗，这一篇往回退一步，问一个更基础的问题：你这次选型，到底是在替谁选？

某区属国企的信息化主任跟我吐槽过一件怪事：他们花大力气招标上线了一套企业级 AI 知识平台，功能全、合规齐、评审高分通过——上线三个月，月活不到员工的 5%。与此同时，公司里真正在用 AI 干活的人不少：写材料的用外部对话工具润色稿子，做表的用各种在线助手，年轻人手机里装着好几个 AI App。公司买的没人用，大家在用的都不是公司买的。

这不是执行力问题，是需求分类问题。政企组织里的「AI 需求」其实是三种截然不同的东西，混在一起立项，几乎必出这种事故。

一、三类需求，三套逻辑

第一类：员工想用——个人提效类。写稿润色、材料检索、翻译、会议纪要、做 PPT 大纲。特征是：使用者就是决策者，需求来自一线体感，见效以「天」计，切换成本几乎为零——不好用，卸载就是了。这类需求的本质是「体验品」。

第二类：部门要买——部门业务类。客服坐席助手、合同审查、风控报告、智能问数、公文辅助。特征是：买单的部门负责人不是天天用的人，需求来自业务指标（处理时长、差错率、人力成本），见效以「季度」计，要和部门现有系统打通。这类需求的本质是「业务件」。

第三类：单位得建——组织基建类。统一模型底座、智能体平台、企业知识库、AI 网关与安全护栏。特征是：决策是一把手工程，涉及采购、安全、信息化多部门会签，预算走立项专项，见效以「年」计，一建就是五年起步。这类需求的本质是「基础设施」。

三类需求的决策权、预算科目、评估标准完全不同——这是本合集最重要的一张表，建议截图：

图1：六个维度，三套逻辑——把它们塞进同一个采购流程，是选型事故的头号根因

二、混在一起立项，会发生什么

回到开头那个事故。复盘时把时间倒回立项会，一切就清楚了：当时业务部门提的需求是「员工写材料太慢」（第一类），领导拍板的逻辑是「要建就建大的，建个平台」（第三类），最后招标出来的是一个重型知识管理平台——用第三类的钱，解第一类的问题。

结果注定尴尬：员工要的是「打开就能用、说了就懂我」，平台给的是「申请账号、按目录检索、走审批流程」。体验品被做成了基础设施，输入框变成了办事窗口。

三个典型混法，对应三种典型事故：

混法一：拿个人体验说服采购。「我用某公有云助手特别好使，给全单位买一样的。」——个人场景里没有数据边界问题（你喂的是公开资料），单位场景里全是。第一类需求里的「好用」，到第三类里往往直接撞上第二层约束（数据边界）。员工用得爽，恰恰是因为它不设防。

混法二：拿采购流程管个人尝鲜。员工想试用一个翻译工具，也要走立项、测评、审批三个月。管的结果是：员工绕过你，直接把内部材料粘进了公网工具——这就是第 20 篇要展开的「影子 AI」，很多单位的禁令越严，泄露越狠，因为合规的供给没跟上。

混法三：部门试点升格为全单位底座。某部门买了个客服助手用得很好，领导一高兴：「就以这个为底座，给全公司建 AI 平台。」——客服场景的模型选型、知识边界、权限模型，和全单位通用底座是两回事。部门件长不成组织底座，硬长就是「模型孤岛」的反面教材（第 17 篇讲集约化时会展开）。

三、责任地图：谁该为哪类工具负责

分清了需求，就该把责任钉到具体角色上。给这张地图一个可以直接抄进制度文件的版本：

第一类（员工想用）：单位负责「给合规的，划不能碰的」。不需要审批每个员工用什么，但要做两件事：① 提供至少一个合规可用的替代工具（哪怕是采购一个企业版席位池）；② 用制度划死红线——什么数据不能喂任何 AI、什么工具禁止处理工作信息。红线要短、要具体、要培训到位（判例提醒：没有专项制度，连辞退违规员工都难，第 06 篇细讲）。

第二类（部门要买）：部门负责人对业务指标负责，信息化部门对约束核验负责。部门选型不过四层约束核验的，信息化一票否决；过了核验的，业务好不好用部门自己定。关键是两条线分开审：约束合规审归合规审，业务评测归业务评测，不许用「业务急需」豁免约束核验，也不许用「流程未完」卡死业务试点。

第三类（单位得建）：一把手定需求边界，专业团队做约束核验与评测，审计全程留痕。这类项目最忌讳「技术部门自己提、自己选、自己验」——决策、核验、评估三权分开，选型档案完整归档（第 19 篇的选型报告骨架就是干这个用的）。

还有一个所有单位都会漏掉的角色：三类需求的接口。员工用出来的好工具会升级成部门采购，部门试点跑通了会升格为组织基建——这些「升格通道」要事先设计好：谁提名、按哪类标准重新核验、原工具的数据怎么迁移。没有通道，升格就靠领导拍脑袋；有了通道，第 02 篇那张准入白名单才是活的。

图2：把责任钉到角色——三权分开、两线分审、一个升格通道

四、动手之前：先做一张需求分类表

下一篇会发全合集的「选型地图」，在那之前，本篇给你一个立刻能做的动作——把你们单位现在所有 AI 相关诉求，按下面五列填一张表：

1.诉求描述：谁、想解决什么事（原话记录，别加工）；

2.归类：员工想用 / 部门要买 / 单位得建（拿不准的，看「失败代价」那行——代价决定类别）；

3.数据暴露面：这个诉求会喂给 AI 什么数据？含不含内部/敏感/个人信息？（这一列直接决定走不走第 02 篇的筛漏斗）；

4.现有供给：单位白名单里有没有能覆盖的？员工是不是已经在私自用外部工具干这事？

5.处理路径：合规供给（买席位/开白名单）、立项评估（进筛漏斗）、还是制度红线（明确禁止+给替代）。

这张表通常一周就能填完。它的价值在于：填完之后你会发现，很多「我们要采购 AI」的诉求，拆开看根本不属于采购——有的缺的是一个席位池，有的缺的是一句明确的红线，有的缺的只是一个还没跑的试点。真正需要走重型立项的，往往比立项会上喊的少一半。

下一篇把镜头拉远：供给形态五类 × 能力品类七类，画一张 2026 版的政企 AI 工具选型地图，给三种典型单位各标一条推荐路径——那张图值得收藏。

图3：下一篇的预告——双轴选型地图，先睹为快

下一篇预告：04《政企 AI 工具选型地图（2026 版）》——供给形态（公有云 API／混合云／全栈私有化／端侧一体机／开源自运维）× 能力品类（通用对话、办公写作、编码、知识问答、数据分析、智能体平台、安全合规）双轴成图，每格标注代表供给与主要风险，涉密单位、一般国企、区县政务各有一条推荐路径。合集收藏位。

《数据不出域：政企 AI 工具选型实战》合集目录

01 你以为选不出 AI 工具，是因为没先画约束线

02 1112 款备案服务里，你能用的其实没几个

03 先分清三类需求：员工想用、部门要买、单位得建（本篇）

04 政企 AI 工具选型地图（2026 版）

05 通用对话助手：公有云、私有化、端侧三种形态怎么选

06 办公写作类：公文、纪要、PPT，最容易被「影子AI」击穿的一环（付费）

07 编码研发类：代码能不能出内网，是政企第一道生死线（付费）

08 知识问答与 RAG：几十年的文件积累，才是真正的护城河（付费）

09 数据分析与智能问数：报表工具加了个大模型，不等于会分析

10 智能体平台：从「回答问题」到「替你办事」，风险等级完全变了

11 信创适配不是「支持国产」四个字：算力、OS、数据库、中间件四层清单（付费）

12 数据不出域：一条 Prompt 的完整旅程，比你看十份宣传册都管用（付费）

13 合规准入：备案、等保、密评、算法与安全分级，一张资质核验表搞定（付费）

14 审计追溯：AI 干的每一件事，出事后能不能定责（付费）

15 合同与供应商：把安全承诺写进条款，才算真的合规（付费）

16 评分卡：把「感觉不错」翻译成能过评审会的数字

17 自建、复用上级的、还是买服务：集约化部署三条路（付费）

18 POC 怎么测才不被演示骗：自建评测集是唯一的解（付费）

19 选型报告怎么写：让评审会一次通过的骨架（付费）

20 堵不如疏：治理影子 AI 的六步法

21 上线才是麻烦的开始：成本、幻觉、攻击面三本账

22 一年后的选型复盘：什么该换、什么不该换

23 五类政企，五条完全不同的选型路径

24 选型不是选工具，是选三年后的自己（收官）

口径说明：文中场景为多年项目经验的合成复盘，不指向任何具体单位、项目或厂商；政策与判例线索以官方公开发布为准，查询时间截至 2026 年 10 月。文中观点不构成对任何产品的评价或推荐，选型请以本单位实际合规要求与最新政策为准。