رد شواهد: آماده‌کردن سامانه هوش مصنوعی برای حسابرسی

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

آمادگی حسابرسی یعنی توان ارائه شاهد مرتبط، قابل اتکا و محافظت‌شده برای یک assertion مشخص. assertion می‌تواند این باشد که «هر بازپرداخت بالاتر از حد، تأیید انسانی گرفته»، «فقط مدل تأییدشده به تولید رفته» یا «سامانه پرریسک رویدادهای مقرر را ثبت کرده است». هر ادعا شاهد خاص خود را می‌خواهد؛ چیزی به نام لاگ واحد و عمومی حسابرسی AI وجود ندارد.

این مطلب الگوی مهندسی است، نه مشاوره حقوقی یا حسابرسی. الزام به حوزه قضایی، صنعت، نقش سامانه و قرارداد بستگی دارد. برای نمونه متن رسمی ماده ۱۲ قانون هوش مصنوعی اتحادیه اروپا درباره قابلیت ثبت رویداد در سامانه پرریسک است و traceability را به هدف مورد نظر آن پیوند می‌دهد. چارچوب مدیریت ریسک AI نسخه ۱٫۰ NIST داوطلبانه و مستقل از حوزه کاربرد است و NIST اعلام کرده بازنگری آن در جریان است. ISO/IEC 42001:2023 یک استاندارد سیستم مدیریت AI است و جای قانون خاص deployment را نمی‌گیرد.

از assertion آغاز کنید، نه از telemetry موجود

پیش از انتخاب ابزار لاگ، ماتریس شاهد بنویسید:

این ماتریس مانع «شاهد اتفاقی» می‌شود؛ حالتی که داده فنی فراوان است اما کنترل کسب‌وکار اثبات نمی‌شود. جمعیت را به اندازه شرط قبولی دقیق تعریف کنید. اگر درخواست ناموفق پیش از گرفتن شناسه ناپدید شود، مجموعه شاهد به سود موفقیت‌ها bias دارد.

مرز سامانه هر assertion را ترسیم کنید. یک workflow ممکن است از برنامه، API مدل، بازیابی، موتور سیاست، صف انسان، درگاه پرداخت و اعلان عبور کند. trace برنامه که پیش از درگاه پرداخت تمام می‌شود، صدور بازپرداخت را ثابت نمی‌کند.

راهنمای اتوماسیون مبتنی بر شاهد برای طراحی مرز اقدام و receipt آن پیش از گسترش خودمختاری مکمل خوبی است.

envelope مشترک رویداد بسازید

هر رویداد مادی باید envelope کوچکی داشته باشد تا رکوردها بدون تکثیر همه داده حساس به هم join شوند:

• شناسه تغییرناپذیر رویداد؛
• شناسه workflow یا case؛
• شناسه parent و correlation؛
• نوع رویداد و نسخه schema؛
• زمان رخداد و زمان ingestion همراه منبع ساعت؛
• نوع actor و شناسه احرازشده او؛
• سازمان، محیط و حوزه اقامت داده؛
• سرویس تولیدکننده و build مستقر؛
• ارجاع payload یا digest محتوا؛
• طبقه‌بندی، کلاس نگهداری و سیاست دسترسی؛
• اطلاعات integrity رمزنگارانه اگر threat model لازم بداند.

سپس payload نوع‌دار برای دریافت درخواست، بازیابی منبع، ارزیابی سیاست، فراخوان مدل، پیشنهاد ابزار، درخواست تأیید، تصمیم تأیید، ارسال اقدام، تأیید اقدام، اعلان کاربر، بازشدن استثنا و بستن پرونده تعریف کنید.

یک «توضیح تصمیم» آزاد را تنها پیوند نگذارید. شناسه پایدار مانند policy_version، model_artifact_digest، prompt_template_version، source_record_id، tool_definition_version و action_receipt_id به‌کار ببرید. خلاصه انسانی برای بازبین مفید است، ولی فیلد نوع‌دار آزمون completeness و population را ممکن می‌کند.

زمان رخداد و ingestion را جدا ثبت کنید. رویداد دیررس ممکن است تأخیر شبکه یا نشانه دست‌کاری باشد. ساعت را همگام، skew را پایش و ترتیب را صریح تعریف کنید؛ ترتیب insert پایگاه داده الزاماً ترتیب جهان واقعی نیست.

زنجیره تصمیم را بدون ضبط همه‌چیز ثبت کنید

برای اقدام پیامددار، زنجیره معمولاً این موارد را لازم دارد:

1. درخواست احرازشده و هدف اعلامی؛
2. رکورد منبع، نسخه، زمان بازیابی و مبنای مجوز؛
3. نسخه مدل، template پرامپت، بازیابی، ابزار و تنظیم؛
4. خروجی مادی مدل یا ارجاع محافظت‌شده به آن؛
5. نتیجه سیاست قطعی و ورودی هر قاعده؛
6. عدم قطعیت یا سیگنال ارزیابی که routing استفاده کرده؛
7. تأیید، رد، ویرایش و delegation انسانی؛
8. فرمان دقیق ارسال‌شده به سامانه بیرونی؛
9. receipt موفقیت، شکست یا settlement سامانه بیرونی؛
10. اعلان، اصلاح، rollback و نتیجه نهایی.

این درخواست آرشیو زنجیره فکر پنهان نیست. حسابرس شاهد مشاهده‌پذیر می‌خواهد: ورودی، خروجی، معیار، تصمیم، actor و اثر. rationale تولیدی مدل ثابت نمی‌کند همان دلیل باعث نتیجه شده است. تصمیم سیاست را تا جای ممکن قطعی کنید و اجرای واقعی قاعده را ثبت نمایید.

کمینه‌سازی مهم است. وقتی سند کامل نباید در stream رویداد باشد، hash و ارجاع object امن ذخیره کنید. شناسه را tokenize، secret را پیش از log حذف و مشاهده payload را نقش‌محور کنید. digest نشان می‌دهد کدام object ارجاع شده؛ درستی یا جمع‌آوری قانونی آن را ثابت نمی‌کند.

یک پرونده ملموس را دنبال کنید

کوپایلوت حساب‌های پرداختنی را در نظر بگیرید که پرداخت تأمین‌کننده پیشنهاد می‌دهد:

• سفارش خرید PO-4821، فاکتور INV-817 و رسید کالا با نسخه معلوم بازیابی می‌شوند؛
• استخراج نوری مبلغ، ارز، حساب بانکی و تاریخ را نامزد می‌کند؛
• قواعد تطبیق، تأمین‌کننده، مقدار، مالیات، تکرار و tolerance را می‌سنجند؛
• مدل اختلاف را خلاصه می‌کند اما قاعده را عوض نمی‌کند؛
• سیاست، مغایرت ذی‌نفع را به گروه تأیید نام‌دار می‌فرستد؛
• بازبین تصویر منبع و نتیجه قواعد را می‌بیند، memo را ویرایش و تأیید می‌کند؛
• سرویس پرداخت فرمان امضاشده با idempotency key می‌گیرد؛
• بانک یا درگاه receipt برمی‌گرداند؛
• reconciliation بعدی settlement یا رد را به پرونده وصل می‌کند.

trace پرامپت تقریباً هیچ‌کدام را ثابت نمی‌کند. شیء حسابرسی graph پرونده‌ای است که رکورد معتبر، اجرای کنترل، عمل انسان و نتیجه بیرونی را پیوند می‌دهد.

مسیر نامطلوب را هم بیازمایید: استخراج شکست می‌خورد، بازبین timeout می‌شود، تأمین‌کننده حساب را عوض می‌کند، API پاسخ مبهم می‌دهد یا retry همان idempotency key را می‌بیند. assurance اغلب جایی ضعیف است که exception یک workflow موازی و کم‌مشاهده می‌سازد.

integrity را محافظت و وظیفه را تفکیک کنید

