اگر امروز برای اتوماسیون فرآیندهای حساس شرکتتان روی امتیازات اطمینان مدل‌ها حساب می‌کنید، احتمالاً در حال ساختن یک بمب ساعتی حقوقی هستید. مبلغ ۱۹۳ هزار دلار، بهای جریمه‌ای است که شرکت DoNotPay در فوریه ۲۰۲۵ به کمیسیون تجارت فدرال (FTC) پرداخت کرد؛ تماماً به این دلیل که خروجی‌های «وکیل ربات» خود را با توصیه‌های وکلاهای دارای مجوز تست نکرده بود. تقریباً بلافاصله پس از عرضه، این پلتفرم — که ادعا می‌کرد اولین وکیل ربات جهان است — با یک شکایت دسته‌جمعی (Class-action lawsuit) به دلیل ارائه خدمات حقوقی غیرمجاز بدون داشتن مجوز کانون وکلای کالیفرنیا مواجه شد.
این پرونده، شکاف عمیقی را میان تبلیغات بازاریابی هوش مصنوعی و نتایج واقعی شرکتی نشان می‌دهد. برای مدیرانی که قراردادهای میلیون دلاری نرم‌افزاری امضا می‌کنند، این فاصله یک منطقه خاکستری قانونی ایجاد می‌کند که بسیاری از آن‌ها برای اجتناب از آن مستأصل‌اند، چرا که بسیاری از این پیچیدگی‌ها هنوز سابقه قانونی ندارند و هیچ پیشینه قضایی برای حل آن‌ها وجود ندارد. این چالش‌های نظارتی در حالی رخ می‌دهد که بسیاری از کارکنان اداری برای افزایش بهره‌وری، از ابزارهای ممنوع هوش مصنوعی در محیط کار استفاده می‌کنند و ریسک‌های امنیتی و حقوقی سازمان‌ها را دوچندان می‌کنند.
اکنون اکثر سازمان‌ها به سمت الگوهای طراحی نظارت انسانی (Human-in-the-Loop یا HITL) می‌روند. این معماری — شبیه به یک ایستگاه بازرسی در جاده که اجازه نمی‌دهد هیچ کامیونی بدون بازرسی وارد شهر شود — تصمیمات پیچیده را پیش از اجرا به بررسی انسانی می‌فرستد تا زنجیره مسئولیت‌پذیری شفاف بماند. این رویکرد به‌ویژه برای بخش‌های حساسی مثل عملیات بهداشتی، بررسی‌های انطباق مقرراتی، تراکنش‌های مالی کلان و تصمیم‌گیری‌های حقوقی حیاتی است؛ جایی که یک توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌تواند منجر به یک شکایت قضایی شود.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های حفاظتی باید در سطح معماری تعریف شوند، نه به عنوان یک افزونه ساده.
درک معماری نظارت انسانی
نظارت انسانی یک الگوی طراحی نوظهور است که در آن عامل‌ها (Agents) تصمیمات پیچیده را پیش از تولید پاسخ یا اجرای تکلیف، به بررسی انسان می‌فرستند. با این حال، تعریف این مفهوم گسترده است و شرکت‌ها اغلب از این اصطلاح به صورت سیال برای توصیف معماری‌های متفاوتی استفاده می‌کنند.
به عنوان مثال، یک فروشنده SaaS که هر چند وقت یک‌بار روی سیستم AI خود ممیزی امنیتی انجام می‌دهد، ممکن است ادعا کند نظارت انسانی دارد. اما این با داشتن انسانی که در لحظه یک تصمیم غلط را متوقف می‌کند، متفاوت است. اخیراً شرکت‌هایی که در حوزه‌های IT، DevOps، جریان‌های کاری Vibe Coding یا تصمیمات مدیریتی در صنایع تحت نظارت رگولاتورها فعالیت می‌کنند، نظارت لحظه‌ای را به عنوان یک راهکار موقت معماری (Architectural stopgap) پیاده کرده‌اند. این پیچیدگی‌های عملیاتی در پیاده‌سازی عامل‌ها می‌تواند هزینه‌های سرور را به شدت افزایش دهد؛ چنان‌که بخش کوچکی از اجرای عامل‌های هوش مصنوعی، حجم قابل توجهی از هزینه‌های کل را به خود اختصاص می‌دهند.
آکاش تاکور (Akash Thakur)، معمار SRE و مهندس قابلیت اطمینان AI در کانادا، توضیح می‌دهد که مدل تنها یک جزء از یک جریان کاری بزرگ‌تر است. به باور او، مشکل اصلی خودِ مدل نیست، بلکه نحوه برخورد سیستم با عدم قطعیت یا اشتباه مدل است. HITL در واقع یک سیستم ممیزی لحظه‌ای است تا اشتباهات را پیش از آنکه مشتری یا رگولاتور متوجه شوند، شکار کند.
تلهٔ امتیاز اطمینان
دانیل گمبر (Daniel Gamber)، مدیرعامل پلتفرم پردازش اسناد Cambrion، معتقد است رایج‌ترین نقص در سیستم‌های HITL، استفاده از «امتیاز اطمینان» (Confidence Score) خودِ مدل به عنوان تنها محرک برای ارجاع به انسان است. گمبر استدلال می‌کند که امتیازات اطمینان، دقیقاً چیز اشتباهی را اندازه می‌گیرند:
- امتیاز اطمینان نشان می‌دهد که ماشین توانسته متن را بخواند.
- اما نشان نمی‌دهد که عدد یا حقیقت حاصل، واقعاً درست است یا خیر.
تاکور این وضعیت را یک «نقطه کور قابلیت اطمینان» می‌نامد و تأکید می‌کند که «اطمینان مدل با درست بودن یکی نیست». اگر مدلی در حالی که اشتباه می‌کند، با اطمینان بالا پاسخ دهد، از آستانه‌ای که باعث ارجاع به انسان می‌شود عبور می‌کند و بدون هیچ هشدار قرمز، به دست مشتری یا رگولاتور می‌رسد. در این حالت، «احساس درونی» مدل به درستی، تبدیل به یک ریسک و نقطه ضعف می‌شود. علاوه بر این، تاکور هشدار می‌دهد که بررسی‌های انسانی اگر درست پیاده نشوند، حتی با وجود هزینه‌ی بالا، نمی‌توانند شرکت را در برابر مسائل قانونی یا عدم انطباق بیمه کنند.
طراحی ارجاع مؤثر
آسیم حسین (Asim Husain)، هم‌بنیان‌گذار Alterion و معاون سابق مهندسی گوگل، پیشنهاد می‌کند که ارجاع نباید دوتایی (صفر و یک) باشد. او چهار پاسخ خطای متمایز را پیشنهاد می‌کند که سیستم‌های HITL باید برای آن‌ها برنامه داشته باشند:
- اعلان و ادامه (Notify and Proceed): اطلاع‌رسانی به فرد، اما اجازه ادامه فرآیند.
- پوشاندن و ادامه (Mask and Proceed): ماسک کردن بخش‌های حساس داده و ادامه مسیر.
- توقف برای تأیید (Hold for Approval): متوقف کردن کامل فرآیند تا زمان تأیید انسانی.
- قرنطینه (Quarantine): قطع کامل جلسه (Session) و توقف عملیات.
پاسخ ایده‌آل به میزان تحمل ریسک سازمان بستگی دارد که باید در طراحی سیستم لحاظ شود. همچنین، دقت در این مورد که «چه کسی» هشدار را دریافت کند ضروری است. حسین اشاره می‌کند که یک تغییر مخرب در پایگاه‌داده باید به تیم پلتفرم یا تیم امنیتی که مالک آن سیستم است ارجاع شود. در مقابل، یک تراکنش مالی بالاتر از یک حد مشخص باید به کسی ارجاع یابد که کنترل تراکنش‌ها را در اختیار دارد.
موانع انطباق و سوگیری
قانون هوش مصنوعی اتحادیه اروپا (EU AI Act)، که توسعه‌یافته‌ترین قانون در این حوزه است، «نظارت قابل اثبات» (Demonstrable oversight) را یک شرط اصلی برای انطباق می‌داند. طبق این قانون، سیستم‌های AI پرریسک که الزامات اساسی امنیت سایبری افقی را برآورده می‌کنند، در صورتی منطبق شناخته می‌شوند که دستیابی به این الزامات در اظهارنامه اتحادیه اروپا اثبات شده باشد.
حسین تأکید می‌کند که کلمه «قابل اثبات» بار سنگینی دارد. این یعنی سازمان باید بتواند در دادگاه یا پیش رگولاتور ثابت کند که نظارت واقعی با یک ردپای ممیزی (Audit Trail) از شواهد فیزیکی داشته است. این امر مستلزم آموزش ناظران انسانی است تا خروجی AI را به طور فعال به چالش بکشند و سوابق دقیقی از این موضوع نگه دارند که آیا خروجی تغییر یافته است یا همان‌طور که بود ارسال شده است.
همچنین ریسک «تأیید صوری» (Rubber-stamping) وجود دارد. تاکور هشدار می‌دهد که اگر ناظر انسانی هرگز تصمیم سیستم را تغییر ندهد، این دیگر نظارت نیست. ناظران اغلب صدها مورد را به صورت پیش‌فرض تأیید می‌کنند چون زمان یا بستر لازم برای قضاوت ندارند و صرفاً برای سرعت بخشیدن به کار، تأیید می‌کنند.
سوگیری سیستماتیک و داده‌های جایگزین
حتی با نظارت انسانی، سوگیری‌های ارث رسیده از مدل‌ها تهدیدی جدی هستند. گزارش سال ۲۰۲۴ دفتر حسابرسی دولت آمریکا (GAO) درباره سیستم انتخاب ممیزی خودکار IRS نشان داد که مؤدیان سیاه‌پوست ۳ تا ۵ برابر بیشتر از سایرین ممیزی شده‌اند، در حالی که سیستم هیچ فیلد مستقیمی برای «نژاد» نداشت.
پژوهشگران استنفورد پیشنهاد کردند که این نابرابری احتمالاً از دو عامل نشأت گرفته است:
- بررسی سخت‌گیرانه اعتبارات مالیاتی درآمد کسب‌شده (Earned Income Tax Credit) که توسط خانواده‌های کم‌درآمد و متوسط درخواست شده بود.
- رویه رایج ثبت شخصی اظهارنامه‌های مالیاتی.
سازمان IRS در گزارش سالانه ۲۰۲۴ خود این موضوع را پذیرفت و متعهد شد سیستم‌های خود را برای رفع این سوگیری بازسازی کند.
مسیر رسیدن به صحت از طریق مبنی‌سازی
برای حل این مشکلات، برخی پلتفرم‌ها به سمت مبنی‌سازی (Grounding) می‌روند. مبنی‌سازی — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — یعنی مدل را مجبور کنیم پاسخ‌ها را فقط از یک منبع معتبر استخراج کند. اریک وان (Eric Vaughan)، مدیرعامل IgniteTech، این روش را در محصولات خود یعنی MyPersonas و Eloquens AI پیاده کرده است؛ به این صورت که مدل دستور دارد هر پاسخی را که در پایگاه دانش موجود شرکت نیست، برای نظارت انسانی ارجاع دهد.
وان معتقد است AI نباید برای راضی کردن کاربر هر پاسخی بدهد، بلکه باید محدود به یک بدنه دانش تعریف‌شده باشد و در صورت نبود اطلاعات به طور صریح، از پاسخ دادن خودداری کند. او موفقیت را با «صحت مبنی‌سازی» (Grounding accuracy) می‌سنجد که در سیستم‌های او در محدوده ۹۰ تا ۹۵ درصد است.
به همین ترتیب، Cambrion اسنادی را که مقادیرشان در منبع اصلی یافت نمی‌شود یا در بررسی‌های داخلی ناسازگار هستند، ارجاع می‌دهد. مثال‌هایی از این محرک‌ها عبارتند از:
- اسنادی با تاریخ‌های متناقض.
- امضاهای مفقود.
- محاسبات مالیاتی که با هم همخوانی ندارند و جمع نمی‌شوند.
شخصی‌سازی آستانه‌های ریسک
پس از مبنی‌سازی، ارجاع باید با آستانه‌های ریسک داخلی سازمان مطابقت داشته باشد. حسین توضیح می‌دهد که حد تراکنش ۱۰۰۰ دلاری برای یک بانک منطقه‌ای با یک خرده‌فروش Fortune 50 کاملاً متفاوت است.
پلتفرم Innovaccer Gravity که مدیریت مزایای مراقبت‌های پزشکی را خودکار می‌کند، به مشتریان اجازه می‌دهد هر نقطه از حلقه نظارت را خودشان تنظیم کنند. برای مثال، مراکز درمانی می‌توانند در هر مرحله از زنجیره ارجاع به درمان، بررسی کارکنان را اضافه کنند، به جای اینکه یک مدل ثابت و غیرقابل کنترل را بپذیرند.
مسئولیت‌پذیری و حفاظ‌های نهایی
در نهایت، مکانیسم‌هایی مثل مبنی‌سازی، تأیید اجباری، ارجاع هوشمند و ردپای ممیزی برای این هستند که اطمینان حاصل شود برای هر تصمیم سرنوشت‌ساز، یک «شخص» مسئول است. به قول وان: «AI قابلیت‌ها را شتاب می‌دهد، نه مسئولیت‌پذیری را». مدل‌ها تمایل دارند به جای پذیرش نادانی، پاسخ دهند و همین موضوع حفاظ‌های انسانی را ضروری می‌کند.
پلتفرم Nominal، که یک پلتفرم خودکار حساب‌های پرداختنی است، مثالی عملی از این رویکرد است. این سیستم داده‌ها را از دفاتر تجاری می‌گیرد و با یک مدل اختصاصی با منطق سفارشی تحلیل می‌کند، اما پیش از هر تراکنش واقعی، تأیید انسانی اجباری است. در این مدل، AI لایه‌ای از زمینه (Context) را برای ناظر فراهم می‌کند، نه اینکه انتقال وجه را روی حالت خلبان خودکار اجرا کند.
سازمان‌ها باید اکنون جریان‌های کاری AI خود را ممیزی کنند تا ببینند آیا به امتیازات اطمینان متکی هستند یا مبنی‌سازی واقعی. گام بعدی احتمالاً استانداردسازی «ردپای ممیزی» به عنوان یک الزام قانونی برای تمام استقرارهای پرریسک AI در سازمان‌ها خواهد بود.
گام بعدی شما
- بررسی کنید آیا سیستم‌های AI شما از Confidence Score برای ارجاع به انسان استفاده می‌کنند یا از Grounding (مبنی‌سازی) بر اساس داده‌های مرجع.
- برای فرآیندهای پرریسک، مدل «تأیید اجباری» (Mandatory Approval) را جایگزین «اعلان و ادامه» کنید.
- یک ردپای ممیزی (Audit Trail) برای تغییرات انسانی در خروجی‌های AI ایجاد کنید تا در صورت بازرسی‌های قانونی، مدرک داشته باشید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو