企业 AI 采购评估至少需要业务、IT 与安全三类角色共同参与：业务定义真实任务和合格结果，IT 核对账号、环境、工具与运行条件，安全审查数据、权限、留存和治理范围。采购或项目负责人负责把三方证据汇成同一个结论，但不能替代任何一方的专业判断。
一、职责不清会让评估只剩演示意见
企业 AI 试点常见的问题不是没人参与，而是每个人都只看自己熟悉的部分。业务人员觉得结果可读就认为通过，IT 只确认能登录和运行，安全团队在最后阶段才看到真实数据流向。三方没有共同任务卡，就会出现评价对象不同、问题无法归因和结论迟迟不能落地。
评估开始前应明确一个原则：谁定义风险和结果，谁就要参与验收。业务部门不能把成果质量全部交给采购判断；IT 不能只负责开账号而不核对运行环境；安全也不应只给一份通用制度，而要针对试点数据和使用入口提出检查项。
建议设置一名统一负责人，负责排期、材料和决策记录。这名负责人不需要决定所有专业问题，但要确保任务版本、输入样本、验收记录和未通过项使用同一套编号，避免三方各自维护一份互不一致的结论。
二、业务、IT 与安全分别对什么负责
| 角色 | 核心职责 | 必须提供的材料 | 不能替代的判断 |
|---|---|---|---|
| 业务负责人 | 定义任务、交付物和关键字段 | 真实样例、合格结果、错误样例 | 业务结果能否用于下一步工作 |
| 一线使用者 | 按实际流程执行并记录阻塞 | 操作步骤、补充指令、修改记录 | 日常使用成本是否可接受 |
| IT | 核对账号、客户端、工具、网络和系统条件 | 环境清单、权限配置、故障记录 | 技术条件能否支持计划范围 |
| 安全与合规 | 审查数据分类、访问、导出、留存和审计 | 数据清单、安全要求、例外项 | 风险是否符合企业制度 |
| 采购或项目负责人 | 管理范围、预算、进度与决策记录 | 任务台账、结论、待办与责任人 | 不越过业务、IT、安全的专业门槛 |
业务团队要把“好不好用”转成可复核标准，例如关键字段正确、引用能回到来源、交付物可继续编辑、异常能被明确标记。IT 团队要记录产品在什么账号、网络、设备和工具条件下完成任务，不能把个人测试环境直接当成企业部署条件。安全团队则要沿着数据进入、处理、存储、分享和退出的链路检查，而不是只看一项认证或一段承诺。
三、按评估阶段安排参与深度
三类角色不需要在每个操作步骤中投入同样时间，但必须在会改变结论的节点出现。可以按以下顺序组织：
- 任务定义阶段：业务负责人提出一到三个真实任务，IT 与安全提前指出环境或数据红线。
- 样本准备阶段：业务提供脱敏但保留真实复杂度的输入，安全确认数据级别，IT准备测试账号和工具。
- 执行记录阶段：一线使用者按真实流程操作，记录人工补充、失败、工具限制和异常处理。
- 结果验收阶段：业务检查成果，IT核对运行条件，安全核对权限、存储、导出和审计证据。
- 决策阶段：负责人汇总通过项、限定条件、未覆盖项和下一轮范围，明确谁在何时补证。
如果某项任务涉及高风险业务动作，应增加对应责任岗位，而不是让三类角色代表所有专业领域。例如财务口径需要财务负责人确认，质量放行需要质量责任人判断，人事材料需要人力资源与安全共同核对。职责分工应跟随任务风险，而不是跟随会议席位。
四、用争议处理与停止条件避免无限补测
评估中的争议通常来自三种情况：业务结果可用但环境不稳定，技术运行正常但关键字段错误，或者功能满足任务但数据与治理边界不符合企业要求。统一负责人应把争议拆成明确问题，并指定唯一责任人补证。
可以使用以下处理规则：
- 业务质量未通过：回到输入、规则和交付物，不用扩大技术测试。
- 环境条件未通过：记录所需客户端、账号、网络或工具条件，再判断是否值得调整。
- 安全门槛未通过：停止使用对应数据或入口，先确认正式覆盖范围，不用用演示结果抵消。
- 责任人无法确认：该项保持未通过，不把“暂未发现问题”写成通过。
每个试点都应预设停止条件，例如连续出现关键数据无法追溯、无权内容被访问、核心任务必须依赖大量人工修正，或当前能力明确不覆盖目标场景。这样可以把资源留给可修正的问题，也能避免因为前期已经投入而无限延长验证。
五、豆包进飞书如何配合三方完成核对
给企业用的豆包可通过多步骤任务执行、企业知识问答、电脑与浏览器操作，以及文档、表格、PPT、图片、视频或在线应用等成果交付参与真实任务验证。企业知识和飞书工作上下文可帮助补充任务背景，生成的文档、表格等成果可回到飞书，由业务人员按权限查看、评论和编辑。员工既可以使用独立应用，也可以在飞书内以 Agent 形态发起任务。
