一份 marketing AI 政策，係關於 AI 可以被用嚟做咩、可以睇咩數據、以及邊個喺佢個產出離開團隊之前 review 佢嗰套書面規則。Governance 係令嗰啲規則成真嘅實踐——將一份文件變成行為嘅 review、記錄同 owner。兩者你都需要，而大部分團隊兩者都冇，或者有一個喺度假裝係另一個。
呢件事喺 marketing 度比喺好多職能度更重要嘅原因，係 marketing 產出直接掂到客戶、品牌同客戶合約。一行壞 code 係一個 bug；一行壞 copy 係一個公開聲明。嗰種唔對稱，就係政策一定要喺 tooling 規模化之前存在、而唔係喺第一次事故之後嘅原因。
冇 governance 嘅政策係表演
一份住喺 wiki 度、從不俾人引用嘅政策，比冇政策更差，因為佢製造咗冇實質嘅控制嘅表象。啲人以為有人喺度執行佢。冇人喺度。第一次出事嗰陣，政策成為團隊知個風險卻乜都冇做嘅證據。
Governance 係唔光鮮嗰一半：邊個簽批一個新用例、review 步驟住喺個 workflow 邊度、咩俾人記錄、以及咩觸發一次升級。佢係流程，唔係文字。如果你嘅 governance 淨係一份政策，你有一個願望，唔係一個控制。
政策一定要覆蓋嘅五件事
一份可行嘅 marketing AI 政策答五條問題、將其餘留俾 operating model。將佢保持喺呢五個上，係令佢短到讀得到、又具體到執行得到嘅嘢。
| 領域 | 佢答嘅問題 | 好嘅樣 |
|---|---|---|
| 允許嘅用途 | AI 可以被用嚟做咩？ | 明確嘅允許、review、禁止清單 |
| 數據邊界 | Model 可以睇咩數據？ | 客戶、個人、機密規則 |
| 披露 | 幾時一定要聲明使用？ | 按 channel、按合約嘅規則 |
| Review | 邊個喺產出上線之前檢查佢？ | 點名嘅角色同一個定義好嘅步驟 |
| Accountability | 邊個擁有一次失敗？ | 一位點名嘅 owner，唔係「團隊」 |
如果一份政策唔答晒五個，佢會俾每個讀到佢嘅人作唔同解讀，嗰個恰恰係 governance 要防止嘅狀態。
先定數據邊界
邊界問題係下行風險最大嗰個，所以先解決佢。客戶數據、個人數據、以及任何喺合約之下嘅嘢，都應該有明確規則：邊啲工具處理得到佢、佢可以喺邊。一個「唔好將客戶數據貼入公開工具」係好嘅開始、差嘅結束，因為佢冇話俾一個忙碌嘅 operator 知可以改做咩。
更好嘅規則係分層嘅：一類數據去得任何批准嘅工具，一類只可以去有 data-processing agreement 嘅工具，一類唔可以離開你嘅系統。然後令安全嘅路成為容易嘅路，令遵循規則比破壞佢更省力。一條啲人遵守得到嘅邊界，勝過一條佢哋繞開嘅邊界。
披露同客戶合約
披露係政策撞到客戶關係嘅地方。有啲客戶想知 AI 幾時俾人用喺佢哋嘅工作上；有啲合約已經要求佢；有啲 channel 有自己嘅規則。政策應該講你嘅默認係咩、以及客戶點樣改變佢，而唔係俾每個 account 團隊即興發揮。
務實嘅動作係將披露變成一個你喺 kickoff 時問嘅問題，而唔係客戶提起時嘅一次手忙腳亂。一條解釋 AI 用喺邊、唔用喺邊嘅短條款，喺一開始商定，將一次未來嘅對抗變成一次已解決嘅預期。Governance 喺主動時更平。
Review 同 accountability
每一份到達客戶或消費者嘅 AI 輔助產出，都應該經過一個由點名角色擁有嘅 review 步驟。Review 唔需要重；佢需要真實、一致、俾人記錄。要點係一位有 accountability 嘅人睇咗份工作、並決定佢可以交付。
隨住啲工具變快，呢個更重要、而唔係更次要：一個令 reviewer 對產出蓋橡皮章嘅工具，係一個 governance 風險，而唔係一個生產力收益——我喺點解大部分 AI marketing 工具感覺快卻削弱團隊判斷描述嘅嗰種判斷侵蝕動態。
Accountability 係更難嗰一半。出事嗰陣，「團隊」咩都唔擁有。為每一類產出點名 owner，並俾佢哋停下份工作嘅權力。一份分配責任卻唔俾權力嘅政策，會喺佢第一次令某人俾出一個 deadline 嘅代價時俾人無視。
執行佢而唔拖慢所有人
Governance 會殺死速度嘅擔心係真實嘅，亦都大體可避免。個秘訣係將控制嵌進個 workflow，而唔係作為批准擰上去。如果 review 步驟係工作點移動嘅一部分，佢花幾分鐘；如果佢係一道某人一定要記得嘅獨立門，佢花幾日、且喺壓力下俾人跳過。
由風險最高嘅用例同真正覆蓋到佢哋嘅最輕可能控制開始，然後擴展。一個由第一日就覆蓋一切嘅 governance 體制會俾人怨恨同侵蝕。一個由窄開始、並賺得自己範圍嘅會捱得過一個忙碌嘅季度。點樣 pilot AI係自然嘅伙伴，因為一次 pilot 就係你測試自己實際需要邊啲控制嘅地方。
一頁骨架
將政策寫成一頁：允許嘅用途分三張清單、一條分層嘅數據規則、一個披露默認同一個 kickoff 問題、一個點名嘅 review 步驟、以及每一類產出嘅點名 owner。加一個短嘅變更日誌，令佢隨工具演進。比呢個更長嘅唔會俾人讀；比呢個更含糊嘅唔會俾人跟。
然後將 governance 當成佢嘅活版本：每月睇一眼出現咗邊啲新用例、邊啲 review 捉到嘢、以及係咪有規則要改。嗰個節奏令政策保持當下，而唔使不斷重寫，亦都俾團隊一個地方提出一份文件永遠無法完全預料到嘅邊緣案例。
起步而唔塞住團隊
令 governance 失敗最快嘅方式，係將佢當成一次打壓嚟發佈。處於壓力下嘅團隊會繞過令佢哋俾出 deadline 嘅控制，而佢哋怨恨嘅政策會俾人當成一種形式。由兩三條覆蓋最高下行風險嘅規則開始——客戶數據邊界同 review 門——將其餘保持為指導而非禁止。
令合規嘅路成為最快嘅路。如果批准嘅工具比唔批准嘅更慢，啲人會用唔批准嗰個。提供一個安全又容易嘅默認，令遵循政策比無視佢更省力。然後隨團隊養成習慣而擴展規則，並喺工具變嗰陣重訪佢哋。隨使用而成長嘅 governance 會俾人跟；一次強加嘅會俾人審計住對抗。保留一個一行嘅變更日誌，令啲人睇到政策係活嘅、而非刻喺石頭上，並同用佢嘅人跑一次簡短嘅季度 review，因為佢哋帶嚟嘅邊緣案例正係文件無法預料到嘅。一個團隊幫手維護嘅政策，係佢哋會喺要緊嗰陣真正跟嘅政策。
用真實嘅一個禮拜測試政策
一份政策嘅好壞只取決於佢喺壓力下嘅行為，所以用正常嘅一個禮拜、而唔係抽象咁測試佢。攞團隊實際交付嘅三樣嘢，追蹤每一個：model 睇咗咩數據、邊個 review 咗個產出、以及如果佢錯咗會點。如果三樣入面任何一個無法由一份記錄答到，governance 就係空想嘅。然後攞啲人已經喺度抱怨嘅邊緣案例——一個趕出嚟嘅 deadline、一個想要速度嘅客戶、一個有人偏好嘅工具——而家就決定政策點處理佢哋，而唔係喺一次事故中發現答案。捱得過呢個測試嘅政策係短、具體、且略煩人嘅；失敗嗰個喺紙上全面、喺實踐中沉默。
FAQ
如果我哋只用批准嘅工具，仲需要政策咩？
需要，因為風險好少係工具、通常係數據或產出。批准嘅工具仍然處理客戶數據、產出到達消費者嘅 copy。政策定義兩者嘅邊界，唔理個工具係點俾人批准嘅。
邊個該擁有佢？
Marketing 領導層擁有政策，一位點名嘅 operator 擁有日常 governance。法律同安全應該 review 數據邊界，但政策唔可以由法律嚟運營，因為佢一定要契合 marketing 實際點工作。所有權喺 marketing 內部，才令佢可執行。
佢該幾耐變一次？
每月 review 邊緣、每季 review 成份文件。工具比政策週期移動得更快，所以一個變更日誌同一個短嘅 review 節奏，比一次全面重寫更重要。目標係一個當下嘅 one-pager，唔係一個年度 project。
政策會拖慢我哋咩？
做得差，會。作為 workflow 嘅一部分做，佢加幾分鐘、並預防嗰種花幾週嘅事故。嗰啲覺得 governance 慢嘅團隊，通常將佢砌成咗一個獨立嘅批准層，而唔係嵌進工作已經點移動。
短版
一份 marketing AI 政策定義 AI 可以掂咩、可以睇咩、邊個 review 佢、以及邊個擁有一次失敗。Governance 係令嗰啲規則喺 workflow 內成真嘅實踐。將政策保持喺一頁，先解決數據邊界，透過工作、而唔係繞開工作嚟執行佢。Execution 指南將 governance 放入更寬嘅 operating model，面向 in-house 團隊嘅 lane為一個客戶側嘅團隊將佢貫穿嚟做。
如果你嘅團隊寫過一份噉嘅，我好想聽下邊條規則喺實踐中結果最重要。
Cheers, Chandler
本文提供繁體中文（香港）版本。課程材料（影片、模板和配套指南）以英文、日文、簡體中文和韓文提供。本網站提供 13 種語言版本。