SaaS में AI audit trail और output provenance: क्या दर्ज करें
AI output का रास्ता, लागू policy और source versions तथा उसके बाद हुए actions का privacy-conscious record बनाएँ; हर customer prompt को default रूप से log न करें।
इस मार्गदर्शिका में
AI audit trail में क्या दर्ज होना चाहिए?
AI audit trail से अधिकृत reviewer request से output और action तक का जरूरी रास्ता समझ सके: कौन-सा tenant और actor दायरे में था, कौन-से system versions चले, कौन-से sources और policy decisions लागू थे तथा आगे क्या हुआ। यह traceability record है; इससे उत्तर सही सिद्ध नहीं होता और stochastic model को हूबहू दोबारा चलाने की गारंटी नहीं मिलती। NIST GenAI risk management में documentation और provenance पर जोर देता है; OpenTelemetry GenAI conventions telemetry के साझा नाम देते हैं।
Stable identifiers और configuration versions दर्ज करें
Request या interaction ID, tenant reference, प्रमाणित actor या service identity, feature और workflow, provider तथा model identifier, prompt और schema revision, retrieval index या source versions, policy version और समय दर्ज करें। ऐसे identifiers रखें जो अधिकृत responder को systems के बीच record जोड़ने दें, पर हर event में नाम, email या raw content न डालें।
Workflow समझाने वाले decisions और outcomes दर्ज करें
दर्ज करें कि content retrieve हुआ या नहीं, permission check पास हुआ, moderation या policy control चला, इंसान ने action मंजूर किया, tool invoke हुआ, request असफल रही या परिणाम सुधारा गया। जहाँ उपयोगी हो status, error category और downstream action reference रखें। घटनाओं का अर्थपूर्ण क्रम बचाएँ और एक logical user request को provider retry attempts से अलग दिखाएँ।
Answer citation को जाँचे जा सकने वाले source version से जोड़ें
Retrieval से मिले source identifiers और passage location के साथ document version और access scope रखें। User को translation या summary दिखे तो source भाषा और मूल सामग्री तक link बचाएँ। केवल इसलिए citation दर्ज न करें कि model ने संदर्भ जैसा कुछ बना दिया; वही capture करें जो retrieval ने वास्तव में लौटाया था।
| Event और उद्देश्य | ज़रूरी identifiers | हटाए गए sensitive fields | पहुँच और retention | Integrity और query test |
|---|---|---|---|---|
| Request पूरी हुई | ||||
| Human approval या denial | ||||
| Policy block या correction |
AI logs को उपयोगी और निजी कैसे रखें?
Raw prompt और answer अपने आप न इकट्ठा करें
Prompts, model outputs, retrieved passages और tool arguments में personal, confidential या security-sensitive जानकारी हो सकती है। पहले identifiers, versions, outcomes और error categories को प्राथमिकता दें। Defined support या safety उद्देश्य से content रखना जरूरी हो तो users को उचित सूचना दें, संभव हो तो redact करें, पहुँच सीमित रखें और deletion की तय अवधि रखें।
Storage और investigation tools में tenant सीमा लागू करें
हर event को server-verified tenant से जोड़ें और search, export तथा support access पर product वाली authorization policy लागू करें। अंदाज़े से दिए request IDs, bulk exports, shared dashboards और incident tools में cross-tenant exposure जाँचें। Logs को unauthorized बदलाव से बचाएँ और audit के उद्देश्य के अनुसार integrity evidence रखें।
Retention, deletion और access review तय करें
Events को उतने समय तक रखें जितना लिखित operational, security, customer और legal उद्देश्य माँगता है। Telemetry retention को स्वीकृत content-review store से अलग रखें और replicas तथा exports में deletion का व्यवहार स्पष्ट करें। Privileged access की समीक्षा करें, sensitive records तक पहुँच audit करें और deletion process test करें; केवल dashboard setting को पूरी सफाई का प्रमाण न मानें।
Review या incident में AI trace का उपयोग कैसे करें?
Content surveillance बनाए बिना records खोजने योग्य रखें
समय, tenant, feature version, status और correlation ID से query की सुविधा दें। Metrics में कम-विविधता वाले operational fields रखें और sensitive identifiers को metric labels से बाहर रखें। OpenTelemetry conventions interoperability बढ़ा सकते हैं, लेकिन वे आपकी retention policy तय नहीं करते और prompt या response log करना सुरक्षित नहीं बनाते।
Reproducibility का दावा सटीक रखें
Versioned trace बता सकती है कि कौन-सा configuration और प्रमाण इस्तेमाल हुआ और failure की जाँच में मदद कर सकती है। इससे provider का ठीक वही उत्तर हमेशा वापस नहीं मिलता, क्योंकि hosted model, sampling, provider बदलाव और बाहरी data बदल सकते हैं। Repeatable test के लिए controlled evaluation fixtures और redacted evidence रखें।
Audit path को product feature की तरह test करें
सफल, refused, timeout, retry, human-approved और denied requests पर expected events जाँचें। Confirm करें कि source references असली retrieved documents की ओर हैं, policy versions दर्ज हैं और tenant query केवल authorized events लौटाती है। महत्वपूर्ण action के लिए audit event गायब हो तो alert दें और बताएँ कि जाँच कौन करेगा।
AI audit trail और provenance: आम सवाल
क्या SaaS को हर prompt और AI answer audit log में सहेजना चाहिए?
डिफ़ॉल्ट रूप से नहीं। Content में संवेदनशील data हो सकता है। पहले identifiers, configuration versions, policy decisions, source references और outcomes रखें; content केवल स्पष्ट उद्देश्य तथा उचित सूचना, पहुँच और retention के साथ लें।
क्या trace साबित करती है कि AI answer सही था?
नहीं। Trace रास्ता और प्रमाण समझाती है। सही होने और citation का समर्थन जाँचने के लिए sources और output अलग से review करें।
क्या audit trail ठीक वही model response फिर चला सकती है?
जरूरी नहीं। यह जाँच के लिए versions और inputs दर्ज कर सकती है, लेकिन provider behavior और generation बदल सकते हैं। दोहराए जा सकने वाले regression tests के लिए controlled fixtures उपयोग करें।
क्या OpenTelemetry conventions compliance checklist हैं?
नहीं। वे interoperability के लिए telemetry की साझा शब्दावली बनाते हैं। Event का उद्देश्य, access, privacy, integrity और retention आपका संगठन तय करता है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .
- OpenTelemetry GenAI Semantic Conventions
- OWASP Cheat Sheet: logging
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- Your data and model usage policies by endpoint
- SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- OWASP API Security Top 10: API1:2023 Broken Object Level Authorization
- Evaluation best practices