Lovable تحدد معايير الأمان للقطاع المالي: سجلات تدقيق لمدة 13 أسبوعاً ومعالجة استدلال داخل الاتحاد الأوروبي

أصدرت منصة Lovable، المخصصة لتطوير التطبيقات الوظيفية عبر الأوامر النصية (Prompts)، دليلاً لمديري التسويق في القطاع المالي. تنطلق الفكرة من واقع عملي بسيط: بات بناء النموذج الأولي للحملة ممكناً خلال ساعات، في حين قد يستغرق التنسيق مع إدارات الامتثال والأمان أسابيع. يوضح الدليل حدود المسؤولية بين المنصة والعميل، ونوعية البيانات المحظور إدخالها إلى Lovable، وآليات مراجعة التطبيق قبل نشره. ورغم كونه مستنداً صادراً عن مزود الخدمة، فإنه يقدم تفاصيل عملية كافية لتشكيل قائمة تدقيق داخلية للمؤسسات.

المنصة والتطبيق: مستويان من الحماية

تقسم Lovable تدابير الأمان إلى طبقتين رئيسيتين. تشمل طبقة المنصة التشفير، وعزل مساحات العمل، والهوية المؤسسية، وسجلات التدقيق، بالإضافة إلى أنظمة رصد ومنع وتطهير بيانات الهوية الشخصية (PII). تفيد هذه الطبقة فرق أمان المعلومات في تقييم Lovable كمزود للخدمة. أما طبقة التطبيق، فتركز على الفحص التلقائي لما يقوم المستخدم ببنائه بنفسه: رصد صلاحيات قواعد البيانات غير الآمنة، والمفاتيح المسربة، والاعتماديات المعرضة للاختراق، والثغرات في الكود.

تقترح المنصة الإجابة عن خمسة أسئلة قبل البدء في البناء: ما طبيعة البيانات المستخدمة (عامة، داخلية، شخصية، استثمارية سرية)، من هو الجمهور المستهدف، ما الوظائف التي يؤديها التطبيق (عرض البيانات، تعديل السجلات، الإرسال البريدي، تقديم التوصيات)، ما تكلفة حدوث خطأ، ومن هو مالك التطبيق المخول بإيقافه. وتصنف المشاريع منخفضة المخاطر مثل أدوات التخطيط الداخلي للحملات القائمة على بيانات اصطناعية، أو النماذج الأولية لصفحات الفعاليات. في المقابل، تندرج بوابات المستثمرين، والتسويق المخصص للصناديق، والتكامل مع أنظمة إدارة علاقات العملاء (CRM)، والأدوات التي تتضمن تقييمات غير منشورة ضمن الفئات عالية المخاطر. ويؤكد الدليل بوضوح: وصف البيانات بأنها «داخلية» لا يعني أنها «آمنة» إذا كانت تحتوي على معلومات جوهرية غير علنية (MNPI).

ويشكل القسم 3.8 من اتفاقية معالجة البيانات (DPA) لباقات Business وEnterprise قيداً محورياً؛ إذ يحظر نقل البيانات الحساسة مثل أرقام الحسابات المالية، والمعرفات الحكومية، والبيانات الحيوية، والمعلومات الصحية المحمية. وتطبيق آليات التحكم في الوصول أو معالجة الاستدلال داخل أوروبا (EU inference) لا يلغي هذا الحظر بأي شكل.

موصلات الربط والبيانات ونطاق المعالجة الجغرافي

تعتبر موصلات الربط (Connectors) الجزء الأكثر حساسية في الإعداد، وتنقسم إلى أربعة أنواع يحدد كل منها من يمكنه الاطلاع على البيانات:

• Chat connector: يوفر سياقاً شخصياً أثناء مرحلة البناء (مثل ملخص محفوظ في Google Drive)، ولا يصل إلى التطبيق النهائي المنشور، لكن يمكن للزملاء في مساحة العمل المشتركة رؤية هذه البيانات.
• App + chat connector: يعتمد حساباً موحداً مشتركاً لعمليات البناء وتشغيل التطبيق، ويرى المستخدمون البيانات في حدود صلاحيات هذا الحساب.
• App user connector: يعمل كل مستخدم تحت حسابه الخاص؛ كأن يطلع المدير على حساباته المسندة إليه فقط.
• Custom connectors وMCP: يعتمد سلوك الربط على النموذج والآلية المحددة في الإعدادات.

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

وفيما يتعلق بتدريب النماذج: يتم استبعاد محتوى عملاء خطط Business وEnterprise (من أوامر نصية، وملفات، وشفرات برمجية، ومخرجات) من عمليات التدريب افتراضياً. أما في خطط Free وPro، فقد تُستخدم البيانات ما لم يختر المستخدم إلغاء ذلك صراحة. وتتيح باقة Enterprise ميزة EU inference لتوجيه طلبات الاستدلال نحو نقاط توزيع أوروبية؛ وفي حال عدم توفر نقطة متوافقة، ينتهي الطلب بخطأ برمجي دون تحويله إلى منطقة جغرافية أخرى. مع وجود تنبيهات جوهرية: تختلف حدود التغطية باختلاف المزودين، وبعض الوظائف قد لا تكون متاحة، كما أن بعض أدوات الوكلاء (Agents) تعالج البيانات داخل الولايات المتحدة في كل الأحوال، فضلاً عن أن تفعيل هذا الخيار لا يغير الموقع الفعلي لتخزين بيانات التطبيق. ويتم تحديد المنطقة الجغرافية لخوادم Lovable Cloud بشكل منفصل تماماً.

السجلات، الباقات، وقائمة التدقيق قبل النشر

ترصد سجلات التدقيق (Audit logs) في خطة Enterprise التغييرات التي تطرأ على الأعضاء، والأدوار، والإعدادات، وعمليات الربط، والنشر: من أجرى التغيير، وتوقيته، وتفاصيل الإجراء، والمورد المتأثر. وتُحفظ هذه السجلات لمدة 13 أسبوعاً (نحو 90 يوماً)، ويجب على العميل تصديرها بعد انقضاء هذه المدة. ولا تشمل هذه السجلات الإجراءات المتخذة داخل التطبيق نفسه—مثل تحميل المستثمر لمستند أو الموافقة على حملة بريدية—حيث يتعين على المطور برمجة هذه الأحداث وتتبعها بشكل مستقل.

وعلى صعيد الباقات: تتيح Pro استخدام النطاقات المخصصة وأنظمة التصميم، وتضيف Business ميزات تسجيل الدخول الموحد (SSO)، وتحديد الصلاحيات بحسب الأدوار، وقوالب التصميم، مع إلغاء التدريب على البيانات افتراضياً، بينما تنفرد Enterprise بسجلات التدقيق، ودعم بروتوكول SCIM، وعمليات فحص الأمان المجدولة. ويجب احتساب استهلاك الرصيد (Credits) لمرحلتي التطوير والتشغيل الفعلي معاً؛ إذ تستهلك موارد الواجهة الخلفية، ونماذج الذكاء الاصطناعي، وبعض الموصلات رصيداً إضافياً أثناء العمل.

أما خطة العمل التنفيذية للفرق البرمجية فتتطلب أولاً تصنيف المشروع وفقاً للأسئلة الخمسة ومطابقة طبيعة البيانات مع اتفاقية DPA، وبناء النسخ التجريبية اعتماداً على بيانات اصطناعية. وإذا كان التطبيق مخصصاً لخمسة أفراد، يتم تحديد جمهور مخصص (Custom audience) على خطط Business وEnterprise، أو تفعيل خيار Invite only في خطط Free وPro. ويجب اختبار الحالات الحدية للتأكد من عجز المستخدم الخارجي عن فتح لوحة التحكم، واقتصار رؤية العضو المدعو على سجلاته المحددة فقط.

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