تدقيق GDPR وسجلّ الوصول

بُنيت betool لتلبية متطلّبات GDPR دون امتثال مُضاف بعد الأمر: يُسجَّل كل وصول إلى محتوى المستخدم من قِبَل عميل ينتمي إلى مؤسسة أخرى، ويمكن لكل مؤسسة الاطّلاع على سجلّها الخاص.

سجلّ الوصول

يُسجّل جدول مخصّص، لكل وصول عابر للمستأجرين:

• الطابع الزمني (بدقّة الميكروثانية)
• المؤسسة المستهدَفة (التي قُرِئ محتواها)
• المؤسسة القارئة (عادةً المورّد)
• الدور / العميل (agent) / المستخدم الذي نفّذ القراءة
• نوع الكيان (مفردات مغلقة: exchange_text، knowledge_chunk، audio_segment…)
• معرّف الكيان
• سياق الاستخدام (مهمّة، تذكرة، اقتراح)

مفردات الكيان مغلقة على مستوى قاعدة البيانات (قيد CHECK) ومغلقة على مستوى الكود (قائمة سماح في التطبيق). تتطلّب إضافة نوع عملية ترحيل جديدة إضافةً إلى تحديث قائمة السماح. لا مدخلات مفاجئة.

حق الوصول (المادة 15)

يمكن لكل مؤسسة الاطّلاع على سجلّات الوصول الخاصّة بها عبر:

GET /api/admin/me/content-reads

المرشّحات المتاحة: نطاق زمني، ونوع الكيان، ومعرّف الكيان، وهوية القارئ. تصدير CSV / Excel للمشاركة مع مسؤول حماية البيانات.

لا وصول عابر للمؤسسات على سجلّ التدقيق: لا يرى المورّد أبدًا سجلّات تدقيق العميل.

حق المحو (المادة 17)

تُدعَم ثلاثة مستويات من المحو:

1. محو المستخدم — يطلب مستخدم نهائي حذف بياناته داخل مؤسسة عميلة. تُطلِق المؤسسة المحو عبر لوحة الإدارة أو عبر واجهة الإدارة API.
2. محو المؤسسة — تغادر مؤسسة منصّة betool. تُحذَف جميع مواردها: الجداول المُرشّحة حسب org_id، وتُطهَّر مساحة تخزين الملفّات، وتُزال الأسرار. النافذة التعاقدية الافتراضية: 30 يومًا للتراجع، ثم تطهير لا رجعة فيه.
3. المحو القانوني — بأمر قضائي، حذف عناصر محدّدة دون المساس بالباقي. يُسجَّل في مسار التدقيق مع إشارة إلى الأساس القانوني.

الموافقة والانسحاب من القراءة العابرة للمستأجرين

افتراضيًا، تكون موافقة القراءة العابرة للمستأجرين على القيمة FALSE. يمكن للمؤسسة تفعيلها تحت الإدارة ← الخصوصية ← القراءة العابرة للمستأجرين.

ثلاثة أوضاع:

• رفض كامل — الوضع الافتراضي. لا يمكن للمورّد الوصول إلى أي محتوى من هذه المؤسسة. النتيجة: لا يمكن تقديم دعم عابر للمؤسسات على مستوى المحتوى (يبقى الدعم البنيوي وأعلام الأعمال متاحين).
• موافقة مؤقّتة — تصريح لنافذة زمنية محدّدة، قابلة للإلغاء.
• موافقة دائمة — للعملاء الراغبين في دعم استباقي (نادر في القطاع المصرفي، شائع في SaaS القياسي).

لا يستطيع المورّد تفعيل هذه الموافقة نيابةً عن العميل. وهذا اختبار جوهري: إذا استطاع المورّد التبديل دون فعل من العميل، فإن البنية معطوبة.

حاجز حماية للعمليات المُدمِّرة

تُرفَض أي عملية تُدمّر المحتوى أو تستبدله (DELETE، REPLACE-IN-PLACE) عند المُدقِّق (validator) إذا لم تُفعّل المؤسسة المستهدَفة موافقة القراءة. المبرّر: دون رؤية، سيقترح المُشغّل حمولةً قد تطمس المحتوى الموجود عشوائيًا.

الرفض المتسلسل عند عدم توفّر التدقيق

إذا كانت قاعدة بيانات التدقيق غير متوفّرة (حادث بنية تحتية)، تُرفَض جميع القراءات العابرة للمستأجرين. سياسة صارمة: لا قراءة دون أثر.

النتيجة من جانب الكود: يجب على المُستدعي الذي يلتقط استثناءً أن يُعيد رفع خطأ التدقيق قبل أي معالجة أعمال. وهذا ثابت يتحقّق منه معيار الأمن (benchmark).

ملفّات تعريف الارتباط الخاصة بالموافقة

على الموقع التسويقي وأداة الدردشة (chat widget)، لا تُضبط سوى ملفّات تعريف الارتباط الضرورية للغاية. لا ملفّات تعريف ارتباط تحليلية من طرف ثالث دون لافتة موافقة متوافقة.