این مقاله یک برگه آماده‌سازی مدیریتی می‌سازد. اگر پاسخ بعضی سؤال‌ها هنوز معلوم نیست، همان «نامشخص» نیز داده مهمی است. جلسه خوب قرار نیست همه تصمیم‌ها را قطعی کند؛ باید ابهام‌های اصلی، مسیر بررسی و گام بعد را روشن سازد.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: یک نماینده تصمیم‌گیر و یک نماینده فنی همراه باشند، هدف کسب‌وکار را در یک جمله بنویسیم، مالک هر کاربرد را معرفی کنیم. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- یک نماینده تصمیم‌گیر و یک نماینده فنی همراه باشند
- هدف کسب‌وکار را در یک جمله بنویسیم
- مالک هر کاربرد را معرفی کنیم
- تعداد تیم‌ها و کاربران را برآورد کنیم
یک نماینده تصمیم‌گیر و یک نماینده فنی همراه باشند
مدیرعامل یا مدیر ارشد می‌تواند هدف، بودجه و فوریت را توضیح دهد. مدیر فناوری یا نماینده زیرساخت محدودیت‌های شبکه، دیتاسنتر و عملیات را می‌شناسد. حضور هر دو نگاه از تبدیل جلسه به بحث صرفاً تجاری یا فنی جلوگیری می‌کند.
اگر واحد امنیت یا مالک کاربرد نقش تعیین‌کننده دارد، سؤال‌های آن‌ها پیش از جلسه جمع‌آوری شود. لازم نیست گروه بزرگی حاضر باشد. افراد کمتر با اختیار و اطلاعات روشن، معمولاً به نتیجه سریع‌تری می‌رسند.
هدف کسب‌وکار را در یک جمله بنویسیم
عبارت «می‌خواهیم AI داشته باشیم» برای طراحی زیرساخت کافی نیست. هدف می‌تواند کاهش زمان جست‌وجوی دانش داخلی، کمک به تحلیل اسناد، پردازش تصویر یا ایجاد محیط آزمایش کنترل‌شده باشد. جمله باید بگوید کدام واحد چه نتیجه‌ای می‌خواهد و موفقیت چگونه دیده می‌شود.
نیازی به ورود به انتخاب مدل یا توسعه نرم‌افزار در این جلسه نیست. راگا بر زیرساخت تمرکز دارد. اما نوع کاربرد به تخمین ظرفیت، Storage، امنیت و سطح خدمت کمک می‌کند. دو کاربرد اولیه از فهرست بلند آینده ارزشمندترند.
مالک هر کاربرد را معرفی کنیم
پروژه بدون مالک کسب‌وکاری ممکن است پس از دریافت زیرساخت متوقف شود. فرد یا واحدی باید اولویت، کاربر، داده و معیار موفقیت را تأیید کند. مالک کاربرد با مالک زیرساخت یکسان نیست؛ یکی نتیجه کسب‌وکار و دیگری پایداری محیط را دنبال می‌کند.
در جلسه نام نقش کافی است و لازم نیست اطلاعات شخصی گسترده ثبت شود. مشخص‌بودن مالک کمک می‌کند سؤال‌های بعدی درباره زمان، بودجه و داده پاسخ معتبرتری داشته باشند.
تعداد تیم‌ها و کاربران را برآورد کنیم
برآورد می‌تواند بازه باشد: یک تیم پنج تا ده نفره در فاز اول و دو واحد دیگر در فصل بعد. تعداد حساب با هم‌زمانی مصرف یکسان نیست. چند کاربر سبک ممکن است کمتر از یک Job سنگین منابع بخواهند. بنابراین ساعت و الگوی کار نیز یادداشت شود.
اگر واحدها هنوز قطعی نیستند، سناریوی حداقل و رشد ارائه شود. این اطلاعات به مقایسه سهمیه Multi Tenant با ظرفیت اختصاصی کمک می‌کند. عدد دقیق ظاهری بر پایه حدس، تصمیم را بهتر نمی‌کند.
الگوی مصرف روزانه و اوج را توضیح دهیم
کاربرد ممکن است تعاملی و در ساعات اداری باشد یا پردازش دسته‌ای شبانه انجام دهد. برخی پروژه‌ها در پایان ماه اوج دارند. مدت هر کار، تکرار و امکان زمان‌بندی بر ظرفیت اثر می‌گذارند. یک تقویم ساده از دوره‌های اوج مفید است.
اگر تجربه قبلی وجود دارد، گزارش مصرف محیط آزمایشی همراه آورده شود. اگر نه، نیاز به پایلوت به‌عنوان خروجی جلسه ثبت می‌شود. راگا می‌تواند Baseline را در یک آزمون نماینده بسازد.
حجم و مسیر داده را در سطح غیرمحرمانه بگوییم
نوع داده می‌تواند متن، تصویر، ویدئو یا داده ساختاریافته باشد. حجم اولیه، رشد ماهانه و محل فعلی آن برای طراحی Storage و Network لازم‌اند. نیازی به ارسال خود داده نیست. طبقه حساسیت و محدودیت خروج، اطلاعات کافی برای گفت‌وگوی اولیه‌اند.
مسیر ورود و خروج نیز مهم است. آیا داده از دیتاسنتر داخلی منتقل می‌شود، به‌صورت دوره‌ای به‌روزرسانی می‌گردد یا در همان محیط تولید می‌شود؟ پاسخ بر پهنای باند، زمان شروع و روش اتصال اثر دارد.
حساسیت داده را با برچسب کلی مشخص کنیم
عمومی، داخلی، محرمانه و بسیار حساس می‌توانند سطح‌های اولیه باشند. اگر سازمان طبقه‌بندی خود را دارد، همان واژه‌ها استفاده شوند. تیم امنیت می‌تواند بگوید چه داده‌ای نباید از مرز مشخص خارج شود و چه نوع ثبت یا رمزنگاری لازم است.
فرم عمومی رویداد جای ثبت نام مشتری، نمونه سند یا جزئیات معماری امنیتی نیست. اطلاعات دقیق‌تر فقط در جلسه کنترل‌شده و بر اساس نیاز مبادله می‌شوند. اصل کمینه‌سازی داده از همین مرحله آغاز می‌شود.
زمان شروع و ضرب‌الاجل واقعی را بنویسیم
«هرچه زودتر» تاریخ نیست. آیا پروژه باید برای فصل بعد آماده باشد، به بودجه امسال وابسته است یا رویداد داخلی مشخصی دارد؟ تاریخ هدف به برنامه پایلوت، تأمین، اتصال و آموزش جهت می‌دهد. تفاوت میان شروع آزمایش و بهره‌برداری سازمانی نیز باید روشن باشد.
اگر تاریخ قطعی نیست، بازه و عامل تصمیم نوشته شود. مثلاً شروع پس از تأیید امنیت یا بودجه. این شرط‌ها به راگا کمک می‌کنند برنامه مرحله‌ای ارائه دهد.
بودجه را به‌صورت بازه و مدل هزینه بیان کنیم
لازم نیست عدد محرمانه در فرم عمومی ثبت شود. سازمان می‌تواند بگوید بودجه فاز آزمایشی محدود است، سرمایه‌گذاری اختصاصی در صورت اثبات ارزش بررسی می‌شود یا هزینه باید مصرفی باشد. بازه تقریبی در جلسه خصوصی، پیشنهادهای غیرواقعی را حذف می‌کند.
همچنین ترجیح Capex یا Opex، دوره تصمیم و فرایند تصویب اهمیت دارند. مدل Multi Tenant معمولاً برای شروع مرحله‌ای مناسب‌تر است؛ زیرساخت اختصاصی سرمایه و مسئولیت بیشتری می‌خواهد. مقایسه باید هزینه کل و زمان را ببیند.
محدودیت دیتاسنتر را از قبل بررسی کنیم
اگر مسیر اختصاصی مدنظر است، فضای Rack، برق، خنک‌سازی، شبکه و زمان آماده‌سازی سایت باید در حد اولیه شناخته شوند. لازم نیست Survey کامل قبل از رویداد انجام شود، اما وجود محدودیت جدی باید گفته شود. ممکن است همین عامل مدل سرویس را در فاز اول منطقی‌تر کند.
اگر سازمان دیتاسنتر دوم یا سیاست محل داده دارد، آن نیز ذکر شود. تیم راگا سپس می‌تواند سؤال‌های دقیق‌تر برای Assessment بعدی آماده کند.
اتصال شبکه و هویت را توصیف کنیم
کاربران از کجا وارد می‌شوند؟ آیا اتصال اختصاصی لازم است؟ آیا سازمان می‌خواهد هویت داخلی و MFA خود را استفاده کند؟ پاسخ اولیه به این پرسش‌ها دامنه Integration و زمان اجرا را نشان می‌دهد.
آدرس‌ها، Ruleهای دقیق فایروال و Credentialها نباید در جلسه عمومی مبادله شوند. کافی است نوع اتصال، محدودیت خروج و تیم مسئول مشخص باشد. جزئیات در کارگاه فنی امن بررسی می‌شوند.
سطح خدمت مورد انتظار را واقع‌بینانه بیان کنیم
محیط پایلوت و سرویس حیاتی نیاز یکسانی ندارند. سازمان باید بگوید توقف چه اثری دارد، چه ساعت‌هایی مهم‌اند و چه زمان پاسخی انتظار می‌رود. سطح بالاتر می‌تواند ظرفیت رزرو و هزینه بیشتری بخواهد. این انتخاب مدیریتی است.
اگر کاربرد هنوز آزمایشی است، توافق سبک‌تر می‌تواند شروع را سریع کند. با ورود به تولید، SLA بازبینی می‌شود. مسیر بلوغ باید از ابتدا در نظر گرفته شود.
Backup و نگهداری داده را فراموش نکنیم
کدام داده قابل بازسازی و کدام نتیجه حیاتی است؟ چه مقدار تاریخچه باید بماند؟ پاسخ در سطح کاربرد کافی است. راگا سپس می‌تواند دامنه Backup، Object Storage، Immutability و زمان بازیابی را بررسی کند.
اگر سازمان سیاست نگهداری مصوب دارد، خلاصه آن همراه باشد. در غیر این صورت، نیاز به تدوین سیاست به‌عنوان اقدام بعدی ثبت می‌شود. حفظ همه داده‌ها بدون دوره مشخص هم هزینه و هم ریسک ایجاد می‌کند.
مسئول عملیات در هر مدل را مشخص کنیم
در زیرساخت اختصاصی، سازمان باید درباره Patch، Capacity، Monitoring، Backup و رخداد تصمیم بگیرد. ممکن است بخشی را به راگا بسپارد. در مدل Multi Tenant، ارائه‌دهنده مسئول لایه‌های توافق‌شده است و سازمان هویت کاربران و مصرف داخلی را اداره می‌کند.
جلسه باید بگوید تیم داخلی چه مهارت و زمانی دارد. اگر منابع محدودند، مدل خدمت وزن بیشتری می‌گیرد. اگر کنترل کامل و تیم آماده وجود دارد، اختصاصی می‌تواند مناسب باشد.
معیار موفقیت پایلوت را همراه بیاوریم
پایلوت باید یک سؤال تصمیم را پاسخ دهد. آیا ظرفیت برای بار نماینده کافی است، انتقال داده در زمان مجاز انجام می‌شود، کاربران می‌توانند مستقل کار کنند یا سطح امنیت تأیید می‌شود؟ دو تا پنج معیار قابل اندازه‌گیری انتخاب شوند.
نمایش یک نمونه بدون معیار ممکن است جذاب باشد اما تصمیم را جلو نبرد. مالک کاربرد و فناوری نتیجه را با هم تأیید می‌کنند. زمان پایلوت، دامنه و خروجی نیز مشخص می‌شود.
سؤال‌های مربوط به Multi Tenant را آماده کنیم
سازمان می‌تواند درباره جداسازی محیط، نقش‌ها، ظرفیت رزرو، اثر Noisy Neighbor، گزارش مصرف، Backup، SLA و خروج سؤال کند. پاسخ باید نتیجه قابل مشاهده و مسئولیت هر طرف را روشن کند. اصطلاحات پیچیده بدون ارتباط با سناریو ضروری نیستند.
همچنین بپرسید توسعه ظرفیت چه Lead Time و روشی دارد. اگر پروژه بزرگ شد، مسیر انتقال به محیط اختصاصی چگونه است؟ این سؤال‌ها چرخه عمر را کامل می‌کنند.
سؤال‌های مربوط به زیرساخت اختصاصی را آماده کنیم
برای مسیر اختصاصی، معماری توسعه‌پذیر، ظرفیت روز اول، محدودیت دیتاسنتر، زمان تأمین، قطعه و پشتیبانی اهمیت دارند. مسئول عملیات، آموزش و انتقال دانش نیز باید روشن شوند. قیمت تجهیز تنها بخش تصمیم است.
سازمان می‌تواند بخواهد چند سناریو ارائه شود: حداقل قابل شروع، ظرفیت محتمل و توسعه آینده. فرض هر سناریو کنار عدد نوشته می‌شود. این روش بودجه را قابل دفاع‌تر می‌کند.
چه اطلاعاتی را همراه نیاوریم
Dataset واقعی، رمزها، کلید API، فهرست کامل IP، فایل تنظیمات و اسناد مشتری برای جلسه عمومی لازم نیستند. معماری بسیار دقیق امنیتی نیز باید فقط در کانال کنترل‌شده مبادله شود. هدف جلسه نخست تعیین دامنه و گام بعد است.
اگر نمونه لازم است، داده مصنوعی یا بی‌نام استفاده شود. تیم راگا نیز باید روش دریافت و نگهداری هر اطلاعات بعدی را شفاف کند. امنیت همکاری از شیوه تبادل اطلاعات آغاز می‌شود.
برگه یک صفحه‌ای آماده کنیم
برگه می‌تواند شامل هدف، دو کاربرد، مالک‌ها، تعداد تیم، الگوی مصرف، حجم و حساسیت داده، زمان، بودجه، سطح خدمت و محدودیت دیتاسنتر باشد. در پایین صفحه پنج سؤال اصلی سازمان نوشته می‌شوند. هر مورد نامشخص علامت می‌خورد.
این برگه جای Assessment نیست؛ جلسه را متمرکز می‌کند. پس از رویداد، اطلاعات لازم برای کارگاه فنی، پایلوت یا پیشنهاد اولیه مشخص خواهند شد. از تولید اسناد بلند بی‌استفاده جلوگیری می‌شود.
خروجی مورد انتظار از رویداد
سازمان بهتر است با یکی از چند نتیجه مشخص جلسه را ترک کند: تعیین مسیر مقدماتی Multi Tenant یا اختصاصی، نیاز به مقایسه بیشتر، تعریف پایلوت، برنامه Assessment یا توقف تا رفع یک پیش‌نیاز. هر نتیجه گام بعد، مالک و زمان پیگیری دارد.
قرار نیست همان روز قرارداد نهایی شود. ارزش رویداد در کاهش ابهام و ساختن پرونده تصمیم است. اگر سؤال مهمی بی‌پاسخ ماند، ثبت آن از پاسخ حدسی بهتر است.
نقش راگا در گفت‌وگوی نیازسنجی
راگا باید اطلاعات سازمان را به زبان زیرساخت ترجمه کند: ظرفیت پردازش، Network، Storage، Backup، Security و عملیات. سپس دو مدل Multi Tenant و اختصاصی با معیار مشترک مقایسه می‌شوند. پیشنهاد باید به کاربرد و محدودیت واقعی متصل باشد.
در جلسه عمومی اطلاعات حساس دریافت نمی‌شود. در صورت نیاز، کارگاه فنی جدا با دامنه و افراد مشخص برگزار خواهد شد. این مرزبندی هم تصمیم را سریع و هم تبادل اطلاعات را امن‌تر می‌کند.
معیارهای مقایسه را پیش از رویداد وزن بدهیم
سرعت شروع، امنیت داده، پیش‌بینی‌پذیری ظرفیت، هزینه، کنترل و مسئولیت عملیات برای همه سازمان‌ها وزن یکسانی ندارند. مدیرعامل و مدیر فناوری می‌توانند هر معیار را از یک تا پنج اولویت‌بندی کنند. این وزن‌ها به بحث Multi Tenant و اختصاصی جهت می‌دهند.
اگر امنیت و کنترل بیشترین وزن را دارند، باید دقیق شود کدام کنترل مدنظر است. اگر هزینه مهم است، دوره و سطح خدمت مشترک تعیین شود. واژه‌های کلی با یک سؤال تکمیلی به معیار قابل مقایسه تبدیل می‌شوند.
پس از رویداد تصمیم‌ها را همان روز ثبت کنیم
یادداشت کوتاه شامل پاسخ‌های قطعی، فرض‌ها، موارد باز و گام بعد تهیه شود. هر اقدام مالک و تاریخ دارد. اگر پایلوت پیشنهاد شد، سؤال تصمیم و معیار موفقیت آن نوشته می‌شود. اگر Assessment لازم است، دامنه و اطلاعات ورودی مشخص می‌گردد.
این ثبت مانع بازگشت جلسه به نقطه اول می‌شود. ارائه‌دهنده و سازمان می‌توانند خلاصه مشترک را تأیید کنند. اطلاعات حساس همچنان در مخزن و کانال مناسب نگهداری می‌شوند.
هماهنگی داخلی را پیش از درخواست پیشنهاد انجام دهیم
تیم مالی ممکن است هزینه مصرفی را ترجیح دهد، در حالی که زیرساخت کنترل اختصاصی می‌خواهد و امنیت بر محل داده تأکید دارد. این تفاوت‌ها طبیعی‌اند، اما اگر پیش از RFP دیده نشوند، پیشنهادها به خواسته‌های متناقض پاسخ می‌دهند. یک جلسه داخلی کوتاه اولویت‌ها را مرتب می‌کند.
هدف رسیدن به توافق کامل نیست. موارد اختلاف به‌عنوان سناریو در جلسه راگا مطرح می‌شوند. مثلاً یک گزینه Multi Tenant برای شروع و یک گزینه اختصاصی برای فاز تثبیت مقایسه می‌گردند. اختلاف به سؤال تصمیم تبدیل می‌شود.
نماینده جلسه باید بداند کدام موضوع در اختیار اوست و کدام تصمیم به تأیید دیگری نیاز دارد. این مرزبندی از تعهد ناخواسته جلوگیری می‌کند و اجازه می‌دهد پاسخ‌های نیازمند بررسی با مالک و موعد مشخص دنبال شوند.
جمع‌بندی مدیرعامل پیش از حضور
مدیرعامل سازمان ارائه سی‌صفحه‌ای را کنار می‌گذارد و یک برگه یک‌صفحه‌ای را تأیید می‌کند. دو کاربرد اولیه، مالک‌ها، بازه کاربران، حساسیت داده، زمان هدف و مدل بودجه روی آن قرار می‌گیرند. چهار مورد نامشخص نیز به‌صورت سؤال نوشته می‌شوند.
تیم اکنون برای یک جلسه واقعی آماده است. آن‌ها قرار نیست همه جزئیات فنی را بدانند؛ باید مسئله، محدودیت و معیار تصمیم خود را بشناسند. همین اطلاعات کافی است تا گفت‌وگو از معرفی عمومی به نیازسنجی و انتخاب گام بعد برسد.
چک‌لیست تصمیم‌گیری
- نیاز و مالک کسب‌وکاری مشخص باشد.
- نوع داده و محدودیت دسترسی ثبت شود.
- ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
- مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.
برای تصمیم‌گیری درباره Private AI
نیاز، ظرفیت، داده و مدل بهره‌برداری سازمان را پیش از خرید یا دریافت سرویس بررسی کنید.
سؤالات متداول
Private AI را از کجا شروع کنیم؟
از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.
زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟
پاسخ به حساسیت داده، زمان شروع، الگوی مصرف، توان بهره‌برداری و سطح کنترل موردنیاز بستگی دارد.
ظرفیت Private AI چگونه تعیین می‌شود؟
هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.
منابع
[۱] NIST — چارچوب مدیریت ریسک هوش مصنوعی و توجه به زمینه استفاده مشاهده منبع
[۲] Microsoft Learn — ملاحظات حاکمیت و عملیات در راهکارهای Multi Tenant مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «پیش از انتخاب Private AI باید مسیر توسعه انتقال داده و پایان همکاری روشن باشد» را ببینید.