مرز تأیید: قضاوت انسانی دقیقاً کجا لازم است

«تأیید انسانی اضافه کنید» طراحی ایمنی نیست؛ آغاز طراحی است.

وقتی درخواست مبهم، شاهد پنهان، action از قبل اجراشده یا هزینه رد بیشتر از قبول بی‌فکر باشد، انسان oversight واقعی ندارد. promptهای کم‌ارزش و تکراری نیز به reviewer یاد می‌دهند approval تشریفاتی است. ممکن است انسان در حلقه باشد اما زمان، اطلاعات، صلاحیت یا اختیار تغییر نتیجه را نداشته باشد.

هدف، مداخله مؤثر در نقطه‌ای است که پیامد و عدم قطعیت قضاوت را توجیه می‌کنند. بعضی گام‌ها باید خودکار باشند. بعضی با نمونه‌برداری یا صف exception بررسی شوند. بعضی approval هم‌زمان، reviewer دوم یا اجرای مستقیم انسان می‌خواهند. مرز از action و context می‌آید، نه یک threshold عمومی confidence.

پیش از checkpoint، تصمیم را طبقه‌بندی کنید

هر action را در شش بُعد بسنجید:

1. اثر: پول، ایمنی، حق، اعتبار، دسترسی یا طرف بیرونی.
2. برگشت‌پذیری: آیا نتیجه کامل و سریع قابل‌لغو است.
3. عدم قطعیت: شاهد مفقود، متعارض، کهنه یا خارج توزیع.
4. دامنه: یک رکورد، مشتری، batch یا کل سامانه.
5. قابلیت کشف: آیا خطا پیش از گسترش زیان دیده می‌شود.
6. اختیار: آیا policy یا قانون انتخاب را برای فرد واجدصلاحیت نگه می‌دارد.

سپس mode اجرا را تعیین کنید:

«قابل‌برگشت» را آزادانه تفسیر نکنید. email از mailbox فرستنده پاک می‌شود اما از ذهن گیرنده نه. پست عمومی حذف می‌شود اما screenshot باقی می‌ماند. refund شاید در عملیات برگردد ولی زیان حقوقی یا تجربه مشتری بسازد.

هسته چارچوب مدیریت ریسک هوش مصنوعی NIST تعریف نقش و مسئولیت در پیکربندی انسان–هوش مصنوعی و treatment متناسب با context را پیشنهاد می‌کند. این راهنمای داوطلبانه است، نه شاهد ایمنی یک workflow خاص.

action مشخص را تأیید کنید، نه وعده کلی

approval باید به پارامتر immutable متصل شود:

• operation و target دقیق؛
• فرد، رکورد، فایل یا سامانه متأثر؛
• مبلغ، تعداد، currency، deadline و destination؛
• شاهد استفاده‌شده و شاهد مهم در دسترس‌نبوده؛
• نتیجه policy و exception؛
• عدم قطعیت به زبان task؛
• پیامد approve، reject، delay و escalate؛
• expiry و فیلدی که تغییرش approval را باطل می‌کند.

reviewer که پرداخت €4,800 به Supplier A را تأیید کرده، retry با €5,300 یا bank account دیگر را تأیید نکرده است. action payload را hash یا version کنید. تغییر material باید با diff دیداری به review برگردد.

انتخاب دقیق ارائه کنید:

• فقط همین action را approve کن؛
• فیلد مشخص را edit و validation را تکرار کن؛
• با reason ساختاریافته reject کن؛
• evidence مفقود را بخواه؛
• به role مشخص escalate کن؛
• workflow را stop و permission موقت را revoke کن.

approval نباید action بعدی را پنهانی مجاز کند. اگر خرید هم‌زمان announcement عمومی بفرستد و credential vendor ذخیره کند، scope بیش از حد گسترده است.

راهنمای اتوماسیون شواهد‌محور source، policy، decision و outcome را در packet قابل‌بازبینی به هم متصل می‌کند. چک‌لیست آمادگی تولید AI همین packet را در release و incident control قرار می‌دهد.

decision packet را برای verification بسازید

کوچک‌ترین مجموعه کامل evidence را نشان دهید، نه transcript کامل مدل.

packet مفید پنج بخش دارد:

1. action پیشنهادی: یک جمله و parameter دقیق.
2. چرا اکنون: trigger، deadline و state.
3. شاهد: fact لینک‌شده به source، date و provenance.
4. استثنا: missing field، disagreement، policy deviation و uncertainty.
5. پیامد: چه فرد یا چیزی پس از هر انتخاب تغییر می‌کند.

source evidence را بر rationale مدل مقدم کنید. توضیح روان ممکن است همان خطا را مطمئن‌تر بازگو کند. line invoice، clause قرارداد، test result یا دستور مشتری را نمایش دهید. inference را صریح mark کنید.

progressive disclosure به کار ببرید: fact تصمیم‌ساز ابتدا و trace کامل در دسترس، بدون اجبار به بازسازی task. مقدار تغییرکرده و condition غیرعادی را highlight کنید. اگر تخصص لازم است case را به role درست بفرستید؛ متن بیشتر به فرد نامناسب کمک نمی‌کند.

