# 数据治理

Microsoft 2026 Work Trend Index 把企业推向 Frontier Firm，Databricks 也开始强调治理 AI agents 能做什么。对数据团队来说，Agent 进公司流程前最该问的不是能不能自动跑，而是谁给它身份、权限、审批和日志边界？

很多数据团队一听语义层，就想到老 BI、指标平台和数据治理文档。但 Power BI、Databricks、MIT 和 Lyft 最近都在重新谈 semantic layer。对数据分析师和数据工程师来说，真正的问题是：怎么从 20 个高频业务问题开始，把指标、维度、权限、质量和拒答规则写成 AI 能调用的数据说明书？

很多公司做 AI 问数时，先关心模型会不会写 SQL，却忽略了一个更普通的问题：公司有没有一本能说明指标口径、数据来源、权限边界和适用场景的指标说明书？对数据分析师和 BI 同学来说，AI 最先暴露的往往不是模型能力，而是组织没有把业务语义写下来。

Power BI、Databricks 和 MIT 最近都在把语义模型、治理台和 GenAI 放到一起讲。对数据分析师和 BI 同学来说，问题不只是报表会不会被 AI 取代，而是你的指标、权限、口径和解释，能不能变成 AI 也能调用的业务接口？

本期数据周刊关注 6 月最后一周的 5 个信号：Power BI 把语义模型接到 AI 应用，Databricks 继续强化 Unity Catalog 治理，MIT 讨论 GenAI 语义层，Lyft 公开指标语义层实践，Shopify 训练 AI 拒答。数据分析师和数据工程师该准备什么？

很多公司做数据治理时会建指标字典、数据标准、血缘文档和质量规则，但业务仍然在群里问口径、导 Excel、临时找人解释。数据治理失败不一定是没人做，而是做完没有进入真实工作流。本文从一次治理项目复盘讲起，拆解治理没人用的 4 个原因和 3 个更小的落地入口。

数据同学最怕业务反复改口径：今天按下单，明天按支付，后天又要排除退款。很多人第一反应是改 SQL，但真正该问的是业务到底要用这个指标做什么。本文从一次复购指标争议讲起，拆解口径反复背后的 4 个问题，以及一张指标变更卡应该记录什么。

AI 问数和 Text-to-SQL Demo 往往很顺：输入一句话，模型生成 SQL，图表立刻出现。但一到真实企业上线，就会遇到权限、口径、表名、脏数据和责任边界。本文从一次上线评审讲起，拆解 AI 问数翻车的 4 个原因，以及上线前必须补的 5 个基础动作。

很多候选人回答数据质量，只会背空值、重复、波动 3 类规则。但面试官真正想听的是：你怎么判断业务真的下滑还是链路出错，怎么定义影响面，怎么把规则放进数据链路，怎么处理业务责任。本文用一个面试现场拆解数据质量问题的 5 层回答方式，适合数据开发和数据分析师准备面试。

一次数据事故从周五晚上拖到周日，团队 48 小时修完任务、补跑数据、恢复看板，但复盘时才发现真正缺的不是告警，而是影响面、修复记录、责任边界和上线验证。本文用 5 个问题拆解数据事故复盘，帮数据开发和数据治理团队避免下次重复摔在同一个地方。

数据资产入表不是把数据估个价格写进报表，而是要求企业能证明数据来源、权属、质量、成本、使用场景和收益逻辑。本文结合财政部企业数据资源会计处理规定，解释普通公司为什么卡在资产识别、成本归集、质量治理、合规证明和业务闭环这些长期的数据基础能力上。

企业内部做高质量数据集，不能只是建一个文件夹或上传一批样本。真正可复用的数据集需要设计使用场景、字段说明、版本记录、质量验收、权限边界、调用登记和反馈机制，才能成为 AI 应用、业务分析和数据产品可以反复使用、长期持续维护的稳定数据供给能力。

AI 合规不只是法务问题。随着生成式 AI、深度合成标识、拟人化互动等监管要求逐步落地，数据分析师、数据开发和数据产品经理需要知道数据来源、授权范围、敏感信息、输出标识、日志追溯和责任分工这些工作边界，避免把企业 AI 项目做成不可追溯的生产黑箱。

企业 AI 应用上线前，数据团队不能只说“先接数据试试”。本文从生成式 AI 暂行办法、AI 生成合成内容标识和个人信息保护要求出发，给数据开发、数据治理负责人和 AI 产品经理一套四条数据边界检查法：来源授权、敏感信息、模型使用、输出追溯。

数据治理不是让全公司补字段表，而是从真实业务争议里建立可维护机制。本文用一次转化率和销售额口径冲突，拆解数据分析师、数据开发和业务负责人如何沉淀指标定义、责任分工、变更记录、下游影响和通知流程，把治理做成业务会继续使用、后续能持续维护的方法。

数据团队经常抱怨业务反复改指标口径，但很多口径变化不是业务不专业，而是目标、责任、考核和决策动作还没有对齐。本文从一次销售额口径争议讲起，说明数据分析师和数据开发如何把口径变更从临时改 SQL，变成有场景、有确认、有版本、有通知的协作机制。

公司开始提“数据要素×”、数据资产和项目申报时，数据分析师和数据开发最容易被拉去补材料、盘表和赶节点。本文从一次内部会议拆起，结合 2024—2026 年“数据要素×”行动计划和 2025 年全国数据资源调查，说明普通数据从业者如何判断一个项目是成长机会，还是一场材料劳动。

当公司要求数据团队参与数据要素、数据资产入表、公共数据授权运营或“数据要素×”项目时，数据开发和数据分析师不能只看项目名。本文给出一套可直接用于内部评审的 6 维判断清单、18 个澄清问题、红黄绿灯判断标准和交付物模板，帮助你判断哪些项目值得接，哪些边界必须提前写清楚。

很多数据治理、数据资产和指标体系项目启动时声势很大，最后却变成填字段、补责任人和催模板。问题通常不在数据团队不努力，而在项目没有绑定销售复盘、经营分析、AI 问数等真实决策场景。本文给数据分析师和数据开发一套判断方法：先问谁会使用结果、表格进入哪个流程、30 天后能减少什么返工。

AI 时代，数据从业者不能只学提示词、Agent 框架或问数 Demo。真正长期保值的能力，是从指标口径、可信数据供给、AI 工作流、应用评估到权限治理，逐层把自己从取数报表的人，升级为智能应用的业务数据负责人。本文给出能力分层、自测清单和 30 天练习路径。

当领导突然要求建设高质量数据集，数据团队不能只把它理解成标注任务。真正可落地的高质量数据集，需要从业务场景、字段定义、样本边界、质量验收、版本管理和责任分工一起设计，否则很容易变成一个没人敢用的共享文件夹。遇到类似需求时，应该先问什么、留什么证据？