اخلاق هوش مصنوعی در تولید محتوا؛ حقوق، افشا و پاسخ‌گویی

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

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

اخلاق هوش مصنوعی در تولید محتوا دقیقاً چیست؟

موضوع فقط مؤدب‌بودن مدل یا تشخیص سرقت ادبی نیست. یک سیستم مسئولانه باید درباره هفت پرسش جواب قابل اثبات بدهد:

1. Purpose: چرا از AI استفاده می‌کنیم و مخاطب چه تصمیمی با خروجی می‌گیرد؟
2. Rights: برای داده، متن، عکس، موسیقی، چهره و صدا چه حق یا مجوزی داریم؟
3. Truth: کدام ادعاها واقعیت‌سنجی شده‌اند و منبع معتبرشان چیست؟
4. Representation: چه گروهی ممکن است حذف، تحقیر یا کلیشه‌ای نمایش داده شود؟
5. Transparency: مخاطب چه چیزی را، چه زمان و با چه زبانی باید بداند؟
6. Accountability: چه کسی اجازه انتشار می‌دهد و چه کسی خطا را اصلاح می‌کند؟
7. Evidence: اگر مشتری، پلتفرم یا نهاد ناظر پرسید، چه مدرکی نشان می‌دهیم؟

این نگاه با پروفایل هوش مصنوعی مولد NIST AI ۶۰۰-۱ هم‌جهت است: سندی داوطلبانه و میان‌بخشی برای واردکردن ملاحظات اعتمادپذیری به طراحی، استفاده و ارزیابی سیستم‌های مولد. این چارچوب قانون ایران یا گواهی انطباق نیست؛ از آن به‌عنوان ورودی Governance و ارزیابی ریسک استفاده کنید.

اول واژه‌ها را از هم جدا کنید

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

برای جزئیات انتخاب مدل، API، Eval، امنیت و MLOps به راهنمای هوش مصنوعی در وب‌اپلیکیشن مراجعه کنید. این صفحه بر حقوق، افشا و پاسخ‌گویی محتوای منتشرشده تمرکز دارد.

ریسک را بر اساس اثر خروجی بسنجید، نه نام ابزار

یک مدل واحد می‌تواند برای پیشنهاد عنوان کم‌ریسک و برای ساخت توصیه پزشکی بسیار پرریسک استفاده شود. طبقه‌بندی را از Use case، مخاطب، رسانه، امکان آسیب و برگشت‌پذیری تصمیم بسازید.

«پرریسک» در این جدول، طبقه‌بندی عملیاتی داخلی است و لزوماً همان تعریف حقوقی High-risk AI در یک قانون مشخص نیست. این تمایز را در سیاست سازمان بنویسید تا تیم محتوا یک امتیاز داخلی را حکم حقوقی تلقی نکند.

پیش از Prompt یک Use-case Contract بنویسید

یک Brief خوب فقط موضوع و کلمه کلیدی ندارد. قرارداد کاربرد باید حدود مسئولیت را پیش از آن‌که خروجی جذاب تصمیم‌ها را منحرف کند، ثبت کند:

Purpose: این محتوا چه مسئله‌ای را حل می‌کند؟
Audience/decision: مخاطب با آن چه تصمیمی می‌گیرد؟
Modality: متن، تصویر، صدا یا ویدیو؟
AI role: ایده، پیش‌نویس، ویرایش، تولید کامل یا انتشار؟
Inputs: منبع، مالک، مجوز، طبقه داده و محدودیت استفاده
People: فرد واقعی، کودک، گروه آسیب‌پذیر یا شخصیت عمومی؟
Claims: ادعاهای مادی و منبع لازم
Risk tier: کم، متوسط، زیاد یا بحرانی
Human reviewer: نام، صلاحیت، اختیار رد و زمان لازم
Disclosure: متن، محل، زمان و فرمت ماشین‌خوان
Territory/channel: کشور، پلتفرم، تبلیغ یا تحریریه
Correction/appeal: مالک، SLA، کانال گزارش و اقدام توقف

اگر یکی از فیلدهای Rights، People، Reviewer یا Correction خالی است، خروجی هنوز Ready to publish نیست؛ حتی اگر از نظر نگارشی بی‌نقص باشد.

زنجیره مسئولیت؛ چه کسی پاسخ‌گوست؟

تأمین‌کننده مدل، نویسنده Prompt، ویراستار، صاحب برند و پلتفرم نقش‌های متفاوتی دارند. جمله «AI تولید کرد» مسئولیت را از سازمان منتشرکننده برنمی‌دارد. برای هر دارایی دست‌کم این نقش‌ها را مشخص کنید:

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

حقوق ورودی؛ هر چیزی که قابل Upload است، مجاز نیست

پیش از واردکردن فایل یا متن به ابزار، منبع و اختیار استفاده را ثبت کنید. ورودی ممکن است متعلق به کارمند، مشتری، عکاس، ناشر، پیمانکار یا شریک تجاری باشد و اجازه انتشار قبلی الزاماً اجازه پردازش با یک سرویس AI را شامل نمی‌شود.

• مالکیت و مجوز: صاحب دارایی کیست و مجوز چه استفاده، رسانه، قلمرو و مدتی را پوشش می‌دهد؟
• محرمانگی: قرارداد مشتری، برنامه محصول، Source code یا گزارش داخلی اجازه خروج از محیط کنترل‌شده دارد؟
• داده شخصی: Purpose، ضرورت، حداقل‌سازی، دسترسی، نگهداری و حذف چیست؟
• شرایط سرویس: داده برای آموزش، بهبود، Abuse monitoring یا Log نگهداری می‌شود؟ کنترل Opt-out یا Enterprise چه دامنه‌ای دارد؟
• زنجیره تأمین: Sub-processor، محل پردازش، Export/Delete و تغییر نسخه Provider چگونه مدیریت می‌شود؟

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

حقوق خروجی؛ پاسخ جهانی و همیشگی وجود ندارد

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

برای نمونه، اداره کپی‌رایت ایالات متحده در گزارش Part ۲ گفته است استفاده کمکی از AI مانع حمایت نیست، اما در نظام آمریکا حمایت به عناصر بیانیِ کافی که انسان تعیین کرده وابسته است؛ Prompt به‌تنهایی در وضعیت فناوری بررسی‌شده کافی دانسته نشده است. این یک نمونه از موضع رسمی آمریکا است، نه نتیجه حقوقی برای ایران یا همه کشورها.

برای هر خروجی مهم این شواهد را نگه دارید:

• نسخه ورودی و منشأ آن؛
• نام سرویس، Plan و Snapshot شرایط در تاریخ تولید؛
• مراحل انتخاب، ترکیب، تدوین و تغییر خلاقانه انسانی؛
• Reverse search یا بررسی شباهت متناسب با نوع رسانه؛
• قرارداد انتقال حقوق با کارمند، فریلنسر یا استودیو؛
• محدودیت قلمرو، رسانه، مدت یا استفاده تبلیغاتی.

سرقت ادبی و شباهت؛ Detector حکم صادر نمی‌کند

یک «درصد AI» یا «درصد Plagiarism» به‌تنهایی اثبات نمی‌کند محتوا قانونی، اصیل یا غیراخلاقی است. ابزار ممکن است متن عمومی را مشابه، متن بازنویسی‌شده را متفاوت یا نوشته انسانی فارسی را AI تشخیص دهد.

بررسی عملی را لایه‌ای انجام دهید:

1. عبارت‌های متمایز را با جست‌وجوی دقیق و Corpus مرتبط مقایسه کنید.
2. برای تصویر، Reverse image search و برای صدا/موسیقی، Fingerprint مناسب به کار ببرید.
3. شباهت ساختاری، شخصیت، Trade dress، علامت تجاری و تقلید سبک را جدا بررسی کنید.
4. نتیجه ابزار را همراه نمونه تطبیق به انسان متخصص بدهید؛ Score خالی قابل تصمیم نیست.
5. برای ریسک زیاد، بازبینی حقوقی و ثبت تصمیم انجام دهید.

به‌جای درخواست «دقیقاً مثل نویسنده زنده X بنویس»، ویژگی‌های قابل مشاهده و مستقل مثل طول جمله، میزان رسمیت، ساختار استدلال و واژه‌نامه برند را تعریف کنید. برای ساخت این مرزها، راهنمای صدای برند، Tone و Style Guide مفیدتر از تقلید شخص است.

چهره و صدا؛ رضایت باید دامنه‌دار باشد

اجازه عکاسی در یک رویداد، اجازه ساخت صدای مصنوعی برای آگهی سال بعد نیست. برای Digital replica یا هر بازنمایی قابل شناسایی، رضایت مکتوب باید دست‌کم هویت فرد، هدف، نوع رسانه، کانال، قلمرو، مدت، نوع ویرایش، استفاده تبلیغاتی، جبران مالی، Sub-license، مسیر توقف و اثر لغو بر نسخه‌های قبلی را پوشش دهد.

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

