> 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-governance-framework.md).

# 2027年AI数据治理框架：模型上线前的五项决策

本文整理自 Duaer 文档站，探讨企业在让AI基于内部数据回答问题之前，需要先厘清的核心决策，包括数据归属、分级访问、质量与血缘、流程化政策以及效果衡量。

## 为什么AI一到来，数据治理就开始失灵

大多数想让AI基于内部数据回答问题的企业，几周之内都会遇到同一个问题。试点在干净的样本上运行良好，但接着有人会问：定价表哪个版本才是正确的？人事记录能否用于面向客户的工具？现在模型引用的这张表是谁批准的？没有人能很快回答。问题通常不在模型本身，而在于组织从未就「数据归谁负责、敏感程度如何、该信任到什么程度」达成一致。AI数据治理框架，就是在模型上线之前把这些问题厘清的一组决策。

多数公司已经有一定的数据治理，通常服务于报表和合规，常见形式是数据目录、政策文件或IT团队的访问控制列表。这些机制是为按计划查看仪表盘的人设计的。AI改变了这种模式：检索系统或智能体能在几秒内读取成千上万份文档，以分析师不会采用的方式把它们组合起来，并自信地给出结果。过去人类要打开五个文件才能看到的内容，在模型可以汇总全部文件时，同一项权限就变成了真实的暴露风险。

第二个不同之处在于不确定性被放大。报表上的错误数字会在会议上被质疑，而AI给出的错误数字却常常被直接接受。这意味着过去多年被容忍的数据质量问题，如今会暴露在从未意识到底层数据不一致的用户面前。

## 先定归属，再谈工具

最常见的错误，是在决定每个数据集由谁负责之前就购买治理平台。工具可以执行规则，但无法决定销售区域代码是否正确，也无法判断合同档案是否是最新版本。这件事必须有人负责。

一个务实的做法是：为第一个AI用例涉及的每个数据域指定业务负责人，例如客户记录、产品信息、政策文档或运营日志。负责人对定义、质量阈值以及访问申请的审批负责。IT或数据平台团队作为保管方，负责落实规则。纸面上要把这些角色分开，出现字段相关问题时，团队应当清楚该找谁。

这一步看起来繁琐，却是框架中成本最低的一环。它只需要几次工作坊和一份共享表格，就能避免之后数月的争论。

## 分级与访问：谁能通过哪个模型看到什么

AI治理需要一套人们真正能执行的分级方案。起步阶段通常三级就够了：公开或一般内部信息、机密业务信息，以及受限数据，例如个人信息、财务细节或受监管的记录。每一级都应有简短明确的规则，说明它可以在哪里处理、哪些模型可以读取，以及输出能否离开内部网络。

关键在于，访问控制必须跟随用户和使用场景，而不只是跟随文件。代表经理检索薪资表的模型，不应该在员工问一个普通问题时把这张表展示出来。团队常常发现，现有权限在进入AI流水线后失效了，因为索引会复制文档并剥离原有的访问标记。应当明确测试：用不同角色的账号向系统提问，检查受限内容是否会泄露到答案中。

对于有数据驻留要求的组织，同样的逻辑也适用于地理位置。明确哪些数据可以发送到外部模型服务，哪些必须留在受控环境内，并把这些规则写进流水线配置，而不是留作给开发人员的个人指导。

## 质量与血缘：清楚模型在信任什么

忽视数据质量的治理框架，会在第一个真实问题上失败。在建立索引或训练之前，应为每个来源定义一小组质量检查：时效性（最近一次更新是什么时候）、完整性（必填字段是否齐全）、一致性（两个系统对同一客户或产品的描述是否一致）以及权威性（哪份文档是经批准的版本）。

血缘同样重要。当一个答案引用某份文档时，团队应能追溯这份文档来自哪里、谁最后修改过、经历了哪些转换步骤。没有血缘记录，每个错误答案都会变成「是模型还是来源有问题」的争论；有了血缘，负责人就能修正源头，系统也能对受影响的内容重新处理。

