الاستخباراتُ المؤسسية: معماريّةُ اتخاذِ القرار مع OSINT و Data Fusion

عندما تَتّخذ مؤسسةٌ قرارًا، أكثر من نصف المعلومات التي تَحتاجها موجودٌ بالفعل داخل أنظمتها. النصفُ الآخر في مصادرَ خارجيةٍ مفتوحة: السجلّات العامّة، وسائل التواصل، أخبارُ القطاع، تسريباتُ dark web، بياناتُ المورّدين من طرفٍ ثالث. المشكلةُ ليست الوصولَ إلى المعلومات بل القدرةَ على دمج المجموعتين للإجابة على نفس السؤال. ما لاحظه فريقُ الاستخبارات السيبرانية لدينا خلال السنوات الثلاث الماضية: قراراتُ المؤسسات تَتأخّر عادةً ليس بسبب "نقص البيانات" بل بسبب "تَجزُّؤ البيانات".

يَشرح هذا المقالُ كيف يَعمل OSINT و data fusion معًا لتغيير طبقةِ اتخاذِ القرار في المؤسسة. المعماريّةُ التقنية، الحدودُ القانونية، والممارسةُ التشغيلية في قطعةٍ واحدة. نُشارك سبعَ ممارساتٍ تعلّمها فريقُنا الهندسي أثناء نَشر منصّاتٍ على نمط ⁦Palantir⁩.

١. حدودُ التخصُّصين ونقطةُ التقائهما

OSINT (Open Source Intelligence) يَصف نوعَ مصدر بيانات — معلوماتٌ مُنظَّمة تُجمَع بطرقٍ قانونية من الآثار الرقمية المتاحة للعامّة. المحتوى يَشمل السجلّات العامّة (السجلّ التجاري، أحكامُ المحاكم، البياناتُ الضريبية)، منشوراتُ وسائل التواصل المفتوحة، مواقعُ الأخبار، منتدياتُ dark web (ضمن الحدود القانونية)، مواقعُ الشركات، المقالاتُ الأكاديمية، ومُورّدو البيانات الخارجيون.

data fusion بالمقابل هو تخصُّصُ دمج البيانات من مصادرَ مختلفة في رسمٍ بيانيٍّ واحد للروابط. المصادرُ قد تكون OSINT، CRM مؤسستكم، سجلّاتُ SOC لديكم، أو تغذياتُ استخبارات تهديداتٍ خارجية. قيمةُ data fusion ليست في جمع بياناتٍ جديدة بل في نمذجةِ البيانات الموجودة لتُجيب على أسئلةٍ جديدة.

التخصُّصان يَلتقيان هنا: تُدمَج بياناتُ OSINT الخام التي جَمعتموها مع بياناتكم المؤسسية عبر منصّةِ data fusion. OSINT وحده يَبقى تقريرَ PDF؛ data fusion وحده مُحاصَرٌ في الداخل ولا يَرى الخارج. عند الدمج، أسئلةٌ مثل "هذا العميل المرتقَب ارتَبط بأيّ دعوى قضائية في الأشهر الستّة الماضية، أيُّ عضوٍ في مجلس الإدارة تابَع أيّ منافسٍ على Twitter، هل حركةُ سهمِ ⁦BIST⁩ مُتوافقة مع تقاريرنا الأخيرة؟" تُجاب بنقرةٍ واحدة.

٢. خريطةُ مصادر البيانات — الأسبوع الأول

المهمّةُ الأكثر حرجًا في بداية كلّ مشروع data fusion هي إنتاجُ خريطة المصادر. ليست قائمة "نَستخدم هذه الأنظمة"؛ بل جردٌ تفصيلي بأيّ كياناتٍ يَحملها كلُّ نظام، أيّةُ حقولٍ قابلةٌ للمطابقة، ما تَواتر التحديث.

تَشمل الخريطةُ المؤسسية النموذجية:

