ورود به سیستم، مسیر حسابرسی و اثبات پذیری

سود:

• توانایی طراحی حداقل طرح دنباله حسابرسی کافی برای بازسازی رویداد
• امکان جلوگیری از نشت لاگ با پوشاندن اعلان/پاسخ
• امکان ایجاد لاگ های قابل تایید با هویت همبستگی، تغییر ناپذیری و دوره نگهداری

در یک سیستم هوش مصنوعی، یک روز مطمئناً این سؤال مطرح می شود: "چرا این تصمیم به این شکل گرفته شد، دقیقاً آن روز چه اتفاقی افتاد؟" این سوال ممکن است توسط یک مشتری، یک حسابرس، یک تنظیم کننده یا یک دادگاه پرسیده شود. پاسخ شما یا یک دنباله حسابرسی قابل تأیید خواهد بود یا "ما نمی دانیم". مورد دوم در یک محیط شرکتی غیرقابل قبول است. در این بخش، یاد می‌گیریم که چه چیزهایی را باید و چه مواردی را نباید به‌خصوص هوش مصنوعی ثبت کنیم، چگونه یک مسیر حسابرسی ایجاد کنیم، و چگونه گزارش‌ها را در تعادل با امنیت و حریم خصوصی نگه داریم.

چرا ورود به سیستم در هوش مصنوعی متفاوت است؟

در نرم افزارهای کلاسیک، "who did what" ثبت می شود. در هوش مصنوعی، سه بعد جدید به این اضافه می شود: چه مدل/نسخه ای استفاده شده است، چه پیامی ارسال شده است و چه پاسخی تولید شده است. هنگامی که یک خطا یا شکایت رخ می دهد، بدون این سه نمی توانید حادثه را بازسازی کنید. اما این اعلان/پاسخ می‌تواند حاوی PII باشد، همانطور که در واحد 2 دیدیم - به این معنی که گزارش خود می‌تواند به منبع نشت تبدیل شود. این هنر تعادل است.

احتیاط: ورود به سیستم "ورود همه چیز" نیست. ثبت بیش از حد، خطر حفظ حریم خصوصی را ایجاد می کند، و ثبت بسیار کم باعث کمبود شواهد می شود. هدف این است که مقدار کافی از PII برای بازسازی رویداد با پوشاندن آن حفظ شود.

چه چیزی باید ثبت شود؟ طرح ردیابی حسابرسی

یک مسیر حسابرسی هوش مصنوعی، حداقل شامل موارد زیر است:

• چه کسی: شناسه کاربری و نقش (یا شناسه سرویس).
• زمان: مهر زمانی (فقط در صورت امکان پیوست).
• چه: اقدام مورد نظر و ابزار احضار.
• کدام مدل: نام و نسخه مدل (به عنوان مثال claude-opus-4-8)، پارامترهای مهم مانند دما.
• خلاصه ورودی/خروجی: نسخه پوشانده شده یا خلاصه/هش درخواست و پاسخ.
• تصمیم: آیا به طور خودکار پردازش شد، به یک انسان رفت، تایید یا رد شد؟
• نتیجه: آیا عملیات موفقیت آمیز است یا خطا، کدام منبع تحت تأثیر قرار می گیرد؟

گام به گام: ایجاد یک مسیر حسابرسی

1. یک هدف تعیین کنید. چه کسی این لاگ ها را خواهد خواند و چرا؟ (پاسخ به رویداد، حسابرسی انطباق، اشکال زدایی.) هدف تعیین می کند که چه چیزی را نگه دارید.
2. سیاست PII را اجرا کنید. اعلان/پاسخ را قبل از ورود به سیستم بپوشانید (واحد 2).
3. تغییر ناپذیری را فراهم کند. اجازه دهید گزارش‌های بحرانی فقط پیوست شوند. هیچ کس نباید بتواند گذشته را در سکوت پاک کند.
4. دوره نگهداری را تعریف کنید مدت زمان را با توجه به تعادل الزامات قانونی و محرمانگی تعیین کنید. به طور خودکار حذف زمانی که زمان منقضی می شود.
5. دسترسی را محدود کنید دسترسی به سیاههها نیز باید با RBAC محافظت شود. خواندن گزارش نیز باید ثبت شود.
6. شناسه همبستگی (شناسه ردیابی) را اضافه کنید. تمام مراحل یک درخواست (ورودی، تماس ابزار، تأیید، خروجی) را با یک هویت واحد وصل کنید.