افشا؛ چه وقت، کجا و با چه عبارتی؟

هدف افشا کمک به تصمیم آگاهانه مخاطب است، نه نمایش یک Badge تزئینی. افشا وقتی مهم‌تر می‌شود که AI نقش مادی در پیام داشته، رسانه می‌تواند واقعی تلقی شود، فرد واقعی بازنمایی شده، محتوا تبلیغاتی است یا خروجی درباره موضوع عمومی و پراثر صحبت می‌کند.

عبارت افشا باید مشخص باشد. «با فناوری ساخته شد» مبهم است؛ «این صدا با AI از صدای X و با رضایت او برای این راهنما ساخته شده است» به مخاطب اطلاعات تصمیم‌پذیر می‌دهد. افشا نباید در Tooltip نامرئی، انتهای Terms یا رنگ کم‌کنتراست پنهان شود.

قانون اتحادیه اروپا چه نمونه‌ای از شفافیت می‌دهد؟

برای کسب‌وکاری که در قلمرو اتحادیه اروپا فعالیت مرتبط دارد، باید Scope حقوقی دقیق بررسی شود. در Snapshot رسمی ۱۰ اوت ۲۰۲۶، راهنمای کمیسیون اروپا درباره ماده ۵۰ AI Act می‌گوید تعهدهای شفافیت این ماده از ۲ اوت ۲۰۲۶ اعمال می‌شوند.

متن رسمی Regulation (EU) ۲۰۲۴/۱۶۸۹ میان نقش Provider و Deployer تفکیک می‌کند: برای برخی خروجی‌های مصنوعی، نشانه‌گذاری ماشین‌خوان و قابل تشخیص مطرح است؛ Deployerِ Deepfake تصویری، صوتی یا ویدیویی باید مصنوعی یا دست‌کاری‌شدن را افشا کند؛ و برای متن AI درباره امور مورد توجه عمومی نیز قواعد و استثنای بازبینی/کنترل تحریریه با پذیرش مسئولیت آمده است. جزئیات هنر، طنز، داستان، ویرایش کمکی و الزامات دسترس‌پذیری هم مهم‌اند.

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

Provenance و Content Credentials چه می‌کنند؟

Provenance تاریخچه قابل بررسی یک دارایی را ثبت می‌کند: منبع، ابزار ایجاد یا تغییر، اجزای استفاده‌شده و امضا. در استاندارد باز C2PA Content Credentials 2.4، Manifest می‌تواند به دارایی به‌صورت رمزنگارانه متصل و ادعاهای منشأ در آن امضا شود.

اما Content Credentials ماشین حقیقت‌سنج نیست. توضیح رسمی C2PA تصریح می‌کند که استاندارد درباره «خوب یا بد» یا درست‌بودن واقعیتِ ادعا داوری نمی‌کند؛ اعتبار امضا و پیوند ادعا با دارایی را می‌سنجد. Metadata ممکن است حذف شود، زنجیره می‌تواند ناقص باشد و نبود Credential نیز به‌خودی‌خود نشانه جعلی‌بودن محتوا نیست.

مدل دفاعی بهتر سه لایه دارد:

1. افشای انسانی: متن روشن و نزدیک به محل تصمیم؛
2. منشأ ماشین‌خوان: C2PA/Content Credentials یا روش سازگار پلتفرم؛
3. شواهد سازمانی: Asset log، Consent، Claim review و نسخه قابل بازیابی.

واقعیت‌سنجی را در سطح ادعا انجام دهید

خواندن کل متن و گفتن «به نظر درست می‌آید» بازبینی نیست. ادعاهای قابل ابطال را استخراج و برای هرکدام Scope، تاریخ، واحد، منبع و تصمیم ثبت کنید.

منبع باید واقعاً از Claim پشتیبانی کند؛ وجود لینک کنار جمله کافی نیست. برای ساخت Claim→Evidence→Review و اصول اعتماد، راهنمای E‑E‑A‑T و شواهد اعتماد را ببینید.

در YMYL و موضوعات پراثر، Disclaimer کنترل اصلی نیست

نوشتن «این متن توصیه پزشکی نیست» زیر توصیه خطرناک، آسیب را خنثی نمی‌کند. در سلامت، مالی، حقوقی، ایمنی، انتخابات و حقوق افراد:

