سيادة AI
مقالمتخصص

مسؤول الأنظمة المستقلة Autonomous Systems Officer وحوكمة الذكاء الاصطناعي في DIFC

نُشر 2 سبتمبر 2026

يتضمن Regulation 10 النافذ في مركز دبي المالي العالمي بالفعل دور Autonomous Systems Officer ضمن شروط استخدام الأنظمة المستقلة وشبه المستقلة في أنشطة المعالجة عالية المخاطر. أما تعديلات 2026 المقترحة فتهدف إلى توضيح الدور ومتطلبات الاعتماد والشهادات وتطوير النظام التنظيمي القائم.

⚡ الخلاصة السريعة

Autonomous Systems Officer ليس دورًا جديدًا ظهر لأول مرة في مقترحات 2026؛ أساسه موجود في Regulation 10 النافذ، بينما تسعى تعديلات 2026 المقترحة إلى زيادة الوضوح حول دوره ونظام الاعتماد والشهادات.

الخلاصة التنفيذية

يمثل Autonomous Systems Officer — ASO تطورًا مهمًا في الحوكمة لأنه يربط الأنظمة المستقلة بمسؤول بشري متخصص لا يكتفي بفهم الخصوصية، بل يحتاج إلى فهم مخاطر المعالجة والأنظمة المتقدمة والرقابة والمساءلة.

لكن توجد نقطة يجب تثبيتها بدقة:

ASO ليس فكرة استحدثتها استشارة DIFC لعام 2026.

أساس الدور موجود بالفعل في Regulation 10 النافذة منذ 2023.

تعديلات 2026 المقترحة تسعى إلى تطوير النظام القائم، وزيادة الوضوح حول الدور، ومتطلبات الشهادات والاعتماد، وبعض العناصر التنظيمية المرتبطة به.


تصحيح مهم حول أصل دور ASO

Regulation 10.3.3 تتناول الأنظمة المستخدمة في High Risk Processing Activities.

ومن بين الشروط الواردة في النص تعيين:

Autonomous Systems Officer.

إذن التسلسل الصحيح هو:

2023: Regulation 10 تضع الأساس التنظيمي للدور.

ثم:

2026: DIFC تقترح تعديلات لتوضيح وتطوير النظام التنظيمي، بما في ذلك مزيد من الوضوح حول ASO.

وهذا الفرق مهم جدًا في Regulatory Intelligence.


ما هو Autonomous Systems Officer؟

يمكن فهم ASO باعتباره وظيفة مساءلة وإشراف متخصصة ترتبط باستخدام الأنظمة المستقلة وشبه المستقلة في السياقات التي تحددها Regulation 10.

الدور ليس:

  • AI Engineer.
  • Model Developer.
  • CIO.
  • DPO باسم جديد.

بل وظيفة حوكمية متخصصة.


الأساس في Regulation 10

ينص Regulation 10.3.3، في سياق High Risk Processing Activities، على شروط تشمل:

  • وجود متطلبات التدقيق والشهادات التي يحددها Commissioner.
  • امتثال النظام لهذه المتطلبات.
  • ارتباط أغراض معالجة البيانات بالأغراض البشرية المحددة أو المعتمدة.
  • تعيين ASO.

إذن ASO جزء من منظومة أوسع.

لا يجوز أخذ الدور وحده وفصله عن:

Risk + Certification + Purpose + Accountability.


ارتباطه بـHigh Risk Processing

هذه نقطة حاسمة.

لا ينبغي ترجمة Regulation 10 إلى قاعدة تقول:

كل مؤسسة تستخدم AI يجب أن تعين ASO.

النص أكثر تحديدًا.

يجب أولًا تقييم:

  • هل Regulation 10 تنطبق؟
  • هل النظام يعالج Personal Data؟
  • هل الحالة تدخل High Risk Processing Activities؟
  • ما المتطلبات الحالية التي أصدرها Commissioner؟

فقط بعد ذلك يمكن تحديد obligation بشكل صحيح.


ASO مقابل DPO

Regulation 10 تربط ASO بكفاءات ووضع ودور ومهام مماثلة أو قريبة بدرجة كبيرة من DPO.

لكن ذلك لا يعني أنهما متطابقان دائمًا.

DPO

تركيزه الأساسي:

  • Data Protection Law.
  • حقوق Data Subjects.
  • Privacy compliance.
  • DPIA.
  • الإشراف على معالجة البيانات.

ASO

يحتاج أيضًا إلى التعامل مع:

  • Autonomous systems.
  • AI risks.
  • System design.
  • Algorithmic impact.
  • Human control.
  • Certification.
  • Accountability of advanced systems.

قد يكون الشخص نفسه قادرًا على أداء الدورين إذا توفرت الكفاءة والاستقلالية والمتطلبات.

لكن لا ينبغي افتراض ذلك آليًا.


الكفاءة والاستقلالية

وظيفة ASO لا تحقق الغرض منها إذا كانت مجرد اسم في Organization Chart.

يجب النظر إلى:

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

الوظيفة التي لا تستطيع تحدي قرار النشر ليست Assurance Function قوية.


المساءلة المؤسسية

وجود ASO لا ينقل كل المسؤولية إليه.

تبقى المسؤوليات موزعة على:

  • Deployer.
  • Operator.
  • Executive Management.
  • Data Protection.
  • Risk.
  • Security.
  • System Owner.

ASO يعمل داخل هذا النظام.

لا يصبح "مالك جميع مخاطر AI".


موقع ASO في نموذج الحوكمة

يمكن للمؤسسة بناء نموذج مثل:

Board / Executive Oversight

AI Governance Committee

System Owner / Process Owner

ASO / DPO / Risk / Security / Compliance

Development and Operations Teams

في هذا النموذج يكون ASO جزءًا من Challenge and Oversight Layer.


