صنع في الاتحاد الأوروبي، وأين تُحفظ بياناتك

أين يُبنى Nessie، وأين تُحفظ بياناتك، وما الذي تتحكم فيه عندما تستضيفه بنفسك.

من يبنيه، وبموجب أي قانون

تبني Nessie شركة UnlikeOtherAI s.r.o.، وهي شركة مسجّلة في جمهورية التشيك وتعمل وفق القانون التشيكي.

هذه الصفحة وصف لكيفية بناء البرنامج والمكان الذي يعمل فيه. وهي ليست بيان امتثال: لا تحمل Nessie أي شهادة أمنية، ولا ينبغي فهم أي شيء هنا على أنه كذلك. أما البيانات الشخصية التي تُعالَج وعلى أي أساس، فهي موضوع سياسة الخصوصية، وهي صفحة منفصلة.

أين يعمل المنتج المستضاف

تعمل Nessie Cloud على مزوّدي استضافة أوروبيين، منهم Scaleway وHetzner وغيرهما. ونختار أفضل خدمة يقدّمها كل مزوّد، لذلك قد تعمل أجزاء مختلفة من المنتج لدى مزوّدين مختلفين، وكلهم في أوروبا.

أي تفصيل أدق من ذلك، كموقع بعينه أو مدينة أو مركز بيانات، لا نذكره هنا عمدًا، لأنه سيصبح قديمًا دون أن ينتبه أحد.

الاستضافة الذاتية تضع الخيار بين يديك

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

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

ما تحتفظ به Nessie، وما لا تحتفظ به عمدًا

الهوية لا تُنسخ

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

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

والأمر نفسه ينطبق على البنية. فمؤسسة واحدة لدى المزوّد تقابل مؤسسة واحدة في Nessie، ويربط بينهما معرّف المؤسسة لدى المزوّد؛ والفريق الذي لا يرتبط بمصدر أعلى يردّ بالخطأ 404 TEAM_NOT_LINKED بدل الرجوع إلى تخمين محلي، وقراءة قائمة الأعضاء الحية تذهب إلى مزوّد الهوية ولا تحفظ شيئًا.

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

لا شيء تجاري

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

الأسرار

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

أما بيانات الاعتماد التي يجب على Nessie نفسها الاحتفاظ بها لتعمل كعميل OAuth، وهي بيانات اعتماد الموصّلات وصناديق البريد وأسرار webhook ومواد تجديد الجلسات وحمولات المنفّذ، فتُغلَق في أظرف AES-256-GCM مرتبطة بغرضها، تحت حلقة مفاتيح ذات إصدارات هي جذر منفصل عن سرّ توقيع الجلسات، مع إجراء موثّق للتدوير.

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

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

عزل المستأجرين

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

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

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

سجل التدقيق

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

السجل للإضافة فقط بحكم التصميم، ولا توجد طريقة للكتابة فيه من الخارج: POST /api/audit-log غير موجود، وهذا مقصود. والمدخلات متسلسلة، إذ يحمل كل مدخل بصمة SHA-256 لحقوله المعتمدة مع بصمة المدخل السابق لتلك المؤسسة، فأي صف معدَّل أو محذوف يكسر السلسلة ويمكن كشفه. ويستطيع مالك المؤسسة أو مسؤولها تتبّع هذه السلسلة عند الطلب، ويُبلَّغ بالموضع الذي انكسرت عنده أولًا إن انكسرت.

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

دفتر التكاليف

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

هذا الدفتر قياس تشغيلي: ما أنفقته مؤسسة ولحساب من. وهو ليس فاتورة، وليس مرجعًا للفوترة.

الأطراف الثالثة عند استخدام المنتج المستضاف

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

وكل ما عدا ذلك تقريبًا معطّل إلى أن يهيّئه مشغّل، وتُعلَن حالته بدل أن يفشل بصمت: حسابات Google وMicrosoft وSlack المتصلة؛ بريد الوكلاء عبر Amazon SES، الذي يشغّله النشر في حسابه الخاص دون وسيط؛ الإشعارات الفورية للجوال والمتصفح؛ موصّلات البحث ومصادر اللوحات؛ المتصفحات السحابية. وهناك تفصيلان يستحقان الذكر لأنهما يغيّران وجهة البيانات:

• صناديق البريد المتصلة تبقى لدى مزوّدك. يُقرأ البريد مباشرة من مزوّدك، عبر IMAP وSMTP أو عبر تسجيل الدخول الخاص بالمزوّد؛ وتخزّن Nessie بيانات الاعتماد مغلقة، ولا شيء آخر عن الحساب. وصندوق البريد الذي تربطه بصندوق وارد Clients هو الاستثناء: فأنت تطلب أن تُحفظ محادثاته مع كل عميل، لذلك تُنسخ إلى Nessie.
• المكالمات الصوتية داخل التطبيق لا تمر عبر Nessie. تتوسط واجهة API في تسليم بيانات اعتماد، ويفتح العميل اتصال الصوت بنفسه. أما الإملاء والمكالمات الهاتفية فمختلفان: فصوتهما يمر عبر Nessie إلى مزوّدي الكلام والنماذج الذين يعالجونه.

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

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

تشغيلها بنفسك يغيّر هذا كله

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

وهذا هو جوهر الترتيب: البرنامج هو نفسه، والقرارات المتعلقة بمكان تشغيله وما يمكنه الوصول إليه تعود لمن يشغّله. وتشرح صفحة التثبيت الكيفية.