• دامنه مجاز و ادعاهای ممنوع را پیش از تولید تعریف کنید؛
• منابع اولیه یا مرجع و تاریخ به‌روزرسانی را اجباری کنید؛
• متخصصِ دارای Scope مناسب بازبینی کند؛
• عدم قطعیت، جمعیت هدف و استثناها را حفظ کنید؛
• مدل اجازه اختراع Citation یا توصیه شخصی بدون داده کافی نداشته باشد؛
• مسیر ارجاع به انسان و تماس اضطراری متناسب با موضوع وجود داشته باشد؛
• انتشار خودکار و Batch generation بدون Gate ممنوع باشد.

گاهی تصمیم اخلاقی درست، استفاده‌نکردن از GenAI است: مثلاً ساخت توصیه شخصی سلامت بدون تیم بالینی، داده معتبر و مسئول پاسخ‌گو.

سوگیری را با یک‌بار خواندن «لحن» پیدا نمی‌کنید

سوگیری ممکن است در انتخاب موضوع، داده، Prompt، تصویر، ترجمه، Ranking یا فرایند تأیید وارد شود. مثال ایرانی: تولید پیوسته تصویر خانواده شهریِ تهرانی به‌عنوان نماینده همه ایران؛ ناتوانی در فهم فارسی محاوره، Finglish یا لهجه؛ نسبت‌دادن شغل‌ها به جنسیت؛ یا حذف افراد دارای معلولیت و قومیت‌های مختلف.

برای Use case پرتکرار، Evaluation set لایه‌ای بسازید:

• فارسی رسمی، محاوره، نیم‌فاصله، ی/ک عربی و فارسی؛
• لهجه یا گونه زبانی مرتبط، بدون کاریکاتورکردن؛
• جنسیت، سن، معلولیت، طبقه، شهر و منطقه متناسب با مخاطب؛
• موارد ضدکلیشه و موارد مبهم؛
• Promptهای خصمانه برای تولید توهین، حذف یا Sexualization؛
• امکان Abstain و ارجاع به انسان.

فقط Average score گزارش نکنید. نرخ خطای هر Slice، شدیدترین Harm، تعداد اعتراض معتبر و فاصله گروه‌ها را ببینید. نمونه کم نیز حکم قطعی درباره «بی‌طرفی» نمی‌دهد؛ نتیجه باید با دامنه و محدودیت ثبت شود.

بازبینی انسانی فقط وقتی کنترل است که اختیار و شایستگی دارد

Human-in-the-loop به‌تنهایی نشان کیفیت نیست. بازبین زیر فشار حجم، بدون منبع، بدون تخصص یا بدون اختیار ردکردن، به Rubber stamp تبدیل می‌شود.

بازبینی قابل اتکا این ویژگی‌ها را دارد:

• ریسک و معیار پذیرش را می‌داند؛
• به ورودی، منبع و سابقه تغییر دسترسی دارد؛
• برای ادعاهای تخصصی صلاحیت متناسب دارد؛
• زمان کافی و سقف بار روزانه دارد؛
• می‌تواند خروجی را رد، متوقف یا Escalate کند؛
• از منبع مستقل استفاده می‌کند و به Citation ساخت مدل تکیه نمی‌کند؛
• تصمیم و دلیل را ثبت می‌کند؛
• در موارد بحرانی از تولیدکننده خروجی استقلال دارد.

دسترس‌پذیری بخشی از مسئولیت محتواست

محتوای مصنوعی نباید مخاطبی را که از Screen reader، Caption یا Transcript استفاده می‌کند از زمینه افشا محروم کند. برای تصویر AI، Alt باید آنچه برای هدف صفحه مهم است توصیف کند؛ نه این‌که همیشه صرفاً عبارت «تصویر ساخته‌شده با AI» را تکرار کند. افشای منشأ را در Caption یا متن مجاور هم قرار دهید تا مستقل از Alt قابل دسترسی باشد.

• ویدیو: Caption دقیق، Transcript و توصیف تغییر مادی؛
• صدای مصنوعی: افشا پیش از پخش یا ابتدای فایل، همراه نسخه متنی؛
• برچسب: کنتراست مناسب و قابل خواندن با فناوری کمکی؛
• نمودار: داده یا خلاصه متنی، نه تصویر بدون جایگزین؛
• ترجمه: QA فارسی، نام‌ها، عدد، واحد و ترتیب RTL/BiDi.