دسترس‌پذیری نیز شرط oversight است: keyboard، screen reader، نشانه غیررنگی، diff خوانا، عدد و تاریخ localized و زمان کافی. prompt زمان‌داری که پیش از فهم منقضی می‌شود کنترل معنادار نیست.

با اصطکاک هدفمند automation bias را کم کنید

explanation و confidence score خودکار oversight خوب نمی‌سازند. انسان زیر workload و repetition ممکن است بیش از حد به advice تکیه کند.

در آزمایش کنترل‌شده ۲۰۲۱ با ۱۹۹ نفر، Buçinca، Malaya و Gajos نشان دادند cognitive forcing overreliance را کاهش داد، اما طراحی مؤثرتر امتیاز رضایت پایین‌تری گرفت. مطالعه ACM در ۲۰۲۵ درباره partial explanation و cognitive forcing نیز نشان داد interface می‌تواند engagement را بیشتر کند و trade-off دارد. این آزمایش‌ها UI همگانی تجویز نمی‌کنند؛ نشان می‌دهند convenience و decision quality باید جدا سنجیده شوند.

اصطکاک را انتخابی اعمال کنید:

• در تصمیم نادر و پراثر، assessment مستقل reviewer را پیش از advice مدل بگیرید؛
• مقایسه با یک alternative قابل‌قبول بخواهید؛
• recommendation را تا دیدن evidence حیاتی پنهان کنید؛
• برای override policy یا قبول evidence ناقص reason بخواهید؛
• review کم‌ریسک را batch یا rotate کنید تا توجه حفظ شود؛
• diagnostic time-out را برای مورد abnormal بگذارید، نه همه caseها.

checkbox صرفاً برای ساخت trail حقوقی اضافه نکنید. friction بدون اطلاعات تأخیر می‌سازد، نه قضاوت.

confidence را برای task کالیبره کنید

probability مدل با احتمال ایمن بودن action یکی نیست. مدل ممکن است classification را مطمئن بگوید، در حالی که source کهنه، user فاقد authority یا payload تغییرکرده است.

routing باید این عوامل را ترکیب کند:

• عملکرد مدل روی release set نماینده همان task؛
• کیفیت و تازگی داده؛
• نتیجه policy validation؛
• novelty یا فاصله از مورد عادی؛
• impact و reversibility؛
• عملکرد subgroup یا context در جای مرتبط؛
• disagreement حل‌نشده میان مدل، rule یا source.

probability calibrated را فقط وقتی نشان دهید که برای همان task و population آزموده شده است. در غیر این صورت uncertainty concrete بدهید: «شماره حساب با سه invoice پرداخت‌شده قبلی فرق دارد»، «دو نسخه قرارداد تعارض دارند» یا «آدرس verify نشد». reviewer می‌تواند این‌ها را بررسی کند.

Playbook چارچوب NIST پیشنهاد می‌کند نقش انسان–AI، training، documentation، monitoring و risk response برای context tailor شود. این playbook خود را پیشنهاد داوطلبانه می‌داند، نه checklist یکسان.

صف‌ها را بر اساس تخصص و فوریت جدا کنید

یک queue برای همه exception یعنی routing ضعیف. این موارد را تعریف کنید:

• role واجدصلاحیت reviewer؛
• service-level objective و timeout امن؛
• delegation و absence؛
• conflict-of-interest؛
• امکان edit، approve-only یا escalation؛
• حداکثر batch و حفاظت workload؛
• evidence و reason code لازم؛
• appeal و incident path.

timeout باید safe default داشته باشد. نرسیدن reviewer نباید «نیازمند approval» را به اجرای خودکار تبدیل کند. بر حسب action، timeout hold، cancel، rollback یا escalate می‌کند.

self-review را جایی که designer از approval نفع می‌برد کم کنید. تصمیم مالی، access، employment، medical یا legal ممکن است review مستقل، qualification تخصصی یا two-person control بخواهد.

در context regulated، الزام واقعی را بررسی کنید. ماده ۱۴ قانون AI اتحادیه اروپا می‌خواهد سامانه high-risk در دامنه قانون برای oversight مؤثر طراحی شود؛ رابط باید امکان فهم قابلیت و محدودیت، تشخیص anomaly، پرهیز از over-reliance، interpretation و مداخله یا stop را بدهد. این حکم نمی‌گوید هر feature AI دکمه approval می‌خواهد. compliance به classification، role، تاریخ اجرا و جزئیات حقوقی وابسته است.

پس از approval حلقه را ببندید

بررسی کنید:

• payload اجراشده با payload approved یکسان است؛
• سامانه بیرونی action را یک بار پذیرفته؛
• state مورد انتظار تغییر کرده؛
• reviewer و requester result را می‌بینند؛
• rollback یا remediation هست؛
• side effect غیرمنتظره incident یا review تازه می‌سازد؛
• correction reviewer وارد evaluation می‌شود، نه training خودکار بی‌review.