许多团队正是在这一步意识到，他们的知识库多年来一直以几个相互冲突的版本并存。一个有用的练习是：挑选二十个对业务重要的问题，在当前来源中找到答案，并统计有多少来源相互矛盾。结果通常比任何演示文稿都更能说明治理工作的必要性。如果你需要一种结构化的方式，在自己的数据源上完成这项检查，可以使用Duaer平台（https://www.duaer.com），让团队在真实数据集上先试用归属、分级和检索等步骤，再决定是否大范围推广。它是一种工具，不能替代负责人的判断，但能缩短从政策到可测试行为之间的距离。

## 让政策在流程中运行，并衡量效果

只存在于PDF中的框架不会治理任何东西。规则需要在数据流动的节点上执行：摄取、索引、检索和输出。对每条规则，都要决定失败时会发生什么：系统应该阻止该文档、屏蔽某个字段、把请求转交人工审核，还是记录事件后继续。没有后果的规则只是建议。

日志需要特别关注。记录每个答案使用了哪些来源、哪位用户提问、通过了哪些政策检查。出现问题时，审计人员、安全团队和业务负责人都需要这些记录。日志还能帮助你发现规律，例如某个来源反复产生低置信度的答案。

如果你的组织也在推进更广泛的AI治理，可以参考《2027年AI治理框架的常见问题》（https://doc.duaer.com/zh/guides/ai-governance-framework-2027/），了解为什么政策常常止步于纸面而无法投入生产。本文描述的数据专项规则，正是让这些政策可以真正执行的部分。

衡量效果需要业务人员能够读懂的指标。持续跟踪几项内容：拥有明确负责人的数据来源占比、受限来源通过访问测试的占比、引用了被标记为过时或未经批准来源的答案数量，以及解决一次数据访问申请或质量问题所需的时间。随时间比较这些数字，而不是追逐单一目标。

对虚荣指标要保持警惕。编目的数据集数量很多，但如果大多数没有负责人，这个数字说明不了什么；事件数量少，也可能只是因为没人在检查。每个指标都应配合抽样审查：由人阅读实际输出，并追溯到其来源。

## 本周可以先做的一件事

选择最接近上线的那一个AI用例，列出它将读取的数据来源。对每个来源写下三件事：业务负责人、分级层级，以及最可能捕获严重错误的一项质量检查。如果某个来源这三项无法全部填写，就先不要为它建立索引。这项练习只需一个下午，却能立刻暴露框架中缺失的部分。

完成之后，就可以对整条链路做端到端测试：使用不同角色的账号运行该用例，记录每个答案引用了哪些来源，并与负责人一起复核结果。如果流程看起来可以管理，就可以逐步扩大范围。如果你希望有一个可以动手的环境来做这类试用，可以注册 https://www.duaer.com ，用自己的文档搭建一个有限范围的试点。

AI数据治理框架不是开始之前就要写完的文件，而是你在把每个数据集接入AI系统时，针对归属、访问、质量和可追溯性所做出的一系列决策。尽早做出这些决策的组织，能避免之后让试点停滞不前的大多数信任问题。

## 常见问题

### 企业做AI数据治理，第一步应该做什么？

先为第一个AI用例涉及的每个数据域指定业务负责人，明确其对定义、质量阈值和访问审批的责任，IT或数据平台团队负责落实规则。在角色清楚之前，不必急于购买治理平台。

### 数据分级通常需要分几级？

起步阶段三级通常就够用：公开或一般内部信息、机密业务信息，以及个人信息、财务细节、受监管记录等受限数据。每一级都应配有明确的处理地点、可用模型以及输出能否离开内网的规则。

### 如何判断AI数据治理是否真正有效？

可以持续跟踪拥有明确负责人的数据来源占比、受限来源通过访问测试的比例、引用过时或未经批准来源的答案数量，以及处理访问申请和质量问题的时间，并配合人工抽样，把实际输出追溯到其来源。