وكلاء AI خاضعون للحوكمة عبر الموردين — كل استدعاء مفوَّض وموثَّق

المشكلة

يدخل وكلاء AI من موردين مختلفين إلى العمليات واحدًا تلو الآخر: وكيل assurance من مورد، ووكيل شبكة من مورد آخر، ومساعد تذاكر من مورد ثالث. يحتاج كل منهم إلى الوصول إلى الأنظمة، وأبسط طريقة هي منحه صلاحيات دائمة. وعندها لا يستطيع أحد لاحقًا أن يحدد أي وكيل فعل ماذا، وبأي صلاحية، ولماذا.

ما الذي يتغيّر

1. يُسجَّل كل وكيل مع مالك وإصدار والوظائف المسموح له بتنفيذها.
2. يمتد عطل عبر عدة مجالات؛ فيعثر وكيل الـ assurance على الوكلاء المسؤولين عن الشبكة والـ OSS حسب الغرض، لا عبر عنوان مثبّت في الكود.
3. يمر كل استدعاء بين الوكلاء عبر الـ Trusted Gateway، الذي يفوّضه لذلك الغرض ويحمي من الأوامر النصية الحرة ومن حقن البيانات.
4. تنتظر الإجراءات التي يصنّفها المشغّل حساسةً موافقة شخص؛ وتُسجَّل الموافقة إثباتًا، ولا تفوّض البوابة إلا ذلك الإجراء الواحد.
5. يُسجَّل كل استدعاء مفوَّض إثباتًا لأغراض التدقيق.

ما القيمة

• يعمل وكلاء من موردين مختلفين معًا دون وصول دائم إلى أنظمتكم.
• ترى فرق الأمن والتدقيق من فعل ماذا، وبأي صلاحية.
• يُضاف الوكلاء واحدًا تلو الآخر، دون إعادة بناء منظومة العمليات.
• التدقيق حسب مجال TM Forum eTOM — Assurance و Fulfillment و Billing — استعلام واحد: كل dispatch يحمل عملية eTOM الخاصة به.

ما الذي يقدّمه MEF.DEV

Agent Fabric-T مع الـ Trusted Gateway بوصفه نقطة إنفاذ السياسات (policy enforcement point)، و Knowledge Graph الذي يمكنه أن يزوّد الوكلاء بالعلاقات والقواعد المستمدة من بياناتكم، مع مصدر كل معلومة (وهو يعمل في Product Offering AI لباقات تعرفة WideCoup Convergent BSS؛ أما نموذج الشبكة فهو نهج نقترحه، لا مجموعة بيانات جاهزة). وموافقة الإنسان على الإجراءات الحساسة جزء من Enterprise Modules.