التحقق من النماذج اللغوية المخصصة وإطلاقها في المجالات الخاضعة للتنظيم

ملاحظات من دورة الإطلاق — الجزء الرابع

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

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

هذا ليس جواباً امتثالياً. إنه لا-جواب مصحوب بهزة أكتاف إجرائية.

تتناول هذه المقالة الشكل الذي يبدو عليه جواب الامتثال الحقيقي للنماذج اللغوية المخصصة — عبر أربعة أطر تنظيمية (قانون الذكاء الاصطناعي للاتحاد الأوروبي، المادة 17 من GDPR، HIPAA، NIST AI RMF)، مُسقطةً على خط الإطلاق ذي المراحل الأربع (التسجيل ← البوابة ← الطرح ← المراقبة) الذي نُصدِره لإطلاقات العملاء. التوتر الجوهري الذي يسري في كل مطلب تنظيمي هو الأوزان المفتوحة مقابل واجهات الـ API المغلقة: الأشياء التي يمكنك إثباتها بشأن ضبط دقيق لـ Gemma 4 ليست الأشياء التي يمكنك إثباتها بشأن إطلاق يُقدَّم خلف API بائع معتم. صيغة الإيصال التي نستخدمها تقول ذلك صراحةً، سطراً بسطر. هذه الصراحة هي ما يجعل الإيصال مفيداً للمدقق.

المنظمون الأربعة وما يريده كل منهم فعلياً

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

أرقام العقوبات ليست هي ما يجعل هذه الأطر مثيرة للاهتمام. أرقام العقوبات هي ما يجعلها حمَّالة الثقل. الجزء المثير للاهتمام هو البنية الأولية للتحقق — كيف يريد كل إطار أن يبدو الأثر فعلياً. ثلاثة من الأربعة تطلب إثباتاً بدرجة تشفيرية بمفردات مختلفة. أما الرابع (NIST AI RMF) فطوعي لكنه مطلوب بحكم الأمر الواقع في مشتريات المؤسسات. وتتلاقى جميعها في الشكل نفسه: أثر يستطيع المدقق التحقق منه دون الثقة في سجلاتكم.

الانقسام: الأوزان المفتوحة مقابل واجهات الـ API المغلقة

قبل الإسقاط لكل مرحلة، أهم تحفُّظ في هذه المقالة بأكملها:

بالنسبة للنماذج ذات الأوزان المفتوحة — Gemma، Qwen، Llama، Mistral، GPT-OSS، أي نموذج تكون أوزانه قابلة للعنونة والتحرير — يُصدِر كل قرار إطلاق من Divinci إيصال vindex يتضمن شهادة وزن: إثبات تشفيري بأن الأوزان النشطة وقت القرار هي تماماً الأوزان التي سجَّلها البيان. هذا ما يجعل المحو القابل للتحقق بموجب المادة 17 من GDPR ممكناً. تُطبِّق رقعة DELETE تُزيل علاقة كيان محددة من فضاء الوزن، ويُضمِّن الإيصال تجزئة الحالة قبل وبعد، ويستطيع المدقق التحقق من حدوث الحذف بإعادة تشغيل عملية التحقق مقابل vindex العامة.

بالنسبة للنماذج عبر API المغلقة — OpenAI، Anthropic، Google عبر واجهات API معتمة — يغطي الإيصال نفسه سلسلة القرار (أي بيان، أي نتيجة بوابة، أي قراءة مراقب، أي مستخدم أطلق أي إجراء) لكنه لا يستطيع المطالبة بإثبات مصدر الأوزان، لأن المزوِّد لا يكشف عن الأوزان. يُشير الإيصال إلى ذلك صراحةً في حقل weight_attestation: null مع note يشرح السبب. هذا ليس وضعية امتثال متدنية — إنه حد ما يمكن التحقق منه، مُدوَّناً بصراحة. المدقق الذي يقرأ الإيصال يفهم تماماً أي فئة من الإثبات يُقدَّم وأيها لا يُقدَّم.

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

كيف يُسقَط كل إطار على مراحل خط الإطلاق الأربع

يضم خط الإطلاق أربع مراحل. يُسقَط طلب كل منظِّم على مرحلة أو أكثر. المصفوفة أدناه هي الإسقاط الفعلي.

الخليتان المُعَلَّمتان بـ ◐ هما إدخالات المادة 17 من GDPR / المخصصة للأوزان المفتوحة فقط — هذه هي المطالب التي لا يستطيع مسار API المغلق تلبيتها بالكامل. كل ما عداها ينطبق على كلا النوعين.

تُسلِّط بقية المقالة الضوء على إسهام كل مرحلة.

المرحلة ① — التسجيل