العلاقة بالشهادات والتدقيق

High Risk Processing في Regulation 10 مرتبط بالتدقيق والشهادات.

لذلك دور ASO لا ينبغي أن يكون منفصلًا عن:

  • Certification readiness.
  • Evidence management.
  • Risk assessment.
  • Periodic review.
  • Controls testing.
  • Incident management.

إذا كان النظام عالي المخاطر لكنه لا يملك Evidence يمكن فحصها، تصبح وظيفة ASO نظرية.


ماذا تقترح تعديلات 2026؟

في يونيو 2026 طرحت DIFC تعديلات مقترحة على Data Protection Regulations.

المقترحات تشمل تطوير Regulation 10، وتعزيز مفاهيم:

  • Safety.
  • Ethical development.
  • Privacy by design.
  • Certification.
  • Accreditation.
  • ASO clarity.

كما تقترح Regulation 11 جديدة تمنح Commissioner سلطات متعلقة بالاعتراف بأطر الاعتماد والشهادات.

لكن هذه العناصر يجب قراءتها وفق حالتها التشريعية.


ما هو نافذ وما هو مقترح؟

نافذ

Regulation 10 الحالية.

وجود ASO في سياق 10.3.3.

الإطار الحالي لحماية البيانات والأنظمة المستقلة.

Regulatory Watch

تعديلات 2026 المقترحة.

Regulation 11 المقترحة.

أي صياغات جديدة لم يتم سنها رسميًا بعد.

هذه التفرقة يجب أن تظهر في Compliance Register.


كيف تستعد المؤسسة؟

حتى قبل أي تعديل نهائي يمكن للمؤسسة القيام بأعمال No-Regret:

  • تحديد الأنظمة المستقلة.
  • تصنيف معالجة البيانات.
  • تحديد High Risk Processing.
  • مراجعة أدوار DPO وASO.
  • بناء Evidence Repository.
  • تحديد أصحاب المسؤولية.
  • مراجعة الشهادات المطلوبة.
  • تتبع التغييرات التنظيمية.

هذا استعداد.

وليس افتراضًا بأن كل المقترحات أصبحت نافذة.


الأدلة التي يجب أن توجد

ASO فعال يحتاج إلى الوصول إلى:

  • System inventory.
  • Use-case register.
  • Data flows.
  • DPIAs.
  • Risk assessments.
  • Model/system documentation.
  • Audit reports.
  • Certification records.
  • Incidents.
  • Complaints.
  • Human intervention records.
  • Vendor documentation.

بدون Evidence يتحول oversight إلى رأي شخصي.


أخطاء شائعة

القول إن ASO ظهر في 2026

غير صحيح.

القول إن كل مؤسسة مطالبة به

يتجاهل نطاق Regulation 10 وشروط High Risk Processing.

اعتباره DPO تلقائيًا

التشابه لا يعني التطابق.

وضعه داخل فريق التطوير دون استقلال

قد ينتج Conflict of Interest.

تحميله كل مسؤولية AI

الحوكمة المؤسسية أوسع من وظيفة واحدة.


قراءة سيادة

ASO يقدم مثالًا مهمًا على تطور AI Governance.

المرحلة الأولى كانت:

AI Principles.

المرحلة التالية:

AI Governance Committees.

لكن الأنظمة عالية الأثر تحتاج إلى:

Named accountable functions with evidence, authority and competence.

هذا هو التحول الحقيقي من Governance on Paper إلى Governance in Operation.


الخلاصة

Autonomous Systems Officer ليس مجرد مسمى جديد.

هو جزء من محاولة DIFC بناء مسؤولية واضحة حول الأنظمة المستقلة، خصوصًا عند المعالجة عالية المخاطر.

والقراءة الصحيحة اليوم هي:

Regulation 10 = نافذة.

ASO = له أساس تنظيمي نافذ.

تعديلات 2026 = مسار تطوير تنظيمي يجب مراقبته حتى صدور النص النهائي.

المفاهيم الرئيسية

  • Autonomous Systems Officer
  • ASO
  • DIFC Regulation 10
  • High Risk Processing
  • الأنظمة المستقلة
  • المساءلة
  • حوكمة الذكاء الاصطناعي
  • حماية البيانات
  • الشهادات والاعتماد

الخطوات العملية

  1. 1حدد ما إذا كانت أنظمة المؤسسة تقع ضمن نطاق Regulation 10.
  2. 2حدد ما إذا كانت حالة الاستخدام تتضمن High Risk Processing Activities.
  3. 3راجع متطلبات Regulation 10.3.3 المتعلقة بالأنظمة عالية المخاطر.
  4. 4حدد المسؤول الحالي عن وظائف ASO ومدى استقلاليته وكفاءته وصلاحياته.
  5. 5تابع تعديلات 2026 المقترحة باعتبارها Regulatory Watch حتى يتم سنها نهائيًا.
  6. 6افصل في سجل الالتزامات بين النص النافذ والتغييرات المقترحة.

الأخطاء الشائعة

  • القول إن Autonomous Systems Officer استُحدث لأول مرة في تعديلات 2026.
  • القول إن كل شركة في الإمارات ملزمة بتعيين ASO.
  • تجاهل ارتباط متطلبات ASO في Regulation 10 بسياق High Risk Processing.
  • الخلط بين Autonomous Systems Officer وData Protection Officer رغم التشابه الوظيفي بينهما.
  • تقديم تعديلات 2026 المقترحة على أنها نافذة قبل صدور إشعار سن رسمي.

انضم لمجتمع سيادة AI التفاعلي على واتساب

كن جزءًا من مجتمع المهتمين بحوكمة الذكاء الاصطناعي وسيادته، وتابع النقاشات والمستجدات.

انضم الآن