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