Vibe Coding और GDPR: आपकी AI से बनी साइट शायद कानून तोड़ रही है

आप किसी coding agent को बताते हैं कि आपको कैसी app चाहिए, वह code लिखता है, आप deploy करते हैं, और कुछ ही घंटों बाद आपके पास एक असली product ऑनलाइन होता है। यही vibe coding का वादा है, और ज्यादातर समय यह वादा निभता भी है। साइट लोड होती है, signup चलता है, dashboard साफ-सुथरा दिखता है। जो कुछ आपको दिखता है, वह सब ठीक है।

दिक्कत उस सब में है जो आपको दिखता नहीं। जब वह आपके features जोड़ रहा था, तभी agent ने cookies, tracking, data storage और users के अधिकारों के बारे में दर्जनों छोटे-छोटे फैसले भी ले लिए। किसी ने उससे कानून के बारे में सोचने को नहीं कहा, इसलिए उसने सोचा भी नहीं। जिस वक्त आप ship करते हैं, उस वक्त तक आपकी चमचमाती नई साइट शायद पहले से ही GDPR उल्लंघनों के ढेर पर बैठी होती है, और आपको इसका कोई अंदाजा नहीं होता।

यह न तो कोई Claude की समस्या है, न Codex की। यह तो AI coding agents के काम करने के तरीके में ही बसी एक बुनियादी बात है, और यह उन सब पर लागू होती है। आइए ठीक-ठीक देखें कि क्या गड़बड़ होती है, इसकी क्या कीमत हो सकती है, और वह मुफ्त Claude Code skill जो किसी regulator के पहुंचने से पहले इन दिक्कतों को ढूंढकर ठीक कर देता है।

AI coding agent चुपचाप क्या गलत करता है

कोई भी coding agent सिर्फ एक चीज के लिए optimize करता है: feature को चला देना। उससे analytics मांगिए, वह एक tracking script टपका देगा। उससे contact form मांगिए, वह हर submission को एक table में store कर देगा। उससे login मांगिए, वह user records को अनिश्चितकाल तक रखे रहेगा। अलग-अलग देखें तो हर फैसला वाजिब है। पर मिलाकर देखें तो ये उन्हीं उल्लंघनों की किताबी सूची बन जाते हैं जिन पर regulators सबसे ज्यादा कार्रवाई करते हैं।

किसी आम vibe-coded साइट पर अमूमन यही चीजें नजर से छूट जाती हैं:

• Cookies और trackers consent से पहले चल पड़ते हैं। Analytics, embedded maps, fonts, social pixels और session tools पेज खुलते ही लोड हो जाते हैं। GDPR और ePrivacy नियमों के तहत, गैर-जरूरी cookies के लिए पहले से, स्वतंत्र रूप से दिया गया consent चाहिए। जो साइट उन्हें पहले paint पर ही टपका देती है, वह पहले से ही गैर-अनुपालक है, और वह cookie banner जो tracker के चलने के बाद ही दिखता है, इसे ठीक नहीं करता।
• Personal data हमेशा के लिए रखा जाता है। Agent एक users table, एक submissions table, एक logs table बनाता है, और कभी कोई retention policy नहीं जोड़ता। GDPR की मांग है कि आप personal data को बस उतनी ही देर रखें जितनी आपको सचमुच जरूरत हो। "हमेशा के लिए रखो, क्या पता कब काम आ जाए" वही storage-limitation उल्लंघन है जिसे रोकने के लिए कानून लिखा गया था।
• आपके data को डिलीट करने का कोई रास्ता नहीं है। Users को erasure का अधिकार है, यानी वही मशहूर भूल जाने का अधिकार (right to be forgotten)। लगभग कोई भी vibe-coded app किसी delete-my-account flow या erasure अनुरोध पूरा करने की किसी documented प्रक्रिया के साथ नहीं आती। Data अंदर जाता है, पर बाहर निकलने का कोई दरवाजा नहीं होता।
• Access या portability का कोई रास्ता नहीं। आपके पास उनके बारे में जो कुछ भी है, लोग उस सबकी एक copy मांग सकते हैं। अगर आपका इकलौता जवाब एक manual database query है जिसे आपने कभी test ही नहीं किया, तो आप access और portability की जिम्मेदारियां पूरी नहीं कर रहे।
• Third-party data चुपचाप EU से बाहर चला जाता है। वह analytics script या hosted font जो आपने दो सेकंड में जोड़ा, वह IP addresses और identifiers को बिना किसी कानूनी transfer तंत्र के EU के बाहर के servers तक भेज रहा हो सकता है।
• आप क्या इकट्ठा करते हैं, इसका कोई रिकॉर्ड नहीं। GDPR उम्मीद करता है कि आप अपनी processing गतिविधियों को जानें भी और उन्हें लिखित में दर्ज भी रखें। एक ऐसी app जिसके data flows सिर्फ agent के भुला दिए गए chat history में दबे पड़े हैं, उसके पास कोई register है ही नहीं।