• الأنظمةُ المؤسسية: CRM (عميل، جهة اتصال، فرصة)، ERP (طلب، فاتورة، مخزون)، نظامُ HR (موظف، منصب)، helpdesk (تذكرة، حلّ).
• البياناتُ التشغيلية: سجلّاتُ SOC، تليمتري الشبكة، سجلّاتُ التطبيقات، أثرُ التدقيق.
• تغذياتُ OSINT: واجهاتُ السجلّ التجاري، ⁦BIST⁩ / مُورّدو البيانات المالية، خدماتُ مراقبة dark web، مراقبةُ وسائل التواصل (ضمن الحدود القانونية)، صفحةُ إخطار خرقِ KVKK.
• أرشيفُ الوثائق: العقود، المراسلاتُ القانونية، تقاريرُ التدقيق، ملاحظاتُ مكالمات العملاء.

أكثرُ المفاجآت شيوعًا أثناء الرسم: نفسُ الكيان يُحتفَظ به بمعرّفاتٍ مختلفة في أنظمةٍ مختلفة. نفسُ العميل يَظهر في CRM كـ "Acme A.Ş."، في ERP "ACME ANONIM SIRKETI"، وفي helpdesk "acme". حلُّ هذا مسألةٌ هندسيّة مستقلّة تُسمّى entity resolution.

مثالٌ عملي من مشروعين أخيرين: في الخريطة التي أعدَدناها لمؤسسةٍ مالية، أُدرِجَ تسعة أنظمةٍ مختلفة؛ بعد أسبوعين من المسح العميق اكتَشفنا أنّها أربعة عشر. الأنظمةُ الخمسة الناقصة كانت أدواتٍ صغيرة على مستوى الأقسام (قوالب ماكرو Excel، مجلّداتُ SharePoint مُشتركة، قاعدةُ Access قديمة، بوّابةُ مورّد، قاعدةُ فلتر بريد). كانت ناقصةً من القائمة الخارجية لأنّ IT المؤسسية اعتَبرتها "shadow IT". قاعدةٌ عملية: الخريطةُ تَبدأ ناقصة دائمًا وتُكمَل بمراقبةِ سيرورات العمل اليومية للفِرَق. المشاريعُ التي تَعتمد فقط على جرد IT من مكتب CIO تَصطدم في الإنتاج بمفاجأة "مصدرُ بياناتٍ لم نَعرف به" بنسبة ٤٠-٦٠٪.

٣. Entity resolution — عمودُ نموذج الرسم البياني

Entity resolution هو عمليّةُ دمجِ سجلّاتٍ مختلفة تَعود لنفس الكيان عبر أنظمةٍ مختلفة. ثلاثُ تقنيّاتٍ تُستخدَم معًا:

المطابقةُ الحتمية: الإقرانُ عبر مُعرِّفاتٍ فريدة كرقم الضرائب، رقم MERSIS، الرقم الوطني. الأكثرُ موثوقية؛ دقّةُ ٩٩٪+. الحد: قد لا تُحتفَظ هذه المُعرِّفات في كلّ نظام.

المطابقةُ الاحتمالية: تشابهُ الأسماء (مسافةُ Levenshtein، خوارزمياتٌ صوتية)، تطبيعُ الهاتف/البريد، parsing العنوان. دقّةٌ ٨٥-٩٥٪؛ المطابقاتُ فوق عتبةٍ تُدمَج تلقائيًّا، تحت العتبة تُحال إلى محلّلٍ بشري.

المطابقةُ السياقية: شخصان حَضرا الاجتماع نفسه، حسابان يَتعاملان من نفس IP، شركتان وقّعتا نفس الوثيقة. تُستَنبَط من الجوار في الرسم؛ تُؤتمَت بواسطة وكلاء AI في AIGENCY V4.

