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

لما حد يسألني: "تكلفة بناء نظام AI كام؟"، إعطاء رقم قبل ما أفهم الـworkflow غالبًا هيكون رقم مضلل.

نظام يجيب على أسئلة من مستندات الشركة ليس نفس المشروع الذي فيه AI Agent متصل بـCRM، يقرأ بيانات العميل، يجهز عرضًا، يطلب موافقة، يحدث records ويسجل كل Action حصل.

الاثنان ممكن نسميهم "نظام ذكاء اصطناعي"، لكن حجم الشغل الهندسي مختلف تمامًا.

لذلك السؤال المفيد مش:

الـAI بيكلف كام؟

لكن:

إيه الـbusiness process اللي هنغيرها؟ النظام مسموح له يعمل إيه؟ وإزاي هنقيس نجاحه؟

سعر الـAI Model جزء واحد فقط من التكلفة

من السهل جدًا فتح صفحة أسعار API ومقارنة تكلفة الـtokens، ثم محاولة بناء ميزانية المشروع منها.

لكن في production، الـmodel قد يكون واحدًا من أصغر أجزاء المشكلة الهندسية.

نظام حقيقي قد يحتاج:

• Product وworkflow design.
• Backend وfrontend development.
• Authentication وصلاحيات.
• ربط CRM أو ERP أو booking system أو internal APIs.
• تجهيز البيانات والـretrieval.
• RAG أو search infrastructure.
• Agent tools وorchestration.
• Human approval flows.
• Logging وauditability.
• Evaluation واختبارات.
• Monitoring والتعامل مع الفشل.
• Hosting وdatabases وqueues.
• تكلفة استخدام الـmodels باستمرار.
• Security وprivacy controls.

علشان كده مشروعان يستخدمان نفس LLM ممكن تكون تكلفة تنفيذهما مختلفة جدًا.

سعّر الـWorkflow قبل الـPrompt

تخيل شركتين طلبوا "AI Customer Service System".

الأولى تريد النظام يرد على 50 سؤالًا متكررًا من documentation معتمدة، وأي شيء آخر يتحول لموظف.

الثانية تريد النظام يتعرف على العميل، يجلب الطلبات، يراجع السياسات، يعدل الحجوزات، يحدث CRM، ينشئ tickets، يعمل على WhatsApp والموقع، يدعم العربي والإنجليزي ويطلب موافقة على الإجراءات الحساسة.

الفرق بين المشروعين مش الـprompt.

الفرق هو الـworkflow.

قبل الكلام عن الميزانية، أحب أرسم:

Trigger → Input → Knowledge → Decision → Systems → Action → Approval → Result → Measurement

بعدها التقدير يصبح له معنى.

إيه اللي بيحدد التكلفة فعلًا؟

1. حجم الـScope

Workflow محددة وواضحة أرخص في البناء والاختبار والتشغيل من Assistant مفتوح مطلوب منه "يساعد في كل حاجة".

وده سبب من أسباب إني أفضل البداية بـuse case واحدة قابلة للقياس.

مثلًا:

تأهيل الـleads الداخلة وإنشاء records منظمة داخل CRM.

أسهل كثيرًا في التقدير من:

اعمل لنا موظف AI للشركة.

2. الـIntegrations

كل نظام خارجي تضيفه يعني شغل هندسي حقيقي.

CRM قد يكون عنده API ممتازة. ERP قديم قد لا يكون كذلك. وبعض الأنظمة الداخلية تحتاج endpoints جديدة أو تعديل authentication أو تنظيف بيانات قبل أن يستطيع AI استخدامها بأمان.

Integration قد تشمل:

• Authentication.
• API clients.
• Field mapping.
• Webhooks.
• Retries.
• Idempotency.
• Rate limits.
• Error handling.
• Sync logic.
• Permission boundaries.

لو AI مطلوب منه ينفذ داخل الشركة، الـintegrations في أحيان كثيرة أهم من اختيار الـmodel.

3. معرفة الشركة والبيانات

لو النظام يحتاج معرفة خاصة بالشركة، لازم نعرف هذه المعرفة موجودة فين ومدى موثوقيتها.

قد تكون موزعة بين PDFs وCMS ومستندات داخلية وdatabase وCRM notes وsupport tickets وأنظمة أخرى.

RAG قد يكون مناسبًا، لكن جملة "نضيف RAG" ليست architecture كاملة.

لازم نسأل:

• أي مصادر هي الـsource of truth؟
• البيانات تتغير كل قد إيه؟
• مين مسموح له يشوف إيه؟
• إزاي المحتوى يتقسم ويتفهرس؟
• ماذا يحدث لو مصدران اختلفا؟
• هل الإجابات تحتاج citations أو provenance؟

البيانات السيئة لا تصبح بيانات جيدة لمجرد أن LLM يستطيع قراءتها.

4. الـActions ومستوى الـAutonomy

التكلفة والمخاطر يزيدان عندما ينتقل النظام من الإجابة إلى التنفيذ.

قراءة حالة طلب شيء.

تغيير الطلب شيء آخر.

تنفيذ refund شيء أكبر.

AI Agent يستطيع تنفيذ Actions قد يحتاج tool permissions وvalidation وموافقات وaudit logs ومسارات recovery واختبارات لكل Action.

كلما استطاع النظام تغيير business state حقيقية، احتاج هندسة أكثر حرصًا.

5. تجربة المستخدم

Internal tool يستخدمه خمسة موظفين ليس نفس product scope لنظام يتعامل مع العملاء على الموقع وWhatsApp.

التكلفة قد تزيد مع احتياجات مثل:

• Admin dashboard.
• Customer chat interface.
• Arabic/English UX.
• Conversation history.
• Role-based access.
• Notifications.
• Human handoff.
• Analytics.
• Mobile support.

AI backend مجرد جزء من المنتج.

6. الدقة والـEvaluation

Prototype قد يبدو ممتازًا بعد عشر تجارب ناجحة.

Production لازم يتعامل مع الحالات التي لا تظهر في الـdemo.

Evaluation قد تشمل real task datasets، expected outputs، صحة tool calls، retrieval quality، escalation behavior، latency وحالات الفشل.

Internal summarizer منخفض المخاطر لا يجب أن يكون له نفس acceptance bar لنظام يعدل بيانات العملاء.

7. الخصوصية وطريقة الـDeployment

بعض الشركات تستطيع استخدام hosted AI APIs بما يناسب متطلباتها.

شركات أخرى قد تحتاج عزل بيانات أكبر أو private infrastructure أو Local LLM أو on-premise deployment.

Private AI يمكن أن يغيّر حجم شغل الـinfrastructure لأنك قد تصبح مسؤولًا عن model serving وGPU capacity والـscaling والـmonitoring والتحديثات.

أرخص model في سعر الـtoken ليس بالضرورة أرخص system في التشغيل.

تكلفة البناء غير تكلفة التشغيل

أي estimate مفيد لازم يفصل على الأقل بين حاجتين:

Implementation Cost — تصميم وبناء النظام.

Operating Cost — تكلفة استمرار النظام مع الاستخدام.

تكلفة التشغيل قد تشمل:

• Model/API usage.
• Embeddings وreranking.
• Databases وvector/search infrastructure.
• Application hosting.
• Queues وworkers.
• Observability.
• Storage.
• Third-party APIs.
• Messaging channels.
• Maintenance وتغير الـmodels.

أحيانًا system أغلى في التنفيذ يكون أوفر في التشغيل لأنه لا يرسل كل شيء للـLLM ويستخدم deterministic code للأجزاء التي لا تحتاج AI.

مش كل Task تحتاج أغلى Model

Production architecture جيدة يمكن أن تستخدم components مختلفة حسب المهمة.

مثلًا:

• Deterministic code لقواعد الشركة.
• Search أو RAG لاسترجاع المعرفة.
• Model أصغر للclassification أو extraction.
• Model أقوى فقط للمهام التي تحتاج reasoning أكبر.
• Human approval للقرارات عالية المخاطر.

ده غالبًا أفضل من إرسال كل رسالة لأكبر model متاح.

الهدف ليس تقليل token cost بأي ثمن، لكن الوصول للجودة والاعتمادية المطلوبة بدون هدر compute.

Prototype وPilot وProduction ثلاث ميزانيات مختلفة

سبب مهم للخبطة في أسعار مشاريع AI أن الناس أحيانًا تقارن مراحل مختلفة.

Prototype

يجيب عن سؤال: هل الفكرة ممكنة تقنيًا؟

قد يستخدم sample data وintegrations محدودة وخطوات يدوية.

Pilot

يجيب عن سؤال: هل الحل مفيد فعلًا لمستخدمين حقيقيين؟

هنا ندخل workflows حقيقية وintegrations مختارة وقياس واستخدام controlled.

Production

يجيب عن سؤال: هل الشركة تستطيع الاعتماد عليه؟

هنا نهتم بالصلاحيات والاعتمادية والـmonitoring والـedge cases والدعم والأمان والـscalability وملكية التشغيل.