इनमें से कुछ भी किसी demo में नहीं दिखता। App बिल्कुल सही चलती है। कानूनी परत बस गायब रहती है, और तब तक गायब रहती है जब तक कोई शिकायत न करे या कोई regulator दरवाजा न खटखटाए।

Agent बायां स्तंभ बिना किसी चूक के भर देता है। दायां स्तंभ वह हिस्सा है जिसे बनाने को किसी ने उससे कहा ही नहीं, इसलिए वह खाली रह जाता है।

हर coding agent ऐसा क्यों करता है, सिर्फ Claude नहीं

एक ही tool को दोष देना आसान है, पर वजह कहीं गहरी है। Coding agent सार्वजनिक code से सीखते हैं, और ज्यादातर सार्वजनिक code कभी GDPR को ध्यान में रखकर लिखा ही नहीं गया। जब किसी model ने "Google Analytics जोड़ो" के दस हजार उदाहरण देखे हों जो script को सीधे <head> में डाल देते हैं, तो यही pattern वह दोहराता है। Training data में बुरी आदत बैठ जाती है, इसलिए output उसी को विरासत में पा लेता है।

इस समस्या के व्यापक रूप पर ठोस आंकड़े मौजूद हैं। Veracode की 2025 GenAI Code Security Report ने 100 से ज्यादा large language models की output को दर्जनों coding कार्यों पर परखा और पाया कि 45% AI-generated code ने एक security खामी जोड़ी। उसी अध्ययन ने पाया कि AI से लिखे code में इंसानों के लिखे code के मुकाबले 2.74 गुना ज्यादा vulnerabilities थीं, और गौर करने लायक बात यह कि नए और बड़े models ने भी बेहतर नहीं किया। यह संरचनात्मक है, कोई ऐसा bug नहीं जिसे अगला release ठीक कर देगा।

Privacy अनुपालन भी ठीक उसी तरह की समस्या है जैसी security। दोनों ही ऐसी अदृश्य जरूरतें हैं जिन्हें "बस इसे चला दो" वाला लक्ष्य सीधे लांघ जाता है। तो चाहे आप Claude Code चलाएं या Codex, Antigravity CLI, Cursor, या कोई और agent, आप उसी blind spot के जोखिम में रहते हैं। Tool बदलता है, खाई नहीं।

एक GDPR उल्लंघन की असली कीमत क्या हो सकती है

यहीं आकर यह सब किताबी बातें नहीं रह जातीं। GDPR के जुर्माने की ऊपरी सीमा 2 करोड़ यूरो या वैश्विक सालाना कारोबार के 4% में से जो भी ज्यादा हो, उस पर तय है, और regulators ने इस दायरे के ऊपरी सिरे का इस्तेमाल शुरू कर दिया है।

