> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/ai-data-readiness-framework.md).

# 2027年AI数据就绪框架：首个模型之前的五项检查

本文整理自 Duaer 文档站。企业AI试点往往卡在数据而不是模型上。文章介绍了AI数据就绪框架的五个衡量维度，以及针对单一用例的评分与优先修复方法。

## AI数据就绪框架衡量什么

大多数企业AI试点停滞，并不是因为模型能力不足，而是因为背后的数据没有准备好。团队往往先用一份干净的样本做出令人信服的演示，之后才发现生产数据分散在不同系统中，标注口径不一致，缺少明确的负责人，而且许多管理规则从未被写下来。模型从来不是真正的瓶颈，真正的差距在于“我们有数据”与“我们有一个AI系统能够可靠使用的数据”之间的距离。AI数据就绪框架的作用，就是在投入资金和信任之前，先把这段距离量出来。

就绪框架是一种结构化的方法，用来回答一个问题：针对某个具体的AI用例，数据是否足够好、足够易得、足够受控，能够支撑可靠的结果。它不是企业数据部门的通用成熟度评分，也不是数据仓库审计。它从用例出发，倒推出所需的数据。

在实践中，一个有用的框架通常覆盖五个维度：可用性（数据是否存在、能否被访问）、质量（是否足够准确、完整、及时）、语境（定义、元数据和业务含义是否有文档记录）、权限与合规（团队在法律和技术上能否使用这些数据）、运营（由谁维护、如何发现变化、错误如何反馈）。每个维度都应针对目标用例打分，而不是对照某种抽象的理想状态。

这套结构的价值在于，它能把“我们的数据很乱”这样模糊的担忧，转化为一系列具体的缺口，这些缺口可以被分配责任、估算成本并排定顺序。

## 为什么就绪比看上去更难

数据就绪的问题往往悄无声息地出现。基于同一批数据表做出的仪表盘，在管理层看来可能完全正常，因为人类会自动弥补小的错误。AI系统却不会以同样的方式弥补。它会把每个字段都当作事实，把每份过时的文档都当作最新版本来检索，即使底层记录是错的，它也能给出流畅的回答。

这类问题之所以容易被低估，主要有三个结构性原因。第一，数据往往归系统所有，而不是归个人所有。CRM、ERP、工单工具和共享盘各自持有一部分事实，却没有人对整体图景负责。第二，许多定义存在于人们的脑海中。“活跃客户”在销售、财务和客服部门可能有三种不同含义，而AI系统会悄无声息地选择其中一种。第三，访问规则常常依靠惯例而非制度来执行。团队可能以为某个数据集仅限内部使用，但供应商的数据管道已经把它复制到了别处。

由于这些问题在演示阶段完全不可见，团队通常要等到试点已经消耗了预算和精力之后，才会发现它们。

## 三个常见误解

第一个误解是，就绪意味着拥有大量数据。数据量很少是真正的制约因素。一家企业即便拥有庞大的归档，如果相关子集缺乏文档或互相矛盾，依然可能没有准备好。就绪始终是相对于用例而言的：一万条描述清楚的客服工单，可能比一千万封未加标注的邮件更加就绪。

第二个误解是，数据湖或一个新平台能够解决就绪问题。如果没有先理清定义、责任和质量，单纯整合存储只会把混乱搬到新的位置。工具有助于执行，但无法替代关于“正确”意味着什么的决策。

第三个误解是，就绪是一次性项目。数据在持续变化。春天时已经就绪的流程，到了秋天可能因为表单重新设计或源系统被替换而逐渐偏离。如果框架没有持续的负责人，几个季度之后就会变成过时的报告。

## 如何为单个用例打分

从一个具体的用例开始，例如为客服人员回答内部政策问题，或为客户经理汇总合同续约风险。写下系统必须回答的具体问题，以及回答这些问题所需的数据来源。

对每个来源，按照五个维度，用三级简单量表打分：已就绪、需整改后可用、受阻。打分要严格。“数据存在”并不等于“数据是最新的且有明确负责人”。一个有用的规则是：每个“已就绪”的评分都必须有证据支撑，包括指定的负责人、最后更新日期、经人工核查过的样本，以及模型将使用的字段所对应的书面定义。

