لقد بنيته باستخدام Lovable — فمن المسؤول عندما تتسرب البيانات؟

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

لا أحد يطرح السؤال المهم الذي سيطرحه مراجع أمني أو جهة تنظيمية بعد ستة أشهر: من المسؤول عن كيفية تعامل هذا التطبيق مع البيانات التي يلمسها؟

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

ما الذي يعنيه "التطبيق المبني بالذكاء الاصطناعي" فعلياً

هناك فئة جديدة من الأدوات — Lovable وBase44 وBolt.new وCursor وقائمة متنامية من غيرها — تتيح للأشخاص بناء تطبيقات ويب حقيقية ونشرها انطلاقاً من مطالبات (prompts) بلغة طبيعية. غالباً ما تُسمى منصات "vibe coding". الجاذبية واضحة: يمكن لشخص غير مطوّر أن ينتج شيئاً كان يتطلب سابقاً فريقاً كاملاً، ويمكنه فعل ذلك في ساعات معدودة.

هذه التطبيقات ليست ألعاباً. إنها تُنشر لمستخدمين حقيقيين، وتتصل بانتظام بأنظمة الشركة الحقيقية — Google Workspace وSalesforce وقواعد البيانات الداخلية — عبر منح OAuth العادية. من منظور البيانات، يبدو تطبيق بُني في بعد ظهر واحد بمطالبة واحدة وتطبيق بُني على مدى أشهر من قبل فريق هندسي متطابقين: كلاهما يحمل رمز وصول (access token)، وكلاهما يمكنه قراءة ما يسمح به ذلك الرمز.

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

البناء بالذكاء الاصطناعي ليس مرادفاً للأمان

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

نادراً ما يقرأ الناشر الشيفرة. القيمة الكاملة لعرض "vibe coding" هي أنك لست مضطراً لذلك. لذا فإن الشخص الذي أطلق التطبيق غالباً لا يستطيع إخبارك كيف يخزّن البيانات، وما إذا كان يسجّل حقولاً حساسة، وإلى أين يرسل المعلومات، أو كم من الوقت يحتفظ بأي شيء. الطرف المُساءل هو من لديه أقل قدر من الرؤية على الشيء الذي يُساءل عنه.

الوصول واسع وغير مرئي. تطلب أدوات البناء بالذكاء الاصطناعي الصلاحيات (scopes) التي تجعل العرض التوضيحي يعمل، و"جعله يعمل" غالباً ما يعني وصول قراءة واسعاً. لوحة معلومات داخلية كانت تحتاج فقط لقراءة مجلد واحد قد تحمل صلاحية قراءة كامل Drive. ولأن المنح تم عبر شاشة موافقة OAuth عادية، لم تظهر أبداً على رادار أي فريق أمني — إنها، بحكم التعريف، ظل تقني (shadow IT).

لا توجد سياسة موثّقة للتعامل مع البيانات. اسأل عن سياسة الاحتفاظ الخاصة بنظام إنتاجي مبني يدوياً وستحصل غالباً على إجابة. اسأل عن سياسة الاحتفاظ الخاصة بتطبيق أنشأه زميل يوم الثلاثاء الماضي ولن تجد أي سجل. بموجب قانون حماية البيانات، فإن "لا نعرف إلى متى تحتفظ البيانات" ليست إجابة محايدة — إنها نتيجة تدقيق (finding).

لماذا الشركة — وليست المنصة — هي المسؤولة

هنا يأتي الجزء الذي يفاجئ الناس. عندما يسيء تطبيق مبني بالذكاء الاصطناعي التعامل مع البيانات، تقع المسؤولية القانونية والتنظيمية على المؤسسة التي نشرت التطبيق، وليس على منصة الذكاء الاصطناعي التي ولّدته.

هذا هو نفس تحوّل المساءلة الذي يعيد الآن تشكيل قانون الذكاء الاصطناعي بشكل عام. بموجب اللائحة العامة لحماية البيانات في الاتحاد الأوروبي (GDPR)، فإن الجهة التي تحدد أغراض ووسائل معالجة البيانات الشخصية هي المتحكم بالبيانات (data controller)، والمتحكم يتحمل الالتزامات — الأساس القانوني، وتقليل البيانات، وتحديد مدة التخزين، والالتزام بإثبات كل ذلك. عندما تنشر شركتك تطبيقاً يعالج بيانات العملاء، تكون شركتك هي المتحكم. منصة البناء هي، على الأكثر، أداة استخدمتها.

