ماده 50 AI Act از 2 اوت 2026؛ چه چیزی باید برچسب AI بخورد؟

از 2 اوت 2026 الزامات شفافیت ماده 50 AI Act وارد مرحله اجرا می شوند. در این راهنما دقیقاً می بینیم چه محصول هایی درگیرند، کجا disclosure یا نشانه گذاری لازم است، مهلت 2 دسامبر چه دامنه ای دارد و تیم فنی باید چه چیزی را در معماری محصول تغییر دهد.

از 2 اوت 2026 دقیقاً چه چیزی شروع می شود؟

از 2 اوت 2026 بخش مهمی از الزامات شفافیت ماده 50 قانون هوش مصنوعی اتحادیه اروپا وارد مرحله اجرا می شود. این تاریخ را نباید با «اجرای همه مقررات AI Act» یکی دانست. ماده 50 روی موقعیت هایی تمرکز دارد که کاربر باید بفهمد با یک سامانه هوش مصنوعی در تعامل است یا محتوایی که می بیند، می شنود یا می خواند به طور مصنوعی تولید یا دست کاری شده است. بنابراین اثر عملی آن فقط حقوقی نیست؛ طراحی رابط کاربری، معماری تولید محتوا، متادیتا، مسیر انتشار و حتی قرارداد میان ارائه دهنده مدل و محصولی که مدل را مصرف می کند می تواند تحت تأثیر قرار بگیرد.

کمیسیون اروپا در 20 ژوئیه 2026 راهنمای اجرایی ماده 50 را منتشر کرد تا مرز مسئولیت «provider» و «deployer» روشن تر شود. برای تیم فنی، مهم ترین ترجمه این دو نقش این است: یک شرکت ممکن است در یک محصول ارائه دهنده سامانه باشد و در محصول دیگری صرفاً استفاده کننده سازمانی آن. پس اولین کار قبل از اضافه کردن هر برچسبی این است که زنجیره محصول را رسم کنید: چه کسی مدل یا سامانه را عرضه می کند، چه کسی آن را در تجربه نهایی قرار می دهد، چه نوع خروجی ساخته می شود و مخاطب در کدام نقطه با AI مواجه می شود.

چهار سناریویی که باید بررسی شوند

این جدول یک نقشه شروع است، نه جایگزین متن قانون یا راهنمای کمیسیون. تفاوت provider و deployer اهمیت زیادی دارد، چون یک تیم SaaS ممکن است یک مدل عمومی را از شرکت دیگری دریافت کند اما خودش تجربه چت بات را برای مشتری نهایی طراحی کند. در چنین حالتی مسئولیت های رابط و اطلاع رسانی را نمی توان صرفاً به سازنده مدل واگذار کرد. برعکس، اگر شما API یک سامانه را به توسعه دهندگان دیگر می فروشید، باید فکر کنید آیا اطلاعات و سازوکار لازم برای رعایت شفافیت در لایه پایین دستی در اختیار مصرف کننده قرار گرفته است یا نه.

«ماشین خوان» یعنی فقط یک واترمارک روی تصویر کافی نیست

یکی از بخش هایی که برای تیم های فنی بیشترین ابهام ایجاد می کند، الزام مربوط به قابل تشخیص بودن محتوای تولید یا دست کاری شده با AI است. راهنمای رسمی روی نشانه گذاری قابل تشخیص و قابل اتکا تأکید می کند. نتیجه معماری این است که برچسب بصری را نباید تنها منبع حقیقت در نظر گرفت. برچسبی که فقط داخل پیکسل های تصویر نوشته شده، ممکن است با crop، resize یا تبدیل فرمت از بین برود. از طرف دیگر متادیتایی که فقط داخل یک فایل اصلی وجود دارد، ممکن است در زنجیره انتشار شبکه اجتماعی حذف شود. طراحی درست باید مسیر ایجاد، ذخیره، تبدیل و انتشار محتوا را یک زنجیره واحد ببیند.

برای محصول واقعی، بهتر است provenance را از لحظه ایجاد خروجی ثبت کنید: شناسه job، نوع مدل یا سامانه، زمان تولید، نوع عملیات مانند تولید کامل یا ویرایش، و وضعیت برچسب گذاری. این داده لازم نیست همگی به کاربر نمایش داده شود، اما برای audit و ایجاد نشانه های سازگار در مراحل بعدی مفید است. اگر محصول شما خروجی را ابتدا به object storage می فرستد، سپس CDN آن را optimize می کند و در نهایت به شبکه های دیگر تحویل می دهد، باید با تست واقعی بررسی کنید کدام نشانه ها در تمام این تبدیل ها باقی می مانند.

برای چت بات و دستیار AI چه باید کرد؟

در چت بات، مسئله معمولاً ساده تر از رسانه تولیدشده است: کاربر باید در زمان مناسب بفهمد طرف مقابل یک سامانه هوش مصنوعی است. این اطلاع رسانی باید بخشی طبیعی از تجربه باشد، نه متنی که در صفحه شرایط استفاده دفن شده است. اگر نام، آواتار، لحن و رفتار محصول می تواند کاربر را به این برداشت برساند که با انسان صحبت می کند، شفافیت باید واضح تر شود. برای تیم UX این یعنی وضعیت AI باید در نقطه ای دیده شود که کاربر واقعاً تصمیم به تعامل می گیرد.

از نظر محصول، لازم است تمام نقاط ورود را بررسی کنید: ویجت وب، اپ موبایل، کانال پشتیبانی، پیام رسان، API صوتی و حتی پاسخ های خودکار در سیستم تیکت. یک برچسب در صفحه اصلی برای همه این مسیرها کافی نیست. همچنین اگر سامانه در میانه گفت وگو بین انسان و AI handoff انجام می دهد، وضعیت باید به شکلی طراحی شود که تغییر نقش برای کاربر قابل فهم باشد. هدف مقررات این نیست که رابط را با هشدار پر کنید؛ هدف جلوگیری از ابهام درباره ماهیت تعامل است.

دیپ فیک و محتوای منافع عمومی؛ تیم انتشار هم درگیر است

در محتوای تصویری، صوتی و ویدیویی که مصداق دیپ فیک باشد، نقش deployer پررنگ می شود. یعنی حتی اگر محتوای اولیه با سرویس شخص ثالث ساخته شده باشد، سازمانی که آن را در یک کمپین، رسانه یا محصول منتشر می کند باید فرایند افشا را در workflow انتشار داشته باشد. همین منطق برای متن تولید یا دست کاری شده با AI که با هدف اطلاع رسانی درباره موضوعات منافع عمومی منتشر می شود مطرح است؛ به ویژه وقتی بررسی انسانی یا کنترل تحریری وجود ندارد. بنابراین compliance فقط مسئله تیم ML نیست و CMS، پنل انتشار، approval و لاگ تغییرات هم وارد ماجرا می شوند.

راه عملی این است که فیلد provenance را به مدل محتوای CMS اضافه کنید و آن را از فیلد «نویسنده» جدا نگه دارید. نویسنده ممکن است انسان باشد اما بخشی از محتوا با AI تولید شده باشد؛ برعکس ممکن است AI صرفاً پیشنهاد اولیه داده و نسخه نهایی تحت بررسی واقعی تحریری قرار گرفته باشد. یک Boolean ساده مثل isAiGenerated معمولاً برای چنین تفاوت هایی ناکافی است. بهتر است حداقل نوع استفاده، وضعیت بازبینی و نوع افشای اعمال شده را جدا ثبت کنید تا تصمیم انتشار قابل توضیح باشد.

مهلت گذار تا 2 دسامبر دقیقاً برای چیست؟

