अपनी AI-बनाई ऐप में User Data कैसे सुरक्षित रखें (बिना किसी Security Team के)

हमारी जानने वाली एक coach ने एक weekend में किसी AI app builder से एक client-tracking ऐप बनाई। Session notes, goals, progress check-ins — वो सब कुछ जो वो पहले एक notebook में रखती थी, अब searchable और व्यवस्थित। यह इतना अच्छा चला कि उसके दो coach दोस्तों ने भी इसे इस्तेमाल करने को कहा।

तभी उसे एहसास हुआ: वो अब अपने ही notes नहीं रख रही थी। वो दूसरे लोगों के उनके clients के बारे में notes रख रही थी — health details, निजी जद्दोजहद, नाम। अगर वो डेटा leak होता, तो वो उसकी शर्मिंदगी नहीं होती। वो उनकी होती।

इसे ज़िम्मेदारी से संभालने के लिए आपको किसी security team की ज़रूरत नहीं। आपको तीन आदतों और अपने AI builder से कुछ सीधे सवाल पूछने की इच्छाशक्ति की ज़रूरत है। यह गाइड बताता है कि अपनी AI-बनाई ऐप में user data को उस स्तर पर कैसे सुरक्षित रखें जो किसी छोटे product के लिए असल में मायने रखता है।

शुरुआत यह ग़ौर करने से करें कि आप असल में कौन सा user data रख रहे हैं

ज़्यादातर builders इसे कम आंकते हैं। “मेरे पास तो बस एक signup form है” का आमतौर पर मतलब होता है कि आपके पास है:

• Email addresses — किसी को spam या phish करने के लिए काफ़ी।
• Behavior से जुड़े नाम — उन्होंने क्या खरीदा, क्या लिखा, कब log in करते हैं।
• जो भी आपके यूज़र free-text boxes में टाइप करते हैं — और लोग किसी notes field में कुछ भी टाइप कर देंगे: phone numbers, medical details, salaries, अपने boss की शिकायतें।

दस मिनट लें और हर वो जानकारी लिख डालें जो आपकी ऐप किसी इंसान के बारे में store करती है। database fields नहीं — इंसानी मतलब। “Email,” “वो कौन से supplements लेते हैं,” “उनके trainer ने उनके बारे में जो notes लिखे।” वो list आपकी ज़िम्मेदारी की सतह है। इस पोस्ट का बाक़ी सब उसे छोटा और सुरक्षित बनाने के बारे में है।

आदत 1: कम जमा करें

सुरक्षित रखने में सबसे सस्ता डेटा वो होता है जो आपने जमा ही नहीं किया। कुछ भी सुरक्षित करने से पहले, list छोटी करें।

अभी बनाई list में से गुज़रें और हर item के बारे में पूछें: क्या मैं इसे इस्तेमाल करता हूं? coach की ऐप signup पर date of birth मांगती थी क्योंकि AI builder के signup template में वो शामिल था। उसने उसे कहीं इस्तेमाल ही नहीं किया। उसके AI builder से एक वाक्य — “signup से date of birth हटा दो और column delete कर दो” — और sensitive डेटा की एक पूरी श्रेणी ख़त्म हो गई।

जो चीज़ें ऐप्स आमतौर पर जमा करती हैं और कभी इस्तेमाल नहीं करतीं: birth dates, phone numbers, physical addresses, gender, “आपको हमारे बारे में कैसे पता चला।” अगर आप इसे इस महीने इस्तेमाल नहीं कर रहे, तो आप बाद में कभी भी मांग सकते हैं। आप leak हुए को वापस नहीं कर सकते।

आदत 2: कौन क्या देख सकता है, इसे control करें

इस सवाल के दो वर्शन हैं, और आपको दोनों चाहिए।

ऐप के अंदर: क्या एक यूज़र दूसरे यूज़र का डेटा देख सकता है? अगर आपकी ऐप में clients और coaches हैं, तो क्या client A कभी client B के notes देख सकता है? हमने आपकी AI-बनाई ऐप में user permissions पर एक पूरा गाइड लिखा है, पर छोटा वर्शन: नियम को अपने AI builder को आसान भाषा में बताएं (“एक coach सिर्फ़ अपने ही clients देखता है; clients सिर्फ़ खुद को देखते हैं”) और फिर दो accounts से खुद उसे test करें। एक यूज़र के रूप में log in करें, इधर-उधर क्लिक करके दूसरे यूज़र के डेटा तक पहुंचने की कोशिश करें। पांच मिनट, दो test accounts। यह एक टेस्ट छोटी ऐप्स में सबसे आम leak पकड़ लेता है।

ऐप के बाहर: database को खुद कौन देख सकता है? वो आप हैं, आपका AI builder platform, और हर वो इंसान जिसके साथ आपने logins शेयर किए हैं। जो हमें सवालों तक ले आता है।

आदत 3: अपने builder से ये पांच सवाल पूछें

आपको जवाबों को गहराई से समझने की ज़रूरत नहीं। आपको पूछने की ज़रूरत है, और जवाब आत्मविश्वास भरे “हां” होने चाहिए। इन्हें अपने AI app builder में एक-एक करके paste करें:

1. “क्या user passwords hashed store होते हैं, या कोई भी उन्हें पढ़ सकता है?” एकमात्र स्वीकार्य जवाब में “hashed” शब्द होता है। अगर आपकी ऐप ऐसे passwords store करती है जिन्हें कोई भी पढ़ सके, तो आज ही ठीक करें — यह आमतौर पर एक-prompt वाला fix है, और ज़्यादातर modern builders इसे default रूप से सही करते हैं।
2. “क्या ऐप का connection encrypted (HTTPS) है?” अपने ही browser में padlock ढूंढें। अगर आपकी ऐप का address https:// से शुरू होता है, तो इस वाले के साथ आपका काम हो गया।
3. “अगर किसी को database file मिल जाए, तो क्या वो sensitive fields पढ़ सकता है?” यह encryption at rest के बारे में है। ज़्यादातर hosting platforms इसे अपने-आप संभालते हैं — फिर भी पूछें और जवाब लिख लें।
4. “कौन सी third-party services user data पाती हैं?” Email tools, analytics, payment processors। आप उन्हें हटा नहीं रहे — आप अपनी list को पूरा कर रहे हैं, क्योंकि आपके यूज़र्स का डेटा रखने वाली हर service आपकी ज़िम्मेदारी की सतह का हिस्सा है।
5. “क्या कोई backup है, और उस तक कौन पहुंच सकता है?” Backups आपके डेटा की copies हैं, और copies को भी सुरक्षा चाहिए। (अगर आपने backups बिल्कुल भी सेट नहीं किए हैं, तो यहां से शुरू करें।)

जवाबों को एक doc में save करें। वो doc आपकी security posture की शुरुआत है, और पहली बार जब कोई customer — या किसी customer का वकील — पूछेगा, तब आप खुश होंगे कि वो मौजूद है।

जब कोई कहे “मेरा डेटा delete करो”

आख़िरकार कोई कहेगा, और ज़्यादातर जगहों का क़ानून (यूरोप में GDPR, और कहीं-कहीं वैसे ही नियम) कहता है कि आपको उसे सचमुच करना होगा। अभी तय करें कि आपका जवाब क्या है:

• क्या आप एक यूज़र और उससे जुड़ी हर चीज़ delete कर सकते हैं? अपने AI builder से इसे जोड़ने को कहें — “एक admin action बनाओ जो एक यूज़र और उसका सारा डेटा delete कर दे” — डेडलाइन के दबाव में इसकी ज़रूरत पड़ने से पहले।
• क्या उन्हें ऐप में delete करने से वो आपके email tool और analytics से भी हट जाते हैं? सवाल 4 वाली अपनी list चेक करें।
• Backups में वो कुछ समय तक फिर भी रहेंगे। यह सामान्य है और आमतौर पर ठीक है — बस इसे जान लें, ताकि आप ईमानदारी से बता सकें।

तैयारी की वजह से किसी deletion request का जवाब एक दिन में देना प्रोफेशनल लगता है। दो हफ़्ते हाथ-पैर मारना ठीक वैसा ही लगता है जैसा वो है।

आसान भाषा वाला privacy page लिखें

अभी 4,000-शब्द वाली generate की हुई क़ानूनी जटिलता छोड़ दें। पांच ईमानदार वाक्य लिखें: आप क्या जमा करते हैं, क्यों, और कौन उसे छूता है (आपका email tool, आपका payment processor), आप उसे कितने समय रखते हैं, और deletion कैसे मांगें। उसे /privacy पर रखें और अपने signup page से उसका link दें।

यह क़ानूनी सलाह नहीं है, और अगर आप सचमुच sensitive डेटा संभाल रहे हैं — health, बच्चे, finances — तो किसी वकील के साथ एक घंटे पर पैसे खर्च करें। पर एक साफ़, ईमानदार page एक प्रभावशाली दिखने वाले page से बेहतर है जिसे कोई पढ़ ही न सके, और उसे लिखना आपको मजबूर करता है कि आप अपने ही जवाब सचमुच जानें।

मानक आपके डर से नीचा है, और शून्य से ऊंचा है

आप किसी राष्ट्र-राज्यों के ख़िलाफ़ बचाव नहीं कर रहे। आप उन बोरिंग, आम नाकामियों के ख़िलाफ़ बचाव कर रहे हैं: एक बचा-खुचा data field जिसकी किसी को ज़रूरत नहीं थी, एक permissions नियम जिसे किसी ने test नहीं किया, एक password table जिसे hash करना कोई भूल गया। इस स्तर पर user data सुरक्षित रखना कोई विशेषज्ञ का हुनर नहीं — उन नाकामियों में से हर एक एक आसान-भाषा वाले prompt और एक पांच-मिनट के टेस्ट से ठीक हो सकती है।

शुरुआत वाली coach ने यह सब एक दोपहर में किया: दो बेकार fields delete कीं, दो-account वाला टेस्ट चलाया (और एक leak पकड़ा — clients एक dropdown में एक-दूसरे के first names देख सकते थे), पांच सवाल पूछे, अपना privacy page लिखा। उसके बाद उसकी ऐप ज़रा भी अलग नहीं दिखी। पर जब उसकी दोस्त ने पूछा “क्या यह चीज़ मेरे client notes के लिए सुरक्षित है?”, तो उसके पास एक असली जवाब था।

वो दोपहर निकालें। आपके यूज़र्स ने आपको अपना डेटा भरोसे पर दिया — उसे संभालना ऐसा ही दिखता है।