لاگنگ، آڈٹ ٹریل اور ثابت ہونا

فائدہ:

• ایونٹ کی تشکیل نو کے لیے کم از کم آڈٹ ٹریل اسکیم کو ڈیزائن کرنے کی صلاحیت
• پرامپٹ/جواب کو ماسک کرکے لاگ کو رساو کا ذریعہ بننے سے روکنے کی صلاحیت
• ارتباط کی شناخت، ناقابل تبدیلی اور برقرار رکھنے کی مدت کے ساتھ قابل تصدیق لاگز قائم کرنے کی صلاحیت

اے آئی سسٹم میں، ایک دن یہ سوال ضرور پوچھا جائے گا: "یہ فیصلہ اس طرح کیوں کیا گیا، اس دن اصل میں کیا ہوا؟" یہ سوال ایک صارف، ایک آڈیٹر، ایک ریگولیٹر، یا عدالت سے پوچھا جا سکتا ہے۔ آپ کا جواب یا تو قابل تصدیق آڈٹ ٹریل ہوگا یا "ہمیں نہیں معلوم"۔ مؤخر الذکر کارپوریٹ ماحول میں ناقابل قبول ہے۔ اس یونٹ میں، ہم سیکھیں گے کہ AI کے لیے مخصوص کیا لاگ ان ہونا چاہیے اور کیا نہیں، آڈٹ ٹریل کیسے قائم کیا جائے، اور لاگز کو سیکیورٹی اور رازداری کے ساتھ توازن میں کیسے رکھا جائے۔

AI میں لاگنگ مختلف کیوں ہے؟

کلاسیکی سافٹ ویئر میں، "کس نے کیا کیا" لاگ ان ہوتا ہے۔ AI میں، اس میں تین نئی جہتیں شامل کی گئی ہیں: کون سا ماڈل/ورژن استعمال کیا گیا تھا، کون سا پرامپٹ بھیجا گیا تھا، اور کیا جواب دیا گیا تھا۔ جب کوئی غلطی یا شکایت ہوتی ہے، تو آپ ان تینوں کے بغیر واقعہ کو دوبارہ نہیں بنا سکتے۔ لیکن اس فوری/جواب میں PII شامل ہو سکتا ہے، جیسا کہ ہم نے یونٹ 2 میں دیکھا — یعنی لاگ خود ہی لیک کا ذریعہ بن سکتا ہے۔ یہ توازن کا فن ہے۔

احتیاط: لاگنگ "لاگ ہر چیز" نہیں ہے۔ بہت زیادہ لاگنگ رازداری کا خطرہ پیدا کرتی ہے، اور بہت کم لاگنگ ثبوت کی کمی پیدا کرتی ہے۔ مقصد یہ ہے کہ PII کو ماسک کر کے ایونٹ کی تشکیل نو کے لیے کافی رکھیں۔

کیا لاگ ان ہونا چاہئے؟ آڈٹ ٹریل سکیما

ایک ٹھوس AI آڈٹ ٹریل میں کم از کم شامل ہیں:

• کون: یوزر آئی ڈی اور رول (یا سروس آئی ڈی)۔
• کب: ٹائم اسٹیمپ (صرف اگر ممکن ہو تو)۔
• کیا: مطلوبہ کارروائی اور طلب کردہ ٹولز۔
• کون سا ماڈل: ماڈل کا نام اور ورژن (جیسے claude-opus-4-8)، اہم پیرامیٹرز جیسے درجہ حرارت۔
• ان پٹ/آؤٹ پٹ ڈائجسٹ: ایک ماسک شدہ ورژن یا درخواست اور جواب کا ڈائجسٹ/ہیش۔
• فیصلہ: کیا یہ خود بخود عمل میں آیا، کسی انسان کے پاس گیا، کیا اسے منظور یا مسترد کر دیا گیا؟
• نتیجہ: کیا آپریشن کامیاب ہے یا غلطی، کون سا وسیلہ متاثر ہوا؟

مرحلہ وار: آڈٹ ٹریل کا قیام

1. ایک مقصد طے کریں۔ یہ نوشتہ کون پڑھے گا اور کیوں؟ (واقعہ کا جواب، تعمیل آڈیٹنگ، ڈیبگنگ۔) مقصد اس بات کا تعین کرتا ہے کہ آپ کیا رکھتے ہیں۔
2. PII پالیسی نافذ کریں۔ لاگ ان کرنے سے پہلے پرامپٹ/جواب کو ماسک کریں (یونٹ 2)۔
3. عدم تغیر فراہم کریں۔ تنقیدی نوشتہ جات کو صرف منسلک ہونے دیں۔ کسی کو بھی خاموشی سے ماضی کو مٹانے کے قابل نہیں ہونا چاہیے۔
4. برقرار رکھنے کی مدت کی وضاحت کریں۔ قانونی تقاضوں اور رازداری کے توازن کے مطابق مدت کا تعین کریں۔ وقت ختم ہونے پر خود بخود حذف کر دیں۔
5. رسائی کو محدود کریں۔ لاگز تک رسائی کو بھی RBAC کے ساتھ محفوظ کیا جانا چاہیے۔ لاگ ریڈنگ بھی لاگ ان ہونی چاہیے۔
6. ارتباط ID (ٹریس ID) شامل کریں۔ درخواست کے تمام مراحل (ان پٹ، ٹول کال، تصدیق، آؤٹ پٹ) کو ایک ہی شناخت کے ساتھ مربوط کریں۔

