Mesterséges Intelligencia Központ
القائمة

كيف نربط أنظمة الشركة بالذكاء الاصطناعي؟

ترى Mesterséges Intelligencia Központ Kft.، شركة تطوير البرمجيات في بودابست بالمجر، أن الطريق إلى ذلك هو بناء النموذج اللغوي في سير العمل القائم عبر API: تبقى الأنظمة كما هي، والنموذج يستخرج، ويصنّف، ويلخّص، ويصوغ.

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

ماذا يعني ذلك عمليًا؟

يفسّر النموذج اللغوي الكبير (large language model، LLM) النصوص وينتجها. وفي الاستخدام لدى الشركات لا يعني نافذةَ محادثة منفصلة ينسخ إليها الموظفون النصوص ثم ينسخونها منها، بل خدمةً تستدعيها برامج الشركة نفسها عبر واجهة برمجية، أي عبر API (application programming interface). يتلقى النموذج البيانات التي تحتاجها المهمة، وينجز العمل اللغوي، ثم ينقل البرنامج النتيجة إلى النظام المناسب، بعد التحقق منها وتسجيلها.

خمس عمليات لغوية تتكرر في كل تكامل تقريبًا:

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

ثلاثة أنماط للتكامل

API وwebhook

لدى معظم أنظمة الشركات (CRM، وERP، والمتجر الإلكتروني، وبرنامج الفوترة، والبريد الإلكتروني) واجهة API يستطيع برنامج آخر من خلالها أن يقرأ منها البيانات أو يكتبها فيها. أما webhook فهو عكس ذلك: إذ يُخطر النظامُ نفسه عنوانًا محددًا مسبقًا عندما يحدث شيء ما، كوصول طلب أو رسالة. ويتكوّن أبسط تكامل للذكاء الاصطناعي من هذين العنصرين: حدثٌ يُطلق خدمة خاصة بنا، تستدعي API النموذج اللغوي، وتتحقق من النتيجة، ثم تكتبها عبر API النظام المستهدف. وفي هذا النمط لا يصل النموذج مباشرة إلى أيّ من أنظمة الشركة؛ فشيفرتنا هي التي تتولى كل شيء، وهناك يتقرّر ما الذي يجوز أن يصل إلى النموذج، وما الذي يجوز أن يعود منه.

استدعاء الدوال (tool use)

استدعاء الدوال (ويُسمّى لدى Anthropic باسم tool use، أي استخدام الأدوات) يتيح للنموذج أن يقرّر بنفسه متى يحتاج إلى معلومة أو عملية. يصف المطوّر للنموذج الدوال المتاحة، مثل «الاستعلام عن حالة الطلب»، ويعيد النموذج بناءً على السؤال استدعاءً منظَّمًا بالمعاملات اللازمة. وبحسب وثائق المزوّدين الكبار الثلاثة جميعًا، فإن التطبيق هو الذي يشغّل الدالة، لا النموذج: ففي وثائق OpenAI تعمل الشيفرة في جانب التطبيق، وبحسب Anthropic ينفّذ التطبيقُ الأدوات الخاصة به، وتنص وثائق Google Gemini على أن النموذج لا ينفّذ الدالة بنفسه. ومن هنا ينبع أهم مبادئ التصميم: التحقق من الصلاحيات يقيم في شيفرتنا، ولا يتوقف على حسن سلوك النموذج. وتقدّم OpenAI وAnthropic أيضًا وضعًا صارمًا (strict) يضمن أن تتبع معاملات الاستدعاء المخطط المحدد بدقة؛ لكن وثائق Anthropic تنبّه في الوقت نفسه إلى أن النموذج قد يختلق أحيانًا، عند نقص البيانات، قيمة تبدو معقولة، ولذلك يجب على الشيفرة أيضًا التحقق من المعاملات.

Model Context Protocol (MCP)

MCP بروتوكول مفتوح يقدّم، بحسب مواصفته، طريقة موحّدة لربط التطبيقات التي تستخدم النماذج اللغوية بمصادر البيانات والأدوات الخارجية. وله ثلاثة أطراف: المضيف (host)، أي التطبيق الذي يستخدم النموذج اللغوي؛ والعميل (client) الذي يعمل داخله؛ والخادم (server) الذي يقدّم البيانات (resources)، وقوالب التعليمات (prompts)، والأدوات القابلة للاستدعاء (tools). والرسائل بصيغة JSON-RPC 2.0؛ والنسخة الحالية من المواصفة هي التي تحمل الرمز 2026-07-28 (تم التحقق في 17 أكتوبر 2026).

وميزة MCP أنه يكفي كتابة خادم لنظام ما مرة واحدة، ثم يمكن لعدة تطبيقات ذكاء اصطناعي استخدامه. ويمكن لكلٍّ من واجهة API لدى Anthropic، وواجهة API لدى OpenAI، وGemini API الاتصال بخوادم MCP بعيدة (تم التحقق في 17 أكتوبر 2026). ولا يحل البروتوكول كل مسائل الأمان: فبموجب مبادئ الأمان في المواصفة، يجب على التطبيق المضيف أن يطلب موافقة صريحة من المستخدم قبل كل استدعاء لأداة، لكن البروتوكول نفسه لا يستطيع فرض ذلك، بل على المنفِّذ أن يبنيه. وتنبّه OpenAI أيضًا إلى أن خادمًا خبيثًا قد يسرّب البيانات الحساسة التي تدخل سياق النموذج. ولذلك لا يُنظر في بيئة الشركات إلا في الخوادم الخاصة أو تلك الصادرة عن مزوّد موثوق.

النمطما يناسبهما يجب الانتباه إليه
API وwebhookالعمليات الثابتة القابلة للتوقع: كل رسالة وكل فاتورة تسلك المسار نفسهيجب التخطيط لكل خطوة مسبقًا، بما في ذلك معالجة الأخطاء وإعادة المحاولة
استدعاء الدوالإذا وجب على النموذج أن يجلب بيانات أو يبدأ عملية بحسب السؤالنطاق الدوال وصلاحياتها؛ وقد يقدّم النموذج معاملًا خاطئًا أيضًا
MCPإذا وجب أن تصل عدة تطبيقات ذكاء اصطناعي إلى النظام نفسهخوادم موثوقة فقط؛ والموافقة قبل استدعاءات الأدوات

فيمَ يمكن استخدامه؟ المهام المعتادة

المجالالمهمةالنمط المعتادالموافقة البشرية
المستنداتاستخراج بيانات الفاتورة وإشعار التسليم والعقد ومطابقتها مع الطلبAPI، بمخرجات وفق مخطط ثابتعند وجود تباين أو استخراج غير مؤكد
البريد الإلكترونيتصنيف الرسائل الواردة وتحويلها، ومسودة الردwebhook وAPIقبل إرسال الرد
CRMتلخيص تاريخ العميل، واقتراح الخطوة التاليةاستدعاء الدوال بصلاحية القراءةلا حاجة إليها، لأنه مجرد اقتراح
ERPأسئلة عن البيانات بلغة يومية عادية، وإعداد التقاريراستدعاء الدوال بصلاحية القراءةإذا كانت العملية ستعدّل البيانات
المتجر الإلكترونيأوصاف المنتجات، والترجمة، وبحث أدقAPIقبل نشر النص
المعرفة الداخليةأسئلة وأجوبة من اللوائح والأدلةRAGلا حاجة إليها، إذا أشارت الإجابة إلى المصدر

ويمكنكم القراءة بمزيد من التفصيل عن خدماتنا في صفحة دمج الذكاء الاصطناعي، وعن العمليات المؤتمتة الممتدة عبر عدة أنظمة في صفحة أتمتة العمليات، وعن الذكاء الاصطناعي المدمج في أنظمة ERP وCRM في صفحة برمجيات الأعمال.

تدفق البيانات وحمايتها: ما الذي يذهب إلى أين؟

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

ماذا يقول المزوّدون؟

جوانب GDPR

إذا وصلت بيانات شخصية إلى النموذج، فإن معالجتها تخضع لـGDPR. ويكون مزوّد النموذج حينئذٍ في العادة معالِجًا للبيانات، ولذلك يلزم معه عقد وفق الفقرة (3) من المادة 28 من اللائحة العامة لحماية البيانات؛ وتفرض المادة 5 تقليل البيانات، أما المادة 25 فتذكر استخدام الأسماء المستعارة (pseudonymisation) مثالًا بين أدوات حماية البيانات منذ التصميم. وعمليًا يعني ذلك ما يلي:

ونكتب عن نقل البيانات إلى خارج الاتحاد الأوروبي، والشفافية، وAI Act في مقال AI Act وGDPR: إلامَ ننتبه في روبوت محادثة الشركة؟. هذه معلومات إرشادية وليست استشارة قانونية.

أين تلزم الموافقة البشرية؟

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

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

ومن المخاطر المستقلة حقن الموجِّهات (prompt injection): فإذا قرأ النموذج محتوى خارجيًا، كرسالة واردة أو مستند مرفوع أو صفحة ويب، فقد يتضمن نصًا يحاول التأثير فيه كأنه تعليمات. وتوصي OWASP في مواجهته بالحد الأدنى اللازم من الصلاحيات، والموافقة البشرية قبل العمليات ذات الامتيازات، ومعالجة المحتوى الخارجي بشكل منفصل، مع وسمه بأنه غير موثوق.

