اتفاقية معالجة البيانات (DPA)

تعالج Devotel البيانات الشخصية نيابة عنك كـ معالج، وأنت المتحكم. GDPR المادة 28 تتطلب أن تحكم هذه العلاقة عقد مكتوب — اتفاقية معالجة البيانات. تعرض Devotel ذلك العقد كاحتكال click-wrap خدمة ذاتية لتتمكن من مراجعته وقبوله وأرشفته دون تسليم قانوني يدوي. يغطي هذا الدليل دورة الحياة الكاملة: ما تحكمه الـ DPA، وكيف يعمل dpa_status، وكيف تعاين القالب، وكيف تقبله، وكيف تحمل النسخة المنفذة، وما يحدث عندما ينشر إصدار قالب جديد.

القبول هو حفظ سجلات تعاقدي محض. لا يفرض أبداً بوابة على الإرسال أو الاستقبال أو أي قدرة منتج أخرى.

ما تحكمه الـ DPA

تربط الـ DPA Devotel بالتزامات المعالج في المادة 28(3) من GDPR. بعبارات بسيطة، تلتزم Devotel بـ:

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

قبول الـ DPA لا يغير ما تفعله Devotel ببياناتك — تلك الالتزامات موجودة أياً كان الأمر. القبول هو السجل المكتوب الذي تتطلبه المادة 28 بصفتك المتحكم. تجعل Devotel ذلك السجل توقيعاً إلكترونياً مكتوباً يمكنك إكماله من لوحة التحكم في دقيقة بدلاً من مستند موجّه عبر المشتريات. التوقيع الإلكتروني المكتوب هو احتكال click-wrap: تكتب اسمك القانوني لتوقّع. يسجل كل قبول إصدار القالب، واسم الموقِّع، والبريد الإلكتروني، والعنوان، وختم وقت القبول، وطريقة القبول (اكتب-الاسم). ذلك السجل هو الدليل القانوني للشهادة؛ المستند المعرض المخزن عند القبول هو النسخة المنفذة الرسمية.

حالات `dpa_status`

تكون منظمتك دائماً في إحدى حالتين، تُبلغ عنه بواسطة GET /api/v1/compliance/dpa:

الحالة	المعنى
`not_accepted`	لا يوجد ملف قبول DPA. هذا هو الافتراضي لكل منظمة جديدة.
`accepted`	يوجد ملف قبول DPA. تتضمن الاستجابة الإصدار المقبول، وختم الوقت، وتفاصيل الموقِّع.

بجانب الحالة، يُعيد GET /api/v1/compliance/dpa علامة needs_update. هي true عندما إصدار القالب الذي قبلته منظمتك أقدم من الإصدار الرسمي الحالي — مثلاً، قبلت v1 ونشرت Devotel من ثم v2. العلامة إعلامية: لا شيء محظور، وقبولك الحالي يظل في الملف. تقودها تبة لوحة التحكم لbanner إعادة القبول حتى تعتمد الإصدار الجديد. شكل الاستجابة:

{
  "dpa_status": "accepted",
  "dpa_accepted_version": "v1",
  "dpa_accepted_at": "2026-08-10T14:22:31.410Z",
  "dpa_signer_name": "Jane Roe",
  "dpa_signer_email": "jane@example.com",
  "dpa_signer_title": "General Counsel",
  "current_version": "v1",
  "needs_update": false
}

على عكس HIPAA BAA، ليست للـ DPA مدة سنوية. تبقى مقبولة حتى يُنشر إصدار قالب جديد، حيث تصبح needs_update مشمولة true — لا تنيّف من تلقاء نفسها أبداً.

معاينة القالب

قبل القبول، راجع نص الاتفاقية بالضبط. GET /api/v1/compliance/dpa/template يُعيد القالب معرّباً باسم منظمتك مملوءاً، حتى تقرأ الاتفاقية النهائية بدلاً من مستند مليء بالأسموحات. الحقول التي لا توجد إلا عند القبول — أختام وقت القبول ومرجع المستند — تظهر كعلامات قابلة للقراءة “ممْلئة عند القبول”. حقول الموقِّع تظهر كبلانيز تملؤها لوحة التحكم حياً بينما تكتب.

curl "https://api.orbit.devotel.io/api/v1/compliance/dpa/template?version=v1" \
  -H "Authorization: Bearer sk_live_..."

الاستجابة:

{
  "version": "v1",
  "controller_name": "Acme Health Ltd",
  "format": "markdown",
  "body": "# Data Processing Agreement\n\nThis Data Processing Agreement..."
}

أي دور admin أو أعلى يمكنه المعاينة. المعاينة متطابقة لكل متصل في المنظمة وتغيّرت فقط عندما تنشر Devotel إصدار قالب جديد.

قبول الـ DPA

القبول للمالك فقط — توقيع قانوني ملزم ليس فعلاً من طبقة المطور. POST /api/v1/compliance/dpa/accept يأخذ هوية الموقِّع وشهادة مكتوبة:

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/dpa/accept" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "signer_name": "Jane Roe",
    "signer_email": "jane@example.com",
    "signer_title": "General Counsel",
    "typed_attestation": "Jane Roe"
  }'

الحقل	القاعدة
`signer_name`	اسم الموقِّع القانوني (2–200 حرف).
`signer_email`	عنوان بريد إلكتروني صالح.
`signer_title`	دور الموقِّع أو عنوانه (2–200 حرف).
`typed_attestation`	يجب أن يطابق `signer_name` بالضبط. الموقِّع يعيد كتابة اسمه كالتوقيع؛ عدم التطابق يُرفض بـ `400` (يمنع أيضاً إرسال نموذج فارغ تلقائي).
`template_version`	أختياري. افتراضي إلى الإصدار الرسمي الحالي.