چار کاپی ایبل ٹیمپلیٹس

آڈٹ لاگ اسکیما (JSON):

{ "trace_id": "...", "time": "YYYY-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary": "", "summary>": "Summary>": "Summary>" "tools": ["tool_a", "tool_b"], "decision": "auto|human_approval", "approval": "منظور شدہ|rejected|none", "نتیجتا": "کامیابی|غلطی"، "متاثرہ_ وسائل": "..."}

لاگ PII کنٹرول پرامپٹ:

ذیل میں لاگ کی مثالیں دیکھیں۔ کیا آڈٹ ٹریل کے لیے درکار فیلڈز (کون، کب، ماڈل، فیصلہ، نتیجہ) مکمل ہیں؟ کیا خام PII بھی لیک ہو گیا ہے؟ ہر قطار کے لیے، بطور اطلاع دیں: "کافی نہیں ہے / خالی جگہ: ... /PII لیک: ..." <logs>{{ مثالیں }}</logs>

واقعہ کی تعمیر نو کا اشارہ:

مندرجہ ذیل آڈٹ ریکارڈز ایک واحد trace_id سے تعلق رکھتے ہیں۔ واقعہ کو تاریخی ترتیب میں بیانیہ میں تبدیل کریں: صارف کیا چاہتا تھا، ماڈل نے کیا کیا، کون سی توثیق ہوئی، فیصلہ کیسے کیا گیا، نتیجہ کیا نکلا؟ پرچم غائب یا متضاد اقدامات۔<records>{{ trace_registers }}</records>

برقرار رکھنے کی پالیسی کے فیصلے کا اصول:

لاگ کی ہر قسم کے لیے، تعین کریں:- کیا کوئی قانونی برقرار رکھنے کی ذمہ داری ہے؟ (کم از کم مدت اگر کوئی ہے) - کیا اس میں PII ہے؟ (اگر شامل ہو تو، دورانیہ کو کم کریں، رسائی کو کم کریں) - سیکورٹی واقعے کا ثبوت؟ (اسٹور کو تبدیل نہیں کیا جا سکتا) نتیجہ: "اسٹور N دن + ضمیمہ صرف mi + رسائی کی سطح"۔

کمزور پرامپٹ / مضبوط اشارہ

غریب نقطہ نظر

مضبوط نقطہ نظر

لاگ ان بالکل نہیں ("ضرورت نہیں")

ایونٹ کی تشکیل نو کے لیے کم از کم سیٹ لاگ کرنا

لاگنگ خام پرامپٹ/جواب جیسا ہے۔

ماسکڈ سمری + ٹریس آئی ڈی لاگنگ

لاگز کو لامحدود طور پر اسٹور کریں۔

قانونی + رازداری کے توازن کے ساتھ برقرار رکھنے کی مدت

کوئی بھی لاگز کو حذف کر سکتا ہے۔

تنقیدی نوشتہ جات صرف منسلک ہوتے ہیں، رسائی کو کنٹرول کیا جاتا ہے۔

تین چھوٹے کیسز

کیس 1 — ٹریس آئی ڈی نے ایک دن کی تفتیش کو 15 منٹ تک کم کر دیا۔ "میری درخواست کو غیر منصفانہ طور پر مسترد کر دیا گیا تھا،" ایک صارف نے بینک کے کریڈٹ پری ایویلیویشن اسسٹنٹ سے کہا۔ ارتباطی ID کی بدولت، ٹیم نے اس درخواست کے ان پٹ، ملازمین کی تصدیق، اور فیصلے کو 15 منٹ میں دوبارہ تشکیل دیا۔ نے ظاہر کیا کہ غلطی ایک اصول کی توثیق میں ایک غلط حد کی وجہ سے ہوئی تھی اور اسے ٹھیک کر دیا۔

کیس 2 - آڈٹ میں ضرورت سے زیادہ لاگنگ کا پتہ چلا۔ ایک ای کامرس کمپنی ڈیبگنگ کے لیے خام لاگز پر تمام اشارے/جواب لکھ رہی تھی۔ سالانہ آڈٹ کے دوران دیکھا گیا کہ ان لاگز میں صارفین کے ایڈریس اور ٹیلی فون نمبر تھے اور 2 سال کے لیے رکھے گئے تھے۔ تلاش کو ماسکنگ + 90 دن کی برقرار رکھنے کی پالیسی پر سوئچ کر کے بند کر دیا گیا تھا۔ آڈٹ ٹریل فنکشن محفوظ تھا۔

