الموقف: الثقة في النظام تُختبر فقط تحت الضغط
تدير كثير من المؤسسات السعودية اليوم عمليات تشغيلية مرتبطة مباشرة بأنظمة ذكاء اصطناعي: تصنيف طلبات العملاء، تسعير ديناميكي، كشف احتيال، جدولة موارد، أو محركات توصية. في الأيام العادية، هذه الأنظمة تبدو مستقرة لأن الحمل متوقع والبيانات متجانسة والتغييرات التقنية تتم بوتيرة هادئة. المشكلة أن هذا الاستقرار الظاهري نادرًا ما يُختبر فعليًا، لأن الاختبار الحقيقي يحدث فقط حين يتغير السياق بشكل حاد ومفاجئ.
المواسم الحرجة في السياق السعودي لها طبيعة مزدوجة. من جهة، هناك ارتفاع حاد في الطلب خلال رمضان، مواسم التجزئة، نهاية السنة المالية، أو فترات الذروة الحكومية والخدمية. من جهة أخرى، كثير من المؤسسات تفرض في هذه الفترات تحديدًا سياسة تجميد التغيير (Change Freeze) لتقليل المخاطر التشغيلية، أي منع أي تعديل على الأنظمة، بما في ذلك التحديثات الروتينية وإصلاحات الأخطاء غير الحرجة. هذا يعني أن النظام يجب أن يتحمل أعلى ضغط تشغيلي في السنة، دون أي قدرة على التدخل السريع لإصلاحه.
النتيجة أن كثيرًا من القيادات تكتشف هشاشة أنظمتها الذكية في أسوأ توقيت ممكن: حين يرتفع حجم الطلبات، يتغير سلوك العملاء الموسمي، وتتوقف فرق التقنية عن إجراء أي تعديل. هذا ليس عيبًا في فكرة الذكاء الاصطناعي نفسها، بل في غياب إطار واضح للجاهزية يسبق الموسم، ويُختبر قبل أن يصبح الإصلاح مكلفًا أو مستحيلًا.
الفجوة المكلفة: حين يلتقي الحمل الأقصى بغياب القدرة على التدخل
الفجوة الحقيقية ليست في أداء النظام وقت الهدوء، بل في سلوكه حين تتغير ثلاثة عوامل معًا: حجم البيانات، نمط استخدام العملاء، وغياب نافذة الصيانة. نظام تصنيف احتيال مُدرّب على سلوك شرائي عادي قد يبدأ بإصدار إنذارات خاطئة بكثرة خلال موسم تسوق مكثف، لأن النمط السلوكي الموسمي يختلف فعليًا عن بيانات التدريب. ونظام جدولة موارد قد ينهار منطقيًا حين يتضاعف حجم الطلبات دون أن تكون البنية التحتية أو منطق النموذج مُصممين لهذا التوسع المؤقت.
الكلفة هنا ليست تقنية بحتة، بل تشغيلية ومالية وسمعية في آن واحد. تعطل جزئي لنظام حرج خلال موسم الذروة يعني قرارات خاطئة متكررة في وقت قصير، تراكم شكاوى عملاء في أكثر الفترات حساسية تجاريًا، وضغطًا على الفرق البشرية لتعويض يدويًا ما كان من المفترض أن يُدار آليًا. والأخطر أن تجميد التغيير يمنع الفريق التقني من نشر أي إصلاح سريع، فيضطرون إما لتحمل الخلل طوال الموسم أو لكسر سياسة التجميد نفسها، وكلا الخيارين يحمل مخاطر حوكمية واضحة.
كثير من المؤسسات تتعامل مع هذا الموقف بردة فعل بدلًا من استعداد مسبق: مراقبة يدوية مكثفة، تعليمات طوارئ غير موثقة، أو قرار متأخر بتعطيل ميزة الذكاء الاصطناعي بالكامل والعودة لعمليات يدوية في أكثر الأوقات ضغطًا. هذا الحل البديل مكلف من ناحية الكفاءة، ويُفقد المؤسسة بالضبط الميزة التي استثمرت فيها، في اللحظة التي كانت تحتاجها أكثر من أي وقت آخر.
معايير القرار: كيف تقيّم جاهزية نظامك قبل الموسم لا أثناءه
السؤال الأول الذي يجب أن تطرحه القيادة ليس "هل النظام يعمل؟" بل "هل تم اختبار النظام تحت حمل يعادل أو يفوق ذروة الموسم المتوقع؟". كثير من المؤسسات تختبر الأنظمة الذكية في بيئة تطوير أو بحمل متوسط، ولا تجري اختبار تحمل (Stress Test) يحاكي فعليًا سيناريو الذروة الفعلي: عدد الطلبات، سرعة الاستجابة المطلوبة، وتزامن الاستخدام عبر قنوات متعددة في وقت واحد.
السؤال الثاني يتعلق بسلوك النموذج نفسه عند تغير النمط الموسمي. هل تم تقييم أداء نموذج الذكاء الاصطناعي على بيانات تاريخية من مواسم مماثلة سابقة، أم أن تدريبه يعتمد فقط على بيانات الأيام العادية؟ الفارق هنا جوهري: نظام مُختبر على بيانات رمضان أو موسم تسوق سابق لديه فرصة أعلى للتنبؤ الدقيق بالسلوك الاستثنائي، بينما نظام مُدرّب فقط على المتوسط السنوي سيُفاجأ بانحراف حقيقي في الأداء.
السؤال الثالث، وهو الأكثر إهمالًا، يخص بروتوكول تجميد التغيير نفسه: هل توجد خطة طوارئ موثقة ومعتمدة مسبقًا تحدد بدقة ما الذي يُسمح بإصلاحه أثناء التجميد، ومن يملك صلاحية الموافقة السريعة، وما هو السيناريو البديل إذا تعطل جزء من النظام؟ غياب هذه الخطة يعني أن أي عطل، مهما كان بسيطًا، سيتحول فورًا إلى أزمة قرار داخلي في وقت لا تحتمل فيه المؤسسة التأخير.
ما يتطلبه الحل الجاد: ثلاثة أركان لا يمكن الاستغناء عنها
الركن الأول هو اختبار الحمل الموسمي كجزء من دورة الحوكمة السنوية، وليس كنشاط استثنائي. هذا يعني محاكاة حجم الطلبات المتوقع فعليًا بناءً على بيانات المواسم السابقة إن وجدت، أو بناءً على تقديرات تشغيلية محافظة إن لم تتوفر بيانات تاريخية كافية، ثم قياس زمن الاستجابة، معدل الخطأ، واستقرار النظام تحت هذا الحمل قبل دخول الموسم بوقت كافٍ لإجراء أي تعديل ضروري.
الركن الثاني هو فصل واضح بين "تغييرات تحسينية" يمكن تأجيلها بأمان، و"تغييرات إصلاحية حرجة" يجب أن تُستثنى من سياسة التجميد ضمن مسار موافقة سريع ومحدد مسبقًا. هذا الفصل يتطلب تصنيفًا واضحًا للمخاطر منذ البداية، وليس نقاشًا مرتجلًا وقت حدوث العطل، لأن اتخاذ قرار الاستثناء تحت ضغط الأزمة غالبًا ما يكون أبطأ وأكثر عرضة للخطأ من قرار مُعد مسبقًا ضمن إطار حوكمي واضح.
الركن الثالث هو خطة تدهور متدرج (Graceful Degradation) بدلًا من توقف كامل أو استمرار بأداء معطوب. أي أن يملك النظام مسارًا بديلًا واضحًا حين يتجاوز الحمل حدًا معينًا: تبسيط منطق القرار مؤقتًا، تحويل جزء من الطلبات لمراجعة بشرية محددة سلفًا، أو تقليل نطاق الميزة الذكية دون إيقافها بالكامل. هذا يتطلب تصميمًا هندسيًا واعيًا منذ البداية، وليس حلًا يُرتجل بعد وقوع الأزمة.
كيف تعرف أن هذا الملف أولوية لمؤسستك الآن
هذا الملف يستحق أولوية فورية إذا كانت مؤسستك تطبق سياسة تجميد تغيير رسمية خلال موسم تشغيلي حرج، ولم تُجرِ اختبار حمل موسميًا موثقًا لأنظمة الذكاء الاصطناعي المرتبطة مباشرة بقرارات العملاء أو العمليات المالية أو خدمة الجمهور. علامة أخرى واضحة هي إذا كان الموسم السابق قد شهد تدخلات يدوية طارئة أو شكاوى غير معتادة من دقة النظام، دون أن يُترجم ذلك إلى مراجعة هيكلية قبل الموسم التالي.
إذا كانت مؤسستك، على النقيض، لديها بالفعل اختبارات حمل منتظمة، وتصنيف واضح للتغييرات الحرجة مقابل التحسينية، وخطة تدهور متدرج موثقة ومُختبرة، فإن أولويتك الحالية على الأرجح ليست هذا الملف تحديدًا، بل قد تكون تحسين دقة النماذج نفسها أو توسيع نطاق الأتمتة، وهذا قرار مختلف يستحق مسارًا استشاريًا منفصلًا.
عدم معالجة هذه الفجوة لا يعني بالضرورة كارثة فورية، لكنه يعني أن المؤسسة تدخل أكثر الفترات أهمية تجاريًا وهي تعتمد على افتراض غير مُختبر، وتترك قرار الاستقرار للصدفة بدلًا من الحوكمة. الخطوة المنطقية التالية ليست إعادة بناء الأنظمة من الصفر، بل جلسة تقييم جاهزية محددة النطاق مع فريق ASLS.AI، تبدأ بمراجعة معمارية النظام الحالي وسياسة التغيير المعمول بها، وتنتهي بتوصيات عملية وقابلة للتنفيذ قبل دخول الموسم القادم، دون وعود بنتائج لم تُختبر بعد.