الاختبار والمراقبة

لا يكون دمج الذكاء الاصطناعي جيدًا لأنه مقنع في العرض التوضيحي، بل لأنه يعمل جيدًا على نحو قابل للقياس على المواد الحقيقية للشركة. وبحسب دليل التقييم لدى OpenAI، يجب أن تتضمن بيانات الاختبار حالات نموذجية وحدّية ومضلِّلة عمدًا، ويجب إعادة تشغيل التقييم عند كل تغيير؛ وتوصي Anthropic بـمعايير نجاح محددة وقابلة للقياس وبمجموعة اختبار تعكس المهام الحقيقية. وهكذا نبنيها:

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

أيّ نموذج نختار؟

لا يوجد نموذج جيد بالقدر نفسه في كل المهام، ولذلك فالاختيار مسألة قياس، لا ولاء لعلامة تجارية. ومعاييرنا:

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

علامَ تتوقف التكلفة؟

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

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

خطوة خطوة: هكذا نبدأ

  1. اختيار مهمة واحدة: عمل متكرر ذو طابع لغوي، بهدف قابل للقياس، مثل تصنيف الشكاوى الواردة.
  2. رسم تدفق البيانات: من أين تأتي البيانات، وما الذي يجوز أن يذهب إلى النموذج، وإلى أين تذهب النتيجة، ومن يوافق عليها.
  3. العيّنات ومجموعة التقييم: أمثلة حقيقية مجهَّلة مع النتيجة المتوقعة.
  4. النموذج الأولي: مقارنة النماذج المرشّحة على العيّنات، قبل أي ربط فعلي.
  5. الربط: API، أو webhook، أو استدعاء الدوال، أو MCP، مع الصلاحيات ومعالجة الأخطاء وتسجيل الأحداث.
  6. الإطلاق التجريبي: في نطاق ضيق، مع موافقة بشرية على كل خطوة؛ ونتعلم من التصحيحات.
  7. التوسيع والتشغيل: حيث يثبت القياس ذلك، تضيق دائرة الموافقة؛ وتستمر المراقبة وتبديل النماذج.

الأخطاء المعتادة

الأسئلة الشائعة

أيّ نموذج نختار؟

النموذج الذي يحقق على نحو قابل للقياس أفضل أداء في المهمة المعنية على عيّنات الشركة نفسها، برسوم مقبولة وشروط مناسبة لمعالجة البيانات. ونحن نعمل بنماذج OpenAI وAnthropic وGoogle، ونقارن المرشّحين على أمثلة الشركة، ولأن النموذج في طبقة منفصلة، يمكن تعديل القرار لاحقًا.

هل إرسال بيانات الشركة إلى خدمة ذكاء اصطناعي آمن؟

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

هل يجب أن نستبدل أنظمتنا القائمة؟

لا. يقوم التكامل على API الأنظمة القائمة، أو webhook، أو قاعدة البيانات، أو تصدير الملفات، وتعود النتيجة إلى حيث كان الموظفون يعملون من قبل. وإذا لم تكن لنظام قديم واجهة برمجية، فإننا ندرس الطريق الذي يمكن الوصول به إلى بياناته بأمان.

ما هو MCP؟

إن Model Context Protocol بروتوكول مفتوح يربط بطريقة موحّدة التطبيقاتِ التي تستخدم النماذج اللغوية بمصادر البيانات والأدوات الخارجية. وهو مفيد إذا وجب أن تصل عدة تطبيقات ذكاء اصطناعي إلى النظام نفسه. وفي بيئة الشركات من المستحسن ألا يُستخدم إلا مع خادم موثوق، ومع الموافقة قبل استدعاءات الأدوات.

ماذا يحدث إذا أخطأ الذكاء الاصطناعي؟

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

كيف نساعدكم؟

نربط بالذكاء الاصطناعي كل ما هو موجود: نربط النماذج اللغوية من OpenAI (ChatGPT) وAnthropic (Claude) وGoogle (Gemini) بالأنظمة القائمة لدى الشركات. الاستشارة الأولى مجانية؛ ونقيس حجم التطوير بنقاط COSMIC الوظيفية، ومنه يُعَدّ العرض والجدول الزمني. ونوقّع عند الطلب اتفاقية عدم إفصاح (NDA)، وبعد التسليم نتولى التشغيل والصيانة أيضًا، بما في ذلك مراقبة عمل النموذج. وتخضع الشيفرة المصدرية وحقوق الاستخدام لأحكام العقد.

التفاصيل في صفحة دمج الذكاء الاصطناعي. وإن كانت لديكم عملية تودّون ربطها بالذكاء الاصطناعي، فاكتبوا لنا عبر بيانات التواصل الواردة في صفحة التواصل.

المصادر