مقدمه: اشتراک ماهانه دیگر تمام هزینه هوش مصنوعی نیست
مدیر مالی می‌پرسد: «چرا هزینه ابزار هوش مصنوعی این ماه بالا رفت؟» پاسخ واحد فناوری این است که تعداد کاربران تغییر نکرده است. بااین‌حال صورتحساب افزایش یافته؛ زیرا سامانه پشتیبانی مشتریان درخواست‌های بیشتری پردازش کرده، مدل گران‌تری فعال شده یا خروجی هر درخواست طولانی‌تر بوده است. در این وضعیت، شمار کاربران یا تعداد اشتراک‌ها به‌تنهایی علت افزایش هزینه را توضیح نمی‌دهد.
برای شرکت‌هایی که از API مدل‌های هوش مصنوعی، ابزارهای اشتراکی و عامل‌های خودکار استفاده می‌کنند، مدیریت هزینه باید از «فهرست اشتراک‌ها» به «ردیابی مصرف و بهای تمام‌شده خدمت» برسد. یک تراکنش ممکن است به چند فراخوانی مدل، استفاده از ابزار جانبی و اجرای مجدد نیاز داشته باشد؛ در مقابل، دو تیم با تعداد کاربران برابر می‌توانند هزینه‌های بسیار متفاوتی ایجاد کنند.
این مسئله فقط فنی نیست. وقتی مصرف به پروژه و مرکز هزینه متصل نباشد، بودجه‌ریزی، تخصیص هزینه، تشخیص انحراف و ارزیابی بهره‌وری نیز مبهم می‌شوند. راهکار، ثبت داده قابل تطبیق و کنترل انسانی است؛ نه سپردن تصمیم نهایی بودجه یا ثبت حسابداری به یک عامل هوشمند.
چرا اکنون این موضوع مطرح شده است؟
در ۱۲ اکتبر ۲۰۲۶، شرکت Freshworks توافق قطعی خود برای خرید Torii را اعلام کرد. در توضیح رسمی، یکی از مسائل اصلی، دشواری نظارت بر هزینه نرم‌افزارهای SaaS و ابزارهای هوش مصنوعی با قیمت‌گذاری مبتنی بر مصرف عنوان شد. طبق اعلام شرکت، Torii قابلیت ردیابی مصرف تا سطح توکن، انتساب به افراد و تیم‌ها و پیش‌بینی روند هزینه را هدف گرفته است. این خبر اعلام توافق خرید است، نه تکمیل معامله؛ نهایی‌شدن آن به شرایط معامله وابسته است.
این خبر به‌تنهایی اثبات نمی‌کند چنین قابلیتی در همه سازمان‌ها بدون خطا کار می‌کند. ارزش حرفه‌ای آن طرح یک پرسش است: اگر مصرف هوش مصنوعی به‌اندازه انرژی، مواد یا خدمات ابری به فعالیت واقعی وابسته شده، چرا واحد مالی نباید هزینه آن را در سطح پروژه و خروجی کنترل کند؟
سه عددی که نباید با هم اشتباه شوند
هزینه مصرف‌شده برآورد بهای خدمات استفاده‌شده در یک دوره بر اساس داده معتبر مصرف و تعرفه قرارداد است؛ مبلغ صورتحساب مطالبه فروشنده پس از اعمال اعتبار، مالیات یا تعدیلات است؛ مبلغ پرداخت‌شده وجهی است که از بانک خارج می‌شود و ممکن است به پیش‌پرداخت یا تسویه بدهی پیشین نیز مربوط باشد.
داشبورد مناسب این سه را جدا می‌کند. خرید اعتبار پیش‌پرداخت‌شده به‌خودی‌خود به معنای مصرف کامل خدمت نیست؛ کاهش مانده کیف پول نیز الزاماً برابر هزینه همان دوره نیست. شناسایی حسابداری مطابق قرارداد و استاندارد قابل اعمال انجام می‌شود و نباید مستقیماً از گزارش توکن نتیجه‌گیری شود.
داده لازم برای محاسبه هزینه واقعی AI
برای هر رویداد مصرف، تا جایی که ارائه‌دهنده و قرارداد اجازه می‌دهد، شناسه یکتا، تاریخ و منطقه زمانی، شناسه پروژه، مرکز هزینه، نام و نسخه مدل، نوع عملیات، تعداد توکن ورودی عادی، ورودی کش‌شده و خروجی، تعرفه معتبر همان زمان، ارز، حساب سرویس، وضعیت درخواست و پیوند آن با فعالیت کسب‌وکار ثبت شود.
ثبت متن محرمانه پرامپت برای محاسبه هزینه ضروری نیست. می‌توان شناسه، شمارنده مصرف و حداقل فراداده موردنیاز را نگه داشت؛ دسترسی به داده‌های کارکنان، مشتریان و درخواست‌ها نیز باید با سیاست محرمانگی تنظیم شود.
توکن در همه خدمات تنها واحد هزینه نیست. فراخوانی ابزار، جست‌وجو، پردازش تصویر و صدا، ذخیره‌سازی، حداقل تعهد قراردادی یا مجوز کاربر ممکن است جداگانه قیمت‌گذاری شوند. موتور محاسبه باید فهرست تعرفه، واحد سنجش و بازه اعتبار هر قلم را نسخه‌دار نگه دارد؛ یک نرخ ثابت برای همه مدل‌ها کافی نیست.
مثال عددی: سه مرکز هزینه را از مصرف به بهای خدمت برسانیم
شرکتی فرضی از یک سرویس هوش مصنوعی در واحدهای مالی، فروش و پشتیبانی استفاده می‌کند. تعرفه‌ها در این مثال کاملاً آموزشی‌اند: یک میلیون توکن ورودی عادی ۲ دلار، ورودی کش‌شده ۰٫۲ دلار و خروجی ۸ دلار. این قیمت‌ها تعرفه واقعی هیچ مدل مشخصی نیستند و مثال هزینه جانبی دیگری ندارد.
واحد مالی با ۶ میلیون توکن ورودی عادی، ۲ میلیون کش‌شده و ۱ میلیون خروجی، هزینه متغیر ۲۰٫۴ دلار دارد. هزینه فروش با مقادیر ۴، ۱ و ۲ میلیون به ۲۴٫۲ دلار می‌رسد؛ پشتیبانی با ۸، ۳ و ۴ میلیون، ۴۸٫۶ دلار هزینه دارد. جمع هزینه متغیر سه واحد ۹۳٫۲ دلار است.
فرمول این محاسبه عبارت است از: تعداد میلیون توکن ورودی عادی × ۲، به‌علاوه تعداد میلیون توکن کش‌شده × ۰٫۲، به‌علاوه تعداد میلیون توکن خروجی × ۸. برای واحد مالی داریم: ۶×۲ + ۲×۰٫۲ + ۱×۸ = ۲۰٫۴ دلار؛ مجموع همه واحدها ۹۳٫۲ دلار می‌شود.
حال فرض کنید هزینه ثابت زیرساخت مشترک در ماه ۶۰ دلار است و طبق سیاست مصوب، بر اساس تعداد حساب‌های فعال تخصیص می‌یابد: مالی دو حساب، فروش یک حساب و پشتیبانی سه حساب دارد. سهم هزینه ثابت به‌ترتیب ۲۰، ۱۰ و ۳۰ دلار و جمع هزینه مدیریتی سه واحد ۴۰٫۴، ۳۴٫۲ و ۷۸٫۶ دلار خواهد بود؛ در مجموع ۱۵۳٫۲ دلار.
مبنای تعداد حساب‌های فعال فقط یک سیاست فرضی است. در سازمان دیگری ممکن است زمان استفاده، تعداد کاربران مجاز، مصرف قابل انتساب مستقیم یا مبنای علّی دیگری مناسب‌تر باشد. روش تخصیص باید مستند، پایدار و قابل بازبینی باشد؛ تغییر سلیقه‌ای آن برای مطلوب‌نمایی سود واحدها کنترل مدیریتی نیست.
بهای تمام‌شده هر خروجی؛ نه صرفاً تعداد توکن
فرض کنید واحد مالی ۲۰۰ سند را پس از کنترل انسانی تکمیل کرده، فروش ۳۰۰ پیشنهاد قیمت تأییدشده ساخته و پشتیبانی ۱۲۰۰ درخواست مشتری را به نتیجه قابل قبول رسانده است. هزینه مدیریتی هر خروجی به‌ترتیب ۰٫۲۰۲ دلار برای سند مالی، ۰٫۱۱۴ دلار برای پیشنهاد قیمت و ۰٫۰۶۵۵ دلار برای درخواست پشتیبانی خواهد بود.
ماهیت این خروجی‌ها متفاوت است و ارقام آنها نباید برای رتبه‌بندی مستقیم بهره‌وری واحدها استفاده شوند. مقایسه معنادار روند هزینه هر خروجی پذیرفته‌شده در همان فرایند، همراه با نرخ خطا، زمان انجام کار و بار بازبینی انسانی است. خروجی ظاهراً ارزان اما نیازمند اصلاح گسترده ممکن است گران‌تر تمام شود.
اگر برای انجام یک کار مالی سه بار مدل فراخوانی شود اما فقط خروجی آخر پذیرفته شود، هزینه هر سه تلاش باید به همان کار منتسب شود. تقسیم کل هزینه صرفاً بر تعداد پاسخ‌های تولیدشده، در حالی که پاسخ‌های ردشده یا تکراری حذف شده‌اند، بهای واقعی خدمت قابل قبول را کمتر از واقع نشان می‌دهد.
از صورتحساب فروشنده تا دفتر هزینه؛ تطبیق قابل دفاع
مجموع هزینه محاسبه‌شده از رخدادهای مصرف باید با گزارش مصرف و صورتحساب تأمین‌کننده تطبیق داده شود. تفاوت ممکن است از گردکردن، تأخیر ثبت رویداد، منطقه زمانی، اعتبار قراردادی، مالیات، نرخ تبدیل ارز یا اقلامی ناشی شود که در داده خام API دیده نمی‌شوند.
هر مغایرت پرونده‌ای با شناسه، علت، مبلغ، مسئول رسیدگی و وضعیت اصلاح داشته باشد. اگر تعداد رویدادها ناقص است، نباید اختلاف را با یک سند دستی بی‌ردپا صفر کرد. اطلاعات پرداخت بانکی و پیش‌پرداخت نیز جدا از هزینه مدیریتی نگهداری شود تا گزارش مالی با گزارش مصرف اشتباه نشود.
هشدار بودجه باید به تصمیم قابل اقدام منجر شود
بودجه را فقط در سطح سازمان تعریف نکنید. برای هر پروژه، واحد، مدل و بازه زمانی، سقف مصرف، سطح هشدار و مسئول پاسخ‌گویی مشخص باشد. هشدار خوب می‌گوید کدام عامل هزینه تغییر کرده است: افزایش تعداد درخواست، طول خروجی، افت کش، تغییر مدل یا تکرار فراخوانی‌ها.
پیش‌بینی روند مصرف باید با سناریوهای توضیح‌پذیر همراه باشد. برای مثال اگر مصرف روزانه هفته‌های اخیر تکرار شود، برآورد پایان ماه چه می‌شود؟ اگر حجم درخواست دو برابر شود یا تعرفه قرارداد تغییر کند چه میزان حاشیه بودجه باقی می‌ماند؟ هیچ پیش‌بینی‌ای بدون بیان فرض‌ها قطعیت ایجاد نمی‌کند.
هشدار به معنی اجازه قطع خودکار خدمت بااهمیت نیست. کاهش سطح مدل، توقف کارهای غیرفوری یا تغییر سقف مصرف ممکن است بر کیفیت خدمت مشتری و تعهدات قراردادی اثر بگذارد؛ تصمیم اجرایی باید با مالک فرایند، قواعد مصوب و مسیر تأیید انسانی همراه باشد.
چه کنترل‌هایی هزینه را قابل حسابرسی می‌کنند؟
کنترل نخست، جداسازی نقش‌هاست: توسعه‌دهنده مدل نباید به‌تنهایی تعرفه مالی، مبنای تخصیص و تأیید گزارش هزینه را تغییر دهد. کنترل دوم، ثبت نسخه تعرفه و قرارداد در لحظه مصرف است تا تحلیل‌های گذشته با تعرفه امروز بازنویسی نشوند.
کنترل سوم، جلوگیری از ثبت تکراری است. هر رویداد باید شناسه مستقل و وضعیت روشن داشته باشد؛ اجرای مجدد و خطا نیز طبق قرارداد ممکن است هزینه ایجاد کند، اما نباید یک رویداد واحد چند بار در دفتر مدیریتی منظور شود. کنترل چهارم، آزمون کامل‌بودن با تطبیق دوره و آمار ارائه‌دهنده است.
کنترل پنجم، کیفیت اتصال فعالیت به پروژه و مرکز هزینه است. درخواست‌های فاقد برچسب باید در سرفصل «تخصیص‌نیافته» باقی بمانند تا تعیین تکلیف شوند، نه اینکه بدون دلیل میان واحدها سرشکن شوند. کنترل ششم، مستندسازی استثناها، تعدیل‌ها و تأیید نهایی مدیر مالی است.
پیاده‌سازی در شرکت: از آزمایش محدود تا ماژول مالی
در یک پایلوت چهارمرحله‌ای، ابتدا فقط دو سرویس AI و دو مرکز هزینه را انتخاب کنید؛ سپس رویدادهای مصرف و تعرفه‌های دوره را به‌صورت خواندنی جمع‌آوری کنید. در مرحله بعد موتور قواعد هزینه را محاسبه و با گزارش فروشنده تطبیق دهد و مغایرت‌ها به واحد مالی ارجاع شود.
در مرحله سوم هزینه هر خروجی پذیرفته‌شده و شاخص‌های کیفیت هر فرایند گزارش شود؛ در مرحله چهارم هشدار انحراف و مسئول بازبینی تعیین گردد. شاخص‌های مفید عبارت‌اند از درصد هزینه منتسب به پروژه، اختلاف صورتحساب با برآورد مصرف، درصد درخواست بدون برچسب، هزینه هر نتیجه قابل قبول و زمان رسیدگی به هشدارها.
برای محیط‌های مالی در ایران، ثبت ارز اصلی مصرف و روش تسعیر، تاریخ شمسی در کنار زمان استاندارد رویداد، تفکیک ریال و تومان، قراردادهای واسط، محدودیت دسترسی به API و مغایرت مانده اعتبارات پیش‌پرداخت‌شده اهمیت دارد. نرخ تسعیر یا شیوه ثبت حسابداری نباید از یک مقدار فرضی در موتور AI برداشت شود.
فرصت محصولی برای حسابداران برتر
یک ایده توسعه نرم‌افزاری، ماژول «کنترل مصرف و بهای تمام‌شده هوش مصنوعی» است که رخداد مصرف، تعرفه نسخه‌دار، مرکز هزینه، بودجه، کیفیت خروجی و پرونده تطبیق صورتحساب را به هم متصل کند. چنین ماژولی می‌تواند به اتوماسیون مالی و گزارش بودجه متصل شود، بی‌آنکه هوش مصنوعی اجازه تغییر مستقیم سند نهایی را داشته باشد.
این پیشنهاد به معنی وجود فعلی محصول در حسابداران برتر نیست. پیش از توسعه باید با داده مجاز واقعی، دقت انتساب هزینه، هزینه اتصال ارائه‌دهندگان مختلف، کیفیت گزارش مغایرت و ارزش عملی هشدارها آزمون شود. نتیجه مطلوب، شفافیت و تصمیم مالی بهتر است؛ نه صرفاً داشبوردی پر از عدد توکن.
جمع‌بندی: از شمارش توکن تا تصمیم مالی قابل دفاع
افزایش هزینه هوش مصنوعی همیشه به افزایش کاربران مربوط نیست. تعداد درخواست‌ها، نوع مدل، توکن‌های ورودی و خروجی، استفاده از کش، ابزارهای جانبی و تکرار عملیات همگی می‌توانند هزینه را تغییر دهند؛ بنابراین مدیریت مالی باید مصرف را در سطح فعالیت و قرارداد ببیند.
گزارش قابل دفاع نشان می‌دهد هر رویداد از کجا آمده، با چه تعرفه‌ای محاسبه شده، به کدام مرکز هزینه و خروجی پذیرفته‌شده مربوط است و چه کسی مغایرت آن را بررسی کرده است. موتور هوشمند می‌تواند کشف و توضیح کند، اما تأیید هزینه و تصمیم بودجه‌ای با مسئول مالی و کنترل‌های مصوب می‌ماند.
