AI ऐप्लिकेशन्स को सुरक्षित करनामध्यमपाठ 1458 मिनट का पाठ

Production में AI ऐप्स की logging और monitoring

जिस चीज़ को आपने रिकॉर्ड ही नहीं किया, उसकी जांच आप नहीं कर सकते। हर AI बातचीत (interaction) से जुड़ी सही चीज़ें लॉग करें, उन logs में मौजूद पर्सनल डेटा को सुरक्षित रखें, और गलत इस्तेमाल (abuse) पर नज़र रखें।

✦ ट्यूटर से पूछें🧪 लैब · 35 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

Production में AI ऐप्स की logging और monitoring

जिस चीज़ को आपने रिकॉर्ड ही नहीं किया, उसकी जांच आप नहीं कर सकते। हर AI बातचीत (interaction) से जुड़ी सही चीज़ें लॉग करें, उन logs में मौजूद पर्सनल डेटा को सुरक्षित रखें, और गलत…

1/4
आसान शब्दों में
किसी दुकान का CCTV तभी काम आता है जब वह रिकॉर्डिंग कर रहा हो, कोई गड़बड़ी पर नज़र रख रहा हो, और पुरानी रिकॉर्डिंग समय पर हटाई जाएं ताकि वे हमेशा के लिए जमा न होती रहें।
"Watching what your agent does" वाले पाठ में बताया गया था कि agents के लिए क्या रिकॉर्ड करना चाहिए। यह पाठ production में चलने वाले किसी भी AI ऐप के बारे में है: chatbots, RAG search और AI फीचर्स। इसका मकसद घटनाओं की जांच करना, गलत इस्तेमाल को जल्दी पकड़ना, लागत को काबू में रखना और क्वालिटी सुधारना है, बिना पर्सनल डेटा का ऐसा नया भंडार बनाए जो खुद एक जोखिम बन जाए।

हर बातचीत (interaction) के लिए क्या लॉग करें

Fieldक्योंप्राइवेसी से जुड़ी सावधानी
Request id, time, feature, tenantअलग-अलग इवेंट्स को आपस में जोड़नाकम जोखिम
User id (जहाँ तक हो सके कल्पित नाम / pseudonymous)हर यूज़र के गलत इस्तेमाल और कोटा पर नज़र रखने के लिएनाम या फोन नंबर की जगह internal id इस्तेमाल करें
Model का नाम और version, prompt template versionयह जानने के लिए कि किस बदलाव से क्या हुआकम जोखिम
User input और model outputगलत इस्तेमाल और क्वालिटी की जांच के लिएपर्सनल डेटा को redact करें (हटाएं/छिपाएं); एक्सेस सीमित रखें; कम समय तक संभाल कर रखें (shorter retention)
निकाले गए स्रोत (document ids)जवाब पर किस चीज़ का असर पड़ाids लॉग करें, पूरा डॉक्यूमेंट टेक्स्ट नहीं
Tool calls, arguments और resultsसिस्टम ने असल में क्या कियासंवेदनशील arguments को redact करें
Tokens, cost, latencyDenial of wallet और परफॉरमेंसकम जोखिम
Safety signalsGuardrail blocks, refusals, canary hits, limit hitsकम जोखिम

स्टोर करने से पहले redact करें

Python: simple redaction of common Indian identifierspython
import re