این جزئیات برای برنامه ریزی پروژه حیاتی است. بعضی تیم ها ممکن است با دیدن عبارت «grace period» نتیجه بگیرند که تا دسامبر هیچ اقدامی لازم نیست؛ چنین برداشتی خطرناک است. FAQ کمیسیون دامنه مهلت را محدود کرده و همچنین می گوید محتوایی که پیش از 2 اوت 2026 تولید شده الزام به برچسب گذاری retroactive ندارد، هرچند انجام داوطلبانه آن تشویق می شود. پس inventory شما باید هم تاریخ عرضه سامانه و هم تاریخ تولید محتوا را در نظر بگیرد.

اگر محصول قبل از تاریخ مرزی عرضه شده، از این مهلت برای تعویق تحلیل استفاده نکنید؛ آن را برای پیاده سازی صحیح provenance، تست سازگاری فرمت ها و rollout کنترل شده مصرف کنید. اگر محصول جدید بعد از 2 اوت عرضه می شود، فرض محافظه کارانه این است که الزامات مرتبط باید از همان ابتدا در طراحی باشد. اینجا تفاوت میان «feature flag موقت» و «معماری دائمی» مهم می شود: شفافیت اگر در لایه داده و pipeline وجود نداشته باشد، اضافه کردن یک badge در UI مشکل را کامل حل نمی کند.

ریسک فقط UX نیست؛ جریمه و قابلیت اثبات هم مطرح است

صفحه Quick Facts کمیسیون می گوید جریمه نقض برخی الزامات می تواند تا 15 میلیون یورو یا تا 3 درصد گردش مالی سالانه جهانی شرکت برسد و برای SMEها اصل تناسب در نظر گرفته می شود. این عدد نباید به تیتر ترساندن تیم تبدیل شود؛ پیام مهم تر این است که compliance باید قابل اثبات باشد. اگر سازمان نتواند نشان دهد چه سیاستی داشته، چه نسخه ای از محصول فعال بوده و چه کنترل هایی در زمان انتشار اعمال شده، دفاع از فرایند بسیار سخت تر می شود.

برای مهندسی، قابلیت اثبات یعنی versioned configuration، audit log و تست regression. مثلاً اگر برچسب ماشین خوان توسط سرویس media processing اضافه می شود، باید تستی داشته باشید که حذف شدن تصادفی آن بعد از تغییر encoder را تشخیص دهد. اگر disclosure چت بات در فرانت اند است، تست E2E باید نقاط ورود اصلی را پوشش دهد. اگر CMS درباره محتوای عمومی تصمیم می گیرد، rule یا workflow مربوط به review باید قابل ردیابی باشد. چنین کنترل هایی هم برای compliance و هم برای کیفیت محصول ارزش دارند.

چک لیست اجرایی برای تیم محصول و توسعه

1. محصول ها و featureهای AI را فهرست کنید و برای هرکدام provider، deployer و کاربر نهایی را مشخص کنید.
2. چهار سناریوی ماده 50 را روی هر feature بررسی کنید: تعامل AI، محتوای مصنوعی، emotion/biometric و deepfake یا public-interest text.
3. برای خروجی های مولد، provenance را در لایه داده ثبت کنید و فقط به badge رابط متکی نباشید.
4. مسیر تبدیل فایل، CDN، export و شبکه های اجتماعی را تست کنید تا نشانه گذاری در پردازش های واقعی از بین نرود.
5. برای چت بات ها disclosure را در تمام entry pointها و handoffهای انسان/AI بررسی کنید.
6. برای CMS وضعیت استفاده از AI، review انسانی و نوع disclosure را از هم جدا مدل کنید.
7. کنترل ها را با feature flag، audit log و تست E2E قابل بازبینی کنید.
8. موارد مرزی و استثناها را با تیم حقوقی و متن رسمی راهنما تطبیق دهید؛ مقاله فنی جای مشاوره حقوقی نیست.

