در مجموعه «هوش مصنوعی بدون اعتماد» از این فرض شروع کردیم که امن‌کردن شبکه، سرور و دسترسی برای حفاظت از یک سامانه هوش مصنوعی کافی نیست. اکنون ISO/IEC 27090 همین فاصله را در سطح استاندارد بین‌المللی به رسمیت می‌شناسد: داده، مدل، رفتار و چرخه حیات هوش مصنوعی خودشان موضوع امنیت‌اند.
در معماری سنتی امنیت، نقطه شروع معمولاً حفاظت از منابع است: چه کسی وارد شبکه می‌شود، چه کسی به داده دسترسی دارد، کدام سرویس مجاز است و چگونه می‌توان نفوذ، نشت یا تغییر غیرمجاز را تشخیص داد. معماری بدون اعتماد این نگاه را اصلاح کرد و گفت هیچ کاربر، دستگاه یا سرویس را نباید صرفاً به‌دلیل قرارگرفتن در محیط داخلی قابل اعتماد فرض کرد.
مسئله‌ای که در مجموعه هوش مصنوعی بدون اعتماد (ZTAI) مطرح شد، یک گام بعد از همین نقطه آغاز می‌شود: در هوش مصنوعی حتی اگر هویت، دسترسی و زیرساخت درست کنترل شده باشند، هنوز نمی‌توان به داده، مدل، خروجی و فرایندی که آن‌ها را تولید کرده است اعتماد پیش‌فرض داشت. مدل می‌تواند روی داده آلوده آموزش دیده باشد، خروجی ممکن است اطلاعات حساس افشا کند و یک ورودی کاملاً مجاز می‌تواند رفتاری خارج از انتظار ایجاد کند.
ISO/IEC 27090 که اکنون در مرحله نهایی انتشار قرار دارد، تقریباً همین شکاف را رسمی می‌کند. ISO آن را مکمل 27001 و 27002 می‌داند و تصریح می‌کند که تهدیدهای مخصوص هوش مصنوعی را باید در کنار امنیت متعارف فناوری اطلاعات دید؛ از داده آموزشی و مدل تا رفتار سامانه و به‌روزرسانی آن.
مسئله فقط حفاظت از سامانه نیست؛ باید به آنچه سامانه «شده» هم شک کرد
یک سرور ممکن است امن باشد یا نباشد، اما هویت آن نسبتاً روشن است. نسخه سیستم‌عامل، فایل‌های نصب‌شده و تنظیمات را می‌توان بررسی کرد و تا حد زیادی فهمید چه چیزی در حال اجراست. مدل هوش مصنوعی چنین ویژگی ساده‌ای ندارد. رفتار آن حاصل ترکیبی از داده، الگوریتم، پارامترها، Fine-tuning، Prompt، RAG، Guardrail و تعاملات محیط عملیاتی است. حتی اگر فایل مدل تغییر نکرده باشد، تغییر در یکی از این اجزا می‌تواند رفتار سامانه را عوض کند.
این همان چیزی است که در مدل بلوغ ZTAI اهمیت پیدا می‌کند. از سطحی که مدل فقط یک فایل دستی است، به مرحله‌ای می‌رسیم که داده، کد، آزمایش، مدل، ارزیابی و استقرار همگی نسخه‌گذاری و قابل ردیابی‌اند. هدف این ردیابی فقط DevOps بهتر نیست؛ بدون آن اساساً نمی‌توان اثبات کرد مدلی که امروز در تولید است همان مدلی است که دیروز ارزیابی شده بود.
ISO/IEC 27090 نیز امنیت را در طول چرخه حیات می‌بیند و به‌طور مشخص به این مسئله اشاره می‌کند که داده جمع‌شده در بهره‌برداری ممکن است بعداً وارد Retraining شود. اگر این داده دستکاری شده باشد، رخدادی که امروز در محیط عملیاتی اتفاق افتاده می‌تواند فردا به بخشی از رفتار مدل تبدیل شود.
در چنین سامانه‌ای «تغییر» دیگر فقط یک موضوع عملیاتی نیست؛ خودش یک مسئله امنیتی است.
ورودی مجاز می‌تواند حمله باشد
یکی از تفاوت‌های مهم هوش مصنوعی با نرم‌افزار سنتی این است که بخشی از حملات الزاماً از مسیر دسترسی غیرمجاز اتفاق نمی‌افتند.
فرض کنیم کاربر کاملاً احراز هویت شده، مجوز فراخوانی API دارد و درخواستش از همه کنترل‌های شبکه عبور کرده است. در معماری کلاسیک، بخش مهمی از کار امنیت درست انجام شده است. اما همان کاربر می‌تواند با مجموعه‌ای از Queryهای حساب‌شده برای استخراج مدل تلاش کند یا ورودی‌ای طراحی کند که رفتار آن را منحرف کند.
ISO/IEC 27090 به همین دسته از مخاطرات می‌پردازد؛ از Data Poisoning و Model Exfiltration تا Membership Inference، Model Inversion و Prompt Injection. نکته مشترک آن‌ها این است که امنیت در بسیاری از موارد باید رفتار تعامل را بسنجد، نه فقط مجازبودن اتصال را.
در ZTAI همین مسئله با «راستی‌آزمایی صریح و مستمر» صورت‌بندی شده بود. احراز هویت در ابتدای نشست کافی نیست؛ داده تغییر می‌کند، مدل بازآموزی می‌شود و رفتار سرویس نیز ثابت نمی‌ماند. بنابراین اعتماد باید پیوسته بازبینی شود.
این نقطه‌ای است که Zero Trust برای هوش مصنوعی از Zero Trust شبکه جدا می‌شود: سؤال دیگر فقط «چه کسی اجازه دسترسی دارد؟» نیست، بلکه «آیا این استفاده، با این داده، روی این مدل و در این لحظه هنوز با سیاست مورد انتظار سازگار است؟»
در Agentها، این تفاوت از نظری به عملی تبدیل می‌شود
تا زمانی که مدل فقط متن تولید می‌کند، بخشی از رفتار ناخواسته ممکن است در حد یک خروجی غلط باقی بماند. اما در Agentها، همان خروجی می‌تواند به عمل تبدیل شود: فراخوانی API، اجرای دستور، خواندن فایل یا تغییر یک سامانه دیگر.
در این وضعیت، مدل نه فقط یک منبع پاسخ، بلکه بخشی از زنجیره تصمیم و اجراست. بنابراین اصل کمترین دسترسی نیز باید از کاربر به خود مدل و Agent گسترش پیدا کند؛ همان چیزی که در کنترل‌های عملی ZTAI مطرح شد: هر مدل، سرویس و جزء باید فقط حداقل اختیار لازم را داشته باشد و تصمیم مدل نباید به‌تنهایی مجوز انجام عمل محسوب شود.
ISO/IEC 27090 نیز Zero Trust، Threat Modelling و Red Teaming را در کنار تهدیدهای هوش مصنوعی-specific قرار می‌دهد. این ترکیب مهم است، چون نشان می‌دهد امنیت Agent را نمی‌توان با یک «Guardrail بهتر» حل کرد. کنترل باید در معماری توزیع شود: میان داده، مدل، سیاست، ابزار و محیط مقصد.
به همین دلیل در ZTAI تأکید شد که انسان یا مدل نباید بتواند تنها با داشتن یک مجوز کلی، مسیرهای دیگر کنترل را دور بزند. حتی حذف دسترسی مستقیم انسان به داده هم کافی نیست اگر همان فرد بتواند کدی بنویسد که داده را از مسیر خروجی یا لاگ خارج کند. امنیت واقعی نیازمند تفکیک اختیار تعریف پردازش، پذیرش آن و اجازه خروج نتیجه است.
همین منطق برای Agent نیز برقرار است؛ موضوعی که در «ZTAI برای عامل‌های خودکار؛ اختیار محدود در تمام مسیر اجرا» بررسی شد.
امنیت مدل بدون منشأ و ردیابی معنا ندارد
ISO/IEC 27090 فقط درباره حمله در زمان استفاده نیست؛ منشأ مدل و داده نیز بخشی از مسئله است. اگر ندانیم مدل از کجا آمده، روی چه داده‌ای تغییر کرده، چه نسخه‌ای از آن ارزیابی شده و چه چیزی پس از ارزیابی عوض شده، مفهوم «مدل امن» بسیار ضعیف می‌شود.
این موضوع در مجموعه ZTAI به شکل دیگری مطرح شده بود: نسخه‌گذاری داده، کد، مدل، آزمایش و نتیجه ارزیابی پیش‌شرط راستی‌آزمایی است. MLOps در این نگاه صرفاً ابزار افزایش سرعت توسعه نیست؛ زیرساختی است که شواهد لازم برای اعتماد‌نکردن را تولید می‌کند.
این شاید یکی از مهم‌ترین اتصال‌های میان ZTAI و 27090 باشد. Zero Trust بدون مشاهده‌پذیری و Provenance خیلی زود به شعار تبدیل می‌شود. نمی‌توان گفت «همیشه تأیید کن» اگر سامانه قادر نیست نشان دهد چه چیزی تغییر کرده است.
27090 چه چیزی به ZTAI اضافه می‌کند؟
ZTAI یک صورت‌بندی معماری است: به داده، مدل، خروجی و مسیر اجرا اعتماد پیش‌فرض نکن و کنترل را در تمام چرخه توزیع کن. ISO/IEC 27090 چیز دیگری فراهم می‌کند: زبان مشترک امنیتی برای بخشی از همین تهدیدها.
اهمیتش در این نیست که ZTAI بدون آن ناقص بوده یا حالا باید معماری را با یک استاندارد جایگزین کرد. برعکس، استاندارد نشان می‌دهد مسئله‌ای که پیش‌تر می‌شد آن را یک برداشت سخت‌گیرانه از Zero Trust دانست، اکنون دارد در ادبیات رسمی امنیت هوش مصنوعی نیز تثبیت می‌شود.
وقتی ISO به‌طور مستقل Data Poisoning، Model Exfiltration، Prompt Injection، Model Update و چرخه حیات مدل را موضوع امنیت می‌داند، مرز قدیمی میان «امنیت IT» و «امنیت مدل» عملاً کمرنگ‌تر می‌شود. به همین دلیل، 27090 را می‌توان نه رقیب 27001 و نه جایگزین 42001 دید. 27001 نظام مدیریت امنیت اطلاعات را می‌سازد، 42001 مدیریت سازمانی هوش مصنوعی را پوشش می‌دهد و 27090 به بخشی از تهدیدهایی می‌پردازد که به خود سامانه هوش مصنوعی و چرخه حیات آن مربوط‌اند.
یک حلقه تازه در معماری «بدون اعتماد»
اگر بخواهیم این استاندارد را در امتداد مجموعه ZTAI بخوانیم، پیامش ساده است: هرجا ویژگی‌های هوش مصنوعی یک سطح حمله تازه ایجاد می‌کنند، همان ویژگی باید وارد مرز اعتماد شود.
اگر داده می‌تواند مدل را تغییر دهد، منشأ و یکپارچگی داده باید راستی‌آزمایی شود. اگر مدل می‌تواند اطلاعات را از خود افشا کند، خود مدل یک دارایی امنیتی است. اگر Agent می‌تواند عمل کند، اختیار عمل باید مستقل از تصمیم مدل کنترل شود. اگر Retraining رفتار آینده را تغییر می‌دهد، چرخه آموزش نیز بخشی از سطح امنیتی سامانه است. اگر خروجی ممکن است حامل دستور یا داده حساس باشد، خروجی نیز نباید پیش‌فرض قابل اعتماد باشد.
این دقیقاً ادامه همان ایده‌ای است که مجموعه ZTAI با آن آغاز شد: اعتماد صفر در هوش مصنوعی فقط درباره کسی نیست که پشت در ایستاده است؛ درباره خود داده، مدل، فرایند و نتیجه‌ای است که از در عبور می‌کند.
ISO/IEC 27090 هنوز در مرحله 60.00 و در آستانه انتشار نهایی است؛ بنابراین بهتر است تا انتشار رسمی، آن را «استاندارد در حال انتشار» بنامیم. اما حتی پیش از انتشار نهایی، جهت حرکت روشن است: امنیت هوش مصنوعی دارد از یک پیوست کوچک به امنیت سایبری، به یک لایه مستقل در معماری و حکمرانی سامانه‌های هوشمند تبدیل می‌شود.