تُنتِج مرحلة التسجيل بيان JSON غير قابل للتغيير، مُعنوناً بـ SHA-256. للإطلاقات الخاضعة للتنظيم يحمل البيان كل ما يطلبه الملحق الرابع^[1] في أثر واحد:

• أثر النموذج (مستودع HF + commit SHA، أو مرجع رقعة vindex)
• قالب التحفيز (كل متغيِّر، كل رسالة نظام — تحت تحكم الإصدار)
• قواعد التوجيه (أي فئة حركة مرور تصل إلى أي إطلاق)
• إصدار مجموعة البيانات المستخدَم لحساب عتبات البوابة (ملخص بيانات التدريب بالتجزئة)
• SHA الإطلاق السابق (حتى تبقى سلسلة التدقيق متصلة)
• نطاق الإفصاح — لعمليات نشر HIPAA، أي فئات PHI يُسمح للنموذج بتلقّيها

البيان هو التوثيق. لا يقرأ المدقق نصاً نثرياً؛ بل يقرأ تجزئة البيان ويتحقق من الحزمة. لا حاجة إلى ملخص نثري كُتب بعد ستة أشهر.

مكافأة الأوزان المفتوحة. عندما يشير أثر النموذج إلى نموذج بأوزان مفتوحة، يُضمِّن البيان أيضاً vindex_sha256 — البصمة التشفيرية لـ vindex المنشور للنموذج. هذه البصمة هي ما يتيح لطرف ثالث التحقق من الأوزان النشطة دون الاضطرار قط للثقة في بنيتنا التحتية للنشر.

تحفُّظ API المغلق. عندما يشير أثر النموذج إلى نموذج عبر API مغلق، يكون حقل vindex_sha256 في البيان null، ويكون weight_attestation_class في البيان decision_chain_only. المدقق الذي يقرأ هذا يعرف تماماً ما يُدَّعى وما لا يُدَّعى.

المرحلة ② — البوابة

مرحلة البوابة هي المكان الذي تتحول فيه “تدابير الإشراف البشري”^[1] في قانون الذكاء الاصطناعي للاتحاد الأوروبي إلى ممارسة. المنظم الذي يقرأ قانون الذكاء الاصطناعي للاتحاد الأوروبي ويستنتج “نحتاج إلى تدفق موافقة بشري” قد فاته جوهر الأمر — السؤال الأصعب هو مقابل أي شيء يوافق البشري. تُجيب مرحلة البوابة على هذا السؤال بمعامل سبيرمان ρ لكل شريحة مقابل مُقَيِّم مُرتكز بشرياً^[3]. كل شريحة مهمة في وضعيتك التنظيمية (طب أورام الأطفال، ترخيص الملكية الفكرية، الفرنسية البلجيكية) تحصل على عتبتها الخاصة. يتطلب مسار التجاوز مبرراً مكتوباً يدخل مسار التدقيق.

بالنسبة لعمليات النشر التي يشملها HIPAA، هذا أيضاً هو موضع قاعدة “الحد الأدنى الضروري” للإفصاح. تشمل مجموعة الـ QA المُقَيَّمة في البوابة اختبارات سلبية للإفراط في كشف PHI — إجابات تتضمن مُعرِّفات شخصية حين لم يُطلَب شيء منها. إطلاق يتراجع على شريحة الإفراط في الكشف يفشل في البوابة، بصرف النظر عن أداء شرائحه الأخرى.

بالنسبة لـ NIST AI RMF، تغطي مرحلة البوابة وظيفة “القياس” — الدليل العددي لكل شريحة على أن النظام يعمل ضمن نطاقات التحمل المُهَيَّأة.

المرحلة ③ — الطرح

يتطلب رصد ما بعد السوق في قانون الذكاء الاصطناعي للاتحاد الأوروبي^[1] من المُشَغِّل إثبات مراقبة متواصلة — وليس فقط ما قبل الإطلاق — لكيفية أداء نظام الذكاء الاصطناعي في الظروف الحقيقية. كنري 5% ← 25% ← 100% مع نقاط فحص لمراقب الجودة هو الطريقة الأكثر طبيعية لتلبية هذا الطلب. مدة المكوث عند كل نقطة فحص، إضافةً إلى قراءات المراقب أثناء المكوث، هي ما يريد المدقق رؤيته.

بالنسبة لـ HIPAA، مرحلة الكنري هي أيضاً المكان الذي يُمارَس فيه تسجيل تدقيق الطلب من الطرف إلى الطرف. تُنتِج كل نقطة فحص عيِّنة من إيصالات طلب-استجابة موقَّعة؛ إذا كان أي منها يحتوي على معالجة PHI مُهَيَّأة بشكل خاطئ، فإنها تظهر عند 5% من حركة المرور بدلاً من 100%.

المرحلة ④ — المراقبة

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

