تصور کنید در یک سیستم قضایی، بازرس همان کسی باشد که متهم را بازداشت کرده و حالا خودش حکم تبرئه یا محکومیت را صادر می‌کند؛ در چنین وضعیتی، عدالت جای خود را به سوگیری می‌دهد. در دنیای نرم‌افزار نیز وقتی یک عامل (Agent) — شبیه دستیاری که همزمان هم غلط‌گیر است و هم نویسنده — هم خطا را پیدا کند و هم آن را اصلاح نماید، ما عملاً اعتبار کل فرآیند بازرسی را از دست می‌دهیم.
طبق اعلام تاد لینرتز (Todd Linnertz)، خالق سیستم حاکمیتی متن‌باز AIEOS، ادغام اعتبارسنجی و اصلاح (Remediation) در یک اقدام واحد، باعث شکست بحرانی در نظارت سازمانی می‌شود. او استدلال می‌کند نهادی که تصمیم می‌گیرد کد «خوب» است یا نه، نباید همان نهادی باشد که کد را «خوب» می‌کند. لینرتز این رویکرد ترکیبی را به بازرسی می‌ماند که شغلش را رها کرده است؛ یعنی به‌جای نمره دادن، شروع به حل تکالیف کرده و کاربر دیگر نمی‌داند کدام بخش از نتیجه را باید باور کند.
این هشدار در حالی مطرح می‌شود که فروشندگان ابزارهای توسعه AI به سمت چارچوب‌های «Solve» حرکت می‌کنند؛ جایی که عامل‌ها به‌طور خودکار مشکلاتی را که شناسایی کرده‌اند، وصله می‌زنند. برای تیم‌های فعال در صنایع تحت نظارت (Regulated Industries)، این تغییر صرفاً یک به‌روزرسانی فنی نیست، بلکه فروپاشی «ردپای بازرسی» (Audit Trail) است. در یک خط لوله نرم‌افزاری حرفه‌ای، «یافته»، «اصلاح» و «تأیید» باید سه واقعیت مجزا باشند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، فقدان مرز میان عملیات مختلف می‌تواند منجر به رفتارهای پیش‌بینی‌ناپذیر شود. لینرتز در سری مقالات «حکمرانی AI در سازمان» (پست F-AID3)، تله‌های معماری حلقه مدل‌های عامل‌محور مدرن را به تفصیل شرح داده است. او با وجود پذیرش ایده‌های خوب سال گذشته، خط قرمز دقیقی روی ادغام «اعتبارسنج» و «اصلاح‌کننده» می‌کشد، زیرا این کار ویژگی اصلیِ قابلیتِ حاکمیتی یک سیستم AI را از بین می‌برد.
سه چارچوبی که ارزش پذیرش دارند
لینرتز نمی‌خواهد صرفاً کسی باشد که می‌گوید «نه». او سه چرخش صنعتی را معرفی می‌کند که حاکمیت را بهبود می‌بخشند و می‌توان آن‌ها را در چارچوب‌های دیگر به کار گرفت:
- بدهی تأیید (Verification Debt): این اصطلاح که توسط سونار (Sonar) رایج شده، فاصله کیفی بین خروجی پیش‌فرض یک عامل و کیفیتی را توصیف می‌کند که یک اپلیکیشن حیاتی و بلندمدت واقعاً به آن نیاز دارد. ما پیش‌تر در بررسی ریسک‌های پنهان کدنویسی با هوش مصنوعی به این موضوع پرداختیم که چگونه این بدهی می‌تواند ثبات سیستم‌های سازمانی را تهدید کند. لینرتز این مفهوم را از «بدهی فنی» (Tech Debt) جدا می‌کند. بدهی فنی نتیجه‌ی میان‌بری است که شما آگاهانه انتخاب کردید؛ اما بدهی تأیید، هزینه‌ای است که بابت صدها تصمیمی می‌پردازید که یک ماشین گرفته و شما هرگز آن‌ها را ندیده‌اید.
- حلقه‌های داخلی در برابر خارجی: این تفکیک مشخص می‌کند بررسی در کجا رخ می‌دهد. حلقه داخلی (Inner Loop) در یک گام استدلالی واحد اتفاق می‌افتد، جایی که عامل در میانه فکر خود، تردید می‌کند. حلقه خارجی (Outer Loop) پس از اتمام کلی کار اجرا می‌شود. این تفاوت هنگام توضیح برای تیم‌های امنیتی حیاتی است تا بحث از «جایی در دل عامل» به یک «دروازه ارتقای مشخص» تغییر کند.
- تست سایه (Shadow Testing): در این روش، یک عامل جدید به‌صورت موازی با عامل عملیاتی واقعی اجرا می‌شود، اما دسترسی به نوشتن (Write Path) برای آن بسته است. به نقل از گزارش‌های صنعتی، یک تیم اتوماسیون حقوق و دستمزد با این روش، دقت عامل خود را از ۷۰٪ به ۹۸٪ رساند، بدون اینکه یک بار هم در محیط عملیاتی تغییر ایجاد کند؛ آن‌ها صرفاً عامل را «در تاریکی» اجرا کرده و خروجی‌ها را برای چند هفته با انسان‌ها مقایسه کردند.
خطر مرحله «Solve»
تضاد اصلی از مرحله‌ای در چارچوب سونار به نام «Solve» می‌آید. در این مدل، اعتبارسنج صرفاً مشکل را پیدا نمی‌کند، بلکه آن را حل می‌کند. او باگ را می‌یابد، وصله را می‌نویسد و حلقه را می‌بندد — تمام این‌ها در دل همان مؤلفه‌ای رخ می‌دهد که وظیفه‌اش گفتن این بود که آیا کد کیفیت لازم را دارد یا خیر.
در دموها این روند شبیه جادو است چون ابزار در یک لحظه مشکل را می‌بیند و حل می‌کند، اما این کار عینیتِ نمره‌دهی را نابود می‌کند. اگر نمره‌دهنده پیش از امتیاز دادن، پاسخ را اصلاح کند، نتیجه تقریباً همیشه «عالی» خواهد بود؛ چراکه AI دلیلی ندارد به خودش نمره کم بدهد. در اینجا دیگر هیچ فاصله یا شفافیتی بین «قضاوت» و «مداخله» وجود ندارد. این چالش در واقع ریشه در شکست تست‌های نرم‌افزاری سنتی در ارزیابی عامل‌های غیرقطعی دارد، جایی که معیارهای قدیمی نمی‌توانند رفتارهای پویا و خود-اصلاح‌گر AI را به‌درستی بسنجند.
در سازمان‌های تحت نظارت، هزینه این فروپاشی در صبح دوشنبه‌ها حس می‌شود. وقتی چیزی خراب منتشر می‌شود، هیئت بررسی سه پرسش می‌پرسد: «چه چیزی تغییر کرد؟ چه کسی تأیید کرد و بررسی واقعاً چه چیزی را شناسایی کرد؟» اعتبارسنجی که اصلاح هم می‌کند، این‌ها را در یک خط میblend می‌کند: ابزار پیدا کرد، ابزار درست کرد، پاک‌سازی شد. چون هیچ‌کس بین این مراحل را ندیده، دیگر جایی نیست تا بپرسیم آیا قضاوت اولیه درست بود یا خیر.
فراتر از ردپای بازرسی، این وضعیت مدل تهدید امنیتی را تغییر می‌دهد. اعتبارسنجی که فقط گزارش می‌دهد، یک مشاهده‌گر «فقط‌خواندنی» است. اما اعتبارسنجی که می‌تواند بنویسد، دیگر ناظر نیست؛ دامنه فعالیتش از «ببین و گزارش کن» به «ببین و کد را تغییر بده» تغییر می‌کند. این یک ریسک کاملاً متفاوت است که باید با تیم‌های پلتفرم بحث شود، اما اکثر سازمان‌ها چون این قابلیت در قالب یک «ویژگی» (Feature) عرضه شده، بدون هیچ بحثی آن را می‌پذیرند.
جایگزین AIEOS
لینرتز می‌پذیرد که کشش به سمت «Solve» واقعی است، زیرا بازخورد سریع، آمارهای خوبی می‌سازد. وقتی اصلاح، نیم‌ثانیه بعد از شناسایی رخ دهد، سرعت تکرار (Iteration) به شدت بالا می‌رود. برخی تیم‌ها گزارش می‌دهند که ۹ مورد از هر ۱۰ مشکل در زمان ویرایش و پیش از بازبینی انسانی حل شده است. ممنوع کردن این ادغام یعنی پذیرش کاهش سرعت.
با این حال، لینرتز یک اصل معماری سخت‌گیرانه برای AIEOS پیشنهاد می‌کند: اعتبارسنج‌ها قضاوت می‌کنند، کمک نمی‌کنند. او اصلاح خودکار را به‌طور کلی ممنوع نمی‌کند، بلکه اصرار دارد که «نمره‌دهنده» نباید قلم در دست داشته باشد. در این فضای تحول، شاهد هستیم که قضاوت مهندسی در حال جایگزینی خروجی‌های خام کد است تا مهارت تحلیل بر تولید انبوه کد ارجحیت یابد.
در گردش کار پیشنهادی او، اصلاح به عنوان یک اثر مجزا با نویسنده مخصوص به خود تعریف می‌شود:
- گام ۱: اعتبارسنجی. اعتبارسنج یک حکم (پذیرفته/رد شده) صادر می‌کند و متوقف می‌شود. او یک قاضی فقط‌خواندنی است.
- گام ۲: اصلاح. اگر کد رد شود، یک عامل اصلاح‌کننده مجزا، آن حکم را می‌گیرد و تغییری پیشنهاد می‌دهد.
- گام ۳: دروازه ارتقا. این اصلاح پیشنهادی، دقیقاً از همان مسیری رد می‌شود که هر تغییر دیگری می‌رود و در برابر یک خط مبنای ثابت تست می‌شود.
این ساختار تضمین می‌کند که «حکم» و «اصلاح» دو اتفاق مجزا با دو نویسنده و دو برچسب زمانی مختلف باشند. اصلاح نباید صرفاً چون از یک ابزار هوشمند آمده، «نوبت خود را پیش بیندازد». اگر اصلاح بر اساس شایستگی‌های خودش از دروازه عبور نکند، منتشر نخواهد شد.
چشم‌انداز نهایی حاکمیت
این رویکرد سرعت تکرار سریع را حفظ می‌کند و در عین حال یکپارچگی ردپای بازرسی را تضمین می‌نماید. با جداسازی «بررسی» از «درمان»، تیم‌ها از خودکارسازی تنها سیگنال صادقانه‌ای که در خط لوله تحویل دارند، جلوگیری می‌کنند.
لینرتز اعتراف می‌کند که صنعت هنوز روی شکل نهایی جایگاه اصلاح به توافق نرسیده است. او یک پاسخ کاربردی دارد — یک عامل مجزا تحت حاکمیت مستقل — اما مطمئن نیست که این فرم نهایی باشد. ممکن است در آینده به یک لایه درجه‌یک تبدیل شود یا تحت قوانین سخت‌گیرانه جداسازی آثار، در بخش اعتبارسنجی ادغام شود.
صرف‌نظر از معماری نهایی، او روی یک خط دفاعی متمرکز است: آنچه تصمیم می‌گیرد کد شما خوب است یا نه، نباید همان چیزی باشد که کد را خوب می‌کند. این دو شغل را در دو دست متفاوت نگه دارید. روزی که این دو ادغام شوند، شما سیگنال‌های خود را خودکار کرده‌اید و متوجه نخواهید شد تا زمانی که ابزاری که برای شکار مشکلات به آن اعتماد کردید، خودش به‌طور خاموش در حال خلق آن‌ها باشد.
گام بعدی شما
- اگر از ابزارهای AI برای اصلاح کد استفاده می‌کنید، بررسی کنید آیا خروجی «اصلاح» مستقیماً جایگزین کد می‌شود یا ابتدا توسط یک عامل مجزا اعتبارسنجی می‌گردد.
- در معماری سیستم‌های خود، «حلقه داخلی» (تصمیمات لحظه‌ای AI) را از «حلقه خارجی» (دروازه‌های تأیید نهایی) تفکیک کنید.
- برای ارزیابی مدل‌های جدید، از روش «تست سایه» استفاده کنید تا بدون ریسک، دقت واقعی را در برابر داده‌های زنده بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو