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

عثرتُ على نماذج ذكاء اصطناعي بأبواب خلفية على Hugging Face — وكذلك فعل كل من كلّف نفسه عناء البحث

Ashutosh SinghalAshutosh Singhal23 أبريل 202614 min

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

قلت: "انتظر. ما صيغة هذا النموذج؟"

Pickle.

انقبضت معدتي.

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

النموذج الذي يتصل بالبيت

إليك ما حدث فعليًا على Hugging Face. رفع مستخدم باسم "baller423" نموذج PyTorch بدا طبيعيًا تمامًا. اسم معقول، ووصف مقنع، ومقاييس أداء تبدو محترمة. لكن مدفونًا داخل أوزانه المُسلسَلة بصيغة pickle كانت هناك حمولة خبيثة، ما إن شغّل أحدهم torch.load()، حتى فتحت صدفة عكسية إلى عنوان IP يعود إلى شبكة Korea Research Environment Open Network.

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

ولم يكن "baller423" وحده. عثرت JFrog على نحو 100 نموذج مثل هذا — كل واحد منها حصان طروادة متنكّر في هيئة نموذج مُدرَّب مسبقًا نافع.

حين تشغّل torch.load() على ملف pickle، فأنت لا تحمّل بيانات. أنت تنفّذ شيفرة. وليست لديك أدنى فكرة عما تفعله تلك الشيفرة حتى يفوت الأوان.

عليّ أن أشرح لماذا يبلغ هذا الخطر هذا الحد، لأن معظم الناس — بل ومعظم المهندسين — لا يدركون ما هو pickle حقًا. صيغة pickle في Python ليست مجرد طريقة لتسلسل البيانات. إنها آلة افتراضية قائمة على المكدّس. بوسعها تنفيذ أي دوال Python اعتباطية أثناء فك التسلسل. فحين يحمّل عالم البيانات لديك نموذجًا، يستطيع pickle أن يستدعي بصمت os.system() أو subprocess.run() في الخلفية. النموذج يعمل على ما يرام. التنبؤات تبدو طبيعية. وفي الأثناء، يكون لدى شخص ما في الطرف الآخر من العالم صدفة على خادمك.

هذه ليست ثغرة برمجية. هكذا صُمِّم pickle. نحن فقط لم نحسب يومًا حساب ما يعنيه ذلك حين تأتي الملفات من غرباء على الإنترنت.

لماذا لم تلتقطه أدوات الفحص؟

هذا هو الجزء الذي أرّقني تلك الليلة. كانت لدينا أدوات أمنية. وكان لدى القطاع PickleScan، الأداة المعيارية لفحص ملفات النماذج. وHugging Face نفسها تشغّلها. لا بد أن أدوات الفحص ستلتقط شيئًا بهذا الوضوح، أليس كذلك؟

لم تلتقطه. والأمر يزداد سوءًا.

اكتشفت JFrog لاحقًا ثلاث ثغرات يوم-صفر في PickleScan نفسها — إحداها مسجَّلة برقم CVE-2025-10155 — تتيح للمهاجمين تجاوز الكشف تمامًا عبر التلاعب بامتدادات الملفات أو استغلال تعارضات في أرشيفات ZIP. يمكن لنموذج خبيث أن يُصنَّف "آمنًا" من قِبَل الأداة ذاتها المصمَّمة لحمايتك.

الصورة الإحصائية قاتمة: ما يصل إلى 96% من تنبيهات أدوات الفحص الحالية إيجابيات كاذبة. فكّر فيما يفعله ذلك بفريق أمني. بعد الإنذار الكاذب المئة، تكفّ عن التدقيق. وتبدأ بالنقر على "موافقة" بشكل انعكاسي. وعند تلك اللحظة بالضبط، يدخل التهديد الحقيقي من الباب.

خضت نقاشًا محتدمًا مع أحد قادة فرقي حول هذا. كان يرى أننا نبالغ في ردة الفعل. قال: "نحن لا نسحب النماذج إلا من مؤسسات موثّقة." أريته بيانات JFrog. أريته أن حتى الصيغ الأحدث "الآمنة" مثل GGUF — المصمَّمة تحديدًا لتفادي مشكلات pickle — وُجد أنها تؤوي قوالب Jinja خبيثة في بياناتها الوصفية تُنفَّذ أثناء الاستدلال، لا أثناء التحميل. أداة الفحص لا تراها أبدًا لأن الهجوم يقع لاحقًا، حين يكون النموذج قيد التشغيل بالفعل.

صمت طويلًا. ثم قال: "إذن، بماذا نثق فعلًا؟"

هذا هو السؤال الصحيح.

ماذا يحدث حين يكون داخل ذكائك الاصطناعي عميل نائم؟

مخطط يوضّح سلسلة القتل للذكاء الاصطناعي (AI Kill Chain) من NVIDIA — المراحل الخمس التي يخترق بها المهاجمون أنظمة تعلّم الآلة بشكل ممنهج — مع إحصاءات رئيسية من المقال مُعلَّقة عند المراحل ذات الصلة.

كانت حادثة Hugging Face تتعلق بحمولات فجّة قابلة للكشف — صدفات عكسية، وتنفيذ شيفرة ظاهر للعيان. لكن التهديد الأعمق، ذاك الذي يخيفني حقًا، هو تسميم البيانات. والأبحاث في هذا الشأن مرعبة.

أثبت فريق NVIDIA الأحمر للذكاء الاصطناعي، بالاستناد إلى نتائج Anthropic، أن بإمكانك زرع سلوك خفي بشكل دائم في نموذج بـ13 مليار معامل عبر تسميم ما لا يتجاوز 0.00016% من بيانات التدريب — أي نحو 250 وثيقة من بين الملايين.

دع هذا الرقم يستقر في ذهنك. مئتان وخمسون وثيقة.

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

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

وإليك الضربة الرياضية الموجعة: إضافة المزيد من البيانات النظيفة لا تصلح الأمر. فما إن يبلغ الباب الخلفي عتبة معينة — عادةً من 50 إلى 100 ظهور للمُحفِّز أثناء التدريب — حتى يصبح مخبوزًا بشكل دائم داخل الأوزان. لا يمكنك التخلص منه بالتدريب. ولا يمكنك تخفيفه حتى الزوال.

صاغت NVIDIA هذا في ما تسميه سلسلة القتل للذكاء الاصطناعي (AI Kill Chain): خمس مراحل — الاستطلاع، والتسميم، والاختطاف، والتثبيت، والتأثير — ترسم كيف يخترق المهاجمون أنظمة تعلّم الآلة بشكل ممنهج. وقد كتبت عن هذا الإطار وعن الطيف الكامل لمتجهات الهجوم في عرضنا البحثي التفاعلي، وأشجّع كل من ينشر نماذج في بيئة الإنتاج على أن يخصص وقتًا لقراءته.

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

مشكلة الذكاء الاصطناعي الظِّلّي التي لا يريد أحد الحديث عنها

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

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

والأثر المالي ليس تجريديًا. فالحوادث التي تشمل أدوات ذكاء اصطناعي غير مفحوصة ترفع تكلفة اختراق البيانات بمتوسط قدره $670,000. هذه هي العلاوة التي تدفعها مقابل "التحرك بسرعة" دون حوكمة.

أتفهّم هذا الاندفاع. أتفهّمه حقًا. فحين تكون مهندسًا تحاول إطلاق ميزة وتستغرق عملية المراجعة الأمنية ثلاثة أسابيع، فمن الطبيعي أن تُغريك فكرة أن تسحب نموذجًا من Hugging Face وتوصّله وحسب. لقد شعرت بذلك الإغراء بنفسي. لكن إفصاح JFrog كان ينبغي أن ينهي ذلك العصر. نحن نعلم الآن، بيقين تجريبي، أن منصات النماذج العامة تحتوي على أدوات مُسلَّحة. والتعامل معها كمصادر موثوقة هو المعادل في عالم الذكاء الاصطناعي لتشغيل curl | bash من gist عشوائي على GitHub في بيئة الإنتاج.