برای retry از idempotency key و برای proposal، evidence، policy، approval، execution و result از task ID ثابت استفاده کنید. تصمیم‌گیر، role، timestamp، version action، reason و outcome را ثبت کنید. داده حساس log را کمینه و retention و access را کنترل کنید.

reviewer باید feedback بگیرد. اگر action را رد کند و proposal بدون evidence تازه دوباره ظاهر شود، workflow خراب است. اگر action پذیرفته بعداً fail شود، outcome باید training، policy و interface را اصلاح کند.

بسنجید oversight نتیجه را تغییر می‌دهد یا نه

معیارها را بر حسب کلاس action و role نگه دارید:

• approval rate فقط همراه دیگر معیارها؛
• edit rate برای تغییر material؛
• reject و escalation با reason؛
• decision latency شامل tail؛
• reviewer dwell time با تفسیر محتاطانه؛
• post-approval defect؛
• catch rate برای proposal بد متوقف‌شده؛
• miss rate برای proposal بد accepted؛
• false escalation برای مورد routine؛
• override quality و اثر correction انسان؛
• queue load و abandonment؛
• payload integrity؛
• appeal و remediation برای تصمیم مؤثر بر مردم.

approval rate برابر ۹۹٫۸٪ الزاماً خوب نیست. شاید upstream عالی، checkpoint بی‌اهمیت یا reviewer disengaged باشد. نمونه accepted را مستقل audit و در جای مناسب test case کنترل‌شده seed کنید.

نمونه عملی: تغییر حساب بانکی supplier

supplier bank detail تازه را با email می‌فرستد و عامل تغییر vendor master را پیشنهاد می‌کند. action اثر بالا، برگشت‌پذیری کم پس از پرداخت و fraud risk زیاد دارد. عامل می‌تواند request را extract کند اما حق approve یا execute ندارد.

packet حساب قبلی و جدید، supplier record، origin درخواست، contract owner و ناکافی بودن email-only verification را نشان می‌دهد. policy callback به شماره independently stored می‌خواهد، نه شماره داخل پیام. procurement نتیجه verification را ثبت و finance payload hash‌شده را approve می‌کند. سامانه یک بار master را تغییر، مقدار را read-back و هر دو reviewer را مطلع می‌کند. تغییر بعدی approval را باطل می‌کند.

AI کار دفتری را کم می‌کند؛ انسان identity verification و separation of duties را نگه می‌دارد.

ریسک و محدودیت

human review می‌تواند delay، inconsistency، bias و exposure حریم خصوصی اضافه کند. expert هم اشتباه می‌کند. queue understaffed فشار rubber-stamp می‌سازد. reviewer شاید advice مطابق پیش‌داوری خود را انتخابی دنبال کند، نه اینکه همیشه over-trust کند.

oversight را socio-technical system آزمون کنید: کیفیت proposal، evidence presentation، رفتار reviewer، staffing، incentive، policy gateway، execution integrity و appeal path. workflow human-only، AI-only در جای اخلاقاً مجاز و ترکیبی را بر outcome task مقایسه کنید، نه فقط satisfaction.

عبارت «انسان تأیید کرد» نباید accountability را از سازمان designer بردارد. سازمان تعیین می‌کند reviewer چه ببیند، چقدر زمان داشته باشد، چه actionهایی ممکن باشند و پس از click چه رخ دهد.

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

آیا هر پیام بیرونی approval می‌خواهد؟

نه. acknowledgement کم‌ریسک از template مجاز شاید خودکار باشد. گیرنده تازه، داده حساس، commitment، dispute، ادعای حقوقی یا attachment غیرعادی review می‌خواهد.

آیا confidence مدل برای routing کافی است؟

خیر. confidence evaluated را با data quality، policy، novelty، impact، reversibility و authority ترکیب کنید.

چه زمانی recommendation را پنهان کنیم؟

برای تصمیم نادر و consequential که anchoring خطرناک است independent-first را بیازمایید. این کار شاید فکر مستقل را بهتر و زمان و frustration را بیشتر کند.

timeout امن چیست؟

تنظیم همگانی ندارد. action برگشت‌ناپذیر را hold یا cancel کنید. کار safety-critical را به on-call واجدصلاحیت escalate کنید. missed approval نباید permission شود.

منابع — بازبینی در ۳۰ ژوئیه ۲۰۲۶

• هسته AI RMF در NIST و Govern 3.2 درباره نقش انسان–AI
• Playbook چارچوب مدیریت ریسک NIST، به‌روزرسانی ژوئن ۲۰۲۶
• قانون AI اتحادیه اروپا، مقرره 2024/1689 و ماده ۱۴
• Buçinca، Malaya و Gajos درباره cognitive forcing، ACM 2021
• de Jong و همکاران درباره partial explanation، ACM 2025
• Amershi و همکاران، Guidelines for Human-AI Interaction، CHI 2019

چارچوب NIST داوطلبانه است، الزام اتحادیه اروپا به قلمرو و classification وابسته است و پژوهش interaction در taskهای آزمایشی مشخص انجام شده است. این منابع hypothesis طراحی و اولویت آزمون می‌دهند؛ ثابت نمی‌کنند یک UI در همه حوزه‌ها oversight مؤثر می‌سازد.