લોગીંગ, ઓડિટ ટ્રેઇલ અને સાબિતી

નફો:

• ઇવેન્ટનું પુનર્નિર્માણ કરવા માટે પૂરતી ન્યૂનતમ ઓડિટ ટ્રેઇલ સ્કીમ ડિઝાઇન કરવાની ક્ષમતા
• પ્રોમ્પ્ટ/પ્રતિસાદને માસ્ક કરીને લોગને લીકેજના સ્ત્રોત બનતા અટકાવવાની ક્ષમતા
• સહસંબંધ ઓળખ, અપરિવર્તનક્ષમતા અને રીટેન્શન અવધિ સાથે ચકાસી શકાય તેવા લૉગ્સ સ્થાપિત કરવાની ક્ષમતા

એઆઈ સિસ્ટમમાં, એક દિવસ ચોક્કસ પ્રશ્ન પૂછવામાં આવશે: "આ નિર્ણય આ રીતે શા માટે લેવામાં આવ્યો, તે દિવસે બરાબર શું થયું?" આ પ્રશ્ન ગ્રાહક, ઓડિટર, નિયમનકાર અથવા કોર્ટ દ્વારા પૂછવામાં આવી શકે છે. તમારો જવાબ કાં તો ચકાસી શકાય તેવું ઓડિટ ટ્રેલ હશે અથવા "અમને ખબર નથી." કોર્પોરેટ વાતાવરણમાં બાદમાં અસ્વીકાર્ય છે. આ એકમમાં, અમે શીખીશું કે AI માટે વિશિષ્ટ રીતે શું લૉગ કરવું જોઈએ અને શું ન કરવું જોઈએ, ઑડિટ ટ્રેલ કેવી રીતે સ્થાપિત કરવું અને સુરક્ષા અને ગોપનીયતા સાથે લૉગને કેવી રીતે સંતુલિત રાખવું.

AI માં લોગિંગ શા માટે અલગ છે?

ક્લાસિકલ સોફ્ટવેરમાં, "who did what" લોગ થયેલ છે. AI માં, આમાં ત્રણ નવા પરિમાણો ઉમેરવામાં આવ્યા છે: કયા મોડલ/સંસ્કરણનો ઉપયોગ કરવામાં આવ્યો હતો, કયો પ્રોમ્પ્ટ મોકલવામાં આવ્યો હતો અને કયો પ્રતિસાદ આપવામાં આવ્યો હતો. જ્યારે કોઈ ભૂલ અથવા ફરિયાદ થાય છે, ત્યારે તમે આ ત્રણ વિના ઘટનાનું પુનર્નિર્માણ કરી શકતા નથી. પરંતુ આ ખૂબ જ પ્રોમ્પ્ટ/પ્રતિસાદમાં PII હોઈ શકે છે, જેમ કે આપણે યુનિટ 2 માં જોયું છે — એટલે કે લોગ પોતે જ લીકનો સ્ત્રોત બની શકે છે. આ સંતુલનની કળા છે.

સાવધાન: લોગિંગ એ "લોગ એવરીંગ" નથી. વધુ પડતું લોગીંગ ગોપનીયતાનું જોખમ ઉભું કરે છે, અને બહુ ઓછું લોગીંગ પુરાવાનો અભાવ બનાવે છે. ધ્યેય એ છે કે ઇવેન્ટને માસ્ક કરીને પુનઃનિર્માણ કરવા માટે પૂરતી PII રાખવાનો છે.

શું લૉગ કરવું જોઈએ? ઓડિટ ટ્રેઇલ સ્કીમા

એક નક્કર AI ઓડિટ ટ્રેઇલમાં ઓછામાં ઓછા સમાવેશ થાય છે:

• કોણ: વપરાશકર્તા ID અને ભૂમિકા (અથવા સેવા ID).
• ક્યારે: ટાઈમસ્ટેમ્પ (જો શક્ય હોય તો જ ઉમેરો).
• શું: ઇચ્છિત ક્રિયા અને સમન્સ સાધનો.
• કયું મોડેલ: મોડેલનું નામ અને સંસ્કરણ (દા.ત. ક્લાઉડ-ઓપસ-4-8), તાપમાન જેવા જટિલ પરિમાણો.
• ઇનપુટ/આઉટપુટ ડાયજેસ્ટ: માસ્ક કરેલ સંસ્કરણ અથવા વિનંતી અને પ્રતિસાદનું ડાયજેસ્ટ/હેશ.
• નિર્ણય: શું તે આપમેળે પ્રક્રિયા કરવામાં આવ્યું હતું, માનવમાં ગયું હતું, શું તે મંજૂર હતું કે નકારવામાં આવ્યું હતું?
• પરિણામ: શું ઓપરેશન સફળ છે કે ભૂલ, કયા સંસાધનને અસર થાય છે?

સ્ટેપ બાય સ્ટેપ: ઓડિટ ટ્રેઇલની સ્થાપના

1. એક ધ્યેય નક્કી કરો. આ લોગ કોણ વાંચશે અને શા માટે? (ઘટના પ્રતિભાવ, અનુપાલન ઓડિટીંગ, ડીબગીંગ.) હેતુ નક્કી કરે છે કે તમે શું રાખો છો.
2. PII નીતિ લાગુ કરો. લોગીંગ કરતા પહેલા પ્રોમ્પ્ટ/પ્રતિસાદને માસ્ક કરો (યુનિટ 2).
3. અપરિવર્તનશીલતા પ્રદાન કરો. જટિલ લોગને ફક્ત-જોડવા દો; કોઈએ ભૂતકાળને ચૂપચાપ ભૂંસી નાખવો જોઈએ નહીં.
4. રીટેન્શન અવધિ વ્યાખ્યાયિત કરો. કાનૂની જરૂરિયાત અને ગોપનીયતાના સંતુલન અનુસાર સમયગાળો નક્કી કરો; જ્યારે સમય સમાપ્ત થાય ત્યારે આપમેળે કાઢી નાખો.
5. ઍક્સેસ મર્યાદિત કરો. લૉગની ઍક્સેસ પણ RBAC સાથે સુરક્ષિત હોવી જોઈએ; લોગ રીડિંગ પણ લોગ થયેલ હોવું જોઈએ.
6. સહસંબંધ ID (ટ્રેસ ID) ઉમેરો. વિનંતીના તમામ પગલાં (ઇનપુટ, ટૂલ કૉલ, વેરિફિકેશન, આઉટપુટ)ને એક જ ઓળખ સાથે જોડો.

ચાર નકલ કરી શકાય તેવા નમૂનાઓ

ઓડિટ લોગ સ્કીમા (JSON):

{ "trace_id": "...", "સમય": "YYYY-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary": "Skmary>": "Summary>", "summary>" "tools": ["tool_a", "tool_b"], "decision": "auto|human_approval", "approval": "approved|rejected|none", "પરિણામ": "સફળતા|ભૂલ", "અસરગ્રસ્ત_સંસાધન": "..."}

લોગ PII નિયંત્રણ પ્રોમ્પ્ટ:

નીચેના લોગ ઉદાહરણો તપાસો. શું ઓડિટ ટ્રેઇલ (કોણ, ક્યારે, મોડેલ, નિર્ણય, પરિણામ) માટે જરૂરી ક્ષેત્રો પૂર્ણ છે? શું કાચો PII પણ લીક થયો છે? દરેક પંક્તિ માટે, આ રીતે જાણ કરો: "પર્યાપ્ત નથી / જગ્યા ખૂટે છે: ... /PII લીક: ..." <logs>{{ ઉદાહરણો }}</logs>

ઇવેન્ટ રીબિલ્ડ પ્રોમ્પ્ટ:

નીચેના ઓડિટ રેકોર્ડ્સ એકલ ટ્રેસ_આઈડીના છે. ઘટનાને કાલક્રમિક ક્રમમાં વર્ણનમાં ફેરવો: વપરાશકર્તાને શું જોઈએ છે, મોડેલે શું કર્યું, કઈ માન્યતાઓ ચાલી, નિર્ણય કેવી રીતે લેવામાં આવ્યો, પરિણામ શું આવ્યું? ફ્લેગ ગુમ અથવા અસંગત પગલાં.<records>{{ trace_registers }}</records>

રીટેન્શન પોલિસી નિર્ણય નિયમ:

