هوش مصنوعی خصوصی در سازمان؛ از ایده تا بهره‌برداری قابل اعتماد

برای مدیران فناوری اطلاعات، ارزیابی «هوش مصنوعی خصوصی» معمولاً بر کنترل داده، رعایت سطوح دسترسی، کیفیت پاسخ و پیش‌بینی‌پذیری هزینه متمرکز است. دستیابی به این اهداف مستلزم آن است که محیط پردازش، منابع دانش و مسئولیت بهره‌برداری از ابتدا مشخص باشند. این مقاله، با استفاده از یک سناریوی دانش داخلی، مسیر تصمیم‌گیری و تحویل خدمت هوش مصنوعی خصوصی را بررسی می‌کند.

تفاوت Private AI، استقرار داخلی و ابر خصوصی

در این مقاله، Private AI به معماری‌ای اطلاق می‌شود که سازمان در آن، حدود و کنترل‌های مشخصی برای داده، هویت کاربران، مدل‌های مجاز و عملیات تعریف کرده است. این عنوان به‌تنهایی بیانگر یک استاندارد امنیتی یا تضمین محل نگهداری داده نیست. ارائه‌دهنده باید به‌روشنی توضیح دهد که عنوان «خصوصی» کدام بخش‌های خدمت را پوشش می‌دهد.

تعریف اصطلاحات برای تصمیم‌گیری معماری

عدم استفاده از داده برای آموزش مدل، با نگهداری داده در داخل سازمان یکسان نیست. برای نمونه، تعهدات حریم خصوصی سازمانی OpenAI این موضوع را برای خدمات کسب‌وکار توضیح می‌دهد، اما آن خدمات همچنان مسیر پردازش و قواعد نگهداری خود را دارند. امکان استفاده رسمی از هر خدمت خارجی نیز باید پیش از انتخاب جداگانه بررسی شود.

شرایط نیاز سازمان به معماری هوش مصنوعی خصوصی

نشانه‌های نیاز سازمانی

وجود داده داخلی، به‌تنهایی سرمایه‌گذاری فوری در زیرساخت گسترده را توجیه نمی‌کند. نقطه شروع مناسب، انتخاب یک مسئله پرتکرار با مالک مشخص و سنجش زمان و کیفیت روش فعلی است. در نبود منابع معتبر یا مسئول به‌روزرسانی آن‌ها، آماده‌سازی داده ممکن است نسبت به انتخاب مدل اولویت بیشتری داشته باشد.

مثال فرضی: دستیار دانش داخلی واحد فناوری اطلاعات

در این سناریو، سازمان مجموعه‌ای از راهنماهای سامانه‌ها، دستورالعمل‌های امنیتی، قراردادهای خدمت و پرسش‌های پشتیبانی در اختیار دارد. کارشناس می‌پرسد: «برای دسترسی همکار جدید به سامانه خرید چه تأییدهایی لازم است؟» دستیار باید دستورالعمل معتبر همان سامانه را، متناسب با نقش کاربر، بازیابی کند، مراحل را خلاصه سازد و پیوند و نسخه منبع را نمایش دهد.

چنانچه درخواست به اطلاعات محرمانه قرارداد یا رمزهای دسترسی مربوط باشد، منابع خارج از مجوز کاربر نباید در اختیار مدل قرار گیرند. اگر راهنما قدیمی یا مبهم باشد، پاسخ باید این محدودیت را بیان کند و کاربر را به مالک سامانه ارجاع دهد. درصد اطمینانی که مدل تولید می‌کند، جایگزین شواهد و آزمون نیست؛ هر امتیاز اطمینان باید تعریف مشخصی داشته باشد و با نمونه‌های واقعی ارزیابی شده باشد.

معماری پیشنهادی در سطح عملیاتی

1. هویت و دسترسی: کاربر، گروه و نقش از منبع معتبر سازمان شناسایی شود؛ مجوز در زمان دسترسی اعمال شود
2. داده و دانش: منابع دارای مالک، تاریخ و سطح محرمانگی باشند و تغییر نسخه به نمایه منتقل شود
3. مدل و پردازش: مدل‌ها و مقصدهای مجاز با توجه به کیفیت، سیاست داده و شرایط استفاده انتخاب شوند
4. بازیابی و ابزارها: فقط اطلاعات لازم و مجاز در اختیار مدل قرار گیرد؛ اتصال به سامانه‌ها محدود و قابل پیگیری باشد
5. عملیات و ارزیابی: نسخه‌ها، کیفیت، تأخیر، مصرف و رخدادها با حداقل داده لازم پایش شوند
6. تجربه کاربر: پاسخ مستند، اعلام کمبود اطلاعات و ارجاع به کارشناس در دسترس باشد