الرسمُ البياني الموحَّد للكيانات الناتجُ عن دمج الثلاثة هو الأساس لكلّ استعلامٍ لاحق. نُكرّس الأسبوعين الأوّلين من كلّ مشروع لبناء هذا الرسم بشكلٍ صحيح؛ إذا كان خاطئًا، يَعمل كلُّ تحليلٍ لاحق على بياناتٍ معطوبة.

٤. توافقُ KVKK — قرارٌ معماري، لا إلحاق

لا يمكن لمشاريع OSINT و data fusion أن تُضيف توافقَ KVKK كطبقةٍ نهائية. ثلاثُ طبقاتٍ يجب تصميمُها معًا منذ اليوم الأول:

طبقةُ الأساس القانوني: أيُّ فئةٍ من البيانات (شخصية، حسّاسة، مجهولة الهوية) تُعالَج على أيّ أساسٍ قانوني؟ يُوثَّق كلُّ تدفّقِ بياناتٍ ضمن KVKK المادة ٥ (الرضا الصريح)، المادة ٦ (شروطٌ إضافية للفئات الخاصّة)، والمادة ٩ (النقلُ عبر الحدود). الرأيُ القائل "يمكن أن نُعالجها لأنّها عامّة" خاطئ — KVKK لا يَحتوي هذا الاستثناء؛ يجب إجراءُ توازنِ المصلحة المشروعة.

طبقةُ إخفاء الهوية: حيث لا تَلزم الهويةُ الكاملة للقرار، تُهَش معرّفاتُ الكيانات؛ تَبقى البياناتُ الخام مرئيّة للمحلّلين المُخوَّلين فقط، والـ dashboards تُظهر بياناتٍ مُجَمَّعة / مجهولة الهوية. تُستَخدَم طبقةُ ذاكرة AIGENCY V4 المُشَفَّرة للإبقاء على المعالجة داخل تركيا.

طبقةُ سِجلّ التدقيق: كلُّ استعلامٍ يُنتج إدخالًا في السجل يُظهر أيُّ دورٍ وَصل إلى أيّ كيان ولأيّ سبب. السجلّ يُحفَظ append-only وغير قابلٍ للتغيير. يجب أن يكون dump قابلَ الإنتاج خلال ٢٤ ساعة عند طلب تدقيقِ KVKK.

تصميمُ هذه الطبقات الثلاث معًا يَحفظ تكلفةَ التوافق عند ٥-١٠٪ من إجمالي جهد المشروع. إضافتُها لاحقًا تَعني ٣٠-٥٠٪ من وقت تطويرٍ إضافي للوصول إلى نفس مستوى التوافق؛ خدمتُنا لنشر منصّة AI مؤسسية تُضمِّن هذه المعماريّة كمعيار.

٥. التفويض — مَن يَرى أيّ عقدة

الميزةُ الأكثر إهمالًا والأكثر حرجًا في منصّة data fusion هي التفويضُ القائمُ على الأدوار. قاعدةُ بياناتٍ واحدة + dashboard واحد تَعمل للفِرَق الصغيرة؛ في المنظّمات المتوسّطة والكبيرة تُولّد مشكلةَ أمنٍ جوهرية.

في معماريّةِ permissioned graph، كلُّ عقدةٍ (كيان) وكلُّ ضلعٍ (علاقة) يَحمل بياناتٍ وصفية خاصّة بالتفويض. سيناريوهاتُ مثال:

• محلّلُ التسويق: يَرى اسمَ العميل + القطاع + تاريخَ المبيعات؛ مؤشّرُ المتانة المالية مخفي.
• الفريقُ القانوني: يَرى نصَّ العقد الكامل + إشاراتُ المخاطر؛ ملاحظاتُ تواصل CRM مخفية.
• القيادةُ التنفيذية: تَرى تقاريرَ مُركَّبة + تحليلاتُ الاتجاه؛ لا وصولَ للبيانات الخام.
• فريقُ SOC: يَرى كلَّ سجلّات النظام + استخباراتُ التهديد؛ لا وصولَ لبيانات العملاء الشخصية.

