اگر مسئول اصلاح در دسترس نباشد
مدیر فناوری، مسیر پیشنهادی اصلاحِ دسترسی را توضیح داد. آزمون حساب کارمند عادی باید دوباره اجرا می‌شد و نتیجهٔ آن پیش از گسترش استفاده بررسی می‌شد.
مدیرعامل پرسید: «اگر هفتهٔ بعد سند تازه‌ای اضافه شد، همین آزمون دوباره انجام می‌شه؟»
«باید انجام بشه.»
«چه چیزی باعث می‌شه فراموش نشه؟»
مدیر فناوری به یادداشتش نگاه کرد. «فعلاً همکار مسئول، تغییر رو بررسی و آزمون رو اجرا می‌کنه.»
مدیر مالی پرسید: «اگر در دسترس نبود، بقیه می‌دونن دقیقاً چه چیزی عوض شده و چه آزمونی لازمه؟»
مدیر عملیات گفت: «برای بعضی تغییرها، هنوز باید از همون کسی بپرسیم که انجامش داده.»
مسئول ریسک و انطباق پرسید: «برای بررسی هم لازم می‌شه دوباره به همهٔ اسناد دسترسی کامل بدیم؟»
چند لحظه سکوت شد. روی کاغذ، حدود دسترسی کاربران روشن‌تر شده بود؛ اما ادارهٔ همان حدود هنوز به دانسته‌ها و دسترسی‌های چند نفر وابسته بود.
مدیرعامل گفت: «باید بتونیم مسیر کار و نتیجهٔ بررسی رو دنبال کنیم. بعد هم ببینیم کدوم کار واقعاً به دیدن دادهٔ محرمانه نیاز داره و کدوم رو می‌شه در یک فرایند کنترل‌شده انجام داد.»
در درس یازدهم دیدیم مجوز باید پیش از خواندن منبع و پیش از اقدام بررسی شود. آزمون حساب کارمند عادی نشان داد که دسترس‌پذیری خدمت، رعایت این مرزها را ثابت نمی‌کند.
اکنون مسیر اصلاح مشخص شده و پرسش‌های جلسه دربارهٔ سند تازه و غیبت مسئول آزمون، بحث را به حفظ کنترل در طول زمان رسانده‌اند. کنترل باید پس از تغییر منبع، مدل، تنظیمات یا تیم اجرا نیز برقرار بماند؛ با سوابق روشن، ارزیابی قابل تکرار و حدود دسترسی معلوم. این بار، موضوع بلوغی است که اجرای کنترل را از وابستگی به حافظه و حضور چند فرد دور می‌کند.
این درس، اسلایدهای ۹۰ تا ۹۶ را به ترتیب و با تکیه بر صورت‌بندی بخش ۳.۴ سند «معماری بدون اعتماد هوش مصنوعی» دنبال می‌کند. در این روایت، مسیر از بلوغ مهندسی و عملیات آغاز می‌شود و در سطح چهار به امکان اجرای فرایند بدون دسترسی مستقیم انسان به دادهٔ حساس می‌رسد. انسان، سیاست و فرایند را تعریف می‌کند و بر شواهد نظارت دارد.
بلوغ را در قابلیت کنترل ببینیم
در سطوح بلوغ مهندسی و کنترل در این صورت‌بندی، از وضعیت موردی و واکنش پس از رخداد، به سیاست مستند، مرز اختیار روشن، مالکیت مشخص و نظارت مبتنی بر شواهد می‌رسیم. برای تحقق این قابلیت‌ها، باید آماده‌سازی، ارزیابی و انتشار مدل نیز به بلوغ برسند؛ همان مسیر عملیاتی که سند ZTAI آن را از مهندسی هوش مصنوعی تا هوش مصنوعی بدون اعتماد صورت‌بندی می‌کند. اگر بخواهید اجزای این مسیر مهندسی را دقیق‌تر دنبال کنید، MLOps؛ بستر پیاده‌سازی هوش مصنوعی بدون اعتماد رابطهٔ داده، کد، آزمایش، مدل و استقرار را در یک چرخهٔ قابل ردیابی توضیح می‌دهد.
باید میان داشتن یک عنوان و داشتن قابلیت واقعی تفاوت بگذاریم. اگر گفته‌ایم تغییرات کنترل می‌شوند، باید بتوانیم سابقهٔ تغییر، نتیجهٔ بررسی و نسخهٔ مستقر را نشان دهیم. اگر گفته‌ایم دسترسی محدود است، اجرای همین محدودیت باید قابل بررسی باشد. عدد سطح، نتیجهٔ این شناخت است. برای برنامه‌ریزی، لازم است بدانیم اکنون چه کاری واقعاً انجام می‌شود، چه بخشی همچنان به پیگیری فردی وابسته است و گام بعدی چه قابلیتی به سازمان اضافه می‌کند.
مدیر عملیات پرسید: «یعنی الان باید برای خودمون یک سطح تعیین کنیم؟»
مدیرعامل گفت: «اول وضعیت واقعی رو بنویسیم. کجا سابقه داریم، کجا آزمون داریم و کجا فقط به تجربهٔ یک نفر تکیه می‌کنیم.»
مدیر فناوری گفت: «ممکنه بعضی بخش‌ها جلوتر باشن و بعضی هنوز دستی اداره بشن.»
مدیر مالی گفت: «همین برای تصمیم بعدی مفیده. معلوم می‌شه بودجه قراره کدوم فاصله رو برطرف کنه.»
سطوح صفر تا چهار در این درس، صورت‌بندی آموزشی مسیر مهندسی و کنترل در سند ZTAI هستند. این مسیر را نباید معیار کامل یا جهان‌شمول بلوغ حکمرانی دانست. سازمان ممکن است عملیات خودکار و قابل ردیابی داشته باشد، اما در انتخاب سرمایه‌گذاری، استقلال ارزیابی، پاسخ‌گویی یا رسیدگی به اعتراض ضعیف عمل کند. در مقابل، اجرای بخشی از فعالیت‌ها به‌صورت دستی، به‌تنهایی نشانهٔ ضعف حکمرانی نیست.
برای ارزیابی وضعیت سازمان، دست‌کم باید این ابعاد را جدا دید: حق تصمیم و پاسخ‌گویی؛ مدیریت ارزش و منابع؛ ارزیابی ریسک و آثار؛ استقلال نظارت و رسیدگی؛ و قابلیت مهندسی و کنترل. این درس عمدتاً بُعد آخر و ارتباط آن با سایر ابعاد را دنبال می‌کند.
هدف نیز رسیدن همهٔ سازمان‌ها به بیشترین خودکارسازی نیست. سطح مناسب کنترل و خودکارسازی باید با حساسیت کاربرد، منابع، هزینه و مسئولیت‌های سازمان تناسب داشته باشد.
سطح صفر: کار پیش می‌رود، اما به افراد وابسته است
در سطح صفر، کارها پراکنده و عمدتاً دستی‌اند. مدل یا اصلاح آماده می‌شود و فردی آن را وارد خدمت می‌کند. ممکن است آزمایش‌هایی هم انجام شده باشد، اما مسیر و نتایج آن‌ها به‌درستی ثبت و نسخه‌گذاری نشده‌اند. مسئله، توانایی یا تعهد افراد نیست. سازمان برای فهم آنچه انجام شده، به همان افراد وابسته است. اگر فایل‌ها یا روش کار تغییر کنند، بازسازی وضعیت قبلی دشوار می‌شود.
این وابستگی، در امنیت نیز اثر دارد. برای بررسی خطا ممکن است دوباره فایل‌ها جابه‌جا شوند، دسترسی‌های گسترده داده شود یا تغییر مستقیماً روی خدمت اعمال شود. معلوم نیست همهٔ این کارها چه سابقه و تأییدی دارند. پرسش مدیر این است: اگر مسئول اصلی حضور نداشت، آیا سازمان می‌توانست همان نتیجه را بررسی یا همان نسخه را دوباره آماده کند؟
مدیر فناوری گفت: «برای بعضی تنظیمات، سابقهٔ کامل نداریم. باید از کسی که تغییر داده بپرسیم.»
مدیرعامل گفت: «پس همون‌ها رو مشخص کنیم. تجربهٔ همکار باید به دانشی تبدیل بشه که سازمان هم بتونه بهش رجوع کنه.»
سطح یک: اجزایی مدیریت می‌شوند، اما وابستگی اصلی باقی است
در سطح یک، بخشی از گردآوری و مدیریت کار منظم‌تر شده است. نسخه‌گذاری اولیه و آزمون‌های پایه وارد می‌شوند، اما ادارهٔ مدل و ورود آن به خدمت هنوز به کار مستقیم افراد وابسته است. در روایت سند، همین‌جا باید میان کنترل بخش نرم‌افزار و کنترل کیفیت مدل دقت کنیم. داشتن نظم در یک بخش، کامل‌بودن ارزیابی کل خدمت را اثبات نمی‌کند.
برای پروندهٔ دستیار، ممکن است نسخهٔ برنامه معلوم باشد، اما هنوز روشن نباشد آن نسخه با کدام مجموعهٔ منابع، تنظیمات و ارزیابی همراه بوده است. یا نتیجهٔ آزمون در جایی ذخیره شده باشد، بی‌آنکه به نسخهٔ مورد استفاده وصل شود. گام مدیریتی این سطح، شناخت همین شکاف است: چه چیزی نسخه دارد و چه چیزی همچنان بیرون از سابقهٔ قابل رجوع قرار گرفته است؟
مدیر مالی پرسید: «پس اینکه برنامه نسخه داره، یعنی وضعیت کامل دستیار رو ثبت کردیم؟»
مدیر فناوری گفت: «باید منابع، تنظیمات و ارزیابی مربوط به همون نسخه رو هم مشخص کنیم.»
مدیرعامل کنار فهرست نوشت: «سابقهٔ کامل وضعیت خدمت.»
سطح دو: مسیر کار قابل تکرار و قابل ردیابی می‌شود
در سطح دو، مدیریت و خودکارسازی اولیه با ردیابی کامل‌تر همراه می‌شود. داده، روش پردازش، مدل، برنامه و آزمون‌ها نسخه دارند و نتیجهٔ ارزیابی در کنار آن‌ها نگهداری می‌شود. اکنون می‌توان پرسید یک خروجی بر اساس کدام وضعیت تولید شده و برای بررسی دوباره به چه اجزایی نیاز داریم. این قابلیت، بررسی تغییرات و مقایسهٔ نسخه‌ها را قابل اتکاتر می‌کند.
با این حال، در روایت سند، انتشار هنوز دستی است و ارتباط میان کیفیت اجزای بررسی‌شده و کیفیت خدمت مستقر کامل نشده است. باید مطمئن شویم همان وضعیتِ بررسی‌شده به محیط استفاده رسیده و تنظیمات یا دسترسی‌ها در این فاصله تغییر نکرده‌اند. در لایهٔ زیرساخت، فاصلهٔ میان وضعیت پذیرفته‌شده و وضعیت جاری را در ثباتی که قابل اثبات و بازگشت نیست، امنیت نیست بررسی کرده‌ام؛ از رانش پیکربندی تا اثبات وضعیت و بازگشت به نسخهٔ معتبر.
برای مدیر، دستاورد این سطح قابلیت رجوع به شواهد است؛ و پرسش بعدی، کنترل مسیر رسیدن همان نسخه به خدمت واقعی است.
مسئول ریسک و انطباق پرسید: «می‌تونیم نشان بدیم نسخه‌ای که آزمون دسترسی رو گذرونده، همون نسخه‌ایه که کاربران استفاده می‌کنن؟»
مدیر فناوری گفت: «باید ارتباط نتیجهٔ آزمون با وضعیت مستقر رو هم ثبت و کنترل کنیم.»
مدیرعامل گفت: «پس گزارش آزمون و تحویل نسخه باید به هم وصل باشن.»
سطح سه: انتشار کنترل می‌شود؛ بازخورد هنوز حلقه را کامل نکرده است
در سطح سه، همکاری تیم‌ها و کنترل ورود نسخه به خدمت منظم‌تر می‌شود. ارزیابی، تأیید و انتشار در یک مسیر مشخص قرار می‌گیرند و بخش بیشتری از اجرا خودکار می‌شود. نتیجهٔ مدیریتی، کاهش وابستگی به اجرای دستی و موردی افراد است. باید معلوم باشد چه نسخه‌ای، با چه نتیجهٔ بررسی و از چه مسیری منتشر شده است.
در ZTAI، این سطح دروازهٔ ورود به هوش مصنوعی بدون اعتماد نامیده شده است. قابلیت مهندسی لازم در حال شکل‌گرفتن است، اما هنوز امکان دسترسی مستقیم به داده و مداخلهٔ فردی باقی است. همچنین، مسیر می‌تواند یک‌طرفه بماند: نسخه بررسی و منتشر شود، اما آنچه در استفادهٔ واقعی رخ می‌دهد به‌طور منظم در اصلاح نسخهٔ بعد اثر نگذارد. بهترشدن نتیجهٔ آزمون هم لزوماً بهبود تجربهٔ واقعی کاربر را نشان نمی‌دهد. پس مدیر باید از ارتباط انتشار با ارزیابی، و سپس از نحوهٔ استفاده از بازخورد واقعی بپرسد.
مدیر عملیات گفت: «اگر نسخهٔ تازه همهٔ آزمون‌ها رو گذروند، ولی کاربران باز هم در ارجاع درخواست مشکل داشتن چی؟»
مدیر فناوری گفت: «باید این بازخورد وارد ارزیابی و اصلاح بعدی بشه.»
مدیرعامل گفت: «و معلوم باشه چه کسی تصمیم می‌گیره معیارها نیاز به بازنگری دارن.»
سطح چهار: اجرای خودکار، با تغییر نقش انسان
محدودکردن دسترسی مستقیم تیم توسعه به دادهٔ خام حساس، هدف یک طراحی متناسب با نیاز محرمانگی است. این هدف، تعریف عمومی Zero Trust یا شرط لازم بلوغ همهٔ کاربردهای هوش مصنوعی نیست. در معماری Zero Trust، اصل بر نبود اعتماد ضمنی و اعمال احراز هویت و مجوز متناسب با دسترسی است. ضرورت و شیوهٔ جداسازی داده باید برای همان کاربرد طراحی و ارزیابی شود.
در سطح چهار، حلقهٔ استفاده و اصلاح به هم وصل می‌شود. پایش و بازخورد می‌توانند نیاز به تغییر را آشکار کنند؛ آماده‌سازی، ارزیابی و انتشار نیز در مسیر قابل ردیابی و کنترل‌شده انجام می‌شوند.
در صورت‌بندی ZTAI، خودکارسازی کامل، امکان تغییر نقش انسان و سلب دسترسی مستقیم او به بخش‌های داده‌محور را فراهم می‌کند. متخصص، روش و فرایند را تعریف می‌کند؛ اجرای روزمره می‌تواند بدون مراجعهٔ مستقیم او به دادهٔ خام حساس انجام شود.
در این برداشت، انسان همچنان مسئول هدف، سیاست، معیار پذیرش، حدود اختیار و رسیدگی به استثناهاست. وظیفهٔ نظارت نیز با مشاهدهٔ شواهد مجاز و ارزیابی رفتار خدمت ادامه پیدا می‌کند.
برای پروندهٔ ما، این پرسش مطرح می‌شود: آیا تیم فنی می‌تواند سازوکار دستیار را توسعه و ارزیابی کند، بدون آنکه برای هر تغییر به همهٔ پرونده‌های محرمانهٔ کارکنان دسترسی بگیرد؟ آیا پردازش دادهٔ حساس می‌تواند در محیط مجاز انجام شود و نتیجهٔ بررسیِ متناسب در اختیار ناظر قرار گیرد؟
پاسخ عملی به نیازهای مهندس و ارزیاب، موضوع مهندسی داده و مدل بدون مشاهدهٔ دادهٔ محرمانه است: قرارداد داده، نمونهٔ ساختگی، بررسی کیفیت و عیب‌یابی درون مرز مجاز، ابزار ادامهٔ کار را فراهم می‌کنند. این قابلیت باید طراحی و اثبات شود. خودکارشدن چند فعالیت، به‌تنهایی نشان نمی‌دهد دسترسی مستقیم انسان حذف شده یا مسیر کنترل‌شده قابل دورزدن نیست.
حدود خودکارسازیِ ادارهٔ خدمت را باید از اختیار تصمیم‌گیریِ دستیار جدا نگه داریم. خودکارشدن ارزیابی و انتشار، مجوز رد خودکار درخواست خرید ایجاد نمی‌کند. حدود استفادهٔ کسب‌وکار همچنان همان چیزی است که جداگانه تصویب کرده‌ایم.
مدیر منابع انسانی پرسید: «یعنی می‌تونیم توسعهٔ دستیار رو ادامه بدیم، بدون اینکه هر بار پرونده‌های واقعی کارکنان رو در اختیار تیم توسعه بذاریم؟»
مدیر فناوری گفت: «اگر مسیر توسعه، اجرای پردازش و ارزیابی رو برای همین هدف طراحی کنیم.»
مدیرعامل گفت: «پس هدف سطح چهار رو دقیق بنویسیم: تیم، فرایند رو تعریف و بررسی می‌کنه؛ دسترسی مستقیم به دادهٔ حساس باید بر اساس نیاز واقعی محدود بشه.»
مسئول ریسک و انطباق گفت: «و باید شواهدی داشته باشیم که این تفکیک در عمل هم برقرار مونده.»
محیط حساس: پردازش داده را از دسترسی تیم توسعه جدا کنیم
در محیط حساس، این تفکیک به شیوهٔ کار تیم توسعه و محل پردازش داده مربوط می‌شود. تیم توسعه می‌تواند با داده‌های عمومی یا نمونه‌های مجاز کار کند. پردازش اصلیِ دادهٔ محرمانه در محیط جداشده و کنترل‌شده انجام می‌شود و خروجیِ مجاز از مسیر تعیین‌شده به بهره‌برداری می‌رسد.
سند، چهار مرز را برای این تفکیک مطرح می‌کند:
| مرحله | نقش انسان | انتظار از مسیر اجرا |
|---|---|---|
| آماده‌سازی داده | تعریف قواعد ورود و آماده‌سازی | پردازش دادهٔ حساس در محدودهٔ مجاز و با دسترسی کنترل‌شده |
| آموزش مدل | تعریف روش و تنظیمات فرایند | اجرای فرایند در محیط امن، بدون نیاز به مشاهدهٔ مستقیم دادهٔ محرمانه توسط تیم توسعه |
| ارزیابی و اعتبارسنجی | تعیین معیارها و نظارت بر نتیجه | بررسی نسخه و ارائهٔ شواهد مجاز برای پذیرش یا رد |
| استقرار | تعیین شرایط انتشار و مقصد مجاز | انتقال فقط از مسیر تأییدشده و با سابقهٔ قابل پیگیری |
برای مدیر، موضوع اصلی این است که اختیار طراحی و ادارهٔ فرایند چگونه از مشاهدهٔ مستقیم داده جدا می‌شود. این تفکیک باید دسترسی تیم توسعه و مدیر سامانه، مسیر تغییر، گزارش‌ها و خروج نتیجه را نیز پوشش دهد.
مسیرهای دسترسی از راه تغییر کد، گزارش خطا، خروج مدل یا مدیریت زیرساخت را در وقتی انسان داده را نمی‌بیند؛ آیا واقعاً دسترسی او حذف شده است؟ بررسی کرده‌ام. آن نوشته کمک می‌کند این تفکیک را در برابر دسترسی غیرمستقیم هم بسنجیم. پذیرش این طرح به شواهد نیاز دارد: چه کسی چه چیزی را می‌تواند ببیند یا تغییر دهد؟ ورودی و خروجی چگونه کنترل می‌شوند؟ تغییر تأییدنشده چگونه متوقف می‌شود؟ در خرابی یا رسیدگی به خطا، همان مرزها چگونه حفظ می‌شوند؟
در این روایت، حرکت از سطح صفر تا چهار، توان مهندسی و کنترل سازمان را برای چنین هدفی می‌سازد. برنامهٔ پیشرفت باید با وضعیت واقعی، حساسیت داده و منابع سازمان متناسب باشد؛ هر گام نیز باید قابلیت قابل بررسی‌ای به خدمت اضافه کند.
برنامهٔ پیشرفت، با شواهد مشخص
مدیر مالی پرسید: «پس برای ادامهٔ کار، از کجا شروع کنیم؟»
مدیر فناوری گفت: «اول وضعیت نسخه‌ها، منابع، آزمون‌ها و انتشار رو کامل ثبت کنیم. بعد، مسیر ارزیابی و انتشار رو به هم وصل کنیم و برای جداسازی دادهٔ حساس برنامه بدیم.»
مدیر منابع انسانی گفت: «ما هم باید معلوم کنیم کدوم داده و کدوم خروجی برای چه نقشی مجازه.»
مدیرعامل گفت: «برای هر گام، مسئول، نتیجه و شاهد پذیرش می‌خوایم. سطح بلوغ رو از روی همین قابلیت‌ها می‌سنجیم.»
مسئول ریسک و انطباق پرسید: «وقتی انسان بیشتر ناظر فرایند شد، چه اطلاعات و چه اختیاری برای مداخله خواهد داشت؟»
مدیرعامل به گزارش‌های روی میز نگاه کرد: «همین رو هم باید روشن کنیم. ناظر باید بتونه مسئله رو بفهمه و به‌موقع تصمیم بگیره.»
در درس سیزدهم، از اسلاید ۹۷ ادامه می‌دهیم: نظارت انسانی چگونه با اثر و اختیار سامانه متناسب می‌شود و برای مداخلهٔ واقعی به چه اطلاعات، فرصت و مسئولیتی نیاز دارد؟
این درس، دوازدهمین درس مجموعهٔ «حکمرانی هوش مصنوعی در سازمان» و تشریح اسلایدهای ۹۰ تا ۹۶ دوره است. درس قبل: امنیت دستیار را کجا و چگونه کنترل کنیم؟؛ اسلایدهای کامل دوره
صورت‌بندی سطوح با تکیه بر بخش ۳.۴ سند «معماری بدون اعتماد هوش مصنوعی»، شناسهٔ PPD-ZTAI-GEN-002، نسخهٔ ۳، تنظیم شده است. شرح تفصیلی این روایت در مدل بلوغ هوش مصنوعی بدون اعتماد آمده است.