اصل کنترل مجوز مستقل از محل شبکه، در معماری اعتماد صفر NIST توضیح داده شده است. برای جزئیات آزمون اسناد و مسیر داده، راهنمای امنیت استقرار داخلی را مطالعه کنید؛ کنترل دسترسی نباید صرفاً به پنهان‌کردن گزینه‌ها در رابط کاربری محدود شود.

مبنای برآورد واقع‌بینانه زمان و هزینه

زمان‌بندی پروژه به آمادگی منابع، مجوزهای دسترسی، زیرساخت و مشارکت کارشناسان سازمان وابسته است. جدول زیر، الگویی برای برنامه‌ریزی یک سناریوی محدود ارائه می‌کند و تعهد تحویل محسوب نمی‌شود. حتی برآورد یک تا دو هفته برای مرحله شناخت و طراحی، تنها در صورت تعیین دامنه، آماده‌بودن اسناد نمونه و دسترسی به تصمیم‌گیران قابل بررسی است.

مراحل و خروجی‌های برنامه‌ریزی

سه بخش اصلی هزینه کل

• هزینه راه‌اندازی: تحلیل، آماده‌سازی داده، مجوز نرم‌افزار، اتصال‌ها، آزمون و آموزش
• هزینه زیرساخت و خدمت: سرور یا پردازش ابری مجاز، ذخیره‌سازی، شبکه، انرژی و پشتیبان
• هزینه بهره‌برداری: پشتیبانی، امنیت، بازبینی پاسخ، به‌روزرسانی محتوا و ارزیابی نسخه جدید

مقایسه پیشنهادها باید بر فرض‌های یکسان درباره تعداد کاربران فعال، درخواست‌های هم‌زمان، طول اسناد و سطح خدمت استوار باشد. قیمت GPU یا هزینه توکن، به‌تنهایی مبنای کافی برای این مقایسه نیست. هزینه هر کار موفق باید با احتساب بازبینی و اصلاح خطا محاسبه شود و برآورد بازگشت سرمایه تنها پس از اندازه‌گیری عملکرد روش فعلی و پایلوت انجام گیرد.

شواهد لازم برای پذیرش و تحویل خدمت

معیارهای پیشنهادی پذیرش پایلوت

آستانه پذیرش و مسئول تأیید باید پیش از آزمون تعیین و ثبت شوند. پذیرش کاربر و استناد به سند، هر دو شواهد مفیدی هستند، اما هیچ‌یک به‌تنهایی صحت نهایی پاسخ را اثبات نمی‌کند. توانایی سامانه در اعلام نبود پاسخ در منابع معتبر نیز باید بخشی از ارزیابی باشد.

چارچوب مدیریت ریسک هوش مصنوعی NIST می‌تواند به سازمان‌دهی مسئولیت و بازبینی ریسک کمک کند. برای کنترل روزمره کیفیت و هزینه نیز چرخه LLMOps باید متناسب با دامنه خدمت طراحی شود.

اطلاعات مورد نیاز از ارائه‌دهنده پیش از انتخاب راهکار

• حدود دقیق پردازش و نگهداری داده و فهرست وابستگی‌های بیرونی، از مدل تا ثبت رویداد و پشتیبانی
• تفکیک امکانات نسخه قابل تحویل، توسعه سفارشی و برنامه آینده
• نتیجه آزمون مدل و سخت‌افزار پیشنهادی روی سناریوی توافق‌شده
• شرح مسئولیت سازمان و پیمانکار در امنیت، پشتیبان و نگهداری محتوا
• روش دریافت داده و تنظیمات، شرایط پایان قرارداد و نحوه ادامه پشتیبانی

نقطه شروع مناسب، خدمتی با دامنه محدود، حدود مشخص و شواهد قابل بررسی است. افزودن واحدها و منابع در مراحل بعد نیز باید به‌صورت تدریجی انجام شود. عنوان Private AI زمانی مبنای مناسبی برای تصمیم مدیر فناوری اطلاعات است که کنترل‌ها، مسئولیت‌ها و نتایج آزمون آن به‌روشنی قابل بررسی باشند.