فجوة المساءلة في الذكاء الاصطناعي المستقل: 

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

وهذه الوكالة تغيِّر كل ما يتعلق بالهوية وإدارة الوصول والمساءلة.
فهذه الأنظمة لا تكتفي بتنفيذ التعليمات، بل تقرِّر الإجراءات التي ينبغي اتخاذها وتفوِّض الصلاحيات وتعمل باستمرار بدلًا من العمل فقط عند تلقي أمر. كما تشغِّل الأدوات وواجهات برمجة التطبيقات (APIs) والأنظمة بصورة مستقلة، وغالبًا ما تعمل نيابةً عن المستخدمين أو الفِرق أو حتى الأجهزة الأخرى. وبذلك، فإنها تفرض قدرًا من الغموض فيما يتعلق بالنية والصلاحيات والمسؤولية.

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

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

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

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

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

1. أن الهويات تمثِّل مستخدمين بشرًا أو أجهزة ثابتة.
2. أن الوصول يعتمد على الجلسات ويتم منحه وفق دورة حياة دورية.
3. أن المصادقة تفتح الجلسة، بينما يكون التفويض واسع النطاق إلى حد كبير، إذ يتم منح صلاحيات الوصول استنادًا إلى سمات عامة، مثل دور المستخدم أو القسم الذي ينتمي إليه.

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

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

وعندما تطبِّق المؤسسات أنماط إدارة الهوية والوصول (IAM) المصممة للمستخدمين على الوكلاء، تظهر أربع مشكلات جوهرية:

• صلاحيات مفرطة من دون رؤية واضحة: تتراكم لدى الوكلاء صلاحيات وصول دائمة؛ لأن سحب الأذونات وإعادة الموافقة عليها يبطئ وتيرة الابتكار، وغالبًا ما تبقى هذه الصلاحيات سارية من دون انتهاء.
• تفويض غير مرئي:
  يعيد العديد من الوكلاء استخدام رموز وصول المستخدمين بدلًا من منحهم صلاحيات مفوضة. ويؤدي هذا الأسلوب إلى طمس الفصل المطلوب في سجلات التدقيق، وتحميل المسؤولية لأفراد لم يوافقوا أصلًا على تنفيذ الإجراء.
• غياب فرض السياسات عند نقطة التنفيذ: قد تكون السياسات موجودة، لكن الإجراءات الفعلية، مثل استدعاءات واجهات برمجة التطبيقات (APIs) أو الوصول إلى البيانات أو تغييرات التهيئة، غالبًا ما يتم تنفيذها دون ضوابط في الوقت الفعلي.
• انعدام المساءلة عند وقوع المشكلات: بعد أي حادثة، لا تتمكن الفِرق من إعادة بناء ما حدث بصورة موثوق بها، أو معرفة سبب حدوثه، أو تحديد الجهة التي منحت الصلاحية لتنفيذه.

ولا تمثل هذه المشكلة نقصًا في الأدوات، بل فجوة في الحوكمة ينبغي معالجتها.

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

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

ويتطلب الذكاء الاصطناعي الوكيل الانتقال من التحكم في الوصول إلى التحكم في الصلاحيات. ويعني ذلك ما يلي:

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

ولا يتعلق الأمر بإبطاء الذكاء الاصطناعي، بل بجعل الاستقلالية أكثر أمانًا. ورغم أن المصادقة تظل مطلبًا أساسيًا لأي نظام، فإن التفويض يجب أن يصبح عنصرًا أساسيًا في نظام إدارة الوصول. وتترتب على ذلك آثار مهمة بالنسبة إلى المؤسسات التي تنفِّذ برامج إدارة الهوية والوصول (IAM). 

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

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

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

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

يتولى IBM Verify إدارة هوية المستخدم والوكيل، وتحديد ما يُسمح للوكيل بتنفيذه، والظروف التي يُسمح فيها للمستخدم والوكيل بتنفيذ هذه الإجراءات. 

أما HashiCorp Vault، فيوفر تخزينًا آمنًا للأسرار وإدارتها ويُنشئ بيانات اعتماد ديناميكية عند الطلب ويفرض مدة صلاحيتها (TTL) وتجديدها وإلغاءها، كما يوفر سياسات مركزية وسجلات تدقيق. وبذلك، لا يحتاج الوكلاء إلى بيانات اعتماد دائمة مضمَّنة داخل التعليمات البرمجية أو مهام سير العمل.

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

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

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

وفي المقابل، يتحرك المهاجمون بوتيرة أسرع من المدافعين، مستهدفين وكلاء الذكاء الاصطناعي تحديدًا؛ لأنهم غالبًا ما يعملون بصلاحيات متراكمة وتحت مستوى محدود من الرقابة.

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

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