SaaS LLM privacy: customer data और retention controls
Prompts, logs, provider retention, regional processing, deletion, subprocessors और customer commitments के लिए SaaS LLM privacy review बनाएं।
इस मार्गदर्शिका में
SaaS company LLM को भेजे customer data को कैसे सुरक्षित रखे?
Model provider को ऐसे data-processing path की तरह देखें जिसकी अपनी collection, retention, access और deletion प्रक्रिया है। Customer content भेजने से पहले purpose, data categories, endpoint और model, provider settings, persistence features और contract terms पहचानें। Provider policies product के अनुसार अलग होती हैं और बदल सकती हैं, इसलिए सभी prompts के व्यवहार के बारे में अनुमान लगाने की जगह exact API या service की मौजूदा शर्तें जांचें।
Service से बाहर जाने से पहले data कम और classify करें
हर AI feature के लिए केवल जरूरी fields map करें। असंबंधित records, secrets और direct identifiers हटाएं; task के लिए उपयुक्त हो तो pseudonyms या redaction करें। संवेदनशील categories को prompt से रोकें, जब तक documented purpose, approved provider path, access controls और उचित customer notice न हो। Truncation और masking का test करें, ताकि attachments या metadata में sensitive values बच न जाएं।
Exact endpoint के provider use और retention की समीक्षा करें
वास्तविक provider endpoint और account के लिए जांचें कि inputs या outputs model improvement में इस्तेमाल होते हैं या नहीं, abuse monitoring के लिए रखे जाते हैं या नहीं, application state के रूप में store होते हैं या provider logs में बने रहते हैं। Zero-data-retention या modified-monitoring विकल्प की पात्रता, approval, excluded features, region और deletion जांचें। OpenAI की प्रकाशित endpoint policy एक provider का उदाहरण है; यह दूसरे providers या हर endpoint का आश्वासन नहीं है।
AI logs और state में customer तथा tenant boundaries बनाए रखें
Request traces, safety logs, conversation history, vector stores, caches, feedback data और evaluation datasets की सूची बनाएं। हर item का owner, purpose, access policy और expiry तय करें। Stored state को सही tenant और user तक सीमित रखें; support या analytics tools को raw content default से न दिखाएं; और documented retention commitments के अनुसार customer deletion derived copies तक पहुंचाएं।
| Feature और data fields | Provider/endpoint और region | Use और retention की शर्तें | Tenant access/deletion path | Owner और review date |
|---|---|---|---|---|
| Customer support का सार | ||||
| Document question answering | ||||
| Model evaluation या feedback |
Launch से पहले SaaS AI vendor को क्या देखना चाहिए?
Purpose, roles और customer-facing notice दर्ज करें
बताएं कि AI feature क्या करता है, कौन सी जानकारी process होती है, कौन से subprocessors data पाते हैं और क्या कोई व्यक्ति output review करता है। Staff access को business need तक सीमित करें और support access दर्ज करें। Product notices, privacy disclosures, data-processing terms और असली implementation में मेल रखें; data कभी retain नहीं होता ऐसा दावा न करें जब provider और application settings उसे साबित न करें।
Region, transfer, security और incident की शर्तें जांचें
पुष्टि करें कि requests, stored state, abuse-monitoring data, backups और support access कहां process हो सकते हैं। Encryption, tenant isolation, subprocessors, breach notice, deletion सहायता और contractual जिम्मेदारी देखें। Region selector शायद केवल कुछ resources पर लागू हो; residency का वादा करने से पहले मौजूदा service documentation और contract में उसका दायरा जांचें।
Retention, deletion और provider बदलाव की योजना बनाएं
Prompts, outputs, ratings और traces के लिए retention schedule तय करें। Application databases, queues, indexes, backups और आपके नियंत्रण वाले provider state में deletion का परीक्षण करें। Vendor inventory रखें और endpoint, model, feature, subprocessor या policy बदलने पर review करें। Security, support या कानूनी जरूरत के लिए केवल न्यूनतम evidence रखें, जिसके साथ owner और expiry हो।
AI privacy controls को रोजमर्रा के संचालन में कैसे लाएं?
Code में data categories और destinations पर रोक लगाएं
Providers, endpoints, regions और data classes की reviewed allowlist इस्तेमाल करें। Destination स्वीकृत न हो या जरूरी settings की पुष्टि न हो सके तो request रोकें। Provider credentials server-side और environment के अनुसार अलग रखें; client code को model endpoint चुनने या मनमानी customer files बाहरी request में जोड़ने न दें।
वास्तविक जैसे fixtures से deletion और isolation जांचें
अलग marker वाले synthetic records से पुष्टि करें कि एक tenant के prompts, retrieval context, stored conversations और support views दूसरे को दिखाई न दें। User deletion, tenant closure, retention expiry और provider errors जांचें। Product record हटाने के बाद analytics export और evaluation dataset में वही content चुपचाप बचा न हो।
दूसरा sensitive store बनाए बिना evidence रखें
Versioned provider-policy reviews, endpoint settings, data-flow diagrams, contract references, retention decisions और test results रखें। Raw prompts के बजाय metadata और hashes को प्राथमिकता दें। Evidence तक पहुंच जवाबदेह staff तक सीमित रखें और उसकी अपनी retention अवधि तय करें; पूरी customer conversation वाले audit log से नया data exposure बन सकता है।
SaaS LLM data privacy: अक्सर पूछे जाने वाले सवाल
क्या API prompts हमेशा provider के model को train करने में इस्तेमाल होते हैं?
किसी भी दिशा में अनुमान न लगाएं। Exact provider product, endpoint और account की मौजूदा policy और settings जांचें। Model training को abuse-monitoring retention, application state, human review और आपके SaaS में रखे data से अलग समझें।
क्या zero-retention setting हर AI feature को cover करती है?
जरूरी नहीं। पात्रता, approval, endpoint coverage, stateful features और exceptions अलग हो सकते हैं। मौजूदा provider documentation और लिखित शर्तें जांचें, फिर test करें कि आपका application वही data अलग से retain न कर रहा हो।
नाम हटाकर क्या customer data भेज सकते हैं?
Pseudonymization exposure घटाती है, लेकिन व्यक्ति की पहचान असंभव होने की गारंटी नहीं। Fields कम करें, दोबारा पहचान का जोखिम देखें और data तभी भेजें जब feature का purpose और provider controls उसे उचित बनाएं।
AI feature के बारे में customers को क्या बताएं?
Purpose, data categories, provider की भूमिका, retention और उपलब्ध controls साफ शब्दों में बताएं और deployed system तथा contract से मेल रखें। ऐसे absolute privacy claims न करें जो सत्यापित provider या application behavior से आगे जाते हों।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- Your data and model usage policies by endpoint
- OWASP Top 10 for LLM Applications 2025
- LLM08:2025 Vector and Embedding Weaknesses
- Data Residency and Hybrid Cloud Lens
- AWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकना
- AWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षण
- OWASP Cheat Sheet: authorization
- OWASP Cheat Sheet: logging
- Digital Personal Data Protection Act, 2023
- Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E))