من المسؤول عندما يتضرر طفل من نظام ذكاء اصطناعي؟ تفكيك المساءلة عبر سلسلة القيمة

لماذا تصبح المساءلة أصعب كلما أصبح النظام «أكثر تكاملاً»؟

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

تقرير Children’s Safety and Well-Being in the Age of AI: Best Practices and Incentives يضع إصبعه على المشكلة الأساسية: توزيع المسؤولية لا يضمن المساءلة. بل قد يحدث العكس. عندما يحدد كل طرف نطاقًا ضيقًا جدًا لدوره، يمكن أن تُدفع المشكلة إلى الطرف التالي حتى لا يبقى طرف واحد يرى الصورة كاملة أو يملك التزامًا تشغيليًا واضحًا بمعالجة الضرر. وهذا أخطر في البيئات العابرة للحدود، حيث قد يُطوَّر النموذج في دولة، وتستضاف الخدمة في أخرى، وتوزع عبر متجر عالمي، وتستخدم في مدرسة داخل ولاية تنظيمية ثالثة.

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

من يملك «السيطرة الفعلية» أهم من من يظهر اسمه على الواجهة

في الحوكمة التقليدية، من السهل الوقوع في أسر التسميات التعاقدية أو التقنية. قد تقول جهة ما: «نحن مجرد مزود نموذج»، أو «نحن مجرد منصة توزيع»، أو «المدرسة هي التي اختارت الإعدادات»، أو «المستخدم هو من كتب الطلب». لكن التقرير يدفع نحو معيار أكثر واقعية: النظر إلى القانون، والسيطرة العملية، والقدرة التقنية، والرؤية، والمساهمة في الخطر.

هذا يعني أن التحليل الجيد لا يبدأ من سؤال: من وقّع العقد؟ بل من أسئلة مثل:

• من يستطيع تغيير سلوك النموذج أو خصائص السلامة؟
• من يستطيع الوصول إلى سجلات التفاعل اللازمة للتحقيق؟
• من يقرر تفعيل الذاكرة أو التخصيص أو أدوات خارجية؟
• من يستطيع تعليق الحساب أو إيقاف الوظيفة أو سحب الإصدار؟
• من يحدد معايير العمر أو سياق الاستخدام المقصود؟
• من يعلم أو يفترض أن أطفالًا سيستخدمون النظام؟
• من يمكنه اكتشاف أن ضررًا متكررًا أو نمطًا خطيرًا يتشكل؟
• من يملك سلطة الإصلاح عندما يثبت أن الحماية غير فعالة؟

كلما كانت جهة تملك إجابات أكثر عن هذه الأسئلة، يصبح من الصعب قبول ادعاء أنها «مجرد طرف تقني» لا علاقة له بالنتيجة.

المسؤولية يجب أن تتبع نقاط السيطرة لا حدود الشركات

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

يمكن تصورها على أربع طبقات مترابطة:

1. سيطرة التصميم

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

2. سيطرة التقييم والإطلاق

تشمل من يختبر النظام، يوافق على الإطلاق، يحدد ما إذا كانت الحماية كافية، يقرر قبول مخاطر متبقية، ويحدد ما الذي يعتبر تغييرًا جوهريًا يستدعي إعادة التقييم.

3. سيطرة التشغيل والمراقبة

تشمل من يرى الحوادث والأنماط، من يستقبل البلاغات، من يستطيع ربط عدة إشارات ببعضها، ومن يستطيع اتخاذ إجراء خلال دقائق أو ساعات بدل انتظار سلسلة بريدية بين مزودين.

4. سيطرة المعالجة والإنصاف

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

إذا كانت هذه الطبقات موزعة، فالعقد والـOperating Model يجب أن يوزعا الواجبات بنفس الدقة. أما استخدام عبارة عامة مثل «المورد مسؤول عن أمن الخدمة» فلا يكفي أمام حادث معقد يتعلق بسلوك نموذج، أو ذاكرة محادثة، أو قرار آلي، أو ضرر نشأ من تفاعل بين عدة مكونات.

لماذا «الجميع مسؤول» قد تعني عمليًا «لا أحد مسؤول»؟

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

المقياس الحقيقي هو: هل يستطيع النظام المؤسسي الانتقال من حادث إلى صاحب قرار خلال مسار قصير ومحدد؟

