एक marketing AI policy वह लिखित नियम-समूह है कि AI किस लिए इस्तेमाल हो सकता है, कौन-सा data देख सकता है, और team से बाहर निकलने से पहले उसका output कौन review करता है। Governance वह practice है जो उन rules को असली बनाती है — reviews, logs और owners जो एक document को behaviour में बदल देते हैं। आपको दोनों चाहिए, और ज़्यादातर teams के पास न तो कोई है और न एक दूसरे का रूप धारण किए हुए।
यह marketing में कई functions से ज़्यादा क्यों मायने रखता है इसका कारण यह है कि marketing output सीधे customers, brands और client contracts को छूता है। Code की एक ख़राब line एक bug है; copy की एक ख़राब line एक सार्वजनिक बयान है। वह asymmetry ही कारण है कि policy tooling के scale होने से पहले मौजूद होनी चाहिए, पहली घटना के बाद नहीं।
बिना governance की policy नाटक है
जो policy एक wiki में रहती है और कभी refer नहीं की जाती वह बिना policy से बुरी है, क्योंकि यह control की आभा बनाती है बिना substance के। लोग मान लेते हैं कि कोई इसे enforce कर रहा है। कोई नहीं कर रहा। पहली बार जब कुछ ग़लत होता है, policy इस बात का सबूत बन जाती है कि team जोखिम जानती थी और उसके बारे में कुछ नहीं किया।
Governance वह ग़ैर-चमकदार आधा है: एक नए use case पर कौन sign off करता है, workflow में review step कहाँ रहता है, क्या log होता है, और क्या एक escalation trigger करता है। यह process है, prose नहीं। अगर आपकी governance सिर्फ़ एक policy है, तो आपके पास एक इच्छा है, एक control नहीं।
पाँच चीज़ें जो एक policy को cover करनी चाहिए
एक काम की marketing AI policy पाँच सवालों का जवाब देती है और बाक़ी operating model पर छोड़ देती है। इसे इन पाँच तक रखना ही इसे पढ़ने लायक़ छोटी और enforce करने लायक़ specific बनाता है।
| क्षेत्र | जिस सवाल का जवाब देती है | अच्छा कैसा लगता है |
|---|---|---|
| अनुमत उपयोग | AI किस लिए इस्तेमाल हो सकता है? | स्पष्ट allow, review और ban lists |
| Data boundaries | एक model कौन-सा data देख सकता है? | Client, personal और confidential rules |
| Disclosure | उपयोग कब declare करना है? | Per-channel और per-contract rules |
| Review | Output भेजे जाने से पहले कौन check करता है? | एक नामित role और एक defined step |
| Accountability | एक failure का owner कौन? | एक नामित owner, "team" नहीं |
अगर एक policy पाँचों का जवाब नहीं देती, तो उसे हर पढ़ने वाला अलग समझेगा, जो ठीक वह अवस्था है जिसे governance रोकना चाहती है।
पहले data boundaries
Boundary का सवाल वही है जिसमें सबसे ज़्यादा नुक़सान है, तो इसे पहले तय करें। Client data, personal data, और contract के तहत कुछ भी — इनके बारे में स्पष्ट rules होने चाहिए कि कौन-से tools उन्हें process कर सकते हैं और वे कहाँ रह सकते हैं। "Client data एक public tool में paste न करें" एक अच्छी शुरुआत और एक ख़राब अंत है, क्योंकि यह एक व्यस्त operator को नहीं बताता कि इसके बजाय वह क्या कर सकता है।
बेहतर rule एक tiered rule है: एक data category जो किसी भी approved tool में जा सकती है, एक जो सिर्फ़ data-processing agreement वाले tools में जा सकती है, और एक जो आपके systems से बिलकुल बाहर नहीं जा सकती। फिर सुरक्षित रास्ते को आसान रास्ता बनाएँ, ताकि rule follow करना उसे तोड़ने से कम काम हो। जो boundary लोग निभा सकें वह उस boundary को हराती है जिसे वे बाईपास करते हैं।
Disclosure और client contracts
Disclosure वह जगह है जहाँ policy client relationship से मिलती है। कुछ clients जानना चाहते हैं कि उनके काम में AI कब इस्तेमाल हुआ; कुछ contracts पहले से यह माँगते हैं; कुछ channels के अपने rules हैं। Policy को बताना चाहिए कि आपका default क्या है और एक client उसे कैसे बदल सकता है, हर account team को improvisation पर छोड़ने के बजाय।
व्यावहारिक कदम disclosure को एक ऐसा सवाल बनाना है जो आप kickoff पर पूछें, एक ऐसी जल्दबाज़ी नहीं जब client इसे उठाए। एक छोटा clause जो समझाता है कि AI कहाँ इस्तेमाल होता है और कहाँ नहीं, शुरू में तय किया हुआ, एक भावी टकराव को एक settled expectation में बदल देता है। Governance तब सस्ती होती है जब वह proactive हो।
Review और accountability
हर AI-assisted output जो एक client या एक consumer तक पहुँचता है, उसे एक नामित role के स्वामित्व वाले एक review step से गुज़रना चाहिए। Review को भारी होने की ज़रूरत नहीं; उसे असली, consistent और logged होने की ज़रूरत है। बात यह है कि accountability वाले एक human ने काम देखा और तय किया कि वह भेजने लायक़ है।
यह तब और मायने रखता है, कम नहीं, जब tools तेज़ होते हैं: जो tool reviewers को output carimba करने देता है वह एक productivity win के बजाय एक governance risk है — वह judgement-erosion dynamic जिसे मैंने क्यों ज़्यादातर AI marketing tools तेज़ लगते हैं पर team judgment कमज़ोर करते हैं में बताया।
Accountability कठिन आधा है। जब कुछ ग़लत होता है, "team" किसी चीज़ की owner नहीं। हर output class के लिए owner नाम लें, और उन्हें काम रोकने का अधिकार दें। जो policy बिना authority के ज़िम्मेदारी सौंपती है वह एक ऐसी policy है जिसे पहली बार नज़रअंदाज़ किया जाएगा जब यह किसी का deadline ले।
सबको धीमा किए बिना enforce करना
यह डर कि governance speed मार देती है असली है और ज़्यादातर टाला जा सकता है। तरकीब यह है कि controls को approvals की तरह लगाने के बजाय workflow में embed करें। अगर review step काम के चलने का हिस्सा है, तो उसमें मिनट लगते हैं; अगर यह एक अलग gate है जिसे किसी को याद रखना है, तो दिन लगते हैं और दबाव में छोड़ दिया जाता है।
सबसे जोखिम भरे use cases और उन्हें सचमुच cover करने वाले सबसे हल्के controls से शुरू करें, फिर बढ़ें। जो governance regime पहले दिन से सब कुछ cover करे उससे चिढ़ होगी और वह erode होगी। जो संकुचित शुरू होकर अपना scope कमाए वह एक व्यस्त quarter के संपर्क में बचेगी। AI कैसे pilot करें वाला लेख स्वाभाविक साथी है, क्योंकि एक pilot वह जगह है जहाँ आप test करते हैं कि आपको असल में कौन-से controls चाहिए।
एक page का skeleton
Policy को एक page की तरह लिखें: तीन lists में permitted uses, एक tiered data rule, एक disclosure default और एक kickoff सवाल, एक नामित review step, और हर output class के लिए एक नामित owner। एक छोटा change log जोड़ें ताकि वह tools के साथ evolve करे। इससे लंबा कुछ भी पढ़ा नहीं जाएगा; इससे vague कुछ भी follow नहीं किया जाएगा।
फिर governance को living version मानें: एक मासिक नज़र कि कौन-से नए use cases आए, किन reviews ने कुछ पकड़ा, और क्या कोई rule बदलने की ज़रूरत है। वह cadence policy को बिना लगातार दोबारा लिखे current रखती है, और team को एक जगह देती है जहाँ वे edge cases उठाएँ जिनका एक document कभी पूरी तरह अनुमान नहीं लगा सकता।
Team को रोके बिना शुरू करना
Governance को fail कराने का सबसे तेज़ तरीक़ा इसे एक crackdown की तरह launch करना है। दबाव में teams उन controls को बाईपास करेंगी जो उनका deadline लेते हैं, और जिस policy से वे चिढ़ती हैं उसे एक formality माना जाएगा। सबसे ज़्यादा नुक़सान वाले दो-तीन rules से शुरू करें — client data boundaries और review gate — और बाक़ी सब को prohibition के बजाय guidance रखें।
Compliant रास्ते को सबसे तेज़ बनाएँ। अगर approved tool unapproved से धीमा है, तो लोग unapproved इस्तेमाल करेंगे। एक ऐसा default दें जो सुरक्षित और आसान हो, ताकि policy follow करना उसे नज़रअंदाज़ करने से कम काम हो। फिर rules बढ़ाएँ जैसे team आदतें बनाए, और उन्हें तब revise करें जब tools बदलें। जो governance इस्तेमाल के साथ बढ़ती है वह follow की जाती है; जो एक साथ थोपी जाती है उसके ख़िलाफ़ audit होता है। एक एक-line change log रखें ताकि लोग देखें कि policy ज़िंदा है, पत्थर पर खुदी नहीं, और एक छोटा त्रैमासिक review उन लोगों के साथ चलाएँ जो इसे इस्तेमाल करते हैं, क्योंकि वे edge cases जो वे लाते हैं वही हैं जिनका document अनुमान नहीं लगा सकता। जिस policy को team बनाए रखने में मदद करती है वही है जिसे वे असल में follow करेंगे जब यह मायने रखेगी।
किसी असली हफ़्ते पर policy test करना
एक policy उतनी ही अच्छी है जितना दबाव में उसका व्यवहार, तो इसे एक आम हफ़्ते पर test करें, अमूर्त में नहीं। तीन चीज़ें लें जो team ने सचमुच भेजी, और हर एक को trace करें: model ने कौन-सा data देखा, output किसने review किया, और अगर वह ग़लत होता तो क्या होता। अगर तीनों में से कोई एक एक record से जवाब न दे सके, तो governance aspirational है। फिर वे edge cases लें जिन पर लोग पहले से बड़बड़ाते हैं — एक जल्दी deadline, एक client जो रफ़्तार चाहता है, एक tool जो किसी को पसंद है — और अभी तय करें कि policy उन्हें कैसे handle करती है, किसी incident के दौरान जवाब खोजने के बजाय। जो policy इस test से बचे वह छोटी, specific और थोड़ी कष्टकारी होती है; जो fail हो वह काग़ज़ पर comprehensive और व्यवहार में ख़ामोश।
FAQ
अगर हम सिर्फ़ approved tools इस्तेमाल करें तो क्या policy चाहिए?
हाँ, क्योंकि जोखिम कम ही tool होता है और आमतौर पर data या output। Approved tools अब भी client data process करते हैं और consumers तक पहुँचने वाली copy produce करते हैं। Policy दोनों के इर्द-गिर्द boundaries तय करती है, इस बात की परवाह किए बिना कि tool कैसे approve हुआ।
इसका owner कौन होना चाहिए?
Marketing leadership policy की owner है, एक नामित operator दिन-प्रतिदिन की governance का owner होता है। Legal और security को data boundaries review करनी चाहिए, लेकिन policy legal से नहीं चलाई जा सकती, क्योंकि उसे marketing के असल काम में फिट होना है। Marketing के अंदर ownership ही इसे enforceable बनाती है।
इसे कितनी बार बदलना चाहिए?
Edges को महीने में और पूरे document को तिमाही review करें। Tools policy cycles से तेज़ चलते हैं, इसलिए एक change log और एक छोटी review cadence एक comprehensive rewrite से ज़्यादा मायने रखते हैं। लक्ष्य एक current one-pager है, एक सालाना project नहीं।
क्या एक policy हमें धीमा करती है?
बुरी तरह किया तो हाँ। Workflow का हिस्सा बनाकर किया तो यह मिनट जोड़ती है और उस तरह की incident रोकती है जो हफ़्ते लेती है। जो teams governance को धीमा पाती हैं उन्होंने आमतौर पर इसे एक अलग approval layer की तरह बनाया है, काम के पहले से चलने के तरीक़े में embed करने के बजाय।
Short version
एक marketing AI policy तय करती है कि AI क्या छू सकता है, क्या देख सकता है, उसे कौन review करता है, और एक failure का owner कौन है। Governance वह practice है जो उन rules को workflow के अंदर असली बनाती है। Policy को एक page पर रखें, data boundaries पहले तय करें, और इसे काम के ज़रिए enforce करें, उसके इर्द-गिर्द नहीं। Execution guide governance को व्यापक operating model में रखता है, और for in-house teams track इसे एक client-side team के लिए चलाती है।
अगर आपकी team ने इस तरह की एक लिखी है, तो मैं सुनना चाहूँगा कि कौन-सा rule व्यवहार में सबसे ज़्यादा मायने रखता निकला।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी और जापानी में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।