11% فقط من قادة التكنولوجيا يشعرون باستعداد كامل لحجم نشر وكلاء الذكاء الاصطناعي المتوقَّع هذا العام، والمؤسسة المتوسطة في أحدث عيّنة لـ IBM استوعبت 54 حادثة وكلاء خلال الأشهر الاثني عشر الماضية — أحداث غير مقصودة أو ضارّة تطلّبت تدخّل إنسان لتصحيحها (IBM Institute for Business Value, 2026). تأتي هذه الأرقام من استطلاع عالمي شمل 2000 من رؤساء المعلومات والتقنية — أشخاص يديرون شركات تملك فرق أمن ووظائف امتثال وحوكمة لتقنية المعلومات لا تملكها أنت. إذا كان 11% من الاستعداد هو السقف في شركات مبنية لاستيعاب كل هذا، فاسأل نفسك كيف تبدو الأرضية في عملية من 200 موظف بدوام كامل تضيف وكلاء إلى المالية والدعم والجدولة هذا الربع، بلا أيٍّ من تلك البنية.
هذا هو موضوع المقال. ليس ما إذا كان عليك نشر الوكلاء — ستفعل، وحالة الإنتاجية حقيقية — بل ما إذا كنت تبني حوكمة الذكاء الاصطناعي الوكيلي اللازمة للنجاة من الوكلاء الذين تنشرهم. تتضمّن بيانات IBM نتيجة تعيد صياغة القرار بأكمله: التحكّم ليس مكبح سرعة الوكلاء. إنه المحرّك.
فجوة التحكّم مشكلة سوق متوسطة بثوب مؤسسي
تُسمّي IBM التوتّر الجوهري بدقّة: المساءلة تتجاوز التحكّم. ثلثا قادة التكنولوجيا المُستطلَعين يقولون إنهم مُساءَلون عن أنظمة ذكاء اصطناعي لا يتحكّمون بها بالكامل، و77% يعترفون بأن تبنّي الذكاء الاصطناعي تجاوز بالفعل قدرات الحوكمة في مؤسساتهم (IBM Institute for Business Value, 2026). و70% يؤكّدون أن الفرق في أنحاء الشركة تنشر التقنية أسرع مما تستطيع تقنية المعلومات تتبّعه — نشر ظلّي، وكلاء يُشغَّلون في قسم ويُكتشَفون لاحقًا.
عند قراءته كمشغّل في السوق المتوسطة، تكون الترجمة غير مريحة. في المؤسسة الكبرى، "تقنية المعلومات لا تستطيع التتبّع" تعني أن شركة من 5000 شخص لديها ثغرات. في شركة من 200 موظف، غالبًا لا يوجد "تقنية المعلومات لا تستطيع التتبّع" مركزي، لأنه لا توجد تقنية معلومات مركزية تتتبّع. الوكيل الذي ربطه مسؤول الدعم لديك بمكتب المساعدة في عطلة نهاية أسبوع ليس على خريطة أحد. فجوة التحكّم التي تقيسها IBM في المؤسسة هي، بنيويًا، أوسع بالنسبة لك — لأن المؤسسة على الأقل تعلم أن الفجوة موجودة ولديها مسؤول أمن معلومات مهمّته سدّها.
يهمّ هذا الآن لأن الوكلاء ليسوا نظريين. تتوقّع Gartner أن 40% من تطبيقات المؤسسات ستضمّ وكلاء ذكاء اصطناعي مخصّصين للمهام بنهاية 2026، صعودًا من أقل من 5% في العام السابق (Gartner, 2025). الأدوات التي تدفع ثمنها بالفعل تضخّ وكلاء في منظومتك، سواء كانت لديك خطة حوكمة لهم أم لا.
ما تكلّفه الـ54 حادثة فعلًا
تبدو كلمة "حادثة" هيّنة حتى تنظر إلى توزيع الخطورة. من بين الـ54 حادثة وكلاء المُسجَّلة وسطيًا، كانت 17% عالية الخطورة — أحداث استغرق احتواؤها أكثر من أربع ساعات. ومن بين تلك الحالات الخطيرة، تضمّن 37% تسريب بيانات أو اختراقًا أمنيًا، و33% أعطالًا متتالية في الأنظمة، و17% مخالفات امتثال (IBM Institute for Business Value, 2026). هذا ليس "أعطى روبوت المحادثة جوابًا غريبًا". إنه تسريب بيانات عملاء، أو عملية لاحقة انكسرت لأن وكيلًا غذّاها بمخرجات خاطئة، أو تعرّض تنظيمي يظهر عند التدقيق.
قِسْ ذلك بأمانة على بيئتك. لن تستوعب 54 — أنت أصغر. لكنك أيضًا لن تستوعب الحالات العالية الخطورة كما تفعل مؤسسة كبرى. حادثة تسريب بيانات تستغرق أربع ساعات في شركة لديها عقد استجابة للاختراقات وفريق اتصالات هي حدث محتوًى. الحادثة نفسها في شركة من 200 موظف تعني مسؤول العمليات والمؤسِّس ومحاميًا خارجيًا في مكالمة، يُلغون كل شيء آخر لأسبوع. عدد الحوادث يتناسب مع حجمك؛ أما التكلفة لكل حادثة فلا تتناقص معه.
تصوغ Deloitte النسخة الكلّية بوضوح: الذكاء الاصطناعي الوكيلي يتوسّع أسرع من الحواجز الواقية المُفترَض أن تحكمه (Deloitte Insights, 2026). الفجوة بين سرعة النشر ونضج التحكّم ليست شذوذًا خاصًّا بالسوق المتوسطة. إنها الحالة التي تُعرّف هذه الدورة التقنية. مشكلة السوق المتوسطة المحدّدة هي أنها تندفع داخل تلك الفجوة بأقلّ هامش خطأ.
التحكّم شرط مسبق للسرعة، لا ضريبة عليها
إليك النتيجة التي ينبغي أن تغيّر كيف ترتّب العمل. الحدس — حدسي أيضًا قبل قراءة البيانات — هو أن الحوكمة تبطئك: كل ضابط تضيفه نقطة تفتيش، ونقاط التفتيش تكلّف سرعة. أرقام IBM تقلب هذا الحدس تمامًا.
المؤسسات التي تُضمِّن التحكّم مباشرةً في أنظمة وكلائها، بدلًا من حوكمتها يدويًا بعد وقوع الأمر، تنشر 16 ضعفًا من وكلاء الذكاء الاصطناعي، وتسجّل حوادث أقل بنسبة 25%، وتحقّق هوامش تشغيلية أعلى بنسبة 18% من المؤسسات التي تحكم يدويًا (IBM Institute for Business Value, 2026). كما تنفق نحو أربعة أضعاف أقل من ميزانية الذكاء الاصطناعي لتحقيق ذلك. ستة عشر إلى واحد في حجم النشر ليست فرق تقريب. إنها الفجوة بين مؤسسات تثق بوكلائها بما يكفي لتتركهم يتكاثرون، ومؤسسات مضطرّة لمراقبة كلٍّ منهم لأنها لم تبنِ يومًا الأدوات التي تتيح إشاحة النظر.
الآلية بديهية بمجرّد رؤيتها. الحوكمة اليدوية شخص يراجع عمل وكيل. هذا الشخص هو عنق الزجاجة — يحدّ عدد الوكلاء الذين تستطيع تشغيلهم بالعدد الذي يستطيع إنسان الإشراف عليه. التحكّم بالتصميم يعني أن قابلية المراقبة والملكية ومفتاح الإيقاف مدمَجة في الوكيل عند النشر، فيُشرف النظام على نفسه ولا يُصعِّد إلا الاستثناءات. أنت لا تقايض السرعة بالأمان. أنت تشتري السرعة مع الأمان، لأن الأمان هو ما يتيح لك التوسّع إلى ما وراء مدى انتباه إنسان واحد متوتّر.
لهذا فإن "سنضيف الحوكمة بعد أن يثبت الوكلاء جدارتهم" هو عكس الصواب تمامًا. المؤسسات التي تنشر 16 ضعفًا من الوكلاء لم تكسب حقّ التوسّع بالإسراع أولًا ثم إضافة التحكّم لاحقًا. توسّعت لأن التحكّم كان حاضرًا منذ الوكيل الأول.
الاعتراض المضادّ: "الحوكمة عبء مؤسسي لا نقدر عليه"
أقوى اعتراض من مشغّل متمرّس هو اعتراض ميزانية، ويستحقّ ردًّا مباشرًا. يبدو التحكّم بالتصميم برنامجًا مؤسسيًا — منصّة حوكمة، ولجنة مخاطر، وتعيين امتثال. نحن 200 شخص. لا نستطيع إقامة وظيفة تحكّم بحجم IBM، والتظاهر بأننا نستطيع يعني فقط ألّا ننشر شيئًا بينما ينطلق المنافسون.
عادل. والبيانات توافق جزئيًا: المؤسسات التي تفوز هنا هي بشكل غير متناسب تلك ذات الانضباط المالي القوي، التي تنشر 2.4 ضعفًا من الوكلاء بلا ميزانية أعلى، واحتمال شعورها بالاستعداد أكبر ثلاث مرات (IBM Institute for Business Value, 2026). قد يُقرأ ذلك كـ"تحتاج نضجًا لا تملكه". لكن انظر إلى ما يعنيه الانضباط فعلًا في البيانات — ليس ميزانية أكبر، بل الميزانية نفسها مُنفَقة بترتيب مختلف. التحكّم بالتصميم يكلّف أربعة أضعاف أقل من تركيب الحوكمة لاحقًا. المسار المكلف هو الذي يفترضه الاعتراض رخيصًا: انشر بسرعة، بلا حوكمة، ثم ادفع لاحتواء الـ54 حادثة وتركيب الضوابط تحت الضغط. أرضية الحوكمة ليست عبئًا مؤسسيًا. إنها القرارات التصميمية الثلاثة أو الأربعة التي تتّخذها بشأن كل وكيل قبل نشره، وتكلّف محادثة، لا قسمًا.
أرضية الحوكمة: جهّز الوكيل القادم، لا الحادثة الأخيرة
التصحيح ضيّق وتحت سيطرتك بالكامل هذا الربع. لا تحتاج منصّة حوكمة. تحتاج أرضية — حدًّا أدنى من المعايير يجتازه كل وكيل جديد قبل أن يمسّ الإنتاج. ثلاثة أمور، قابلة للتركيب في الوكيل القادم الذي تنشره.
أولًا، قابلية المراقبة قبل الاستقلالية. لا يدخل أي وكيل الإنتاج حتى تستطيع رؤية ما فعله — سجلّ لأفعاله ومدخلاته ومخرجاته يستطيع إنسان مراجعته لاحقًا دون إعادة بنائه من الذاكرة. إن لم تستطع الإجابة عن "ماذا فعل هذا الوكيل أمس؟" في أقل من خمس دقائق، فالوكيل ليس جاهزًا. هذا هو الضابط الوحيد الذي يحوّل حادثة خطيرة صامتة إلى حادثة مُكتشَفة.
ثانيًا، مالك مُسمّى لكل وكيل. لكل وكيل شخص مسؤول عن سلوكه — لا لجنة، بل اسم. فجوة التحكّم كلها لدى IBM هي الفجوة بين المساءلة والتحكّم؛ تسدّها على نطاقك بالتأكّد من أن لكل وكيل شخصًا مهمّته التحكّم به. النشر الظلّي يموت هنا، لأن وكيلًا بلا مالك لا يُسمَح له بالعمل.
ثالثًا، نطاق تأثير محدّد ومفتاح إيقاف. قبل النشر، تقرّر ما يُسمَح للوكيل بمسّه وكيف توقفه. الوكيل الذي يستطيع قراءة الجدول خطر مختلف عن وكيل يستطيع إرسال بريد للعملاء أو تحريك أموال؛ قيّده إلى الحدّ الأدنى، وتأكّد أن شخصًا واحدًا يستطيع إيقافه خلال ثوانٍ دون تذكرة هندسية. هذا ما يمنع خطأ وكيل واحد من أن يصبح العطل المتتالي الذي يمثّل 33% من الحوادث الخطيرة.
لا يتطلّب أيٌّ من هذه الثلاثة كوادر لا تملكها. تتطلّب أن تقرّر، قبل النشر، أن الوكيل يكسب استقلاليّته بكونه قابلًا للمراقبة ومملوكًا ومحدودًا. ذلك القرار هو أرضية الحوكمة، وهو الفرق بين توسيع الوكلاء وتكديس الحوادث.
القصة الإجمالية لبيانات IBM 2026 هي أن الوكلاء يأتون أسرع من الضوابط، وأن المؤسسات التي تفوز ليست تلك التي تنشر أسرع — بل تلك التي سرعتها مبنيّة على التحكّم لا مُشتراة على حسابه. القصة الكامنة، لمسؤول عمليات يضيف وكلاء هذا الربع، هي قرار تسلسل واحد: هل يولد الوكيل القادم في خطتك بقابلية مراقبة ومالك ومفتاح إيقاف مدمَجة، أم يولد عاريًا ويستعيدها بالطريقة الصعبة بعد أن تفرض الحادثة الأولى المحادثة؟ ابنِ الأرضية في الوكيل القادم. ميزة الـ16 إلى 1 لا تذهب لمن يتحرّك أولًا — بل لمن يتحرّك أولًا والتحكّم موجود مسبقًا داخل الآلة.
