数据治理与AI：别再把数据当“燃料”了

这两年，几乎每家公司都在谈AI。会议上、PPT里、年终总结里，AI成了必选项。但真正落地的时候，很多人发现一个尴尬的现实：模型再先进，算法再花哨，最后卡在数据上。

数据脏、数据乱、数据不全、数据权限说不清……这些问题不是技术问题，是治理问题。AI把数据治理这件事，从后台推到了台前。

为什么现在特别痛

以前做业务系统，数据质量差一点还能凑合。报表错一点，人工再对一下就行。但AI不一样。模型吃的是数据，吐出来的结果会直接影响决策、推荐、风控甚至客户体验。输入是垃圾，输出大概率也是垃圾，而且垃圾还带着“智能”的外壳，更难察觉。

我见过几个典型场景：

• 客户画像做了半年，推荐系统上线后效果平平。回头查，发现同一用户在不同系统里有三四个ID，行为数据对不上。
• 风控模型误伤率居高不下，排查后发现历史标签里混了大量人工标注错误，而且标注标准前后不一致。
• 某个部门花大价钱买了外部数据，结果因为字段定义和内部口径对不上，白花钱。

这些都不是模型本身的问题，是数据从产生、流转到使用的全链路没有规矩。

数据治理到底在管什么

很多人一听“治理”，就想到建一堆制度、画一堆架构图、买一套平台。其实核心就几件事：

先搞清楚“有什么”。
很多公司连自己有哪些数据、存在哪、谁在用、质量怎么样，都说不清楚。没有数据资产目录，后面的一切都是空中楼阁。

再明确“能不能用、怎么用”。
权限、脱敏、合规、留存周期，这些以前可以模糊处理，现在不行。尤其涉及个人信息和敏感业务数据时，法规越来越严。AI项目如果因为数据合规问题被叫停，损失的不只是研发成本。

然后管“好不好用”。
质量规则、主数据、元数据、血缘关系。听起来很虚，但落地后你会发现：一旦有了清晰的血缘，出问题能快速定位；有了统一的主数据，跨系统对账不再靠人肉。

治理不是为了治理而治理，是为了让数据真正能被业务和AI用起来。

AI对治理提出了新要求

传统数据治理更多关注结构化数据、报表口径、财务合规。AI把范围扩大了：

• 非结构化数据（文本、图片、日志、语音）也成了核心资产，治理难度更高。
• 特征工程、训练数据、标注数据需要版本管理和可复现性。模型出了问题，得能追溯到具体用了哪一批数据。
• 实时性要求变高。很多AI场景是流式的，数据延迟和质量问题会直接体现在线上效果上。
• 人机协同带来新风险。模型生成的内容如果再被当作训练数据，可能形成反馈循环，偏差被不断放大。

另外还有一个容易被忽视的点：AI项目往往跨部门协作，数据从业务系统到算法团队再到生产环境，中间经过多个环节。如果没有统一的治理机制，责任边界会非常模糊。出了问题，业务怪算法，算法怪数据，数据团队说“你们当初没提需求”。

真正有效的做法没那么玄

我见过一些做得比较扎实的公司，共同点其实很朴素：

1. 从具体场景切入，而不是先建大而全的平台。
   先选一个痛点明显的AI项目，把这个项目需要的数据链路理清楚：从源头到特征到模型到监控。做通一条链路，再复制经验。

2. 把“数据责任”落到人。
   每个核心数据域有明确的业务负责人（Data Owner）和技术负责人。出了质量问题，有人能拍板改。光靠数据团队推动，很难。

3. 质量和安全并重，而不是二选一。
   有的公司为了安全把数据锁得死死的，AI团队拿不到可用数据；有的则是为了快，把权限开得很松。长期看，两者都会出问题。分级分类 + 动态脱敏 + 审计日志，是比较务实的方向。

4. 监控前置。
   不要等模型效果掉了才去查数据。对关键特征、标签分布、缺失率、异常值设置监控，异常时能及时告警。很多“模型漂移”其实是数据漂移。

5. 文档和沟通比工具更重要。
   再贵的数据平台，如果业务方和算法方对字段含义理解不一致，还是白搭。定期对齐口径、维护数据字典，虽然笨，但有效。

最后说几句实在的

数据治理不是一劳永逸的项目，而是持续的运营。AI把这件事的优先级抬高了，也把标准抬高了。以前“差不多就行”，现在“差不多”会直接反映在业务结果上。

与其追求完美的治理体系，不如先把最影响当前AI项目的那几条数据链路理顺。把数据当成真正的核心资产来经营，而不是当成模型的“燃料”随便往里倒。

燃料烧完了可以再买，数据如果从源头就乱了，后面花再多钱也难救。

AI时代，拼的不只是算法和算力，更是谁家的数据更干净、更可信、更可管。这件事，急不得，也拖不得。