PATTERNS = [
    ("EMAIL", re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")),
    ("PAN", re.compile(r"\b[A-Z]{5}[0-9]{4}[A-Z]\b")),
    # Indian mobile: optional +91, then 10 digits starting 6-9.
    # Runs before LONG_NUMBER, which would otherwise eat "+91 98..." whole.
    ("PHONE", re.compile(r"(?<!\d)(?:\+91[ -]?)?[6-9]\d{9}(?!\d)")),
    # 12 to 16 digits, spaces or dashes allowed: Aadhaar-like or card-like
    ("LONG_NUMBER", re.compile(r"(?<!\d)\d(?:[ -]?\d){11,15}(?!\d)")),
]

def redact(text: str) -> str:
    for label, pattern in PATTERNS:
        text = pattern.sub(f"[{label}]", text)
    return text
पैटर्न पर आधारित redaction आम फॉर्मेट्स को तो पकड़ लेता है, लेकिन बहुत सी चीज़ें छोड़ देता है: नाम, पते, स्वास्थ्य से जुड़ी जानकारी, शब्दों में या दूसरी लिपियों में लिखे गए नंबर। इसे सुरक्षा की सिर्फ एक परत (layer) समझें। साथ ही, यह भी सीमित करें कि कौन logs पढ़ सकता है, और पूरी बातचीत के टेक्स्ट को metadata की तुलना में कम समय तक रखें।

ऐसे signals जिन पर अलर्ट मिलना चाहिए

Signalइसका क्या मतलब हो सकता है
कोई एक अकाउंट हर दिन अपनी टोकन सीमा के करीब हो, या अचानक खर्च बहुत बढ़ जाएDenial of wallet, या कोई बॉट आपके फीचर का इस्तेमाल कर रहा है
बार-बार prompt-extraction या "ignore previous instructions" जैसे इनपुटकोई आपके ऐप की टोह ले रहा है (जांच-परख कर रहा है)
आउटपुट में आपका prompt canary दिखाई दे जाएSystem prompt लीक हो गया है
किसी एक यूज़र के लिए बहुत सारे refusals या ब्लॉक किए गए आउटपुटJailbreak की कोशिशें
अनजान domains के लिंक या इमेज वाले आउटपुटडेटा चुराने (data exfiltration) की मुमकिन कोशिश
किसी टूल का सामान्य से कहीं ज़्यादा इस्तेमाल होना, या पहली बार इस्तेमाल होनागलत इस्तेमाल, या कोई लूप
किसी दूसरे tenant के डॉक्यूमेंट्स बाहर आ जानाPermission filter की गड़बड़ी: इसे एक गंभीर घटना (incident) मानें
  1. 1

    Baseline

    कुछ हफ़्तों तक समझें कि 'सामान्य' क्या होता है: इस्तेमाल का वॉल्यूम, खर्च, refusals, टूल्स।
  2. 2

    Rules

    ऊपर दिए गए सिग्नल्स के लिए अलर्ट नियम लिखें; कई टीमें अपने SIEM और डिटेक्शन नियम शेयर करने के लिए Sigma जैसे फॉर्मेट्स का इस्तेमाल करती हैं।
  3. 3

    Route

    हर अलर्ट उस ज़िम्मेदार व्यक्ति (owner) के पास जाए जो उस फीचर को अच्छी तरह जानता हो।
  4. 4

    Runbook

    लिख कर रखें कि क्या करना है: अकाउंट ब्लॉक करना, कोई टूल बंद करना, kill switch का इस्तेमाल करना।
  5. 5

    Tune

    बेकार के शोर वाले (noisy) अलर्ट हटाएं, और हर घटना के बाद नए नियम जोड़ें।

डेटा रखने की अवधि (Retention) और नियम

Logs को सिर्फ तब तक रखें जब तक अपने काम के लिए उनकी ज़रूरत हो। भारत का Digital Personal Data Protection Act 2023 संस्थाओं से उम्मीद करता है कि वे पर्सनल डेटा की सुरक्षा करें और उसे ज़रूरत से ज़्यादा समय तक न रखें। CERT-In साइबर घटनाओं की रिपोर्टिंग और logs रखने के बारे में दिशा-निर्देश जारी करता है। अपनी लीगल और कम्प्लायंस टीम से पूछें कि आप पर कौन से नियम लागू होते हैं, और हर तरह के log के लिए retention अवधि तय करके लिखें।
सावधान रहें
AI बातचीत के logs में यूज़र्स द्वारा टाइप की गई हर चीज़ हो सकती है: पर्सनल डिटेल्स, शिकायतें, और कभी-कभी गलती से पेस्ट किए गए पासवर्ड भी। इन पर हमलावरों की नज़र रहती है। इन्हें encrypt करें, एक्सेस सीमित करें, यह ट्रैक करें कि इन्हें कौन पढ़ रहा है, और किसी भी थर्ड-पार्टी टूल में भेजने से पहले इनकी जांच करें।
करके देखें। अपने किसी जाने-पहचाने AI फीचर की एक log लाइन देखें। क्या आप बता सकते हैं कि किस model version, prompt version और किन डॉक्यूमेंट्स से वह जवाब बना था? क्या उसमें कोई ऐसा पर्सनल डेटा है जिसकी वहां ज़रूरत नहीं थी?

और देखें और पढ़ें

CERT-InGovernment of India · reading

लैब

एक log record डिज़ाइन, टेस्ट के साथ काम करने वाला एक redaction फ़ंक्शन, तीन अलर्ट नियम और एक retention टेबल।

~35 min

समस्या

Starter फ़ाइल में दिए गए फ़र्ज़ी डेटा के साथ अपने कंप्यूटर पर काम करें।

  1. Starter चलाएं। Redaction टेस्ट पास करवाएं (पैटर्न को ठीक करने या क्रम बदलने की ज़रूरत पड़ सकती है)।
  2. एक ऐसा टेस्ट खुद जोड़ें जिसे पैटर्न पकड़ नहीं पाता, और एक वाक्य में लिखें कि सिर्फ regex ही काफी क्यों नहीं है।
  3. इस पाठ से कम से कम आठ fields लेकर चैटबॉट की एक बातचीत (turn) के लिए JSON log record डिज़ाइन करें। मार्क करें कि किन fields में पर्सनल डेटा है।
  4. सादे शब्दों में तीन अलर्ट नियम लिखें: signal, threshold, किसे बताया जाए, पहला एक्शन।
  5. एक retention टेबल लिखें: full text, metadata, cost data, security alerts।

प्रैक्टिस लैब

कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।

आउटपुट

कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1Redaction पैटर्न्स का क्रम (order) मायने क्यों रख सकता है?दिखाएं

क्योंकि पहले वाला पैटर्न उस टेक्स्ट को ले सकता है जिसकी ज़रूरत बाद वाले पैटर्न को है। शुरुआती कोड में, सामान्य "long number" पैटर्न पहले चलता है और "91 9876543210" को 12 अंकों की संख्या के रूप में देखता है, जिससे एक फ़ोन नंबर को गलत लेबल मिल जाता है और एक छूटा हुआ "+" पीछे रह जाता है। ज़्यादा सटीक पैटर्न्स (जैसे देश के कोड वाला फ़ोन नंबर) को सामान्य catch-all पैटर्न्स से पहले चलाएं, और boundaries का इस्तेमाल करें ताकि कोई पैटर्न किसी बड़े नंबर के अंदर मैच न हो सके।

Q2एक जांचकर्ता को 6 महीने पहले का यूज़र का सटीक मैसेज चाहिए, लेकिन आपका full-text retention केवल 30 दिनों का है। आप प्राइवेसी और जांच दोनों को ध्यान में रखकर सिस्टम कैसे डिज़ाइन कर सकते हैं?दिखाएं

मेटाडेटा को ज़्यादा समय तक रखें: request ids, user ids, model और prompt versions, document ids, tool calls और सेफ़्टी सिग्नल्स। जब कोई अलर्ट ट्रिगर हो या कोई इंसिडेंट शुरू हो, तो उससे जुड़े पूरे रिकॉर्ड्स को एक सुरक्षित इंसिडेंट स्टोर में कॉपी कर लें, जिसका अपना अलग retention हो। ज़्यादातर जांचें मेटाडेटा से शुरू हो सकती हैं, और सबसे ज़रूरी टेक्स्ट उसी समय सुरक्षित कर लिया जाता है जब वह प्रासंगिक बनता है।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या हमें पूरे prompts और outputs को लॉग करना भी चाहिए?

अक्सर हाँ, क्योंकि इनके बिना घटनाओं की जांच करना मुश्किल होता है। लेकिन पहले redact करें, एक्सेस सीमित करें, और पूरे टेक्स्ट को metadata की तुलना में कम समय तक रखें। बहुत संवेदनशील फीचर्स के लिए, सिर्फ metadata और एक hash लॉग करने पर विचार करें, और जांच के लिए पूरा टेक्स्ट बहुत कम समय के लिए ही रखें।

हमें AI logs कब तक रखने चाहिए?

इसका कोई एक तय जवाब नहीं है। यह आपके मकसद, आपकी कानूनी जिम्मेदारियों और आपके कॉन्ट्रैक्ट्स पर निर्भर करता है। हर log टाइप के हिसाब से तय करें, इसे लिख लें, और समय पूरा होने पर अपने आप डिलीट होने दें।

क्या यूज़र्स हमसे अपनी बातचीत डिलीट करने के लिए कह सकते हैं?

प्राइवेसी कानून अक्सर लोगों को अपने डेटा पर अधिकार देते हैं, जिसमें कई मामलों में डेटा मिटाने (erasure) का अधिकार भी शामिल है। Logs को इस तरह डिज़ाइन करें कि आप किसी एक यूज़र के डेटा को ढूंढकर डिलीट कर सकें। आपकी लीगल टीम ठीक-ठीक बता सकती है कि आप पर क्या नियम लागू होते हैं।

क्या मॉडल प्रोवाइडर भी हमारे prompts अपने पास रखता है?

यह प्रोवाइडर और आपके कॉन्ट्रैक्ट या सेटिंग्स पर निर्भर करता है। उनके डेटा के इस्तेमाल और retention की शर्तें पढ़ें, और ऐसे विकल्प चुनें जो आपके डेटा के अनुकूल हों। यह आपके threat model का हिस्सा है, कोई बाद में सोचने वाली बात नहीं।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें