数据中台数据治理做哪些工作，可以先从八类工作包看起：治理组织与制度、数据标准、主数据、指标口径、元数据与血缘、数据质量、数据安全与权限、数据资产目录与生命周期。分工上，业务 Owner 定口径并裁决争议，数据管家维护标准与质量，平台团队落实技术规则和服务，治理办公室统筹协调；各项再写清配合、审批与交付物。
这些工作挂在数据中台架构的接入、建模、资产和服务链路上，但责任不止落在中台团队。下面按工作清单、职责分工、协作机制和首期启动顺序展开，各模块的具体操作方法只点到为止，标准、质量、安全等专题会分别展开。
一、中台治理的边界在哪里
中台治理的对象，是进入中台并对外提供服务的共享数据资产，以及支撑这些资产的标准、指标、模型、权限和变更流程。源系统的数据质量、录入规范和安全基线，仍由源系统责任部门负责。中台可以在接入环节做校验、隔离和回写建议，无法替代源头治理。
职责设计时，应明确业务数据负责人对本域数据含义与质量目标承担的责任，不能默认将这些责任全部交给应用系统或数据库管理员。这个判断放到中台同样成立：中台团队可以建规则、跑监控、修链路，业务部门要确定数据含义、质量目标和可接受的使用方式。
治理工作可以按作用分成三类：
- 定规则：制度、数据标准、指标口径、权限策略、质量目标。
- 做执行：落标、建模、质检、权限配置、元数据采集、问题修复。
- 做运营：资产盘点、评审、问题闭环、度量、培训和复盘。
数据中台建设解决平台有没有、链路通不通；数据治理解决数据能不能信、谁来负责、出了问题怎么改。两项工作可以并行推进，治理不必等平台全部上线。
二、数据中台数据治理有哪些工作
国家标准全文公开系统显示，GB/T 36073-2025《数据管理能力成熟度评估模型》于 2025 年 12 月 31 日发布，已于 2026 年 7 月 1 日实施。企业可以用它盘点数据管理能力，再决定治理任务的优先级。
数据治理工作清单可以按八类工作包展开。下表先给出全貌，后面再说明每组的工作重点。
| 工作包 | 主要动作 | 交付物 | 完成信号 |
|---|---|---|---|
| 治理组织与制度 | 设委员会、治理办公室、数据 Owner 和数据管家；发布制度与流程 | 组织架构图、职责清单、制度、年度计划 | 每个数据域有 Owner，争议有裁决路径 |
| 数据标准 | 梳理业务术语、字段、编码、值域和命名规范 | 标准库、标准卡、落标清单 | 新系统按标准建模，存量系统有整改计划 |
| 主数据 | 统一客户、物料、组织、供应商等核心实体；建立变更流程 | 主数据清单、唯一主键、变更流程 | 一处修改，相关系统按规则同步 |
| 指标口径 | 建指标字典，指定口径负责人，做评审和版本管理 | 指标字典、口径说明、版本记录 | 同一指标跨报表一致，变更有记录 |
| 元数据与血缘 | 采集技术元数据和业务元数据，维护血缘和影响分析 | 元数据目录、血缘图、变更影响清单 | 改字段前能查到下游影响 |
| 数据质量 | 配置质量规则、监控、工单、整改和复查 | 规则库、质量报告、问题台账 | 问题有定级、有责任人、有复查 |
| 数据安全与权限 | 分类分级、访问审批、脱敏、审计 | 分类分级清单、权限矩阵、审计记录 | 敏感数据可追踪，权限符合最小必要 |
| 资产目录与生命周期 | 资产盘点、编目、发布、检索、归档和下线 | 资产目录、责任标注、归档与下线记录 | 业务能查到资产和负责人，废弃数据有出口 |
1. 规则类工作：标准、主数据与指标口径
数据标准是各系统共同使用的语言。工作内容包括业务术语、字段命名、编码规则、值域约束和指标定义。标准要进入建模、开发和发布流程，才能约束新产生的数据；只发布一份文档，执行时很容易回到各自定义。具体做法可以参考数据标准怎么制定和执行。
主数据解决核心实体的一致性。客户、物料、组织、供应商这类数据在多个系统里重复出现，需要确定唯一来源、唯一主键和变更流程。主数据变更往往影响财务、供应链和经营分析，变更申请要有业务 Owner 审批，技术团队负责同步和回写。
指标口径是经营分析的语言。每个核心指标要有业务定义、计算公式、统计范围、时间口径和负责人。指标新增、修改和下线都要评审，版本变化要通知使用方。口径治理做不好，中台会不断输出互相矛盾的报表，业务自然不愿意用。
2. 结构类工作：元数据、血缘与资产目录
元数据是数据的登记信息，记录数据叫什么、来自哪里、是什么格式、归谁负责。技术元数据可以由平台自动采集，业务元数据需要数据管家维护。元数据不完整，资产目录就只剩表名，业务人员仍然找不到可用的数据。
血缘回答一份数据经过哪些加工、流向哪些报表和服务。它的直接价值在变更管理：修改字段、调整逻辑或下线任务之前，先查下游影响，避免一张报表改了、另一张报表悄悄出错。血缘还可以用于质量问题定位，把问题从结果反查到加工环节。
资产目录回答有什么、在哪里、谁负责、能不能用。目录里的每项资产要标注责任人、更新频率、质量状态、权限申请方式和使用说明。目录只做展示、不做维护，很快会变成过期的清单。
3. 运行类工作：质量、权限与生命周期
数据质量工作包括规则设计、监控、问题工单、整改和复查。规则要覆盖完整性、唯一性、及时性、准确性、一致性等维度，技术规则由数据团队配置，业务规则由业务部门确认。质量问题要能派到具体的人，修复后要复查，重复出现的问题要回到源头找原因。
安全与权限工作包括分类分级、访问审批、脱敏、加密、审计和应急响应。安全法务部门定合规底线，业务 Owner 审批本域数据的访问申请，中台和 IT 团队实现权限控制并保留审计记录。权限策略按最小必要原则执行，临时授权要有期限和回收机制。
生命周期工作覆盖采集、存储、使用、归档和销毁。哪些数据长期保留、哪些数据到期归档、哪些数据必须删除，要有明确规则。变更和下线同样要走评审，避免上游任务停了，下游报表无人知晓。
三、数据治理职责分工怎么落地
1. 决策层、管理层、执行层各管什么
常见的数据治理组织架构分三层。决策层是数据治理委员会或领导组，由高管牵头，业务、IT、安全法务等负责人参加，负责批准战略、制度、预算和跨域争议裁决。管理层是数据治理办公室，可以是常设团队，也可以是虚拟组织，负责方法、计划、评审组织、度量、培训和跨部门协调。执行层是各数据域的治理工作组，由业务和数据技术人员混编，负责本域的标准、质量、权限和问题整改。
华为云 DataArts Studio 的治理组织说明提供了一个可参考的样本：战略层由数据治理赞助人和各部门负责人组成领导组，运作层设数据治理委员会和各领域工作组；领域工作组包含数据所有者、数据代表、数据管家、数据专员和数据架构师。企业不必照搬角色名称，分层逻辑可以借鉴：决策、统筹、执行分开，每层都有明确产出。
小团队可以把委员会和治理办公室合并，也可以让一个人兼任多个角色。兼任时要把决策、执行和验收的边界写清楚，避免同一个人既定标准又验收自己的执行结果。
2. 如何用RACI明确责任
RACI 是一种责任分配方法，四个字母分别对应执行、最终负责、咨询和知会。每项工作只能有一个最终负责人，执行人可以多个，决策前要咨询相关方，结果要知会使用方。下面这张表是示例，企业可以按自己的组织调整。
| 工作 | 治理委员会 | 治理办公室 | 数据 Owner | 数据管家 | 中台与 IT | 安全法务 |
|---|---|---|---|---|---|---|
| 治理制度与年度计划 | 最终负责 | 执行 | 咨询 | 知会 | 咨询 | 咨询 |
| 数据标准制定 | 最终负责 | 咨询 | 执行 | 执行 | 咨询 | 知会 |
| 主数据变更 | 知会 | 咨询 | 最终负责 | 执行 | 执行 | 知会 |
| 指标口径裁决 | 最终负责 | 咨询 | 执行 | 咨询 | 咨询 | 知会 |
| 质量规则与整改 | 知会 | 咨询 | 最终负责 | 执行 | 执行 | 知会 |
| 权限审批 | 知会 | 咨询 | 最终负责 | 咨询 | 执行 | 咨询 |
| 资产目录发布 | 知会 | 咨询 | 最终负责 | 执行 | 执行 | 知会 |
| 安全事件响应 | 知会 | 咨询 | 咨询 | 知会 | 执行 | 最终负责 |
这张表要配合职责说明使用。数据 Owner 对业务含义、质量目标和访问授权负责；数据管家负责日常的标准维护、元数据登记、质量规则确认和问题跟踪；中台与 IT 团队负责平台实现、链路运行、权限技术控制和监控；安全法务负责分类分级、合规审查和事件响应。每个角色都知道自己交付什么，RACI 才能成为可执行的责任表。
图1：数据治理的职责分层
四、哪些责任需要提前约定
指标口径谁说了算。业务 Owner 定业务含义和使用范围，财务、法务等相关部门对涉及收入、成本、合规的口径会签，中台团队负责实现、发布和版本记录。出现跨部门分歧时，提交治理委员会裁决，不留在群里反复争论。
源系统脏数据谁修。源系统的录入校验、接口规范和数据质量由源系统责任部门负责，中台团队负责接入校验、问题隔离、影响分析和回写建议。把源头修复责任写进源系统团队的职责，中台才不会变成所有脏数据的清理责任方。
数据质量谁验收。业务部门验收数据是否可用、口径是否符合业务实际；数据团队验收规则是否覆盖、技术修复是否完成；安全法务验收权限和合规要求是否满足。三方验收结论要留记录，后续出现争议时有据可查。
五、协作机制如何运行
职责分工解决谁做什么，协作机制解决事情怎么往前走。以下四个机制可以直接放进治理运营手册。
- 需求入口分级。取数需求、标准变更、指标新增、质量问题分开入口，分别设置处理时限和审批人。临时取数走快速通道，标准和指标变更走评审通道，紧急质量问题走事件通道。
- 评审与发布。数据标准、指标口径、数据模型、权限策略的变更都要评审。评审要明确谁签字、谁发布、谁通知使用方，发布后保留版本记录。
- 问题工单闭环。质量问题按影响范围定级，派给数据 Owner 或数据管家，修复后由提出方复查。工单要记录发现时间、责任人、修复动作和复查结论，重复问题要进入复盘。
- 例会与度量。月度治理运营会看问题闭环、资产使用和重点需求，季度委员会看投入、跨域争议和下一阶段优先级。度量可以从核心指标口径覆盖率、质量规则覆盖率、问题按期闭环率、资产目录完整率、权限复核完成率中选几项，不必一次铺满。
六、AI能辅助哪些治理工作
AI 可以接手一部分重复治理工作，例如元数据自动采集、字段相似度比对、质量异常检测、规则建议、血缘抽取和自然语言查数。这些能力可以减少人工登记和巡检，对数据量大的企业，AI 辅助还能加快存量标准和指标的盘点。
决策责任仍要由人承担。业务含义、指标口径、权限授予、质量容忍度和跨域争议，涉及业务取舍和合规判断，不能交给模型自动决定。AI 生成的标准建议、质量规则和血缘结果，需要数据管家确认后才能发布。
ThinkingAI 的企业级知识库可将指标定义、业务术语和规则文档编译为 Agent 可读取、检索与引用的知识，为分析提供业务上下文。统一口径仍需业务负责人审核并持续维护；具体权限、审批和版本管理能力，应按目标部署版本逐项确认。 指标、业务术语和政策口径需要保持清晰、可追溯；责任归属和争议裁决仍要由企业治理组织确定。理解这类应用的能力边界，可参阅《什么是企业级 AI Agent？》。
七、首期治理工作如何推进
以下周期、抽样数量和阈值用于说明方案编排方法，需按本企业数据基础、资源与验收标准调整。
首期不宜全量铺开。选一个业务域、三到五个核心指标，先把责任和闭环跑通，再扩展范围。下面是一份可调整的 90 天工作清单。
| 阶段 | 重点 | 交付物 | 退出条件 |
|---|---|---|---|
| 第 1 至 2 周 | 盘点和选域 | 系统与数据域清单、候选场景、角色名单 | 选定一至两个业务域、三至五个指标，每个域有数据 Owner |
| 第 3 至 4 周 | 定责任和最小制度 | RACI 表、问题入口、评审规则 | 关键工作都有最终负责人和执行人，争议有裁决人 |
| 第 2 个月 | 建首批规则 | 标准卡、指标字典、质量规则、权限基线、元数据采集 | 核心数据可查，规则可运行，权限可审计 |
| 第 3 个月 | 跑通闭环 | 问题台账、月度报告、复盘纪要 | 至少一个质量问题完成发现、派单、修复和复查，业务愿意继续使用 |
验收看四件事：业务是否愿意用，问题是否减少，责任是否清楚，变更是否可控。四项都有改善，再扩大数据域和指标范围；如果业务仍然不用，先回到口径、质量和使用门槛找原因，可参考数据中台建成后用不起来的原因。
准备启动时，可以把这张工作清单和 RACI 表交给第一个业务域，用一轮真实需求检验分工。数据开发与治理如何协同、治理如何前置到开发流程，可以继续阅读数据中台建设：数据开发与治理如何成为双引擎。
常见问题
1. 数据中台还没建好，能先做治理吗？
可以。先做数据标准、指标口径、主数据规则和责任机制，这些工作不依赖平台全部上线。平台建设过程中再把规则固化到建模、发布和权限流程里，能减少上线后的返工。
2. 小团队没有专职数据治理岗，怎么分工？
委员会和治理办公室可以合并，数据 Owner 和数据管家可以由业务骨干兼任。兼任时要把决策、执行和验收分开，至少保证定标准的人不单独验收自己的执行结果。角色可以少，责任不能空。
3. 数据 Owner 一定要由高管担任吗？
不一定。数据 Owner 由对业务结果负责、能调动本域资源的负责人担任更合适，高管在委员会层面批准战略和处理跨域争议。Owner 可以不是高管，但要有明确的决策权和资源支持。
4. 治理工作是不是都交给中台团队？
中台团队负责平台实现、链路运行、权限技术控制和监控。业务定义、指标口径、访问授权和质量验收要由业务部门承担，安全合规要求由安全法务把关。全部交给中台团队，治理很快会变成技术团队的单方面推动。
5. 怎么判断职责分工是否有效？
看四件事：争议能否在约定时间内裁决，质量问题能否派到具体的人，变更是否有人评审，业务是否愿意使用治理后的数据。职责文件的页数不能作为判断依据，运行记录更能说明分工是否落地。