SEO؛ Google روش تولید را جای کیفیت نمی‌نشاند

در Snapshot رسمی این مقاله، راهنمای Google Search درباره محتوای مولد می‌گوید GenAI می‌تواند برای تحقیق و ساختاردهی مفید باشد؛ اما ساخت انبوه صفحه بدون ارزش افزوده ممکن است سیاست Scaled content abuse را نقض کند. بنابراین «انسان یک‌بار خوانده» یا «AI را افشا کردیم» مجوز تولید هزار صفحه مشابه نیست.

برای SEO این سه مرز را نگه دارید:

• ارزش یکتا، شواهد و حل مسئله را بسنجید؛ نه درصد AI یا چگالی کلمه؛
• صفحه‌های نزدیک را Merge کنید و Intent ownership داشته باشید؛
• روش تولید، تخصص و اصلاح را جایی توضیح دهید که برای اعتماد کاربر مفید است؛ افشا را ترفند رتبه‌گیری نکنید.

برای Source Pack، Fact-check، SEO و فرایند انتشار، مقاله تخصصی گردش‌کار محتوای AI و سئو را بخوانید. برای انتخاب Portfolio، Distribution و Outcome نیز راهنمای استراتژی بازاریابی محتوا مرجع مناسب‌تری است.

Vendor due diligence؛ مدل فقط یک Endpoint نیست

پیش از خرید یا تمدید سرویس، یک رجیستر نسخه‌دار بسازید. صفحه Marketing تأمین‌کننده کافی نیست؛ Contract، تنظیمات واقعی Account و مسیر خروج مهم‌اند.

قیمت API تنها جزء کوچکی از هزینه است. نیروی بازبینی، Fact-check، مجوز، Incident، اصلاح و خروج از Vendor را در TCO ببینید؛ روش آن در مقاله هزینه پیاده‌سازی AI در سایت آمده است.

سیاست سازمانی را به Gate تبدیل کنید

سیاستی که فقط می‌گوید «اخلاق را رعایت کنید» قابل آزمون نیست. آن را به قواعد Allow، Conditional و Prohibited تبدیل کنید.

Ruleها را در CMS، فرم Brief و دسترسی ابزار پیاده کنید. آموزش بدون محدودیت فنی در برابر اشتباه عجولانه یا نشت داده ضعیف است؛ محدودیت فنی بدون آموزش نیز دور زده می‌شود.

حداقل رکورد لازم برای هر Asset

همه Promptهای خام را بی‌نهایت نگه ندارید؛ ممکن است خودشان داده حساس داشته باشند. یک رکورد حداقلی، Purpose-bound و دارای Retention بسازید:

asset_id / channel / publish_url / version
owner / creator / reviewers / approval_time
use_case / risk_tier / audience / territory
provider / model_or_service_version / account_type
input_sources / licenses / consent_ids / data_class
material_claims / evidence_ids / review_outcome
AI_role / material_edits / similarity_check
disclosure_text / placement / machine_readable_provenance
known_limits / expiry_or_review_date
complaint_channel / correction_SLA / withdrawal_status

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

Scorecard پذیرش؛ کیفیت را چندبعدی بسنجید

امتیاز میانگین نباید خطای بحرانی را پنهان کند. قواعد Hard fail را پیشاپیش تعیین کنید: فقدان رضایت چهره، Citation جعلی، نشت Secret یا توصیه پزشکی خطرناک با Score خوب لحن جبران نمی‌شود.

نمونه ۱: توضیح محصول فروشگاه ایرانی

یک فروشگاه می‌خواهد ۵۰۰ توضیح کالا از فید تأمین‌کننده تولید کند. ریسک متوسط است، اما اگر AI ویژگی ناموجود بسازد، مرجوعی و ادعای گمراه‌کننده ایجاد می‌شود.

1. منبع حقیقت را SKU/PIM و آخرین فید تأییدشده تعیین کنید.
2. مدل اجازه ساخت ویژگی خارج از Schema نداشته باشد.
3. برای ضمانت، جنس، ظرفیت و کشور سازنده Hard validation بگذارید.
4. نمونه‌گیری فقط برای لحن نباشد؛ Error rate هر فیلد و هر تأمین‌کننده سنجیده شود.
5. توضیح تغییر مادی تصویر محصول کنار تصویر بیاید.
6. اگر نرخ خطای بحرانی از Threshold گذشت، Batch متوقف و نسخه‌ها Rollback شوند.

نمونه ۲: مقاله سلامت فارسی

تیم از AI برای ساخت پیش‌نویس «علائم کمبود یک ویتامین» استفاده می‌کند. جست‌وجوی زیاد، مجوز کاهش کنترل نیست.

• پرسش و حدود مقاله را متخصص تعیین می‌کند؛
• منابع مرجع با تاریخ و جمعیت هدف در Source Pack ثبت می‌شوند؛
• هر Claim پزشکی به منبع و Scope متصل است؛
• مدل اجازه ساخت دوز، تشخیص یا جایگزینی مراجعه ندارد؛
• بازبین دارای تخصص مناسب نام و تاریخ بازبینی دارد؛
• هشدار مراجعه فوری بر اساس راهنمای معتبر و بدون اغراق نوشته می‌شود؛
• کانال اصلاح برای پزشک و خواننده قابل مشاهده است.

نمونه ۳: اینفلوئنسر مصنوعی در تبلیغ

برند یک شخصیت واقع‌نما می‌سازد که محصول مراقبت پوست را توصیه می‌کند. حتی اگر شخص واقعی Clone نشده باشد، مخاطب ممکن است آن را تجربه انسانی واقعی تصور کند.

ماهیت مصنوعی شخصیت و رابطه تبلیغاتی را نزدیک پیام افشا کنید؛ Claim محصول را با مدرک مستقل بسنجید؛ از Testimonial ساختگی مثل «من سه ماه استفاده کردم» پرهیز کنید؛ ظاهر را برای گروه‌های مختلف ارزیابی کنید؛ و برای Commentهایی که سؤال سلامت می‌پرسند مسیر پاسخ انسانی داشته باشید. طراحی افشا نیز نباید یک دارک‌پترن باشد.

نمونه ۴: صدای مصنوعی مدیرعامل در بحران

تولید سریع Voice clone برای پاسخ به بحران جذاب است، اما بیشترین خطر جعل، نسخه قدیمی و سوءبرداشت را دارد. Script، رضایت موردی، زمان انقضا، کانال‌های مجاز و افشای ابتدای صوت را ثبت کنید. فایل نهایی را امضا/دارای Provenance کنید، نسخه‌های غیرمجاز را رصد و Contact رسمی برای تأیید اصالت اعلام کنید. اگر تأیید مدیر و تیم بحران در دسترس نیست، متن رسمی انسانی گزینه امن‌تری است.

Runbook انتشار مسئولانه

1. Intake: Use-case Contract، سطح ریسک و Owner را ثبت کنید.
2. Rights gate: مجوز ورودی، Consent، Data class و شرایط Provider را تأیید کنید.
3. Generate: نسخه ابزار و ورودی‌ها را ثبت و خروجی را از انتشار جدا نگه دارید.
4. Evaluate: Claim، شباهت، سوگیری، حریم خصوصی، برند و Accessibility را بسنجید.
5. Review: بازبین متناسب با ریسک، با اختیار رد، تصمیم ثبت کند.
6. Disclose: متن انسانی و Provenance ماشین‌خوان را بر اساس Context اعمال کنید.
7. Release: Accountable editor، URL/Asset ID، تاریخ و Expiry را امضا کند.
8. Monitor: شکایت، تصحیح، Drift، تغییر Provider و بازنشر خارج Context را رصد کنید.

Runbook خطا و اصلاح

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

1. نسخه، URL، زمان، Screenshot، Prompt/ورودی مجاز و مسیر توزیع را Freeze کنید.
2. شدت آسیب و ادامه مواجهه را بسنجید؛ در خطر زیاد انتشار و Campaign را متوقف کنید.
3. مالک حقوق/حریم خصوصی/موضوع را وارد کنید و به گزارش‌دهنده رسید بدهید.
4. اصلاح، حذف، جایگزینی، اطلاع به افراد متأثر و انتشار Correction را بر اساس آسیب انتخاب کنید.
5. نسخه Cache، Feed، CDN، شبکه اجتماعی، شریک و آرشیو تحت کنترل را دنبال کنید.
6. Root cause را در داده، Prompt، مدل، Rule، Review، افشا یا توزیع مشخص کنید.
7. Eval و Gate را به‌روزرسانی کنید؛ فقط به کاربر نگویید «دقت کند».

شاخص‌هایی که واقعاً پاسخ‌گویی را نشان می‌دهند

تعداد خروجی یا سرعت تولید، معیار اخلاق نیست. Dashboard را با Outcome و Guardrail بسازید:

• Accepted asset rate: سهم خروجی‌های پذیرفته‌شده پس از QA؛
• Critical error rate: خطای حقوق، سلامت، هویت، Secret یا Claim مهم؛
• Evidence coverage: سهم Claimهای مادی با شاهد قابل قبول؛
• Consent coverage: دارایی‌های مشمول با رضایت معتبر و دامنه منطبق؛
• Disclosure coverage: سناریوهای مشمول با افشای صحیح و قابل دسترسی؛
• Correction rate: اصلاح به تفکیک علت، کانال و شدت؛
• Time to contain/correct: زمان توقف توزیع و زمان اصلاح کامل؛
• Appeal outcome: تعداد اعتراض، نرخ پذیرش و گروه‌های متأثر؛
• Review load: زمان، صف و نرخ Rubber-stamp احتمالی؛
• Cost per accepted asset: هزینه تولید + Review + Correction، نه فقط API.

این شاخص‌ها را با سطح ریسک و نوع محتوا Slice کنید. یک نرخ خطای ۱٪ برای Alt تزئینی و یک نرخ خطای ۱٪ برای توصیه دارویی معنای یکسان ندارد.

ملاحظات ویژه کسب‌وکار ایرانی

«بومی‌سازی» فقط ترجمه رابط نیست. تصمیم Responsible AI در ایران باید واقعیت داده، زبان، عملیات و قلمرو انتشار را در نظر بگیرد:

• قانون و قرارداد: تعهدهای قراردادی، قوانین ایران و هر قلمرو هدف را جدا بررسی کنید؛ GDPR یا EU AI Act را خودکار به همه کسب‌وکارهای ایرانی تعمیم ندهید.
• زبان: فارسی رسمی/محاوره، Finglish، ی/ک، نیم‌فاصله، BiDi، نام‌ها و لهجه‌ها را در Eval واقعی بگنجانید.
• عدد و زمان: ریال/تومان، درصد، ممیز، تاریخ شمسی/میلادی و منطقه زمانی را با منبع قطعی Validate کنید.
• فرهنگ و تنوع: تهران را معادل ایران نگیرید و قومیت، پوشش، خانواده، جنسیت یا مذهب را کلیشه‌ای تولید نکنید.
• تأمین‌کننده: Eligibility، تغییر دسترسی، پرداخت، ارز، تأخیر شبکه، Data location و خروج از سرویس را سناریویی مدیریت کنید.
• رسانه مصنوعی: رضایت چهره/صدا، کانال رسمی تأیید و پاسخ سریع به جعل را جدی بگیرید.
• موضوع حساس: سلامت، مالی، حقوقی، کودک، بحران، انتخابات و دین را با Gate تخصصی و حقوقی بالاتر اداره کنید.
• اصلاح: فرم گزارش فارسی، شماره پیگیری و SLA متناسب با شدت داشته باشید.

برنامه اجرایی ۳۰/۶۰/۹۰روزه

روز ۱ تا ۳۰: Scope و مهار ریسک فوری

• فهرست Use caseها، ابزارها، حساب‌ها، Ownerها و کانال‌های انتشار را بسازید.
• Secret، داده مشتری، Clone چهره/صدا و انتشار خودکار پرریسک را تا تعیین Gate متوقف کنید.
• Risk tier، Use-case Contract و فهرست Useهای ممنوع را تصویب کنید.
• ده Asset پرمخاطب را برای حقوق، Claim، افشا و امکان اصلاح ممیزی کنید.

روز ۳۱ تا ۶۰: Evidence و کنترل انتشار

• Asset log، Consent template، Claim ledger و Release record را در Workflow قرار دهید.
• بازبین و Accountable editor هر سطح ریسک را تعیین کنید.
• ماتریس افشا، استاندارد Caption/Alt و روش Provenance را Pilot کنید.
• Vendor register و Exit/Deletion test را برای ابزارهای اصلی اجرا کنید.
• Golden set فارسی و Hard-failهای حقوق، صحت و سوگیری را بسازید.

روز ۶۱ تا ۹۰: تمرین رخداد و تصمیم Scale

• یک سناریوی Citation جعلی، یک شکایت چهره/صدا و یک نشت داده را Tabletop کنید.
• زمان توقف، اصلاح، اطلاع و پاک‌سازی کانال‌ها را اندازه بگیرید.
• Dashboard کیفیت، حقوق، افشا، اعتراض و Cost per accepted asset را راه بیندازید.
• Use caseهای فاقد ارزش یا دارای ریسک کنترل‌نشده را متوقف کنید.
• سیاست را با شواهد Pilot و تغییر Terms تأمین‌کننده نسخه جدید دهید.

چک‌لیست Gate پیش از انتشار

• هدف، مخاطب، نقش AI و سطح ریسک ثبت شده است.
• مالک و مجوز همه ورودی‌های مادی روشن است.
• داده محرمانه/شخصی حداقل و مطابق سیاست پردازش شده است.
• رضایت چهره، صدا یا هویت با دامنه استفاده منطبق است.
• شرایط و نسخه Provider در تاریخ تولید ثبت شده است.
• Claimهای مهم منبع، Scope، تاریخ و Reviewer دارند.
• شباهت و حقوق خروجی بر اساس ریسک بررسی شده است.
• Sliceهای فارسی و گروه‌های متأثر ارزیابی شده‌اند.
• افشا روشن، نزدیک، به‌موقع و دسترس‌پذیر است.
• Provenance در صورت نیاز ثبت شده و محدودیت آن فهمیده شده است.
• بازبین صلاحیت، زمان و اختیار ردکردن دارد.
• Accountable editor تصمیم انتشار را ثبت کرده است.
• URL/Asset ID، نسخه، Expiry و مسیر اصلاح مشخص است.
• Hard fail صفر و معیار پذیرش Use case پاس شده است.

جمع‌بندی؛ اعتماد از شواهد می‌آید، نه از برچسب

تولید مسئولانه محتوا با AI یعنی سازمان بتواند نشان دهد چرا این فناوری انتخاب شده، چه حقی بر ورودی و هویت افراد داشته، کدام ادعا را چگونه سنجیده، چه چیزی را به مخاطب گفته و هنگام خطا چه کسی چه اقدامی می‌کند. Disclosure، Human review و Content Credentials هرکدام لایه‌ای از کنترل‌اند؛ هیچ‌کدام به‌تنهایی مسئولیت را کامل نمی‌کنند.

از یک Use case محدود شروع کنید. معیار پذیرش و Hard fail را قبل از تولید بنویسید، شواهد را در سطح Asset نگه دارید، رخداد را تمرین کنید و فقط وقتی Scale کنید که هزینه، کیفیت، حقوق و امکان اصلاح هم‌زمان قابل دفاع باشند.

سوالات متداول

آیا باید روی همه محتواهای تولیدشده با AI برچسب بزنیم؟

نسخه یکسان برای همه موقعیت‌ها مناسب نیست. نقش مادی AI، احتمال گمراهی، نوع رسانه، بازنمایی فرد، تبلیغ، موضوع عمومی، ریسک و قانون قلمرو تعیین می‌کند چه افشایی لازم است. اصلاح املای داخلی با Voice clone واقع‌نما یکسان نیست.

آیا بازبینی انسانی مسئولیت محتوای AI را حل می‌کند؟

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

آیا خروجی AI حق کپی‌رایت دارد؟

پاسخ به حوزه قضایی، شرایط سرویس، ورودی و سهم خلاقیت انسانی وابسته است. موضع اداره کپی‌رایت آمریکا درباره نقش کافی مؤلف انسانی یک نمونه است و نباید حکم ایران یا پاسخ جهانی تلقی شود؛ برای Asset مهم بررسی حقوقی لازم است.

آیا C2PA ثابت می‌کند یک تصویر واقعی است؟

خیر. Content Credentials می‌تواند منشأ و پیوند ادعاهای امضاشده با دارایی را قابل بررسی کند، اما درباره درست‌بودن رویداد واقعی حکم نمی‌دهد. زنجیره ممکن است ناقص یا Metadata حذف‌شده باشد؛ Fact-check و افشای انسانی همچنان لازم‌اند.

اولین قدم یک تیم کوچک ایرانی چیست؟

Use caseها را فهرست و به چهار سطح ریسک تقسیم کنید؛ ورود داده محرمانه و Clone بدون رضایت را فوراً ممنوع کنید؛ برای هر خروجی عمومی Owner، منبع Claim، تصمیم افشا و مسیر اصلاح ثبت کنید؛ سپس یک Pilot محدود را با معیار خطای بحرانی و Cost per accepted asset بسنجید.