مشكلة الإثبات.

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

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

تشريح برنامج غير قابل للإثبات

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

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

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

لا شيء من هذه مشكلات تتعلق بالنموذج. إنها مشكلات حوكمة — وهي بالضبط العمل الذي يُقتطَع حين يتسابق برنامجٌ نحو موعد إطلاق. النموذج يُقدَّم عرضه ببراعة؛ أمّا الحوكمة فتظل غير مرئية حتى يطلبها أحد.

تتآكل خطوط الأساس في اللحظة التي تتخطّاها فيها

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

التقييم عادة، لا حدث.

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

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

نرى النمط نفسه عبر القطاعات الخاضعة للتنظيم: تجربة رائدة ناجحة، ثم طرحٌ حماسي، ثم تآكلٌ بطيء للثقة لأن البرنامج لا يستطيع تقديم إجابةٍ عن نفسه. لم تفشل التقنية. بل فشل الإثبات.

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

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

اجعل الإثبات خاصيةً من خصائص النظام

حين يُهنْدَس الإثبات داخل النظام، لا يكون التدقيق حدثاً تستعد له — بل استعلاماً تُجريه. وذلك هو الفرق بين برنامجٍ يصمد أمام التدقيق وآخر يكتفي بالأمل في تجنّبه.

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

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

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

وكل ما عدا ذلك عرضٌ توضيحي ينتظر سؤالاً لا يستطيع الإجابة عنه.