दस्तावेज़ीकरण और Auditability

जो लिखा नहीं गया, वह हुआ नहीं

Auditors, नियामक, ग्राहक और आपकी भविष्य की टीम पूछेंगे: यह system किसलिए है, किस डेटा से train हुआ या सूचित है, कैसे परखा गया, किसने मंज़ूर किया, तब से क्या बदला, और कौन-सी घटनाएँ हुईं? System cards, impact assessments, evaluation रिपोर्ट, मंज़ूरी रिकॉर्ड, परिवर्तन logs (prompt, model और डेटा versions) और घटना रिकॉर्ड ऐसी जगह रखें जहाँ से वे पुनः प्राप्त हो सकें और access-नियंत्रित हों। लक्ष्य रखें कि प्रमाण सामान्य काम के उप-उत्पाद के रूप में बनें, audit से पहले की भाग-दौड़ में नहीं।

परिवर्तन-log प्रविष्टि

छोटी, एक-सी प्रविष्टियाँ व्यवहार में बदलाव को उसके कारण तक खोजना संभव बनाती हैं।

{
  "date": "2026-09-18",
  "system": "support-assistant",
  "change": "prompt v14 -> v15; retrieval top_k 4 -> 6",
  "reason": "reduce unsupported answers on billing questions",
  "eval": {"cases": 250, "grounded_correct": "91% -> 93%", "hindi_slice": "84% -> 88%"},
  "approved_by": "AI review board (ticket GOV-212)",
  "rollback": "revert to prompt v14, top_k 4"
}

प्रमाण को निर्णयों से जोड़ें

दस्तावेज़ों का ढेर audit trail नहीं है। हर मंज़ूरी को उन evaluation नतीजों और आकलन से जोड़ें जिन पर वह टिकी थी, ताकि समीक्षक मिनटों में तर्क का पीछा कर सके।

त्वरित जाँच: दस्तावेज़ीकरण को audits के लिए उपयोगी क्या बनाता है?

• पुराने रिकॉर्ड हटाना
• एक बहुत लंबी अकेली फ़ाइल
• सिर्फ़ मौखिक सहमतियाँ
• क्या परखा, मंज़ूर हुआ और बदला, उसका जुड़ा, versioned प्रमाण