تقييم جاهزية الذكاء الاصطناعي: ما الذي يجب فحصه قبل شراء أي حل؟

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

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

لماذا يصعب الحكم على الجاهزية من الخارج

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

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

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

الأخطاء الشائعة لدى الفرق

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

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

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

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

هيكل عملي للتقييم

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

1. ملاءمة سير العمل

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

2. البيانات والسياق

• أين يوجد كل مُدخل، ومن يستطيع الوصول إليه، وكيف: عبر واجهة، أم قاعدة بيانات، أم ملف مُصدَّر، أم شخص بعينه؟
• ما مدى الحداثة المطلوبة للبيانات، وما مدى حداثتها فعليًا؟
• هل تحتوي المدخلات أو المخرجات على معلومات حساسة أو شخصية أو خاضعة للتنظيم؟
• هل توجد أمثلة حقيقية مصنفة بما يكفي للاختبار؟

3. الأنظمة والتكامل

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

4. المخاطر والمراجعة

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

5. المسؤولية

• من يملك سير العمل بعد الإطلاق، بما في ذلك تعديل التعليمات والبيانات والتكاملات؟
• من يراجع حالات الفشل، وكيف تتحول إلى إصلاحات؟

6. التقييم

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

اعتبارات التنفيذ

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

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

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

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

الموازنات والمفاضلات

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

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

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

دروس من عمل ImadDhin

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

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

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

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

أخطاء شائعة يجب اختبارها

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

متى يكون الحل الأبسط أفضل

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

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

ابدأ بسير عمل واحد، لا بعرض استراتيجي

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

يمكنك البدء بفحص AI Readiness Scan المجاني، أو الاطلاع على استشارات أتمتة الذكاء الاصطناعي لتقييم أعمق، أو مناقشة سير عمل مرشح في مكالمة مدتها 30 دقيقة.