این جلسه نباید به دریافت چند پاسخ «بله» و «خیر» ختم شود. هر پاسخ مهم باید به شاهد، تعهد، روش اندازه‌گیری یا بند توافق متصل باشد. انتخاب سرویس زمانی قابل دفاع است که سازمان بداند چه مسئولیتی بر عهده ارائه‌دهنده است و چه مسئولیتی همچنان نزد خودش باقی می‌ماند.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: ابتدا دامنه سرویس را روشن کنیم، داده کجا قرار می‌گیرد و چگونه جابه‌جا می‌شود؟، جداسازی محیط ما از دیگران چگونه انجام می‌شود؟. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- ابتدا دامنه سرویس را روشن کنیم
- داده کجا قرار می‌گیرد و چگونه جابه‌جا می‌شود؟
- جداسازی محیط ما از دیگران چگونه انجام می‌شود؟
- چه کسی دسترسی مدیریتی دارد؟
ابتدا دامنه سرویس را روشن کنیم
عبارت «زیرساخت Private AI به‌صورت سرویس» می‌تواند برای دو طرف معنای متفاوتی داشته باشد. آیا سرویس فقط منابع پردازشی را تحویل می‌دهد؟ Storage، شبکه، مدیریت دسترسی، پایش و پشتیبانی تا چه سطحی در دامنه است؟ چه چیزی توسط تیم سازمان پیکربندی می‌شود و چه چیزی توسط ارائه‌دهنده؟ این مرز باید پیش از مقایسه قیمت مشخص شود.
در سناریوی ما، تیم یک صفحه دامنه می‌نویسد: منابع پایه، روش درخواست ظرفیت، محیط دسترسی، گزارش مصرف، ساعت پشتیبانی و اقلام خارج از سرویس. این صفحه اجازه می‌دهد پیشنهادها بر اساس یک نیاز مشترک بررسی شوند. اگر دامنه مبهم بماند، پیشنهاد ارزان‌تر ممکن است فقط بخش کوچک‌تری از کار را پوشش دهد.
داده کجا قرار می‌گیرد و چگونه جابه‌جا می‌شود؟
مدیر امنیت می‌پرسد داده سازمان در چه محل و بستری نگهداری می‌شود. آیا هنگام انتقال و نگهداری حفاظت می‌شود؟ چه مسیرهایی برای ورود و خروج وجود دارد و چه کسی می‌تواند آن‌ها را فعال کند؟ آیا نسخه‌های موقت یا Snapshot ساخته می‌شوند و دوره نگهداری آن‌ها چیست؟ پاسخ باید با معماری واقعی سرویس هماهنگ باشد.
مکان داده فقط یک نشانی فیزیکی نیست. سازمان باید بداند کدام نسخه اصلی است، چه کپی‌هایی برای پشتیبانی یا بازیابی وجود دارد و حذف آن‌ها چگونه تأیید می‌شود. اگر داده حساسیت‌های متفاوتی دارد، ممکن است همه مجموعه‌ها مجاز به ورود به سرویس نباشند. طبقه‌بندی داده پیش‌نیاز انتخاب مسیر است.
جداسازی محیط ما از دیگران چگونه انجام می‌شود؟
در مدل Multi-Tenant، بخشی از بستر میان چند مشتری مشترک است و محیط هر سازمان باید با کنترل‌های طراحی‌شده از دیگران تفکیک شود. پرسش مدیریتی این است که مرز در کدام لایه‌ها قرار دارد: هویت، شبکه، منابع پردازشی، Storage و مدیریت. نام مدل به‌تنهایی کیفیت جداسازی را ثابت نمی‌کند.
ارائه‌دهنده باید بتواند تصویر قابل فهمی از مرزها و روش آزمون آن‌ها ارائه کند. آیا کاربر یک سازمان می‌تواند منبع سازمان دیگر را ببیند؟ تغییر تخصیص ظرفیت چگونه کنترل می‌شود؟ خطای پیکربندی چه سازوکاری برای کشف دارد؟ راهنمای معماری Multi-Tenant مایکروسافت نیز بر ارتباط هویت، مجوز و محدوده Tenant برای جلوگیری از دسترسی ناخواسته تأکید می‌کند.[۱]
چه کسی دسترسی مدیریتی دارد؟
برخی فعالیت‌های نگهداری نیازمند دسترسی تیم ارائه‌دهنده است. سازمان باید بداند این دسترسی دائمی است یا هنگام نیاز فعال می‌شود، چه کسانی مجازند، تأیید چگونه انجام می‌شود و فعالیت‌ها کجا ثبت می‌شوند. عبارت «تیم پشتیبانی دسترسی دارد» برای یک تصمیم حساس کافی نیست.
می‌توان اصل حداقل دسترسی، تفکیک نقش و دسترسی زمان‌دار را در پرسش‌ها وارد کرد. برای رخداد اضطراری نیز مسیر جداگانه تعریف شود. گزارش دسترسی‌های مدیریتی باید قابل بازبینی باشد. اگر ارائه‌دهنده بخشی از کار را به طرف دیگری می‌سپارد، دامنه دسترسی او نیز باید روشن شود.
هویت کاربران با سازمان چگونه هماهنگ می‌شود؟
مدیر فناوری می‌خواهد بداند کاربران با چه روشی وارد می‌شوند. آیا امکان اتصال به سامانه هویت سازمان وجود دارد؟ ایجاد، تغییر و حذف کاربر چگونه انجام می‌شود؟ اگر فردی از سازمان خارج شود، دسترسی او در سرویس چه زمانی قطع می‌گردد؟ حساب محلی بدون مالک می‌تواند همان ریسک‌های زیرساخت داخلی را تکرار کند.
برای مدیران لازم نیست نام همه پروتکل‌ها مطرح شود، اما مسئولیت چرخه حساب باید مشخص باشد. سازمان منبع حقیقت کارکنان را نگه می‌دارد و ارائه‌دهنده باید روشی برای اعمال تغییرات و ارائه گزارش داشته باشد. احراز هویت قوی، سطح دسترسی متناسب و ثبت فعالیت از معیارهای پایه‌اند.
ظرفیت چگونه تخصیص و گزارش می‌شود؟
مدیر مالی از عبارت «قابل توسعه» پاسخ عملی می‌خواهد. افزایش ظرفیت چه مدت زمان می‌برد؟ حداقل و حداکثر قابل ارائه چیست؟ مصرف چگونه اندازه‌گیری می‌شود و گزارش آن با چه دوره‌ای در اختیار سازمان قرار می‌گیرد؟ اگر چند مشتری هم‌زمان اوج مصرف داشته باشند، سطح خدمت چگونه حفظ می‌شود؟
پاسخ باید میان ظرفیت رزروشده، ظرفیت قابل درخواست و ظرفیت تضمین‌شده تفاوت بگذارد. ممکن است مدل سرویس برای استفاده متغیر مناسب باشد، اما هر افزایش فوری و نامحدود نیست. سازمان باید نیاز پایه، اوج قابل پیش‌بینی و رخداد استثنایی را بیان کند تا ارائه‌دهنده روش تأمین هرکدام را توضیح دهد.
عملکرد را با چه معیاری می‌سنجیم؟
عبارت «سریع» یا «High Performance» قابل پذیرش نیست. معیار باید به کار واقعی سازمان وصل شود: زمان آماده شدن محیط، زمان دسترسی به ظرفیت، تأخیر Storage، توان جابه‌جایی داده یا تکمیل یک سناریوی نماینده. لازم نیست همه جزئیات عمومی شوند، اما روش اندازه‌گیری و مسئول تأیید باید روشن باشد.
یک دمو یا آزمون محدود می‌تواند بخشی از پاسخ را نشان دهد. داده غیرحساس و سناریوی مشخص انتخاب می‌شود و نتیجه در شرایط توافق‌شده ثبت می‌گردد. آزمون قرار نیست تمام آینده را پیش‌بینی کند؛ فرض‌های پیشنهاد را قابل مشاهده می‌سازد و پرسش‌های دقیق‌تری برای قرارداد ایجاد می‌کند.
اگر بخشی از سرویس در دسترس نبود چه می‌شود؟
مدیرعامل می‌پرسد در زمان اختلال چه کسی پاسخ می‌دهد و چه اطلاعاتی دریافت می‌کنیم. ساعت خدمت، مسیر ثبت رخداد، زمان پاسخ، اولویت‌ها و روش Escalation باید مشخص باشند. تفاوت میان زمان پاسخ و زمان رفع نیز مهم است. یک پیام سریع الزاماً به معنای بازگشت فوری سرویس نیست.
برنامه تداوم ارائه‌دهنده و مسئولیت سازمان باید با هم دیده شوند. سازمان ممکن است هنوز به اتصال شبکه، حساب داخلی یا داده‌ای وابسته باشد که خودش مدیریت می‌کند. راهنمای NIST درباره استفاده از خدمات ابری بر حفظ نظارت و مسئولیت سازمان حتی هنگام استفاده از ارائه‌دهنده تأکید دارد.[۲] واگذاری خدمت، مسئولیت تصمیم را حذف نمی‌کند.
بکاپ و بازیابی در دامنه چه جایگاهی دارند؟
وجود Storage به معنای وجود بکاپ نیست. باید پرسید از کدام داده‌ها نسخه تهیه می‌شود، دوره نگهداری چیست، نسخه‌ها در برابر حذف چگونه محافظت می‌شوند و بازیابی با چه هدف زمانی انجام می‌گردد. اگر بکاپ خارج از دامنه است، سازمان باید روش خودش را طراحی و دسترسی لازم را دریافت کند.
آزمون بازیابی باید بخشی از پذیرش باشد. یک فایل یا محیط نمونه بازگردانده شود و زمان و مسئولیت‌ها ثبت گردد. در مدل Multi-Tenant، جداسازی نسخه‌های هر سازمان و مجوز دسترسی به آن‌ها نیز اهمیت دارد. پاسخ کلی «بکاپ داریم» نباید جای سیاست و آزمون را بگیرد.
رخداد امنیتی چگونه اطلاع‌رسانی می‌شود؟
سازمان باید بداند چه رخدادی به او اطلاع داده می‌شود، در چه زمانی، از چه کانالی و با چه سطحی از اطلاعات. اگر یک فعالیت مشکوک فقط در لایه مشترک دیده شود، آیا مشتریان مرتبط خبر می‌گیرند؟ چه کسی هماهنگی بررسی و حفظ شواهد را انجام می‌دهد؟
پیش از حادثه، مخاطبان و مسیر ارتباط تعیین می‌شوند. مدیر امنیت، مدیر فناوری و نماینده کسب‌وکار ممکن است نقش‌های متفاوتی داشته باشند. گزارش اولیه می‌تواند محدود باشد و با تکمیل بررسی به‌روز شود. انتظار «همه جزئیات در لحظه» واقع‌بینانه نیست، اما سکوت و ابهام نیز قابل قبول نیست.
تغییرات و نگهداری چگونه برنامه‌ریزی می‌شوند؟
بستر سرویس برای حفظ امنیت و کارایی نیاز به تغییر دارد. ارائه‌دهنده باید روش اطلاع‌رسانی، پنجره نگهداری، تغییر اضطراری و بازگشت را توضیح دهد. سازمان نیز باید بداند کدام تغییرات داخلی‌اش نیاز به هماهنگی با سرویس دارد. نبود این ارتباط می‌تواند یک ارتقای عادی را به اختلال تبدیل کند.
گزارش تغییرات مهم و اثر احتمالی بر سازمان، تصمیم‌گیری را آسان‌تر می‌کند. برای تغییر پرریسک می‌توان آزمون، اطلاع قبلی و تأیید پس از اجرا تعریف کرد. هدف متوقف کردن به‌روزرسانی نیست؛ ایجاد تغییر کنترل‌شده و قابل پیگیری است.
هزینه در حالت معمول و اوج چگونه محاسبه می‌شود؟
مدیر مالی باید مبلغ پایه، واحد سنجش مصرف، هزینه ظرفیت اضافه، خدمات پشتیبانی و موارد خارج از قرارداد را جدا ببیند. اگر مصرف کاهش یابد، چه بخشی از هزینه تغییر می‌کند؟ اگر افزایش یابد، چه آستانه‌ای نیازمند تصمیم جدید است؟ گزارش مصرف باید امکان مقایسه با بودجه و ارزش استفاده را بدهد.
همچنین هزینه ورود داده، انتقال، نگهداری و خروج باید بررسی شود. پیشنهاد ارزان در ماه نخست ممکن است در زمان رشد یا پایان همکاری هزینه بیشتری ایجاد کند. مقایسه باید یک سناریوی مصرف معمول، اوج و توسعه را پوشش دهد و فرض هر عدد آشکار باشد.
در پایان همکاری چگونه خارج می‌شویم؟
Exit Plan از روز شروع اهمیت دارد. سازمان باید بداند داده و تنظیمات در چه قالبی تحویل می‌شوند، انتقال چه مدت طول می‌کشد، چه کمکی از ارائه‌دهنده دریافت می‌کند و پس از تأیید چه نسخه‌هایی حذف می‌شوند. اگر خروج مبهم باشد، وابستگی به سرویس در آینده به هزینه تصمیم تبدیل می‌شود.
آزمون کامل خروج در ابتدا لازم نیست، اما یک نمونه تحویل و مستندات مسیر مفید است. مسئول تأیید حذف، دوره باقی ماندن نسخه‌های پشتیبان و وضعیت حساب‌ها باید مشخص شود. امکان خروج قابل برنامه‌ریزی، اعتماد به شروع همکاری را بیشتر می‌کند.
پاسخ را به شاهد تبدیل کنیم
برای هر سؤال مهم، نوع شاهد تعیین شود: سند معماری، گزارش آزمون، نمونه گزارش مصرف، فرایند پشتیبانی، بند توافق یا دمو. همه اطلاعات فنی لازم نیست در قرارداد بیاید، اما معیارهای نتیجه و مسئولیت باید قابل رجوع باشند. فهرست بلند وعده‌ها بدون روش تأیید، در اختلاف آینده کمکی نمی‌کند.
سازمان می‌تواند یک جدول سه‌ستونه بسازد: سؤال، پاسخ ارائه‌دهنده و شاهد. موارد بدون پاسخ یا شاهد به‌عنوان ریسک باقی می‌مانند و مدیریت تصمیم می‌گیرد آن‌ها را بپذیرد، اصلاح کند یا گزینه دیگری بسنجد. این روش مقایسه چند پیشنهاد را نیز منصفانه‌تر می‌کند.
نقش راگا در جلسه ارزیابی سرویس
راگا مسیر ارائه زیرساخت Private AI را با گفت‌وگوی نیاز، حساسیت داده، ظرفیت، زمان شروع و محدودیت بودجه آغاز می‌کند. در جلسه ارزیابی، دامنه سرویس Multi-Tenant، روش جداسازی، دسترسی، گزارش مصرف، پشتیبانی و گزینه خروج بر اساس شرایط سازمان بررسی می‌شوند. اگر الزام‌ها با محیط مشترک سازگار نباشند، مسیر زیرساخت اختصاصی نیز روی میز قرار می‌گیرد.
هدف جلسه فروش یک بسته ثابت نیست. خروجی باید فهرست سؤال‌های پاسخ‌داده‌شده، اطلاعات ناقص و گام بعدی باشد. ممکن است یک دمو محدود، برآورد ظرفیت یا بررسی معماری لازم شود. این شفافیت به مدیرعامل و مدیر فناوری کمک می‌کند تصمیم را بر پایه شواهد و مسئولیت‌های روشن بگیرند.
تصمیم بعدی سازمان
مدیرعامل تصمیم نهایی را یک هفته عقب می‌اندازد تا پاسخ ده سؤال کلیدی با شاهد جمع شود. مدیر امنیت روی داده، جداسازی و رخداد تمرکز می‌کند؛ مدیر فناوری دامنه، عملکرد و تغییر را می‌سنجد؛ مدیر مالی مدل هزینه و خروج را بررسی می‌کند. ارائه‌دهنده نیز باید پاسخ‌ها را در یک جلسه مشترک توضیح دهد.
اعتماد به سرویس از نام فناوری یا جمله «کاملاً امن» ساخته نمی‌شود. اعتماد نتیجه مرز روشن، دسترسی کنترل‌شده، گزارش قابل مشاهده، تعهد قابل سنجش و امکان آزمون است. پیش از سپردن زیرساخت Private AI، سؤال‌های درست هزینه ایجاد نمی‌کنند؛ از ابهام‌هایی جلوگیری می‌کنند که بعداً بسیار پرهزینه‌تر خواهند بود.
مالکیت داده و استفاده ثانویه را شفاف کنیم
سازمان باید بداند داده ورودی، خروجی و اطلاعات عملیاتی سرویس متعلق به چه کسی است و ارائه‌دهنده برای چه هدفی مجاز به استفاده از آن‌هاست. آیا داده فقط برای ارائه خدمت پردازش می‌شود؟ آیا برای عیب‌یابی نمونه‌ای نگهداری می‌گردد؟ گزارش‌های مصرف تا چه سطحی شامل اطلاعات سازمان هستند؟ این موارد باید با طبقه‌بندی داده و توافق حقوقی هماهنگ شوند.
همچنین لازم است میان داده سازمان و Telemetry فنی تمایز گذاشته شود. ارائه‌دهنده برای اداره زیرساخت به برخی شاخص‌ها نیاز دارد، اما دامنه و دوره نگهداری آن‌ها باید روشن باشد. پاسخ دقیق درباره مالکیت و استفاده، اعتماد را بیشتر از جمله کلی «اطلاعات محرمانه می‌ماند» می‌سازد.
امکان ممیزی و بازبینی دوره‌ای
پاسخ‌های روز قرارداد باید در طول همکاری نیز قابل بررسی بمانند. سازمان می‌تواند دوره‌ای برای مرور دسترسی‌های مدیریتی، رخدادهای مهم، ظرفیت، تغییرات و وضعیت بکاپ تعیین کند. اگر معماری یا طرف‌های درگیر تغییر کردند، اثر آن بر تعهدهای قبلی توضیح داده شود. بازبینی منظم مانع می‌شود اعتماد به سرویس بر تصویری قدیمی استوار بماند.
گزارش دوره‌ای باید برای مدیر فناوری قابل فهم و برای تیم فنی قابل پیگیری باشد. موارد استثنا، اقدام اصلاحی و موعد نیز ثبت شوند. هدف افزایش کاغذبازی نیست؛ چند شاهد اصلی باید نشان دهند کنترل‌های توافق‌شده هنوز کار می‌کنند و نیاز سازمان با رشد مصرف تغییر نکرده است.
در این بازبینی، تغییر نیاز سازمان نیز باید دیده شود. ورود واحد جدید، افزایش حساسیت داده یا تغییر الگوی مصرف ممکن است کنترل و قرارداد قبلی را ناکافی کند. ارائه‌دهنده و سازمان باید مسیر اصلاح دامنه را پیش از رخداد تعریف کرده باشند.
چک‌لیست تصمیم‌گیری
- نیاز و مالک کسب‌وکاری مشخص باشد.
- نوع داده و محدودیت دسترسی ثبت شود.
- ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
- مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.
برای تصمیم‌گیری درباره Private AI
نیاز، ظرفیت، داده و مدل بهره‌برداری سازمان را پیش از خرید یا دریافت سرویس بررسی کنید.
سؤالات متداول
Private AI را از کجا شروع کنیم؟
از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.
زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟
پاسخ به حساسیت داده، زمان شروع، الگوی مصرف، توان بهره‌برداری و سطح کنترل موردنیاز بستگی دارد.
ظرفیت Private AI چگونه تعیین می‌شود؟
هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.
منابع
[۱] Microsoft Learn — ملاحظات هویت و جداسازی دسترسی در راهکارهای Multi-Tenant مشاهده منبع
[۲] NIST SP ۸۰۰-۱۴۴ — راهنمای امنیت و حریم خصوصی در خدمات ابری عمومی مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «تصمیم درباره ظرفیت پایه و اوج مصرف زیرساخت Private AI» را ببینید.