المطلوب ليس أن يتحمل طرف واحد كل شيء، بل ألا توجد «مساحة خالية» بين الأطراف. أي نقطة في سلسلة الخطر يجب أن يقابلها مالك واجب محدد. إذا كان التطبيق يستطيع إيقاف ميزة خطرة، فهناك جهة يجب أن تكون مسؤولة عن قرار الإيقاف. إذا كان مزود النموذج وحده يستطيع تغيير سلوك جوهري، يجب أن تكون هناك آلية تعاقدية وتصعيدية تلزمه بالتحقيق والمعالجة. إذا كانت المدرسة هي من اختار سياق الاستخدام، فيجب ألا تتهرب من مسؤولية الإشراف البشري والملاءمة التعليمية بحجة أن التقنية خارجية.

المساءلة تبدأ قبل الحادث: التعيين، العقود، ونقاط التصعيد

التقرير لا يتعامل مع المساءلة باعتبارها «ما يحدث بعد الضرر» فقط. الممارسة الجيدة تبدأ قبل النشر من خلال تعيين مالك مسؤول رفيع المستوى وتخصيص المسؤوليات المتعلقة بضمانات الأطفال والحوادث عبر سلسلة القيمة. هذه المسؤوليات يجب ألا تبقى في وثيقة حوكمة داخلية منفصلة، بل يجب أن تظهر أيضًا في العقود، وشروط الـAPI، واتفاقيات المشتريات، وتراخيص النماذج المفتوحة، وقواعد المتاجر، وسياسات الاستخدام السحابي حيث يكون لذلك أثر.

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

الإشراف البشري ليس زينة امتثال

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

هذا يفرض ثلاثة شروط عملية:

أولًا، يجب تعريف محفزات المراجعة البشرية مسبقًا: متى يتوقف التدفق الآلي ويصعد إلى إنسان؟ لا يجوز اختراع هذه المعايير وقت الأزمة.

ثانيًا، يجب أن يملك الإنسان معلومات كافية لاتخاذ قرار مستقل، لا أن يرى فقط التوصية نفسها التي أنتجها النظام.

ثالثًا، يجب أن توجد طريقة مفهومة للطفل أو مقدم الرعاية لطلب التصحيح أو المراجعة أو الاستئناف.

لو كان «المشرف البشري» لا يستطيع تغيير القرار، أو لا يرى الأدلة، أو لا يملك وقتًا أو تدريبًا، فالإشراف هنا صوري لا تشغيلي.

في الأنظمة الوكيلية: المساءلة تحتاج حدود سلطة قابلة للإيقاف

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

بالنسبة للمؤسسة، هذا يعني أن سؤال «من المسؤول؟» لا يمكن حله إذا لم نعرف أصلًا ما الذي كان النظام مخولًا بفعله. لا مساءلة بلا حدود سلطة موثقة. فإذا استطاع وكيل الوصول إلى حساب، أو إرسال رسالة، أو شراء خدمة، أو تعديل إعداد، أو الإفصاح عن بيانات، يجب أن نستطيع مقارنة الفعل المنفذ بنطاق السلطة الممنوح له. عندها فقط يمكن تمييز خطأ التصميم من خطأ الإعداد من تجاوز الصلاحية من فشل المراقبة.

الأدلة: ما لا يمكن إثباته يصعب مساءلته

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

التوازن الصحيح هو تحديد الحد الأدنى من الأدلة التي تسمح بالإجابة عن الأسئلة الحرجة:

• ما الإصدار الذي كان يعمل؟
• ما الإعدادات والضوابط النشطة؟
• ما البيانات أو الذاكرة التي استخدمت؟
• ما الفعل أو القرار الذي اتخذه النظام؟
• هل كان داخل نطاق السلطة؟
• ما إشارات الخطر التي ظهرت؟
• هل عملت آلية التصعيد؟
• من استلم البلاغ ومتى؟
• ما الإجراء الذي اتخذ؟
• هل تكرر النمط بعد المعالجة؟

بدون هذه السلسلة، تتحول المساءلة إلى نقاش روايات بدل فحص أدلة.

المعالجة والإنصاف: زر البلاغ لا يكفي

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

