سقف هزینه عامل جدید گوگل؛ کدام خرج واقعاً متوقف می‌شود؟

خبر ۸ اکتبر؛ سقف هزینه به عامل کاری می‌رسد

گوگل در ۸ اکتبر ۲۰۲۶، برابر با ۱۶ مهر، در رویداد Gemini at Work عامل کاری جدید خود را معرفی کرد. اطلاعیه کوتاه همان روز، اتصال کارهای سازمانی، انتخاب مدل و کنترل هزینه را کنار هم قرار می‌دهد. موضوع این شماره، سقف هزینه عامل هوش مصنوعی است؛ نه ارزیابی کیفیت همه قابلیت‌های معرفی‌شده یا تکرار آمار تبلیغاتی مشتریان. ^[۱]

در متن تفصیلی، گوگل می‌گوید می‌توان برای هزینه هوش مصنوعیِ پروژه در Cloud Billing حد تعیین کرد؛ مصرف توکن و هزینه محیط اجرای ایزوله پایش می‌شود و با فعال‌شدن سقف، عامل آن پروژه مکث می‌کند. ادامه کار نیز از کنسول ممکن است. این توصیف عرضه‌کننده از قابلیت تازه است، نه نتیجه آزمون مستقل ژرف‌بان. ^[۲]

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

سه چیز را یکی نگیرید: بودجه، هشدار و توقف

راهنمای رسمی بودجه‌های گوگل صریح است: بودجه از نوع «فقط هشدار» به‌طور خودکار مصرف یا هزینه Google Cloud و Google Maps را محدود نمی‌کند. دریافت ایمیل عبور از آستانه، سند توقف خدمت نیست. همان راهنما، کنترل مصرف خدمات واجد شرایط را به نوع جداگانه بودجه دارای سقف مصرف ارجاع می‌دهد. ^[۳]

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

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

مستندات فنی چه مرزی برای سقف می‌گذارند؟

در مستند عمومی Spend Cap، دامنه یک پروژه، یک خدمت واجد شرایط و دوره ماهانه است؛ هزینه اشتراک خارج از آن قرار دارد. مبنای اصلی تحریک، عبور هزینه ناخالصِ برآوردی از ۱۰۰ درصد بودجه، بدون تخفیف و اعتبار است. اجرا آنی نیست و اضافه‌مصرف صورتحساب می‌شود. درخواست در حال اجرا و هزینه ثابت منابع ماندگار می‌توانند ادامه یابند. ^[۴]

این سند درباره خدمات مشمول Cloud Billing است؛ آن را بی‌بررسی به تمام اجزای عامل تازه یا هر اشتراک Gemini تعمیم نمی‌دهیم. تطبیق دقیق خبر با بسته خریداری‌شده هنوز پرسش اجرایی مهم است. در ارزیابی ژرف‌بان، نه می‌توان از عبارت تبلیغاتیِ سقف، تضمین ریاضی صفرشدن اضافه‌خرج ساخت، نه از وجود استثنا نتیجه گرفت این کنترل بی‌فایده است. فایده آن باید برای همان دامنه و همان عملیات سنجیده شود.

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

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

دکمه ادامه کار، یک اختیار مالی است

مستند Spend Cap نکته تعیین‌کننده دیگری دارد: با برداشتن دستی سقف، همان کنترل در باقی دوره دوباره فعال نمی‌شود، مگر مبلغ بودجه افزایش یابد؛ در آغاز دوره بعد بازنشانی می‌شود. بنابراین برداشتن محدودیت را نباید با رفع موقت یک خطای فنی اشتباه گرفت. این رفتار مربوط به سازوکار مستندشده است و باید در پیکربندی خریداری‌شده نیز بررسی شود. ^[۴]

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

راهنمای OWASP درباره اختیار بیش‌ازحد عامل، محدودکردن ابزار و مجوز، تأیید انسانی اقدامات پراثر و اجرای کنترل دسترسی در سامانه مقصد را توصیه می‌کند؛ تشخیص مجازبودن نباید فقط به مدل واگذار شود. این سند فنیِ زمینه‌ای نسخه ۲۰۲۵ است، نه خبر امروز یا مقرره ایرانی. در کاربرد مالی، سقف خرج هم جای تأیید پرداخت یا مجوز تغییر سند را نمی‌گیرد. ^[۵]

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

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

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

چارچوب مدیریت ریسک هوش مصنوعی NIST که نخستین نسخه آن در ۲۶ ژانویه ۲۰۲۳ منتشر شد، داوطلبانه است و مدیریت ریسک را در طراحی، توسعه، استفاده و ارزیابی دنبال می‌کند. این منبع، شاهد عملکرد محصول تازه نیست؛ مبنایی برای جداکردن ادعای عرضه‌کننده از ارزیابی سازمانی است. نتیجه آزمون را با دامنه و محدودیتش نگه دارید، نه با برچسب کلی «هوش مصنوعی تأیید شد». ^[۶]

اکنون چه بخواهیم و چه چیزی را رصد کنیم؟

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

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

مبنای خبر دو اطلاعیه ۸ اکتبر گوگل در پنجره ۲۴ ساعته منتهی به صبح ۱۷ مهر است؛ این دو تأیید مستقل از یکدیگر نیستند. راهنماهای زنده صورتحساب و اسناد OWASP و NIST برای سنجش حدود ادعا خوانده شده‌اند، نه به‌عنوان رویداد تازه. ما کاهش هزینه، کیفیت خروجی یا مناسب‌بودن این محصول برای شرکت مشخصی را اندازه‌گیری نکرده‌ایم؛ تصمیم باید به شواهد همان محیط وابسته بماند.