تسعى الشركات الكبرى اليوم إلى الاستفادة من وكلاء الذكاء الاصطناعي لربط التطبيقات، أتمتة المهام، والوصول إلى البيانات بسرعة أكبر. لكن هذا التوسع يضع ضغوطاً جديدة على الأنظمة المؤسسية التي بُنيت في الأصل للتعامل مع طلبات تشغيلية واضحة ومحددة، لا مع أدوات مستقلة قادرة على تنفيذ آلاف الاستدعاءات المتتابعة في وقت قصير. في هذا السياق، تطرح SAP مقاربة تقوم على الحوكمة والتنظيم بدلاً من ترك الاتصالات مفتوحة بلا ضوابط.
جوهر الموقف الذي تطرحه الشركة هو أن فرض حدود على استخدام واجهات البرمجة ليس إجراءً استثنائياً، بل ممارسة معتادة في برمجيات الأعمال السحابية. فمعظم مزودي المنصات الكبيرة يطبقون منذ سنوات حدوداً على عدد الطلبات، وضوابط على الاستهلاك، ومنعاً لاستخدام الواجهات الداخلية غير المعلنة. الجديد هنا ليس المبدأ نفسه، بل توحيد هذه القواعد ضمن سياسة واحدة تشمل عدداً أكبر من منتجات SAP في وقت يتوسع فيه استخدام الذكاء الاصطناعي الوكيل.
ما الذي تغير في سياسة واجهات البرمجة
توضح SAP أن السياسة الأخيرة لا تضيف حظراً جديداً بقدر ما تجمع قواعد كانت مطبقة سابقاً بشكل متفرق داخل منتجات متعددة. هذا التوحيد يأتي مع زيادة اعتماد الشركات على خدمات سحابية متعددة المستأجرين، حيث يمكن لأي زيادة حادة وغير منضبطة في الاستدعاءات أن تؤثر في الأداء والاستقرار والأمان.
من منظور تشغيلي، ترى الشركة أن الواجهات التي صُممت لمعالجة العمليات اليومية، مثل قراءة طلب بيع أو تسجيل حركة مخزنية أو تشغيل دفعة مالية، ليست مهيأة بطبيعتها لكي تصبح قناة لاستخراج واسع للبيانات أو لاستكشاف بنية النظام بواسطة وكلاء مستقلين. لذلك، فإن ضبط الاستهلاك أصبح جزءاً من إدارة البنية التحتية، وليس مجرد قرار تجاري.
الفرق بين الواجهات المخصصة والواجهات الداخلية
إحدى النقاط الحساسة في النقاش تتعلق بالمطورين والعملاء الذين بنوا على مدى سنوات واجهات مخصصة داخل بيئاتهم. هنا تميز SAP بين نوعين مختلفين تماماً. النوع الأول هو الواجهات التي يطورها العميل داخل نطاقه الخاص لأغراض التكامل أو التوسعة أو الترحيل، وهذه لا تستهدفها السياسة الجديدة بشكل مباشر. أما النوع الثاني فهو الواجهات الداخلية التابعة للشركة نفسها، غير المنشورة وغير المعتمدة للاستخدام الخارجي، وهي التي تضعها السياسة ضمن نطاق التقييد أو المنع.
هذا التفريق مهم لأن كثيراً من المؤسسات تعتمد على تطويرات داخلية متراكمة منذ سنوات، ولا ترغب في رؤية هذه الاستثمارات تصبح بلا قيمة. الرسالة الأساسية هنا أن حرية التخصيص داخل النطاق المخصص للعميل لا تُسحب، لكن الاعتماد على مكونات داخلية لم تُصمم أصلاً كواجهات عامة يظل خياراً عالي المخاطر، خصوصاً مع انتقال الأنظمة إلى نماذج تشغيل سحابية أكثر صرامة.
لماذا يغير وكلاء الذكاء الاصطناعي نمط استخدام الأنظمة
الفرق بين أداة تكامل تقليدية ووكيل ذكاء اصطناعي ليس فرقاً في السرعة فقط، بل في طبيعة الاستخدام. أدوات التكامل المعتادة تنقل البيانات من نظام إلى آخر وفق مسار معروف مسبقاً. أما الوكيل الذكي فيحاول فهم العلاقات بين الكيانات والحقول والخطوات التشغيلية لكي يبني سياقاً يسمح له باتخاذ قرارات أو تنفيذ مهام مركبة.
عندما يقرأ الوكيل بيانات أوامر البيع، وبنود الطلب، والقيم المالية، وعلاقاتها بالتسليم والفوترة ودفاتر الحسابات، فهو لا يستهلك بيانات تشغيلية فحسب، بل يستوعب أيضاً البنية المنطقية التي يقوم عليها النظام. هذا النوع من القراءة المتتابعة والعميقة يخلق حملاً مختلفاً على واجهات البرمجة، وقد يحول قنوات مصممة للمعاملات المحدودة إلى مسارات استكشاف واسعة النطاق.
من هنا ترى SAP أن المسألة لا تتعلق فقط بحق الوصول إلى البيانات، بل أيضاً بحماية النموذج التشغيلي والمعرفي للأنظمة المؤسسية من الاستخدام غير المنضبط أو الاستخراج المفرط.
مخاطر أمنية تتجاوز الأداء
الضغوط التقنية ليست التحدي الوحيد. فمع انتشار أدوات مفتوحة ومجتمعية لبروتوكولات ربط النماذج، مثل خوادم MCP التي يبنيها أطراف ثالثة، تظهر أسئلة جدية حول الأمان. البيئة الحالية تشهد هجمات على سلاسل الإمداد البرمجية، ومشكلات في إدارة الرموز السرية، وتوسيعاً مفرطاً للصلاحيات، إضافة إلى احتمالات حقن الأوامر أو التلاعب بالأدوات.
عند توصيل وكيل ذكاء اصطناعي بخادم وسيط غير محكوم جيداً، ثم منحه مساراً إلى أنظمة أعمال حساسة، يرتفع مستوى الخطر بشكل واضح. فالوكيل لا يعمل هنا كتطبيق مكتبي بسيط، بل كجهة تمتلك قدرة على الوصول المتكرر إلى بيانات تشغيلية ومالية وموارد بشرية. وإذا كانت أداة الربط نفسها ضعيفة أمنياً، فإن مساحة الهجوم تتسع بسرعة.
لهذا السبب، تربط SAP بين سياسة واجهات البرمجة وبين متطلبات الحد الأدنى للأمان في النشر المؤسسي، خاصة في ظل استمرار نضج هذه البروتوكولات والمعايير.
مشكلة الكلفة والكفاءة في الربط غير الواعي بالسياق
تنتقد الشركة أيضاً ما تعتبره اعتماداً مبالغاً فيه على بروتوكول MCP بوصفه حلاً كاملاً لتشغيل وكلاء الذكاء الاصطناعي داخل المؤسسات. من وجهة نظرها، هذا البروتوكول يحدد طريقة استدعاء الأداة، لكنه لا يمنح النموذج فهماً تلقائياً لسياق الأعمال أو ترتيب الخطوات أو آثار كل استدعاء على النظام.
النتيجة أن التنفيذ غير المدرك للسياق قد يؤدي إلى استهلاك ضخم للرموز الحاسوبية، وزيادة في عدد الاستدعاءات، وارتفاع مباشر في كلفة التشغيل. وتشير أمثلة تشغيلية طرحتها الشركة إلى أن استعلامات معينة داخل أنظمة الموارد البشرية يمكن أن تستهلك عدداً كبيراً جداً من الرموز عند تنفيذها عبر ربط تقليدي، بينما ينخفض هذا الرقم بشكل واضح عندما تُستخدم طبقة سياقية تعرف بنية البيانات والعلاقات التشغيلية مسبقاً.
هذه النقطة مهمة للشركات التي تتعامل مع آلاف العمليات يومياً، لأن الفرق في كلفة كل استعلام قد يتحول سريعاً إلى أثر مالي ملحوظ على مستوى المؤسسة كلها.
بديل SAP للانفتاح المنضبط
بدلاً من إغلاق الباب أمام التكامل الخارجي، تقول SAP إنها تعمل على فتح مسارات أكثر ضبطاً. في مقدمة هذه المسارات يأتي بروتوكول A2A الذي تراه مناسباً للوصول الخارجي المنظم إلى الوكلاء والأنظمة، إلى جانب بنية مرجعية منشورة للتكامل مع الشركاء. وتقدم الشركة أيضاً طبقات مساعدة مثل الرسوم المعرفية، وبيانات وصفية منظمة، ومنتجات بيانات جاهزة، بهدف تحويل الاتصال التقني الخام إلى تفاعل يفهم منطق الأعمال.
كما تشير إلى وجود خوادم MCP محكومة في بعض بيئات التطوير، مع نية التوسع إلى مزيد من الأدوات مستقبلاً. الرسالة هنا أن الانفتاح مقبول، لكن ضمن أبواب موثقة، بهويات واضحة، وصلاحيات محددة، وأدوات يمكن تدقيقها ومراقبتها.
وتعزز الشركة هذا الطرح عبر مشاركتها في المبادرات المعيارية المرتبطة بالوكلاء، بما في ذلك بروتوكولات التوافق والهوية والثقة بين الأنظمة المختلفة. وهذا يمنحها أساساً للقول إنها لا تقاوم المعايير المفتوحة، بل تحاول دفعها نحو مستوى جاهز للنشر المؤسسي.
ما الذي يعنيه ذلك للشركات
بالنسبة لفرق التقنية داخل المؤسسات، يبرز من هذا النقاش درس أساسي: لا يكفي أن يكون الربط بين النموذج والنظام ممكناً من الناحية التقنية، بل يجب أن يكون قابلاً للإدارة والقياس والتأمين. أي مشروع يعتمد على وكلاء الذكاء الاصطناعي للوصول إلى أنظمة تخطيط الموارد أو الموارد البشرية أو المشتريات يحتاج إلى تقييم دقيق لثلاثة عناصر: الواجهة المستخدمة، والوسيط الذي ينفذ الاتصال، والقدرة على فهم سياق الأعمال من دون توليد استدعاءات زائدة أو مخاطر أمنية غير ضرورية.
ومن المرجح أن يتكرر هذا النقاش في شركات برمجيات مؤسسية أخرى، لأن الضغوط نفسها لا تخص SAP وحدها. توسع الوكلاء الذكيين يعيد تعريف طريقة استهلاك واجهات البرمجة، ويجبر الموردين والعملاء معاً على إعادة التفكير في الحدود بين الانفتاح والاعتمادية.
خلاصة المشهد
ما تطرحه SAP يمكن اختصاره في فكرة واحدة: زمن توصيل وكلاء الذكاء الاصطناعي مباشرة بأي واجهة متاحة داخل الأنظمة المؤسسية يقترب من نهايته. المرحلة المقبلة ستعتمد أكثر على الحوكمة، والواجهات المعلنة، والطبقات السياقية، والبروتوكولات التي تأخذ الهوية والثقة والأداء في الاعتبار منذ البداية.
قد يختلف البعض مع تفاصيل السياسة أو توقيتها، لكن الاتجاه العام يبدو واضحاً. مع انتقال الذكاء الاصطناعي من دور المساعد إلى دور المنفذ والمشغل، تصبح الحماية التشغيلية والأمنية جزءاً من تصميم التجربة نفسها، لا طبقة لاحقة تضاف بعد انتشار الاستخدام.