लॉगिंग, ऑडिट ट्रेल आणि सिद्धता

नफा:

• कार्यक्रमाची पुनर्रचना करण्यासाठी पुरेशी किमान ऑडिट ट्रेल योजना डिझाइन करण्याची क्षमता
• प्रॉम्प्ट/प्रतिसाद मास्क करून लॉगला गळतीचा स्रोत होण्यापासून रोखण्याची क्षमता
• सहसंबंध ओळख, अपरिवर्तनीयता आणि धारणा कालावधीसह पडताळणीयोग्य लॉग स्थापित करण्याची क्षमता

एआय प्रणालीमध्ये, एक दिवस हा प्रश्न नक्कीच विचारला जाईल: "हा निर्णय अशा प्रकारे का घेतला गेला, त्या दिवशी नेमके काय झाले?" हा प्रश्न ग्राहक, ऑडिटर, नियामक किंवा न्यायालय विचारू शकतो. तुमचे उत्तर एकतर पडताळणीयोग्य ऑडिट ट्रेल असेल किंवा "आम्हाला माहित नाही." कॉर्पोरेट वातावरणात नंतरचे अस्वीकार्य आहे. या युनिटमध्ये, आम्ही AI साठी विशिष्ट काय लॉग केले पाहिजे आणि काय करू नये, ऑडिट ट्रेल कसे स्थापित करावे आणि सुरक्षितता आणि गोपनीयतेसह लॉग कसे संतुलित ठेवावे हे शिकू.

AI मध्ये लॉगिंग वेगळे का आहे?

शास्त्रीय सॉफ्टवेअरमध्ये, "कोण केले काय" लॉग केले जाते. AI मध्ये, यामध्ये तीन नवीन आयाम जोडले गेले आहेत: कोणते मॉडेल/आवृत्ती वापरली गेली, कोणता प्रॉम्प्ट पाठविला गेला आणि कोणता प्रतिसाद तयार केला गेला. जेव्हा एखादी त्रुटी किंवा तक्रार येते तेव्हा तुम्ही या तिघांशिवाय घटनेची पुनर्रचना करू शकत नाही. परंतु या अगदी तत्पर/प्रतिसादामध्ये PII असू शकतो, जसे की आम्ही युनिट 2 मध्ये पाहिले — म्हणजे लॉग स्वतः लीकचा स्रोत बनू शकतो. ही समतोल साधण्याची कला आहे.

खबरदारी: लॉगिंग करणे म्हणजे "लॉग सर्वकाही" नाही. खूप जास्त लॉगिंगमुळे गोपनीयतेचा धोका निर्माण होतो आणि खूप कमी लॉगिंगमुळे पुराव्याचा अभाव निर्माण होतो. इव्हेंटला मुखवटा लावून त्याची पुनर्रचना करण्यासाठी पुरेसा PII ठेवणे हे ध्येय आहे.

काय लॉग केले पाहिजे? ऑडिट ट्रेल स्कीमा

सॉलिड एआय ऑडिट ट्रेलमध्ये किमान हे समाविष्ट आहे:

• कोण: वापरकर्ता आयडी आणि भूमिका (किंवा सेवा आयडी).
• केव्हा: टाइमस्टॅम्प (शक्य असल्यास केवळ जोडणे).
• काय: इच्छित कृती आणि बोलावलेली साधने.
• कोणते मॉडेल: मॉडेलचे नाव आणि आवृत्ती (उदा. क्लॉड-ऑपस-4-8), तापमानासारखे गंभीर पॅरामीटर्स.
• इनपुट/आउटपुट डायजेस्ट: मुखवटा घातलेली आवृत्ती किंवा विनंती आणि प्रतिसादाचा डायजेस्ट/हॅश.
• निर्णय: त्यावर आपोआप प्रक्रिया झाली, माणसाकडे गेली, ती मंजूर झाली की नाकारली गेली?
• परिणाम: ऑपरेशन यशस्वी आहे की त्रुटी, कोणत्या संसाधनावर परिणाम होतो?

स्टेप बाय स्टेप: ऑडिट ट्रेलची स्थापना

1. ध्येय निश्चित करा. या नोंदी कोण वाचणार आणि का? (घटना प्रतिसाद, अनुपालन लेखापरीक्षण, डीबगिंग.) उद्देश तुम्ही काय ठेवता ते ठरवते.
2. PII धोरण लागू करा. लॉगिंग करण्यापूर्वी प्रॉम्प्ट/प्रतिसाद मास्क करा (युनिट 2).
3. अपरिवर्तनीयता प्रदान करा. क्रिटिकल लॉग्स फक्त जोडू द्या; कोणीही भूतकाळ शांतपणे पुसून टाकू नये.
4. धारणा कालावधी परिभाषित करा. कायदेशीर आवश्यकता आणि गोपनीयतेच्या संतुलनानुसार कालावधी निश्चित करा; वेळ संपल्यावर आपोआप हटवा.
5. प्रवेश मर्यादित करा. लॉगचा प्रवेश देखील RBAC सह संरक्षित केला पाहिजे; लॉग वाचन देखील लॉग केले पाहिजे.
6. सहसंबंध आयडी (ट्रेस आयडी) जोडा. विनंतीचे सर्व टप्पे (इनपुट, टूल कॉल, पडताळणी, आउटपुट) एकाच ओळखीने कनेक्ट करा.

चार कॉपी करण्यायोग्य टेम्पलेट्स

ऑडिट लॉग स्कीमा (JSON):

{ "trace_id": "...", "time": "YYYY-MM-DDThh:mm:ssZ", "वापरकर्ता": "...", "भूमिका": "...", "मॉडेल": "क्लॉड-ऑपस-4-8", "मापदंड": { "तापमान": 0 }, "request_summary": "Summary>", "summary>", "summary>" "tools": ["tool_a", "tool_b"], "decision": "auto|human_approval", "approval": "approved|rejected| none", "result": "यशस्वी|त्रुटी", "प्रभावित_संसाधन": "..."}

लॉग पीआयआय नियंत्रण प्रॉम्प्ट:

खालील लॉग उदाहरणे पहा. ऑडिट ट्रेलसाठी आवश्यक फील्ड (कोण, कधी, मॉडेल, निर्णय, निकाल) पूर्ण आहेत का? कच्चा PII देखील लीक झाला आहे का? प्रत्येक पंक्तीसाठी, म्हणून अहवाल द्या: "पुरेशी नाही / जागा गहाळ आहे: ... /PII गळती: ..." <logs>{{ उदाहरणे }}</logs>

इव्हेंट रीबिल्ड प्रॉम्प्ट:

खालील ऑडिट रेकॉर्ड एकाच ट्रेस_आयडीशी संबंधित आहेत. इव्हेंटला कालक्रमानुसार वर्णनात रूपांतरित करा: वापरकर्त्याला काय हवे होते, मॉडेलने काय केले, कोणती प्रमाणीकरणे झाली, निर्णय कसा घेतला गेला, त्याचा परिणाम काय झाला? ध्वजांकित गहाळ किंवा विसंगत पायऱ्या.<records>{{ trace_registers }}</records>

धारणा धोरण निर्णय नियम:

प्रत्येक लॉग प्रकारासाठी, निश्चित करा:- कायदेशीर धारणा बंधन आहे का? (असल्यास किमान कालावधी)- त्यात PII आहे का? (समाविष्ट असल्यास, कालावधी कमी करा, प्रवेश कमी करा)- सुरक्षा घटनेचा पुरावा? (स्टोअर बदलता येत नाही) परिणाम: "स्टोअर N दिवस + फक्त-जोडलेले mi + प्रवेश स्तर".

कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट

गरीब दृष्टीकोन

मजबूत दृष्टीकोन

अजिबात लॉगिंग नाही ("आवश्यक नाही")

इव्हेंटची पुनर्रचना करण्यासाठी किमान सेट लॉग करत आहे

रॉ प्रॉम्प्ट/प्रतिसाद जसे आहे तसे लॉग करत आहे

मुखवटा केलेला सारांश + ट्रेस आयडी लॉगिंग

लॉग अमर्यादित साठवा

कायदेशीर + गोपनीयता संतुलनासह धारणा कालावधी

कोणीही लॉग हटवू शकतो

क्रिटिकल लॉग हे केवळ जोडलेले आहेत, प्रवेश नियंत्रित आहेत

तीन मिनी केसेस

केस 1 — ट्रेस आयडीने एक दिवसाचा तपास 15 मिनिटांपर्यंत कमी केला. "माझा अर्ज अयोग्यरित्या नाकारण्यात आला," एका ग्राहकाने बँकेच्या क्रेडिट पूर्व-मूल्यांकन सहाय्यकाला सांगितले. सहसंबंध आयडीबद्दल धन्यवाद, संघाने त्या अर्जाचे इनपुट, कर्मचारी पडताळणी आणि निर्णय 15 मिनिटांत पुनर्रचना केली; नियम प्रमाणीकरणामध्ये चुकीच्या थ्रेशोल्डमुळे त्रुटी उद्भवली असल्याचे दाखवले आणि त्याचे निराकरण केले.

प्रकरण 2 - लेखापरीक्षणात अतिप्रमाणात लॉगिंग आढळून आले. एक ई-कॉमर्स कंपनी डीबगिंगसाठी रॉ लॉगवर सर्व प्रॉम्प्ट/प्रतिसाद लिहित होती. वार्षिक लेखापरीक्षणादरम्यान, असे दिसून आले की या नोंदींमध्ये ग्राहकांचे पत्ते आणि दूरध्वनी क्रमांक होते आणि ते 2 वर्षांसाठी ठेवण्यात आले होते. मास्किंग + 90-दिवस धारणा धोरणावर स्विच करून शोध बंद केला गेला; ऑडिट ट्रेल फंक्शन जतन केले गेले.

