Snowflake 意图驱动治理：把数据治理从"写策略"变成"说意图"
产品解读 · 数据治理 × 企业 AI × 合规 | 2026 年 6 月
摘要
2026 年 6 月，Snowflake Summit 2026 上，Horizon Catalog 的一项能力被现场分析师称为"业界首创"——Intent-Driven Governance(意图驱动治理)。它的口号简单到一句话："你表达意图，我们处理细节(You express the intent, we take care of the details)。"
具体是这样：业务负责人或数据工程师不再需要手写掩码策略、不再需要记住 Snowflake 那套治理原语(masking policy、row-access policy、tag、DMF……),而是用自然语言写下"我要守住什么"——比如"把这个账户里的 PII 都保护起来"。系统会扫描账户、生成一份 CISO 看得懂的治理规格(spec),你点一下批准，Snowflake 就自动把它落成标签化的掩码、行访问、分类、数据质量策略，覆盖现有以及未来新增的对象,并持续监测配置漂移、自动生成可以反向追溯回"那条被批准的人类意图"的审计包。
本文不复述"Horizon 是什么"(那篇已经写过),而是聚焦这一个点深挖：意图驱动治理到底解决了什么老问题、它的"意图→策略→执行→监测→审计"闭环怎么转、底层靠什么机制把一句话变成上千张表的策略、它和传统 Policy-as-Code 是什么范式关系，以及作为采购方/合规方该怎么看它的风险。结论先放这：它的价值不在"AI 能写策略",而在"把治理意图本身变成了系统的第一公民"——策略只是意图的可执行投影，而审计能一路追回到那句话。
一、问题定义：治理为什么总是"做不动、对不齐、说不清"
先把要解决的痛点讲透，否则很容易把它当成"又一个 AI 写 SQL 的噱头"。
传统的数据治理，卡在三件事上，而且这三件事在 Agent 时代被放大了。
第一，意图和实现之间隔着一条"翻译鸿沟"。 真正定义治理意图的人——合规官、CISO、业务负责人——往往不会写 Snowflake 的 masking policy,也不懂 tag-based policy、row-access policy、DMF 这些原语。于是治理意图要经过"业务说需求 → 数据工程师翻译成策略 → 落地 → 再回去验证是不是这个意思"的多轮搬运。每一次搬运都在丢失信息：业务说的"客户敏感信息要脱敏",到工程师手里可能只覆盖了 5 张表里的 3 列，而漏掉的那部分，没人发现。
第二，策略一旦写下，就开始和现实"漂移(drift)"。 你今天给 1000 张表打了标、配了掩码，明天新建了 50 张表、加了 20 个新列、接入了 3 个外部数据源——这些新对象默认不在你的策略覆盖里。治理不是一次性工程，而是一条要持续对齐的战线，但传统做法几乎没有"自动跟上"的能力，全靠人记得回去补。
第三，审计时"说不清当初为什么这么配"。 监管来查，问的不是"你现在有没有掩码",而是"你这条掩码对应的是哪条合规要求、谁批准的、什么时候生效的、中间改过没有"。传统治理里，策略配置和它背后的意图是断开的：数据库里只有一堆 policy 对象，没有一条线把它连回"2026 年 Q2 那次 PII 合规评审里 CISO 批准的那个决定"。审计因此变成考古。
把这三句话连起来看，你会发现它们其实是同一个根因：治理系统里只存了"策略(how)",没存"意图(why)",更没存两者之间那条可追溯的链。 Intent-Driven Governance 要补的，正是这条链。
二、它是什么：把"意图"做成可编译、可执行、可追溯的第一公民
一句话定义：Intent-Driven Governance 是 Horizon Catalog 里的一项能力(发布时为私有预览),它把自然语言表达的治理意图，自动编译成 Horizon Catalog 的活动策略(掩码、访问控制、数据质量等),按标签在现有和未来对象上强制执行，并持续监测漂移、生成可追溯回原始意图的审计包。
这里有三个词值得抠：
| 关键词 | 含义 | 为什么重要 |
|---|---|---|
| 意图(Intent) | 用自然语言/纯文本模板表达"要守住什么",而非具体策略语法 | 让定义治理的人(业务/合规)不必学 Snowflake 治理原语 |
| 编译(Compile) | 系统把意图转成标签化的可执行策略，先产出一份人类可读的 spec 供审批 | 意图不是直接黑箱执行，而是"先成文、再批准、后生效" |
| 追溯(Trace back) | 线上每一条生效配置，都能反向连回"那条被批准的意图" | 审计从考古变成查表，合规链路天然完整 |
要理解它的边界，最好的方式还是看它不是什么：
| 容易误认为它是… | 但实际上… |
|---|---|
| "AI 帮你写一段 masking policy SQL" | 不是生成一段代码丢给你，而是端到端管"意图→执行→监测→审计"整条闭环 |
| 一个一次性的策略生成器 | 它持续监测漂移，新对象自动纳管，不是配完就完 |
| 取代 CISO/数据治理团队的"自动驾驶" | 关键的一步是人类审批那份 spec——AI 提议，人拍板 |
| 又一个独立治理产品 | 它构建在 Horizon Catalog 已 GA 的三个 CoCo 技能(Data Governance、Data Quality、Lineage)之上 |
官方反复强调的那句话，是理解它定位的钥匙："You express the intent, we take care of the details." 注意，它没说"we make the decisions"——决策权(审批)仍在人这边，系统接管的是"把意图翻译成上千个技术细节并保持它们对齐"这件最耗人、最易错的脏活。
三、核心机制：一个"意图 → 策略 → 执行 → 监测 → 审计"的闭环
意图驱动治理真正的设计精华，是它不是一条单向的"输入意图、输出策略"的直线，而是一个会自我维持的闭环。把现场 session(WN210T:Govern Your Entire Data and AI Estate)演示的流程拆开，大致是五步。
▲ 意图驱动治理闭环：自然语言意图经 AI 编译成可读 spec,人工审批后落成标签化策略，执行结果持续被监测漂移，并生成可反向追溯回原始意图的审计包
第 1 步：表达意图(Intent)。 你对 CoCo 用自然语言说一句，比如现场演示的 "govern my account with PII protection"(把我这个账户用 PII 保护管起来)。意图也可以是纯语言模板，覆盖更细的规则，比如"所有标注为客户邮箱的列，对非营销团队脱敏"。
第 2 步：编译成规格(Compile to spec)。 这是最关键、也最容易被忽略的一步。系统不会直接闷头改配置，而是先扫描整个账户,识别出哪些对象命中了这条意图(用的是后面会讲的分类器),然后生成一份 CISO 读得懂的 spec——它是人话写的"我打算这么做：这些库、这些列会被这样脱敏，这些角色保留访问",而不是一堆 SQL。这一步把"AI 的理解"摊在桌面上给人看。
第 3 步：人工审批(Approve)。 业务负责人/合规官看过 spec,点一下批准。这一下点击，就是整条链的"信任锚点"——后面所有自动执行，都挂在这个被批准的意图下面。这也是它和"全自动治理"的本质区别：AI 负责提议和落地，人负责拍板。
第 4 步：标签化强制执行(Enforce)。 批准之后，Snowflake 自动驱动基于标签(tag-based)的强制执行——掩码、访问控制、数据质量规则，一次性铺到现有对象上，而且未来新建的、命中同样标签的对象也会自动被纳管。这就把第一节说的"漂移"问题从根上摁住了：策略跟着标签走，不是跟着你手动维护的表清单走。
第 5 步：监测漂移 + 审计回溯(Monitor & Audit)。 系统持续盯着配置漂移——有人手动改了某条策略、某个对象脱离了覆盖，都会被发现。同时它生成详细的审计包,把"线上此刻的真实配置"一路连回"当初那条被批准的人类意图"。换句话说，审计员问"这条掩码为什么在",系统能直接回答"因为 X 月 X 日某某批准的 PII 保护意图，它对应这条要求"。
这个闭环的妙处在于：它把治理从"一次性项目"变成了"持续运行的服务"。意图是源头(source of truth),策略只是它当前的可执行投影；现实一旦偏离意图，系统要么自动拉回、要么告警。意图不再是写在某份 PPT 里的话，而是系统里一个活的、可执行、可追溯的对象。
四、底层原理：为什么"一句话"能管住"上千张表"
很多人第一反应是怀疑：自然语言这么模糊，凭什么能精确落成上千张表的策略？答案不在"大模型很聪明",而在 Snowflake 治理体系里几个早就存在的硬骨架——意图驱动治理是把它们串了起来，而不是凭空发明。
骨架一：标签化策略(Tag-Based Policy)——"一个标签，一条策略"。 这是整个机制的承重墙。Snowflake 的玩法是：你不对每张表、每列单独配掩码，而是给对象打标签(比如 PII、EMAIL),再把掩码/行访问策略绑在标签上。于是"一个标签、一条策略"就能覆盖数千张表，而且新对象只要带上这个标签，策略自动生效。意图驱动治理之所以能"管住未来对象",根就在这——它编译出来的不是一堆散落的 per-table 策略，而是"标签 + 标签级策略"这种会自动扩散的结构。更狠的是，同一个标签的策略也会应用到 AI 智能体的输出上：Agent 想把带 PII 标签的数据吐出来，一样被掩掉。
骨架二：自动敏感数据分类(150+ 分类器)——让"PII"这个词有精确所指。 你说"保护 PII",系统得知道哪些列才是 PII。Horizon 的 Automatic Sensitive Data Protection(私有预览)用 150 多个分类器识别 PII/PCI,而且不依赖列名——哪怕列名叫 TX_LMT 这种鬼东西，它也能从数据本身判断这是不是敏感字段。这就解决了"自然语言意图"到"具体对象集合"的映射问题：不是靠猜列名，而是靠分类器给出精确命中集。
骨架三：三个已 GA 的 CoCo 治理技能——意图驱动治理站在它们肩上。 意图驱动治理不是从零搭的，它构建在 Horizon 已经 GA 的三个 CoCo 技能之上：Data Governance、Data Quality、Lineage。也就是说，"应用策略、修复问题、跨资源监控敏感数据"这些原子动作早就能用自然语言驱动了(这部分是 GA 的 agentic governance),意图驱动治理是在它们上面加了"先编译成可审批 spec、再持续监测漂移、再生成审计包"这层闭环编排。
把这三层叠起来看，就理解了那句"一句话管上千张表"背后的工程现实：
| 层 | 机制 | 解决的子问题 |
|---|---|---|
| 命中 | 150+ 分类器、不依赖列名 | "PII"到底指哪些列 |
| 执行 | 标签化策略(一个标签一条策略) | 怎么覆盖现有 + 未来对象 |
| 编排 | 三个 GA 的 CoCo 技能 + 闭环 | 怎么把原子动作串成"提议→审批→监测→审计" |
顺带一提，它还有个"姊妹能力"叫 AI Governance：一个集中可视化所有 Agent、技能、MCP 服务器的仪表盘，外加一个能用自然语言回答"哪些 Agent 在没有掩码的情况下读了 PII?"这类问题的技能。如果说意图驱动治理管的是"数据该怎么被保护",AI Governance 管的就是"Agent 有没有越界"——两者合起来，才是 Agent 时代治理的完整画面。
五、范式视角：从 Policy-as-SQL,到 Policy-as-Code,再到 Policy-as-Intent
要判断它是"真范式"还是"营销词",最好把它放进治理范式的演化线里看。治理策略的表达方式，大致走过三代：
| 代际 | 表达方式 | 谁来写 | 痛点 |
|---|---|---|---|
| Policy-as-SQL | 手写 CREATE MASKING POLICY …、手动打标 | 数据工程师/DBA | 业务意图到代码全靠人翻译，易漏、难维护 |
| Policy-as-Code | 声明式配置、版本化(类 Terraform) | 平台/治理工程师 | 可复现可审查，但仍要懂 DSL,意图与代码仍是两层 |
| Policy-as-Intent | 自然语言意图 → AI 编译 → 人审批 | 业务/合规 + AI | 意图成为源头，代码降级为"投影";但要信任 AI 的编译 |
这条线的方向很清楚：表达治理的"抽象层"在不断上移,离"人脑里的真实意图"越来越近，离"机器执行的语法"越来越远。
▲ 三代范式拾级而上：抽象层越往上越靠近人脑里的意图、越远离机器语法。到 Policy-as-Intent 这一级，策略不再是源头，而被"降级"为意图的可执行投影
Policy-as-Code 已经把"可复现、可审查"做到了，但它没解决"翻译鸿沟"——你还是得有人把业务诉求写成 DSL。意图驱动治理的赌注是：把这最后一层翻译也交给 AI,人只保留"审批"这个最高价值的动作。
但范式上移是有代价的，这代价就是信任。Policy-as-Code 的代码是确定性的，你 review 的就是最终执行物；而 Policy-as-Intent 里，你 review 的是 AI 编译出的 spec——它是否忠实地、完整地表达了你的意图,本身需要被信任。Snowflake 的应对是那个"先生成 CISO 可读 spec、再人工审批"的设计：它没有跳过人，而是把人放在"审 spec"而不是"审代码"的位置。这是个聪明的折中——但也意味着，spec 的可读性和完整性，直接决定了这套范式能不能被合规团队接受。 这正是它作为"私有预览"最需要被现场验证的地方。
六、合规与落地视角：审计闭环是它最被低估的杀手锏
如果只从"省了工程师写 SQL 的时间"来看这东西，会严重低估它。它真正的价值，在受监管行业(金融、医疗、公共部门)的审计场景里。
先说为什么审计是老大难。 传统治理里，合规链条是断的：监管要求在一份 Word 里，评审决定在一封邮件里，实际策略在数据库里，三者之间没有机器可读的连接。每次审计、每次合规复查，团队都要手工"重建"这条链：翻邮件找谁批的、查 DDL 看当时怎么配的、写报告解释为什么。这是纯消耗，而且容易出错、容易被质疑。
意图驱动治理把这条链变成了系统的原生结构。 因为每一条线上配置都"挂"在一个被批准的意图下面，审计包可以自动生成,并且直接把"现在的真实配置"追溯回"当初被批准的那条人类意图"。审计员要的"谁批的、为什么、什么时候、改过没有",系统直接给答案。这对那些把"56% 的受访者反映遇到至少一项治理与合规挑战"(Snowflake《2026 ROI of Gen AI and Agents》报告数据)当成头号拦路虎的企业，价值是实打实的。
从落地视角看，几条现实判断：
- 它降低的是"治理的参与门槛",不是"治理的责任"。 业务和合规终于能直接表达意图、看懂 spec、亲手审批，治理不再是数据工程团队的"黑话飞地"。但审批意味着担责，这件事的组织含义比技术含义更大。
- 大量能力仍是私有预览。 Intent-Driven Governance、Automatic Sensitive Data Protection 都标着 Private Preview——这意味着"现在就全量上线"不现实。能立刻用的是那三个 GA 的 CoCo 治理技能(用自然语言应用策略、修 bug、监控敏感数据),它们是这套范式"可以先试的入口"。
- 它的价值随数据估摸越碎越大。 当治理要横跨 Snowflake 内外、跨 Iceberg、跨外部引擎(Spark/Trino/Databricks),手工维护策略的成本是指数级的；而标签化 + 意图驱动正是为这种规模设计的。单一小仓库反而体现不出它的威力。
七、三个核心洞见与风险清单
把这篇调研里最值得记住的判断，提炼成三条：
洞见一：被自动化的是"翻译与对齐",不是"决策"。
意图驱动治理接管的是"把意图翻成上千个技术细节、并持续保持对齐"这件脏活，而"批准与否"这个决策权牢牢留在人手里。这条边界划得很精准——它没有去碰"AI 替你做合规决定"那条危险的线。
洞见二：意图成为源头，审计从"考古"变成"查表"。
当线上配置能一路追溯回被批准的意图，合规链条第一次在系统里被打通。对受监管行业，这比"省了写 SQL 的工"重要一个量级——它把审计从一项周期性的消耗，变成了一次查询。
洞见三：这是治理抽象层的又一次上移，代价是要为"AI 的编译"建立信任。
从 SQL 到 Code 再到 Intent,治理表达越来越靠近人脑里的意图。但越靠近，中间那层 AI 编译就越需要被信任——Snowflake 用"可读 spec + 人工审批"来兜底，而这套兜底好不好用，得等预览期的真实反馈。
风险也得摆清楚：
| 风险 | 说明 |
|---|---|
| 大量私有预览 | 核心能力尚未 GA,生产全量落地需要等待，且预览能力可能变动 |
| AI 编译的信任成本 | spec 是否忠实表达意图，需要合规团队建立新的审查习惯；漏掉的意图最危险 |
| 强 Snowflake 绑定 | 价值最大化依赖数据/资产在 Horizon 的治理边界内；跨栈时收益取决于互操作能力的成熟度 |
| 组织含义大于技术 | "业务/合规直接审批治理"会重新分配责任，落地阻力可能来自组织而非技术 |
结论
读完这篇，如果只带走几句话：
- 意图驱动治理的本质，是把"治理意图"提升为系统的第一公民。 策略(掩码/行访问/质量规则)从此只是意图的可执行投影，而不是治理的源头。
- 它的闭环是"意图→编译成可读 spec→人工审批→标签化执行→监测漂移→审计回溯",真正的护城河不在"AI 会写策略",而在"审计能一路追回那句被批准的话"。
- 底层不是魔法：靠的是标签化策略(一个标签一条策略、自动覆盖未来对象)、150+ 不依赖列名的分类器、以及三个已 GA 的 CoCo 治理技能这套早就存在的骨架。
- 现实地用它：多数能力还是私有预览，先从 GA 的自然语言治理技能试水；它的威力在数据估摸越碎、跨栈越多时越明显，合规审计场景收益最高。
当模型变成大路货、Agent 开始以机器速度读写敏感数据，企业治理的胜负手正在从"你写了多少策略"转向"你的策略还对不对得齐当初的意图、你能不能在审计时一秒说清"。意图驱动治理赌的就是后者。
留一个问题给你：如果明天合规官能直接用一句话表达治理意图、看懂 AI 生成的 spec、亲手点下批准——你的组织准备好把"治理的方向盘"交到业务和合规手里了吗？还是说，你更担心的是那份 spec 里"没被写进去"的意图？ 你的答案，基本决定了这层"意图"对你值多少钱。
参考资料
- Snowflake,"Set the Foundation for Trusted AI",2026-06-02,https://www.snowflake.com/en/blog/trusted-data-trusted-ai/
- Snowflake,"Snowflake Horizon Catalog: Data Governance & Discovery"(产品页),2026,https://www.snowflake.com/en/product/features/horizon/
- Snowflake(Danielle Kucera),"Intelligence and Interoperability: Data Catalog Must-Haves for AI Data Governance",2026-03-17,https://www.snowflake.com/en/blog/universal-ai-catalog-data-governance/
- DATUM STUDIO(菊地),"Snowflake Summit 2026 最速レポート Day3 – Horizon Catalogで実現するデータ＆AIガバナンス編 –"(WN210T 现场实录),2026-06-05,https://datumstudio.jp/blog/snowflake-summit-2026-dailyreport-day3-6/
- SiliconANGLE(Mark Albertson),"Snowflake adds new AI services while continuing to build relationships with key model providers",2026-06-02,https://siliconangle.com/2026/06/02/snowflake-adds-new-ai-services-continuing-build-relationships-key-model-providers/
- theCUBE Research,"Snowflake moves up the AI stack but the system of intelligence is still being built",2026-06,https://thecuberesearch.com/special-breaking-analysis-snowflake-moves-up-the-ai-stack-but-the-system-of-intelligence-is-still-being-built/