كيف تختار شركة أو مستشار ذكاء اصطناعي لمشروعك؟

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

Chatbot شكله ممتاز ممكن يتعمل بسرعة.

السؤال الأصعب: هل الشخص أو الفريق ده يقدر ياخد مشكلة شركتك الحقيقية من workflow → architecture → integration → production → measurement؟

وده اللي أنا شخصيًا هقيّمه قبل التعاقد على مشروع AI.

ما تبدأش بسؤال: بتستخدموا أنهي Model؟

OpenAI وClaude وGemini والـLocal LLMs والـopen models كلها أدوات.

اختيار الـmodel مهم، لكنه يأتي بعد فهم المهمة.

لو consultant بدأ بـ:

"هنعمل المشروع باستخدام Model X."

قبل ما يفهم الـprocess والبيانات والمستخدمين والأنظمة والمخاطر، اسأله: ليه الـarchitecture اتحددت أصلًا قبل فهم المشكلة؟

السؤال الأقوى هو:

إيه الـbusiness process اللي بنحاول نحسنها، وإيه اللي لازم يحصل من أولها لآخرها؟

الإجابة ممكن تحتاج LLM.

ممكن تحتاج RAG.

ممكن تحتاج AI Agent.

وممكن الجزء الأكبر يكون Integration وsoftware تقليدي.

وأحيانًا التوصية الصحيحة تكون استخدام AI أقل، مش أكثر.

1. هل يقدر يفهم الـBusiness Workflow؟

قبل مناقشة architecture، المفروض يقدر يرسم العملية الحالية.

مثلًا:

Customer request → الموظف يفتح CRM → يراجع نظام تاني → ياخد قرار → يحدث record → يرسل الرد

بعدها نسأل:

• فين الوقت بيضيع؟
• أنهي خطوات متكررة؟
• أنهي قرارات تحتاج judgment؟
• إيه الـsource of truth لكل معلومة؟
• أنهي Actions فيها مخاطرة؟
• فين لازم الإنسان يفضل موجود؟

لو الحل المقترح مش مبني على الـworkflow الحقيقي، المشروع ممكن يتحول لـdemo غالي بعيد عن التشغيل الفعلي للشركة.

2. هل يعرف إمتى ما يستخدمش AI؟

ده من الاختبارات المفضلة عندي.

اسأله:

إيه الأجزاء في المشروع اللي متعمد ما تعملهاش بالـAI؟

إجابة جيدة قد تتكلم عن deterministic business rules أو permissions أو calculations أو validation أو authentication أو workflow automation مباشرة.

LLMs قوية جدًا، لكنها ليست بديلًا لكل component في software.

Consultant يحاول يحول كل مشكلة لـAgent قد يكون بيحسن الـnovelty أكثر من reliability.

3. هل يستطيع شرح الـArchitecture بدون الاختباء وراء المصطلحات؟

مش مطلوب منك تبقى AI Engineer علشان تشتري AI system.

لكن مقدم الخدمة لازم يقدر يشرح المكونات الأساسية بوضوح.

مثلًا:

• Customer input بيدخل منين؟
• معرفة الشركة بتيجي منين؟
• كل model مسؤول عن إيه؟
• Agent مسموح له يستخدم أنهي tools؟
• أنهي system هو الـsource of truth؟
• الصلاحيات بتتطبق فين؟
• إيه اللي بيحصل لو AI مش واثق؟
• إيه اللي بيحصل لو API وقعت؟
• إيه اللي بيتسجل في logs؟

لو الشرح كله سحابة من كلمات Agents وEmbeddings وRAG وVector Database وFine-tuning، كمل أسئلة لحد ما business flow نفسها تبقى مفهومة.

4. اسأله: إيه اللي يحصل لما AI يغلط؟

ما تطلبش happy-path demo بس.

اطلب:

وريني Failure Path.

ماذا يحدث لو:

• Model فهم المستخدم غلط؟
• Retrieval رجع document غلط؟
• CRM مش متاح؟
• المستخدم طلب Action غير مدعومة؟
• معلومة مطلوبة ناقصة؟
• نظامان عندهم بيانات متعارضة؟
• Agent حاول ينفذ نفس Action مرتين؟

Production engineering في جزء كبير منها هي تصميم ما يحدث عندما المسار المثالي يفشل.

الإجابة المفروض تتكلم عن validation وretries وidempotency وescalation وhuman approval وmonitoring حسب الحاجة — مش مجرد "الـmodel دقيق جدًا".

5. اسأل الصلاحيات بتتطبق إزاي

الموضوع يصبح Critical عندما النظام يستطيع تنفيذ Actions.

لو AI Agent يستطيع تعديل بيانات عميل أو تغيير حجز أو إرسال رسالة أو تشغيل business process، اسأل:

