وقتی یک عامل هوش مصنوعی کد مینویسد، عامل دیگری آن را بازبینی میکند و عامل سوم مسئول انتشار میشود، نام ثبتشده در تاریخچهٔ تغییرات دیگر لزوماً نشان نمیدهد کار چگونه تولید شده است. پرسش درست این است: این تغییر از چه ورودیهایی، با کدام ابزار و مدل، طبق چه سیاستی و با اجازهٔ چه کسی ایجاد شد و چه شواهدی برای اثبات آن داریم؟
این قسمت هفتم از مجموعهٔ دهقسمتی «حاکمیت هوش مصنوعی در یک شرکت نرمافزاری مبتنی بر هوش مصنوعی» است. در قسمت ششم، دربارهٔ مهار عاملها دیدیم سامانه باید بتواند اجرای عامل را متوقف کند، دامنهٔ آسیب را تشخیص دهد و وضعیت را بازیابی کند. اینجا به کنترل مکمل میپردازیم: چگونه پس از وقوع رویداد ثابت کنیم دقیقاً چه اتفاقی افتاده است؟
در سامانهای که عاملها بخشی از فرایند توسعهاند، هویت یک فرد با منشأ واقعی کد یکی نیست. منشأ یک زنجیره است.
از نام نویسنده تا منشأ قابل اثبات تغییر
در شیوهٔ سنتی، یک توسعهدهنده تغییر را ثبت میکرد؛ امضای ثبت تغییر به هویت او متصل بود و میشد از همان فرد دربارهٔ تصمیمش سؤال کرد. امروز ممکن است انسان فقط هدفی را تعریف کند؛ عامل از چند منبع اطلاعات بگیرد، مدلی را فراخوانی کند، تغییر بسازد، آزمون اجرا کند و پس از چند تلاش خروجی بدهد. عامل دیگری سیاستها را بررسی کند، عامل بعدی تغییر را در محیط عملیاتی قرار دهد و سامانهای دیگر دربارهٔ بازگرداندن آن تصمیم بگیرد.
برای بازسازی این جریان باید بتوانیم به پرسشهای مشخصی پاسخ دهیم: هدف اولیه چه بود؟ عامل از چه اطلاعاتی استفاده کرد؟ کدام مدل و نسخه، دستور و مهارت فعال بودند؟ چه ابزارهایی با چه آرگومانهایی فراخوانی شدند؟ کدام نسخهٔ سیاست خروجی را بررسی کرد و نتیجهٔ ارزیابی چه بود؟ هر مرحله چه مدرکی ثبت کرد؟ انسان دقیقاً کدام اقدام را در چه محدودهای مجاز دانست؟ تغییر در نهایت چه اثری بر سامانه گذاشت؟
پاسخ این پرسشها نباید در نُه گزارش جداگانه پراکنده باشد. باید یک زنجیرهٔ پیوسته از هدف تا اثر نهایی وجود داشته باشد. پیوند گمشده درست همان جایی است که هنگام اختلاف یا حادثه دیگر نمیتوان واقعیت را اثبات کرد. کنترلهایی که اجرا شدهاند اما ردشان باقی نمانده، در عمل صرفاً ادعای اجرای کنترلاند.
زنجیرهٔ نگهداری شواهد برای کار عاملها
نمودار زنجیرهٔ نگهداری شواهد برای کار عاملها
مسیر اطلاعات چنین است: هدف ← زمینه و ورودیها ← مدل، دستور و مهارت ← اقدام ← رأی سیاست ← محصول تغییر ← استقرار ← اثر در زمان اجرا ← شواهد. هر اتصال میتواند نقطهٔ قطع زنجیره باشد.
چند روش مهندسی شناختهشده این اتصالات را حفظ میکنند:
- شناسهٔ ارتباطی پایدار: برای هر هدف یک شناسه تولید شود و تمام سرویسها همان شناسه را منتقل کنند. حذف آن در هر مرز، اتصال رویدادهای بعدی به درخواست اولیه را دشوار یا ناممکن میکند.
- نسخههای ثابت و قابل بازیابی: نسخهٔ مدل، اثر انگشت رمزنگاریشدهٔ دستور، نسخهٔ مهارت، ساختار ابزار و شناسهٔ بستهٔ سیاست ثبت شود. عبارت «آخرین نسخه» برای حسابرسی کافی نیست.
- اثر انگشت ورودیها: لازم نیست همهٔ دادههایی که عامل خوانده ذخیره شوند. ثبت هش و نشانی منبع امکان میدهد بعداً بررسی کنیم آیا ورودی مشخصی همان دادهٔ استفادهشده بوده است یا نه.
- گواهی امضاشده در هر مرحلهٔ ارزیابی: ارزیاب باید هویت خود، موضوع ارزیابی، نتیجه و نسخهٔ سیاست را به شکلی قابل راستیآزمایی ثبت کند.
- شواهد فقطافزودنی: سابقه نباید بیصدا ویرایش شود. رکورد جدید میتواند رکورد قبلی را جایگزین کند، اما هر دو باید باقی بمانند.
حاصل این طراحی، امکان بازتولید و بررسی رخداد، دشوار شدن انکار سابقه و آشکار شدن دستکاری است. گزارشی که امکان دنبال کردن و بازسازی مسیر تغییر را ندهد، صرفاً روایت ماجراست.
سهم انسان و عامل را در خود محصول تغییر ثبت کنید
برچسب مبهم «بخشی از کد را هوش مصنوعی نوشته» به نیاز تیم حقوقی، مشتری یا حسابرس پاسخ نمیدهد. سهم عوامل باید در دادههای همراه هر محصول تغییر بهصورت ساختیافته مشخص باشد. پنج وضعیت متفاوت را باید از هم جدا کرد:
- عامل تمام خروجی را نوشته و انسان فقط در مرز مشخص آن را تأیید کرده است.
- عامل پیشنویس را ساخته و انسان آن را ویرایش کرده است؛ تفاوت پیشنویس و نسخهٔ نهایی حفظ شده است.
- انسان نویسنده بوده و عامل صرفاً پیشنهادهایی ارائه داده است.
- انسان مشخصات را نوشته ولی اجرای آن را عامل انجام داده است.
- تمام کار را انسان بدون کمک عامل انجام داده است.
این تمایزها بسته به حوزه میتوانند در مالکیت فکری، مجوز استفاده، ضمانت و انطباق اهمیت پیدا کنند؛ اما نباید نتیجهٔ حقوقی معینی را صرفاً از روی یک برچسب فرض کرد. راهکار عملی، فیلد ساختیافته و امضاشدهٔ authorship است که سامانهٔ انجامدهندهٔ کار در زمان تولید یا انتشار ثبت میکند؛ نه اینکه فردی بعداً گزینهای را در فرم علامت بزند. اگر اطلاعات مالک، نسخه و منشأ از قبل جزو فرادادهٔ محصولات بودهاند، ثبت سهم نویسندگی ادامهٔ همان نظم مهندسی است.
فقط کد را امضا نکنید؛ آنچه رفتار عامل را میسازد نیز ثابت کنید
در زنجیرهٔ ساخت نرمافزار، امضای نسخهٔ منتشرشده و ثبت هش آن کمک میکند ثابت کنیم محصول تحویلشده همان چیزی است که ساختهایم. برای عاملها، رفتار به اجزای دیگری هم وابسته است: مدل و نسخهٔ دقیق آن، دستور فعال و هش آن، مهارت همراه با قرارداد و آزمون، مجموعهٔ قواعد و دامنهٔ اجرای آنها، فهرست ابزارهای قابل فراخوانی و بستهٔ سیاستی که ارزیاب دریافت کرده است. این اجزا باید هنگام انتشار نسخهبندی و امضا شوند و هنگام اجرا با نسخهٔ ثبتشده تطبیق داده شوند.
یک خطای متداول، ویرایش مستقیم فایل دستور است: سامانه بیسروصدا نسخهٔ جدید را میخواند، اما سابقهٔ تغییر به متنی اشاره میکند که دیگر وجود ندارد. راهکار این است که دستور با هش مشخص ثبت و در زمان انتشار امضا شود و سامانه از بارگذاری نسخهٔ تأییدنشده جلوگیری کند. همین قاعده برای مهارت، ساختار ابزار، قواعد و مدل صدق میکند. ارتقای مدل هم باید زیر نظر فرایند مدیریت تغییر باشد، نه وابسته به تغییر خاموش نامی که ارائهدهنده کنترل میکند.
از امضای نسخهٔ نرمافزار تا امضای اجزای تعیینکنندهٔ رفتار عامل
همانطور که فهرست مواد و وابستگیهای نرمافزار نشان میدهد چه چیزی وارد محصول شده، سامانهٔ عاملمحور هم به فهرستی از اجزای دقیق شکلدهندهٔ هر خروجی نیاز دارد؛ فهرستی که هنگام تولید خروجی ثبت شود. هدف فقط امنیت نیست: باید بتوانیم هر نتیجه را به علتی قابل بررسی متصل کنیم. اگر اجزای تعیینکنندهٔ رفتار بدون امضا تغییر کنند، زنجیرهٔ حسابرسی در همان نقطه پایان مییابد.
در مرز میان سرویسها دوباره مدرک بگیرید
قسمت چهارم مجموعه بر ثبت شواهد در هر مرحلهٔ اعمال سیاست تأکید داشت. اما تحویل کار از یک سرویس به سرویس دیگر نقطهٔ شکست جداگانهای است. ممکن است شناسهٔ ارتباطی حذف، شناسهٔ تازه صادر، نسخهٔ سیاست فراموش یا امضای قبلی در مسیر پاک شود.
در هر مرز باید بررسی شود: سرویس اول مدارک موردنیاز بعدی را صادر میکند؟ گیرنده آنها را راستیآزمایی میکند؟ شناسهٔ مشترک و نسخهٔ سیاست منتقل میشوند؟ اگر کار به ابزار خارجی، ارائهدهندهٔ مدل یا رابط برنامهنویسی شخص ثالث سپرده میشود، آیا زمینهٔ تصمیم و شواهد در قالبی قابل بررسی ثبت شده است؟
در ارتباط داخلی میتوان قرارداد میان سرویسها را اصلاح کرد. در ارتباط خارجی باید احتمال تغییر شناسه، تلاش مجدد پنهان یا پاسخ بدون پیوند روشن با درخواست را از ابتدا در طراحی پذیرفت. مسئول حاکمیت باید در این مرز مدرک را مجدداً برقرار کند؛ نه اینکه تصور کند طرف مقابل خودبهخود تمام زنجیره را حفظ خواهد کرد.
ردیابی نباید به نظارت دائمی بر کارکنان تبدیل شود
هدف ثبت منشأ تصمیمهاست، نه ضبط کلیدهایی که مهندس در ساعت مشخصی فشرده است. برای بازسازی اقدام عامل، دانستن هدف، دادهها و سیاستهای مؤثر، نتیجهٔ ارزیابی، تغییر اعمالشده و پیامد آن کافی است. در بسیاری از موارد، هویت مؤثر در زنجیره چیزی شبیه «عامل الف، طبق سیاست ب، برای هدف ج» است. در حضور انسان، مرز اختیار و نوع تأیید اهمیت دارد؛ نه جزئیات رفتاری او پشت صفحهکلید.
دو اصل باید در طراحی اعمال شود: حداقل شواهد کافی، یعنی تنها دادههای لازم برای بازسازی تصمیم نگهداری شوند؛ و مدت نگهداری محدود، یعنی مدارک مانند دیگر دادههای حساس زمان انقضا و قواعد دسترسی داشته باشند. ذخیرهسازی نامحدود نه مزیت ذاتی است و نه بدون خطر. اگر مهندسان سامانهٔ حسابرسی را ابزار کنترل شخصی بدانند، ممکن است از آن فاصله بگیرند و خود قابلیت اتکای سابقه تضعیف شود.
ردیابی برای بازسازی اتفاقات است، نه برای تماشای پیوستهٔ افراد.
چگونه بفهمیم زنجیره واقعاً کار میکند؟
در یک سامانهٔ قابل اتکا میتوان هر تغییر عملیاتی را به هدف اولیه رساند؛ نسخهٔ مدل، هش دستور، نسخهٔ مهارت و بستهٔ سیاست هر اقدام را پیدا کرد؛ سهم نویسندگی انسان و عامل را از فیلد امضاشده خواند؛ پیوستگی مسیر را در مرزهای داخلی و خارجی آزمود؛ و شواهد امضاشده و فقطافزودنی را با اثر انگشتشان بررسی کرد. تیم باید بتواند توضیح دهد رفتار عامل در ۳۰ روز گذشته دقیقاً چه تغییری داشته و گزارش حسابرسی با تصویری که مهندسان از سامانه دارند تناقض نداشته باشد.
نشانههای نبود ردیابی نیز روشناند: نام یک انسان بهعنوان نویسنده ثبت میشود درحالیکه عامل کار را انجام داده است؛ دستور تغییر کرده ولی هشی از آن باقی نمانده؛ مدل ارتقا یافته ولی نسخهٔ آن در سابقه ثبت نشده؛ گزارشها پراکندهاند و زنجیرهای ندارند؛ یا هر بار که بخش حقوقی سؤال ثابتی میپرسد پاسخ متفاوتی دریافت میکند. اگر نتیجهٔ یک سؤال به فرد پاسخدهنده وابسته است، بهجای منشأ قابل اثبات تنها چند روایت داریم.
خرابیهای تکراری زنجیره
فراموشی شناسه: شناسه در سرویس اول ساخته و در سرویس دوم حذف میشود؛ گزارشهای پاییندستی دیگر به درخواست اصلی وصل نمیشوند. ناپدید شدن نسخه: رخداد ثبت شده اما نسخهٔ مدل یا دستور و سیاست سازندهٔ آن نه. دستور قابل تغییر: خروجی امضا شده ولی متن اولیه پس از تولید ویرایش شده است. نویسندگی پیشفرض: تمام تغییر به نام انسانی ثبت میشود که صرفاً آن را تأیید کرده است. سکوت بیرونی: رد رویداد در داخل سازمان کامل است اما در نخستین فراخوانی خارجی قطع میشود. حسابرسی با تصویر صفحه: تیم با حافظه، گفتگوها و اسکرینشاتها داستانی ناقص و قابل اختلاف میسازد.
مقایسهٔ زنجیرهٔ کامل با زنجیرهٔ گسستهٔ شواهد
عامل مشترک این خرابیها تصور نادرستی است: گمان میکنیم صرفِ وجود گزارشهای رویداد باعث میشود زنجیره خودبهخود شکل بگیرد. چنین نیست.
منشأ تغییر باید در خود فرایند مهندسی ساخته شود
در شیوهٔ قدیمی، حسابرسی اغلب بعد از درخواست بخش انطباق آغاز میشد: گزارشها صادر و گزارشی انسانی نوشته میشد. در سامانهٔ عاملمحور این روش از نظر فنی کافی نیست، زیرا اگر نسخهٔ مدل، هش دستور یا شناسهٔ ارتباطی در لحظهٔ اقدام ثبت نشده باشد، بعداً مدرکی برای بازیابی وجود ندارد.
شناسههای مشترک همان مفهوم ردیابی در سامانههای توزیعشدهاند؛ گواهی امضاشده به امضای نسخه شباهت دارد؛ سابقهٔ فقطافزودنی شبیه ثبت رویداد است و هش ورودی از اصول نشانیدهی بر اساس محتوا استفاده میکند. این امکانات باید بخشی از طراحی و ساخت سامانه باشند، نه گزارشی که بعداً تولید میشود.
ترتیب عملی اجرای کار
۱. زنجیرهٔ لازم را تعریف کنید. از پرسشهای واقعی مشتری، حقوقی، انطباق و نهاد ناظر شروع کنید و به عقب برگردید. هدف ضبط همهچیز نیست.
۲. یک مسیر مهم را کامل تجهیز کنید. مثلاً از دستور اولیه برای درخواست تغییر کد توسط عامل تا بررسی، استقرار و اثر عملیاتی آن.
۳. شناسهٔ ارتباطی را جزئی از قرارداد کنید. از لحظهٔ دریافت هدف تولید شود، در تمام مراحل منتقل و در هر مرز بررسی شود. افتادن آن یک نقص واقعی است.
۴. اجزای مؤثر بر رفتار را نسخهبندی و امضا کنید. دستور با هش، مهارت با نسخه، مدل با شناسهٔ ثابت و سیاست با اثر انگشت مشخص ثبت شود.
۵. سهم نویسندگی را در خود محصول تغییر قرار دهید. فیلد ساختیافتهٔ امضاشده باید توسط سامانه تولید و هنگام انتشار الزامی باشد.
۶. مرزها را روشن کنید. برای مسیرهای داخلی قرارداد و برای مسیرهای خارجی شواهد ازنو برقرارشده و وابستگی به طرف سوم ثبت شود.
۷. با سؤال واقعی آزمایش کنید. یک تغییر اخیر را انتخاب کنید و بپرسید چه چیزی، با اختیار چه کسی و بر مبنای کدام سیاست آن را ایجاد کرده است. اگر پاسخگویی بیش از چند دقیقه صرف جمعآوری مدرک میکند، زنجیره هنوز آمادهٔ اتکا نیست.
جمعبندی
حسابرسی در توسعهٔ مبتنی بر عامل دیگر صرفاً کار اداری نیست؛ قابلیتی مهندسی است. زنجیرهٔ شواهد را باید پیش از آنکه نخستین عامل تغییر خود را منتشر کند در سامانه ساخت. این زنجیره دیگر از یک نفر به نفر بعدی نمیرود؛ از هدف تا اثر نهایی، از میان عاملها، دستورها، مدلها، مهارتها، سیاستها و محیط اجرا عبور میکند.
بااینحال منشأیابی نمیتواند دربارهٔ تغییری که هیچگاه دیده نشده توضیح بدهد: ارتقای پنهانی مدل پشت یک نام ثابت، ویرایش مستقیم دستور یا افزودهشدن ابزار به مهارتی که ثبت نشده، همگی از نگاه زنجیره پنهان میمانند. بنابراین تغییر قابلیتهای عامل نیز باید رویدادی تحت حاکمیت باشد. سازمانی که فقط آییننامهٔ مفصل دارد ولی نمیتواند مسیر یک تغییر را از هدف تا نتیجه بازسازی کند، شواهد لازم را ندارد.
قسمت بعدی: راهنمای مدیریت تغییر عاملها؛ پس از ایجاد قابلیت ردیابی میتوان ارتقای توانایی عامل را مانند انتشار نرمافزار با ثبت نسخه، اجرای آزمایشی، اطلاعرسانی و امکان بازگشت مدیریت کرد.
این مقاله نخستین بار در ۴ ژوئن ۲۰۲۶ به قلم رضا آرانی در Medium منتشر شد و برای Aipolix بهعنوان قسمت هفتم مجموعه بازآرایی شده است.
دیدگاهها
هنوز دیدگاهی ثبت نشده است. اولین نفر باشید.
ثبت دیدگاه