مدل‌های هوش مصنوعی (AI Models) در حال تبدیل شدن به مستاجران کوتاه‌مدت در دارایی‌های داده‌ای بلندمدت سازمان‌ها هستند. با این حال، بسیاری از سازمان‌ها به اشتباه، کل ساختمان (زیرساخت) خود را بر اساس نیازهای هر مستاجر جدید بازسازی می‌کنند.
تغییر سریع مدل‌ها در مقابل ثبات داده‌های سازمانی
امروزه بازار مدام این سوال را می‌پرسد که سازمان‌ها باید به کدام مدل اعتماد کنند: مدل‌های باز (Open) یا بسته (Closed)، داخلی یا خارجی؟ این‌ها سوالات مهمی هستند، اما عمر کوتاهی دارند. رتبه‌بندی مدل‌ها ماهانه تغییر می‌کند، تامین‌کنندگان شرایط خود را عوض می‌کنند و قابلیت‌هایی که شش ماه پیش کمیاب بودند، اکنون به کالاهایی عمومی تبدیل شده‌اند.
در مقابل، داده‌های سازمانی، کنترل‌ها، اپلیکیشن‌ها و فرآیندهای کسب‌وکار با این سرعت تغییر نمی‌کنند. این عدم تطابق باعث شده تا مهم‌ترین تصمیم معماری برای مدیران فناوری (CIOs) دیگر انتخاب یک مدل خاص نباشد، بلکه این باشد که آیا سازمان می‌تواند تغییرات مستمر را بدون تکه‌تکه شدن دارایی‌های داده‌ای یا از دست دادن کنترل، جذب کند یا خیر.
توسعه‌پذیری به عنوان یک نیاز عملیاتی
در مراحل آزمایش (Experimentation)، محدودیت‌های معماری به راحتی پنهان می‌شوند. یک تیم می‌تواند یک مدل جدید را به یک مجموعه داده کپی شده متصل کرده و موفقیت پروژه پایلوت را اعلام کند. اما در مرحله تولید (Production)، معماری واقعی خود را نشان می‌دهد: هویت (Identity)، مجوزها (Permissions)، محل استقرار داده‌ها (Data Residency)، تبار داده‌ها (Data Lineage)، تاخیر (Latency)، بازیابی و هزینه.
هر بار که این کنترل‌ها بر اساس یک مدل خاص بازسازی شوند، آن مدل به یک وابستگی (Dependency) تبدیل می‌شود. در این حالت، افزودن یا تغییر قابلیت‌ها به معنای جابجایی داده‌ها، بازنویسی سیاست‌های دسترسی و بررسی مجدد انطباق (Compliance) خواهد بود. آنچه در مرحله پایلوت «سرعت» به نظر می‌رسید، در مرحله تولید به مارپیچی از معماری‌های نقطه-به-نقطه تبدیل می‌شود که توسعه و مدیریت آن بسیار دشوار است.
شکاف بین انتظارات و معماری
بر اساس نظرسنجی‌ها، اکثر مدیران فناوری انتظار دارند تا سال ۲۰۲۶ از دو یا چند تامین‌کننده مدل‌های زبانی بزرگ (LLM) استفاده کنند، زیرا مدل‌های مختلف برای کاربردهای مختلف عملکرد بهتری دارند. وقتی یک مدل عمیقاً در منطق اپلیکیشن و خطوط لوله داده (Data Pipelines) جاسازی شود، جایگزینی آن به جای یک تغییر ساده در پیکربندی، به یک پروژه مهندسی چند ماهه تبدیل می‌شود.
این موضوع توضیح می‌دهد چرا بسیاری از ابتکارات هوش مصنوعی به اهداف تجاری خود نمی‌رسند. سیستم‌هایی که برای اولین دموی مدل بهینه شده‌اند، به ندرت به طور تصادفی به سیستم‌های تولیدی بادوام تبدیل می‌شوند.
تمرکز کنترل بر لایه داده‌ها
مدل‌ها به طور فزاینده‌ای قابل جایگزینی هستند، اما زمینه‌ی سازمانی (Enterprise Context) این‌گونه نیست. دارایی متمایز یک سازمان، مجموعه مدیریت‌شده‌ای از تاریخچه مشتریان، وضعیت عملیاتی و مالکیت معنوی است که به مدل اجازه می‌دهد استدلال‌های مفیدی انجام دهد.
به همین دلیل، لایه داده‌ها (Data Layer) باید نقطه کنترل بادوام باشد. هویت، دسترسی، محل استقرار، حسابرسی (Audit) و سیاست‌ها باید تا حد امکان نزدیک به داده‌ها و در محیطی که سازمان بر آن تسلط دارد، اعمال شوند. در این حالت، مدل می‌تواند در این مرزها بازرسی، ایزوله (Sandbox) یا جایگزین شود.
اگر حاکمیت (Governance) بر اساس لایه داده‌ها اجرا شود، هر مدل جدیدی که جایگزین شود، از روز اول سیاست‌های عملیاتی و ردپای حسابرسی موجود را به ارث می‌برد. این یعنی «حاکمیت عملیاتی»؛ اینکه نه تنها داده‌ها کجا میزبانی می‌شوند، بلکه چه کسی می‌تواند محیط را طبق شرایط خود مدیریت کرده، جابجا یا توسعه دهد.
تاثیر بر عامل‌های هوش مصنوعی (AI Agents)
با ورود عامل‌های هوش مصنوعی به محیط تولید، این موضوع حیاتی‌تر می‌شود. عامل‌ها به سرعت تکثیر می‌شوند و در سیستم‌های مختلف عمل می‌کنند. اگر کنترل‌ها در محل استقرار داده‌ها اعمال شوند، هر عامل جدید به طور پیش‌فرض این کنترل‌ها را به ارث می‌برد. در غیر این صورت، هر عامل با خط لوله و مدل مجوزهای خاص خود می‌آید و بار مدیریتی سازمان با هر عامل جدید افزایش می‌یابد.
نتیجه‌گیری: هوشمندانه‌ترین استراتژی هوش مصنوعی، شرط‌بندی روی مدل امروز نیست، بلکه ایجاد یک زیرساخت داده‌ای است که بتواند بدون واگذاری اختیار بر داده‌ها، توسعه یابد. ساختمان باید بیشتر از مستاجر عمر کند و هیچ مدل یا پلتفرمی نباید مالک سند داده‌های سازمان باشد.
