رفتن به محتوای اصلی
دانیال سمیعیمدرسهٔ تصمیم / هوش مصنوعیسایت اصلی ↗
مسیر یادگیری شما۰ از ۱۲ فصل

فصل ۱۱ / ۲۵ دقیقه مطالعهٔ مرجع

حاکمیت، محرمانگی و مسئولیت؛ قواعد استفادهٔ سازمانی

یک سیاست عملی برای داده، اختیار، کنترل کیفیت، تأمین‌کننده و رخداد؛ متناسب با سطح ریسک هر کاربرد.

بعد از این فصل می‌توانید…

  • کاربردها را بر اساس پیامد خطا سطح‌بندی می‌کنید.
  • دادهٔ مجاز و مرز اقدام را مشخص می‌کنید.
  • مسئول، شواهد و راه توقف را در فرایند می‌گنجانید.
۰۱

مسئولیت را پیش از ابزار تعیین کنید

حاکمیت یعنی معلوم باشد چه کسی هدف را تعیین می‌کند، چه داده‌ای مجاز است، چه کسی خروجی را می‌پذیرد و در خطا چه اتفاقی می‌افتد. یک سیاست صرفاً ممنوع‌کننده ممکن است استفادهٔ پنهان ایجاد کند؛ سیاست صرفاً تشویقی نیز مرز ریسک را مبهم می‌گذارد. برای هر کاربرد، مسئول کسب‌وکار و مسئول کنترل کیفیت مشخص کنید.

NIST در چارچوب خود فعالیت‌های حاکمیت، شناخت زمینه، اندازه‌گیری و مدیریت ریسک را مطرح می‌کند. این‌ها یک چک‌لیست یک‌بارمصرف یا ترتیب خطی ثابت نیستند. در این دوره از این ایده برای ساخت قواعد عملی استفاده می‌کنیم؛ انطباق حقوقی هر شرکت به صنعت، قرارداد، داده و مقررات مربوط به خودش نیاز دارد.

برای میز تصمیم: مالک تصمیم و مالک داده را با نام نقش سازمانی مشخص کنید؛ عبارت «تیم فناوری مسئول است» معمولاً کافی نیست.

۰۲

چه داده‌ای را کجا می‌توان وارد کرد؟

یک طبقه‌بندی ساده برای آموزش بسازید: عمومی، داخلی، محرمانه و بسیار حساس. برای هر طبقه محیط مجاز، فرد تأییدکننده و مدت نگه‌داری را تعیین کنید. دادهٔ عمومی هم ممکن است محدودیت حق استفاده داشته باشد؛ دادهٔ بی‌نام نیز اگر با اطلاعات دیگر قابل‌اتصال باشد الزاماً ناشناس کامل نیست.

برای تمرین، نام‌ها و شناسه‌ها را حذف و داده را ساختگی کنید. برای استفادهٔ واقعی، شرایط سرویس، قرارداد سازمانی، سیاست آموزش مدل، محل پردازش در حد تعهد قابل‌اثبات، حذف و دسترسی مدیر را بررسی کنید. «چت موقت» یا خاموش‌کردن یک گزینه را با تضمین قراردادی عدم نگه‌داری یکی ندانید.

طبقهٔ آموزشینمونهقاعدهٔ پیشنهادی آغازین
عمومیمتن منتشرشدهٔ شرکتبررسی حق استفاده و صحت
داخلیروش کاری غیرحساسفقط محیط مصوب سازمان
محرمانهقرارداد منتشرنشده یا اطلاعات مشتریکمینه‌سازی و تأیید مالک داده
بسیار حساسرمز، کلید، پروندهٔ حساس فردیورود ممنوع در تمرین؛ مسیر تخصصی و مجوز مستقل
۰۳

پیش‌نویس با مجوز اقدام برابر نیست

از ابتدا مشخص کنید سامانه فقط می‌خواند، پیش‌نویس می‌سازد یا حق اجرای عمل دارد. ارسال پیام، انتشار، تغییر رکورد، رزرو و پرداخت اثر بیرونی دارند. تأیید باید به عمل مشخص و محتوای قابل‌مشاهده وصل باشد، نه عبارت کلی «هرچه لازم است انجام بده» در یک گفت‌وگوی قدیمی.

در سامانهٔ واقعی، کنترل اختیار باید در سرویس اجرا شود. متن پرامپت به‌تنهایی دیوار امنیتی نیست. برای اقدام‌های تکرارپذیر، شناسهٔ یکتا، جلوگیری از تکرار، ثبت نتیجه و راه لغو لازم است. اگر شرایط یا محتوای اقدام پس از تأیید تغییر کرد، اعتبار همان تأیید باید دوباره بررسی شود.

مکث و تمرین

