سيسأل أحدهم في مؤسستك هذا السؤال قبل أن يحصل أي شخص على مقعد، وهو محقّ في ذلك. والإجابات المعتادة عديمة الفائدة في الاتجاهين — المتشكّك يقول «إنه يرسل كودنا إلى شركة أمريكية»، والمتحمّس يقول «لا بأس، إنه بمستوى المؤسسات»، ولم يقرأ أيٌّ منهما السياسة.
إليك ما هو صحيح فعلًا، بترتيب الأهمية.
الشيء الوحيد الذي يفهمه معظم الناس بالمقلوب
للخطط الاستهلاكية والخطط التجارية سياسات بيانات مختلفة، والفرق ليس ما يفترضه الناس.
| الخطة | التدريب على بياناتك |
|---|---|
| الشروط التجارية — Team وEnterprise والـ API والمنصّات الخارجية مثل Bedrock وClaude Gov | لا تدرّب Anthropic الـ models التوليدية على الكود أو الـ prompts التي ترسلها إلى Claude Code. والاستثناء الوحيد أن تشترك مؤسستك صراحةً في شيء مثل Development Partner Program، وهو ما يجب أن يفعله مسؤول عمدًا. |
| الخطط الاستهلاكية — Free وPro وMax | يُمنح لك الخيار. وحين يكون إعداد مشاركة البيانات مفعّلًا، ستدرّب Anthropic models جديدة باستخدام بيانات هذه الحسابات، بما في ذلك بيانات جلسات Claude Code التي تجري عليها. |
تأمّل الأثر لحظة. مطوّر أو محلّل على اشتراك Pro شخصي، ينجز عمل الشركة، ولم يمسّ الإعداد الافتراضي، في موقع مختلف عن الشخص نفسه على مقعد Team. ليست هذه فضيحة — فالأمر موثّق بوضوح، ويمكنك تغيير الإعداد في أي وقت من ضوابط الخصوصية على claude.ai/settings/data-privacy-controls. لكنه أشيع سوء فهم، وهو ما سيهتمّ به فريق الأمان لديك أكثر من غيره.
القاعدة العملية: إن كان عمل شركة، فينبغي أن يكون على مقعد شركة. هذه الجملة وحدها تحلّ معظم القلق في هذا الباب كله.
كم يُحفَظ أي شيء
يتبع الاحتفاظ التقسيم نفسه:
| الحالة | مدة الاحتفاظ |
|---|---|
| تجاري (Team وEnterprise والـ API) | 30 يومًا، قياسيًا |
| استهلاكي، مشاركة البيانات معطّلة | 30 يومًا |
| استهلاكي، مشاركة البيانات مفعّلة | 5 سنوات |
النصوص المرسلة عبر /feedback و/bug و/share | 5 سنوات |
| نصّ جلسة تختار مشاركته بعد استبيان الجودة | حتى 6 أشهر |
| Zero Data Retention (Enterprise المؤهّل) | لا حفظ على الخوادم |
أمران يستحقّان الإشارة ويفوتان الناس.
Zero Data Retention ليس تلقائيًا على Enterprise. إنه متاح للحسابات المؤهّلة ويُفعَّل لكل مؤسسة على حدة بواسطة فريق حسابك بعد التأكّد من الأهلية — وليس جزءًا من خطة Enterprise القياسية. وإن كان ZDR شرطًا صارمًا في قطاعك، فاطرحه أثناء الشراء لا افتراضًا.
هناك نسخة على جهازك أنت. يخزّن Claude Code نصوص الجلسات محليًا، بصيغة نصّية واضحة، تحت ~/.claude/projects/، لمدة 30 يومًا افتراضيًا حتى تستطيع استئناف الجلسات. هذا ملف محلي على حاسوب، أي أنه يرث ما لديك أصلًا من تشفير للقرص وسياسة للأجهزة — وهو قابل للتعديل عبر إعداد cleanupPeriodDays. لمعظم المؤسسات هذه ليست مشكلة؛ ولقلّة منها هي أهمّ تفصيل.
ما الذي يغادر جهازك فعلًا
يعمل Claude Code محليًا. ولإنجاز أي شيء مفيد عليه إرسال الـ prompts ومحتوى الملفات ذي الصلة إلى الـ model عبر الشبكة — مشفَّرًا أثناء النقل بـ TLS 1.2 أو أحدث. هذا جوهر تدفّق البيانات، ولا توجد نسخة من هذا المنتج لا يحدث فيها ذلك.
وعند التخزين، يعتمد التشفير على مزوّدك: تشفير أقراص على مستوى البنية التحتية بمعيار AES-256 على الـ API الخاص بـ Anthropic، وAES-256 بمفاتيح تديرها AWS على Bedrock (مع إتاحة مفاتيح يديرها العميل عبر KMS)، ومفاتيح تديرها Google مع إتاحة CMEK على منصّة Google Cloud.
وإلى جانب ذلك تدفّقان أصغر، وكلاهما قابل للتحكّم:
- مقاييس الاستخدام — زمن الاستجابة والموثوقية وأنماط الاستخدام. وهذه لا تتضمّن أبدًا كودك أو الـ prompts أو مسارات ملفاتك. عطّلها بـ
DISABLE_TELEMETRY=1. - تقارير الأخطاء — آثار أعطال Claude Code نفسه، مع تنقيح الأنماط المعروفة للمفاتيح السرّية ومسارات الملفات والمعلومات الشخصية قبل مغادرة أي شيء الجهاز. عطّلها بـ
DISABLE_ERROR_REPORTING=1. وهي مفعّلة أصلًا فقط لتسجيلات الدخول على Pro وMax المتّصلة مباشرةً بـ Claude API، ولا تفعّل أبدًا للمؤسسات التي لديها اتفاقيات Zero Data Retention أو HIPAA.
واضبط CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC لتعطّلها جميعًا دفعة واحدة. وعلى Bedrock ومنصّة Google Cloud وMicrosoft Foundry تكون تقارير الأخطاء والمقاييس وتقارير العلل معطّلة افتراضيًا أصلًا.
واستثناء واحد يستحقّ المعرفة لأنه يفاجئ فرق الشبكات: قبل جلب أي رابط، ترسل أداة WebFetch اسم المضيف فقط — لا المسار ولا محتوى الصفحة — إلى api.anthropic.com لفحصه مقابل قائمة حظر أمنية، مع تخزين مؤقّت لكل مضيف لمدة خمس دقائق. ويجري هذا بغضّ النظر عن المزوّد. وإن كانت شبكتك تحجب هذا النطاق، فستفشل عمليات الجلب حتى تسمح به أو تعطّل الفحص.
الجزء الذي تتحكّم فيه: ما يستطيع Claude لمسه
السياسة نصف الأمان فقط. والنصف الآخر هو النطاق، وهنا تملك أكبر تحكّم مباشر.
يرى Claude المجلد الذي تفتحه ولا شيء غيره. ويصوغ Cowork هذا صراحةً على هيئة نموذج permissions على مستوى المجلد — تمنح صلاحية القراءة والكتابة والإنشاء في مجلدات محدّدة، والملفات خارجها غير مرئية. ليس هذا وعدًا بحسن السلوك؛ إنه الآلية. والنتيجة العملية أن لسؤال «كيف نحدّ من الانكشاف؟» إجابة بسيطة جدًا: وجّهه إلى أقلّ.
يسأل قبل الإجراءات ذات الأثر. على Desktop، وضع Ask permissions — الذي توصي به الوثائق للمستخدمين الجدد — يتوقّف قبل أي شيء مهمّ وينتظر نقرتك. وتظهر التغييرات على هيئة diff مرئي تقبله أو ترفضه. أما وضع auto فيستبدل السؤال بمصنِّف يمرّر الإجراءات الآمنة ويحجب الخطرة، ويحجب فئات بعينها حجبًا صارمًا، منها أوامر git المدمّرة حين لم تطلب التخلّص من عملك.
قواعد الـ permissions صريحة. تستطيع المؤسسات كتابة قواعد سماح ومنع — تصل إلى مطابقة معاملات أدوات بعينها — وقواعد منع صارمة تحجب إجراءً دون قيد أو شرط بغضّ النظر عن أي استثناء سماح.
الخلاصة الصادقة: agent لديه صلاحية على الملفات آمن بقدر نطاقه وبوّابات موافقته بالضبط. وكلاهما قابل للضبط، وكلاهما مرئي، والوضع الافتراضي يسأل ولا يفترض.
ما سيطلبه فعلًا فريقا تقنية المعلومات والأمان
لنشر على مستوى المؤسسة، تكون القائمة عادةً واحدة في كل مكان:
- تسجيل الدخول الموحّد — SAML 2.0 وOIDC مدعومان، فتتمركز المصادقة مع كل شيء آخر.
- سجلّات التدقيق — أحداث المصادقة، واستدعاءات الـ model مع بياناتها الوصفية، والتفاعلات مع الملفات. تُحفَظ 30 يومًا افتراضيًا في لوحة الإدارة، وتُصدَّر بصيغة JSON أو CSV، أو تُدفَع مباشرةً إلى منصّات SIEM مثل Splunk أو Datadog أو Elastic.
- واجهة Compliance API — نقاط برمجية لسرد بيانات المؤسسة واسترجاعها وحذفها.
- ضوابط المسؤولين — مفاتيح على مستوى المؤسسة لإمكانات مثل الـ artifacts والـ connectors، وتحديد النطاق بحسب الدور على Enterprise، وسياسات الاحتفاظ، والتحكّم في إمكانية مشاركة أي شيء علنًا.
- خيارات القطاعات المنظَّمة — مفاتيح تشفير يديرها العميل، واتفاقيات HIPAA، وZero Data Retention، ويُرتَّب كلٌّ منها مع فريق حسابك.
وإن كنت تعمل عبر التنفيذ السحابي بدل المحلي — Claude Code على الويب — فيُستنسخ الـ repository خاصتك في جهاز افتراضي معزول، وتُدار مصادقة GitHub عبر وسيط آمن بحيث لا تدخل بياناتك الاعتمادية إلى البيئة المعزولة، وتمرّ كل حركة الخروج عبر وسيط أمني لتسجيل التدقيق.
الخطر الذي لا تغطّيه أي سياسة: prompt injection
هذا يستحقّ قسمًا خاصًا لأنه الخطر الجديد فعلًا، ولا يحلّه أي إعداد.
الذكاء الاصطناعي الذي يقرأ مستندًا يتأثّر بما فيه. فجدول بيانات أو صفحة ويب أو ملف من خارج مؤسستك قد يحتوي نصًا مصاغًا للتلاعب بالـ model — لدفعه إلى كشف معلومات من موضع آخر في سياقه، أو إلى اتخاذ إجراء لم تقصده. وتشير Anthropic إلى هذا صراحةً بخصوص Claude for Excel: لا تطبّقه على جداول بيانات من مصادر خارجية غير موثوقة.
والتخفيفات غير براقة لكنها فعّالة:
- عامِل الملفات من خارج مؤسستك على أنها مدخلات غير موثوقة، كما تعامل مرفق بريد إلكتروني.
- أبقِ بوّابة الموافقة مفعّلة لأي شيء يتّجه إلى الخارج — إرسال، أو نشر، أو ترحيل.
- لا تمنح جلسةً صلاحية واسعة ومحتوى غير موثوق في الوقت نفسه. النطاق هو الدفاع.
ليس هذا سببًا لتجنّب التقنية. إنه سبب لإبقاء إنسان عند النقطة التي يغادر فيها العمل المبنى.
إذن — هل هو آمن؟
لعمل الشركة على خطة شركة، مع نطاق معقول وبوّابات الموافقة مفعّلة: نعم، والضوابط المتاحة أدقّ ممّا تستخدمه معظم المؤسسات فعلًا.
وأنماط الفشل التي تؤذي حقًا ليست غريبة:
- عمل شركة على حساب Pro شخصي مع تفعيل مشاركة البيانات — الخطأ الذي وُجد هذا الدليل كله لمنعه.
- افتراض أن ZDR مشمول في Enterprise بينما يجب تفعيله لكل مؤسسة على حدة.
- توجيهه إلى كل شيء لأن تحديد النطاق بدا احتكاكًا في اليوم الأول.
- الثقة بمخرجات تبدو منجزة. لا سياسة تحميك من رقم غير مراجَع في ملف مجلس الإدارة.
عالِج هذه الأربعة وستكون قد عالجت من المخاطر الحقيقية أكثر ممّا يعالجه أي قدر من استمارات المورّدين الشكلية.
تطرحه على فريق؟ دليل الفرق يغطّي ترتيب الخطوات، ودليل الخطط يوضّح أي خطة تضعك تحت الشروط التجارية الموصوفة أعلاه.