مما يتكوّن اجتماع InterMIND الواحد

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

هذه المقالة مكمّلة لمقالة أين يعمل اجتماع InterMIND الواحد فعلياً، التي رسمت الجغرافيا: أين تُنفَّذ كل خدمة وما البيانات التي تمر بها. وتجيب هذه المقالة عن السؤال التالي لدى فريق الأمن: مم تتكوّن هذه المنظومة، وهل يمكننا قراءتها وتدقيقها واستبدالها؟

ليس أين تعمل، بل مم هي مصنوعة، طبقةً طبقة.

الخيارات الافتراضية وكلفتها

كل منتج هو مجموعة من الخيارات. وفي معظم المنتجات تُتخذ أغلب هذه الخيارات بشكل افتراضي: Google Analytics وFirebase وGoogle Translate API وAuth0 وReact. إنها الطريق الأسهل، وهو قرار معقول لمعظم الفرق. لكن الثمن أن كلاً منها يضع جزءاً من بنيتك خلف مزوّد لا تستطيع قراءته ولا تدقيقه ولا مغادرته دون إعادة كتابة.

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

العمود الفقري: المحرّك هو كودنا نحن، لا كود طرف ثالث

لنبدأ بالطبقة الأهم، لأن معظم اجتماعك يمر عبرها. يعمل النقل في الوقت الفعلي وترجمة الصوت والدردشة معاً على mind-sdk + Mind API، أي محرّكنا الخاص، على OVH في فرنسا. الطريقة الافتراضية لبناء اجتماع مترجَم هي ربط خدمة SaaS للوقت الفعلي (LiveKit) بواجهة ترجمة (DeepL أو Google)، ونحن لا نشغّل أياً منهما في المسار المباشر. لا يوجد أي نموذج ترجمة تابع لطرف ثالث في الحلقة. (نستخدم DeepL فعلاً، لكن للمستندات المرفوعة في الدردشة فقط، لا في مسار الصوت والدردشة المباشر؛ راجع خريطة التشغيل. وقد شرحنا آليات خطوط المعالجة في داخل خطوط الترجمة الأربعة.)

وهذا ما لا تجده في خريطة التشغيل: حزمة SDK التي يعمل عليها اجتماعك مفتوحة المصدر بترخيص BSD 3-Clause، وعميل mind-sdk متاح للعموم على gitlab.com/mindlabs/api/sdk، وحقوق النشر لشركة MindMeeting OÜ، كيان الملكية الفكرية الإستوني لدينا. وهو يتصل بـ Mind API على api.mind.com، الذي نشغّله بأنفسنا على OVH في فرنسا.

وهذا ليس ترتيباً من نوع «يمكنك النظر ولا تلمس» كما في المصدر المتاح فقط. فترخيص BSD 3-Clause متساهل ومعتمد من OSI. يستطيع فريق الأمن لديك استنساخ SDK وقراءة كيف يُلتقط صوتك ونصك بالضبط، وكيف يُقسَّمان إلى إطارات ويُبثّان، ثم تدقيق هذا التكامل وفق متطلباتك. أما المحرّك الذي يتصل به من جهة الخادم فهو ملكنا، لا صندوقاً أسود لطرف ثالث. ومحرّك قابل للاستضافة الذاتية بالكامل للمستأجر الذي يحتاجه موجود في خارطة طريقنا، وليس شيئاً نقدّمه اليوم. وسنحدّث هذه المقالة فور إطلاقه.

طبقة بطبقة: الافتراضي مقابل ما نشغّله

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

وبعض هذه الطبقات يستحق جملة إضافية. PostHog مفتوح المصدر وقابل للاستضافة الذاتية؛ نشغّله على سحابة PostHog في الاتحاد الأوروبي ونمرّره كطرف أول عبر نطاقنا، فلا تُحجب الأحداث بصمت بواسطة مانعات الإعلانات، ولا تمر عبر نطاق تحليلات تابع لطرف ثالث. والمصادقة لا تذهب أبداً إلى خدمة SaaS تابعة لطرف ثالث تقف بينك وبين جلساتك؛ نشغّل مسار OIDC بأنفسنا ونربطه بهويتك الحالية في Google أو Microsoft. والخطوط في كل صفحة تُقدَّم من نطاقنا نحن؛ والمكان الوحيد الذي يظهر فيه Google Fonts في كودنا هو سكربت أصول العلامة التجارية غير المتصل، وليس التطبيق الذي يحمّله مستخدموك.

أين نتحلّى بالواقعية: نقولها صراحةً

لا ندّعي أن المنظومة كلها مكتوبة يدوياً أو غير أمريكية. هي ليست كذلك، وأي مقالة تدّعي خلاف ذلك ستكذّبها خريطة التشغيل التي نشرناها.