مدیری که هم سامانه و هم رد حسابرسی را تغییر می‌دهد، می‌تواند تفاوت عملیات و شاهد را پاک کند. کنترل متناسب با ریسک شامل ذخیره append-only یا write-once، هویت سرویس محدود، permission جدا برای عملیات و تأیید و مدیریت شاهد، build امضاشده و digest artifact، لاگ دسترسی به خود شواهد، آزمون backup و restore و روش اصلاحی است که amendment اضافه کند نه تاریخچه را جایگزین.

زنجیره رمزنگارانه حذف یا جابه‌جایی را آشکار می‌کند، اما رویداد دروغ را راست نمی‌کند. receipt مستقل، reconciliation و رکورد source system از یک self-attestation قوی‌ترند.

تفکیک وظیفه باید پس از خودکارسازی هم باقی بماند. اگر همان agent تراکنش را بسازد، استثنای خود را تأیید و با همان credential نتیجه را تصدیق کند، سه نوع event سه کنترل نمی‌سازند. تأیید را به هویت مستقل ببندید و سرویس authorization آن را enforce کند.

تأیید انسانی را شاهد طراحی کنید

رکورد تأیید باید نشان دهد بازبین واقعاً چه دیده است: نسخه منبع، اقدام پیشنهادی، استثنای سیاست، اطمینان و هشدار مادی. تصمیم، actor، نقش، زمان، ویرایش و reason code را ذخیره کنید. اگر پرونده پس از تأیید تغییر مادی کرد، تأیید را invalidate یا دوباره درخواست کنید.

از نمایش انسانی پرهیز کنید. بازبینی که صدها هشدار کم‌زمینه می‌گیرد، click-through می‌کند. سن صف، زمان مرور، override، اختلاف، تأیید تکراری هر actor و درصد پرونده با شاهد کامل را بسنجید. کیفیت تصمیم را نمونه‌برداری کنید.

راهنمای طراحی تأیید انسانی routing بر اساس پیامد و زمینه بازبین را توضیح می‌دهد. درس assurance روشن است: «انسان در حلقه» تا زمانی که حق تصمیم تعریف‌شده و رکورد آزمون‌پذیر ندارد، assertion نیست.

نگهداری، حذف و redaction را سیاستی کنید

مدت نگهداری باید از assertion، قانون، قرارداد، litigation و کمینه‌سازی بیاید، نه «همه‌چیز برای همیشه». هنگام ایجاد، retention class بدهید. legal hold، استثنا، قالب آرشیو، رمزگذاری، rotation کلید و راستی‌آزمایی حذف را مستند کنید.

حذف یک workflow میان لاگ اصلی، object storage، index جست‌وجو، نسخه تحلیلی، backup، فروشنده و داده مشتق‌شده است. دامنه و وضعیت را بدون بازسازی محتوای حذف‌شده ثبت کنید. اگر شاهد باید بماند ولی payload حساس حذف شود، فراداده و اطلاعات integrity مجاز را طبق سیاست مصوب نگه دارید.

نگهداری طولانی با وجود کمک به تحقیق می‌تواند ریسک امنیت و حریم را زیاد کند. بررسی کنید آیا همان assertion با ارجاع امن، fact ساخت‌یافته یا aggregate به جای پرامپت و سند خام پشتیبانی می‌شود.

کارکرد واقعی رد را اندازه بگیرید

معیارهای مفید assurance:

• نرخ بازسازی: درصد پرونده نمونه که بازبین مستقل بدون کمک تیم عملیات بازسازی می‌کند؛
• پوشش جمعیت: پرونده مورد انتظار با رویداد آغاز و پایان معتبر؛
• پوشش شاهد کنترل: کنترل لازم با ورودی، نتیجه، نسخه و مالک؛
• کامل‌بودن lineage منبع: خروجی مادی متصل به نسخه قابل بازیابی؛
• integrity تأیید: تأیید متصل به همان اقدام و باطل‌شده پس از تغییر؛
• تأیید اقدام: فرمان ارسال‌شده با وضعیت معتبر موفق، ناموفق یا unresolved؛
• تأخیر و skew: فاصله رخداد تا ingestion ماندگار؛
• اعتبار schema: رکورد malformed یا ناشناخته؛
• نقض دسترسی شاهد: تلاش غیرمجاز یا غیرعادی؛
• زمان پاسخ: زمان بازبین مستقل برای حل پرسش تعریف‌شده؛
• اجرای retention: حذف، حفظ یا hold مطابق سیاست.

