یک پیشنهاد برای کوتاه‌کردن مسیر
مدیر عملیات به پاسخ نمونه روی نمایشگر اشاره کرد؛ همان پاسخی که به کارمند می‌گفت ثبت درخواست خرید در اختیار واحد او نیست.
گفت: «اگر قراره آخرش همین رو بفهمیم، چرا از اول مسیر رو کوتاه نکنیم؟ دستیار مبلغ رو ببینه، مقررات رو بررسی کنه و اگر مجاز نبود، درخواست رو برگردونه.»
مدیر فناوری پرسید: «یعنی فقط توضیح بده که نیاز به بررسی داره یا واقعاً جلوی ادامهٔ درخواست رو بگیره؟»
«اگر معلومه مجاز نیست، دیگه چرا چند نفر بررسی کنن؟»
مدیر مالی دستش را روی سه سند گذاشت. «تا چند دقیقه پیش داشتیم اعتبار همین‌ها رو روشن می‌کردیم. حالا می‌خوایم جواب دستیار، اختیار رد درخواست هم داشته باشه؟»
مدیر عملیات گفت: «من دارم پیشنهاد می‌دم. اگر قابل اتکا باشه، می‌تونه کار رو سریع‌تر کنه.»
مسئول ریسک و انطباق پرسید: «چه کسی قابل اتکابودنش رو برای این کار تأیید می‌کنه؟ اگر اشتباه کرد، چه کسی می‌تونه تصمیمش رو برگردونه؟»
مدیرعامل عنوان تازه‌ای زیر برگهٔ منشور نوشت: «پیشنهاد افزایش اختیار».
گفت: «این دیگه فقط بهترکردن جواب نیست. داریم دربارهٔ واگذاری بخشی از تصمیم حرف می‌زنیم. اول معلوم کنیم چه چیزی رو، با چه شواهدی و تحت نظر چه کسی واگذار می‌کنیم.»
در درس هفتم دیدیم که ریسک را باید با توجه به پیامد، شدت، گستره، برگشت‌پذیری و امکان اعتراض سنجید. حتی پاسخ متنیِ دستیار می‌تواند بر تصمیم کاربر اثر بگذارد.
پیشنهاد مدیر عملیات، گفت‌وگو را از اثر پاسخ به واگذاری اختیار برده است: آیا دستیار می‌تواند خودش درخواست را برگرداند؟ این تغییر در شرح قابلیت، مسئولیت تازه‌ای برای سازمان ایجاد می‌کند. «پاسخ بدهد»، «پیشنهاد بدهد» و «درخواست را رد کند» به شواهد و نظارت یکسانی نیاز ندارند. حالا باید ارزیابی اثر را به حدود روشن اختیار وصل کنیم.
این درس، اسلایدهای ۴۵ تا ۴۸ را به ترتیب دنبال می‌کند و بخش سوم دوره را به پایان می‌رساند: از پاسخ عمومی تا تصمیم اجرایی، طبقات ریسک، شواهد متناسب با اختیار و ماتریس ریسک دستیار سازمانی.
از پاسخ عمومی تا تصمیم اجرایی، مسئولیت تغییر می‌کند
برای توصیف نقش دستیار در فرایند، چهار وضعیت را جدا می‌کنیم. این‌ها طبقات ثابت ریسک نیستند؛ یک پاسخ متنی در موضوع حساس می‌تواند پرریسک‌تر از یک اقدام خودکار محدود و برگشت‌پذیر باشد.
| وضعیت استفاده | نقش سامانه | انتظار از کنترل |
|---|---|---|
| اطلاع‌رسانی و پاسخ‌گویی | یافتن یا توضیح اطلاعات عمومی یا تخصصی | اعتبار منبع، رعایت دسترسی و روشن‌بودن حدود پاسخ |
| پیشنهاد و توصیه | ارائهٔ گزینه یا توصیه برای بررسی | امکان بررسی، رد یا اصلاح و دسترسی به مبنای مرتبط |
| پشتیبانی از تصمیم | تأمین خروجی‌ای که در تصمیم رسمی انسان نقش مشخص دارد | ارزیابی اثر، ثبت مبنا، مسئول تصمیم و امکان اعتراض |
| تصمیم و اقدام خودکار | تعیین نتیجه یا اجرای اقدام در دامنهٔ تفویض‌شده | اختیار مصوب، کنترل مستقل عملیات، پایش و شرایط توقف و رسیدگی |
مرز این سطح‌ها را باید در فرایند واقعی دید. اگر عنوان خروجی «پیشنهاد» باشد، اما کارکنان موظف باشند آن را بدون بررسی اجرا کنند، عنوان به‌تنهایی نقش تصمیم‌گیرانهٔ سامانه را محدود نمی‌کند. باید معلوم باشد انسان واقعاً چه چیزی را بررسی می‌کند و چه اختیار عملی برای تغییر نتیجه دارد.
مدیر فناوری گفت: «می‌تونیم دو گزینه بنویسیم. در اولی، دستیار می‌گه درخواست به بررسی مرجع بالاتر نیاز داره. در دومی، خودش درخواست رو برمی‌گردونه.»
مدیر مالی گفت: «در اولی هنوز باید روشن باشه چه کسی بررسی می‌کنه. در دومی، باید اختیار برگردوندن رو هم جدا تصویب کنیم.»
مدیرعامل گفت: «همین تفاوت رو در صورت‌جلسه بیاریم. تصویب دستیار پاسخ‌گو، تصویب رد خودکار درخواست نیست.»
پیشنهاد مدیر عملیات کنار گذاشته نشد؛ به تصمیمی جداگانه تبدیل شد که باید درباره‌اش شواهد جمع می‌کردند.
طبقهٔ ریسک را از روی نام سامانه تعیین نکنیم
چارچوب قانون هوش مصنوعی اتحادیهٔ اروپا، کاربردها را در چهار طبقهٔ ریسک معرفی می‌کند:
- ریسک غیرقابل قبول: برخی کاربردهای آسیب‌زا ممنوع‌اند؛ افزایش دقت، مجوز ادامهٔ همان کاربرد را ایجاد نمی‌کند.
- ریسک بالا: برخی کاربردهای اثرگذار بر ایمنی، حقوق و فرصت‌های مهم، الزامات سخت‌گیرانه دارند؛ از جمله در بعضی استفاده‌های استخدامی، آموزشی و خدمات ضروری.
- ریسک محدود: برای برخی تعامل‌ها و محتواهای هوش مصنوعی، شفافیت دربارهٔ مواجهه با سامانه یا محتوای تولیدشده اهمیت دارد.
- ریسک حداقلی: کاربردهای کم‌خطر، معمولاً مشمول الزامات ویژهٔ این قانون نیستند.
این طبقه‌بندی به چارچوب حقوقی اتحادیهٔ اروپا مربوط است و جهان‌شمول نیست. همچنین، داشتن رابط گفت‌وگو به‌تنهایی ثابت نمی‌کند کاربرد کم‌خطر است؛ یک دستیار می‌تواند در فرایندی حساس به کار گرفته شود. برای تعیین الزامات حقوقی، باید کاربرد مشخص و مقررات مربوط به آن بررسی شوند.
نام «دستیار» سطح مراقبت را تعیین نمی‌کند. باید بدانیم سامانه در چه موضوعی استفاده می‌شود، چه اثری دارد و چه اختیاری به آن داده‌ایم.
این نگاه، پرسش مدیرعامل را تغییر می‌دهد. به‌جای اینکه فقط بپرسد «آیا استفاده از دستیار تصویب شده؟»، باید بپرسد «کدام استفاده، برای کدام تصمیم و تحت چه شرایطی تصویب شده است؟»
مدیر عملیات پرسید: «پس برای همهٔ سؤال‌ها یک مسیر تأیید نمی‌ذاریم؟»
مسئول ریسک و انطباق گفت: «پیدا کردن نشانی یک فرم، با توصیه دربارهٔ تعهد مالی یا تصمیم دربارهٔ یک فرد، یکسان نیست.»
مدیر منابع انسانی گفت: «حتی در واحد ما هم اعلام ساعت مراجعه با ارزیابی شرایط یک کارمند فرق داره.»
مدیرعامل گفت: «پس موضوع‌های استفاده رو جدا ثبت کنیم. یک برچسب کلی برای همهٔ دستیار کافی نیست.»
با افزایش اختیار، چه شواهد و نظارتی لازم است؟
پس از شناخت طبقات ریسک، باید حدود اختیار را به انتظار از ارزیابی و نظارت وصل کنیم.
برای تعیین شواهد و نظارت لازم، چهار سطح «اطلاع‌رسانی و پاسخ‌گویی»، «پیشنهاد و توصیه»، «پشتیبانی از تصمیم» و «تصمیم و اقدام خودکار» را در نظر می‌گیریم.
| سطح استفاده | شواهد مورد نیاز | نظارت و کنترل |
|---|---|---|
| اطلاع‌رسانی و پاسخ‌گویی | آزمون کارکرد و بررسی محتوای منابع | اعلام ماهیت ماشینی پاسخ و ثبت استفاده و بازخورد |
| پیشنهاد و توصیه | سنجش کیفیت خروجی و بررسی سناریوهای رایج | بازبینی موارد مهم و امکان رد یا اصلاح پیشنهاد |
| پشتیبانی از تصمیم | معیار موفقیت روشن، بررسی خطا، سوگیری و پایداری و تحلیل اثر | انسانِ تصمیم‌گیر نهایی، ثبت منطق و مسیر تصمیم و امکان اعتراض و رسیدگی |
| تصمیم و اقدام خودکار | شواهد قوی دربارهٔ ایمنی و اثربخشی، سناریوهای شکست و حدود توقف | تأیید رسمی، اختیار مشخص، پایش مستمر و امکان توقف فوری و بازگشت |
در پروندهٔ ما، پاسخ‌دادن به چند سؤال متداول، به‌تنهایی شواهد لازم برای ردکردن درخواست خرید را فراهم نمی‌کند. برای این اختیار تازه باید وضعیت‌های مرتبط بررسی شوند: تعارض سند، اطلاعات ناقص درخواست، نیاز به استثنا و حالتی که تعیین تکلیف به مرجع دیگری تعلق دارد.
نظارت انسانی هم باید در خود فرایند معنا داشته باشد. اگر بازبین فقط یک نتیجه را ببیند و به منبع، دلیل و اطلاعات مرتبط دسترسی نداشته باشد، بررسی او محدود خواهد بود. اگر اختیار اصلاح یا ارجاع نداشته باشد، حضورش در مسیر به معنای کنترل مؤثر تصمیم نیست.
همچنین، تأیید انسانی باید به مسئولیت مشخص وصل باشد. چه کسی صلاحیت و اختیار بررسی دارد؟ چه مواردی به او ارجاع می‌شوند؟ تصمیم و دلیل آن کجا ثبت می‌شود؟ اعتراض را چه کسی پیگیری می‌کند؟
شرح فنیِ اتصال این حدود به هویت مأموریت، مجوز ابزار، توقف و ارزیابی مستقل را می‌توان در ZTAI برای عامل‌های خودکار؛ اختیار محدود در تمام مسیر اجرا دنبال کرد.
این‌ها همان کلاه‌های مسئولیت‌اند. ممکن است یک نفر چند کلاه داشته باشد یا چند نفر در انجام یک مسئولیت همکاری کنند. لازم است مسیر کار و اختیار پاسخ‌گویی روشن باشد؛ زیادکردن عنوان‌ها، جای این توافق را نمی‌گیرد.
مدیر فناوری گفت: «می‌تونیم قبل از برگشت درخواست، دکمهٔ تأیید مدیر بذاریم.»
مدیر مالی پرسید: «مدیر چی می‌بینه؟ فقط پیشنهاد برگشت رو یا دلیل، منبع و شرایط درخواست رو هم؟»
«باید اون‌ها رو هم ببینه.»
مسئول ریسک و انطباق پرسید: «اگر با پیشنهاد موافق نبود، می‌تونه اصلاحش کنه یا برای بررسی بفرسته؟»
مدیرعامل گفت: «همین‌ها رو بنویسیم. اسمش رو تأیید انسانی نذاریم و از کنارش رد نشیم. باید معلوم باشه بررسی‌کننده چه می‌دونه و چه اختیاری داره.»
برای یک دستیار، چند نوع استفاده تعریف کنیم
ماتریس پایانی، همهٔ بحث را به پروندهٔ دستیار برمی‌گرداند. محور عمودی، اثر و ریسک است؛ محور افقی، سطح اختیار یا اتکا. این کنارهم‌گذاشتن مهم است: حتی پیش از واگذاری اقدام مستقیم، اتکای زیاد به پاسخ می‌تواند نقش آن را در تصمیم پررنگ کند.
در تصویر، پاسخ عمومی در ناحیهٔ پایین‌تر قرار گرفته است. سپس کاربردهای منابع انسانی، حقوقی و قراردادی و در نهایت تصمیم اجرایی دیده می‌شوند.
این جایگاه‌ها راهنمای بررسی‌اند، نه حکم ثابت دربارهٔ همهٔ سؤال‌های هر واحد. یک سؤال عمومی دربارهٔ منابع انسانی با ارزیابی استخدام یا تصمیم دربارهٔ مزایای فرد یکسان نیست. در حوزهٔ قرارداد نیز پیدا کردن نشانی یک بند، با تفسیر تعهد و توصیه به پذیرش آن تفاوت دارد.
برای پروندهٔ خرید، می‌توان همین تمایز را به چهار استفادهٔ مشخص تبدیل کرد:
- دستیار، محل فرم و مرجع مقررات خرید را نشان دهد.
- دربارهٔ قاعدهٔ مرتبط با درخواست، با ذکر منبع توضیح بدهد.
- ارجاع درخواست به مرجع بالاتر را برای بررسی پیشنهاد کند.
- درخواست را تأیید، رد یا به‌طور رسمی در مسیر دیگری قرار دهد.
ممکن است همهٔ این قابلیت‌ها زیر یک نام و در یک محیط عرضه شوند، اما تصویب و ارزیابی آن‌ها را نباید یکجا انجام داد. سازمان می‌تواند یک استفاده را در دامنه‌ای محدود بپذیرد و استفادهٔ دیگری را تا فراهم‌شدن شواهد و کنترل‌های لازم، مجاز نداند.
خروجی این بحث باید قابل رجوع باشد. برای هر استفاده، باید بتوانیم بگوییم موضوع چیست، خروجی چه اثری دارد، چه کسی بر آن تکیه می‌کند، حد اختیار سامانه کجاست و چه کسی مسئول تأیید، رسیدگی یا توقف است.
مصوبه‌ای که حدودش معلوم بود
مدیرعامل برگهٔ منشور را به سمت خود کشید.
گفت: «برای نسخهٔ فعلی، نشون‌دادن منبع و توضیح مقررات رو در دامنهٔ آزمایش نگه می‌داریم. موارد مبهم یا متعارض هم باید برای بررسی ارجاع بشن.»
مدیر عملیات پرسید: «پیشنهاد کوتاه‌کردن مسیر چی می‌شه؟»
«باقی می‌مونه. ولی رد خودکار درخواست، فعلاً جزو اختیار این نسخه نیست. برای اون باید جدا شواهد و مسئولیت‌ها رو بررسی کنیم.»
مدیر مالی گفت: «و پیشنهاد ارجاع هم باید معلوم باشه چه کسی تأییدش می‌کنه.»
مسئول ریسک و انطباق به صورت‌جلسه اشاره کرد: «حدود استفاده و مسئول رسیدگی رو همین‌جا ثبت کنیم.»
مدیر فناوری گفت: «پس این حدود باید در خود سامانه هم قابل اجرا باشه. فقط نوشتنش در صورت‌جلسه کافی نیست.»
مدیرعامل پرسید: «برای اینکه منابع معتبر، دسترسی‌ها و همین حدود اختیار واقعاً تحت کنترل ما بمونن، سامانه رو چطور باید تهیه و اداره کنیم؟»
این بار، بحث به انتخاب شیوهٔ ساخت و تأمین دستیار رسیده بود؛ با تصویری روشن‌تر از آنچه سازمان می‌خواست تحت کنترل نگه دارد.
با این درس، بخش سوم پایان می‌یابد. در درس بعد، از اسلاید ۴۹ وارد بخش چهارم، «معماری، داده و تأمین‌کننده»، می‌شویم. پرسش مدیریتی آن بخش این است که انتخاب شیوهٔ ساخت و تأمین، چه اثری بر کنترل، مسئولیت و امکان ادارهٔ دستیار دارد.
این درس، هشتمین درس مجموعهٔ «حکمرانی هوش مصنوعی در سازمان» و تشریح اسلایدهای ۴۵ تا ۴۸ دوره است. درس قبل: خطای هوش مصنوعی برای چه کسی گران تمام می‌شود؟؛ اسلایدهای کامل دوره
منبع توضیح طبقات ریسک: معرفی قانون هوش مصنوعی در وب‌سایت کمیسیون اروپا.