حوكمة الذكاء الاصطناعي في الرعاية الصحية: الدقة وحدها لا تكفي

المشكلة ليست الدقة فقط

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

التتبع عبر دورة الحياة

كل نتيجة عالية الأثر يجب أن تكون قابلة للربط مع:

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

المراقبة بعد النشر

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

الخصوصية والتدفقات عبر الحدود

البيانات الصحية حساسة بطبيعتها. يجب ربط استخدامها بسياسات الوصول والاحتفاظ والنقل والموقع، وعدم افتراض أن وجود النظام في بيئة سحابية متوافقة يلغي مسؤولية المؤسسة عن الاستخدام الفعلي للبيانات.

ملاحظة منهجية

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

كيف نعرف أن النموذج يعمل بعد أشهر من الإطلاق؟

المراقبة بعد النشر يجب أن تجمع بين أداء النموذج وأداء الخدمة. قد يبقى المقياس التقني مستقرًا بينما يتغير سلوك المستخدم أو مسار العمل أو نوعية الحالات التي تصل للنظام.

لذلك نحتاج إلى:

• مؤشرات جودة وأداء موزعة حسب الموقع أو الفئة المناسبة.
• مراجعة الحالات الشاذة أو الاعتراضات البشرية.
• مراقبة تغير البيانات والمدخلات.
• سجل للحوادث أو Near Misses.
• آلية واضحة لإعادة التقييم خارج الدورة.

حدود الإشراف البشري

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

ما الذي يجب أن يحدث قبل الاستخدام السريري؟

الانتقال من Pilot إلى استخدام يؤثر في قرار سريري يحتاج Gate واضحًا. يجب أن نعرف Intended Use، الفئة السكانية، الحدود المعروفة، سيناريوهات عدم الاستخدام، وكيفية عرض المخرج للطبيب أو الفريق السريري.

هذا مهم لأن نفس النموذج قد يكون مناسبًا كمساعد ترتيب أولوية وغير مناسب كبديل لقرار متخصص.

Traceability ليست Logging فقط

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

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

Human Oversight يجب أن يكون قابلًا للقياس

عبارة «يوجد إشراف بشري» غير كافية. يجب تحديد:

• من يراجع؟
• متى تكون المراجعة إلزامية؟
• هل يملك المراجع وقتًا ومعلومات كافية؟
• هل يستطيع رفض المخرج بسهولة؟
• هل يتم تسجيل override؟
• هل ارتفاع معدل override يؤدي إلى Review للنظام؟

الإشراف الذي لا يستطيع تغيير النتيجة فعليًا هو إجراء شكلي.

مراقبة الاختلاف بين المواقع

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

يمكن متابعة الأداء حسب الموقع، نوع الجهاز، الفئة السكانية، نوع الحالة، أو أي تقسيم ذي صلة بالاستخدام.

Triggers لإعادة التقييم

• تغير Dataset أو طريقة جمع البيانات.
• تحديث Model Version.
• تغير Workflow السريري.
• ارتفاع الشكاوى أو Overrides.
• Drift مستمر.
• اختلاف أداء جوهري بين المواقع.
• توسع الاستخدام إلى حالة جديدة.

كل Trigger يجب أن يؤدي إلى Review محدد، وليس مجرد تنبيه.

Evidence Pack تشغيلي

إضافة إلى Model Card، تحتاج المؤسسة إلى سجل تحقق، بروتوكول إشراف، تعريفات Monitoring، Incident/Exception Log، سجل إصدارات، Data Flow، وإثبات أن المستخدمين يعرفون حدود النظام.

سؤال الحوكمة الأهم

هل تستطيع المؤسسة أن تشرح ليس فقط كيف يعمل النظام، بل كيف تستخدمه فعليًا، ومن يستطيع إيقافه، وما الدليل أن استخدامه الحالي ما زال ضمن النطاق المقبول؟ إذا لم تستطع، فالمشكلة ليست طبية فقط؛ إنها مشكلة Governance وAssurance.