7 أخطاء في خصوصية بيانات وكلاء الذكاء الاصطناعي تُسرّب بيانات شركتك بصمت (وكيف تتجنبها)

معظم تسريبات بيانات وكلاء الذكاء الاصطناعي ليست بسبب حفظ النموذج لبيانات شركتك سراً. إنها ناتجة عن أخطاء في الإعداد والبنية يمكنك تسميتها وإصلاحها. أبرزها: التشغيل على حساب من الفئة الاستهلاكية تتدرب إعداداته الافتراضية على مدخلاتك، والسماح للوكيل بأن يرث صلاحيات شخص واحد واسعة، ووصل وكيل يواجه الجمهور بالأنظمة الداخلية، وترك "الثلاثي القاتل" قائماً (بيانات خاصة، ومحتوى غير موثوق، ومسار إرسال خارجي) بحيث يستطيع حقن أوامر واحد قراءة بياناتك وإرسالها بالبريد. هذا النمط الأخير هو بالضبط الطريقة التي كشف بها EchoLeak (CVE-2025-32711) بيانات حساسة عبر Microsoft 365 Copilot من بريد إلكتروني مُعدّ بعناية، دون أي نقرة من المستخدم. الحلول ليست غريبة، وجميعها تقريباً قرارات تُتخذ قبل إطلاق الوكيل، وليست قائمة مراجعة تُسلَّم إليك بعد حدوث تسريب.

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

أولاً، تمييز يغفله تقريباً كل مقال يتناول هذا الموضوع، لأن الخطأ فيه هو الخطأ صفر. هناك طريقتان مختلفتان تماماً تغادر بهما البيانات عبر وكيل، ولهما حلّان مختلفان تماماً:

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

تقول أرقام الاستطلاعات إن المشترين يستشعرون هذا حتى عندما لا يستطيعون تسميته. في بحث Cloudera الذي شمل نحو 1,500 من كبار قادة تقنية المعلومات عبر 14 دولة، يخطط 96% لتوسيع استخدام وكلاء الذكاء الاصطناعي خلال العام المقبل، ومع ذلك يذكر 53% (أكثر من النصف) خصوصية البيانات بوصفها العائق الأساسي أمام التبني. الأخطاء السبعة أدناه هي حيث يتحول ذلك الخوف إلى تسريب حقيقي، وحيث يعيش الحل.

الخطأ 1: تشغيل وكلاء الإنتاج على حسابات من الفئة الاستهلاكية

هذا أرخص خطأ يمكن ارتكابه وأسهلها إصلاحاً. يصل أحدهم سير عمل بحساب ChatGPT شخصي أو حساب Gemini استهلاكي لأنه موجود بالفعل، والآن أصبحت بيانات أعمالك محكومة بشروط استهلاكية لم تُصمَّم لها أبداً.

الفجوة بين الفئتين الاستهلاكية والمؤسسية حادة. على الجانب المؤسسي، النمط ثابت عبر المزوّدين: لا تدريب على بياناتك بشكل افتراضي، ونافذة احتفاظ قصيرة لمراقبة إساءة الاستخدام، وخيارات أقوى عند الطلب. تحتفظ واجهة OpenAI بالبيانات لمدة 30 يوماً لمراقبة إساءة الاستخدام ثم تحذفها، ولا تتدرب عليها بشكل افتراضي. واعتباراً من 14 سبتمبر 2025، خفّضت Anthropic احتفاظ سجلات الواجهة من 30 يوماً إلى 7 أيام، ومدخلات الواجهة ومخرجاتها لا تُستخدم أبداً للتدريب. أما Google Vertex AI (الفئة المؤسسية) فقابلة للضبط بلا استخدام للتدريب. وعلى الجانب الاستهلاكي تنقلب الإعدادات الافتراضية: يخزّن ChatGPT الاستهلاكي المحادثات إلى أجل غير مسمى ما لم تحذفها، واحتفاظ Gemini الاستهلاكي يصل إلى 36 شهراً وقد يُستخدم لتحسين المنتجات.

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

الخطأ 2: الصلاحيات المفرطة الاتساع التي يرثها الوكيل

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

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

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

الخطأ 3: وكلاء يواجهون الجمهور موصولون بالبيانات الداخلية

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

يرسم إطار Microsoft أصرم خط هنا: "يجب ألا يصل الوكلاء الذين يواجهون الجمهور إلى بيانات الأعمال الداخلية." أبقِ السري والعمومي منفصلين بحدّ مادي أو منطقي (مثالهم يستخدم مجموعتي إدارة منفصلتين "corp" و"online"). الفكرة أن الحدّ بنيوي، وليس أملاً في أن يصمد الأمر.

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

