استدعاء الأدوات، واجهات برمجة التطبيقات، والتكامل المؤسسي

تخيل أن فريقك المالي بدأ بالفعل في استخدام الذكاء الاصطناعي للمساعدة في عملية إغلاق الدفاتر الشهرية. المساعد الرقمي الحالي ذكي بما يكفي لشرح سبب تعليق فاتورة معينة. ولكن عندما يسأل الفريق: "هل يمكن لهذا الذكاء الاصطناعي إصلاح الحالة مباشرة؟"، لا توجد إجابة بعد. بيانات الفاتورة موزعة بين نظام تخطيط موارد المؤسسة (ERP)، وجداول بيانات الموردين، ورسائل التأكيد الإلكترونية. يجب التحقق من أمر الشراء (PO)، ومقارنة إيصالات استلام البضائع، وإذا كانت هناك مشكلة، يجب فتح حالة في نظام سير العمل. كل هذه الخطوات لا تزال يدوية.

السؤال الذي يطرح نفسه بعد ذلك ليس حول مدى تطور نموذج اللغة، بل: كيف يمكن للذكاء الاصطناعي أن يساعد حقًا في تنفيذ هذه العملية، وليس مجرد شرحها؟

هذه هي المشكلة التي تواجهها العديد من الشركات اليوم. لقد قاموا بالفعل بتجارب أولية جذابة للذكاء الاصطناعي، لكن القيمة التجارية لم تتحقق بعد لأن الذكاء الاصطناعي يتوقف عند التوصيات. لم يتمكن الوكيل (Agent) بعد من لمس الأنظمة الفعلية. في الواقع، بدون القدرة على سحب البيانات من ERP، أو التحقق من الحالة في CRM، أو تحديث تذكرة في ITSM، فإن الذكاء الاصطناعي ليس سوى آلة إجابات لا تنفذ أي شيء أبدًا.

من الشرح إلى التنفيذ

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

هذه القدرة هي ما يسمى باستدعاء الأدوات (Tool Calling). لا يقوم النموذج فقط بتوليد النص، بل يختار ويستدعي قدرات خارجية لإنجاز العمل. يمكن أن تكون الأداة API إلى ERP أو CRM، أو استعلامًا إلى قاعدة بيانات، أو وظيفة لإنشاء تذكرة، أو موصلًا للبريد الإلكتروني، أو إجراءً لسير العمل في BPM، أو خدمة داخلية مثل مدقق السياسات ومحرك التسعير.

بدون استدعاء الأدوات، يصبح الوكيل مجرد محلل بارع في الكلام. مع استدعاء الأدوات، يبدأ الوكيل في التحول إلى منفذ يمكنه إنجاز العمل.

ليست كل الأدوات متساوية في المخاطر

هنا ترتكب العديد من المؤسسات خطأً. إنهم يعاملون جميع الأدوات كما لو كانت متشابهة، بينما في الواقع هناك فرق كبير من الناحية التشغيلية بين الأداة التي تقرأ البيانات فقط والأداة التي تغير حالة العمل.

الأدوات للقراءة فقط (Read-only) مثل التحقق من حالة الفاتورة، أو سجل العملاء، أو قراءة سياسات المشتريات، أو البحث في مقال معرفي، لها مخاطر منخفضة نسبيًا. على الرغم من أنها لا تزال بحاجة إلى التحكم في الوصول وتسجيل الدخول، إلا أن تأثير أخطائها يقتصر على المعلومات الخاطئة، وليس على تغيير البيانات المسبب للضرر.

في المقابل، أدوات الإجراء (Action) مثل إنشاء مورد جديد، أو تغيير عنوان العميل، أو إصدار أمر شراء، أو إغلاق تذكرة، أو إرسال استرداد، أو تنفيذ تغيير في التكوين، لها مخاطر أعلى بكثير. هذه الإجراءات لها تأثير مباشر على عمليات الشركة ورقابتها ومساءلتها.

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

