در انتخاب شریک هوش مصنوعی، فقط توان فنی را نبینید

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

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

پرسش هایی که معمولا دیر پرسیده می شوند

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

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

این سوال ها به اندازه دقت مدل اهمیت دارند. سامانه ای که در روز اول دقیق است، اما در روز حادثه پاسخ گویی مشخصی ندارد، انتخاب مطمئنی نیست.

شریک خوب قرار نیست شما را وابسته نگه دارد

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

من ترجیح می دهم تیم داخلی حداقل در سه نقطه مستقل باشد: بتواند کیفیت خروجی را خودش بسنجد، منطق دسترسی و کنترل را بفهمد و بداند در صورت تغییر تامین کننده چه چیزهایی باید جابه جا شود. لازم نیست همه اجزا را خودتان بسازید؛ لازم است مالک تصمیم باقی بمانید.

دامنه همکاری را پیش از قرارداد روشن کنید

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

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

قرارداد باید با زندگی واقعی هماهنگ باشد

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

خرید فناوری با خرید نتیجه متفاوت است

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

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

محدودیت های راه حل را پیش از امضا بشناسید

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

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

آزمایش روی داده و کار خودتان

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

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

شریک مناسب، دانش را در سازمان نگه می دارد

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

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

چند شریک یا یک شریک؟

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

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

قرارداد را با یک برنامه خروج کامل کنید

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

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

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

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