مدیر عملیات فهرستی را که در پایان جلسهٔ قبل باز کرده بود، روی نمایشگر آورد. بالای صفحه نوشته بود: «درخواست‌های هوش مصنوعی واحدها».

ردیف اول، کنترل روشنایی ساختمان بود. ردیف دوم، داشبورد فروش. بعد، ثبت‌نام هوشمند دوره‌های آموزشی، جست‌وجوی اسناد و پیشنهاد پاسخ به درخواست‌های کارکنان آمده بود.

مدیرعامل پرسید: «برای همهٔ این‌ها باید همون نقش‌ها و دروازه‌های تصمیم رو تعیین کنیم؟»

مدیر مالی به ردیف ثبت‌نام اشاره کرد: «این قرار بود فرم بگیره، ظرفیت رو کنترل کنه و پیام تأیید بفرسته. کجاش هوش مصنوعیه؟»

مدیر عملیات گفت: «اسم پیشنهادی واحد، ثبت‌نام هوشمنده.»

مدیر فناوری پرسید: «روشنایی هم با حسگر و ساعت کار می‌کنه یا قراره از داده‌ها چیزی یاد بگیره و پیش‌بینی کنه؟»

مسئول ریسک و انطباق گفت: «حتی اگر هوش مصنوعی نباشه، ایمنی و امنیتش مهمه. ولی کنترل‌هایی که برای رفتار مدل می‌خوایم، باید معلوم باشه کجا موضوعیت دارن.»

مدیرعامل به عنوان بالای فهرست نگاه کرد. تا چند دقیقه پیش، فکر می‌کرد مسئله فقط تقسیم بودجه میان چند پروژهٔ تازه است. حالا باید معلوم می‌شد این فهرست، اصلاً فهرست چه چیزهایی است.

گفت: «قبل از اینکه مسیر تصویبشون رو تعیین کنیم، روشن کنیم هرکدوم واقعاً چه کاری انجام می‌ده و چطور.»

در درس سوم، حق پیشنهاد، ارزیابی، تصویب و توقف را برای کاربرد و دامنهٔ مشخص دستیار روشن کردیم. همچنین دیدیم که عبور از هر مرحله به شواهد و مرجع تصمیم معلوم نیاز دارد.

فهرست تازهٔ مدیر عملیات، دامنهٔ همان تصمیم‌ها را به پرسش می‌کشد. کنترل روشنایی، داشبورد فروش و پیشنهاد پاسخ، همگی زیر عنوان هوش مصنوعی آمده‌اند؛ اما به روش یکسانی کار نمی‌کنند. پیش از تعیین مسیر حکمرانی آن‌ها، باید روش تولید خروجی و نقش آن در تصمیم و اقدام را بشناسیم. نام‌هایی مانند «هوشمند» و «خودکار» این شناخت را فراهم نمی‌کنند.

با این درس، قسمت اول بخش دوم دوره را آغاز می‌کنیم: تشخیص قلمرو حکمرانی.

هوشمندسازی یا هوش مصنوعی

هوشمندسازی یا هوش مصنوعی؛ اتصال، حسگر، کنترل و اتوماسیون در برابر استنباط، پیش‌بینی، تولید و توصیه
متصل شدن تجهیزات و خودکار شدن عملیات، به‌تنهایی وجود هوش مصنوعی را نشان نمی‌دهد.

هوشمندسازی، که در ادبیات ما برداشتی غلط از کلمه Automation یا خودکارسازی است، می‌تواند شامل اتصال تجهیزات، دریافت داده از حسگر، کنترل از راه دور یا اجرای خودکار یک فرایند باشد. چراغی که با حضور فرد روشن می‌شود، تجهیزی که وضعیت خود را ارسال می‌کند یا سامانه‌ای که در ساعت معین فرمانی را اجرا می‌کند، همه این‌ها می‌توانند خودکار باشند، اما لزوماً از هوش مصنوعی استفاده نمی‌کنند.

در مقابل، در بحث هوش مصنوعی با استنباط خروجی از ورودی سروکار داریم؛ خروجی می‌تواند پیش‌بینی، توصیه، محتوا یا تصمیم باشد. برای مثال، سامانه‌ای ممکن است از وضعیت تجهیزات، احتمال خرابی را برآورد کند یا از روی اسناد، پاسخ یک پرسش را تولید کند.

