فهرست این فصلبخش ۵، فصل ۴۱ — صفحهٔ ۱ از ۲
بخش ۵، فصل ۴۱ — صفحهٔ ۱ از ۲
کاربرد در سازمان‌های ایرانی: ارزیابی هوش مصنوعی مولد و مدیریت محتوای مصنوعی
متن اصلی فارسی با منشأ، شناسه و پیوند استناد پایدار.
تفسیر اجرایی تدوینگر: از سنجش آزمایشگاهی تا کنترل سازمانی
سه سند مرجع این بخش — NIST AI 700-1 (ارزیابی آزمایشی سامانه‌های مولد متن‌به‌متن)، NIST AI 700-2 با عنوان ARIA (سنجش ریسک و اثر هوش مصنوعی در زمینهٔ عملیاتی واقعی) و NIST AI 100-4 (کاهش ریسک‌های محتوای مصنوعی، شامل احراز اصالت، رهگیری منشأ و برچسب‌گذاری) — در کنار هم یک پیام روشن دارند: کیفیت، ریسک و اصالت محتوای مولد را باید پیش از انتشار، در شرایط واقعی کاربرد و به‌صورت مستمر سنجید. تفسیر اجرایی تدوینگر این پیام را به سه پرسش عملی برای هر سازمان ایرانی تبدیل می‌کند:
- «کجا؟»: سازمان باید بداند هوش مصنوعی مولد کجا استفاده می‌شود؛ از چت‌بات مشتری و دستیار کارشناسان گرفته تا سرویس‌های ابری که کارکنان شخصاً به آن‌ها متصل می‌شوند (سایه‌فناوری). خروجی این گام، فهرست موارد کاربرد است.
- «چقدر خوب؟»: هر مورد کاربرد به ارزیابی کیفیت (مجموعهٔ آزمون مرجع و داوری انسانی) و ارزیابی زمینه‌محور ریسک و اثر در محیط عملیاتی واقعی نیاز دارد؛ نتیجهٔ آزمایشگاه به تنهایی قابل تعمیم نیست.
- «اصالت؟»: سازمان هم تولیدکنندهٔ محتوای مصنوعی است و هم گیرندهٔ آن؛ باید هم خروجی‌های خود را برچسب‌گذاری کند و هم برای محتوای مشکوک ورودی (مانند مدارک جعلی عمیق) فرایند راستی‌آزمایی منشأ داشته باشد.
واحدهای درگیر معمولاً شامل تحول دیجیتال/IT، امنیت اطلاعات، مدیریت ریسک، حقوقی، حریم خصوصی، انطباق، تیم داده، تیم AI/ML، مهندسی نرم‌افزار، SOC و تدارکات است. مدارک لازم حداقل عبارت‌اند از: سیاست استفاده از ابزارهای مولد، فهرست موارد کاربرد، برنامهٔ ارزیابی و نتایج آن، ثبت ریسک و فرم گزارش رخداد. شواهد قابل ممیزی شامل لاگ‌های ارزیابی و پایش، مصوبات کمیته و نمونه‌های خروجی برچسب‌دار است. تصمیم‌های کلیدی عبارت‌اند از تصویب انتشار یا توقف هر مورد کاربرد، تعیین طبقهٔ ریسک و تعیین الزامات برچسب‌گذاری.
در لایهٔ اجرایی این کتاب پیشنهاد می‌شود این تصمیم‌ها به کمیتهٔ موجود امنیت اطلاعات یا ریسک الحاق شود تا ساختار موازی ایجاد نشود؛ ممکن است بسته به صنعت و مقررات حاکم، الزامات دیگری نیز اعمال شود.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S01
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S01-426C038F
جعبهٔ پیاده‌سازی: برنامهٔ ارزیابی هوش مصنوعی مولد و مدیریت محتوای مصنوعی
در لایهٔ اجرایی این کتاب پیشنهاد می‌شود برنامهٔ زیر به‌عنوان نقشهٔ راه پایهٔ سازمان در نظر گرفته شود. مقادیر این جعبهٔ پیاده‌سازی، نمونهٔ پیشنهادی تدوینگر بر پایهٔ مفاهیم مطرح‌شده در منابع این بخش است و باید با مقیاس و پروفایل ریسک سازمان تنظیم شود.
| مؤلفه | شرح پیشنهادی |
|---|---|
| هدف | توانمندسازی سازمان در ارزیابی کیفی و امنیتی سامانه‌های مولد پیش از انتشار و مدیریت دوطرفهٔ ریسک محتوای مصنوعی |
| دامنه | همهٔ موارد کاربرد هوش مصنوعی مولد (متن، تصویر، صوت) شامل سرویس‌های ابری و ابزارهای مورد استفادهٔ کارکنان |
| مسئول اصلی | AI Officer (نقش معادل سازمانی: دبیر کارگروه هوش مصنوعی یا معاون تحول دیجیتال) |
| واحدهای درگیر | مدیریت ریسک، امنیت اطلاعات، حقوقی، حریم خصوصی، انطباق، تیم داده، تیم AI/ML، SOC، تدارکات، منابع انسانی |
| پیش‌نیازها | حاکمیت پایهٔ امنیت اطلاعات، مالک مشخص برای هر دارایی، دسترسی مستند به لاگ سامانه‌های مولد |
| ورودی‌ها | فهرست موارد کاربرد، قواعد کسب‌وکار، داده‌های نمونهٔ مجاز برای ارزیابی، نتایج ارزیابی تأمین‌کننده |
| فعالیت‌ها | ثبت مورد کاربرد؛ طبقه‌بندی ریسک؛ ساخت مجموعهٔ آزمون مرجع و داوری انسانی؛ ارزیابی زمینه‌محور؛ آزمون‌های امنیتی؛ برچسب‌گذاری خروجی؛ استقرار پایش؛ تمرین رخداد |
| خروجی‌ها | فهرست مصوب، گزارش ارزیابی هر مورد، تصمیم انتشار یا توقف، لاگ پایش، گزارش‌های رخداد |
| مدارک مورد نیاز | سیاست استفاده از ابزارهای مولد، روش اجرایی ارزیابی، برنامهٔ پایش، طرح خروج اضطراری |
| شواهد قابل ممیزی | صورت‌جلسات کمیته، مخزن نسخه‌دار مجموعه‌های آزمون، لاگ ارزیابی‌ها، نمونهٔ خروجی برچسب‌دار، گزارش رخداد بسته‌شده |
| KPIها | پوشش فهرست (٪)؛ نسبت موارد ارزیابی‌شده پیش از انتشار (٪)؛ میانگین زمان مهار رخداد AI؛ نسبت خروجی‌های برچسب‌دار (٪) |
| ریسک‌ها | ارزیابی صوری، تکیه صرف بر سنجه‌های خودکار، سایه‌فناوری، نشت داده در پرامپت، محتوای جعلی ورودی |
| کنترل‌ها | الزام مصوبه برای انتشار، پایش لاگ در SOC، آزمون دوره‌ای تزریق پرامپت و نشت داده، بازبینی فصلی فهرست |
| تناوب بازبینی | فهرست: فصلی؛ ارزیابی هر مورد: پیش از انتشار عمده و حداقل سالانه؛ آزمون امنیتی: شش‌ماهه |
| سطح بلوغ پیشنهادی | آغاز در سطح ۱ تا ۲ و هدف‌گذاری سطح ۳ تا ۴ ظرف ۱۲ تا ۱۸ ماه (به مدل بلوغ در بخش «اگر سازمان شما از صفر شروع می‌کند» نگاه کنید) |
فرم پیشنهادی TPL-P05-1 برای ثبت و ارزیابی یکدست هر مورد کاربرد، در همین بخش ارائه شده است.
نمونه فرم — فرم ثبت و ارزیابی مورد کاربرد هوش مصنوعی مولد (نمونهٔ پیشنهادی تدوینگر) (نمونه پیشنهادی تدوینگر بر پایه مفاهیم مطرح‌شده در منابع این فصل)
| فیلد | English | توضیح | نمونه |
|---|---|---|---|
| شناسهٔ مورد کاربرد | use_case_id | کد یکتا برای ارجاع در ثبت ریسک، گزارش ارزیابی و گزارش رخداد | UC-P05-014 |
| نام و شرح مورد کاربرد | use_case_title | شرح کوتاه کارکرد و ارزش کسب‌وکاری مورد کاربرد | دستیار پاسخگویی کارشناسان شعبه بر پایهٔ اسناد داخلی |
| نوع سامانه و مدل | system_and_model_type | مدل یا سرویس (داخلی یا ابری) و مؤلفه‌های همراه مانند RAG | LLM ابری از طریق API + پایگاه دانش داخلی (RAG) |
| داده‌های ورودی و منابع | input_data_sources | داده‌هایی که مدل می‌بیند یا بازیابی می‌کند و منبع آن‌ها | پرسش کارشناس + حدود ۱۲٬۰۰۰ سند قرارداد داخلی |
| خروجی و کاربران نهایی | output_and_users | آنچه تولید می‌شود و چه کسی آن را می‌بیند یا استفاده می‌کند | پیش‌نویس پاسخ برای کارشناس شعبه؛ نمایش نهایی فقط با تأیید کارشناس |
| زمینهٔ عملیاتی ارزیابی | operational_context | شرایط واقعی استفاده: کاربر، زبان، محیط و محدودیت‌ها | استفاده در شعبه‌ها، زبان فارسی، اسناد ناقص رایج در عملیات |
| طبقهٔ ریسک و اثر | risk_class | سطح ریسک تعیین‌شده و اثرهای اصلی در صورت خطا | بالا؛ پاسخ نادرست به مشتری، افشای دادهٔ حساس |
| روش ارزیابی و معیارها | evaluation_method | مجموعهٔ آزمون، داوری انسانی، آزمون‌های امنیتی و آستانهٔ پذیرش | مجموعهٔ مرجع ۲۰۰ نمونه + داوری سه‌نفره + آزمون تزریق پرامپت؛ آستانهٔ پذیرش ۹۰٪ |
| الزامات برچسب‌گذاری و منشأ | labeling_and_provenance | برچسب خروجی برای کاربر نهایی و شواهد منشأ در صورت نیاز | نمایش عبارت «پیشنهاد تولیدشده با هوش مصنوعی» در رابط کاربری |
| مالک کسب‌وکار و مالک فنی | owners | مسئولان پاسخگو برای نتیجهٔ کسب‌وکاری و برای عملکرد فنی | مالک کسب‌وکار: معاون خدمات؛ مالک فنی: تیم AI/ML |
| وضعیت و تاریخ بازبینی بعدی | status_next_review | وضعیت چرخهٔ عمر مورد کاربرد و زمان بازبینی بعدی | در عملیات پایش‌شده؛ بازبینی بعدی: پایان فصل |
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S02
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S02-0C1F257B
نگاشت مفهوم‌های NIST به هدف، کنترل، شواهد، KPI و مالک
جدول زیر نشان می‌دهد مفاهیم کلیدی منابع این بخش در ساختار یک سازمان ایرانی به چه هدف، کنترل، شواهد و شاخصی ترجمه می‌شوند. نگاشت و KPIهای آن، نمونهٔ پیشنهادی تدوینگر بر پایهٔ مفاهیم مطرح‌شده در منابع این بخش است.
| مفهوم NIST | هدف سازمانی | کنترل عملیاتی | شواهد | KPI نمونه | مالک |
|---|---|---|---|---|---|
| ارزیابی سامانه‌های مولد متن (NIST AI 700-1) | اطمینان از کیفیت خروجی پیش از ارائه به کاربر | مجموعهٔ آزمون مرجع، داوری انسانی و آستانهٔ پذیرش مصوب | گزارش ارزیابی و لاگ اجرای آزمون‌ها | نسبت موارد کاربرد با ارزیابی کامل پیش از انتشار (٪) | تیم AI/ML و مالک مدل |
| سنجش ریسک و اثر در زمینهٔ واقعی (NIST AI 700-2) | تصمیم آگاهانهٔ انتشار بر پایهٔ شرایط عملیاتی | ارزیابی زمینه‌محور با کاربر و دادهٔ واقعی و ثبت ریسک | سند زمینهٔ ارزیابی، ثبت ریسک، مصوبهٔ کمیته | تعداد موارد پرریسک با ارزیابی زمینه‌ای تکمیل‌شده | مدیر ریسک و AI Officer |
| احراز اصالت و رهگیری منشأ (NIST AI 100-4) | تشخیص محتوای جعلی در ورودی‌ها و ادعاها | فرایند راستی‌آزمایی منشأ برای محتوای حساس ورودی | لاگ راستی‌آزمایی و گزارش رخدادهای جعل | نسبت محتوای حساس ورودیِ راستی‌آزمایی‌شده (٪) | SOC و CISO |
| برچسب‌گذاری محتوای مصنوعی (NIST AI 100-4) | شفافیت در قبال مشتری و ذی‌نفعان | برچسب یا اعلان تولید ماشینه بر خروجی‌های مشتری‌رو | سیاست برچسب‌گذاری مصوب و نمونهٔ خروجی برچسب‌دار | نسبت خروجی‌های مولد دارای برچسب (٪) | مالک سیستم و انطباق |
| پاسخ به رخداد محتوای مصنوعی (NIST AI 700-2 و 100-4) | مهار سریع خطا و سوءاستفاده | فرایند گزارش، مهار و بستن رخداد AI | گزارش‌های رخداد و اقدام اصلاحی | میانگین زمان مهار رخداد AI | SOC و AI Officer |
نگاشت تدوینگر به استانداردهای ISO/IEC، همراه با سطح اطمینان:
| مفهوم این بخش | استاندارد | سطح اطمینان | دلیل مفهومی |
|---|---|---|---|
| حاکمیت، فهرست موارد کاربرد و نقش‌ها | ISO/IEC 42001 | DIRECT | هر دو بر سامانهٔ مدیریت AI و چرخهٔ برنامه‌ریزی، اجرا و بهبود مستمر تأکید دارند |
| ارزیابی و ثبت ریسک AI | ISO/IEC 23894 | DIRECT | هر دو فرایند ساخت‌یافتهٔ شناسایی، تحلیل و پاسخ به ریسک هوش مصنوعی را عرضه می‌کنند |
| لاگ، IAM و کنترل‌های فنی | ISO/IEC 27001 | PARTIAL | کنترل‌های امنیت اطلاعات زیربنای فنی هستند اما اختصاص به ارزیابی AI ندارند |
| روش‌شناسی ریسک زیربنایی | ISO/IEC 27005 | RELATED | چارچوب ریسک سایبری قابل اتکاست اما ریسک‌های خاص محتوای مولد خارج از دامنهٔ مستقیم آن است |
| داده‌های ارزیابی و حریم خصوصی | ISO/IEC 27701 | RELATED | مدیریت اطلاعات حریم خصوصی بر داده‌های ارزیابی اعمال می‌شود اما معادل مستقیمی برای منشأ محتوا ندارد |
| رهگیری منشأ و برچسب‌گذاری محتوا | — | NO_DIRECT_EQUIVALENT | در فهرست استانداردهای یادشده معادل مستقیم ندارد و به استانداردهای تخصصی رهگیری محتوا نیاز است |
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S03
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S03-4B4B384A
جدول RACI برنامهٔ ارزیابی و مدیریت محتوای مصنوعی
در جدول RACI زیر: R = مجری، A = پاسخگو، C = مشاور، I = مطلع. در سازمان‌های کوچک می‌توان چند نقش را در یک شخص تجمیع کرد؛ عبارت «نقش معادل سازمانی» برای تطبیق عناوین لاتین با ساختارهای مرسوم ایرانی به کار می‌رود.
| نقش | تصویب سیاست و چارچوب | ثبت و ارزیابی مورد کاربرد | استقرار کنترل‌های فنی | پایش رخداد و محتوای مصنوعی | بازبینی و ممیزی |
|---|---|---|---|---|---|
| هیئت‌مدیره | A | I | I | I | A |
| مدیرعامل | R | A | I | I | I |
| CIO | C | C | R | C | C |
| CTO | C | C | A | C | C |
| CISO (نقش معادل سازمانی: مدیر امنیت اطلاعات) | C | C | R | A | C |
| AI Officer (نقش معادل سازمانی: دبیر کارگروه هوش مصنوعی) | R | R | C | R | R |
| مدیر ریسک | C | C | I | C | R |
| انطباق (نقش معادل سازمانی: واحد انطباق مقررات) | C | C | C | C | R |
| حقوقی | C | C | I | C | C |
| ممیزی داخلی | I | I | I | I | R |
| حریم خصوصی | C | C | C | C | I |
| تیم داده | C | R | R | C | I |
| تیم AI/ML | C | R | R | C | C |
| مهندسی نرم‌افزار | I | C | R | C | I |
| SOC (نقش معادل سازمانی: مرکز پایش امنیت) | I | I | C | R | C |
| زیرساخت | I | C | R | C | I |
| تدارکات | C | C | C | I | I |
| منابع انسانی | C | I | I | I | C |
| مالک کسب‌وکار | C | R | C | C | C |
| مالک مدل/سیستم/داده | I | R | R | R | C |
در لایهٔ اجرایی این کتاب پیشنهاد می‌شود نقش «A» هر ستون در سند مصوب حاکمیتی به یک شغل مشخص — نه یک واحد — منصوب شود تا پاسخگویی در ممیزی قابل ردیابی باشد.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S04
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S04-65E75291
سناریوهای سازمانی: بانکی با دستیار مکالمه، بیمه‌ای با مدرک جعلی
سناریوی ۱ — دستیار کارشناسان در یک بانک ایرانی: بانک می‌خواهد دستیار مکالمه‌ای بر پایهٔ LLM و RAG روی اسناد داخلی، پاسخ پیشنهادی پرسش‌های مشتریان را به کارشناسان شعبه بدهد. مسیر پیشنهادی تدوینگر: ثبت مورد کاربرد و تعیین طبقهٔ ریسک بالا (دادهٔ حساس و ارتباط با مشتری)؛ ساخت مجموعهٔ آزمون مرجع فارسی و داوری انسانی کارشناسان؛ آزمون تزریق پرامپت و نشت داده پیش از انتشار؛ نمایش برچسب «پیشنهاد تولیدشده با هوش مصنوعی» در رابط کاربری؛ اتصال لاگ پرسش و پاسخ به SIEM و تعریف قاعدهٔ هشدار؛ و تمرین یک رخداد شبیه‌سازی‌شده با SOC. نتیجه: انتشار مرحله‌ای با پایش هفتگی و بازبینی سه‌ماهه.
سناریوی ۲ — مدرک جعلی در یک شرکت بیمه: در رسیدگی خسارت، تصویری مشکوک به دستکاری هوشمند ارسال می‌شود. سازمان پیش از هر ابزاری به «فرایند» نیاز دارد: علامت‌گذاری مدرک مشکوک توسط کارشناس، ارجاع به مسیر راستی‌آزمایی منشأ، ثبت در فرم گزارش رخداد، اعلان به امنیت اطلاعات و در صورت نیاز واحد حقوقی، و بازخورد نتیجه به برنامهٔ آموزش کارشناسان. این سناریو نشان می‌دهد مدیریت محتوای مصنوعی بیش از آن‌که مسئلهٔ ابزار باشد، مسئلهٔ فرایند و آموزش است.
هر دو سناریو عمومی و فرضی‌اند و به هیچ سازمان واقعی اشاره ندارند؛ ممکن است بسته به صنعت و مقررات حاکم، الزامات دیگری نیز اعمال شود.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S05
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S05-3DC2E746
مثال‌های تدوینگر برای سه مفهوم دشوار
سه مفهوم این بخش معمولاً در اجرا بدفهمیده می‌شوند؛ مثال‌های زیر از تدوینگر است:
- «ارزیابی در زمینهٔ واقعی» (در پرتو ARIA): یک مدل خلاصه‌سازی گزارش مالی در آزمایشگاه، با اسناد تمیز و پرسش‌های استاندارد، نمرهٔ خوب می‌گیرد؛ اما در عمل، با اسناد ناقص و پرسش‌های واقعی کارشناسان شعبه، خلاصه‌های گمراه‌کننده تولید می‌کند. درس اجرایی: نتیجهٔ ارزیابی بدون ثبت زمینهٔ آن — چه کسی، با چه داده‌ای، در چه شرایطی — قابل تعمیم نیست.
- «برچسب‌گذاری» در برابر «منشأ»: برچسب‌گذاری اظهار تولیدکننده است («این متن با هوش مصنوعی ساخته شده است») و مانند هر اظهاری می‌تواند حذف یا جعل شود؛ رهگیری منشأ و احراز اصالت، شواهد فنی همراه محتواست که راستی‌آزمایی مستقل را ممکن می‌کند. مثال: دربارهٔ ویدئویی ادعایی از یک مدیر، حذف برچسب ساده ممکن است اما راستی‌آزمایی منشأ نیازمند بررسی شواهد فنی در فرایند رسمی است.
- «سنجهٔ خودکار» در برابر «داوری انسانی» (در پرتو NIST AI 700-1): سنجه‌های خودکار عدد می‌دهند و مقایسهٔ مدل‌ها را سریع می‌کنند، اما درست بودن واقعی خروجی تخصصی را فقط داوری انسانی با معیار مشخص تضمین می‌کند. در لایهٔ اجرایی این کتاب پیشنهاد می‌شود ترکیب هر دو با آستانهٔ پذیرش مصوب، ملاک تصمیم انتشار باشد.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S06
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S06-8D71967D
چک‌لیست اجرایی ارزیابی هوش مصنوعی مولد و محتوای مصنوعی
طبقه‌بندی اقلام زیر — ضروری برای اجرای پایه / پیشنهادی / پیشرفته — طبقه‌بندی تدوینگر است و الزام منابع NIST نیست.
- شناسایی کنید همهٔ موارد کاربرد هوش مصنوعی مولد را، شامل ابزارهای ابری مورد استفادهٔ شخصی کارکنان. (ضروری برای اجرای پایه)
- ثبت کنید موارد کاربرد را در فهرست دارایی‌ها با مالک مشخص. (ضروری برای اجرای پایه)
- تعیین کنید طبقهٔ ریسک هر مورد را بر پایهٔ نوع داده، کاربر و اثر. (ضروری برای اجرای پایه)
- ارزیابی کنید خروجی موارد پرریسک را با مجموعهٔ آزمون مرجع و داوری انسانی، پیش از انتشار. (ضروری برای اجرای پایه)
- تعیین کنید آستانهٔ پذیرش و تصمیم‌گیرندهٔ انتشار را به‌صورت مصوب. (ضروری برای اجرای پایه)
- مستندسازی کنید زمینه، داده و نتیجهٔ هر ارزیابی را. (ضروری برای اجرای پایه)
- تصویب کنید سیاست برچسب‌گذاری خروجی‌های مشتری‌رو را و اعمال کنید آن را در رابط کاربری. (ضروری برای اجرای پایه)
- ثبت کنید رخدادهای هوش مصنوعی و محتوای مصنوعی را و گزارش کنید خلاصهٔ آن‌ها را به کمیتهٔ ریسک. (ضروری برای اجرای پایه)
- آزمون کنید مقاومت سامانه را در برابر تزریق پرامپت و نشت داده، پیش از انتشار و پس از هر تغییر عمده. (پیشنهادی)
- پایش کنید سنجه‌های کیفیت و ایمنی را در عمل و لاگ آن‌ها را در SIEM/SOC. (پیشنهادی)
- بازبینی کنید فهرست موارد کاربرد و ارزیابی‌ها را فصلی. (پیشنهادی)
- ارزیابی کنید تأمین‌کنندگان مدل و سرویس ابری را پیش از انعقاد قرارداد. (پیشنهادی)
- راستی‌آزمایی کنید منشأ محتوای حساس ورودی (مدارک، تصاویر، پیام‌های صوتی) را با فرایند و ابزار مشخص. (پیشرفته)
- مستقر کنید ارزیابی زمینه‌محور کامل با کاربران واقعی را برای موارد اثرگذار. (پیشرفته)
- آزمون کنید تیم قرمز را در سناریوهای سوءاستفاده از عامل‌ها و زنجیرهٔ تأمین مدل. (پیشرفته)
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S07
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S07-7BE1ED1B
اگر سازمان شما از صفر شروع می‌کند: توالی آغاز
توالی پیشنهادی تدوینگر برای ۹۰ روز نخست:
- هفتهٔ ۱ تا ۲: تعیین کنید میزبان حاکمیت را (AI Officer یا الحاق به کمیتهٔ امنیت اطلاعات موجود) و تصویب کنید سیاست یک‌صفحه‌ای استفاده از ابزارهای مولد را: چه کاربردی مجاز است و چه داده‌هایی نباید وارد پرامپت شود.
- هفتهٔ ۳ تا ۶: ثبت کنید فهرست موارد کاربرد را با پرسشگری از واحدها و بازبینی لاگ‌های خروجی؛ تعیین کنید طبقهٔ ریسک سادهٔ کم/متوسط/بالا.
- هفتهٔ ۷ تا ۱۲: ارزیابی کنید موارد پرریسک را با مجموعهٔ آزمون کوچک (۵۰ تا ۱۰۰ نمونه)، داوری انسانی و آزمون امنیتی پایه؛ برچسب‌گذاری کنید خروجی‌های مشتری‌رو را؛ ثبت کنید مسیر گزارش رخداد را در یک فرم واحد.
- پس از روز ۹۰: پایش کنید به‌صورت مستمر، بازبینی کنید فصلی و ارتقا دهید ارزیابی را به الگوی زمینه‌محور.
«حداقل حاکمیت قابل‌دوام هوش مصنوعی»: در لایهٔ اجرایی این کتاب، حداقلِ قابل‌دوام سه عنصر است — فهرست به‌روز موارد کاربرد، ارزیابی مستند پیش از انتشار و مسیر گزارش رخداد. این اصطلاح، اصطلاح رسمی NIST نیست و صرفاً پیشنهاد تدوینگر برای نقطهٔ شروع کم‌هزینه است.
برای سنجش پیشرفت، مدل بلوغ تدوینگر (سطح ۰ تا ۵):
| سطح | وضعیت سازمان |
|---|---|
| ۰ | آگاهی و فهرستی از استفادهٔ هوش مصنوعی مولد وجود ندارد |
| ۱ | فهرست موارد کاربرد موجود است اما ارزیابی منظم ندارد |
| ۲ | ارزیابی کیفی و امنیتی پیش از انتشار برای موارد پرریسک انجام می‌شود |
| ۳ | ارزیابی زمینه‌محور با کاربران واقعی و ثبت ریسک برقرار است |
| ۴ | پایش مستمر در SOC، مدیریت رخداد و تمرین‌های دوره‌ای برقرار است |
| ۵ | ارزیابی و پایش در چرخهٔ بهبود مستمر و تصمیم‌های کسب‌وکاری یکپارچه است |
این مدل بلوغ، چارچوب رسمی NIST نیست و برای کاربرد اجرایی این کتاب تدوین شده است.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S08
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S08-45AD34AB
زنجیرهٔ بازخورد انسانی در آموزش مدل‌های زبانی بزرگ: از قضاوت انسانی تا به‌روزرسانی وزن مدل
«این بخش برای شفاف‌سازی زنجیرهٔ آموزش مدل‌های زبانی بزرگ افزوده شده و لایهٔ تدوینگر است؛ ادعایی مبنی بر راهنمای رسمی NIST برای پیاده‌سازی RLHF ندارد.»
سردرگمی رایجی که در سازمان‌ها دیده می‌شود، خلط چهار مفهوم نزدیک اما متفاوت است: قضاوت انسانی (Human Judgment)، بازخورد انسانی (Human Feedback)، برچسب‌گذاری داده (Data Labeling) و رتبه‌بندی ترجیح (Preference Ranking). قضاوت انسانی مفهومی عام است (تصمیم یک فرد در هر بستری، از نظارت تا اعتبارسنجی)؛ برچسب‌گذاری داده، اعمال آن قضاوت به شکل برچسب روی داده‌های آموزشی است؛ رتبه‌بندی ترجیح، نوع خاصی از برچسب‌گذاری است که در آن انسان از میان چند خروجی مدل، بهتر را برمی‌گزیند؛ و بازخورد انسانی، داده‌ای است که از این قضاوت‌ها گردآوری و برای اصلاح رفتار مدل استفاده می‌شود.
نکتهٔ کلیدی: خودِ رابط برچسب‌گذاری یا رتبه‌بندی، وزن‌های مدل را تغییر نمی‌دهد. زنجیرهٔ صحیح این است:
تصمیم انسانی ← دادهٔ ترجیح/برچسب ← الگوریتم آموزش ← به‌روزرسانی وزن‌های مدل
خط لولهٔ معمول آموزش یک مدل زبانی بزرگ از این مراحل می‌گذرد:
| مرحله | شرح | نقش داده و بازخورد انسانی |
|---|---|---|
| پیش‌آموزش (Pre-training) | آموزش مدل پایه روی حجم عظیمی از متن با خودنظارتی | بدون بازخورد انسانی مستقیم؛ کیفیت داده منبع اهمیت دارد |
| تنظیم دقیق نظارت‌شده (SFT) | تنظیم مدل روی نمونه‌های ورودی-خروجی نوشته یا گزینش‌شده توسط انسان | داده‌های نمونه (demonstration) که حاشیه‌نویسان یا کارشناسان تهیه می‌کنند |
| دادهٔ ترجیح (Preference Data) | گردآوری رتبه‌بندی انسانی میان چند خروجی مدل برای یک درخواست واحد | رتبه‌بندی ترجیح؛ اینجاست که «بازخورد انسانی» به شکل داده درمی‌آید |
| مدل‌سازی پاداش / بهینه‌سازی ترجیح (Reward Modeling / Preference Optimization) | آموزش یک مدل پاداش که یاد می‌گیرد کدام خروجی را انسان‌ها ترجیح می‌دهند | دادهٔ ترجیح، ورودی آموزش مدل پاداش است |
| RLHF یا DPO | تنظیم مدل اصلی با استفاده از سیگنال مدل پاداش (RLHF) یا مستقیماً از دادهٔ ترجیح (DPO)، برای هم‌راستاسازی رفتار مدل | اینجا وزن‌های مدل اصلی به‌طور واقعی به‌روزرسانی می‌شوند |
| ارزیابی (Evaluation) | سنجش کیفیت، ایمنی و هم‌راستایی مدل نهایی پیش از استقرار | داوران انسانی یا سنجه‌های خودکار؛ می‌تواند به دور بعدی گردآوری دادهٔ ترجیح بازخورد دهد |
به‌بیان ساده: یک رتبه‌بند (Rater) که میان دو پاسخ چت‌بات، یکی را ترجیح می‌دهد، مستقیماً مدل را تغییر نمی‌دهد؛ تصمیم او بخشی از دادهٔ ترجیح می‌شود، آن داده مدل پاداش را آموزش می‌دهد یا مستقیماً وارد الگوریتم بهینه‌سازی ترجیح می‌شود، و تنها در آن مرحله وزن‌های مدل به‌روزرسانی می‌شوند. سازمان‌هایی که تیم رتبه‌بندی داخلی یا برون‌سپاری‌شده دارند، بهتر است این زنجیره را به‌روشنی برای رتبه‌بندها و مدیرانشان توضیح دهند تا انتظار نادرستی از تأثیر آنی هر رتبه‌بندی شکل نگیرد.
همان زیرساخت حاکمیتیِ برچسب‌گذاری داده که در فصل حاکمیت و مدیریت ریسک این کتاب معرفی شد (راهنمای حاشیه‌نویسی، درجهٔ اطمینان، اختلاف‌نظر میان رتبه‌بندها، داوری، نسخه‌بندی مجموعه‌دادهٔ ترجیح) برای دادهٔ ترجیح نیز به همان اندازه لازم است؛ رتبه‌بندهای انسانی نیز می‌توانند با یکدیگر اختلاف‌نظر داشته باشند و این اختلاف باید ثبت و داوری شود، نه نادیده گرفته شود.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P05-C41-S09
شناسهٔ محتوا KDJ-AI-2026E1-P05-C41-S09-43B306C8