الجزء الأصعب في الاستقلالية ليس السيارة، بل الخدمة

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

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

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

مكدّس الاستقلالية هو الجزء الأسهل، لأنه قابل للفهم والقياس

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

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

• كيف تتعامل مع راكب يرفض مغادرة مركبة انتهت رحلته؟
• ماذا يحدث عندما يعطي شرطي إشارة يد تخالف علامات الطريق؟
• من يقرر إيقاف العمليات أثناء عاصفة، وما الأدلة التي تسند ذلك القرار؟
• كيف تُثبت لاحقاً ما الذي «رآه» النظام ولماذا تصرّف كما تصرّف؟

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

remote-ops ليست شخصاً يراقب شاشات، بل نظام قيادة للحوادث

غالباً ما تُصوَّر العمليات عن بُعد على أنها tele-driving: إنسان يتولى القيادة عندما تتعثر السيارة. هذه الصورة مبسطة أكثر من اللازم وخطرة أيضاً. في خدمة مدينة منظَّمة، يجب أن تبدو remote-ops أقرب إلى incident command منها إلى أسلوب الألعاب.

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

طريقة عملية لتصميم ذلك هي فصل ثلاث قدرات:

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

إذا لم تفصل بين هذه الأدوار، ستنتهي إلى مخاطرة «عصا التحكّم العشوائية». ليس لأن الشخص غير كفؤ، بل لأن النظام يطلب بطولات فردية بدلاً من أن يوفّر بنية واضحة.

ما الذي يجب تحديده قبل إضافة مزيد من السيارات

قبل أن يجادل أحد حول حجم الأسطول، وثّق نموذج remote-ops كتابةً. ليس كمسرحية سياسات، بل كأداة للمواءمة والتدقيق. إن أردت قائمة بداية:

• Span of control: كم تدخلاً متزامناً يمكن لأخصائي عن بُعد دعمه بأمان، وما الدليل؟
• Intervention taxonomy: تحديد الأحداث التي تستدعي تدخلاً عن بُعد، وتلك التي يجب أن تبقى مستقلة بالكامل.
• مسارات التصعيد: ما الذي يفعّل incident commander، أو إشعاراً قانونياً، أو جهة اتصال مع المدينة؟
• التدريب والاعتماد: ما الكفاءات المطلوبة، وكيف تُختبر وتُحدَّث؟
• السجلات وإعادة التشغيل: ما البيانات التي تُحفظ، ولمدة كم، ومن يملك صلاحية الوصول؟

لاحظ ما الذي لا يظهر هنا: معمارية النموذج. ليس لأنها غير مهمة، بل لأنها ليست أول ما ينهار في خدمة عامة.

ملف السلامة ليس PDF، بل عقد حيّ مع الواقع

في البيئات الخاضعة للتنظيم، يُعامل «ملف السلامة» كعمل ورقي. عملياً، هو الحُجّة التي تربط الافتراضات بالتشغيل. يقول: هذا هو المجال الذي نزعم أننا نتعامل معه، وهذه هي المخاطر، وهذه هي الضوابط، وهذه هي طريقة مراقبتنا لاستمرار فعالية الضوابط.

تفرض كوبنهاغن سؤالاً غير مريح حول ما الذي يدّعيه النظام فعلاً. خدمة robot-taxi ليست «قيادة ذاتية». إنها:

• نظام توزيع
• نظام مدفوعات وهوية
• نظام صحة الأسطول والصيانة
• نظام مساندة عن بُعد وإدارة حوادث
• نظام دعم عملاء
• نظام امتثال وتدقيق

المركبة مكوّن واحد. يجب أن يغطي ملف السلامة الخدمة كاملة، بما في ذلك كيفية تفاعل البشر معها تحت الضغط.

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

إذا أردت للاستقلالية أن تصبح أمراً مملاً، فعليك جعل ملف السلامة قابلاً للتشغيل: يجب أن يوجّه التدريب، والتنبيه، وبوابات الإطلاق. وهذا أيضاً سبب تفضيلي للتعامل مع المواصفات الرسمية كأدوات للحوادث لا كبراهين أكاديمية، كما كتبت في Formal Specs Are Incident Tools, Not Academic Proofs.

المسؤولية القانونية قيد التصميم الذي لا يريد أحد امتلاكه

كل مشروع استقلالية يصطدم في النهاية بالمسؤولية. ليس كحاشية قانونية، بل كقيد محوري يشكّل النظام بأكمله.

سؤال «من المسؤول؟» يظهر على طبقات متعددة:

• قرارات لحظية: إذا وافقت remote-ops على مناورة، فهل هذا «قيادة» أم «إشراف»؟
• تصميم النظام: إذا غابت آلية أمان، فمن صادق على تلك الفجوة؟
• التشغيل: إذا استمرت الخدمة في ظروف خارج النطاق المعلن، فمن اتخذ القرار؟
• النموذج التجاري: من هو مزوّد الخدمة على الورق، وماذا يعتقد العميل أنه يشتري؟

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

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

نموذج استقلالية جاهز لكوبنهاغن: الحد الأدنى الذي ينبغي طلبه

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

1. سلطة حوادث داخل البلاد: ليس مجرد غرفة شاشات، بل وظيفة مسماة تستطيع إيقاف العمليات، والتواصل مع الجهات المعنية، وتفعيل التصعيد.
2. تدخلات عن بُعد محدودة النطاق: taxonomy مكتوبة، مع ضوابط تقنية تمنع tele-driving الارتجالي خارج الحالات المسموح بها.
3. قابلية رصد شاملة من الطرف إلى الطرف: قياسات المركبة، ولقطات الإدراك عند الحاجة، وأفعال remote-ops، وتفاعلات العملاء ضمن خط زمني واحد.
4. انضباط إطلاق مرتبط بادعاءات السلامة: التغييرات التي تمس ملف السلامة تمر بمراجعة صريحة وإطلاق تدريجي. عاملوها كـ release pipeline لا كـ feature toggle. الفكرة نفسها تظهر في البرمجيات أيضاً، وقد تناولتها في Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle.
5. مساءلة تجارية واضحة: الجهة التي تجمع المال يجب أن تكون الجهة التي يمكن محاسبتها، وإلا فأنت تبني متاهة للتنصّل من اللوم.

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

رأيي: نظّموا الخدمة، لا «السحر»

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

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

إن كنت مؤسساً أو مالكاً أو قائداً تنفيذياً تبني شيئاً منظَّماً وقريباً من السلامة، فاعتمد هذه العدسة: النواة التقنية نادراً ما تكون عنق الزجاجة. عنق الزجاجة هو operating model الذي يجعل ادعاءاتك قابلة للدفاع، وحوادثك قابلة للإدارة، ومسؤوليتك واضحة.