أعادت غوغل تصميم بنيتها للبيانات لتجنب إخفاق الذكاء الاصطناعي في بيئات الأعمال
لسنوات طويلة، عمل فريق البيانات وفريق الذكاء الاصطناعي في كبرى الشركات كأنهما قادمان من بلدين مختلفين. كان الأول يبني مستودعات البيانات، وفهارسها، وخطوط أنابيب المعالجة. وكان الثاني يُطلق النماذج وواجهات برمجة التطبيقات والوكلاء الذكيين. وكان العالمان يتواصلان عبر عمليات تصدير يدوية، وعمليات متقطعة، وإيمان أعمى بأن "الفريق الآخر سيحلّها". وكانت النتيجة متوقعة: يصل وكلاء الذكاء الاصطناعي إلى بيئة الإنتاج فيتهاوون أمام بيانات لم يُعدّها أحد لكي تستطيع آلة مستقلة قراءتها وتفسيرها والتصرف بناءً عليها.
في مؤتمر Google Cloud Next 2026، سمّت غوغل ذلك الانهيار بدقة متناهية: إن الفصل بين منصة البيانات ومنصة الذكاء الاصطناعي هو أكبر عائق أمام نشر الوكلاء المستقلين في بيئات الأعمال. وجاء ردّها على ذلك في هيئة السحابة البيانية الوكيلية، وهي إعادة هيكلة جذرية لبنية البيانات لا تُضيف طبقةً للذكاء الاصطناعي فوق ما هو قائم، بل تُعيد تصميم الأسس من البداية لكي يصبح الوكلاء مستخدمين من الدرجة الأولى للبيانات المؤسسية.
والفارق في مستوى الطموح ليس هيّناً بأي حال. لا يتعلق الأمر بموصّلات جديدة أو بلوحات بيانات مُعزَّزة بالغة الطبيعية. بل يتعلق بإعادة تصميم هيكلية تُجبر أي شركة من قائمة Fortune 500 —التي تتوزع بياناتها بين AWS وAzure وGoogle Cloud— على إعادة التفكير في كيفية حوكمة المعلومات التي تمتلكها بالفعل، وتقديمها، وتحقيق الدخل منها.
التشخيص الذي يفضّل المديرون تجاهله
ثمة رقم يُسبّب الإزعاج: وفقاً للدراسة المرافقة للإطلاق، فإن نحو 70% من الشركات تكتشف إخفاقات بنيتها للبيانات بعد نشر الوكلاء، لا قبله. وهذه ليست مشكلة تقنية في حقيقتها. إنها مشكلة قيادية متنكّرة في هيئة تقنية.
البيانات المتشتتة، العارية من الحوكمة، المحبوسة في صوامع سحابية متعددة، لم تظهر بين عشية وضحاها. تراكمت على مدى سنوات من القرارات المتسرعة، وعمليات الاستحواذ المؤسسية المُدمجة بشكل سيئ، ونزعة تنظيمية بشرية عميقة: تأجيل الحوار الصعب حول البنية الفعلية للبيانات لأن "الأعمال ما زالت تسير". إلى أن تتوقف عن السير.
تتألف البنية التي قدّمتها غوغل من ستة مكوّنات ليست مستقلة عن بعضها، بل تشكّل منظومة ذات منطق تسلسلي. في القاعدة، يوجد Data Lakehouse متعدد السحابات، مبني على تنسيق Apache Iceberg المفتوح، يُتيح لـ BigQuery الاستعلام عن البيانات المستضافة في AWS S3 وAzure ADLS دون الحاجة إلى نقلها أو نسخها، مما يُلغي تكاليف الخروج وخطر التعارض بين النسخ المتعددة. وفوق تلك القاعدة يعمل محرك Lightning لـ Apache Spark، وهو طبقة تنفيذ مُتّجهة مكتوبة بلغة C++ تُقدّم أداءً يبلغ 4.9 ضعف أداء Spark التقليدي. فالبيانات لا تكون قابلة للوصول فحسب؛ بل قابلة للمعالجة بسرعة تجعل من الممكن أن يولّد الوكيل كود Spark وينفّذه ويُصحّحه في دورات متواصلة دون أن تتصاعد التكاليف.
فوق تلك البنية التحتية للتنفيذ تأتي طبقة الذكاء السياقي: كتالوج المعرفة، الذي يمثّل تطوراً لـ Dataplex Universal Catalog الذي أُعلن عنه في العاشر من أبريل 2026. وهذا المكوّن هو الأجدر باستئثار انتباه المهندسين المعماريين في المؤسسات. فالكتالوج لا يستلزم من فرق البيانات فهرسة الأصول يدوياً، بل يفحص سجلات الاستعلامات، ويُعدّ ملفات تعريف الجداول، ويُحلّل النماذج الدلالية لأدوات مثل Looker، ويستخرج العلاقات بين الكيانات من ملفات غير منظمة. والنتيجة هي رسم بياني للمعرفة ديناميكي يُصان تلقائياً، يُجيب على السؤال الذي يحتاج أي وكيل إلى الإجابة عنه قبل التصرف: ما البيانات الموجودة، وماذا تعني بدقة، وهل هي موثوقة.
حين يكف التخزين عن أن يكون سلبياً
المكوّن الذي يُغيّر هندسة البيانات التشغيلية بصورة جذرية هو التخزين الذكي، المتاح حالياً في نسخة معاينة. حتى الآن، كان الملف الذي يدخل إلى حاوية في Google Cloud Storage يظل خاملاً حتى يقرر أحدهم معالجته. بفضل هذه الوظيفة، في اللحظة التي يصل فيها الملف إلى الحاوية، يُصنّفه النظام تلقائياً، ويُنشئ له تضمينات، ويستخرج الكيانات ذات الصلة، ويربطه بكتالوج المعرفة. ملفات PDF والعقود وتذاكر الدعم وتسجيلات الصوت: كل شيء يتحوّل إلى أصل قابل للبحث دون أن يتدخل أي مهندس.
بالنسبة للمديرين الذين يُؤجّلون مشاريع إعداد البيانات غير المنظمة —تلك التي "ستستغرق ستة أشهر" من الاستخراج والتعرف الضوئي على الحروف والفهرسة والتصنيف— فإن هذا يُعيد رسم معادلة الوقت والتكلفة بطريقة لا تقبل التأجيل المريح. ما كان في السابق مشروعاً يحتاج راعياً تنفيذياً وميزانية مستقلة وتاريخ تسليم غير مؤكد، بات نتيجة تلقائية لسياسة التخزين المعتمدة.
وكيل البحث المعمّق، المبني على Gemini 3.1 Pro، يُجسّد حالة الاستخدام النهائية لهذه البنية التحتية بأكملها. يعمل بدمج المصادر الداخلية من كتالوج المعرفة والـ Lakehouse مع المصادر المفتوحة على الإنترنت، ويُولّد خططاً بحثية منظمة، ويُقدّم تقارير تحتوي على مراجع قابلة للتحقق في غضون دقائق. المهام التي كانت تستهلك في مجالات مثل الاستخبارات التنافسية وعلوم الحياة والخدمات المالية من أسبوع إلى ثلاثة أسابيع من عمل المحللين، باتت نقطة البداية لا نقطة الوصول.
مجموعة أدوات وكلاء البيانات تُكمل الصورة من جانب المطوّر. تُقدّم أدوات MCP مُهيَّأة مسبقاً وثلاثة وكلاء متخصصين: الأول يُحوّل التعليمات بالغة الطبيعية إلى خطوط أنابيب مُدارة يختار بينها BigQuery أو dbt أو Spark أو Airflow؛ والثاني يُؤتمت دورة نماذج علم البيانات الكاملة؛ والثالث مخصص لقابلية مراقبة البنية التحتية. يعمل بروتوكول سياق النموذج كطبقة تشغيل بيني تُتيح لوكلاء أي مزوّد —Gemini أو Claude أو النماذج الخاصة— الوصول إلى أصول البيانات دون الحاجة إلى موصّلات مخصصة.
تتحول متعددة السحابات من شكوى إلى قرار معماري
لا توجد شركة واحدة بين شركات قائمة Fortune 500 تعمل حصراً على Google Cloud. أنظمة SAP وSalesforce وWorkday وOracle موزعة بين AWS وAzure لأسباب تاريخية وتعاقدية وتشغيلية لا يمكن لأي توجيه من مدير تقنية المعلومات أن يحلّها بمذكرة داخلية. ولسنوات طويلة، كانت متعددة السحابات الحجة المتكررة لتبرير عدم المضي قُدُماً في أي مبادرة للذكاء الاصطناعي على نطاق واسع: "نحتاج أولاً إلى توحيد البيانات".
Data Lakehouse متعدد السحابات يُفكّك تلك الحجة بتحديد تقني دقيق. باستخدام كتالوج REST الخاص بـ Iceberg، والاتصال البيني متعدد السحابات، وطبقة تخزين مؤقت ذكية، يستطيع BigQuery الاستعلام عن البيانات في AWS S3 وAzure ADLS بزمن استجابة وتكلفة مقارنَين بما هو موجود في البيانات الأصلية على Google Cloud. يمكن لوكيل المشتريات دمج بيانات العقود المخزنة في S3، والمخزون في Azure، والسجلات المعاملاتية في BigQuery في استعلام واحد، وكل ذلك تحت كتالوج Iceberg موحّد، دون أن تضطر أي فرق هندسية إلى إدارة عملية ETL بين السحابات.
الانعكاس على مهندسي التكامل ذو طابع استراتيجي بامتياز. لم تعد المحادثة تدور حول "كيف ننقل كل شيء إلى سحابة واحدة"، بل أصبحت حول "كيف نحكم كتالوجاً موحداً فوق توزيع البيانات الذي نمتلكه بالفعل". وهاتان ليستا المحادثة ذاتها. الأولى تنطوي على تكلفة سياسية ومالية باهظة في معظم المنظمات الناضجة. أما الثانية فقابلة للتنفيذ دون الإخلال بالعقود القائمة مع المزوّدين الآخرين.
ما تقترحه غوغل في مجملها هو تحوّل جذري في المنهج له تبعات تنظيمية تتجاوز البنية التقنية. يستدعي بروتوكول MCP بوصفه طبقةً لحوكمة الوكلاء أن يُدار بالانضباط ذاته المُطبَّق اليوم على بوابة واجهات برمجة التطبيقات: الإصدارات، والمصادقة، والمراقبة، وحدود الاستخدام. يكفّ كتالوج المعرفة عن كونه مشروع توثيق، ليصبح اعتماداً تشغيلياً في الزمن الفعلي، مما يستلزم اتفاقيات مستوى الخدمة، والصيانة المستمرة، ونموذج تشغيل لم تصمّمه فرق البيانات بعد.
إن ثقافة المنظمة ليست اللافتة المعلّقة في قاعة الاجتماعات، ولا خطاب الرئيس التنفيذي في المؤتمر السنوي. إنها المجموع التراكمي لكل القرارات التي اتخذها القادة حين كان التأجيل أريح من الحسم، والتفويض أأمن من تحمّل المسؤولية، وإلقاء اللوم على الديون التقنية أسهل من الاعتراف بأن بنية البيانات تعكس بدقة جراحية بنية السلطة والخوف والمحادثات التي لم يملك الفريق القيادي يوماً الشجاعة الكافية لخوضها.