کیس 3 - صرف شامل کرنے والے لاگ سے اندرونی بدسلوکی کا انکشاف ہوا۔ ایک فراہم کنندہ کے ایک ملازم نے اپنے بنائے ہوئے غلط بیچ کو چھپانے کے لیے لاگز کو حذف کرنے کی کوشش کی۔ چونکہ لاگز صرف شامل کرنے کے لیے ہیں اور لاگ پڑھنے/ حذف کرنے کی کوششیں ریکارڈ کی جاتی ہیں، اس لیے یہ کوشش فوری طور پر نظر آتی ہے۔ اس واقعے کے نتیجے میں تادیبی اور عمل کی اصلاح ہوئی۔

مشورہ: ہر درخواست کے لیے ایک ارتباطی ID (ٹریس آئی ڈی) تفویض کریں اور اسے تمام مراحل سے گزاریں۔ جب کوئی مسئلہ پیش آتا ہے تو، ایک سوال کے ساتھ "اس درخواست کے بارے میں سب کچھ" جمع کرنے کے قابل ہونا واقعہ کے ردعمل کا سب سے بڑا سرعت ہے۔

عام غلطیاں

• بالکل لاگ ان نہیں کرنا، یا اتنا کم لاگنگ کرنا کہ آپ ایونٹ کو دوبارہ تشکیل نہیں دے سکتے۔
• خام درخواست/جواب کو بغیر ماسک کے لاگ کرنا اور لاگ کو رساو کے ذریعہ میں تبدیل کرنا۔
• ماڈل کا نام/ورژن اور فیصلہ لاگ ان نہیں کرنا (خودکار/انسانی)۔
• لاگز کو لامحدود مدت کے لیے ذخیرہ کرنے سے رازداری کا خطرہ بڑھ جاتا ہے۔
• اہم نوشتہ جات کو تبدیلی کے تابع چھوڑنا؛ لاگنگ لاگ رسائی نہیں ہے۔
• اقدامات کو ایک ساتھ جوڑنے کے قابل نہیں ہے کیونکہ یہ ایک ارتباطی ID (ٹریس ID) کا استعمال نہیں کرتا ہے۔

خلاصہ میں

• AI لاگنگ "کس نے کیا کیا" میں تین جہتیں شامل کیں: کون سا ماڈل/ورژن، کون سا پرامپٹ، کون سا ردعمل۔
• مقصد یہ ہے کہ PII کو اتنا کم سے کم رکھا جائے کہ اس کو ماسک کر کے ایونٹ کی تشکیل نو کر سکے—زیادہ نہیں، کم نہیں۔
• آڈٹ ٹریل میں کون/کب/کیا/کون سا ماڈل/فیصلہ/نتیجہ کی فیلڈز شامل ہونی چاہئیں۔
• تنقیدی نوشتہ جات صرف منسلک ہونے چاہئیں، رسائی محدود ہونی چاہیے، اور لاگ تک رسائی بھی لاگ ان ہونی چاہیے۔
• کوریلیشن آئی ڈی (ٹریس آئی ڈی) درخواست کے تمام مراحل کو جوڑتا ہے اور واقعے کی تحقیقات کو تیز کرتا ہے۔

درخواست کا کام

اپنے AI بہاؤ سے ایک درخواست منتخب کریں اور اوپر JSON اسکیما کے ساتھ اس کے لیے مثالی آڈٹ ٹریل لکھیں۔ پھر دو ٹیسٹ کریں: (1) کیا آپ صرف اس ریکارڈنگ سے کہانی شروع سے آخر تک بتا سکتے ہیں؟ (2) کیا ریکارڈ میں خام PII ہے؟ اگر کوئی فیلڈ غائب ہے تو اسے شامل کریں، اگر PII ہے تو اسے ماسک کریں۔ آخر میں، برقرار رکھنے کی مدت اور رسائی کی سطح مقرر کریں۔

چیک لسٹ

• آڈٹ ٹریل میں کون/کب/کیا/پیٹرن/فیصلہ/نتیجہ کی فیلڈز شامل ہیں۔
• لاگز سے پہلے پرامپٹ/جواب کو چھپا دیا جاتا ہے (کوئی PII نہیں)۔
• ہر درخواست کے لیے ایک ارتباطی ID (ٹریس ID) تفویض کی جاتی ہے۔
• [ ] تنقیدی نوشتہ جات صرف منسلک ہوتے ہیں اور رسائی کو کنٹرول کیا جاتا ہے۔
• سٹوریج کی مدت قانونی + رازداری کے بیلنس کے ذریعے بیان کی جاتی ہے، اور مدت کے اختتام پر اسے حذف کر دیا جاتا ہے۔
• لاگز کے ساتھ میں 30 منٹ سے بھی کم وقت میں ایک ایونٹ کو دوبارہ بنا سکتا ہوں۔