وابستگی کسب و کارها به شرکت های هوش مصنوعی خطرآفرین است

وقتی تکیه به غول های هوش مصنوعی، کسب وکارها را شکننده می کند

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

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

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

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

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

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

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

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

چرا هوش مصنوعی با نرم افزارهای معمولی فرق دارد؟

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

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

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

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

ریسک فقط از کار افتادن سرویس نیست

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

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

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

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

قفل شدن در اکوسیستم یک فروشنده

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

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

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

تنوع تأمین کننده به تنهایی کافی نیست

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

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

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

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

برنامه خروج باید قبل از بحران آماده شود

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

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

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

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

نظارت روی خروجی، بخشی از تاب آوری است

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

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

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

مدیران باید چه سؤال هایی بپرسند؟

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

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

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

استفاده از هوش مصنوعی، اما بدون سپردن کلید شرکت

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

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

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

برای دریافت جدیدترین اخبار تکنولوژی با مجله هوش مصنوعی با ما همراه باشید