الخطأ 4: تجاهل الثلاثي القاتل

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

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

الجزء الصريح، والسبب في أن هذه بنية وليست مشكلة هندسة أوامر: "ما زلنا لا نعرف كيف نمنع حدوث هذا بموثوقية 100%." أصابت ثغرات موثّقة Microsoft 365 Copilot، وخادم MCP من GitHub، وGitLab Duo. وفي أسبوع واحد من يناير 2026، كُشف عن ثغرات حقن أوامر غير مباشر في أربع أدوات إنتاجية مدعومة بالذكاء الاصطناعي، كلها نفس نمط الثلاثي.

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

الخطأ 5: التعامل مع EchoLeak كأنه مشكلة شخص آخر

من المفيد تسمية حادثة حقيقية واحدة، لأن "الثلاثي القاتل" يبدو مجرداً حتى تراه يُنفَّذ. كان EchoLeak (CVE-2025-32711) هجوماً بلا نقرة على Microsoft 365 Copilot. أرسل مهاجم بريداً إلكترونياً مُعدّاً بعناية. وCopilot، أثناء أدائه لعمله المعتاد، عالج ذلك البريد (محتوى غير موثوق)، وكان لديه وصول إلى البيانات الداخلية للمستخدم (بيانات خاصة)، وكان لديه طريق لإرسال المعلومات للخارج (تواصل خارجي). أكمل الأمر المخفي كشفاً عن بيانات حساسة دون أي تفاعل من المستخدم على الإطلاق. لم ينقر أحد على شيء.

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

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

الخطأ 6: غياب حدّ لإقامة البيانات أو الاحتفاظ بها

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

الخبر المطمئن، الذي لا يذكره أي مقال بوضوح تقريباً، هو مقدار ما يمكنك تثبيته. النمط المؤسسي عبر المزوّدين هو عدم التدريب افتراضياً، بالإضافة إلى نافذة احتفاظ قصيرة، بالإضافة إلى ضمانات أقوى عند الطلب. تقدّم Anthropic للمؤسسات المؤهلة اتفاقية عدم الاحتفاظ بالبيانات (ZDR)، التي بموجبها لا تُخزّن المدخلات والمخرجات بما يتجاوز ما يلزم لفحص إساءة الاستخدام. وتقدّم OpenAI اتفاقية ZDR عبر اتفاق متفاوض عليه وإقامة بيانات. وكلاهما يتيح لك اختيار مكان وجود البيانات. والاستضافة الذاتية لنموذج مفتوح (مثلاً عبر Ollama) تبقي البيانات محلية بالكامل بلا احتفاظ من أطراف ثالثة.

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

الخطأ 7: التعامل مع الخصوصية كقائمة مراجعة تُسلِّمها

الخطأ الأخير بنيوي. معظم الإرشادات، بما فيها إطار Microsoft الممتاز، تفترض أنك ستبني الوكيل وتحكمه بنفسك، فتسلّمك كومة من 3,000 كلمة من هويات Entra، وتصنيفات Purview، ومجموعات الإدارة. هذا هو الجواب الصحيح لفريق تقنية معلومات كبير. أما لمعظم الأعمال فهو قائمة مراجعة لا يملك أحد الوقت أو المهارة المتخصصة لتنفيذها بالكامل، فتُنفَّذ نصفها، والثغرات هي بالضبط حيث تتسرب البيانات.

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

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

كيف تتطابق الأخطاء السبعة والحلول

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

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

ما الذي لا يغادر فعلاً، عندما يُبنى الحدّ بشكل صحيح

من السهل أن تقرأ سبعة أخطاء وتستنتج أن وكلاء الذكاء الاصطناعي حقل ألغام للخصوصية. ليسوا كذلك، عندما يُرسم الخط عمداً. بشروط مؤسسية، مدخلاتك ليست بيانات تدريب، والاحتفاظ بالأيام لا إلى الأبد (7 لواجهة Anthropic، و30 لـ OpenAI، ثم تُحذف). مع ZDR، لا تُخزّن بما يتجاوز فحص إساءة الاستخدام. ومع تثبيت إقامة البيانات، تبقى في منطقتك. ومع الاسترجاع داخل شبكتك الخاصة (VPC) أو على البنية الداخلية، لا تغادر البيانات الحساسة محيطك على الإطلاق. ومع الحجب عند الحدّ، تُزال الحقول التي لا ينبغي أن تنتقل أبداً قبل إرسال أي شيء. ومع تحديد النطاق بأقل صلاحية الذي يرث صلاحيات المستخدم، لا يستطيع الوكيل أبداً الوصول إلا إلى ما كان يستطيع الشخص الفاعل الوصول إليه أصلاً.

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

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