أيُّ دورٍ يَرى أيّ مجالٍ يُقرَّر مع مالك الأعمال، ليس من جانب الهندسة وحدها. ممارستُنا: عند انطلاق المشروع تُنتَج "مصفوفةُ أدوار"؛ لكلّ عمود (دور) × صف (نوع كيان)، يُحدَّد مستوى الوصول (لا شيء / مُجَمَّع / تفصيل). لا يُكتَب كودٌ قبل وجود هذه المصفوفة.

٦. تكاملُ AIGENCY V4 — الاستعلامُ باللغة الطبيعية

القيمةُ الحقيقية لرسمِ data fusion تَعتمد على تمكين المستخدمين غير المحلّلين من السؤال والحصول على إجاباتٍ. في المنهج الكلاسيكي، كلُّ استعلامٍ يَتطلّب محلّلَ بياناتٍ يَعرف SQL/Cypher؛ هذا اختناقٌ وتكاليفُ تشغيلٍ مرتفعة معًا.

معماريّةُ ٨ وكلاءَ في AIGENCY V4 تُزيل ذلك الاختناق. يَسأل المستخدم بلغةٍ طبيعية: "أيُّ قضايانا تَعلّقت بـ ⁦Acme A.Ş.⁩ في الأشهر الستّة الماضية، وأيُّ أعضاء مجلس الإدارة متّصلون بالأشخاص المذكورين في تلك الإجراءات؟"

ما يَفعله النظام: ١. وكيلُ التنسيق يُفكّك السؤال إلى مهامَّ فرعية. ٢. وكيلُ الباحث يَكتب استعلاماتِ Cypher على قاعدة بيانات الرسم (على ⁦Neo4j⁩) أو يَستدعي GraphQL API. ٣. وكيلُ المراجع يَتحقّق من أنّ النتائج تَجتاز طبقةَ التفويض؛ إن لم تَفعل، يُرجع إجابةً جزئية. ٤. وكيلُ المبرمج يُحوّل النتائج إلى الشكل المفضّل للمستخدم (جدول، رسم، تركيب). ٥. وكيلُ التركيب يَكتب الإجابةَ بلغةٍ طبيعية، مع مراجعَ للعُقَد المصدريّة (سلسلةُ أدلّة).

تُشحَن هذه المعماريّة مع خدمتنا لنشر منصّة AI مؤسسية. محلّلٌ مُدرَّب يُجيب على ٣-٥ استعلامات بالساعة؛ نظامٌ مدعومٌ بـ AIGENCY V4 يُجيب على ٣٠-٥٠ — يُستشار المحلّل فقط في حالات عدم اليقين.

للاستعلامِ باللغة الطبيعية فائدتان إضافيّتان. أولًا، صياغةُ السؤال لا تَتطلّب من المستخدم تعلّمَ نموذج البيانات؛ قد يَقول محلّلٌ "شريحةُ عميل" بينما يَقول التسويقُ "كوهورتُ عميل"، والمعماريّةُ تَحلّ الاثنين على نفس الكيان. ثانيًا، تُسجَّل استعلاماتُ المستخدمين عبر الزمن كـ أنماطِ استخدام؛ يمكن إنتاجُ materialised views لأكثر ٥٠ استعلامًا شيوعًا، يَتعلّم النظامُ ليكون فعّالًا حيث يُستخدَم فعلًا. هذا هو الفارقُ الجوهري عن المنهج الساكن لـ dashboards في أدوات BI الكلاسيكية.

