فاتورة الذكاء الاصطناعي لا تُقاس بعدد الرموز وحده

تعرض لوحة المزود عدداً واضحاً من الرموز والطلبات، لكن السؤال الأهم يبقى بلا إجابة: كم كلّفت النتيجة المفيدة فعلاً؟ قد تبدو فاتورة النموذج منخفضة، بينما تستهلك عمليات الاسترجاع وإعادة المحاولة ومراجعة الموظفين وقتاً ومالاً لا يظهران في السعر المعلن.

أظهرت تغطية عربية نُشرت في 16 سبتمبر فجوة لافتة: 13% فقط من المشاركين في أدوار العمليات المالية السحابية يستطيعون ربط فواتير الذكاء الاصطناعي وتعلّم الآلة بمالكي الأعمال وإقرانها برؤى التحسين. هذه ليست مشكلة محاسبية صغيرة؛ إنها تعني أن المؤسسة قد توسّع خدمة لا تعرف هامشها الحقيقي.

بالنسبة إلى الشركات في الخليج، الحل ليس إيقاف التجارب ولا إنشاء لجنة جديدة لكل أداة. المطلوب هو تعريف «وحدة قيمة» مفهومة، وربط التكلفة بها، ثم منح الفرق ضوابط تسمح بالابتكار داخل حدود واضحة.

ابدأ من النتيجة لا من الرمز

عدد الرموز مقياس للاستهلاك، وليس مقياساً للنجاح. إذا أنتج المساعد عشرة ردود رخيصة واضطر الموظف إلى إعادة كتابتها، فقد ارتفعت الكلفة رغم انخفاض سعر الطلب. أما الرد الأغلى قليلاً الذي يُعتمد من المرة الأولى فقد يكون أفضل اقتصادياً.

عرّف الوحدة بحسب العمل نفسه: تكلفة تذكرة دعم أُغلقت ولم تُفتح مجدداً، أو مستند عولج بالدقة المطلوبة، أو فرصة بيع قبلها الفريق التجاري، أو تغيير برمجي اجتاز المراجعة والاختبارات، أو معاملة اكتملت دون تدخل يدوي غير مخطط.

يجب أن يتضمن التعريف شرط جودة. لا يكفي عدّ الحالات المغلقة؛ يلزم ربطها بالقبول أو الدقة أو رضا العميل أو عدم تكرار العمل. هكذا يصبح تحسين التكلفة تحسيناً للقيمة، لا سباقاً إلى أرخص نموذج.

الفاتورة الحقيقية موزعة على أكثر من نظام

تتكون تكلفة التطبيق الذكي من النموذج، وتخزين المتجهات، ونقل البيانات، ومحركات البحث، وواجهات الأدوات، والحماية، والتقييم، والمراقبة، وإعادة المحاولات، والبنية السحابية، ثم وقت الإنسان الذي يراجع النتيجة. وقد يحوّل طلب واحد من المستخدم إلى سلسلة طويلة من الاستدعاءات لا تظهر في واجهة المنتج.

تنصح إرشادات IBM العربية للعمليات المالية بمواءمة فرق المالية والتقنية والأعمال، وباستخدام التصنيف لتوزيع التكلفة على الجهة المسؤولة. عملياً، يجب أن يحمل كل طلب في الإنتاج معرّفات للمنتج والبيئة والفريق وحالة الاستخدام والنتيجة. وسجّل معه النموذج والرموز والأدوات وزمن التنفيذ وإعادة المحاولات وحالة المراجعة.

إذا تعذّر توزيع تكلفة خدمة مشتركة بدقة، استخدم قاعدة تقديرية مكتوبة وراجعها دورياً. الرقم التقريبي المنسوب إلى مالك أفضل من إجمالي دقيق لا يتحمل مسؤوليته أحد.

خمس أسئلة قبل توسيع أي حالة استخدام

1. ما وحدة القيمة؟ حدّد النتيجة التي سيدفع العميل أو العمل مقابلها، ولا تجعل «عدد المستخدمين» بديلاً تلقائياً عنها.

2. ما السقف لكل عملية؟ ضع حداً للتكلفة والزمن وعدد خطوات الوكيل. عند بلوغ السقف، يجب أن يتوقف المسار أو ينتقل إلى نموذج أصغر أو يطلب توضيحاً أو يحيل المهمة إلى موظف.