• المستخدم بيتعمله authentication إزاي؟
• Agent مسموح له يوصل لإيه؟
• أنهي Actions تحتاج Approval؟
• هل permissions يتم التحقق منها خارج الـLLM؟
• هل Actions بتتسجل؟
• هل يمكن عكس Action؟

الـPrompt ليس Authorization System.

Business permissions لازم يفرضها software حول الـmodel.

6. اسأل بيانات شركتك هتتعامل إزاي

لازم تعرف أي معلومات تدخل AI system وفين تروح.

أسئلة مهمة:

• أنهي بيانات تذهب لمزودي models خارجيين؟
• أنهي بيانات تظل داخل infrastructure الشركة؟
• هل sensitive data يتم تقليلها أو فلترتها؟
• التطبيق يحتفظ بالبيانات قد إيه؟
• مين يقدر يشوف logs؟
• هل نحتاج private deployment؟
• هل Local LLM أو Private RAG مناسب؟

مفيش deployment model واحد صحيح لكل الشركات.

الـarchitecture لازم تناسب حساسية البيانات والمتطلبات التنظيمية والتشغيلية الفعلية.

7. اسأل RAG ومعرفة الشركة متصممين إزاي

لو المشروع يستخدم مستنداتك أو معرفة داخلية، ما تعتبرش "هنحطها في Vector Database" خطة كاملة.

اسأل:

• أنهي مصادر سيتم فهرستها؟
• مين يكسب لو مصدران اختلفوا؟
• التحديثات بتوصل إزاي؟
• صلاحيات الوصول للمعلومات محفوظة إزاي؟
• هل الإجابات تعرض مصادرها عند الحاجة؟
• Retrieval quality هتتقاس إزاي؟

RAG هي retrieval architecture، مش ضمان صحة.

8. اسأل إزاي هيعملوا Evaluation

Demo مش evaluation strategy.

قبل production لازم توجد طريقة لاختبار النظام على tasks تمثل الاستخدام الحقيقي.

حسب المشروع، القياس قد يشمل:

• Answer correctness.
• Retrieval quality.
• Tool selection.
• صحة arguments للـtools.
• Successful task completion.
• Escalation behavior.
• Latency.
• Cost per task.
• Failure rates.

اسأل عن Acceptance Criteria قبل بداية المشروع.

لو محدش عارف يعرف النجاح، هيبقى صعب نعرف النظام اتحسن ولا لأ.

9. اسأل عن Operating Cost مش Development Cost بس

فاتورة التنفيذ مش التكلفة الكاملة لنظام AI.

ممكن تدفع أيضًا في:

• Model APIs.
• Hosting.
• Databases.
• Vector/Search infrastructure.
• Messaging providers.
• Third-party APIs.
• Observability.
• Maintenance.

Architecture جيدة لا تستخدم AI calls غالية لمهام software deterministic يستطيع تنفيذها بثبات.

اسأل إيه عوامل التكلفة وإيه اللي يحصل لها مع زيادة الاستخدام.

10. دور على Production Experience مش AI Vocabulary فقط

مشاريع AI تظل Software Projects.

تحتاج APIs وdatabases وqueues وauthentication وdeployments وmonitoring وtesting وsecurity وproduct decisions.

علشان كده أنا أعتبر وجود دليل على القدرة على بناء وتشغيل systems كاملة أهم من مجرد notebooks أو prompts أو prototypes منفصلة.

الدليل قد يكون:

• Production products.
• Technical case studies.
• Open-source work.
• Architecture explanations.
• Integrations حقيقية.
• Systems يتم صيانتها بمرور الوقت.

شكل الـportfolio يختلف حسب المشروع، لكن ابحث عن evidence إن الفريق بيعرف يشحن product حقيقي.

11. اسأل مين اللي هيبني المشروع فعلًا

الشخص اللي باع لك المشروع مش بالضرورة الشخص اللي هينفذه.

اسأل:

• مين مسؤول عن architecture؟
• مين بيكتب production code؟
• مين مسؤول عن infrastructure؟
• مين مسؤول عن AI evaluation؟
• مين يتعامل مع production failure؟
• هل الشغل هيتم outsource؟

وده مهم خصوصًا عند المقارنة بين AI Company كبيرة وIndependent Consultant.

الشركة قد توفر فريقًا أكبر وcapacity أكثر.

Senior consultant قد يعطيك وصولًا مباشرًا أكثر للشخص الذي يأخذ قرارات الـarchitecture.

ولا واحد فيهم أفضل تلقائيًا. المهم تعرف مين مسؤول عن النتيجة.

12. اسأل مين يملك الـCode والـInfrastructure

قبل التطوير وضح:

• مين يملك source code؟
• Repository فين؟
• Cloud accounts ملك مين؟
• مين يتحكم في API credentials؟
• Prompts وevaluation datasets ملك مين؟
• هل engineering team أخرى تقدر تصين النظام بعدين؟
• إيه documentation اللي هتتسلم؟