المشهد القانوني الأوسع لعام 2026 يشير في نفس الاتجاه. بدأت المحاكم تعامل الشركة التي تستخدم نظام ذكاء اصطناعي بوصفها مسؤولة عن سلوكه — سارت قضية *Mobley v. Workday* في الولايات المتحدة على أساس نظرية الوكالة (agency theory) وحصلت لاحقاً على موافقة مشروطة على دعوى جماعية على مستوى وطني. وفي ألمانيا، تناولت محكمة OLG Hamm مسؤولية ما يخبر به نظام ذكاء اصطناعي العملاء وأشارت إلى أن إخلاء مسؤولية عام من نوع "لا ضمان" لا يحمي وحده الشركة الناشرة. ويضيف قانون الذكاء الاصطناعي للاتحاد الأوروبي (EU AI Act) التزامات خاصة بالناشرين فوق ذلك، مع عقوبات كبيرة على الاستخدامات عالية الخطورة. نتناول هذا التحول بعمق في نظرتنا الشاملة حول من يتحمل المسؤولية عند تسرب البيانات عبر وكيل ذكاء اصطناعي.

الخيط المشترك: نشر تطبيق مبني بالذكاء الاصطناعي هو قرار اتخذته مؤسستك، والقانون يعامل القرارات على أنها تحمل مسؤولية. حقيقة أن الذكاء الاصطناعي كتب الشيفرة لا تغيّر شيئاً بشأن من اختار ربطه ببيانات الشركة.

الثغرة العمياء، بشكل ملموس

اجمع القطع معاً وستظهر حالة فشل شائعة ومحددة:

• يبني موظف غير تقني تطبيقاً باستخدام أداة بناء بالذكاء الاصطناعي.
• يتصل التطبيق بـ Google Workspace عبر OAuth ويُمنح صلاحيات واسعة.
• يصل إلى بيانات شخصية للعملاء أو الموظفين — جهات اتصال، محتويات بريد إلكتروني، ملفات.
• لم يراجع أحد التعامل مع البيانات، ولا توجد سياسة احتفاظ مسجلة.
• ليس لدى فريق الأمن أي إدخال في الجرد الخاص بالتطبيق، لأنه لم يمرّ أبداً بمراجعة.

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

كيف تسدّ الفجوة

الحل ليس حظر أدوات البناء بالذكاء الاصطناعي — فقد خُسر ذلك السباق بالفعل، والإنتاجية حقيقية. الحل هو الرؤية والأدلة: معرفة أي التطبيقات المبنية بالذكاء الاصطناعي متصلة، ومعرفة ما يمكن لكل واحد منها الوصول إليه، والقدرة على إثبات أنك حكمتها.

هذا بالضبط ما تقوم به 8200.dev. فهي تكتشف تطبيقات OAuth المتصلة بـ Google Workspace الخاص بك، وتُعلّم تلك التي تنشأ من أدوات البناء بالذكاء الاصطناعي — Lovable وBase44 وBolt.new وCursor وما شابهها — من خلال توقيعات اسم التطبيق ومضيف إعادة التوجيه، ومن النمط الدال على تطبيق غير موثّق تم إنشاؤه حديثاً ويحمل بالفعل صلاحيات واسعة. لكل واحد منها ترى منصة البناء، والصلاحيات الممنوحة بالضبط، ومن قام بتفويضه، ودرجة المخاطرة، وكل ذلك معروض في عرض مخصص لـ التطبيقات المبنية بالذكاء الاصطناعي (AI-Built Apps) إلى جانب بقية وكلاء الذكاء الاصطناعي وتطبيقات OAuth لديك.

عندما يستطيع تطبيق مبني بالذكاء الاصطناعي الوصول إلى بيانات تعريف شخصية للعملاء (PII)، أو يحمل وصولاً واسعاً بلا سياسة احتفاظ موثقة، فإنه يثير نتيجة تدقيق محددة — بحيث تتحول الفجوة إلى مهمة لها مالك بدلاً من مفاجأة في تدقيق. ويمكن تسجيل كل تطبيق مبني بالذكاء الاصطناعي في سجل وكلاء الذكاء الاصطناعي (AI Agent Registry)، بحيث تظهر حتى تلك التي لا يصلها أي رابط في جرد واحد كامل. يمكنك الاطلاع على مجموعة الميزات الكاملة هنا.

الهدف ليس إبطاء فرقك. الهدف هو التأكد من أنه عندما يُطرح السؤال — من جهة تنظيمية، أو مدقق، أو مراجعة أمنية لعميل — تستطيع الإجابة عليه. ليس بـ "لقد بنيناه بالذكاء الاصطناعي، فهي مشكلة المنصة"، فهذا ليس دفاعاً، بل بـ "هذا هو التطبيق، وهذا بالضبط ما يمكنه الوصول إليه، وهذا هو الدليل على أننا راجعناه". لمزيد من التفصيل حول ما يتوقعه المراجعون الآن، انظر ما يتطلبه المدققون لحوكمة الذكاء الاصطناعي في 2026.

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

ابدأ بمعرفة ما هو متصل بالفعل بمساحة العمل (Workspace) الخاصة بك. يمكنك رسم خريطة لتطبيقاتك المبنية بالذكاء الاصطناعي، وتقييم وصولها، وتوليد أول دليل لديك في المستوى المجاني — اطّلع على الخطط وابدأ مجاناً.

*هذا المقال معلومات عامة، وليس استشارة قانونية. استشر محامياً مؤهلاً للحصول على إرشادات خاصة بمؤسستك.*