3. ما نسبة النتائج المقبولة؟ اربط التكلفة بالجودة. توصي مادة Microsoft Learn العربية بتقييم إجمالي تكلفة الملكية والعائد على الاستثمار عند قرار البناء أو الشراء أو التوسّع، وباستخدام توجيه النماذج لموازنة الأداء والكلفة.

4. من يملك الانحراف؟ يجب أن يصل تنبيه ارتفاع التكلفة إلى مالك منتج يستطيع تفسير تغير الاستخدام، لا إلى فريق المالية وحده بعد إغلاق الشهر.

5. ما الإجراء القابل للعكس؟ قبل أن تغيّر الأتمتة الموارد أو توقف خدمة، حدّد نطاق الصلاحية وحد الأثر المالي وخطة الرجوع وسجل التدقيق.

صمّم الخدمة بميزانية تشغيلية

يمكن خفض التكلفة دون إضعاف التجربة عبر توجيه الطلبات: نموذج خفيف للمهام المتكررة، ونموذج أقوى للحالات المعقدة فقط. اختصر السياق، واسترجع المقاطع ذات الصلة بدلاً من المستند الكامل، وخزّن النتائج المستقرة، واجمع الأعمال الخلفية في دفعات، وضع حداً للحلقات وإعادة المحاولة.

ينبغي أيضاً إطفاء الموارد التجريبية تلقائياً، وفصل ميزانية التطوير عن الإنتاج، ومنع استخدام المفاتيح المشتركة التي تخفي المالك. تشير مقالة IBM العربية عن التكاليف الخفية للذكاء الاصطناعي إلى أن الجدوى الاقتصادية قد تعطل التوسع حتى عندما تكون القدرة التقنية متاحة. لذلك يجب أن يدخل قرار الكلفة في التصميم منذ البداية.

لا تمنح أتمتة FinOps مفاتيح الإنتاج فوراً

ابدأ بمستوى القراءة: تطلب الأداة بيانات الفوترة وتشرح سبب الارتفاع مع روابط إلى الأدلة. بعد ذلك اسمح بتغيير بسيط قابل للرجوع بعد موافقة بشرية. ثم طبّق قواعد متكررة على موارد محددة، مثل إيقاف بيئات الاختبار خارج ساعات العمل. أما الاستقلالية المستمرة فتأتي أخيراً، داخل صلاحيات وحجم أثر معروفين.

يناسب هذا التدرج المؤسسات الصغيرة أيضاً. لا تحتاج إلى فريق FinOps مستقل كي تبدأ؛ يمكن لمالك المنتج ومهندس المنصة ومسؤول المالية عقد مراجعة أسبوعية مدتها نصف ساعة تتناول ثلاث نقاط: أكبر انحراف، وكلفة الوحدة، وتجربة التحسين التالية.

ما الذي ينبغي فعله هذا الأسبوع؟

• اختر حالة استخدام واحدة موجودة في الإنتاج وسمِّ مالكها.
• احسب التكلفة الكاملة لعينة من مئة عملية، بما فيها وقت المراجعة البشرية.
• عرّف وحدة قيمة مع شرط جودة واضح، وانشرها في لوحة يراها المنتج والهندسة والمالية.
• ضع سقفاً للطلب الواحد ولليوم، وتنبيهاً مبكراً قبل بلوغ الميزانية الشهرية.
• اختبر تغييراً واحداً—توجيه نموذج، أو سياقاً أقصر، أو تخزيناً مؤقتاً—وقارن الكلفة لكل نتيجة مقبولة.

زاوية قمرة تك

اقتصاديات الذكاء الاصطناعي ليست لوحة فوترة إضافية، بل عقد تشغيل بين المنتج والهندسة والمالية. عندما يعرف الفريق تكلفة النتيجة المقبولة، يستطيع اتخاذ قرارات أفضل حول النموذج والبنية والتسعير وحدود الأتمتة.

لا تنتظروا تضخم الفاتورة لبدء القياس. ضعوا وحدة القيمة والميزانية داخل تصميم الخدمة اليوم؛ فكل طلب لا يحمل مالكاً ونتيجة قابلة للقياس هو إنفاق يصعب الدفاع عنه غداً.