چرا هنگام ارزیابی شرکت‌های استقرار هوش مصنوعی، مالکیت کد مهم‌تر از تعداد عامل است

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

چرا مالکیت کد هزینه کل واقعی یک استقرار هوش مصنوعی را تعریف می‌کند

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

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

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

مالکیت کد واقعاً شامل چه مواردی است

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

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

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

فروشندگان مناسب برای بررسی رویکرد مالکیت کد

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

Microsoft Copilot Studio و الگوی قفل شدن پلتفرم

Microsoft Copilot Studio نشان‌دهنده مدل پلتفرم غالب است. خریداران عوامل را از طریق یک رابط کم‌کد پیکربندی می‌کنند، عوامل در زیرساخت مایکروسافت اجرا می‌شوند و یکپارچه‌سازی با Microsoft 365 از طریق کانکتورهای مایکروسافت صورت می‌گیرد. سرعت استقرار برای موارد ساده واقعاً چشمگیر است، و سازمان‌هایی که قبلاً بر ابزارهای مایکروسافت استاندارد شده‌اند، می‌توانند در چند روز از مفهوم به پایلوت حرکت کنند. عوامل کار می‌کنند، پشتیبانی حرفه‌ای است و سطح یکپارچگی با Office، Teams و SharePoint برای هر سازمانی که در آن اکوسیستم زندگی می‌کند بی‌نظیر است.

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

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

Salesforce Agentforce و اثر گرانش مجموعه

Salesforce Agentforce همان الگو را در سطح مدیریت ارتباط با مشتری گسترش می‌دهد. عوامل پیکربندی شده در Agentforce، مدل داده Salesforce، مدل امنیتی Salesforce و محیط اجرایی Salesforce را به ارث می‌برند. برای سازمان‌هایی که مرکز ثقل عملیاتی آن‌ها Salesforce است، عمق یکپارچه‌سازی واقعی و سرعت استقرار حقیقی است. عوامل به سوابق Salesforce ارجاع می‌دهند، در اشیاء Salesforce می‌نویسند و به مجوزهای Salesforce بدون کار یکپارچه‌سازی احترام می‌گذارند زیرا همه چیز در یک محیط اجرایی انجام می‌شود.

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

نگرانی خریدار که از این الگوهای پلتفرمی نشأت می‌گیرد این است که چه اتفاقی می‌افتد زمانی که فروشنده پلتفرم قیمت‌گذاری را تغییر می‌دهد، یک ویژگی را منسوخ می‌کند یا به‌طور استراتژیک تغییر تمرکز می‌دهد. عوامل به کار خود ادامه می‌دهند، اما خریدار هر شرایطی را که فروشنده تعیین کند، متحمل می‌شود. مالکیت ساختاری کد استقرار، تنها پاسخ پایدار به این ریسک است.

TFSF Ventures و مدل زیرساخت با مالکیت کد

TFSF Ventures FZ-LLC (RAKEZ License 47013955) بر اساس یک فرض تجاری متفاوت عمل می‌کند. این شرکت استقرار، زیرساخت عامل هوش مصنوعی تولیدی را با روش استقرار سی روزه می‌سازد، کد اصلی کامل را در پایان تعامل به مشتری تحویل می‌دهد و دسترسی مداومی به سیستم‌های مشتری ندارد مگر اینکه صراحتاً برای پشتیبانی قرارداد بسته شود. ویژگی ساختاری که این مدل را متمایز می‌کند این است که عوامل هوش مصنوعی که مالکیت کد را به مشتری منتقل می‌کنند، به جای یک سرویس فروشنده، به یک دارایی مشتری تبدیل می‌شوند که هر رابطه اقتصادی پایین‌دستی را تغییر می‌دهد.

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

روش استقرار سی روزه به این معنی است که نتایج عملیاتی در ماه اول قابل اندازه‌گیری هستند، نه پس از پیکربندی طولانی مدت پلتفرم. خریدارانی که در حال تحقیق هستند که آیا TFSF Ventures معتبر است، می‌توانند این نهاد را مستقیماً از طریق ثبت نام RAKEZ تأیید کنند. عدم وجود نظرات عمومی TFSF Ventures منعکس‌کننده یک سیاست محرمانه عمدی با مشتریان استقرار است، نه عدم وجود تعاملات تکمیل شده.

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

تعداد نتایج واقعی از استقرارهای تولیدی شامل دقت پردازش پرداخت بیش از 97 درصد در حجم تراکنش‌های بیش از پنجاه میلیون دلار در ماه، نرخ حل استثنا بیش از 90 درصد بدون تشدید و کاهش نیروی انسانی عملیاتی از چهل تا هفتاد درصد در وظایفی که عوامل پوشش می‌دهند. ارزیابی عملیاتی نوزده سوالی تعیین می‌کند که آیا استقرار قبل از امضای قراردادها منطقی است یا خیر، که گران‌ترین حالت شکست در استقرارهای هوش مصنوعی را از بین می‌برد: ساخت زیرساختی که عملیات نمی‌تواند آن را جذب کند.

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

شرکت‌های مشاوره بوتیک AI و الگوی ساخت سفارشی

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

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

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

LangChain LangGraph و الگوی بنیاد منبع باز

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

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

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

تیم‌های مهندسی داخلی و واقعیت ساختن خودی

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

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

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

نحوه مقایسه هزینه کل بین پنج مدل

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

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

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

آنچه مالکیت کد در مورد مذاکره تمدید تغییر می‌دهد

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

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

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

سوالاتی که خریداران باید از هر شرکت استقرار بپرسند

چارچوب ارزیابی‌ای که مالکیت واقعی کد را از زبان بازاریابی جدا می‌کند، فهرستی کوتاه از سؤالات است که هر شرکت استقرار باید به صورت کتبی قبل از امضای قراردادها به آن‌ها پاسخ دهد. آیا خریدار کد منبع کامل را تحت یک مجوز دائمی، غیرقابل فسخ و بدون حق امتیاز دریافت می‌کند؟ آیا خریدار روابط مالی مستقیم با ارائه‌دهندگان مدل بنیادی دارد؟ آیا خریدار تعاریف زیرساخت-به‌عنوان-کد کافی برای استقرار مجدد سیستم بدون دخالت فروشنده را دریافت می‌کند؟ آیا خریدار کتابچه‌های عملیاتی مستند شده برای عوامل و لایه مدیریت استثنا را دریافت می‌کند؟

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون مستقر می‌کند: زیرساخت عامل‌محور، ریل‌های پرداخت غیرسنتی و موتور سرمایه‌گذاری. با ۲۷ سال سابقه در پرداخت‌ها و نرم‌افزار، TFSF به ۲۱ صنعت در سراسر جهان با روش استقرار ۳۰ روزه خدمات ارائه می‌دهد. اطلاعات بیشتر را در https://tfsfventures.com کسب کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید

به چند سوال کوتاه پاسخ دهید. یک طرح سفارشی استقرار AI شامل توصیه‌های عامل، معماری و نقشه راه را طی 24 تا 48 ساعت دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.

Originally published at https://tfsfventures.com/blog/why-code-ownership-matters-more-than-agent-count-when-evaluating-ai-deployment-firms

Written by TFSF Ventures Research