بيانات الشركة والخصوصية والقواعد

هنا يصحّ أمران في آنٍ واحد عادةً: السؤال يبدو ضخمًا، والإجابة الصادقة عن معظم العمل اليومي هي “نعم، من الحساب الصحيح”. يبدو ضخمًا لأن سؤال “هل هذا آمن؟” هو في الحقيقة عدّة أسئلة مجموعة معًا — هل يستخدم المزوّد ما ترسله في تدريب نماذجه، ومن لديه صلاحية الاطلاع عليه لدى المزوّد ولأي مدّة، وهل تسمح عقودك أنت أصلًا بإرساله إلى طرف ثالث. أجوبة مختلفة، ومسؤولون مختلفون، ومعظم الجدال حول الذكاء الاصطناعي والبيانات هو شخصان يجيب كلٌّ منهما عن سؤال غير الذي يجيب عنه الآخر.

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

والنصف الذي ينساه الناس هو أن الخصوصية لا تتعلّق بما يدخل فقط. في اللحظة التي تسمح فيها لـ Claude بقراءة صفحة ويب أو صندوق بريد أو مستند كتبه شخص من خارج فريقك، تكون قد سمحت له أيضًا بقراءة أي تعليمات مخبَّأة داخله. هذا هو prompt injection، المعرَّف أدناه، وهو سبب أن خطوات الموافقة ليست بيروقراطية: الأذونات هي ما يقف بين مستند عدائي وإجراء حقيقي على أنظمتك. والحذر نفسه ينطبق أول مرة تثبّت فيها connector — انظر ربط Claude ببقية أدواتك.

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