حوكمة بيانات الذكاء الاصطناعي ومخاطر الأطراف الثالثة في اليمن

لماذا البيانات والموردون موضوع واحد تقريبًا في AI؟

في كثير من أنظمة AI الحديثة، البيانات لا تبقى داخل نظام تملكه المؤسسة بالكامل.

قد تنتقل إلى:

Cloud Provider.

Model Provider.

Vector Database.

Monitoring Service.

أو Support Tool.

لذلك Data Governance وThird-Party Governance مرتبطان مباشرة.

ابدأ بخريطة البيانات

قبل تقييم النموذج، ارسم Data Flow.

من أين تبدأ البيانات؟

أين تخزن؟

من يعالجها؟

إلى أي API ترسل؟

أين تحفظ Logs؟

هل توجد نسخة احتياطية؟

هذه الخريطة تكشف المخاطر التي لا تظهر في واجهة المستخدم.

Data Inventory

المؤسسة تحتاج إلى معرفة مجموعات البيانات المستخدمة في AI.

لكل Dataset يجب تسجيل:

المالك.

المصدر.

الغرض.

الحساسية.

الجودة.

التحديث.

والأنظمة التي تستخدمها.

بدون Inventory لا يوجد Governance فعلي.

مصدرية البيانات

Data Provenance تعني القدرة على تتبع البيانات إلى أصلها.

هذا مهم عندما يظهر خطأ.

هل جاء من Model؟

أم من سجل غير صحيح؟

أم من عملية تحويل؟

أم من مصدر قديم؟

التحقيق يعتمد على هذه الإجابة.

جودة البيانات

AI لا يجعل البيانات أفضل تلقائيًا.

إذا كانت البيانات ناقصة أو متعارضة، قد يضخم النظام المشكلة.

يجب قياس:

Completeness.

Accuracy.

Consistency.

Timeliness.

وأي Bias مرتبط بالغرض.

بيانات التدريب

إذا كانت المؤسسة تدرب نموذجًا أو Fine-tune، يجب معرفة مصدر Training Data.

هل تملك حق استخدامها؟

هل تحتوي بيانات شخصية؟

هل تم تنظيفها؟

هل تم توثيق الإصدار؟

هذه الأسئلة تختلف عن استخدام Model جاهز فقط.

RAG Data

RAG لا يدرب النموذج بالضرورة، لكنه يستخدم مصادر المؤسسة وقت الإجابة.

لذلك يحتاج إلى Governance.

يجب تحديد:

من يستطيع إضافة المصدر؟

كيف يتم اعتماده؟

كيف تزال النسخة القديمة؟

ومن يملك صلاحية رؤيته؟

Embeddings

Embeddings قد تحتوي تمثيلًا مشتقًا من معلومات حساسة.

لا يجب افتراض أنها غير حساسة فقط لأنها ليست النص الأصلي.

يجب حماية Vector Store مثل بقية أصول البيانات المهمة.

الوصول

القدرة التقنية على الوصول لا تعني الحاجة.

Least Privilege ينطبق على البيانات كذلك.

النظام يجب أن يرى فقط ما يحتاجه للغرض المحدد.

فصل العملاء والمستخدمين

إذا كانت الخدمة Multi-tenant، يجب التأكد من الفصل.

تسرب سياق مستخدم إلى آخر يمكن أن يكون حادثًا خطيرًا حتى دون اختراق كامل للنظام.

نقل البيانات عبر الحدود

عندما تستخدم المؤسسة خدمة أجنبية، قد تتم المعالجة أو التخزين خارج اليمن.

يجب أن يكون ذلك معلومًا في Architecture.

ولا ينبغي افتراض موقع المعالجة من اسم الشركة فقط.

قد يستخدم المورد Regions أو Subprocessors متعددة.

لا نخترع قانونًا

لا يوجد في قاعدة سيادة حاليًا إطار يمني متحقق يسمح لنا بتقديم قواعد تفصيلية لنقل بيانات AI عبر الحدود باعتبارها متطلبات وطنية.

لذلك يجب الفصل بين:

الممارسة المؤسسية الجيدة.

وبين المتطلب القانوني المثبت.

المورد المباشر

قبل التعاقد يجب معرفة:

هوية المزود.

الخدمة.

الموقع.

SLA.

السياسات الأمنية.

Retention.

Breach Notification.

والخروج.

Subprocessors

المورد قد يعتمد على موردين آخرين.

قد تستخدم منصة SaaS Model API من شركة أخرى.

وهذا النموذج يعمل على Cloud ثالث.

المؤسسة يجب أن تعرف سلسلة الاعتماد.

Third-Party AI Risk

الخطر قد يأتي من:

توقف المورد.

اختراقه.

تغيير النموذج.

تغيير شروط البيانات.

إيقاف الخدمة.

أو انتقال المعالجة.

لذلك التقييم ليس Checklist أمنيًا فقط.

Model Provider

يجب السؤال:

