业务验收人
由使用部门派出，负责说清什么样算能用，并在测试中判定输出是否解决问题。为什么必须是他：技术方无法判断业务合理性，标准若由供应方单方制定，验收就失去意义，也没人敢在出问题时签字。
测试执行人
负责按用例执行、记录结果、登记缺陷，不对功能实现负责。怎么做：执行人可以来自质量岗、第三方或客户方，关键是与被测系统的开发者分离，否则问题容易被解释成设计如此，执行记录也要与开发提交分开保存。
数据提供人
提供真实样本并负责脱敏与授权范围，说明样本的来源时段与抽取规则。边界：样本涉及个人信息时，提供方需确认使用目的与保存期限，我方不擅自扩大使用范围，用完按约定处理或销毁，处理方式要有书面记录。
安全复核人
检查权限边界、日志留痕、敏感字段是否出现在回答中，以及测试环境的账号回收。为什么：AI 系统的越权往往不是绕过登录，而是回答里多带了不该给的数据，页面看不出异常，常规功能测试也覆盖不到。
技术负责人
保障测试环境与生产一致，提供版本号与配置说明，并对稳定性问题负责。怎么做：测试前确认环境差异清单，差异过大的项需在验收单中标注为未覆盖，避免上线后才发现结果无法复现，并在验收单上注明差异项。
适用与不适用
适合谁
- 正在排验收计划、需要明确参与方的项目经理
- 客户与供应商共同验收的交付项目
- 验收常因人手不足而草草收场的组织
不适合谁
- 单人开发、无独立使用方的内部小工具
- 尚未确定验收范围与判定标准的早期项目
典型场景
某政务服务中心的办事引导助手验收，业务科出两人定标准并判定回答是否准确，信息中心提供脱敏问答样本，第三方测试员执行用例，安全岗抽查越权提问。执行中发现两类敏感字段外泄，修复后复测通过，五方分别签字。
可执行步骤
- 项目启动时确定五方参与人，并把姓名、职责与替补写进验收计划表。
- 由业务方主导编写判定标准，供应方只负责澄清技术口径与举出示例。
- 数据提供方完成脱敏，并书面说明样本来源、抽取时段与保存期限。
- 确保测试执行人与开发者分离，由执行人独立记录结果与判定结论。
- 安全复核人抽查越权提问，以及敏感字段是否出现在回答与日志中。
- 五方在验收单上分别签署本岗结论，并记下遗留事项的处理人与期限。
常见坑
- 让开发兼任测试执行人，缺陷容易被解释成设计如此，验收流于形式，上线后问题照旧且无人担责。
- 业务方只在最后签字、不参与判定，上线后集中出现不好用的反馈，返工方向难以判断，容易反复折腾。
- 数据提供方未做脱敏，测试环境留存真实个人信息，形成合规与审计风险，事后难以彻底清除。
自检与验收清单
- 五方参与人是否在验收计划中落实到姓名与职责
- 判定标准是否由业务方主导、供应方仅澄清口径
- 样本脱敏方式与使用期限是否书面确认并留档
- 测试执行人是否独立于被测系统的开发者与产品经理
- 越权与敏感字段复核是否纳入验收范围并留记录
常见问题
客户方没人懂 AI 怎么当验收人？
不需要懂模型，只需要懂业务：这个回答能不能让一线直接用、哪些情况必须转人工。供应方应提供判定示例与培训，但不能代替业务方定标准，否则验收只是自证，出了问题仍然要业务承担。
第三方测试有必要吗？
在权责敏感或对外交付的项目里值得考虑，尤其当客户与供应方对结论预期不一致时。第三方的价值在于独立记录与复现，不在于技术更强；成本与范围应事先约定，避免临期追加预算。
供应商能不能参与测试？
可以参与执行与修复，但不应独自判定通过。合理分工是供应方负责环境、数据导入与缺陷修复，客户方或独立测试方负责判定与签认，两条线分开留痕，事后可追溯责任归属。