السيطرة تزداد صرامة كلما اقتربنا من الإجراء

بمجرد أن يتمكن الوكيل من الكتابة إلى الأنظمة، يجب على الشركة التعامل مع كل استدعاء أداة كما لو كان إجراءً تشغيليًا رسميًا. يجب أن يكون واضحًا على الأقل من هو الوكيل الذي يقوم بالاستدعاء، وباسم من، وما هي البيانات المستخدمة، وما هي الأداة التي تم استدعاؤها، وما هي المعلمات التي تم إرسالها، وما هي النتيجة التي تم تلقيها، وما إذا كان هناك موافقة أو فحص سياسة قبل التنفيذ.

في عملية الإغلاق المالي، على سبيل المثال، يختلف الوكيل الذي يقوم فقط بإعداد مسودة قيد محاسبي اختلافًا جوهريًا عن الوكيل الذي يقوم بالفعل بترحيل القيد إلى ERP. الأول قد يكون كافيًا مع وجود إنسان في الحلقة (Human-in-the-loop). أما الثاني فسيحتاج بالتأكيد إلى ضوابط أكثر صرامة، وربما لا يكون مناسبًا حتى للمراحل المبكرة.

في المشتريات، الوكيل الذي يقرأ العقود ويقترح مسار الشراء هو شيء. والوكيل الذي يقوم بتفعيل مورد جديد أو إصدار أمر شراء هو شيء آخر تمامًا.

المبدأ بسيط: كلما زاد التأثير التجاري لاستدعاء الأداة، زادت الحاجة إلى التحقق من الصحة، وتنفيذ السياسات، وقابلية التدقيق.

واجهات برمجة التطبيقات (API) كمسار آمن

إذا كان استدعاء الأدوات هو آلية العمل، فإن API هو المسار الأكثر صحة لربط الوكيل بأنظمة المؤسسة. توفر API واجهة منظمة وموثقة وقابلة للتحكم. لا يحتاج الوكيل إلى "اللعب" على الشاشة مثل الإنسان. يكفي أن يستدعي نقطة النهاية (Endpoint) التي تم توفيرها بالفعل لقراءة أو كتابة البيانات وفقًا لقواعد النظام.

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

واجهة المستخدم ليست عقد تكامل مستقر. تتغير شاشات العرض، وتنتقل الحقول، وتتبدل التسميات، ويمكن أن يختلف تدفق النقرات بين الإصدارات. الوكيل الذي يعتمد على واجهة المستخدم سيكون هشًا. كما أن التحكم يصعب فرضه لأنه على مستوى واجهة المستخدم يصعب تقييد الوكيل بإجراءات معينة دون منحه وصولًا واسعًا جدًا. مسار التدقيق (Audit trail) أسوأ لأن استدعاءات API يمكن عادةً تسجيلها بشكل صريح، بينما أتمتة واجهة المستخدم تكون آثارها غامضة. التحقق من صحة المخطط (Schema validation) أضعف أيضًا لأن API تسمح بإدخال وإخراج تم التحقق منه رسميًا.

لهذا السبب، إذا كانت الشركة جادة في بناء نموذج تشغيلي قائم على الوكيل (Agentic Operating Model)، فيجب أن تكون API هي المسار الرئيسي. يتم استخدام أتمتة واجهة المستخدم فقط بشكل محدود، مع ضوابط تعويضية واضحة، عندما لا يكون تحديث التكامل قد اكتمل بعد.

كل نقطة نهاية كنقطة تحكم

ليست كل API آمنة للتطبيقات العادية آمنة تلقائيًا للوكيل. يعمل الوكيل بأنماط مختلفة: أسرع، وأكثر تكرارًا، وأحيانًا أكثر استقلالية. لذلك، يجب التعامل مع كل نقطة نهاية يمكن للوكيل استدعاؤها كنقطة تحكم.

هناك على الأقل أربعة تخصصات أساسية. أولاً، الصلاحيات (Permission): يجب أن يتمتع الوكيل بالحد الأدنى من حقوق الوصول اللازمة. لا تستخدم حساب خدمة عامًا (Generic Service Account) بوصول واسع فقط لتسريع التجربة الأولية. ثانيًا، تحديد المعدل (Rate Limit): يمكن للوكيل توليد حجم كبير من الاستدعاءات، خاصة في حالة حدوث حلقة (Loop) أو إعادة محاولة (Retry) سيئة. ثالثًا، التحقق من صحة المخطط (Schema Validation): يجب التحقق بدقة من المدخلات من الوكيل. إذا كانت الأداة تتوقع customer_id و refund_reason و amount، فيجب أن يتوافق الحمولة (Payload) مع المخطط، وليس نصًا حرًا غامضًا. رابعًا، تسجيل التدقيق (Audit Logging): يجب تسجيل كل استدعاء، ليس فقط للأمان ولكن أيضًا للعمليات، والتحقيق في الحوادث، والتحسين المستمر.

في الممارسة المؤسسية، تصبح مكونات مثل بوابة API (API Gateway) ومحرك السياسات (Policy Engine) مهمة جدًا. تساعد بوابة API في إدارة المصادقة، وتحديد المعدل، وقابلية المراقبة (Observability)، والتوجيه (Routing). يضمن محرك السياسات أنه حتى لو "أراد" الوكيل القيام بشيء ما، يجب أن يظل هذا الإجراء خاضعًا لقواعد العمل وضوابط المخاطر.

تخيل وكيل خدمة العملاء يريد معالجة استرداد. التصميم السليم ليس منح الوكيل وصولًا مباشرًا إلى وظيفة الاسترداد الكاملة. التصميم الأكثر أمانًا هو أن يقوم الوكيل باستدعاء نقطة نهاية للتحقق من الأهلية (Eligibility Check)، ويتحقق محرك السياسات من الحدود وتاريخ العميل، وإذا استوفى الشروط، يمكن معالجة الاسترداد الصغير باستقلالية محدودة (Bounded Autonomy)، وإذا تجاوز عتبة معينة، يطلب النظام تلقائيًا موافقة المشرف، ويتم تسجيل جميع الخطوات. بهذا النمط، لا تصبح API مجرد موصل تقني. بل تصبح مسارًا آمنًا يفرض الانضباط التشغيلي.

كتالوج القدرات، وليس قائمة الموصلات

بمجرد أن يزداد عدد الأدوات، تحتاج الشركة إلى أكثر من مجرد توثيق التكامل. إنهم بحاجة إلى سجل أدوات (Tool Registry): كتالوج مركزي يشرح الأدوات المتاحة، ووظائفها التجارية، ومن يمكنه استخدامها، ومخطط الإدخال والإخراج، والنظام المستهدف، ومستوى المخاطر، ووضع الوصول (قراءة أو كتابة)، والتبعيات، والضوابط الوقائية (Guardrails) المطبقة.

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

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

بالنسبة للمؤسسات، يحتوي السجل المفيد عادةً على اسم ووصف الأداة، والمالك التجاري والمالك التقني، والنظام المستهدف، وفئة المخاطر، ومخطط الإدخال والإخراج، ونموذج الصلاحيات، ومتطلبات الموافقة، ومعدل الاستخدام واتفاقية مستوى الخدمة (SLA)، وإصدار الأداة، والحالة التشغيلية، وخطافات التدقيق وقابلية المراقبة.

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

الأخطاء الأكثر شيوعًا

تفشل العديد من برامج الوكيل ليس لأن النموذج ضعيف، ولكن لأن أنماط التكامل كانت خاطئة منذ البداية. هناك بعض الأنماط المضادة (Anti-patterns) الشائعة جدًا.

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

عدم التمييز بين أدوات القراءة فقط وأدوات الإجراء يمثل مشكلة أيضًا. إذا تم التعامل مع جميع الأدوات بالتساوي، فستصبح الحوكمة فوضوية. يمكن منح أدوات القراءة فقط استقلالية محدودة بشكل أسرع. يجب أن تمر أدوات الإجراء عبر تصنيف المخاطر ومنطق الموافقة وقابلية مراقبة أكثر صرامة.

