Lovable تتيح لعملائها من الشركات معالجة طلبات الذكاء الاصطناعي في أوروبا

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

مساران تصل عبرهما البيانات إلى النموذج

لدى المنصة التي تولّد التطبيقات تدفقان مختلفان للبيانات. الأول ينشأ في مرحلة التطوير: تُرسل إلى النموذج المطالبات (prompts) ومقاطع من الشيفرة البرمجية ووصف منطق العمل والملفات المرفوعة. أما الثاني فيظهر بعد النشر. فإذا كان داخل التطبيق مساعد محادثة أو مصنِّف للطلبات أو بحث في المستندات، فإن ما يدخله المستخدم يمر هو الآخر عبر النموذج، وغالبًا ما تكون هذه بيانات عملاء.

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

لماذا أصبح موقع المعالجة سؤالًا إلزاميًا

مقر Lovable في ستوكهولم، والعملاء الأوروبيون يمثلون للشركة سوقًا طبيعية. وفي استبيانات المشتريات لديهم بند مستقل منذ زمن طويل: أين تُعالج البيانات؟ والتخزين والمعالجة أمران مختلفان. فقد تكون قاعدة البيانات في فرانكفورت بينما يذهب الطلب إلى النموذج عبر endpoint في الجانب الآخر من المحيط. ومن زاوية GDPR، يتطلب هذا النقل أساسًا قانونيًا مستقلًا، وعلى الفرق القانونية وفرق الأمن أن تشرح ذلك.

يقدّم كبار مزوّدي النماذج السحابية بالفعل نقاط نهاية إقليمية، ولذلك فإن الأساس التقني لهذا التوجيه موجود. وتتيحه Lovable داخل منتجها نفسه، فلا يحتاج الفريق إلى بناء طبقة وسيطة بنفسه من المفاتيح والبروكسيات.

ما هو معروف من الإعلان:

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

ما بقي خارج الصورة

كلمة «المدعومة» هي الأهم في الإعلان. فنقاط النهاية الأوروبية لدى مزوّدي النماذج كثيرًا ما تحصل على الإصدارات الجديدة بعد النقاط العالمية. وقد يواجه الفريق الذي يفعّل EU inference أن بعض النماذج غير متاحة أو أن إصداراتها متأخرة.

وهناك أيضًا سؤال عن سلوك النظام عند حدوث عطل. إذا تعذّر الوصول إلى endpoint الأوروبي، هل ينبغي أن ينتهي الطلب بخطأ أم يُحوَّل إلى منطقة أخرى؟ من منظور الامتثال لا يصح إلا الخيار الأول، أما من منظور استمرارية التشغيل (uptime) فالثاني أنسب. ولا يتضح من الإعلان كيف يعمل ذلك.

ويجب أخذ التسجيل (logging) والتخزين في الحسبان بشكل منفصل. فالمعالجة الإقليمية بحد ذاتها لا تجيب عن أسئلة: من يخزّن المطالبات، ولكم من الوقت، وما المعالِجون الفرعيون (subprocessors) المشاركون.

ما الذي يجب التحقق منه قبل التفعيل

على الفريق الذي يخطط لنقل وظائف الذكاء الاصطناعي إلى المعالجة الأوروبية أن يطلب من Lovable عدة أمور:

• القائمة المحدّثة بالنماذج والمناطق التي تتوفر فيها خاصية EU inference.
• وصف السلوك عند عدم توفر endpoint الأوروبي.
• شروط تخزين المطالبات والردود وتسجيلها، إضافة إلى قائمة المعالِجين الفرعيين.
• اتفاقية معالجة البيانات (DPA) المحدّثة بما يراعي الخيار الجديد.

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