این دو حوزه می‌توانند در یک راهکار کنار هم قرار بگیرند. حسگر، داده جمع می‌کند؛ مدل، از داده استنباط می‌کند؛ سامانهٔ کنترل، اقدامی را اجرا می‌کند. برای حکمرانی باید بدانیم هر بخش چه نقشی دارد و خطا یا اختلال در آن چه پیامدی ایجاد می‌کند.

تفاوت فنی چه تغییری در حکمرانی ایجاد می‌کند

مقایسه هوش مصنوعی با هوشمندسازی از منظر ماهیت، خروجی، ریسک، مالک و پیام حکمرانی
با وارد شدن استنباط و اثرگذاری بر تصمیم، بررسی رفتار سامانه و مسئولیت پیامد اهمیت بیشتری پیدا می‌کند.

در یک سامانهٔ متصل یا خودکار، پرسش‌هایی مانند صحت دریافت داده، امنیت تجهیزات، ایمنی و تداوم عملیات مهم‌اند. اگر فرمان از پیش تعریف‌شده باید در شرایط معینی اجرا شود، باید بتوانیم صحت همین منطق و اجرای آن را بررسی کنیم.

وقتی یک مدل آموخته‌شده یا دانش‌محور در تولید خروجی نقش دارد، پرسش‌های دیگری هم اضافه می‌شوند: خروجی در چه شرایطی قابل اتکاست؟ چه خطاهایی دارد؟ آیا برای این کاربرد ارزیابی شده است؟ انسان در کدام نقطه باید مداخله کند و مسئول پیامد استفاده کیست؟

این تفاوت، ریسک‌های قبلی را حذف نمی‌کند. یک راهکار هوش مصنوعی متصل به تجهیزات، همچنان به ایمنی و امنیت زیرساخت نیاز دارد. کنترل‌های مربوط به رفتار مدل و تصمیم، بر آن‌ها افزوده می‌شوند.

پیام این مقایسه برای مدیر آن است که ترکیب مسئولیت‌ها را با ماهیت واقعی راهکار تنظیم کند. عملیات، مهندسی و فناوری در ادارهٔ تجهیزات نقش دارند؛ با ورود استنباط و تصمیم‌سازی، مسئولیت کسب‌وکار و پیگیری ریسک نیز باید در همان پرونده روشن شود.

مدیر عملیات توضیح داد: «روشنایی فعلاً با حسگر حضور و برنامهٔ زمانی کنترل می‌شه.»

مدیر فناوری گفت: «پس این درخواست رو با همین مشخصات ثبت کنیم. اگر بعداً پیشنهاد پیش‌بینی مصرف یا تشخیص وضعیت اضافه شد، اون بخش رو جدا بررسی می‌کنیم.»

مسئول ریسک و انطباق گفت: «و خروج از فهرست هوش مصنوعی، کنترل ایمنی و امنیت ساختمان رو حذف نمی‌کنه.»

مدیر مالی کنار ردیف اول نوشت: «کنترل روشنایی با حسگر و برنامهٔ زمانی». کلمهٔ «هوشمند» دیگر تنها توضیح آن ردیف نبود.

داشبورد گزارش می‌دهد یا سامانه تصمیم می‌سازد

هوش تجاری، تحلیل یا تصمیم خودکار؛ تفاوت نقش، خروجی، جایگاه انسان و پیام حکمرانی
برای تعیین کنترل‌ها، باید دید گزارش، پیش‌بینی یا توصیه چگونه وارد تصمیم و اقدام می‌شود.

داشبورد می‌تواند داده‌ها را گردآوری و شاخص‌ها را نمایش دهد. در این وضعیت، پرسش‌های اصلی دربارهٔ کیفیت و تبار داده، سطح دسترسی، تعریف درست شاخص و تفسیر گزارش‌اند. مدیر با اتکا به گزارش، تصمیم می‌گیرد.

حال فرض کنیم همان محیط، فروش دورهٔ بعد را پیش‌بینی کند، برای مشتریان امتیاز بسازد یا پیشنهاد تخصیص منابع بدهد. باید معلوم شود این خروجی با چه روشی تولید شده و چگونه در تصمیم به کار می‌رود. اگر در تولید آن از هوش مصنوعی استفاده شده باشد، عملکرد مدل، خطا، سوگیری و حدود استفاده هم باید بررسی شوند.

گام بعدی، اتصال خروجی به اقدام است. نمایش یک پیشنهاد با اجرای خودکار آن تفاوت دارد. کاربری که می‌تواند پیشنهاد را بررسی و اصلاح کند، در موقعیت متفاوتی با انسانی است که فقط پس از اجرای تصمیم از نتیجه مطلع می‌شود.

این مرزها با ظاهر صفحه مشخص نمی‌شوند. یک داشبورد ممکن است صرفاً گزارش دهد یا در پشت آن، پیش‌بینی و توصیه تولید شود. یک رابط گفت‌وگو هم ممکن است فقط پاسخ ذخیره‌شده را نمایش دهد یا از مدل برای ساخت پاسخ استفاده کند.

نمونهٔ عملیِ خروجی کوتاهی که در تصمیم اثر می‌گذارد را در Jev و Laya؛ وقتی هوش مصنوعی به‌جای حرف زدن تصمیم می‌گیرد بررسی کرده‌ام؛ یک برچسب یا امتیاز هم می‌تواند مسیر رسیدگی به درخواست را تغییر دهد.

شدت حکمرانی را باید با توجه به اثر سامانه بر تصمیم و اقدام تعیین کرد؛ داشتن داشبورد یا الگوریتم، پاسخ نهایی این پرسش نیست.

مدیر مالی دربارهٔ داشبورد فروش گفت: «نسخهٔ فعلی فقط فروش شعب رو کنار هم نشون می‌ده.»

مدیر عملیات پاسخ داد: «در درخواست جدید نوشته‌ن سهمیهٔ ماه بعد رو هم پیشنهاد بده.»

مدیر فناوری پرسید: «بر اساس یک فرمول مشخص یا یک مدل پیش‌بینی؟»

مدیرعامل گفت: «پس این‌ها رو در یک ردیف مبهم ننویسیم. گزارش فعلی یک کاره، پیش‌بینی و پیشنهاد سهمیه کارهای دیگه‌ای هستن.»

ردیف دوم فهرست، به توضیح دقیق‌تری از خروجی و نقش آن در تصمیم نیاز داشت.

کارکرد سامانه به‌تنهایی هوش مصنوعی بودن را ثابت نمی‌کند

عبارت‌هایی مانند «پیش‌بینی»، «تشخیص» و «توصیه» توضیح می‌دهند که سامانه قرار است چه کمکی بکند؛ اما برای شناخت ماهیت فنی آن کافی نیستند. باید بدانیم این خروجی چگونه تولید می‌شود و چه روشی پشت آن قرار دارد.

نکته مهم این است که هوش مصنوعی را نباید با هوش مصنوعی مولد یکی گرفت. تولید متن، تصویر، صدا و کد تنها یکی از خانواده‌های فناوری هوش مصنوعی است. در بسیاری از کاربردهای صنعتی، اتفاقاً مدل‌های غیرمولد کاربردی‌تر، اقتصادی‌تر و قابل اتکاترند.

برای مثال، سامانه‌ای که از روی تصویر قطعه، عیب سطحی را تشخیص می‌دهد، الزاماً چیزی تولید نمی‌کند. مدلی که احتمال خرابی یک تجهیز را بر اساس دما، لرزش و سابقه عملکرد پیش‌بینی می‌کند، متن یا تصویر نمی‌سازد. سامانه‌ای که مصرف انرژی را بهینه می‌کند، محصولش ممکن است صرفاً یک نقطه تنظیم یا برنامه عملیاتی باشد. این‌ها می‌توانند نمونه‌هایی از کاربرد هوش مصنوعی باشند، بدون آنکه مولد باشند.

کارکرد سامانه به‌تنهایی هوش مصنوعی بودن آن را ثابت نمی‌کند؛ مسیرهای بینش و اقدام
توصیف، تشخیص، پیش‌بینی، توصیه، استدلال، تولید محتوا و اقدام، کارکردهایی‌اند که باید روش پیاده‌سازی آن‌ها را هم شناخت.

از بینش تا اقدام؛ هوش مصنوعی چه کارهایی انجام می‌دهد؟

کارکردهای هوش مصنوعی را می‌توان از دو منظر بررسی کرد: نخست، نوع مسئله و خروجی مورد انتظار؛ دوم، روش فنی مورد استفاده برای حل آن مسئله.

در سطح کارکرد، طیفی از قابلیت‌ها وجود دارد:

  • توصیف: استخراج و نمایش وضعیت از داده‌ها؛ مانند گزارش وضعیت خط تولید یا خلاصه‌سازی روند عملکرد تجهیزات.
  • تشخیص و طبقه‌بندی: شناسایی یک وضعیت یا قرار دادن داده در یک گروه مشخص؛ مانند تشخیص عیب در تصویر محصول، شناسایی قطعه معیوب یا دسته‌بندی درخواست‌های مشتریان.
  • پیش‌بینی و برآورد: تخمین یک وضعیت یا مقدار در آینده؛ مانند پیش‌بینی تقاضا، زمان خرابی تجهیز، میزان تولید یا مصرف انرژی.
  • کشف الگو و ناهنجاری: شناسایی رفتارهای غیرمعمول یا روابطی که به‌سادگی با قواعد ثابت قابل تشخیص نیستند؛ مانند کشف تقلب، شناسایی انحراف در فرایند تولید یا تشخیص رفتار غیرعادی شبکه.
  • توصیه و تصمیم‌سازی: پیشنهاد یک اقدام بر اساس داده‌ها، محدودیت‌ها و هدف مشخص؛ مانند پیشنهاد زمان مناسب تعمیرات، انتخاب ترکیب تولید یا تعیین اولویت رسیدگی به سفارش‌ها.
  • استدلال و استنتاج: رسیدن به نتیجه از طریق قواعد، روابط و بازنمایی دانش؛ مانند سامانه‌های خبره‌ای که با استفاده از دانش تخصصی، شرایط را ارزیابی و نتیجه‌ای قابل توضیح ارائه می‌کنند.
  • تولید محتوا: ساخت متن، تصویر، صدا، ویدئو یا کد بر اساس ورودی و زمینه؛ قابلیتی که در مدل‌های هوش مصنوعی مولد دیده می‌شود.
  • برنامه‌ریزی و اقدام: انتخاب و اجرای مجموعه‌ای از گام‌ها برای رسیدن به یک هدف؛ مانند سامانه‌های عامل‌محور که می‌توانند ابزارها را فراخوانی کنند، اطلاعات جمع‌آوری کنند و فرایندهایی را پیش ببرند.

این فهرست به معنای آن نیست که همه این کارکردها الزاماً با هوش مصنوعی انجام می‌شوند. یک گزارش توصیفی ممکن است فقط با پرس‌وجو از پایگاه داده ساخته شود؛ یک سامانه تشخیص ممکن است مجموعه‌ای از قواعد ثابت را اجرا کند؛ و یک پیش‌بینی نیز ممکن است بر روش‌های آماری متعارف متکی باشد. عنوان کارکرد، به‌تنهایی روش فنی را مشخص نمی‌کند.

خانواده‌های فنی هوش مصنوعی

برای شناخت روش پیاده‌سازی، باید به خانواده فناوری مورد استفاده توجه کرد. این خانواده‌ها مرزهای کاملاً جدا از هم ندارند و یک محصول می‌تواند چند مورد از آن‌ها را ترکیب کند:

  • یادگیری ماشین: استخراج الگو از داده‌ها و استفاده از آن‌ها برای پیش‌بینی، طبقه‌بندی، برآورد یا کشف ناهنجاری. بسیاری از کاربردهای صنعتی هوش مصنوعی، از کنترل کیفیت تا پیش‌بینی خرابی تجهیزات، در این خانواده قرار می‌گیرند.
  • بینایی ماشین: تحلیل تصاویر و ویدئو برای شناسایی اشیا، تشخیص عیب، اندازه‌گیری، کنترل کیفیت و پایش فرایندها. این حوزه می‌تواند از روش‌های کلاسیک پردازش تصویر تا مدل‌های یادگیری عمیق استفاده کند.
  • پردازش زبان طبیعی: تحلیل، استخراج اطلاعات و درک متن و گفتار؛ از دسته‌بندی اسناد و استخراج موجودیت‌ها تا پاسخ‌گویی و ترجمه.
  • سامانه‌های خبره و هوش مصنوعی نمادین: استفاده از قواعد، منطق و بازنمایی دانش برای استنتاج و تصمیم‌گیری در حوزه‌هایی که دانش تخصصی و روابط قابل تعریف اهمیت دارند.
  • یادگیری تقویتی: یادگیری سیاست تصمیم‌گیری از طریق تعامل با محیط و دریافت بازخورد؛ برای مثال در کنترل فرایندها، مدیریت منابع یا بهینه‌سازی رفتار یک عامل.
  • هوش مصنوعی مولد: تولید محتوای جدید بر اساس الگوهای آموخته‌شده؛ از مدل‌های زبانی بزرگ تا مدل‌های تولید تصویر و صدا.

در کنار این خانواده‌ها، روش‌های بهینه‌سازی و تحقیق در عملیات نیز در بسیاری از سامانه‌های صنعتی به کار می‌روند. البته هر الگوریتم بهینه‌سازی را نباید خودبه‌خود هوش مصنوعی نامید؛ ممکن است یک روش ریاضی یا الگوریتم کلاسیک باشد، یا در کنار مدل هوش مصنوعی برای انتخاب بهترین اقدام استفاده شود.

چرا این تمایز در کاربرد صنعتی اهمیت دارد؟

در انتخاب راهکار، نباید صرفاً به دنبال استفاده از جدیدترین یا پرسر‌وصداترین فناوری بود. مسئله باید تعیین کند که چه روشی مناسب‌تر است.

برای مثال، اگر هدف تشخیص ترک روی قطعات تولیدی باشد، احتمالاً یک مدل بینایی ماشین مناسب‌تر از یک مدل زبانی مولد است. اگر هدف پیش‌بینی خرابی تجهیزات باشد، مدل‌های پیش‌بینی مبتنی بر داده‌های حسگر و سوابق تعمیرات می‌توانند انتخاب مناسب‌تری باشند. اگر مسئله، پاسخ‌گویی به پرسش‌های کارکنان از روی اسناد سازمانی باشد، مدل زبانی و بازیابی اطلاعات می‌توانند نقش اصلی داشته باشند.

حتی در یک راهکار واحد نیز ممکن است چند خانواده فناوری کنار هم قرار بگیرند: یک مدل پیش‌بینی وضعیت تجهیز را تخمین بزند، یک موتور قواعد محدودیت‌های عملیاتی را بررسی کند و یک سامانه زبانی نتیجه را برای اپراتور توضیح دهد. در چنین ساختاری، مولد بودن یکی از اجزاست، نه تعریف کل راهکار.

بنابراین، هنگام بررسی یک محصول یا پیشنهاد فنی باید دست‌کم سه پرسش را از هم جدا کنیم:

۱. سامانه چه کاری انجام می‌دهد؟ تشخیص، پیش‌بینی، توصیه، استنتاج، تولید محتوا یا اقدام؟

۲. این کار چگونه انجام می‌شود؟ قواعد ثابت، روش آماری، یادگیری ماشین، بینایی ماشین، سامانه خبره، مدل مولد یا ترکیبی از آن‌ها؟

۳. خروجی در کدام تصمیم یا فرایند استفاده می‌شود؟ آیا صرفاً اطلاعاتی برای کاربر فراهم می‌کند، مبنای تصمیم قرار می‌گیرد یا مستقیماً اقدامی را اجرا می‌کند؟

این تفکیک کمک می‌کند قابلیت واقعی سامانه را از عنوان‌های بازاریابی آن جدا کنیم و درباره تناسب فناوری، ریسک، هزینه و سطح نظارت انسانی دقیق‌تر تصمیم بگیریم.

مدیر منابع انسانی به ردیف «ثبت‌نام هوشمند» اشاره کرد: «فرم رو می‌گیره، ظرفیت رو می‌سنجه و اگر جا باشه پیام تأیید می‌فرسته.»

مدیر فناوری پرسید: «چیزی از سابقه فرد استنباط می‌کنه؟ دوره‌ای پیشنهاد می‌ده یا فقط همین شرط‌ها رو اجرا می‌کنه؟»

«فعلاً فقط همین شرط‌ها.»

مدیرعامل گفت: «پس همین رو بنویسیم. اگر پیشنهاد دوره بر اساس نیاز فرد اضافه شد، باید روش اون قابلیت رو هم روشن کنیم.»

مدیر تولید که تا آن لحظه ساکت بود، گفت: «ما هم یک سامانه داریم که از روی تصویر محصول، عیب سطحی رو تشخیص می‌ده. اون هم هوش مصنوعی مولده؟»

مدیر فناوری پاسخ داد: «نه. اون یک مدل بینایی ماشینه. اصلاً قرار نیست چیزی تولید کنه؛ باید عیب رو درست تشخیص بده. برای پیش‌بینی خرابی تجهیزات هم می‌تونیم از مدل‌های پیش‌بینی استفاده کنیم.»

مدیرعامل گفت: «پس در فهرست، فقط ننویسیم هوش مصنوعی. مشخص کنیم چه قابلیتی داریم و با چه روشی پیاده شده.»

نام درخواست عوض نشد، اما شرح آن دیگر اجرای شرط‌های ثابت، استنباط از داده‌ها و تولید پیشنهاد را با هم مخلوط نمی‌کرد.

چه چیزهایی را نباید صرفاً به دلیل نامشان هوش مصنوعی بدانیم

نمونه‌های خودکارسازی ساده، محاسبه، پاسخ‌های ذخیره‌شده، قواعد مستقیم و خدماتی که صرفاً هوشمند نامیده می‌شوند
در خواندن مثال‌ها، روش پیاده‌سازی تعیین‌کننده است؛ نام محصول یا پیچیدگی نرم‌افزار کافی نیست.

اجرای صرف یک دستور یا نگاشت از پیش تعیین‌شده، محاسبه با فرمول مشخص، نمایش دادهٔ ذخیره‌شده و انتخاب مستقیم یک پاسخ آماده، به‌خودی‌خود وجود هوش مصنوعی را نشان نمی‌دهند. پیچیده شدن نرم‌افزار یا زیاد شدن تعداد شروط نیز به‌تنهایی این وضعیت را تغییر نمی‌دهد.

خودکارسازی سادهٔ صنعتی، آبیاری زمان‌بندی‌شده، کنترل تردد مبتنی بر شناسه و روشنایی برنامه‌ریزی‌شده، نمونه‌هایی‌اند که باید بر اساس منطق واقعی کارشان بررسی شوند. همین‌طور وجود پورتال، پایگاه داده، نمایشگر وضعیت یا فهرست پرسش‌های متداول، نشانهٔ کافی برای تشخیص هوش مصنوعی نیست.

در این مرزبندی، اجرای مستقیم قواعد را باید از استنتاج دانش‌محور تفکیک کرد. سامانه‌های هوش مصنوعی می‌توانند از روش‌های یادگیری ماشین یا رویکردهای منطقی و دانش‌محور استفاده کنند. بنابراین داشتن قواعد یا تکرارپذیر بودن خروجی، به‌تنهایی دلیل خارج بودن از هوش مصنوعی نیست. در توضیح OECD نیز هر دو خانوادهٔ یادگیری ماشین و رویکردهای دانش‌محور در قلمرو هوش مصنوعی آمده‌اند.

به همین دلیل، در بررسی نمونه‌های ساده باید روش اجرای کار را شناخت. یک پاسخ‌گوی مبتنی بر جواب‌های از پیش تعیین‌شده با دستیاری که پاسخ را با مدل می‌سازد، یکسان نیست. نام «مترجم»، «بازی»، «کنترل‌گر» یا «دستیار» نیز بدون بررسی روش اجرا، برای طبقه‌بندی کافی نیست.

هدف این غربال، کم‌ارزش دانستن خودکارسازی نیست. ممکن است یک راهکار ساده، دقیقاً مسئلهٔ سازمان را حل کند. موضوع آن است که ارزش و کنترل مورد نیازش را بر اساس کاری که واقعاً انجام می‌دهد بسنجیم.

مدیر مالی گفت: «اگر ثبت‌نام با همین قواعد کار می‌کنه و نیازمون رو هم برطرف می‌کنه، چرا باید تبدیلش کنیم به پروژهٔ هوش مصنوعی؟»

مدیر منابع انسانی پاسخ داد: «لازم نیست. مسئلهٔ فعلی، ثبت‌نام و کنترل ظرفیته.»

مدیر عملیات کنار همان ردیف، روش اجرای کار را اضافه کرد. حالا می‌شد دربارهٔ ارزش و هزینهٔ درخواست صحبت کرد، بی‌آنکه نام «هوشمند» جای توضیح راهکار را بگیرد.

دو غربال برای قلمرو و شدت حکمرانی

غربال اولیه قلمرو و شدت حکمرانی؛ تشخیص هوش مصنوعی بودن و سپس بررسی کاربرد و پیامد
ورود به قلمرو هوش مصنوعی و تعیین شدت کنترل، دو تصمیم مرتبط اما متفاوت‌اند.

اکنون می‌توان بررسی اولیه را در دو گام انجام داد.

گام نخست این است که مشخص کنیم سامانه با استفاده از مدل آموخته‌شده یا دانش‌محور، از ورودی برای تولید خروجی استنباط می‌کند یا نه. اگر پاسخ منفی باشد، آن درخواست در فهرست هوش مصنوعی قرار نمی‌گیرد؛ اما کنترل‌های فناوری اطلاعات، داده، امنیت، حریم خصوصی و ایمنی همچنان برقرارند.

اگر پاسخ مثبت یا هنوز نامشخص باشد، کاربرد باید بررسی شود. نامشخص بودن را نباید با نبودن هوش مصنوعی یکی گرفت. ممکن است لازم باشد روش کار، اجزای راهکار یا نقش تأمین‌کننده روشن‌تر شود.

گام دوم، بررسی کاربرد مشخص و پیامد آن است. یک فناوری یکسان می‌تواند در کاربردهای متفاوت، اثر و اختیار متفاوتی داشته باشد. در این غربال، وضعیت‌های کاربرد ممنوع، کاربرد پرریسک یا جزء ایمنی، کاربرد مشمول شفافیت و سایر کاربردها از هم تفکیک می‌شوند. این تقسیم، مسیر بررسی و کنترل را مشخص می‌کند؛ تشخیص ممنوعیت یا الزام خاص باید با قواعد حاکم بر همان کاربرد انجام شود.

برای تعیین شدت بررسی، این پنج پرسش اهمیت دارند:

عاملپرسش برای کاربرد مورد بررسی
شدت پیامداگر خروجی اشتباه باشد، چه آسیبی ممکن است ایجاد شود؟
مقیاس استفادهچند نفر، واحد یا فرایند از آن اثر می‌پذیرند؟
حساسیت دادهچه داده‌هایی وارد سامانه می‌شوند و چه محدودیت‌هایی دارند؟
میزان اتکای انسانخروجی فقط برای بررسی است یا عملاً مبنای تصمیم و اقدام قرار می‌گیرد؟
امکان بازگشت و جبرانآیا می‌توان نتیجه را اصلاح کرد و پیامد آن را جبران کرد؟

در پروندهٔ دستیار، نمایش یک بند عمومی با ارائهٔ نتیجه دربارهٔ وضعیت فردی کارکنان، کاربرد یکسانی نیست. اگر پاسخ به اقدام خودکار متصل شود، پرسش‌های دیگری دربارهٔ اختیار، کنترل و امکان اصلاح نتیجه مطرح می‌شوند.

نوع داده نیز در تعیین شدت کنترل اثر دارد. در تنظیم‌گری داده‌ها؛ تعادل میان نوآوری، حریم خصوصی و امنیت تفاوت داده‌های عمومی، شخصی و حساس، اسرار صنعتی و داده‌های تولیدی و تحلیلی را توضیح داده‌ام؛ این تفکیک، مبنای روشن‌کردن هدف مجاز استفاده و سطح دسترسی است.

هوش مصنوعی بودن، ورود به فرایند بررسی را مشخص می‌کند؛ کاربرد و پیامد، شدت حکمرانی را تعیین می‌کنند.

مدیرعامل گفت: «پس اگر یک درخواست هوش مصنوعی بود، قرار نیست حتماً همون کنترل دستیار منابع انسانی رو براش تکرار کنیم.»

مسئول ریسک و انطباق پاسخ داد: «باید کاربردش رو ببینیم. اینکه چه داده‌ای می‌گیره، چه کسی به خروجی تکیه می‌کنه و اگر اشتباه کرد چه اتفاقی می‌افته.»

مدیر فناوری به ردیف جست‌وجوی اسناد اشاره کرد: «برای این هم باید روشن کنیم قرار است سند رو پیدا کنه، پاسخ بسازه یا بعد از پاسخ کاری انجام بده.»

