DXC تُدخل وكلاء الذكاء الاصطناعي إلى عمليات تقنية المعلومات في البنوك والمستشفيات: زمن حل الحوادث ينخفض بنسبة 95%

عندما يستطيع وكيل الدخول إلى خادم الإنتاج في أحد البنوك، يتراجع سؤال «أي نموذج نختار» إلى المرتبة الثانية. تُظهر الحوادث المعلنة التي نفّذت فيها وكلاء مستقلون إجراءات مدمّرة لم يطلبها أحد أن المشكلة نادرًا ما تكون في النموذج نفسه. المشكلة في وكيل يملك صلاحيات أكثر مما تتطلبه المهمة، وفي بنية لا توقفه. وقد روت شركة المقاولات DXC Technology (115 ألف موظف في 70 دولة، وعملاؤها بنوك ومستشفيات وجهات حكومية) في مدونة AWS كيف بنت مثل هذا المانع لمنصتها DXC OASIS.

طبقتان: الركيزة والغلاف التشغيلي

الفكرة بسيطة: سؤال «أي نموذج» منفصل عن سؤال «كيف يُنجَز العمل». تسمي DXC الطبقة السفلية الركيزة (substrate). وهي Amazon Bedrock: واجهة API واحدة لنماذج Claude وAmazon Nova وMeta Llama وعائلات النماذج مفتوحة الأوزان. وفوقها تعمل Bedrock Guardrails بترشيح المحتوى وإزالة البيانات الشخصية وحظر المواضيع المحظورة، وهي متطابقة لكل النماذج. ويمر ترافيق الاستدلال عبر PrivateLink داخل VPC الخاصة بالعميل، كما أن النموذج بلا خوادم (serverless) يُغني عن امتلاك أسطول GPU خاص يمثل نقطة فشل.

أما الطبقة العليا فهي «الغلاف التشغيلي» (harness) الخاص بـ DXC نفسها. بُنيت عملية التنسيق على LangGraph مفتوح المصدر: وكيل مشرف يقسّم المهمة ويوزعها على وكلاء متخصصين. ويحتوي الغلاف أيضًا على السياق التشغيلي المستمد من 60 عامًا من أدلة التشغيل (runbooks) وبيانات ITSM، وفحص السياسات عند كل طلب، وسجل الإجراءات.

والتفصيل المهم هو أين يمر الحد الفاصل. تُرشّح Guardrails مدخلات النموذج ومخرجاته، لكنها لا تستطيع تقييد ما يحق للوكيل فعله على الخادم. وهذا ما يقدر عليه الغلاف التشغيلي فقط، لأنه يعتمد على سياق العميل ومسؤوليته.

كيف يبدو الأمر في حادثة واحدة

في بيئة تجريبية لشركة طيران خيالية، تنفد المساحة على الخادم FlightOps ولا يفيد دليل التشغيل. يرى CIO التنبيه كخطر على الأعمال، بينما يتلقى مهندس Linux البيانات نفسها بتفاصيلها التقنية. يضع المشرف خطة ويستدعي الوكلاء Metrics وLinux System وITSM. يؤكد الأول أن القرص ممتلئ بنسبة 99% ويشير إلى مقالات من قاعدة المعرفة، ويعثر الثاني على ملف مؤقت واحد بحجم 5 غيغابايت.

ثم تأتي اللحظة الحاسمة: يعرض الوكيل الخطة كاملة، ولا يُنفَّذ شيء حتى يوافق المهندس. يستطيع التشخيص بحرية، أما تغيير بيئة الإنتاج فلا يكون إلا بموافقة مسجّلة. ويُنشئ الغلاف التشغيلي السجل (ما الذي شُغّل، وأين، ومن اعتمده، ومتى)، وليس روايةً من الوكيل نفسه.

وتُنظَّم الصلاحيات في أربع مراحل: المراقبة، والاقتراح، والتنفيذ بموافقة، والتنفيذ ضمن نطاق محدد. تبدأ كل شخصية (persona) بوضع القراءة فقط، وتوسيع الصلاحيات قرار واعٍ يتم مرحلة واحدة في كل مرة.

الأرقام وكيف نتعامل معها

منذ الإتاحة العامة (GA) في مارس 2026، تخدم OASIS ‏12 شخصية تشغيلية (Linux وWindows وSAP والشبكات والنسخ الاحتياطي وAWS وAzure وغيرها). وبحسب DXC، انخفض متوسط زمن الحل بنسبة 95% على 56 سيناريو تم قياسها. فحادثة نظام الملفات كانت تستغرق 53–90 دقيقة، وأصبحت 3–6. ومشكلات قواعد البيانات: من 2–3 ساعات إلى 5–12 دقيقة. وإدارة المشكلات المعقدة (problem management): من 2–6 أيام إلى 8–10 دقائق. ودقة التشخيص 92% فأكثر قياسًا بتقييم كبار المهندسين.

ينبغي التعامل مع هذه الأرقام بحذر. فهذا منشور مشترك بين AWS والمورّد، ولا يوجد تحقق مستقل، ومنهجية القياس «قبل/بعد» غير معلنة، كما أن دقة 92% تعني أن التشخيص قد يكون خاطئًا في حالة من كل اثنتي عشرة. لذلك فإن الموافقة البشرية هنا ليست إجراءً شكليًا.

الخلاصة العملية لمن يبنون وكلاء لبيئات الإنتاج:

• اجعلوا اختيار النموذج والتنسيق وبيئة النشر قرارات مستقلة. عندها يصبح تعطل المزوّد أو إيقاف نموذج (deprecation) مجرد تعديل في التوجيه. لكن تساوي واجهات API لا يعني تساوي السلوك: قبل إدخال نموذج جديد في التوجيه، اختبروه على مجموعات مهامكم الخاصة.
• لا تثقوا بأن النموذج سيقيّد نفسه. يجب أن تعيش الصلاحيات ومراحل الاستقلالية والتدقيق خارج النموذج، في الشيفرة والسياسات.
• ابدؤوا بوضع القراءة فقط ووسّعوا الاستقلالية حسب المهام، لا افتراضيًا.
• انتبهوا إلى الارتباط بالمزوّد: المخطط كله يعتمد على Bedrock، ومجموعة النماذج المتاحة تتوقف على منطقة AWS.

الدرس الرئيسي لا يتعلق بخدمة سحابية بعينها. فأمان الوكيل يحدده ما يُسمح له بفعله، لا مدى ذكاء النموذج. وما دام هذا الحد لم يُرسم بوضوح، فمن المبكر توسيع نطاق الوكلاء على الأنظمة الحية.