然后观察整体模式。如果受阻项集中在权限与合规上，第一步应是法律和架构层面的工作，而不是技术工作。如果集中在质量上，第一步应是对一小部分数据进行有针对性的清理。如果集中在语境上，第一步应是与业务负责人召开术语梳理研讨会。这种模式能告诉你，第一个月应该把精力投向何处。

如果团队希望使用结构化清单来执行这项评分，[数据与AI就绪度评估指南](https://doc.duaer.com/zh/guides/data-ai-readiness-assessment/)介绍了项目启动前需要询问的问题。已经确定用例的团队，也可以使用 Duaer 将这类逐来源审查设置为可重复的工作流程，而不必为每次试点重新制作表格。

## 先修一个数据集，而不是整个数据资产

完成评分之后，不要急于修复所有问题。就绪框架最有价值的用途，是作为排序工具。选择业务价值最高、受阻依赖最少的那一个用例，然后只修复该用例所需的数据。

这种聚焦有两个好处。其一，它能在合理的时间内产出一个可以运行的系统，从而建立组织内部的信任。其二，它会沉淀出可复用的资产，例如经过文档化的客户定义或清洗过的产品目录，后续的用例可以直接继承。那些试图先修复整个数据资产的团队，往往还没有让任何AI输出抵达用户，耐心就已经耗尽了。

如果想更全面地了解数据准备如何融入整体采用计划，[企业AI采用需求指南](https://doc.duaer.com/zh/guides/enterprise-ai-adoption-requirements/)介绍了应与数据工作同步落实的基础条件。

## 上线后持续衡量，并从本周开始行动

如果框架在上线时就结束，那它是不完整的。应定义两到三个持续性指标：用户标记为错误的回答比例、最常用源文档的平均年龄，以及每月提出的定义争议数量。这些指标收集起来很简单，却能及早暴露偏离。

为每个来源指定一位负责人，由其接收这些信号，并有权修复上游问题。如果没有这种联动，用户的反馈只会积累在无人阅读的日志中。当数据生产者与AI输出的使用者共同参与定期复盘时，就绪才会成为一种持续的实践。

行动上，不要从平台评估开始，而是从一个用例和一页纸开始。写下AI系统必须回答的三个问题，列出它需要的五到八个数据来源，并按照上述严格的证据规则，依据五个维度为每个来源打分。然后，与两个得分最低的来源负责人安排一次60分钟的会议。这次会议的目标不是解决他们的全部问题，而是就一位指定负责人、一个关键字段的定义，以及下一次复审的日期达成一致。

如果这一页纸暴露出的缺口比你预想的多，说明框架正在发挥作用。在一周的评分中发现问题，远比在一个季度的停滞集成中发现要便宜得多。

如果你准备把这套做法落地为一个可运行的流程，可以[注册 Duaer 试用](https://www.duaer.com)，并在那里完成第一个用例的评分。从一个场景开始，保持范围精简，并利用结果来判断下一笔预算应当真正投向哪项数据工作。

数据就绪并不是要在AI开始之前完成的前提条件，而是决定AI能否产出企业可以信赖的答案的一项持续性纪律。

## 常见问题

### 企业如何判断数据是否已经准备好支持AI项目？

可以针对一个具体用例，列出所需的数据来源，并从可用性、质量、语境、权限与合规、运营五个维度逐一打分。每个“已就绪”的评分都应有指定负责人、最后更新日期、人工核查的样本以及书面定义作为证据。如果评分中出现大量受阻项，说明数据还未准备好，应先处理这些缺口。

### AI数据就绪评估应该由谁负责？

通常需要业务负责人、数据提供方、法务或合规人员以及技术团队共同参与。每个数据来源应指定一位有权修复上游问题的负责人，并定期接收用户反馈等信号。如果没有明确的责任人，评估结果很容易只停留在报告中，无法持续改进。

### 为什么不建议一开始就修复全部企业数据？

全面修复耗时长、成本高，而且很难在短期内让AI输出真正被用户使用，容易消耗组织的耐心和信任。更务实的做法是选择一个业务价值高、依赖少的用例，只修复其所需的数据。这样既能尽快产出可用的系统，也能沉淀可复用的定义和数据资产，供后续用例继承。