كل قرار إطلاق — تسجيل، نجاح بوابة، فشل بوابة، تجاوز بوابة، ترقية نقطة فحص، تعليق نقطة فحص، إلغاء عودة تلقائي، إلغاء عودة يدوي، وأي تطبيق لرقعة DELETE بموجب المادة 17 من GDPR — يُصدِر إيصال vindex. مُسَلسَل بالتجزئة مع الإيصال السابق لهذا العميل والإيصال السابق لهذا الإطلاق.

إليك ما يبدو عليه إيصال حقيقي لرقعة DELETE بموجب المادة 17 من GDPR — مُعدَّل مباشرةً من الصيغة المُوَثَّقة على صفحة الامتثال:

{
  "name": "gdpr-art17-patient-12348-removal",
  "version": 1,
  "base_model": "google/gemma-4-E2B-it",
  "manifest_sha256": "9abaeaf6c91f8b...",
  "previous_manifest_sha256": "8f72b1de4a93c5...",
  "created_at": "2026-05-29T03:17:42Z",
  "user_id": "compliance-officer-7c4e1a",
  "operation": {
    "op": "delete",
    "entity": "patient-record-12348",
    "relation": "diagnosis-association",
    "target": "weight-feature-11179-layer-27",
    "weight": -1.0
  },
  "verification": {
    "before_feature_11179_score": 17.34,
    "before_feature_11179_rank": 1,
    "after_feature_11179_score": null,
    "after_feature_11179_rank": "ABSENT_FROM_TOP_25",
    "perplexity_delta_wikitext103": "+0.02%",
    "vindex_sha256_before": "abc12...",
    "vindex_sha256_after":  "def34..."
  },
  "weight_attestation_class": "full",
  "chain_signature": "sha256(manifest || prev_manifest || user_id || created_at || prev_chain_signature)"
}

هذا الأثر قابل للتحقق. لا يتعيَّن على المدقق الثقة في سجلاتنا. يأخذ vindex_sha256_after، ويسحب vindex المنشور المقابل من huggingface.co/Divinci-AI، ويتحقق من أن الميزة 11179 في الطبقة 27 غائبة هيكلياً من أعلى 25. يأخذ chain_signature ويتحقق منه مقابل الإيصال السابق. السلسلة بأكملها مُثَبَّتة خارجياً وفق جدول زمني يُهَيِّئه العميل.

نفس العملية مقابل نموذج عبر API مغلق. تتغير حقول الإيصال أعلاه بثلاث طرق: يصبح operation.target هو provider_api_endpoint، ويصبح verification مخططاً مختلفاً يغطي دليل سلسلة القرار فقط، ويصبح weight_attestation_class هو decision_chain_only. مزوِّد النموذج عبر API المغلق لم يكشف عن الأوزان، فالإيصال يقول ذلك. المدقق الذي يريد إثباتاً على مستوى الوزن يعرف الآن أنه بحاجة إلى التصعيد إلى المزوِّد، لا إلينا.

هذا هو التمييز الذي لا يُصدِره أحد آخر في 2026. معسكر eval-CI (Braintrust وHumanloop وPatronus) لا يجلس على حركة المرور ولا يُصدِر إيصالات قرار. معسكر كنري التقديم (SageMaker Deployment Guardrails^[2]، KServe، Vertex، BentoCloud، Seldon) يُصدِر سجلات مقاييس بنية تحتية لكن ليس إيصالات امتثال مُتَسَلسَلة بالتجزئة. معسكر القابلية للمراقبة (Arize، Phoenix، Confident، Deepchecks) يراقب الخرج لكنه لا يُنفِّذ.

ما الذي يتحقق منه المدقق فعلياً؟

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

ما لا يضطر المدقق إلى فعله: الثقة في Datadog لدينا. الثقة في CloudWatch لدينا. الثقة في لقطة شاشة. الثقة في تصدير. الهدف من صيغة الإيصال هو أن يستطيع المدقق التحقق منها باستقلال.

ما الذي لا تحلّه هذه الطريقة

ثلاثة حدود صادقة:

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

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

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

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

ما هو المحو القابل للتحقق بموجب المادة 17 من GDPR لأنظمة الذكاء الاصطناعي؟

المحو القابل للتحقق يعني أن طرفاً ثالثاً يستطيع التحقق من أن البيانات قد أُزيلت دون الاضطرار للثقة في سجلاتك. ضبط نموذج لـ “ينسى” معلومات معينة لا يستوفي هذا المعيار — يمكن أن تظهر المعلومات مجدداً تحت التحفيز العدائي، ولا توجد بنية أولية تشفيرية يستطيع المدقق فحصها. أما رقعة DELETE على مستوى الوزن مع تجزئة vindex قبل/بعد منشورة فإنها تستوفي المعيار، لأن المدقق يستطيع إعادة تشغيل التحقق مقابل الأثر العام.

