این درسنامهها بر پایهٔ مباحث و اسلایدهای درس «حکمرانی هوش مصنوعی در سازمان» در دورهٔ DBA هوش مصنوعی در کسب‌وکار دانشگاه تهران تدوین شده‌اند. کلیات موضوع با روایت جلسه‌های یک سازمان و دنبال‌کردن پروندهٔ یک دستیار هوش مصنوعی توضیح داده می‌شوند؛ به زبانی که برای خوانندگان فنی و غیرفنی قابل فهم باشد. مخاطب اصلی مجموعه مدیران سازمان‌ها، به‌ویژه مدیران ارشد و مدیران فناوری اطلاعات (IT) هستند. درس‌ها برای همهٔ کسانی که می‌خواهند نقش هوش مصنوعی و مسئولیت‌های پیرامون آن را در محیط کار بشناسند، چه مدیر باشند و چه نباشند، کاربرد دارند.
محور اصلی مجموعه، طراحی حق تصمیم، مسئولیت و سازوکار ارزیابی در کاربردهای سازمانی هوش مصنوعی است. پروندهٔ یک دستیار سازمانی، مسیر مشترک درس‌ها را می‌سازد؛ در کنار آن، نمونهٔ پیش‌بینی خرابی تجهیزات نشان می‌دهد کدام اصول میان کاربردها مشترک‌اند و کدام ارزیابی‌ها و کنترل‌ها باید متناسب با هر کاربرد تغییر کنند.
از تعریف مسئله و حق تصمیم تا داده، ریسک، معماری، قرارداد و بهره‌برداری پیش رفته و در هر درس، روایت را با توضیح مفاهیم، نکات کلیدی و تمرین همراه می‌شود. طبیعتا این درسنامهها جایگزین کلاس حضوری نیستند. در کلاس، مباحث با مثال‌های عملی و انتقال تجربه بسط داده شده‌اند؛ به همین دلیل، تدریس این مجموعه در مجموع ۱۶ ساعت زمان برده است و امکان برگزاری تخصصی آن برای مجموعه‌هایی که درخواست داشته باشند میسر می‌باشد.
درس اول؛ از درخواست یک دستیار تا تعریف مسئله، دامنه و یک آزمایش قابل ارزیابی.
مطالعهٔ درس: حکمرانی هوش مصنوعی در سازمان از کجا آغاز می‌شود
در اتاق جلسه
چراغ‌های ساختمان‌های روبه‌رو روشن شده بود. روی نمایشگرهای اتاق، نمودارها هنوز بالا و پایین می‌رفتند، اما توجه همه به مدیرعامل بود که کنار نمایشگر ایستاده بود. حتما چیز مهمی بود که همه رو دعوت به جلسه کرده بود. مدیرعامل از جایش بلند شد، یک دست را روی میز گذاشت و گفت:
«تا سه ماه دیگه یک دستیار هوش مصنوعی می‌خوام. چیزی که همه کارکنان بتونن باهاش کار کنن، اطلاعات سازمان رو بشناسه و کارها رو براشون ساده‌تر کنه. نمی‌خوام هر بار برای پیدا کردن یک جواب یا انجام یک کار، چند نفر درگیر بشن.»
مدیر مالی خودکارش را روی دفتر گذاشت. در ذهنش داشت هزینه اشتراک، خرید سرور و نیروی انسانی موردنیاز را حساب می‌کرد.
پرسید: «برای این کار چقدر بودجه در نظر گرفتیم؟ اصلاً قراره محصول آماده بخریم یا هزینه توسعه بدیم؟»
مدیر فناوری سرش را بلند کرد: «بستگی داره. باید مشخص کنیم از سرویس‌های خارجی استفاده می‌کنیم یا مدل رو داخل زیرساخت خودمون مستقر می‌کنیم.»
مسئول امنیت حرفش را قطع کرد: «هنوز معلوم نیست چه اطلاعاتی قراره در اختیارش قرار بگیره. اگر به اسناد سازمان دسترسی داشته باشه، چطور مطمئن بشیم هر کارمند فقط اطلاعات مجاز خودش رو می‌بینه؟»
مدیر منابع انسانی که تا آن لحظه مشغول فکر کردن بود، گفت: «من فکر می‌کنم بهترین نقطه شروع، آموزش کارکنان باشه. مثلاً یک نیروی تازه‌وارد به‌جای اینکه برای هر سؤال سراغ همکارانش بره، از دستیار می‌پرسه. حتی می‌تونه مراحل اداری و فرایندهای داخلی رو بهش یاد بده.»
مدیر مالی برگشت و پرسید: «یعنی فقط جواب سؤال‌ها رو می‌ده؟ نمی‌تونه خودش مثلاً درخواست خرید ثبت کنه یا گزارش هزینه‌ها رو آماده کنه؟»
مدیر فناوری گفت: «اگر بخوایم، می‌تونیم به سامانه‌های داخلی هم متصلش کنیم.»
مدیر امنیت دوباره وارد بحث شد: «پس دیگه فقط بحث دسترسی به اطلاعات نیست. داریم درباره اجازه انجام عملیات در سامانه‌های سازمان صحبت می‌کنیم.»
آن سوی میز، مدیر حقوقی به موضوع دیگری فکر می‌کرد. گفت: «فرض کنید دستیار به یکی از کارکنان توصیه‌ای بکنه و اون کارمند بر اساسش تصمیم اشتباهی بگیره. یا حتی خودش یک اقدام انجام بده. در این صورت مسئولیت با کیه؟ چه کسی باید پاسخ‌گو باشه؟»
یکی از مدیران که تجربه کار با ابزارهای هوش مصنوعی عمومی را داشت، با تردید گفت: «من هنوز به این پاسخ‌ها اعتماد ندارم. چند بار جواب‌هایی گرفتم که با اطمینان کامل بیان می‌شدن، ولی اساساً اشتباه بودن. از کجا معلوم این یکی هم همون‌طور نباشه؟»
مدیر فناوری خواست توضیح بدهد که می‌توان با اتصال دستیار به اسناد معتبر سازمان و کنترل منابع پاسخ، احتمال خطا را کاهش داد؛ اما مدیر امنیت هنوز درباره محرمانگی اطلاعات سؤال داشت و مدیر حقوقی منتظر پاسخ مسئولیت بود.
مدیرعامل به صورت‌های دور میز نگاه کرد. هرکس داشت درباره چیزی حرف می‌زد که به نظر خودش مهم‌ترین بخش دستیار هوش مصنوعی بود. یکی به دنبال کاهش هزینه بود، دیگری افزایش بهره‌وری، یکی نگران اطلاعات محرمانه بود و دیگری به خطا و مسئولیت فکر می‌کرد.
گفت: «ظاهراً من یک دستیار خواستم، ولی شما هرکدوم دارید درباره یک چیز متفاوت صحبت می‌کنید!»
برای چند لحظه سکوت برقرار شد.
مدیر فناوری نگاهی به بقیه انداخت و پرسید:
«شاید قبل از اینکه تصمیم بگیریم چطور بسازیمش، باید اول بفهمیم اصلاً منظورمون از دستیار هوش مصنوعی چیه. دستیار برای انجام چه کاری؟ و قرار است تا کجا اختیار داشته باشه؟»
روایت بالا فقط یک قصه نیست. صورت فشردهٔ موقعیتی است که با ورود هوش مصنوعی به یک سازمان می‌تواند شکل بگیرد: مدیران بر سر آغاز کار توافق دارند، اما از محصول مورد انتظار، حدود استفاده و مسئولیت نتیجه، برداشت مشترکی ندارند.
در این جلسه هنوز مدلی انتخاب نشده، قراردادی امضا نشده و سروری خریداری نشده است. بااین‌حال، تصمیم‌هایی پیش روی سازمان قرار گرفته که بر همهٔ این انتخاب‌ها اثر می‌گذارند.
حکمرانی هوش مصنوعی از همین تصمیم‌ها آغاز می‌شود.
هر واحد بخشی از مسئله را می‌بیند
هشت حوزهٔ به‌هم‌پیوسته در حکمرانی هوش مصنوعی؛ از تعریف مسئله تا قرارداد و ارزیابی.
در نگاه نخست، ممکن است واکنش‌های اعضای جلسه به صورت موانعی در برابر اجرای پروژه دیده شوند: مالی نگران هزینه است، امنیت محدودیت ایجاد می‌کند و حقوقی دربارهٔ مسئولیت سؤال دارد. اما هرکدام بخشی از مسئله‌ای را می‌بینند که برای تصمیم سازمان ضروری است.
سامانه‌ای که از نظر فنی کار می‌کند، ممکن است هزینهٔ بهره‌برداری نامتناسبی داشته باشد. راهکاری که سریع راه می‌افتد، ممکن است به داده‌ای دسترسی بخواهد که استفاده از آن مجاز نیست. پاسخی که برای آموزش عمومی کارکنان مناسب است، ممکن است برای تصمیم دربارهٔ حقوق استخدامی آن‌ها قابل اتکا نباشد.
مسئله و هدف، تصمیم و مسئولیت، داده و دانش، معماری و فناوری، ریسک و کنترل، امنیت و اعتماد، ارزیابی و پایش، و قرارداد و تأمین‌کننده به هم وابسته‌اند. انتخاب در هر بخش می‌تواند گزینه‌های بخش‌های دیگر را تغییر دهد. استفاده از یک خدمت بیرونی، برای مثال، هم بر زمان اجرا اثر دارد، هم بر محل پردازش داده، هزینهٔ مصرف، استمرار خدمت و امکان تغییر تأمین‌کننده.
سازمان باید بتواند میان این ملاحظات تصمیم بگیرد. اگر چنین سازوکاری نداشته باشد، هر واحد بر اساس برداشت خود پیش می‌رود و اختلاف‌ها هنگام اتصال اجزا یا تحویل پروژه آشکار می‌شوند.
مدیرعامل دوباره نشست. رو به مدیر منابع انسانی کرد: «شما از این دستیار چه انتظاری دارید؟»
«پرسنل جدید سؤال‌هاشون رو ازش بپرسن؛ دربارهٔ فرایندها، آیین‌نامه‌ها، کارهای اداری.»
یکی از مدیران گفت: «خوب، اگر آیین‌نامه رو می‌فهمه، درخواست‌ها رو هم بررسی کنه. چرا دوباره بفرستیم برای کارشناس؟»
مسئول امنیت پرسید: «یعنی به پروندهٔ افراد هم دسترسی داشته باشه؟»
مدیر فناوری گفت: «این‌ها دو دامنهٔ متفاوتن.»
هنوز کسی با ساختن دستیار مخالفت نکرده بود. تازه داشت معلوم می‌شد هرکس چه دستیاری را تصور کرده است.
پشت این مسئله‌ها چهار کارکرد قرار دارد
چهار کارکرد راهبری، شناخت زمینه، سنجش و مدیریت با الهام از NIST AI RMF.
برای اداره کردن این مجموعهٔ به‌هم‌پیوسته، به روشی نیاز داریم که پرسش‌ها را به تصمیم و اقدام متصل کند. با الهام از چارچوب مدیریت ریسک هوش مصنوعی NIST، چهار کارکرد را دنبال می‌کنیم:
جهت‌دهی و راهبری: تعیین سیاست‌ها، نقش‌ها، حدود مسئولیت و اختیار.
شناخت زمینه: روشن کردن مسئله، کاربرد، استفاده‌کنندگان، منافع و آثار.
پایش و سنجش: ارزیابی عملکرد، ریسک، اعتمادپذیری و پیامدها.
مدیریت و اقدام: اولویت‌بندی، اعمال کنترل، واکنش و در صورت لزوم توقف.
در NIST AI RMF، این کارکردها مراحل خطی و یک‌بارمصرف نیستند. راهبری در سراسر فعالیت‌های دیگر حضور دارد و شناخت، سنجش و مدیریت نیز با تغییر شرایط بازبینی می‌شوند. NIST AI RMF 1.0، بخش ۵
برای پیوند دادن این بحث به یک پروژه، چهار پرسش پیش روی ماست: چه کاری قرار است انجام شود؟ چه کسی اختیار و مسئولیت آن را دارد؟ با چه معیاری نتیجه را می‌سنجیم؟ و بر اساس نتیجه چه تصمیمی می‌گیریم؟
این رابطه را در همان دستیار می‌توان دید. اگر کاربرد از پاسخ‌گویی عمومی به بررسی وضعیت یک کارمند تغییر کند، باید دوباره دربارهٔ داده‌های مورد نیاز، اثر پاسخ، حدود اختیار و روش ارزیابی تصمیم گرفت.
تأیید کاربرد نخست، به‌خودی‌خود تأیید کاربرد دوم نیست.
مدیرعامل گفت: «قبل از اینکه دربارهٔ خرید حرف بزنیم، روشن کنیم دقیقاً چه کاری ازش می‌خوایم و از کجا می‌فهمیم درست انجامش داده.»
مدیر مالی گفت: «اگر این‌ها معلوم بشه، دربارهٔ بودجه هم می‌شه حرف زد.»
مدیر فناوری گفت: «باید بدونیم از آزمایش چه انتظاری داریم. اینکه چند سؤال بپرسیم و جواب بگیریم، برای تصمیم دربارهٔ ادامهٔ پروژه کافی نیست.»
بحث از اینکه چه کسی موافق یا مخالف هوش مصنوعی است، فاصله گرفته بود. حالا سؤال این بود که سازمان برای جلو رفتن، چه چیزهایی باید بداند.
اولین تصمیم کدام است
پیش از شروع پروژه، کدام تصمیم ابهام اصلی سازمان را برطرف می‌کند؟
انتخاب مدل، تأمین بودجه، تعیین مالک و دامنه، انتخاب پیمانکار، گردآوری داده یا ساخت پایلوت؛ هرکدام می‌تواند در موقعیتی مشخص، تصمیم فوری سازمان باشد. اولویت را باید با توجه به وضعیت پروژه و ابهامی تعیین کرد که مانع پیشروی آن شده است.
در پروندهٔ ما، هنوز توافقی دربارهٔ کارکرد دستیار وجود ندارد. در این وضعیت، مقایسهٔ مدل‌ها می‌تواند بررسی مفیدی باشد، اما نتیجهٔ آن به‌تنهایی تکلیف پروژه را روشن نمی‌کند. مدلی که برای پاسخ‌گویی به پرسش‌های عمومی مناسب است، الزاماً شواهد کافی برای سپردن تصمیم‌های اداری به آن فراهم نمی‌کند.
آزمایش اولیه هم باید مأموریت داشته باشد. سازمان می‌تواند برای شناخت امکان‌پذیری هزینه کند، به شرط آنکه روشن باشد آزمایش قرار است کدام ابهام را برطرف کند و نتیجه‌اش مبنای چه تصمیمی شود.
تعریف مسئله، مالکیت، دامنه و نظام تصمیم‌گیری، مسئولیت‌هایی هستند که خرید فناوری برطرفشان نمی‌کند.
خرید مدل، زیرساخت یا خدمت، جای تصمیم دربارهٔ مسئله، مسئولیت و حدود استفاده را نمی‌گیرد. حتی با دسترسی به فناوری مناسب، سازمان باید این موارد را روشن کند.
ابهام در تعریف مسئله باعث می‌شود هر واحد موفقیت را به شکلی متفاوت بسنجد. ابهام در دامنه، دسترسی و وظایف سامانه را در طول اجرا تغییر می‌دهد. ابهام در مسئولیت هم رسیدگی به اختلاف‌ها و تصمیم دربارهٔ ادامهٔ کار را دشوار می‌کند.
مدیر فناوری لپ‌تاپش را کمی جلو کشید: «می‌تونیم چند راهکار رو بررسی کنیم. ولی اگر هدف پیدا کردن بند آیین‌نامه است، یک جور آزمایش می‌خوایم؛ اگر هدف تأیید و رد درخواسته، یک جور دیگه.»
مدیرعامل پرسید: «برای شروع، کدومش روشن‌تره؟»
مدیر منابع انسانی گفت: «سؤال‌های پرتکرار کارکنان رو داریم. می‌تونیم از همون‌ها شروع کنیم.»
مسئول امنیت اضافه کرد: «با اسناد عمومی داخل سازمان، بدون پروندهٔ شخصی افراد.»
برای نخستین بار، پیشنهادی روی میز بود که می‌شد حدود آن را نوشت.
حکمرانی را به تصمیم‌های قابل اجرا تبدیل کنیم
از نیاز سازمان تا خلق ارزش؛ مسئولیت، دامنه، معیار موفقیت، کنترل و فناوری در یک سازوکار تصمیم‌گیری.
در این مجموعه، حکمرانی هوش مصنوعی را سازوکاری برای تعیین این موضوع می‌دانیم که چه مسئله‌ای، با چه فناوری، تحت مسئولیت چه کسی، در چه محدوده‌ای، با چه کنترل‌هایی و بر مبنای کدام معیار موفقیت حل شود.
این تعریف، بحث را به کار روزمرهٔ مدیران متصل می‌کند. تصویب بودجه، تعیین دسترسی به داده، انتخاب پیمانکار، پذیرش نتیجهٔ آزمون و اجازهٔ بهره‌برداری، باید صاحب اختیار و مبنای مشخص داشته باشند.
مسیر حکمرانی از نیاز سازمان آغاز می‌شود و به حل مسئله و خلق ارزش می‌رسد. میان این دو، مسئولیت، دامنه، معیار موفقیت، کنترل‌ها و فناوری قرار دارند. بازخورد نیز می‌تواند باعث بازنگری هرکدام شود؛ از جمله اینکه مسئله در ابتدا درست تعریف نشده باشد.
این گذار از اصول کلی به ممیزی، گزارش رخداد و امکان مداخله را در حکمرانی هوش مصنوعی در حال عبور از قانون‌نویسی در مقیاس تنظیم‌گری دنبال کرده‌ام؛ در سازمان نیز سیاست باید به تصمیم و اقدام قابل پیگیری برسد.
برای شروع یک آزمایش محدود، لازم نیست همهٔ جزئیات محصول نهایی از پیش معلوم باشند. لازم است حدود همان آزمایش روشن شود: چه داده‌ای در اختیار تیم است، چه کسانی از خروجی استفاده می‌کنند، چه اقدامی مجاز است و چه کسی نتیجه را بررسی می‌کند. سازمان می‌تواند این تصمیم‌ها را با اختیارات و فرایندهای موجود خود بگیرد و هرجا خلأیی دارد، آن را مشخص کند.
مدیرعامل گفت: «پس فعلاً قرار نیست دستیار دربارهٔ درخواست کسی تصمیم بگیره. می‌خوایم ببینیم می‌تونه جواب معتبر رو از آیین‌نامه پیدا کنه و به کارمند نشون بده.»
مدیر حقوقی پرسید: «اگر دو نسخهٔ متفاوت از آیین‌نامه پیدا کرد چی؟»
مدیر منابع انسانی مکث کرد. بعضی دستورالعمل‌ها در پوشهٔ مشترک بود، بعضی با بخشنامهٔ تازه تغییر کرده بود و بعضی را کارکنان هنوز از روی فایل‌های قدیمی می‌خواندند.
گفت: «قبلش باید معلوم کنیم مرجع معتبر کدومه.»
حالا بخشی از کاری که همه از دستیار انتظار داشتند، به تصمیمی دربارهٔ اسناد خود سازمان رسیده بود.
چارچوب‌ها چه کمکی به این تصمیم‌ها می‌کنند
جایگاه متفاوت NIST AI RMF، ISO/IEC 42001 و EU AI Act در تصمیم‌های سازمان.
در این درس سه چارچوب جهانی مورد استفاده قرار گرفته‌اند که تا حدودی با هم همپوشانی دارند. NIST AI RMF، ISO/IEC 42001 و EU AI Act هرکدام از زاویه‌ای متفاوت به ادارهٔ هوش مصنوعی می‌پردازند. NIST AI RMF چارچوبی برای مدیریت ریسک است. ISO/IEC 42001 به استقرار، نگهداری و بهبود نظام مدیریت هوش مصنوعی در سازمان می‌پردازد. EU AI Act نیز مقررهٔ حقوقی اتحادیهٔ اروپا با رویکرد مبتنی بر ریسک است.
در این دوره، از این منابع برای منظم کردن تصمیم‌های سازمان کمک می‌گیریم: شناخت کاربرد، تعیین نقش‌ها، ارزیابی اثر، تعریف کنترل، مستندسازی و بازنگری. استفادهٔ آموزشی از یک مقرره نیز به معنای تعمیم الزام‌های آن به همهٔ سازمان‌ها و کشورها نیست.
نام این چارچوب‌ها زمانی برای پروندهٔ ما مفید می‌شود که در تصمیم واقعی اثر بگذارد. اگر مسئول صحت منابع معلوم نباشد، افزودن نام یک استاندارد به مستند پروژه آن مسئولیت را ایجاد نمی‌کند. اگر آزمون فقط چند پاسخ منتخب را نشان دهد، اشاره به یک چارچوب مدیریت ریسک، جای شواهد ارزیابی را نمی‌گیرد.
برای روشن‌ترشدن تفاوت استاندارد، کنترل و سازوکار اجرا، از STIG و CIS تا RBAC یک نمونهٔ فنی از همین تفکیک در امنیت سیستم‌عامل ارائه می‌کند.
در ادامهٔ دوره، نگاشت این چارچوب‌ها به تصمیم‌های واقعی سازمان را در شش محور بررسی می‌کنیم. اساس حکمرانی هوش مصنوعی در سازمان را در همین شش محور تشریح خواهیم کرد:
حق تصمیم و ساختار حکمرانی: مالک مسئله، نقش‌ها و اختیار تصمیم‌گیری در مراحل مختلف کار.
قلمرو و صورت‌بندی مسئله: مرز کاربرد، کاربران، داده‌ها و کارهایی که سامانه مجاز است انجام دهد.
اثر، ریسک و سطح اختیار: شدت و برگشت‌پذیری پیامدها و میزان اختیار و نظارت متناسب با آن‌ها.
معماری، داده و قابلیت سازمانی: تناسب راهکار با داده‌های موجود، ظرفیت سازمان و نیازهای مقیاس‌پذیری و قابلیت اطمینان.
امنیت، مسئولیت و نظارت انسانی: حفاظت از سامانه، پاسخ‌گویی و امکان مداخلهٔ انسان در تصمیم‌ها و اقدامات آن.
قرارداد، پذیرش و بهره‌برداری: تعهدات تأمین‌کننده، شواهد ارزیابی، شرایط پذیرش، پایش خدمت و امکان خروج از آن.
مدیر مالی پرسید: «برای این بررسی اولیه هم باید یک ساختار جدید درست کنیم؟»
مدیرعامل به یادداشت‌هایش نگاه کرد: «اول با همین مسئولیت‌های فعلی شروع کنیم. ببینیم کجا اختیار یا مسئول مشخص نداریم.»
مدیر حقوقی گفت: «و تصمیم‌هایی که می‌گیریم ثبت بشه. بعداً قرار نیست دوباره دربارهٔ اینکه منظور جلسه چی بوده، بحث کنیم.»
برگه‌ای که قرار بود در آن فقط نام یک پروژه و مهلت تحویل نوشته شود، حالا داشت به صورت‌جلسهٔ چند تصمیم مشخص تبدیل می‌شد.
این پرونده هنوز خام است
پرونده هنوز کامل نشده است؛ هر مدیر بخشی از مسئله را می‌بیند.
درخواست اولیه کمی روشن‌تر شده است. سازمان می‌خواهد امکان پاسخ‌گویی به پرسش‌های پرتکرار کارکنان را با تکیه بر اسناد معتبر بررسی کند. دامنهٔ پیشنهادی، تصمیم‌گیری دربارهٔ اشخاص و دسترسی به پرونده‌های شخصی را در بر نمی‌گیرد.
اما هنوز پرسش‌های مهمی باقی مانده است. چه کسی مالک این مسئله است؟ اعتبار و به‌روزرسانی منابع را چه کسی تضمین می‌کند؟ چه خطاهایی برای این کاربرد مهم‌اند؟ چه شواهدی برای پذیرش آزمایش لازم است؟ و اگر نتیجه مناسب نبود، چه کسی دربارهٔ اصلاح، محدودسازی یا توقف تصمیم می‌گیرد؟
هر مدیر هنوز بخشی از پرونده را در دست دارد. کار حکمرانی این است که رابطهٔ این بخش‌ها را روشن کند و سازمان را قادر سازد بر مبنای آن‌ها تصمیم بگیرد.
در این مرحله، دستاورد جلسه می‌تواند تعریف یک آزمایش محدود و پرسش‌هایی باشد که باید پاسخ بگیرند. آزمایش شاید نشان دهد کیفیت منابع باید اصلاح شود، شاید نیاز به تغییر راهکار را آشکار کند و شاید شواهد کافی برای گسترش خدمت به دست دهد. ارزش آن در این است که نتیجه بتواند تصمیم بعدی سازمان را تغییر دهد.
پایان جلسه
جلسه رو به پایان بود. مدیرعامل مهلت سه‌ماهه را خط نزد، اما کنار آن نوشت: «دامنه و شرایط بهره‌برداری باید مشخص شود.»
بعد گفت: «پیشنهاد آزمایش محدود رو آماده کنید؛ با منابع معتبر، بدون دسترسی به پروندهٔ افراد، و با روشی که بشه نتیجه‌اش رو سنجید.»
مدیر فناوری سر تکان داد. مدیر منابع انسانی پوشهٔ آیین‌نامه‌ها را جلو کشید. مدیر مالی پرسید هزینهٔ این مرحله چه زمانی برآورد می‌شود.
مدیرعامل خودکار را روی میز گذاشت و پرسید: «یک نفر هم باید پیگیر نتیجهٔ این کار باشه. مسئولش کیه؟»
مدیر فناوری به مدیر منابع انسانی نگاه کرد. مدیر منابع انسانی گفت: «ما محتوای کار رو می‌دیم، ولی سامانه دست ما نیست.»
هنوز کسی از اتاق بیرون نرفته بود که مسئلهٔ بعدی روی میز آمد: چه کسی مسئول کدام تصمیم است؟
در این مجموعه، ارجاع به یک چارچوب یا استاندارد به معنای اثبات تجربی برتری همهٔ سازوکارهای پیشنهادی نیست. الزامات منبع، صورت‌بندی‌های آموزشی مدرس و مثال‌های فرضی باید از هم قابل تشخیص باشند. چهار کلاه مسئولیت و هفت دروازهٔ تصمیم، ابزارهای آموزشی این دوره‌اند؛ تعداد و عنوان آن‌ها نسخهٔ واحدی برای همهٔ سازمان‌ها نیست.
این مجموعه بر پایهٔ مباحث دورهٔ «حکمرانی هوش مصنوعی در سازمان» در DBA هوش مصنوعی در کسب‌وکار تدوین شده است. اسلایدهای کامل دوره
درس دوم؛ چهار کلاه مسئولیت، تقسیم نقش‌ها میان افراد و گروه‌ها و پیگیری نتیجهٔ خدمت.
مطالعهٔ درس: چه کسی پاسخ‌گوی دستیار هوش مصنوعی سازمان است
چند هفته بعد، در همان اتاق جلسه
روی نمایشگر، همان دستیار هوش مصنوعی که چند هفته قبل درباره‌اش تصمیم گرفته بودند، در حال پاسخ دادن به پرسش‌های کارکنان بود.
آزمایش اولیه شروع شده بود. دستیار به مجموعه‌ای از آیین‌نامه‌ها و دستورالعمل‌های داخلی متصل شده بود و گروه محدودی از کارکنان می‌توانستند از آن استفاده کنند.
مدیر فناوری چند نمونه از پاسخ‌ها را نشان داد و گفت: «تا اینجا نتایج خوب بوده. سرعت پاسخ‌گویی بالاست و بیشتر کارکنان هم ازش راضی هستن.»
مدیرعامل گفت: «پس می‌تونیم برای گروه بعدی هم دسترسی رو باز کنیم.»
مدیر منابع انسانی که برگه‌ای در دست داشت، گفت: «قبل از اون بهتره این مورد رو بررسی کنیم.»
برگه مربوط به پرسش یکی از کارکنان درباره شرایط دریافت کمک‌هزینه دوره‌های آموزشی بود. دستیار با استناد به یکی از آیین‌نامه‌ها پاسخ مثبت داده بود، اما وقتی کارمند درخواستش را ثبت کرده بود، کارشناسان منابع انسانی اعلام کرده بودند که شرایط دریافت کمک‌هزینه را ندارد.
مدیرعامل پرسید: «پس جواب دستیار اشتباه بوده؟»
مدیر فناوری گفت: «باید بررسی کنیم. ممکنه نسخه‌ای که در اختیار سامانه قرار گرفته به‌روز نبوده باشه، یا مدل شرط مهمی رو در پاسخ در نظر نگرفته باشه.»
مدیر منابع انسانی گفت: «ما همه آیین‌نامه‌هایی رو که خواسته بودید تحویل دادیم. اگر قرار باشه هر بار کارمند به یک پاسخ متفاوت برسه، نمی‌تونیم بهش اعتماد کنیم.»
مسئول امنیت پرسید: «اصلاً چه کسی مسئول بررسی پاسخ‌های این دستیار است؟»
مدیرعامل به مدیر فناوری نگاه کرد: «مگر قرار نبود تیم شما پروژه رو مدیریت کنه؟»
مدیر فناوری گفت: «مدیریت فنی و اجرای پروژه با ماست. اما ما نمی‌تونیم درباره شرایط دریافت کمک‌هزینه یا اعتبار آیین‌نامه‌ها تصمیم بگیریم.»
مدیر منابع انسانی گفت: «ما هم مسئول رفتار مدل نیستیم. اگر سامانه یک بند رو اشتباه تفسیر کرده، باید تیم فنی بررسی کنه.»
مدیر حقوقی که تا آن لحظه ساکت بود، پرسید: «پس اگر کارمند بر اساس همین پاسخ اقدامی انجام بده و متضرر بشه، چه کسی باید پاسخ‌گو باشه؟»
مدیرعامل به صورت‌جلسه جلسه قبلی نگاه کرد. مقابل عنوان «مسئول اجرای آزمایش» نام مدیر فناوری نوشته شده بود. همه می‌دانستند چه کسی پروژه را جلو می‌برد، اما درباره اینکه چه کسی باید صحت پاسخ‌ها را تأیید کند، چه کسی باید به شکایت کاربر رسیدگی کند و چه کسی اختیار توقف یا اصلاح خدمت را دارد، چیزی ثبت نشده بود.
گفت: «ما یک نفر رو مسئول پروژه کردیم. چطور ممکنه هنوز معلوم نباشه مسئول نتیجه کیه؟»
مدیر فناوری پاسخ داد:
«چون مسئول ساختن و راه‌اندازی یک سامانه بودن، با مسئول اداره کردن خدمتی که از اون استفاده می‌کنیم، یکی نیست.»
در درس اول دیدیم که یک درخواست ساده برای ساخت دستیار هوش مصنوعی باید به مسئله، دامنه و آزمایشی قابل ارزیابی تبدیل شود. حالا آزمایش آغاز شده و نخستین مسئله واقعی خود را نشان داده است.
سازمان برای اجرای پروژه مسئول تعیین کرده، اما هنوز معلوم نیست مسئولیت اداره خدمت، اعتبار پاسخ‌ها، رسیدگی به خطا و تصمیم درباره ادامه استفاده چگونه میان افراد و واحدها تقسیم شده است.
این تفاوت، موضوع اصلی این درس است: چگونه مسئولیت را از مرحله ساخت و تحویل سامانه تا استفاده، نظارت و رسیدگی به پیامدهای آن امتداد دهیم؟
پایلوت کار می‌کند اما خدمت هنوز صاحب می‌خواهد
کار کردن اجزا و موفقیت آزمایش، به‌تنهایی سازوکار ادارهٔ یک خدمت را ایجاد نمی‌کند.
پایلوت می‌تواند نشان دهد که راهکار از نظر فنی امکان‌پذیر است: سامانه اسناد را بازیابی می‌کند، پاسخ قابل قبولی می‌سازد و گروهی از کاربران می‌توانند از آن بهره ببرند. اما این شواهد هنوز به این معنا نیست که سازمان آمادهٔ استفادهٔ مستمر از آن به‌عنوان یک خدمت است. با آغاز استفادهٔ واقعی، پرسش‌های تازه‌ای مطرح می‌شوند: چه کسی به‌روز بودن منابع را تضمین می‌کند؟ اگر کاربری به پاسخ اعتراض داشته باشد، چه کسی آن را بررسی می‌کند؟ دسترسی‌ها چگونه تغییر می‌کنند و چه کسی مسئول رسیدگی به اختلال‌ها و خطاهاست؟
این مسئولیت‌ها با پایان توسعه یا تحویل سامانه از بین نمی‌روند. حتی اگر ساخت راهکار به پیمانکار سپرده شده باشد، ادارهٔ خدمتی که کارکنان به آن اتکا می‌کنند همچنان بر عهدهٔ سازمان است. بنابراین باید از ابتدا مشخص باشد چه خدمتی، برای چه گروهی از کاربران، با چه سطحی از پشتیبانی و تحت چه سازوکارهایی اداره خواهد شد. در مقالهٔ قرارداد هوش مصنوعی؛ دقیقاً چه چیزی را باید تحویل بگیریم؟ نشان داده‌ام که چگونه می‌توان بخشی از این مسئولیت‌ها را به تعهدهای قراردادی مشخص دربارهٔ پایش، تغییر نسخه، رسیدگی به خطا و پشتیبانی تبدیل کرد.
برای روشن‌شدن این تفاوت، باید سه وضعیت را از یکدیگر جدا کنیم: ساخته‌شدن اجزای فنی، موفقیت یک راهکار آزمایشی و شکل‌گیری یک محصول قابل استفاده. ممکن است اجزای فنی ساخته شده باشند، اما هنوز نتوانند مسئله‌ای واقعی را برای کاربر حل کنند. ممکن است پایلوت در شرایط کنترل‌شده موفق باشد، اما سازمان هنوز منابع، رویه‌ها و مسئولیت‌های لازم برای پشتیبانی از آن را نداشته باشد. محصول زمانی قابل استفاده است که بتواند مسئله‌ای مشخص را در جریان واقعی کار حل کند و سازمان نیز توان اداره، پایش و اصلاح مستمر آن را داشته باشد.
در پروندهٔ ما، نمایش پاسخ و نام سند فقط بخش قابل مشاهدهٔ سامانه است؛ نه تمام خدمتی که به کاربر ارائه می‌شود. کارمندی که پاسخ مربوط به شرایط دریافت کمک‌هزینه را مبنای اقدام قرار داده، حالا با پاسخی متفاوت از سوی منابع انسانی روبه‌رو شده است. او فقط به یک پاسخ دیگر نیاز ندارد؛ باید بداند اعتراض خود را کجا مطرح کند، چه کسی اختلاف را بررسی می‌کند و کدام پاسخ مبنای اقدام قرار می‌گیرد. اینجاست که تفاوت میان تحویل یک سامانه و پذیرفتن مسئولیت ادارهٔ یک خدمت آشکار می‌شود.
مدیرعامل پرسید: «اگر همین سؤال رو تلفنی از منابع انسانی پرسیده بود، الان چه کار می‌کردیم؟»
مدیر منابع انسانی گفت: «کارشناس مربوط بررسی می‌کرد و اگر لازم بود از مسئول آیین‌نامه استعلام می‌گرفت.»
«پس اینجا هم کارمند باید بدونه به کجا مراجعه کنه.»
مدیر فناوری گفت: «مسیر ارجاع رو می‌تونیم اضافه کنیم. باید مشخص کنید چه کسی درخواست رو می‌گیره و نتیجهٔ بررسی چطور به تیم ما برمی‌گرده.»
برای اولین بار در این جلسه، بحث از درست یا غلط بودن یک پاسخ به شیوهٔ ادارهٔ خدمت رسیده بود.
مسئولیت در سراسر زنجیره امتداد دارد
منشأ خطا و مسئول اصلاح آن را باید در زنجیرهٔ داده، مدل، سامانه، فرایند و اقدام بررسی کرد.
برای رسیدگی به پاسخ مورد اختلاف، باید معلوم شود در کدام بخش از زنجیره چه اتفاقی افتاده است. ممکن است نسخهٔ نامعتبر آیین‌نامه وارد پایگاه دانش شده باشد. ممکن است سامانه سند معتبر را بازیابی کرده، اما شرط مهمی را در پاسخ حذف کرده باشد. ممکن است شرایط پاسخ‌گویی به موارد مبهم اصلاً تعریف نشده باشد یا مسیر ارجاع، هنگام استفاده کار نکند.
هرکدام از این وضعیت‌ها، اقدام اصلاحی متفاوتی می‌خواهد. بررسی صرفِ مدل، مسئلهٔ اسناد نامعتبر را حل نمی‌کند. تغییر فایل‌ها نیز، به‌تنهایی جلوی استنباط نادرست یا گم شدن درخواست کاربر را نمی‌گیرد.
مسئول رسیدگی به نیاز کاربر هم الزاماً همان کسی نیست که جزء معیوب سامانه را اصلاح می‌کند. منابع انسانی می‌تواند مرجع پاسخ رسمی به پرسش کمک‌هزینه باشد، درحالی‌که تیم فناوری مسئول اصلاح رفتار سامانه و متولی اسناد مسئول تعیین نسخهٔ معتبر است. این مسئولیت‌ها باید به هم متصل شوند تا پرونده میان واحدها رفت‌وبرگشت بی‌پایان نداشته باشد.
مسئولیت‌پذیری یعنی هر بخش وظیفهٔ خود را انجام دهد و سازمان بتواند رسیدگی به مسئله را تا حصول نتیجه دنبال کند.
این تقسیم کار، به معنای تعیین مقصر پیش از بررسی نیست. ابتدا باید به کاربر رسیدگی کرد، شواهد را حفظ کرد و منشأ خطا را شناخت. سپس اصلاح و تصمیم دربارهٔ ادامهٔ استفاده، به مسئول و مرجع مربوط سپرده شود.
مدیر منابع انسانی برگه را برداشت: «جواب رسمی این مورد رو ما بررسی می‌کنیم. اما باید بدونیم دفعهٔ بعد هم همین اتفاق می‌افته یا نه.»
مدیر فناوری گفت: «نسخهٔ سند و پاسخ تولیدشده رو بررسی می‌کنیم. اگر سند درست بوده و پاسخ شرطی رو حذف کرده، کار اصلاح سامانه با ماست.»
مسئول ریسک و انطباق پرسید: «تا نتیجهٔ بررسی، دربارهٔ کمک‌هزینه باز هم پاسخ می‌ده؟»
مدیرعامل خواست جواب بدهد، اما مکث کرد. رسیدگی به کارمند، اصلاح سامانه و محدود کردن یک کاربرد، سه تصمیم متفاوت بودند.
چهار کلاه مسئولیت در یک پروژه
در بسیاری از پروژه‌ها، سازمان یک مدیر پروژه یا مسئول اجرا تعیین می‌کند تا فعالیت‌ها، زمان‌بندی و تحویل خروجی را پیگیری کند. این نقش ضروری است، اما جایگزین مالکیت کسب‌وکار، مسئولیت فنی یا مدیریت ریسک نیست. پروژه ممکن است طبق برنامه تحویل شود، درحالی‌که هنوز هیچ‌کس مسئول اداره خدمت، کیفیت نتایج و رسیدگی به کاربران نباشد.
این چهار عنوان، نقش و تعهد را مشخص می‌کنند؛ تعداد افراد و واحدها می‌تواند متفاوت باشد.
برای روشن کردن این مسئولیت‌ها، چهار نقش را از هم تفکیک می‌کنیم. می‌توان آن‌ها را چهار کلاه مسئولیت دانست. هر کلاه مشخص می‌کند چه موضوعی باید پیگیری شود، چه تصمیمی لازم است و چه نتیجه‌ای باید تحویل داده شود.
کلاه مسئولیت
تعهد اصلی
نمونه در پروندهٔ دستیار
حامی اجرایی
فراهم کردن حمایت و منابع، رفع موانع میان واحدها و پشتیبانی از تصمیم‌های کلان
تأمین ظرفیت لازم برای اصلاح منابع و حل اختلاف میان واحدهای درگیر
مالک کسب‌وکار
پیگیری مسئله و ارزش مورد انتظار، تعریف کاربرد و معیار موفقیت، و ادارهٔ فرایند استفاده پس از استقرار
تعیین مرجع پاسخ معتبر، مسیر رسیدگی به پرسش‌ها و سنجش فایدهٔ دستیار برای کارکنان
بررسی بازیابی و تولید پاسخ، اجرای کنترل‌ها، ثبت شواهد و اصلاح رفتار سامانه
مالک ریسک
پیگیری ارزیابی و کاهش ریسک، کنترل حدود تحمل و ارجاع تصمیم‌های مربوط به ریسک باقیمانده
پیگیری خطای مؤثر بر کارکنان و اقدام برای محدودسازی یا ارجاع موضوع طبق اختیار تعیین‌شده
مالک کسب‌وکار در اینجا صاحب مسئله و نتیجهٔ مورد انتظار است. این عنوان دربارهٔ مالکیت حقوقی کد، داده یا محصول صحبت نمی‌کند. مالک فنی نیز می‌تواند فرد یا گروهی باشد که کار فنی را درون سازمان یا با کمک پیمانکار اداره می‌کند. برون‌سپاری، نیاز سازمان به تعریف و پیگیری این مسئولیت را برطرف نمی‌کند.
مالک ریسک هم قرار نیست شخصاً همهٔ کنترل‌ها را اجرا کند یا به‌تنهایی دربارهٔ پذیرش هر ریسکی تصمیم بگیرد. باید روشن باشد کدام اقدام در اختیار اوست، چه موضوعی را به مرجع دیگری ارجاع می‌دهد و پیگیری رفع ریسک چگونه انجام می‌شود. کنترل فنی را ممکن است تیم فناوری اجرا کند، درحالی‌که تصمیم دربارهٔ ادامهٔ استفاده نیازمند نظر کسب‌وکار و تصویب مرجع دارای اختیار باشد.
این چهار نقش، شیوهٔ صورت‌بندی این درس‌اند. چارچوب NIST AI RMF نیز در GOVERN 2 بر روشن و مستند بودن نقش‌ها و مسیرهای ارتباطی، توانمندی افراد و مسئولیت مدیریت ارشد در تصمیم‌های ریسک تأکید می‌کند؛ بدون آنکه همین چهار عنوان سازمانی را تجویز کند.
مدیر مالی به چهار عنوان نگاه کرد: «یعنی برای همین دستیار باید چهار نفر جدید تعیین کنیم؟»
مدیرعامل گفت: «برای منابع و رفع اختلاف‌ها خودم درگیرم. این یکیش.»
مدیر منابع انسانی پرسید: «اگر من مسئول کاربرد باشم، باید دربارهٔ مدل هم تصمیم بگیرم؟»
مدیر فناوری گفت: «شما باید بگید چه مسئله‌ای باید حل بشه و چه پاسخی قابل قبوله. انتخاب و ادارهٔ راهکار فنی رو ما پیگیری می‌کنیم.»
مدیرعامل گفت: «پس قرار نیست همه یک کار رو انجام بدیم. باید معلوم باشه هر بخش کار به چه کسی سپرده شده.»
یک نفر چند کلاه و چند نفر یک کلاه
تفکیک این نقش‌ها، به معنای ایجاد چهار سمت یا چهار واحد تازه نیست.
یک نفر می‌تواند چند کلاه داشته باشد و چند نفر هم می‌توانند یک کلاه را مشترکاً بر عهده بگیرند.
تعداد صندلی‌ها، کیفیت حکمرانی را تعیین نمی‌کند؛ مهم این است که مسئولیت‌ها پذیرفته شوند و قابل پیگیری باشند.
در یک شرکت کوچک، مدیرعامل ممکن است هم حامی اجرایی باشد و هم مالک مسئلهٔ کسب‌وکار. در یک تیم فنی کوچک، همان فردی که معماری را انتخاب می‌کند، عملیات و پیگیری کنترل‌های ریسک را هم اداره کند. جمع شدن نقش‌ها در یک فرد، تعهدات هر نقش را از بین نمی‌برد. او باید بداند در هر تصمیم، کدام مسئولیت را انجام می‌دهد و چه شواهدی برای آن لازم دارد.
در سازمانی بزرگ‌تر، مالکیت فنی ممکن است بر عهدهٔ یک گروه مشترک از متخصصان مدل، نرم‌افزار و زیرساخت باشد. مسئولیت کسب‌وکار دستیار نیز می‌تواند میان چند نفر در منابع انسانی مشترک باشد؛ برای مثال، کسانی که حوزه‌های آموزش، رفاه و روابط کارکنان را اداره می‌کنند.
اشتراک یک کلاه زمانی کار می‌کند که اعضای گروه دربارهٔ شیوهٔ انجام مسئولیت توافق داشته باشند. باید معلوم باشد موضوع چگونه وارد کار گروه می‌شود، چه کسی یا کسانی آن را پیگیری می‌کنند، تصمیم مشترک چگونه گرفته می‌شود و در غیاب یک عضو، رسیدگی چگونه ادامه پیدا می‌کند. اگر اختیار میان چند نفر توزیع شده، مسیر جمع شدن نظرها و صدور تصمیم نیز باید روشن باشد.
تجربهٔ قراردادهای مشارکتی در IT و AI نمونه‌ای از همکاری چند شرکت با حفظ هویت مستقل آن‌هاست؛ در آن می‌توان دید که توافق دربارهٔ مسئولیت، اختیار و حقوق هر شریک چگونه بخشی از طراحی همکاری می‌شود.
آرایش نقش‌ها
نمونه
چیزی که باید روشن بماند
یک نفر با چند کلاه
مدیرعامل، حامی اجرایی و مالک کسب‌وکار است
تعهدات و حدود اختیار هر دو نقش
چند نفر با یک کلاه
تیم مشترک، مالک فنی خدمت است
تقسیم کار، پوشش متقابل و شیوهٔ تصمیم‌گیری
چند نفر با چند کلاه
منابع انسانی، فناوری و ریسک، مسئولیت‌ها را میان خود تقسیم کرده‌اند
مرز مسئولیت‌ها و مسیر رسیدگی به موضوعات مشترک
وجود یک گروه پاسخ‌گو کاملاً ممکن است. لازم نیست برای هر کلاه، یک فرد ثابت و انحصاری تعیین کنیم. اما عبارت‌هایی مانند «با هماهنگی واحدهای مربوط» نیز برای ادارهٔ کار کافی نیستند. کاربر و همکاران باید بدانند درخواست را کجا ثبت کنند، چه پاسخی دریافت می‌کنند و نتیجه را از چه مسیری دنبال کنند.
مدیر منابع انسانی گفت: «محتوای دستیار فقط آموزش نیست. همکار رفاه هم باید در اداره‌اش سهم داشته باشه.»
مدیر فناوری گفت: «سمت ما هم زیرساخت و تیم مدل هر دو درگیرن.»
مدیرعامل پرسید: «می‌تونید مشترک اداره کنید، طوری که موضوع بین افراد گم نشه؟»
مدیر منابع انسانی گفت: «برای هر حوزه مسئول رسیدگی مشخص می‌کنیم. موارد مشترک رو هم با هم جمع‌بندی می‌کنیم و نتیجه در یک مسیر ثبت می‌شه.»
مدیر فناوری گفت: «ما هم مسیر پشتیبانی واحد می‌ذاریم؛ کاربر لازم نیست تشخیص بده مشکل از مدل بوده یا زیرساخت.»
نام چند نفر زیر یک نقش قرار گرفت. این بار کنار نام‌ها نوشته شد که کار چگونه به دستشان می‌رسد و چگونه باید به نتیجه برسد.
مسئولیت باید با اختیار و امکان اقدام همراه باشد
نوشتن نام افراد یا گروه‌ها، آغاز تقسیم مسئولیت است. برای پذیرفتن آن، افراد باید اطلاعات، زمان، توانایی و اختیار متناسب داشته باشند.
اگر از منابع انسانی انتظار داریم اعتبار منابع را پیگیری کند، باید بتواند نسخهٔ معتبر را تعیین کند، سند منسوخ را از جریان پاسخ‌گویی خارج سازد و نتیجهٔ اصلاح را بررسی کند. اگر تیم فنی مسئول اصلاح خطاست، باید به شواهد لازم دسترسی داشته باشد و تغییر را در محیط مناسب آزمایش کند. اگر کسی مسئول پیگیری ریسک است، مسیر درخواست محدودسازی، اجرای اقدام فوری در حدود اختیار و ارجاع اختلاف باید برایش روشن باشد.
حامی اجرایی نیز با تعیین نام‌ها از پرونده خارج نمی‌شود. ممکن است رسیدگی به خطا به زمان کارشناسان، هزینهٔ اصلاح یا همکاری چند واحد نیاز داشته باشد. فراهم کردن این امکان‌ها بخشی از همان مسئولیت حمایتی است.
برای قابل پیگیری شدن هر کلاه، می‌توان چهار مورد را ثبت کرد: موضوع مسئولیت، تصمیم یا اقدام مجاز، شواهدی که باید دریافت یا تولید شود و مرجع رسیدگی به اختلاف. این ثبت می‌تواند در همان منشور پروژه یا رویهٔ ادارهٔ خدمت انجام شود.
معیار مسئولیت‌پذیری این است که وقتی مسئله‌ای پیش می‌آید، افراد بدانند چه کاری باید انجام دهند، اختیار انجامش را داشته باشند و نتیجهٔ رسیدگی معلوم شود.
مدیر منابع انسانی گفت: «برای تعیین نسخهٔ معتبر، باید همکارانم وقت بذارن. اگر هم تغییرات آیین‌نامه دیر به ما برسه، دوباره همین مشکل رو داریم.»
مدیرعامل گفت: «زمان لازم رو در برنامهٔ واحد ببینید. مسیر اعلام تغییرات رو هم مشخص کنیم.»
مسئول ریسک و انطباق پرسید: «اگر نشانهٔ خطای جدی دیدیم، باید تا جلسهٔ بعد منتظر بمونیم؟»
مدیر فناوری گفت: «از نظر فنی می‌تونیم یک موضوع یا یک منبع رو موقتاً از پاسخ‌گویی خارج کنیم. باید معلوم باشه درخواست از چه مسیری می‌آد و اجازهٔ اجرا در چه حدودیه.»
این بار، کنار مسئولیت‌ها، جای خالی اختیارها هم دیده می‌شد.
اگر انجام مسئولیت، برخلاف منفعت صاحب آن باشد
در ادامهٔ فرضی همین پرونده، پاداش حامی پروژه به راه‌اندازی در موعد مقرر وابسته است. کارشناسان نگران‌اند اطلاعاتی که برای آموزش و ارزیابی دستیار فراهم می‌کنند، بعداً مبنای کاهش نیروی انسانی شود. بازبین نیز می‌داند گزارش نقص می‌تواند زمان راه‌اندازی را عقب بیندازد.
در این وضعیت، روشن‌کردن نام مسئولان کافی نیست. حامی ممکن است نتیجهٔ نامطلوب را کم‌اهمیت جلوه دهد؛ کارشناسان ممکن است همکاری محدودی داشته باشند؛ و بازبین ممکن است از ثبت صریح مسئله پرهیز کند. این رفتارها را نمی‌توان فقط با آموزش ابزار یا تکمیل کاربرگ مسئولیت برطرف کرد.
در این مثال، مرجع دارای اختیار سه تصمیم می‌گیرد: ارزیابی حامی را به کیفیت و پایداری نتیجه نیز وابسته می‌کند؛ هدف استفاده از داده‌های پایلوت و حدود استفادهٔ بعدی از آن‌ها را برای کارکنان روشن می‌کند؛ و مسیر ثبت و ارجاع یافتهٔ مهم را به موافقت مجری یا حامی وابسته نمی‌گذارد.
بازبین، یافته و شواهدش را مستقیماً به صاحب تصمیم می‌رساند. تصمیم دربارهٔ پذیرش ریسک باقیمانده با نام، دلیل و موعد بازبینی ثبت می‌شود. اگر منابع یا اختیار لازم برای اصلاح فراهم نشد، این موضوع به‌عنوان مانع تصمیم گزارش می‌شود.
این ترتیب، تعارض منافع را حذف نمی‌کند. آن را قابل مشاهده می‌کند و مانع می‌شود اختلاف به نام «هماهنگی بین واحدها» از پرونده ناپدید شود.
پروندهٔ پاسخ باید به نتیجه برسد
در پروندهٔ کمک‌هزینه، می‌توان مسئولیت‌ها را چنان به هم متصل کرد که رسیدگی به کاربر و اصلاح خدمت هر دو پیش بروند. منابع انسانی پاسخ رسمی را پیگیری کند و مرجع معتبر را روشن سازد. تیم فنی شواهد را بررسی و اشکال فنی را اصلاح کند. متولی ریسک، پیامد و امکان تکرار خطا را دنبال کند و اقدام لازم را طبق اختیارات مصوب پیش ببرد. حامی اجرایی نیز منابع و همکاری مورد نیاز را فراهم کند.
این‌ها تعهداتی‌اند که می‌توان میان افراد و گروه‌های مختلف توزیع کرد. برای نمونه، دو همکار در منابع انسانی ممکن است مشترکاً رسیدگی کنند و یک تیم فنی هم مسئول بررسی و اصلاح باشد. آنچه باید قابل مشاهده بماند، دریافت موضوع، اقدام انجام‌شده و نتیجهٔ آن است.
پاسخ دستیار به کار چند فرد و گروه در این زنجیره وابسته است.
این وابستگی، مسئولیت هر بخش و پاسخ‌گویی سازمان در برابر استفاده‌کننده را از بین نمی‌برد.
قرار است ارتباط مسئولیت‌ها روشن شود تا هر بخش بتواند سهم خود را انجام دهد و کار تا نتیجه ادامه پیدا کند.
پایان جلسه
روی میز هنوز همان پاسخ چاپ‌شده بود. این بار برگه فقط میان واحدها دست‌به‌دست نمی‌شد.
منابع انسانی رسیدگی به درخواست کارمند و تعیین مرجع معتبر را پذیرفت. تیم فناوری بررسی سند و رفتار پاسخ‌گویی را دنبال می‌کرد. موضوع خطا و اقدام‌های لازم نیز در مسیر پیگیری ریسک ثبت می‌شد.
مدیرعامل گفت: «خوب، پس معلوم شد چه کارهایی باید انجام بشه.»
مدیر فناوری برگهٔ دیگری را جلو گذاشت: «بعد از اصلاح، می‌خوایم دسترسی رو برای گروه بعدی باز کنیم.»
مدیر منابع انسانی گفت: «اول باید نتیجهٔ بررسی پاسخ‌ها رو ببینیم.»
مسئول ریسک و انطباق اضافه کرد: «و تکلیف محدودیت پاسخ‌گویی دربارهٔ کمک‌هزینه هم روشن بشه.»
مدیرعامل به نام‌ها و نقشهای روی کاغذ نگاه کرد. مسئولیت‌ها روشن‌تر شده بودند، اما پرسش تازه‌ای پیش رو بود: چه کسی، با دیدن چه شواهدی، اجازهٔ گسترش استفاده را می‌دهد؟
این مجموعه بر پایهٔ مباحث دورهٔ «حکمرانی هوش مصنوعی در سازمان» در DBA هوش مصنوعی در کسب‌وکار تدوین شده است. اسلایدهای کامل دوره
درس سوم؛ حق پیشنهاد، ارزیابی، تصویب و توقف، مدل‌های حکمرانی، مرکز تعالی و دروازه‌های تصمیم.
مطالعهٔ درس: چه کسی حق تصمیم دارد
ادامهٔ همان جلسه
برگهٔ پیشنهاد گسترش دسترسی هنوز وسط میز بود. روی برگهٔ کناری، کلاه‌های مسئولیت و نام افراد و گروه‌های مرتبط نوشته شده بود. برای رسیدگی به پاسخ اشتباه دستیار، بالاخره تقسیم کار روشنی داشتند.
مدیر فناوری گفت: «از نظر ظرفیت، برای گروه بعدی مشکلی نداریم. دسترسی‌ها هم قابل تنظیمه.»
مدیر منابع انسانی پاسخ داد: «اما بررسی پاسخ‌های مربوط به کمک‌هزینه هنوز تموم نشده.»
مسئول ریسک و انطباق گفت: «پیشنهاد من اینه که فعلاً اون موضوع از پاسخ‌گویی خارج بشه.»
مدیرعامل به سه نفر نگاه کرد: «پس الان دسترسی رو بیشتر کنیم یا نه؟»
مدیر فناوری گفت: «حرف من آمادگی فنیه. دربارهٔ محتوای منابع انسانی، باید نظر اون واحد هم باشه.»
مدیر منابع انسانی گفت: «من هم دربارهٔ صحت پاسخ‌ها نظر می‌دم. اینکه استفاده برای گروه بزرگ‌تری مجاز باشه، باید با همین محدودیت‌ها تصمیم‌گیری بشه.»
روی کاغذ، مسئولیت‌ها تقسیم شده بود. در عمل، هرکس دربارهٔ بخش خود حرف می‌زد و هنوز معلوم نبود این نظرها چگونه باید به یک تصمیم قابل اجرا برسند.
مدیرعامل پرسید: «خوب، چه کسی باید این پیشنهاد رو جمع‌بندی کنه و اجازهٔ ادامه بده؟»
در درس دوم، چهار کلاه مسئولیت را از هم تفکیک کردیم: حامی اجرایی، مالک کسب‌وکار، مالک فنی و مالک ریسک. دیدیم که یک نفر می‌تواند چند کلاه داشته باشد و چند نفر هم می‌توانند یک کلاه را مشترکاً بر عهده بگیرند.
در ادامهٔ جلسه، پیشنهاد گسترش دسترسی هنوز روی میز مانده است. هر واحد دربارهٔ بخش خود نظر می‌دهد، اما جمع این نظرها هنوز به تصمیم منجر نشده است. اکنون باید مسئولیت‌ها را به اختیارهای مشخص وصل کنیم: چه کسی حق دارد پیشنهاد بدهد، ارزیابی کند، تصویب کند یا کار را متوقف سازد؟
این درس، قسمت دوم «مدل عملیاتی حکمرانی و حق تصمیم» است و با آن، بخش اول دوره را به پایان می‌رسانیم.
هر نقش در هر مرحله چه اختیاری دارد؟
در یک سازمان، تصمیم‌های مربوط به هوش مصنوعی معمولاً حاصل کار یک نفر یا یک واحد نیستند. برای مثال، تغییر مدل ممکن است از طرف تیم فناوری پیشنهاد شود، اما اثر آن بر کیفیت پاسخ‌های منابع انسانی را نمی‌توان صرفاً با ارزیابی فنی سنجید. واحد منابع انسانی باید بررسی کند که آیا پاسخ‌های جدید همچنان با نیازها و مقررات سازمان سازگارند؛ مسئول ریسک باید پیامدهای احتمالی تغییر را بسنجد؛ و در نهایت، مرجعی که اختیار تصویب دارد باید درباره اعمال تغییر تصمیم بگیرد.
اینجا یک تمایز مهم وجود دارد: مشارکت در یک تصمیم با داشتن اختیار تصمیم‌گیری یکسان نیست. کسی که اطلاعات یا ارزیابی تخصصی ارائه می‌کند، لزوماً حق تصویب ندارد. کسی که تصویب می‌کند، لزوماً مجری تغییر نیست. و کسی که مسئول اجرای سامانه است، الزاماً اختیار پذیرش ریسک ناشی از آن را ندارد.
برای روشن‌شدن این تفاوت، باید چهار نوع اختیار را در طول چرخه عمر سامانه از یکدیگر تفکیک کنیم:
پیشنهاد دادن: آغاز یک تغییر یا طرح یک تصمیم. پیشنهاددهنده مسئله، دلیل تغییر، گزینه‌های موجود و پیامدهای مورد انتظار را مطرح می‌کند. برای مثال، تیم فناوری پیشنهاد می‌دهد مدل زبانی به‌روزرسانی شود تا کیفیت بازیابی یا سرعت پاسخ بهتر شود.
ارزیابی کردن: بررسی پیشنهاد بر اساس شواهد و معیارهای مرتبط. ارزیاب باید بتواند مزایا، محدودیت‌ها و پیامدهای پیشنهاد را از منظر تخصصی خود بررسی کند. برای مثال، منابع انسانی کیفیت پاسخ‌های مربوط به آیین‌نامه‌ها را می‌سنجد و مسئول ریسک پیامدهای پاسخ اشتباه را بررسی می‌کند.
تصویب کردن: اجازه دادن به اجرای پیشنهاد یا پذیرش یک وضعیت مشخص. تصویب‌کننده باید اختیار سازمانی لازم را داشته باشد و مسئولیت تصمیم خود را بپذیرد. تأیید یک ارزیاب تخصصی به‌تنهایی جایگزین این تصویب نیست.
متوقف کردن: جلوگیری از ادامه یک فعالیت، محدودسازی موقت یا تعلیق یک قابلیت در شرایطی که ادامه آن می‌تواند پیامد نامطلوبی داشته باشد. این اختیار باید از پیش تعریف شده باشد؛ از جمله اینکه چه کسی می‌تواند توقف را درخواست کند، چه کسی مجاز به اعمال فوری آن است و بازگشایی به تأیید چه مرجعی نیاز دارد.
این چهار اختیار الزاماً به چهار فرد یا واحد متفاوت تعلق ندارند. ممکن است یک نفر در یک تصمیم پیشنهاددهنده و در تصمیم دیگری تصویب‌کننده باشد. همچنین ممکن است ارزیابی یک پیشنهاد به چند واحد سپرده شود. نکته این است که سازمان باید برای هر تصمیم مشخص کند چه کسی چه نقشی دارد و حدود اختیار هر نقش کجاست.
حق پیشنهاد، ارزیابی، تصویب و توقف در مراحل مختلف می‌تواند به نقشهای متفاوتی سپرده شود.
این تقسیم اختیار در مراحل مختلف چگونه عمل می‌کند؟
نقشهٔ حق تصمیم فقط برای زمان بهره‌برداری نیست. از لحظه‌ای که سازمان مسئله‌ای را برای استفاده از هوش مصنوعی انتخاب می‌کند تا زمانی که سامانه تغییر می‌کند، محدود می‌شود یا کنار گذاشته می‌شود، تصمیم‌های متعددی باید گرفته شوند. برای فهم بهتر، پروندهٔ دستیار سازمانی خودمان را در نظر بگیریم.
۱. انتخاب مسئله و تعیین دامنهٔ استفاده
فرض کنیم منابع انسانی پیشنهاد می‌کند دستیار هوش مصنوعی به پرسش‌های پرتکرار کارکنان درباره آیین‌نامه‌ها پاسخ دهد.
منابع انسانی می‌تواند پیشنهاددهنده باشد و توضیح دهد کدام پرسش‌ها پرتکرارند، چه مشکلی را باید حل کرد و پاسخ معتبر از نظر آن واحد چیست.
تیم فناوری امکان‌پذیری فنی، منابع مورد نیاز و محدودیت‌های معماری را ارزیابی می‌کند.
مسئول ریسک، پیامدهای احتمالی پاسخ اشتباه، دامنه اطلاعات قابل دسترسی و مواردی را که باید به کارشناس ارجاع شوند بررسی می‌کند.
مرجع دارای اختیار، پس از بررسی این شواهد، دامنه آزمایش را تصویب می‌کند؛ مثلاً استفاده برای گروهی محدود از کارکنان، با اتکا به اسناد عمومی و معتبر و بدون دسترسی به پرونده‌های شخصی.
اگر در بررسی اولیه مشخص شود که کاربرد پیشنهادی با ریسک غیرقابل‌قبولی همراه است، مرجع تعیین‌شده باید بتواند از آغاز آن جلوگیری کند.
در این مرحله، منابع انسانی درباره نیاز کسب‌وکار نظر تخصصی می‌دهد، اما نمی‌تواند به‌تنهایی امکان‌پذیری فنی را تأیید کند. تیم فناوری نیز می‌تواند بگوید ساخت سامانه ممکن است، اما این به معنای تصویب استفاده از آن نیست.
۲. انتخاب فناوری، مدل و تأمین‌کننده
پس از تصویب دامنه، نوبت به انتخاب مدل، زیرساخت، ابزارها و احتمالاً پیمانکار می‌رسد.
تیم فناوری گزینه‌های فنی را پیشنهاد می‌کند و درباره معماری، هزینه، ظرفیت، امنیت فنی و امکان نگهداری آن‌ها ارزیابی ارائه می‌دهد.
مالک کسب‌وکار بررسی می‌کند که گزینه انتخابی واقعاً نیاز کاربران را پوشش می‌دهد و محدودیت‌های آن با جریان کاری سازمان سازگار است.
مسئول ریسک و متولی امنیت، شرایط نگهداری داده، دسترسی تأمین‌کننده، امکان انتقال اطلاعات، وابستگی به ارائه‌دهنده و پیامدهای خروج از قرارداد را بررسی می‌کنند.
مرجع دارای اختیار، گزینه نهایی را با توجه به ارزیابی‌ها، بودجه و سطح ریسک قابل‌پذیرش تصویب می‌کند.
اگر بررسی‌ها نشان دهد تأمین‌کننده یا معماری پیشنهادی الزامات ضروری سازمان را برآورده نمی‌کند، باید امکان رد پیشنهاد یا توقف فرایند انتخاب وجود داشته باشد.
برای مثال، ممکن است یک مدل از نظر کیفیت پاسخ بهترین گزینه باشد، اما داده‌های سازمان را به یک سرویس خارجی ارسال کند. تیم فناوری می‌تواند کیفیت و عملکرد آن را تأیید کند؛ اما پذیرش پیامدهای محرمانگی و حقوقی این انتخاب باید از مسیر اختیارهای مربوط به ریسک و حاکمیت داده انجام شود.
۳. ارزیابی پایلوت و اجازهٔ ورود به بهره‌برداری
در این مرحله، سامانه ساخته شده و آزمایش محدود انجام شده است. پرسش دیگر صرفاً این نیست که آیا سامانه کار می‌کند؛ باید معلوم شود آیا شواهد کافی برای استفاده واقعی وجود دارد یا خیر.
تیم فناوری نتایج آزمون‌های فنی، پایداری، دسترس‌پذیری، امنیت و عملکرد را ارائه می‌کند.
مالک کسب‌وکار بررسی می‌کند که پاسخ‌ها برای کاربران مفیدند، نیازهای واقعی را پوشش می‌دهند و در جریان کار قابل استفاده‌اند.
مسئول ریسک، خطاهای مهم، موارد پاسخ‌گویی نامطمئن، احتمال آسیب و کفایت کنترل‌ها را ارزیابی می‌کند.
در صورت نیاز، ارزیاب مستقل یا واحدی خارج از تیم اجرا می‌تواند شواهد را بازبینی کند؛ به‌خصوص وقتی مجری پروژه هم‌زمان مسئول ارزیابی موفقیت آن است.
مرجع تصویب‌کننده بر اساس مجموع این شواهد درباره ادامه آزمایش، اصلاح، محدودسازی یا ورود به بهره‌برداری تصمیم می‌گیرد.
فرض کنیم تیم فناوری اعلام کند دستیار در ۹۵ درصد آزمون‌ها پاسخ فنی قابل قبولی تولید کرده است. این عدد به‌تنهایی برای تصویب بهره‌برداری کافی نیست. باید پرسید آن ۵ درصد باقیمانده چه نوع خطاهایی دارند؟ آیا پاسخ اشتباه ممکن است کارمند را به اقدام نادرست سوق دهد؟ آیا سامانه در موارد نامطمئن از پاسخ‌دادن خودداری می‌کند؟ آیا کاربر راهی برای ارجاع پرسش به مرجع انسانی دارد؟
در نتیجه، تأیید فنی، تأیید کیفیت خدمت و تصویب بهره‌برداری سه موضوع مرتبط اما متمایزند.
۴. گسترش دسترسی و تغییر دامنهٔ استفاده
فرض کنیم پایلوت موفق بوده و مدیرعامل می‌خواهد دسترسی به دستیار از یک واحد به تمام کارکنان گسترش پیدا کند.
این تغییر ممکن است در نگاه اول صرفاً افزایش تعداد کاربران به نظر برسد، اما در عمل می‌تواند بار زیرساختی، دامنه اثر خطا، نیازهای پشتیبانی و حتی نوع اطلاعاتی را که کاربران وارد سامانه می‌کنند تغییر دهد.
مالک کسب‌وکار می‌تواند گسترش استفاده را پیشنهاد کند و شواهد مربوط به تقاضا و منفعت آن را ارائه دهد.
تیم فناوری ظرفیت زیرساخت، کنترل دسترسی، امنیت و آمادگی عملیاتی را ارزیابی می‌کند.
منابع انسانی یا واحدهای بهره‌بردار، کیفیت پاسخ‌ها را در گروه‌های جدید و متناسب با نیازهای آن‌ها بررسی می‌کنند.
مسئول ریسک، تغییر در دامنه مواجهه با ریسک و کفایت کنترل‌های قبلی را می‌سنجد.
مرجع تصویب‌کننده درباره گسترش دسترسی تصمیم می‌گیرد؛ ممکن است تصویب مرحله‌ای را به جای گسترش یکباره انتخاب کند.
برای مثال، اگر دستیار ابتدا فقط به پرسش‌های عمومی کارکنان پاسخ می‌داده، اضافه‌شدن امکان پاسخ‌گویی درباره وضعیت فردی مرخصی یا مزایا یک تغییر ساده در دسترسی نیست. این تغییر، دامنه داده، مسئولیت پاسخ و سطح ریسک را عوض می‌کند و باید به‌عنوان تصمیمی مستقل ارزیابی شود.
۵. تغییر مدل، منابع و رفتار سامانه در زمان بهره‌برداری
حتی پس از آغاز بهره‌برداری، سامانه ثابت نمی‌ماند. مدل به‌روزرسانی می‌شود، اسناد تغییر می‌کنند، منابع جدید اضافه می‌شوند و گاهی تنظیمات بازیابی یا دستورالعمل‌های پاسخ‌گویی تغییر می‌کنند.
نباید برای تمام این تغییرها یک فرایند تصویب سنگین و یکسان تعریف کرد. تغییر جزئی در قالب نمایش پاسخ با تغییر مدل اصلی یا اضافه‌شدن منبعی که مبنای تصمیم‌های کارکنان است، پیامد یکسانی ندارد.
سازمان می‌تواند تغییرها را بر اساس اثر و ریسک آن‌ها طبقه‌بندی کند:
تغییرهای کم‌اثر و از پیش تعریف‌شده، مانند اصلاح ظاهری رابط، ممکن است در حدود اختیار تیم فنی انجام شوند.
تغییر در منابع محتوایی باید با تأیید متولی همان محتوا و کنترل نسخه انجام شود.
تغییر مدل یا تنظیمات مؤثر بر رفتار پاسخ‌گویی باید از ارزیابی فنی و کسب‌وکاری عبور کند.
تغییر در دامنه کاربرد، نوع داده یا سطح اختیار سامانه ممکن است به ارزیابی ریسک و تصویب مجدد نیاز داشته باشد.
برای نمونه، اگر منابع انسانی نسخه جدید آیین‌نامه کمک‌هزینه را منتشر کند، تیم فناوری می‌تواند مسئول به‌روزرسانی منبع در سامانه باشد، اما تشخیص اینکه نسخه جدید معتبر است و جایگزین نسخه قبلی شده، باید به متولی محتوای مربوط وابسته باشد. همچنین اگر تغییر مدل باعث شود پاسخ‌ها با اطمینان بیشتری اما با دقت کمتر تولید شوند، بررسی این تغییر فقط در اختیار تیم فنی نیست.
۶. مواجهه با خطا، محدودسازی و بازگشایی خدمت
این مرحله جایی است که نبود نقشه حق تصمیم می‌تواند به اختلاف جدی میان واحدها منجر شود.
فرض کنیم دستیار به کارمندی درباره شرایط دریافت کمک‌هزینه آموزشی پاسخ مثبت داده، اما منابع انسانی اعلام کرده است که آن پاسخ با شرایط واقعی آیین‌نامه سازگار نیست. در این وضعیت چند تصمیم متفاوت وجود دارد:
چه کسی خطا را گزارش و مستند می‌کند؟
چه کسی بررسی می‌کند که منشأ خطا، سند نامعتبر، بازیابی نادرست، رفتار مدل یا طراحی نامناسب فرایند بوده است؟
چه کسی درباره اصلاح منبع یا سامانه اقدام می‌کند؟
آیا لازم است قابلیت پاسخ‌گویی به این دسته از پرسش‌ها موقتاً محدود شود؟
چه کسی اجازه می‌دهد خدمت پس از اصلاح دوباره فعال شود؟
این تصمیم‌ها نباید در یک عنوان کلی مانند «مسئولیت با واحد فناوری است» ادغام شوند.
برای مثال، منابع انسانی می‌تواند خطای محتوایی را گزارش کند و اعتبار پاسخ را بررسی کند. تیم فناوری می‌تواند منشأ فنی خطا را پیدا کند و اصلاح لازم را انجام دهد. مسئول ریسک می‌تواند شدت پیامد را ارزیابی و محدودسازی موقت را درخواست کند. اما اگر خطا جدی باشد، سازمان باید از پیش مشخص کرده باشد چه فرد یا مرجعی اختیار اعمال فوری توقف را دارد؛ نه اینکه در زمان وقوع حادثه تازه درباره این اختیار مذاکره کند.
همچنین بازگشایی خدمت لزوماً با انجام اصلاح فنی مجاز نمی‌شود. ممکن است اصلاح انجام شده باشد، اما هنوز شواهد کافی از رفع خطا وجود نداشته باشد. بنابراین باید مشخص شود چه کسی اصلاح را ارزیابی می‌کند و چه مرجعی اجازه بازگشت به بهره‌برداری را صادر می‌کند.
۷. خروج از خدمت و کنارگذاری سامانه
چرخه عمر سامانه با بهره‌برداری پایان نمی‌یابد. گاهی راهکار دیگر پاسخ‌گوی نیاز سازمان نیست، تأمین‌کننده خدمات خود را متوقف می‌کند، ریسک آن بیش از منفعتش می‌شود یا جایگزین مناسب‌تری در دسترس قرار می‌گیرد.
در این مرحله نیز باید مشخص باشد چه کسی خروج از خدمت را پیشنهاد می‌کند، چه کسی اثر آن بر کاربران و فرایندها را می‌سنجد، چه مرجعی آن را تصویب می‌کند و چه کسی مسئول اجرای خروج است. حذف دسترسی‌ها، تعیین تکلیف داده‌ها و سوابق، انتقال فرایندهای وابسته و اطلاع‌رسانی به کاربران از جمله اقداماتی هستند که باید برای آن‌ها مسئول مشخص وجود داشته باشد.
یک تصمیم، چند مشارکت‌کننده؛ اما نه چند صاحب اختیار نهایی
آنچه در مثال‌های بالا اهمیت دارد، صرفاً فهرست‌کردن نقش‌ها نیست. باید بین چهار نوع مشارکت تمایز قائل شویم:
پیشنهاددهنده مسئله یا تغییر را مطرح می‌کند؛ اما الزاماً حق اجرای آن را ندارد.
ارزیاب شواهد و نظر تخصصی ارائه می‌دهد؛ اما ارزیابی مثبت او به‌تنهایی مجوز اجرا نیست.
تصویب‌کننده تصمیم نهایی را در محدوده اختیار تفویض‌شده می‌گیرد و باید بتواند مبنای تصمیم خود را توضیح دهد.
متوقف‌کننده باید بتواند در شرایط تعریف‌شده از ادامه فعالیت جلوگیری کند؛ حتی اگر پیشنهاددهنده یا تصویب‌کننده با توقف موافق نباشند.
ممکن است در یک تصمیم، چند ارزیاب از واحدهای مختلف مشارکت کنند. برای مثال، تغییر مدل از نظر فنی، کیفیت پاسخ، امنیت و ریسک بررسی شود. اما باید معلوم باشد آیا همه این ارزیابی‌ها شرط لازم برای تصویب‌اند یا برخی صرفاً نظر مشورتی محسوب می‌شوند. اگر یکی از ارزیابان با تغییر مخالفت کند، آیا تصمیم متوقف می‌شود یا مرجع تصویب‌کننده می‌تواند با ثبت دلیل و پذیرش مسئولیت، آن را بپذیرد؟
این پرسش‌ها را نمی‌توان با تعیین عنوان‌هایی مانند مالک کسب‌وکار، مالک فنی یا مالک ریسک به‌تنهایی پاسخ داد. این عنوان‌ها حوزه مسئولیت را روشن می‌کنند؛ اما حق تصمیم باید جداگانه و برای هر نوع تصمیم تعریف شود.
حق توقف؛ اختیاری که نباید فقط روی کاغذ وجود داشته باشد
در میان چهار اختیار، حق توقف اهمیت ویژه‌ای دارد؛ زیرا ممکن است لازم باشد در شرایط اضطراری، ادامه فعالیت پیش از تکمیل فرایند معمول تصویب متوقف شود.
برای مثال، اگر دستیار به‌طور گسترده اطلاعات محرمانه را در پاسخ‌ها افشا کند، سازمان نباید منتظر تشکیل جلسه بعدی کمیته یا تأیید مدیرعامل بماند. باید از قبل مشخص باشد چه کسی می‌تواند قابلیت آسیب‌دیده را فوراً محدود کند، چه کسی مسئول اجرای این محدودسازی است و چه مرجعی درباره ادامه توقف یا بازگشایی تصمیم می‌گیرد.
در اینجا سه اختیار را باید از هم جدا کرد:
۱. درخواست توقف: هر فرد یا واحدی که نشانه‌ای معتبر از خطر مشاهده می‌کند، باید بتواند موضوع را گزارش کند و توقف را درخواست دهد.
۲. اعمال توقف: افراد مشخصی باید اختیار عملیاتی لازم برای غیرفعال‌کردن یک قابلیت، محدودکردن دسترسی یا تعلیق خدمت را داشته باشند. در موارد اضطراری، این اختیار می‌تواند پیش از تصویب نهایی اعمال شود.
۳. تصمیم درباره بازگشایی: بازگشت به وضعیت عادی باید پس از بررسی شواهد اصلاح، ارزیابی مجدد ریسک و تأیید مرجع دارای اختیار انجام شود.
این اختیارات ممکن است در سازمان‌های مختلف متفاوت توزیع شوند. برای مثال، مسئول ریسک می‌تواند اختیار درخواست توقف داشته باشد، تیم فناوری آن را اجرا کند و بازگشایی به تصویب مرجع مشخصی نیاز داشته باشد. در سازمانی دیگر ممکن است مسئول امنیت در محدوده‌ای از پیش تعیین‌شده اختیار توقف فوری داشته باشد. آنچه ضروری است، روشن‌بودن دامنه اختیار و امکان اجرای واقعی آن است.
داشتن عنوان «مالک ریسک» به‌خودی‌خود به معنای داشتن حق توقف نیست. این حق باید صریحاً در سازوکار اختیارات سازمان تعریف و ابلاغ شده باشد.
نقشه حق تصمیم را چگونه مستند کنیم؟
برای هر تصمیم مهم در چرخه عمر، بهتر است یک جدول یا ماتریس مشخص وجود داشته باشد که دست‌کم این موارد را ثبت کند:
موضوع تصمیم و دامنه آن؛
پیشنهاددهنده یا واحد آغازکننده؛
ارزیابان لازم و شواهدی که باید ارائه کنند؛
مرجع تصویب و حدود اختیار او؛
فرد یا واحد دارای اختیار توقف؛
مسئول اجرای تصمیم و ثبت نتیجه؛
شرایط بازبینی، تجدید ارزیابی یا بازگشایی.
برای مثال، در تصمیم «گسترش دسترسی دستیار به تمام کارکنان» می‌توان منابع انسانی را پیشنهاددهنده، فناوری را ارزیاب آمادگی فنی، منابع انسانی و کاربران آزمایشی را ارزیاب کیفیت خدمت، مسئول ریسک را ارزیاب پیامدها و مدیر اجرایی دارای اختیار را تصویب‌کننده تعیین کرد. در کنار آن باید مشخص شود چه کسی در صورت مشاهده خطای جدی می‌تواند دسترسی را موقتاً محدود کند و بازگشایی به چه تأییدی نیاز دارد.
این ماتریس نباید صرفاً فهرستی از نام افراد باشد. ممکن است افراد تغییر کنند یا چند نقش در یک نفر تجمیع شوند؛ آنچه باید پایدار بماند، حدود اختیار، مسئولیت و مسیر پاسخ‌گویی است. همچنین تصمیم‌های مهم باید همراه با شواهد، نظرهای مخالف، دلیل تصویب یا رد و نام مرجع تصمیم‌گیر ثبت شوند. این ثبت، هم امکان بازبینی بعدی را فراهم می‌کند و هم مانع از آن می‌شود که در زمان بروز مشکل، هر واحد مسئولیت را به واحد دیگری ارجاع دهد.
اینکه ناظر چه شواهدی باید مطالبه کند و چه حقی برای آزمون مستقل و درخواست اصلاح داشته باشد، موضوعی جداگانه است. در مقالهٔ برای حکمرانی هوش مصنوعی، آیا باید کد منبع را ببینیم؟ این موضوع را با تفکیک حق ممیزی از مالکیت فناوری بررسی کرده‌ام.
مدیرعامل گفت: «پس پیشنهاد افزایش دسترسی رو با شرایطش بنویسید. فنی بگه چه چیزی آماده است، منابع انسانی نتیجه بررسی پاسخ‌ها رو بده و ریسک هم محدودیت‌های لازم رو مشخص کنه.»
مدیر فناوری پرسید: «تصویب این مرحله با شماست؟»
مدیرعامل پاسخ داد: «برای این گسترش مشخص، بله. اما قرار نیست برای هر اصلاح جزئی همین مسیر رو طی کنیم. حدود اختیار تغییرهای معمول رو هم مشخص کنیم.»
مسئول ریسک و انطباق گفت: «و تکلیف محدودسازی موقت و بازگشایی خدمت هم باید روشن باشه. اگر فردا خطای جدی دیدیم، نباید تازه دنبال این بگردیم که چه کسی اجازه توقف داره.»
این بار، کنار نام نقش‌ها، نوع تصمیم و حدود اختیار هرکدام هم نوشته شد.
آنچه سازمان نیاز داشت صرفاً تعیین مسئول برای هر واحد نبود؛ بلکه نقشهای بود که نشان دهد در هر مرحله چه کسی می‌تواند پیشنهاد بدهد، چه کسی باید شواهد را بررسی کند، چه کسی اجازه اجرا می‌دهد و در شرایط خطر چه کسی می‌تواند جلوی ادامه کار را بگیرد.
سؤال بعدی دیگر فقط این نیست که چه کسی مسئول است؛ بلکه این است که هر تصمیم بر اساس چه شواهدی گرفته می‌شود و چگونه می‌توان از درستی آن اطمینان پیدا کرد؟
چه چیزی باید به سطح بالاتر برگردد؟
در طراحی حکمرانی، فقط نام صاحب تصمیم را تعیین نمی‌کنیم؛ حدود تصمیم‌های واگذارشده و شرایط ارجاع دوباره را هم مشخص می‌کنیم. مرجع حاکم، جهت و حدود را تعیین می‌کند، مدیریت در آن حدود تصمیم می‌گیرد و اجرا فعالیت‌های مجاز را انجام می‌دهد. این مرجع، بسته به ساختار سازمان و اهمیت موضوع، می‌تواند هیئت‌مدیره یا مرجع دارای اختیار دیگری باشد.
سطح
نمونهٔ مسئولیت در این پرونده
مرجع حاکم
تعیین حدود تحمل ریسک، اصول استفاده، سقف اختیارات و شیوهٔ گزارش‌دهی
مدیریت
انتخاب و اولویت‌بندی کاربرد، تخصیص منابع در حدود اختیار و پذیرش استفادهٔ مشخص
در مثال این درس، اصلاح یک سند در دامنهٔ پذیرفته‌شده، با تأیید مسئول محتوا و طی کنترل تغییر انجام می‌شود. افزودن پرونده‌های شخصی کارکنان یا اختیار رد خودکار درخواست، تغییر دامنه است و به تصمیم تازهٔ مرجع دارای اختیار نیاز دارد.
ارجاع به سطح بالاتر زمانی لازم می‌شود که تصمیم از حدود تفویض‌شده خارج شود، ریسک باقیمانده از حد پذیرفته‌شده عبور کند، منابع بیشتری از سقف مصوب بخواهد یا اختلافی ایجاد کند که در سطح جاری قابل حل نیست. این‌ها قواعد این مثال‌اند؛ سازمان باید مصداق و مرجع هرکدام را در نقشهٔ تصمیم خود ثبت کند.
بنابراین، هیئت‌مدیره لازم نیست هر تغییر جزئی دستیار را تصویب کند. مسئولیت آن در کاربردهای متناسب، می‌تواند تعیین چارچوب و مطالبهٔ شواهد دربارهٔ عملکرد همان چارچوب باشد.
پس از مشخص‌کردن اینکه چه کسی در هر مرحله حق پیشنهاد، ارزیابی، تصویب یا توقف دارد، پرسش دیگری مطرح می‌شود: این اختیارها باید در کجای سازمان قرار بگیرند؟
فرض کنیم منابع انسانی برای پاسخ‌گویی به پرسش‌های کارکنان از هوش مصنوعی استفاده می‌کند. آیا این واحد باید برای انتخاب هر ابزار، تغییر هر منبع اطلاعاتی و اصلاح هر قابلیت، از یک مرجع مرکزی مجوز بگیرد؟ یا می‌تواند مستقلاً درباره راهکار خود تصمیم بگیرد؟ اگر واحد مالی، فناوری اطلاعات و چند واحد دیگر نیز راهکارهای مشابهی داشته باشند، چه کسی مسئول هماهنگی، امنیت، استانداردها و جلوگیری از دوباره‌کاری خواهد بود؟
این مسئله فقط درباره سرعت تصمیم‌گیری نیست. محل استقرار اختیار، بر هزینه‌ها، کیفیت کنترل‌ها، امکان استفاده مجدد از قابلیت‌ها، استقلال واحدها و در نهایت پاسخ‌گویی سازمان اثر می‌گذارد.
اگر تمام تصمیم‌ها به مرکز ارجاع شوند، ممکن است کارها پشت صف تأیید بمانند و تصمیم‌گیرندگان از جزئیات نیازهای عملیاتی واحدها فاصله بگیرند. از سوی دیگر، اگر هر واحد همه‌چیز را مستقل تعیین کند، سازمان ممکن است با چندین سکوی ناسازگار، قراردادهای تکراری، استانداردهای امنیتی متفاوت و راهکارهایی روبه‌رو شود که امکان نظارت و پشتیبانی مشترک ندارند.
برای تنظیم این نسبت، سه الگوی اصلی را می‌توان در نظر گرفت: متمرکز، فدرال و توزیع‌شده.
انتخاب مدل، به اندازهٔ سازمان، تنوع کاربردها، سطح ریسک و قابلیت واحدها بستگی دارد.
۱. مدل متمرکز: تصمیم‌گیری و قابلیت‌های مشترک در مرکز
در مدل متمرکز، بخش عمده‌ای از سیاست‌گذاری، تعیین استانداردها، انتخاب فناوری‌های مجاز، مدیریت زیرساخت و تصویب تصمیم‌های کلیدی در یک مرجع مرکزی قرار می‌گیرد. واحدهای سازمانی نیازها و پیشنهادهای خود را مطرح می‌کنند، اما بخش مهمی از تصمیم‌ها و اجرا از مسیر مرکز عبور می‌کند.
برای مثال، سازمان ممکن است یک سکوی مشترک هوش مصنوعی، یک مخزن دانش سازمانی، قراردادهای یکپارچه با تأمین‌کنندگان و سیاست‌های واحد برای دسترسی به داده‌ها داشته باشد. واحد منابع انسانی می‌تواند نیاز خود را برای ساخت دستیار مطرح کند، اما انتخاب مدل، تأمین زیرساخت و تعیین الزامات امنیتی در مرکز انجام شود.
مزیت اصلی این مدل، هماهنگی و امکان اعمال کنترل‌های مشترک است. سازمان می‌تواند هزینه‌های زیرساخت را تجمیع کند، از خریدهای تکراری جلوگیری کند، استانداردهای امنیتی یکسانی داشته باشد و تصویر نسبتاً جامعی از کاربردهای هوش مصنوعی به دست آورد.
اما تمرکز بیش از حد سه مشکل ایجاد می‌کند:
گلوگاه تصمیم‌گیری: درخواست‌های متعدد واحدها برای بررسی و تصویب به مرکز ارجاع می‌شوند و سرعت پاسخ‌گویی کاهش می‌یابد.
فاصله از مسئلهٔ عملیاتی: تیم مرکزی ممکن است شناخت کافی از جزئیات فرایندهای منابع انسانی، مالی، فروش یا تولید نداشته باشد.
تبدیل مرکز به مجری همه‌چیز: به‌جای فراهم‌کردن قابلیت‌ها و قواعد مشترک، مرکز مسئول اجرای تمام پروژه‌ها می‌شود و ظرفیت آن به‌سرعت محدود خواهد شد.
این مدل در سازمان‌هایی که اندازه کوچک‌تری دارند، کاربردهای محدودتری دارند یا به دلیل حساسیت داده و الزامات نظارتی به کنترل یکپارچه نیازمندند، می‌تواند انتخاب مناسبی باشد. بااین‌حال، حتی در یک مدل متمرکز هم مالکیت مسئله و مسئولیت نتایج کسب‌وکاری نباید از واحد متقاضی گرفته شود.
۲. مدل فدرال: قواعد مشترک، اختیار عملیاتی در واحدها
مدل فدرال تلاش می‌کند مزیت هماهنگی مرکزی را با شناخت و اختیار محلی ترکیب کند. در این مدل، مرکز چارچوب‌ها، استانداردها، زیرساخت‌ها و قابلیت‌های مشترک را فراهم می‌کند، اما واحدهای کسب‌وکار در محدودهٔ مشخصی درباره کاربردها، اولویت‌ها و نحوه استفاده از این قابلیت‌ها تصمیم می‌گیرند.
برای مثال، سازمان می‌تواند یک سکوی مشترک برای دسترسی به مدل‌های هوش مصنوعی، سیاست یکپارچه مدیریت دسترسی، چارچوب ارزیابی ریسک و قراردادهای پایه داشته باشد. در مقابل، منابع انسانی مسئول انتخاب و اعتبارسنجی اسناد مربوط به آیین‌نامه‌های کارکنان باشد؛ واحد مالی منابع معتبر خود را اداره کند و هر واحد درباره طراحی فرایندهای اختصاصی خود تصمیم بگیرد.
در این مدل، مرکز صرفاً یک مرجع تصویب‌کننده نیست؛ نقش مهم آن ایجاد توانمندی مشترک، تعریف مرزهای اختیار، ارائه ابزارهای استاندارد و نظارت بر رعایت الزامات سازمانی است. واحدها نیز صرفاً مصرف‌کننده خدمات مرکز نیستند؛ آن‌ها در محدودهٔ اختیارات خود مسئول انتخاب، اجرا و اداره کاربردهای هوش مصنوعی هستند.
مزیت اصلی مدل فدرال، ترکیب استانداردسازی با تناسب محلی است. واحدها برای هر تصمیم عملیاتی منتظر مرکز نمی‌مانند، اما در عین حال می‌توانند از زیرساخت، دانش، قراردادها و کنترل‌های مشترک استفاده کنند.
این مدل البته بدون تعریف دقیق مرزها می‌تواند به تعارض منجر شود:
مرکز ممکن است تصمیم‌های واحدها را بیش از حد محدود کند یا در جزئیات اجرایی آن‌ها دخالت کند.
واحدها ممکن است تغییرهایی را در پوشش اختیار محلی انجام دهند که بر امنیت، هزینه یا سایر واحدها اثر بگذارد.
مسئولیت یک موضوع ممکن است میان مرکز و واحدها مبهم شود؛ مثلاً مرکز سکوی مشترک را اداره کند، اما هیچ‌کس مسئول کیفیت منابع محتوایی مورد استفاده در آن نباشد.
بنابراین مدل فدرال به یک نظام روشن تفویض اختیار نیاز دارد. باید مشخص باشد چه تصمیم‌هایی در سطح سازمان مشترک‌اند، چه تصمیم‌هایی در اختیار واحدها قرار دارند و در چه شرایطی یک تغییر محلی باید دوباره در سطح مرکزی بررسی شود.
این مدل به‌ویژه برای سازمان‌های بزرگ و چندبخشی که کاربردهای متنوع دارند، اما همچنان به استانداردها و قابلیت‌های مشترک نیازمندند، مناسب است.
۳. مدل توزیع‌شده: اختیار گسترده در واحدها
در مدل توزیع‌شده، واحدها استقلال بیشتری در انتخاب فناوری، طراحی راهکار، اجرای پروژه و اداره کاربردهای خود دارند. هر واحد متناسب با نیاز و ظرفیت تخصصی خود تصمیم می‌گیرد و لزوماً از یک سکوی اجرایی یا فرایند تصویب مرکزی استفاده نمی‌کند.
برای مثال، واحد فروش ممکن است دستیار تحلیل مکالمات مشتریان را توسعه دهد، واحد مالی از یک راهکار تحلیل اسناد استفاده کند و منابع انسانی سامانه‌ای برای پاسخ به پرسش‌های کارکنان راه‌اندازی کند. هر واحد می‌تواند تیم، پیمانکار و زیرساخت مورد نیاز خود را انتخاب کند.
مزیت اصلی این مدل، سرعت و نزدیکی تصمیم به مسئله است. واحدی که نیاز را بهتر می‌شناسد، می‌تواند بدون طی‌کردن مسیرهای طولانی اداری راهکار مناسب را انتخاب و اصلاح کند. همچنین مسئولیت نتایج کاربرد به واحدی نزدیک می‌ماند که از آن استفاده می‌کند.
اما استقلال گسترده، هزینه‌ها و ریسک‌های خاص خود را دارد:
چند واحد ممکن است برای حل مسئله‌های مشابه، راهکارهای جداگانه بسازند و هزینه‌های تکراری ایجاد کنند.
داده‌ها، قراردادها، مدل‌ها و کنترل‌های امنیتی ممکن است بدون هماهنگی توسعه پیدا کنند.
سازمان ممکن است دید جامعی از محل استفاده از هوش مصنوعی، میزان وابستگی به تأمین‌کنندگان یا ریسک‌های انباشته نداشته باشد.
در صورت خروج یک پیمانکار یا تغییر فناوری، پشتیبانی و نگهداری هر راهکار به مسئله‌ای مستقل تبدیل می‌شود.
مدل توزیع‌شده الزاماً به معنای نبود سیاست سازمانی نیست. حتی اگر واحدها در انتخاب و اجرای راهکار مستقل باشند، سازمان همچنان باید حداقل الزامات مشترک خود را درباره امنیت، محرمانگی، نگهداری داده، خرید و قرارداد، ثبت کاربردها و پاسخ‌گویی مشخص کند. تفاوت اینجاست که اجرای این الزامات و بسیاری از تصمیم‌های عملیاتی به خود واحدها سپرده می‌شود.
این مدل در سازمان‌هایی با واحدهای نسبتاً مستقل، تخصص‌های بالغ و قابلیت‌های فنی و مدیریتی قوی قابل استفاده است. در غیر این صورت، استقلال واحدها ممکن است به‌جای چابکی، پراکندگی و افزایش هزینه ایجاد کند.
سه مدل، سه پاسخ متفاوت به مسئلهٔ توزیع اختیار
موضوع
متمرکز
فدرال
توزیع‌شده
سیاست‌ها و استانداردهای مشترک
عمدتاً در مرکز
در مرکز، با مشارکت واحدها
چارچوب مشترک با اجرای محلی
انتخاب فناوری و زیرساخت
عمدتاً مرکزی
ترکیبی؛ سکوی مشترک و انتخاب‌های محلی در محدوده مجاز
عمدتاً در واحدها
اولویت‌بندی کاربردها
با هماهنگی و تصویب مرکز
در واحدها، با هم‌راستایی سازمانی
عمدتاً در واحدها
تأمین و توسعه راهکار
تیم یا پیمانکار مرکزی
ترکیبی از قابلیت مرکزی و تیم‌های واحدی
عمدتاً در واحدها
ارزیابی ریسک
چارچوب و نظارت مرکزی
چارچوب مرکزی و ارزیابی محلی
مسئولیت اجرایی محلی تحت الزامات مشترک
اداره و پشتیبانی
عمدتاً مرکزی
تقسیم‌شده بر اساس نوع خدمت
عمدتاً محلی
هماهنگی و نظارت سازمانی
ساده‌تر، با خطر گلوگاه
نیازمند سازوکار هماهنگی روشن
دشوارتر و نیازمند شفافیت و گزارش‌دهی قوی
این جدول یک الگوی مفهومی است، نه توصیف الزام‌آور ساختار همه سازمان‌ها. در عمل، ممکن است یک سازمان در بعضی حوزه‌ها متمرکز و در حوزه‌های دیگر فدرال یا توزیع‌شده عمل کند.
چرا انتخاب یک مدل واحد برای همه تصمیم‌ها اشتباه است؟
یکی از خطاهای رایج این است که سازمان تصور کند باید یک‌بار برای همیشه یکی از سه مدل را انتخاب کند و همه تصمیم‌های هوش مصنوعی را بر همان اساس پیش ببرد. درحالی‌که محل مناسب اختیار به ماهیت تصمیم، گستره اثر آن، حساسیت داده و توانمندی واحد مربوط بستگی دارد.
برای مثال، در پرونده دستیار سازمانی می‌توان چنین ترکیبی را در نظر گرفت:
سیاست محرمانگی، امنیت و دسترسی: در سطح سازمان تعیین شود؛ زیرا تصمیم یک واحد می‌تواند بر داده‌ها و امنیت کل سازمان اثر بگذارد.
انتخاب و به‌روزرسانی اسناد منابع انسانی: به خود واحد منابع انسانی سپرده شود؛ زیرا این واحد مرجع اعتبار محتوای مربوط به کارکنان است.
زیرساخت، مدیریت مدل‌ها و قابلیت‌های مشترک: در اختیار تیم مرکزی فناوری باشد تا از دوباره‌کاری و پراکندگی فنی جلوگیری شود.
ارزیابی کیفیت پاسخ‌ها: با مشارکت واحد بهره‌بردار و تیم فنی انجام شود؛ زیرا کیفیت خدمت هم به صحت محتوایی وابسته است و هم به عملکرد سامانه.
افزودن قابلیت دسترسی به پرونده‌های شخصی: به دلیل تغییر جدی در دامنه داده و ریسک، از مسیر ارزیابی و تصویب مشترک عبور کند.
اصلاح‌های معمول و کم‌اثر: در محدوده‌ای که از پیش تعریف شده، به واحد مسئول یا تیم فنی تفویض شود.
در چنین ساختاری، یک واحد برای هر تغییر کوچک نیازمند تأیید مدیران مرکزی نیست؛ اما نمی‌تواند با عنوان استقلال عملیاتی، سیاست‌های مشترک امنیت و محرمانگی را نادیده بگیرد.
چه عواملی در انتخاب مدل اهمیت دارند؟
برای انتخاب مدل مناسب، بهتر است سازمان به‌جای پیروی از یک الگوی رایج یا انتخاب ساختاری که در سازمان دیگری موفق بوده، چند عامل را بررسی کند:
اندازه و پراکندگی سازمان: هرچه تعداد واحدها، شعب، مناطق جغرافیایی و فرایندهای مستقل بیشتر باشد، مدیریت تمام تصمیم‌ها از یک نقطه دشوارتر می‌شود.
تنوع کاربردها: سازمانی که فقط چند کاربرد محدود و مشابه دارد، احتمالاً به ساختار متمرکز ساده‌تری نیاز دارد. اما در سازمانی با کاربردهای متفاوت در تولید، مالی، منابع انسانی، فروش و خدمات مشتری، واگذاری بخشی از اختیار به واحدها اهمیت بیشتری پیدا می‌کند.
سطح ریسک و حساسیت داده: کاربردهایی که با اطلاعات محرمانه، تصمیم‌های اثرگذار بر اشخاص یا فرایندهای حیاتی سروکار دارند، به کنترل و نظارت مشترک بیشتری نیازمندند. این موضوع حتی در سازمان‌های با ساختار توزیع‌شده نیز تغییر نمی‌کند.
بلوغ واحدها: واگذاری اختیار بدون وجود نیروی متخصص، توان ارزیابی، منابع نگهداری و مسئولیت‌پذیری می‌تواند به تولید راهکارهای ناپایدار منجر شود. واحدی که اختیار بیشتری دریافت می‌کند باید توان استفاده مسئولانه از آن را هم داشته باشد.
ظرفیت مرکز: اگر تیم مرکزی منابع و تخصص کافی برای پاسخ‌گویی به تمام درخواست‌ها نداشته باشد، تمرکز کامل ممکن است به گلوگاه تبدیل شود. در مقابل، اگر مرکز نتواند استانداردهای مشترک و قابلیت‌های پایه را فراهم کند، توزیع اختیار احتمالاً به پراکندگی منجر خواهد شد.
هزینه و امکان استفاده مجدد: اگر چند واحد مسئله‌های مشابهی دارند، ساخت راهکار مستقل برای هرکدام لزوماً منطقی نیست. گاهی یک سکوی مشترک یا قابلیت قابل استفاده مجدد، هزینه و پیچیدگی سازمان را به‌طور محسوسی کاهش می‌دهد.
در نهایت، انتخاب مدل باید متناسب با توان واقعی سازمان باشد، نه صرفاً ساختار رسمی آن. سازمانی که از نظر چارت سازمانی فدرال به نظر می‌رسد، ممکن است در عمل تمام تصمیم‌ها را در یک مدیر متمرکز کرده باشد؛ همان‌طور که یک ساختار متمرکز می‌تواند بخش زیادی از تصمیم‌های عملیاتی را با تفویض اختیار روشن به واحدها واگذار کند.
مدیر منابع انسانی گفت: «اگر برای اصلاح هر بخشنامه منتظر تأیید مرکزی بمونیم، جواب‌ها همیشه عقب می‌مونن.»
مسئول ریسک و انطباق پاسخ داد: «اصلاح محتوای معتبر یک موضوعه؛ اضافه کردن دسترسی به پروندهٔ افراد یک موضوع دیگه.»
مدیر فناوری گفت: «می‌تونیم مسیر به‌روزرسانی محتوا رو به خود واحد بدیم، ولی تغییر دسترسی‌ها و قابلیت‌های سامانه مسیر جدا داشته باشه.»
مدیرعامل گفت: «همین مرزها رو بنویسیم؛ چه چیزی در اختیار واحده و چه چیزی تصمیم مشترک می‌خواد.»
در این جلسه، مسئله دیگر انتخاب یک ساختار سازمانی با نام متمرکز یا فدرال نبود. آن‌ها داشتند مشخص می‌کردند کدام اختیار باید در نزدیک‌ترین نقطه به مسئله قرار بگیرد و کدام تصمیم به دلیل اثر گسترده‌تر، باید با هماهنگی و کنترل مشترک گرفته شود.
مرکز تعالی چگونه به این مدل کمک می‌کند
مرکز تعالی می‌تواند قابلیت مشترک بسازد و به اجرای مسئولیت‌ها کمک کند؛ حدود اختیار آن نیز باید روشن باشد.
با افزایش تعداد کاربردها، نیاز به دانش، روش‌ها و ابزارهای مشترک بیشتر می‌شود. واحدهای مختلف ممکن است برای ارزیابی مدل، ثبت سامانه‌ها، انتخاب معماری، آموزش کارکنان یا بررسی تأمین‌کننده به کمک مشابهی نیاز داشته باشند. مرکز تعالی می‌تواند این قابلیت‌ها را فراهم کند.
در سازمان‌ها، واحدی که این نقش را بر عهده دارد، با عنوان‌هایی مانند «آزمایشگاه هوش مصنوعی» یا «معاونت هوشمندسازی» هم شناخته می‌شود. برای فهم جایگاه آن، باید مأموریت، خروجی و حدود اختیارش را در کنار نامش دید.
آزمایشگاه هوش مصنوعی در مأموریت آزمایشگاهی خود، بر کشف امکان‌ها، آزمودن ایده‌ها و ساخت نمونه تمرکز دارد. برای پروندهٔ ما، می‌تواند چند مدل را روی اسناد منتخب بیازماید، یک نمونهٔ دستیار بسازد و نشان دهد کدام روش پاسخ بهتری می‌دهد و چه محدودیت‌هایی دارد. خروجی این کار، نمونه و شواهدی است که به تصمیم بعدی کمک می‌کند. آزمایشگاه‌های هم‌آفرینی هوش مصنوعی مایکروسافت نمونه‌ای از تمرکز بر ساخت، آزمون و توسعهٔ راهکارند.
مرکز تعالی هوش مصنوعی، تجربه و توان تخصصی را به قابلیتی مشترک و ماندگار برای سازمان تبدیل می‌کند. در این نقش، چارچوب مشترک تدوین می‌کند، تجربه‌ها را میان واحدها منتقل می‌کند، ابزار و خدمت مشترک ارائه می‌دهد و به استفادهٔ دوباره از راهکارهای مناسب کمک می‌کند. همچنین می‌تواند ارزیابی اولیه و مشاورهٔ معماری را انجام دهد تا هر واحد همهٔ مسیر را از ابتدا طی نکند. در راهنمای ایجاد مرکز تعالی مایکروسافت نیز آموزش، هدایت پایلوت، استانداردهای مشترک و دارایی‌های قابل استفادهٔ دوباره، در کنار هم قرار دارند.
این دو مأموریت می‌توانند در یک گروه جمع شوند. مرکز تعالی می‌تواند خودش نمونه بسازد و آزمایشگاه هم می‌تواند مسئولیت استانداردگذاری، آموزش و خدمات مشترک را بپذیرد و نقش مرکز تعالی را ایفا کند. تفاوت در دامنهٔ مسئولیتی است که سازمان به آن سپرده است: ساختن و آزمودن یک راهکار، یا فراهم‌کردن روش و توان مشترک برای چندین کاربرد در طول زمان.
معاونت هوشمندسازی، عنوان یک جایگاه مدیریتی در ساختار سازمان است. مأموریت آن می‌تواند برنامه‌ریزی تحول، هماهنگی پروژه‌ها و منابع و پیگیری نتیجهٔ هوشمندسازی را دربر بگیرد و آزمایشگاه یا مرکز تعالی نیز زیرمجموعهٔ آن باشد. اختیاراتی مانند تصویب بودجه، پذیرش ریسک یا اجازهٔ بهره‌برداری باید در شرح مأموریت و تفویض اختیار مشخص شوند.
در پروندهٔ دستیار، ساختن نمونه و گزارش نتیجهٔ آزمون، مأموریت آزمایشگاهی است. وقتی همان گروه روش ارزیابی مشترک را نگهداری می‌کند، تیم‌های واحدها را آموزش می‌دهد و تجربهٔ هر پروژه را در اختیار پروژه‌های بعدی می‌گذارد، نقش مرکز تعالی را هم بر عهده گرفته است. عنوانی که سازمان برای گروه انتخاب کرده، این تقسیم کار را تغییر نمی‌دهد.
در عین حال، باید معلوم باشد مرکز در هر پرونده چه کلاهی بر سر دارد: استانداردگذار است، مشاور است، مجری است یا ارزیاب؟ اگر اجرای بخشی از کار به آن سپرده شده، تعهدات همان اجرا باید روشن شود. اگر اختیار ارزیابی یا تصویب دارد، حدود آن باید مشخص باشد.
صرف ایجاد مرکز تعالی، مسئولیت مسئلهٔ کسب‌وکار، ادارهٔ فنی خدمت و پیگیری ریسک را منتقل نمی‌کند. آن مسئولیت‌ها همچنان باید برای هر کاربرد تعیین شوند.
همچنین لازم نیست همهٔ پروژه‌ها برای هر تغییر کوچک به مرکز مراجعه کنند؛ موضوعاتی که به بررسی مشترک نیاز دارند باید از پیش روشن شوند.
همان‌طور که چهار کلاه مسئولیت الزاماً چهار سمت تازه نبودند، این قابلیت مشترک هم می‌تواند ابتدا توسط گروهی از افراد موجود فراهم شود. نام و ساختار آن زمانی مفید است که واحدها بدانند چه کمکی دریافت می‌کنند و در برابر چه چیزی پاسخ‌گو می‌مانند.
مدیر فناوری گفت: «برای ارزیابی پاسخ‌ها یک روش مشترک لازم داریم. چند واحد دیگه هم دارن دستیار می‌خوان.»
مدیرعامل پرسید: «گروه مشترکمون می‌تونه روش آزمون و ابزار ثبت نتیجه رو آماده کنه؟»
«بله؛ ولی پاسخ درست هر حوزه رو باید متخصص همون حوزه تعیین کنه.»
مدیر منابع انسانی گفت: «این کمک می‌کنه. همکاران من روی اعتبار محتوا و کاربرد کار می‌کنن؛ روش ارزیابی رو هم از صفر اختراع نمی‌کنیم.»
کمک مشترک، جای مسئولیت محلی را نگرفت. انجام آن را ممکن‌تر کرد.
عبور از هر مرحله به چه شواهدی نیاز دارد
دروازهٔ تصمیم، محل بررسی شواهد و انتخاب اقدام بعدی است؛ ساختن یک جزء، مجوز خودکار مرحلهٔ بعد نیست.
وقتی مسئله تعریف می‌شود، راهکار طراحی می‌شود، پایلوت اجرا می‌شود و خدمت به بهره‌برداری می‌رسد، سازمان فقط یک فهرست فعالیت فنی را طی نمی‌کند. در نقاطی از این مسیر باید تصمیم بگیرد آیا شواهد موجود برای ادامه کافی است و ادامه با چه شرایطی مجاز خواهد بود.
دروازهٔ تصمیم، همین نقطهٔ بررسی است. برای هر دروازه باید پرسش، شواهد لازم، مرجع تصمیم و گزینه‌های پیش رو معلوم باشند. گزینه‌ها می‌توانند ادامه، ادامه با محدودیت، بازگشت برای اصلاح، بررسی بیشتر یا توقف باشند.
در مسیر آموزشی این بخش، هفت دروازه را دنبال می‌کنیم:
دروازه
پرسش اصلی
ورود
آیا مسئله ارزش بررسی برای استفاده از هوش مصنوعی را دارد؟
تصویب
آیا مالک، دامنه، ارزش مورد انتظار و ریسک اولیه به اندازهٔ لازم روشن‌اند؟
طراحی
آیا داده، معماری و شیوهٔ تأمین برای این کاربرد قابل قبول‌اند؟
آمادگی
آیا کیفیت، امنیت و معیارهای پذیرش مورد نیاز برای ورود به پایلوت فراهم شده‌اند؟
گسترش
آیا شواهد پایلوت، افزایش دامنهٔ استفاده را توجیه می‌کنند؟
بهره‌برداری
آیا مسئولیت عملیاتی، پشتیبانی و کنترل‌های لازم برقرارند؟
ادامه یا توقف
با توجه به نتایج واقعی، خدمت باید ادامه یابد، اصلاح شود، گسترش یابد یا متوقف شود؟
این دروازه‌ها به معنای تشکیل هفت کمیته یا هفت جلسهٔ رسمی نیستند. برای یک تغییر کوچک، بررسی و تصمیم می‌تواند در همان فرایند جاری و با ثبت کوتاه انجام شود. برای گسترش اثرگذار، شواهد و مشارکت بیشتری لازم است. تغییر داده، مدل، کاربران یا حدود اختیار هم می‌تواند بازبینی یک تصمیم قبلی را ضروری کند.
در چارچوب NIST AI RMF نیز MANAGE 1.1 بر تصمیم دربارهٔ تحقق هدف و ادامهٔ توسعه یا استقرار تأکید می‌کند. MANAGE 2.4 نیز به سازوکار و مسئولیت مشخص برای کنار گذاشتن یا غیرفعال کردن سامانه‌ای می‌پردازد که عملکرد یا پیامدش با کاربرد مورد انتظار سازگار نیست. هفت دروازهٔ بالا، صورت‌بندی آموزشی این دوره برای عملیاتی کردن چنین تصمیم‌هایی است. NIST AI RMF 1.0، بخش MANAGE
پرسش فعلی پروندهٔ ما، دروازهٔ گسترش است. آماده بودن ظرفیت فنی، یکی از شواهد آن است. سازمان باید نتیجهٔ بررسی پاسخ‌ها، وضعیت منابع معتبر، کارکرد ارجاع و محدودیت‌های باقیمانده را هم ببیند و سپس دربارهٔ افزایش دسترسی تصمیم بگیرد.
نسبت نتیجهٔ ارزیابی با اختیار انتشار یا توقف، موضوع اصلی وقتی استاندارد هست، اما کسی ملزم به آزمون نیست است. آن نوشته کمک می‌کند فاصلهٔ میان داشتن گزارش و اثرگذاشتن گزارش بر تصمیم را دقیق‌تر ببینیم.
مدیرعامل پرسید: «برای تصمیم این مرحله، چه چیزهایی هنوز کم داریم؟»
مدیر منابع انسانی گفت: «نتیجهٔ بررسی پاسخ‌های مورد اختلاف و تأیید منابعی که قرار است استفاده بشه.»
مدیر فناوری گفت: «آزمون مسیر ارجاع و اجرای محدودیت پاسخ‌گویی رو هم اضافه کنیم.»
مسئول ریسک و انطباق گفت: «شرایطی که باعث محدودسازی موقت می‌شه و مرجع بازگشایی هم ثبت بشه.»
مدیرعامل روی برگهٔ پیشنهاد نوشت: «پس از تکمیل شواهد، برای تصویب گسترش بررسی شود.»
پیشنهاد روی میز ماند، اما دیگر بلاتکلیف نبود. معلوم بود برای تصمیم گرفتن چه کاری باقی مانده است.
کلاه‌ها و اختیارها را روی همان پرونده امتحان کنیم
کارت تحول، آزمون مدل حکمرانی است: آیا اختلاف میان مسئولیت‌ها به رسیدگی و تصمیم منتهی می‌شود؟
اکنون می‌توانیم دوباره به اختلافی نگاه کنیم که در درس قبل آغاز شد. فناوری از زیرساخت و رفتار سامانه صحبت می‌کند، منابع انسانی از محتوا و فرایند، حامی از نتیجهٔ پروژه و متولی ریسک از پیامد پاسخ. همه بخشی از واقعیت را می‌بینند. مدل عملیاتی باید این سهم‌ها را به رسیدگی و تصمیم متصل کند.
برای پاسخ محل اختلاف، منابع انسانی رسیدگی به نیاز کارمند و تعیین مرجع معتبر را پیگیری می‌کند. تیم فنی منشأ اشکال و اصلاح سامانه را دنبال می‌کند. پیگیری ریسک، حدود استفاده و اقدام‌های لازم را روشن می‌سازد. حامی نیز منابع و همکاری مورد نیاز را فراهم می‌کند. این مسئولیت‌ها می‌توانند بر عهدهٔ افراد یا گروه‌های مشترک باشند؛ همان‌طور که در درس دوم توضیح دادیم.
حالا برای تصمیم دربارهٔ گسترش، همین نقش‌ها با اختیارهای مشخص وارد می‌شوند: پیشنهاد آماده می‌شود، شواهد ارزیابی می‌شوند و مرجع تصویب تعیین‌شده تصمیم می‌گیرد. اگر تصمیم مشروط باشد، باید روشن باشد چه کسی تحقق شرط‌ها را بررسی می‌کند و چه زمانی اجازهٔ اجرا برقرار می‌شود.
در صورت بروز خطا هم، مسیر محدودسازی و بازگشایی باید معلوم باشد.
داشتن اختیار اجرای یک توقف موقت، لزوماً به معنای داشتن اختیار رفع همهٔ محدودیت‌ها نیست.
هرکدام باید در نقشهٔ تصمیم جای مشخص داشته باشد.
با پایان بخش اول، باید بتوانیم برای همین پرونده توضیح دهیم چه کسی یا گروهی مسئول کدام موضوع است، چه اختیارهایی دارد، از چه قابلیت مشترکی کمک می‌گیرد و در کدام نقاط باید بر مبنای شواهد تصمیم تازه‌ای گرفته شود.
پایان بخش اول
در جلسهٔ بعد، برگهٔ پیشنهاد گسترش تنها نبود. گزارش بررسی پاسخ‌ها، فهرست منابع معتبر و نتیجهٔ آزمون ارجاع هم کنارش قرار گرفته بود.
در پیشنهاد تازه، پاسخ‌گویی دربارهٔ موارد فردی کمک‌هزینه به کارشناس ارجاع می‌شد. افزایش دسترسی برای گروه مشخصی از کارکنان پیشنهاد شده بود و زمان بازبینی هم داشت.
مدیر منابع انسانی گفت: «این دامنه و منابعش رو بررسی کردیم.»
مدیر فناوری گفت: «محدودیت‌ها و مسیر ارجاع آزمایش شده.»
مسئول ریسک و انطباق شرایط محدودسازی و بازگشایی را مرور کرد.
مدیرعامل، در جایگاه مرجع تصویب تعیین‌شده برای این مرحله، گسترش محدود را تأیید کرد. تصمیم، دامنه و زمان بازبینی آن ثبت شد.
درخواست سادهٔ «یک دستیار می‌خواهم» حالا به پرونده‌ای تبدیل شده بود که می‌شد مسئولیت‌ها و تصمیم‌هایش را دنبال کرد.
پیش از بسته شدن جلسه، مدیر عملیات فهرست دیگری را باز کرد: «برای چند کار دیگه هم درخواست هوش مصنوعی داریم؛ از جست‌وجوی اسناد تا خودکار کردن چند گردش کار.»
مدیرعامل به فهرست نگاه کرد: «همهٔ این‌ها باید همین مسیر رو طی کنن؟ اصلاً کدومشون هوش مصنوعیه؟»
بخش اول تمام شده بود، اما برای شروع پرونده‌های بعدی، پرسش تازه‌ای داشتند: دقیقاً چه چیزهایی باید زیر حکمرانی هوش مصنوعی قرار بگیرند؟
این درس، قسمت دوم و پایانی بخش اول «مدل عملیاتی حکمرانی و حق تصمیم» و تشریح اسلایدهای ۱۴ تا ۱۸ دوره است. درس قبل؛ اسلایدهای کامل دوره
درس چهارم؛ تمایز هوشمندسازی، هوش تجاری و هوش مصنوعی و تشخیص قلمرو و شدت حکمرانی هر کاربرد.
مطالعهٔ درس: چه چیزی واقعاً باید زیر حکمرانی هوش مصنوعی قرار گیرد
فهرست درخواست‌های تازه
مدیر عملیات فهرستی را که در پایان جلسهٔ قبل باز کرده بود، روی نمایشگر آورد. بالای صفحه نوشته بود: «درخواست‌های هوش مصنوعی واحدها».
ردیف اول، کنترل روشنایی ساختمان بود. ردیف دوم، داشبورد فروش. بعد، ثبت‌نام هوشمند دوره‌های آموزشی، جست‌وجوی اسناد و پیشنهاد پاسخ به درخواست‌های کارکنان آمده بود.
مدیرعامل پرسید: «برای همهٔ این‌ها باید همون نقش‌ها و دروازه‌های تصمیم رو تعیین کنیم؟»
مدیر مالی به ردیف ثبت‌نام اشاره کرد: «این قرار بود فرم بگیره، ظرفیت رو کنترل کنه و پیام تأیید بفرسته. کجاش هوش مصنوعیه؟»
مدیر عملیات گفت: «اسم پیشنهادی واحد، ثبت‌نام هوشمنده.»
مدیر فناوری پرسید: «روشنایی هم با حسگر و ساعت کار می‌کنه یا قراره از داده‌ها چیزی یاد بگیره و پیش‌بینی کنه؟»
مسئول ریسک و انطباق گفت: «حتی اگر هوش مصنوعی نباشه، ایمنی و امنیتش مهمه. ولی کنترل‌هایی که برای رفتار مدل می‌خوایم، باید معلوم باشه کجا موضوعیت دارن.»
مدیرعامل به عنوان بالای فهرست نگاه کرد. تا چند دقیقه پیش، فکر می‌کرد مسئله فقط تقسیم بودجه میان چند پروژهٔ تازه است. حالا باید معلوم می‌شد این فهرست، اصلاً فهرست چه چیزهایی است.
گفت: «قبل از اینکه مسیر تصویبشون رو تعیین کنیم، روشن کنیم هرکدوم واقعاً چه کاری انجام می‌ده و چطور.»
در درس سوم، حق پیشنهاد، ارزیابی، تصویب و توقف را برای کاربرد و دامنهٔ مشخص دستیار روشن کردیم. همچنین دیدیم که عبور از هر مرحله به شواهد و مرجع تصمیم معلوم نیاز دارد.
فهرست تازهٔ مدیر عملیات، دامنهٔ همان تصمیم‌ها را به پرسش می‌کشد. کنترل روشنایی، داشبورد فروش و پیشنهاد پاسخ، همگی زیر عنوان هوش مصنوعی آمده‌اند؛ اما به روش یکسانی کار نمی‌کنند. پیش از تعیین مسیر حکمرانی آن‌ها، باید روش تولید خروجی و نقش آن در تصمیم و اقدام را بشناسیم. نام‌هایی مانند «هوشمند» و «خودکار» این شناخت را فراهم نمی‌کنند.
با این درس، قسمت اول بخش دوم دوره را آغاز می‌کنیم: تشخیص قلمرو حکمرانی.
هوشمندسازی یا هوش مصنوعی
متصل شدن تجهیزات و خودکار شدن عملیات، به‌تنهایی وجود هوش مصنوعی را نشان نمی‌دهد.
هوشمندسازی، که در ادبیات ما برداشتی غلط از کلمه Automation یا خودکارسازی است، می‌تواند شامل اتصال تجهیزات، دریافت داده از حسگر، کنترل از راه دور یا اجرای خودکار یک فرایند باشد. چراغی که با حضور فرد روشن می‌شود، تجهیزی که وضعیت خود را ارسال می‌کند یا سامانه‌ای که در ساعت معین فرمانی را اجرا می‌کند، همه این‌ها می‌توانند خودکار باشند، اما لزوماً از هوش مصنوعی استفاده نمی‌کنند.
در مقابل، در بحث هوش مصنوعی با استنباط خروجی از ورودی سروکار داریم؛ خروجی می‌تواند پیش‌بینی، توصیه، محتوا یا تصمیم باشد. برای مثال، سامانه‌ای ممکن است از وضعیت تجهیزات، احتمال خرابی را برآورد کند یا از روی اسناد، پاسخ یک پرسش را تولید کند.
این دو حوزه می‌توانند در یک راهکار کنار هم قرار بگیرند. حسگر، داده جمع می‌کند؛ مدل، از داده استنباط می‌کند؛ سامانهٔ کنترل، اقدامی را اجرا می‌کند. برای حکمرانی باید بدانیم هر بخش چه نقشی دارد و خطا یا اختلال در آن چه پیامدی ایجاد می‌کند.
تفاوت فنی چه تغییری در حکمرانی ایجاد می‌کند
با وارد شدن استنباط و اثرگذاری بر تصمیم، بررسی رفتار سامانه و مسئولیت پیامد اهمیت بیشتری پیدا می‌کند.
در یک سامانهٔ متصل یا خودکار، پرسش‌هایی مانند صحت دریافت داده، امنیت تجهیزات، ایمنی و تداوم عملیات مهم‌اند. اگر فرمان از پیش تعریف‌شده باید در شرایط معینی اجرا شود، باید بتوانیم صحت همین منطق و اجرای آن را بررسی کنیم.
وقتی یک مدل آموخته‌شده یا دانش‌محور در تولید خروجی نقش دارد، پرسش‌های دیگری هم اضافه می‌شوند: خروجی در چه شرایطی قابل اتکاست؟ چه خطاهایی دارد؟ آیا برای این کاربرد ارزیابی شده است؟ انسان در کدام نقطه باید مداخله کند و مسئول پیامد استفاده کیست؟
این تفاوت، ریسک‌های قبلی را حذف نمی‌کند. یک راهکار هوش مصنوعی متصل به تجهیزات، همچنان به ایمنی و امنیت زیرساخت نیاز دارد. کنترل‌های مربوط به رفتار مدل و تصمیم، بر آن‌ها افزوده می‌شوند.
پیام این مقایسه برای مدیر آن است که ترکیب مسئولیت‌ها را با ماهیت واقعی راهکار تنظیم کند. عملیات، مهندسی و فناوری در ادارهٔ تجهیزات نقش دارند؛ با ورود استنباط و تصمیم‌سازی، مسئولیت کسب‌وکار و پیگیری ریسک نیز باید در همان پرونده روشن شود.
مدیر عملیات توضیح داد: «روشنایی فعلاً با حسگر حضور و برنامهٔ زمانی کنترل می‌شه.»
مدیر فناوری گفت: «پس این درخواست رو با همین مشخصات ثبت کنیم. اگر بعداً پیشنهاد پیش‌بینی مصرف یا تشخیص وضعیت اضافه شد، اون بخش رو جدا بررسی می‌کنیم.»
مسئول ریسک و انطباق گفت: «و خروج از فهرست هوش مصنوعی، کنترل ایمنی و امنیت ساختمان رو حذف نمی‌کنه.»
مدیر مالی کنار ردیف اول نوشت: «کنترل روشنایی با حسگر و برنامهٔ زمانی». کلمهٔ «هوشمند» دیگر تنها توضیح آن ردیف نبود.
داشبورد گزارش می‌دهد یا سامانه تصمیم می‌سازد
برای تعیین کنترل‌ها، باید دید گزارش، پیش‌بینی یا توصیه چگونه وارد تصمیم و اقدام می‌شود.
داشبورد می‌تواند داده‌ها را گردآوری و شاخص‌ها را نمایش دهد. در این وضعیت، پرسش‌های اصلی دربارهٔ کیفیت و تبار داده، سطح دسترسی، تعریف درست شاخص و تفسیر گزارش‌اند. مدیر با اتکا به گزارش، تصمیم می‌گیرد.
حال فرض کنیم همان محیط، فروش دورهٔ بعد را پیش‌بینی کند، برای مشتریان امتیاز بسازد یا پیشنهاد تخصیص منابع بدهد. باید معلوم شود این خروجی با چه روشی تولید شده و چگونه در تصمیم به کار می‌رود. اگر در تولید آن از هوش مصنوعی استفاده شده باشد، عملکرد مدل، خطا، سوگیری و حدود استفاده هم باید بررسی شوند.
گام بعدی، اتصال خروجی به اقدام است. نمایش یک پیشنهاد با اجرای خودکار آن تفاوت دارد. کاربری که می‌تواند پیشنهاد را بررسی و اصلاح کند، در موقعیت متفاوتی با انسانی است که فقط پس از اجرای تصمیم از نتیجه مطلع می‌شود.
این مرزها با ظاهر صفحه مشخص نمی‌شوند. یک داشبورد ممکن است صرفاً گزارش دهد یا در پشت آن، پیش‌بینی و توصیه تولید شود. یک رابط گفت‌وگو هم ممکن است فقط پاسخ ذخیره‌شده را نمایش دهد یا از مدل برای ساخت پاسخ استفاده کند.
شدت حکمرانی را باید با توجه به اثر سامانه بر تصمیم و اقدام تعیین کرد؛ داشتن داشبورد یا الگوریتم، پاسخ نهایی این پرسش نیست.
مدیر مالی دربارهٔ داشبورد فروش گفت: «نسخهٔ فعلی فقط فروش شعب رو کنار هم نشون می‌ده.»
مدیر عملیات پاسخ داد: «در درخواست جدید نوشته‌ن سهمیهٔ ماه بعد رو هم پیشنهاد بده.»
مدیر فناوری پرسید: «بر اساس یک فرمول مشخص یا یک مدل پیش‌بینی؟»
مدیرعامل گفت: «پس این‌ها رو در یک ردیف مبهم ننویسیم. گزارش فعلی یک کاره، پیش‌بینی و پیشنهاد سهمیه کارهای دیگه‌ای هستن.»
ردیف دوم فهرست، به توضیح دقیق‌تری از خروجی و نقش آن در تصمیم نیاز داشت.
کارکرد سامانه به‌تنهایی هوش مصنوعی بودن را ثابت نمی‌کند
عبارت‌هایی مانند «پیش‌بینی»، «تشخیص» و «توصیه» توضیح می‌دهند که سامانه قرار است چه کمکی بکند؛ اما برای شناخت ماهیت فنی آن کافی نیستند. باید بدانیم این خروجی چگونه تولید می‌شود و چه روشی پشت آن قرار دارد.
نکته مهم این است که هوش مصنوعی را نباید با هوش مصنوعی مولد یکی گرفت. تولید متن، تصویر، صدا و کد تنها یکی از خانواده‌های فناوری هوش مصنوعی است. در بسیاری از کاربردهای صنعتی، اتفاقاً مدل‌های غیرمولد کاربردی‌تر، اقتصادی‌تر و قابل اتکاترند.
برای مثال، سامانه‌ای که از روی تصویر قطعه، عیب سطحی را تشخیص می‌دهد، الزاماً چیزی تولید نمی‌کند. مدلی که احتمال خرابی یک تجهیز را بر اساس دما، لرزش و سابقه عملکرد پیش‌بینی می‌کند، متن یا تصویر نمی‌سازد. سامانه‌ای که مصرف انرژی را بهینه می‌کند، محصولش ممکن است صرفاً یک نقطه تنظیم یا برنامه عملیاتی باشد. این‌ها می‌توانند نمونه‌هایی از کاربرد هوش مصنوعی باشند، بدون آنکه مولد باشند.
توصیف، تشخیص، پیش‌بینی، توصیه، استدلال، تولید محتوا و اقدام، کارکردهایی‌اند که باید روش پیاده‌سازی آن‌ها را هم شناخت.
از بینش تا اقدام؛ هوش مصنوعی چه کارهایی انجام می‌دهد؟
کارکردهای هوش مصنوعی را می‌توان از دو منظر بررسی کرد: نخست، نوع مسئله و خروجی مورد انتظار؛ دوم، روش فنی مورد استفاده برای حل آن مسئله.
در سطح کارکرد، طیفی از قابلیت‌ها وجود دارد:
توصیف: استخراج و نمایش وضعیت از داده‌ها؛ مانند گزارش وضعیت خط تولید یا خلاصه‌سازی روند عملکرد تجهیزات.
تشخیص و طبقه‌بندی: شناسایی یک وضعیت یا قرار دادن داده در یک گروه مشخص؛ مانند تشخیص عیب در تصویر محصول، شناسایی قطعه معیوب یا دسته‌بندی درخواست‌های مشتریان.
پیش‌بینی و برآورد: تخمین یک وضعیت یا مقدار در آینده؛ مانند پیش‌بینی تقاضا، زمان خرابی تجهیز، میزان تولید یا مصرف انرژی.
کشف الگو و ناهنجاری: شناسایی رفتارهای غیرمعمول یا روابطی که به‌سادگی با قواعد ثابت قابل تشخیص نیستند؛ مانند کشف تقلب، شناسایی انحراف در فرایند تولید یا تشخیص رفتار غیرعادی شبکه.
توصیه و تصمیم‌سازی: پیشنهاد یک اقدام بر اساس داده‌ها، محدودیت‌ها و هدف مشخص؛ مانند پیشنهاد زمان مناسب تعمیرات، انتخاب ترکیب تولید یا تعیین اولویت رسیدگی به سفارش‌ها.
استدلال و استنتاج: رسیدن به نتیجه از طریق قواعد، روابط و بازنمایی دانش؛ مانند سامانه‌های خبره‌ای که با استفاده از دانش تخصصی، شرایط را ارزیابی و نتیجه‌ای قابل توضیح ارائه می‌کنند.
تولید محتوا: ساخت متن، تصویر، صدا، ویدئو یا کد بر اساس ورودی و زمینه؛ قابلیتی که در مدل‌های هوش مصنوعی مولد دیده می‌شود.
برنامه‌ریزی و اقدام: انتخاب و اجرای مجموعه‌ای از گام‌ها برای رسیدن به یک هدف؛ مانند سامانه‌های عامل‌محور که می‌توانند ابزارها را فراخوانی کنند، اطلاعات جمع‌آوری کنند و فرایندهایی را پیش ببرند.
این فهرست به معنای آن نیست که همه این کارکردها الزاماً با هوش مصنوعی انجام می‌شوند. یک گزارش توصیفی ممکن است فقط با پرس‌وجو از پایگاه داده ساخته شود؛ یک سامانه تشخیص ممکن است مجموعه‌ای از قواعد ثابت را اجرا کند؛ و یک پیش‌بینی نیز ممکن است بر روش‌های آماری متعارف متکی باشد. عنوان کارکرد، به‌تنهایی روش فنی را مشخص نمی‌کند.
خانواده‌های فنی هوش مصنوعی
برای شناخت روش پیاده‌سازی، باید به خانواده فناوری مورد استفاده توجه کرد. این خانواده‌ها مرزهای کاملاً جدا از هم ندارند و یک محصول می‌تواند چند مورد از آن‌ها را ترکیب کند:
یادگیری ماشین: استخراج الگو از داده‌ها و استفاده از آن‌ها برای پیش‌بینی، طبقه‌بندی، برآورد یا کشف ناهنجاری. بسیاری از کاربردهای صنعتی هوش مصنوعی، از کنترل کیفیت تا پیش‌بینی خرابی تجهیزات، در این خانواده قرار می‌گیرند.
بینایی ماشین: تحلیل تصاویر و ویدئو برای شناسایی اشیا، تشخیص عیب، اندازه‌گیری، کنترل کیفیت و پایش فرایندها. این حوزه می‌تواند از روش‌های کلاسیک پردازش تصویر تا مدل‌های یادگیری عمیق استفاده کند.
پردازش زبان طبیعی: تحلیل، استخراج اطلاعات و درک متن و گفتار؛ از دسته‌بندی اسناد و استخراج موجودیت‌ها تا پاسخ‌گویی و ترجمه.
سامانه‌های خبره و هوش مصنوعی نمادین: استفاده از قواعد، منطق و بازنمایی دانش برای استنتاج و تصمیم‌گیری در حوزه‌هایی که دانش تخصصی و روابط قابل تعریف اهمیت دارند.
یادگیری تقویتی: یادگیری سیاست تصمیم‌گیری از طریق تعامل با محیط و دریافت بازخورد؛ برای مثال در کنترل فرایندها، مدیریت منابع یا بهینه‌سازی رفتار یک عامل.
هوش مصنوعی مولد: تولید محتوای جدید بر اساس الگوهای آموخته‌شده؛ از مدل‌های زبانی بزرگ تا مدل‌های تولید تصویر و صدا.
در کنار این خانواده‌ها، روش‌های بهینه‌سازی و تحقیق در عملیات نیز در بسیاری از سامانه‌های صنعتی به کار می‌روند. البته هر الگوریتم بهینه‌سازی را نباید خودبه‌خود هوش مصنوعی نامید؛ ممکن است یک روش ریاضی یا الگوریتم کلاسیک باشد، یا در کنار مدل هوش مصنوعی برای انتخاب بهترین اقدام استفاده شود.
چرا این تمایز در کاربرد صنعتی اهمیت دارد؟
در انتخاب راهکار، نباید صرفاً به دنبال استفاده از جدیدترین یا پرسر‌وصداترین فناوری بود. مسئله باید تعیین کند که چه روشی مناسب‌تر است.
برای مثال، اگر هدف تشخیص ترک روی قطعات تولیدی باشد، احتمالاً یک مدل بینایی ماشین مناسب‌تر از یک مدل زبانی مولد است. اگر هدف پیش‌بینی خرابی تجهیزات باشد، مدل‌های پیش‌بینی مبتنی بر داده‌های حسگر و سوابق تعمیرات می‌توانند انتخاب مناسب‌تری باشند. اگر مسئله، پاسخ‌گویی به پرسش‌های کارکنان از روی اسناد سازمانی باشد، مدل زبانی و بازیابی اطلاعات می‌توانند نقش اصلی داشته باشند.
حتی در یک راهکار واحد نیز ممکن است چند خانواده فناوری کنار هم قرار بگیرند: یک مدل پیش‌بینی وضعیت تجهیز را تخمین بزند، یک موتور قواعد محدودیت‌های عملیاتی را بررسی کند و یک سامانه زبانی نتیجه را برای اپراتور توضیح دهد. در چنین ساختاری، مولد بودن یکی از اجزاست، نه تعریف کل راهکار.
بنابراین، هنگام بررسی یک محصول یا پیشنهاد فنی باید دست‌کم سه پرسش را از هم جدا کنیم:
۱. سامانه چه کاری انجام می‌دهد؟ تشخیص، پیش‌بینی، توصیه، استنتاج، تولید محتوا یا اقدام؟
۲. این کار چگونه انجام می‌شود؟ قواعد ثابت، روش آماری، یادگیری ماشین، بینایی ماشین، سامانه خبره، مدل مولد یا ترکیبی از آن‌ها؟
۳. خروجی در کدام تصمیم یا فرایند استفاده می‌شود؟ آیا صرفاً اطلاعاتی برای کاربر فراهم می‌کند، مبنای تصمیم قرار می‌گیرد یا مستقیماً اقدامی را اجرا می‌کند؟
این تفکیک کمک می‌کند قابلیت واقعی سامانه را از عنوان‌های بازاریابی آن جدا کنیم و درباره تناسب فناوری، ریسک، هزینه و سطح نظارت انسانی دقیق‌تر تصمیم بگیریم.
مدیر منابع انسانی به ردیف «ثبت‌نام هوشمند» اشاره کرد: «فرم رو می‌گیره، ظرفیت رو می‌سنجه و اگر جا باشه پیام تأیید می‌فرسته.»
مدیر فناوری پرسید: «چیزی از سابقه فرد استنباط می‌کنه؟ دوره‌ای پیشنهاد می‌ده یا فقط همین شرط‌ها رو اجرا می‌کنه؟»
«فعلاً فقط همین شرط‌ها.»
مدیرعامل گفت: «پس همین رو بنویسیم. اگر پیشنهاد دوره بر اساس نیاز فرد اضافه شد، باید روش اون قابلیت رو هم روشن کنیم.»
مدیر تولید که تا آن لحظه ساکت بود، گفت: «ما هم یک سامانه داریم که از روی تصویر محصول، عیب سطحی رو تشخیص می‌ده. اون هم هوش مصنوعی مولده؟»
مدیر فناوری پاسخ داد: «نه. اون یک مدل بینایی ماشینه. اصلاً قرار نیست چیزی تولید کنه؛ باید عیب رو درست تشخیص بده. برای پیش‌بینی خرابی تجهیزات هم می‌تونیم از مدل‌های پیش‌بینی استفاده کنیم.»
مدیرعامل گفت: «پس در فهرست، فقط ننویسیم هوش مصنوعی. مشخص کنیم چه قابلیتی داریم و با چه روشی پیاده شده.»
نام درخواست عوض نشد، اما شرح آن دیگر اجرای شرط‌های ثابت، استنباط از داده‌ها و تولید پیشنهاد را با هم مخلوط نمی‌کرد.
چه چیزهایی را نباید صرفاً به دلیل نامشان هوش مصنوعی بدانیم
در خواندن مثال‌ها، روش پیاده‌سازی تعیین‌کننده است؛ نام محصول یا پیچیدگی نرم‌افزار کافی نیست.
اجرای صرف یک دستور یا نگاشت از پیش تعیین‌شده، محاسبه با فرمول مشخص، نمایش دادهٔ ذخیره‌شده و انتخاب مستقیم یک پاسخ آماده، به‌خودی‌خود وجود هوش مصنوعی را نشان نمی‌دهند. پیچیده شدن نرم‌افزار یا زیاد شدن تعداد شروط نیز به‌تنهایی این وضعیت را تغییر نمی‌دهد.
خودکارسازی سادهٔ صنعتی، آبیاری زمان‌بندی‌شده، کنترل تردد مبتنی بر شناسه و روشنایی برنامه‌ریزی‌شده، نمونه‌هایی‌اند که باید بر اساس منطق واقعی کارشان بررسی شوند. همین‌طور وجود پورتال، پایگاه داده، نمایشگر وضعیت یا فهرست پرسش‌های متداول، نشانهٔ کافی برای تشخیص هوش مصنوعی نیست.
در این مرزبندی، اجرای مستقیم قواعد را باید از استنتاج دانش‌محور تفکیک کرد. سامانه‌های هوش مصنوعی می‌توانند از روش‌های یادگیری ماشین یا رویکردهای منطقی و دانش‌محور استفاده کنند. بنابراین داشتن قواعد یا تکرارپذیر بودن خروجی، به‌تنهایی دلیل خارج بودن از هوش مصنوعی نیست. در توضیح OECD نیز هر دو خانوادهٔ یادگیری ماشین و رویکردهای دانش‌محور در قلمرو هوش مصنوعی آمده‌اند.
به همین دلیل، در بررسی نمونه‌های ساده باید روش اجرای کار را شناخت. یک پاسخ‌گوی مبتنی بر جواب‌های از پیش تعیین‌شده با دستیاری که پاسخ را با مدل می‌سازد، یکسان نیست. نام «مترجم»، «بازی»، «کنترل‌گر» یا «دستیار» نیز بدون بررسی روش اجرا، برای طبقه‌بندی کافی نیست.
هدف این غربال، کم‌ارزش دانستن خودکارسازی نیست. ممکن است یک راهکار ساده، دقیقاً مسئلهٔ سازمان را حل کند. موضوع آن است که ارزش و کنترل مورد نیازش را بر اساس کاری که واقعاً انجام می‌دهد بسنجیم.
مدیر مالی گفت: «اگر ثبت‌نام با همین قواعد کار می‌کنه و نیازمون رو هم برطرف می‌کنه، چرا باید تبدیلش کنیم به پروژهٔ هوش مصنوعی؟»
مدیر منابع انسانی پاسخ داد: «لازم نیست. مسئلهٔ فعلی، ثبت‌نام و کنترل ظرفیته.»
مدیر عملیات کنار همان ردیف، روش اجرای کار را اضافه کرد. حالا می‌شد دربارهٔ ارزش و هزینهٔ درخواست صحبت کرد، بی‌آنکه نام «هوشمند» جای توضیح راهکار را بگیرد.
دو غربال برای قلمرو و شدت حکمرانی
ورود به قلمرو هوش مصنوعی و تعیین شدت کنترل، دو تصمیم مرتبط اما متفاوت‌اند.
اکنون می‌توان بررسی اولیه را در دو گام انجام داد.
گام نخست این است که مشخص کنیم سامانه با استفاده از مدل آموخته‌شده یا دانش‌محور، از ورودی برای تولید خروجی استنباط می‌کند یا نه. اگر پاسخ منفی باشد، آن درخواست در فهرست هوش مصنوعی قرار نمی‌گیرد؛ اما کنترل‌های فناوری اطلاعات، داده، امنیت، حریم خصوصی و ایمنی همچنان برقرارند.
اگر پاسخ مثبت یا هنوز نامشخص باشد، کاربرد باید بررسی شود. نامشخص بودن را نباید با نبودن هوش مصنوعی یکی گرفت. ممکن است لازم باشد روش کار، اجزای راهکار یا نقش تأمین‌کننده روشن‌تر شود.
گام دوم، بررسی کاربرد مشخص و پیامد آن است. یک فناوری یکسان می‌تواند در کاربردهای متفاوت، اثر و اختیار متفاوتی داشته باشد. در این غربال، وضعیت‌های کاربرد ممنوع، کاربرد پرریسک یا جزء ایمنی، کاربرد مشمول شفافیت و سایر کاربردها از هم تفکیک می‌شوند. این تقسیم، مسیر بررسی و کنترل را مشخص می‌کند؛ تشخیص ممنوعیت یا الزام خاص باید با قواعد حاکم بر همان کاربرد انجام شود.
برای تعیین شدت بررسی، این پنج پرسش اهمیت دارند:
عامل
پرسش برای کاربرد مورد بررسی
شدت پیامد
اگر خروجی اشتباه باشد، چه آسیبی ممکن است ایجاد شود؟
مقیاس استفاده
چند نفر، واحد یا فرایند از آن اثر می‌پذیرند؟
حساسیت داده
چه داده‌هایی وارد سامانه می‌شوند و چه محدودیت‌هایی دارند؟
میزان اتکای انسان
خروجی فقط برای بررسی است یا عملاً مبنای تصمیم و اقدام قرار می‌گیرد؟
امکان بازگشت و جبران
آیا می‌توان نتیجه را اصلاح کرد و پیامد آن را جبران کرد؟
در پروندهٔ دستیار، نمایش یک بند عمومی با ارائهٔ نتیجه دربارهٔ وضعیت فردی کارکنان، کاربرد یکسانی نیست. اگر پاسخ به اقدام خودکار متصل شود، پرسش‌های دیگری دربارهٔ اختیار، کنترل و امکان اصلاح نتیجه مطرح می‌شوند.
نوع داده نیز در تعیین شدت کنترل اثر دارد. در تنظیم‌گری داده‌ها؛ تعادل میان نوآوری، حریم خصوصی و امنیت تفاوت داده‌های عمومی، شخصی و حساس، اسرار صنعتی و داده‌های تولیدی و تحلیلی را توضیح داده‌ام؛ این تفکیک، مبنای روشن‌کردن هدف مجاز استفاده و سطح دسترسی است.
هوش مصنوعی بودن، ورود به فرایند بررسی را مشخص می‌کند؛ کاربرد و پیامد، شدت حکمرانی را تعیین می‌کنند.
مدیرعامل گفت: «پس اگر یک درخواست هوش مصنوعی بود، قرار نیست حتماً همون کنترل دستیار منابع انسانی رو براش تکرار کنیم.»
مسئول ریسک و انطباق پاسخ داد: «باید کاربردش رو ببینیم. اینکه چه داده‌ای می‌گیره، چه کسی به خروجی تکیه می‌کنه و اگر اشتباه کرد چه اتفاقی می‌افته.»
مدیر فناوری به ردیف جست‌وجوی اسناد اشاره کرد: «برای این هم باید روشن کنیم قرار است سند رو پیدا کنه، پاسخ بسازه یا بعد از پاسخ کاری انجام بده.»
فهرست درخواست‌ها هنوز کامل نشده بود. این بار، ابهام دقیق‌تری داشتند که باید برطرف می‌شد.
همه از دستیار یک چیز نمی‌خواهند
تا معنای دستیار و حدود کار آن روشن نشود، دامنهٔ پروژه نیز مشترک نخواهد بود.
در کارت تحول دوم، همان واژه‌ای که در شروع دوره ساده به نظر می‌رسید، دوباره مسئله‌ساز می‌شود: «دستیار». این بار باید ببینیم هر واحد از آن چه خروجی و چه اختیاری انتظار دارد.
برداشت از دستیار
چیزی که باید دربارهٔ دامنه روشن شود
FAQ داخلی
آیا فقط پاسخ‌های از پیش تعیین‌شده را نمایش می‌دهد؟
جست‌وجوی سازمانی
آیا سند و محل اطلاعات را پیدا می‌کند یا از آن نتیجه هم می‌گیرد؟
RAG روی اسناد
آیا پس از بازیابی منابع، با مدل پاسخ تولید می‌کند و حدود اتکا به آن چیست؟
داشبورد و تحلیل
آیا گزارش می‌دهد، پیش‌بینی می‌کند یا توصیه‌ای برای تصمیم می‌سازد؟
اتوماسیون فرایند
آیا قواعد مشخص را اجرا می‌کند و در کدام مرحله به نظر انسان نیاز دارد؟
عامل یا اقدام خودکار
چه اقدامی مجاز است انجام دهد و حدود اختیارش کجاست؟
این برداشت‌ها می‌توانند به داده، روش ارزیابی، مسئولیت و کنترل متفاوتی نیاز داشته باشند. بعضی نیز ممکن است در یک محصول کنار هم قرار بگیرند. لازم است دامنهٔ هر قابلیت مشخص شود تا نام مشترک محصول، تفاوت‌ها را پنهان نکند.
توافق درس قبل دربارهٔ گسترش، برای همان کاربرد و محدودیت‌های تعریف‌شده بود. نمی‌توان آن را به هر قابلیت تازه‌ای که زیر عنوان «دستیار» پیشنهاد می‌شود تعمیم داد. افزودن تولید پاسخ، دسترسی به دادهٔ فردی یا اختیار اقدام باید در شرح کاربرد دیده شود و دوباره از مسیر تصمیم مربوط بگذرد.
در این مرحله باید بتوانیم درخواست مبهم را چنان توضیح دهیم که روشن باشد کدام قابلیت، با چه روش و چه نقشی در تصمیم یا اقدام، موضوع بررسی است.
پایان قسمت اول بخش دوم
مدیر منابع انسانی گفت: «برای واحد ما، دستیار باید پاسخ سؤال‌های کارکنان رو از منابع معتبر بده و موارد خاص رو ارجاع بده.»
مدیر عملیات گفت: «من انتظار داشتم درخواست رو هم بگیره و گردش کار رو جلو ببره.»
مدیر مالی گفت: «من از داشبوردی حرف می‌زدم که وضعیت رو نشون بده و برای تصمیم کمک کنه.»
مدیر فناوری به سه ردیف فهرست اشاره کرد: «این‌ها ممکنه در یک محصول جمع بشن، ولی الان سه کاربرد متفاوت داریم. باید جدا معلوم باشه چه داده‌ای می‌خوان، چه خروجی‌ای می‌دن و چه کاری اجازه دارن انجام بدن.»
مدیرعامل کلمهٔ «دستیار» را از بالای فهرست پاک نکرد. فقط زیر آن، جای توضیح کاربردها را باز کرد.
پرسید: «خوب، قبل از انتخاب این قابلیت‌ها، مسئلهٔ اصلی هر واحد چیه؟ کارکنان جواب رو پیدا نمی‌کنن، اسناد متناقضه یا فرایند رسیدگی طولانیه؟»
برای پاسخ به این سؤال، فهرست فناوری‌ها کافی نبود. باید خود مسئله را صورت‌بندی می‌کردند.
این درس، قسمت اول بخش دوم «قلمرو حکمرانی» و تشریح اسلایدهای ۱۹ تا ۲۶ دوره است. درس قبل؛ اسلایدهای کامل دوره
درس پنجم؛ شناخت سازمان، تله‌های صورت‌بندی، بررسی علت‌ها و روشن‌کردن اعتبار اسناد و مسئولیت محتوا.
مطالعهٔ درس: پیش از انتخاب هوش مصنوعی، مسئله را درست تعریف کنیم
پرسشی که جلسه را به عقب برگرداند
مدیرعامل هنوز کنار نمایشگر ایستاده بود. زیر عنوان «دستیار هوشمند سازمان»، سه انتظار متفاوت نوشته بودند: پاسخ به پرسش‌های کارکنان، پیش‌بردن درخواست‌ها و کمک به تصمیم مدیران.
پرسید: «خوب، مسئلهٔ اصلی هر واحد چیه؟ کارکنان جواب رو پیدا نمی‌کنن، اسناد متناقضه یا فرایند رسیدگی طولانیه؟»
مدیر منابع انسانی گفت: «کارشناس‌های ما بخش زیادی از روز رو صرف جواب دادن به سؤال‌های تکراری می‌کنن.»
مدیر عملیات گفت: «برای ما مشکل اینه که درخواست از یک واحد به واحد دیگه می‌ره و معلوم نیست کجا مونده.»
مدیر مالی پوشه‌اش را بست: «من هم می‌خوام وقتی دربارهٔ یک هزینه سؤال می‌کنم، مجبور نباشم از چند نفر جداگانه توضیح بگیرم.»
مدیر فناوری به سه جمله نگاه کرد. «اگر برای همهٔ این‌ها یک چت‌بات بسازیم، از کجا می‌فهمیم کدوم مشکل واقعاً حل شده؟»
چند لحظه کسی چیزی نگفت. روی میز، پیشنهاد فنی دستیار باز بود؛ چند صفحه دربارهٔ مدل، زیرساخت و قابلیت‌ها. اما برای پاسخ به این پرسش، صفحه‌ای نداشت.
مدیرعامل گفت: «فعلاً پیشنهاد فنی رو ببندیم. قبل از اینکه بگیم چی می‌خریم، بنویسیم چه چیزی باید بهتر بشه.»
در درس چهارم دیدیم که عنوان یک سامانه، ماهیت و قلمرو حکمرانی آن را روشن نمی‌کند. برای تشخیص نوع کنترل، باید بدانیم سامانه چگونه کار می‌کند و خروجی آن چه نقشی دارد.
گفت‌وگوی مدیران اکنون یک قدم عقب‌تر رفته است: هرکدام از قابلیت‌های درخواستی قرار است کدام مسئلهٔ سازمان را حل کنند؟ پاسخ‌گویی به پرسش‌ها، پیگیری درخواست و کمک به تصمیم، زیر یک نام جمع شده‌اند؛ درحالی‌که مدیران هنوز دربارهٔ چیزی که باید بهتر شود توافق ندارند. پیشنهاد فنی آماده است، اما صورت‌مسئله هنوز صفحه‌ای در آن ندارد. «دستیار می‌خواهیم» آغاز گفت‌وگوست؛ تصمیم سرمایه‌گذاری به تعریف روشن‌تری نیاز دارد.
این درس، اسلایدهای ۲۷ تا ۳۵ ارائه را به ترتیب دنبال می‌کند؛ از آغاز «حکمرانی مسئله و سبد سرمایه‌گذاری» تا سومین کارت تحول. در این قسمت بر شناخت و صورت‌بندی مسئله تمرکز می‌کنیم؛ منشور پروژه، سبد سرمایه‌گذاری و شواهد مورد انتظار از پایلوت، ادامهٔ همین بحث در درس بعد خواهند بود.
فناوری، آخرین حلقهٔ حل مسئله است
از هدف، تصمیم، فرایند، ذی‌نفع و محدودیت شروع می‌کنیم و سپس به گزینه‌های راه‌حل می‌رسیم.
مسیر حل مسئله از شناخت «سازمان» آغاز می‌شود: هدف چیست، چه تصمیمی باید گرفته شود، چه فرایندی درگیر است، چه کسانی از نتیجه اثر می‌پذیرند و چه محدودیت‌هایی وجود دارد؟
پس از آن، به «مسئله» می‌رسیم: فاصلهٔ وضع موجود و مطلوب کجاست؟ چه نشانه‌ای از این فاصله داریم؟ علت احتمالی چیست و خط مبنای مقایسه کدام است؟ تازه پس از روشن‌شدن این‌ها، می‌توانیم دربارهٔ راه‌حل صحبت کنیم؛ از اصلاح قاعده و فرایند یا آموزش، تا نرم‌افزار، خودکارسازی و هوش مصنوعی.
برای مثال، «کارکنان سؤال‌های تکراری می‌پرسند» یک نشانه است. ممکن است اطلاعات به‌سختی پیدا شود، متن مقررات فهم‌پذیر نباشد، کارکنان از وجود منابع خبر نداشته باشند یا برای تشخیص وضعیت خاص خود به کارشناس نیاز داشته باشند. هر علت، مسیر متفاوتی پیش پای سازمان می‌گذارد.
خط مبنا نیز باید به همین مسئله مربوط باشد. اکنون پاسخ‌گویی چقدر طول می‌کشد؟ چه مقدار از وقت کارشناسان صرف آن می‌شود؟ کدام سؤال‌ها تکرار می‌شوند و چه تعداد از آن‌ها بدون ارجاع قابل پاسخ‌اند؟ بدون این شناخت، حتی یک سامانهٔ خوش‌ظاهر هم ممکن است تغییری در گرفتاری اصلی ایجاد نکند.
اگر شناخت سازمان و مسئله را حذف کنیم، فناوری فقط پاسخ دقیق‌تری به سؤال اشتباه می‌دهد.
مدیر منابع انسانی گفت: «پس بنویسیم کاهش سؤال‌های تکراری.»
مدیرعامل پرسید: «اگر کارکنان دیگه سؤال نپرسن، ولی کارشون هم راه نیفته، موفق شدیم؟»
مدیر منابع انسانی مکث کرد. «نه. باید بتونن جواب قابل استفاده بگیرن، بدون اینکه برای هر سؤال منتظر کارشناس بمونن.»
مدیر فناوری کنار جمله نوشت: «پیدا کردن پاسخ قابل استفاده؛ زمان انتظار؛ میزان نیاز به ارجاع.»
تعداد سؤال‌ها هنوز مهم بود، اما دیگر تنها چیزی نبود که قرار بود اندازه بگیرند.
حکمرانی از تبدیل مسئله به پروژه آغاز می‌شود
تأیید مسئله و مالک، تأیید گزینه و بودجهٔ آزمایش، پذیرش شواهد و مجوز استقرار یا توقف، تصمیم‌های حکمرانی‌اند.
برای تبدیل مسئله به پروژه، چهار مرحله را دنبال می‌کنیم: صورت‌بندی مسئله، طراحی گزینه‌های راه‌حل، آزمایش و تولید شواهد، و تصمیم برای ادامه، اصلاح یا توقف.
در مرحلهٔ نخست باید روشن شود چه نشانه‌ای دیده‌ایم، کاربر کیست و قرار است از کدام تصمیم یا فعالیت پشتیبانی کنیم. تأیید مسئله و مالک آن، در همین نقطه معنا پیدا می‌کند. اگر قرار باشد یک نفر هم‌زمان چند کلاه داشته باشد یا چند نفر مسئولیتی را با هم انجام دهند، باز هم باید معلوم باشد چه کسی با چه اختیاری پاسخ‌گویی را بر عهده گرفته است.
در مرحلهٔ دوم، گزینه‌ها را طراحی و مقایسه می‌کنیم: تغییر فرایند، قاعده، هوش تجاری، خودکارسازی یا هوش مصنوعی. تأیید گزینه و بودجهٔ آزمایش، یعنی سازمان برای بررسی یک مسیر مشخص، منابع اختصاص می‌دهد.
مرحلهٔ سوم باید دربارهٔ امکان‌پذیری، ارزش و ریسک شواهد تولید کند. سپس، در مرحلهٔ چهارم، بر پایهٔ آن شواهد دربارهٔ ادامه، بازطراحی، توقف یا گسترش تصمیم می‌گیریم.
حکمرانی را نمی‌توان به امضای نهایی پیش از استقرار محدود کرد. هنگامی که سازمان یک نشانه را «مسئلهٔ مهم» می‌نامد، برای آن مالک تعیین می‌کند و بررسی یک راه‌حل را تأمین مالی می‌کند، بخشی از تصمیم‌های اصلی را گرفته است.
مدیر مالی پرسید: «پس بودجهٔ آزمایش رو برای چی تصویب کنیم؟ برای ساخت دستیار یا برای بررسی راه کم‌کردن انتظار کارکنان؟»
مدیر فناوری گفت: «اگر از اول فقط ساخت دستیار رو تصویب کنیم، بررسی گزینه‌های دیگه عملاً از دستور کار خارج می‌شه.»
مدیرعامل عنوان ردیف بودجه را تغییر داد: «بررسی و آزمایش راه بهبود پاسخ‌گویی به کارکنان.»
بعد پرسید: «چه کسی تأیید می‌کنه که مسئله رو درست فهمیدیم؟»
نگاه‌ها به مدیر منابع انسانی برگشت. جلسه، پیش از خرید فناوری، به یک تصمیم دربارهٔ مسئولیت رسیده بود.
همهٔ مسئله‌ها، یک جنس ندارند
روشن‌بودن هدف، ورودی‌ها و قواعد حل، بر انتخاب روش اثر می‌گذارد.
برای انتخاب شیوهٔ بررسی، باید میان روشن‌بودن صورت مسئله و وجود تعارض دربارهٔ خود مسئله تفاوت بگذاریم.
در مسئلهٔ خوش‌فرم، هدف، ورودی‌ها، قواعد و معیار تشخیص پاسخ نسبتاً روشن‌اند. بررسی احراز شرایط دریافت یک مزیت، وقتی قاعده و اطلاعات معتبر در اختیار داریم، می‌تواند به چنین وضعیتی نزدیک باشد.
در مسئلهٔ بدفرم، بخشی از هدف، اطلاعات، متغیرهای مؤثر یا معیار ارزیابی هنوز روشن نیست. بررسی و آزمایش می‌تواند به شناخت بهتر این ابهام‌ها کمک کند.
مسائل Wicked، که در این درس آن‌ها را «مسائل بدخیم و درهم‌تنیده» یا مطابق اسلایدها، به صورت طنز، «لاینحل» می‌نامیم، فقط اطلاعات ناقص ندارند. ذی‌نفعان ممکن است دربارهٔ تعریف مسئله، هدف مطلوب و قابل قبول بودن پیامدها اختلاف داشته باشند. خود مداخله نیز می‌تواند وضعیت و رفتار افراد را تغییر دهد. این سه عنوان، سه طبقهٔ کاملاً جدا و جامع نیستند؛ یک مسئلهٔ بدخیم می‌تواند زیرمسئله‌هایی با صورت روشن داشته باشد.
می‌توان برای اقدام، دامنه‌ای محدود و زیرمسئله‌هایی قابل بررسی تعریف کرد؛ اما حل آن زیرمسئله‌ها الزاماً تعارض اصلی را برطرف نمی‌کند. اگر کارکنان، دستیار را مقدمهٔ حذف شغل بدانند، کاهش زمان پاسخ‌گویی به‌تنهایی پاسخ این نگرانی نیست. انتخاب اینکه کدام پیامد را اندازه بگیریم و کدام موضوع را خارج از دامنه بگذاریم، خودش تصمیمی مدیریتی و قابل پرسش است.
بنابراین، هدف صورت‌بندی فقط ساده‌کردن مسئله نیست. باید روشن کنیم چه چیزی را برای اقدام محدود کرده‌ایم، چه وابستگی‌هایی باقی مانده‌اند، چه کسانی از این انتخاب متأثر می‌شوند و کدام اختلاف هنوز حل نشده است.
گاهی لازم است ابعاد مورد بررسی را تغییر دهیم؛ مثلاً از یک درخواست کلی مانند «رفع نارضایتی کارکنان» به زمان انتظار، اعتبار اطلاعات و مسیر رسیدگی برسیم. گاهی هم همان موضوع را در یک نمایش دیگر بهتر می‌فهمیم. تجزیهٔ فوریه مثال روشنی از این تغییر نگاه است.
یک موج تناوبی را تصور کنید که پر از برآمدگی و فرورفتگی است و شکل آن در نگاه اول عجیب و پیچیده به نظر می‌رسد. در تحلیل فوریه، آن را بر حسب مؤلفه‌های سینوسی با دامنه و بسامدهای متفاوت توصیف می‌کنیم؛ موج‌های ساده‌ای که با جمع‌شدن، شکل موج اصلی را می‌سازند. به‌جای دنبال‌کردن تک‌تک پیچ‌وخم‌ها، می‌پرسیم چه مؤلفه‌هایی با چه سهمی در آن حضور دارند. با نگه‌داشتن مؤلفه‌های اصلی نیز می‌توان تقریب ساده‌تری از موج ساخت. درس سری فوریه در MIT همین شیوهٔ نمایش را توضیح می‌دهد.
در این نمونه، موج بالایی دقیقاً جمع سه موج پایین است. تغییر شیوهٔ نمایش، مؤلفه‌های سادهٔ آن را آشکار می‌کند.
موج همان موج است، اما ساختارش در نمایش تازه آشکارتر می‌شود. درس مدیریتی این مثال، پیدا کردن زاویه‌ای است که بتوان از آن ساختار مسئله را دید و روی اجزای آن کار کرد. در پروندهٔ دستیار، وقتی «پاسخ‌گویی نامناسب» را به اعتبار منابع، پیدا کردن قاعدهٔ مرتبط و مسیر رسیدگی تقسیم می‌کنیم، برای هر بخش پرسش و مسئول مشخص‌تری پیدا می‌شود. با انتخاب یک حوزهٔ محدود و روشن‌کردن وابستگی این بخش‌ها، می‌توان آزمایشی تعریف کرد که از نتیجهٔ آن چیزی بیاموزیم.
این مثال، تمثیلی برای تغییر شیوهٔ نمایش مسئله است. در مسائل سازمانی، اجزا الزاماً مستقل یا جمع‌پذیر نیستند و رابطهٔ آن‌ها ممکن است با مداخله تغییر کند. تجزیهٔ مسئله می‌تواند محل اقدام را روشن کند، اما برای نتیجه‌گیری دربارهٔ کل سازمان باید وابستگی اجزا، بازخوردها و تعارض منافع را دوباره بررسی کرد.
مدیر عملیات گفت: «برای بعضی درخواست‌ها، مسیر رسیدگی دقیقاً معلومه. فقط کسی نمی‌دونه الان دست چه واحدیه.»
مدیر فناوری گفت: «اون قسمت رو می‌شه با ثبت وضعیت و گردش کار بررسی کرد.»
مدیر منابع انسانی پرسید: «ولی وقتی کارمند نمی‌دونه سؤالش زیر کدوم مقررات قرار می‌گیره چی؟»
مدیرعامل دو مورد را در دو سطر جدا نوشت. هر دو به کارکنان مربوط بودند، اما قرار نبود به‌خاطر این شباهت، یک راه‌حل مشترک به آن‌ها تحمیل شود.
هشت تله‌ای که پاسخ را در صورت سؤال پنهان می‌کنند
یک صورت‌مسئله می‌تواند پیش از بررسی شواهد، راه‌حل و محدودیت‌های آن را تعیین کرده باشد.
ممکن است ظاهراً دربارهٔ مسئله صحبت کنیم، اما جمله‌ای که نوشته‌ایم فقط خرید یا تصمیم از پیش انتخاب‌شده را توجیه کند. هشت تله را می‌توان در همان درخواست «دستیار سازمانی» دید:
تله
چگونه وارد صورت‌مسئله می‌شود؟
نمونه در پروندهٔ دستیار
Anchoring؛ قفل‌شدن روی پاسخ
سؤال طوری نوشته می‌شود که فقط یک پاسخ از پیش مطلوب داشته باشد.
«چگونه ثابت کنیم چت‌بات بهترین راه پاسخ‌گویی است؟»
Solutioneering؛ وابسته‌کردن مسئله به فناوری
انتخاب فناوری، پیش از بررسی مسئله انجام می‌شود.
«مسئلهٔ ما نداشتن یک سامانهٔ RAG است.»
Hamstringing؛ ساختن قیدهای مصنوعی
فرض‌هایی را بدون بررسی، محدودیت قطعی می‌گیریم.
«راه‌حل باید بدون هیچ تغییری در فرایند فعلی کار کند.»
Narrowing؛ محدودکردن میدان دید
فقط بخشی از وضعیت واقعی در تعریف مسئله جا می‌گیرد.
«فقط سؤال‌های ساده را بررسی کنیم و موارد ارجاع را از محاسبه کنار بگذاریم.»
Wishlisting؛ نوشتن فهرست آرزوها
مجموعهٔ قابلیت‌های دلخواه، جای مسئله را می‌گیرد.
«پاسخ بدهد، گزارش بسازد، درخواست ثبت کند و کارشناس هم باشد.»
Buzzwording؛ صورت‌بندی با نام‌های پرآوازه
نام محصول و سرویس، مبنای تعریف مسئله می‌شود.
«برای سازمان یک ChatGPT می‌خواهیم.»
Presuming؛ فرض‌گرفتن رفتار کاربر
بدون شواهد دربارهٔ رفتار و نیاز کاربر حکم می‌دهیم.
«اگر چت‌بات داشته باشیم، کارکنان دیگر تماس نمی‌گیرند.»
Catastrophizing؛ شروع از فاجعهٔ فرضی
بدترین حالت فرضی، بی‌بررسی به مسئلهٔ اصلی امروز تبدیل می‌شود.
«سامانه را برای روزی طراحی کنیم که هیچ کارشناسی در دسترس نیست و همهٔ کارکنان هم‌زمان پاسخ می‌خواهند.»
این جدول، گزیده و بازپردازی آموزشی چند خطای صورت‌بندی مسئله است؛ فهرستی جامع یا طبقه‌بندی استاندارد خطاهای شناختی نیست. بخشی از نام‌گذاری‌ها و توضیح‌ها با ارائهٔ «Stop Doing What You’re Told» از Stephen P. Anderson تطبیق دارد.
این تله‌ها به معنای بی‌اهمیت‌بودن محدودیت یا سناریوی خسارت نیستند. محدودیت واقعی باید ثبت شود و خطر جدی باید بررسی شود. مسئله از جایی آغاز می‌شود که فرض تأییدنشده، بدون بررسی مبنای طراحی و هزینه می‌شود.
برای بازبینی صورت‌مسئله، می‌توان پرسید: کدام بخش این جمله یک مشاهده است؟ کدام بخش برداشت ماست؟ کجا نام راه‌حل را جای مشکل گذاشته‌ایم؟ کدام رفتار کاربر را هنوز ندیده‌ایم، اما قطعی فرض کرده‌ایم؟
مدیر فناوری پیشنهاد اولیه را دوباره باز کرد. در صفحهٔ نخست نوشته بود: «با استقرار دستیار هوشمند، تماس کارکنان با کارشناسان حذف خواهد شد.»
گفت: «این جمله رو هنوز نمی‌تونیم قول بدیم.»
مدیر منابع انسانی گفت: «بعضی‌ها حتی بعد از خوندن جواب هم می‌خوان دربارهٔ شرایط خودشون با کارشناس صحبت کنن.»
مدیرعامل گفت: «پس حذف تماس رو از هدف قطعی برداریم. اول ببینیم کدوم تماس‌ها واقعاً قابل کاهش‌اند و کدوم‌ها باید باقی بمونن.»
یکی از وعده‌های پررنگ پیشنهاد حذف شد؛ در عوض، چیزی پیدا کرده بودند که می‌شد درباره‌اش تحقیق کرد.
کارایی و اثربخشی را جدا بسنجیم
پیچیدگی تحلیل و راهکار را با توجه به منابع مصرف‌شده و نتیجه‌ای که برای سازمان ایجاد می‌کند، بسنجیم.
برای تصمیم دربارهٔ عمق تحلیل، تعداد کنترل‌ها و پیچیدگی راهکار، باید منابع مصرف‌شده و میزان تحقق هدف را جداگانه بررسی کنیم.
کارایی (Efficiency) به نسبت نتیجه و منابع مصرف‌شده مربوط است: برای رسیدن به پاسخ، چه مقدار زمان، هزینه، توان پردازشی و کار انسانی صرف می‌کنیم؟ در پروندهٔ دستیار، هزینهٔ پاسخ فقط مصرف مدل نیست؛ وقتی کارشناس باید پاسخ را دوباره بررسی کند یا درخواست را میان واحدها بگرداند، آن زمان و کار هم بخشی از منابع مصرف‌شده‌اند.
اثربخشی (Effectiveness) به میزان تحقق هدف مربوط است: آیا کارمند پاسخ معتبر گرفته، تکلیفش روشن شده و کارش پیش رفته است؟ پاسخ چندثانیه‌ای به پرسشی که مشکل اصلی کاربر را حل نمی‌کند، نتیجهٔ مورد انتظار پروژه را فراهم نکرده است. باید کل مسیر رسیدن به نتیجه را ببینیم.
راه‌حل خوب، با منابع متناسب به نتیجهٔ مورد نیاز می‌رسد. برای افزودن هر مرحلهٔ تحلیل، کنترل یا فناوری، باید روشن باشد چه تغییری در حل مسئله ایجاد می‌کند.
برای نمونه، می‌توان مدل را سریع‌تر کرد، اما تا وقتی از اسناد متناقض پاسخ می‌گیرد، کاربر همچنان به جواب قابل اتکا نمی‌رسد. از سوی دیگر، اگر برای هر پرسش ساده چند مرحلهٔ تأیید بگذاریم، زمان و هزینهٔ رسیدگی بالا می‌رود. باید بدانیم هر کنترل کدام خطا را کاهش می‌دهد و این بهبود در برابر منابعی که مصرف می‌کند، چه ارزشی دارد.
نمودار علت‌یابی در میانهٔ اسلاید، ابزاری برای بررسی عمیق‌تر مسئله است؛ از نشانه و علت فنی تا سازوکارهای سازمانی. این بررسی به ما کمک می‌کند محل مداخله را درست انتخاب کنیم. اگر ناسازگاری منابع، علت پاسخ‌های متفاوت باشد، روشن‌کردن مرجع معتبر می‌تواند هم کیفیت نتیجه را بهتر کند و هم نیاز به بررسی و اصلاح مکرر پاسخ‌ها را کاهش دهد. چنین تغییری، کارایی و اثربخشی را با هم بهبود می‌دهد.
پس دامنهٔ تحلیل و راهکار را متناسب با مسئله انتخاب می‌کنیم. برای یک پرسش با قاعدهٔ روشن، همان قاعده و مسیر سادهٔ رسیدگی کافی است. برای مسئله‌ای با منابع متعارض یا پیامد حساس، بررسی عمیق‌تر و کنترل بیشتر ارزش پیدا می‌کند. معیار تصمیم این است که با این پیچیدگی و هزینه، چه مقدار به حل مسئله نزدیک‌تر می‌شویم.
مدیر منابع انسانی گفت: «می‌تونیم قبل از رسیدن جواب به کارمند، یک مرحلهٔ بازبینی دیگه بذاریم.»
مسئول ریسک و انطباق پرسید: «کدوم جواب‌ها به این بررسی نیاز دارن و قرار است چه خطایی رو پیدا کنه؟»
مدیر فناوری گفت: «اگر همهٔ جواب‌ها رو بفرستیم، دوباره یک صف انتظار درست می‌کنیم. بعضی سؤال‌ها فقط نشانی یک فرم رو می‌خوان.»
مدیرعامل گفت: «پس موارد نیازمند بررسی رو جدا کنیم. بعد هم ببینیم همکارمون چقدر منتظر می‌مونه و آخرش جواب قابل استفاده می‌گیره یا نه.»
کنار پیشنهاد بازبینی، دو موضوع ثبت شد: منابعی که مصرف می‌کند و نتیجه‌ای که باید بهتر کند.
اختلاف بر سر راه‌حل، گاهی از اختلاف در دیدن مسئله می‌آید
زاویهٔ نگاه، متغیرهای مهم و فضای راه‌حل را تغییر می‌دهد.
زاویهٔ نگاه، تعیین می‌کند مسئله را با چه متغیرها و رابطه‌هایی تعریف کنیم. وقتی این صورت‌بندی عوض شود، راه‌هایی به چشم می‌آیند که پیش‌تر در محدودهٔ سؤال ما نبودند. کاری که پیچیده به نظر می‌رسید، گاهی با همین تغییر نگاه، راه‌حل ساده‌ای پیدا می‌کند.
برای نمونه، می‌توان مسائل فیزیک را بر اساس ظاهرشان دید: جعبه، سطح شیبدار یا فنر. نگاه دیگر، رابطهٔ انرژی را در همان مسئله تشخیص می‌دهد. در بعضی مسائل، دنبال‌کردن نیروها و شتاب در طول مسیر، محاسبه‌ای طولانی می‌سازد؛ اما نگاه از منظر انرژی، رابطهٔ ابتدا و انتهای حرکت را روشن می‌کند و مسیر حل کوتاه‌تر می‌شود. وضعیت فیزیکی همان است؛ کمیت و رابطه‌ای که مبنای حل قرار می‌دهیم تغییر کرده‌اند.
یک مثال آموزشی دیگر، جعبه‌های خالی در خط بسته‌بندی بستنی است. کارخانه‌ای را تصور کنید که بعضی جعبه‌ها بدون محصول از خط خارج می‌شوند. اگر مسئله را «چگونه داخل همهٔ جعبه‌های بسته را ببینیم؟» تعریف کنیم، به سراغ حسگر، تصویربرداری و سامانهٔ تشخیص می‌رویم. حالا پرسش را عوض کنیم: «چگونه مانع رسیدن جعبهٔ خالی به انتهای خط شویم؟» با این نگاه، اختلاف وزن جعبهٔ پر و خالی هم به یک امکان تبدیل می‌شود.
در این مثال فرض کنیم جعبه‌های خالی آن‌قدر سبک‌اند که جریان هوا آن‌ها را از مسیر کنار می‌زند و جعبه‌های پر سر جای خود می‌مانند. در چنین شرایطی، پنکه‌ای در نقطهٔ مناسب خط، راهی ساده برای جداسازی است. هدف همچنان جلوگیری از خروج جعبهٔ خالی است، اما صورت‌بندی تازه اجازه می‌دهد از یک ویژگی فیزیکی ساده استفاده کنیم. به‌جای دیدن داخل جعبه، از تفاوت وزن آن استفاده کرده‌ایم.
پیش از پیچیده‌ترکردن ابزار، ببینیم صورت سؤال ما چه راه‌هایی را از ابتدا کنار گذاشته است. گاهی با تغییر پرسش، متغیری ساده پیدا می‌شود که همان هدف را با راه کوتاه‌تری محقق می‌کند.
در پروندهٔ دستیار هم اگر پرسش را «چگونه مدلی بسازیم که به همهٔ سؤال‌های کارکنان جواب بدهد؟» بگذاریم، میدان انتخاب را از ابتدا به قابلیت‌های مدل محدود کرده‌ایم. اگر بپرسیم «کارکنان برای پیش‌بردن کارشان چه چیزی را نمی‌دانند؟»، گزینه‌های دیگری هم پیدا می‌شوند: نمایش وضعیت درخواست، روشن‌کردن مرجع رسیدگی، دسترسی مستقیم به مقررات معتبر یا پاسخ‌گویی دربارهٔ معنای همان مقررات. هرکدام مسئله و روش مناسب خود را دارند.
مدیر عملیات گفت: «بخشی از تماس‌ها فقط برای اینه که همکارمون بدونه درخواستش الان دست کیه.»
مدیر فناوری گفت: «برای این مورد می‌تونیم وضعیت همون درخواست رو مستقیم از سامانه نشون بدیم.»
مدیر منابع انسانی پرسید: «پس سؤال دربارهٔ شرایط استفاده از مزایا چی؟ اون رو از کجا می‌فهمه؟»
مدیرعامل گفت: «اون رو جدا ببینیم. اول معلوم کنیم هر سؤال چه جوابی می‌خواد. برای پیگیری درخواست، وضعیتش رو نشون بدیم؛ برای فهم مقررات هم راه مناسب خودش رو پیدا کنیم.»
یکی از کارهایی که قرار بود به توان پاسخ‌گویی مدل سپرده شود، با تغییر سؤال به نمایش وضعیت موجود در سامانه تبدیل شد. صورت‌بندی تازه، راه ساده‌تری را وارد انتخاب‌های پروژه کرده بود.
کدام محدودیت واقعی است و کدام را به ارث برده‌ایم؟
کدام محدودیت در صورت‌مسئله وجود دارد و کدام را خودمان به آن اضافه کرده‌ایم؟
در روایت مشهور این تصویر، چند میمون در محیطی قرار دارند که در مرکز آن نردبانی به سمت چند موز گذاشته شده است. هر بار که یکی از میمون‌ها برای برداشتن موز از نردبان بالا می‌رود، سایر میمون‌ها با پاشش آب سرد مواجه می‌شوند. پس از تکرار این اتفاق، میمون‌ها یاد می‌گیرند مانع بالا رفتن یکدیگر شوند؛ حتی وقتی دیگر پاشش آب اتفاق نمی‌افتد.
در ادامه، میمون‌ها به‌تدریج با اعضای جدید جایگزین می‌شوند. میمون تازه‌وارد هم وقتی به سمت نردبان می‌رود، از سوی دیگران متوقف می‌شود؛ با اینکه خودش هرگز پاشش آب را تجربه نکرده است. سرانجام گروهی باقی می‌ماند که هیچ‌کدام دلیل اولیهٔ این رفتار را نمی‌دانند، اما همچنان مانع نزدیک‌شدن به نردبان می‌شوند.
در پروژه‌های سازمانی نیز جمله‌هایی مانند «این فرایند نباید تغییر کند»، «کاربران این کار را انجام نمی‌دهند» یا «فقط همین واحد می‌تواند پاسخ بدهد» ممکن است بارها تکرار شوند. بخشی از آن‌ها پشتوانهٔ معتبر دارند؛ بخشی هم ممکن است از تصمیم یا محدودیتی قدیمی باقی مانده باشند که دیگر کسی دلیلش را به یاد نمی‌آورد.
نمی‌توان همهٔ این محدودیت‌ها را کنار گذاشت. باید پرسید هر قید از کجا آمده است: الزام قانونی، تعهد قراردادی، ملاحظهٔ امنیتی، محدودیت منابع، تصمیم مدیریتی یا صرفاً عادتی که در طول زمان تثبیت شده است؟ آیا هنوز برقرار است؟ چه کسی اختیار بازبینی آن را دارد؟
گاهی اجرای پروژه واقعاً به رعایت یک قید وابسته است. گاهی هم بازبینی همان قید، راه‌حل ساده‌تری پیش پای سازمان می‌گذارد. هدف، حذف محدودیت‌ها نیست؛ تشخیص تفاوت میان قیدهای واقعی و فرض‌هایی است که بدون بررسی به ارث برده‌ایم.
اگر قید پروژه، دسترسی به داده است، گره کور داده برای هوش مصنوعی نسبت محرمانگی با امکان بهره‌برداری را باز می‌کند و بحث را به سمت استفادهٔ مجاز و پردازش امن می‌برد.
مدیر منابع انسانی گفت: «یک فرض دیگه هم داشتیم؛ اینکه هیچ‌کس برای پیدا کردن جواب، صفحهٔ مقررات رو باز نمی‌کنه.»
مدیرعامل پرسید: «بررسی کردیم یا چون سال‌ها این جمله رو شنیدیم، همون رو نوشتیم؟»
مدیر منابع انسانی گفت: «آمار دقیقی نداریم. باید ببینیم پیدا نمی‌کنن، نمی‌خونن یا بعد از خوندن هم تکلیفشون روشن نمی‌شه.»
مدیر فناوری گفت: «این سه حالت، سه کار متفاوت از ما می‌خوان.»
قیدی که تا آن لحظه قطعی به نظر می‌رسید، به یک پرسش قابل بررسی تبدیل شد.
کارت تحول سوم: مسئله فقط جست‌وجو نیست؛ اسناد متناقض‌اند
صورت‌مسئله از ساخت چت‌بات به حکمرانی دانش، نسخهٔ اسناد و مالکیت محتوا تغییر می‌کند.
در ادامهٔ همان پرونده، مسئله یک بار دیگر تغییر می‌کند. سؤال مشخص است: «سقف اختیار خرید تجهیزات IT چقدر است؟» اما سه پاسخ متفاوت پیش روی ماست: ۵۰۰ میلیون ریال، ۳۰۰ میلیون ریال و یک میلیارد ریال. پشت هر پاسخ هم سندی قرار گرفته است؛ سیاست خرید، آیین‌نامهٔ مالی و اصلاحیهٔ خرید.
وجود منبع، به‌تنهایی اعتبار پاسخ را اثبات نمی‌کند. باید معلوم باشد کدام سند برای این سؤال و این وضعیت معتبر است، اصلاحیه چه دامنه‌ای دارد، کدام نسخه جایگزین شده و مرجع رفع تعارض کیست. حتی تاریخ جدیدتر نیز بدون شناخت دامنه و اعتبار سند، برای داوری کافی نیست.
این وضعیت را نمی‌توان فقط به ضعف جست‌وجو نسبت داد. ممکن است سامانه هر سه متن را درست پیدا کند و همچنان معلوم نباشد سازمان کدام حکم را معتبر می‌داند. مدلی هم که از میان آن‌ها یک جواب روان انتخاب می‌کند، ابهام سازمان را رفع نکرده است.
در اینجا موضوع به حکمرانی دانش می‌رسد: مالک محتوا، اعتبار و نسخهٔ سند، قواعد استفاده و مسیر حل تعارض باید روشن شوند. فناوری می‌تواند در یافتن منابع، آشکارکردن اختلاف و ارجاع سؤال کمک کند؛ تعیین اعتبار سازمانی سند، به مسئولیت و اختیار نیاز دارد.
تمایز رساندن دانش درست به مدل و تغییر رفتار آن را در تفاوت روش‌های بازیابی دانش و آموزش دوبارهٔ مدل با مثال‌های ساده باز کرده‌ام. این تمایز کمک می‌کند پیش از پیشنهاد آموزش دوباره، محل مسئله را پیدا کنیم.
همان منطق کلاه‌ها اینجا نیز برقرار است. قرار نیست برای هر عنوان یک سمت تازه ایجاد کنیم. ممکن است یک نفر چند مسئولیت داشته باشد یا چند نفر در نگهداری یک حوزهٔ محتوا همکاری کنند. آنچه باید روشن بماند، مسئولیت به‌روزرسانی، اختیار تأیید و مسیر پاسخ‌گویی هنگام اختلاف است.
سه پاسخ، پیش از ورود مدل
مدیر مالی برای روشن‌شدن بحث، سقف اختیار خرید تجهیزات را مثال زد. یک نفر سیاست خرید را باز کرد؛ دیگری آیین‌نامهٔ مالی را. مدیر فناوری هم اصلاحیه‌ای را از پوشهٔ واحد خود بیرون آورد.
سه عدد روی میز بود.
مدیرعامل پرسید: «کدومش معتبره؟»
مدیر مالی گفت: «باید دامنهٔ اصلاحیه و مصوبهٔ مربوط رو بررسی کنیم.»
مدیر فناوری آهسته گفت: «اگر هر سه فایل رو به دستیار بدیم، فقط کاری کردیم که سریع‌تر به هر سه برسه. هنوز نگفتیم وقتی با هم نمی‌خونن، چه کنه.»
مسئول ریسک و انطباق پرسید: «و چه کسی مسئول روشن‌کردن این تعارضه؟»
مدیرعامل به صفحهٔ اول پیشنهاد نگاه کرد؛ همان‌جا که نوشته بودند «دسترسی سریع به دانش سازمان».
زیرش نوشت: «پاسخ بر پایهٔ منبع معتبر، با نسخه و مسئول مشخص؛ تعارض‌ها باید برای بررسی ارجاع شوند.»
حالا می‌شد دربارهٔ پروژه حرف دقیق‌تری زد. پیش از تصویب، باید معلوم می‌کردند کدام حوزهٔ محتوا را انتخاب می‌کنند، چه کسی اعتبار آن را تأیید می‌کند و از آزمایش چه نتیجه‌ای انتظار دارند.
پیش از تصویب پروژه، چه چیزی را مکتوب کنیم؟
مسیر این درس، درخواست مبهم «یک دستیار می‌خواهیم» را به پرسشی مشخص‌تر رساند: چگونه کاربر به پاسخ قابل استفاده‌ای برسد که منبع معتبرش معلوم باشد و موارد تعارض، مسیر رسیدگی داشته باشند؟
صورت‌مسئله هنوز باید با شواهد و بررسی صاحبان مسئولیت تکمیل شود. اما حالا می‌دانیم صرفاً با خرید مدل یا افزودن یک رابط گفت‌وگو، همهٔ اجزای آن حل نمی‌شوند. بخشی از کار به محتوا، بخشی به فرایند و بخشی به قابلیت فنی مربوط است.
در درس بعد، اسلایدهای ۳۶ تا ۳۹ را دنبال می‌کنیم: این شناخت چگونه در منشور پروژه ثبت می‌شود، پروژه با چه معیارهایی در سبد سرمایه‌گذاری قرار می‌گیرد و پایلوت باید چه شواهدی برای تصمیم ادامه یا توقف فراهم کند؟
این درس، قسمت دوم بخش دوم «حکمرانی مسئله و سبد سرمایه‌گذاری» و تشریح اسلایدهای ۲۷ تا ۳۵ دوره است. درس قبل؛ اسلایدهای کامل دوره
درس ششم؛ منشور پروژه، اولویت سرمایه‌گذاری و اثبات امکان، ارزش و قابلیت بهره‌برداری در پایلوت.
مطالعهٔ درس: پایلوت هوش مصنوعی چه چیزی را باید اثبات کند؟
بودجه برای اثبات چه چیزی؟
سه سند هنوز روی میز بود. مدیر مالی کنار هرکدام عدد متفاوتی برای سقف اختیار خرید نوشته بود. قرار شد اعتبار و دامنهٔ آن‌ها بررسی شود؛ اما پیشنهاد اجرای دستیار هم همچنان منتظر تصمیم بود.
مدیرعامل پرسید: «اگر این تعارض رو روشن کنیم، می‌تونیم پایلوت رو شروع کنیم؟»
مدیر فناوری گفت: «از نظر فنی می‌تونیم یک نسخهٔ محدود آماده کنیم.»
مدیر مالی پرسید: «و آخرش چه چیزی رو تحویل می‌گیریم؟»
«یک دستیار که به سؤال‌ها از روی اسناد جواب می‌ده.»
مدیر مالی به سه سند اشاره کرد: «این رو که از جلسهٔ اول می‌گفتیم. من می‌خوام بدونم بعد از هزینه‌کردن، چه چیزی می‌دونیم که الان نمی‌دونیم.»
مدیر منابع انسانی گفت: «مثلاً اینکه واقعاً از انتظار کارکنان کم می‌کنه یا فقط یک راه تازه برای پرسیدن سؤال اضافه می‌شه.»
مسئول ریسک و انطباق گفت: «و اینکه وقتی سند معتبر پیدا نمی‌کنه، سؤال رو برای بررسی ارجاع می‌ده یا باز هم جواب قطعی می‌سازه.»
مدیرعامل پیشنهاد فنی را کنار کشید و یک برگهٔ سفید وسط میز گذاشت.
گفت: «قبل از تصویب بودجه، بنویسیم این آزمایش قراره به کدوم سؤال‌های ما جواب بده.»
در درس پنجم دیدیم که درخواست «دستیار می‌خواهیم» چگونه با بررسی مسئله تغییر کرد. مشکل فقط دسترسی به اسناد نبود؛ اعتبار منابع، تعارض نسخه‌ها و مسئولیت محتوا نیز باید روشن می‌شد.
سه سند متعارض هنوز روی میز است، اما مدیر مالی پرسش بعدی را مطرح کرده: با هزینه‌کردن برای پایلوت، چه چیزی می‌فهمیم که اکنون نمی‌دانیم؟ ساختن یک نسخهٔ آزمایشی باید شواهدی دربارهٔ ارزش و امکان ادارهٔ خدمت فراهم کند تا سازمان بتواند دربارهٔ ادامهٔ سرمایه‌گذاری تصمیم بگیرد.
حالا باید این شناخت را به مبنای تصمیم تبدیل کنیم. این درس، اسلایدهای ۳۶ تا ۳۹ را به ترتیب دنبال می‌کند و بحث «حکمرانی مسئله و سبد سرمایه‌گذاری» را به پایان می‌رساند: چه چیزی در منشور پروژه ثبت شود، پروژه در کنار گزینه‌های دیگر چه اولویتی پیدا کند و پایلوت چه شواهدی برای تصمیم بعدی بسازد؟
منشور پروژه باید ابهام‌های تصمیم را روشن کند
منشور پروژه، ایدهٔ مبهم را به مسئله‌ای قابل حکمرانی تبدیل می‌کند.
منشور پروژه جایی است که توافق دربارهٔ مسئله و انتظار از پروژه مکتوب می‌شود. ارزش آن به این است که هنگام اختلاف یا تصمیم برای ادامه، بتوانیم به آن رجوع کنیم و بفهمیم چه چیزی را پذیرفته بودیم.
منشور شش موضوع را دربر می‌گیرد. هرکدام، بخشی از ابهامی را برطرف می‌کنند که در پروندهٔ دستیار دیده‌ایم:
موضوع
پرسش اصلی
مصداق در پروندهٔ دستیار
هدف
پروژه دقیقاً چه ارزشی ایجاد می‌کند؟
دسترسی سریع‌تر به پاسخ قابل اتکا دربارهٔ مقررات منتخب و کاهش دوباره‌کاری پاسخ‌گویی.
تصمیم مورد حمایت
خروجی به کدام تصمیم مدیریتی یا عملیاتی کمک می‌کند؟
تشخیص قاعدهٔ معتبر و مسیر رسیدگی به یک درخواست خرید؛ با حدود استفادهٔ روشن.
کاربر و ذی‌نفع
چه کسی از خروجی استفاده می‌کند و موفقیت را چگونه می‌بیند؟
کارکنان درخواست‌کننده، کارشناسان پاسخ‌گو و صاحبان محتوای مالی و خرید، با انتظارهای متفاوت.
خط مبنا
امروز مسئله چگونه حل می‌شود و وضعیت موجود چیست؟
مسیر فعلی دریافت پاسخ، زمان انتظار، میزان ارجاع و موارد پاسخ ناسازگار.
هزینهٔ خطا
پاسخ نادرست چه پیامدی دارد؟
اقدام بر پایهٔ سقف اختیار نامعتبر، تأخیر در خرید، دوباره‌کاری یا اتکای کاربر به قاعدهٔ نامربوط.
دامنه
چه چیزهایی داخل و خارج پروژه‌اند؟
در مرحلهٔ آزمایش، یک حوزهٔ مشخص از اسناد و سؤال‌ها؛ با تفکیک پاسخ‌گویی از تأیید یا اجرای درخواست.
این جدول، نمونهٔ تکمیل شش موضوع منشور برای پروندهٔ ماست. پاسخ‌های واقعی هر سازمان باید با مشارکت کسانی روشن شود که مسئول مسئله و استفاده از خروجی‌اند.
هدف و تصمیم مورد حمایت، دو پرسش متفاوت‌اند. «کم‌شدن زمان انتظار» ارزش مورد انتظار است. «کارمند بر اساس پاسخ چه کاری انجام می‌دهد؟» مسیر اثرگذاری خروجی را روشن می‌کند. ممکن است دو سامانه به کاهش زمان کمک کنند، اما یکی فقط محل سند را نشان دهد و دیگری مبنای تصمیم دربارهٔ یک خرید قرار بگیرد. انتظار از ارزیابی آن‌ها یکسان نخواهد بود.
خط مبنا نیز فقط یک عدد نیست. باید بدانیم امروز پاسخ چگونه تهیه می‌شود، چه کسی آن را بررسی می‌کند و در کدام مرحله انتظار یا خطا رخ می‌دهد. اگر بخشی از زمان به رفع تعارض اسناد اختصاص دارد، سریع‌ترشدن جست‌وجو الزاماً همان بخش از تأخیر را کم نمی‌کند.
دامنه، امکان ارزیابی را فراهم می‌کند. «پاسخ به همهٔ پرسش‌های سازمان» موضوعی بسیار گسترده است. وقتی حوزهٔ محتوا، گروه کاربران و نوع استفاده مشخص باشد، می‌توان سؤال‌های مرتبط انتخاب کرد و نتیجه را با وضعیت موجود سنجید.
مدیر مالی گفت: «برای این آزمایش، همهٔ دانش سازمان رو وارد نکنیم. اول همین مقررات خرید تجهیزات رو با منابع معتبر بررسی کنیم.»
مدیر منابع انسانی پرسید: «پس پاسخ‌گویی منابع انسانی چی؟»
مدیرعامل گفت: «اون مسئله سر جاشه. نتیجهٔ این آزمایش هم به‌تنهایی موفقیت اون حوزه رو ثابت نمی‌کنه.»
مسئول ریسک و انطباق اضافه کرد: «اینجا هم روشن بنویسیم که پاسخ‌گویی، اختیار تأیید خرید ایجاد نمی‌کنه.»
برگهٔ سفید، کم‌کم داشت مشخص می‌کرد چه چیزی قرار است آزمایش شود و از نتیجهٔ آن چه برداشتی می‌توان کرد.
پروژهٔ جذاب، لزوماً اولویت سرمایه‌گذاری نیست
ارزش و آمادگی روی محورها، ریسک با رنگ و زمان اثبات با اندازهٔ دایره‌ها نمایش داده شده‌اند.
پس از روشن‌شدن منشور، هنوز یک پرسش باقی است: چرا این پروژه باید در مقایسه با گزینه‌های دیگر، اکنون منابع بگیرد؟
برای سنجش اولویت سرمایه‌گذاری، چهار معیار را کنار هم می‌گذاریم. ارزش به اثر بر درآمد، هزینه، کیفیت یا تصمیم مربوط است. آمادگی، وضعیت داده، فرایند، مالک، دسترسی و پذیرش را دربر می‌گیرد. ریسک، پیامدهای حقوقی، عملیاتی، شهرتی و تغییر سازمانی را به بحث می‌آورد. زمان اثبات هم می‌پرسد چه مدت لازم است تا به نتیجه‌ای قابل اندازه‌گیری برسیم.
در نمودار، محور عمودی ارزش و محور افقی آمادگی است. رنگ دایره‌ها سطح ریسک را نشان می‌دهد و اندازهٔ آن‌ها زمان اثبات را. بنابراین دایرهٔ بزرگ‌تر، نشانهٔ بودجه یا ارزش بیشتر نیست؛ طبق راهنمای همین اسلاید، رسیدن به شواهد زمان بیشتری می‌خواهد.
پروژهٔ باارزش و آماده می‌تواند اولویت اقدام باشد. پروژهٔ باارزش اما کم‌آماده، ممکن است ابتدا به آماده‌سازی نیاز داشته باشد. در مقابل، پروژه‌ای که سریع و آسان اجرا می‌شود اما اثر کمی دارد، نباید فقط به دلیل سهولت اجرا، بخش اصلی منابع را جذب کند. برای پروژهٔ کم‌ارزش و کم‌آماده نیز باید توقف یا بازتعریف را جدی گرفت.
جایگاه نمونه‌هایی مانند تحلیل قرارداد، پیش‌بینی خرابی، دستیار دانش یا کشف تقلب در این تصویر، حکم همیشگی دربارهٔ این کاربردها نیست. سازمان باید با شواهد خودش جای هر پروژه را تعیین کند. برای سازمانی که اسناد معتبر و مسئول به‌روزرسانی آن‌ها روشن نیست، آمادگی دستیار دانش را نمی‌توان صرفاً از آماده‌بودن مدل و سرور نتیجه گرفت.
بودجه، وقت صاحبان فرایند و ظرفیت تیم فنی محدودند. تصمیم به اجرای یک پروژه، بخشی از همین ظرفیت را به آن اختصاص می‌دهد.
مدیر عملیات فهرست پروژه‌ها را دوباره باز کرد: «پیگیری وضعیت درخواست‌ها رو هم داریم. اون یکی شاید زودتر نتیجه بده.»
مدیر فناوری گفت: «ولی اثرش با پاسخ‌گویی به مقررات یکی نیست. باید هر دو رو با معیارهای روشن مقایسه کنیم.»
مدیر مالی به پروندهٔ دستیار اشاره کرد: «ارزش احتمالی داره. اما تا اعتبار اسناد و مسئول نگهداریشون روشن نشه، آماده نیستیم.»
مدیرعامل گفت: «پس آماده‌سازی منابع رو در تصمیم بیاریم. نصب مدل، تنها شرط شروع نیست.»
این بار، عقب‌افتادن شروع یک آزمایش به معنای کنارگذاشتن ایده نبود؛ معلوم شده بود پیش از آن چه کاری باید انجام شود.
پایلوت باید سه چیز را اثبات کند
پایلوت باید دربارهٔ امکان فنی، ارزش کسب‌وکار و قابلیت بهره‌برداری شواهد فراهم کند.
انتظار از پایلوت را می‌توان در سه پرسش روشن کرد. این تفکیک کمک می‌کند یک نتیجهٔ خوب در یک بُعد، جای خالی دو بُعد دیگر را نپوشاند.
آیا راه‌حل شدنی است؟
در اثبات امکان، باید معلوم شود داده و اسناد لازم در دسترس و قابل استفاده‌اند، کیفیت پاسخ و پایداری اولیه قابل قبول است و یک سناریوی واقعی، از ابتدا تا انتها کار می‌کند.
برای دستیار پروندهٔ ما، تنها دیدن یک پاسخ روان کافی نیست. باید بتوان سؤال واقعی را دریافت کرد، به منبع معتبر و مجاز رسید، پاسخ متناسب تولید کرد و در صورت ابهام یا تعارض، مسیر رسیدگی را طی کرد. اگر بخشی از این مسیر فقط با دخالت پنهان تیم سازنده کامل شود، همان وابستگی باید در نتیجه ثبت شود.
موفقیت فنی یک سناریوی منتخب، محدودهٔ مشخصی از امکان را نشان می‌دهد. از آن نمی‌توان توانایی پاسخ‌گویی به همهٔ سؤال‌ها و همهٔ حوزه‌های سازمان را نتیجه گرفت.
آیا ارزش معناداری ایجاد می‌کند؟
در اثبات ارزش، می‌پرسیم آیا تصمیم یا فرایند هدف واقعاً بهتر شده است. خط مبنا و معیار موفقیت باید از قبل روشن باشند و بهبودی مانند صرفه‌جویی، سرعت یا کیفیت بهتر، قابل مشاهده باشد.
ممکن است دستیار در چند ثانیه پاسخ بدهد، اما کارشناس مجبور باشد برای هر پاسخ، چند دقیقه اعتبار منبع را بررسی کند. در این حالت باید کل مسیر دریافت پاسخ قابل استفاده را سنجید. ممکن است زمان انتظار کاربر کم شود، اما کار دیگری به کارشناسان منتقل شود؛ این جابه‌جایی باید در ارزیابی دیده شود.
همچنین، اگر پیش از آزمایش اسناد پاک‌سازی و قواعد روشن شده‌اند، بخشی از بهبود ممکن است حاصل همین آماده‌سازی باشد. برای تصمیم سرمایه‌گذاری باید بفهمیم قابلیت فنی افزوده‌شده، در کنار آن اصلاحات، چه سهمی در نتیجه دارد.
زمان آزادشده، چه زمانی به ارزش تبدیل می‌شود؟
اعداد این مثال کاملاً فرضی‌اند. سازمان در سال ۲۴ هزار درخواست رسیدگی می‌کند. متوسط کار انسانی برای هر درخواست در روش فعلی ۱۲ دقیقه است. برای ساده‌کردن مقایسه، حجم درخواست‌ها و زمان‌های متوسط را در کل سال ثابت می‌گیریم.
گزینه
متوسط کار انسانی هر درخواست
کار انسانی سالانه
هزینهٔ راه‌اندازی
هزینهٔ ادارهٔ سالانه
روش فعلی
۱۲ دقیقه
۴۸۰۰ ساعت
—
—
اصلاح اسناد و فرایند
۸ دقیقه
۳۲۰۰ ساعت
۱۲۰ میلیون تومان
۶۰ میلیون تومان
اصلاح اسناد و فرایند همراه با دستیار
۵ دقیقه
۲۰۰۰ ساعت
۴۲۰ میلیون تومان
۱۸۰ میلیون تومان
هزینهٔ گزینهٔ دستیار، اصلاح اسناد و فرایند را نیز دربر می‌گیرد؛ این هزینه‌ها دوباره به آن اضافه نمی‌شوند. هزینهٔ ادارهٔ جدول نیز جدا از زمان کار انسانیِ رسیدگی است.
مقایسهٔ دستیار با وضع فعلی، ۲۸۰۰ ساعت کاهش کار انسانی نشان می‌دهد. اما برای تصمیم دربارهٔ افزودن دستیار، مقایسهٔ مهم‌تر با گزینهٔ اصلاح فرایند است: ۱۲۰۰ ساعت ظرفیت بیشتر، در برابر ۳۰۰ میلیون تومان هزینهٔ راه‌اندازی و ۱۲۰ میلیون تومان هزینهٔ ادارهٔ سالانهٔ بیشتر.
فرض کنیم فقط برای ۴۰ درصد این ۱۲۰۰ ساعت، فعالیت جایگزین مشخص و قابل پیگیری وجود دارد؛ یعنی ۴۸۰ ساعت در سال. اگر ارزش هر ساعت فعالیت جایگزین را با فرضی قابل دفاع ۳۰۰ هزار تومان بگیریم، ارزش برآوردی آن ۱۴۴ میلیون تومان می‌شود. این عدد، کاهش نقدی هزینهٔ حقوق نیست. برای تحقق آن باید کار جایگزین، مسئول تخصیص ظرفیت و نتیجهٔ مورد انتظار مشخص باشند.
اکنون فرض کنیم سقف بودجهٔ تصمیم‌های جدید سال اول ۷۰۰ میلیون تومان است. پروژهٔ دیگری برای پیش‌بینی خرابی تجهیزات، ۳۲۰ میلیون تومان بودجهٔ سال اول می‌خواهد و منفعت خالص نقدی مورد انتظار آن، پس از هزینه‌های جاری، ۱۸۰ میلیون تومان در سال برآورد شده است. این برآورد هم فرضی است و باید همراه با عدم قطعیت و ریسک آن بررسی شود.
اجرای کامل دستیار در سال اول ۶۰۰ میلیون تومان می‌خواهد و جمع آن با پروژهٔ تجهیزات از سقف بودجه عبور می‌کند. در مقابل، اصلاح فرایند با هزینهٔ سال اول ۱۸۰ میلیون تومان و پروژهٔ تجهیزات، جمعاً ۵۰۰ میلیون تومان می‌خواهند.
با اطلاعات فعلی این مثال، پیشنهاد ما اصلاح فرایند و پیش‌بردن پروژهٔ تجهیزات است. بررسی دستیار می‌تواند با پایلوتی جداگانه و سقف هزینهٔ ۸۰ میلیون تومان ادامه یابد؛ در این صورت جمع بودجهٔ پیشنهادی ۵۸۰ میلیون تومان خواهد بود. بودجهٔ پایلوت، مجوز خرید یا استقرار کامل دستیار نیست.
پایلوت باید مشخص کند دستیار، نسبت به همان فرایند و منابع اصلاح‌شده، چه بهبود افزوده‌ای ایجاد می‌کند؛ چه مقدار از ظرفیت آزادشده واقعاً مصرف مفید پیدا می‌کند؛ و هزینهٔ نگهداری محتوا و بازبینی چقدر است. تا پیش از این شواهد، نباید کل بهبود ناشی از پاک‌سازی اسناد و اصلاح فرایند را به مدل نسبت داد.
این تصمیم به معنای بی‌ارزش‌بودن دستیار نیست. نشان می‌دهد جذابیت یک پروژه، برای اولویت‌دادن به آن در سبد محدود سازمان کافی نیست.
آیا سازمان می‌تواند آن را اداره کند؟
در اثبات قابلیت بهره‌برداری، پرسش از ادارهٔ روزمرهٔ سامانه است. مالک فرایند، کاربر و پشتیبان باید مشخص باشند، ریسک و امنیت و مسئولیت‌پذیری در نظر گرفته شوند و مسیر استقرار، مقیاس‌پذیری و پشتیبانی روشن باشد.
وقتی سند اصلاح می‌شود، چه کسی تغییر را تأیید و وارد منابع دستیار می‌کند؟ وقتی پاسخ مورد اعتراض است، چه کسی رسیدگی می‌کند؟ اگر سامانه در دسترس نباشد، کاربر از چه مسیری پاسخ می‌گیرد؟ پس از پایان همکاری تیم آزمایش، چه کسی مسئول نگهداری است؟
ظرفیت پاسخ‌گویی هم باید در شرایط استفادهٔ واقعی سنجیده شود. مثال‌ها و ابزار محاسبهٔ ۱۰۰ کاربر هم‌زمان در یک دستیار هوشمند یعنی چه؟ نشان می‌دهند چگونه تعداد کاربران، طول درخواست و صف را به آزمون ظرفیت وصل کنیم.
این مسئولیت‌ها، همان کلاه‌هایی هستند که در درس‌های قبل شناختیم. یک نفر می‌تواند چند کلاه داشته باشد و چند نفر می‌توانند در انجام یک مسئولیت همکاری کنند. معیار، روشن‌بودن مسئولیت و اختیار و امکان پاسخ‌گویی است. تعدد عنوان‌ها به‌تنهایی قابلیت بهره‌برداری ایجاد نمی‌کند.
مدیر فناوری گفت: «برای نمونه، چند سؤال مشخص آماده می‌کنیم و جواب‌ها رو نشون می‌دیم.»
بعد گفت: «گزارش پایلوت باید برای هر سه سطر جواب و شاهد داشته باشه.»
معیار موفقیت، دامنهٔ مشخص، دادهٔ واقعی و تصمیم بعدی، چهار شرطی هستند که پایلوت را به تصمیم سازمان وصل می‌کنند.
پیش از شروع باید معلوم باشد چه نتیجه‌ای ادامه را توجیه می‌کند، چه یافته‌ای نیازمند اصلاح است و چه مانعی، توقف یا تعلیق را ضروری می‌کند. لازم نیست همهٔ ابهام‌ها از پیش حل شده باشند؛ پایلوت برای روشن‌کردن بخشی از آن‌ها اجرا می‌شود. اما باید بدانیم کدام ابهام‌ها را می‌آزماییم و چه کسی یافته‌ها را برای تصمیم بعدی بررسی می‌کند.
پروندهٔ دستیار، حالا صورت روشن‌تری دارد
از درخواست یک چت‌بات به مسئله‌ای سازمانی رسیده‌ایم؛ گام بعد، ارزیابی اثر، ریسک و اختیار است.
در آغاز، درخواست سازمان یک عنوان داشت: «دستیار هوشمند». حالا اجزای پرونده روشن‌تر شده‌اند. بخشی از مشکل به جست‌وجو مربوط است، بخشی به تعارض اسناد و بخشی به مسئولیت دانش و پاسخ. پایلوت هم باید چیزی فراتر از امکان اجرای مدل را اثبات کند.
منشور پروژه، مبنای توافق را ثبت می‌کند. بررسی سبد، نشان می‌دهد این پروژه در مقایسه با سایر گزینه‌ها چه اولویتی دارد و برای آماده‌شدن به چه کاری نیازمند است. پایلوت، دربارهٔ امکان، ارزش و بهره‌برداری شواهد می‌سازد. هرکدام از این‌ها، بخشی از تصمیم را روشن می‌کنند.
با این حال، یک پرسش مهم هنوز باقی است: خروجی دستیار در زندگی سازمان چه اثری می‌گذارد و تا کجا می‌تواند مبنای تصمیم یا اقدام قرار بگیرد؟ پاسخ به همین پرسش، ما را به بخش بعد دوره می‌رساند.
یک پرسش، پیش از امضای نهایی
مدیر مالی برگهٔ منشور را خواند و گفت: «حالا معلومه بودجهٔ آزمایش رو برای چی می‌خوایم.»
مدیر فناوری گفت: «و معلومه گزارش پایانش فقط چند تصویر از پاسخ‌های خوب نیست.»
مدیر منابع انسانی پرسید: «اگر همین مسیر برای حوزهٔ ما هم جواب بده، می‌تونیم توسعه‌اش بدیم؟»
مدیرعامل گفت: «با ارزیابی همون حوزه. قرار نیست نتیجهٔ این آزمایش، مجوز همهٔ استفاده‌ها بشه.»
مسئول ریسک و انطباق به سطر «تصمیم مورد حمایت» اشاره کرد: «پیش از تأیید محدودهٔ استفاده، این رو هم روشن کنیم. وقتی کارمند جواب سقف اختیار خرید رو می‌گیره، فقط داره مقررات رو می‌خونه یا واحد بعدی اون جواب رو مبنای اقدام قرار می‌ده؟»
مدیر عملیات گفت: «اگر پاسخ وارد گردش کار بشه، ممکنه همون لحظه مبنای اقدام قرار بگیره.»
مدیرعامل خودکار را روی میز گذاشت.
«پس فقط کیفیت جواب مطرح نیست. باید ببینیم جواب کجا اثر می‌ذاره و چه اختیاری بهش می‌دیم.»
در درس بعد، از اسلاید ۴۰ وارد بخش سوم می‌شویم: ارزیابی اثر، سطح ریسک و اختیار. مسئله اکنون آن‌قدر روشن شده است که بتوانیم دربارهٔ پیامد استفاده از خروجی و حدود دخالت سامانه، دقیق‌تر تصمیم بگیریم.
درس هفتم؛ پیامد استفاده، هزینهٔ خطا و سنجش شدت، گستره، برگشت‌پذیری و امکان اعتراض.
مطالعهٔ درس: خطای هوش مصنوعی برای چه کسی گران تمام می‌شود؟
پاسخی که هیچ دکمه‌ای را فشار نمی‌داد
مدیرعامل هنوز خودکار را برنداشته بود. پرسش آخر جلسه روی برگهٔ منشور مانده بود: «پاسخ دستیار، کجا مبنای اقدام قرار می‌گیرد؟»
مدیر فناوری گفت: «در این نسخه به سامانهٔ خرید وصل نیست. هیچ درخواستی رو ثبت یا تأیید نمی‌کنه. فقط جواب می‌ده.»
مدیر عملیات یکی از پاسخ‌های نمونه را روی نمایشگر آورد: «با توجه به مبلغ خرید، ثبت این درخواست در اختیار واحد شما نیست.»
پرسید: «اگر کارمند این رو بخونه و درخواستش رو اصلاً ثبت نکنه چی؟»
مدیر فناوری گفت: «باید منبع رو هم ببینه.»
مدیر مالی گفت: «اگر منبع، نسخهٔ قبلی مقررات باشه، ممکنه همون رو معتبر بدونه و کار متوقف بشه.»
مدیر منابع انسانی پرسید: «و ما از کجا می‌فهمیم چند نفر به خاطر جواب اشتباه، از پیگیری کارشون منصرف شدن؟»
هیچ دکمه‌ای برای رد درخواست وجود نداشت. هیچ فرمانی هم از سامانه صادر نشده بود. با این حال، همه می‌توانستند نتیجه را تصور کنند: پاسخی روی صفحه، و کاری که دیگر انجام نمی‌شود.
مدیرعامل گفت: «پس از اینکه فقط جواب می‌ده، نمی‌تونیم نتیجه بگیریم اثرش محدوده. ببینیم همین جواب با تصمیم آدم‌ها چه می‌کنه.»
در درس ششم دیدیم پایلوت باید دربارهٔ امکان فنی، ارزش و قابلیت بهره‌برداری شواهد فراهم کند. منشور پروژه نیز باید تصمیم مورد حمایت، هزینهٔ خطا و دامنهٔ استفاده را روشن کند.
پاسخ روی نمایشگر، هزینهٔ خطا را ملموس‌تر می‌کند: دستیار هیچ درخواستی را رد نکرده، اما ممکن است کارمند را از ثبت آن منصرف کند. پاسخ و توصیه نیز وارد زنجیرهٔ تصمیم می‌شوند، حتی وقتی اتصال اجرایی وجود ندارد. برای ارزیابی پایلوت، باید ببینیم همین خروجی چه رفتاری ایجاد می‌کند و پیامد آن برای چه کسی است.
این درس، آغاز بخش سوم دوره و مبتنی بر اسلایدهای ۴۰ تا ۴۴ است: تفاوت کاربردها، منابع ریسک، ارزش متفاوت خطاها و چهار پرسش برای ارزیابی اثر. در درس بعد، اسلایدهای ۴۵ تا ۴۸ را دنبال می‌کنیم و این ارزیابی را به حدود اختیار و کنترل‌های دستیار وصل خواهیم کرد.
یک مدل مشترک، کاربردهای هم‌ریسک نمی‌سازد
ارزیابی کاربرد، به پیامد، اختیار و امکان کنترل نیاز دارد.
چهار نوع استفاده را می‌توان در یک طیف دید: پاسخ عمومی، تحلیل، توصیه و تصمیم اجرایی. در هر قدم باید پرسید خروجی در چه کاری استفاده می‌شود و چگونه بر نتیجه اثر می‌گذارد.
ممکن است سامانه‌ای فقط ساعت کار یک واحد را اعلام کند. سامانه‌ای دیگر همان داده‌های سازمان را تحلیل کند و الگوی تأخیر را نشان دهد. کاربرد بعدی می‌تواند پیشنهاد تغییر فرایند باشد؛ و در نهایت، سامانه‌ای ممکن است خود دربارهٔ یک درخواست تصمیم بگیرد و آن را اجرا کند.
این تفاوت‌ها با نام مدل روشن نمی‌شوند. حتی اگر همه از یک مدل استفاده کنند، نوع ارزیابی، شواهد لازم و نظارت مورد نیازشان می‌تواند متفاوت باشد.
این طیف، راهنمای توجه به اثر و اختیار است. جای‌دادن یک کاربرد زیر عنوان «پاسخ عمومی» به‌تنهایی برای کم‌ریسک‌دانستن آن کافی نیست. باید موضوع پاسخ، مخاطب و نحوهٔ اتکای او به خروجی را هم بشناسیم. یک متن اطلاع‌رسانی دربارهٔ ساعت کار، با پاسخی دربارهٔ شرایط دریافت یک مزیت یا حدود اختیار مالی، پیامد یکسانی ندارد.
از طرف دیگر، وجود تحلیل یا توصیه نیز به‌خودی‌خود به معنای خطر زیاد در همهٔ موقعیت‌ها نیست. باید مسیر استفاده را دنبال کنیم: چه کسی خروجی را می‌بیند؟ چه تصمیمی بر پایهٔ آن گرفته می‌شود؟ کدام کنترل پیش از اثرگذاری وجود دارد؟
مدیر فناوری کنار مشخصات نسخه نوشت: «بدون اتصال اجرایی».
مدیرعامل گفت: «این رو نگه داریم، مهمه. ولی یک سطر دیگه هم لازم داریم: کاربران با جوابش چه می‌کنن؟»
مدیر عملیات گفت: «بعضی‌ها فقط سند رو پیدا می‌کنن. بعضی‌ها هم از جواب، مجازبودن یا نبودن کارشون رو می‌فهمن.»
مدیر مالی گفت: «پس این دو نوع استفاده رو در ارزیابی از هم جدا کنیم.»
محدودبودن اختیار فنی، یکی از ویژگی‌های سامانه بود. جلسه حالا داشت اثر واقعی استفاده از آن را هم ثبت می‌کرد.
ریسک را در فرد، سازمان و جامعه ببینیم
خطای مدل، تنها یکی از منابع ریسک است.
اگر بررسی ریسک را به احتمال پاسخ غلط محدود کنیم، بخشی از مسئله را نمی‌بینیم. پیامد استفاده را باید در سه سطح فرد، سازمان و جامعه بررسی کنیم.
در سطح فرد، حریم خصوصی و محرمانگی، تبعیض و بی‌عدالتی، امکان اعتراض و توضیح، و ایمنی و حقوق فرد مطرح‌اند. برای مثال، دستیار ممکن است پاسخ درستی را به فردی نشان دهد که مجاز به دیدن اطلاعات آن نیست. در این وضعیت، درست‌بودن پاسخ مشکل را برطرف نمی‌کند؛ مسئله در دسترسی و محرمانگی است.
در سطح سازمان، اختلال در عملیات، ریسک حقوقی و انطباق، امنیت و نشت داده، و شهرت، هزینه و پاسخ‌گویی اهمیت دارند. پاسخ دستیار ممکن است باعث دوباره‌کاری شود، رسیدگی را متوقف کند یا اطلاعاتی را در مسیر نامناسب قرار دهد. برای شناخت این پیامدها باید فرایند و مسئولیت‌ها را هم بررسی کنیم.
در سطح جامعه، اعتماد عمومی، اثر بر گروه‌های گسترده، پیامدهای اقتصادی و اجتماعی، و زیرساخت و منافع عمومی مطرح می‌شوند. دامنهٔ ارزیابی باید با کاربرد تناسب داشته باشد. یک دستیار محدود داخلی، با سامانه‌ای که دربارهٔ دسترسی جمعیت بزرگی به خدمات اثر می‌گذارد، بررسی یکسانی نمی‌خواهد.
برای دنبال‌کردن این پرسش که چه کسی داده را تولید می‌کند، چه کسی از آن تصمیم می‌سازد و چه کسی پیامد را تحمل می‌کند، تحلیل بازیگران زیست‌بوم داده‌ها نقش‌ها و منافع را در مقیاس گسترده‌تری کنار هم می‌گذارد.
این سه سطح جای یکدیگر را نمی‌گیرند. ممکن است رخدادی برای سازمان هزینهٔ مالی اندکی داشته باشد، اما برای فردی که اطلاعاتش افشا شده یا فرصت مهمی را از دست داده، پیامد سنگینی ایجاد کند. همچنین، رخداد کوچک اما تکرارشونده می‌تواند در مقیاس گسترده به مسئله‌ای متفاوت تبدیل شود.
داده، فرایند، اختیار، کاربر و زمینهٔ استفاده هم از منابع ریسک‌اند. افزایش کیفیت مدل، همهٔ این منابع ریسک را برطرف نمی‌کند.
مدیر فناوری گفت: «پاسخ نمونه از متن سند گرفته شده. از این نظر، چیزی رو از خودش نساخته.»
مسئول ریسک و انطباق پرسید: «ولی اون سند برای این کاربر و این درخواست معتبر بوده؟ کاربر مجاز بوده همهٔ اطلاعاتش رو ببینه؟»
مدیر مالی گفت: «و اگر جواب باعث توقف کار بشه، چه کسی باید موضوع رو بررسی کنه؟»
مدیرعامل کنار عبارت «کیفیت پاسخ» نوشت: «اعتبار منبع، دسترسی، استفاده و رسیدگی به پیامد».
گزارش فنی هنوز لازم بود؛ حالا پرسش‌هایی هم داشتند که پاسخشان در گزارش عملکرد مدل پیدا نمی‌شد.
کدام خطا پرهزینه‌تر است؟
انتخاب معیار ارزیابی باید با خطای پرهزینهٔ کاربرد مرتبط باشد.
دو سامانه ممکن است درصد موفقیت مشابهی گزارش کنند، اما در خطاهایی که مرتکب می‌شوند و پیامد آن خطاها تفاوت زیادی داشته باشند. برای انتخاب معیار، باید ابتدا بدانیم کدام اشتباه برای این کاربرد اهمیت بیشتری دارد.
دو مثال را کنار هم بگذاریم: فرد بی‌گناه نباید متهم شود؛ خطر واقعی نباید از تشخیص جا بماند. در مثال نخست، هشدار بی‌مبنا می‌تواند به فرد آسیب بزند. در مثال دوم، کشف‌نکردن یک وضعیت خطرناک می‌تواند پیامد جدی داشته باشد.
برای فهم تفاوت Precision و Recall، یک مسئلهٔ طبقه‌بندی را در نظر بگیریم که خروجی آن «نیازمند بررسی» است:
Precision می‌پرسد از مواردی که سامانه علامت زده، چه سهمی واقعاً به آن دسته تعلق داشته‌اند؟
Recall می‌پرسد از همهٔ موارد واقعی آن دسته، چه سهمی را پیدا کرده‌ایم؟
در یک مثال فرضی، اگر سامانه ۲۰ مورد را علامت بزند و ۱۸ مورد واقعاً نیازمند بررسی باشند، Precision برابر ۹۰ درصد است. اگر در کل ۳۰ مورد واقعی وجود داشته باشد، همان سامانه فقط ۱۸ مورد از ۳۰ مورد را یافته و Recall آن ۶۰ درصد است. دوازده مورد جا مانده‌اند. تعریف این دو معیار، با تعریف رسمی آن‌ها در راهنمای ارزیابی طبقه‌بندی گوگل سازگار است.
این مثال نشان می‌دهد یک عدد خوب می‌تواند در کنار یک ضعف مهم قرار بگیرد. البته «نیازمند بررسی» به معنای اثبات تخلف نیست و نباید بی‌بررسی به حکم علیه فرد تبدیل شود.
در کاربرد صنعتی نیز باید هزینهٔ ندیدن خطر را در کنار هزینهٔ هشدار بی‌مورد دید. هشدارهای بی‌مورد می‌توانند ظرفیت رسیدگی را مصرف کنند؛ از قلم‌افتادن خطر هم می‌تواند پیامد دیگری داشته باشد. انتخاب معیار و آستانهٔ قابل قبول، به همین زمینه وابسته است.
در دقت ۹۵ درصد برای کارخانه چه معنایی دارد؟ همین تفاوت را با یک مثال عددی دنبال کرده‌ام: عیبِ ازدست‌رفته و هشدار کاذب را به هزینه و ظرفیت رسیدگی تبدیل می‌کنیم تا معنای عملی معیارها روشن شود.
برای دستیار متنی نیز باید خطاها را به زبان مسئله تعریف کنیم. پاسخ اشتباهی که کاربر را به اقدام غیرمجاز سوق می‌دهد، با پاسخی که بی‌دلیل او را از اقدام مجاز بازمی‌دارد، یک پیامد ندارد. این دو معیار را هم نمی‌توان بدون تعریف روشن دسته‌ها و ارزیابی، به‌عنوان نمرهٔ کلی کیفیت تمام پاسخ‌های گفت‌وگویی به کار برد.
مدیر مالی گفت: «تا الان بیشتر نگران بودیم دستیار بگه اجازهٔ خرید دارید، در حالی که ندارید.»
مدیر عملیات به پاسخ روی نمایشگر اشاره کرد: «ولی این یکی برعکسه. ممکنه اجازه داشته باشی و جواب بگه نداری.»
مدیر منابع انسانی گفت: «اولی شاید با ثبت درخواست و کنترل بعدی پیدا بشه. دومی ممکنه اصلاً به درخواست تبدیل نشه که ببینیمش.»
مدیرعامل گفت: «پس در آزمایش، هر دو رو جدا بررسی کنیم. یک درصد کلی نمی‌گه کدوم اتفاق افتاده.»
چهار پرسش برای سنجیدن اثر
شدت و گسترهٔ بیشتر، همراه با امکان کمترِ اصلاح و اعتراض، کنترل و نظارت بیشتری می‌خواهد.
ارزیابی اثر را با چهار پرسش دنبال می‌کنیم. پاسخ آن‌ها باید به کاربرد مشخص و پیامد واقعی مربوط باشد.
محور
پرسش اصلی
مصداق در پروندهٔ دستیار
شدت
اگر سامانه اشتباه کند، زیان چقدر است؟
پاسخ، چند دقیقه تأخیر ایجاد می‌کند یا باعث از دست‌رفتن یک فرصت، افشای اطلاعات یا اختلال مهم می‌شود؟
گستره
اثر بر چند نفر، واحد یا فرایند وارد می‌شود؟
پاسخ برای یک مورد استفاده شده یا میان چند واحد بازنشر و مبنای عمل قرار گرفته است؟
برگشت‌پذیری
اگر خطا رخ دهد، آیا می‌توان آن را اصلاح یا جبران کرد؟
آیا اصلاح پاسخ هنوز به‌موقع است؟ می‌توان تصمیم را برگرداند یا مهلت و فرصت از دست رفته است؟
امکان اعتراض
فرد یا واحد متأثر چگونه می‌تواند اعتراض کند؟
آیا مسیر رسیدگی، مسئول بازبینی و امکان بررسی انسانی روشن است؟
شدت را باید از نگاه متأثران هم دید. کم‌بودن هزینه برای سازمان، لزوماً به معنای کم‌بودن خسارت برای فرد نیست. یک رخداد با دامنهٔ محدود نیز می‌تواند به‌دلیل پیامد سنگین، به کنترل جدی نیاز داشته باشد.
گستره فقط شمار کاربران ثبت‌شده نیست. یک پاسخ ممکن است کپی شود، در گروه کاری بگردد یا به رویه‌ای غیررسمی تبدیل شود. در این صورت، اثر آن از همان گفت‌وگوی اولیه فراتر می‌رود.
برگشت‌پذیری نیز با امکان ویرایش متن یکی نیست. می‌توان پاسخ روی صفحه را اصلاح کرد، اما اگر کاربر پیش‌تر بر اساس آن عمل کرده باشد، باید امکان جبران پیامد را بررسی کرد. تغییر پاسخ، اطلاعات افشاشده را محرمانه نمی‌کند و همیشه فرصت ازدست‌رفته را برنمی‌گرداند.
امکان اعتراض با وجود یک دکمهٔ ثبت نظر کامل نمی‌شود. باید روشن باشد درخواست بازبینی به چه کسی می‌رسد، چگونه رسیدگی می‌شود و آیا پیش از تثبیت پیامد، امکان اصلاح وجود دارد. کسی که متأثر شده، نباید برای پیدا کردن مسئول رسیدگی میان واحدها سرگردان بماند.
این مسئولیت‌ها نیز کلاه‌اند. ممکن است مسئول محتوای یک حوزه، بازبین پاسخ هم باشد یا چند نفر رسیدگی را با هم انجام دهند. آنچه اهمیت دارد، روشن‌بودن اختیار و مسئولیت و قابل پیگیری‌بودن رسیدگی است.
برای این درس لازم نیست چهار محور را بی‌دلیل به یک امتیاز نهایی تبدیل کنیم. ثبت روشن پاسخ‌ها و شواهد، می‌تواند نشان دهد کجا به بررسی و کنترل بیشتری نیاز داریم. یک پیامد شدید را نباید فقط با کم‌بودن تعداد افراد متأثر، کم‌اهمیت نشان داد.
اصلاح جواب، پس از پایان مهلت
مدیرعامل پرسید: «اگر جوابِ منع ثبت درخواست اشتباه باشه و فردا اصلاحش کنیم، مسئله حل می‌شه؟»
مدیر عملیات گفت: «اگر هنوز فرصت ثبت باشه، شاید. اگر مهلت گذشته باشه، فقط متن رو درست کردیم.»
مسئول ریسک و انطباق پرسید: «کاربر از کجا می‌فهمه می‌تونه درخواست بازبینی بده؟»
مدیر فناوری گفت: «می‌تونیم کنار پاسخ، مسیر ارجاع رو نمایش بدیم.»
مدیر مالی گفت: «باید معلوم هم باشه چه کسی به اون ارجاع رسیدگی می‌کنه. وگرنه فقط یک صف تازه درست کردیم.»
مدیرعامل چهار واژه را پایین برگه نوشت: «شدت، گستره، برگشت‌پذیری، اعتراض».
بعد به پاسخ نمونه نگاه کرد: «این هنوز فقط متنه. اما اگر همین متن وارد گردش کار بشه و درخواست رو نگه داره، دیگه باید دربارهٔ اختیار سامانه هم تصمیم بگیریم.»
اکنون پرسش پایان درس قبل، دقیق‌تر شده است. می‌دانیم باید پیامد خروجی را دنبال کنیم و ببینیم خطا برای چه کسی، در چه مقیاسی و با چه امکان جبرانی هزینه ایجاد می‌کند.
در درس بعد، اسلایدهای ۴۵ تا ۴۸ را ادامه می‌دهیم: از پاسخ عمومی تا تصمیم اجرایی، طبقات ریسک، افزایش اختیار و ماتریس ریسک دستیار سازمانی. این بار باید روشن کنیم هر نوع استفاده، به چه سطحی از شواهد و نظارت نیاز دارد.
درس هشتم؛ حدود اختیار دستیار، شواهد متناسب با ریسک، تأیید انسانی و امکان توقف.
مطالعهٔ درس: دستیار هوش مصنوعی تا کجا حق اقدام دارد؟
یک پیشنهاد برای کوتاه‌کردن مسیر
مدیر عملیات به پاسخ نمونه روی نمایشگر اشاره کرد؛ همان پاسخی که به کارمند می‌گفت ثبت درخواست خرید در اختیار واحد او نیست.
گفت: «اگر قراره آخرش همین رو بفهمیم، چرا از اول مسیر رو کوتاه نکنیم؟ دستیار مبلغ رو ببینه، مقررات رو بررسی کنه و اگر مجاز نبود، درخواست رو برگردونه.»
مدیر فناوری پرسید: «یعنی فقط توضیح بده که نیاز به بررسی داره یا واقعاً جلوی ادامهٔ درخواست رو بگیره؟»
«اگر معلومه مجاز نیست، دیگه چرا چند نفر بررسی کنن؟»
مدیر مالی دستش را روی سه سند گذاشت. «تا چند دقیقه پیش داشتیم اعتبار همین‌ها رو روشن می‌کردیم. حالا می‌خوایم جواب دستیار، اختیار رد درخواست هم داشته باشه؟»
مدیر عملیات گفت: «من دارم پیشنهاد می‌دم. اگر قابل اتکا باشه، می‌تونه کار رو سریع‌تر کنه.»
مسئول ریسک و انطباق پرسید: «چه کسی قابل اتکابودنش رو برای این کار تأیید می‌کنه؟ اگر اشتباه کرد، چه کسی می‌تونه تصمیمش رو برگردونه؟»
مدیرعامل عنوان تازه‌ای زیر برگهٔ منشور نوشت: «پیشنهاد افزایش اختیار».
گفت: «این دیگه فقط بهترکردن جواب نیست. داریم دربارهٔ واگذاری بخشی از تصمیم حرف می‌زنیم. اول معلوم کنیم چه چیزی رو، با چه شواهدی و تحت نظر چه کسی واگذار می‌کنیم.»
در درس هفتم دیدیم که ریسک را باید با توجه به پیامد، شدت، گستره، برگشت‌پذیری و امکان اعتراض سنجید. حتی پاسخ متنیِ دستیار می‌تواند بر تصمیم کاربر اثر بگذارد.
پیشنهاد مدیر عملیات، گفت‌وگو را از اثر پاسخ به واگذاری اختیار برده است: آیا دستیار می‌تواند خودش درخواست را برگرداند؟ این تغییر در شرح قابلیت، مسئولیت تازه‌ای برای سازمان ایجاد می‌کند. «پاسخ بدهد»، «پیشنهاد بدهد» و «درخواست را رد کند» به شواهد و نظارت یکسانی نیاز ندارند. حالا باید ارزیابی اثر را به حدود روشن اختیار وصل کنیم.
این درس، اسلایدهای ۴۵ تا ۴۸ را به ترتیب دنبال می‌کند و بخش سوم دوره را به پایان می‌رساند: از پاسخ عمومی تا تصمیم اجرایی، طبقات ریسک، شواهد متناسب با اختیار و ماتریس ریسک دستیار سازمانی.
از پاسخ عمومی تا تصمیم اجرایی، مسئولیت تغییر می‌کند
نزدیک‌شدن پاسخ به تصمیم حساس و اثرگذار، شواهد و نظارت بیشتری می‌خواهد.
برای توصیف نقش دستیار در فرایند، چهار وضعیت را جدا می‌کنیم. این‌ها طبقات ثابت ریسک نیستند؛ یک پاسخ متنی در موضوع حساس می‌تواند پرریسک‌تر از یک اقدام خودکار محدود و برگشت‌پذیر باشد.
وضعیت استفاده
نقش سامانه
انتظار از کنترل
اطلاع‌رسانی و پاسخ‌گویی
یافتن یا توضیح اطلاعات عمومی یا تخصصی
اعتبار منبع، رعایت دسترسی و روشن‌بودن حدود پاسخ
پیشنهاد و توصیه
ارائهٔ گزینه یا توصیه برای بررسی
امکان بررسی، رد یا اصلاح و دسترسی به مبنای مرتبط
پشتیبانی از تصمیم
تأمین خروجی‌ای که در تصمیم رسمی انسان نقش مشخص دارد
ارزیابی اثر، ثبت مبنا، مسئول تصمیم و امکان اعتراض
تصمیم و اقدام خودکار
تعیین نتیجه یا اجرای اقدام در دامنهٔ تفویض‌شده
اختیار مصوب، کنترل مستقل عملیات، پایش و شرایط توقف و رسیدگی
مرز این سطح‌ها را باید در فرایند واقعی دید. اگر عنوان خروجی «پیشنهاد» باشد، اما کارکنان موظف باشند آن را بدون بررسی اجرا کنند، عنوان به‌تنهایی نقش تصمیم‌گیرانهٔ سامانه را محدود نمی‌کند. باید معلوم باشد انسان واقعاً چه چیزی را بررسی می‌کند و چه اختیار عملی برای تغییر نتیجه دارد.
مدیر فناوری گفت: «می‌تونیم دو گزینه بنویسیم. در اولی، دستیار می‌گه درخواست به بررسی مرجع بالاتر نیاز داره. در دومی، خودش درخواست رو برمی‌گردونه.»
مدیر مالی گفت: «در اولی هنوز باید روشن باشه چه کسی بررسی می‌کنه. در دومی، باید اختیار برگردوندن رو هم جدا تصویب کنیم.»
مدیرعامل گفت: «همین تفاوت رو در صورت‌جلسه بیاریم. تصویب دستیار پاسخ‌گو، تصویب رد خودکار درخواست نیست.»
پیشنهاد مدیر عملیات کنار گذاشته نشد؛ به تصمیمی جداگانه تبدیل شد که باید درباره‌اش شواهد جمع می‌کردند.
طبقهٔ ریسک را از روی نام سامانه تعیین نکنیم
این طبقه‌بندی با تکیه بر قانون هوش مصنوعی اتحادیهٔ اروپا ارائه شده و جهان‌شمول نیست.
چارچوب قانون هوش مصنوعی اتحادیهٔ اروپا، کاربردها را در چهار طبقهٔ ریسک معرفی می‌کند:
ریسک غیرقابل قبول: برخی کاربردهای آسیب‌زا ممنوع‌اند؛ افزایش دقت، مجوز ادامهٔ همان کاربرد را ایجاد نمی‌کند.
ریسک بالا: برخی کاربردهای اثرگذار بر ایمنی، حقوق و فرصت‌های مهم، الزامات سخت‌گیرانه دارند؛ از جمله در بعضی استفاده‌های استخدامی، آموزشی و خدمات ضروری.
ریسک محدود: برای برخی تعامل‌ها و محتواهای هوش مصنوعی، شفافیت دربارهٔ مواجهه با سامانه یا محتوای تولیدشده اهمیت دارد.
ریسک حداقلی: کاربردهای کم‌خطر، معمولاً مشمول الزامات ویژهٔ این قانون نیستند.
این طبقه‌بندی به چارچوب حقوقی اتحادیهٔ اروپا مربوط است و جهان‌شمول نیست. همچنین، داشتن رابط گفت‌وگو به‌تنهایی ثابت نمی‌کند کاربرد کم‌خطر است؛ یک دستیار می‌تواند در فرایندی حساس به کار گرفته شود. برای تعیین الزامات حقوقی، باید کاربرد مشخص و مقررات مربوط به آن بررسی شوند.
نام «دستیار» سطح مراقبت را تعیین نمی‌کند. باید بدانیم سامانه در چه موضوعی استفاده می‌شود، چه اثری دارد و چه اختیاری به آن داده‌ایم.
این نگاه، پرسش مدیرعامل را تغییر می‌دهد. به‌جای اینکه فقط بپرسد «آیا استفاده از دستیار تصویب شده؟»، باید بپرسد «کدام استفاده، برای کدام تصمیم و تحت چه شرایطی تصویب شده است؟»
مدیر عملیات پرسید: «پس برای همهٔ سؤال‌ها یک مسیر تأیید نمی‌ذاریم؟»
مسئول ریسک و انطباق گفت: «پیدا کردن نشانی یک فرم، با توصیه دربارهٔ تعهد مالی یا تصمیم دربارهٔ یک فرد، یکسان نیست.»
مدیر منابع انسانی گفت: «حتی در واحد ما هم اعلام ساعت مراجعه با ارزیابی شرایط یک کارمند فرق داره.»
مدیرعامل گفت: «پس موضوع‌های استفاده رو جدا ثبت کنیم. یک برچسب کلی برای همهٔ دستیار کافی نیست.»
با افزایش اختیار، چه شواهد و نظارتی لازم است؟
واگذاری اختیار بیشتر، به شواهد قوی‌تر و نظارت متناسب نیاز دارد.
پس از شناخت طبقات ریسک، باید حدود اختیار را به انتظار از ارزیابی و نظارت وصل کنیم.
برای تعیین شواهد و نظارت لازم، چهار سطح «اطلاع‌رسانی و پاسخ‌گویی»، «پیشنهاد و توصیه»، «پشتیبانی از تصمیم» و «تصمیم و اقدام خودکار» را در نظر می‌گیریم.
سطح استفاده
شواهد مورد نیاز
نظارت و کنترل
اطلاع‌رسانی و پاسخ‌گویی
آزمون کارکرد و بررسی محتوای منابع
اعلام ماهیت ماشینی پاسخ و ثبت استفاده و بازخورد
پیشنهاد و توصیه
سنجش کیفیت خروجی و بررسی سناریوهای رایج
بازبینی موارد مهم و امکان رد یا اصلاح پیشنهاد
پشتیبانی از تصمیم
معیار موفقیت روشن، بررسی خطا، سوگیری و پایداری و تحلیل اثر
انسانِ تصمیم‌گیر نهایی، ثبت منطق و مسیر تصمیم و امکان اعتراض و رسیدگی
تصمیم و اقدام خودکار
شواهد قوی دربارهٔ ایمنی و اثربخشی، سناریوهای شکست و حدود توقف
تأیید رسمی، اختیار مشخص، پایش مستمر و امکان توقف فوری و بازگشت
در پروندهٔ ما، پاسخ‌دادن به چند سؤال متداول، به‌تنهایی شواهد لازم برای ردکردن درخواست خرید را فراهم نمی‌کند. برای این اختیار تازه باید وضعیت‌های مرتبط بررسی شوند: تعارض سند، اطلاعات ناقص درخواست، نیاز به استثنا و حالتی که تعیین تکلیف به مرجع دیگری تعلق دارد.
نظارت انسانی هم باید در خود فرایند معنا داشته باشد. اگر بازبین فقط یک نتیجه را ببیند و به منبع، دلیل و اطلاعات مرتبط دسترسی نداشته باشد، بررسی او محدود خواهد بود. اگر اختیار اصلاح یا ارجاع نداشته باشد، حضورش در مسیر به معنای کنترل مؤثر تصمیم نیست.
همچنین، تأیید انسانی باید به مسئولیت مشخص وصل باشد. چه کسی صلاحیت و اختیار بررسی دارد؟ چه مواردی به او ارجاع می‌شوند؟ تصمیم و دلیل آن کجا ثبت می‌شود؟ اعتراض را چه کسی پیگیری می‌کند؟
این‌ها همان کلاه‌های مسئولیت‌اند. ممکن است یک نفر چند کلاه داشته باشد یا چند نفر در انجام یک مسئولیت همکاری کنند. لازم است مسیر کار و اختیار پاسخ‌گویی روشن باشد؛ زیادکردن عنوان‌ها، جای این توافق را نمی‌گیرد.
مدیر فناوری گفت: «می‌تونیم قبل از برگشت درخواست، دکمهٔ تأیید مدیر بذاریم.»
مدیر مالی پرسید: «مدیر چی می‌بینه؟ فقط پیشنهاد برگشت رو یا دلیل، منبع و شرایط درخواست رو هم؟»
«باید اون‌ها رو هم ببینه.»
مسئول ریسک و انطباق پرسید: «اگر با پیشنهاد موافق نبود، می‌تونه اصلاحش کنه یا برای بررسی بفرسته؟»
مدیرعامل گفت: «همین‌ها رو بنویسیم. اسمش رو تأیید انسانی نذاریم و از کنارش رد نشیم. باید معلوم باشه بررسی‌کننده چه می‌دونه و چه اختیاری داره.»
برای یک دستیار، چند نوع استفاده تعریف کنیم
موضوع، اثر و میزان اختیار یا اتکا، جایگاه هر استفاده از دستیار را تغییر می‌دهند.
ماتریس پایانی، همهٔ بحث را به پروندهٔ دستیار برمی‌گرداند. محور عمودی، اثر و ریسک است؛ محور افقی، سطح اختیار یا اتکا. این کنارهم‌گذاشتن مهم است: حتی پیش از واگذاری اقدام مستقیم، اتکای زیاد به پاسخ می‌تواند نقش آن را در تصمیم پررنگ کند.
در تصویر، پاسخ عمومی در ناحیهٔ پایین‌تر قرار گرفته است. سپس کاربردهای منابع انسانی، حقوقی و قراردادی و در نهایت تصمیم اجرایی دیده می‌شوند.
این جایگاه‌ها راهنمای بررسی‌اند، نه حکم ثابت دربارهٔ همهٔ سؤال‌های هر واحد. یک سؤال عمومی دربارهٔ منابع انسانی با ارزیابی استخدام یا تصمیم دربارهٔ مزایای فرد یکسان نیست. در حوزهٔ قرارداد نیز پیدا کردن نشانی یک بند، با تفسیر تعهد و توصیه به پذیرش آن تفاوت دارد.
برای پروندهٔ خرید، می‌توان همین تمایز را به چهار استفادهٔ مشخص تبدیل کرد:
دستیار، محل فرم و مرجع مقررات خرید را نشان دهد.
دربارهٔ قاعدهٔ مرتبط با درخواست، با ذکر منبع توضیح بدهد.
ارجاع درخواست به مرجع بالاتر را برای بررسی پیشنهاد کند.
درخواست را تأیید، رد یا به‌طور رسمی در مسیر دیگری قرار دهد.
ممکن است همهٔ این قابلیت‌ها زیر یک نام و در یک محیط عرضه شوند، اما تصویب و ارزیابی آن‌ها را نباید یکجا انجام داد. سازمان می‌تواند یک استفاده را در دامنه‌ای محدود بپذیرد و استفادهٔ دیگری را تا فراهم‌شدن شواهد و کنترل‌های لازم، مجاز نداند.
خروجی این بحث باید قابل رجوع باشد. برای هر استفاده، باید بتوانیم بگوییم موضوع چیست، خروجی چه اثری دارد، چه کسی بر آن تکیه می‌کند، حد اختیار سامانه کجاست و چه کسی مسئول تأیید، رسیدگی یا توقف است.
مصوبه‌ای که حدودش معلوم بود
مدیرعامل برگهٔ منشور را به سمت خود کشید.
گفت: «برای نسخهٔ فعلی، نشون‌دادن منبع و توضیح مقررات رو در دامنهٔ آزمایش نگه می‌داریم. موارد مبهم یا متعارض هم باید برای بررسی ارجاع بشن.»
«باقی می‌مونه. ولی رد خودکار درخواست، فعلاً جزو اختیار این نسخه نیست. برای اون باید جدا شواهد و مسئولیت‌ها رو بررسی کنیم.»
مدیر مالی گفت: «و پیشنهاد ارجاع هم باید معلوم باشه چه کسی تأییدش می‌کنه.»
مسئول ریسک و انطباق به صورت‌جلسه اشاره کرد: «حدود استفاده و مسئول رسیدگی رو همین‌جا ثبت کنیم.»
مدیر فناوری گفت: «پس این حدود باید در خود سامانه هم قابل اجرا باشه. فقط نوشتنش در صورت‌جلسه کافی نیست.»
مدیرعامل پرسید: «برای اینکه منابع معتبر، دسترسی‌ها و همین حدود اختیار واقعاً تحت کنترل ما بمونن، سامانه رو چطور باید تهیه و اداره کنیم؟»
این بار، بحث به انتخاب شیوهٔ ساخت و تأمین دستیار رسیده بود؛ با تصویری روشن‌تر از آنچه سازمان می‌خواست تحت کنترل نگه دارد.
با این درس، بخش سوم پایان می‌یابد. در درس بعد، از اسلاید ۴۹ وارد بخش چهارم، «معماری، داده و تأمین‌کننده»، می‌شویم. پرسش مدیریتی آن بخش این است که انتخاب شیوهٔ ساخت و تأمین، چه اثری بر کنترل، مسئولیت و امکان ادارهٔ دستیار دارد.
درس نهم؛ انتخاب معماری و شیوهٔ تأمین، مسئولیت اجزا، کنترل دارایی‌ها و امکان تغییر تأمین‌کننده.
مطالعهٔ درس: ساخت یا خرید هوش مصنوعی؛ کنترل چه چیزی باید دست سازمان بماند؟
پیشنهادی که همه‌چیز را یکجا تحویل می‌داد
مدیر فناوری، در پاسخ به پرسش آخر مدیرعامل، دو پیشنهاد را روی نمایشگر آورد.
در اولی نوشته بودند: «راهکار آمادهٔ دستیار سازمانی؛ راه‌اندازی، میزبانی و پشتیبانی توسط تأمین‌کننده.» در دومی، بخشی از کار بر عهدهٔ تیم داخلی بود و چند جزء را باید جداگانه تهیه می‌کردند.
مدیر عملیات به پیشنهاد اول اشاره کرد: «این که مسیرش کوتاه‌تره. یک طرف هم مسئول تحویل داریم.»
مدیر مالی پرسید: «هزینهٔ ادامهٔ کارش چقدره؟»
مدیر فناوری گفت: «هزینهٔ راه‌اندازی و پشتیبانی رو نوشتن. برای تغییر دامنه و افزایش استفاده باید جزئیات بیشتری بگیریم.»
مسئول ریسک و انطباق پرسید: «دسترسی به اسناد رو چه کسی تعیین می‌کنه؟ اگر بخوایم استفاده از یک منبع یا قابلیت رو متوقف کنیم، خودمون می‌تونیم؟»
مدیر منابع انسانی گفت: «و وقتی یک سند عوض می‌شه، مسئول تأیید و جایگزین‌کردنش کیه؟ این رو هم شرکت انجام می‌ده؟»
مدیر عملیات گفت: «پس ازشون می‌پرسیم چه چیزهایی رو انجام می‌دن.»
مدیرعامل به دو پیشنهاد نگاه کرد. «فقط این رو نپرسیم. معلوم کنیم چه چیزهایی باید تحت اختیار خودمون بمونه. اگر یک روز بخوایم مسیر رو عوض کنیم، باید بدونیم چه چیزی رو می‌تونیم با خودمون ببریم.»
در درس هشتم حدود پاسخ‌گویی، پیشنهاد، تصمیم و اقدام را از هم جدا کردیم. دیدیم که برای هر استفاده، شواهد، مسئول تأیید و امکان رسیدگی یا توقف باید روشن باشند.
دو پیشنهاد روی نمایشگر، راه‌های متفاوتی برای اجرای همان حدود پیش پای مدیران گذاشته‌اند. انتخاب میان آن‌ها به تقسیم کار، محل نگهداری اطلاعات، اختیار تغییر، هزینهٔ ادامه و میزان وابستگی هم مربوط است. پرسش مدیرعامل دربارهٔ تغییر تأمین‌کننده، این تصمیم‌ها را آشکار می‌کند: سازمان برای ادامهٔ کار، کنترل چه چیزهایی را باید در اختیار داشته باشد؟
این درس، آغاز بخش چهارم دوره، «معماری، داده و تأمین‌کننده»، و مبتنی بر اسلایدهای ۴۹ تا ۵۴ است. پرسش ما مدیریتی است: چه چیزی را تهیه می‌کنیم، مسئولیت هر بخش با کیست و کنترل چه دارایی‌ها و تصمیم‌هایی باید در اختیار سازمان بماند؟
انتخاب معماری، میزان کنترل و وابستگی را تغییر می‌دهد
انتخاب معماری بر کنترل سازمان بر داده، تصمیم و آیندهٔ سامانه اثر دارد.
معماری در این بحث، به چگونگی کنار هم قرارگرفتن اجزای راهکار و تقسیم ادارهٔ آن‌ها مربوط است. مدیر لازم است بداند این ترتیب، چه اختیاری برای سازمان ایجاد می‌کند و چه وابستگی‌هایی به همراه دارد.
برای مقایسهٔ گزینه‌های معماری، پنج موضوع را پیش روی تصمیم‌گیر می‌گذاریم:
کنترل: داده کجا می‌ماند، چه کسی می‌تواند تنظیمات را تغییر دهد و چه چیزی واقعاً در اختیار سازمان است؟
هزینه: راه‌اندازی، افزایش استفاده، نگهداری و تغییر مسیر در آینده چه منابعی می‌خواهند؟
امنیت: اطلاعات در چه محدوده‌ای پردازش می‌شود، دسترسی چگونه تعیین می‌شود و رخدادها چگونه پیگیری می‌شوند؟
استقلال: سازمان برای فهم و ادارهٔ سامانه چه دانشی دارد و برای تغییرات تا چه اندازه به تأمین‌کننده وابسته است؟
امکان خروج: آیا می‌توان داده و خدمت را منتقل کرد و تأمین‌کننده را جایگزین کرد؟
این پرسش‌ها باید در مقایسهٔ پیشنهادها حضور داشته باشند. ممکن است یک گزینه با هزینهٔ اولیهٔ کمتر آغاز شود، اما تغییر دامنه یا انتقال آن در آینده پرهزینه باشد. ممکن است گزینه‌ای اختیار بیشتری به سازمان بدهد، اما برای ادارهٔ آن به نیروی انسانی و مسئولیت بیشتری نیاز داشته باشیم.
داشتن تجهیزات در محل سازمان نیز به‌تنهایی پاسخ همهٔ پرسش‌های کنترل نیست. باید معلوم باشد چه کسی دسترسی مدیریتی دارد، چه کسی تغییرات را انجام می‌دهد و سازمان برای ادامه یا توقف خدمت به چه کسی وابسته است. در استفاده از خدمت بیرونی هم باید همین مرزهای اختیار را روشن کنیم.
مدیر مالی گفت: «پس این دو رقم راه‌اندازی رو مستقیم کنار هم نذاریم. هزینهٔ ادامه و تغییر رو هم بخوایم.»
مدیر فناوری گفت: «و مشخص کنیم چه تغییرهایی رو خودمون می‌تونیم انجام بدیم و برای کدوم‌ها باید سفارش تازه بدیم.»
مدیرعامل پرسید: «اگر بخوایم یک منبع نامعتبر رو از استفاده خارج کنیم، این کار در اختیار چه کسیه؟»
سؤال ساده بود، اما در هیچ‌کدام از دو صفحهٔ نخست پیشنهادها جواب روشنی نداشت.
مسئولیت را در چهار رکن سامانه روشن کنیم
هر رکن، مسئولیت تخصصی و تصمیم‌های حکمرانی متفاوتی دارد.
ممکن است همهٔ راهکار را از یک شرکت بگیریم، اما مسئولیت‌های سازمانی آن همچنان متفاوت‌اند. برای روشن‌کردن این مسئولیت‌ها، چهار رکن را جدا می‌کنیم: داده، مدل، پلتفرم و زیرساخت، و کاربرد و فرایند.
رکن
مسئولیت محوری
پرسش تصمیم‌ساز برای سازمان
داده
کیفیت، کامل‌بودن، محرمانگی و اعتبار منابع
چه اطلاعاتی وارد سامانه می‌شود، چه کسی مجاز به استفاده است و نسخهٔ معتبر کدام است؟
مدل
کیفیت عملکرد، سوگیری و تغییر رفتار در طول استفاده
کدام مدل پذیرفته می‌شود و در چه شرایطی باید دوباره ارزیابی شود؟
پلتفرم و زیرساخت
امنیت، دسترس‌پذیری، هزینه و وابستگی
خدمت کجا اداره می‌شود، دسترسی با کیست و مسیر پشتیبانی و خروج چیست؟
کاربرد و فرایند
اثر بر کاربر و تصمیم سازمانی
دستیار در کدام تصمیم مجاز است، چه نظارتی لازم است و چه کسی پاسخ‌گوست؟
در پروندهٔ ما، واحد فناوری می‌تواند محل نگهداری اسناد را اداره کند، اما اعتبار آخرین اصلاحیهٔ خرید را باید مسئول محتوای همان حوزه تأیید کند. تیم ارزیابی می‌تواند کیفیت پاسخ را بررسی کند، اما اجازهٔ استفاده از آن برای تصمیم خرید، به صاحب فرایند و مرجع تعیین اختیار مربوط است.
تأمین‌کننده نیز ممکن است بخشی از کار هر رکن را انجام دهد. لازم است روشن کنیم چه کاری به او سپرده می‌شود، چه چیزی را تحویل می‌دهد و پذیرش نتیجه در سازمان بر عهدهٔ چه کسی است.
این تفکیک، به معنای ایجاد چهار سمت تازه نیست. مسئولیت‌ها کلاه‌اند: یک نفر می‌تواند چند کلاه داشته باشد و چند نفر می‌توانند در یک مسئولیت همکاری کنند. مهم آن است که هنگام تغییر یا خطا، مسیر تصمیم و پاسخ‌گویی معلوم باشد.
مدیر منابع انسانی پرسید: «اگر شرکت اسناد رو وارد کنه، مسئول درست‌بودن محتوا هم می‌شه؟»
مدیر مالی گفت: «ورود فایل رو می‌تونیم بهش بسپریم. ولی باید خودمون معلوم کنیم کدوم سند معتبره.»
مدیر فناوری گفت: «من هم باید مطمئن بشم همون نسخهٔ تأییدشده در دستیار استفاده می‌شه.»
مدیرعامل گفت: «پس در تحویل کار، فقط ننویسیم اسناد بارگذاری شد. تأیید محتوا و کنترل استفاده از نسخه رو هم مشخص کنیم.»
دستیار درون یک سامانهٔ سازمانی کار می‌کند
ارزش، از ارتباط داده، سامانه‌ها، افراد و فرایندها شکل می‌گیرد.
هوش مصنوعی در میانهٔ مسیر ارائهٔ خدمت قرار دارد. پیش از آن، منابع داده و سامانه‌های عملیاتی‌اند؛ پس از آن، کاربردها، کانال‌های ارتباط با کاربران و نتایج سازمانی.
برای دستیار خرید، مسیر می‌تواند از مقررات و اطلاعات معتبر شروع شود، به پاسخ یا پیشنهاد برسد و در نهایت بر نحوهٔ رسیدگی به درخواست اثر بگذارد. موفقیت، به درست‌کارکردن ارتباط این بخش‌ها وابسته است.
اگر مرجع معتبر محتوا روشن نباشد، پاسخ قابل اتکا دشوار می‌شود. اگر دستیار پاسخ درست بدهد اما کاربر نداند قدم بعدی چیست، ممکن است کار همچنان متوقف بماند. اگر پیشنهاد ارجاع تولید شود اما مرجع رسیدگی و مسیر تحویل آن معلوم نباشد، صرف تولید پیشنهاد مسئله را حل نمی‌کند.
لایه‌های پشتیبان این مسیر عبارت‌اند از امنیت و حریم خصوصی، اخلاق و مسئولیت‌پذیری، ریسک و انطباق، مالی و هزینه، نقش‌ها و سیاست‌ها، و پایش و بهبود مستمر. این موضوع‌ها به کل خدمت مربوط‌اند.
بنابراین، در ارزیابی پیشنهاد باید کل مسیر استفاده را ببینیم. تحویل یک محیط پاسخ‌گو، فقط بخشی از تعهد مورد انتظار است. باید روشن باشد به‌روزرسانی محتوا، مدیریت دسترسی، رسیدگی به بازخورد و سنجش نتیجه چگونه در کار روزمره قرار می‌گیرند.
مدیر عملیات پرسید: «اگر دستیار بگه درخواست باید به کمیته بره، خودش ارجاع می‌ده؟»
مدیر فناوری گفت: «در دامنه‌ای که فعلاً تصویب کردیم، نه. فقط مسیر رو توضیح می‌ده.»
مدیر عملیات گفت: «پس باید معلوم باشه کاربر بعدش چه کاری انجام می‌ده. اگر فقط اسم کمیته رو بگیم، ممکنه دوباره تماس بگیره.»
مدیرعامل کنار دامنهٔ تحویل نوشت: «بررسی مسیر واقعی استفاده، از سؤال تا رسیدگی.»
حالا می‌دانستند پایان نمایش پاسخ روی صفحه، الزاماً پایان کار کاربر نیست.
چه دارایی‌هایی باید در اختیار سازمان بمانند؟
دارایی‌های سازندهٔ مزیت، امنیت و استقلال تصمیم‌گیری باید تحت مالکیت و کنترل سازمان بمانند.
شش گروه دارایی را از هم جدا می‌کنیم. برای هر گروه، لازم است از عنوان کلی «مالکیت سازمان» به یک انتظار قابل بررسی برسیم.
دارایی
چه چیزی باید روشن بماند؟
داده‌های راهبردی
اطلاعات اختصاصی، اسناد کلیدی و داده‌های تولیدشده کجا نگهداری می‌شوند و سازمان چگونه به آن‌ها دسترسی دارد؟
مدل‌ها و دانش مدل
اجزای اختصاصی، تنظیمات، نسخه‌ها و دانش لازم برای اداره و ارزیابی آن‌ها در اختیار چه کسی است؟
سیاست‌ها و استانداردها
قواعد امنیت، دسترسی، کیفیت و ارزیابی را چه کسی تعیین و تغییر می‌دهد؟
فرایندها و تصمیم‌ها
منطق تصمیم، دستورالعمل‌ها و معیارهای موفقیت چگونه ثبت و به‌روز می‌شوند؟
زیرساخت حیاتی
اختیار دسترسی، حفاظت، تداوم خدمت و بازیابی چگونه در اختیار سازمان قرار می‌گیرد؟
نیروی انسانی و دانش داخلی
چه کسانی در سازمان، دانش کافی برای ارزیابی، تصمیم‌گیری و ادامهٔ کار دارند؟
در مورد ابزارها و مدل‌های عمومی، سازمان باید حق استفاده و حدود وابستگی را روشن کند. دربارهٔ دارایی‌های اختصاصی خود، مانند اسناد، قواعد تصمیم و دانش حاصل از اجرای پروژه، باید امکان حفظ و استفادهٔ مستقل را در تصمیم تأمین ببیند.
برای نمونه، اگر در طول پایلوت مجموعه‌ای از سؤال‌های ارزیابی، پاسخ‌های مورد تأیید و موارد خطا تهیه کرده‌ایم، این‌ها بخشی از دانش پروژه‌اند. برای ارزیابی تغییرات یا مقایسهٔ تأمین‌کنندهٔ بعدی به آن‌ها نیاز خواهیم داشت.
کنترل نیز باید عملی باشد. اگر سازمان نتواند فهرست منابع، وضعیت دسترسی‌ها یا سوابق لازم برای رسیدگی را دریافت کند، عبارت کلی «اطلاعات متعلق به کارفرماست» همهٔ نیازش را برآورده نکرده است. باید معلوم باشد چه چیزی، در چه قالبی و با چه ترتیبی در اختیار سازمان قرار می‌گیرد.
توان داخلی هم بخشی از همین کنترل است. سازمان به کسانی نیاز دارد که بتوانند اعتبار محتوا، کیفیت خروجی و اثر تغییرات را بررسی کنند و دربارهٔ پیشنهاد تأمین‌کننده تصمیم بگیرند. میزان این توان باید با دامنه و حساسیت استفاده تناسب داشته باشد.
وابستگی فنی نیز می‌تواند در ابزار اجرا و مهارت تیم پنهان بماند. اگر فردا NVIDIA را برداریم، چه چیزهایی می‌شکند؟ یک نمونهٔ مشخص از هزینهٔ خروج در لایه‌های نرم‌افزار، ارتباط پردازنده‌ها و موتور استنتاج است.
مدیر مالی پرسید: «اگر سال بعد بخوایم شرکت رو عوض کنیم، اسناد خودمون رو که داریم. چیز دیگه‌ای هم لازم داریم؟»
مدیر فناوری گفت: «باید بدونیم چه منابعی تأیید شدن، چه تنظیماتی اعمال شده، چه آزمون‌هایی انجام دادیم و چه ایرادهایی پیدا شده.»
مسئول ریسک و انطباق گفت: «و چه دسترسی‌ها و حدود اختیاری تصویب شده. نباید از اول حدس بزنیم نسخهٔ فعلی بر چه مبنایی کار می‌کرده.»
مدیرعامل گفت: «پس انتقال دانش و اطلاعات لازم برای ادامهٔ کار، جزو خروجی‌های مشخص پروژه باشه.»
ساخت، خرید، خدمت آماده یا ترکیب چند گزینه؟
انتخاب مناسب، به نیاز سازمان به کنترل، سرعت، هزینه، امنیت و استقلال بستگی دارد.
پس از روشن‌شدن مسئله و دارایی‌های مهم، می‌توان پنج مسیر تأمین را با هم مقایسه کرد:
ساخت: می‌تواند برای نیاز اختصاصی یا قابلیت متمایز سازمان مناسب باشد. در مقابل، زمان، تیم و مسئولیت توسعه و نگهداری می‌خواهد. سازمان باید بسنجد آیا ارزش این اختصاصی‌سازی، منابع لازم را توجیه می‌کند.
خرید راهکار آماده: می‌تواند راه رسیدن به یک قابلیت استاندارد را کوتاه کند. باید دامنهٔ سازگاری با فرایند سازمان، محدودیت تغییر، پشتیبانی و هزینهٔ ادامهٔ استفاده روشن باشد.
دریافت یک قابلیت به‌صورت خدمت از تأمین‌کننده، یا API: می‌تواند شروع را سریع کند و نیاز به ادارهٔ بخشی از راهکار را کاهش دهد. پرسش‌های مدیریتی آن، محل و شرایط استفاده از داده، هزینهٔ مصرف، تداوم خدمت و وابستگی به عرضه‌کننده‌اند.
پرسش مربوط به خروج داده را در حفظ محرمانگی داده در استفاده از APIهای عمومی دقیق‌تر بررسی کرده‌ام؛ از اطلاعاتی که در معنا و روابط متن باقی می‌مانند تا حدود روش‌های حذف نام و ناشناس‌سازی.
استفاده از راهکار متن‌باز: می‌تواند امکان اداره و تغییر بیشتری در اختیار تیم قرار دهد. هزینهٔ استقرار، نگهداری و پشتیبانی و توان لازم برای پذیرفتن این مسئولیت‌ها باید در ارزیابی حضور داشته باشد.
معماری ترکیبی: اجزا را بر اساس نیاز تهیه می‌کند. ممکن است سازمان یک بخش را بخرد، از خدمت آماده‌ای استفاده کند و ادارهٔ منابع و قواعد حساس را در اختیار خود نگه دارد. این انتخاب به مسئولیت روشن برای هماهنگی اجزا و ادارهٔ کل خدمت نیاز دارد.
این گزینه‌ها می‌توانند کنار هم قرار بگیرند. لازم نیست انتخاب یک مدل، روش تهیهٔ همهٔ اجزای دیگر را هم تعیین کند. موضوع آن است که هر جزء چگونه به نیاز سازمان پاسخ می‌دهد و مسئولیت ارتباط آن با بقیهٔ سامانه بر عهدهٔ کیست.
این مقایسه، جهت کلی تفاوت‌ها را نشان می‌دهد. برای انتخاب واقعی باید همان عوامل را در پیشنهاد مشخص بررسی کنیم. سرعت شروع، هزینه و میزان کنترل، به دامنهٔ کار، شرایط تأمین و توان سازمان وابسته‌اند.
در پروندهٔ دستیار، نقطهٔ شروع مقایسه باید همان تصمیم‌های درس‌های قبل باشد: منابع معتبر، حدود دسترسی، اختیار محدود و مسیر رسیدگی. از هر گزینه می‌خواهیم نشان دهد این نیازها را چگونه برآورده می‌کند و چه تعهدی را بر عهدهٔ سازمان می‌گذارد.
پیش از انتخاب نام شرکت
مدیر عملیات به پیشنهاد اول برگشت: «ممکنه هنوز همین گزینه مناسب‌تر باشه.»
مدیرعامل گفت: «ممکنه. حالا می‌دونیم برای انتخابش چه چیزهایی رو باید روشن کنیم.»
مدیر مالی فهرست کوتاهی نوشت: «هزینهٔ شروع، ادامه، تغییر و خروج.»
مسئول ریسک و انطباق گفت: «و اینکه محدودیت‌هایی که تصویب کردیم، در عمل چطور اجرا و بررسی می‌شن.»
مدیرعامل گفت: «با همین پرسش‌ها پیشنهادها رو تکمیل کنیم. بعد مقایسه کنیم چه چیزی می‌گیریم و چه مسئولیتی می‌پذیریم.»
مدیر منابع انسانی به فهرست قابلیت‌های یکی از پیشنهادها اشاره کرد: «اینجا برای همهٔ کارها، تولید پاسخ و متن پیشنهاد داده. برای تشخیص و دسته‌بندی درخواست‌ها هم همین رو لازم داریم؟»
مدیر فناوری گفت: «باید ببینیم هر کار دقیقاً چه خروجی‌ای می‌خواد.»
گفت‌وگو به پرسش بعدی رسیده بود: انتخاب نوع راهکار، بر اساس کاری که باید انجام شود.
در درس بعد، از اسلاید ۵۵ ادامه می‌دهیم و گزینه‌های راهکار و محدودیت‌های آن‌ها را بررسی می‌کنیم. محور بحث همچنان تصمیم سازمان است: برای هر مسئله چه قابلیتی لازم داریم و چه انتظاری از آن می‌توانیم داشته باشیم؟
درس دهم؛ انتخاب قابلیت مناسب، ارزیابی خروجی، ریسک تولید محتوا و الگوهای ادارهٔ دستیار سازمانی.
مطالعهٔ درس: آیا هر مسئله‌ای به هوش مصنوعی مولد نیاز دارد؟
آیا همهٔ این کارها، تولید پاسخ می‌خواهند؟
مدیر منابع انسانی هنوز به فهرست قابلیت‌های پیشنهاد نگاه می‌کرد.
گفت: «اینجا برای دسته‌بندی درخواست‌ها هم نوشته از دستیار مولد استفاده می‌کنیم. ما می‌خوایم معلوم بشه درخواست مربوط به آموزش، مرخصی یا مزایاست. آخرش چه چیزی باید تولید کنه؟»
مدیر فناوری گفت: «خروجی اون قسمت می‌تونه فقط یک دسته و مقصد رسیدگی باشه.»
«اون هم یک کار جداست. باید سابقه و وضعیت رسیدگی رو بررسی کنیم.»
مدیر مالی یکی از نمونه‌های پاسخ را باز کرد. «ولی چیزی که به ما نشون دادن، این متن چندپاراگرافیه. خوب نوشته شده، اما از روی این نمی‌فهمیم دسته‌بندی یا پیش‌بینی هم درست کار می‌کنه.»
مدیرعامل فهرست را از اول خواند: پاسخ به پرسش، دسته‌بندی درخواست، پیش‌بینی تأخیر، تهیهٔ پیش‌نویس و پیشنهاد ارجاع.
گفت: «تا اینجا همه رو زیر اسم دستیار جمع کرده بودیم. برای هرکدوم بنویسیم چه خروجی‌ای می‌خوایم و از کجا می‌فهمیم درست انجام شده.»
در درس نهم دیدیم که انتخاب شیوهٔ ساخت و تأمین، بر کنترل دارایی‌ها، مسئولیت اجزا و امکان تغییر مسیر اثر دارد. برای مقایسهٔ پیشنهادها باید بدانیم چه چیزی تحویل می‌گیریم و چه مسئولیتی می‌پذیریم.
پرسش مدیر منابع انسانی، حالا فهرست قابلیت‌های همان پیشنهاد را باز کرده است. دسته‌بندی درخواست و پیش‌بینی تأخیر، خروجی و معیار موفقیت خود را می‌خواهند؛ متن چندپاراگرافیِ خوش‌خوان، موفقیت آن‌ها را اثبات نمی‌کند. باید کارهایی را که زیر نام «دستیار» جمع شده‌اند جدا کنیم و برای هرکدام قابلیت، داده، ارزیابی و مسئولیت متناسب بخواهیم.
این درس، اسلایدهای ۵۵ تا ۵۸ را به ترتیب دنبال می‌کند: دامنهٔ راهکارهای غیرمولد، مقایسه با هوش مصنوعی مولد، ریسک‌های تولید محتوا و سه الگوی پیشنهادی برای ادارهٔ دستیار سازمانی.
هوش مصنوعی، کارهای زیادی فراتر از تولید محتوا دارد
دامنهٔ قابلیت‌های هوش مصنوعی را باید فراتر از تولید متن دید.
مدیر هنگام انتخاب راهکار با دامنه‌ای از قابلیت‌ها روبه‌روست: پیش‌بینی، پردازش زبان و گفتار، شناخت تصویر، سیستم‌های خبره، برنامه‌ریزی، بهینه‌سازی و رباتیک. هدف این است که هنگام تعریف راهکار، همهٔ نیازها را به گفت‌وگو و تولید متن تقلیل ندهیم.
ممکن است سازمان بخواهد تقاضای ماه آینده را برآورد کند، درخواست‌ها را دسته‌بندی کند، اطلاعات مشخصی را از اسناد بیرون بکشد یا یک وضعیت غیرعادی را تشخیص دهد. در هر مورد باید بدانیم چه نتیجه‌ای به کار سازمان می‌آید.
در پروندهٔ دستیار، دسته‌بندی درخواست باید به رسیدن آن به مرجع درست کمک کند. پیش‌بینی تأخیر باید امکان رسیدگی زودتر یا تخصیص منابع را فراهم کند. استخراج مبلغ و تاریخ از یک سند نیز باید اطلاعات درست و قابل بررسی در اختیار فرایند بگذارد.
هیچ‌کدام از این نتیجه‌ها با دیدن یک متن خوش‌خوان اثبات نمی‌شوند. برای هرکدام، نمونه‌های مرتبط و معیار پذیرش لازم است. حتی ممکن است بخشی از کار با قاعدهٔ روشن یا قابلیت موجود سازمان انجام شود؛ همان پرسشی که در درس‌های صورت‌بندی مسئله مطرح کردیم.
پس در مقایسهٔ پیشنهادها، از تأمین‌کننده می‌خواهیم کار مورد انتظار را توضیح دهد: کدام قابلیت چه خروجی‌ای می‌سازد، به کدام داده نیاز دارد و نتیجهٔ آن چگونه سنجیده می‌شود؟
مدیر عملیات گفت: «برای دسته‌بندی، نمونهٔ درخواست‌های قبلی رو داریم. می‌تونیم ببینیم به واحد درست می‌رسن یا نه.»
مدیر منابع انسانی گفت: «مواردی هم داریم که بین دو واحد مرزشون روشن نیست. اون‌ها رو هم باید ببینیم.»
مدیر فناوری گفت: «پس فقط چند مثال واضح برای نمایش انتخاب نکنیم.»
برای اولین بار، این قابلیت معیار خودش را پیدا کرده بود.
نوع خروجی، انتظار از ارزیابی را تغییر می‌دهد
قابلیت‌های مولد و غیرمولد می‌توانند در یک راهکار کنار هم قرار بگیرند.
پیش‌بینی تقاضا، قیمت‌گذاری و بهینه‌سازی، در کنار نوشتن و ویرایش، تهیهٔ پیش‌نویس، تولید طرح و گفت‌وگو، نیازهای متفاوتی را پوشش می‌دهند. بعضی کاربردها، مانند توصیه‌گری و تشخیص تقلب، می‌توانند از ترکیب روش‌های مولد و غیرمولد استفاده کنند.
در کاربرد مولد، تولید محتوا بخشی از کار است؛ برای نمونه، تهیهٔ پیش‌نویس نامه یا خلاصهٔ جلسه. در کارهای دیگری مانند پیش‌بینی یا دسته‌بندی، ممکن است خروجی مطلوب یک برآورد، یک دسته یا یک امتیاز باشد. انتخاب روش انجام کار باید با نیاز و شواهد ارزیابی آن تناسب داشته باشد.
برای پروندهٔ ما، می‌توان انتظارها را این‌گونه جدا کرد:
کار مورد انتظار
خروجی مورد نیاز
چه چیزی باید بررسی شود؟
دسته‌بندی درخواست
دسته و مقصد رسیدگی
آیا درخواست به مرجع درست می‌رسد و موارد مبهم چگونه رسیدگی می‌شوند؟
پیش‌بینی تأخیر
برآورد احتمال یا زمان تأخیر
آیا برآورد در عمل به شناسایی و رسیدگی به موارد مهم کمک می‌کند؟
تهیهٔ پیش‌نویس پاسخ
متن پیشنهادی
آیا متن درست، مرتبط، متناسب با مخاطب و قابل تأیید است؟
پیشنهاد ارجاع
پیشنهاد همراه با مبنا
آیا دلیل پیشنهاد معتبر است و مسئول تأیید مشخص است؟
همین پرسش‌ها در پیش‌بینی خرابی چه شکلی دارند؟
برای مقایسه، یک پروندهٔ فرضی دیگر را در نظر بگیریم: سامانه‌ای از دادهٔ حسگرها و سابقهٔ تعمیر، احتمال خرابی تجهیزات را برآورد می‌کند. خروجی، متن پاسخ‌گو نیست؛ هشدار یا امتیازی است که در برنامهٔ تعمیر اثر می‌گذارد.
موضوع
دستیار اسنادی
پیش‌بینی خرابی تجهیزات
دادهٔ مهم
سند معتبر، نسخه و مجوز استفاده
دادهٔ حسگر، وضعیت تجهیز و سابقهٔ معتبر خرابی و تعمیر
خطای مهم
پاسخ نامعتبر، افشای اطلاعات یا ارجاع نامناسب
خرابیِ کشف‌نشده یا هشدار بی‌مورد
ارزیابی
صحت و اعتبار پاسخ، ارجاع و رعایت دسترسی
کشف خرابی با فرصت اقدام، هشدار کاذب و بار رسیدگی
حد اختیار
توضیح، پیشنهاد یا اقدام در دامنهٔ مصوب
هشدار به مسئول تعمیر یا توقف تجهیز، فقط در صورت تصویب جداگانه
تغییر مهم
تغییر سند، مدل یا دامنهٔ استفاده
تغییر حسگر، نوع تجهیز، الگوی کار یا سیاست تعمیر
در پروندهٔ تجهیزات، واکنش به هشدار می‌تواند جلوی خرابی را بگیرد. بنابراین نبود خرابی پس از مداخله، به‌تنهایی ثابت نمی‌کند هشدار غلط بوده است. ثبت اقدام تعمیر و بررسی مستقل موارد، بخشی از شناخت نتیجه است. تغییر سیاست تعمیر نیز می‌تواند داده‌های بعدی را تغییر دهد.
اصول حق تصمیم، مسئولیت، شواهد و بازبینی میان دو پرونده مشترک‌اند؛ اما پیکرهٔ آزمون، معیارها، منشأ خطا و کنترل عملیاتی آن‌ها یکسان نیست. چک‌لیست دستیار اسنادی را نباید بدون تغییر به این کاربرد منتقل کرد.
این جدول، نوع خروجی را روشن می‌کند؛ تصمیم دربارهٔ روش انجام هر کار، به بررسی جداگانه نیاز دارد. ممکن است یک راهکار، دسته‌بندی، جست‌وجو و تولید متن را کنار هم داشته باشد.
غیرمولدبودن یک قابلیت، آن را از حکمرانی بی‌نیاز نمی‌کند. اگر دسته‌بندی، دسترسی فرد به رسیدگی را تغییر دهد یا یک امتیاز مبنای تصمیم حساس شود، همان پرسش‌های اثر، اختیار و امکان اعتراض مطرح‌اند.
مدیر مالی گفت: «پس در پایلوت، برای هر ردیف نتیجهٔ خودش رو می‌خوایم. کیفیت پیش‌نویس رو به حساب درست‌بودن پیش‌بینی نذاریم.»
مدیر فناوری گفت: «و اگر یک قابلیت رو برای شروع لازم نداریم، می‌تونیم از دامنهٔ این مرحله خارجش کنیم.»
مدیرعامل پرسید: «کدوم قسمت الان بیشترین کمک رو به مسئلهٔ منتخب می‌کنه؟»
این بار، گفت‌وگو به‌جای بلندترکردن فهرست قابلیت‌ها، دربارهٔ اولویت آن‌ها بود.
تولید محتوای روان، به کنترل‌های مشخص نیاز دارد
هنگام پذیرش قابلیت مولد، باید پیامد تولید و استفاده از محتوا را بررسی کنیم.
تولید محتوا با ریسک‌هایی همراه است که شدت آن‌ها را باید در همان کاربرد مشخص سنجید؛ با توجه به مخاطب، داده، حدود استفاده و پیامد اتکا به خروجی.
برای پروندهٔ دستیار، هر موضوع ریسک به پرسشی مدیریتی دربارهٔ پذیرش و ادارهٔ خدمت تبدیل می‌شود:
موضوع ریسک
پرسشی برای پذیرش و ادارهٔ دستیار
اطلاعات نادرست
درستی اطلاعات پاسخ چگونه بررسی می‌شود و اصلاح آن به چه کسی می‌رسد؟
پاسخ ساختگی
اگر سامانه عدد، بند یا مرجعی بدون پشتوانه بسازد، چگونه آشکار و رسیدگی می‌شود؟
محتوای نامناسب
چه محتوایی برای محیط و مخاطب سازمان قابل قبول است و موارد نامناسب چگونه پیگیری می‌شوند؟
سوگیری
آیا کیفیت یا نحوهٔ پاسخ‌گویی برای گروه‌ها و شرایط مختلف بررسی شده است؟
مالکیت فکری
استفاده و انتشار محتوای ورودی و خروجی، چه بررسی و تأییدی می‌خواهد؟
حریم خصوصی
چه اطلاعاتی مجاز است وارد سامانه شود و چه کسی مجاز است آن را در خروجی ببیند؟
دستکاری و جعل هویت
چگونه روشن می‌ماند متن را چه کسی تولید و چه مرجعی تأیید کرده است؟
پیامد ناخواسته
کاربر ممکن است از خروجی چه برداشتی کند و بر اساس آن چه اقدامی انجام دهد؟
یکی از مسائل مهم، پاسخی است که نادرست است اما با اطمینان و ظاهری موجه ارائه می‌شود. وجود توضیح یا ارجاع در متن نیز به‌تنهایی پشتوانهٔ آن را ثابت نمی‌کند. نمایهٔ ریسک هوش مصنوعی مولد NIST نیز به تولید محتوای نادرست و حتی استدلال یا ارجاع ساختگی توجه می‌دهد.
برای دستیار خرید، باید بتوانیم بررسی کنیم عدد اعلام‌شده از کدام منبع معتبر آمده و آیا توضیح پاسخ واقعاً با آن منبع سازگار است. در پیش‌نویس نامه نیز لازم است وضعیت «پیشنهاد برای بررسی» با «متن تأییدشدهٔ سازمان» روشن بماند.
این پرسش‌ها باید در معیار پذیرش و مسئولیت ادارهٔ خدمت وارد شوند. عبارت کلی «کاربر خروجی را بررسی کند» کافی نیست، مگر آنکه معلوم باشد چه کسی، چه چیزی را، با چه اطلاعات و اختیاری بررسی می‌کند.
مدیر مالی یکی از پاسخ‌های نمونه را خواند: «اینجا به یک بند مقررات اشاره کرده. خود بند رو هم داریم؟»
مدیر فناوری سند را باز کرد. «باید متن پاسخ رو با همین منبع تطبیق بدیم.»
مدیر منابع انسانی گفت: «در پیش‌نویس‌ها هم ممکنه متن، رسمی و قطعی به نظر بیاد. باید معلوم باشه هنوز تأیید نشده.»
مدیرعامل گفت: «این رو جزو معیار تحویل بیاریم: منبع قابل بررسی، وضعیت تأیید روشن و مسئول رسیدگی به خطا.»
سه الگوی ادارهٔ دستیار را چگونه مقایسه کنیم؟
انتخاب الگو، به هدف کسب‌وکار، ریسک، الزامات و بلوغ سازمان وابسته است.
پس از انتخاب قابلیت‌ها، باید دربارهٔ شیوهٔ هماهنگی منابع و ادارهٔ خدمت تصمیم بگیریم. سه الگو را برای دستیار سازمانی مقایسه می‌کنیم. برای مدیر، تفاوت اصلی در محل کنترل، مسئولیت مشترک و نیاز به هماهنگی است.
الگو
منطق استفاده
نیاز مدیریتی و محدودیت
لایه‌ای
شروع با یک دستیار و دسترسی به منابع اطلاعاتی، با دامنهٔ محدود
شروع سریع‌تر و ساده‌تر؛ نیازمند روشن‌کردن اعتبار منابع، دسترسی و محدودیت کنترل جریان اطلاعات
متمرکز
هماهنگی منابع و خدمت‌ها از طریق یک درگاه مشترک سازمانی
کنترل هماهنگ‌تر و ارتباط با سامانه‌های سازمان؛ نیازمند تیم و مسئولیت روشن برای ادارهٔ خدمت مشترک
فدراتیو
هماهنگی دستیارها و منابع واحدهای تخصصی در چارچوب سیاست‌های مشترک
حفظ مسئولیت و کنترل محلی همراه با هماهنگی سازمانی؛ نیازمند بلوغ، همکاری و هزینهٔ ادارهٔ بیشتر
در الگوی لایه‌ای، تأکید بر شروع سریع و کاربردهای عمومی‌تر است. اگر سازمان بخواهد از آن در موضوع حساس یا برای اقدام استفاده کند، باید دوباره بسنجد آیا کنترل‌های موجود پاسخ‌گوی نیاز تازه هستند.
در الگوی متمرکز، سازمان یک نقطهٔ مشترک برای هماهنگی استفاده، منابع و خدمت‌ها دارد. باید مشخص باشد چه کسی آن را اداره می‌کند، تغییرات واحدها چگونه پذیرفته می‌شود و دسترسی و سوابق کاربران چگونه مدیریت می‌شوند.
در الگوی فدراتیو، واحدهای تخصصی منابع و دستیارهای خود را دارند و در چارچوب مشترکی هماهنگ می‌شوند. این استقلال به توافق دربارهٔ مسئولیت محتوا، قواعد دسترسی، رسیدگی به تعارض و ارجاع میان واحدها نیاز دارد.
سطح کنترل هر الگو، به امکانات و مسئولیت‌های آن وابسته است. در انتخاب واقعی باید ببینیم آن‌ها چگونه اجرا می‌شوند. نام یک الگو، به‌تنهایی شاهد رعایت سیاست‌ها یا حفظ محرمانگی نیست.
برای پروندهٔ ما، مقایسه باید از نیازهای ثبت‌شده شروع شود: چه کسی منبع معتبر را تعیین می‌کند، دسترسی را چه کسی کنترل می‌کند، پاسخ متعارض کجا ارجاع می‌شود و حدود اختیار چگونه اجرا می‌شوند؟ از هر گزینه، شواهد و توضیح متناسب با همین پرسش‌ها می‌خواهیم.
یک درگاه، با مسئولیت‌های روشن
مدیر منابع انسانی گفت: «ممکنه کاربر یک دستیار ببینه، ولی اعتبار محتوای منابع انسانی همچنان با ما باشه.»
مدیر مالی گفت: «برای مقررات خرید هم همین‌طور. باید معلوم باشه چه چیزی رو تأیید کردیم.»
مدیر فناوری گفت: «پس در مقایسهٔ گزینه‌ها، ادارهٔ منابع هر حوزه و هماهنگی بین اون‌ها رو جدا بررسی می‌کنیم.»
مدیر عملیات پرسید: «اگر یک سؤال به دو واحد مربوط باشه چی؟»
مدیرعامل گفت: «باید مسیر رسیدگی مشترک داشته باشیم. نباید دستیار خودش اختلاف دو واحد رو تعیین تکلیف کنه.»
مسئول ریسک و انطباق به فهرست منابع نگاه کرد: «یک پرسش دیگه هم داریم. اگر منابع واحدها در دسترس دستیار باشن، از کجا مطمئن می‌شیم هر کاربر فقط اطلاعاتی رو می‌بینه که مجازه؟»
مدیرعامل گفت: «این رو قبل از گسترش استفاده روشن کنیم. هماهنگ‌شدن منابع، قرار نیست مرز دسترسی افراد رو برداره.»
با این درس، بحث مدیریتی بخش چهارم به انتخاب قابلیت، ریسک و شیوهٔ ادارهٔ دستیار رسید. در درس یازدهم، از اسلاید ۸۵ وارد بخش پنجم، «امنیت، مسئولیت و نظارت انسانی»، می‌شویم: چگونه حدودی که تصویب کرده‌ایم، در استفادهٔ واقعی حفظ و قابل بررسی شوند؟
درس یازدهم؛ امنیت در کل مسیر خدمت، پایش رفتار و کنترل مجوز پیش از خواندن منبع و اجرای اقدام.
مطالعهٔ درس: امنیت دستیار را کجا و چگونه کنترل کنیم؟
فایلی که نباید خوانده می‌شد
برای پاسخ به پرسش پایان جلسهٔ قبل، مدیر فناوری یک آزمون دسترسی آماده کرده بود. چند سند نمونه را در محیط آزمایشی گذاشته بودند؛ بعضی عمومی و بعضی مخصوص یک گروه محدود.
با حسابی که نقش کارمند عادی داشت، از دستیار دربارهٔ مقررات پرداخت پرسید.
پاسخ سریع آمد. چند سطر توضیح، یک عدد و ارجاع به سندی که روی آن نوشته بودند: «مخصوص گروه مجاز».
مدیر منابع انسانی به نمایشگر نزدیک شد: «این حساب نباید اون فایل رو ببینه.»
مدیر فناوری گفت: «باید بررسی کنیم سند از چه مسیری وارد پاسخ شده.»
مدیر عملیات به صفحهٔ وضعیت خدمت نگاه کرد: «ولی همه‌چیز عادیه. خطا هم نداده.»
مسئول ریسک و انطباق گفت: «همین پاسخ، موضوع بررسی ماست. سامانه کار کرده، ولی باید می‌فهمیدیم آیا این کاربر اجازهٔ استفاده از اون منبع رو داشته یا نه.»
مدیرعامل پرسید: «می‌تونیم از دستیار بخوایم اطلاعات اون فایل رو در جواب نیاره؟»
مدیر فناوری مکث کرد. «قبل از اون باید روشن کنیم چرا اصلاً برای پاسخ به این کاربر، فایل رو خوانده.»
مدیرعامل پاسخ را کنار برگهٔ حدود اختیار گذاشت.
«پس کنترل رو باید در همون مسیری ببینیم که اطلاعات وارد پاسخ می‌شه. بعد از نمایش جواب، ممکنه دیر شده باشه.»
در درس دهم دیدیم هر قابلیت، خروجی و ارزیابی متناسب می‌خواهد و شیوهٔ ادارهٔ دستیار باید مسئولیت منابع و کنترل دسترسی را روشن کند. جلسه با پرسش دربارهٔ حفظ مرز دسترسی کاربران در میان منابع واحدها پایان یافت.
آزمون این جلسه همان پرسش را به یک مشاهده تبدیل کرده است: حساب کارمند عادی، از سند محدود پاسخ گرفته، درحالی‌که صفحهٔ وضعیت خدمت همه‌چیز را عادی نشان می‌دهد. برای ارزیابی امنیت، باید مسیر ورود اطلاعات به پاسخ و اجرای مجوز را ببینیم. اکنون، پس از عبور از بخش موسوم به «پرانتز فنی» دوره، وارد بخش پنجم، «امنیت، مسئولیت و نظارت انسانی»، می‌شویم.
این درس، اسلایدهای ۸۵ تا ۸۹ را به ترتیب دنبال می‌کند: دامنهٔ امنیت هوش مصنوعی، تهدیدهای آن، انحراف رفتار در یک خدمت ظاهراً سالم و کنترل مجوز پیش از خواندن منبع و پیش از اقدام.
امنیت، باید کل مسیر خدمت را پوشش دهد
داده، مدل، فرایند، زنجیرهٔ تأمین و رفتار سامانه باید در دامنهٔ بررسی امنیت باشند.
کنترل‌های شناخته‌شدهٔ هویت و دسترسی، شبکه، برنامه، داده و عملیات زیرساخت، نقطهٔ شروع بررسی امنیت‌اند. با ورود هوش مصنوعی، باید اجزای دیگری از خدمت را هم در ارزیابی ببینیم.
داده از منابع مختلف وارد می‌شود و ممکن است در چند مرحله استفاده شود. مدل و تنظیمات آن تغییر می‌کنند. سامانه ممکن است به اسناد، خدمات و ابزارهای سازمانی متصل باشد. بخشی از این اجزا نیز از تأمین‌کنندگان مختلف تهیه شده‌اند.
پرسش امنیت فقط دربارهٔ ورود به محیط دستیار نیست. باید بدانیم در ادامهٔ مسیر چه اتفاقی می‌افتد: چه منبعی استفاده می‌شود، چه کسی تغییر آن را تأیید می‌کند، چه اطلاعاتی در اختیار مدل قرار می‌گیرد و چه اقدامی می‌تواند انجام شود.
برای مدیر، این دامنهٔ گسترده باید به مسئولیت‌های روشن تبدیل شود. مسئول تأیید منبع کیست؟ تغییر مدل یا تنظیمات چه بررسی‌ای می‌خواهد؟ دسترسیِ ایجادشده برای یک خدمت، تا کجا مجاز است؟ چه کسی می‌تواند استفاده از یک جزء مسئله‌دار را متوقف کند؟
پاسخ این پرسش‌ها در مرز واحدها قرار می‌گیرد. صاحب محتوا، فناوری، امنیت، صاحب فرایند و تأمین‌کننده ممکن است هرکدام بخشی از کار را انجام دهند. لازم است ارتباط مسئولیت‌ها نیز روشن باشد؛ به‌ویژه در تغییرات و رسیدگی به رخداد.
مدیر فناوری گفت: «ورود با حساب کاربری درست انجام شده. حالا باید مسیر انتخاب سند رو بررسی کنیم.»
مدیر مالی پرسید: «طبقه‌بندی فایل رو چه کسی تعیین کرده بود؟»
مسئول ریسک و انطباق گفت: «هم تعریف طبقه‌بندی رو می‌خوایم، هم شاهد اینکه در زمان استفاده رعایت شده.»
مدیرعامل گفت: «این دو تا رو کنار هم بررسی کنیم. داشتن سیاست و اجراشدن اون، هر دو باید روشن باشه.»
تهدیدها، مسئولیت بررسی متفاوتی ایجاد می‌کنند
سیاست، کنترل دسترسی، پایش، اعتبارسنجی و حفاظت از اجزا باید در کنار هم قرار بگیرند.
شش گروه تهدید را بررسی می‌کنیم. هدف مدیریتی از شناخت آن‌ها این است که بدانیم چه چیزی ممکن است آسیب ببیند و از چه کسی چه شواهدی بخواهیم.
موضوع تهدید
چه اتفاقی محل نگرانی است؟
پرسش مدیریتی
مسمومیت داده‌ها
دادهٔ دستکاری‌شده بر رفتار سامانه اثر بگذارد.
ورود و تأیید منابع چگونه کنترل می‌شود؟
وارونگی مدل
از رفتار مدل، اطلاعاتی دربارهٔ داده‌های آن استنباط شود.
افشای احتمالی اطلاعات حساس چگونه ارزیابی می‌شود؟
سرقت مدل
اجزای مدل یا قابلیت آن به‌صورت غیرمجاز برداشت یا بازسازی شود.
دسترسی به دارایی‌های مدل و استفاده از آن چگونه حفاظت و بررسی می‌شود؟
نمونه‌های خصمانه
ورودیِ هدفمند، رفتار سامانه را منحرف کند.
رفتار در ورودی‌های نامعمول یا گمراه‌کننده چگونه آزموده می‌شود؟
به‌روزرسانی‌های مسموم
تغییر یک جزء، رفتار آسیب‌زا وارد خدمت کند.
منبع تغییر، تأیید انتشار و امکان بازگشت چگونه روشن است؟
نشت اطلاعات
اطلاعات به فرد یا مقصد نامجاز برسد.
مجوز خواندن، استفاده و انتقال اطلاعات کجا اعمال می‌شود؟
برای مقابله با این تهدیدها، مجموعه‌ای از کنترل‌ها در کنار هم قرار می‌گیرند: سیاست و حکمرانی، هویت و دسترسی، پایش و کشف تهدید، حفاظت از مدل و داده، اعتبارسنجی تغییرات و تاب‌آوری خدمت.
برای نمونه، بررسی امنیت در زمان تحویل اولیه باید با بررسی تغییرات بعدی همراه شود. سند تازه، مدل تازه یا گسترش یک دسترسی می‌تواند وضعیت خدمت را تغییر دهد.
همچنین، نباید هر پاسخ نامناسب را پیش از بررسی علت، به یک منشأ مشخص نسبت داد. ممکن است در محتوا، مجوز، تغییرات یا نحوهٔ استفاده مسئله‌ای وجود داشته باشد. رسیدگی باید با شواهد مسیر همان درخواست انجام شود.
مدیر عملیات پرسید: «پس این مورد حتماً حمله بوده؟»
مسئول ریسک و انطباق گفت: «هنوز علت رو نمی‌دونیم. باید مشخص بشه مجوز چطور تعریف و چطور اعمال شده.»
مدیر فناوری گفت: «نسخهٔ منابع و تنظیمات این آزمون رو هم بررسی می‌کنیم. باید بتونیم همون وضعیت رو دوباره ببینیم.»
مدیرعامل گفت: «در گزارش، چیزی رو که دیدیم از چیزی که هنوز باید اثبات بشه جدا بنویسیم.»
سامانه می‌تواند روشن باشد و رفتار نامناسب داشته باشد
دسترس‌پذیری و سرعت، همهٔ ابعاد سلامت خدمت را نشان نمی‌دهند.
خدمت می‌تواند در دسترس باشد، سریع پاسخ بدهد، ورود کاربران عادی به نظر برسد و هشدار بحرانی هم نداشته باشد؛ درحالی‌که به دادهٔ آلوده یا قدیمی، متن و زمینهٔ دستکاری‌شده یا سند نامعتبر تکیه می‌کند و پاسخ نامجاز یا تصمیم منحرف می‌سازد.
این تفکیک، دامنهٔ پایش را تغییر می‌دهد. دسترس‌پذیری مهم است؛ در کنار آن باید بدانیم سامانه به چه اطلاعاتی تکیه کرده و آیا در حدود مجاز رفتار کرده است.
برای نمونه، یک متن واردشده از سند یا منبع بیرونی ممکن است حاوی دستورهایی باشد که رفتار دستیار را از وظیفهٔ اصلی منحرف کنند. خواندن یک منبع نباید به آن منبع اختیار تعیین سیاست دسترسی یا تغییر حدود کار را بدهد. راهنمای OWASP نیز به امکان انحراف رفتار از طریق محتوای منابع بیرونی توجه می‌دهد.
برای مدیر، نتیجهٔ عملی این است که گزارش خدمت باید فراتر از تعداد پاسخ و زمان انتظار باشد. باید بتوان موارد مهم را بررسی کرد: کدام منبع استفاده شده، تصمیم مجوز چه بوده، چه تغییری در خدمت رخ داده و چه بازخوردی دربارهٔ رفتار آن ثبت شده است.
در پروندهٔ ما، همین آزمون دسترسی بخشی از شواهد پذیرش است. باید با نقشهای متفاوت بررسی کنیم چه چیزی قابل مشاهده است، چه چیزی باید مسدود شود و آیا نتیجه با سیاست مصوب سازگار است. دیدن چند پاسخ درست با یک حساب پر‌دسترسی، رعایت محدودیت کاربران دیگر را ثابت نمی‌کند.
مدیر عملیات دوباره به صفحهٔ وضعیت نگاه کرد: «این گزارش فقط می‌گه خدمت در دسترس بوده.»
مدیر فناوری گفت: «برای این مسئله، باید گزارش مجوز و منابع استفاده‌شده رو هم ببینیم.»
مدیر منابع انسانی گفت: «و آزمون رو با نقشهای مختلف انجام بدیم. دسترسی کارشناس منابع انسانی با کارمند عادی یکی نیست.»
مدیرعامل گفت: «پس از گزارش سلامت، انتظار روشن داشته باشیم. باید معلوم بشه هر شاخص، چه چیزی رو نشان می‌ده.»
دو نقطهٔ کنترل: پیش از خواندن منبع و پیش از اقدام
مجوز باید پیش از دسترسی به سند و پیش از اجرای اقدام بررسی شود.
دو نقطهٔ تعیین‌کننده برای اعمال کنترل داریم. این دو نقطه، همان حدودی را به اجرا وصل می‌کنند که در درس‌های قبل درباره‌شان تصمیم گرفتیم.
نقطهٔ نخست، پیش از خواندن منبع است. هویت کاربر، طبقه‌بندی اطلاعات، هدف استفاده و سیاست دسترسی باید تعیین کنند چه سندی برای پاسخ به این درخواست مجاز است.
اگر کاربر مجاز به دیدن یک سند نیست، محتوای آن نباید برای پاسخ به همان کاربر در اختیار مدل قرار بگیرد. سپردن اطلاعات به مدل و سپس انتظارِ پنهان‌کردن آن در پاسخ، کنترل دسترسی پیش از خواندن منبع را جایگزین نمی‌کند.
همچنین، ورود موفق کاربر به سامانه به معنای دسترسی به همهٔ منابع متصل نیست. مجوز باید با هویت و دامنهٔ مجاز همان کاربر در همان درخواست تطبیق داده شود.
نقطهٔ دوم، پیش از اقدام است. اگر دستیار به ابزاری برای ارسال، ثبت، تغییر، ارجاع یا اجرای کار متصل باشد، مجوز آن عملیات نیز باید بررسی شود. اجازهٔ خواندن یک سند، اختیار اجرای همهٔ اقدام‌های مربوط به آن را ایجاد نمی‌کند.
در این نقطه، حد اختیار، تأیید انسانیِ لازم و ثبت رویداد اهمیت دارند. در نسخهٔ فعلی پروندهٔ ما، رد خودکار درخواست خرید تصویب نشده است؛ بنابراین پیشنهاد یا متن تولیدشده نباید راهی برای اجرای همان اقدام خارج از دامنهٔ مصوب ایجاد کند.
اجرای مجوز باید در سازوکار کنترل دسترسیِ سامانه و خدمات متصل اعمال شود. خودِ پاسخ مدل یا ادعای کاربر دربارهٔ سمتش، شاهد کافی برای اجازهٔ اقدام نیست. راهنمای OWASP نیز بر اجرای عملیات در محدودهٔ مجوز همان کاربر و با کمترین دسترسی لازم تأکید دارد.
چهار اصل را کنار هم قرار می‌دهیم: اختیار متناسب با نقش، ثبت و ممیزی، کنترل در لحظهٔ اجرا و کمترین سطح دسترسی. این‌ها مبنای پرسش از تیم اجرا و تأمین‌کننده‌اند: نشان دهید محدودیت کجا اعمال می‌شود و با چه آزمونی می‌توان رعایت آن را دید.
برای پاسخ‌گویی نیز باید کارها به هم وصل باشند. صاحب محتوا و فرایند، حدود استفاده را مشخص می‌کنند؛ مسئولان اجرای کنترل، رعایت آن را در خدمت فراهم و بررسی می‌کنند؛ مرجع پذیرش، شواهد را می‌سنجد. این مسئولیت‌ها کلاه‌اند و می‌توانند میان افراد توزیع یا در یک نفر جمع شوند، اما مسیر تصمیم و رسیدگی باید روشن بماند.
کنترل، پیش از آنکه دیر شود
مدیرعامل به پاسخ آغاز جلسه برگشت: «پس برای این حساب، فایل محدود نباید وارد مسیر پاسخ می‌شد.»
مدیر فناوری گفت: «بله. باید همان‌جا مجوز بررسی و دسترسی نامجاز متوقف می‌شد.»
مسئول ریسک و انطباق گفت: «پیش از اجرای اون کار هم باید مجوز و حدود اختیار بررسی بشه. تصویب یک قابلیت، مجوز همهٔ اقدام‌ها نیست.»
مدیرعامل گفت: «تا نتیجهٔ این آزمون روشن و کنترل اصلاح نشده، دامنهٔ استفاده رو گسترش نمی‌دیم.»
بعد به برگه‌های سیاست و گزارش نگاه کرد: «حالا باید مطمئن بشیم این فقط یک اصلاح موردی نمی‌مونه. با کاربر تازه، سند تازه و تغییر نسخه، چطور دوباره رعایتش رو می‌سنجیم؟»
جلسه به پرسش بعدی رسیده بود: چگونه کنترل‌ها از پیگیری موردی افراد، به روشی مستند و قابل تکرار تبدیل شوند؟
در درس دوازدهم، از اسلاید ۹۰ ادامه می‌دهیم و مدل بلوغ حکمرانی را بررسی می‌کنیم. موضوع این است که سازمان چگونه سیاست، مجوزدهی، ارزیابی و پایش را در طول تغییرات، قابل تکرار و قابل پیگیری نگه می‌دارد.
درس دوازدهم؛ مسیر نسخه‌گذاری، ارزیابی، انتشار کنترل‌شده و حفاظت از داده چگونه اجرای تصمیم‌های حکمرانی را پشتیبانی می‌کند؟ صورت‌بندی سطوح این درس به بلوغ مهندسی و کنترل مربوط است و همهٔ ابعاد بلوغ حکمرانی سازمان را پوشش نمی‌دهد.
مطالعهٔ درس: بلوغ مهندسی و کنترل در پشتیبانی از حکمرانی
اگر مسئول اصلاح در دسترس نباشد
مدیر فناوری، مسیر پیشنهادی اصلاحِ دسترسی را توضیح داد. آزمون حساب کارمند عادی باید دوباره اجرا می‌شد و نتیجهٔ آن پیش از گسترش استفاده بررسی می‌شد.
مدیرعامل پرسید: «اگر هفتهٔ بعد سند تازه‌ای اضافه شد، همین آزمون دوباره انجام می‌شه؟»
«باید انجام بشه.»
«چه چیزی باعث می‌شه فراموش نشه؟»
مدیر فناوری به یادداشتش نگاه کرد. «فعلاً همکار مسئول، تغییر رو بررسی و آزمون رو اجرا می‌کنه.»
مدیر مالی پرسید: «اگر در دسترس نبود، بقیه می‌دونن دقیقاً چه چیزی عوض شده و چه آزمونی لازمه؟»
مدیر عملیات گفت: «برای بعضی تغییرها، هنوز باید از همون کسی بپرسیم که انجامش داده.»
مسئول ریسک و انطباق پرسید: «برای بررسی هم لازم می‌شه دوباره به همهٔ اسناد دسترسی کامل بدیم؟»
چند لحظه سکوت شد. روی کاغذ، حدود دسترسی کاربران روشن‌تر شده بود؛ اما ادارهٔ همان حدود هنوز به دانسته‌ها و دسترسی‌های چند نفر وابسته بود.
مدیرعامل گفت: «باید بتونیم مسیر کار و نتیجهٔ بررسی رو دنبال کنیم. بعد هم ببینیم کدوم کار واقعاً به دیدن دادهٔ محرمانه نیاز داره و کدوم رو می‌شه در یک فرایند کنترل‌شده انجام داد.»
در درس یازدهم دیدیم مجوز باید پیش از خواندن منبع و پیش از اقدام بررسی شود. آزمون حساب کارمند عادی نشان داد که دسترس‌پذیری خدمت، رعایت این مرزها را ثابت نمی‌کند.
اکنون مسیر اصلاح مشخص شده و پرسش‌های جلسه دربارهٔ سند تازه و غیبت مسئول آزمون، بحث را به حفظ کنترل در طول زمان رسانده‌اند. کنترل باید پس از تغییر منبع، مدل، تنظیمات یا تیم اجرا نیز برقرار بماند؛ با سوابق روشن، ارزیابی قابل تکرار و حدود دسترسی معلوم. این بار، موضوع بلوغی است که اجرای کنترل را از وابستگی به حافظه و حضور چند فرد دور می‌کند.
این درس، اسلایدهای ۹۰ تا ۹۶ را به ترتیب و با تکیه بر صورت‌بندی بخش ۳.۴ سند «معماری بدون اعتماد هوش مصنوعی» دنبال می‌کند. در این روایت، مسیر از بلوغ مهندسی و عملیات آغاز می‌شود و در سطح چهار به امکان اجرای فرایند بدون دسترسی مستقیم انسان به دادهٔ حساس می‌رسد. انسان، سیاست و فرایند را تعریف می‌کند و بر شواهد نظارت دارد.
بلوغ را در قابلیت کنترل ببینیم
سیاست، مجوزدهی، پایش و شواهد، مبنای پیشرفت کنترل‌ها هستند.
در سطوح بلوغ مهندسی و کنترل در این صورت‌بندی، از وضعیت موردی و واکنش پس از رخداد، به سیاست مستند، مرز اختیار روشن، مالکیت مشخص و نظارت مبتنی بر شواهد می‌رسیم.
برای تحقق این قابلیت‌ها، باید آماده‌سازی، ارزیابی و انتشار مدل نیز به بلوغ برسند؛ همان مسیر عملیاتی که سند ZTAI آن را از مهندسی هوش مصنوعی تا هوش مصنوعی بدون اعتماد صورت‌بندی می‌کند.
اگر بخواهید اجزای این مسیر مهندسی را دقیق‌تر دنبال کنید، MLOps؛ بستر پیاده‌سازی هوش مصنوعی بدون اعتماد رابطهٔ داده، کد، آزمایش، مدل و استقرار را در یک چرخهٔ قابل ردیابی توضیح می‌دهد.
باید میان داشتن یک عنوان و داشتن قابلیت واقعی تفاوت بگذاریم. اگر گفته‌ایم تغییرات کنترل می‌شوند، باید بتوانیم سابقهٔ تغییر، نتیجهٔ بررسی و نسخهٔ مستقر را نشان دهیم. اگر گفته‌ایم دسترسی محدود است، اجرای همین محدودیت باید قابل بررسی باشد.
عدد سطح، نتیجهٔ این شناخت است. برای برنامه‌ریزی، لازم است بدانیم اکنون چه کاری واقعاً انجام می‌شود، چه بخشی همچنان به پیگیری فردی وابسته است و گام بعدی چه قابلیتی به سازمان اضافه می‌کند.
مدیر عملیات پرسید: «یعنی الان باید برای خودمون یک سطح تعیین کنیم؟»
مدیرعامل گفت: «اول وضعیت واقعی رو بنویسیم. کجا سابقه داریم، کجا آزمون داریم و کجا فقط به تجربهٔ یک نفر تکیه می‌کنیم.»
مدیر فناوری گفت: «ممکنه بعضی بخش‌ها جلوتر باشن و بعضی هنوز دستی اداره بشن.»
مدیر مالی گفت: «همین برای تصمیم بعدی مفیده. معلوم می‌شه بودجه قراره کدوم فاصله رو برطرف کنه.»
سطوح صفر تا چهار در این درس، صورت‌بندی آموزشی مسیر مهندسی و کنترل در سند ZTAI هستند. این مسیر را نباید معیار کامل یا جهان‌شمول بلوغ حکمرانی دانست. سازمان ممکن است عملیات خودکار و قابل ردیابی داشته باشد، اما در انتخاب سرمایه‌گذاری، استقلال ارزیابی، پاسخ‌گویی یا رسیدگی به اعتراض ضعیف عمل کند. در مقابل، اجرای بخشی از فعالیت‌ها به‌صورت دستی، به‌تنهایی نشانهٔ ضعف حکمرانی نیست.
برای ارزیابی وضعیت سازمان، دست‌کم باید این ابعاد را جدا دید: حق تصمیم و پاسخ‌گویی؛ مدیریت ارزش و منابع؛ ارزیابی ریسک و آثار؛ استقلال نظارت و رسیدگی؛ و قابلیت مهندسی و کنترل. این درس عمدتاً بُعد آخر و ارتباط آن با سایر ابعاد را دنبال می‌کند.
هدف نیز رسیدن همهٔ سازمان‌ها به بیشترین خودکارسازی نیست. سطح مناسب کنترل و خودکارسازی باید با حساسیت کاربرد، منابع، هزینه و مسئولیت‌های سازمان تناسب داشته باشد.
سطح صفر: کار پیش می‌رود، اما به افراد وابسته است
در وضعیت دستی و فردمحور، بازتولید و بررسی مسیر کار دشوار است.
در سطح صفر، کارها پراکنده و عمدتاً دستی‌اند. مدل یا اصلاح آماده می‌شود و فردی آن را وارد خدمت می‌کند. ممکن است آزمایش‌هایی هم انجام شده باشد، اما مسیر و نتایج آن‌ها به‌درستی ثبت و نسخه‌گذاری نشده‌اند.
مسئله، توانایی یا تعهد افراد نیست. سازمان برای فهم آنچه انجام شده، به همان افراد وابسته است. اگر فایل‌ها یا روش کار تغییر کنند، بازسازی وضعیت قبلی دشوار می‌شود.
این وابستگی، در امنیت نیز اثر دارد. برای بررسی خطا ممکن است دوباره فایل‌ها جابه‌جا شوند، دسترسی‌های گسترده داده شود یا تغییر مستقیماً روی خدمت اعمال شود. معلوم نیست همهٔ این کارها چه سابقه و تأییدی دارند.
پرسش مدیر این است: اگر مسئول اصلی حضور نداشت، آیا سازمان می‌توانست همان نتیجه را بررسی یا همان نسخه را دوباره آماده کند؟
مدیر فناوری گفت: «برای بعضی تنظیمات، سابقهٔ کامل نداریم. باید از کسی که تغییر داده بپرسیم.»
مدیرعامل گفت: «پس همون‌ها رو مشخص کنیم. تجربهٔ همکار باید به دانشی تبدیل بشه که سازمان هم بتونه بهش رجوع کنه.»
سطح یک: اجزایی مدیریت می‌شوند، اما وابستگی اصلی باقی است
مدیریت اولیهٔ محیط و نسخه‌ها، اولین نظم را ایجاد می‌کند.
در سطح یک، بخشی از گردآوری و مدیریت کار منظم‌تر شده است. نسخه‌گذاری اولیه و آزمون‌های پایه وارد می‌شوند، اما ادارهٔ مدل و ورود آن به خدمت هنوز به کار مستقیم افراد وابسته است.
در روایت سند، همین‌جا باید میان کنترل بخش نرم‌افزار و کنترل کیفیت مدل دقت کنیم. داشتن نظم در یک بخش، کامل‌بودن ارزیابی کل خدمت را اثبات نمی‌کند.
برای پروندهٔ دستیار، ممکن است نسخهٔ برنامه معلوم باشد، اما هنوز روشن نباشد آن نسخه با کدام مجموعهٔ منابع، تنظیمات و ارزیابی همراه بوده است. یا نتیجهٔ آزمون در جایی ذخیره شده باشد، بی‌آنکه به نسخهٔ مورد استفاده وصل شود.
گام مدیریتی این سطح، شناخت همین شکاف است: چه چیزی نسخه دارد و چه چیزی همچنان بیرون از سابقهٔ قابل رجوع قرار گرفته است؟
مدیر مالی پرسید: «پس اینکه برنامه نسخه داره، یعنی وضعیت کامل دستیار رو ثبت کردیم؟»
مدیر فناوری گفت: «باید منابع، تنظیمات و ارزیابی مربوط به همون نسخه رو هم مشخص کنیم.»
مدیرعامل کنار فهرست نوشت: «سابقهٔ کامل وضعیت خدمت.»
سطح دو: مسیر کار قابل تکرار و قابل ردیابی می‌شود
می‌توان ارتباط اجزای تولید و شواهد ارزیابی را دنبال کرد.
در سطح دو، مدیریت و خودکارسازی اولیه با ردیابی کامل‌تر همراه می‌شود. داده، روش پردازش، مدل، برنامه و آزمون‌ها نسخه دارند و نتیجهٔ ارزیابی در کنار آن‌ها نگهداری می‌شود.
اکنون می‌توان پرسید یک خروجی بر اساس کدام وضعیت تولید شده و برای بررسی دوباره به چه اجزایی نیاز داریم. این قابلیت، بررسی تغییرات و مقایسهٔ نسخه‌ها را قابل اتکاتر می‌کند.
با این حال، در روایت سند، انتشار هنوز دستی است و ارتباط میان کیفیت اجزای بررسی‌شده و کیفیت خدمت مستقر کامل نشده است. باید مطمئن شویم همان وضعیتِ بررسی‌شده به محیط استفاده رسیده و تنظیمات یا دسترسی‌ها در این فاصله تغییر نکرده‌اند.
در لایهٔ زیرساخت، فاصلهٔ میان وضعیت پذیرفته‌شده و وضعیت جاری را در ثباتی که قابل اثبات و بازگشت نیست، امنیت نیست بررسی کرده‌ام؛ از رانش پیکربندی تا اثبات وضعیت و بازگشت به نسخهٔ معتبر.
برای مدیر، دستاورد این سطح قابلیت رجوع به شواهد است؛ و پرسش بعدی، کنترل مسیر رسیدن همان نسخه به خدمت واقعی است.
مسئول ریسک و انطباق پرسید: «می‌تونیم نشان بدیم نسخه‌ای که آزمون دسترسی رو گذرونده، همون نسخه‌ایه که کاربران استفاده می‌کنن؟»
مدیر فناوری گفت: «باید ارتباط نتیجهٔ آزمون با وضعیت مستقر رو هم ثبت و کنترل کنیم.»
مدیرعامل گفت: «پس گزارش آزمون و تحویل نسخه باید به هم وصل باشن.»
سطح سه: انتشار کنترل می‌شود؛ بازخورد هنوز حلقه را کامل نکرده است
ارزیابی و انتشار به مسیر مشخص و قابل نظارت وصل می‌شوند.
در سطح سه، همکاری تیم‌ها و کنترل ورود نسخه به خدمت منظم‌تر می‌شود. ارزیابی، تأیید و انتشار در یک مسیر مشخص قرار می‌گیرند و بخش بیشتری از اجرا خودکار می‌شود.
نتیجهٔ مدیریتی، کاهش وابستگی به اجرای دستی و موردی افراد است. باید معلوم باشد چه نسخه‌ای، با چه نتیجهٔ بررسی و از چه مسیری منتشر شده است.
در ZTAI، این سطح دروازهٔ ورود به هوش مصنوعی بدون اعتماد نامیده شده است. قابلیت مهندسی لازم در حال شکل‌گرفتن است، اما هنوز امکان دسترسی مستقیم به داده و مداخلهٔ فردی باقی است.
همچنین، مسیر می‌تواند یک‌طرفه بماند: نسخه بررسی و منتشر شود، اما آنچه در استفادهٔ واقعی رخ می‌دهد به‌طور منظم در اصلاح نسخهٔ بعد اثر نگذارد. بهترشدن نتیجهٔ آزمون هم لزوماً بهبود تجربهٔ واقعی کاربر را نشان نمی‌دهد.
پس مدیر باید از ارتباط انتشار با ارزیابی، و سپس از نحوهٔ استفاده از بازخورد واقعی بپرسد.
مدیر عملیات گفت: «اگر نسخهٔ تازه همهٔ آزمون‌ها رو گذروند، ولی کاربران باز هم در ارجاع درخواست مشکل داشتن چی؟»
مدیر فناوری گفت: «باید این بازخورد وارد ارزیابی و اصلاح بعدی بشه.»
مدیرعامل گفت: «و معلوم باشه چه کسی تصمیم می‌گیره معیارها نیاز به بازنگری دارن.»
سطح چهار: اجرای خودکار، با تغییر نقش انسان
محدودکردن دسترسی مستقیم تیم توسعه به دادهٔ خام حساس، هدف یک طراحی متناسب با نیاز محرمانگی است. این هدف، تعریف عمومی Zero Trust یا شرط لازم بلوغ همهٔ کاربردهای هوش مصنوعی نیست. در معماری Zero Trust، اصل بر نبود اعتماد ضمنی و اعمال احراز هویت و مجوز متناسب با دسترسی است. ضرورت و شیوهٔ جداسازی داده باید برای همان کاربرد طراحی و ارزیابی شود.
انسان، تعریف‌کننده و ناظر فرایند است و اجرای تکرارشونده در مسیر کنترل‌شده انجام می‌شود.
در سطح چهار، حلقهٔ استفاده و اصلاح به هم وصل می‌شود. پایش و بازخورد می‌توانند نیاز به تغییر را آشکار کنند؛ آماده‌سازی، ارزیابی و انتشار نیز در مسیر قابل ردیابی و کنترل‌شده انجام می‌شوند.
در صورت‌بندی ZTAI، خودکارسازی کامل، امکان تغییر نقش انسان و سلب دسترسی مستقیم او به بخش‌های داده‌محور را فراهم می‌کند. متخصص، روش و فرایند را تعریف می‌کند؛ اجرای روزمره می‌تواند بدون مراجعهٔ مستقیم او به دادهٔ خام حساس انجام شود.
در این برداشت، انسان همچنان مسئول هدف، سیاست، معیار پذیرش، حدود اختیار و رسیدگی به استثناهاست. وظیفهٔ نظارت نیز با مشاهدهٔ شواهد مجاز و ارزیابی رفتار خدمت ادامه پیدا می‌کند.
برای پروندهٔ ما، این پرسش مطرح می‌شود: آیا تیم فنی می‌تواند سازوکار دستیار را توسعه و ارزیابی کند، بدون آنکه برای هر تغییر به همهٔ پرونده‌های محرمانهٔ کارکنان دسترسی بگیرد؟ آیا پردازش دادهٔ حساس می‌تواند در محیط مجاز انجام شود و نتیجهٔ بررسیِ متناسب در اختیار ناظر قرار گیرد؟
پاسخ عملی به نیازهای مهندس و ارزیاب، موضوع مهندسی داده و مدل بدون مشاهدهٔ دادهٔ محرمانه است: قرارداد داده، نمونهٔ ساختگی، بررسی کیفیت و عیب‌یابی درون مرز مجاز، ابزار ادامهٔ کار را فراهم می‌کنند.
این قابلیت باید طراحی و اثبات شود. خودکارشدن چند فعالیت، به‌تنهایی نشان نمی‌دهد دسترسی مستقیم انسان حذف شده یا مسیر کنترل‌شده قابل دورزدن نیست.
حدود خودکارسازیِ ادارهٔ خدمت را باید از اختیار تصمیم‌گیریِ دستیار جدا نگه داریم. خودکارشدن ارزیابی و انتشار، مجوز رد خودکار درخواست خرید ایجاد نمی‌کند. حدود استفادهٔ کسب‌وکار همچنان همان چیزی است که جداگانه تصویب کرده‌ایم.
مدیر منابع انسانی پرسید: «یعنی می‌تونیم توسعهٔ دستیار رو ادامه بدیم، بدون اینکه هر بار پرونده‌های واقعی کارکنان رو در اختیار تیم توسعه بذاریم؟»
مدیر فناوری گفت: «اگر مسیر توسعه، اجرای پردازش و ارزیابی رو برای همین هدف طراحی کنیم.»
مدیرعامل گفت: «پس هدف سطح چهار رو دقیق بنویسیم: تیم، فرایند رو تعریف و بررسی می‌کنه؛ دسترسی مستقیم به دادهٔ حساس باید بر اساس نیاز واقعی محدود بشه.»
مسئول ریسک و انطباق گفت: «و باید شواهدی داشته باشیم که این تفکیک در عمل هم برقرار مونده.»
محیط حساس: پردازش داده را از دسترسی تیم توسعه جدا کنیم
تفکیک محیط‌ها، صورت عملی محدودکردن دسترسی مستقیم به دادهٔ حساس را نشان می‌دهد.
در محیط حساس، این تفکیک به شیوهٔ کار تیم توسعه و محل پردازش داده مربوط می‌شود. تیم توسعه می‌تواند با داده‌های عمومی یا نمونه‌های مجاز کار کند. پردازش اصلیِ دادهٔ محرمانه در محیط جداشده و کنترل‌شده انجام می‌شود و خروجیِ مجاز از مسیر تعیین‌شده به بهره‌برداری می‌رسد.
سند، چهار مرز را برای این تفکیک مطرح می‌کند:
مرحله
نقش انسان
انتظار از مسیر اجرا
آماده‌سازی داده
تعریف قواعد ورود و آماده‌سازی
پردازش دادهٔ حساس در محدودهٔ مجاز و با دسترسی کنترل‌شده
آموزش مدل
تعریف روش و تنظیمات فرایند
اجرای فرایند در محیط امن، بدون نیاز به مشاهدهٔ مستقیم دادهٔ محرمانه توسط تیم توسعه
ارزیابی و اعتبارسنجی
تعیین معیارها و نظارت بر نتیجه
بررسی نسخه و ارائهٔ شواهد مجاز برای پذیرش یا رد
استقرار
تعیین شرایط انتشار و مقصد مجاز
انتقال فقط از مسیر تأییدشده و با سابقهٔ قابل پیگیری
برای مدیر، موضوع اصلی این است که اختیار طراحی و ادارهٔ فرایند چگونه از مشاهدهٔ مستقیم داده جدا می‌شود. این تفکیک باید دسترسی تیم توسعه و مدیر سامانه، مسیر تغییر، گزارش‌ها و خروج نتیجه را نیز پوشش دهد.
مسیرهای دسترسی از راه تغییر کد، گزارش خطا، خروج مدل یا مدیریت زیرساخت را در وقتی انسان داده را نمی‌بیند؛ آیا واقعاً دسترسی او حذف شده است؟ بررسی کرده‌ام. آن نوشته کمک می‌کند این تفکیک را در برابر دسترسی غیرمستقیم هم بسنجیم.
پذیرش این طرح به شواهد نیاز دارد: چه کسی چه چیزی را می‌تواند ببیند یا تغییر دهد؟ ورودی و خروجی چگونه کنترل می‌شوند؟ تغییر تأییدنشده چگونه متوقف می‌شود؟ در خرابی یا رسیدگی به خطا، همان مرزها چگونه حفظ می‌شوند؟
در این روایت، حرکت از سطح صفر تا چهار، توان مهندسی و کنترل سازمان را برای چنین هدفی می‌سازد. برنامهٔ پیشرفت باید با وضعیت واقعی، حساسیت داده و منابع سازمان متناسب باشد؛ هر گام نیز باید قابلیت قابل بررسی‌ای به خدمت اضافه کند.
برنامهٔ پیشرفت، با شواهد مشخص
مدیر مالی پرسید: «پس برای ادامهٔ کار، از کجا شروع کنیم؟»
مدیر فناوری گفت: «اول وضعیت نسخه‌ها، منابع، آزمون‌ها و انتشار رو کامل ثبت کنیم. بعد، مسیر ارزیابی و انتشار رو به هم وصل کنیم و برای جداسازی دادهٔ حساس برنامه بدیم.»
مدیر منابع انسانی گفت: «ما هم باید معلوم کنیم کدوم داده و کدوم خروجی برای چه نقشی مجازه.»
مدیرعامل گفت: «برای هر گام، مسئول، نتیجه و شاهد پذیرش می‌خوایم. سطح بلوغ رو از روی همین قابلیت‌ها می‌سنجیم.»
مسئول ریسک و انطباق پرسید: «وقتی انسان بیشتر ناظر فرایند شد، چه اطلاعات و چه اختیاری برای مداخله خواهد داشت؟»
مدیرعامل به گزارش‌های روی میز نگاه کرد: «همین رو هم باید روشن کنیم. ناظر باید بتونه مسئله رو بفهمه و به‌موقع تصمیم بگیره.»
در درس سیزدهم، از اسلاید ۹۷ ادامه می‌دهیم: نظارت انسانی چگونه با اثر و اختیار سامانه متناسب می‌شود و برای مداخلهٔ واقعی به چه اطلاعات، فرصت و مسئولیتی نیاز دارد؟
صورت‌بندی سطوح با تکیه بر بخش ۳.۴ سند «معماری بدون اعتماد هوش مصنوعی»، شناسهٔ PPD-ZTAI-GEN-002، نسخهٔ ۳، تنظیم شده است. شرح تفصیلی این روایت در مدل بلوغ هوش مصنوعی بدون اعتماد آمده است.
درس سیزدهم؛ شرایط نظارت انسانی، حق توقف و پاسخ‌گویی؛ از رسیدگی به رخداد تا بازگشت خدمت.
مطالعهٔ درس: ناظر انسانی چه زمانی واقعاً می‌تواند مداخله کند؟
گزارشی که بعد از اقدام می‌رسد
مدیرعامل به پرسش پایان بحث بلوغ برگشت: «ناظر چه چیزی رو می‌بینه و چه وقت می‌تونه مداخله کنه؟»
مدیر فناوری گفت: «می‌تونیم گزارش عملکرد و هشدار موارد غیرعادی رو در اختیارش بذاریم.»
مدیر مالی پرسید: «قبل از اینکه اتفاقی بیفته یا بعدش؟»
«بستگی به نوع استفاده داره.»
مدیر عملیات گفت: «اگر قرار باشه هر پاسخ منتظر تأیید بمونه، کار کند می‌شه.»
مسئول ریسک و انطباق گفت: «برای همهٔ کارها یک روش نمی‌خوایم. ولی اگر در یک کار حساس، هشدار بعد از اقدام برسه، باید معلوم باشه اون ناظر دقیقاً چه چیزی رو می‌تونه متوقف یا اصلاح کنه.»
مدیر منابع انسانی پرسید: «و اگر مسئله مربوط به پروندهٔ یک کارمند باشه، ناظر باید چه اطلاعاتی رو ببینه؟ لازم نیست همهٔ داده‌ها در اختیارش باشه، ولی باید بتونه موضوع رو بفهمه.»
مدیرعامل زیر عنوان «نظارت انسانی» چند جای خالی گذاشت.
«اسم ناظر رو که بنویسیم، کار تموم نمی‌شه. باید زمان اطلاع، اطلاعات لازم، اختیار تصمیم و مسیر توقف رو هم مشخص کنیم.»
در درس دوازدهم دیدیم که در روایت ZTAI، بلوغ می‌تواند امکان حذف دسترسی مستقیم تیم فنی به دادهٔ حساس را فراهم کند؛ مسئولیت تعریف سیاست و نظارت انسانی همچنان باقی می‌ماند. در ادامهٔ همان جلسه، پرسش مدیر مالی بحث را از وجود گزارش به زمان رسیدن آن برد: اگر گزارش پس از اقدام برسد، ناظر چه فرصتی برای مداخله دارد؟ حالا باید روشن کنیم او چه اطلاعاتی می‌بیند، چه اختیاری دارد و چگونه می‌تواند بر نتیجه اثر بگذارد.
این درس، اسلایدهای ۹۷ تا ۱۰۱ را به ترتیب دنبال می‌کند و بخش پنجم دوره را به پایان می‌رساند: شکل‌های نظارت انسانی، منشأ خطا و پاسخ‌گویی، مسیر رسیدگی به رخداد، استفادهٔ خارج از چارچوب مصوب و پروندهٔ دسترسی نامجاز.
نظارت انسانی را متناسب با کار تعریف کنیم
زمان، اطلاعات، دانش، اختیار و امکان توقف، شرایط نظارت معنادارند.
حضور انسان در تصمیم و اجرا می‌تواند چهار شکل داشته باشد. انتخاب میان آن‌ها باید با اثر، اختیار و برگشت‌پذیری تصمیم متناسب باشد.
شیوهٔ حضور
نقش انسان
چه چیزی باید روشن باشد؟
انسان در حلقهٔ تصمیم
تصمیم را می‌گیرد یا نتیجه را پیش از اجرا تأیید می‌کند.
فرصت بررسی، اطلاعات کافی و امکان رد یا اصلاح
انسان ناظر حین اجرا
سامانه اقدام می‌کند و انسان رفتار آن را پایش می‌کند.
زمان دریافت هشدار و امکان مداخله پیش از گسترش پیامد
انسان حاکم بر سیاست و حدود
سیاست، محدودیت‌ها و حق توقف را تعیین می‌کند.
مرز اختیار سامانه و سازوکار بررسی رعایت آن
اجرای مستقل در دامنهٔ مصوب
انسان در هر اجرای روزمره وارد نمی‌شود؛ کار در حدود از پیش تعیین‌شده انجام می‌شود.
دامنهٔ مجاز، شواهد عملکرد و تکلیف خروج از شرایط مصوب
این‌ها انتخاب‌هایی برای کارهای متفاوت‌اند. ممکن است در یک دستیار، پاسخ به پرسش عمومی بدون تأیید موردی انجام شود، اما یک پیشنهاد اثرگذار بر وضعیت کارکنان به بررسی پیش از اقدام نیاز داشته باشد.
نظارت معنادار به پنج شرط وابسته است. زمان یعنی ناظر هنگامی مطلع شود که هنوز امکان اثرگذاری دارد. اطلاعات باید برای فهم موضوع کافی و در عین حال با دسترسی مجاز او متناسب باشد. دانش به توان تشخیص و ارزیابی مسئله مربوط است. اختیار باید اجازهٔ تصمیم و مداخله بدهد و امکان توقف نیز باید در عمل قابل استفاده باشد.
اگر از فردی انتظار تأیید داریم، باید بار بررسی او را هم بشناسیم. انبوه درخواست‌ها، اطلاعات نامفهوم یا فرصت ناکافی می‌تواند تأیید را به کاری صوری تبدیل کند. این موضوع باید در طراحی فرایند و سنجش قابلیت بهره‌برداری دیده شود.
معنای فنی این مداخله را در «ZTAI برای عامل‌های خودکار؛ اختیار محدود در تمام مسیر اجرا» باز کرده‌ام: توقف پذیرش کار تازه، لغو مجوزها و رسیدگی به اثر اقدام‌های انجام‌شده، هر کدام سازوکار خود را دارند. همان‌جا توضیح داده‌ام چگونه ناظر می‌تواند شواهد لازم را ببیند، بدون آنکه همهٔ داده‌های حساس در اختیارش قرار گیرد.
مدیر مالی گفت: «اگر قرار باشه پیشنهاد دستیار رو تأیید کنم، باید دلیل و منبعش رو هم ببینم.»
مدیر منابع انسانی گفت: «و برای موارد مربوط به کارکنان، باید روشن باشه چه کسی صلاحیت بررسی داره.»
مدیر فناوری گفت: «پس برای هر نوع استفاده، زمان و نحوهٔ بررسی رو جدا ثبت می‌کنیم.»
مدیرعامل گفت: «همراه با کاری که ناظر می‌تونه انجام بده. فقط فرستادن گزارش، همهٔ نظارت نیست.»
منشأ خطا و مسئول پاسخ‌گویی را جدا بررسی کنیم
یافتن منشأ خطا، باید به تعیین مسئولیت بررسی، اصلاح و تصمیم متصل شود.
وقتی مشکلی رخ می‌دهد، ممکن است چند بخش در زنجیرهٔ آن نقش داشته باشند. برای یافتن منشأ، چهار حالت را از هم جدا کنیم:
منشأ احتمالی
نمونهٔ مطرح‌شده
پرسش بررسی
مدل
پاسخ غلط تولید شده است.
آیا خروجی با اطلاعات معتبر سازگار بوده و ارزیابی مرتبط انجام شده است؟
سامانه
سند نامعتبر بازیابی شده است.
انتخاب منبع و اعمال مجوز در مسیر پاسخ چگونه انجام شده است؟
استفاده
کاربر خارج از دامنهٔ مصوب استفاده کرده است.
دامنه چگونه به او اعلام شده و چه کنترل و آموزشی وجود داشته است؟
تصمیم
مدیر بر مبنای پاسخ نامعتبر تصمیم گرفته است.
چه شواهد و بررسی‌ای مبنای پذیرش و اقدام بوده است؟
این جدول، نقطهٔ شروع بررسی است. در هر رخداد باید با شواهد روشن کنیم چه اتفاقی افتاده است. ممکن است پاسخ غلط، هم به منبع نامعتبر مربوط باشد و هم به نارسایی ارزیابی یا نحوهٔ استفاده.
همچنین، منشأ خطا به‌تنهایی مسئولیت همهٔ مراحل رسیدگی را تعیین نمی‌کند. ممکن است اصلاح یک کنترل با مالک فنی باشد، اما تعیین دامنهٔ توقف، رسیدگی به اثر بر افراد و پذیرش بازگشت خدمت به مشارکت مسئولان دیگر نیاز داشته باشد.
حامی، مالک کسب‌وکار، مالک فنی و مالک ریسک باید ارتباط مسئولیت‌های خود را بشناسند. این‌ها همان کلاه‌ها هستند: یک نفر می‌تواند چند کلاه داشته باشد و چند نفر می‌توانند در یک مسئولیت همکاری کنند. مهم، روشن‌بودن مسیر پیگیری و اختیار تصمیم است.
مدیر عملیات پرسید: «اگر کاربر از پاسخ در جای نامناسب استفاده کرده باشه، رسیدگی با خودشه؟»
مسئول ریسک و انطباق گفت: «باید ببینیم دامنه رو چطور اعلام کردیم، چه آموزشی داده شده و چه محدودیتی در سامانه بوده.»
مدیر فناوری گفت: «و مستقل از اون، بررسی کنیم آیا منبع و پاسخ درست بوده‌اند.»
مدیرعامل گفت: «گزارش باید سهم هر بخش رو روشن کنه. نباید با پیدا کردن یک علت، بقیهٔ مسیر بررسی بسته بشه.»
مسیر رسیدگی را پیش از رخداد مشخص کنیم
صاحب کنترل، حق توقف، شواهد و مسئولیت بازگشت باید از پیش روشن باشند.
مسیر رسیدگی را می‌توان در هشت گام تعریف کرد:
کشف رخداد: گزارش کاربر، هشدار یا بررسی، موضوع را آشکار می‌کند.
محدودسازی و توقف: دامنهٔ استفاده یا دسترسیِ مسئله‌دار مهار می‌شود.
حفظ شواهد: اطلاعات لازم برای فهم رخداد، با رعایت حدود دسترسی نگهداری می‌شود.
بررسی فنی و کسب‌وکاری: علت، دامنه و پیامد در کنار هم بررسی می‌شوند.
اطلاع و رسیدگی به شکایت: افراد و مراجع مرتبط، در مسیر تعیین‌شده پاسخ می‌گیرند.
اصلاح: کنترل، فرایند یا جزء مسئله‌دار تغییر می‌کند.
بازاعتبارسنجی: شواهد نشان می‌دهند اصلاح، مسئله را برطرف کرده و استفادهٔ مجاز قابل پذیرش است.
بازگشت یا خروج: دربارهٔ ادامه، بازگشت محدود یا کنارگذاشتن خدمت تصمیم گرفته می‌شود.
برای اجرای این مسیر، اختیارها باید از قبل معلوم باشند. چه کسی می‌تواند یک قابلیت را متوقف کند؟ دامنهٔ توقف چگونه تعیین می‌شود؟ چه کسی نتیجهٔ بررسی را می‌پذیرد و چه شواهدی بازگشت را توجیه می‌کنند؟
در این تقسیم کار، مالک فنی مسئول کنترل‌ها، اصلاح و بازاعتبارسنجی است. مالک کسب‌وکار، موضوع را در ارتباط با تصمیم و اثر بر کار می‌بیند و در تأیید بازگشت یا خروج نقش دارد. مالک ریسک، سطح ریسک و کنترل‌های کاهنده را بررسی می‌کند و مسئول امنیت یا انطباق، هماهنگی و گزارش‌دهی مرتبط را دنبال می‌کند.
این تقسیم کار باید با ساختار واقعی سازمان تطبیق یابد. مهم آن است که میان «ایراد اصلاح شد» و «استفاده دوباره پذیرفته شد» مسیر روشنی وجود داشته باشد.
گزارش رخداد، دانشی از شکست‌های واقعی به سازمان می‌دهد که گزارش معمول عملکرد به‌تنهایی فراهم نمی‌کند. در «حکمرانی هوش مصنوعی در حال عبور از قانون‌نویسی» به نقش ثبت و گزارش رخداد در یادگیری از شکست‌ها و اصلاح آزمون‌ها و قواعد پرداخته‌ام.
مدیر فناوری گفت: «ممکنه اصلاح فنی رو سریع انجام بدیم.»
مدیر منابع انسانی پرسید: «ولی چه کسی بررسی می‌کنه چه اطلاعاتی دیده شده و فرد متأثر چه پاسخی باید بگیره؟»
مسئول ریسک و انطباق گفت: «این‌ها باید هم‌زمان در مسیر رسیدگی قرار بگیرن.»
مدیرعامل گفت: «بازگشت هم فقط با اعلام رفع ایراد انجام نشه. نتیجهٔ آزمون و نظر مسئولان مربوط باید روشن باشه.»
استفادهٔ کارکنان از ابزارها نیز بخشی از همین حکمرانی است
سیاست روشن، آموزش متناسب با نقش و کنترل اجرایی باید همراه باشند.
حکمرانی به دستیار رسمی سازمان محدود نمی‌شود. ممکن است کارکنان برای نوشتن، خلاصه‌کردن یا بررسی اطلاعات از ابزارهای دیگری استفاده کنند، بدون آنکه شرایط استفاده در سازمان روشن شده باشد.
برای صورت‌بندی سیاست، می‌توان از چنین ماتریسی شروع کرد:
نوع داده
ابزار عمومی
ابزار سازمانی
سامانهٔ داخلی
عمومی
مجاز
مجاز
مجاز
داخلی
مشروط
مجاز
مجاز
محرمانه
ممنوع
مشروط
مجاز
بسیار حساس
ممنوع
ممنوع
مشروط
این جدول، یک الگوی نمونه برای سیاست استفاده است. سازمان باید معنای دسته‌های داده، ابزارهای مورد تأیید و شروط استفاده را برای وضعیت خودش روشن کند. عنوان «سازمانی» یا «داخلی»، به‌تنهایی رعایت همهٔ شرایط امنیتی را ثابت نمی‌کند. مجازبودن استفاده نیز باید با نقش کاربر، هدف استفاده و کنترل‌های مربوط همراه باشد.
اجرای این سیاست به سه رکن وابسته است:
سیاست روشن باید بگوید چه داده‌ای، برای چه کاری و در کدام ابزار قابل استفاده است و مسئولیت‌ها چیست.
آموزش و سواد متناسب با نقش باید به کارکنان، مدیران و مسئولان کمک کند این سیاست را در موقعیت واقعی تشخیص دهند. توصیهٔ کلی «اطلاعات حساس وارد نکنید» وقتی مفید می‌شود که فرد بتواند حساسیت و حدود استفاده را بفهمد.
کنترل اجرایی و ثبت استفاده باید امکان اعمال محدودیت، پایش و رسیدگی را فراهم کند. در کنار آن، باید مسیر مجاز انجام کار نیز برای کارکنان قابل دسترس و قابل فهم باشد.
مدیر منابع انسانی گفت: «ممکنه کارمند برای خلاصه‌کردن یک متن، از ابزار عمومی استفاده کنه و ندونه متنش در کدوم دسته قرار می‌گیره.»
مدیر عملیات پرسید: «پس باید فقط اسم ابزارهای ممنوع رو اعلام کنیم؟»
مسئول ریسک و انطباق گفت: «باید نوع داده، کار مجاز و شروط استفاده رو هم روشن کنیم. آموزش و کنترلش هم همراهش باشه.»
مدیرعامل گفت: «و کسی که برای انجام کارش سؤال داره، بدونه از چه مسیری می‌تونه جواب و راه مجاز بگیره.»
پروندهٔ دسترسی نامجاز، آزمون کل مسیر است
رخداد، مسئولیت، حق توقف و تعهدات بهره‌برداری را هم‌زمان به آزمون می‌گذارد.
در پروندهٔ دستیار، کاربر به سندی دست یافته که مجاز به مشاهدهٔ آن نبوده است. اکنون باید هم مسئلهٔ کنترل را بررسی کرد، هم اثر بر فرد و هم شرایط ادامهٔ خدمت را.
در پرونده، مسئول امنیت بر قطع دسترسی و مهار دامنه تأکید می‌کند. منابع انسانی، حریم خصوصی و حقوق فرد متأثر را در اولویت می‌بیند. مالک فنی باید عیب کنترل را بررسی و اصلاح کند و مالک کسب‌وکار، پیامد توقف و ادامهٔ کار را مدیریت کند.
این مسئولیت‌ها باید به تصمیم‌های مشخص برسند: توقف یا محدودسازی متناسب، حفظ شواهد و بررسی دامنه، اصلاح کنترل، پاسخ به فرد و شکایت و بازاعتبارسنجی پیش از بازگشت.
در امتداد روایت درس‌های قبل، این رخداد آزمون آمادگی سازمان است. اگر همان مشکلی که در محیط آزمایش دیدیم در استفادهٔ واقعی رخ دهد، آیا می‌دانیم چه کسی، با چه اختیاری و در چه مسیری عمل می‌کند؟
از همین‌جا بحث به قرارداد می‌رسد. کنترل، مسئولیت و حق توقف باید در قرارداد، معیار پذیرش و تعهدات بهره‌برداری هم بازتاب روشن داشته باشند. لازم است معلوم باشد تأمین‌کننده برای بررسی، اصلاح، ارائهٔ شواهد و ادامه یا توقف خدمت چه تعهدی پذیرفته است.
برای تبدیل این تصمیم‌ها به تحویل‌دادنی و معیار پذیرش، در «قرارداد هوش مصنوعی؛ دقیقاً چه چیزی را باید تحویل بگیریم؟» مسیر ارجاع به انسان، شرایط مداخلهٔ بازبین و تعهدات دورهٔ بهره‌برداری را با جزئیات بیشتری توضیح داده‌ام؛ همان مواردی که اکنون باید وارد پوشهٔ قرارداد دستیار شوند.
از صورت‌جلسه تا تعهد بهره‌برداری
مسئول ریسک و انطباق کارت رخداد را پیش روی جمع گذاشت: «فرض کنیم همین دسترسی نامجاز، در استفادهٔ واقعی اتفاق افتاده. مسیر رسیدگی‌ای که نوشتیم، قابل اجراست؟»
مدیر فناوری گفت: «برای بررسی دامنه و اصلاح، بخشی از شواهد و دسترسی‌ها باید از طرف تأمین‌کننده فراهم بشه.»
مدیر مالی پرسید: «در پیشنهادش مشخص کرده چه چیزی و در چه زمانی تحویل می‌ده؟»
مدیر فناوری صفحهٔ پشتیبانی را باز کرد. توضیح کلی دربارهٔ رفع اشکال بود، اما جزئیات این مسیر در آن دیده نمی‌شد.
مدیرعامل گفت: «پس همین موارد رو به تعهد روشن تبدیل کنیم. حق توقف، همکاری در بررسی، شواهد پذیرش و شرایط بازگشت باید معلوم باشه.»
مدیر عملیات پرسید: «و از اول هم باید روشن کنیم دقیقاً چه چیزی رو تحویل می‌گیریم؛ مدل، یک سامانه یا خدمت قابل بهره‌برداری؟»
مدیرعامل پوشهٔ قرارداد را باز کرد.
«بحث بعدی رو از همین‌جا شروع کنیم.»
با این درس، بخش پنجم پایان می‌یابد. در درس چهاردهم، از اسلاید ۱۰۲ وارد بخش ششم، «قرارداد، پذیرش و بهره‌برداری»، می‌شویم و بررسی می‌کنیم تصمیم‌های حکمرانی چگونه به موضوع تحویل، معیار پذیرش و تعهدات روشن تبدیل می‌شوند.
درس چهاردهم؛ موضوع تحویل، تعهد قابل آزمون، دارایی‌های لازم برای ادامهٔ خدمت و محل آموزش مدل.
مطالعهٔ درس: در قرارداد هوش مصنوعی، دقیقاً چه چیزی تحویل می‌گیریم؟
چه چیزی را قرار است تحویل بگیریم؟
مدیرعامل پوشهٔ قرارداد را که در پایان بحث قبل باز کرده بود، به وسط میز کشید.
در صفحهٔ نخست نوشته بودند: «تحویل مدل اختصاصی دستیار هوشمند با دقت بالا». چند سطر پایین‌تر، از نصب سامانه و پشتیبانی خدمت صحبت شده بود.
مدیر مالی پرسید: «بالاخره موضوع تحویل کدومه؟ مدل، سامانه یا خدمت؟»
مدیر فناوری گفت: «برای استفادهٔ ما، این‌ها باید کنار هم کار کنن.»
«درسته. ولی اگر مدل تحویل بشه و دسترسی‌ها درست کار نکنن، تعهد انجام شده؟ اگر سامانه نصب بشه و بعد از مدتی خدمت قطع بشه چی؟»
مسئول ریسک و انطباق به یادداشت جلسهٔ قبل اشاره کرد: «همکاری در بررسی رخداد، ارائهٔ شواهد و شرایط توقف و بازگشت هم باید معلوم باشه.»
مدیر عملیات گفت: «از طرف ما هم انتظار کم‌شدن زمان رسیدگی مطرح شده. اون کجای توافقه؟»
مدیرعامل چهار واژه را روی برگه‌ای نوشت: «مدل، سامانه، خدمت، نتیجه».
گفت: «قبل از اینکه دربارهٔ مبلغ و زمان تحویل تصمیم بگیریم، روشن کنیم از هرکدوم چه چیزی می‌خوایم و چه کسی پاسخ‌گوی اون بخشه.»
در درس سیزدهم دیدیم که نظارت انسانی به فرصت و اختیار مداخله نیاز دارد و مسیر توقف، رسیدگی به رخداد و بازگشت خدمت باید از پیش روشن باشد. پایان همان جلسه، وابستگی بخشی از این مسیر به همکاری تأمین‌کننده، مدیرعامل را به سراغ پوشهٔ قرارداد برد. حالا پرسش مدیر مالی ابهام تازه‌ای را آشکار می‌کند: طرفین از «تحویل دستیار» چه برداشتی دارند و کدام مسئولیت را پذیرفته‌اند؟ با این پرسش وارد بخش ششم دوره، «قرارداد، پذیرش و بهره‌برداری»، می‌شویم.
این درس، اسلایدهای ۱۰۲ تا ۱۰۶ را به ترتیب دنبال می‌کند: موضوع قرارداد، تبدیل ادعا به تعهد قابل آزمون، دارایی‌های لازم برای ادامهٔ خدمت و تصمیم دربارهٔ محل آموزش مدل.
مدل، سامانه، خدمت و نتیجه را جدا روشن کنیم
موضوع تحویل، انتظار از مسئولیت و پذیرش را تغییر می‌دهد.
موضوع قرارداد می‌تواند مدل، سامانه، خدمت عملیاتی یا نتیجهٔ کسب‌وکار باشد. در یک پروژه ممکن است چند مورد از آن‌ها هم‌زمان در دامنه باشند، اما باید انتظار مربوط به هرکدام مشخص شود.
موضوع
نمونهٔ تحویل
چه چیزی باید در توافق روشن شود؟
مدل
نسخهٔ مدل، وزن‌ها یا پیکربندی، مستندات و معیار ارزیابی
عملکرد فنی مورد انتظار، شرایط استفاده و حدود تعهد سازنده
سامانه
محیط کاربری، ارتباط با منابع و سامانه‌ها، استقرار و کنترل‌های پایه
کارکرد یکپارچه، دسترسی‌ها و مسئولیت عملکرد سامانه
خدمت عملیاتی
پایش، پشتیبانی، رسیدگی به رخداد و نگهداری
سطح خدمت، زمان و شیوهٔ رسیدگی و مسئولیت ادارهٔ مستمر
نتیجه یا اثر کسب‌وکار
شاخص هدف، اثر مورد انتظار، سنجهٔ پذیرش و گزارش تحقق
نقش مالک کسب‌وکار و مجری، اقدامات لازم و نحوهٔ سنجش نتیجه
برای دستیار پروندهٔ ما، کیفیت مدل بخشی از موضوع است. دسترسی درست به منابع، اجرای حدود اختیار و مسیر ارجاع به کارکرد سامانه مربوط‌اند. ادامهٔ پاسخ‌گویی و رسیدگی به خطاها نیز به خدمت عملیاتی مربوط می‌شود.
کاهش زمان رسیدگی، یک انتظار دیگر است که به نحوهٔ استفاده و فرایند سازمان هم وابسته است. باید معلوم باشد سازمان چه تغییری در کار خود می‌دهد، مجری چه قابلیتی فراهم می‌کند و اثر حاصل چگونه بررسی می‌شود.
این تفکیک از انتقال مسئولیت با چند واژهٔ کلی جلوگیری می‌کند. ممکن است تأمین‌کننده ادارهٔ خدمت را هم بپذیرد یا فقط بخشی از راهکار را تحویل دهد. در هر حالت، دامنهٔ تعهد باید با موضوع واقعی کار هماهنگ باشد.
مسئولیت‌های داخل سازمان نیز باید روشن بمانند. پذیرش عملکرد فنی، تأیید اعتبار محتوا و پذیرش اثر در کسب‌وکار به بررسی‌های متفاوت نیاز دارند. همان منطق کلاه‌ها برقرار است؛ افراد می‌توانند چند مسئولیت داشته باشند، اما باید بدانند با کدام اختیار، چه چیزی را تأیید می‌کنند.
مدیر فناوری گفت: «در دامنهٔ فعلی، یک سامانهٔ محدود برای پاسخ از منابع تأییدشده می‌خوایم، همراه با پشتیبانی مشخص.»
مدیر عملیات پرسید: «کاهش زمان پاسخ‌گویی رو هم می‌سنجیم؟»
مدیرعامل گفت: «بله، ولی معلوم کنیم چه بخشی به قابلیت سامانه و چه بخشی به آماده‌سازی منابع و فرایند خودمون مربوطه.»
مدیر مالی کنار متن نخست قرارداد نوشت: «موضوع تحویل و تعهد هر بخش، جدا تکمیل شود.»
هر ادعا را به تعهد قابل آزمون تبدیل کنیم
هر تعهد به معیار، دادهٔ آزمون، آستانهٔ پذیرش و مسئول اندازه‌گیری نیاز دارد.
عبارت‌هایی مانند «دقت بالا»، «مدل اختصاصی»، «امنیت کامل» یا «بهترین فناوری» به توضیح بیشتر نیاز دارند. برای پذیرش، باید بتوانیم ادعا را در شرایط معلوم بررسی کنیم.
برای تبدیل ادعا به تعهد قابل آزمون، چهار جزء لازم است:
معیار: دقیقاً چه چیزی اندازه‌گیری می‌شود؟
داده و سناریوی آزمون: بررسی روی چه نمونه‌ها و در چه شرایطی انجام می‌شود؟
آستانهٔ پذیرش: چه نتیجه‌ای قابل قبول است؟
مسئول اندازه‌گیری: چه کسی و با چه روشی نتیجه را می‌سنجد؟
برای نمونه، اگر ادعا «کنترل دسترسی» است، باید نقشهای کاربری و منابع مجاز و غیرمجاز معلوم باشند. سناریوی آزمون باید نشان دهد کاربر مجاز به منبع لازم می‌رسد و منبع غیرمجاز وارد مسیر پاسخ او نمی‌شود. نتیجهٔ مورد انتظار و مرجع بررسی نیز باید از قبل روشن باشند.
در ادعای «دقت بالا»، باید مشخص کنیم دربارهٔ کدام سؤال‌ها و کدام ابعاد کیفیت صحبت می‌کنیم. صحت، ارتباط با سؤال، کامل‌بودن، استنادپذیری، شفافیت و ایمنی و انطباق، ابعاد متفاوتی از کیفیت پاسخ‌اند.
برای مثال، پاسخ می‌تواند مرتبط و روان باشد اما ناقص باشد؛ یا به سندی ارجاع بدهد که برای این سؤال معتبر نیست. باید بدانیم این وضعیت‌ها در ارزیابی چگونه دیده می‌شوند.
معیارهای عملیاتی نیز مکمل کیفیت پاسخ‌اند: رفتار زیر بار، زمان پاسخ، کنترل دسترسی، هزینه و ظرفیت. ممکن است پاسخ در چند نمونهٔ ساده مناسب باشد، اما شرایط استفادهٔ واقعی هنوز بررسی نشده باشد.
این مرحله، کارِ تبدیل وعده به انتظار روشن است. جزئیات انتخاب معیار درست و استقلال آزمون را در ادامهٔ همین بخش بررسی خواهیم کرد.
در «قرارداد هوش مصنوعی؛ دقیقاً چه چیزی را باید تحویل بگیریم؟» این مسیر را تا برگهٔ تحویل پروژه و پیوند پرداخت با شواهد هر مرحله دنبال کرده‌ام. برای بازنویسی پیشنهاد دستیار، می‌توان از همان برگه کمک گرفت تا معیارهای کیفیت، امنیت، ظرفیت و پشتیبانی در اقلام تحویل دیده شوند.
مدیر مالی به عبارت «امنیت کامل» اشاره کرد: «این رو چطور تحویل می‌گیریم؟»
مسئول ریسک و انطباق گفت: «کنترل‌های مورد انتظار و سناریوهای بررسی رو مشخص کنیم. برای همون دسترسی نامجاز، نقش، منبع، نتیجهٔ مورد انتظار و شاهد اجرا لازم داریم.»
مدیر فناوری گفت: «برای کیفیت پاسخ هم باید همین کار رو انجام بدیم.»
مدیرعامل گفت: «پس هیچ وعده‌ای بدون روش بررسی وارد مبنای پذیرش نشه.»
دارایی‌های لازم برای ادامه و انتقال خدمت را مشخص کنیم
بازسازی، ارزیابی، ممیزی، انتقال و ادامهٔ خدمت به مجموعه‌ای از دارایی‌ها نیاز دارند.
در درس نهم، دربارهٔ دارایی‌های راهبردی سازمان صحبت کردیم. اکنون همان موضوع را به تحویل پروژه وصل می‌کنیم: برای ادامهٔ کار، ارزیابی یا تغییر تأمین‌کننده، دقیقاً به چه چیزهایی نیاز داریم؟
گروه دارایی
چه چیزی باید در تحویل و حدود استفاده روشن باشد؟
داده و اسناد
دسترسی سازمان به داده‌های مجاز و اسناد مبنای پروژه
دادهٔ آماده‌شده و برچسب‌خورده
اطلاعات حاصل از آماده‌سازی و اصلاح داده و امکان استفادهٔ بعدی
مدل و وزن‌ها یا حق استفادهٔ پایدار
نسخهٔ مورد استفاده، حق استفاده و محدودیت‌های مرتبط
تنظیمات دستیار
دستورالعمل‌ها، قالب‌ها و پیکربندی‌های مؤثر بر پاسخ
نمایه و پیکربندی بازیابی
اطلاعات و تنظیمات لازم برای یافتن منابع مرتبط
مجموعهٔ مرجع و دادهٔ آزمون
نمونه‌ها، پاسخ‌های مرجع و مواد لازم برای ارزیابی
سوابق، نتایج و شواهد ارزیابی
گزارش‌ها و اطلاعات لازم برای بررسی کیفیت و تصمیم‌های گذشته
کد، وابستگی‌ها و مستندات استقرار
اجزای لازم برای بازسازی، اداره، انتقال و ادامهٔ خدمت
این فهرست باید به نیاز و دامنهٔ واقعی پروژه ترجمه شود. دربارهٔ هر جزء، لازم است روشن کنیم چه چیزی تحویل می‌شود، چه کسی آن را به‌روز می‌کند و سازمان در ادامه چه اختیار استفاده‌ای دارد.
در مورد اجزای عمومی یا متعلق به دیگران، حق استفاده و حدود آن باید با نیاز ادامهٔ خدمت سازگار و روشن باشد. دربارهٔ داده و دانش اختصاصی پروژه نیز باید تکلیف حفظ، دسترسی و انتقال مشخص شود.
مالکیت و امکان نظارت هم دو موضوع جدا هستند. در «برای حکمرانی هوش مصنوعی، آیا باید کد منبع را ببینیم؟» تفاوت مالکیت فناوری با حق مطالبهٔ شواهد، ممیزی و آزمون مستقل را توضیح داده‌ام. این تمایز کمک می‌کند در قرارداد، هم تکلیف دارایی‌های لازم برای ادامهٔ کار روشن شود و هم حق ارزیابی سازمان، حتی برای اجزایی که مالک آن‌ها نیست.
صرف داشتن اسناد اولیه، برای بازسازی همان دستیار کافی نیست. ممکن است تنظیمات، نسخهٔ مدل، منابع تأییدشده، شیوهٔ یافتن اطلاعات و نتایج آزمون بر رفتار آن اثر گذاشته باشند. برای مقایسهٔ نسخهٔ بعدی نیز به همان شواهد نیاز داریم.
زمان تحویل و روش استفاده از این دارایی‌ها هم اهمیت دارد. سازمان باید بتواند در طول بهره‌برداری، به اطلاعات لازم برای بررسی کیفیت یا رسیدگی به رخداد دسترسی داشته باشد. نیاز به انتقال دانش و روشن‌کردن مالکیت و حق استفاده، در راهنماهای تأمین هوش مصنوعی نیز مورد توجه است.
مدیر مالی گفت: «در پیشنهاد نوشته اسناد و مدل تحویل می‌شن. این فهرست چیزهای بیشتری داره.»
مدیر فناوری گفت: «باید مشخص کنیم منظور از تحویل مدل چیه و برای راه‌اندازی دوباره چه اجزایی لازم داریم.»
مدیر منابع انسانی پرسید: «پاسخ‌های تأییدشده و اصلاحاتی که در پایلوت انجام دادیم هم باقی می‌مونن؟»
مدیرعامل گفت: «همین‌ها رو به اقلام مشخص تحویل تبدیل کنیم. هر چیزی که برای ارزیابی و ادامهٔ کار لازمه، باید تکلیفش روشن باشه.»
محل آموزش مدل را با نیاز کنترل و بهره‌برداری بسنجیم
محل آموزش به حساسیت داده، تکرار کار، انتقال دانش و مسئولیت بهره‌برداری وابسته است.
تصمیم دربارهٔ محل آموزش زمانی مطرح می‌شود که آموزش یا تغییر مدل، بخشی از تعهد پروژه باشد. باید روشن شود این فعالیت کجا انجام می‌شود، به چه داده‌ای نیاز دارد و نتیجه و دانش آن چگونه در اختیار بهره‌بردار قرار می‌گیرد.
سه گزینه پیش روی سازمان است:
گزینه
چه زمانی می‌تواند مطرح باشد؟
چه چیزی باید روشن شود؟
سمت پیمانکار
کار آزمایشی یا کوتاه‌مدت، دادهٔ مجاز و غیرحساس و نیاز به شروع سریع‌تر
شرایط استفاده از داده، تحویل نتیجه و هزینه و روش انتقال در آینده
سمت کارفرما
دادهٔ حساس، آموزش مکرر، اهمیت کنترل بلندمدت یا راهبردی‌بودن مدل
توان اداره، دسترسی‌ها، پشتیبانی و مسئولیت ادامهٔ کار
ترکیبی
نیاز به تخصص پیمانکار همراه با ضرورت جداسازی بخش حساس
مرز کارِ هر طرف، محل اجرای هر مرحله و برنامهٔ انتقال دانش و زیرساخت
معیارهای تصمیم عبارت‌اند از حساسیت داده، هزینه و مقیاس پردازش، تکرار آموزش، نیاز به انتقال و مسئولیت بهره‌برداری. این عوامل باید کنار هم بررسی شوند.
اگر قرار است مدل در طول خدمت مرتب تغییر کند، هزینه و وابستگی هر بار تغییر اهمیت پیدا می‌کند. اگر داده حساس است، حدود دسترسی و محل پردازش باید با سیاست سازمان سازگار باشد. اگر سازمان مسئول ادارهٔ بلندمدت است، توان، دانش و اقلام تحویل لازم برای این مسئولیت نیز باید دیده شوند.
در الگوی ترکیبی، می‌توان بخشی از آماده‌سازی را با نمونه‌های مجاز انجام داد و بخش حساس را در محیط کنترل‌شدهٔ سازمان پیش برد. در درس دوازدهم دیدیم که این تفکیک چگونه به محدودکردن دسترسی مستقیم تیم توسعه به دادهٔ محرمانه مربوط می‌شود.
جزئیات این شیوهٔ همکاری را در «مهندسی داده و مدل بدون مشاهدهٔ دادهٔ محرمانه» آورده‌ام؛ از ساخت دادهٔ آزمایشی بر اساس قرارداد داده تا ارزیابی مستقل و عیب‌یابی در محیط کنترل‌شده. این مسیر روشن می‌کند چگونه می‌توان تخصص پیمانکار را به کار گرفت و دسترسی او به دادهٔ واقعی را محدود نگه داشت.
محل تجهیزات، یکی از اجزای تصمیم است. باید اختیار تغییر، مدیریت دسترسی، اجرای آموزش، ارزیابی و تحویل نسخه نیز روشن باشد. این‌ها تعیین می‌کنند سازمان در عمل چه کنترلی بر ادامهٔ مسیر دارد.
پیش از امضای تحویل
مدیر فناوری گفت: «اگر آموزش یا تغییر مدل در دامنه باشه، باید محل اجرا و برنامهٔ تحویل دانش رو مشخص کنیم.»
مدیر مالی پرسید: «هزینهٔ تغییرهای بعدی هم از همین حالا قابل بررسیه؟»
«باید شرایطش رو بخوایم. مخصوصاً اگر قرار باشه فقط خود پیمانکار بتونه اون کار رو انجام بده.»
مدیرعامل چهار عنوان روی برگه گذاشت: «موضوع تحویل، معیار پذیرش، دارایی‌های لازم، مسئولیت ادامهٔ کار».
گفت: «پیشنهاد رو با این‌ها تکمیل کنیم.»
مدیر عملیات یکی از پاسخ‌های نمونه را دوباره باز کرد: «برای معیار پذیرش، این جواب خیلی محکم و روشن نوشته شده. از کجا می‌فهمیم درسته؟»
مدیرعامل به منبع کنار پاسخ نگاه کرد.
«مرحلهٔ بعد رو از همین سؤال شروع کنیم.»
در درس پانزدهم، از اسلاید ۱۰۷ ادامه می‌دهیم: تفاوت لحن قاطع با صحت پاسخ، هزینهٔ انواع خطا، ارزیابی مستقل و شرایط پذیرش پروژه. موضوع آن است که برای پذیرش، دقیقاً چه شاهدی را معتبر می‌دانیم.
مدیر عملیات پوشهٔ مصوبات را باز کرد. چند لحظه بعد، دو سند کنار هم روی میز بود. موضوع یکی بود؛ حکمشان یکسان نبود.
مسئول ریسک و انطباق گفت: «پس منبع داشته، ولی باید اعتبار همین نسخه رو هم بررسی کنیم.»
مدیر فناوری پاسخ را از ابتدا خواند. این بار مکثش طولانی‌تر بود.
مدیرعامل برگهٔ معیارهای پذیرش را، که در جلسهٔ قبل آماده کرده بودند، به طرف خود کشید.
«اگر امروز این مورد اتفاقی پیدا نمی‌شد، با همون چند پاسخ خوب، آماده بودیم تحویلش بگیریم؟»
هیچ‌کس بلافاصله جواب نداد.
در درس چهاردهم موضوع تحویل و مسئولیت هر بخش را روشن کردیم و دیدیم هر ادعا باید معیار، دادهٔ آزمون، آستانهٔ پذیرش و مسئول اندازه‌گیری داشته باشد. در پایان همان جلسه، مدیر عملیات دربارهٔ درستی یک پاسخ قاطع پرسید. حالا کنار هم قرارگرفتن دو نسخهٔ بخشنامه نشان می‌دهد چرا داشتن منبع و نگارش محکم، بررسی را تمام نمی‌کند. باید مشخص کنیم چه آزمونی، با چه داده‌ای و به داوری چه کسی، شواهد کافی برای پذیرش دستیار فراهم می‌کند.
این درس اسلایدهای ۱۰۷ تا ۱۱۱ را به ترتیب دنبال می‌کند: صحت پاسخ، هزینهٔ انواع خطا، ارزیابی مستقل، تفاوت ادعاها و شواهد، و پذیرش چندلایه همراه با استقرار مرحله‌ای.
پاسخ قاطع، چه چیزی را اثبات می‌کند؟
لحن پاسخ و اطمینان مدل، جای آزمون صحت و اعتبار منبع را نمی‌گیرند.
باید سه مفهوم را از هم جدا کنیم: لحن قاطع، اطمینان مدل و صحت پاسخ. ممکن است پاسخ با ادبیاتی محکم بیان شود؛ ممکن است برای آن نشانه یا عددی از اطمینان هم نمایش داده شود. هیچ‌کدام به‌تنهایی نشان نمی‌دهد حکم ارائه‌شده دربارهٔ مسئلهٔ سازمان درست است.
در پروندهٔ ما، حتی پیدا شدن عبارت در سند نیز بررسی را تمام نمی‌کند. باید معلوم باشد سند معتبر است، نسخهٔ درست آن استفاده شده و حکم برای همین وضعیت کاربرد دارد. پاسخ به یک درخواست خرید، با استناد به بخشنامه‌ای که دیگر مبنای عمل نیست، با انتظار سازمان از پاسخ درست فاصله دارد؛ هرچند نقل عبارت کاملاً دقیق باشد.
بنابراین معیار پذیرش باید معنای «درست بودن» را برای همین کاربرد روشن کند. برای دستیار پاسخ‌گو از منابع سازمانی، می‌توان بررسی کرد که آیا پاسخ با منبع مصوب و معتبر سازگار است، به نسخهٔ قابل استفاده ارجاع می‌دهد و در صورت ابهام یا تعارض، مسیر ارجاع را رعایت می‌کند.
همهٔ این‌ها به حدود اختیار قبلی وابسته‌اند. دستیار پروندهٔ ما برای توضیح مقررات از منابع تأییدشده بررسی می‌شود؛ اختیار رد یا تصویب مستقل خرید به آن نداده‌ایم. پس رفتار صحیح در یک مورد مبهم می‌تواند توقف در پاسخ قطعی و ارجاع به مسئول مربوط باشد. آزمونی که فقط جواب نهایی را امتیاز بدهد و چنین ارجاعی را شکست بداند، ممکن است با سیاست مصوب سازمان ناسازگار باشد.
اعتبار پاسخ باید در نسبت با سؤال، منبع و حدود اختیار سنجیده شود. خوش‌بیانی پاسخ یکی از ویژگی‌های تجربهٔ کاربر است؛ پذیرش صحت به شواهد خودش نیاز دارد.
مدیر عملیات گفت: «پس توی آزمون، فقط نمی‌پرسیم جمله‌اش درسته یا نه؛ می‌پرسیم بر اساس کدوم نسخه و برای چه وضعیتی گفته.»
مسئول ریسک و انطباق نام دو بخشنامه را کنار هم نوشت: «این مورد رو هم نگه داریم؛ انتظار ما اینه که تعارض رو تشخیص بده یا ارجاع بده.»
مدیر مالی به گزارش نمونه اشاره کرد: «اینجا نوشته دقت بالا. اگر بیشتر جواب‌ها درست باشن، همین کافی نیست؟»
مدیرعامل گفت: «ببینیم اون جواب‌های غلط، کدوم‌ها هستن و چه اثری می‌ذارن.»
یک عدد دقت، هزینهٔ خطاها را نشان نمی‌دهد
معیار موفقیت باید با هزینه و پیامد انواع خطا هماهنگ باشد.
در درس هفتم دربارهٔ هزینهٔ خطا صحبت کردیم. اینجا همان بحث به تصمیم پذیرش می‌رسد: آیا گزارشی که فقط یک عدد کلی از دقت نشان می‌دهد، برای تصمیم کافی است؟
مثال مزایای کارکنان، تفاوت هزینهٔ خطاها را روشن می‌کند. سامانه ممکن است به اشتباه فردی را واجد مزایا بداند؛ یا فرد واجد شرایط را فاقد مزایا معرفی کند. اولی می‌تواند پرداخت یا تعهد ناموجه ایجاد کند و پس از اصلاح، نارضایتی به همراه داشته باشد. دومی می‌تواند حق فرد را نادیده بگیرد و به شکایت و کاهش اعتماد برسد.
در دسترسی به اطلاعات نیز دو خطا داریم: باز کردن سند محرمانه برای فرد غیرمجاز، و محروم کردن کاربر مجاز از دسترسی لازم. پیامد این دو یکسان نیست. وزن آن‌ها هم باید با حساسیت اطلاعات و نیاز فرایند تعیین شود.
اگر خطاهای متفاوت را در یک میانگین جمع کنیم، بخشی از اطلاعات لازم برای پذیرش از بین می‌رود. ممکن است سامانه در سؤال‌های پرتکرار و کم‌خطر خوب عمل کند، اما در چند مورد حساس، رفتاری نشان دهد که با حدود پذیرفته‌شدهٔ سازمان سازگار نباشد.
برای پروندهٔ ما، گزارش آزمون باید خطاها را دست‌کم به اندازه‌ای تفکیک کند که تصمیم ممکن شود: استناد به سند منسوخ، پاسخ قطعی در وضعیت مبهم، ارجاع درست و رعایت محدودیت دسترسی، نتایج متفاوتی هستند. سپس برای موارد مهم، معیار و حد پذیرش متناسب تعیین می‌شود. موفقیت در سؤال‌های آسان نباید شکست یک کنترل ضروری را در میانگین پنهان کند.
این انتخاب، مسئولیت مالک کسب‌وکار و صاحبان ریسک را هم درگیر می‌کند. تیم فنی می‌تواند نتیجهٔ آزمون را اندازه بگیرد، اما تعیین اینکه کدام پیامد برای سازمان پذیرفتنی است، به تصمیم صاحبان اختیار نیاز دارد.
در «دقت ۹۵ درصد برای کارخانه چه معنایی دارد؟» همین مسئله را با دو سامانهٔ دارای دقت یکسان و هزینه‌های متفاوت نشان داده‌ام. مثال عددی آن یادداشت، هم هزینهٔ عیب‌های ازدست‌رفته و هشدارهای کاذب را حساب می‌کند و هم زمانی را که بررسی انسانی هشدارها از فرایند می‌گیرد.
مدیر مالی گفت: «در مزایا، هم پرداخت اشتباه مهمه، هم محروم‌شدن فردی که حق داره. نمی‌خوام یکی زیر عدد کلی اون یکی گم بشه.»
مدیر عملیات اضافه کرد: «برای خرید هم موارد تعارض سند و ارجاع رو جدا ببینیم.»
مدیر فناوری برگهٔ آزمون را جلو کشید: «نمونه‌هایی که تا حالا دیدیم رو پیمانکار آماده کرده. برای بررسی این موارد، باید مجموعهٔ آزمون خودمون رو هم مشخص کنیم.»
مدیرعامل پرسید: «و کسی که دربارهٔ نتیجه نظر می‌ده، از کجا می‌فهمه این نمونه‌ها نمایندهٔ کار واقعی ما هستن؟»
خط مبنا و آزمون مستقل را پیش از پذیرش آماده کنیم
پذیرش باید بر شواهد مستقل، موارد واقعی و مقایسه با خط مبنا تکیه کند.
خط مبنا، پیکرهٔ طلایی و ارزیابی مستقل، نقشهای مکمل دارند. خط مبنا نشان می‌دهد کار امروز چگونه انجام می‌شود. پیکرهٔ طلایی مجموعه‌ای از موارد مرجع با پاسخ یا رفتار مورد انتظارِ بررسی‌شده است. ارزیابی مستقل امکان می‌دهد نتیجه را خارج از انتخاب و داوری انحصاری سازنده بسنجیم.
خط مبنا برای پروندهٔ ما می‌تواند رسیدگی فعلی کارشناسان باشد: پاسخ چگونه پیدا می‌شود، چقدر زمان می‌برد، چه خطاهایی رخ می‌دهد و چه مواردی ارجاع می‌شوند. بدون این شناخت، ممکن است یک قابلیت جذاب را ببینیم، اما ندانیم چه بهبودی ایجاد کرده یا چه هزینه‌ای به فرایند افزوده است.
پیکرهٔ طلایی نیز صرفاً فهرستی از سؤال‌ها نیست. برای هر مورد باید انتظار معتبر وجود داشته باشد. اگر خود سازمان هنوز دربارهٔ اعتبار دو بخشنامه توافق ندارد، همان اختلاف ابتدا باید توسط صاحب اختیار روشن شود؛ وگرنه آزمون، داوری دربارهٔ عملکرد سامانه را با اختلاف حل‌نشدهٔ سازمان مخلوط می‌کند.
این مجموعه باید سؤال‌های عادی و موارد مرزی مهم را پوشش دهد: تعارض اسناد، نبود منبع کافی، تفاوت مجوز کاربران و وضعیت‌هایی که پاسخ درستشان ارجاع است. بیست سؤال آسان و انتخاب‌شده برای نمایش، پوشش این موقعیت‌ها را اثبات نمی‌کند.
میان دادهٔ توسعه و شواهد پذیرش نیز باید فاصله باشد. مواردی که برای ساخت و اصلاح پاسخ‌ها استفاده شده‌اند، به‌تنهایی نشان نمی‌دهند سامانه با مسائل ندیده چگونه برخورد می‌کند. برای ارزیابی کور، بخشی از آزمون نهایی و پاسخ‌های مرجع آن از دسترس فرایند توسعه کنار گذاشته می‌شود و نتیجه با معیار از پیش تعیین‌شده بررسی می‌شود.
سازنده نباید تنها طراح آزمون و تنها داور پذیرش کار خودش باشد. پیمانکار همچنان آزمون داخلی انجام می‌دهد و شواهد ارائه می‌کند؛ مسئولیت کارفرما برای آماده‌کردن معیار، موارد مرجع و داوری مستقل باقی می‌ماند.
اینجا هم مسئولیت‌ها کلاه‌اند، اما تعارض نقش باید دیده شود. لازم نیست برای هر کلاه یک پست سازمانی تازه بسازیم؛ بااین‌حال، اینکه فرد نتیجهٔ کاری را که خودش ساخته، به‌تنهایی تأیید کند، استقلال ارزیابی ایجاد نمی‌کند. باید برای داوری آن بخش، بازبینی فرد یا مرجع دیگری پیش‌بینی شود.
برای عملی‌کردن این استقلال در رابطه با تأمین‌کننده، در «برای حکمرانی هوش مصنوعی، آیا باید کد منبع را ببینیم؟» دربارهٔ حق انجام آزمون مستقل و فراهم‌کردن محیط و اطلاعات لازم برای ممیز توضیح داده‌ام. این حق باید امکان راستی‌آزمایی را فراهم کند، حتی وقتی سازمان مالک کد یا وزن‌های مدل نیست.
مدیر عملیات گفت: «موارد مرجع رو با کارشناسی که صاحب همین فراینده بررسی می‌کنیم؛ جواب درست و محل ارجاع رو هم مشخص می‌کنیم.»
مسئول ریسک و انطباق ادامه داد: «چند مورد دسترسی و تعارض سند هم در آزمون مستقل می‌ذاریم. نتیجه‌شون رو جدا گزارش می‌کنیم.»
مدیر مالی پرسید: «پس نمایش هفتهٔ قبل چی رو ثابت کرده بود؟»
مدیر فناوری گفت: «اینکه در نمونه‌های نمایش‌داده‌شده، امکان پاسخ‌گویی وجود داره.»
مدیرعامل روی برگه نوشت: «ادعای هر مرحله را مشخص کنیم.»
دمو، پایلوت، محصول اولیه و سامانهٔ عملیاتی، ادعاهای متفاوتی دارند
چیدمان تصویر، مسیر نمونهٔ ارائه است؛ دمو، پایلوت، MVP و عملیات الزاماً مراحل پیاپی همهٔ پروژه‌ها نیستند.
دمو، پایلوت، MVP و سامانهٔ عملیاتی به پرسش‌های متفاوتی پاسخ می‌دهند. دمو امکان یک قابلیت را نشان می‌دهد؛ پایلوت، راهکار را در محیط واقعی اما محدود می‌آزماید. MVP یا حداقل محصول پذیرفتنی، شکل اولیه‌ای از محصول است که امکان شروع یادگیری معتبر دربارهٔ فرض‌های آن را فراهم می‌کند. در روش‌شناسی Lean Startup، هدف MVP آغاز چرخهٔ ساختن، سنجیدن و یادگرفتن است؛ از جمله اینکه آیا محصول مسئلهٔ مورد نظر کاربران را حل می‌کند و چه تغییری لازم دارد.
می‌توان یک MVP را در پایلوت آزمود: محصول، امکانات لازم برای آزمودن یک فرض مشخص را دارد و استفاده از آن در یک گروه یا محیط محدود بررسی می‌شود. بنابراین پایلوت لزوماً پیش از MVP قرار نمی‌گیرد. ترتیب، همپوشانی و تکرار این فعالیت‌ها به مسئله، ریسک و فرض‌هایی که باید آزموده شوند وابسته است.
چهار نوع ادعا و شاهد
نوع ادعا
پرسش
شاهد مورد نیاز
دمو
آیا امکان اولیهٔ مورد نظر در نمونهٔ ارائه‌شده نشان داده می‌شود؟
اجرای قابل بررسیِ همان قابلیت، با شرایط و محدودیت‌های روشن
پایلوت
آیا راهکار در محیط واقعی اما محدود و کنترل‌شده نتیجهٔ مورد انتظار می‌دهد؟
نتایج استفادهٔ محدود، مقایسه با خط مبنا و بررسی موارد مهم در همان دامنه
MVP
آیا شکل اولیهٔ محصول، امکان آزمودن فرض مشخصی دربارهٔ نیاز و رفتار کاربران را فراهم می‌کند؟
مشاهده و سنجش رفتار کاربران با معیار مرتبط با آن فرض؛ نتیجه می‌تواند تأیید یا رد فرض باشد
سامانهٔ عملیاتی
آیا می‌توان خدمت را با پایداری، امنیت، پشتیبانی و ظرفیت لازم اداره کرد؟
شواهد بار، امنیت، بازیابی، پشتیبانی و هزینه در شرایط بهره‌برداری مورد نظر
یک دموی خوب برای بررسی امکان اولیه مفید است. برای نتیجه‌گیری دربارهٔ رفتار زیر بار واقعی، رسیدگی به رخداد، رعایت دسترسی‌ها یا هزینهٔ ادامهٔ خدمت، باید شواهد همان ادعاها فراهم شود.
در درس ششم پایلوت را به امکان اجرا، ارزش و قابلیت ادارهٔ راهکار پیوند دادیم. اکنون باید هنگام پذیرش مراقب باشیم نتیجهٔ یک آزمون محدود، به تعهدی گسترده‌تر تبدیل نشود. پذیرش پایلوت برای تعداد مشخصی کاربر و چند نوع سؤال، مجوز خودکار برای استفادهٔ همهٔ کارکنان در همهٔ فرایندها ایجاد نمی‌کند.
نام‌گذاری نیز به‌تنهایی کافی نیست. ممکن است چیزی «پایلوت» نامیده شود، اما کاربران واقعی بدون محدودیت به خروجی آن تکیه کنند. باید دامنهٔ کاربران، اطلاعات، اختیار و اثر خروجی روشن باشد تا ریسک واقعی با نام مرحله هماهنگ بماند.
در قرارداد و صورت‌جلسهٔ پذیرش، باید مشخص شود کدام نوع تحویل و کدام دامنهٔ استفاده تأیید می‌شود و تغییر یا گسترش آن به چه شواهدی نیاز دارد.
مدیر مالی کنار واژهٔ «تحویل» نوشت: «تحویل کدام مرحله؟»
مدیر عملیات گفت: «برای ما فعلاً همون استفادهٔ محدود مطرحه؛ چند کاربر مشخص و پاسخ از منابع تأییدشده.»
مدیر فناوری سر تکان داد: «با کنترل‌هایی که هنوز باید دوباره آزمون بشن.»
مدیرعامل گفت: «پس اگر این مرحله موفق شد، قدم بعدی رو هم با شرط مشخص باز می‌کنیم. از حالا ننویسیم آمادهٔ استفادهٔ عمومی.»
پذیرش چندلایه است؛ گسترش استفاده هم باید مرحله‌ای باشد
صحت پاسخ یکی از لایه‌های پذیرش است؛ مسیر استقرار تصویر، نمونه‌ای برای پروندهٔ دستیار این دوره است.
پذیرش را در پنج لایه بررسی می‌کنیم. برای دستیار پروندهٔ ما، هر لایه پرسش‌های خودش را دارد:
لایه
پرسش پذیرش
فنی
پاسخ‌ها چقدر درست‌اند و تأخیر و پایداری در شرایط آزمون چگونه است؟
عملیاتی
پایش، پشتیبانی و فرایند اجرا آماده‌اند و مسئول رسیدگی مشخص است؟
امنیتی
دسترسی‌ها، ثبت رخداد و آزمون‌های امنیتی مورد نیاز نتیجهٔ قابل قبول دارند؟
انسانی
کاربر آموزش دیده، محدودیت‌ها را می‌فهمد و می‌تواند از حق مداخله و ارجاع استفاده کند؟
اقتصادی
هزینه و ظرفیت خدمت با ارزش مورد انتظار برای کسب‌وکار تناسب دارد؟
ممکن است پاسخ درست باشد، اما کاربر راه ارجاع خطا را نداند. ممکن است تجربهٔ استفاده خوب باشد، اما پشتیبانی برای زمان قطع خدمت آماده نباشد. ممکن است همهٔ این‌ها در استفادهٔ محدود خوب عمل کنند، اما هزینهٔ همان الگو در دامنهٔ بزرگ‌تر، با انتظار سازمان سازگار نباشد.
پس نتیجهٔ پذیرش باید به مجموعهٔ شواهد متکی باشد. برای هر لایه، مرجع تأیید و شرط عبور روشن می‌شود. یک فرد می‌تواند چند کلاه داشته باشد، اما باید معلوم بماند هر تأیید را با کدام مسئولیت و بر اساس کدام شواهد انجام داده است.
برای دستیار پروندهٔ ما، مسیر نمونهٔ استقرار در ارائه چنین است: حالت سایه، پایلوت محدود، آزمون بار و آزمون امنیتی، استفاده برای گروه محدود و استقرار کنترل‌شده.
در حالت سایه، می‌توان پاسخ سامانه را در کنار فرایند جاری بررسی کرد، بدون اینکه آن پاسخ مبنای اجرای اقدام سازمان شود. در پایلوت، استفاده در محدودهٔ مصوب انجام می‌شود. سپس شواهد بار و امنیت بررسی می‌شوند و با فراهم‌شدن شرایط، خدمت برای گروه محدودی گسترش می‌یابد. در مرحلهٔ آخر نیز کنترل دامنه، پایش و امکان مداخله باقی می‌ماند.
دامنه و ریسک کاربرد تعیین می‌کنند کدام بررسی‌ها هم‌زمان انجام شوند و کدام‌یک با تغییر شرایط تکرار شوند. این ترتیب به معنای موکول‌کردن امنیت به روزهای پایانی نیست؛ حداقل‌های لازم باید پیش از ورود هر کاربر و دادهٔ واقعی برقرار باشند. آزمون‌های بعدی، آمادگی برای دامنه و شرایط تازه را می‌سنجند.
هر افزایش در کاربران، منابع یا اختیار باید با شرایط عبور خودش همراه باشد. اگر شرطی برقرار نیست، تصمیم می‌تواند ادامهٔ آزمون در همان محدوده، اصلاح یا توقف گسترش باشد. پذیرش یک مرحله هم باید دقیقاً با همین حدود ثبت شود تا بعدها به تأییدی بی‌قیدوشرط تعبیر نشود.
این پیوند میان نتیجهٔ آزمون و اختیار ادامه یا توقف را در «وقتی استاندارد هست، اما کسی ملزم به آزمون نیست» بیشتر باز کرده‌ام: ارزیابی زمانی بر تصمیم اثر می‌گذارد که روشن باشد شکست یک کنترل، چه اصلاح یا محدودیتی را در پی دارد و چه کسی می‌تواند جلوی استقرار را بگیرد.
پذیرش کدام مرحله، با کدام شواهد؟
مدیرعامل برگه را به وسط میز برگرداند. کنار عنوان «معیار پذیرش»، حالا جای نام آزمون، مرجع داوری و دامنهٔ استفاده هم باز شده بود.
گفت: «اول آزمون مستقل رو کامل کنیم. بعد، دربارهٔ ادامهٔ استفاده در همون محدوده‌ای تصمیم بگیریم که شواهدش رو داریم.»
مدیر عملیات دو بخشنامه را داخل پوشه گذاشت: «این مورد هم جزو آزمون می‌مونه؛ با نتیجهٔ بررسی اعتبار نسخه‌ها.»
مسئول ریسک و انطباق گفت: «نسخهٔ سامانه، منابعی که باهاش آزمون شده و نتیجهٔ هر مورد رو هم باید نگه داریم. وگرنه بعداً نمی‌دونیم دقیقاً چی رو تأیید کردیم.»
مدیر مالی پرسید: «اگر بعد از پذیرش، بخشنامه یا خود سامانه عوض شد، این تأیید هنوز معتبره؟»
مدیرعامل به پوشه‌ای نگاه کرد که دیگر فقط چند پاسخ نمونه در آن نبود.
«پس باید معلوم کنیم چه شواهدی باقی می‌مونه و چه تغییری ما رو دوباره به ارزیابی برمی‌گردونه.»
در درس بعد، از همین‌جا ادامه می‌دهیم: پروندهٔ قابل حسابرسی چه چیزی باید در خود نگه دارد و چرا حکمرانی با تحویل پروژه پایان نمی‌یابد؟
درس شانزدهم؛ پروندهٔ قابل حسابرسی، بهره‌برداری و تغییر، پایان عمر سامانه و مصوبهٔ نهایی دستیار سازمانی.
مطالعهٔ درس: حکمرانی هوش مصنوعی با تحویل پروژه پایان نمی‌یابد
اگر فردا چیزی عوض شد، چه؟
پوشهٔ پذیرش هنوز باز بود. مدیر مالی دستش را روی دو بخشنامه گذاشت؛ همان دو سندی که در بحث قبل، پاسخ قاطع دستیار را زیر سؤال برده بودند.
«اگر بعد از پذیرش، بخشنامه یا خود سامانه عوض شد، این تأیید هنوز معتبره؟»
مدیر فناوری گفت: «باید بدونیم چه چیزی عوض شده و روی چه بخشی اثر می‌ذاره.»
مدیر عملیات پرسید: «و اگر کسی سه ماه بعد پرسید چرا اجازهٔ استفاده دادیم، از کجا نشونش می‌دیم؟»
مسئول ریسک و انطباق گزارش آزمون را کنار صورت‌جلسه گذاشت: «باید بتونیم تصمیم رو به همین شواهد وصل کنیم؛ با نسخهٔ سامانه و منابعی که واقعاً بررسی شده.»
مدیرعامل به صفحهٔ نخست پوشه نگاه کرد. عنوانش هنوز «تحویل پروژه» بود.
خودکار را برداشت و زیر آن نوشت: «بهره‌برداری، تغییر و خروج».
«پس این پوشه با تحویل بسته نمی‌شه. معلوم کنیم از امروز به بعد چه کسی مسئول زنده نگه داشتنشه.»
در درس پانزدهم دیدیم که پذیرش دستیار باید به آزمون مستقل، شواهد چندلایه و دامنهٔ مشخص استفاده متکی باشد. پرسش پایانی مدیر مالی، همان تصمیم را یک قدم جلوتر می‌برد: اگر بخشنامه، مدل یا شرایط استفاده تغییر کند، تأیید قبلی تا کجا اعتبار دارد؟ در ادامهٔ جلسه، اضافه‌شدن «بهره‌برداری، تغییر و خروج» به عنوان پوشه نشان می‌دهد سازمان باید هم سابقهٔ تصمیم را نگه دارد و هم مسئول بازنگری آن را بشناسد.
این درس، اسلایدهای ۱۱۲ تا ۱۱۶ را به ترتیب دنبال می‌کند و به پایان مسیر این دوره می‌رسد: پروندهٔ قابل حسابرسی، چرخهٔ بهره‌برداری، مصوبهٔ نهایی هیئت‌مدیره و منابع دوره.
پروندهٔ قابل حسابرسی؛ بتوانیم منطق تصمیم را نشان دهیم
تصمیم باید به شواهد، نسخهٔ بررسی‌شده و صاحب اختیار آن قابل پیوند باشد.
پروندهٔ قابل حسابرسی باید امکان بازسازی منطق تصمیم را فراهم کند: چه چیزی مطرح بود، چه بررسی‌هایی انجام شد، چه محدودیت‌هایی پذیرفته شد و چه کسی اجازهٔ عبور به مرحلهٔ بعد را داد؟
این پرونده هشت جزء دارد. در دستیار سازمانیِ روایت ما، معنای عملی آن‌ها چنین است:
جزء پرونده
چه چیزی باید قابل پیگیری باشد؟
منشور و دامنهٔ کاربرد
دستیار برای چه مسئله‌ای، چه کاربران و چه نوع استفاده‌ای تعریف شده است؟
نسخهٔ داده و مدل
آزمون و تأیید به کدام نسخهٔ سامانه، مدل و مجموعهٔ منابع مربوط بوده است؟
تبار داده و مجوز استفاده
منابع از کجا آمده‌اند و استفاده از آن‌ها بر چه مبنایی مجاز بوده است؟
نتایج آزمون و پذیرش
چه آزمون‌هایی انجام شده، چه نتیجه‌ای داشته و چه مرجعی آن را پذیرفته است؟
محدودیت‌ها و موارد منع استفاده
چه استفاده‌هایی خارج از دامنه‌اند و در چه شرایطی باید ارجاع یا توقف انجام شود؟
تغییرات، تأییدها و بازگشت
چه چیزی تغییر کرده، چه کسی تأیید کرده و در صورت نیاز چگونه به وضعیت معتبر برمی‌گردیم؟
رخدادها، شکایت‌ها و اصلاحات
چه مشکلی گزارش شده، چگونه رسیدگی شده و نتیجهٔ اصلاح چه بوده است؟
تصمیم‌های دروازه‌ای و صاحب هر تصمیم
چه کسی با کدام شواهد، ادامه، گسترش، تعلیق یا توقف را تصویب کرده است؟
این اجزا باید به یکدیگر وصل باشند. گزارش آزمونی که معلوم نیست مربوط به کدام نسخه است، برای توضیح وضعیت فعلی کفایت نمی‌کند. صورت‌جلسه‌ای که فقط می‌گوید «سامانه تأیید شد»، بدون ثبت حدود استفاده و شروط پذیرش، بخش مهمی از تصمیم را مبهم باقی می‌گذارد.
برای مثال، در پروندهٔ ما باید بتوان دید که موردِ بخشنامهٔ منسوخ چگونه وارد آزمون شده، مرجع اعتبار اسناد را چه کسی تعیین کرده و رفتار مورد انتظار چه بوده است. اگر بعداً منبع عوض شود، این سابقه کمک می‌کند معلوم شود کدام بخش از ارزیابی باید دوباره بررسی شود.
پرونده لازم نیست الزاماً یک پوشهٔ کاغذی یا سامانه‌ای تازه باشد. می‌توان با امکانات موجود، محل و شناسهٔ مشخصی برای اسناد، نتایج و تصمیم‌ها تعیین کرد. آنچه اهمیت دارد، پیوند شواهد، امکان بازیابی سابقه و مشخص‌بودن مسئول به‌روزرسانی آن است.
در ثبت رخداد و سوابق نیز باید حدود دسترسی، محتوای ضروری و مدت نگهداری روشن باشد. قابلیت حسابرسی می‌تواند با شواهدی متناسب با مسئولیت هر نقش فراهم شود؛ این کار نباید به دسترسی بی‌ضابطهٔ افراد به دادهٔ حساس وابسته باشد.
پیوند فنی این سوابق را در «MLOps؛ بستر پیاده‌سازی هوش مصنوعی بدون اعتماد» توضیح داده‌ام: نسخه‌گذاری داده، کد، مدل و نتیجهٔ ارزیابی کمک می‌کند معلوم باشد چه چیزی از مسیر انتشار گذشته و با کدام شواهد تأیید شده است. این چرخه، نگهداری پرونده و اعمال سیاست در طول عمر سامانه را پشتیبانی می‌کند.
همان منطق کلاه‌ها اینجا هم برقرار است. ممکن است یک نفر نگهداری پرونده و بخشی از مسئولیت فنی را هم بر عهده داشته باشد، یا چند نفر در تکمیل یک بخش شریک باشند. باید معلوم بماند چه کسی پرونده را به‌روز می‌کند و چه کسی اختیار تأیید محتوای هر بخش را دارد.
مدیر عملیات گفت: «منابع معتبر و دامنهٔ سؤال‌ها رو صاحب فرایند تأیید می‌کنه. نتیجهٔ این تأیید هم کنار نسخهٔ منابع می‌مونه.»
مدیر فناوری اضافه کرد: «نسخهٔ سامانه و نتیجهٔ آزمون‌ها رو هم به هم وصل می‌کنیم؛ که تأیید نسخهٔ قبلی به نسخهٔ جدید منتقل نشه.»
مسئول ریسک و انطباق گفت: «ثبت رخداد و پیگیری تصمیم اصلاح رو هم در همین سابقه می‌آریم.»
مدیر مالی پرسید: «خوبه. حالا چه چیزی باعث می‌شه دوباره این پرونده رو باز کنیم؟ فقط وقتی کاربر شکایت کرد؟»
بهره‌برداری، چرخهٔ مراقبت و تصمیم دوباره است
قرارداد و عملیات باید تغییر سامانه و پایان عمر آن را هم اداره کنند.
تحویل، بخشی از چرخهٔ بهره‌برداری است. نسخه ثبت می‌شود؛ عملکرد و هزینه پایش می‌شوند؛ افت، رخداد یا شکایت می‌تواند بررسی تازه‌ای را آغاز کند؛ اصلاح یا بازگشت انجام می‌شود؛ نتیجه دوباره اعتبارسنجی می‌شود و دربارهٔ ادامه، محدودسازی یا توقف تصمیم می‌گیریم. بازنشستگی و حذف داده نیز بخشی از همین مسیر است.
برای فهم مدیریتیِ «رانش» یا Drift، کافی است به فاصله‌ای توجه کنیم که ممکن است میان شرایط آزمون و شرایط استفاده پدید آید. کارکنان سؤال‌های تازه‌ای می‌پرسند، مقررات تغییر می‌کند یا منابع جدیدی اضافه می‌شوند. عملکردی که در دامنهٔ قبلی مناسب بوده، باید در برابر این تغییرها هم بررسی شود.
در پروندهٔ ما، اضافه‌شدن یک بخشنامهٔ تازه یا تغییر سطح دسترسی یک گروه، موضوعی مشخص برای بررسی اثر تغییر است. گسترش استفاده از پاسخ‌گویی دربارهٔ خرید به مزایای کارکنان، تغییر بزرگ‌تری است که دامنه و ریسک کاربرد را هم عوض می‌کند. میزان ارزیابی مجدد باید با اثر همین تغییر تناسب داشته باشد.
پایش نیز باید به تصمیم وصل شود. لازم است معلوم باشد چه افتی نیازمند بررسی است، چه رخدادی باید فوراً اعلام شود و چه کسی می‌تواند استفاده را محدود کند. گزارشی که تهیه می‌شود اما صاحب اقدام ندارد، چرخه را کامل نمی‌کند.
اصلاح هم پایان رسیدگی نیست. باید معلوم شود مشکل برطرف شده و استفاده در دامنهٔ مورد نظر دوباره قابل پذیرش است. بازآموزی مدل، در صورت نیاز، یکی از اقدام‌های ممکن است. مشکلِ نسخهٔ سند، مجوز دسترسی یا ابهام فرایند، به اصلاح همان منشأ نیاز دارد.
بازگشت نیز باید به وضعیت قابل قبول برسد. اگر منبع قبلی منسوخ شده باشد، برگرداندن آن مشکل را حل نمی‌کند. ممکن است تا آماده‌شدن وضعیت معتبر، بخشی از خدمت متوقف شود و مسیر رسیدگی قبلیِ سازمان ادامه پیدا کند.
در لایهٔ زیرساخت نیز شناخت وضعیت مرجع و حفظ شواهد تغییر اهمیت دارد. در «ثباتی که قابل اثبات و بازگشت نیست، امنیت نیست» تفاوت پایش عملیاتی با اثبات وضعیت پیکربندی و ضرورت نگه‌داشتن سوابق شکست پس از بازگشت را باز کرده‌ام؛ موضوعی که برای ادارهٔ تغییر زیرساخت این دستیار هم کاربرد دارد.
این چرخه باید در توافق با تأمین‌کننده و تقسیم مسئولیت‌های داخل سازمان قابل اجرا باشد. برای این کار، چند موضوع باید روشن شود:
موضوع توافق
چه چیزی باید روشن شود؟
آستانهٔ افت عملکرد
چه تغییری بررسی، اصلاح یا محدودسازی را فعال می‌کند؟
زمان اعلام و واکنش
چه کسی، در چه زمانی و از چه مسیری باید مطلع شود و اقدام کند؟
مسئول اصلاح و بازآموزی
تشخیص، اجرا و تأیید نتیجه بر عهدهٔ چه کسی است؟
حق ممیزی
سازمان چگونه به شواهد لازم برای بررسی عملکرد و تعهدها دسترسی دارد؟
انتقال دانش و دارایی
ادامهٔ ادارهٔ خدمت و انتقال آن به مسئول بعدی چگونه ممکن می‌شود؟
شرایط خروج و حذف داده
توقف همکاری، تحویل دارایی‌ها و تعیین تکلیف نسخه‌های داده چگونه انجام می‌شود؟
پایان عمر سامانه هم به تصمیم و سابقه نیاز دارد. باید معلوم باشد خدمت جایگزین چیست، چه دارایی‌هایی منتقل می‌شوند، چه داده‌هایی طبق توافق حذف می‌شوند و کدام سوابق لازم، با مسئول و مدت نگهداری مشخص باقی می‌مانند.
در درس چهاردهم دربارهٔ دارایی‌های لازم برای ادامهٔ خدمت صحبت کردیم. اینجا روشن می‌شود چرا تحویل آن‌ها باید از ابتدا در توافق دیده شود: امکان ادامه، اصلاح یا خروج، به دسترسی واقعی سازمان به همان دارایی‌ها و دانش وابسته است.
مدیر فناوری گفت: «تغییر نسخه یا منبع رو ثبت می‌کنیم و اثرش رو می‌سنجیم. برای بازشدن دوبارهٔ خدمت هم نتیجهٔ آزمون لازم داریم.»
مدیر عملیات پرسید: «در فاصلهٔ بررسی، اگر پاسخ‌گویی متوقف شد، درخواست‌ها کجا می‌رن؟»
«باید مسیر رسیدگی جایگزین مشخص باشه.»
مدیر مالی رو به مسئول قرارداد گفت: «تعهدهای بعد از تحویل، انتقال دانش و شرایط خروج رو هم تکمیل کنیم. می‌خوام معلوم باشه هزینه و مسئولیت ادامهٔ کار چیه.»
مدیرعامل برگه‌ای تازه روی میز گذاشت.
«حالا مصوبه رو بنویسیم. با همهٔ چیزهایی که تا اینجا روشن کردیم.»
مصوبهٔ نهایی؛ دربارهٔ یک قابلیت سازمانی تصمیم می‌گیریم
تصویر، گزینه‌های تصمیم را نشان می‌دهد؛ در این پرونده، شروع پایلوت به رفع نواقص و تأیید آزمون مستقل مشروط است.
اکنون به همان جلسهٔ آغاز مسیر برمی‌گردیم. این بار موضوع تصمیم روشن‌تر شده است. هیئت‌مدیره دربارهٔ قابلیتی تصمیم می‌گیرد که باید در سازمان کار کند، صاحب مسئولیت داشته باشد و در طول زمان قابل بازنگری بماند.
پروندهٔ این تصمیم، مسیر طی‌شده را به هم وصل می‌کند: مسئله و دامنه، مالک و حق تصمیم، معماری و داده، اثر و ریسک، امنیت و نظارت، قرارداد و پذیرش، بهره‌برداری و خروج.
اگر این اجزا جدا از هم بررسی شوند، ممکن است یکی از تصمیم‌ها اثر دیگری را خنثی کند. دامنهٔ استفاده محدود باشد، اما قرارداد تعهد گسترده‌ای ایجاد کند. حق توقف تعریف شده باشد، اما کسی مسئول ادامهٔ رسیدگی پس از توقف نباشد. آزمون موفق باشد، اما دارایی لازم برای ادارهٔ خدمت در اختیار سازمان قرار نگیرد.
مصوبه باید نتیجهٔ همین بررسی یکپارچه را بیان کند. چهار گزینه پیش روی مرجع تصمیم است: تصویب کامل، استقرار محدود و مشروط، تعلیق برای رفع نواقص و توقف. انتخاب هرکدام به وضعیت واقعی پرونده و اختیار مرجع تصمیم وابسته است.
تصویب کامل هم به دامنهٔ بررسی‌شده مربوط است. استقرار محدود و مشروط باید شرط‌های قابل بررسی داشته باشد. تعلیق باید نواقص و مسیر بازگشت به تصمیم را روشن کند. توقف نیز به تعیین تکلیف داده، دارایی، تعهدها و فرایند جایگزین نیاز دارد.
در روایت ما، شواهدِ تأیید نهایی آزمون مستقل هنوز ارائه نشده است. پس تصمیم نمی‌تواند وانمود کند که همهٔ شرط‌ها تحقق یافته‌اند. می‌توان اصل ادامهٔ مسیر را پذیرفت و فعال‌سازی پایلوت محدود را به رفع نواقص و تأیید آزمون‌ها وابسته کرد.
برای چنین تصمیمی، باید دامنهٔ کاربران و منابع، حدود اختیار دستیار، شروط فعال‌سازی، مسئول تأیید، زمان بازبینی و شرایط محدودسازی یا توقف روشن باشد. گسترش بعدی نیز به شواهد و تصمیم مربوط به همان گسترش نیاز دارد.
مسئولیت‌پذیری در همین اتصال‌ها دیده می‌شود: چه کسی شرط را بررسی می‌کند، چه کسی اجازهٔ استفاده می‌دهد و چه کسی در صورت تغییر شرایط اقدام می‌کند؟ تعداد عنوان‌های سازمانی اهمیت تعیین‌کننده‌ای ندارد؛ اجرای این مسئولیت‌ها اهمیت دارد.
مصوبه‌ای که بتوان آن را اجرا کرد
مدیرعامل متن را با صدای بلند خواند:
«اصل ادامهٔ مسیر دستیار سازمانی در دامنهٔ محدود پذیرفته می‌شود. فعال‌سازی پایلوت برای کاربران و منابع مشخص، پس از رفع نواقص ثبت‌شده و تأیید آزمون مستقل توسط مسئولان تعیین‌شده مجاز است. دستیار اختیار اقدام مستقل در فرایند خرید ندارد. هر گسترش دامنه، نیازمند بررسی و تصمیم بعدی است.»
مدیر عملیات گفت: «مسیر ارجاع و رسیدگی در زمان توقف رو هم در پیوست مشخص می‌کنیم.»
مسئول ریسک و انطباق ادامه داد: «به همراه شروط بازبینی، شواهد هر تأیید و صاحب اختیار محدودسازی.»
مدیر مالی به پوشهٔ قرارداد اشاره کرد: «تعهد پشتیبانی، انتقال دارایی و خروج هم باید پیش از فعال‌سازی، مطابق همین تصمیم تکمیل بشه.»
مدیر فناوری کنار صفحهٔ امضا نوشت: «نسخهٔ موضوع تصمیم و نتیجهٔ آزمون، پیوست شود.»
مدیرعامل پوشه را بست، اما آن را از روی میز برنداشت.
گفت: «جلسهٔ بعد، گزارش اجرای همین تصمیم رو می‌خوایم؛ شرط‌هایی که انجام شده و چیزهایی که هنوز بازه.»
روی جلد، زیر عنوان «دستیار سازمانی»، حالا چند واژهٔ دیگر هم دیده می‌شد: «مسئول»، «شواهد»، «حدود استفاده» و «بازبینی».
پایان‌بندی دوره؛ روایت اجرای مصوبه با امکانات موجود، همراه با کاربرگ‌های شروع، تقسیم مسئولیت و ثبت تصمیم.
مطالعهٔ مکمل: حکمرانی هوش مصنوعی با امکانات موجود؛ از مصوبه تا اجرا
صبحِ بعد از جلسه
ساعت هنوز نه نشده بود که مدیر عملیات، پوشهٔ مصوبه را روی میز گذاشت. اتاق جلسه پشت سرشان خالی بود. از راهرو صدای تلفن و گفت‌وگوی همکاران می‌آمد؛ سازمان به کار معمولش برگشته بود.
مدیر فناوری صفحهٔ امضا را نگاه کرد و گفت: «برای شروع، یه پیشنهاد ساختار آماده کنم؟»
«چه ساختاری؟»
«دبیرخانه، مسئول هماهنگی، شاید یه سامانه برای ثبت درخواست‌ها…»
مدیر عملیات صندلی را عقب کشید: «فعلاً همون آدم‌های دیروزیم، با همون کارهای قبلی. سؤال من اینه: امروز چه کاری می‌تونیم انجام بدیم؟»
چند دقیقه بعد، در اتاق مدیرعامل بودند.
مدیرعامل پرسید: «برای شروع چی لازم دارین؟»
مدیر عملیات گفت: «وقت مشخص از آدم‌هایی که مسئولیت دارن، اجازهٔ دسترسی به مدارک لازم، و معلوم‌بودن کسی که اختلاف رو حل می‌کنه.»
مدیرعامل تقویمش را باز کرد.
«وقت رو مشخص کنیم. اختیارها رو هم بنویسیم. یک ماه دیگه همین‌جا می‌بینیم چه چیزی واقعاً جلو رفته و کجا به تصمیم یا امکانات بیشتری نیاز داریم.»
مدیر فناوری پوشه را بست: «پس اول ببینیم چه کارهایی همین حالا در جریانه.»
در درس شانزدهم، جلسه به مصوبه‌ای رسید که فعال‌سازی پایلوت را به رفع نواقص و تأیید شواهد وابسته می‌کرد. این مکمل و پایان‌بندی دوره، اجرای همان تصمیم را از صبح بعد از جلسه دنبال می‌کند: وقتی سازمان با همان آدم‌ها و امکانات موجود باید برای مسئولیت‌ها وقت بگذارد، اختیارها را روشن کند و کار را پیش ببرد. یک ماهِ این داستان، فرصت پیشنهادی برای شروع و بازبینی است؛ زمان لازم در هر سازمان به وضعیت و دامنهٔ کار بستگی دارد.
روز اول؛ هوش مصنوعی منتظر مصوبه نمانده بود
نخستین گفت‌وگو کنار میز همکاران اتفاق افتاد؛ جایی که کار از قبل جریان داشت.
پیش از ظهر، کنار میز یکی از کارشناسان خرید ایستاده بودند. مدیر فناوری می‌خواست دربارهٔ سؤال‌های پرتکرار مقررات خرید بپرسد که کارشناس لپ‌تاپ را کمی چرخاند.
«من بعضی وقت‌ها برای مرتب‌کردن متن نامه از این استفاده می‌کنم.»
مدیر عملیات پرسید: «چه جور متن‌هایی؟»
کارشناس مکث کرد: «بیشتر جمله‌بندی. راستش دقیق نمی‌دونم چه چیزهایی رو مجازیم وارد کنیم.»
مدیر فناوری دفترچه‌اش را باز کرد. تا آن لحظه، نام این استفاده در هیچ‌کدام از فهرست‌های پروژه نبود.
در واحد بعدی، همکاری از خلاصه‌کردن مطالب عمومی گفت. یکی برای نوشتن پیش‌نویس پاسخ کمک می‌گرفت. دیگری گفت هنوز استفاده نکرده، چون نمی‌دانسته اجازه دارد یا نه.
مدیر عملیات کنار پنجره ایستاد و به یادداشت‌ها نگاه کرد.
«ما داشتیم برای دستیار جدید تصمیم می‌گرفتیم، ولی بخشی از استفاده از قبل شروع شده.»
آن‌ها در همان پروندهٔ مشترک سازمان، فهرستی باز کردند: کار مورد نظر، ابزار، نوع اطلاعات، کسی که خروجی را بررسی می‌کرد و جایی که نتیجه به کار می‌رفت. جاهایی هم خالی ماند. برای هر جای خالی، نام یک نفر و زمان پیگیری گذاشتند.
مدیر فناوری پرسید: «از همه بخوایم هر کاری کردن بفرستن؟»
«اول همون چیزهایی رو بپرسیم که برای فهمیدن وضعیت لازمه. لازم نیست متن همهٔ نامه‌ها و مکالمه‌ها رو جمع کنیم.»
عصر، یافته‌ها را به مدیرعامل گفتند. او خواست تا تعیین مسیر مجاز، حدود استفادهٔ موقت به کارکنان ابلاغ شود: در ابزارهای عمومی، متن‌های عمومی و غیرمحرمانه؛ خروجی با بازبینی انسانی؛ و هر استفادهٔ دیگر، از مسیر مسئول تعیین‌شده بررسی شود.
مدیر عملیات گفت: «باید یک نفر هم جواب سؤال همکارها رو بده. اگر فقط بگیم استعلام کنین و پاسخی نرسه، همون ابهام قبلی می‌مونه.»
نام مسئول پاسخ‌گویی و مسیر ثبت درخواست را هم مشخص کردند؛ با همان امکان ثبت درخواست داخلی که سازمان از قبل داشت.
روز اول، فهرست کامل نشده بود. اما برای اولین بار، استفاده‌هایی که دیده نمی‌شدند، صاحب سؤال و مسیر پیگیری پیدا کرده بودند.
پایان هفتهٔ اول؛ برای هر کلاه، یک صندلی تازه لازم نبود
قرار شد مسئولیت‌ها به کارهای مشخص و اختیار واقعی وصل شوند.
پنجشنبه، دور میز کوچکی در واحد عملیات نشستند. مدیر عملیات، مدیر فناوری، مسئول ریسک و یکی از کارشناسان باتجربهٔ خرید آمده بودند. پوشهٔ مصوبه میانشان باز بود.
کارشناس خرید گفت: «برای جواب این سؤال، فقط خوندن یک بخشنامه کافی نیست. تاریخ درخواست هم مهمه.»
مدیر فناوری پرسید: «چه کسی جواب مرجع رو تأیید می‌کنه؟»
«من می‌تونم موارد رو آماده کنم. جایی که اختلاف هست، باید مسئول صاحب اختیار نظر بده.»
مدیر عملیات روی برگه نوشت: «تهیهٔ موارد مرجع» و زیر آن: «تأیید اعتبار مقررات و حل اختلاف».
مسئول ریسک پرسید: «پس اگر دو سند با هم نخوندن، چه کسی باید پاسخ بده؟»
نام مسئول مربوط را نوشتند و موضوع را برای تأیید اختیارش به مدیرعامل ارجاع دادند. تا پیش از روشن‌شدن تعارض، آن مورد مبنای پاسخ قطعی دستیار قرار نمی‌گرفت.
مدیر فناوری گفت: «ثبت نسخه‌ها و نگهداری پرونده رو همکار من انجام می‌ده. هماهنگی اصلاح‌ها هم با خودم.»
مسئول ریسک به برگه نگاه کرد: «یک نفر می‌تونه چند مسئولیت داشته باشه. برای تأیید نهایی کاری که تیم خودت ساخته، بازبینی مستقل رو هم لازم داریم.»
قرار شد کارشناس خرید، صحت پاسخ‌های مرجع را بررسی کند؛ کنترل‌های دسترسی را همکار امنیتیِ خارج از تیم اجرا بازبینی کند؛ و صاحب فرایند، نتیجهٔ استفاده در کار واقعی را بپذیرد. نتیجهٔ هر بررسی با نام تأییدکننده و حدود تأییدش ثبت می‌شد.
مدیر عملیات گفت: «تهیهٔ سؤال‌ها رو هم می‌تونیم بین دو کارشناس تقسیم کنیم. مسئول جمع‌کردن و نهایی‌کردنش مشخص باشه.»
روی میز، هیچ حکم انتصاب تازه‌ای نبود. برگه‌ها نشان می‌دادند چه کسی چه کاری انجام می‌دهد، با چه اختیاری و تا چه زمانی. مسئولیت‌هایی که قبلاً در جملهٔ «واحد مربوطه پیگیری کند» پنهان می‌شدند، حالا نام و موعد داشتند.
در آخر جلسه، کارشناس خرید پرسید: «این کار به برنامهٔ قبلی من اضافه می‌شه؟»
مدیر عملیات لحظه‌ای به تقویم نگاه کرد.
«باید براش وقت باز کنیم. بررسی بعضی گزارش‌های غیرضروری رو جابه‌جا می‌کنیم. اگر باز هم زمان کم بود، همون رو برای تصمیم می‌بریم بالا.»
زیر نام هر مسئول، زمانی برای انجام کار گذاشتند. تازه آن وقت برگهٔ مسئولیت‌ها قابل اجرا شد.
هفتهٔ دوم؛ یک پروندهٔ کوچک، چند سؤال واقعی
قرار شد نخستین چرخه را روی همان دستیار پاسخ‌گو دربارهٔ مقررات خرید پیش ببرند. صاحب فرایند مشخص بود؛ سؤال‌های واقعی در دسترس بودند؛ و چند نقص شناخته‌شده، امکان بررسی اصلاح‌ها را فراهم می‌کرد.
درخواست دیگری برای اضافه‌کردن پاسخ‌گویی دربارهٔ مزایای کارکنان رسیده بود. مدیر عملیات آن را در فهرست نگه داشت و کنار آن نوشت: «نیازمند بررسی جداگانهٔ دامنه، منابع و ریسک».
بعد، صفحهٔ نخست پروندهٔ دستیار خرید را تکمیل کردند.
کارشناس خرید خواند: «پاسخ به سؤال‌های مشخص کارکنان مجاز، از منابع تأییدشدهٔ مقررات خرید، همراه با ارجاع به منبع.»
مدیر فناوری گفت: «حدود اختیار؟»
«توضیح و راهنمایی. تصویب، رد یا اجرای خرید با دستیار نیست.»
مسئول ریسک اضافه کرد: «در تعارض سند یا نبود منبع کافی، ارجاع به کارشناس. دسترسی هم در حدود مجوز همون کاربر.»
در چند سطر بعدی، نام صاحب فرایند، مسئول فنی، مرجع بازبینی و محل شواهد آمد. شرط فعال‌سازی هم از مصوبهٔ قبلی منتقل شد: رفع نواقص، تأیید آزمون مستقل و تکمیل تعهدهای لازم برای پشتیبانی و خروج.
پوشه هنوز کم‌حجم بود. اما هر جمله‌اش به یک کار یا مدرک مشخص می‌رسید.
برای شناخت وضعیت فعلی، چند درخواست واقعیِ قابل استفاده را در همان مسیر موجود بررسی کردند. معلوم شد بخشی از زمان پاسخ‌گویی صرف پیدا کردن آخرین نسخهٔ معتبر سند می‌شود.
کارشناس خرید دو فایل را باز کرد: «این دو تا هنوز هر دو بین همکارها می‌چرخه.»
مدیر فناوری به پاسخ نمونهٔ جلسهٔ قبل فکر کرد.
«پس قبل از آزمون دوباره، همین رو تعیین تکلیف کنیم.»
فهرست منابع معتبر با تأیید مسئول مربوط تکمیل شد. نسخهٔ منسوخ از منابع مجاز دستیار کنار رفت و مسیر به‌روزرسانی اسناد مشخص شد. اختلاف‌های حل‌نشده نیز در پرونده باقی ماندند، با انتظار ارجاع.
سپس نوبت موارد آزمون رسید. سؤال‌های عادی، سؤال‌های مبهم، تعارض سند و تفاوت مجوز کاربران را آماده کردند. پاسخ مرجع هر مورد بررسی شد. بخشی از موارد برای آزمون نهایی از تیم توسعه کنار گذاشته شد.
مدیر فناوری پرسید: «برای گزارش، یک امتیاز کلی هم بدیم؟»
مسئول ریسک گفت: «می‌تونیم داشته باشیم. نتیجهٔ موارد حساس رو هم جدا می‌خوام؛ به‌خصوص دسترسی و پاسخ قطعی از سند نامعتبر.»
کارشناس خرید به یکی از سؤال‌ها اشاره کرد: «اگر اینجا ارجاع بده، انتظار ما رو انجام داده. قرار نیست برای هر سؤال حتماً حکم صادر کنه.»
در پایان هفته، هنوز استفادهٔ کاربران پایلوت آغاز نشده بود. فهرست منابع، موارد مرجع و مسئول تأیید هر شرط روشن‌تر شده بود؛ و یک مشکل قدیمیِ گردش اسناد هم صاحب اقدام پیدا کرده بود.
هفتهٔ سوم؛ پیش از ورود کاربر، یک بار مسیر را طی کنیم
اولین بازبینیِ اصلاح‌ها، یک نقص دسترسی را دوباره باز کرد. در یک مورد آزمون، مرز مجوزها هنوز مطابق انتظار عمل نمی‌کرد.
مدیر فناوری گفت: «این مورد باید اصلاح بشه. شروع پایلوت رو عقب می‌بریم.»
مدیر عملیات تقویم را بست: «پس گزارش این هفته همین باشه؛ چه چیزی باقی مونده، مسئولش کیه و چه زمانی دوباره بررسی می‌شه.»
قرار سی‌روزه همچنان برقرار بود. موضوعِ گزارش روز سی‌ام می‌توانست آمادگی، تأخیر یا نیاز به تصمیم تازه باشد.
پس از اصلاح و تکرار آزمون، بازبین مستقل نتیجهٔ کنترل دسترسی را تأیید کرد. صحت منابع و رفتار ارجاع نیز در دامنهٔ مصوب بررسی شد. مسئول قرارداد تکمیل تعهدهای پشتیبانی، انتقال دارایی و خروج را ثبت کرد. صاحب اختیار، شواهد را دید و اجازهٔ شروع پایلوت را برای همان گروه و همان دامنه داد.
پیش از ورود کاربران، یک بار هم مسیر گزارش خطا را طی کردند.
کارشناس، درخواست آزمایشی را در مسیر داخلی ثبت کرد. درخواست به مسئول مربوط رسید، اما جانشین او برای زمان غیبت مشخص نبود.
نام جانشین را اضافه کردند. بعد، یک توقف آزمایشی در محیط پایلوت انجام دادند. کاربران باید می‌دانستند در این فاصله سؤال را به کدام مسیر موجود بفرستند و چه کسی دربارهٔ بازگشت خدمت تصمیم می‌گیرد.
وقتی مسیر یک بار طی شد، چند عبارت کلی در پرونده تغییر کرد. کنار «در اسرع وقت رسیدگی شود»، زمان و مسئول آمد. کنار «در صورت نیاز متوقف شود»، صاحب اختیار و شیوهٔ اعلام نوشته شد.
روز نخست استفاده، کاربران محدودِ پایلوت، حدود کار دستیار و راه گزارش خطا را می‌دانستند. پرونده، نسخهٔ مورد استفاده و شروط اجازه را نشان می‌داد.
چند روز بعد، یکی از کاربران نوشت: «این جواب به دردم نخورد.»
مدیر فناوری پرسید: «اشتباه جواب داده؟»
کارشناس خرید پاسخ را خواند: «متنش با منبع سازگاره، ولی معلوم نکرده قدم بعدیِ کاربر چیه.»
این مورد هم ثبت شد؛ با اصلاح پیشنهادی و آزمونی برای بررسی نتیجه. پایلوت تازه داشت تفاوتِ پاسخ صحیح و پاسخ قابل استفاده را در کار روزمره نشان می‌داد.
روز سی‌ام؛ گزارش کار، با چند خانهٔ باز
در جلسهٔ بازبینی، نتیجه‌ها و مسئله‌های باقیمانده کنار هم روی میز بودند.
یک ماه بعد، دوباره در اتاق جلسه بودند. این بار پوشهٔ مصوبه، چند برگهٔ استفاده‌شده و یادداشت‌های پیگیری هم داشت.
مدیرعامل پرسید: «چی جلو رفته؟»
مدیر عملیات گزارش را باز کرد.
«استفاده‌های شناخته‌شده رو ثبت کردیم؛ فهرست هنوز در حال تکمیله. برای دستیار خرید، منابع معتبر و حدود اختیار روشن شده. اصلاح‌های لازم و بازبینی مستقل انجام شده و پایلوت در همون دامنهٔ مصوب شروع شده. مسیر ارجاع و توقف رو هم یک بار طی کردیم.»
مدیر مالی پرسید: «ارزش استفاده چطور؟»
«برای بعضی سؤال‌ها، پیدا کردن منبع راحت‌تر شده. برای نتیجه‌گیری دربارهٔ صرفه‌جویی و هزینهٔ ادامه، به مشاهدهٔ بیشتری نیاز داریم. فعلاً پیشنهاد گسترش نمی‌دیم.»
مسئول ریسک یک برگه را جلو گذاشت: «این مورد هم بازه. با تغییر یکی از مسئولان، معلوم شد اختیار جانشین باید دوباره تأیید بشه. تا تأیید، اون دسته از درخواست‌ها از مسیر کارشناس رسیدگی می‌شه.»
مدیرعامل پرسید: «کسی پیگیریش می‌کنه؟»
مدیر عملیات به نام و موعد کنار برگه اشاره کرد.
«بله. نتیجه‌اش به همین پرونده اضافه می‌شه.»
مدیر فناوری گفت: «برای ادامه هم یک نیاز واقعی پیدا کردیم. کارشناس منابع، برای نگه داشتن فهرست اسناد وقت ثابت لازم داره. اگر استفاده بیشتر بشه، ظرفیت فعلی کافی نیست.»
مدیرعامل رو به مدیر عملیات گفت: «برای همین نیاز، پیشنهاد مشخص بیارین؛ با حجم کار و گزینه‌های تأمینش.»
او صفحهٔ نخست پرونده را دوباره خواند. هنوز همهٔ خانه‌ها پر نبود. اما سؤالِ باز، مسئول داشت؛ تأیید، به شواهد وصل بود؛ و استفاده، حد و مرز مشخص داشت.
در صورت‌جلسه نوشتند: پایلوت در دامنهٔ فعلی ادامه یابد؛ نتیجهٔ موارد باز و هزینهٔ ادارهٔ خدمت در بازبینی بعدی ارائه شود؛ گسترش استفاده تا تصمیم بعدی انجام نشود.
جلسه که تمام شد، مدیر عملیات پوشه را برداشت و از همان راهروی ماه قبل گذشت. کارشناس خرید از پشت میز صدایش زد:
«یه سؤال جدید رسیده. جوابش توی منابع فعلی نیست. از همون مسیر ارجاع بفرستم؟»
مدیر عملیات ایستاد.
«بله. ثبتش کن تا بررسی بشه.»
کارشناس درخواست را ثبت کرد. چند لحظه بعد، نام مسئول رسیدگی روی صفحه ظاهر شد.
شروع با امکانات موجود، به وقت مشخص، اختیار روشن و مسئول پیگیری نیاز دارد؛ همان چیزهایی که در روایت، برگهٔ مسئولیت‌ها را قابل اجرا کردند.
کاربرگ‌های اجرا
این پیوست همراه روایت «حکمرانی هوش مصنوعی با امکانات موجود؛ از مصوبه تا اجرا» است. برنامهٔ یک‌ماهه، قالبی برای شروع و بازبینی است؛ آماده‌نبودن شروط می‌تواند شروع استفاده را عقب بیندازد. معیار عبور، شواهد تحقق شروط است.
برنامهٔ شروع در روایت
بازه
کار
خروجی قابل بررسی
روزهای نخست
شناسایی استفاده‌های موجود، تعیین حدود موقت و مسیر پاسخ به سؤال کارکنان
فهرست اولیهٔ کاربردها و مسئول پیگیری ابهام‌ها
هفتهٔ اول
انتخاب کاربرد، تقسیم کلاه‌ها، تأیید اختیارها و اختصاص وقت
دامنهٔ اولیه و مسئولیت‌های قابل اجرا
هفتهٔ دوم
تکمیل پرونده، تعیین منابع معتبر، شناخت روش فعلی و آماده‌سازی آزمون
موارد مرجع، خط مبنا و شواهد آمادهٔ ارزیابی
هفتهٔ سوم
اصلاح، بازبینی مستقل، تکمیل تعهدها و تمرین ارجاع و توقف
اجازهٔ محدود در صورت تحقق شروط؛ یا ثبت تأخیر و اقدام لازم
هفتهٔ چهارم
مشاهدهٔ استفادهٔ محدود در صورت صدور اجازه، ثبت خطا و بررسی هزینه و ارزش
پیشنهاد ادامه، اصلاح، محدودسازی یا توقف
بازبینی پایان ماه
بررسی شواهد و مسائل باز توسط صاحب اختیار
تصمیم ثبت‌شده با دامنه، مسئول و موعد بعدی
نمونهٔ پروندهٔ کاربرد در داستان
موضوع
نمونهٔ ثبت
کاربرد
راهنمایی دربارهٔ مقررات خرید از منابع تأییدشده
مسئله
پیدا کردن حکم معتبر و مسیر رسیدگی، میان اسناد پراکنده و گاه متعارض
کاربران
گروه مشخص و مجاز پایلوت؛ فهرست نام‌ها و مجوزها در پیوست سازمانی
منابع
فهرست اسناد مصوب با نسخه، اعتبار، مجوز و مسئول به‌روزرسانی مشخص
اختیار
توضیح و راهنمایی همراه با ارجاع به منبع
خارج از دامنه
تصویب، رد یا اجرای مستقل خرید؛ پاسخ‌گویی دربارهٔ مزایای کارکنان
رفتار در ابهام
ارجاع به مرجع مشخص در نبود منبع کافی یا تعارض حل‌نشده
صاحب فرایند
مدیر عملیات در روایت؛ تأیید مقررات توسط مسئول صاحب اختیار
مسئول فنی
مدیر فناوری و همکاران تعیین‌شده در دامنهٔ وظایفشان
داوری
بازبینی محتوایی توسط صاحب صلاحیت و بازبینی کنترل‌های دسترسی توسط فرد خارج از تیم اجرا؛ تأیید نهایی با صاحب اختیار
شواهد پذیرش
نسخهٔ سامانه و منابع، موارد مرجع، آزمون مستقل، نتیجهٔ تفکیک‌شدهٔ موارد حساس، رفع نواقص و تأییدها
شروط فعال‌سازی
تأیید شواهد لازم، تکمیل تعهدهای پشتیبانی و خروج، آموزش کاربران و آماده‌بودن ارجاع، توقف و مسیر جایگزین
وضعیت پایان روایت
ادامهٔ پایلوت در دامنهٔ فعلی؛ بدون گسترش تا تصمیم بعدی
موارد باز
تأیید اختیار جانشین، شواهد بیشتر دربارهٔ ارزش و هزینه، بررسی ظرفیت نگهداری منابع
محل سابقه
پروندهٔ مشترک با دسترسی متناسب؛ ثبت درخواست‌ها در مسیر داخلی موجود
این نمونه، وضعیت روایی را ثبت می‌کند. برای کاربرد واقعی، نام اشخاص، نسخه‌ها، معیارها و حدهای پذیرش، زمان واکنش، صاحب اختیار توقف و موعد بازبینی باید دقیق تکمیل شوند.
کلاه‌ها و مسئولیت
در درس دوم دیدیم چرا مسئولیت‌ها را باید مستقل از تعداد پست‌های سازمانی مشخص کرد. این برگه، همان منطق را به اقدام و اختیار هر فرد وصل می‌کند.
مسئولیت
اقدام مورد انتظار
نکتهٔ اجرایی
صاحب کاربرد
پذیرش مسئله، دامنه و ارزش مورد انتظار
اختیار تصمیم باید تأیید شده باشد
متولی منبع
تعیین اعتبار و نسخهٔ منابع و پیگیری تغییر آن‌ها
چند نفر می‌توانند موارد را آماده کنند؛ مسئول نهایی‌کردن مشخص باشد
مجری فنی
اجرا، اصلاح، ثبت نسخه و تهیهٔ شواهد فنی
نتیجهٔ کار خود را به‌تنهایی داوری نهایی نمی‌کند
بازبین
سنجش مستقل در حوزهٔ صلاحیت
استقلال از اجرای مورد بررسی برقرار باشد
نگهدارندهٔ پرونده
اتصال شواهد و تصمیم‌ها و پیگیری به‌روزرسانی
اختیار تأیید محتوای تخصصی جدا روشن شود
صاحب تصمیم
اجازهٔ استفاده، تغییر دامنه، محدودسازی یا توقف
تصمیم، دلیل، شواهد و حدود اختیار ثبت شوند
این‌ها کلاه‌اند: یک نفر می‌تواند چند مسئولیت داشته باشد و چند نفر می‌توانند در یک مسئولیت مشارکت کنند. زمان انجام کار، پاسخ‌گویی نهایی و تعارض نقش‌ها باید روشن بمانند.
فرم کوتاه برای کاربرد خودتان
برای تکمیل ردیف خطاهای مهم و حدهای پذیرش، «دقت ۹۵ درصد برای کارخانه چه معنایی دارد؟» مثال عددی روشنی از تبدیل درصد دقت به هزینهٔ خطا و بار بررسی انسانی دارد. معیار این برگه را با پیامد واقعی استفاده در سازمان خودتان تنظیم کنید.