حدُّ الاستعلامِ باللغة الطبيعية هو: في الأسئلة الغامضة أو المتناقضة، يُطبّق النموذجُ تفسيرَه الخاص. لذا فإنّ وكيلَ المراجع حرج — يُعرَض parse tree للاستعلام للمستخدم مع تأكيد "هل تَقصد أن تَسأل هذا؟". الأنظمةُ التي تَتخطّى هذه الخطوة تُخاطر بتقديم جوابٍ خاطئ على أنّه صحيح؛ في AIGENCY V4 هذه الخطوةُ إلزامية.

٧. أخطاءُ الإعداد النموذجية وما تعلّمناه

الأخطاءُ المتكرّرة من المشاريع الـ ١٢ في data fusion التي سَلّمناها خلال السنوات الثلاث الماضية (والتغييراتُ التي اعتَمدناها استجابةً):

الخطأ ١: تأخيرُ قرار نموذج البيانات. في مشروعينا الأوّلين رَتّقنا مخطّطَ الرسم بعد ETL؛ النتيجة: كَتبنا خطوطَ الأنابيب مرّتين. الإصلاح: يجب تَجميد مخطّط الرسم في نهاية المرحلة ١ (١-٢ أسبوع)؛ كلُّ خطوط الأنابيب اللاحقة تَكتب على هذا المخطّط.

الخطأ ٢: عتبةٌ واحدة لـ entity resolution. عتبةٌ واحدة من تشابُهٍ ٠٫٨٥ إمّا تَدمج بإفراطٍ (إيجابياتٌ كاذبة) أو لا تَدمج بكفاية (سلبيّاتٌ كاذبة). الإصلاح: نَستخدم عتبتين — فوق ٠٫٩٥ دَمجٌ تلقائي، ٠٫٧٥-٠٫٩٥ يَسقط على محلّلٍ بشري، تحت ذلك رفض.

الخطأ ٣: تأخيرُ أسئلة تدقيق KVKK إلى النهاية. في مشروعٍ فاتَنا متطلَّبُ dump سجلّ التدقيق من دليل المسؤول عن البيانات في KVKK في النهاية، ممّا كلَّفنا ثلاثة أسابيعَ من refactor. الإصلاح: تَسجيلُ التدقيق يُبنى الآن في Sprint 0؛ هو أوّلُ تنفيذٍ لا آخره.

الخطأ ٤: تَقديمُ خياراتٍ كثيرة جدًّا للمستخدم. في مشروعٍ مبكّر، أَعطينا المحلّلَ ٢٠+ فلتر و ١٥+ تصوّر؛ لم يَستخدم أحدٌ كلَّها، وتَضخَّمت الوثائق. الإصلاح: تُعرَّف ٣-٥ "سيناريوهاتٍ ذهبية" أوّلًا؛ كلُّ UI يُحسَّن لها.

الخطأ ٥: عدمُ كتابة خطّة نسخٍ احتياطي + التعافي من الكوارث. أَدرَكنا مدى أهميّة قاعدة بيانات الرسم النامية بعد عطلِ قرصٍ سنتين لاحقًا. الإصلاح: كلُّ مشروعٍ يَتضمّن الآن snapshots يوميًّا + نسخًا متبادلَ الجغرافيا (Şanlıurfa + Düsseldorf) + ضمانَ RPO/RTO ٤ ساعات.

الخطأ ٦: عدمُ اختبار الأداء بمقياس البيانات الحقيقي. استعلامٌ يَعمل بكمالٍ على ١٠٬٠٠٠ عقدة في بيئة الطيار، انخفض في الإنتاج مع ٥ ملايين عقدة إلى ٩٠ ثانية. الإصلاح: حتى في مرحلة الطيار، اختباراتُ الإجهاد بـ مولّد بياناتٍ اصطناعي بمقياس الإنتاج إلزامية. لا نَنطلق حتى يَنخفض زمنُ الاستعلام p95 دون ٢ ثانية.