هل البيانات تستخدم للتدريب؟

هل يمكن تعطيل ذلك؟

هل توجد Enterprise Controls؟

كيف يتم الاحتفاظ؟

هل توجد Logs إدارية؟

هل تتغير النماذج تلقائيًا؟

Cloud Provider

السحابة تضيف طبقة بنية.

يجب فهم:

Regions.

Identity.

Encryption.

Backup.

Availability.

Exit.

لكن Cloud Security لا يغطي سلوك Model نفسه.

Contract Controls

العقد يمكن أن يغطي:

Ownership.

Data Use.

Retention.

Incident Notification.

Subprocessors.

Model Changes.

Audit Evidence.

Exit.

هذه النقاط يجب أن تظهر قبل Production.

Vendor Lock-in

النظام قد يصبح شديد الاعتماد على API خاصة.

كلما زاد Lock-in زادت كلفة الخروج.

هذا لا يعني رفض الخدمات Proprietary.

يعني فهم أثر القرار.

Exit Strategy

قبل الدخول، صمم الخروج.

كيف نحصل على البيانات؟

بأي Format؟

هل نستطيع نقل Embeddings؟

هل نحتاج إلى إعادة بناء RAG؟

هل يمكن استبدال Model؟

Continuity

إذا توقف Vendor، ماذا يحدث؟

الخدمة غير الحرجة قد تنتظر.

الخدمة الحرجة تحتاج Fallback.

يجب أن تعرف المؤسسة ذلك قبل الحادث.

Concentration Risk

قد تستخدم عدة جهات أو خدمات المورد نفسه.

حادث واحد قد يؤثر في الجميع.

يجب مراقبة Concentration Risk على مستوى Portfolio وليس العقد الفردي فقط.

Monitoring

Vendor Review لا ينتهي عند التوقيع.

نحتاج إلى متابعة:

Incidents.

Changes.

Performance.

Costs.

Model Versions.

ومشكلات البيانات.

Change Notification

إذا حدث تغيير مهم في Model أو Data Policy، يجب أن تعرف المؤسسة.

العقد أو عملية المراقبة يجب أن تلتقط التغييرات المؤثرة.

Data Deletion

إنهاء الحساب لا يعني دائمًا حذف كل البيانات.

يجب معرفة:

كيف يطلب الحذف؟

ما مدة التنفيذ؟

هل تشمل Backups؟

ما الذي يحتفظ به المزود لأسباب تشغيلية؟

Logs لدى المورد

قد يحتاج Vendor إلى Logs لتشغيل الخدمة.

لكن المؤسسة يجب أن تفهم ما تحتويه.

قد تكون فيها Prompts أو Outputs أو Metadata حساسة.

Open Source

استخدام Open-source Model لا يلغي Third-Party Risk.

قد تعتمد على:

Repository.

Libraries.

Weights.

Container Images.

Community Updates.

ويجب تقييم Supply Chain.

المسؤولية الداخلية

وجود Vendor لا ينقل المسؤولية كاملة إليه.

المؤسسة هي التي تختار الغرض والبيانات وطريقة الاستخدام.

لذلك يجب أن يوجد Internal Owner.

بوابة اعتماد المورد

يمكن بناء Gate قبل استخدام أي AI Vendor.

تسأل عن:

البيانات.

الأمن.

الموقع.

التدريب.

Subprocessors.

Continuity.

Exit.

Model Changes.

ثم تحدد مستوى المخاطر.

مورد منخفض المخاطر

Tool يعالج محتوى عامًا دون Integration عميق يمكن أن يمر بمسار أخف.

مورد عالي المخاطر

خدمة تدخل في قرار حكومي أو تصل إلى بيانات حساسة أو تمثل Single Point of Failure تحتاج تقييمًا أقوى.

ما الذي لا ينبغي استنتاجه؟

لا ينبغي اعتبار كل Data Transfer مخالفًا تلقائيًا.

ولا ينبغي اعتباره آمنًا تلقائيًا.

ولا يجب الادعاء بقواعد قانونية يمنية تفصيلية غير متحقق منها.

القرار يجب أن يجمع ما هو قانوني مثبت وما هو Risk Management مؤسسي.

ماذا تفعل المؤسسة الآن؟

ارسم Data Flow.

أنشئ Dataset Register.

صنف البيانات.

اعرف الموردين.

اطلب Subprocessor List.

راجع Retention.

اكتب Exit Plan.

راقب التغيير.

الخلاصة

مشروع AI ليس Model فقط.

هو سلسلة من البيانات والأنظمة والموردين.

كل Link في هذه السلسلة قد يصبح نقطة فشل أو تسريب أو اعتماد مفرط.

حوكمة البيانات الجيدة تجعل المؤسسة تعرف ما تستخدمه.

وحوكمة الأطراف الثالثة تجعلها تعرف من يعتمد عليه النظام.

الجمع بين الاثنين هو أحد أهم أسس AI Governance الواقعية في البيئة اليمنية.