
يوم مطوري OpenAI 2025: تدفقات عمل الذكاء الاصطناعي، الوكلاء، وابتكار المطورين
استكشف رؤى يوم مطوري OpenAI 2025 حول تدفقات عمل الذكاء الاصطناعي، الأنظمة الوكيلية، قواعد بيانات المتجهات، ومستقبل تطوير الذكاء الاصطناعي. تعرّف كيف تبني المؤسس...

ما تعلمناه في قمة لندن AIE 2026: فوضى الوكلاء، الجدل بين السرعة والجودة، موت بيئات التطوير المتكاملة، مفارقات MCP، ولماذا جعلنا الذكاء الاصطناعي نعمل بجهد أكبر.
كان من المفترض أن تكون قمة لندن لمهندسي الذكاء الاصطناعي 2026 احتفالاً بالتقدم. بدلاً من ذلك، شعرتُ بها كمرآة تُرفع أمام مهنة في خضم انهيار عصبي.
لمدة ثلاثة أيام في أوائل أبريل، اجتمع مئات من مهندسي الذكاء الاصطناعي وبناة المنصات والباحثين لمشاركة ما تعلموه. ما ظهر كان نمطاً: الجميع يبني بوكلاء، لا أحد اكتشف كيف يتحكم بهم، الصناعة منقسمة حول ما إذا كان يجب التحرك بسرعة أو التفكير بعناية، والفرضية الكاملة بأن الذكاء الاصطناعي سيجعلنا أكثر إنتاجية انقلبت إلى شيء أكثر قتامة.
هذا ما تعلمناه فعلاً.
حدثت أكثر المحادثات صراحة في القمة في ممر، لا على خشبة المسرح. وصف مهندس من شركة تقنية مالية متوسطة الحجم المشكلة هكذا: “أبدأ موجّهاً، وبعد ثلاث ساعات أعاد وكيلي كتابة نصف قاعدة الكود، وأضاف ميزات لم أطلبها، واستهلك 800 جنيه إسترليني من الحوسبة. لا أستطيع مغادرة مكتبي.”
هذا هو FOMAT: الخوف من فقدان وقت الانتباه. إنها ليست نكتة - إنها القلق المحدد لهندسة الذكاء الاصطناعي في 2026.
كان الجميع في القمة يستخدم الوكلاء. GitHub Copilot وClaude وأطر الوكلاء المخصصة - الأدوات نضجت. لكن التنسيق لم ينضج. الفجوة بين “لدي وكيل” و"وكيلي يفعل ما أردته ولا شيء أكثر" ضخمة.
تتجلى المشكلة بثلاث طرق:
انفلات الرموز. ليس للوكلاء نقاط توقف طبيعية. دون حواجز حماية صريحة، يستمرون في التكرار. يفكر الوكيل: “إعادة هيكلة واحدة أخرى فقط”، وفجأة تحرق ميزانيتك الشهرية.
تضخم النطاق. يتحول طلب “تحسين معالجة الأخطاء” إلى “إعادة كتابة نظام معالجة الأخطاء بأكمله، وإضافة المراقبة، وإعادة هيكلة طبقة التسجيل، وتطبيق التتبع الموزع.” لم يكن الوكيل مخطئاً - كان شاملاً. لكنه لم يكن ما طلبته.
زمن انتقال غير متوقع. لا يمكنك معرفة المدة التي ستستغرقها مهمة وكيلية. يعتمد ذلك على عدد المهام الفرعية التي يقرر الوكيل إنشاءها، وعدد الإخفاقات التي يواجهها، وما إذا كان يقرر إعادة المحاولة أو تغيير المسار. وهذا يجعل من المستحيل جدولة سير العمل القائم على الوكلاء في أنظمة الإنتاج.
لم يكن هناك توافق على الحلول. تستخدم بعض الفرق حدوداً صارمة للرموز. ينفذ آخرون “نقاط تفتيش الوكلاء” - إجبار الوكلاء على التوقف وطلب الإذن قبل المتابعة. يتجه البعض نحو أنظمة وكلاء هرمية حيث يشرف “وكيل مدير” على الوكلاء العاملين ويمكنه مقاطعتهم.
ذُكرت طريقة FlowHunt - تعريفات سير العمل الصريحة بعقد الوكلاء ومعالجات الأخطاء ومنطق التفريع - عدة مرات كنمط محتمل. الفكرة: لا تدع الوكلاء يقررون بنية سير العمل. عرّفها مسبقاً، ثم دع الوكلاء ينفذون خطوات فردية.
لكن حتى ذلك شعر كأنه ضمادة. المشكلة الحقيقية هي أن سلوك الوكيل احتمالي بطبيعته. يمكنك تقليل التباين، لكن لا يمكنك القضاء عليه.
صباح الاثنين، اعتلى Ryan Lopopolo من OpenAI المسرح وألقى خطاباً رئيسياً يمكن تلخيصه بـ: توقف عن قراءة الكود. كن ملياردير رموز.
حجته: في عالم وكيلي، حجم الكود هو المقياس المهم. يجب أن يولد وكيلك آلاف الأسطر يومياً. مهمتك هي تحديد مواصفات المخرجات والسماح للوكيل بتعظيم الإنتاجية. قراءة وفهم كل سطر عنق زجاجة. ثق بالاختبارات. ثق بالوكيل. تحرك بسرعة.
بحلول الأربعاء، ألقى Mario Zechner من Anthropic الخطاب المضاد: أبطئ واقرأ الكود اللعين.
حجته: السرعة فخ. كل سطر كود يكتبه وكيلك هو عبء. تحتاج لفهمه، وتحليله، وأن تكون قادراً على صيانته. الفرق التي ستفوز بعد خمس سنوات هي التي تعطي الأولوية للوضوح والقصد على السرعة. يجب أن تكون الوكلاء أدوات للتفكير، لا لتوليد الكود بلا تفكير.
انقسمت القمة تقريباً إلى ثلاثة معسكرات:
| الموقف | المدافعون | النهج | المخاطر |
|---|---|---|---|
| أقصى الرموز | OpenAI، بعض مهندسي الشركات الناشئة المتوسعة | دع الوكلاء يولدون بقوة؛ ركز على جودة المخرجات عبر الاختبار | قواعد كود غير قابلة للصيانة، دين أمني، هشاشة تقنية |
| الوسط المقصود | معظم مهندسي المؤسسات | استخدم الوكلاء للهيكلة؛ يوفر البشر المعمارية والذوق | سرعة أبطأ، لكن أنظمة أكثر استقراراً |
| الكود أولاً | Anthropic، بعض مهندسي الأبحاث | يعزز الوكلاء التفكير البشري؛ يكتب البشر معظم الكود | إنتاجية أقل، لكن أعلى جودة كود |
لا أحد من الجانبين مخطئ. الخلاف يدور حول كيف يبدو الفشل. Lopopolo يُحسِّن لسرعة التكرار. Zechner يُحسِّن للاستدامة. في 2026، تتعلم الفرق أنه لا يمكنك التحسين لكليهما.
نتيجة ملموسة واحدة: التوظيف معطل. إذا كنت من المؤمنين بأقصى الرموز، لا يهمك ما إذا كان المرشح يمكنه البرمجة - يهمك ما إذا كان يمكنه الكتابة الفعالة للموجهات وتقييم مخرجات الوكيل. إذا كنت من أنصار الكود أولاً، فأنت تريد رؤية تفكير تقني عميق.
لذلك عندما يدخل مرشح إلى مقابلة، لا يعرف المُقابل ولا المرشح أي إطار يتم تقييمهم مقابله. وصفه أحد حضور القمة بأنه “إجراء مقابلات في ضباب”.
أعلن GitHub عن زيادة بمقدار 15 ضعفاً في حركة المرور سنوياً. أبلغت Cloudflare عن ارتفاعات مماثلة. في الوقت نفسه، تشهد بيئات التطوير المتكاملة التقليدية - VS Code وJetBrains وSublime - تراجعاً في الاستخدام بين الفرق الأصلية للذكاء الاصطناعي.
يبدو هذا متناقضاً حتى تفهم ما يحدث فعلاً.
صُممت بيئة التطوير المتكاملة لمطور واحد لكتابة كود محلياً. كان لديها تلوين بناء الجملة والإكمال التلقائي وأدوات التصحيح وشجرة الملفات. كانت بيئة مستقلة.
ينهار هذا النموذج عندما يكون “المطور” وكيلاً. لا يحتاج الوكيل إلى تلوين بناء الجملة. لا يحتاج مصحح أخطاء. يحتاج إلى:
كل ذلك يعيش في المتصفح الآن. GitHub Codespaces وVS Code Web وأدوات مماثلة تحل محل بيئات التطوير المحلية.
طفرة حركة GitHub ليست مطورين يكتبون كوداً في المتصفح. إنها مطورون يراجعون ويعلقون ويدمجون كوداً مُولَّداً بواسطة الوكلاء. إنها طبقة التعاون التي تنفجر، لا طبقة التحرير.
هذا هو سبب رؤية Cloudflare أيضاً لارتفاعات حركة المرور - يستخدم المطورون البنية التحتية السحابية لتشغيل الوكلاء وتنسيق سير العمل. يحل نموذج “تنسيق الوكلاء السحابي الأصلي + المراجعة المعتمدة على المتصفح” محل نموذج “بيئة التطوير المحلية + بيئة التطوير المحلية”.
كانت إحدى الجلسات تحمل هذا العنوان بالضبط. النقطة: الفكرة الرومانسية للمهندس اللامع، وحيداً على لوحة مفاتيحه، يصوغ كوداً أنيقاً - انتهت. الكود الآن مخرج تعاوني بين الإنسان والوكيل. المهارات التي تهم هي:
لم تعد كتابة الكود الأنيق مهارة أساسية. إنه شيء يفعله الوكلاء. يفعل البشر كل شيء آخر.
كان هذا النقاش الأكثر إرباكاً في القمة.
من جهة، كان مهندسو الذكاء الاصطناعي الفرديون ومشرفو أُطر الوكلاء يقولون: “MCP ميت. لسنا بحاجة إليه. وكلاؤنا يمكنهم استدعاء واجهات برمجة التطبيقات مباشرة.”
من جهة أخرى، كان مهندسو المؤسسات وفرق الأمن يقولون: “تبني MCP يتسارع أسرع مما يمكننا بناء أدوات له.”
كلا البيانين صحيحان. يصفان فئتين مختلفتين.
لمطور منفرد يبني وكيلاً بسيطاً، يضيف MCP احتكاكاً. تحتاج إلى:
من الأسهل ببساطة منح وكيلك وصولاً مباشراً إلى واجهة برمجة التطبيقات والسماح له بمعرفة الباقي.
لمؤسسة تُشغل وكلاء في الإنتاج، يصبح MCP فجأة ضرورياً. إليك السبب:
العزل الأمني. لا تريد أن يكون للوكلاء وصول مباشر إلى قاعدة بياناتك أو نظام الدفع أو بيانات العملاء. يتيح لك MCP إنشاء واجهة مُتحكم بها يمكن للوكلاء استدعاؤها دون كشف الأنظمة الأساسية.
قابلية التدقيق. يمر كل إجراء وكيل عبر خادم MCP، الذي يسجله. لديك سجل كامل لما فعله الوكيل ولماذا.
إدارة بيانات الاعتماد. بدلاً من تضمين مفاتيح واجهة برمجة التطبيقات في موجهات الوكلاء أو متغيرات البيئة، تدير خوادم MCP بيانات الاعتماد بشكل آمن.
تحديد المعدل وفرض الحصة. يمكنك التحكم في مقدار ما يمكن للوكيل استهلاكه من مورد.
وفقاً لـ CData Software، فإن 80% من شركات Fortune 500 تقيّم أو تطبق MCP اعتباراً من أوائل 2026، أساساً لهذه الأسباب.
توافق القمة: MCP ليس ميتاً. إنه فقط غير ذي صلة بالـ 80% من تطوير الذكاء الاصطناعي التجريبي والفردي. لكن بالنسبة للـ 20% الإنتاجية ومتعددة الفرق، يصبح MCP معياراً أساسياً.
لهذا السبب تنتشر تطبيقات MCP. تبني Anthropic وOpenAI والبائعون الخارجيون خوادم MCP مُعدّة مسبقاً للأدوات الشائعة (Salesforce وSlack وJira وقواعد البيانات). يمكن للمؤسسات تبني هذه دون بناء خوادم مخصصة.
هنا أصبحت القمة قاتمة.
كان من المفترض أن يكون الذكاء الاصطناعي مضاعف قوة. كنت ستقضي وقتاً أقل في المهام الروتينية ووقتاً أكثر في التفكير الاستراتيجي. كانت الإنتاجية ستحلق.
بدلاً من ذلك، حلقت الإنتاجية - وكذلك توقعات عبء العمل.
تنص مفارقة جيفونز، التي طبقت أصلاً على استهلاك الفحم: عندما يصبح المورد أكثر كفاءة، يزيد الاستهلاك الإجمالي لأن المورد يصبح أرخص وأكثر جاذبية.
بلغة الذكاء الاصطناعي: جعل الوكلاء توليد الكود أرخص وأسرع، لذا يتوقع المديرون الآن من كل مهندس:
استهلكت مكاسب الإنتاجية من قبل التوقعات المتضخمة.
مهندس واحد من شركة ناشئة مقرها لندن: “كنت أكتب 500 سطر من الكود يومياً وأشعر بالإنتاجية. الآن أكتب 5000 سطر يومياً - مُولَّدة من الوكلاء - وأنا منهك لأنني يجب أن أراجع كل شيء، واختباره، وتوثيقه، وشرحه لأصحاب المصلحة. أعمل 60 ساعة أسبوعياً.”
آخر: “يقول مديري: ‘لديك وكيل الآن، لذا يجب أن تكون قادراً على التعامل مع ضعف عدد المشاريع.’ لست أكثر إنتاجية. أنا فقط أكثر انشغالاً.”
باحث: “الوكلاء جيدون في توليد الكود. ليسوا جيدين في تحديد أي كود يجب توليده. تحول عبء اتخاذ القرار هذا بالكامل إلى البشر. نحن لا نؤتمت الجزء الصعب؛ نحن نؤتمت الجزء السهل ونجعل البشر يقومون بمزيد من التفكير.”
نشرت California Management Review التابعة لجامعة UC Berkeley بحثاً في يناير 2026 يوثق هذه الظاهرة. الفكرة الرئيسية: نشر الذكاء الاصطناعي لا يقلل من العمل؛ إنه يغير طبيعة العمل.
العمل القديم: كتابة الكود. العمل الجديد: توجيه الوكلاء، وتقييم المخرجات، والحفاظ على الجودة، وإدارة تضخم النطاق.
العمل الجديد أصعب معرفياً، حتى لو كان فيه طباعة أقل.
كان للقمة فصيل أوروبي قوي، وكانت رسالتهم متسقة: أوروبا لا تتحرك بسرعة مثل الولايات المتحدة في تبني هندسة الذكاء الاصطناعي.
لا يزال قانون الذكاء الاصطناعي للاتحاد الأوروبي قيد التنفيذ. الشركات غير متأكدة من المسؤولية. إذا اتخذ وكيل ذكاء اصطناعي قراراً يضر بعميل، من المسؤول؟ الشركة؟ بائع النموذج؟ المهندس؟
هذه الحالة من عدم اليقين مُشلّة. تنتظر العديد من الشركات الأوروبية لترى كيف ستسير القضايا القضائية الأولى قبل بناء أنظمة وكيلية جادة.
مهندسو البرمجيات التقليديون في أوروبا لا يتحولون إلى مهندسي ذكاء اصطناعي بنفس المعدل كما في الولايات المتحدة. هناك شكوك حول ما إذا كانت المهارات قابلة للنقل. ينتظر العديد من المهندسين الأوروبيين لرؤية ما إذا كانت هندسة الذكاء الاصطناعي مسار مهنة حقيقي أم دورة ضجيج.
أوروبا أيضاً أكثر حذراً بشأن معالجة البيانات. يحتاج الوكلاء إلى الوصول إلى البيانات ليكونوا مفيدين. لكن الشركات الأوروبية مترددة في منح الوكلاء وصولاً إلى بيانات العملاء، حتى مع وجود ضمانات MCP.
لم يكن المهندسون الأوروبيون في القمة ضد الذكاء الاصطناعي. كانوا مع الحذر. الشعور: “الولايات المتحدة تتحرك بسرعة وتكسر الأشياء. سنتحرك ببطء ونحاول ألا نكسر الكثير. بعد خمس سنوات، سنرى من كان على حق.”
بحلول نهاية القمة، ظهر نمط: يتم تفريغ أدوار هندسة البرمجيات التقليدية واستبدالها بثلاثة أنماط جديدة.
| الدور | المسؤولية | المهارات |
|---|---|---|
| مدير منتج الذكاء الاصطناعي | تعريف سلوك الوكيل، مقاييس النجاح، القيود | التفكير المنتجي، تصميم الموجهات، أُطر التقييم |
| جليس الوكيل | مراقبة التنفيذ، التقاط الأخطاء، التدخل عند الحاجة | التصحيح، القابلية للمراقبة، معالجة الأخطاء، الاستجابة للحوادث |
| مُحدد الذوق | تقييم جودة المخرجات، تقديم ملاحظات، توجيه التحسين | مراجعة الكود، تفكير المعمارية، الحكم الجمالي |
لا يتضمن أي من هذه الأدوار كتابة الكود بالمعنى التقليدي. تتضمن جميعها توجيه وتقييم وصقل سلوك الوكيل.
يتم ضغط أدوار “المهندس المبتدئ”. لم يعد هناك مسار واضح من “يمكنني كتابة كود بسيط” إلى “يمكنني تصميم أنظمة”. يتم أتمتة الخطوات الوسيطة.
يخلق هذا منحدر مهارات: إما أنك جيد في الموجهات والتقييم (في هذه الحالة أنت ذو قيمة)، أو لست كذلك (في هذه الحالة تنافس الوكلاء).
تنمو الأدوار التي تتطلب ذوقاً وحكماً وتفكيراً معمارياً. وكذلك الأدوار التي تتطلب خبرة عميقة في المجال (لأن الوكلاء يحتاجون بشراً لتقييم ما إذا كانوا يحلون المشكلة الصحيحة).
لم يكن للقمة توافق حول ما إذا كان هذا جيداً أم سيئاً. رأى البعض أنه تحرر من البرمجة الرتيبة. رأى آخرون أنه تهديد للمهنة.
كُرس قسم واحد من القمة لنقطة تحول محددة: تحول شيء ما في نظام وكلاء الذكاء الاصطناعي حول رأس السنة الجديدة.
بدأ OpenClaw وأُطر مماثلة بتمكين الوكلاء من تحسين مخرجاتهم الخاصة بشكل تكراري دون تحفيز بشري مستمر. بدلاً من “وكيل، اكتب دالة لحساب X”، أصبح “وكيل، اكتب دالة لحساب X واستمر في تحسينها حتى تجتاز جميع الاختبارات وتتعامل مع الحالات الطرفية.”
الفكرة الرئيسية، التي عبر عنها العديد من الباحثين: توقف عن طلب نصائح تافهة من الوكلاء.
بدلاً من الطلب من وكيل “تحسين هذه الدالة”، اطلب منه “جعل هذه الدالة مُحكمة”. دعه يقرر ماذا يعني ذلك. سيقوم الوكيل بـ:
كل ذلك دون أن يُطلب منه كل خطوة.
غيّر هذا النموذج العقلي من “الوكيل كأداة” إلى “الوكيل كمساهم مستقل”. وغيّر ديناميكيات عبء العمل: بدلاً من أن يقلل الوكلاء العمل البشري، زادوا منه (لأن البشر الآن يجب أن يقيموا مخرجات وكيلية أكثر تطوراً بكثير).
انتهت القمة دون حل، وهو ما شعر بأنه صادق. إليك التناقضات التي تحدد هندسة الذكاء الاصطناعي في أبريل 2026:
التناقض 1: الوكلاء أقوياء بما يكفي ليكونوا خطرين (FOMAT حقيقي)، لكن ليسوا أقوياء بما يكفي ليُوثق بهم دون إشراف.
التناقض 2: يُعامل السرعة والجودة كنقيضين، لكن كليهما ضروري.
التناقض 3: MCP ميت (للأفراد) ومزدهر (للمؤسسات) في آن واحد.
التناقض 4: جعلنا الذكاء الاصطناعي أكثر إنتاجية، لكن أيضاً أكثر إرهاقاً.
التناقض 5: الجميع يبني بوكلاء، لكن لا أحد اكتشف كيف يبني بهم بشكل جيد.
التناقض 6: هندسة الذكاء الاصطناعي مسار مهنة حقيقي، لكن المهارات التي ظننا أنها ستهم (كتابة الكود) لم تعد كذلك.
هذه ليست مشاكل يجب حلها. إنها توترات يجب إدارتها. الفرق التي ستفوز في 2026 هي التي تعترف بهذه التناقضات بدلاً من التظاهر بأنها غير موجودة.
كانت قمة لندن لقطة لمهنة في مرحلة انتقالية. هندسة الذكاء الاصطناعي حقيقية، لكنها ليست ما ظننا أنها ستكون. إنها أكثر فوضوية، وأكثر تناقضاً، وأكثر اعتماداً على البشر مما أوحت به الضجة.
أفضل المهندسين في القمة لم يكونوا الذين لديهم أكثر الوكلاء تطوراً. كانوا الذين فهموا أن الوكلاء أداة للتفكير، وليست بديلاً عنه. كانوا الذين بنوا عمليات لإدارة سلوك الوكلاء وتقييم المخرجات والحفاظ على الجودة. كانوا الذين قبلوا أن مكاسب الإنتاجية تأتي مع أنواع جديدة من العمل، وليس عملاً أقل.
إذا كنت تبني أنظمة ذكاء اصطناعي في 2026، فإن دروس القمة واضحة:
التنسيق أهم من قدرة الوكيل. وكيل متوسط مع تنسيق جيد يتفوق على وكيل رائع دون ضوابط.
الوضوح أكثر قيمة من السرعة. التحرك بسرعة وكسر الأشياء يعمل حتى لا يعمل. على النطاق الواسع، لا يعمل.
تبني المؤسسات حقيقي، لكن التبني الفردي لا يزال تجريبياً. إذا كنت مطوراً منفرداً، يمكنك التحرك بسرعة. إذا كنت فريقاً، تحتاج إلى حواجز حماية.
تغيرت المهارات التي تهم. هندسة الموجهات وتقييم المخرجات والتفكير المعماري هي الكفاءات الأساسية الجديدة.
توقع العمل بجهد أكبر، لا أقل. الذكاء الاصطناعي مضاعف إنتاجية، لكن المكاسب تُستهلك من قبل توقعات أعلى. خطط وفقاً لذلك.
لم تُجب القمة على سؤال “كيف تبدو هندسة الذكاء الاصطناعي؟” أرتنا الإجابة: تبدو مثلنا، نحاول اكتشافها في الوقت الفعلي.
{{ cta-dark-panel heading=“توقف عن تنسيق الوكلاء يدوياً” description=“يتيح لك منشئ سير العمل في FlowHunt تعريف سلوك الوكيل، وتعيين حواجز حماية، وأتمتة مهام الذكاء الاصطناعي متعددة الخطوات. لا مزيد من FOMAT. لا مزيد من التخمين حول ما يفعله وكلاؤك.” ctaPrimaryText=“جرّب FlowHunt مجاناً” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“احجز عرضاً تجريبياً” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
أرشيا هو مهندس سير عمل الذكاء الاصطناعي في FlowHunt. بخلفية في علوم الحاسوب وشغف بالذكاء الاصطناعي، يختص في إنشاء سير عمل فعّال يدمج أدوات الذكاء الاصطناعي في المهام اليومية، مما يعزز الإنتاجية والإبداع.

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

استكشف رؤى يوم مطوري OpenAI 2025 حول تدفقات عمل الذكاء الاصطناعي، الأنظمة الوكيلية، قواعد بيانات المتجهات، ومستقبل تطوير الذكاء الاصطناعي. تعرّف كيف تبني المؤسس...

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

استكشف لماذا تعتبر القيادة في الذكاء الاصطناعي ضرورية لنجاح المؤسسات، وكيف يقود القادة الأقوياء تحولات الذكاء الاصطناعي، وكيف تجهز ورشة عمل القيادة في الذكاء ال...
الموافقة على ملفات تعريف الارتباط
نستخدم ملفات تعريف الارتباط لتعزيز تجربة التصفح وتحليل حركة المرور لدينا. See our privacy policy.