अकेले 2025 में, फ्रांस के data protection प्राधिकरण CNIL ने 486 मिलियन यूरो के जुर्माने लगाए, जो उसके 2024 के कुल जोड़ से करीब दस गुना है। सितंबर में एक ही दिन के दो फैसलों से इसका ज्यादातर हिस्सा आया: cookie और advertising-transparency की चूकों के लिए Google पर 325 मिलियन यूरो, और बिना consent टपकाए गए trackers के लिए Shein पर 150 मिलियन यूरो। एक AI agent default रूप से जिन श्रेणियों की गलतियां ship करता है, ठीक वही श्रेणियां नौ अंकों के जुर्माने बटोर रही हैं।

इन आंकड़ों को पढ़कर यह मान लेना आसान है कि regulators सिर्फ दिग्गजों के पीछे पड़ते हैं। पर ऐसा नहीं है। CNIL एक सरलीकृत प्रक्रिया चलाता है जो सीधे छोटे, सीधे-सादे मामलों को निशाना बनाती है: एक गैर-अनुपालक cookie banner, एक नजरअंदाज किया गया access अनुरोध, एक कमजोर password नीति। किसी छोटे कारोबार के लिए ये रोजमर्रा के आम मामले हैं, और ये ठीक वही हैं जो एक vibe-coded साइट गलत करती है। आपकी कंपनी का आकार जुर्माने का आकार बदलता है, यह नहीं कि आप पर जुर्माना लग सकता है या नहीं।

सुर्खियों वाले जुर्माने बड़ी कंपनियों पर पड़ते हैं, लेकिन उनके पीछे के उल्लंघन, बिना consent वाली cookies और गायब transparency, वही हैं जो एक coding agent किसी छोटी साइट पर default रूप से ship कर देता है।

GDPR दरअसल क्या मांगता है (सीधी भाषा में)

ज्यादातर खाई पाटने के लिए आपको वकील बनने की जरूरत नहीं। रोजमर्रा के अनुपालन का बड़ा हिस्सा मुट्ठी भर ठोस व्यवहारों पर आकर टिकता है, जो या तो आपके code में हैं या नहीं:

• गैर-जरूरी cookies से पहले consent। जो कुछ भी track, profile या measure करता है, वह तब तक न चले जब तक user ने सक्रिय रूप से सहमति न दे दी हो। केवल सख्ती से जरूरी cookies ही इसका अपवाद हैं।
• आप जो भी data इकट्ठा करें, उसके हर हिस्से के लिए एक कानूनी आधार। Consent, contract, या legitimate interest, जो कुछ भी store करने से पहले तय हो, बाद में नहीं।
• Data minimization। सिर्फ वही इकट्ठा करें जिसकी feature को सचमुच जरूरत है। सब कुछ log कर देने की agent की प्रवृत्ति इसके ठीक उलट है।
• Retention की सीमाएं। Personal data की हर श्रेणी को एक तय जीवनकाल चाहिए और समय पूरा होने पर उसे डिलीट करने का तरीका।
• Data subject के अधिकार। Access, rectification, erasure और portability, इन सबको एक असली, चलता-फिरता रास्ता चाहिए, किसी privacy policy में किया गया वादा नहीं।
• एक स्पष्ट privacy notice और processing का एक रिकॉर्ड। लोग देख पाएं कि आप क्या इकट्ठा करते हैं और क्यों, और आप इसे साबित कर पाएं।

इस सूची को agents क्या गलत करते हैं वाले हिस्से के सामने रखकर दोबारा पढ़िए, और तालमेल लगभग एकदम सटीक है। अच्छी खबर यह है कि चूंकि ये ठोस, code-स्तर के व्यवहार हैं, इसलिए एक tool इन्हें scan कर सकता है।

हल: एक मुफ्त Claude Code skill जो scan करके ठीक करता है

यहां वह चीज है जो कोई manual checklist आपको नहीं दे सकती: आपके असली codebase पर एक स्वचालित जांच। Jeremy Longshore नाम के एक developer ने scanning-for-gdpr-compliance नाम का एक मुफ्त, open-source Claude Code skill प्रकाशित किया है (कुछ marketplaces में इसे GDPR Compliance Scanner के नाम से सूचीबद्ध किया गया है) जो ठीक यही करता है। यह claude-code-plugins-plus repository में रहता है और पूरी तरह Claude Code के अंदर चलता है, इसलिए साइन अप करने के लिए कोई अलग service नहीं है।