प्रकरण 3 - केवळ जोडलेल्या लॉगमध्ये अंतर्गत गैरवर्तन उघड झाले. एका प्रदात्याच्या कर्मचाऱ्याने त्याने बनवलेले चुकीचे बॅच लपवण्यासाठी लॉग हटविण्याचा प्रयत्न केला. नोंदी केवळ जोडण्यासाठी आहेत आणि लॉग वाचन/हटवण्याचे प्रयत्न रेकॉर्ड केले गेले आहेत, प्रयत्न त्वरित दृश्यमान होता; या घटनेमुळे शिस्तभंग आणि प्रक्रिया दुरुस्ती झाली.

टीप: प्रत्येक विनंतीला एक सहसंबंध आयडी (ट्रेस आयडी) नियुक्त करा आणि सर्व पायऱ्यांमधून पुढे जा. जेव्हा एखादी समस्या उद्भवते, तेव्हा "त्या विनंतीबद्दल सर्व काही" एकाच क्वेरीसह संकलित करण्यात सक्षम असणे हा घटना प्रतिसादाचा सर्वात मोठा प्रवेगक आहे.

सामान्य चुका

• अजिबात लॉगिंग करत नाही किंवा इतके कमी लॉगिंग करत नाही की तुम्ही इव्हेंटची पुनर्रचना करू शकत नाही.
• कच्ची विनंती/प्रतिसाद मास्कशिवाय लॉग करणे आणि लॉगला गळतीच्या स्त्रोतामध्ये बदलणे.
• मॉडेलचे नाव/आवृत्ती आणि निर्णय (स्वयंचलित/मानवी) लॉगिंग करत नाही.
• अमर्यादित कालावधीसाठी लॉग संग्रहित केल्याने गोपनीयतेचा धोका वाढतो.
• बदलाच्या अधीन गंभीर नोंदी सोडणे; लॉग प्रवेश लॉगिंग नाही.
• स्टेप्स एकत्र जोडण्यास सक्षम नाही कारण ते सहसंबंध आयडी (ट्रेस आयडी) वापरत नाही.

सारांशात

• एआय लॉगिंग "कोणी काय केले" मध्ये तीन आयाम जोडते: कोणते मॉडेल/आवृत्ती, कोणता प्रॉम्प्ट, कोणता प्रतिसाद.
• इव्हेंटला मुखवटा घालून पुनर्रचना करण्यासाठी PII कमीत कमी ठेवण्याचे ध्येय आहे—अधिक नाही, कमी नाही.
• ऑडिट ट्रेलमध्ये कोण/केव्हा/काय/कोणते मॉडेल/निर्णय/परिणाम फील्ड समाविष्ट असावेत.
• क्रिटिकल लॉग केवळ जोडलेले असावेत, प्रवेश मर्यादित असावा आणि लॉग प्रवेश देखील लॉग केलेला असावा.
• सहसंबंध आयडी (ट्रेस आयडी) विनंतीच्या सर्व चरणांना जोडतो आणि घटनेच्या तपासाला गती देतो.

अर्ज कार्य

तुमच्या स्वत:च्या एआय फ्लोमधून विनंती निवडा आणि वरील JSON स्कीमासह त्यासाठी आदर्श ऑडिट ट्रेल लिहा. नंतर दोन चाचण्या करा: (१) तुम्ही फक्त या रेकॉर्डिंगसह कथा सुरुवातीपासून शेवटपर्यंत सांगू शकता का? (2) रेकॉर्डमध्ये कच्चा PII आहे का? फील्ड गहाळ असल्यास, ते जोडा, PII असल्यास, ते मास्क करा. शेवटी, एक धारणा कालावधी आणि प्रवेश स्तर सेट करा.

चेकलिस्ट

• [] ऑडिट ट्रेलमध्ये कोण/केव्हा/काय/पॅटर्न/निर्णय/परिणाम फील्ड समाविष्ट आहेत.
• [ ] प्रॉम्प्ट/प्रतिसाद लॉगच्या आधी मुखवटा घातलेला असतो (पीआयआय नाही).
• प्रत्येक विनंतीला एक सहसंबंध आयडी (ट्रेस आयडी) नियुक्त केला जातो.
• [ ] क्रिटिकल लॉग हे फक्त जोडलेले आहेत आणि प्रवेश नियंत्रित आहेत.
• स्टोरेज कालावधी कायदेशीर + गोपनीयता शिल्लक द्वारे परिभाषित केला जातो आणि कालावधीच्या शेवटी हटविला जातो.
• लॉगसह मी 30 मिनिटांपेक्षा कमी वेळेत इव्हेंटची पुनर्रचना करू शकतो.