.png&w=1200&q=75)
حکمرانی هوش مصنوعی در سازمان: چه کسی حق تصمیم دارد؟
خرید یک ابزار هوش مصنوعی، تکلیف اختیار و مسئولیت را روشن نمی‌کند. سازمان پیش از استقرار باید بداند چه کسی کاربرد را تصویب می‌کند، چه کسی نتیجه را می‌سنجد و چه کسی می‌تواند استفاده را متوقف کند.
قرار است یک دستیار هوشمند صورت‌جلسه‌ها را خلاصه کند، نامه بنویسد یا درخواست مشتری را اولویت‌بندی کند. در ظاهر، بحث بر سر انتخاب نرم‌افزار است؛ اما به‌محض آنکه خروجی ابزار بر تصمیم یک واحد اثر بگذارد، مسئله اختیار هم مطرح می‌شود. چه کسی تعیین کرده کدام اسناد وارد سامانه شوند؟ کدام پاسخ قابل اتکاست؟ اگر خطایی تکرار شد، چه کسی حق توقف دارد؟
حکمرانی در اینجا به معنای تعیین همین قواعد، اختیارها و سازوکار پاسخ‌گویی است. حتی سازمانی که مدل تولید نمی‌کند، درباره نحوه استفاده از مدل تصمیم می‌گیرد و در برابر پیامدهای آن مسئولیت سازمانی دارد.
چارچوب چه کمکی می‌کند؟
چارچوب داوطلبانه مدیریت ریسک NIST، منتشرشده در سال ۲۰۲۳، فعالیت‌ها را در چهار حوزه حکمرانی، شناخت زمینه، سنجش و مدیریت ریسک سامان می‌دهد. راهنمای همراه آن نیز تأکید می‌کند پیشنهادها نباید به چک‌لیستی یکسان برای همه سازمان‌ها تبدیل شوند. این چارچوب الزام حقوقی عمومی برای سازمان‌های ایرانی ایجاد نمی‌کند؛ ارزش آن در کمک به طرح‌کردن پرسش‌های منظم است.
برداشت عملی خرد این است که یک سازمان ابتدا به نقشه تصمیم نیاز دارد، سپس به سند سیاست. سیاستی که صاحب تصمیم، مدرک لازم و زمان بازبینی را تعیین نکند، ممکن است فقط صورت مسئله را رسمی‌تر کند.
چهار مسئولیت را از هم جدا کنیم
صاحب فرایند باید توضیح دهد مسئله چیست و نتیجه بهتر چه معنایی دارد. برای نمونه، مدیر پشتیبانی می‌تواند زمان پاسخ‌گویی و نرخ حل مسئله را تعریف کند؛ اما به‌تنهایی مرجع تأیید امنیت داده نیست.
مسئول داده و امنیت باید حدود دسترسی، نگهداری اطلاعات و مسیر گزارش رخداد را مشخص کند. تیم فنی نیز باید بداند چه چیزی را ارزیابی می‌کند و تغییر مدل یا تنظیمات چگونه ثبت می‌شود. مقام تصویب‌کننده باید درباره ریسک باقی‌مانده تصمیم بگیرد و اختیار توقف یا محدودسازی استفاده را به فرد مشخصی بسپارد. در سازمان کوچک ممکن است یک فرد چند نقش داشته باشد؛ مهم آن است که تعارض نقش‌ها دیده شود.
از کاربرد محدود شروع کنیم
در یک مثال فرضی، شرکتی می‌خواهد از دستیار برای تهیه پیش‌نویس پاسخ به مشتری استفاده کند. اجازه تولید پیش‌نویس با اجازه ارسال خودکار یکسان نیست. تصمیم اول می‌تواند با کنترل کارشناس اجرا شود؛ تصمیم دوم به سنجش خطا، ثبت پاسخ‌ها و سازوکار رسیدگی به شکایت نیاز بیشتری دارد.
پیشنهاد تحریریه این است که برای هر کاربرد یک برگه کوتاه تهیه شود: هدف، کاربران، داده مجاز، اقدام مجاز، معیار پذیرش، مسئول پاسخ‌گو و شرط توقف. اگر هدف فقط کمک به نوشتن است، همان برگه باید صریحاً بگوید ابزار اجازه تعهد مالی یا تغییر پرونده مشتری ندارد.
اختیار توقف باید واقعی باشد
نوشتن نام یک مدیر در سند کافی نیست. فرد مسئول باید بتواند نشانه خطا را ببیند، به گزارش دسترسی داشته باشد و بدون انتظار طولانی، استفاده را محدود کند. تیم اجرا هم باید مسیر جایگزین داشته باشد تا توقف ابزار به توقف خدمت منجر نشود. اگر خاموش‌کردن سامانه عملاً ناممکن باشد، اختیار توقف روی کاغذ باقی مانده است.
گزارش دوره‌ای بهتر است علاوه بر میزان استفاده، تعداد خطاهای مهم، موارد اصلاح‌شده، شکایت‌ها و تغییرات نسخه را نشان دهد. افزایش تعداد کاربران به‌خودی‌خود نشانه بهبود تصمیم نیست.
تصمیمی که پیش از خرید باید گرفت
هیچ ساختار واحدی برای همه سازمان‌ها مناسب نیست. شدت کنترل باید با اثر کاربرد، حساسیت داده و امکان جبران خطا متناسب باشد. خلاصه‌سازی یادداشت داخلی و اولویت‌بندی دریافت‌کنندگان یک خدمت عمومی، ریسک هم‌اندازه ندارند.
برای شروع، مدیر سازمان می‌تواند فقط یک کاربرد را انتخاب کند و از تیم بخواهد مسیر یک خروجی اشتباه را تا رسیدگی نهایی توضیح دهد. اگر در این مسیر معلوم نباشد چه کسی می‌بیند، چه کسی تصمیم می‌گیرد و چه کسی پاسخ می‌دهد، مسئله اصلی هنوز حکمرانی است؛ حتی اگر نرم‌افزار آماده تحویل باشد.
درباره این مطلب
این مطلب با کمک ابزارهای هوش مصنوعی تهیه شده و تحلیل‌ها و پیشنهادهای آن متعلق به تحریریه خرد است. منابع اصلی در پیوندهای زیر آمده‌اند؛ مثال‌های فرضی، گزارش رویداد واقعی نیستند.
منابع اصلی
برچسب‌ها
نظرها
هنوز نظری برای این مطلب منتشر نشده است.
نظر شما
نظرها پس از بررسی و تأیید نمایش داده می‌شوند. نظرهای حاوی توهین، تهمت یا تبلیغ منتشر نمی‌شوند.