کاربرد در سازمان‌های ایرانی: از زبان مشترک تا شناسنامهٔ دارایی‌های هوش مصنوعی

این فصل، لایهٔ تدوینگر است و متن رسمی NIST نیست؛ آنچه در ادامه می‌آید، برداشت اجرایی این کتاب از مفاهیم بخش «مبانی و زبان مشترک هوش مصنوعی» برای سازمان‌های ایرانی است. منابع این بخش چهار ستون بنیادی به دست می‌دهند: تعریف هوش مصنوعی (AI) و عناصر «سامانهٔ هوش مصنوعی» (AI system)، «چرخهٔ حیات هوش مصنوعی» از انتخاب مورد کاربرد تا کنار گذاشتن مدل، محدودیت‌های ذاتی مدل‌ها (عدم قطعیت و خطا، سوگیری، تاریک‌ساختگری و امنیت) و اهمیت زبان مشترک میان ذی‌نفعان فنی و غیرفنی.

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

در لایهٔ اجرایی این کتاب پیشنهاد می‌شود سازمان، این مفاهیم را به چهار اقدام عینی ترجمه کند:

• فهرست دارایی‌ها و موارد کاربرد: هر ابزار، مدل یا سرویسی که با یادگیری ماشین (ML) یا مدل‌های زبانی بزرگ (LLM) کار می‌کند — از غربال رزومه و تشخیص تقلب تا دستیارهای پاسخ‌گویی مشتری — شناسایی و در یک فهرست متمرکز ثبت شود. بسیاری از سازمان‌ها هوش مصنوعی را «بی‌نام» به کار می‌گیرند؛ یعنی آن را «سیستم هوشمند» یا «اتوماسیون» می‌نامند و به همین دلیل از دامنهٔ حاکمیت و امنیت خارج می‌ماند.
• تعریف و دامنهٔ مصوب: تعریف سازمانی از هوش مصنوعی، اصطلاحات کلیدی و مرز دامنه (کدام واحدها، کدام سامانه‌ها، کدام تأمین‌کنندگان) به تصویب مدیریت ارشد برسد تا اختلاف بر سر اینکه «چه چیزی AI است» به تعویق پروژه‌ها و توقف پاسخ‌گویی نینجامد.
• ثبت مرحلهٔ چرخهٔ عمر: برای هر دارایی مشخص شود در کدام فاز است (انتخاب مورد کاربرد، طراحی/توسعه، استقرار و پایش، یا کنار گذاشتن)؛ هر فاز تصمیم‌ها، مستندات و مالکیت متفاوتی لازم دارد و «استقرار و پایش» بدون ثبتِ پیش از آن ناقص است.
• سند محدودیت‌های شناخته‌شده: منابع این بخش تأکید می‌کنند خطا و عدم قطعیت، ذاتیِ پیش‌بینی‌های مدل است و سوگیری و تاریک‌ساختگری نیز به‌کلی حذف‌شدنی نیستند؛ بنابراین در لایهٔ اجرایی، شناخت این محدودیت‌ها باید ثبت و به تصمیم‌گیرندگان ابلاغ شود، نه پنهان بماند.

واحدهای درگیر فقط تیم فنی نیستند: معاونت توسعه و برنامه‌ریزی، فناوری اطلاعات (CIO/CTO)، امنیت اطلاعات (CISO)، مدیریت ریسک، حقوقی و انطباق، حریم خصوصی، منابع انسانی، تدارکات و مالکان کسب‌وکار همگی ورودی دارند. مدارک لازم عبارت‌اند از: مصوبهٔ تعاریف و دامنه، فهرست دارایی‌های AI، فرم ثبت مورد کاربرد و سند محدودیت‌های هر دارایی؛ شواهد قابل ممیزی نیز صورت‌جلسات تصویب، تاریخچهٔ بازنگری فهرست و گردش کار ثبت موارد جدید است. ممکن است بسته به صنعت و مقررات حاکم، الزامات دیگری نیز اعمال شود.

جعبهٔ زیر نمونهٔ اجرایی تدوینگر برای نخستین چرخهٔ استقرار «زبان مشترک و فهرست دارایی هوش مصنوعی» است؛ آن را با اندازه، صنعت و ساختار سازمان خود تنظیم کنید.

در جدول نخست، مفاهیم پایهٔ این بخش به زبان مدیریت ترجمه شده است: هر مفهوم به هدف سازمانی، کنترل عملیاتی، شواهد قابل ممیزی، KPI و مالک ختم می‌شود. مقادیر ستون KPI «نمونهٔ پیشنهادی تدوینگر بر پایهٔ مفاهیم مطرح‌شده در منابع این بخش» است، نه الزام NIST.

جدول RACI مسئولیت‌ها را برای فعالیت‌های کلیدی همین چرخه نشان می‌دهد (R: مسئول اجرا، A: پاسخ‌گوی نهایی، C: طرف مشورت، I: مطلع). برای پرهیز از عرض بیش‌ازحد، نقش‌های هم‌خانواده ادغام شده‌اند؛ نقش‌های تدارکات، منابع انسانی و زیرساخت در فعالیت‌های مربوط به خود (خرید، استخدام، استقرار) دخیل‌اند و در صورت نبود عنوان «AI Officer»، نقش معادل سازمانی مانند «مدیر تحول دیجیتال» یا «مدیر دفتر مدیریت داده» منظور می‌شود.

نگاشت این مفاهیم به استانداردهای بین‌المللی نیز تنها با سطح اطمینان معنادار است؛ سطوح اطمینان زیر، قضاوت مفهومی تدوینگر است:

سناریوی نخست — یک بانک ایرانی: این بانک هم‌زمان سه کاربرد دارد: غربال خودکار رزومه‌ها در استخدام شعب، مدل تشخیص تقلب در پرداخت‌ها و دستیار پاسخ‌گویی مشتری مبتنی بر LLM. هر سه در واحدهای جدا توسعه یافته‌اند، هیچ‌کدام با عنوان «هوش مصنوعی» در فهرست دارایی‌های فناوری اطلاعات ثبت نشده‌اند و تعریف و مالکیت یکسانی ندارند. یک روز، پاسخ نادرست دستیارِ مشتری بازتاب عمومی می‌یابد؛ اما معلوم نمی‌شود پاسخ‌گوی نهایی کیست: واحد فناوری، تأمین‌کنندهٔ بیرونی یا مدیریت شعب؟ در لایهٔ اجرایی این کتاب پیشنهاد می‌شود بانک پیش از هر سرمایه‌گذاری جدید، سه گام ساده بردارد: تکمیل فهرست دارایی، تعیین مالک کسب‌وکار و مالک فنی برای هر دارایی، و ثبت محدودیت‌های شناخته‌شدهٔ هر سه سامانه. این سه گام، مسئولیت‌پذیری را ممکن می‌کند و هزینه‌اش در برابر یک رخداد پرتنش ناچیز است.

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

مثال تدوینگر برای دو مفهوم دشوار — تبیین‌پذیری و تاریک‌ساختگری: این دو را با یک مثال جدا کنید. در مدل پیش‌بینی ریزش مشتری، «تبیین‌پذیری» یعنی بتوان گفت کدام عوامل — مثلاً کاهش ورود به اپلیکیشن و تأخیر در پرداخت — در پیش‌بینی مؤثر بوده‌اند؛ اما «تاریک‌ساختگری» به خودِ مدل بازمی‌گردد: اینکه چرا و چگونه این عوامل به این نتیجه رسیده‌اند، حتی برای سازندهٔ مدل نیز به‌سادگی بازسازی نمی‌شود. سازمان معمولاً به «تبیین» نیاز دارد، نه به شفافیت کامل درونیات مدل؛ این دو مفهوم را با هم اشتباه نگیرید.

طبقه‌بندی اقلام زیر — ضروری برای اجرای پایه / پیشنهادی / پیشرفته — قضاوت تدوینگر است، نه الزام NIST؛ ممکن است بسته به صنعت و مقررات حاکم، الزامات دیگری نیز اعمال شود.

اگر در سازمان شما هیچ سند، فهرست یا نقشی برای هوش مصنوعی وجود ندارد، در لایهٔ اجرایی این کتاب توالی زیر پیشنهاد می‌شود:

• ماه نخست — کشف: با پرسش‌نامهٔ کوتاهی از مدیران واحدها و بررسی قراردادهای نرم‌افزاری و سرویس‌های ابری، فهرست اولیهٔ «آنچه ممکن است AI باشد» را بسازید. نیازی به قطعیت فنی نیست؛ ثبت موارد مشکوک بهتر از حذف آن‌هاست.
• ماه دوم — تعریف و مالکیت: تعریف و دامنهٔ یک‌صفحه‌ای را تصویب و ابلاغ کنید؛ برای هر قلم فهرست، مالک کسب‌وکار و مالک فنی تعیین کنید؛ مواردِ بدون مالک را با برچسب «معلق» دنبال کنید.
• ماه سوم — غربال محدودیت‌ها: تنها برای دارایی‌های اثرگذار بر افراد (مشتریان، کارکنان، بیماران و…) سند محدودیت‌های شناخته‌شده را کامل کنید و چرخهٔ بازبینی فصلی را برقرار سازید.

حداقل حاکمیت قابل‌دوام هوش مصنوعی: در لایهٔ اجرایی این کتاب، حداقلِ قابل‌دوام عبارت است از «فهرست دارایی + مالک مشخص + محدودیت‌های شناخته‌شده + مسیر گزارش رخداد». اگر سازمان فقط همین چهار قلم را زنده نگه دارد، حتی بدون هیچ ابزار پیشرفته‌ای، از بسیاری از سازمان‌هایی که AI را بی‌شناسنامه به کار می‌گیرند جلوتر خواهد بود. شایان تأکید است که «حداقل حاکمیت قابل‌دوام» اصطلاح رسمی NIST نیست و صرفاً پیشنهاد تدوینگر است.

مدل بلوغ تدوینگر (سطح ۰ تا ۵): این مدل بلوغ، چارچوب رسمی NIST نیست و برای کاربرد اجرایی این کتاب تدوین شده است.

مفاهیم این بخش برای تیم‌های فنی هفت پیامد عملی دارد. در لایهٔ اجرایی این کتاب پیشنهاد می‌شود:

• ثبت اجزای سامانه (معماری): برای هر مورد کاربرد، اجزا (مدل، مجموعه‌داده، سرویس API، رابط کاربری و نقش انسانی) در یک نمودار ساده ثبت شود؛ منابع این بخش یادآورند که عناصر انسانی نیز جزو سامانهٔ AI است.
• چرخهٔ عمر مدل: نسخه‌گذاری مدل‌ها، ثبت مجموعه‌دادهٔ آموزش هر نسخه و فرایند مشخص «کنار گذاشتن» پیش‌بینی شود؛ مرحلهٔ چرخهٔ عمر هر مدل در فهرست دارایی به‌روز بماند.
• لاگ و پایش: درخواست و پاسخ مدل (با رعایت محرمانگی)، نسخهٔ مدل و شناسهٔ کاربر ثبت و به SIEM ارسال شود تا SOC رفتار غیرعادی را ببیند؛ همین لاگ‌ها شواهد قابل ممیزی فاز «استقرار و پایش»‌اند.
• آزمون: مجموعه‌آزمون مستقل پیش از استقرار و پایش انحراف داده و عملکرد پس از آن؛ نرخ خطای اندازه‌گیری‌شده در سند محدودیت‌ها ثبت شود.
• کنترل دسترسی و IAM: تفکیک دسترسی به دادهٔ آموزش و محیط تولید؛ اصل حداقل دسترسی برای کاربران، سرویس‌ها و عامل‌ها.
• RAG: منابع ورودی به پایگاه دانش اعتبارسنجی شوند و مجوز دسترسی به هر سند در بازیابی رعایت شود تا کاربر به محتوایی که حق دیدنش را ندارد نرسد.
• امنیت لایهٔ دفاعی: برای سامانه‌های مبتنی بر LLM و RAG، پوشش حداقلی موارد زیر پیشنهاد می‌شود (فهرست تهدید‌ها، نمونهٔ تدوینگر بر پایهٔ مفاهیم امنیتی همین بخش است): Prompt Injection و تزریق دستور از ورودی کاربر یا محتوای بازیابی‌شده؛ نشت داده از طریق خروجی مدل؛ سرقت یا استخراج مدل؛ مسموم‌سازی دادهٔ آموزش یا پایگاه RAG؛ مجوزهای بیش‌ازحد عامل‌های هوشمند (AI Agent)؛ اصالت و زنجیرهٔ تأمین مدل و وزن‌ها؛ امنیت API شامل احراز هویت، محدودسازی نرخ و اعتبارسنجی ورودی؛ یکپارچگی لاگ/SIEM/SOC؛ و رعایت DevSecOps در خط لولهٔ ساخت و استقرار.

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

نمونه فرم — فهرست دارایی‌ها و موارد کاربرد هوش مصنوعی (نمونه پیشنهادی تدوینگر بر پایه مفاهیم مطرح‌شده در منابع این فصل)

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

نمونه فرم — غربال محدودیت‌های ذاتی و ریسک‌های بنیادین سامانهٔ هوش مصنوعی (نمونه پیشنهادی تدوینگر بر پایه مفاهیم مطرح‌شده در منابع این فصل)