اشتباهات رایج در پیاده سازی شفافیت AI

اولین اشتباه، تبدیل مسئله به یک checkbox است: «برچسب AI اضافه شد، تمام». در عمل، یک سامانه می تواند چند نوع خروجی و چند مسیر توزیع داشته باشد. دومین اشتباه، یکی دانستن همه استفاده های AI است. پیشنهاد املایی، خلاصه سازی داخلی، چت بات مشتری و تولید ویدیو از نظر exposure و تعهد یکسان نیستند. سومین اشتباه، اعتماد کامل به vendor است؛ حتی اگر مدل یا API پایین دستی metadata بدهد، محصول شما باید مطمئن شود آن metadata در مسیر نهایی حفظ و به شکل مناسب مصرف می شود.

چهارمین اشتباه، نادیده گرفتن محتوای قدیمی و assetهای cacheشده است. هرچند محتوای قبل از 2 اوت الزام retroactive ندارد، باید بتوانید آن را از محتوای جدید تشخیص دهید تا ruleهای جدید تصادفی روی مجموعه ای نامشخص اعمال نشوند. پنجمین اشتباه، درهم کردن review انسانی با یک کلیک صوری است. اگر محصول به استثنا یا وضعیت خاصی مبتنی بر کنترل تحریری متکی است، فرایند review باید واقعی، تعریف شده و قابل ممیزی باشد.

جدول تصمیم سریع برای تیم فنی

پرسش های متداول

ماده 50 AI Act از چه تاریخی اجرا می شود؟

الزامات شفافیت ماده 50 از 2 اوت 2026 اعمال می شوند.

آیا همه محتوای قدیمی AI باید دوباره برچسب بخورد؟

خیر. FAQ کمیسیون می گوید محتوای تولیدشده پیش از 2 اوت 2026 الزام retroactive ندارد، هرچند برچسب گذاری داوطلبانه تشویق می شود.

مهلت 2 دسامبر 2026 برای همه محصولات AI است؟

خیر. این مهلت محدود به marking و detection ماده 50(2) برای سامانه هایی است که پیش از 2 اوت 2026 وارد بازار شده اند.

آیا فقط سازنده مدل مسئول است؟

نه لزوماً. بسته به نقش محصول، provider و deployer می توانند مسئولیت های متفاوتی داشته باشند.

آیا گذاشتن عبارت «ساخته شده با AI» کافی است؟

برای بعضی سناریوها disclosure بصری بخشی از راه حل است، اما الزام های مربوط به محتوای تولید یا دست کاری شده می تواند نیازمند نشانه های ماشین خوان و طراحی provenance نیز باشد.

جریمه نقض این قواعد چقدر است؟

طبق Quick Facts کمیسیون، جریمه می تواند تا 15 میلیون یورو یا 3 درصد گردش مالی سالانه جهانی برسد و برای SMEها تناسب لحاظ می شود.

منابع رسمی و جمع بندی

برای جزئیات حقوقی و استثناها باید به راهنمای رسمی کمیسیون اروپا درباره الزامات شفافیت، صفحه Quick Facts ماده 50 و پرسش های متداول رسمی ماده 50 مراجعه شود. این مقاله از زاویه مهندسی محصول نوشته شده و جایگزین بررسی حقوقی موردی نیست.

جمع بندی فنی ساده است: از 2 اوت، شفافیت AI باید از یک متن حقوقی جداگانه به ویژگی قابل تست محصول تبدیل شود. بهترین تیم ها صرفاً badge اضافه نمی کنند؛ provenance، نقش ها، مسیر انتشار، review و audit را یکجا طراحی می کنند. اگر همین امروز فقط یک اقدام انجام می دهید، inventory واقعی تمام featureهای AI و مسیر خروجی آن ها را بسازید. بدون آن، حتی تشخیص این که کدام بخش محصول مشمول کدام الزام است دشوار خواهد بود.