لماذا لا يزال الجميع يطيرون بلا رؤية؟

إنفوغرافيك صارخ يعرض إحصاءات فجوة الحوكمة الأربع الواردة في المقال، مع إبراز رقم الـ83% "تعمل بلا رؤية" بصريًا ليهيمن على التصميم وينقل حجم المشكلة.

أصدرت NIST إرشاداتها AI 100-2 في عام 2024 — وهي تصنيف شامل لهجمات تعلّم الآلة العدائية وسبل التخفيف منها. إنه عمل جيد. يمنح القطاع لغة مشتركة لهذه التهديدات. ولم ينفّذه أحد تقريبًا.

والأرقام مُدينة:

  • لا تملك سوى 17% من المؤسسات ضوابط أمنية آلية للذكاء الاصطناعي
  • لا تملك سوى 12% منها حوكمة شاملة للذكاء الاصطناعي مطبَّقة
  • لا تملك سوى 14% منها رؤية واضحة لتدفقات بيانات الذكاء الاصطناعي الداخلية
  • 83% من المؤسسات، بتعبير NIST، "تعمل بلا رؤية"

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

83% من المؤسسات لا تملك أي ضوابط آلية على سلسلة توريد الذكاء الاصطناعي لديها. هذه ليست فجوة — إنها باب مفتوح.

كيف بدأنا نتعامل مع النماذج كشيفرة خبيثة

مخطط معماري يوضّح نظام الدفاع ثلاثي الطبقات الموصوف في المقال: ML-BOM من أجل الشفافية، والتوقيع التشفيري مع ضبط القبول عند وقت التحميل، ومراقبة زمن التشغيل أثناء الاستدلال.

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

ليس "غالبًا سليم." وليس "من مصدر ذي سمعة طيبة." بل يُحتمل أن يكون خبيثًا. وانتهى الأمر.

قائمة مواد تعلّم الآلة

أول ما احتجناه كان الشفافية. فقوائم مواد البرمجيات التقليدية (SBOMs) تتعقّب المكتبات والإصدارات، لكن أدوات الذكاء الاصطناعي تحتاج إلى ما هو أكثر: ML-BOM — قائمة مواد تعلّم الآلة — تلتقط مصدر البيانات، ونسب النموذج، وتبعيات أطر العمل، والإثباتات التشفيرية.

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

إن لم تستطع الإجابة عن هذه الأسئلة، فأنت لا تعرف ما الذي تنشره.

إعدام pickle، وتوقيع كل شيء

اتخذنا قرارين هندسيين فوريين. الأول: لا مزيد من pickle. نقطة. كل نموذج في خط إنتاجنا يستخدم SafeTensors — وهي صيغة لا تخزّن سوى بيانات المصفوفات (tensor) مع بيانات وصفية بصيغة JSON، ولا يمكنها تنفيذ شيفرة أثناء التحميل. إنها أقل مرونة من pickle، وهذا هو المقصود بالضبط.

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

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

مراقبة زمن التشغيل: لأن الفحوص الساكنة لا تكفي

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

وللاطلاع على المعمارية التقنية الكاملة — بما فيها نهجنا في الحوسبة السرية عبر بيئات تنفيذ موثوقة مدعومة بالعتاد — انظر الغوص التقني العميق في ورقتنا البحثية. هناك مستوى من تفاصيل التنفيذ يتجاوز ما يمكنني تغطيته في مقال.

الحقيقة المزعجة بشأن "الذكاء الاصطناعي العميق" مقابل أغلفة الـAPI

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

