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