المشكلة التي لا يتحدث عنها أحد تقريبًا مع وكلاء الذكاء الاصطناعي للمؤسسات
يسأل المدير المالي وكيل ذكاء اصطناعي: «كم أنفقنا على الرواتب في الربع الماضي؟»
يستدعي الوكيل واجهة الرواتب. تعيد الواجهة راتب كل موظف ومكافأته ورقمه الشخصي. يلخص الوكيل ذلك في إجمالٍ واضح.
حتى هنا الأمور جيدة — يحق للمدير المالي رؤية هذه البيانات.
الآن يطرح متدربٌ السؤال نفسه على نفس الوكيل. يستدعي الوكيل نفس الواجهة. تعيد الواجهة نفس الحمولة. يجيب الوكيل.
هذا هو نمط الفشل الصامت لأغلب نشرات «وكيل الذكاء الاصطناعي المؤسسي» في الإنتاج اليوم.
لماذا لا يكفي التحكم بالأدوار على مستوى نقطة النهاية
تؤمّن معظم منصات التكامل — بما فيها منصتنا، حتى وقت قريب — الوصول إلى واجهات البرمجة على مستوى نقطة النهاية. إما أن تستطيع استدعاء GET /payroll/employees أو لا. نجح هذا النموذج عندما بشرٌ واجهات تُرشّح النتائج على العميل، وعندما كانت الوحيدة التي تستدعي الخدمات الخلفية الموثوقة.
تكسر الوكلاء هذا النموذج بطريقتين:
- الوكلاء مستدعون عامون. لا يعرفون أي حقول يجب إخفاؤها. يلخصون كل ما يستلمونه.
- الوكلاء يعملون نيابة عن مستخدمين كثيرين. قد يخدم ملف وكيل واحد الرئيس التنفيذي وعامل المستودع. لا يميّز التحكم على مستوى نقطة النهاية بينهما بعد تفويض الطلب.
النتيجة: تصبح الوكلاء مشكلة «النائب المرتبك» على نطاق صناعي. مستخدم بلا وصول مباشر لقاعدة البيانات يمكنه استخراج أي بيانات يصل إليها الوكيل — بسؤال مناسب.
أين يتقصّر التحكم بالأدوار في النظام المصدر
الإجابة الشائعة: «دع النظام المصدر يتولى الأمر». تمرير هوية المستخدم لنظام الرواتب. والسماح له بالترشيح.
ينجح ذلك — عندما يدعم النظام المصدر ذلك. في الواقع:
- الأنظمة القديمة غالبًا حساب خدمة واحد بصلاحية كاملة. لا تفويض لكل مستخدم.
- واجهات SaaS لجهات خارجية غالبًا بلا أذونات على مستوى الصفوف. إما نطاق مسؤول أو لا شيء.
- واجهات داخلية مخصّصة بُنيت قبل وكلاء الذكاء الاصطناعي. لم يُضف
filter_by_user. - التجميعات تتسرّب. حتى مع ترشيح الصفوف، تُحسب المجاميع والمتوسطات غالبًا على المجموعة كاملة.
بالنسبة لمسؤول أمن المعلومات، سطح التعرض للبيانات يُعرَّف الآن بأضعف موصّل في صندوق أدوات الوكيل.
الدفاع المعمّق: ترشيح الاستجابة الموجّه بالسياسات
أضفنا طبقة جديدة إلى منصة التكامل Copyl: DataAccessPolicy. تقع بين استجابة النظام المصدر والوكيل، وتطبّق قواعد تصريحية على ما يُعاد.
للنموذج ثلاث أفكار أساسية:
1. تُربَط السياسات بإجراءات التكامل، لا بالوكلاء.
لنقطة رواتب واحدة سياسة واحدة. كل وكيل — كل مستخدم — يمر عبر نفس المُقيّم. لا يمكن لوكيل مُعدّ بشكل خاطئ تجاوز القاعدة.
2. تطابق القواعد سياق الموضوع، لا نقطة النهاية.
يرى المُقيّم الموضوع كاملًا: هوية المستخدم، الأدوار، الادعاءات، ملف الوكيل، المؤسسة. يمكن أن تقول قاعدة «إذا احتوت دور المستخدم CEO، اسمح بكل الصفوف» أو «إذا كان المستخدم موظفًا، أعد فقط الصفوف حيث employeeId يطابق معرفه.»
3. الدفع لأسفل عند الإمكان، والترشيح اللاحق كاحتياط.
إذا دعمت واجهة المصدر الترشيح، تعيد السياسة صياغة الطلب — ?employeeId=42 — بحيث لا تغادر البيانات الحساسة النظام المصدر. بلا دفع لأسفل، يُرشَّح على الخادم قبل أن يرى الوكيل.
هذه النقطة مهمة للامتثال. الترشيح وقت الاستعلام أكثر أمانًا فعليًا من الترشيح لاحقًا. الترشيح اللاحق دفاع معمّق، وليس بديلاً عن ضوابط المصدر.
ماذا يعني هذا لفريق الأمن والامتثال
ثلاث خصائص تجعل الأمر قابلاً للحوكمة:
قابل للتدقيق. كل تقييم يسجّل: أي سياسة، أي قاعدة، كم صفًا دخل وخرج، كم حقلًا وُسِم. يمكن الإجابة «من رأى بيانات الرواتب يوم الثلاثاء وماذا وُسِم؟» باستعلام SQL.
مُصدَّر الإصدارات. مسودة ← منشور ← مؤرشف. كل تغيير إصدار جديد. مقارنة، استعادة، إثبات ما كان نشطًا في تاريخ.
قابل للاختبار قبل النشر. تشغيل جاف — يُقيَّم المُرشّح ويُسجَّل دون تعديل الاستجابة. التحقق من حركة مرور حقيقية لأسابيع. النشر يتطلب اختبارًا ناجحًا أو تجاوزًا صريحًا.
للقطاعات الخاضعة للتنظيم (الخدمات المالية، الصحة، القطاع العام تحت NIS2/DORA في أوروبا) يتحوّل «الثقة بالوكيل» إلى «إثبات الوكيل».
ما لا يحله
حدود صريحة:
- التفويض في النظام المصدر ما زال أفضل عند توفره. استخدمه أولًا. ترشيح السياسة للحالات التي لا يمكن فيها ذلك.
- التجميعات دقيقة. ترشيح صفوف مع راتب موظف واحد وحقل
total: 4,200,000محسوب على الجميع يتسرّب. يكتشف نموذجنا حقول التجميع وإما يخطئ، أو يزيلها، أو يتطلب موافقة صريحة — يتطلب تفكيرًا لكل نقطة نهاية. - إخفاء الحقول ليس تشفيرًا. الأرقام الشخصية المُجزأة ما زالت بيانات شخصية. الإخفاء يقلل الأثر؛ لا يلغي الالتزام.
- السياسات بجودة قواعدها. مطابقة خاطئة للموضوع تمنح أكثر أو أقل من اللازم. لذلك نطلب تجارب تشغيل ورؤية تدقيق.
ماذا يعني ذلك عمليًا
إذا شغّلتم وكلاء ذكاء اصطناعي ضد أنظمة بلا تحكم أدوار على مستوى الصفوف — أغلب أنظمة تخطيط موارد المؤسسات القديمة، الرواتب، واجهات مبنية قبل 2024 — فلديكم تعرّض لا يغلقه التحكم على مستوى نقطة النهاية.
الحل هيكلي، وليس خدعة في الموجّه. قول «اعرض فقط بيانات هذا المستخدم» في موجّه النظام يصمد حتى كسر الحماية التالي. فرضه في طبقة التكامل بسياسة قابلة للإصدارات والتدقيق شيء يمكن لمسؤول أمن المعلومات المصادقة عليه.
نطرح DataAccessPolicy عبر وكلاء سوق Copyl، بدءًا من الرواتب والموارد البشرية والتمويل. إذا عملتم في بيئة خاضعة للتنظيم وترغبون بمناقشة مكان التعرض في بنيتكم، تواصلوا معنا.
Copyl منصة لبناء ونشر وحوكمة وكلاء الذكاء الاصطناعي للمؤسسات. منصة التكامل لدينا (CIP) تربط الوكلاء بأنظمة الأعمال مع تطبيق السياسات من طرف إلى طرف، وتسجيل التدقيق، ومراقبة الإصدارات.