Skill आपके project को वैसे पढ़ता है जैसे कोई privacy auditor पढ़ेगा। यह data flows, storage की जगहों, processing गतिविधियों, consent तंत्रों, retention नीतियों, access controls, और आप data subject के अधिकारों को कैसे संभालते हैं, इन सबकी जांच करता है। फिर यह तीन ऐसी चीजें करता है जो मायने रखती हैं:

1. यह पहचानता है। नियम-आधारित जांच ऊपर बताए patterns को चिह्नित करती है: consent से पहले चलते trackers, बिना retention सीमा का personal data, गायब erasure रास्ते, बिना document किए गए processing।
2. यह गंभीरता के हिसाब से वर्गीकृत करता है। निष्कर्ष score किए हुए और प्राथमिकता के क्रम में आते हैं, इसलिए identifiers लीक करता हुआ कोई tracker आपकी privacy notice में किसी गायब लाइन से ऊपर रहता है। आप एक सपाट सूची में डूबने के बजाय खतरनाक चीजों को पहले ठीक करते हैं।
3. यह आपके code में सुधार करता है। चूंकि यह agent के अंदर चलता है, यह सिर्फ एक report नहीं बनाता जिस पर आपको बाद में काम करना पड़े। यह सुझाए गए बदलावों को सीधे लागू कर सकता है, "यहां आपकी एक दिक्कत है" को उसी जांच में एक असली edit में बदल देता है।

इसे install करना एक लाइन में हो जाता है। Plugin marketplace के साथ आप source जोड़ते हैं और skill install करते हैं:

/plugin marketplace add jeremylongshore/claude-code-plugins-plus

फिर सीधी-सादी भाषा में एक scan चालू करें। Skill इस तरह के वाक्यांशों पर प्रतिक्रिया देता है:

scan GDPR compliance
check data privacy
validate GDPR

आप इसे अपने project की .claude/skills/ directory में skill folder डालकर भी install कर सकते हैं, यही वह मानक तरीका है जिससे Claude Code skills खोजता है। दोनों ही सूरत में, scan आपके असली repository पर चलता है, किसी किताबी checklist पर नहीं।

Codebase अंदर, प्राथमिकता वाले निष्कर्ष बीच में, असली code edits बाहर। वही loop जो आप पहले से features के लिए इस्तेमाल करते हैं, अनुपालन की ओर मोड़ दिया गया।

एक ईमानदार सावधानी की बात, क्योंकि भरोसा यहीं तय होता है: एक scan कोई कानूनी मंजूरी नहीं है। Skill उन यांत्रिक, code-स्तर के उल्लंघनों को पकड़ता है जो रोजमर्रा के जोखिम का बड़ा हिस्सा बनाते हैं, यानी cookies, retention, गायब erasure flow, और यह आपको चंद मिनटों में अनुपालन के बहुत ज्यादा करीब ले आता है। यह किसी संवेदनशील चीज, किसी Data Protection Impact Assessment, या health data के processing के लिए किसी data protection वकील की जगह नहीं लेता। इसे उस तकनीकी पहली जांच की तरह देखिए जो साफ-साफ उल्लंघन हटा देती है, और फिर किनारे के मामलों के लिए इंसानी समीक्षा को बुलाइए।

जब आप agents का एक बेड़ा चलाते हैं तो यह मुश्किल क्यों हो जाता है

एक agent वाले एक developer के पास संभालने को एक ही codebase होता है। जिस पल आप कई agents समानांतर में चलाते हैं, हर एक उसी product में features ship करता हुआ, खामोश उल्लंघनों की जमीन कई गुना बढ़ जाती है। एक agent एक analytics script जोड़ता है, दूसरा एक logging table खड़ी करता है, तीसरा एक third-party widget जोड़ देता है, और किसी एक इंसान ने पूरे system पर इसके privacy असर की कभी समीक्षा ही नहीं की।