چهار قالب قابل کپی

طرح گزارش حسابرسی (JSON):

{ "trace_id": "..."، "time": "YYYY-MM-DDThh:mm:ssZ"، "user": "..."، "role": "..."، "model": "claude-opus-4-8"، "parameters": { "temperature": 0 }، "request_summary:"""، "<mask" "<masked>"، "tools": ["tool_a"، "tool_b"]، "decision": "auto|human_approval"، "Approval": "Approved|Rejected|none"، "نتیجه": "موفقیت|خطا"، "Affected_Resource": "..."}

اعلان کنترل PII Log:

نمونه های لاگ زیر را بررسی کنید. آیا فیلدهای مورد نیاز برای مسیر حسابرسی (چه کسی، چه زمانی، مدل، تصمیم، نتیجه) کامل شده است؟ همچنین آیا PII خام لو رفته است؟ برای هر ردیف، گزارش دهید: "فقدان / فضای خالی: ... / نشت PII: ..." <logs>{{ نمونه‌ها }}</logs>

درخواست بازسازی رویداد:

سوابق حسابرسی زیر متعلق به یک trace_id است. رویداد را به ترتیب زمانی به یک روایت تبدیل کنید: کاربر چه می‌خواست، مدل چه کار کرد، چه اعتبارسنجی‌هایی انجام شد، چگونه تصمیم گرفته شد، چه نتیجه‌ای حاصل شد؟ مراحل گم شده یا ناسازگار را علامت گذاری کنید.<records>{{ trace_registers }}</records>

قانون تصمیم گیری سیاست حفظ:

برای هر نوع لاگ، تعیین کنید: - آیا الزام قانونی برای نگهداری وجود دارد؟ (حداقل دوره در صورت وجود) - آیا حاوی PII است؟ (در صورت وجود، مدت زمان را کوتاه کنید، دسترسی را محدود کنید) - شواهدی از حادثه امنیتی؟ (فروشگاه قابل تغییر نیست) نتیجه: "store N روز + ضمیمه فقط mi + سطح دسترسی".

اعلان ضعیف / اعلان قوی

رویکرد ضعیف

رویکرد قوی

اصلا وارد نشدن ("نیازی نیست")

ثبت حداقل مجموعه برای بازسازی رویداد

ثبت درخواست/پاسخ خام همانطور که هست

خلاصه ماسک + ثبت شناسه ردیابی

سیاهههای مربوط را به طور نامحدود ذخیره کنید

دوره نگهداری با تعادل حقوقی + حریم خصوصی

هر کسی می تواند گزارش ها را حذف کند

گزارش‌های بحرانی فقط پیوست هستند و دسترسی کنترل می‌شود

سه کیف کوچک

مورد 1 - Trace ID تحقیقات یک روزه را به 15 دقیقه کاهش داد. یکی از مشتریان به معاون پیش ارزیابی اعتبار یک بانک گفت: درخواست من به طور ناعادلانه رد شد. به لطف شناسه همبستگی، تیم ورودی برنامه، تأییدیه‌های کارکنان و تصمیم‌گیری را در 15 دقیقه بازسازی کرد. نشان داد که خطا ناشی از یک آستانه نادرست در اعتبارسنجی یک قانون است و آن را برطرف کرد.

مورد 2 - ثبت بیش از حد در حسابرسی کشف شد. یک شرکت تجارت الکترونیک در حال نوشتن تمام درخواست‌ها/پاسخ‌ها به گزارش‌های خام برای اشکال‌زدایی بود. در طی ممیزی سالانه مشاهده شد که این گزارش ها حاوی آدرس و شماره تلفن مشتریان بوده و به مدت 2 سال نگهداری می شوند. این یافته با تغییر به یک خط مشی حفظ پوشش + 90 روز بسته شد. عملکرد ردیابی حسابرسی حفظ شد.

مورد 3 - گزارش فقط ضمیمه سوء استفاده داخلی را نشان داد. یکی از کارمندان یکی از ارائه‌دهنده‌ها تلاش کرد تا گزارش‌ها را حذف کند تا دسته اشتباهی را که ساخته بود پنهان کند. از آنجایی که گزارش‌ها فقط پیوست هستند و تلاش‌های خواندن/حذف گزارش ثبت می‌شوند، تلاش بلافاصله قابل مشاهده بود. این حادثه منجر به اصلاح انضباطی و فرآیند شد.

نکته: به هر درخواست یک شناسه همبستگی (شناسه ردیابی) اختصاص دهید و آن را در تمام مراحل انجام دهید. هنگامی که مشکلی رخ می دهد، توانایی جمع آوری "همه چیز در مورد آن درخواست" با یک پرس و جو، بزرگترین تسریع کننده پاسخ حادثه است.

اشتباهات رایج

• اصلاً وارد نشدید، یا آنقدر کم ثبت نام کردید که نتوانید رویداد را بازسازی کنید.
• ثبت درخواست/پاسخ خام بدون ماسک و تبدیل لاگ به منبع نشت.
• عدم ثبت نام مدل/نسخه و تصمیم (خودکار/انسانی).
• ذخیره گزارش‌ها برای مدت نامحدود خطر حفظ حریم خصوصی را افزایش می‌دهد.
• ترک سیاهههای مربوط به تغییر در معرض. عدم ثبت دسترسی به گزارش.
• عدم امکان اتصال مراحل به یکدیگر زیرا از شناسه همبستگی (شناسه ردیابی) استفاده نمی کند.

به طور خلاصه

• ثبت هوش مصنوعی سه بعد را به "چه کسی انجام داد" اضافه می کند: کدام مدل/نسخه، کدام درخواست، کدام پاسخ.
• هدف این است که PII را به اندازه کافی حداقل نگه دارید تا با پوشاندن رویداد، آن را بازسازی کنید - نه بیشتر، نه کمتر.
• مسیر حسابرسی باید شامل فیلدهای چه کسی/ چه زمانی/چه/چه مدل/تصمیم/نتیجه باشد.
• گزارش‌های بحرانی باید فقط پیوست باشند، دسترسی باید محدود باشد، و دسترسی به گزارش نیز باید ثبت شود.
• شناسه همبستگی (شناسه ردیابی) تمام مراحل درخواست را به هم متصل می کند و بررسی حادثه را سرعت می بخشد.

وظیفه کاربردی

درخواستی را از جریان هوش مصنوعی خود انتخاب کنید و مسیر حسابرسی ایده آل را برای آن با طرح JSON در بالا بنویسید. سپس دو تست انجام دهید: (1) آیا می توانید داستان را از ابتدا تا انتها فقط با این ضبط بگویید؟ (2) آیا PII خام در پرونده وجود دارد؟ اگر فیلد وجود ندارد، آن را اضافه کنید، اگر PII وجود دارد، آن را ماسک کنید. در نهایت، یک دوره نگهداری و سطح دسترسی را تنظیم کنید.

چک لیست

• [ ] دنباله حسابرسی شامل فیلدهای چه کسی/ چه زمانی/چه/الگو/تصمیم/نتیجه است.
• [ ] اعلان/پاسخ قبل از گزارش ها پوشانده می شود (بدون PII).
• [ ] یک شناسه همبستگی (شناسه ردیابی) به هر درخواست اختصاص داده می شود.
• [ ] گزارش‌های مهم فقط پیوست هستند و دسترسی کنترل می‌شود.
• [ ] دوره ذخیره سازی با تراز قانونی + محرمانه تعریف می شود و در پایان دوره حذف می شود.
• [ ] با گزارش‌ها می‌توانم یک رویداد را در کمتر از 30 دقیقه بازسازی کنم.