هدف خدمت را با پیامد تنظیم کنید. پیشنهاد محتوای کم‌خطر شاید نبود جزئیات trace را تحمل کند. پرداخت، eligibility، استخدام، سلامت یا ایمنی ممکن است lineage کامل بخواهد و با قطع سرویس شاهد fail closed شود.

walkthrough مستقل اجرا کنید

از پرونده عادی، شکست‌خورده، overrideشده، retryشده و appealed نمونه بگیرید. assertion و رابط شاهد مصوب را به بازبین بدهید، نه دسترسی ad hoc پایگاه داده یا coaching. او باید تشخیص دهد چه اتفاقی و با چه ترتیب افتاد، کدام منبع و نسخه استفاده شد، چه مدل و کنترلی فعال بود، هر تصمیم را چه کسی با کدام اختیار گرفت، چه اثر بیرونی دیده شد و اصلاح و اعلان و retention رعایت شدند یا نه.

شاهد گمشده، join مبهم، شکاف ساعت، object غیرقابل دسترس و فیلد روایی که باید type شود ثبت کنید. مدل رویداد را اصلاح و walkthrough را تکرار کنید.

سیستم مدیریت AI باید پیوسته بهتر شود؛ این با توضیح ISO از چرخه Plan-Do-Check-Act در ISO/IEC 42001 سازگار است. قبولی یک walkthrough گواه دائمی رفتار سامانه نیست.

پرسش‌های رایج

باید هر پرامپت و پاسخ را ذخیره کنیم؟

خیر. آنچه برای assertion و پاسخ رخداد لازم است طبق حریم و retention نگه دارید. تصمیم پرریسک شاید محتوای کامل محافظت‌شده بخواهد؛ workflow دیگر با فیلد ساخت‌یافته، hash و ارجاع امن کافی است.

توضیح تولیدی مدل شاهد حسابرسی است؟

شاهد چیزی است که مدل تولید کرده، نه اثبات علت یا compliance. آن را با lineage منبع، کنترل قطعی، معیار نسخه‌دار و تصمیم انسان یا سامانه همراه کنید.

لاگ تغییرناپذیر کافی است؟

خیر. immutability دست‌کاری را آشکار می‌کند، نه کامل‌بودن، حقیقت، مجوز یا وقوع اثر بیرونی را. با سامانه و receipt مستقل تطبیق دهید.

شکست سرویس حسابرسی باید workflow را متوقف کند؟

برای اقدام پیامددار، از دست‌رفتن شاهد لازم ممکن است fail-closed یا عملیات محدود بخواهد. پاسخ را در ارزیابی ریسک تعریف کنید، نه وسط outage.

منابع — بازبینی‌شده در ۲۰۲۶-۰۷-۳۰

• NIST، AI RMF 1.0 و هسته AI RMF: ساختار داوطلبانه مدیریت ریسک چرخه عمر و مستندسازی نظام‌مند.
• اتحادیه اروپا، ماده ۱۲ قانون AI درباره ثبت رویداد: متن رسمی قابلیت logging سامانه پرریسک.
• ISO، مرور ISO/IEC 42001:2023 و توضیح سیستم مدیریت AI: دامنه و بهبود مستمر AIMS.
• NIST، AI RMF Playbook: اقدام‌های پیشنهادی مستندسازی و مدیریت ریسک؛ داوطلبانه است و برنامه کامل حسابرسی نیست.

NIST اعلام کرده RMF 1.0 در حال بازنگری است؛ mapping را نسخه‌دار کنید. صفحه عمومی ISO متن کامل استاندارد نیست. کاربرد قانون اتحادیه اروپا به نقش، طبقه سامانه، تاریخ و راهنمای مرتبط بستگی دارد؛ تعهد را با مشاور حقوقی و متخصص assurance واجد صلاحیت تأیید کنید.