در اتاق جلسه
چراغ‌های ساختمان‌های روبه‌رو روشن شده بود. روی نمایشگرهای اتاق، نمودارها هنوز بالا و پایین می‌رفتند، اما توجه همه به مدیرعامل بود که کنار نمایشگر ایستاده بود. حتما چیز مهمی بود که همه رو دعوت به جلسه کرده بود. مدیرعامل از جایش بلند شد، یک دست را روی میز گذاشت و گفت:
«تا سه ماه دیگه یک دستیار هوش مصنوعی می‌خوام. چیزی که همه کارکنان بتونن باهاش کار کنن، اطلاعات سازمان رو بشناسه و کارها رو براشون ساده‌تر کنه. نمی‌خوام هر بار برای پیدا کردن یک جواب یا انجام یک کار، چند نفر درگیر بشن.»
مدیر مالی خودکارش را روی دفتر گذاشت. در ذهنش داشت هزینه اشتراک، خرید سرور و نیروی انسانی موردنیاز را حساب می‌کرد.
پرسید: «برای این کار چقدر بودجه در نظر گرفتیم؟ اصلاً قراره محصول آماده بخریم یا هزینه توسعه بدیم؟»
مدیر فناوری سرش را بلند کرد: «بستگی داره. باید مشخص کنیم از سرویس‌های خارجی استفاده می‌کنیم یا مدل رو داخل زیرساخت خودمون مستقر می‌کنیم.»
مسئول امنیت حرفش را قطع کرد: «هنوز معلوم نیست چه اطلاعاتی قراره در اختیارش قرار بگیره. اگر به اسناد سازمان دسترسی داشته باشه، چطور مطمئن بشیم هر کارمند فقط اطلاعات مجاز خودش رو می‌بینه؟»
مدیر منابع انسانی که تا آن لحظه مشغول فکر کردن بود، گفت: «من فکر می‌کنم بهترین نقطه شروع، آموزش کارکنان باشه. مثلاً یک نیروی تازه‌وارد به‌جای اینکه برای هر سؤال سراغ همکارانش بره، از دستیار می‌پرسه. حتی می‌تونه مراحل اداری و فرایندهای داخلی رو بهش یاد بده.»
مدیر مالی برگشت و پرسید: «یعنی فقط جواب سؤال‌ها رو می‌ده؟ نمی‌تونه خودش مثلاً درخواست خرید ثبت کنه یا گزارش هزینه‌ها رو آماده کنه؟»
مدیر فناوری گفت: «اگر بخوایم، می‌تونیم به سامانه‌های داخلی هم متصلش کنیم.»
مدیر امنیت دوباره وارد بحث شد: «پس دیگه فقط بحث دسترسی به اطلاعات نیست. داریم درباره اجازه انجام عملیات در سامانه‌های سازمان صحبت می‌کنیم.»
آن سوی میز، مدیر حقوقی به موضوع دیگری فکر می‌کرد. گفت: «فرض کنید دستیار به یکی از کارکنان توصیه‌ای بکنه و اون کارمند بر اساسش تصمیم اشتباهی بگیره. یا حتی خودش یک اقدام انجام بده. در این صورت مسئولیت با کیه؟ چه کسی باید پاسخ‌گو باشه؟»
یکی از مدیران که تجربه کار با ابزارهای هوش مصنوعی عمومی را داشت، با تردید گفت: «من هنوز به این پاسخ‌ها اعتماد ندارم. چند بار جواب‌هایی گرفتم که با اطمینان کامل بیان می‌شدن، ولی اساساً اشتباه بودن. از کجا معلوم این یکی هم همون‌طور نباشه؟»
مدیر فناوری خواست توضیح بدهد که می‌توان با اتصال دستیار به اسناد معتبر سازمان و کنترل منابع پاسخ، احتمال خطا را کاهش داد؛ اما مدیر امنیت هنوز درباره محرمانگی اطلاعات سؤال داشت و مدیر حقوقی منتظر پاسخ مسئولیت بود.
مدیرعامل به صورت‌های دور میز نگاه کرد. هرکس داشت درباره چیزی حرف می‌زد که به نظر خودش مهم‌ترین بخش دستیار هوش مصنوعی بود. یکی به دنبال کاهش هزینه بود، دیگری افزایش بهره‌وری، یکی نگران اطلاعات محرمانه بود و دیگری به خطا و مسئولیت فکر می‌کرد.
گفت: «ظاهراً من یک دستیار خواستم، ولی شما هرکدوم دارید درباره یک چیز متفاوت صحبت می‌کنید!»
برای چند لحظه سکوت برقرار شد.
مدیر فناوری نگاهی به بقیه انداخت و پرسید:
«شاید قبل از اینکه تصمیم بگیریم چطور بسازیمش، باید اول بفهمیم اصلاً منظورمون از دستیار هوش مصنوعی چیه. دستیار برای انجام چه کاری؟ و قرار است تا کجا اختیار داشته باشه؟»
روایت بالا فقط یک قصه نیست. صورت فشردهٔ موقعیتی است که با ورود هوش مصنوعی به یک سازمان می‌تواند شکل بگیرد: مدیران بر سر آغاز کار توافق دارند، اما از محصول مورد انتظار، حدود استفاده و مسئولیت نتیجه، برداشت مشترکی ندارند.
در این جلسه هنوز مدلی انتخاب نشده، قراردادی امضا نشده و سروری خریداری نشده است. بااین‌حال، تصمیم‌هایی پیش روی سازمان قرار گرفته که بر همهٔ این انتخاب‌ها اثر می‌گذارند.
حکمرانی هوش مصنوعی از همین تصمیم‌ها آغاز می‌شود.
هر واحد بخشی از مسئله را می‌بیند
در نگاه نخست، ممکن است واکنش‌های اعضای جلسه به صورت موانعی در برابر اجرای پروژه دیده شوند: مالی نگران هزینه است، امنیت محدودیت ایجاد می‌کند و حقوقی دربارهٔ مسئولیت سؤال دارد. اما هرکدام بخشی از مسئله‌ای را می‌بینند که برای تصمیم سازمان ضروری است.
سامانه‌ای که از نظر فنی کار می‌کند، ممکن است هزینهٔ بهره‌برداری نامتناسبی داشته باشد. راهکاری که سریع راه می‌افتد، ممکن است به داده‌ای دسترسی بخواهد که استفاده از آن مجاز نیست. پاسخی که برای آموزش عمومی کارکنان مناسب است، ممکن است برای تصمیم دربارهٔ حقوق استخدامی آن‌ها قابل اتکا نباشد.
مسئله و هدف، تصمیم و مسئولیت، داده و دانش، معماری و فناوری، ریسک و کنترل، امنیت و اعتماد، ارزیابی و پایش، و قرارداد و تأمین‌کننده به هم وابسته‌اند. انتخاب در هر بخش می‌تواند گزینه‌های بخش‌های دیگر را تغییر دهد. استفاده از یک خدمت بیرونی، برای مثال، هم بر زمان اجرا اثر دارد، هم بر محل پردازش داده، هزینهٔ مصرف، استمرار خدمت و امکان تغییر تأمین‌کننده.
سازمان باید بتواند میان این ملاحظات تصمیم بگیرد. اگر چنین سازوکاری نداشته باشد، هر واحد بر اساس برداشت خود پیش می‌رود و اختلاف‌ها هنگام اتصال اجزا یا تحویل پروژه آشکار می‌شوند.
مدیرعامل دوباره نشست. رو به مدیر منابع انسانی کرد: «شما از این دستیار چه انتظاری دارید؟»
«پرسنل جدید سؤال‌هاشون رو ازش بپرسن؛ دربارهٔ فرایندها، آیین‌نامه‌ها، کارهای اداری.»
یکی از مدیران گفت: «خوب، اگر آیین‌نامه رو می‌فهمه، درخواست‌ها رو هم بررسی کنه. چرا دوباره بفرستیم برای کارشناس؟»
مسئول امنیت پرسید: «یعنی به پروندهٔ افراد هم دسترسی داشته باشه؟»
مدیر فناوری گفت: «این‌ها دو دامنهٔ متفاوتن.»
هنوز کسی با ساختن دستیار مخالفت نکرده بود. تازه داشت معلوم می‌شد هرکس چه دستیاری را تصور کرده است.
پشت این مسئله‌ها چهار کارکرد قرار دارد
برای اداره کردن این مجموعهٔ به‌هم‌پیوسته، به روشی نیاز داریم که پرسش‌ها را به تصمیم و اقدام متصل کند. با الهام از چارچوب مدیریت ریسک هوش مصنوعی 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 نیز مقررهٔ حقوقی اتحادیهٔ اروپا با رویکرد مبتنی بر ریسک است.
در این دوره، از این منابع برای منظم کردن تصمیم‌های سازمان کمک می‌گیریم: شناخت کاربرد، تعیین نقش‌ها، ارزیابی اثر، تعریف کنترل، مستندسازی و بازنگری. استفادهٔ آموزشی از یک مقرره نیز به معنای تعمیم الزام‌های آن به همهٔ سازمان‌ها و کشورها نیست.
نام این چارچوب‌ها زمانی برای پروندهٔ ما مفید می‌شود که در تصمیم واقعی اثر بگذارد. اگر مسئول صحت منابع معلوم نباشد، افزودن نام یک استاندارد به مستند پروژه آن مسئولیت را ایجاد نمی‌کند. اگر آزمون فقط چند پاسخ منتخب را نشان دهد، اشاره به یک چارچوب مدیریت ریسک، جای شواهد ارزیابی را نمی‌گیرد.
برای روشن‌ترشدن تفاوت استاندارد، کنترل و سازوکار اجرا، از STIG و CIS تا RBAC یک نمونهٔ فنی از همین تفکیک در امنیت سیستم‌عامل ارائه می‌کند.
در ادامهٔ دوره، نگاشت این چارچوب‌ها به تصمیم‌های واقعی سازمان را در شش محور بررسی می‌کنیم. اساس حکمرانی هوش مصنوعی در سازمان را در همین شش محور تشریح خواهیم کرد:
- حق تصمیم و ساختار حکمرانی: مالک مسئله، نقش‌ها و اختیار تصمیم‌گیری در مراحل مختلف کار.
- قلمرو و صورت‌بندی مسئله: مرز کاربرد، کاربران، داده‌ها و کارهایی که سامانه مجاز است انجام دهد.
- اثر، ریسک و سطح اختیار: شدت و برگشت‌پذیری پیامدها و میزان اختیار و نظارت متناسب با آن‌ها.
- معماری، داده و قابلیت سازمانی: تناسب راهکار با داده‌های موجود، ظرفیت سازمان و نیازهای مقیاس‌پذیری و قابلیت اطمینان.
- امنیت، مسئولیت و نظارت انسانی: حفاظت از سامانه، پاسخ‌گویی و امکان مداخلهٔ انسان در تصمیم‌ها و اقدامات آن.
- قرارداد، پذیرش و بهره‌برداری: تعهدات تأمین‌کننده، شواهد ارزیابی، شرایط پذیرش، پایش خدمت و امکان خروج از آن.
مدیر مالی پرسید: «برای این بررسی اولیه هم باید یک ساختار جدید درست کنیم؟»
مدیرعامل به یادداشت‌هایش نگاه کرد: «اول با همین مسئولیت‌های فعلی شروع کنیم. ببینیم کجا اختیار یا مسئول مشخص نداریم.»
مدیر حقوقی گفت: «و تصمیم‌هایی که می‌گیریم ثبت بشه. بعداً قرار نیست دوباره دربارهٔ اینکه منظور جلسه چی بوده، بحث کنیم.»
برگه‌ای که قرار بود در آن فقط نام یک پروژه و مهلت تحویل نوشته شود، حالا داشت به صورت‌جلسهٔ چند تصمیم مشخص تبدیل می‌شد.
این پرونده هنوز خام است
درخواست اولیه کمی روشن‌تر شده است. سازمان می‌خواهد امکان پاسخ‌گویی به پرسش‌های پرتکرار کارکنان را با تکیه بر اسناد معتبر بررسی کند. دامنهٔ پیشنهادی، تصمیم‌گیری دربارهٔ اشخاص و دسترسی به پرونده‌های شخصی را در بر نمی‌گیرد.
اما هنوز پرسش‌های مهمی باقی مانده است. چه کسی مالک این مسئله است؟ اعتبار و به‌روزرسانی منابع را چه کسی تضمین می‌کند؟ چه خطاهایی برای این کاربرد مهم‌اند؟ چه شواهدی برای پذیرش آزمایش لازم است؟ و اگر نتیجه مناسب نبود، چه کسی دربارهٔ اصلاح، محدودسازی یا توقف تصمیم می‌گیرد؟
هر مدیر هنوز بخشی از پرونده را در دست دارد. کار حکمرانی این است که رابطهٔ این بخش‌ها را روشن کند و سازمان را قادر سازد بر مبنای آن‌ها تصمیم بگیرد.
در این مرحله، دستاورد جلسه می‌تواند تعریف یک آزمایش محدود و پرسش‌هایی باشد که باید پاسخ بگیرند. آزمایش شاید نشان دهد کیفیت منابع باید اصلاح شود، شاید نیاز به تغییر راهکار را آشکار کند و شاید شواهد کافی برای گسترش خدمت به دست دهد. ارزش آن در این است که نتیجه بتواند تصمیم بعدی سازمان را تغییر دهد.
پایان جلسه
جلسه رو به پایان بود. مدیرعامل مهلت سه‌ماهه را خط نزد، اما کنار آن نوشت: «دامنه و شرایط بهره‌برداری باید مشخص شود.»
بعد گفت: «پیشنهاد آزمایش محدود رو آماده کنید؛ با منابع معتبر، بدون دسترسی به پروندهٔ افراد، و با روشی که بشه نتیجه‌اش رو سنجید.»
مدیر فناوری سر تکان داد. مدیر منابع انسانی پوشهٔ آیین‌نامه‌ها را جلو کشید. مدیر مالی پرسید هزینهٔ این مرحله چه زمانی برآورد می‌شود.
مدیرعامل خودکار را روی میز گذاشت و پرسید: «یک نفر هم باید پیگیر نتیجهٔ این کار باشه. مسئولش کیه؟»
مدیر فناوری به مدیر منابع انسانی نگاه کرد. مدیر منابع انسانی گفت: «ما محتوای کار رو می‌دیم، ولی سامانه دست ما نیست.»
هنوز کسی از اتاق بیرون نرفته بود که مسئلهٔ بعدی روی میز آمد: چه کسی مسئول کدام تصمیم است؟
در این مجموعه، ارجاع به یک چارچوب یا استاندارد به معنای اثبات تجربی برتری همهٔ سازوکارهای پیشنهادی نیست. الزامات منبع، صورت‌بندی‌های آموزشی مدرس و مثال‌های فرضی باید از هم قابل تشخیص باشند. چهار کلاه مسئولیت و هفت دروازهٔ تصمیم، ابزارهای آموزشی این دوره‌اند؛ تعداد و عنوان آن‌ها نسخهٔ واحدی برای همهٔ سازمان‌ها نیست.
این مجموعه بر پایهٔ مباحث دورهٔ «حکمرانی هوش مصنوعی در سازمان» در DBA هوش مصنوعی در کسب‌وکار تدوین شده است. اسلایدهای کامل دوره