Vendor lock-in لازم يكون قرار business مقصود، مش مفاجأة بعد الـlaunch.

13. خليك حذر مع وعود دقة AI المطلقة

AI systems يمكن تقييمها ووضع controls حولها، لكن وعود عامة مثل "100% accuracy" لازم تفتح أسئلة إضافية.

اسأل:

100% على أنهي dataset وأنهي task وتحت أنهي conditions؟

مقدم خدمة جيد لازم يكون مرتاح في مناقشة uncertainty والـsupported use cases وحدود الفشل.

14. اطلب Scope أصغر في البداية

مش لازم مقدم الخدمة يؤتمت الشركة كلها في Phase 1.

First project جيد غالبًا يكون workflow واحدة فيها:

• Inputs واضحة.
• Outputs واضحة.
• Data متاحة.
• Cost أو pain حالي قابل للقياس.
• Risk controlled.
• Value تكفي لتبرير الشغل.

بعدها قِس النتيجة.

لو نجحت، وسّع.

ده يقلل المخاطر للطرفين ويعطي معلومات حقيقية للقرار المعماري التالي.

15. اتأكد إن الـProposal فيها Business Outcome

قارن بين الوصفين:

"Build a multi-agent RAG platform using advanced LLM orchestration."

و:

"تقليل العمل اليدوي المطلوب لتأهيل sales enquiries عن طريق استخراج المعلومات المطلوبة، مراجعة معايير الشركة، إنشاء CRM record منظمة وتحويل الفرص المؤهلة لفريق المبيعات."

الوصف الثاني يقول النظام المفروض يحقق إيه.

بعدها التقنية تتحدد حول النتيجة.

طريقة عملية لمقارنة مقدمي الخدمة — بدون Hype

بدل ترتيب الشركات حسب مين يستخدم أحدث model، قيّم هل كل مقدم خدمة يستطيع الإجابة بوضوح عن:

Business — هل فاهم الـworkflow والنتيجة القابلة للقياس؟

Architecture — هل يقدر يشرح النظام وليه كل component موجود؟

Integration — هل يقدر يتعامل مع software وdata الحقيقية عندك؟

Safety — هل permissions وvalidation وfailure paths متصممة بوضوح؟

Evaluation — هل توجد طريقة repeatable لاختبار الجودة؟

Operations — هل النظام يمكن مراقبته وصيانته وتوسيعه؟

Ownership — هل ملكية الكود والـinfrastructure والـdocumentation والمسؤوليات واضحة؟

Communication — هل يستطيع شرح الـtechnical trade-offs بلغة business؟

مش محتاج تحولها لدرجة رقمية. الـgaps نفسها مفيدة في المناقشة.

Red Flags تستحق أسئلة إضافية

أنا هسأل أكثر لو لقيت:

• Architecture اتحددت قبل فهم الـworkflow.
• كل مشكلة بتتحول لـAI Agent.
• مفيش كلام عن failure cases.
• مفيش human handoff للإجراءات غير المؤكدة أو الخطرة.
• Permissions متحكم فيها بالـprompts فقط.
• مفيش source of truth واضح لبيانات الشركة.
• مفيش evaluation plan.
• مفيش شرح للـoperating cost.
• Prototype بيتباع على إنه production-ready.
• ملكية الـcode أو infrastructure غير واضحة.
• ادعاءات دقة كاملة بدون evaluation context محدد.

ولا نقطة من دول تثبت وحدها إن مقدم الخدمة سيئ، لكنها كلها تستحق إجابة واضحة قبل الالتزام.

أول Meeting جيد لازم يخليك تخرج بأسئلة أفضل

المفروض تخرج من AI discovery conversation فاهم workflow شركتك بشكل أوضح من قبل الاجتماع.

مقدم الخدمة الجيد يساعدك تفصل:

• إيه اللي يحتاج AI.
• إيه اللي يحتاج Automation.
• إيه اللي يحتاج Integration.
• إيه اللي يفضل Human.
• إيه اللي يمكن قياسه.
• وإيه اللي ممكن يستنى للمرحلة التالية.

وده أهم من سماع قائمة طويلة بأسماء models.

بتختار AI Partner لشركتك؟

خذ معك workflow حقيقية لأول conversation بدل طلب عام مثل "عايزين نضيف AI".

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

بعدها قيّم هل الشخص قدامك قادر يحول العملية دي لخطة تقنية واضحة ومحدودة المخاطر وقابلة للقياس.

ناقش مشروع الذكاء الاصطناعي مع فادى مندي.

شغلي يبدأ من الـbusiness workflow ويكمل للـarchitecture والـAI والـintegration والـproduction، بهدف بناء أصغر system reliable يخلق نتيجة قابلة للقياس.

---

مرتبط: AI Consulting، AI Development Services، AI for Business، تكلفة Custom AI، AI Automation، AI Agents، AI Integration، Private AI وCustom Software Development.