الأمان جزء أساسي من طريقة بنائنا للمنتج. تصف هذه الصفحة ما هو صحيح فعلًا عن بنيتنا التقنية وممارساتنا اليوم — وليست قائمة تسويقية. وحيثما لم نُنجز شيئًا بعد (تدقيق رسمي أو شهادة)، نقول ذلك بوضوح بدلًا من الإيحاء بغير ذلك.
بنية مهيّأة لمتطلبات HIPAA
لقد بنينا داخل المنصة، وبشكل افتراضي، الضمانات التقنية التي يحتاجها أي سير عمل خاضع لـ HIPAA:
- إزالة هوية البيانات قبل التخزين أو المعالجة بالذكاء الاصطناعي. يمكن تمرير محتوى المحادثات عبر خطوة تلقائية لحجب بيانات PII/PHI (باستخدام Microsoft Presidio، مع توفّر نموذج مضبوط على النصوص السريرية للسياقات الطبية) قبل أن تصل إلى قاعدة بياناتنا أو مزوّدي الذكاء الاصطناعي لدينا أو البحث والاسترجاع — مع اكتشاف جميع فئات المعرّفات الثماني عشرة الواردة في أسلوب Safe Harbor (الملاذ الآمن) ضمن HIPAA. وهذه الخطوة تفشل بشكل مغلق: فإذا تعذّر تشغيل الحجب، تُرفض الرسالة بدلًا من تخزينها بصمت دون حجب.
- سجلّ تدقيق يكشف أي عبث. يُسجَّل الوصول إلى السجلات الحساسة في سجلّ مترابط بسلسلة تجزئة (hash-chained) مصمَّم بحيث لا يمكن تعديل مدخلاته بصمت بعد تسجيلها.
- تحكم في الوصول قائم على الأدوار وعلى مستوى المورد. تعمل الأدوار على مستوى المنصة والأذونات لكل مورد معًا على ضبط من يرى ماذا.
- التشفير أثناء النقل وفي حالة السكون، مع إتاحة تشفير على مستوى الحقل للبيانات الحساسة المحدَّدة.
ما ليست عليه هذه الصفحة: إنها ليست شهادة امتثال لـ HIPAA. لا توجد أي شهادة HIPAA صادرة عن جهة حكومية — فالامتثال هو مزيج من الضمانات التقنية (المذكورة أعلاه)، وسياسات إدارية مكتوبة، واتفاقيات شريك أعمال موقَّعة (Business Associate Agreement, BAA) مع كل مورّد في مسار البيانات، ويُقيَّم حالةً بحالة لكل علاقة مع عميل بعينه. إذا كنت بحاجة إلى معالجة معلومات صحية محمية (PHI) معنا بموجب اتفاقية شريك أعمال، تحدّث إلينا — وسنعمل معك على تحديد ما يلزم لحالة الاستخدام الخاصة بك.
حماية البيانات
التشفير
- أثناء النقل: TLS في كل مكان بين العملاء وحافة شبكتنا وبنيتنا الأساسية في نقطة الأصل.
- في حالة السكون: تشفير على مستوى المزوّد لمخزن بياناتنا الأساسي وتخزين الكائنات، إضافة إلى طبقة تشفير مخصّصة على مستوى الحقل للحقول الحساسة المحدَّدة.
- إدارة الأسرار: تُدار بيانات الاعتماد ومفاتيح API عبر مدير أسرار مركزي، لا مكتوبة داخل الشيفرة ولا مخزَّنة في ملفات إعداد بنص صريح. وبيئة الإنتاج مُهيّأة لتفشل بشكل مغلق بدلًا من الرجوع بصمت إلى بيانات اعتماد قديمة إذا تعذّر الوصول إلى خدمة الأسرار.
تقليل البيانات إلى الحد الأدنى
- إزالة هوية البيانات (أعلاه) تعني أن بيانات PII/PHI الأصلية تُتلَف ولا يُحتفظ بها، أينما عمل ذلك المسار — أي أصغر أثر ممكن في حال تعرّض أي نظام لاحق للاختراق يومًا ما.
- السجلات تحتوي على بيانات وصفية فقط كسياسة معتمدة: نحن لا نكتب محتوى الرسائل ولا عناوين البريد الإلكتروني ولا أي بيانات شخصية أخرى في سجلات التطبيق أو رسائل الأخطاء.
ضوابط الوصول
- المصادقة عبر Auth0.
- تحكم في الوصول قائم على الأدوار (على مستوى المنصة) إضافة إلى أذونات لكل مورد (على مستوى المستند أو مساحة العمل) — مع مبدأ الحد الأدنى من الامتيازات افتراضيًا.
- مراجعات ربع سنوية للوصول والإعدادات لخدمات الإنتاج.
أمان التطبيق
- الدفاع ضد XSS عند حدّ العرض: يُنقّى المحتوى الذي ينشئه المستخدمون والمحتوى الذي يولّده الذكاء الاصطناعي (باستخدام DOMPurify) في كل موضع يُعرض فيه كـ HTML؛ ولا يُسمح بحقن HTML خام من مصادر غير موثوقة.
- اختبار التفويض: نُجري اختبارات أمنية خاصة بنا، يدوية وبمساعدة الذكاء الاصطناعي، على بيئتَي الاختبار والإنتاج، بما في ذلك فحوص التفويض/IDOR بحسابات مُصادَق عليها — وهذا ليس (حتى الآن) برنامج اختبار اختراق دوري من طرف ثالث، ولن ندّعي وجود مثل هذا البرنامج قبل أن يصبح موجودًا فعلًا.
- مراجعة التبعيات والشيفرة: مراجعة شيفرة معيارية لكل التغييرات؛ وتُتابَع تحديثات التبعيات عبر أدوات البناء المعتادة لدينا.
التوافر والمراقبة
- مراقبة اصطناعية لنقاط النهاية التي يستخدمها العملاء، مع تنبيه فريق المناوبة عبر PagerDuty خلال دقائق من أي انقطاع حقيقي، لا عند أخطاء الخادم فقط — وهي فحوص تتحقق من المحتوى نفسه، لا مجرد “هل أعاد الاستجابة 200”.
- بنية تحتية متعددة المناطق (حافة Cloudflare + نقطة أصل على Google Cloud) مع نسخ احتياطية تلقائية لمخزن بياناتنا الأساسي.
- نحن لا ننشر حاليًا أي اتفاقية مستوى خدمة (SLA) تعاقدية لزمن التشغيل. وإذا كانت حالة استخدامك تتطلب ذلك، فاسألنا — يمكننا مناقشة ما هو واقعي بالنسبة لنشرك.
الاستجابة للحوادث
لدينا عملية موثَّقة للاستجابة للحوادث: الاكتشاف والتصنيف، والاحتواء، وتقييم صادق لما إذا كان الحادث يرقى إلى خرق واجب الإبلاغ عنه، ثم المعالجة، ثم مراجعة لاحقة خالية من إلقاء اللوم تغذّي ما نراقبه لاحقًا. وإذا كنت عميلًا مرتبطًا معنا باتفاقية شريك أعمال، فإن تلك الاتفاقية هي التي تحدد التزاماتنا تجاهك بشأن الإخطار — وشروطها هي السارية، لا هذه الصفحة.
للإبلاغ عن مسألة أمنية أو ثغرة مشتبه بها، راسلنا على security@divinci.ai. نحن لا نُشغّل حاليًا أي برنامج رسمي لمكافآت اكتشاف الثغرات (bug bounty)؛ لكننا نأخذ البلاغات على محمل الجد وسنتعاون معك بحسن نية.
أين نقف من الشهادات الرسمية
نقولها بصراحة، لأن كثيرًا من صفحات الأمان لا تفعل:
- HIPAA: راجع “بنية مهيّأة لمتطلبات HIPAA” أعلاه. أما ما إذا كانت اتفاقية شريك أعمال تنطبق أم لا، فذلك يعتمد على علاقتك المحددة بنا — ونحن نقيّم ذلك لكل عميل على حدة، لا كادّعاء عام شامل.
- SOC 2: لم نبدأ به بعد. إنه ضمن خارطة طريقنا؛ وسنحدّث هذه الصفحة عندما يكون هناك شيء حقيقي يُبلَّغ عنه — وليس قبل ذلك.
- ISO 27001 وFedRAMP وPCI DSS: نحن لا نملك هذه الشهادات. تُعالَج مدفوعات البطاقات عبر Stripe، وDivinci لا تخزّن بيانات حاملي البطاقات بشكل مباشر.
نُفضّل أن نُقلّل من ادّعاءاتنا هنا فنكسب الثقة، على أن نُبالغ فيها ثم نضطر إلى التراجع عنها.
التواصل
للأسئلة الأمنية أو بلاغات الثغرات أو أسئلة الامتثال المتعلقة بصفقة محددة: security@divinci.ai