سعر Prototype لا يجب اعتباره أبدًا التكلفة النهائية لـproduction system.

طيب هل ممكن تقول سعر ثابت؟

لو الـworkflow محددة بوضوح، نعم — بعد discovery.

أما طلب مثل "عايزين AI في الشركة"، إعطاء fixed price مسؤول صعب لأن أهم المتغيرات لم تتحدد أصلًا.

قبل التسعير أحب أحدد:

• المشكلة التجارية.
• الـprocess الحالية.
• المستخدمين والـchannels.
• مصادر البيانات.
• الـintegrations المطلوبة.
• الـactions المسموح للنظام تنفيذها.
• المخاطر والموافقات.
• حجم الاستخدام المتوقع.
• Metric النجاح.

بعدها يمكن تقسيم المشروع لأول scope له قيمة حقيقية وتقدير الشغل بناءً عليه.

إزاي تتحكم في الميزانية؟

لو الميزانية مهمة — وهي لازم تكون مهمة — قلل عدم اليقين قبل إضافة features.

Sequence عملية:

1. ارسم workflow واحدة مكلفة أو متكررة.

2. قِس تكلفتها أو الاحتكاك الحالي.

3. حدد أي أجزاء تحتاج AI وأي أجزاء تحتاج software عادي.

4. ابنِ أصغر end-to-end version تستطيع خلق قيمة.

5. اختبرها على حالات حقيقية.

6. قِس النتيجة.

7. وسّع فقط عندما يكون عندك دليل يبرر التوسع.

وده أكثر أمانًا من الموافقة على مشروع "AI Transformation" ضخم قبل إثبات workflow واحدة.

فكر في ROI وليس سعر المشروع فقط

تخيل workflow تستهلك 200 ساعة عمل شهريًا.

السؤال المهم ليس فقط هل النظام سيكلف X أم Y.

اسأل:

• كام ساعة يمكن تقليلها بشكل واقعي؟
• هل النظام يزيد throughput؟
• هل يقلل زمن رد العملاء؟
• هل يحسن التعامل مع leads؟
• هل يقلل أخطاء التشغيل؟
• هل يخلق capability لم تكن الشركة تستطيع تقديمها؟

ثم قارن القيمة المتوقعة بتكلفة التنفيذ والتشغيل معًا.

لا تخترع ROI percentage قبل وجود baseline حقيقي.

قِس العملية الحالية أولًا.

إمتى Custom AI غالبًا مش مطلوب؟

قد لا تحتاج تطويرًا مخصصًا لو SaaS موجود بالفعل يحل الـworkflow جيدًا، والعملية generic، والـintegrations عادية، والشركة لن تستفيد بشكل حقيقي من امتلاك implementation خاص بها.

الشراء هنا قد يكون القرار الهندسي الأفضل.

Custom AI يصبح أكثر منطقية عندما تكون العملية خاصة بالشركة، أو تحتاج deep integration، أو تعتمد على proprietary knowledge، أو تحتاج controlled actions، أو تبني capability تميز المنتج أو التشغيل.

أغلى AI System هو النظام اللي محدش بيستخدمه

System متقدم تقنيًا بدون adoption أو business outcome قابلة للقياس يظل غاليًا مهما كان رقم الفاتورة.

أفضل بناء workflow صغيرة يستخدمها الموظفون أو العملاء يوميًا على بناء AI platform كبيرة شكلها ممتاز في العرض لكنها لا تدخل التشغيل الحقيقي.

الميزانية لازم تتبع القيمة.

بتخطط لنظام AI مخصص لشركتك؟

قبل ما تطلب سعرًا من شركة أو مهندس، اكتب workflow واحدة تريد تحسينها:

• إيه اللي بيبدأ العملية؟
• مين بيتعامل معها اليوم؟
• إيه الأنظمة الداخلة فيها؟
• إيه القرارات التي تحدث؟
• إيه الـactions المطلوبة؟
• فين الوقت بيضيع أو العملية بتفشل؟
• إزاي هتقيس التحسن؟

مع الإجابات دي، السؤال يتحول من "الـAI هيكلف كام؟" إلى "إيه أصغر system يستحق إننا نبنيه؟"

ناقش مشروع الـCustom AI مع فادى مندي.

أقدر أساعدك في رسم الـworkflow، اختيار الـarchitecture وتحويل أول scope له قيمة إلى production system بدون إضافة AI في الأماكن التي يكون فيها software عادي هو الأداة الأفضل.

---

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