Private AI, مجله راگا
تصمیم اولیه سازمان برای تأمین زیرساخت Private AI
شهریور
در جلسه برنامهریزی سازمان فرضی این روایت، مدیرعامل از مدیر فناوری اطلاعات میپرسد: «اگر بخواهیم استفاده از هوش مصنوعی را جدیتر دنبال کنیم، از کجا باید شروع کنیم؟» پاسخ اولیه، فهرستی از تجهیزات و هزینههاست. هنوز گفتوگو جلو نرفته، مدیر مالی درباره بودجه سؤال میکند. مدیرعامل هم میگوید فعلاً نمیخواهد خرید بزرگی را تصویب کند؛ میخواهد بداند سازمان دقیقاً به چه چیزی نیاز دارد و کدام تصمیم را باید امروز بگیرد.
این جلسه میتواند خیلی زود به مقایسه مشخصات سرورها تبدیل شود. اما پرسش مقدماتی چیز دیگری است: سازمان برای کار موردنظر خود چه محیطی لازم دارد، چه میزان اختیار میخواهد و ترجیح میدهد منابع زیرساختی را چگونه تأمین کند؟ تا این موارد روشن نشوند، حتی یک پیشنهاد فنی دقیق هم ممکن است پاسخ مسئله دیگری باشد.
تصمیم اول، تعیین دامنه نیاز و شیوه بررسی آن است. نتیجه این بررسی میتواند دریافت زیرساخت Private AI بهصورت سرویس یا ایجاد زیرساخت اختصاصی در سازمان باشد. هر دو مسیر باید با بودجه، حساسیت اطلاعات، زمان شروع و توان نگهداری مجموعه سنجیده شوند. برای شروع لازم نیست پاسخ همه جزئیات را بدانیم؛ باید بدانیم چه اطلاعاتی هنوز برای تصمیم کم داریم.
درخواست کلی را به یک نیاز قابل بررسی تبدیل کنیم
مدیر فناوری از مدیرعامل میخواهد جمله «هوش مصنوعی میخواهیم» را کمی باز کند. چه گروهی قرار است از ظرفیت جدید استفاده کند؟ کار آنها در چه ساعاتی انجام میشود؟ آیا شروع کار به زمان مشخصی وابسته است؟ اگر ظرفیت آماده شود، چه کسی مسئول استفاده از آن خواهد بود؟ این سؤالها بحث را از علاقه عمومی به فناوری به یک درخواست سازمانی تبدیل میکند.
فرض کنیم دو تیم سازمان برای انجام کارهای مصوب خود به محیط پردازشی نیاز دارند. یکی هنوز در مرحله بررسی است و دیگری میخواهد فعالیتی منظم را آغاز کند. ممکن است نیاز فنی آنها متفاوت باشد، اما مسئله مدیریتی مشترک است: منابع باید در زمان مناسب، با دسترسی مشخص و هزینه قابل پیگیری در اختیارشان قرار گیرد. جمع کردن این دو درخواست زیر عنوان یک خرید بزرگ، تفاوت مرحله و نیاز آنها را پنهان میکند.
بهتر است برای هر درخواست یک برگه کوتاه تهیه شود. نام مسئول، هدف استفاده، زمان شروع، مدت اولیه، حساسیت اطلاعات و بودجه قابل بررسی در آن نوشته شود. وقتی تیم هنوز مقدار دقیق منابع را نمیداند، همان ابهام ثبت شود. عدد نامطمئن را به تعهد خرید تبدیل نکنیم. اندازهگیری اولیه میتواند یکی از خروجیهای مرحله بعد باشد.
زیرساخت Private AI برای مدیریت چه معنایی دارد
در این بحث، زیرساخت Private AI محیطی برای تأمین منابع پردازشی، ذخیرهسازی و ارتباطات موردنیاز فعالیتهای AI سازمان است که دسترسی و شیوه استفاده از آن باید تحت کنترلهای مشخص قرار گیرد. برای مدیرعامل، موضوع اصلی نام قطعات نیست. اهمیت دارد بداند چه ظرفیتی تحویل میگیرد، چه کسانی اجازه استفاده دارند و هنگام بروز مشکل چه کسی پاسخگو خواهد بود.
عنوان Private AI بهتنهایی پاسخ همه پرسشهای امنیتی یا اجرایی را نمیدهد. محل نگهداری اطلاعات، نحوه تفکیک محیط سازمان، حدود دسترسی مدیران سرویس و مسئولیت نگهداری باید در طراحی و توافق روشن باشد. خصوصیبودن را باید در این تصمیمها و کنترلها دید. صرف استفاده از یک نام در پیشنهاد فروش، جای بررسی آنها را نمیگیرد.
همچنین تأمین زیرساخت میتواند شکلهای متفاوتی داشته باشد. در مدل زیرساخت بهصورت سرویس، مشتری منابع پایهای مانند پردازش، ذخیرهسازی و شبکه دریافت میکند. این همان سطح خدمتی است که NIST در تعریف زیرساخت بهعنوان سرویس توضیح میدهد. [۱] برای سازمان ما، پرسش کاربردی این است که کدام مسئولیتها همراه این منابع واگذار میشوند و کدام بخشها همچنان بر عهده تیم خودش باقی میمانند.
چهار تصمیم پیش از ورود به فهرست تجهیزات
اولین تصمیم به اطلاعات مربوط است. چه دادهای قرار است وارد محیط شود و چه محدودیتی برای محل یا دسترسی به آن وجود دارد؟ پاسخ این پرسش را نباید صرفاً به تأمینکننده سپرد. مدیر فناوری باید با مالک اطلاعات صحبت کند و محدودیتهای واقعی سازمان را مشخص سازد. گاهی الزام، کنترل دسترسی است و گاهی نیاز به یک محیط فیزیکی اختصاصی وجود دارد؛ این دو الزام یکسان نیستند.
تصمیم بعدی، زمان است. اگر سازمان برای شروع یک فعالیت زمان مشخص دارد، مسیر تأمین باید با آن هماهنگ باشد. خرید، آمادهسازی محل، راهاندازی و تحویل هرکدام به بررسی نیاز دارند. دریافت سرویس هم زمان آمادهسازی و کنترلهای خودش را دارد. هیچیک را بدون دریافت برنامه اجرایی، فوری یا طولانی فرض نکنیم.
دو تصمیم دیگر، سقف هزینه و مسئول بهرهبرداری هستند. چه مبلغی برای مرحله اول قابل بررسی است و چه کسی مصرف، دسترسی و درخواست تغییر را مدیریت میکند؟ بودجه بدون مسئول مصرف میتواند به هزینههای نامعلوم برسد. مسئول فنی بدون اختیار لازم هم نمیتواند درباره افزایش ظرفیت یا زمان نگهداری پاسخگو باشد. این رابطه باید پیش از شروع روشن شود.
در جلسه بودجه فقط مبلغ خرید را نبینیم
مدیر مالی فهرست اولیه را نگاه میکند و میپرسد: «این مبلغ، هزینه شروع است یا هزینه کل یک سال؟» تفاوت سؤال مهم است. در زیرساخت اختصاصی، علاوه بر خرید باید نگهداری، پشتیبانی، فضای استقرار، برق و وقت تیم را در نظر گرفت. مقدار هر هزینه به شرایط سازمان وابسته است؛ لازم نیست برای کامل شدن جدول، عدد تخمینی بیپشتوانه وارد شود.
در دریافت سرویس نیز مبلغ دورهای همه داستان نیست. باید مشخص باشد چه منابعی در مبلغ پایه قرار دارد، تغییر ظرفیت چه اثری روی صورتحساب میگذارد و کدام خدمات جداگانه محاسبه میشوند. در این مرحله از گفتوگو، وعده «حتماً ارزانتر است» کمک چندانی نمیکند. مقایسه باید برای یک نیاز و یک سطح خدمت یکسان انجام شود.
نتیجه مفید جلسه میتواند تأیید بودجه یک بررسی محدود باشد. سازمان مبلغ مشخصی برای سنجش نیاز، دریافت پیشنهاد و ارزیابی گزینهها کنار میگذارد. این تصمیم نه خرید نهایی را از پیش قطعی میکند و نه شروع کار را تا روشن شدن تمام آینده عقب میاندازد. مدیر مالی میداند هزینه این مرحله برای پاسخ دادن به کدام ابهام مصرف میشود.
دریافت سرویس را بهعنوان یک گزینه مستقل بررسی کنیم
برای سازمانی که مقدار مصرف آیندهاش روشن نیست، دریافت زیرساخت بهصورت سرویس میتواند یکی از گزینههای جدی بررسی باشد. بهجای شروع گفتوگو با مالکیت تجهیزات، میتوان درباره ظرفیت موردنیاز، مدت استفاده و سطح پشتیبانی صحبت کرد. مناسببودن این مسیر به شرایط واقعی پیشنهاد، الزامات سازمان و هزینه کل وابسته است.
مدیرعامل در روایت ما از این گزینه استقبال میکند، اما یک نگرانی دارد: «اگر بعدها نیازمان بیشتر شد، گرفتار تصمیم امروز نمیشویم؟» پاسخ باید قابل بررسی باشد. چه مقدار افزایش منابع ممکن است؟ زمان تأمین ظرفیت بیشتر چقدر است؟ آیا نوع نیاز جدید با محیط اولیه سازگار خواهد بود؟ انعطافپذیری زمانی ارزش مدیریتی دارد که مسیر استفاده از آن معلوم باشد.
در سرویس Multi-Tenant، چند سازمان میتوانند از یک بستر زیرساختی استفاده کنند و محیط هرکدام باید مطابق طراحی از دیگران تفکیک شود. در قسمتهای بعد، این مدل را با مثال باز میکنیم. فعلاً کافی است آن را کنار گزینه زیرساخت اختصاصی روی میز بگذاریم و درباره مرز دسترسی، ظرفیت قابل ارائه و تعهد پاسخگویی سؤال کنیم.
زیرساخت اختصاصی چه زمانی وارد تصمیم میشود
ممکن است سازمان الزام مشخصی برای استقرار داخلی داشته باشد یا مصرف آن پایدار و قابل پیشبینی باشد. ممکن است هماکنون فضای مناسب و تیم آماده بهرهبرداری در اختیار داشته باشد. در این شرایط، طراحی زیرساخت اختصاصی میتواند انتخاب قابل دفاعی باشد. مهم است این انتخاب از نیاز سازمان بیاید و فقط ادامه عادت همیشگی خرید تجهیزات نباشد.
داشتن تجهیزات در سازمان نیز به معنای حذف هزینه عملیات نیست. باید معلوم باشد چه کسی وضعیت منابع را پیگیری میکند، خرابی را رسیدگی میکند و افزایش ظرفیت را برنامهریزی خواهد کرد. اگر تمام این مسئولیتها به تیمی سپرده شود که همین حالا ظرفیت کاری محدودی دارد، باید هزینه و زمان تقویت آن تیم هم در تصمیم دیده شود.
گاهی ارزیابی نشان میدهد سازمان برای تصمیم نهایی هنوز اطلاعات کافی ندارد. در چنین وضعی، میتوان ابتدا اندازه و الگوی نیاز را روشن کرد و سپس درباره مسیر اختصاصی تصمیم گرفت. مسیر بررسی باید امکان رسیدن به هر دو نتیجه را داشته باشد؛ دریافت سرویس برای نیاز فعلی یا اجرای پروژه اختصاصی با دامنه مشخص.
مالکیت تصمیم را میان واحدها روشن کنیم
مدیر فناوری پیشنهاد میکند واحد درخواستکننده، نتیجه موردانتظار از استفاده را توضیح دهد. تیم او نیاز زیرساختی و شرایط دسترسی را بررسی کند. واحد مالی هم هزینه گزینهها را با فرضهای یکسان مقایسه کند. مدیرعامل زمانی تصمیم میگیرد که این سه نگاه کنار هم قرار گرفته باشند. انتظار پاسخ به تمام پرسشها از یک واحد، معمولاً بخشی از مسئله را نادیده میگذارد.
برای مثال، اگر تیم درخواستکننده نتواند بگوید چه زمانی به ظرفیت نیاز دارد، تیم فناوری نمیتواند برای تحویل تعهد روشنی بگیرد. اگر مالی فقط سقف خرید تجهیزات را اعلام کند، مقایسه با هزینه دورهای سرویس ناقص میماند. جلسه مشترک باید همین وابستگیها را روشن کند، بدون اینکه به مرور همه مشخصات فنی تبدیل شود.
خروجی جلسه بهتر است کوتاه و قابل پیگیری باشد: نیاز اولیه، ابهامهای باقیمانده، مسئول تکمیل اطلاعات و زمان تصمیم بعدی. وجود این برگه جلوی شروع چند بررسی موازی و ناسازگار را میگیرد. هر پیشنهادی که بعداً دریافت میشود، باید به همین درخواست پاسخ دهد تا مقایسه پیشنهادها امکانپذیر بماند.
پاسخگویی پس از تحویل را از حالا ببینیم
ممکن است در جلسه نخست همه بر راهاندازی تمرکز کنند، اما سازمان چند هفته بعد با سؤالهای دیگری مواجه میشود. یک کاربر جدید باید دسترسی بگیرد، مصرف بیشتر شده یا تیمی میخواهد زمان استفاده را تغییر دهد. اگر روش رسیدگی مشخص نباشد، کارهای ساده هم به پیگیریهای طولانی تبدیل میشوند. بنابراین فرایند درخواست و پاسخگویی بخشی از انتخاب زیرساخت است.
دریافت خدمت از بیرون، مسئولیت مدیریتی سازمان را حذف نمیکند. راهنمای امنیت خدمات ابری NIST نیز بر باقیماندن مسئولیت نظارت نزد سازمان تأکید دارد. [۲] در عمل، سازمان باید مسئول ارتباط با ارائهدهنده، تأیید دسترسیها و کنترل هزینه را تعیین کند. دامنه مسئولیت دو طرف هم باید در توافق روشن باشد.
در روایت ما، مدیرعامل میخواهد گزارش مرحله نخست فقط درباره «آماده شدن محیط» نباشد. او میخواهد بداند محیط تحویل گرفته شده، افراد مجاز میتوانند از آن استفاده کنند، هزینه قابل پیگیری است و مسیر درخواست تغییر مشخص شده است. اینها معیارهایی هستند که میتوان درباره آنها توافق و بعداً نتیجه را بررسی کرد.
قبل از جلسه بعدی چه اطلاعاتی جمع کنیم
مدیر فناوری برای دور بعدی بررسی، درخواست فهرست بلندبالایی نمیدهد. از هر تیم میخواهد یک نمونه از برنامه کاری هفته آینده، تعداد افرادی که همزمان کار میکنند و مدت قابل قبول انتظار را ارائه کند. اگر این اطلاعات هنوز معلوم نیست، تیم میتواند یک بازه اولیه بنویسد و توضیح دهد آن را بر چه اساسی برآورد کرده است. برآوردی که فرضش روشن است، بعداً راحتتر اصلاح میشود.
مدیر مالی نیز دو نوع هزینه را جدا میکند: مبلغی که برای شروع باید پرداخت شود و هزینهای که با ادامه استفاده ایجاد خواهد شد. درباره خرید، دوره استفاده و هزینه نگهداری اهمیت دارد. درباره سرویس، مدت تعهد و شرایط تغییر ظرفیت باید معلوم شود. مقایسه مبلغ خرید چندساله با صورتحساب یک ماه سرویس، حتی اگر عددهای هر دو درست باشند، نتیجه معناداری نمیدهد.
یکی از مدیران پیشنهاد میکند نیاز احتمالی همه واحدها از همین ابتدا در محاسبه بیاید تا بعدها دوباره تصمیم نگیرند. مدیرعامل میپرسد کدام درخواست واقعاً تصویب شده و کدام صرفاً یک احتمال است. در برگه بررسی، این دو گروه جدا میشوند. نیاز تأییدشده مبنای شروع قرار میگیرد و نیاز احتمالی در بخش توسعه آینده میآید. به این ترتیب، رشد آینده دیده میشود اما هزینه امروز را بیدلیل بزرگ نمیکند.
پیش از پایان جلسه، زمان بازبینی هم تعیین میشود. اگر تا آن روز هنوز اطلاعات مصرف آماده نباشد، موضوع جلسه بعد باید روش اندازهگیری باشد. اگر اطلاعات کافی جمع شده باشد، مدیران میتوانند پیشنهاد دریافت سرویس و زیرساخت اختصاصی را کنار هم بگذارند. داشتن زمان مشخص برای تصمیم بعدی، کمک میکند بررسی اولیه به یک پروژه بیپایان تبدیل نشود و هر واحد بداند چه چیزی باید تحویل دهد.
شروع گفتوگو با راگا
راگا زیرساخت Private AI را در دو مسیر بررسی میکند: دریافت زیرساخت بهصورت سرویس و طراحی و پیادهسازی زیرساخت اختصاصی برای سازمان. نقطه شروع گفتوگو، شرایط مشتری است؛ چه نیازی دارد، چه اطلاعاتی باید حفاظت شود، چه زمانی میخواهد شروع کند و چه بودجهای برای این مرحله در نظر گرفته است.
اگر این سؤال در سازمان شما هم مطرح شده، برای جلسه اولیه یک شرح کوتاه از نیاز، زمان شروع و محدودیتهای اصلی آماده کنید. لازم نیست از ابتدا فهرست تجهیزات داشته باشید. مشخص شدن نیاز و ابهامها کمک میکند گفتوگو با راگا به بررسی یک گزینه متناسب برسد، نه دریافت پیشنهادی که هنوز معلوم نیست برای چه میزان استفاده تهیه شده است.
جلسه سازمان فرضی ما با خرید تجهیزات تمام نمیشود. مدیران توافق میکنند ابتدا دو مسیر تأمین را با یک نیاز مشترک مقایسه کنند. پرسش بعدی آنها روشن است: برای شروع Private AI، کدام بخش از زیرساخت را واقعاً لازم است بخریم و کدام بخش را میتوانیم بهصورت سرویس دریافت کنیم؟ همین پرسش، موضوع ادامه این روایت خواهد بود.
منابع
[۱] تعریف زیرساخت بهعنوان سرویس در سند NIST SP 800-145 مشاهده منبع
[۲] مسئولیت نظارت سازمان در سند NIST SP 800-144 مشاهده منبع
مطالب مرتبط در سایت راگا
برای آشنایی بیشتر با راهکار مرتبط، راهنمای Private AI روی VCF را ببینید.