بقلم: فهد العنزي
خلال السنوات الماضية، تعودنا في التقنية والأمن السيبراني على مفهوم واضح: المؤسسة قد تستعين بمورد خارجي لتقديم خدمة أو تشغيل نظام، لكنها تظل مسؤولة عن المخاطر الناتجة عن استخدام تلك الخدمة. اليوم نحتاج أن نطبق المبدأ نفسه على الذكاء الاصطناعي، ولكن بصورة أكثر جدية. لأن ما يحدث حاليًا داخل كثير من المؤسسات هو توسع سريع في استخدام حلول AI من أطراف خارجية: نماذج لغوية، مساعدين ذكيين، روبوتات محادثة، أدوات توظيف، أنظمة تحليل بيانات، مساعدين آليين، ووكلاء ذكيين، وحلول مدمجة داخل الأنظمة المؤسسية. والخطأ هو الاعتقاد بأن مسؤولية المؤسسة تقل لأن التقنية جاءت من شركة أخرى. في الواقع، قد يحدث العكس تمامًا.
كلما أصبح الذكاء الاصطناعي جزءًا من عمليات المؤسسة وقراراتها وبياناتها، أصبحت مخاطر المورد جزءًا من مخاطر المؤسسة نفسها.
وهنا يجب أن نتوقف عن النظر إلى AI كأداة تقنية فقط، ونبدأ في التعامل معه باعتباره جزءًا من منظومة المخاطر المؤسسية.
شراء AI لا يعني شراء المسؤولية معه
لنفترض أن شركتك تستخدم نموذجًا من مزود عالمي. أنت لم تطور النموذج. لم تجمع بيانات تدريبه. لم تصمم خوارزمياته. ولا تعرف بالضرورة كل ما يحدث داخله. لكن شركتك قررت استخدامه. وشركتك هي التي قررت ربطه ببيانات العملاء. وشركتك هي التي سمحت له بالوصول إلى أنظمتها. وشركتك هي التي حددت ما إذا كان سيقدم توصية فقط أو سيؤثر فعليًا في قرار. وهنا تكمن النقطة الأساسية:
عدم امتلاكك للتقنية لا يعني عدم امتلاكك للمخاطر الناتجة عن استخدامها.
إذا قدم النظام إجابة خاطئة إلى عميل، أو كشف بيانات، أو اتخذ قرارًا متحيزًا، أو نفذ إجراءً غير صحيح، فلن يكون كافيًا أن نقول:
النظام من طرف ثالث.
بالنسبة للعميل، هو يستخدم خدمتك أنت. وبالنسبة للموظف، النظام جزء من بيئة عملك أنت. وبالنسبة للجهات التنظيمية، مؤسستك هي التي اختارت استخدام التقنية في هذه العملية. ولهذا أرى أن مخاطر الذكاء الاصطناعي لدى الأطراف الثالثة يجب ألا تُعامل كامتداد بسيط لإدارة مخاطر الموردين التقليدية. الذكاء الاصطناعي يضيف طبقة مختلفة من المخاطر.
المشكلة تبدأ قبل شراء النظام
في كثير من المؤسسات، تبدأ عملية شراء حلول AI بالطريقة التقليدية: متطلبات العمل → تقييم المورد → التقييم الأمني → العقد → التشغيل. لكن هذا المسار لم يعد كافيًا. لأن تقييم الأمن السيبراني قد يخبرني أن المورد يستخدم التشفير، ولديه ISO 27001، ويطبق MFA، ويجري اختبار الاختراق. ممتاز. لكن كل ذلك لا يجيب عن أسئلة مختلفة تمامًا:
كيف يتصرف النموذج؟
ما حدود استخدامه؟
هل بياناتنا تستخدم لتحسين أو تدريب النموذج؟
ماذا يحدث للمطالبات النصية والملفات التي يرفعها الموظفون؟
أين تعالج البيانات؟
ما مدة الاحتفاظ بها؟
هل توجد جهات معالجة فرعية؟
هل يستطيع المورد تغيير النموذج دون إشعارنا؟
ماذا سيحدث لسلوك النظام بعد تحديث النموذج؟
هل نستطيع استخراج سجلات كافية للتحقيق في حادث؟
هل يمكننا تفسير قرار مهم ساهم AI في اتخاذه؟
هنا ننتقل من:
تقييم أمن الطرف الثالث
إلى:
تقييم مخاطر الذكاء الاصطناعي لدى الطرف الثالث.
وهما ليسا الشيء نفسه.
لا أثق في AI لأن المورد كبير
هناك افتراض خطير يجب التخلص منه:
المورد شركة عالمية، إذًا النظام آمن.
حجم المورد لا يلغي المخاطر. قد يكون المورد ممتازًا من ناحية الأمن والبنية التحتية، لكن النموذج نفسه قد لا يكون مناسبًا للاستخدام الذي اخترته أنت. وهذا فرق مهم. قد يقدم المورد نموذجًا عامًا، بينما تقوم المؤسسة باستخدامه في: التوظيف، أو تقييم الموظفين، أو الائتمان، أو التأمين، أو الرعاية الصحية، أو التحليل القانوني، أو القرارات المالية. في هذه الحالة، السؤال ليس فقط:
هل النموذج جيد؟
بل:
هل النموذج مناسب لهذا الاستخدام تحديدًا؟
وقد تكون الإجابة مختلفة تمامًا. ولهذا يجب أن يرتبط تقييم AI دائمًا بـ حالة استخدام محددة. لا يوجد عندي شيء اسمه:
نموذج ذكاء اصطناعي معتمد
بشكل مطلق. الأصح:
نموذج ذكاء اصطناعي معتمد لحالة استخدام محددة، وتصنيف بيانات واضح، ومستوى صلاحيات محدد.
قد أوافق على نموذج لتلخيص مستندات عامة. لكنني لا أوافق على النموذج نفسه لاتخاذ قرار توظيف. وقد أسمح له بقراءة قاعدة معرفة داخلية، لكن لا أسمح له بالوصول إلى قاعدة بيانات العملاء. وقد أسمح له باقتراح عملية، لكن لا أسمح له بتنفيذها.
المخاطر ليست في النموذج وحده. المخاطر في النموذج + البيانات + الاستخدام + الصلاحيات + القرار.
عندما نخصص النموذج، تبدأ المسؤولية بالتغير
المرحلة التالية أخطر. نشتري نموذجًا جاهزًا، ثم نقول: نريد أن نجعله مناسبًا لنا. فنربطه ببيانات المؤسسة. ثم نضيف الاسترجاع المعزز بالتوليد (RAG). ثم قاعدة المعرفة. ثم الضبط الدقيق. ثم وكلاء أذكياء. ثم الوصول عبر واجهة API. ثم نعطي الوكيل صلاحية على نظام إدارة علاقات العملاء (CRM). ثم نظام تخطيط موارد المؤسسة (ERP). ثم البريد الإلكتروني. ثم مكتب الخدمة. وبعد فترة، لم يعد لدينا مجرد نموذج من طرف ثالث. لدينا نظام جديد بنيناه نحن باستخدام نموذج طرف ثالث. وهنا يجب أن نكون حذرين جدًا في تعريف المسؤوليات. كلما زاد التخصيص والتكامل والصلاحيات، أصبح من الأصعب تحميل المورد وحده مسؤولية سلوك النظام النهائي. لذلك، قبل أي تخصيص جوهري، أرى أن هناك ثلاثة أسئلة يجب الإجابة عنها:
ماذا يملك المورد؟
ماذا نملك نحن؟
ومن يتحمل أي مخاطر؟
هذه الحدود يجب ألا تكون مفهومة ضمنيًا. يجب أن تكون موثقة. تقنيًا. وتعاقديًا. وقانونيًا.
الـAI Agent يغيّر مستوى الخطر بالكامل
هناك أيضًا فرق كبير بين AI يجيب وبين AI ينفذ. روبوت المحادثة الذي يقدم إجابة خاطئة يمثل مشكلة. لكن الوكيل الذكي الذي يمتلك صلاحية تنفيذية ويقوم بإجراء خاطئ قد يكون مشكلة أكبر بكثير. تخيل وكيلًا يستطيع: إنشاء مستخدم. تعديل صلاحية. إرسال بريد. إصدار أمر شراء. تعديل بيانات عميل. تنفيذ عملية استرداد. الوصول إلى ملفات. تشغيل نص برمجي. أو استدعاء API داخلية. هنا لم نعد نتحدث فقط عن جودة إجابة AI. أصبحنا نتحدث عن الهوية، والتفويض، وفصل المهام، وحدود المعاملات، والمراقبة، وقابلية التدقيق، ومفاتيح الإيقاف. وهذا يعني أن وكيل AI يجب أن يعامل كـ هوية رقمية داخل المؤسسة. لا نعطيه صلاحيات مفتوحة لأنه "ذكي". بل نطبق عليه نفس المبادئ التي نطبقها على المستخدمين والأنظمة:
أقل قدر من الصلاحيات.
الحاجة إلى المعرفة.
فصل المهام.
تفويض صريح.
مراقبة مستمرة.
سجل تدقيق كامل.
وكل عملية حساسة يجب أن يكون واضحًا من نفذها: الإنسان؟ الـAI؟ أم الإنسان بناءً على توصية AI؟
وجود إنسان داخل الحلقة ليس مجرد زر موافقة
كثيرًا ما نسمع:
لدينا إنسان داخل الحلقة.
لكن عندما نفحص العملية نجد أن النظام يصدر التوصية، والموظف يضغط «موافقة» بشكل شبه تلقائي. هذه ليست رقابة بشرية حقيقية. الإنسان يجب أن يستطيع فهم القرار بدرجة كافية. ويجب أن يستطيع رفضه. ويجب ألا يكون تصميم العملية يدفعه إلى قبول توصية AI دون مراجعة. لذلك كلما ارتفعت حساسية القرار، يجب أن يرتفع مستوى الإشراف البشري. AI يلخص تقريرًا؟ المخاطر محدودة نسبيًا. AI يرفض متقدمًا لوظيفة؟ الوضع مختلف. AI يوصي برفض مطالبة تأمين؟ أعلى. AI ينفذ عملية مالية؟ أعلى بكثير. وهكذا.
ثم تأتي مشكلة لا نتحدث عنها كثيرًا: كيف نخرج؟
أثناء شراء التقنية، الجميع يسأل: كيف نربطها؟ لكن قليلًا من المؤسسات يسأل:
كيف نفصلها؟
وهذا سؤال أعتبره أساسيًا في أي بنية للذكاء الاصطناعي. لنفترض أننا استخدمنا مزودًا لمدة ثلاث سنوات. خلال هذه السنوات بنينا مئات المطالبات النصية. أنشأنا مسارات استرجاع معزز بالتوليد. ربطنا قواعد المعرفة. بنينا وكلاء أذكياء. أنشأنا اختبارات تقييم. طورنا حواجز حماية. ربطنا التسجيل والمراقبة. وكتبنا عمليات أعمال تعتمد على سلوك نموذج معين. ثم قررنا تغيير المورد. هل نستطيع؟ غالبًا نعم. لكن السؤال الحقيقي:
بأي تكلفة؟ وخلال كم من الوقت؟
إذا كانت الإجابة غير معروفة، فهذا خطر بحد ذاته.
الاحتجاز لدى المورد في AI مختلف
اعتدنا على الاحتجاز لدى المورد في السحابة وأنظمة ERP وقواعد البيانات. لكن AI يضيف مشكلة مختلفة. لأن الاعتماد ليس على البيانات أو API فقط. قد نعتمد على سلوك النموذج نفسه. قد يعطي المطالب النصي الذي حُسّن مئات المرات ليعمل مع النموذج A نتائج مختلفة مع النموذج B. وقد يحتاج إطار التقييم الذي بنيته إلى تعديل. وقد تحتاج حواجز الحماية إلى إعادة ضبط. وقد تتصرف الوكلاء بصورة مختلفة. حتى طريقة استدعاء الأدوات قد تختلف. لذلك يجب أن تبدأ استراتيجية الخروج من الذكاء الاصطناعي قبل توقيع العقد، وليس عندما نقرر إنهاءه. وأحد الاختبارات التي أرى أنها مفيدة جدًا للأنظمة المهمة هو:
إذا توقف هذا المزود بعد 90 يومًا، هل نستطيع الانتقال إلى مزود آخر؟
إذا لم نستطع الإجابة، فلدينا اعتماد غير مُدار.
MCP جيد… لكنه ليس الحل الكامل
Model Context Protocol أو MCP خطوة ممتازة نحو فصل بعض التكاملات عن النماذج. لكنه لا يجعل كل شيء قابلًا للنقل تلقائيًا. هو يساعد في طبقة الاتصال بالأدوات والبيانات. لكن ما زالت لدينا: المطالبات النصية. التنسيق. سلوك النموذج. التقييمات. حواجز الحماية. المراقبة. الضوابط الأمنية. الحوكمة. منطق الأعمال. لذلك فإن البنية المعيارية مهمة، لكن لا ينبغي أن نعطي أنفسنا انطباعًا خاطئًا بأن استخدام بروتوكول معياري أنهى مشكلة الاحتجاز لدى المورد. لم ينهها. هو فقط خفف جزءًا منها.
ماذا أريد أن أعرف عن كل نظام AI داخل المؤسسة؟
هنا أصل إلى النقطة التي أعتبرها أساس حوكمة الذكاء الاصطناعي. إذا سألت المؤسسة اليوم:
كم نظام AI لدينا؟
يجب أن توجد إجابة. إذا كانت الإجابة:
لا نعرف بالضبط.
فهذه أول مشكلة يجب حلها. نحتاج سجلًا لأنظمة الذكاء الاصطناعي. لكن ليس ملفًا يحتوي على اسم الأداة واسم المورد فقط. أريد أن أعرف عن كل نظام:
من مالك الأعمال؟
من المالك التقني؟
ما المورد؟
ما النموذج وإصداره؟
ما حالة الاستخدام؟
ما تصنيف البيانات؟
ما الأنظمة التي يصل إليها؟
ما واجهات API التي يستطيع استخدامها؟
هل يستطيع تنفيذ إجراءات؟
ما مستوى الاستقلالية؟
هل توجد بيانات شخصية؟
أين تعالج البيانات؟
هل يوجد إشراف بشري؟
ما مستوى المخاطر؟
متى كان آخر تقييم؟
ما الحوادث السابقة؟
كيف نوقف النظام؟
وما استراتيجية الخروج؟
لأن القاعدة بسيطة:
لا يمكنك حوكمة ما لا تستطيع رؤيته.
لا تجعل حوكمة AI مسؤولية الأمن السيبراني وحده
بحكم طبيعة AI، سيكون للأمن السيبراني دور كبير. لكن وضع المسؤولية كاملة على الأمن السيبراني خطأ. تتقاطع مخاطر AI مع: الأمن السيبراني. الخصوصية. الشؤون القانونية. الامتثال. المخاطر المؤسسية. حوكمة البيانات. المشتريات. IT. التدقيق الداخلي. الأعمال. وأحيانًا الموارد البشرية أو المالية أو الرعاية الصحية أو أي قطاع يعتمد على النظام. لذلك أنا أفضل نموذج المساءلة المشتركة مع ملكية واضحة. لا نريد لجنة كبيرة لا يملك فيها أحد القرار. نريد أن نعرف: من يوافق؟ من يرفض؟ من يقبل المخاطر؟ من يراقب؟ من يحقق؟ ومن يستطيع الضغط على زر الإيقاف؟
ونعم، يجب أن يوجد زر إيقاف حقيقي
أي نظام AI عالي المخاطر يجب أن تكون له آلية واضحة لتعطيله. ليس نظريًا. فعليًا. إذا بدأ الوكيل بتنفيذ عمليات خاطئة، لا أريد اجتماعًا لتحديد من يملك صلاحية إيقافه. إذا بدأ النموذج بإرسال بيانات إلى مكان غير صحيح، لا أريد أن نكتشف أن إيقاف التكامل يحتاج طلب تغيير لمدة ثلاثة أيام. مفتاح الإيقاف يجب أن يكون جزءًا من التصميم. ومن يملكه يجب أن يكون معروفًا. واستخدامه يجب أن يكون مسجلًا. وإعادة تشغيل النظام بعده يجب أن تتطلب تحققًا واضحًا.
العقد وحده لن يحمي المؤسسة
وجود عقد قوي مهم. لكن العقد ليس ضابطًا. ولا ينبغي أن نخلط بين:
نقل المخاطر
و
إدارة المخاطر.
قد تنقل جزءًا من الخسارة المالية إلى المورد من خلال بند تعويض تعاقدي. لكن ماذا عن السمعة؟ ماذا عن بيانات العميل؟ ماذا عن توقف العملية؟ ماذا عن قرار خاطئ أثر على شخص؟ ماذا عن التحقيق التنظيمي؟ وماذا لو لم يكن المورد قادرًا أصلًا على تغطية حجم الضرر؟ لذلك يجب أن تنظر عقود AI إلى ما هو أبعد من اتفاقية مستوى الخدمة والسعر. ملكية البيانات. استخدام البيانات. حقوق التدريب. تغييرات النموذج. حقوق التدقيق. الإبلاغ عن الحوادث. المعالجون الفرعيون. موقع استضافة البيانات. الاحتفاظ. الحذف. التعاون التنظيمي. قابلية النقل. الإنهاء. المساعدة على الخروج. هذه ليست بنودًا قانونية فقط. بالنسبة لي، هي جزء من بنية مخاطر AI.
النموذج الذي أراه مناسبًا للمؤسسات
بدل أن يدخل AI إلى المؤسسة من عشرات الأبواب، أرى أن أي استخدام مؤثر يجب أن يمر بدورة واضحة:
اكتشاف → تصنيف → تقييم → اعتماد → تشغيل → مراقبة → إعادة تقييم → إنهاء
ويجب ألا تكون الموافقة دائمة. إذا تغير: النموذج. المورد. حالة الاستخدام. نوع البيانات. الصلاحيات. درجة الاستقلالية. أو التكاملات. فقد تتغير المخاطر. وبالتالي نحتاج إلى إعادة تقييم. خصوصًا أن المورد قد يغير النموذج من جهته بينما لم تغير المؤسسة سطرًا واحدًا في تطبيقها.
في النهاية، السؤال ليس: هل AI آمن؟
هذا السؤال واسع جدًا ولا يفيدني كثيرًا. السؤال الأفضل هو:
هل هذا النموذج، مع هذه البيانات، ولهذا الاستخدام، وبهذه الصلاحيات، وتحت هذه الضوابط، مقبول المخاطر بالنسبة لمؤسستنا؟
هذه هي الطريقة التي أرى أننا يجب أن ننظر بها إلى مخاطر AI. لأن نفس النموذج قد يكون منخفض المخاطر في حالة استخدام، وعالي المخاطر جدًا في حالة استخدام أخرى.
الخلاصة
أنا لا أرى أن المشكلة في استخدام AI من طرف ثالث. بالعكس، من غير الواقعي أن تبني كل مؤسسة نماذجها وتقنياتها بنفسها. المشكلة تبدأ عندما نستعين بالتقنية ونفترض أننا استعنا معها بالمسؤولية. لم نفعل. المورد يملك النموذج. لكن أنت تملك قرار استخدامه. أنت تحدد البيانات التي سيصل إليها. أنت تحدد الأنظمة التي ستربطه بها. أنت تحدد الصلاحيات التي ستمنحه إياها. وأنت تحدد إلى أي مدى ستسمح له بالتأثير في العميل والموظف والقرار والعملية. ولهذا قبل أن أسأل:
أي نظام AI ينبغي أن نستخدم؟
أفضل أن أبدأ بـ:
ما الذي سنسمح لنظام AI بفعله؟
ثم:
ما البيانات التي سيطلع عليها؟
ما الأنظمة التي يمكنه الوصول إليها؟
ما القرارات التي يمكنه التأثير فيها؟
ما الإجراءات التي يمكنه تنفيذها؟
من يراقبه؟
من يستطيع إيقافه؟
كيف نحقق في أدائه أو حوادثه؟
كيف نستبدله؟
وأخيرًا:
من يملك المخاطر؟
إذا كانت الإجابة عن السؤال الأخير هي:
المورد.
فمن الأفضل أن نعيد تقييم الموضوع من البداية.
يمكنك إسناد التقنية إلى طرف خارجي.
يمكنك إسناد التشغيل إلى طرف خارجي.
يمكنك حتى إسناد جزء كبير من التطوير إلى طرف خارجي.
لكن لا يمكنك إسناد مسؤوليتك عن المخاطر التي أدخلتها إلى مؤسستك إلى طرف خارجي.
وهذه، بالنسبة لي، هي نقطة البداية الحقيقية في حوكمة AI.
فهد العنزي