عند النجاح، يعمل الخادم:

تعريب القالب بتفاصيل الموقِّع، وأختام وقت القبول، ومرجع مستند منشأ
تخزين المستند المعرّب كالنسخة المنفذة الرسمية
تسجيل القبول على المنظمة — الإصدار، وختم الوقت، والموقِّع — وإلحاقه بتاريخ قبول غير قابل للتغيير، بحيث لا تمحو إعادات القبول السجل السابق
كتابة إدخال compliance.dpa.accepted في سجل التدقيق — إدخال التدقيق هو الدليل القانوني للشهادة

تُعيد الاستجابة الحالة الجديدة مع مرجع المستند:

{
  "dpa_status": "accepted",
  "dpa_accepted_version": "v1",
  "dpa_accepted_at": "2026-08-24T09:41:12.008Z",
  "dpa_signer_name": "Jane Roe",
  "dpa_signer_email": "jane@example.com",
  "dpa_signer_title": "General Counsel",
  "current_version": "v1",
  "needs_update": false,
  "dpa_id": "dpa_9f2k…"
}

القبول مقيدٌ بمعدل قلوب من الطلبات لكل دقيقة؛ يجب أن يكون فعلاً متعمداً، لا حلقة مكتَب.

تحميل النسخة المنفذة

بمجرد وجود DPA في الملف، أي admin أو أعلى يمكنه إحضارها لسجلاتك، أو تدقيق عميل، أو منظِّم:

curl "https://api.orbit.devotel.io/api/v1/compliance/dpa/download" \
  -H "Authorization: Bearer sk_live_..."

تحمل الاستجابة رابط تحميل صالحاً 24 ساعة:

{
  "url": "https://storage.googleapis.com/…/dpa/org_…/dpa_….pdf?X-Goog-Signature=…",
  "expires_in_seconds": 86400
}

شَارك الرابط ضمن تلك النافذة أو حمّل الملف بنفسك وأرشفه. إن لم تُقبل DPA بعد، تُعيد النقطة 404.

تدفق لوحة التحكم

نفس دورة الحياة متاحة دون لمس API في Settings → Compliance → DPA:

بطاقة الحالة — تعرض not_accepted / accepted، والإصدار والتاريخ المقبولين، والموقِّع، وbanner عندما needs_update هي true
معاينة القالب — الاتفاقية المعربة باسم منظمتك مملوءاً
نموذج الشهادة — الاسم، والبريد الإلكتروني، والعنوان، وحقل التوقيع اكتب-الاسم (للمالك فقط)
التحميل — رابط النسخة المنفذة بمجرد القبول

الأسئلة الشائعة

ماذا يحدث عندما تصبح needs_update مشمولة true؟ نشرت Devotel إصدار قالبة جدك من المقبول. قبولك الحالي يبقى كاملاً في الملف ولا شيء محظور. لتعتمد الإصدار الجديد، عاينه (بارامتر الطلب version افتراضي إلى الإصدار الحالي)، ثم اقبل مجدداً بنفس التدفق. القبول الجديد يسود حقول الحالة، والقبول السابق يبقى في تاريخ القبول غير القابل للتغيير. هل تتطلب إعادة القبول النموذج الكامل مجدداً؟ نعم. كل قبول توقيع مكتوب مستقل — يجب أن تطابق الشهادة المكتوبة اسم الموقِّع في كل مرة. من يمكنه فعل ماذا؟

الفعل	`owner`	`admin`	`developer` / `viewer` / `billing`
قراءة حالة DPA	نعم	نعم	لا
معاينة القالب	نعم	نعم	لا
تحميل النسخة المنفذة	نعم	نعم	لا
قبول / إعادة قبول	نعم	لا	لا

هل تفرض DPA بوابة أي شيء؟ لا. القبول حفظ سجلات تعاقدي. على عكس BAA، التي تفرض وضع HIPAA وإرسال PHI، لا تحظر DPA أبداً قدرة منتج. ما التزام متحكمي بعد القبول؟ تُسَهم قبول DPA متطلب العقد المادة 28 من جانبك. تحديد أساسك القانوني، وتكوين ضوابط الموافقة والإحباط الخاصة بك، والإجابة على طلبات أصحاب البيانات (راجع DSAR) تبقى لك. لترتيب تجميع تلك القطع، راجع Assembling a GDPR Posture End to End.

آخر تحديث: أغسطس 2026 لأسئلة عن DPA، اتصل: compliance@devotel.io

Getting Started

Channels

Channels (Voice)

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Brand & press

Changelog

اتفاقية معالجة البيانات (GDPR المادة 28)

اتفاقية معالجة البيانات (DPA)

ما تحكمه الـ DPA

حالات `dpa_status`

معاينة القالب

قبول الـ DPA

تحميل النسخة المنفذة

تدفق لوحة التحكم

الأسئلة الشائعة

​اتفاقية معالجة البيانات (DPA)

​ما تحكمه الـ DPA

​حالات dpa_status

​معاينة القالب

​قبول الـ DPA

​تحميل النسخة المنفذة

​تدفق لوحة التحكم

​الأسئلة الشائعة

اتفاقية معالجة البيانات (DPA)

ما تحكمه الـ DPA

حالات `dpa_status`

معاينة القالب

قبول الـ DPA

تحميل النسخة المنفذة

تدفق لوحة التحكم

الأسئلة الشائعة