SaaS LLM बातचीत की स्थिति: टेनेंट अलगाव, अवधि और मिटाना
हर अनुरोध पर सर्वर-साइड स्वामित्व जाँच, न्यूनतम स्थिति, स्पष्ट retention, टेनेंट-सीमित पहचान और निकले डेटा व प्रदाता तक पहुँचने वाली deletion से बातचीत सुरक्षित रखें।
इस मार्गदर्शिका में
SaaS ऐप में LLM बातचीत की स्थिति कैसे रखें?
केवल ज़रूरी बातचीत स्थिति सर्वर के नियंत्रण में रखें और उसे मालिक तथा टेनेंट से बाँधें। provider response ID, conversation ID या पिछले-turn token स्थिति का संदर्भ है, यह प्रमाण नहीं कि वर्तमान उपयोगकर्ता उसे पढ़ या जारी रख सकता है। हर पढ़ने, जारी रखने, निर्यात और मिटाने के अनुरोध पर अनुमति जाँचें और प्रदाता की अवधि को अपने नियंत्रण वाली प्रतियों से अलग सँभालें।
स्वामित्व के लिए एप्लिकेशन रिकॉर्ड को प्रामाणिक रखें
एक अप्रत्याशित internal conversation ID बनाएँ और उसे प्रमाणित उपयोगकर्ता, टेनेंट, डेटा वर्ग, प्रदाता संदर्भ और अवधि नीति से जोड़ें। provider ID इस्तेमाल करने से पहले टेनेंट-अनुमति के जरिए अपना रिकॉर्ड खोजें। ब्राउज़र से मिले किसी भी प्रदाता संदर्भ को दूसरे की बातचीत पढ़ने की अनुमति न मानें।
कच्ची बातचीत और निकले सारांश न्यूनतम रखें
तय करें कि अगले काम के लिए कौन-से संदेश, संलग्नक, टूल परिणाम और सारांश ज़रूरी हैं। संभव हो तो संवेदनशील फ़ील्ड सहेजने से पहले हटाएँ। मॉडल का सारांश अविश्वसनीय और अधूरा हो सकता है: उपयोगकर्ता, टेनेंट या अनुमति तय करने के लिए उसे न मानें; मौजूदा एप्लिकेशन डेटा से पहचान सत्यापित करें।
प्रदाता की स्थिति को अपनी प्रतियों से अलग समझें
हर API call के लिए दर्ज करें कि क्या उत्तर सहेजा जाता है, स्थायी conversation बनती है, पिछले उत्तर से श्रृंखला जुड़ती है या अन्य provider सुविधा इस्तेमाल होती है। endpoint, परियोजना सेटिंग, शर्तें, अवधि नियंत्रण और अपवाद मौजूदा दस्तावेज़ में जाँचें। एक setting बंद करने से अपना database, trace, फ़ाइल, backup या हर provider सुविधा नहीं मिटती।
| डेटा प्रति | मालिक और टेनेंट कुंजी | उद्देश्य | अवधि और deletion रास्ता | प्रदाता या backup निर्भरता |
|---|---|---|---|---|
| ऐप के संदेश | ||||
| प्रदाता स्थिति संदर्भ | ||||
| सारांश, कैश या trace |
टेनेंट के बीच पहुँच और पुरानी memory कैसे रोकें?
हर बार आगे की बातचीत और lookup पर अनुमति जाँचें
Internal conversation रिकॉर्ड को उसी समय प्रमाणित टेनेंट और ID से खोजें। हर नए turn पर सदस्यता और भूमिका फिर जाँचें, क्योंकि शुरुआत के बाद पहुँच बदली हो सकती है। क्लाइंट द्वारा ID बदलने या खाता स्थानांतरित होने पर पुराने provider thread को जोड़कर बातचीत दूसरे टेनेंट में न ले जाएँ।
अनुमति बदलने पर स्थिति का पुराना संदर्भ अमान्य करें
यदि retained context किसी पहुँच या निर्णय को प्रभावित कर सकता है तो उसमें स्रोत रिकॉर्ड का संस्करण या policy epoch रखें। अनुमति रद्द, रिकॉर्ड मिटाने या टेनेंट बंद करने पर प्रभावित स्थिति जारी न रखें; नीति के अनुसार सारांश, कैश और retrieval entries अमान्य करें। पुरानी assistant memory को वैध मानने के बजाय मौजूदा अधिकृत स्रोतों से बनाएँ।
पहचान और स्थिति वाले API को सुरक्षित रखें
Provider secret और ID सर्वर पर रखें। जहाँ लागू हो CSRF सुरक्षा, दर सीमा, प्रमाणीकरण, रिकॉर्ड-स्तरीय अनुमति और ऑडिट logging लागू करें। सार्वजनिक URL, analytics, support tool या error message में पहचान न दिखाएँ; रिसाव का संदेह हो तो संदर्भ बदलें और प्रभावित session अमान्य करें।
Retention, export और deletion व्यवहार में कैसे चलाएँ?
हर डेटा प्रति की लिखित अवधि बनाएँ
मूल संदेश, फ़ाइल, सारांश, vector रिकॉर्ड, कैश, मॉडरेशन मामला और trace के लिए उद्देश्य, अवधि, मिटाने की वजह, कानूनी रोक, भूमिकाएँ और backup व्यवहार लिखें। उपयोगकर्ता से किया वादा वास्तविक lifecycle और प्रदाता सेटिंग से मेल खाना चाहिए। सेवा के अधिकार-क्षेत्र और ग्राहक अनुबंध के लिए कानूनी समीक्षा लें।
Deletion को निर्भर सेवाओं तक पहुँचने वाली ट्रैक की गई प्रक्रिया बनाएँ
बातचीत हटाते समय उसे तुरंत अनुपलब्ध करें, provider state और निकले रिकॉर्ड के लिए idempotent deletion कतार में डालें, कैश और retrieval entry अमान्य करें और पूरा होने या दोबारा प्रयास योग्य विफलता दर्ज करें। Backup कितने समय में खत्म होंगे और निर्भर सेवा काम पूरा करे तब उपयोगकर्ता को क्या बताया जाएगा यह तय करें।
Retention setting को केवल नाम से सही न मानें
Provider retention, endpoint व्यवहार और पात्रता सुविधा के अनुसार अलग हो सकती है। मौजूदा शर्तें और endpoint setting जाँचने के लिए अलग परीक्षण परियोजना रखें; नई stateful सुविधा शुरू करने से पहले अपवाद समीक्षा करें। अपनी प्रतियों और उपयोगकर्ता को दी गई जानकारी की ज़िम्मेदारी उत्पाद की ही रहती है।
LLM बातचीत स्थिति सुरक्षा: सामान्य प्रश्न
क्या provider conversation ID उपयोगकर्ता को प्रमाणित करता है?
नहीं। वह provider स्थिति का संदर्भ है, login, टेनेंट खोज या रिकॉर्ड-स्तरीय अनुमति का विकल्प नहीं। पहले internal बातचीत रिकॉर्ड खोजकर अनुमति जाँचें।
क्या no-storage विकल्प रखने से बातचीत का सारा डेटा मिट जाता है?
ज़रूरी नहीं। वह किसी एक endpoint की भंडारण व्यवस्था बदल सकता है। ऐप database, logs, cache, backup, संलग्न फ़ाइल और provider की दूसरी सुविधाओं की अलग सूची और deletion नियंत्रण चाहिए।
AI बातचीत कितने समय तक रखनी चाहिए?
घोषित उत्पाद उद्देश्य, ग्राहक अनुबंध और लागू दायित्व पूरा करने वाली सबसे कम अवधि रखें। सबके लिए एक अवधि नहीं होती। नियम साफ़ बताएँ और उसे निकली हुई प्रतियों पर भी लागू करें।
क्या AI सारांश पूरी पुरानी बातचीत की जगह ले सकता है?
केवल तब जब काम के लिए वह उपयुक्त हो और उसकी सीमाएँ सँभाली जाएँ। सारांश तथ्य छोड़ सकता है या पुराना निर्देश रख सकता है। ज़रूरत पर स्रोत संदर्भ रखें, अनुमति लाइव प्रणाली से जाँचें और उपयोगकर्ता को संदर्भ सुधारने या साफ़ करने दें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .