حين تحتاج الاستقلالية إلى حرّاس، يصبح الوعد موضع تساؤل
ثمة لحظة بعينها تتحوّل فيها لغة الشركات إلى شاهد على نفسها. تحدث حين تُعلن الشركة ذاتها أن عملاء الذكاء الاصطناعي لديها قادرون على العمل باستقلالية تامة، بشكل متوازٍ، دون إشراف، وتسليم النتائج قبل أن يطلبها أحد، ثم تعرض في الحدث ذاته مجموعة من الأدوات التي لا وظيفة لها سوى مراقبة تلك العملاء وتصحيحها والتراجع عن أخطائها.
هذا بالضبط ما حدث في قمة AWS Summit في نيويورك في يونيو 2026. قدّمت شركة Amazon Web Services نفسها أمام السوق المؤسسي بوعد "عصر العملاء"، وخرجت من الحدث بعد أن أعلنت في آنٍ واحد عن نظامها الأكثر طموحاً من العملاء المستقلين وعن أكثف بنية تحتية للتحكم في تاريخها حتى الآن. المسافة بين هذين الأمرين ليست تفصيلاً تقنياً. إنها إعلان موقف يكشف أين تقف الصناعة فعلاً.
بالنسبة لمن يقود منظمة ويتخذ قرارات حول توظيف رأس المال والمواهب والمصداقية المؤسسية، فإن هذا التوتر يستحق تحليلاً أعمق مما يحظى به عادةً.
---
العرض ذو طبقتين، لكن يُباع منه واحدة فحسب
محور إعلان AWS كان Amazon Quick، وهي منصة تتيح للمستخدمين من غير المبرمجين إنشاء عملاء مستقلين بوصف وظيفتهم بلغة طبيعية ونشرهم في غضون ثوانٍ. المثال الذي انتشر: عميل يراقب العروض التنظيمية طوال الليل، ويقارنها بالسياسات الداخلية، ويقدم تحليلاً للأثر قبل الفجر. دون تدخل بشري. دون كود. دون احتكاك.
الحجة التسويقية نظيفة. وفي سياقات محدودة بعينها، ربما تنجح. غير أن العرض ذاته تضمّن أجزاء أخرى تحكي قصة مختلفة.
دمج AWS DevOps Agent قدرات إدارة الإصدارات التي تراجع الكود الذي يولّده عملاء الذكاء الاصطناعي قبل وصوله إلى بيئة الإنتاج، لأن عملاء البرمجة، كما تصف الشركة ذاتها، يكتبون بسرعة مذهلة فيما تظل المراجعة البشرية بطيئة. وظهر أيضاً AWS Transform، المبني على قاعدة مفادها أن كلما تسارع توليد الكود، تراكمت الديون التقنية، وأن هذه الديون تحتاج إلى تنظيف مستمر وذاتي. وقُدّم كذلك AWS Continuum، خدمة أمنية تبدأ في "وضع التعلم" ولا تنتقل إلى التنفيذ الذاتي إلا مع تنامي ثقة النظام.
كل واحدة من هذه الأدوات تفترض، بحكم تصميمها، أن العملاء سيرتكبون أخطاء، وأن هذه الأخطاء ستصل إلى الإنتاج إن لم يعترضها أحد، وأن وتيرة توليد المشكلات قد تتجاوز قدرة الإنسان على اكتشافها. هذا ليس وصفاً للاستقلالية. إنه وصف لنظام يستلزم مراقبة مستمرة على نطاق واسع، لأن بدونها تغدو المخاطر غير قابلة للإدارة.
رفض سوامي سيفاسوبراهمانيان، نائب رئيس الذكاء الاصطناعي العاملي في AWS، قراءة أن في الأمر تناقضاً. حجته: ضوابط التحكم لا تُضعف الاستقلالية بل تجعلها ممكنة. الاحتكاك اليدوي في كل قرار ليس ضماناً لحوكمة جيدة؛ بل هو عنق زجاجة متنكر في هيئة حذر. ما تقترحه AWS هو استبدال ذلك الاحتكاك اليدوي بضوابط قائمة على سياسات قادرة على العمل بالسرعة والنطاق اللذين تتطلبهما المنظمات الحديثة.
هذا حجة ذكية. وهي صحيحة جزئياً. لكنها تتحاشى شيئاً.
---
المشكلة ليست تقنية، بل هي حوكمة لم تُحسم بعد
تنجح أطروحة أن الضوابط الآلية أفضل من الاحتكاك اليدوي حين تكون هذه الضوابط معايَرة بدقة، وحين تعكس السياسات التي تحكم العملاء نوايا المنظمة بصدق، وحين تكون الأخطاء التي ترتكب داخل النظام قابلة للاكتشاف والتصحيح. لا تتوفر أيٌّ من هذه الشروط الثلاث مجاناً. كلها تستلزم عملاً تنظيمياً مسبقاً لم تنجزه معظم الشركات بعد.
تقول ليز ميلر، نائبة الرئيس والمحللة الرئيسية في Constellation Research، بلا مواربة: الحوكمة والمخاطر والمساءلة هي بشكل منهجي أول القيود التي تعيق مشاريع عملاء الذكاء الاصطناعي في الشركات. لا التقنية. لا الميزانية. بل العجز عن الإجابة بوضوح على سؤال: من المسؤول حين يتخذ العميل قراراً لم يُوافق عليه أحد صراحةً؟
هذه هي المحادثة التي تتهرب منها كثير من المنظمات. وتتهرب منها لأن ثمنها السياسي الداخلي مرتفع. إن تحديد ما يمكن للعميل أن يقرره دون تحقق بشري يعني اتخاذ موقف من العمليات القابلة للتقنين والاستثناءات القائمة وما يحدث حين يفشل النظام ومن يوقّع على ذلك. هذه ليست أسئلة تقنية. إنها أسئلة تتعلق بالسلطة والمسؤولية والشهية للمخاطرة، تستلزم أن يُسمّيها أحد من القمة الإدارية أولاً.
أقرّ سيفاسوبراهمانيان بذلك في مقابلته مع Fast Company بطريقة تستحق الانتباه: "يوافق البشر على عدد أقل من الإجراءات الفردية بينما يظلون مسؤولين عن القرارات على مستوى النظام التي تحدد النتائج. المساءلة لا تتراجع." هذا وصف صادق لما يجري. لكنه أيضاً إشارة إلى أن نموذج المساءلة التنظيمي الذي تعمل به كثير من الشركات اليوم، المبني على الموافقات الفردية والمراجعة حالة بحالة، ليس مهيأً للعمل في هذا النمط الجديد.
السؤال الذي لا تستطيع AWS أن تجيب عنه بدلاً من عملائها هو: كم عدد المنظمات التي تملك النضج الداخلي الكافي للتمييز بين أنواع القرارات التي يمكن تفويضها لعميل آلي، وتلك التي ينبغي أن تظل بشرية، وكيفية تصميم الحدود الفاصلة بينهما؟ تلك الحدود لا تُعرّفها التقنية. يُعرّفها القيادة.
---
ما يقوله غارتنر عن الـ 40% ولماذا يهم أكثر مما يبدو
يتوقع غارتنر أن أكثر من 40% من مشاريع عملاء الذكاء الاصطناعي ستُتخلى عنها قبل نهاية 2027. الأسباب التي يذكرها ثلاثة: تصاعد التكاليف، وضعف وضوح القيمة التجارية، وقصور ضوابط المخاطر. هذا التوقع ليس تهويلاً. إنه الوصف الإحصائي لنمط كان موجوداً قبل عملاء الذكاء الاصطناعي: اعتماد التقنية في المؤسسات يفشل في أغلب الأحيان بسبب مشكلات الحوكمة وضبابية تعريف القيمة، لا بسبب القيود التقنية.
ما يجعل هذا الرقم وثيق الصلة بهذا السياق هو أن AWS، ببنائها بنية تحتية كثيفة من الضوابط والرصد، تعترف ضمنياً بأن العملاء دون هذه البنية التحتية معدّلات فشلهم غير مقبولة في بيئة الإنتاج المؤسسية. قرار إطلاق AgentCore بسياسات حوكمة مدمجة، وبدء AWS Continuum في "وضع التعلم"، وإنشاء آليات التراجع في DevOps Agent، ليس تسويقاً أمنياً. إنه هندسة دفاعية في مواجهة مشكلة حقيقية.
المشكلة التي يُفرزها ذلك للعميل المؤسسي ذات طبيعة لا تُسمّيها سوى منظمات قليلة: إن كانت قيمة العملاء مرهونة بجودة السياسات التي تحكمهم، وهذه السياسات رهينة بأن تعرف المنظمة بدقة ما الذي تريد أتمتته، ومن يملك الصلاحية على ذلك، وما الذي يُشكّل خطأً غير مقبول، فإن العمل الحقيقي ليس تقنياً. إنه تنظيمي. وهذا العمل لا يأتي مدرجاً في أي رخصة برمجيات.
تحذّر ميلر من أن الشركات التي تخلط بين أتمتة المهام المتكررة والاستقلالية الحقيقية، أي الأنظمة التي تتخذ قرارات موجّهة بالأهداف في سياقات متغيرة، هي الأكثر عرضة للمخاطر. ليس لأن التقنية تخدعها، بل لأنها هي ذاتها تسمح لنفسها بتجنّب طرح الأسئلة التي ستُثير احتكاكاً داخلياً قبل الالتزام بالنشر.
تحمل AWS تلك المنطق ذاتها إلى تصميم المنتج حين تُعلن أن "الذكاء لم يعد عنق الزجاجة، السياق هو ذلك". هذه العبارة لها معنى تنظيمي ملموس: العملاء لا يتجاوزون في جودتهم جودة البيانات التي يعملون عليها واتساقها وإمكانية الوصول إليها. ومعظم الشركات الكبرى تمتلك بيانات مشتّتة وسجلات متضاربة وأنظمة لا تتواصل فيما بينها. حل ذلك قبل نشر العملاء ليس شرطاً مسبقاً تقنياً يستطيع فريق تكنولوجيا المعلومات التعامل معه وحده. إنه قرار يتعلق بأولويات الاستثمار يتعين على المستوى التنفيذي الأعلى اتخاذه والدفاع عنه.
---
الرهان على المنصة الذي لا تُسمّيه AWS صراحةً
ثمة بُعد في هذا الإعلان يستحق تحليلاً منفصلاً لأنه يؤثر على اقتصاديات قرار أي شركة تفكر في تبني هذه الخدمات.
لا تبيع AWS عملاء فحسب. إنها تبني بنية تحتية يعتمد فيها العملاء على مكوّنات خاصة بها: AWS Context للمعرفة المؤسسية، وAmazon S3 Annotations للبيانات المهيكلة، وAgentCore للتنسيق، وBedrock Guardrails للتحكم في المدخلات والمخرجات. كل طبقة قيمة تنشئها منظمة داخل ذلك النظام، كل سياسة مُعرَّفة، وكل سير عمل مُبرمج، وكل عميل مدرَّب على بيانات خاصة مخزّنة في تلك البنية التحتية، يرفع تكلفة المغادرة.
بإيرادات تجاوزت 104.9 مليار دولار في عام 2024، تمتلك AWS الحجم الكافي للحفاظ على هذه البنية طوال الوقت الذي يحتاجه السوق المؤسسي للنضج نحو استخدام العملاء المستقلين. الرهان ليس على أن العملاء مثاليون اليوم. بل إن المنظمات التي تبني عملياتها على هذه البنية التحتية ستواجه تكلفة هجرة مرتفعة بما يكفي لجعل العلاقة بنيوية لا معاملاتية.
هذا ليس نقداً. إنه وصف للكيفية التي تتنافس بها المنصات في البنى التحتية الحرجة. تفعل مايكروسوفت شيئاً مماثلاً مع Copilot Studio وAzure AI Studio. وتمتلك Google Cloud نسختها الخاصة مع Vertex AI Agent Builder. الجميع يقدم الحجة المركزية ذاتها: التكامل الرأسي بين النماذج والبيانات والتنسيق والحوكمة هو الميزة الحقيقية، لا النموذج ذاته.
بالنسبة للمسؤول التنفيذي الذي يُقيّم أين يلتزم، السؤال ليس عمّا إذا كانت العملاء تعمل في مشروع تجريبي. بل عمّا إذا كانت المنظمة تمتلك النضج الكافي في العمليات، ووضوح البيانات، وثقافة المساءلة اللازمة للعمل في بنية المنصة التي يقترحها كل مورد. هذا التقييم لا يمكن تفويضه إلى فريق التكنولوجيا. يستلزم أن يفهم من يقود ما الذي يوقّع عليه.
---
الاستقلالية مع أوصياء ليست الوجهة، بل نقطة الانطلاق
قارن سيفاسوبراهمانيان المقاومة الراهنة للعملاء بالشكوك التي كانت تكتنف السحابة في سنواتها الأولى. الحجة أن الضوابط تنضج وتنمو الثقة. هذا تشبيه معقول. لكنه يغفل شيئاً عن طبيعة ما يُفوَّض.
حين انتقلت شركة إلى السحابة، فوّضت بنية تحتية للحوسبة. كانت الأخطاء مكلفة في الغالب لكن قابلة للتعافي: خادم معطّل، قاعدة بيانات بطيئة، خدمة غير متاحة. حين تنشر شركة عميلاً مستقلاً في عملية اتخاذ قرار، تتغيّر فئة الخطأ. عميل يُسيء تفسير عرضاً تنظيمياً ويقدم تحليلاً خاطئاً في السادسة صباحاً، تُبنى عليه قرارات قبل أن يراجعه أحد، يولّد نوعاً مختلفاً من الضرر. قابلية التعافي لا تكفل بها سرعة التراجع التقني.
نموذج الحوكمة الذي تقترحه AWS، حيث يوافق البشر على القرارات على مستوى النظام بينما ينفّذ العملاء على مستوى المهام، متسق مفاهيمياً. لكنه لا يعمل إلا إذا كان التمييز بين "مستوى النظام" و"مستوى المهام" مُعرَّفاً بدقة داخل كل منظمة، وإذا فهم من يعمل في القمة ما يكفي من العمق ما الذي يحكمونه.
وعد الاستقلالية الذي حمله AWS إلى القمة حقيقي في طموحه. والحدود التي أقامها إلى جانب ذلك الوعد حقيقية أيضاً في فائدتها. غير أن أياً من الأمرين لا يستطيع أن يحلّ محلّ عمل القيادة الذي يجب أن يتم قبل أن يلمس أي عميل عملية ذات شأن. ذلك العمل ليس مبهجاً. ليس له شرائح عروض تقديمية. لكنه الشرط الذي يقوم عليه كل ما سواه.
لن تكون المنظمات التي تخرج من هذه الدورة في وضع أفضل هي تلك التي تبنّت العملاء بأسرع وتيرة. بل ستكون تلك التي قبل نشرهم عرفت كيف تُسمّي بصدق ما لم تكن قد أنجزته بعد.