برای دستیار جلسه، فهرست «مجاز بدون تأیید»، «نیازمند تأیید» و «خارج از دامنه» بنویسید. آیا ارسال دعوت به همهٔ مخاطبان واقعاً در دامنهٔ آماده‌سازی بستهٔ جلسه است؟

۰۴

خطا، سوگیری و اتکای بیش‌ازحد

در تصمیم‌های اثرگذار بر افراد، مانند استخدام، ارزیابی عملکرد یا اعتبار، خطای مدل فقط خطای متن نیست. دادهٔ تاریخی ممکن است سوگیری داشته باشد و معیار ظاهراً خنثی اثر نامتوازن ایجاد کند. در این دوره مدل را برای ساخت پرسش و بررسی فرایند به کار می‌بریم؛ تصمیم نهایی دربارهٔ افراد را به خروجی بررسی‌نشده واگذار نمی‌کنیم.

اتکای بیش‌ازحد زمانی رخ می‌دهد که افراد به‌دلیل سرعت، ظاهر حرفه‌ای یا سابقهٔ چند پاسخ خوب، بررسی را کنار بگذارند. برای پیشگیری، نمونه‌برداری از خروجی، بررسی موارد مرزی و امکان اعتراض را طراحی کنید. اختلاف نظر متخصص با مدل باید ثبت و بررسی شود، نه اینکه صرفاً به نفع مدل کنار گذاشته شود.

  • کاربرد پرپیامد به بازبینی تخصصی نیاز دارد.
  • دادهٔ ناقص دربارهٔ فرد را با استنباط پُر نکنید.
  • دلیل قابل‌بررسی و راه اعتراض را حفظ کنید.
  • معیار کیفیت را برای گروه‌ها و موارد مرزی نیز بسنجید.
۰۵

امنیت اتصال و محتوای غیرقابل‌اعتماد

فایل، ایمیل، صفحهٔ وب و خروجی مدل را دادهٔ قابل‌بررسی بدانید. ممکن است محتوای آن‌ها تلاش کند رفتار عامل را تغییر دهد. برای عامل متصل، دسترسی کمینه، جداسازی داده، محدودکردن مقصد ارسال و تأیید عمل کمک می‌کند اثر خطا محدود بماند. نام معتبر محصول به‌تنهایی امنیت کل زنجیرهٔ اتصال را ثابت نمی‌کند.

در خرید، دربارهٔ خروج کارکنان، لغو توکن‌ها، ثبت دسترسی، تغییر تأمین‌کننده و امکان خروجی‌گرفتن بپرسید. اگر یک ابزار به حساب شخصی کارمند وابسته است، استمرار فرایند سازمانی شکننده می‌شود. فهرست اتصال‌ها و مالکان آن‌ها را نگه دارید و دسترسی بلااستفاده را با فرایند مشخص لغو کنید.

درخواست آمادهٔ تمرین
برای کاربرد [کاربرد] یک جدول کنترل تهیه کن: داده، ابزار، اختیار، پیامد خطا، کنترل پیشگیرانه، شاهد پذیرش، مسئول و شرط توقف. موارد نامعلوم را سؤال کن. فقط کنترل‌های متناسب با همین کاربرد پیشنهاد بده و ادعای انطباق قانونی قطعی نکن.
۰۶

وقتی خطا رخ می‌دهد، مسیر روشن داشته باشید

نمونهٔ رخداد می‌تواند ارسال اشتباه، افشای داده، تحلیل نادرستِ استفاده‌شده یا مصرف غیرعادی باشد. ابتدا دامنهٔ اثر را محدود کنید: توقف جریان مربوط، لغو دسترسی لازم و حفظ شواهد بدون انتشار بیشتر داده. سپس مسئول تعیین‌شده باید اثر، افراد درگیر و اقدام اصلاحی را بررسی کند.

برای یادگیری سازمانی، علت را فقط «مدل اشتباه کرد» ننویسید. بررسی کنید ورودی، تعریف شاخص، مجوز، طراحی رابط یا بازبینی کجا ناکافی بوده است. معیار بازگشت به کار را تعیین کنید و نمونهٔ رخداد را به آزمون پذیرش اضافه کنید. گزارش رخداد باید واقعیت تأییدشده را از احتمال جدا کند.

برای میز تصمیم: سیاست خوب اجازهٔ استفادهٔ مفید می‌دهد و هم‌زمان مرز داده، اختیار، پاسخ‌گویی و توقف را روشن نگه می‌دارد.

دانش خود را بسنجید

پیش از رفتن به فصل بعد

۱. کدام کنترل برای عامل دارای ابزار کافی نیست؟

۲. پس از خطای استفاده‌شده در تصمیم، چه چیزی برای یادگیری لازم است؟

چک‌لیست پایان فصل

پیشرفت و تیک‌ها فقط در همین مرورگر ذخیره می‌شوند؛ تکمیل فصل به‌معنای گواهی مهارت نیست.

پیوندهای این فصل

منابع برای بررسی مستقیم