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