一份营销 AI 政策，是关于 AI 可以被用于什么、可以看什么数据、以及谁在它的产出离开团队之前审阅它的那套书面规则。治理是让那些规则成真的实践——把一份文件变成行为的审阅、记录和负责人。两者你都需要，而大多数团队两者都没有，或有一个在假装是另一个。
这件事在营销里比在许多职能里更重要的原因，是营销产出直接触及客户、品牌和客户合同。一行坏代码是一个 bug；一行坏文案是一个公开声明。那种不对称，就是政策必须在工具规模化之前存在、而不是在第一次事故之后的原因。
没有治理的政策是表演
一份住在 wiki 里、从不被引用的政策，比没有政策更糟，因为它制造了没有实质的控制的表象。人们以为有人在执行它。没人在。第一次出问题时，政策成为团队知道风险却什么都没做的证据。
治理是不光鲜的那一半：谁签批一个新的用例、审阅步骤住在工作流的哪里、什么被记录、以及什么触发一次升级。它是流程，不是文字。如果你的治理只是一份政策，你有一个愿望，不是一个控制。
政策必须覆盖的五件事
一份可行的营销 AI 政策回答五个问题、把其余留给运营模式。把它保持在这五个上，是让它短到能被读、又具体到能被执行的东西。
| 领域 | 它回答的问题 | 好的样子 |
|---|---|---|
| 允许的用途 | AI 可以被用于什么？ | 明确的允许、审阅、禁止清单 |
| 数据边界 | 模型可以看什么数据？ | 客户、个人、机密规则 |
| 披露 | 何时必须声明使用？ | 按渠道、按合同的规则 |
| 审阅 | 谁在产出上线之前检查它？ | 点名的角色和一个定义好的步骤 |
| 责任 | 谁拥有一次失败？ | 一位点名的负责人，不是「团队」 |
如果一份政策不回答全部五个，它会被每个读到它的人作不同解读，那恰恰是治理要防止的状态。
先定数据边界
边界问题是下行风险最大的那个，所以先解决它。客户数据、个人数据、以及任何在合同之下的东西，都应该有明确规则：哪些工具可以处理它、它可以在哪里。一个「不要把客户数据粘进公开工具」是好的开始、差的结束，因为它没有告诉一个忙碌的操盘手可以改做什么。
更好的规则是分层的：一类数据可以去任何批准的工具，一类只能去有数据处理协议的工具，一类不可以离开你的系统。然后让安全的路成为容易的路，让遵循规则比破坏它更省力。一条人们能遵守的边界，胜过一条他们绕开的边界。
披露与客户合同
披露是政策遇上客户关系的地方。有些客户想知道 AI 何时被用在他们的工作上；有些合同已经要求它；有些渠道有自己的规则。政策应该说你的默认是什么、以及客户如何改变它，而不是让每个 account 团队即兴发挥。
务实的动作是把披露变成一个你在 kickoff 时问的问题，而不是客户提起时的一次手忙脚乱。一条解释 AI 用在哪里、不用在哪里的短条款，在一开始商定，把一次未来的对抗变成一次已解决的预期。治理在主动时更便宜。
审阅与责任
每一份到达客户或消费者的 AI 辅助产出，都应该经过一个由点名角色拥有的审阅步骤。审阅不需要重；它需要真实、一致、被记录。要点是一位有责任的人看了这份工作、并决定它可以交付。
随着工具变快，这更重要、而不是更次要：一个让审阅者对产出盖橡皮章的工具，是一个治理风险，而不是一个生产力收益——我在为什么大多数 AI 营销工具感觉快却削弱团队判断里描述的那种判断侵蚀动态。
责任是更难的那一半。出错时，「团队」什么都不拥有。为每一类产出点名负责人，并给他们停下工作的权力。一份分配责任却不给权力的政策，会在它第一次让某人付出一个 deadline 的代价时被忽视。
执行它而不拖慢所有人
治理会杀死速度的担心是真实的，也大体可避免。诀窍是把控制嵌进工作流，而不是作为批准拧上去。如果审阅步骤是工作如何移动的一部分，它花分钟；如果它是一道某人必须记得的独立门，它花几天、且在压力下被跳过。
从风险最高的用例和真正覆盖它们的最轻可能控制开始，然后扩展。一个从第一天就覆盖一切的治理体制会被怨恨和侵蚀。一个从窄开始、并挣得自己范围的会熬过一个忙碌的季度。如何试点 AI是自然的伙伴，因为一次试点就是你测试自己实际需要哪些控制的地方。
一页骨架
把政策写成一页：允许的用途分三张清单、一条分层的数据规则、一个披露默认和一个 kickoff 问题、一个点名的审阅步骤、以及每一类产出的点名负责人。加一个短的变更日志，让它随工具演进。比这更长的不会被读；比这更含糊的不会被遵循。
然后把治理当作它的活版本：每月看一眼出现了哪些新用例、哪些审阅抓到了东西、以及是否有规则需要改。那个节奏让政策保持当下，而不必不断重写，也给团队一个地方提出一份文件永远无法完全预料的边缘案例。
起步而不堵住团队
让治理失败最快的方式，是把它当作一次打压来发布。处于压力下的团队会绕过让他们付出 deadline 的控制，而他们怨恨的政策会被当成一种形式。从两三条覆盖最高下行风险的规则开始——客户数据边界和审阅门——把其余保持为指导而非禁止。
让合规的路成为最快的路。如果批准的工具比未批准的更慢，人们会使用未批准的那个。提供一个安全又容易的默认，让遵循政策比忽略它更省力。然后随团队养成习惯而扩展规则，并在工具变化时重访它们。随使用而成长的治理会被遵循；一次强加的会被审计着对抗。保留一个一行的变更日志，让人们看到政策是活的、而非刻在石头上，并与使用它的人跑一次简短的季度复盘，因为他们带来的边缘案例正是文件无法预料的。一个团队帮忙维护的政策，是他们会在要紧时真正遵循的政策。
用真实的一周测试政策
一份政策的好坏只取决于它在压力下的行为，所以用正常的一周、而不是抽象地测试它。拿团队实际交付的三样东西，追踪每一个：模型看了什么数据、谁审阅了产出、以及如果它错了会怎样。如果三样里任何一个无法从一份记录回答，治理就是空想的。然后拿人们已经在抱怨的边缘案例——一个赶出来的 deadline、一个想要速度的客户、一个有人偏好的工具——现在就决定政策如何处理它们，而不是在一次事故中发现答案。熬过这个测试的政策是短的、具体的、且略烦人的；失败的那个在纸上全面、在实践中沉默。
FAQ
如果我们只用批准的工具，还需要政策吗？
需要，因为风险很少是工具、通常是数据或产出。批准的工具仍处理客户数据、产出到达消费者的文案。政策定义两者的边界，不管这个工具是如何被批准的。
谁该拥有它？
营销领导层拥有政策，一位点名的操盘手拥有日常治理。法律和安全应该复盘数据边界，但政策不能由法律来运营，因为它必须契合营销实际如何工作。所有权在营销内部，才让它可执行。
它该多久变一次？
每月复盘边缘、每季度复盘整个文件。工具比政策周期移动得更快，所以一个变更日志和一个短的复盘节奏，比一次全面的重写更重要。目标是一个当下的 one-pager，不是一个年度项目。
政策会拖慢我们吗？
做得差，会。作为工作流的一部分做，它加几分钟、并预防那种花几周的事故。那些觉得治理慢的团队，通常把它建成了一个独立的批准层，而不是嵌进工作已经如何移动。
简短版
一份营销 AI 政策定义 AI 可以碰什么、可以看什么、谁审阅它、以及谁拥有一次失败。治理是让那些规则在工作流内成真的实践。把政策保持在一页，先解决数据边界，通过工作、而不是绕开工作来执行它。执行指南把治理放进更宽的运营模式，面向内部团队的车道为一个客户侧的团队贯穿它来做。
如果你的团队写过一份这样的，我想听听哪条规则在实践中结果最重要。
祝好， Chandler
本文提供简体中文版本。课程材料（视频、模板和配套指南）以英语和日语提供。本网站提供13种语言版本。