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