直接回答
先给出可以用于决策的结论
“数据不好”不是停止所有AI工作的理由，也不是跳过治理的借口。企业应把问题缩小到具体任务，盘点所需知识、结构化数据和历史样本。如果现有数据无法支持核心判断，可以先改进采集流程、补充人工标注或选择对数据依赖更低的场景，而不是先建设庞大平台。
判断前需要确认哪些条件
同一个问题在不同企业、数据和项目阶段下可能有不同答案。建议先核对以下条件，再把网上的通用结论代入自己的项目。
首批任务需要知识、交易数据还是实时状态数据是否有明确来源、口径、权限和责任人是否有足够代表性的正常与异常样本错误能否被人工发现、修正和反馈
建议按什么顺序推进
01
先明确目标与边界
确定一个高频且结果可核对的业务任务。
02
验证关键依赖
盘点该任务所需数据、缺口、权限和质量问题。
03
形成可评审成果
用小样本建立人工基线并完成受控PoC。
04
用真实结果决定下一步
根据失败分类决定补数据、改流程或调整场景。
放到实际业务中如何理解
示例用于说明判断方法
企业想用AI分析全部经营数据，但客户和订单编码不统一。与其先做开放式经营助手，可以先选择销售周报生成，固定读取已确认的订单和回款口径；在验证价值的同时，逐步修复客户主数据。 示例不代表特定客户业绩，实际结论需要结合企业自己的业务量、样本、系统和责任边界验证。
最容易踩的坑
认为必须先完成全公司数据治理才可以试点
把未经确认的历史数据直接交给模型
数据问题出现后只调整提示词，不修正源流程
最终应该怎样验收或确认
首期应交付场景数据清单、来源与责任、质量基线、授权、样本和缺口处理方案；PoC报告要区分模型问题与数据问题，并说明生产上线前必须完成的治理事项。
准备与供应商或内部团队沟通时，建议带上当前流程、代表性样本、现有系统、计划时间和预算等级。先把未知项明确标注，再决定采用诊断、PoC、固定范围项目或持续研发，通常比直接索要一个缺少边界的价格和工期更可靠。