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