من زاوية الحوكمة، الـRemedy يختبر حقيقة المساءلة. كثير من المؤسسات تستطيع كتابة Policy ممتازة، لكن عندما يقع الضرر يبدأ المستخدم رحلة بين الدعم الفني والمورد ومزود المنصة. هذا بالضبط ما يجب منعه. الجهة التي تسيطر على القرار ذي الصلة يجب أن تبقى مسؤولة عن توفير المسار العملي للمعالجة، حتى لو احتاجت داخليًا إلى الرجوع لمورد آخر.

العقود يجب أن تحمل معلومات السلامة لا أن تكون مجرد نقل للمخاطر

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

من البنود التشغيلية التي يجب أن تكون واضحة بحسب طبيعة الخدمة:

• من يبلغ من عند حدوث حادث أو تغيير جوهري؟
• ما البيانات أو الأدلة التي يجب توفيرها للتحقيق؟
• ما حقوق التدقيق أو التقييم المستقل؟
• كيف تستخدم إشارات العمر وكيف تحمى؟
• متى يمكن تعليق الخدمة أو ميزة معينة؟
• من يملك قرار الإصلاح؟
• من يوفر المعالجة للطفل؟
• ما الزمن الأقصى للاستجابة للحوادث عالية الخطورة؟
• ماذا يحدث إذا تغير النموذج الأساسي دون تغيير اسم المنتج؟

هذه البنود تجعل العقد جزءًا من نظام الحوكمة، لا مجرد وثيقة قانونية توزع المسؤولية بعد الفشل.

المشتريات نقطة مساءلة قبل أن تصبح نقطة شراء

تستطيع الحكومات والمدارس والجامعات والمؤسسات الكبرى استخدام قدرتها الشرائية لفرض Evidence Requirements قبل السماح بالدخول إلى بيئة الأطفال. التقرير يقترح الاستفادة من المشتريات والتجديد والترخيص كرافعة لطلب تقييم أثر حقوق الطفل، وتصميم ملائم للعمر، وسلامة بالتصميم، واختبار مستقل، وإجراءات استجابة للحوادث.

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

كيف نبني Accountability Map قابلة للاستخدام؟

الوثيقة العملية التي تحتاجها المؤسسة ليست قائمة عامة بأسماء الجهات، بل مصفوفة تربط الخطر بالسيطرة وبصاحب القرار وبالدليل. على سبيل المثال:

هذه الخريطة يجب أن تتغير عندما يتغير النموذج أو المورد أو الـAPI أو قناة التوزيع. المساءلة التي لا تتحدث مع معماريات النظام تتقادم بسرعة.

كيف نعرف أن نموذج المساءلة ضعيف؟

هناك إشارات حمراء واضحة:

• لا يوجد Senior Accountable Owner معروف.
• الحوكمة تقول «Shared Responsibility» دون Decision Rights.
• فريق السلامة لا يملك Release Gate أو سلطة إيقاف.
• العقود لا تمنح حق الوصول إلى معلومات الحوادث.
• لا يوجد سجل واضح لما يستطيع الوكيل فعله.
• المستخدم لا يعرف أين يطلب مراجعة بشرية.
• كل مورد يستطيع إحالة المشكلة إلى طرف آخر.
• القياس يركز على عدد البلاغات لا على فعالية المعالجة وتكرار الفشل.
• لا توجد آلية لاختبار أن الإجراءات التصحيحية خفّضت الخطر فعلاً.

إذا وجدت هذه العلامات، فالمشكلة ليست «نقص سياسة» بل نقص بنية تشغيلية للمساءلة.

الخلاصة التنفيذية لسيادة AI

أقوى رسالة في التقرير ليست أن هناك أطرافًا كثيرة مسؤولة، بل أن المساءلة يجب أن تصمم عبر سلسلة القيمة قبل أن يقع الضرر. المؤسسة الناضجة لا تنتظر الحادث لتقرر من يملك القرار. هي تربط مسبقًا كل Capability وControl وDecision وEvidence وEscalation وRemedy بصاحب سلطة واضح.

في سياق الأطفال، هذا أكثر حساسية لأن الضرر قد ينشأ من تفاعل طويل وليس من مخرج واحد، ولأن الطفل قد لا يستطيع وصف ما حدث أو تحديد الطرف الصحيح، ولأن البيانات والعلاقات والثقة والسلطة تتداخل داخل التجربة نفسها. لذلك فإن Accountability الحقيقية لا تعني العثور على «المذنب» بعد الحادث، بل منع اختفاء المسؤولية بين الحدود التقنية والتجارية والتنظيمية.

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