SaaS teams के लिए Generative AI incident response playbook
हानिकारक AI output, data exposure, unsafe tool action और provider failure को जिम्मेदार owner, सीमित containment, privacy-aware प्रमाण, user सहायता और जाँची हुई recovery से संभालें।
इस मार्गदर्शिका में
Generative AI incident किसे मानें?
AI incident वह घटना है जिसमें AI workflow ने नुकसान किया या बढ़ाया हो, जानकारी उजागर की हो, authorization सीमा तोड़ी हो, unsafe action लिया हो या users को अपेक्षित सेवा न दी हो। Security incident को quality defect, user complaint या availability issue से अलग पहचानें, पर एक ही घटना कई श्रेणियों में आ सकती है। NIST SP 800-61 Rev. 3 मौजूदा cybersecurity incident-response मार्गदर्शन देता है; NIST GenAI Profile incident disclosure और governance पर अलग से विचार करता है।
Report होने वाली घटनाएँ और severity तय करें
Cross-tenant retrieval, संवेदनशील output exposure, malicious tool call, harmful advice, प्रमाण-विहीन high-impact उत्तर, moderation bypass, किसी भाषा में बार-बार विफलता और provider outage या compromise शामिल करें। Severity वास्तविक और संभावित असर, दायरे, reversibility और तात्कालिकता से तय करें। कम असर वाली सामान्य quality समस्या को correction workflow में रखें, जब तक प्रमाण उसे गंभीर न बनाए।
Response roles और निर्णय का अधिकार तय करें
Incident lead, product या engineering owner, security और privacy संपर्क, support lead तथा route या tool बंद करने के अधिकृत व्यक्ति तय करें। लिखें कि एक tenant को कौन अलग कर सकता है, credentials revoke कर सकता है, queued action रोक सकता है, provider से संपर्क कर सकता है और restore मंजूर कर सकता है। After-hours escalation रास्ता प्रभावित feature या model पर निर्भर न हो।
Dependencies और containment के बिंदु पहले से दर्ज करें
Model endpoint, prompts, retrieval indexes, connectors, tools, user-facing screens, queues, caches और downstream side effects सूचीबद्ध करें। किसी खास capability को बंद करना, source रोकना, job रोकना या safe route पर जाना पहले जाँचें। जहाँ संभव हो credentials और runbook तक पहुँच प्रभावित component से स्वतंत्र रखें।
| संकेत और संभावित नुकसान | Severity और प्रभावित दायरा | Containment owner | प्रमाण और privacy सीमा | Recovery test और सूचना |
|---|---|---|---|---|
Responders को AI incident कैसे contain करना चाहिए?
पहले लोगों की सुरक्षा करें और unsafe रास्ता रोकें
तत्काल user impact जाँचें और जरूरत पर human contact या alternate service दें। सबसे सीमित प्रभावी feature, tool, connector, provider route या tenant capability बंद करें; pending jobs रद्द करें और retry को वही unsafe path फिर शुरू करने से रोकें। Scope अज्ञात हो, containment न चले या नुकसान व्यापक हो तो जाँच के दौरान tested global stop उपयोग करें।
दूसरा privacy incident बनाए बिना प्रमाण रखें
समय, प्रभावित tenant references, model और prompt versions, policy decisions, source identifiers, action outcomes और request IDs दर्ज करें। जाँच के लिए जरूरी prompt या output तक पहुँच सीमित करें, असंबंधित personal data हटाएँ और स्वीकृत retention तथा legal-hold प्रक्रिया अपनाएँ। Sensitive प्रमाण को public issue tracker या shared prompt में न डालें।
Product, security, privacy और customer response जोड़ें
एक incident record और decision log रखें ताकि सबको समान scope और स्थिति मिले। Customer को सूचना देने से पहले तथ्य की पुष्टि करें; असर और अगले कदम सरल भाषा में बताएं। Notification की जिम्मेदारी लागू कानून, contract और counsel से जाँचें; generic AI runbook से तय न करें। Provider से स्वीकृत रास्ते से तथ्य माँगें और जरूरत से अधिक customer data साझा न करें।
AI incident के बाद service और सीख कैसे बहाल करें?
सही layer पर root cause जाँचें
देखें कि कारण model behavior, prompt change, poisoned या पुराना data, retrieval permissions, unsafe tool, application code, provider बदलाव या UI की धारणा थी। पूरी request और side effects देखे बिना model को दोष न दें। प्रमाण मिलने तक hypotheses को अपुष्ट मानें।
Controls पास होने पर ही service लौटाएँ
Trigger case और मिलते-जुलते cases पर fix जाँचें, authorization तथा privacy boundaries verify करें, बाहरी side effects का हिसाब मिलाएँ और सीमित rollout देखें। Rollback उपलब्ध रखें। Postmortem में असर, timeline, detection gap, root cause, actions, owners और due dates लिखें; customer की संवेदनशील सामग्री उजागर न करें।
वास्तविक scenarios से playbook का अभ्यास करें
Cross-tenant citation, unsafe tool call, privacy complaint, सांस्कृतिक रूप से नुकसानदेह उत्तर और provider outage पर tabletop exercise करें। Support staff तथा निर्णयकर्ताओं को शामिल करें, feature stop और customer communication जाँचें, और exercise में मिली कमियाँ बंद करें। Product या संगठन बदलने पर severity और escalation contacts अपडेट करें।
Generative AI incident response: आम सवाल
क्या हर गलत AI answer security incident है?
नहीं। कम प्रभाव वाली quality समस्या feedback और correction प्रक्रिया में जा सकती है। असर, scope, privacy exposure, authorization failure या unsafe action आपके incident मानदंड पूरा करे तो escalate करें।
क्या responders को पूरा AI product बंद कर देना चाहिए?
सबसे सीमित tested containment अपनाएँ जो नुकसान रोक दे। Scope अज्ञात हो, containment न चले या कई रास्ते प्रभावित हो सकते हों तो व्यापक stop सही हो सकता है।
क्या incident runbook को हर prompt और answer सहेजना चाहिए?
डिफ़ॉल्ट रूप से नहीं। जाँच के लिए न्यूनतम प्रमाण रखें, पहुँच सीमित करें और जरूरत पर sensitive content के लिए अलग स्वीकृत रास्ता अपनाएँ।
क्या यह playbook कानूनी notification तय करता है?
नहीं। सूचना देने की जिम्मेदारी घटना, jurisdiction, data और contract पर निर्भर है। योग्य legal और privacy reviewers को जल्दी शामिल करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .
- SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- Safety best practices
- LLM04:2025 Data and Model Poisoning
- OWASP Cheat Sheet: logging
- Your data and model usage policies by endpoint
- Evaluation best practices