فهرست درخواست‌ها هنوز کامل نشده بود. این بار، ابهام دقیق‌تری داشتند که باید برطرف می‌شد.

همه از دستیار یک چیز نمی‌خواهند

کارت تحول دوم؛ برداشت‌های متفاوت واحدها از دستیار شامل FAQ، جست‌وجو، RAG، داشبورد، اتوماسیون و عامل اقدام‌کننده
تا معنای دستیار و حدود کار آن روشن نشود، دامنهٔ پروژه نیز مشترک نخواهد بود.

در کارت تحول دوم، همان واژه‌ای که در شروع دوره ساده به نظر می‌رسید، دوباره مسئله‌ساز می‌شود: «دستیار». این بار باید ببینیم هر واحد از آن چه خروجی و چه اختیاری انتظار دارد.

برداشت از دستیارچیزی که باید دربارهٔ دامنه روشن شود
FAQ داخلیآیا فقط پاسخ‌های از پیش تعیین‌شده را نمایش می‌دهد؟
جست‌وجوی سازمانیآیا سند و محل اطلاعات را پیدا می‌کند یا از آن نتیجه هم می‌گیرد؟
RAG روی اسنادآیا پس از بازیابی منابع، با مدل پاسخ تولید می‌کند و حدود اتکا به آن چیست؟
داشبورد و تحلیلآیا گزارش می‌دهد، پیش‌بینی می‌کند یا توصیه‌ای برای تصمیم می‌سازد؟
اتوماسیون فرایندآیا قواعد مشخص را اجرا می‌کند و در کدام مرحله به نظر انسان نیاز دارد؟
عامل یا اقدام خودکارچه اقدامی مجاز است انجام دهد و حدود اختیارش کجاست؟

این برداشت‌ها می‌توانند به داده، روش ارزیابی، مسئولیت و کنترل متفاوتی نیاز داشته باشند. بعضی نیز ممکن است در یک محصول کنار هم قرار بگیرند. لازم است دامنهٔ هر قابلیت مشخص شود تا نام مشترک محصول، تفاوت‌ها را پنهان نکند.

توافق درس قبل دربارهٔ گسترش، برای همان کاربرد و محدودیت‌های تعریف‌شده بود. نمی‌توان آن را به هر قابلیت تازه‌ای که زیر عنوان «دستیار» پیشنهاد می‌شود تعمیم داد. افزودن تولید پاسخ، دسترسی به دادهٔ فردی یا اختیار اقدام باید در شرح کاربرد دیده شود و دوباره از مسیر تصمیم مربوط بگذرد.

در این مرحله باید بتوانیم درخواست مبهم را چنان توضیح دهیم که روشن باشد کدام قابلیت، با چه روش و چه نقشی در تصمیم یا اقدام، موضوع بررسی است.

مدیر منابع انسانی گفت: «برای واحد ما، دستیار باید پاسخ سؤال‌های کارکنان رو از منابع معتبر بده و موارد خاص رو ارجاع بده.»

مدیر عملیات گفت: «من انتظار داشتم درخواست رو هم بگیره و گردش کار رو جلو ببره.»

مدیر مالی گفت: «من از داشبوردی حرف می‌زدم که وضعیت رو نشون بده و برای تصمیم کمک کنه.»

مدیر فناوری به سه ردیف فهرست اشاره کرد: «این‌ها ممکنه در یک محصول جمع بشن، ولی الان سه کاربرد متفاوت داریم. باید جدا معلوم باشه چه داده‌ای می‌خوان، چه خروجی‌ای می‌دن و چه کاری اجازه دارن انجام بدن.»

مدیرعامل کلمهٔ «دستیار» را از بالای فهرست پاک نکرد. فقط زیر آن، جای توضیح کاربردها را باز کرد.

پرسید: «خوب، قبل از انتخاب این قابلیت‌ها، مسئلهٔ اصلی هر واحد چیه؟ کارکنان جواب رو پیدا نمی‌کنن، اسناد متناقضه یا فرایند رسیدگی طولانیه؟»

برای پاسخ به این سؤال، فهرست فناوری‌ها کافی نبود. باید خود مسئله را صورت‌بندی می‌کردند.

این درس، قسمت اول بخش دوم «قلمرو حکمرانی» و تشریح اسلایدهای ۱۹ تا ۲۶ دوره است. درس قبل؛ اسلایدهای کامل دوره