قراردادها و SLA در سرویس‌های AI

SLA چه چیزی را می‌سنجد و چه چیزی را نه؟

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

سه لایه را از هم جدا کنید:

• تعهد ارائه‌دهنده: آنچه در قرارداد برای سرویس مشخص، مثل دسترس‌پذیری یا پشتیبانی صریحاً نوشته شده است.
• هدف سطح خدمت محصول شما (SLO): هدف داخلی تیم برای تأخیر مسیر کامل، کیفیت خروجی، انجام کار، ارجاع انسانی و تحمل خطا در فرایند واقعی. SLO مخفف «هدف سطح خدمت» است؛ آن را وعدهٔ قراردادی ارائه‌دهنده معرفی نکنید، مگر همان تعهد دقیقاً در قرارداد آمده باشد.
• نتیجهٔ کسب‌وکار: تغییری که قرار است برای مشتری یا عملیات رخ دهد؛ مثلاً کاهش زمان رسیدگی بدون افزایش خطای پرهزینه.

از روی یک نمونهٔ رسمی، متن SLA را بخوانیم

صفحهٔ رسمی SLA سرویس Amazon Bedrock هنگام بررسی در ۶ اکتبر ۲۰۲۶، آخرین به‌روزرسانی را ۴ اکتبر ۲۰۲۳ نشان می‌دهد. در این نمونه، تعهد دسترس‌پذیری برای هر حساب AWS و هر منطقه، جداگانه و در دورهٔ ماهانه اعمال می‌شود. دسترس‌پذیری در بازه‌های پنج‌دقیقه‌ای محاسبه می‌شود و سند، خطا را درخواست API با پاسخ HTTP 500 تعریف می‌کند. اگر در یک بازه درخواستی ثبت نشده باشد، آن بازه ۱۰۰٪ در دسترس فرض می‌شود.

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

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

در مذاکره چه چیزهایی را دقیق کنید؟

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

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

تعهد ارائه‌دهنده را به هدف خدمت محصول پیوند دهید

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

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

• زمان از درخواست کاربر تا پاسخ قابل استفاده، نه فقط زمان پاسخ API مدل؛
• نسبت خروجی‌هایی که پس از ارزیابی انسانی یا معیار قطعی قابل استفاده‌اند؛
• نرخ ارجاع به انسان، retry، timeout و fallback؛
• پیامد خطا بر کاربر و هزینهٔ رسیدگی یا اصلاح؛
• رفتار در زمان تغییر مدل، بار، ورودی یا داده.

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

راهنمای Digital, Data and Technology Playbook دولت بریتانیا بر تناسب ریسک و پرداخت، نتیجه، رابطهٔ پایدار و تاب‌آور، مدیریت عملکرد قرارداد و برنامه‌ریزی زودهنگام برای پایان، گذار و خروج تأکید می‌کند. صفحه می‌گوید در ۲۰ ژوئن ۲۰۲۳ به‌روزرسانی شده است. دامنهٔ راهنما پروژه‌های دیجیتال، داده و فناوری بخش عمومی بریتانیاست؛ برای دولت مرکزی و نهادهای وابسته، قاعدهٔ «رعایت یا توضیح» دارد و بخش عمومی گسترده‌تر هم باید آن را در نظر بگیرد. این سند قانون یا دستورالعمل الزام‌آور همگانی برای شرکت‌های خصوصی یا کشورهای دیگر نیست.

پیشنهاد اجرایی حکیم این است که فقط روز عادی را برنامه‌ریزی نکنید. سناریوهای زیر را روی برگهٔ تعهد بیاورید:

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

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

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

اثر AI بر فرایند قراردادی

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

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

جمع‌بندی اجرایی

پیش از امضا، «برگهٔ تعهد سرویس» یک‌صفحه‌ای بسازید: دامنهٔ سرویس، سنجهٔ قراردادی، هدف‌های داخلی، استثناها، روش ثبت رخداد و پیگیری آن، مهلت اطلاع از تغییر، مسئول هر مرحله، راه جبران و مسیر خروج. آن را با مسئولان خرید، حقوقی، مهندسی و عملیات مرور کنید. پس از آغاز کار، سنجش ارائه‌دهنده را با تجربهٔ واقعی و نتیجهٔ کاربر مقایسه کنید؛ اگر این دو فاصله دارند، عدد دسترس‌پذیری را کل داستان محصول گزارش نکنید.

این مقاله توضیح عمومی محصول و عملیات است و جایگزین بررسی قرارداد توسط متخصص حقوقی حوزهٔ مربوط نیست.