為 AI govern marketing 數據，歸結為 model 睇到任何嘢之前你做出嘅四個決定：佢可以睇咩、可以喺邊度跑、邊個擁有產出、以及你保留幾耐。喺砌 memory layer 之前做出呢啲決定，佢哋就會塑造個架構。跳過佢哋，你之後會重建呢一層，通常喺律師嘅監督下，喺某樣嘢已經出咗事之後。
我喺系統度砌過 memory，亦都睇過團隊以速度為名跳過呢一步。個模式係一致嘅：model 睇到嘅比任何人本意嘅都多，一次 review 度有人問咗問題，然後係一次匆忙嘅補救。Governance 唔係對有趣工作徵收嘅稅；佢係安全咁做有趣工作嘅前提。
四個決定
Model 可以睇咩？ 唔係每一塊 marketing 數據都平等。公開 research、內部表現數據、客戶 PII、以及受監管 category，各自帶住唔同嘅義務。喺 model 掂任何嘢之前決定個分類，因為一旦數據入咗個 context window，「取消睇見」佢唔係一個真實選項。
佢可以喺邊度跑？ 一個喺你環境度跑嘅 model，同一個你透過 API 送 prompt 俾佢嘅 model，風險唔同，而兩者又同一個團隊成員貼入去嘅公開工具唔同。決定邊啲數據類別可以去邊種 model，並令個答案可執行、而唔係空想。
邊個擁有產出？ 當 model 產出一份 plan、一段 copy 或一個 audience 定義，要有人擁有佢。Governance 意味住點名嗰個人，並明確 accountability 唔轉移俾個工具。呢個同執行 lane入面嘅 review standard 係同一個原則。
你保留幾耐？ 保留係團隊推遲、之後後悔嘅決定。如果 context 令 model 變好，你想保留佢。如果佢包含個人或受監管數據，你可能俾人要求刪除佢。按數據類別決定保留，並令刪除係真嘅。
先俾數據分類
分類係另外三個決定嘅基礎，所以先做佢並保持簡單。一個可行嘅方案係四桶：公開、內部、機密、受監管。公開數據幾乎去得任何地方。內部數據——表現、花費、策略——留喺批准嘅 model 度。機密數據——特定客戶嘅 context、未發佈嘅 plan——留喺控制之內。受監管數據——任何掂到個人或法律保護資訊嘅嘢——接受最嚴格嘅處理，往往根本唔入一個通用 model。
分類嘅價值在於佢令啲規則對所有人都可讀。一個知個桶嘅 marketer 知咩可以貼入邊個工具，唔需要為每一種情況寫一份政策备忘。簡單喺呢度勝過全面，因為一條冇人記得嘅規則唔係 governance。
Model 喺邊度跑
託管決定係大部分真實風險所在。一個部署喺你自己環境、配你自己控制嘅 model，係最受約束嘅選項，亦都最花功夫跑。一個透過 vendor API、喺一個 data-processing agreement 之下訪問嘅 model，係常見嘅中間路徑，而啲條款極之重要——輸入係咪訓練 vendor 嘅 model、數據存喺邊、刪除保證係咩。
然後仲有公開工具嗰個情形，係一定要明確關掉嗰個。如果團隊成員開得到個 browser、將客戶數據貼入任何工具，其餘呢一切都不重要。點名批准嘅工具，封堵或勸阻其餘嘅，並解釋點解。未受 govern 嘅路徑幾乎總係嗰條方便嘅。
邊個擁有產出
每一個 AI 輔助嘅交付物都需要一位點名嘅 owner，而 owner 係人，唔係 workflow。呢個唔係技術細節；佢係令個產出站得住嘅嘢。如果一個 model 起草咗一份 media plan 而冇人簽批，間 agency 或團隊實際上就發佈咗部機器嘅猜測。Governance 分配個簽名。
呢個直接連到採購。當你買一間 agency 嘅 AI 原生服務，份約應該講邊個擁有產出、出錯時邊個負責。嗰度嘅含糊，係一個質素事故變成法律事故嘅方式。Governance 答案同 review standard 係同一條紀律應用到唔同風險上。
保留同刪除
保留係會複利嘅 memory 收益同刪除義務相撞嘅地方，冇繞過佢嘅辦法。Context 令 model 有用，所以你想保留 brief、結果同決定。同一批數據嘅一部分可能受刪除要求或合約限制。答案係按類別保留：無限咁保留衍生、去識別嘅 context；只喺俾人允許嘅範圍內保留原始個人數據；並明確兩者之間嘅邊界。
要喺砌之前做呢件事，係因為將刪除後補入一個 memory layer 好痛苦。如果原始數據同衍生 context 撈埋一齊，之後分開佢哋係一次遷移。由開始就設計好個分離。呢個係冇 memory 嘅 AI 只係一個貴嘅 chatbot嘅實際核心——memory 係價值，亦都係 governance 面。
一次分類演練
攞一場典型 campaign，將啲輸入排序。Category research 同 competitor 格局係公開嘅——去得任何地方。客戶嘅花費、表現歷史同內部策略係內部嘅——只用批准嘅工具。未發佈嘅 creative 概念同客戶名單係機密嘅——留喺控制之內。而任何識別到個人、或者落喺受監管 category 嘅嘢，接受最嚴格嘅處理，往往完全留喺通用 model 之外。
一旦呢個排序存在，啲規則自己就寫好咗。公開數據去得公開工具。內部同機密數據只入簽約、批准嘅 model。受監管數據冇一次專門 review 就唔去任何地方。個分類係將一份含糊嘅政策變成 marketer 十秒內做得到嘅決定——嗰個係唯一捱得住一個忙碌禮拜嘅 governance。
重要嘅 vendor 條款
當你評估一個 model vendor，四個條款決定大部分風險。Vendor 係咪用你嘅輸入訓練，定係你啲 prompt 俾排除喺訓練之外？數據存同處理喺邊，如果你有數據駐留義務，呢點好重要？刪除保證係咩、你點執行佢？以及合約結束時你嘅數據會點？將答案要成書面，因為個 marketing 網站唔會話你知。
大部分 enterprise vendor 而家提供不訓練選項同合理嘅刪除條款；要點係確認佢，而唔係假設佢。對一個將客戶數據貼入 chat window 嘅團隊，呢啲條款一個都唔適用，呢個正係點解批准工具清單一定要明確而短。
操作嘅次序
俾數據分類，決定每一類可以喺邊度跑，點名產出嘅 owner，按類別定保留。按呢個次序做，喺第一個掂到真實數據嘅 prompt 之前。然後將佢寫喺團隊搵得到嘅地方，並令批准嘅工具成為嗰條容易嘅路。依賴啲人記得一條規則嘅 governance 唔係 governance；係希望。
FAQ
我哋需要一份正式政策，定係一個團隊約定就夠？
由一份一頁嘅決定記錄開始，覆蓋四條問題，之後如果你嘅規模或監管者要求再正式化。一份短、被執行嘅約定，勝過一份冗長、俾人無視嘅政策。要點係決定，唔係產出一份文件。
我哋用得到公開 AI 工具處理內部 marketing 數據咩？
只喺內部數據唔係機密或受監管、而工具嘅條款允許嗰陣。對大部分團隊，誠實嘅答案係將內部同客戶數據透過批准、簽約嘅工具路由，公開工具留俾公開或合成數據。
我哋點樣設定數據邊界本身？
按分類，唔按工具。將每一個輸入排入四桶之一——公開、內部、機密、受監管——俾個桶決定佢可以去邊：公開數據去公開工具，內部同機密去批准、簽約嘅 model，受監管數據冇一次專門 review 就唔去任何地方。個邊界就係個分類，一旦佢存在，marketer 就十秒內做得到個判斷，唔需要政策备忘。
如果我哋講唔清某樣嘢屬於邊個桶呢？
默認到更嚴格嘅桶，將佢放入一個短嘅 review 清單，而唔係猜。模糊嘅數據通常係個人、特定客戶或受監管嘅，正係你唔想之後發現俾人錯處理嘅數據。一張兩行、列住啲人實際會標記嘅案例嘅清單，每月 review 一次，解決得到灰色地帶而唔拖慢工作。
短版
用四個決定 govern marketing 數據、喺 model 睇到任何嘢之前：佢可以睇咩、可以喺邊度跑、邊個擁有產出、保留幾耐。先分類、刻意託管、點名 owner、按類別定保留——然後喺呢個之上砌 memory layer。Execution 指南覆蓋其餘營運問題，面向 in-house 團隊嘅 lane將 governance 貫穿到 measurement。
如果你喺自己團隊上砌過呢套，我好想聽下四個決定入面邊個最難達成一致。
Cheers, Chandler
本文提供繁體中文（香港）版本。課程材料（影片、template同配套指南）以英語同日語提供。本網站提供13種語言版本。