تحدث أيضًا مشكلة الترميز الثابت للتكامل في كل وكيل. يبني كل فريق موصله الخاص إلى ERP أو CRM أو أنظمة التذاكر. والنتيجة هي الازدواجية، وعدم تناسق المخططات، وعدم انتظام ضوابط الوصول، وارتفاع تكاليف الصيانة. هذا هو الطريق السريع نحو انتشار الوكيل غير المنضبط (Agent Sprawl).

إهمال تنفيذ السياسات في وقت التشغيل (Runtime) أمر شائع أيضًا. تقوم العديد من المؤسسات بتصميم السياسات في المستندات، ولكنها لا تدمجها في مسار التنفيذ. ونتيجة لذلك، يمكن للوكيل من الناحية الفنية القيام بإجراءات كان ينبغي تقييدها وفقًا للسياسة.

عدم التحضير لخطة بديلة (Fallback) عند فشل الأداة أمر خطير أيضًا. ستفشل استدعاءات الأدوات. قد يحدث انتهاء مهلة (Timeout) لـ API. قد يتغير المخطط. قد يتعطل النظام المستهدف. إذا لم يكن لدى الوكيل خطة بديلة واضحة، فقد يتوقف في منتصف العملية أو يحاول بشكل متكرر دون سيطرة.

مبدأ بسيط

إذا كان لا بد من تلخيص هذا الموضوع بأكمله في مبدأ واحد، فإن المبدأ هو: لا يجوز للوكيل التصرف إلا من خلال واجهة قابلة للتدقيق. ليس من خلال وصول جامح إلى واجهة المستخدم، وليس من خلال حساب خدمة واسع جدًا، وليس من خلال أداة ليس لها مخطط واضح، وليس من خلال تكامل غير مسجل.

الواجهة القابلة للتدقيق تعني وجود هوية، وأذونات، وعقد إدخال وإخراج، وتنفيذ سياسات، وتسجيل، وقابلية مراقبة، وآلية إيقاف في حالة وقوع حادث.

هذا المبدأ مهم لأن الذكاء الاصطناعي الوكيل في النهاية لا يتعلق بذكاء اصطناعي ذكي، بل بذكاء اصطناعي يمكن الوثوق به للمشاركة في إدارة الشركة.

بالنسبة لمدير تكنولوجيا المعلومات (CIO)، هذا يعني أن أجندة التكامل وتحديث API أصبحت أكثر استراتيجية مما كانت عليه من قبل. بالنسبة لمدير العمليات (COO)، هذا يعني أن إعادة تصميم العمليات يجب أن تأخذ في الاعتبار نقاط الإجراء التي تستحق أن تكون مفتوحة للوكيل. بالنسبة لمدير الموارد البشرية (CHRO) وقائد التحول، هذا يعني أن تغيير الأدوار البشرية سيتأثر بشكل كبير بالأدوات المتاحة، ومدى أمان تصرف الوكيل، وأين يظل الإنسان نقطة التحكم.

السؤال الذي يجب أخذه إلى المنزل: هل مشهد API وطبقة التكامل في شركتك جاهز ليصبح مسارًا للتنفيذ الرقمي، أم أنه لا يزال مصممًا فقط للتطبيقات التقليدية؟ ما هي الإجراءات التشغيلية التي تستحق حقًا أن تكون مفتوحة للوكيل، وأيها يجب أن تظل تحت السيطرة البشرية؟ إذا بدأ الوكيل في تولي الإجراءات الروتينية من خلال الأدوات و API، فأين ستنتقل أدوار الخط الأمامي والمشرفين؟ هل نبني وكيلًا يمكن توسيع نطاقه على مستوى المؤسسة، أم مجرد عرض تجريبي يعمل لأن التحكم لا يزال يدويًا؟