وكيل Gemini Spark للذكاء الاصطناعي يحتاج محفظة لا بطاقة
أعلنت Google عن Gemini Spark في 19 مايو 2026: مساعد ذكي يعمل على مدار الساعة طوال أيام الأسبوع، يقرأ بريدك الإلكتروني على Gmail، ويصيغ الردود، ويحجز المواعيد، ويواصل عمله حتى بعد أن تغلق الحاسوب. الفكرة الجوهرية هي مساعد يعمل باستقلالية دون توقف، يتولى الجزء الممل من صندوق الوارد بينما أنت نائم.
لكن في خضم عروض Gmail، ثمة مشكلة لم يشأ أحد على المنصة الإفصاح عنها بوضوح. في اللحظة التي يتصرف فيها الوكيل دون أن تكون جالساً أمامه، تنهار كل الافتراضات المدمجة في نظام بطاقات الدفع. لا إنسان يضغط "موافق". لا هاتف يستقبل رمز 3-D Secure. لا بطاقة حاضرة، ولا حامل بطاقة حاضر، ولا جلسة.
أعتقد أن هذه هي القصة الحقيقية لإطلاق Gemini 3.5، وهي لا علاقة لها تقريباً بالبريد الإلكتروني.
لماذا لا يستطيع المساعد الذكي الدائم استخدام بطاقتك
تفترض شبكات بطاقات الدفع وجود إنسان. المنظومة الكاملة لمكافحة الاحتيال، من CVV إلى 3-D Secure ورمز SMS إلى فحوصات التكرار، وُجدت لتأكيد أن إنساناً حقيقياً يقف وراء كل معاملة. Spark هو نقيض ذلك تماماً. إنه برنامج يعمل في سحابة Google يستيقظ في الثالثة صباحاً ليعيد حجز رحلة جوية ملغاة.
حين تُشغّل وكيلاً ذكياً مستقلاً على شبكات Visa، سرعان ما تصطدم بجدار:
- تُصنَّف المعاملات غير الحضورية القادمة من عنوان IP لمركز بيانات على أنها مشبوهة أو تُرفض.
- تصل تحديات 3-D Secure إلى إنسان نائم.
- تقع مسؤولية رد المدفوعات على عاتق التاجر في حالة شراء لم يأذن به أي إنسان.
- لا توجد طريقة واضحة لمنح الوكيل الذكي حداً إنفاقياً بقيمة 40 دولاراً يتجدد يومياً ولا يمكن استنزافه.
يرتكز تموضع Google AI Ultra على الاشتراكات المجمّعة تحديداً لأن المدفوعات لكل إجراء لا تزال مسألة غير محلولة. تدفع لـ Google رسوماً شهرية ثابتة، وتتحمل Google تكاليف الوكيل، ولا يضطر أحد لمعرفة كيف يدفع الوكيل لطرف خارجي. هذا يصلح حتى يحتاج الوكيل إلى شراء شيء خارج الحديقة المسوّرة لـ Google.
جانب الطلب أخيراً أصبح حاضراً
لمدة عامين، بنى مجتمع مدفوعات الوكلاء بنيةً تحتيةً لعميل لم يكن موجوداً. تناولتُ هذه الفجوة في مدفوعات وكلاء الذكاء الاصطناعي: Anvita وx402 ومن يملك المنصة، فالتقنية كانت جاهزة، لكن المنفقين المستقلين لم يكونوا كذلك.
يغيّر Spark المعادلة. على وشك أن تُطلق Google عشرات الملايين من الوكلاء الدائمي التشغيل الذين سيحتاجون، في نهاية المطاف، إلى إجراء معاملات. هذا هو الطلب الذي كانت البنية التحتية تنتظره.
المنظومة التقنية التي برزت مملّة بالطريقة الصحيحة:
- يُحيي x402 رمز حالة HTTP 402 "Payment Required" الخامل، ليتمكن الخادم من تحديد سعر ويدفعه الوكيل فورياً بالعملات المستقرة ضمن طلب واحد.
- أضاف AWS AgentCore مساراً للمدفوعات يتيح للوكلاء العاملين في سحابة Amazon تسوية المعاملات دون الحاجة إلى موافقة بشرية على كل رسوم.
- تُغلّف Pay.sh وأدوات مماثلة USDC-on-Base في شيء يمكن للوكيل استدعاؤه كأي واجهة برمجية أخرى.
القاسم المشترك: USDC على Base. إتمام رخيص، ورسوم أقل من سنت، وعملة مستقرة يمكن لخزينة الشركات الاحتفاظ بها فعلياً دون أن يضطر فريق الامتثال إلى رفع دعوى قضائية.
لماذا USDC على Base تحديداً
مدفوعات الوكلاء هي مدفوعات صغيرة. قد يدفع الوكيل 0.003 دولار للاستعلام عن واجهة برمجية للطقس، أو 2 دولار لشراء مجموعة بيانات. ستتجاوز رسوم الغاز على الشبكة الرئيسية لـ Ethereum قيمة الدفعة ذاتها. سجّلت Base تسوية تجاوزت مليار دولار يومياً في حجم تداول DEX خلال هذه الدورة، وتبلغ رسومها أجزاءً من السنت، وهو النظام الوحيد للرسوم الذي تصبح فيه المدفوعات الصغيرة بسرعة الآلة منطقية.
العملات المستقرة أهم من الشبكة. لا يستطيع الوكيل الاحتفاظ بأصل متذبذب؛ فتأرجح السعر بنسبة 4% بين تفويض الدفع وتسويته أمر غير مقبول. USDC مقوّم بالدولار، وقابل للاسترداد، وصادر عن جهة خاضعة للتنظيم. بعد أن أدرج تشريع GENIUS Act لمكافحة غسيل الأموال مُصدري العملات المستقرة ضمن نظام إشراف مماثل للبنوك، أصبح بمقدور المدير المالي الموافقة على الاحتفاظ بـ USDC بطريقة لم تكن ممكنة أبداً مع رمز غير مدعوم.
الوضوح التنظيمي هو المفتاح الحقيقي، لا سرعة المعالجة. لقد شهدت صفقات مؤسسية تتهاوى بسبب هذا السؤال تحديداً: "من المسؤول قانوناً، وهل الجهة المُصدِرة خاضعة للرقابة؟"
الجزء الصعب ليس المدفوعات. بل السلطة
منح الوكيل محفظة هو الجزء السهل، أي 20% من العمل. أما الـ80% الباقية فهي الحوكمة:
- حدود الإنفاق الصارمة. تحتاج محفظة الوكيل إلى سقف صارم مُطبَّق على السلسلة، لا حداً مرناً في كود التطبيق يمكن لهجوم حقن الأوامر تجاوزه.
- التفويض القابل للإلغاء. أنت تُفوِّض الوكيل لإعادة طلب البقالة، لا لتحريك مدخراتك. هذا التحديد يجب أن يكون تشفيرياً، لا مجرد خانة اختيار.
- قابلية التدقيق. يجب أن تكون كل مدفوعة ينفذها الوكيل قابلة للإسناد إلى سياسة وضعها إنسان. "قرر الذكاء الاصطناعي ذلك" ليست إجابة مقبولة لدى أي جهة تنظيمية.
هنا تتجلى خطورة هجمات حقن الأوامر بصورة حقيقية. لقد رأينا بالفعل ما يمكن أن يفعله مفتاح واحد مُسرَّب، راجع ثغرة Polymarket. والآن تخيَّل أن هذا المفتاح يوجد داخل وكيل يقرأ بريداً إلكترونياً غير موثوق طوال اليوم وبإمكانه إنفاق الأموال. سطح الهجوم هنا هو صندوق الوارد بأكمله.
ما أترقبه لاحقاً
لن تضع Google عملة USDC في Spark هذا العام. ستُوجِّه النسخة الأولى كل شيء عبر Google Pay وأنظمة الفوترة الخاصة بها، لأن ذلك قابل للتحكم، ولأن Google تُفضِّل امتلاك القضيب بدلاً من استئجاره.
لكن الوكيل الذي يحجز رحلتك في الثالثة صباحاً سيريد في نهاية المطاف الدفع لجهة لا تربط Google بها علاقة فوترة. حين يحدث ذلك، سيكون المسار الأرخص هو الدفع بالعملة المستقرة عبر بروتوكول مفتوح، لا تكاملاً مخصصاً مع كل تاجر على حدة. القضيب الفائز هو الذي يستطيع الوكيل استخدامه دون استئذان عملاق مدفوعات.
المحفظة قادمة للوكيل. السؤال الوحيد المفتوح هو: هل ستكون دفتراً مغلقاً داخل Google أم دفتراً مفتوحاً يستطيع أي أحد البناء عليه؟ رهاني على المفتوح، للسبب ذاته الذي جعل الويب يتفوق على AOL.