بطاقة النظام: توثيق يُسأل عنه قبل الإطلاق

اقترحت ورقة Model Cards for Model Reporting [1] فكرة بسيطة: أن يُرافق كل نموذج منشور وثيقةٌ موجزة تشرح غرضه وأداءه وحدوده والسياقات التي لا يصلح لها. الفكرة انتقلت من النماذج إلى الأنظمة المبنيّة عليها، وصارت من أوّل ما يُطلب في أي مراجعة جادّة.

لماذا صفحة واحدة

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

القالب

اسم النظام · المالك · تاريخ آخر تحديث

١) الغرض       ماذا يفعل، ولمن، وأي قرار يخدمه
٢) المستخدمون  من يستعمله ومن يتأثّر بمخرجاته
٣) البيانات    ما يقرؤه: مصادره، وتحديثه، ونطاقه
٤) النماذج     المزوّد والإصدار وإصدار التوجيه
٥) الأداء      أرقام المجموعة الذهبية بتاريخها
٦) الحدود      أين يخطئ، وما لا يستطيع
٧) غير المقصود ما لا يجوز استعماله فيه
٨) الضوابط     الامتناع، والموافقة البشرية، وحدود الصلاحيات
٩) الاستجابة   من يوقفه، وكيف يُبلَّغ المتأثّرون

القسمان اللذان يُحذفان أولًا

الحدود المعروفة (٦): حيث تكتب صراحةً: «يضعف في الأسئلة الحسابية»، «لا يغطّي مستندات ما قبل ٢٠٢٤»، «قِيس على العربية الفصحى ولم يُختبر على اللهجات». الفريق يقاوم هذا القسم لأنه يبدو اعترافًا بالضعف — وهو في الحقيقة ما يمنع سوء استعمال يتحوّل إلى حادثة.

الاستخدامات غير المقصودة (٧): «ليس أداة استشارة قانونية»، «لا يُستعمل لقرار توظيف»، «لا يُبنى عليه قرار مالي بلا مراجعة». وجود هذا القسم مكتوبًا هو الفرق بين نظام له حدود معلنة ونظام يُستعمل في ما لم يُصمَّم له ثم يُلام.

كيف تبقى حيّة

اجعلها ملفًّا في المستودع بجانب الكود، لا مستندًا في محرّك بحث داخلي. ثم اربط تحديثها بالأحداث:

• تغيير النموذج أو إصداره ← حدّث القسم ٤.
• تشغيل التقييم ← ألصق الأرقام وتاريخها في القسم ٥.
• كل حادثة أو بلاغ خطأ ← أضف سطرًا في الحدود.
• كل ربع ← مراجعة كاملة وتاريخ جديد.

هذا يجعلها أثرًا جانبيًّا للعمل لا مهمّة إضافية، ويتّسق مع ما يطلبه إطار NIST [2] من توثيق قابل للتتبّع.

متى تكفي نسخة مصغّرة

لأداة داخلية يستعملها فريقك وحده، تكفي نصف صفحة: الغرض، والبيانات، والحدود، والمالك. الأقسام الكاملة تُبرَّر حين يظهر مستخدم خارجي، أو بيانات شخصية، أو قرار يمسّ أفرادًا، أو سوق منظَّم [3].

من يكتبها، ومتى بالضبط

البطاقة التي تُكتب «حين يتّسع الوقت» لا تُكتب. اربطها بأحداث لا بنوايا:

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

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

كم تستغرق: ساعة للنسخة الأولى إن كان الكاتب هو الباني. أطول من ذلك يعني أنك تكتب تقريرًا لا بطاقة، وأنها لن تُحدَّث بعدها أبدًا.

الأخطاء الشائعة

1. كتابتها مرة عند الإطلاق ثم تركها تتقادم.
2. حذف قسم الحدود لأنه «يضعف صورة المنتج».
3. أرقام أداء بلا تاريخ ولا وصف للمجموعة التي قيست عليها.
4. مالك غير محدّد — أي: لا أحد.
5. حفظها بعيدًا عن المستودع، فتُنسى عند كل تغيير.

الأسئلة الشائعة

ما الفرق بين بطاقة النموذج وبطاقة النظام؟

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

هل هي مطلب قانوني؟

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

من يكتبها؟

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

المراجع

1. Mitchell, M. et al. Model Cards for Model Reporting. FAT* 2019. arXiv:1810.03993
2. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). nist.gov
3. الاتحاد الأوروبي. Regulation (EU) 2024/1689 on artificial intelligence. eur-lex.europa.eu
4. OWASP. Top 10 for LLM Applications. owasp.org