الخطأ ٧: ترك تدريب المستخدم للأسبوع الأخير. الكمالُ التقني وحده لا يُحفّز التبنّي. في مشروعٍ سابق سُلّم النظامُ، بَقي الاستخدامُ ١٥٪ بعد ستة أسابيع، وعاد المستخدمون إلى تقارير Excel القديمة. الإصلاح: منذ المرحلة التجريبية، يُدخَل المستخدمون النهائيون في ورشاتٍ أسبوعية؛ التدريبُ يَبدأ في اليوم الأول، لا في يوم التسليم. هذه الممارسةُ رَفعت التبنّي إلى ٨٥٪+.

إصلاحُ هذه الأخطاء السبعة جزءٌ من عمليّتنا المعياريّة الآن؛ يُطبَّق منذ البداية في المشاريع الجديدة. في الأسبوع الأخير من المشروع، يُجري مهندسٌ check-list "ما الذي قد يَسوء" على هذه الرؤوس السبعة — طبقةُ دفاعٍ أخيرة قبل التسليم.

مصفوفةُ القرار: هل تَناسب مؤسستكم، ومتى لا

data fusion ليس الحلَّ الصحيح لكلّ مؤسسة. ثلاثُ أسئلةٍ تُعطيكم قراءةً سريعة:

ثلاث إجاباتٍ "نعم" أو أكثر تَعني أنّ data fusion مُجدٍ. مع اثنتين أو أقل، قَيّموا data warehouse / BI الأبسط أوّلًا؛ يمكن الانتقالُ إلى fusion مع نموّ النطاق.

خدمةُ استخبارات المصادر المفتوحة و خدمةُ معماريّة data fusion لدينا متاحتان كحزمتين منفصلتين أو مدموجتين. عملاؤنا المؤسسيون النموذجيون يَختارون الاثنتين معًا — لأنّ قيمةَ OSINT تَتضاعف عند الدمج مع البيانات المؤسسية.

منهجُنا في المشروع التجريبي

لمؤسسةٍ في البداية، نُوصي بالبدء بـ تجريبٍ ٣ أسابيع. نطاقُ التجريب:

• يُختار سيناريو قرارٍ واحد (مثلًا "تَقييمُ مخاطر عميلٍ مرتقَب يجب أن يَنخفض من ساعة إلى ٥ دقائق").
• يُدمَج مَصدرَا OSINT + نظامان داخليّان.
• يُسلَّم رسمٌ صغير (٥-١٠ أنواع كيانات) + واجهةُ محلّلٍ واحدة.
• يَجري demo + تَقييمُ ROI في نهاية الثلاثة أسابيع.

يَتبع طريقان: إمّا التوسّع (مصادر إضافية، سيناريوهات، نطاقٌ مؤسسي) أو الالتفافُ إلى حلِّ BI أبسط. كلا الاتجاهين يُختار على أساس الأدلّة؛ عمليّتُنا الاستشارية تَتّخذ ذلك القرار معكم لا عنكم.

إذا أردتم تَقييمَ احتياجكم الخاصّ لـ OSINT + data fusion، يمكنكم طلب مكالمةٍ تمهيدية عبر صفحة الاتصال. في مكالمةٍ مجّانية لـ ٦٠ دقيقة نَستعرض كيف تَنطبق البنودُ السبعة على سيناريوكم الخاصّ ونَقترح نطاقَ تجريبٍ.

لا تَتردّدوا في مشاركة هذا المقال مع الزملاء في قطاعكم الذين يَفكّرون في بناءٍ مشابه؛ المحتوى العملي الملموس في هذا المجال لا يَزال نادرًا وقيّمًا. سيُعلِن فريقُنا عن منشوراتٍ جديدة على مدوّنتنا — التالي مُخطَّط: "entity resolution مع permissioned blockchain" و "سيرورات تحليلِ متعدّد الوكلاء مع AIGENCY V4". إن كانت هذه المواضيع مهمّةً لكم، فإنّ ذكرَها في طلبكم يَسمح لنا بمشاركة المادّة التقنية ذات الصلة قبل المكالمة.