દરેક લોગ પ્રકાર માટે, નિર્ધારિત કરો:- શું કાનૂની જાળવણીની જવાબદારી છે? (લઘુત્તમ સમયગાળો જો કોઈ હોય તો)- શું તેમાં PII છે? (જો સમાવિષ્ટ હોય, તો સમયગાળો ટૂંકો કરો, પ્રવેશને સાંકડો કરો)- સુરક્ષા ઘટનાના પુરાવા? (સ્ટોર બદલી શકાતું નથી)પરિણામ: "સ્ટોર N દિવસો + ફક્ત-માત્ર mi + એક્સેસ લેવલ" એપેન્ડ કરો.

નબળા પ્રોમ્પ્ટ / મજબૂત પ્રોમ્પ્ટ

નબળી અભિગમ

મજબૂત અભિગમ

બિલકુલ લોગીંગ નથી ("જરૂર નથી")

ઇવેન્ટનું પુનર્નિર્માણ કરવા માટે ન્યૂનતમ સેટને લૉગ કરી રહ્યાં છીએ

કાચા પ્રોમ્પ્ટ/પ્રતિસાદને જેમ છે તેમ લોગ કરી રહ્યું છે

માસ્ક કરેલ સારાંશ + ટ્રેસ ID લોગીંગ

અમર્યાદિત રીતે લોગ સ્ટોર કરો

કાનૂની + ગોપનીયતાના સંતુલન સાથે રીટેન્શન અવધિ

કોઈપણ લોગ કાઢી શકે છે

ક્રિટિકલ લૉગ્સ ફક્ત જોડવા માટે છે, ઍક્સેસ નિયંત્રિત છે

ત્રણ મિની કેસ

કેસ 1 - ટ્રેસ આઈડીએ એક દિવસની તપાસ ઘટાડીને 15 મિનિટ કરી. "મારી અરજી અયોગ્ય રીતે નકારી કાઢવામાં આવી હતી," એક ગ્રાહકે બેંકના ક્રેડિટ પૂર્વ મૂલ્યાંકન સહાયકને કહ્યું. સહસંબંધ ID માટે આભાર, ટીમે 15 મિનિટમાં તે એપ્લિકેશનના ઇનપુટ, કર્મચારીની ચકાસણી અને નિર્ણયનું પુનઃનિર્માણ કર્યું; દર્શાવે છે કે ભૂલ નિયમ માન્યતામાં ખોટી થ્રેશોલ્ડને કારણે થઈ હતી અને તેને સુધારી હતી.

કેસ 2 - ઓડિટમાં વધુ પડતી લોગીંગ મળી આવી હતી. એક ઈ-કોમર્સ કંપની ડીબગીંગ માટે કાચા લોગ પર તમામ સંકેતો/પ્રતિસાદો લખી રહી હતી. વાર્ષિક ઓડિટ દરમિયાન, એવું જોવામાં આવ્યું હતું કે આ લોગમાં ગ્રાહકના સરનામા અને ટેલિફોન નંબરો હતા અને તેને 2 વર્ષ માટે રાખવામાં આવ્યા હતા. માસ્કિંગ + 90-દિવસ રીટેન્શન પોલિસી પર સ્વિચ કરીને શોધ બંધ કરવામાં આવી હતી; ઓડિટ ટ્રેઇલ ફંક્શન સાચવવામાં આવ્યું હતું.

કેસ 3 - ફક્ત-એન્ડ-લોગમાં આંતરિક દુરુપયોગ જાહેર થયો. એક પ્રદાતાના કર્મચારીએ તેણે બનાવેલી ભૂલભરેલી બેચને છુપાવવા માટે લોગ કાઢી નાખવાનો પ્રયાસ કર્યો. લોગ્સ ફક્ત જોડવા માટેના હોવાથી અને લોગ વાંચવા/કાઢી નાખવાના પ્રયાસો રેકોર્ડ કરવામાં આવ્યા હોવાથી, પ્રયાસ તરત જ દૃશ્યમાન હતો; આ ઘટના શિસ્ત અને પ્રક્રિયા સુધારણામાં પરિણમી.

ટીપ: દરેક વિનંતિ માટે એક સહસંબંધ ID (ટ્રેસ ID) સોંપો અને તેને તમામ પગલાંઓ સુધી લઈ જાઓ. જ્યારે કોઈ સમસ્યા આવે છે, ત્યારે એક જ ક્વેરી સાથે "તે વિનંતી વિશે બધું" એકત્રિત કરવામાં સક્ષમ થવું એ ઘટના પ્રતિસાદનું સૌથી મોટું પ્રવેગક છે.

