hiलेखक: Zeeshan Mallick

आपकी AI Policy, AI Governance नहीं है। यह सिर्फ Permission Slip है।

एक page की policy models, data, access, vendors या incidents को control नहीं करती। McKinsey, NIST और IBM founders के लिए operating governance दिखाते हैं।

आपकी AI Policy, AI Governance नहीं है। यह सिर्फ Permission Slip है। — The Mallick View
aigovernancefoundersceocybersecurityriskleadershipcompany-building
# आपकी AI Policy, AI Governance नहीं है। यह सिर्फ Permission Slip है। **सीधा जवाब:** AI policy लोगों को बताती है कि उन्हें क्या करना चाहिए। AI governance साबित करती है कि risk का owner कौन है, कौन से systems मौजूद हैं, वे कौन सा data छूते हैं, outputs कैसे check होते हैं और failure होने पर क्या होगा। एक page की policy governance नहीं है। यह अच्छे इरादों वाली permission slip है। Data में यह gap पहले से दिख रहा है। McKinsey के अनुसार **तीन-चौथाई से अधिक organisations** कम से कम एक business function में AI use करती हैं। फिर भी generative AI use करने वाली organisations में केवल **27% respondents** ने कहा कि use से पहले employees सभी AI-generated content review करते हैं। लगभग इतना ही share कहता है कि **20% या कम** content check होता है। **47%** ने कहा कि उनकी organisation को generative AI से कम से कम एक negative consequence मिला है। IBM के अनुसार Ponemon Institute द्वारा study की गई **600 organisations** में **63% के पास AI governance policies नहीं थीं** जो AI manage करें या shadow AI रोकें। IBM यह भी report करता है कि AI-related security incident वाली organisations में **97% के पास proper AI access controls नहीं थे**। IBM study में high shadow-AI use ने average breach cost में **USD 670,000** जोड़े। Sources: [McKinsey, The State of AI](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value), [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) और [IBM, 2025 Cost of a Data Breach Report](https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai)। ## Policy illusion ज्यादातर founders एक document से शुरू करते हैं: “Confidential data public AI tools में मत डालो।” “Customer को भेजने से पहले AI output check करो।” “केवल approved tools use करो।” Words responsible लगते हैं। लेकिन ये operating questions का answer नहीं देते: - Employees पहले से कौन से AI tools use कर रहे हैं? - उन्हें approve किसने किया? - कौन से models customer या company data access कर सकते हैं? - किन employees या agents को permission है? - High-volume workflow में “output check” का exact मतलब क्या है? - Prompts, outputs, approvals और incidents कहाँ log होते हैं? - System बंद कौन कर सकता है? - कौन सा vendor data retain कर सकता है या model training में use कर सकता है? अगर कोई answer नहीं दे सकता, तो policy AI को control नहीं करती। यह सिर्फ hope को document करती है। ## Adoption, oversight से तेज चल रहा है McKinsey का 2025 global survey दिखाता है कि AI adoption broad है, लेकिन governance uneven है। AI-using organisations में केवल **28%** respondents ने कहा कि CEO AI governance oversee करता है, जबकि **17%** ने board को owner बताया। McKinsey ने यह भी पाया कि **21%** respondents ने कहा कि उनकी organisation ने generative AI के लिए कम से कम कुछ workflows को fundamentally redesign किया है। पाँच में से एक से कम ने कहा कि organisation generative-AI solutions के KPIs track करती है। एक-तिहाई से कम ने कहा कि organisation McKinsey द्वारा tested 12 adoption और scaling practices में से अधिकांश follow करती है। यह important है क्योंकि AI risk केवल model के अंदर नहीं होता। वह workflow के अंदर भी होता है। Internal notes draft करने वाला AI assistant एक risk है। Refund issue करने, prices बदलने, suppliers approve करने, customer messages भेजने या sensitive records access करने वाला AI agent अलग risk है। दोनों को “AI use” की एक policy category में डालना control system नहीं है। ## केवल policy बनाम operating governance | सवाल | केवल policy वाला approach | Operating governance | |---|---|---| | Ownership | किसी ने document लिखा | Named executive risk own करता है | | Inventory | Employees खुद tools report करते हैं | Company live AI register रखती है | | Access | Sensitive data पर general warning | Role-based access, least privilege और revocation | | Risk | हर use case के लिए एक rule | Impact और autonomy के आधार पर risk tiers | | Output | “Send करने से पहले check करो” | Review thresholds, sampling और sign-off defined | | Vendors | Contract language | Vendor due diligence, data limits और exit plan | | Data | “Confidential data upload न करें” | Classification, lineage, retention और deletion rules | | Monitoring | Annual policy reminder | Logs, KPIs, drift checks, alerts और audits | | Failure | User को blame करना | Pause, contain, investigate, correct और learn | | CEO question | क्या policy publish हुई? | कौन, कौन सा data, क्यों और कैसे use कर रहा है? | ## NIST कहता है governance lifecycle है U.S. National Institute of Standards and Technology ने AI Risk Management Framework बनाया ताकि organisations AI systems के design, development, use और evaluation में trustworthiness शामिल कर सकें। NIST framework को चार functions में organise करता है: **Govern, Map, Measure और Manage**। **Govern** का अर्थ है पूरे lifecycle में ownership, culture और accountability। **Map** का अर्थ है context, intended use, affected people, data, dependencies और possible harm को समझना। **Measure** का अर्थ है performance, security, privacy, bias, reliability और दूसरे risks test करना। **Manage** का अर्थ है risks को prioritise करना, respond करना, document करना और समय के साथ control करना। NIST का point practical है: System बदलता है। Data बदलता है। Users बदलते हैं। Vendor बदलता है। Risk बदलता है। System बदलने पर PDF नहीं बदलती। ## Access-control problem IBM की 2025 breach research उन founders के लिए warning है जो समझते हैं कि AI governance सिर्फ ethics या compliance topic है। यह identity और security topic भी है। IBM कहता है कि AI-related security incident वाली organisations में **97% के पास proper AI access controls नहीं थे**। Question केवल यह नहीं है कि employees AI use कर सकते हैं या नहीं। Question है कि tool क्या read, write, execute, export, remember या trigger कर सकता है। Public article summarise करने वाला chatbot और CRM, finance system, code repository, customer support inbox या HR database access करने वाला autonomous agent एक जैसे नहीं हैं। दोनों को एक policy category में डालना access को accountability से तेज बढ़ने देना है। ## Growing company के लिए minimum governance stack **1. Owner name करें।** CEO को हर control खुद run नहीं करना है, लेकिन AI risk register, decisions, exceptions और reporting का owner कोई होना चाहिए। **2. AI inventory बनाएं।** Models, tools, vendors, internal agents, departments, data sources, users, permissions, locations और affected business decisions list करें। **3. Risk tiers बनाएं।** Low-risk drafting को high-impact decisions, external communication, sensitive data, autonomous actions और regulated use cases से अलग करें। **4. Access control करें।** Least privilege use करें। AI system को सिर्फ वही data और actions दें जिनकी जरूरत है। Roles या vendors बदलने पर permissions review और revoke करें। **5. Data classify करें।** Public, internal, confidential, personal, regulated और prohibited data define करें। हर class के साथ tool-specific rules जोड़ें। **6. Human review define करें।** “Human in the loop” काफी नहीं है। लिखें कि review कब mandatory है, reviewer कौन qualified है, क्या check करना है और क्या evidence record होगा। **7. Important activity log करें।** Appropriate और lawful होने पर tool, user, model, data class, approval, action और incident records रखें। **8. Vendors review करें।** Data कहाँ जाता है, कितने समय retain होता है, model train होता है या नहीं, subprocessors कौन हैं, incidents कैसे report होते हैं और exit कैसे होगा—पूछें। **9. Outcomes और failure measure करें।** Adoption, accuracy, rework, overrides, complaints, security events, time saved, revenue impact और cost track करें। Hours बचाकर rework बढ़ाना productivity win नहीं है। **10. Shutdown practice करें।** तय करें कि system pause, data isolate, access revoke, customers notify और investigation कौन करेगा। अगर answer “उस समय देखेंगे” है, तो control missing है। ## Founder audit अगली leadership meeting में पूछें: 1. आज कितने AI tools use हो रहे हैं, including employee-purchased tools? 2. कौन से AI systems customer, financial, source-code, HR या legal data access कर सकते हैं? 3. कौन से systems केवल text नहीं, action भी कर सकते हैं? 4. हर high-risk use case का owner कौन है? 5. External AI output का कितना percentage qualified review पाता है? 6. हर vendor की retention और training policy last time कब check हुई? 7. किसी AI system का access revoke करने का fastest तरीका क्या है? 8. कौन सा AI KPI activity नहीं, business value prove करता है? 9. कौन सा incident आज system रोक देगा? 10. क्या board को current AI inventory और risk map दिखा सकते हैं? अगर ज्यादातर answers “हमारे पास policy है” हैं, तो governance नहीं है। एक document system की जगह खड़ा है। ## Frequently asked questions ### AI policy और AI governance में क्या difference है? AI policy principles और acceptable behaviour बताती है। AI governance ownership assign करती है और inventory, risk, access, testing, monitoring, incidents, vendors और review के controls चलाती है। ### क्या AI policy useful है? हाँ। Policy governance की एक layer है। यह expectations communicate करती है और baseline बनाती है। यह तब dangerous हो जाती है जब leaders document को proof मान लें कि risk controlled है। ### क्या हर startup को formal AI governance team चाहिए? जरूरी नहीं। Small startup एक accountable owner, live inventory, risk tiers, access rules, vendor checks, output review और incident playbook से शुरू कर सकता है। AI access, autonomy, data sensitivity और business impact बढ़ने पर system भी बढ़ना चाहिए। ### IBM ने AI access controls पर क्या पाया? IBM ने report किया कि AI-related security incident वाली organisations में 97% के पास proper AI access controls नहीं थे। यह IBM research sample का finding है, हर organisation की universal rate नहीं। ### NIST क्या recommend करता है? NIST AI Risk Management Framework risk work को Govern, Map, Measure और Manage के चार functions में organise करता है। यह trustworthy AI के लिए voluntary guidance है। ### Human को कितना AI output review करना चाहिए? हर workflow के लिए एक percentage नहीं है। Customer impact, legal या financial risk, sensitive data, autonomy और error cost जितने ज्यादा हों, review उतना stronger होना चाहिए। “Human in the loop” के बजाय exact thresholds define करें। ### Shadow AI क्या है? Shadow AI उन AI tools या features का use है जिन्हें organisation ने approve, inventory या govern नहीं किया। Good faith में किया गया use भी data, security, privacy, vendor और accountability risks बना सकता है। ### CEO को क्या measure करना चाहिए? Business value और control quality: adoption, accuracy, rework, overrides, incidents, complaints, data exposure, access reviews, time saved, revenue impact और cost। Usage alone governance या value नहीं है। ## अंतिम verdict AI को memo govern नहीं करेगा। AI को owners, inventories, permissions, risk tiers, review thresholds, logs, vendor controls, measurable outcomes और system को समय पर stop करने की क्षमता govern करेगी। **आपकी AI policy governance नहीं है। यह governance का पहला page है। अगर उसके पीछे controls operate नहीं करते, तो यह permission slip है।** ## Sources - [McKinsey — The State of AI](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value) - [NIST — AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [IBM — 2025 Cost of a Data Breach Report](https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai)

Master Collective न्यूज़लेटर

संस्थापकों, पूंजी और रणनीतिक विकास पर संक्षिप्त विचार पाएं।

कॉल बुक करें