اگر امروز بودجه‌ای را برای استقرار هوش مصنوعی در سازمانتان اختصاص داده‌اید، احتمالاً با پدیده‌ای مواجه شده‌اید که در آن هیجان اولیه جای خود را به هزینه‌های پیش‌بینی‌نشده و نتایج مبهم می‌دهد. باید بدانید که مقیاس‌دهی هوش مصنوعی در سطح سازمانی، نه یک مانع فنی، بلکه یک بحران حاکمیتی است.
به نقل از یوری گوبین (Yuri Gubin)، مدیر فناوری (CTO) شرکت DataArt، سازمان‌ها بدون یک چارچوب منضبط برای اعتبارسنجی، در چرخه‌ای از آزمایش‌های گران‌قیمت گرفتار می‌شوند که هرگز ارزش تجاری قابل‌اندازه‌گیری تولید نمی‌کنند. این هشدار گوبین در زمانی مطرح می‌شود که سازمان‌ها در حال گذار از پروژه‌های آزمایشی (Pilot) که صرفاً بر اساس کنجکاوی هدایت می‌شدند، به سمت سیستم‌های در سطح تولید (Production-grade) حرکت می‌کنند. بسیاری از شرکت‌ها در حال حاضر در تشخیص تفاوت بین یک جهش موقت در بهره‌وری و یک بهبود پایدار در جریان کاری دچار مشکل هستند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی حاکمیت داده‌ها در مدل‌های زاینده اشاره کردیم، مدیریت زیرساخت در مقیاس بزرگ نیازمند نظارتی است که فراتر از کدنویسی باشد. برای شرکتی مثل DataArt که با ۶۰۰۰ متخصص در بیش از ۲۰ کشور فعالیت می‌کند، مخاطرات شامل مدیریت هزینه‌های عظیم زیرساختی و حفظ کیفیت کد در صدها مشتری مختلف است.
زمینه: تکامل DataArt و رهبری فنی
شرکت DataArt در سال ۱۹۹۷ در نیویورک تأسیس شد و به مرور زمان به یکی از پیشروان جهانی در مهندسی نرم‌افزار و تحول هوش مصنوعی تبدیل گشت. این شرکت در حال حاضر به بیش از ۴۰۰ مشتری در بخش‌های متنوعی از جمله خدمات مالی، مراقبت‌های بهداشتی و علوم زیستی، سفر، رسانه و سرگرمی، و خرده‌فروشی خدمات ارائه می‌دهد. برای حفظ جایگاه رقابتی خود، DataArt از مشارکت‌های استراتژیک با پلتفرم‌های بزرگی نظیر AWS، Google Cloud، Microsoft Azure، Snowflake و Databricks بهره می‌برد.
در سال ۲۰۲۵، این شرکت تعهد خود به عصر هوش مصنوعی را با اعلام یک سرمایه‌گذاری ۱۰۰ میلیون دلاری سه ساله در قابلیت‌های داده و AI نشان داد. این سرمایه‌گذاری در سال ۲۰۲۶ به عرضه Artisyn منجر شد؛ یک مدل عملیاتی مبتنی بر هوش مصنوعی که برای ادغام عامل‌های AI، شتاب‌دهنده‌های قابل استفاده مجدد، حاکمیت، امنیت و انطباق (Compliance) مستقیماً در فرآیند توسعه نرم‌افزارهای سازمانی طراحی شده است.
رهبری این چشم‌انداز فنی بر عهده یوری گوبین است که در مارس ۲۰۲۶ به مقام CTO رسید. گوبین یک مدیر ارشد فناوری و معمار نرم‌افزار باسابقه است که بیش از ۱۸ سال در DataArt فعالیت کرده است. مسیر شغلی او — که از معماری نرم‌افزار، معماری راهکارها، فناوری ابری و نوآوری عبور کرده — در نهایت به بیش از پنج سال فعالیت به عنوان مدیر ارشد نوآوری (Chief Innovation Officer) شرکت ختم شد.
نفوذ رهبری و تأثیرات خارجی
فراتر از نقش داخلی‌اش، گوبین از سال ۲۰۲۱ عضو هیئت شرکای شرکت بوده است. او دیدگاهی گسترده را به نقش CTO می‌آورد، چرا که چالش‌های پیچیده فناوری را در حوزه‌های اینترنت اشیاء (IoT)، بهداشت و درمان و خدمات مالی حل کرده است.
تأثیر او به جامعه گسترده‌تر فناوری از طریق چندین نقش کلیدی گسترش یافته است:
- شورای فناوری فوربز (Forbes Technology Council): او عضو حرفه‌ای این شورا است و به‌طور خاص در گروه‌های تخصصی هوش مصنوعی و رایانش ابری مشارکت دارد.
- Girls Who Code: او به عنوان مشاور فناوری فعالیت می‌کند و در زمینه‌های معماری، حفاظت از داده‌ها، حاکمیت پلتفرم و سیاست‌های فناوری راهنمایی‌های لازم را ارائه می‌دهد.
چارچوب «خوش‌بینی بدبینانه»
گوبین رویکرد خود را «خوش‌بینی بدبینانه» می‌نامد. این دیدگاه حاصل مشاهده نزدیک به دو دهه از موج‌های فناوری است، از جمله ظهور موبایل، ابری، DevOps، SRE و نسل‌های مختلف هوش مصنوعی. او معتقد است در حالی که تقریباً هر چیزی با تکنولوژی ممکن است، اما «شیطان در جزئیات است».
او استدلال می‌کند که درک واقعی یک فناوری تنها از طریق تحقیق و توسعه (R&D) و پروژه‌های واقعی به‌دست می‌آید؛ جایی که اتفاقات بد رخ می‌دهند و سیستم‌ها شکست می‌خورند. گوبین اثرات منفی تصمیمات اشتباه را از نزدیک دیده است؛ مواردی مانند محیط‌های ابری که هزینه‌هایشان غیرقابل تحمل می‌شود، مدل‌های هوش مصنوعی که طبق وعده‌ها عمل نمی‌کنند و اتوماسیون‌های بد پیاده‌سازی شده در چرخه‌های انتشار (Release Cycles). از نظر او، دانش در اعلان‌های تبلیغاتی یا هایپ‌های رسانه‌ای نیست، بلکه در الگوهایی است که از طریق همکاری با سایر معماران و تحلیلگران کشف می‌شود.
او برای تشخیص آمادگی یک مورد استفاده (Use Case) برای استقرار گسترده، از دو معیار کلیدی استفاده می‌کند:
- منحنی پذیرش (Adoption Curve): ردیابی اینکه آیا کاربران پس از فروکش کردن اثر «واو» (Wow Effect) اولیه، هفته‌ها بعد همچنان از ابزار استفاده می‌کنند یا خیر. این کار از مقیاس‌دهی به یک «جهش موقت» که ارزش بلندمدت ندارد، جلوگیری می‌کند. او تأکید می‌کند که باید همان افراد را در طول چندین هفته مشاهده کرد تا دید شود آیا همچنان از اتوماسیون یا مهارت AI که ایجاد کرده‌اند، رضایت دارند یا خیر.
- منحنی یادگیری (Learning Curve): اعتبارسنجی ابزار ابتدا توسط پیشگامان فنی (کنجک‌ترین و باهوش‌ترین‌ها)، سپس پذیرندگان اولیه (Early Adopters) و در نهایت اکثریت اولیه (Early Majority) پیش از گسترش به سایر بخش‌ها.
مدیریت هایپ مدل‌ها و «پراکندگی عامل‌ها»
زمانی که یک مدل بزرگ جدید منتشر می‌شود، فشار زیادی برای دادن دسترسی فوری به تمام کارکنان ایجاد می‌شود. گوبین معتقد است این یک اشتباه است. در مقیاس بزرگ، داشتن هزاران نفر که بدون راهنما آزمایش می‌کنند، می‌تواند منجر به اتلاف قابل توجه زمان و هزینه شود، به‌ویژه زمانی که نتیجه برای یک مورد استفاده خاص، چندان چشمگیر نباشد. او اشاره می‌کند که بدون راهنمایی، آزمایش‌ها اغلب به سمت نتایج مشخص جهت‌گیری نمی‌کنند و همین امر اندازه‌گیری تفاوت در عملکرد را غیرممکن می‌کند.
در عوض، او توصیه می‌کند که یک گروه محدود R&D مدل را در کنار تیم‌های حقوقی و امنیتی ارزیابی کند و سپس آن را به صورت گسترده‌تر عرضه نماید. این گروه یک ارزیابی جامع انجام داده و پیش از دسترسی عموم، راهنمایی‌های مربوط به امنیت و انطباق را ارائه می‌دهد. این یک اقدام یک‌باره نیست، بلکه یک طرز فکر مستمر است.
برای مدیریت این فرآیند، DataArt یک تیم ضربت (SWAT) چندوظیفه‌ای ایجاد کرد. این گروه شامل نمایندگانی از بخش‌های فناوری، حقوقی، انطباق و امنیت اطلاعات (InfoSec) است. عملیات آن‌ها با ویژگی‌های زیر شناخته می‌شود:
- اهداف پویا: مأموریت این گروه هر چهار تا پنج ماه یک‌بار تغییر می‌کند. اولویت‌ها بین ارتقای مهارت نیروی کار، قابلیت‌های ورود به بازار (Go-to-market)، مشارکت‌ها و فعال‌سازی AI در چرخه حیات توسعه هوش مصنوعی (ADLC) جابجا می‌شود.
- شفافیت بین‌بخشی: جلسات منظم تضمین می‌کند که حتی سوالات فنی محدود نیز به‌طور باز بحث شوند، زیرا این سوالات اغلب پیامدهایی برای کل سازمان دارند. این امر به تیم اجازه می‌دهد استراتژی خود را تغییر داده و فرضیات را به‌طور مداوم اعتبارسنجی کند.
- کاهش ریسک: تیم اطمینان حاصل می‌کند که هیچ ابزار AI در انزوا ارزیابی نشود؛ تیم‌های امنیتی و حقوقی باید ابتدا تعیین کنند که ابزار چگونه با داده‌های شرکت یا مشتری برخورد می‌کند، چه محدودیت‌هایی اعمال می‌شود و آیا می‌توان آن را به‌طور ایمن در مقیاس بزرگ استفاده کرد یا خیر.
بدون این حاکمیت، گوبین هشدار می‌دهد که پدیده «پراکندگی عامل‌ها» (Agent Sprawl) رخ می‌دهد. این وضعیت زمانی اتفاق می‌افتد که به توسعه‌دهندگان به‌صورت انفرادی لایسنس‌های AI داده شود بدون اینکه راهنمایی دریافت کنند و در نتیجه، عامل‌های تکراری برای وظایفی یکسان بسازند. این امر منجر به نتایج زیر می‌شود:
- تیم‌های با عملکرد پایین و عدم تحقق انتظارات.
- افت کیفیت نرم‌افزار.
- افزایش هزینه‌های استنتاج (Inference).
برای کاهش این ریسک، گوبین یک تلاش هماهنگ را پیشنهاد می‌کند. در سطح پروژه، تیم‌ها باید بر سر یک پایگاه دانش مشترک، زمینه (Context) و موارد استفاده خاص توافق کنند. این تلاش‌ها سپس باید توسط یک هیئت معماری سازمانی، CTO یا یک تیم اختصاصی پذیرش AI سازماندهی شوند تا اطمینان حاصل شود که بهترین تجربیات (Best Practices) انباشته می‌شوند، نه اینکه هر بار از نو اختراع شوند.
اقتصاد FinOps در هوش مصنوعی
مدیریت هزینه در هوش مصنوعی اغلب در طول مراحل آزمایشی نادیده گرفته می‌شود اما در مقیاس بزرگ حیاتی می‌شود. گوبین پیشنهاد می‌کند که یک مسیر ایده‌آل هزینه AI باید ابتدا صعود کند، سپس به یک سطح ثابت (Plateau) برسد و در نهایت در طول زمان کمی کاهش یابد. این الگو نشان می‌دهد که هزینه‌ها قابل پیش‌بینی و پایدار هستند.
در مقابل، هزینه‌هایی که به‌شدت نوسان می‌کنند نشان‌دهنده بی‌ثباتی هستند، در حالی که هزینه‌هایی که صعود کرده و سپس کاملاً سقوط می‌کنند، ممکن است نشان‌دهنده شکست در پذیرش یا تغییر کاربران به ابزارهای دیگر باشد. او از «AI FinOps» دفاع می‌کند؛ دیسیپلینی که در آن رهبران محصول و کسب‌وکار دقیقاً تعریف می‌کنند که چه چیزی اندازه‌گیری می‌شود.
AI FinOps شامل تصمیمات فنی و استراتژیک است:
- بهینه‌سازی فنی: انتخاب مدل‌های ترجیحی بر اساس نوع وظیفه، تا سازمان همیشه به گران‌ترین مدل‌های سطح بالا متکی نباشد. این تصمیمات کوچک و تکه‌تکه منجر به صرفه‌جویی‌های قابل توجهی می‌شود.
- همسویی با کسب‌وکار: ادغام رهبران محصول در گفتگوهای مربوط به هزینه برای تعیین بازگشت واقعی سرمایه نسبت به هزینه کرد. گوبین FinOps را متدولوژی‌ای می‌بیند که مستلزم آن است که رهبران تجاری، ارزش تلاش‌های AI را تعریف کنند.
اندازه‌گیری ROI واقعی
بسیاری از شرکت‌ها فاقد یک خط مبنا (Baseline) برای بهره‌وری هستند و همین امر محاسبات ROI را غیرممکن می‌کند. گوبین تأکید می‌کند که ایجاد یک خط مبنا، فارغ از اینکه شرکت در حال حاضر از عامل‌ها استفاده می‌کند یا تازه سفر خود را آغاز کرده، یک «الزام» (Must-have) است.
او پیشنهاد می‌کند از «معیارهای مصنوعی» مانند تعداد کامیت‌های کد یا Story Pointها فاصله بگیرید، زیرا این‌ها فقط نشان می‌دهند که کاری انجام شده است، نه اینکه ارزشی خلق شده باشد. در عوض، او توصیه می‌کند بر معیارهای DORA و سایر اندازه‌های عینی تمرکز کنید:
- زمان تحویل (Lead Time): سرعت حرکت یک ویژگی از ایده تا محیط تولید.
- میانگین زمان بازیابی (MTTR): سرعت تیم در رفع یک باگ تولید یا بازیابی از یک شکست.
- قابلیت اطمینان تخمین‌ها (Estimate Reliability): آیا پذیرش AI باعث می‌شود زمان‌بندی پروژه‌ها پیش‌بینی‌پذیرتر و پایدارتر شود؟ یک تخمین قابل اعتماد، شاخص کلیدی بهره‌وری واقعی است.
- واحد کار (Unit of Work): برای جریان‌های کاری غیرتوسعه‌ای (مانند پردازش ادعاها یا بررسی مدارک)، اندازه‌گیری زمان و هزینه برای رسیدن به «تعریفِ پایان» (Definition of Done) قبل و بعد از پیاده‌سازی AI.
آینده مهندس انسانی
همان‌طور که DataArt از طریق مدل عملیاتی Artisyn (عرضه شده در ۲۰۲۶) هوش مصنوعی را در چرخه تحویل نرم‌افزار ادغام می‌کند، نقش توسعه‌دهنده انسانی در حال تغییر است. گوبین استدلال می‌کند که توانایی تایپ سریع کد در حال کاهش ارزش است.
آنچه در حال افزایش ارزش است، «هنرمندی» (Artisanship) است: توانایی تعریف اینکه «خوب» بودن به چه معناست، درک الگوهای معماری و تعیین محدودیت‌ها برای عامل‌های AI. این تخصص انسانی برای موارد زیر حیاتی است:
- هدایت عامل‌ها: تعیین قوانین و بررسی نتایج برای تضمین کیفیت. بدون این کار، توسعه‌دهندگان ممکن است حتی ندانند چه چیزی در حال توسعه است.
- مقیاس‌پذیری: دانستن اینکه کدام معماری برای یک صنعت یا برنامه خاص مناسب است و چگونه با مقیاس شدن راهکار، پایداری خود را حفظ می‌کند. گوبین اشاره می‌کند که یک معماری واحد ممکن است در تمام طول عمر یک پلتفرم کار نکرد.
- زمینه صنعتی: به کارگیری سلیقه و تجربه متناسب با نیازهای خاص یک مشتری و صنعت او.
او اشاره می‌کند که توسعه‌دهندگان ارشد اکنون می‌توانند بسیار سریع‌تر بین زبان‌ها (مثلاً از .NET به Java) جابجا شوند، زیرا دانش معماری هسته — درک SDLC و ADLC — است که بیشترین اهمیت را دارد. توانایی بازآموزی در مقیاس بزرگ، که یک دهه پیش تقریباً غیرممکن بود، اکنون به دلیل اینکه AI دانش مربوط به کتابخانه‌ها یا زبان‌های خاص را مدیریت می‌کند، به یک واقعیت تبدیل شده است.
مسئولیت‌پذیری در عصر عامل‌محور
با حرکت سازمان‌ها به سمت سیستم‌های تولیدی که در آن عامل‌های AI به‌طور مستقل اقدام می‌کنند، مسئله مسئولیت‌پذیری (Accountability) اهمیت حیاتی می‌یابد. گوبین ایده مقصر دانستن AI یا ارائه‌دهنده مدل برای اشتباهات را رد می‌کند. او مدل «همکاری بدون سرزنش» و مسئولیت مشترک را پیشنهاد می‌کند، اما با تعاریف دقیق:
- توسعه‌دهندگان مسئول کدی هستند که به عنوان Pull Request ارسال می‌کنند؛ آن‌ها باید منطق کد را درک کنند، فارغ از اینکه چگونه تولید شده است.
- معماران مسئول تصمیمات معماری و محدودیت‌های ارائه شده به عامل‌ها هستند.
- تیم‌های پلتفرم مسئول قابلیت اطمینان کلی راهکار هستند، صرف‌نظر از اینکه چه کسی یا چه چیزی یک خط کد خاص را ایجاد کرده است.
- تیم‌های حاکمیتی مسئول تصمیمات مربوط به بودجه، زمان‌بندی و انتشار هستند.
به گفته گوبین، اگر شکستی به محیط تولید برسد، خطا در «فرآیند» است — مانند فقدان تست‌های واحد (Unit Tests) یا شکست در نظارت — و نه در خودِ هوش مصنوعی. شما نمی‌توانید مسئولیت باگی که باید توسط کنترل‌های انسانی شناسایی می‌شد را به یک ارائه‌دهنده ابری یا یک مدل واگذار کنید. سوال حیاتی این نیست که «AI این کار را کرد»، بلکه این است که «چه کنترل‌هایی اجازه دادند این شکست به محیط تولید برسد».
گام بعدی شما
- برای هر ابزار AI در سازمان، یک «منحنی پذیرش» ۳ هفته‌ای تعریف کنید تا متوجه شوید چه چیزی واقعاً کاربردی است و چه چیزی فقط یک هیجان زودگذر است.
- یک تیم ضربت کوچک (فنی + حقوقی + امنیتی) تشکیل دهید تا پیش از دسترسی عمومی، مدل‌های جدید را از نظر حریم خصوصی داده‌ها بررسی کنند.
- معیارهای بهره‌وری خود را از «تعداد خروجی» به «زمان تحویل» (Lead Time) تغییر دهید تا اثر واقعی AI بر زنجیره ارزش را بسنجید.
اما مدیریت هزینه‌های استنتاج در مقیاس میلیونی، چالش پیچیده‌تری است — به تحلیل ما درباره‌ی استراتژی‌های کاهش هزینه GPU مراجعه کنید.
گفتگو