AI के लिए marketing data govern करना चार फ़ैसलों पर आता है जो आप इससे पहले लेते हैं कि model कुछ भी देखे: यह क्या देख सकता है, यह कहाँ चलता है, output का owner कौन है, और आप इसे कितने समय रखते हैं। वे फ़ैसले memory layer बनाने से पहले लें, और वे architecture को shape देते हैं। उन्हें छोड़ें और आप उस layer को बाद में दोबारा बनाएँगे, अक्सर एक वकील की निगरानी में, जब कुछ टूट चुका होगा।
मैंने systems में memory बनाई है और मैंने teams को रफ़्तार के नाम पर यह कदम छोड़ते देखा है। Pattern एक जैसा है: model उससे ज़्यादा देखता है जितना किसी ने सोचा, एक review में एक सवाल उठता है, और एक जल्दबाज़ी में सुधार उसका पीछा करता है। Governance मज़ेदार काम पर एक tax नहीं है; यह मज़ेदार काम को सुरक्षित ढंग से करने की precondition है।
चार फ़ैसले
Model क्या देख सकता है? हर marketing data बराबर नहीं है। सार्वजनिक research, internal performance data, customer PII, और regulated categories अलग obligations लाते हैं। Model कुछ भी छूने से पहले classification तय करें, क्योंकि एक बार data एक context window में हो, "उसे न देखना" एक असली option नहीं रहता।
यह कहाँ चलता है? आपके environment में चलने वाला एक model उससे अलग risk है जिसे आप API से prompt भेजते हैं, और दोनों उस public tool से अलग हैं जिसे एक team member paste करता है। तय करें कि data की कौन-सी class किस प्रकार के model के पास जाती है, और जवाब को enforceable बनाएँ, सिर्फ़ इच्छा नहीं।
Output का owner कौन है? जब model एक plan, एक copy या एक audience definition produce करता है, तो किसी को उसका owner होना चाहिए। Governance का मतलब है उस व्यक्ति का नाम लेना, और साफ़ करना कि accountability tool को transfer नहीं होती। यह वही principle है जो execution lane में review standard है।
आप इसे कितने समय रखते हैं? Retention एक ऐसा फ़ैसला है जिसे teams टालती हैं और बाद में पछताती हैं। अगर context model को बेहतर बनाता है, तो आप उसे रखना चाहते हैं। अगर इसमें personal या regulated data है, तो आपको उसे delete करने के लिए मजबूर किया जा सकता है। Data class के हिसाब से retention तय करें, और deletion को असली बनाएँ।
पहले data classify करें
Classification बाक़ी तीन फ़ैसलों की नींव है, इसलिए इसे पहले करें और सरल रखें। एक व्यावहारिक schema चार groups हैं: public, internal, confidential, और regulated। Public data लगभग कहीं भी जा सकता है। Internal data — performance, spend, strategy — approved models के पास रहता है। Confidential data — client-specific context, unreleased plans — control में रहता है। Regulated data — जो भी personal या legally protected information छुए — सबसे सख़्त treatment पाता है और अक्सर किसी shared model में कभी नहीं जाता।
Classification का value यह है कि यह rules को सबके लिए पढ़ने लायक़ बनाती है। जो marketer group जानता है वह जानता है कि किस tool में क्या paste कर सकता है, हर case के लिए एक policy memo के बिना। यहाँ simplicity exhaustiveness को हराती है, क्योंकि जो rule किसी को याद नहीं रहता वह governance नहीं है।
Model कहाँ चलता है
Storage का फ़ैसला वह जगह है जहाँ असली risk का ज़्यादातर हिस्सा है। आपके अपने controls के साथ आपके environment में deployed एक model सबसे contained और चलाने में सबसे मेहनत वाला option है। एक data-processing agreement के तहत vendor API के ज़रिए access किया गया model आम बीच का रास्ता है, और terms निर्णायक हैं — क्या input vendor के model को train करता है, data कहाँ रहता है, और deletion guarantees क्या हैं।
फिर public tool वाला case है, जिसे साफ़ तौर पर बंद करना है। अगर एक team member एक browser खोलकर किसी भी tool में client data paste कर सकता है, तो बाक़ी सब कुछ मायने नहीं रखता। Approved tools के नाम लें, बाक़ी को block या discourage करें, और क्यों समझाएँ। Ungoverned रास्ता लगभग हमेशा सबसे सुविधाजनक होता है।
Output का owner कौन है
हर AI-assisted deliverable को एक नामित owner चाहिए, और owner एक व्यक्ति है, process नहीं। यह technical nit नहीं है; यह वह चीज़ है जो output को defensible बनाती है। अगर एक model एक media plan लिखता है और कोई हस्ताक्षर नहीं करता, तो एजेंसी या team ने असल में एक machine का अनुमान publish कर दिया। Governance हस्ताक्षर सौंपती है।
यह सीधे ख़रीद से जुड़ता है। जब आप एक एजेंसी की AI-native services ख़रीदते हैं, contract को बताना चाहिए कि output का owner कौन है और जब वह ग़लत हो तो कौन जवाब देता है। वहाँ ambiguity ही वह तरीक़ा है जिससे एक quality incident एक legal incident बन जाता है। Governance का जवाब और review standard एक ही discipline हैं जो अलग risks पर लागू होती हैं।
Retention और deletion
Retention वह जगह है जहाँ memory का compounding benefit और delete करने की obligation टकराते हैं, और सोच-समझकर सोचने से बचने का कोई रास्ता नहीं। Context model को उपयोगी बनाता है, इसलिए आप briefs, results और decisions रखना चाहते हैं। उसी data का एक हिस्सा deletion requests या contract limits के अधीन हो सकता है। समाधान class के हिसाब से retain करना है: derived, de-identified learnings अनिश्चित काल तक रखें; raw personal data सिर्फ़ तब तक जब तक आपको अनुमति हो; और उनके बीच की सीमा साफ़ रखें।
यह build से पहले करने का कारण यह है कि एक memory layer में retroactively delete करना बहुत दर्दनाक है। अगर raw data और derived context मिल जाएँ, तो उन्हें बाद में अलग करना एक migration है। Separation को शुरू से design करें। यह उस कारण का व्यावहारिक दिल है कि बिना memory वाला AI सिर्फ़ एक महँगा chatbot है — memory ही value है, और यह governance की surface भी है।
एक classification, की हुई
एक आम campaign लें और inputs classify करें। Industry research और competitor context public हैं — कहीं भी जा सकते हैं। Spend, performance history और client की internal strategy internal हैं — सिर्फ़ approved tools। Unreleased creative concepts और client की customer list confidential हैं — control में रखे हुए। और जो भी किसी व्यक्ति की पहचान करता है, या एक regulated category से belongs करता है, सबसे सख़्त treatment पाता है और अक्सर shared models से पूरी तरह बाहर रहता है।
एक बार classification मौजूद हो, तो rules ख़ुद लिख जाते हैं। Public data public tools में जा सकता है। Internal और confidential data सिर्फ़ approved, contracted models में जाता है। Regulated data बिना एक specific review के कहीं नहीं जाता। Classification वह चीज़ है जो एक vague policy को उस फ़ैसले में बदलती है जिसे एक marketer दस सेकंड में लेता है — governance का अकेला प्रकार जो एक भरे हफ़्ते के संपर्क में बचता है।
Vendor terms जो मायने रखते हैं
जब आप एक model vendor आँकते हैं, चार terms risk का ज़्यादातर हिस्सा तय करते हैं। Vendor आपके input पर train करता है, या आपका prompt training से बाहर रहता है? Data कहाँ store और process होता है, जो मायने रखता है अगर आपकी data residency obligations हैं? Deletion guarantees क्या हैं और आप उन्हें कैसे enforce करते हैं? और contract ख़त्म होने पर आपके data का क्या होता है? लिखित जवाब माँगें, क्योंकि marketing website आपको नहीं बताएगी।
ज़्यादातर enterprise vendors अब एक no-training option और उचित deletion terms देते हैं; बात assume करने के बजाय confirm करने की है। एक ऐसी team के साथ जो client data एक chat window में paste करती है, कोई term लागू नहीं होता, जो ठीक इसीलिए है कि approved tools की सूची साफ़ और छोटी होनी चाहिए।
कदमों का क्रम
Data classify करें, तय करें कि हर class कहाँ चलती है, output owners के नाम लें, और class के हिसाब से retention तय करें। इसी क्रम में करें, इससे पहले कि पहला prompt असली data छुए। फिर इसे वहाँ लिखें जहाँ team इसे ढूँढ सके, और approved tool को आसान रास्ता बनाएँ। जो governance इस पर निर्भर हो कि लोग एक rule याद रखें वह governance नहीं; वह उम्मीद है।
FAQ
क्या हमें एक formal policy चाहिए या एक team agreement काफ़ी है?
चार सवालों को cover करने वाले एक page के decision record से शुरू करें, और बाद में formalise करें अगर scale या आपका regulator माँगे। एक छोटा, लागू किया गया agreement एक लंबी, अनदेखी policy को हराता है। बात फ़ैसले की है, document बनाने की नहीं।
क्या हम internal marketing data के लिए public AI tools इस्तेमाल कर सकते हैं?
सिर्फ़ तब जब internal data confidential या regulated न हो और tool के terms अनुमति दें। ज़्यादातर teams के लिए, ईमानदार जवाब है internal और client data को approved, contracted tools से route करना, और public tools को public या aggregated data के लिए छोड़ना।
Data boundaries कैसे तय करें?
Classification से, tool से नहीं। हर input को चार groups में से एक में classify करें — public, internal, confidential, regulated — और group को तय करने दें कि यह कहाँ जा सकता है: public data public tools में, internal और confidential approved और contracted models में, regulated data बिना एक specific review के कहीं नहीं। Boundary classification है, और एक बार वह मौजूद हो, एक marketer दस सेकंड में फ़ैसला लेता है बिना policy memo के।
अगर हम पहचान न कर सकें कि कुछ किस group में है?
Default सख़्त group पर रखें और इसे अनुमान लगाने के बजाय एक छोटी review सूची में डालें। Ambiguous data अक्सर personal, client-specific, या regulated होता है — ठीक वही जिसे आप बाद में ग़लत तरीक़े से handled पाते नहीं देखना चाहते। उन cases की दो-line की सूची जिन्हें लोग असल में flag करते हैं, महीने में review की जाने वाली, grey zones को बिना काम धीमा किए सुलझा देती है।
Short version
AI के लिए marketing data को चार फ़ैसलों से govern करें जो model के कुछ भी देखने से पहले लिए जाएँ: यह क्या देख सकता है, कहाँ चलता है, output का owner कौन है, और आप इसे कितने समय रखते हैं। पहले classify करें, retention को जान-बूझकर तय करें, owners के नाम लें, और class के हिसाब से retention रखें — फिर उसके ऊपर memory layer बनाएँ। Execution guide बाक़ी operating सवालों को cover करता है, और for-in-house-teams track governance को measurement तक ले जाती है।
अगर आपने अपनी team पर यह बनाया है, तो मैं सुनना चाहूँगा कि चारों फ़ैसलों में से कौन-सा सहमत होना सबसे मुश्किल था।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी, जापानी, सरलीकृत चीनी और कोरियाई में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।