数字员工项目很少因为模型能力不足而失败，更常见的路径是：演示阶段一切顺利，进入生产后权限越用越宽、异常无人接手、结论追溯不到依据，几个月内要么被业务部门悄悄弃用，要么在缺乏监督的情况下直接触达客户和资金，风险由业务侧被动承担。失控几乎都不是某个瞬间的爆发，而是几个设计缺位叠加后的结果。
失误往往从提问顺序开始
企业在评估阶段最常问的是“这个模型能不能做”，而不是“这件事该不该由它做”。顺序一旦颠倒，后续的权限配置、流程改造和验收标准就会全部围绕技术能力打转。通用聊天工具不能直接当数字员工用，不在于它不够聪明，而在于它不了解某家企业的具体流程，也没有人告诉它权限到哪里为止。
岗位设计要回答的不是“它能做多少”，而是哪些环节允许独立完成、哪些必须由人确认、哪些根本不该交出去。可操作的划分是把岗位工作分成三层：执行层由数字员工独立完成，如数据收集、报告生成、内容初稿；建议层由它产出选项和风险提示，人工审核优先级；判断层必须由人承担，包括最终决策、异常处置、对外正式沟通。
边界通常不是划在整条岗位线上，而是划在岗位内部。以销售为例，客户关系维护、关键条款谈判、信任建立仍由人承担，资料检索、方案初稿、会议纪要整理、标准报价单生成则可以交出去。把整类岗位简单标记为“可替代”或“不可替代”，在实践中没有指导意义。
权限与监督是失控的两条主线
权限配置的常见错误是先开通系统账号再想用途，导致访问范围远超岗位需要。合理的做法是从任务反推权限：读取权限只开放当前任务必需的字段，敏感字段做脱敏或聚合；写入权限区分“生成草稿”和“提交生效”，多数场景只应写入草稿区或待审队列；对外动作初期全部走人工确认；涉及金额、数量、调用次数的操作设置上限。服务账号还应能独立停用，操作日志可按任务回溯到具体输入输出，这是异常处置时快速定位影响范围的前提。
另一条主线是人的责任没有被重新分配。数字员工产出的报告谁来抽查、异常提示谁来响应、投诉时谁出面解释，如果只停留在项目组的口头约定，人员一变就失效。可行的做法是把监督职责写进相关岗位的绩效预期，并明确升级路径：在什么条件下必须停下来交给人、交给谁、多长时间内响应。触发条件要具体可判，例如报价偏离历史区间、关键字段缺失且无法补齐、对方明确要求人工对接，而不是笼统地写“遇到复杂情况时上报”。
验收环节同样容易走偏。用几个精心准备的样例证明系统可用，只能支撑技术验证，不足以支撑上线决策。管理者需要看的是任务完成率、异常识别是否按时上报、结论能否回溯到输入与规则、审核纠错占用的人工工时是否下降，并与人工基线做对比。验收周期还应覆盖一段完整的业务波动期，只有在高峰期和异常输入下仍保持可接受的完成率与上报准确率，这个岗位配置才算具备持续运行的条件。
把这些做扎实，技术选型的空间反而会更清晰，因为企业已经知道自己需要什么，而不是等着供应商告诉自己可以做什么。