لماذا لا تستطيع النماذج عبر API المغلق تلبية المادة 17 من GDPR بالطريقة نفسها؟

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

ماذا يتطلب الملحق الرابع من قانون الذكاء الاصطناعي للاتحاد الأوروبي، بلغة بسيطة؟

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

ما السرعة التي ينبغي أن يكون عليها إلغاء العودة لعمليات النشر التي يشملها HIPAA؟

لا يحدد HIPAA وقت إلغاء عودة، لكن إرشادات HHS بشأن الاستجابة للخروقات تتعامل مع الوقت اللازم للاحتواء بوصفه حمَّال ثقل. إلغاء عودة في حدود الثواني (تصريف أثناء الطيران على تبديل مُدار بالبيان — رقمنا حوالي 12 ثانية) أسرع هيكلياً من blue-green التقليدي المعتمد على مقاييس البنية التحتية الذي يعتمد على انتشار الإنذار. قارن بمراجعات الحوادث العامة: حادث Cloudflare في يونيو 2022^[4] استغرق 44 دقيقة للعودة لأن المهندسين تجاوز بعضهم على عمليات عودة بعض.

كيف يُسقَط NIST AI RMF على خط إطلاق؟

تمتد الوظائف الأساسية الأربع لـ NIST AI RMF — الحوكمة، التخطيط، القياس، الإدارة — عبر دورة حياة الإطلاق بأكملها، وليس مرحلة واحدة. الحوكمة هي سياسة الإطلاق المُوَثَّقة بالإضافة إلى تدفق مبرر تجاوز البوابة (مرحلتا التسجيل والبوابة). التخطيط هو مجموعة الـ QA المُقَيَّمة لكل شريحة (البوابة). القياس هو عتبات سبيرمان لكل شريحة ومراقب الجودة المستمر (البوابة والمراقبة). الإدارة هي مسار إلغاء العودة وسلسلة الإيصالات (المراقبة). تُغطى الوظائف الأربع جميعها حين يُصدِر خط الإطلاق مجموعة إيصالاته الكاملة.

المراجع

1. قانون الذكاء الاصطناعي للاتحاد الأوروبي. artificialintelligenceact.eu. يُحَدِّد الملحق الرابع متطلبات التوثيق التقني لأنظمة الذكاء الاصطناعي عالية المخاطر: منطق النظام، ملخص بيانات التدريب، تدابير الإشراف البشري، رصد ما بعد السوق. عقوبات تصل إلى 7% من الإيرادات العالمية لعدم الامتثال.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. القيمة الافتراضية لـ TerminationWaitInSeconds هي 600، والحد الأقصى لـ MaximumExecutionTimeoutInSeconds هو 1800. مُستشهَد به بوصفه كنري مقاييس البنية التحتية القياسي في الصناعة الذي يُقارَن به مراقب الجودة في المرحلة 4.
3. اتفاق LLM-as-judge المُعَايَر. Zheng et al.، Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). اتفاق GPT-4 مع البشر إجمالاً يتجاوز 80%، مع تباين بحسب الفئة من البرمجة (86%) نزولاً إلى الكتابة (36–44%). مرتكز لمعايرة سبيرمان لكل شريحة التي تُحَرِّك مرحلة البوابة.
4. انقطاع Cloudflare في يونيو 2022. Cloudflare outage on June 21, 2022. 44 دقيقة من "نعرف ما الذي يتعين العودة عنه" إلى إتمام العودة لأن المهندسين تجاوزوا على عمليات عودة بعضهم. مرتكز لادعاء "إلغاء العودة المُدار بالبيان لا يمكن أن يكون له وضع الفشل ذاك".
5. NIST AI Risk Management Framework. NIST AI RMF. Voluntary framework — Govern, Map, Measure, Manage — that has become the de facto enterprise procurement baseline for AI governance. Voluntary but enforced in practice through customer due-diligence questionnaires.
6. HIPAA Privacy Rule. HHS Office for Civil Rights. Minimum-necessary disclosure, access audit, and breach response timing requirements applicable to any AI system that touches PHI. Civil monetary penalties up to $1.9M per violation-type per year per CMP inflation adjustment, 2025.
7. GDPR Article 17 (Right to Erasure). gdpr-info.eu/art-17-gdpr. The data subject's right to obtain erasure of personal data, and the controller's obligation to demonstrate compliance under Article 5(2) accountability. Penalties up to €20M or 4% of annual global turnover.
8. Internal — vindex receipt format. The receipt JSON in this post is adapted from the format documented on the compliance page and demonstrated in the "Deleting Paris from a Language Model" post. The hash chain is SHA-256 over manifest || prev_manifest || user_id || created_at || prev_chain_signature. Externally anchorable on a customer-configured schedule.

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