यही वह वजह है जिससे बड़े पैमाने पर context और संगति मुश्किल हो जाते हैं, एक ऐसा विषय जिस पर हम बार-बार लौटते हैं, चाहे बात coding agents को समानांतर में चलाने की हो या बिना डूबे vibe coding करने की। हल भी हर बार एक जैसा है: मानक को साझा setup का हिस्सा बना दीजिए, बजाय इसके कि वह कोई ऐसी चीज हो जिसे आप अंत में जांचना याद रखें।

AgentsRoom में, यानी उस multi-agent cockpit में, आप एक बार जो skills और नियम configure करते हैं वे कमरे के हर agent पर लागू होते हैं, उन सभी Claude Code, Codex और बाकी providers में जिन्हें आप एक ही जगह से चलाते हैं। अपने workflow में एक बार compliance जांच जोड़ दीजिए और हर agent उसे विरासत में पा लेता है, बजाय यह उम्मीद करने के कि हर एक स्वतंत्र रूप से कोई ऐसा नियम याद रखे जो उसे किसी ने सिखाया ही नहीं। जो अनुशासन एक अकेले session को साफ रखता है, वही पूरे बेड़े को नियामक मुसीबत से बाहर रखता है।

AI से बनी साइटों के लिए एक व्यावहारिक compliance checklist

किसी भी AI से बनी साइट को पूरा मानने से पहले, उसे इस सूची पर परखिए। इसका ज्यादातर हिस्सा scanner पकड़ लेगा, पर यह जानना कि आप क्या ढूंढ रहे हैं, report को पढ़ने लायक बना देता है:

• कोई गैर-जरूरी cookie या tracker user के consent देने से पहले नहीं चलता।
• हर personal-data store की एक तय retention अवधि और एक deletion तंत्र है।
• Users अपने data की एक copy मांग और पा सकते हैं।
• Users अपना account डिलीट कर सकते हैं और अपना data मिटवा सकते हैं।
• एक privacy notice बताता है कि आप क्या इकट्ठा करते हैं, क्यों, और किस कानूनी आधार पर।
• Third-party scripts और EU के बाहर के data transfers के पास एक वैध तंत्र है।
• पूछे जाने पर आप अपनी processing गतिविधियों का एक रिकॉर्ड पेश कर सकते हैं।

अगर आप हर खाने पर सही का निशान नहीं लगा सकते, तो आपकी AI से बनी साइट GDPR जोखिम ढो रही है, और इसे सामने ले आने के लिए एक अकेली शिकायत काफी है।

निचोड़

Vibe coding सचमुच तेज है, और यही तेजी जाल है। Agent वह सब भर देता है जो आपको दिखता है और वह सब छोड़ देता है जो नहीं दिखता, और ठीक वहीं GDPR रहता है। Consent से पहले cookies, हमेशा के लिए रखा गया data, उसे डिलीट करने का कोई रास्ता नहीं: ये कोई अनोखे किनारे के मामले नहीं हैं, ये हर coding agent की default output हैं, और ये वही चूकें हैं जिन पर regulators ने 2025 में करोड़ों यूरो के जुर्माने लगाए।

हल agents का इस्तेमाल बंद करना नहीं है। हल गायब जांच को जोड़ना है। अपने project पर मुफ्त scanning-for-gdpr-compliance skill चलाइए, इसे साफ-साफ उल्लंघनों को वर्गीकृत करके ठीक करने दीजिए, फिर जो बचे उसकी इंसानी समीक्षा करवाइए। चंद मिनटों का scan किसी regulator के पत्र से खाई का पता लगने के मुकाबले कहीं सस्ता है।

एक से ज्यादा agent के साथ बना रहे हैं? Claude Code, Codex और बाकी को एक ही cockpit से चलाने के लिए AgentsRoom डाउनलोड करें, provider compatibility matrix में देखें कि हर एक क्या-क्या सपोर्ट करता है, और पढ़ें कि तेज रफ्तार बनाए कैसे रखें, बिना डूबे vibe coding में।