تصور کنید تضاد میان یک سند سیاستی ۴۰ صفحهای و توسعهدهندهای که مستقیماً از یک نقطه اتصال (Endpoint) مدل استفاده میکند یا عاملی که بدون اجازه، زیر-عاملهای جدیدی میسازد، چقدر عمیق است. وقتی یک حسابرس میپرسد «کجا در زمان اجرا این قانون اجرا شده است؟»، یک لیست اکسل از مدلهای تأییدشده و یک دفتر ثبت ریسک (Risk Register) هیچ کارایی ندارد. برای عبور از دوران «حاکمیت تیکزنی» (Checkbox Governance)، معماران سیستم باید یک گیتوی هوش مصنوعی (AI Gateway) اجباری را بهعنوان صفحه کنترل واحد (Universal Control Plane) برای تمام فراخوانیهای مدل و اقدامات عاملها پیاده کنند. این تغییر، انطباق را از یک «مالیات بر سرعت» به یک مکانیسم اجرایی در زمان اجرا تبدیل میکند.
همانطور که در تحلیل قبلی ما درباره زیرساختهایی مثل Microsoft Azure Linux ۴.۰ برای سرورهای Bare-metal اشاره کردیم، تمرکز اکنون از سیستمعامل پایه به ارکستراسیون حاکمیت AI منتقل شده است. اکثر سازمانها به انطباق «پوشهمحور» (Binder-based) تکیه میکنند؛ یعنی اسنادی که نیت سازمان را توصیف میکنند اما جلوی دور زدن کنترلها توسط توسعهدهنده را نمیگیرند و حتی یک خط شواهد ارائه نمیدهند که نشان دهد یک کنترل واقعاً فعال شده است. طبق تحلیل معماری منتشر شده در ۳ ژوئیه ۲۰۲۶ توسط az365.ai، این شکاف میان دستورالعمل و سیستم در حال اجرا، دقیقاً جایی است که رخنههای امنیتی بعدی در آن رخ میدهند.
برای پر کردن این حفره، گیتوی اجباری باید بر روی سه سطح (Plane) اصلی قرار گیرد: هویت، داده و مدل. این ساختار سیگنالهای پراکنده را به یک نقطه واحد برای اجرا و اثبات تبدیل میکند.
مدل حاکمیتی سه سطحی
مایکروسافت ارتباط نزدیکی میان سه محصول خود ایجاد کرده است، اما گیتوی همان قطعه گمشدهای است که باعث میشود این طراحی در مواجهه با واقعیت شکست نخورد:
- هویت (Microsoft Entra): از کنترل دسترسی نقشمحور (RBAC)، دسترسی شرطی (Conditional Access) و شناسههای مدیریتشده/کاری (Managed/Workload Identities) استفاده میکند. این محکمترین اتصال در این پشته است. گیتوی هر فراخوان را پیش از دسترسی به مدل، بهعنوان یک موجودیت Entra احراز هویت میکند.
- داده (Microsoft Purview): از مدیریت وضعیت امنیت داده (DSPM) برای AI و ثبت بازرسیها (Audit Capture) استفاده میکند. Purview عمدتاً شناساییکننده (Detective) است و برای اپلیکیشنهای سفارشی، مسدودکننده (Blocking) نیست. گیتوی مسدودسازی فعال، مانند سانسور اطلاعات شناسایی شخصی (PII) را فراهم میکند و رویدادهای بازرسیای را صادر میکند که Purview بهتنهایی در مسیرهای کد سفارشی از دست میدهد.
- مدل (Azure AI Foundry): از فیلترهای داخلی ایمنی محتوا (Content Safety) و Azure Policy در استقرارها بهره میبرد. با این حال، گیتهای ارزیابی (Eval Gates) اغلب بهصورت دستی (DIY) ساخته میشوند. گیتوی لیستهای مجاز مدلها و محدودیتهای توکن (Token) — تکههای کوچکی از متن، شبیه برشهای یک کیک طولانی که مدل میخورد — را در سطحی اعمال میکند که سیاستهای داخلی Foundry پس از خروج ترافیک از مرز Azure به آن دسترسی ندارند.
حذف مدلهای سایه و گسترش عاملها
پیادهسازی این گیتوی بهعنوان یک سیاست در Azure API Management (APIM)، سه ریسک سیستمی را بهطور همزمان حل میکند. این یک قطعه معماری است که تضمین میکند هیچ فراخوانی مدل یا اقدام عاملی، صفحه کنترل را دور نزند.
اول، «مدلهای سایه» (Shadow AI) را میکشد. اگر تمام خروجیها به نقاط اتصال مدلها فقط از طریق گیتوی مجاز باشد، استفاده از یک مدل تأییدنشده دیگر یک «تخلف سیاستی» نیست که بعداً کشف شود، بلکه صرفاً یک درخواست شبکه است که متصل نمیشود. این کار باعث میشود با هوش مصنوعی سایه بهجای یک مشکل شناسایی، بهعنوان یک تصمیم مسیریابی (Routing Decision) برخورد شود.
دوم، گسترش بیرویه عاملها (Agent Sprawl) را مهار میکند. هر اقدامی توسط یک عامل باید از یک نقطه کنترلی عبور کند که میتواند آن را احراز هویت، مجازسازی و ثبت کند. این موضوع در حالی اهمیت مییابد که بسیاری از سازمانها عاملهای هوشمند خود را بدون نظارت کافی بر دادهها مستقر کردهاند و اکنون با چالشهای حاکمیتی جدی روبرو هستند. این کار مانع از آن میشود که عاملها بهطور خودکار محدودیتهای امنیتی را دور بزنند یا بیسروصدا زیر-عاملهای غیرمجاز ایجاد کنند.
سوم، شواهد بازرسی (Audit) مستمر تولید میکند. بهجای ساخت گزارشهای دستی برای بررسیهای فصلی، سیستم جریانی از تلمتری برای هر فراخوانی ارسال میکند. این موضوع باعث میشود پاسخ به درخواست حسابرس برای اثبات زمان اجرا (Runtime Proof)، بهجای یک بحران، به یک نمایش ساده تبدیل شود.
حاکمیت به مثابه کد
این صفحه کنترل یک ادعا نیست، بلکه در قالب یک سیاست (Policy) بیان میشود. برای مثال، یک سیاست ورودی گیتوی میتواند کاربر را مجبور به احراز هویت Entra کند، درخواست را به یک بکاند در لیست سفید متصل کند و توکنها را محدود نماید:
<!-- mrd_ai_gateway_inbound_policy --><policies> <inbound> <validate-jwt header-name="Authorization" require-expiration-time="true"> <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" /> <required-claims> <claim name="roles" match="any"> <value>mrd_model_invoke</value> </claim> </required-claims> </validate-jwt> <check-header name="x-mrd-model-id" failed-check-httpcode="403" failed-check-error-message="Model not on allowlist" /> <azure-openai-token-limit tokens-per-minute="20000" counter-key="@(context.Subscription.Id)" /> </inbound> </policies>
علاوه بر این، یک پشتیبان در سطح استقرار (Deployment-plane backstop) میتواند از طریق یک اثر Azure Policy اعمال شود که هر حساب Foundry یا Azure OpenAI را که روی نقطه اتصال عمومی قرار دارد، مسدود (Deny) کند:
{ "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.CognitiveServices/accounts" }, { "field": "Microsoft.CognitiveServices/accounts/publicNetworkAccess", "equals": "Enabled" } ] }, "then": { "effect": "deny" } } }
تطبیق مقررات با زمان اجرا
در حال حاضر هیچ «نقشه تطبیقی» (Crosswalk) رسمی از سوی مایکروسافت برای متصل کردن بندهای ISO 42001 یا مفاد EU AI Act با کنترلهای خاص Azure وجود ندارد. Defender for Cloud هیچ بسته مقرراتی بومی برای AI ارائه نمیدهد. معماران باید خودشان ابتکارات سفارشی بنویسند و به ادعاهای آماده (Turnkey Claims) با شک نگاه کنند. این نیاز به دقت بیشتر است، زیرا رویکردهای نظارتی مشابه در برخی قوانین هوش مصنوعی ممکن است باعث ایجاد بحرانهای اداری شوند اگر با زیرساختهای اجرایی صحیحی پشتیبانی نشوند.
نقشههای حاکمیتی باید بر اساس سطح ریسک ساختار یابند:
- ریسک بالا (ضمیمه III قانون AI اروپا): نیاز به گیتهای ارزیابی در Azure AI Foundry (مسدود کردن در صورت شکست)، لاگهای تغییرناپذیر WORM، نظارت انسانی (Human-in-the-loop)، حفظ تبار (Lineage) در Microsoft Purview و الگوهای مدل زبانی دوگانه (Dual-LLM) برای اقدامات حساس دارد.
- ریسک محدود (شفافیت): تمرکز بر شفافیت از طریق گیتهای ارزیابی در سطح هشدار، لاگهای بازرسی استاندارد، فیلترهای داخلی ایمنی محتوا و شناسههای Entra برای هر تابع است.
- ریسک حداقلی: استفاده از لاگهای پایه، مسیریابی گیتوی و دسترسیهای استاندارد RBAC مایکروسافت Entra.
تفکیک تأمینکننده و استقرارکننده
یک نکته کلیدی و ظریف، تفکیک مسئولیت بین تأمینکنندگان (Providers) و استقرارکنندگان (Deployers) است. اگر شما یک مدل را تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست میدهیم تا روی یک حوزه دقیق شود — و سرویس میدهید، تعهدات تأمینکننده را بر عهده دارید. اگر فقط مدل را در اپلیکیشن خود مصرف میکنید، تعهدات استقرارکننده را دارید. بار ارزیابی اثر (Impact Assessment) در هر مورد متفاوت است. این تفکیک باید پیش از ترسیم ماتریس RACI حل شود، زیرا طراحی کنترلها بدون دانستن اینکه چه کسی مسئول رفتار مدل است، از طرف اشتباه محافظت میکند.
رفع چهار حفره بومی Azure
با وجود استحکام پشته Azure، چهار حفره خاص همچنان باقی است که راهحلهای آمادهای ندارند:
۱. گسترش هویت عاملها: شناسههای Entra Agent ID هنوز در پیشنمایش هستند و فریمورکهای شخص ثالث مثل LangChain یا CrewAI را پوشش نمیدهند. این عاملها فاقد شناسههای سطح اول هستند و زنجیرههای اعتماد عامل-به-عامل را غیرقابل بازرسی میکنند. راهکار این است که به هر تابع عامل، یک شناسه مدیریتشده با کمترین دسترسی (Least-privilege) داده شود و یک آرتیفکت سختافزاری برای ثبت عاملها (Agent Registry) نگهداری شود.
۲. مدلهای سایه: این یک نقص ابزاری نیست، بلکه شکست در انضباط معماری است. اجباری کردن خروجی (Egress) از طریق گیتوی، این مشکل را در لایه شبکه بهطور کلی حذف میکند.
۳. تزریق پرامپت (Prompt Injection) بهعنوان شکست حاکمیتی: در حالی که Prompt Shields وجود دارند، آنها متمرکز بر امنیت هستند. سؤال حاکمیتی این است: وقتی یک تزریق باعث رخنه میشود، چه کسی پاسخگو است؟ راهکار این است که اقدامات با پیامد بالا را خارج از حلقه خود-مجازسازی LLM نگه دارید و از یک «الگوی قرنطینه» استفاده کنید، جایی که مدل خواننده محتوای غیرقابل اعتماد نمیتواند بدون عبور از یک گیت انسانی یا قطعی (Deterministic)، اقدامات دارای امتیاز اجرا کند. این رویکرد برای کاهش نرخ شکست بالای مدلهای آزمایشی عامل که اغلب به دلیل عدم کنترل در لایههای عملیاتی است، حیاتی است.
۴. گسست زنجیره RAG: در تولید بازیابیافزا (RAG) — مثل دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — زنجیره تبار در Purview وقتی دادهها از یک مخزن بردار (Vector Store) عبور میکنند یا از مرزهای Tenant رد میشوند، تخریب میشود. تباری که در مخزن بردار متوقف شود، در بازرسی شکست میخورد. برای حل این موضوع، برچسبهای حساسیت باید تا لایه بردار معنایی (Embedding) حفظ شوند و پاکسازی امنیتی (Security Trimming) در زمان بازیابی اعمال گردد.
استقرار در سه مرحله
برای جلوگیری از شورش سازمانی، حاکمیت باید تدریجی باشد و نه یکباره (Ramped, not flipped). مراحل توصیه شده عبارتند از:
۱. کشف (حالت Audit): استقرار ابتکارات Azure Policy و مسیریابی گیتوی در حالت نظارتی. استفاده از Purview DSPM برای AI برای شناسایی مدلهای سایه موجود، عاملهای بدون کنترل و گسستهای زنجیره تبار. این مرحله فهرست موجودی را میسازد و اعتبار لازم برای اعمال اجباری را ایجاد میکند.
۲. گیتهای اجباری (Deny + CI/CD): تبدیل Azure Policy به حالت «مسدودکننده» (Deny) و سختگیرانهتر کردن دسترسی شرطی Entra روی نقاط اتصال Foundry. ادغام گیتهای ارزیابی Azure AI Foundry در چرخه CI/CD تا مدلهای غیرمنطبق در مرحله Pull Request (PR) شکست بخورند. قرار دادن دسترسیهای ممتاز پشت Entra PIM.
۳. شواهد مستمر (لاگهای تغییرناپذیر): فعالسازی لاگهای تغییرناپذیر WORM (Write Once, Read Many) و دفاترچه انطباق خودکار (Compliance Workbooks) ساخته شده از وضعیت Azure Policy و تلمتری گیتوی. جایگزینی تأییدیههای مقطعی (Point-in-time) با گواهیهای مستمر (Continuous Attestation).
ماتریس مسئولیت (RACI) و پاسخگویی
برای جلوگیری از تلهای که در آن «همه مسئولند، پس هیچکس نیست»، یک RACI دقیق لازم است. فعالیتها به بندهای مقررات متصل میشوند:
- طبقهبندی سطح ریسک: انطباق (A/R)، معمار (C)، MLOps (I) $\rightarrow$ EU AI Act Art. 6, Annex III
- طراحی کنترل و سیاست: معمار (A/R)، انطباق (C)، MLOps (C) $\rightarrow$ ISO 42001 Annex A
- استقرار و گیتهای ارزیابی: MLOps (A/R)، معمار (C)، انطباق (C) $\rightarrow$ EU AI Act Arts. 9-15
- نظارت زمان اجرا و رانش (Drift): MLOps (A/R)، معمار (I)، انطباق (C) $\rightarrow$ ISO 42001 Cl. 9.1
- ارزیابیهای اثر: انطباق (A/R)، معمار (C)، MLOps (I) $\rightarrow$ ISO 42001 Cl. 6.1 / Act Art. 9
- تجمیع شواهد: انطباق (A/R)، معمار (I)، MLOps (C) $\rightarrow$ ISO 42001 Cl. 9.3
حفظ سرعت مهندسی
حاکمیت نباید به معنای قرار دادن یک شورای بررسی بین توسعهدهنده و انتشار محصول باشد. چهار تمرین برای حفظ سرعت پیشنهاد میشود:
- انتقال سیاست به کد (Shift-left): تخلفات باید در لحظه PR در حلقه بازخورد توسعهدهنده شناسایی شوند، نه هفتهها بعد در یک جلسه. هرچه گیت زودتر باشد، هزینه اصلاح کمتر است.
- لایهبندی گیتها: بررسی انسانی گران است. آن را فقط برای سیستمهای با ریسک بالا به کار ببرید؛ استقرارهای با ریسک حداقلی باید از بررسیهای خودکار عبور کنند.
- กระจیده کردن مالکیت (Federated Ownership): یک تیم پلتفرم مرکزی نردهها (Guardrails) را میسازد و تیمهای دامین (Domain teams) هوش مصنوعی خود را مالک هستند. این کار مانع از آن میشود که تیم مرکزی به یک میز کمک (Help Desk) تبدیل شود.
- گواهی مستمر: جایگزینی فرمهای امضا شده با شواهد زنده از گیتوی. یک تأییدیه در زمان استقرار، هیچ اطلاعاتی درباره سیستمی که امروز در حال اجراست به شما نمیدهد.
در نهایت، تغییر به یک گیتوی هوش مصنوعی اجباری به این معناست که سؤال حسابرس درباره زمان اجرا، دیگر یک تهدید نیست و به یک نمایش تبدیل میشود. با تبدیل انطباق به «مسیر با کمترین مقاومت»، سازمانها میتوانند بدون قربانی کردن امنیت، مقیاس AI را بالا ببرند. توجه داشته باشید که قابلیتهایی مثل Entra Agent ID و ثبت ردپا در Purview-Foundry در اوایل ۲۰۲۵ در وضعیت Preview بودند؛ پیش از نهایی کردن معماری، وضعیت فعلی را با مستندات مایکروسافت بررسی کنید.
گام بعدی شما
- بررسی تنظیمات Azure API Management برای پیادهسازی لایه گیتوی.
- تعریف سیاستهای Deny در Azure Policy برای جلوگیری از ایجاد نقاط اتصال عمومی در OpenAI.
- بررسی مستندات Microsoft Purview برای حفظ برچسبهای حساسیت در لایههای بازیابی داده.
اما تأمین زیرساخت سختافزاری برای این حجم از کنترلها چالش دیگری است — به تحلیل ما درباره تراشههای Blackwell برای بهینهسازی استنتاج مراجعه کنید.
گفتگو