સામાન્ય ભૂલો

• બિલકુલ લોગિંગ ન કરો, અથવા એટલું ઓછું લોગિંગ કરો કે તમે ઇવેન્ટનું પુનર્નિર્માણ કરી શકતા નથી.
• કાચી વિનંતી/પ્રતિસાદને માસ્ક વિના લોગ કરવો અને લોગને લીકેજના સ્ત્રોતમાં ફેરવવું.
• મોડલનું નામ/સંસ્કરણ અને નિર્ણય લોગિંગ નથી (ઓટોમેટિક/માનવ).
• અમર્યાદિત સમય માટે લૉગ્સ સ્ટોર કરવાથી ગોપનીયતાનું જોખમ વધે છે.
• નિર્ણાયક લૉગ્સ છોડીને ફેરફારને આધીન છે; લોગ એક્સેસ લોગિંગ નથી.
• પગલાંઓને એકસાથે કનેક્ટ કરવામાં સક્ષમ નથી કારણ કે તે સહસંબંધ ID (ટ્રેસ ID) નો ઉપયોગ કરતું નથી.

સારાંશમાં

• AI લોગિંગ "કોણે શું કર્યું" માં ત્રણ પરિમાણો ઉમેરે છે: કયું મોડેલ/સંસ્કરણ, કયો પ્રોમ્પ્ટ, કયો પ્રતિસાદ.
• ધ્યેય એ છે કે PII ને માસ્ક કરીને ઇવેન્ટનું પુનઃનિર્માણ કરી શકાય તેટલું ન્યૂનતમ રાખવું - વધુ નહીં, ઓછું નહીં.
• ઓડિટ ટ્રેલમાં કોણ/ક્યારે/શું/કયું મોડેલ/નિર્ણય/પરિણામ ક્ષેત્રો શામેલ હોવા જોઈએ.
• ક્રિટિકલ લૉગ્સ ફક્ત-જોડાયેલા હોવા જોઈએ, ઍક્સેસ મર્યાદિત હોવી જોઈએ, અને લૉગ ઍક્સેસ પણ લૉગ થયેલ હોવી જોઈએ.
• સહસંબંધ ID (ટ્રેસ ID) વિનંતીના તમામ પગલાઓને જોડે છે અને ઘટનાની તપાસને ઝડપી બનાવે છે.

એપ્લિકેશન કાર્ય

તમારા પોતાના AI ફ્લોમાંથી વિનંતી પસંદ કરો અને ઉપરની JSON સ્કીમા સાથે તેના માટે આદર્શ ઓડિટ ટ્રેલ લખો. પછી બે પરીક્ષણો કરો: (1) શું તમે આ રેકોર્ડિંગ સાથે શરૂઆતથી અંત સુધી વાર્તા કહી શકો છો? (2) શું રેકોર્ડમાં કાચો PII છે? જો ત્યાં ફીલ્ડ ખૂટે છે, તો તેને ઉમેરો, જો PII હોય, તો તેને માસ્ક કરો. છેલ્લે, રીટેન્શન પીરિયડ અને એક્સેસ લેવલ સેટ કરો.

ચેકલિસ્ટ

• [ ] ઓડિટ ટ્રેલમાં કોણ/ક્યારે/શું/પેટર્ન/નિર્ણય/પરિણામ ફીલ્ડનો સમાવેશ થાય છે.
• [ ] પ્રોમ્પ્ટ/પ્રતિસાદ લોગ પહેલાં માસ્ક કરવામાં આવે છે (કોઈ PII નથી).
• દરેક વિનંતીને સહસંબંધ ID (ટ્રેસ ID) સોંપવામાં આવે છે.
• [ ] ક્રિટિકલ લૉગ્સ ફક્ત એપેન્ડ અને એક્સેસ નિયંત્રિત છે.
• સંગ્રહ સમયગાળો કાનૂની + ગોપનીયતા સંતુલન દ્વારા વ્યાખ્યાયિત કરવામાં આવે છે, અને સમયગાળાના અંતે કાઢી નાખવામાં આવે છે.
• [ ] લોગ વડે હું 30 મિનિટથી ઓછા સમયમાં ઇવેન્ટનું પુનઃનિર્માણ કરી શકું છું.