حين تغلّف واجهة برمجية عامة، فأنت تُسنِد سلسلة توريد الذكاء الاصطناعي لديك إلى طرف آخر. ولا تملك أي رؤية على مصدر نماذجهم، ولا بيانات تدريبهم، ولا وضعهم الأمني. أنت تثق بأن OpenAI أو Anthropic أو Google قد قامت بالعمل الشاق لتأمين خط إنتاجها. ربما فعلت. لكنك لا تستطيع التحقق من ذلك، وفي الأمن، الثقة بلا تحقق ليست سوى أمنية.

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

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

أمن الذكاء الاصطناعي وأمن البرمجيات صارا المشكلة نفسها الآن

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

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

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

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

"لكننا لسنا هدفًا"

يعترض الناس دائمًا بصيغة ما من هذا. "نحن لا نفعل شيئًا حساسًا بما يكفي ليستدعي هذا المستوى من الأمن." "نماذجنا مجرد أدوات داخلية." "لن يكلّف أحد نفسه عناء تسميم نموذج لمهاجمتنا."

سمعت الحجج نفسها عن أمن مكتبات المصدر المفتوح عام 2018. ثم وقعت حادثة SolarWinds. ثم وقعت Log4Shell. ثم وقع الباب الخلفي في XZ Utils — حملة هندسة اجتماعية امتدت سنوات لاختراق مكتبة ضغط واحدة يستخدمها SSH على كل خادم Linux في العالم.

وسلسلة توريد الذكاء الاصطناعي تسلك المسار نفسه، لكن أسرع. فسطح الهجوم أكبر (أوزان النماذج كتل ثنائية معتمة لا يمكن تدقيقها كما تُدقَّق الشيفرة المصدرية)، والأدوات أقل نضجًا (PickleScan فيها ثغرات يوم-صفر)، وفجوة الحوكمة أوسع (83% من المؤسسات لا تملك أي ضوابط آلية).

لست بحاجة إلى أن تكون هدفًا لتصبح ضحية. يكفي أن تكون في الطريق.

كيف يبدو أمن الذكاء الاصطناعي المُمِلّ

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

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

المُمِلّ يعني أنه حين يسأل أحدهم "ما نماذج الذكاء الاصطناعي التي تعمل في بيئة الإنتاج؟" يمكنك أن تجيب في أقل من خمس دقائق، مع إثبات تشفيري.

الهدف ليس جعل نشر الذكاء الاصطناعي مثيرًا. بل جعله مُمِلًّا — قابلًا للتنبؤ، وقابلًا للتدقيق، وآمنًا. فأمن الذكاء الاصطناعي المثير يعني أن شيئًا ما قد ساء.

لم تكن النماذج الخبيثة الـ100+ على Hugging Face حادثة معزولة. كانت عَرَضًا لقطاع بنى قدرات مذهلة على أساس من الثقة العمياء. لقد كنا نحمّل النماذج بالطريقة نفسها التي كنا نحمّل بها ملفات MP3 من LimeWire — نأمل الأفضل، ونتجاهل المخاطر الواضحة، ونتظاهر بالدهشة حين يسوء شيء ما.

لقد انتهى ذلك العصر. والمؤسسات التي ستنجو من الموجة القادمة من الهجمات على سلسلة توريد الذكاء الاصطناعي هي تلك التي قررت، الآن تحديدًا، أن تتعامل مع نماذجها لا بوصفها صناديق سحرية بل بوصفها شيفرة تنفيذية بكل ما يستتبعه ذلك من سطح هجوم. تلك التي اختارت المُمِلّ على السريع. تلك التي نظرت إلى الطرفية، ورأت ملف pickle يُحمَّل، وقالت: "انتظر. ما هذه الصيغة؟"

أبحاث ذات صلة

منشور أيضًا على

ابنِ ذكاءك الاصطناعي بثقة.

تعاون مع فريق يمتلك خبرة عميقة في بناء الجيل القادم من الذكاء الاصطناعي للمؤسسات. دعنا نساعدك على تصميم استراتيجية ذكاء اصطناعي جديرة بثقتك وبنائها وتطبيقها.

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