البنية الداعمة، أي الاستضافة وSSR (Vercel)، وحوسبة خادم الاجتماع (Fly.io)، والمدفوعات (Stripe)، والبريد الإلكتروني المعاملاتي (Resend)، تعمل على خدمات SaaS مقرّها الولايات المتحدة. تتولى Stripe وResend الفوترة والدعوات ولا ترَيان محتوى الاجتماع أبداً. أما Vercel وFly فهما حوسبة مستأجرة: يعمل عليهما كودنا نحن، وخادم الاجتماع على Fly يتعامل فعلاً مع الجلسة المباشرة ومع النص المكتوب الذي يقرؤه الملخص لدينا، لكن هذا كودنا على أجهزتهم، لا منتج مزوّد يستوعب اجتماعك. وكل ذلك يُنفَّذ داخل الاتحاد الأوروبي وقت التشغيل (موضوع خريطة التشغيل).

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

خطوات الذكاء الاصطناعي، وما الذي أُطلق فعلاً

تعمل خطوات النماذج اللغوية، وهي ملخص الذكاء الاصطناعي (المواضيع والقرارات وaction items)، وملخصات المستندات، والإجراءات التوليدية في محرّر الملاحظات بالذكاء الاصطناعي، وAsk AI وMia، على بوابة الذكاء الاصطناعي التي تختارها مؤسستك: Azure OpenAI في EU Data Zone افتراضياً، أو Vertex AI على نقطة النهاية متعددة المناطق في الاتحاد الأوروبي، أو Amazon Bedrock في فرانكفورت بحسب الاختيار، وكلها ضمن مستأجرنا الخاص دون الاحتفاظ بأي بيانات ودون تدريب على محتوى العملاء. أو نقطة النهاية الخاصة بك المتوافقة مع OpenAI، التي تُبقي النموذج على بنية تحتية تتحكم بها. أما الملخص بعد الاجتماع وإجراء الترجمة في المحرّر فيمران عبر مسار الترجمة لا عبر النموذج اللغوي. والصوت والدردشة والملاحظات والمستندات في الوقت الفعلي لم تقترب أصلاً من أي LLM عام الغرض.

هذه هي الصورة الصادقة لهذه الطبقة: النماذج احتكارية، ومزوّدوها شركات أمريكية تشغّل مناطق في الاتحاد الأوروبي، وهي المقايضة نفسها كما في البنية الداعمة أعلاه، مذكورة بجانبها لا مخفية. وما أُطلق بدلاً من نموذج مستضاف ذاتياً من صنعنا هو الاختيار: يمكن للمؤسسة إيقاف الذكاء الاصطناعي كلياً (يستمر النسخ النصي والترجمة في العمل)، ويمكنها توجيه كل ميزة ذكاء اصطناعي إلى نقطة نهاية خاصة بها، مثل vLLM في مركز بياناتها أو نشر داخل مستأجرها، وهذا يضع هذه الطبقة على محور المفتوح والقابل للاستضافة الذاتية نفسه الذي تقوم عليه بقية طبقة البيانات. أما معيار الترجمة العام لدينا فيقيّمه حكَم LLM (Gemini، مع Claude كخيار احتياطي) على جمل مرجعية ثابتة من FLORES-200، وليس على اجتماع أي شخص.

لماذا يهمّ هذا خارج حدودنا

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

1. قابلة للتدقيق. حزمة SDK التي يعمل عليها اجتماعك كود مفتوح المصدر يستطيع فريق الأمن لديك قراءته، والمحرّك الذي خلفها هو محرّكنا نحن، لا صندوق أسود لطرف ثالث.
2. قابلة للنقل. المعايير المفتوحة في كل طبقة بيانات، Postgres وS3 وOIDC، تعني غياب الارتهان الاحتكاري. فما يمكن نقله غير مرتبط بمزوّد واحد.
3. قابلة للاستضافة الذاتية. طبقات البيانات ذات المعايير المفتوحة، Postgres وS3 وOIDC، تعمل اليوم على بنية تحتية تتحكم بها؛ ومحرّك ترجمة مستضاف ذاتياً بالكامل موجود في خارطة الطريق للمستأجر الذي يحتاجه.

هذه هي الصورة بتاريخ 2026-06-07. وسنحدّثها عندما تتغير المنظومة: استبدال مزوّد، أو إعادة بناء طبقة، أو تغيير نموذج الملخص. والإعداد الحالي قابل للتحقق في ملف vercel.json المفتوح لدينا، وفي nuxt.config.ts، وفي مستودع mind-sdk بترخيص BSD-3-Clause المرتبط أعلاه.

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

المصادر: مستودع mind-sdk (BSD-3-Clause)، FLORES-200؛ وقد جرى التحقق من وقائع المنظومة مقابل الإعداد المنشور (vercel.json، nuxt.config.ts) والكود المُطلق، وذلك في أغسطس 2026.