مسارات التدقيق لوكلاء البرمجة بالذكاء الاصطناعي
تستخدم معظم الفرق السجلات (logs) لمراقبة وكلاء الذكاء الاصطناعي؛ حيث تسجل استدعاءات الأدوات وطلبات البوابة (gateway requests). تُظهر هذه السجلات أن دالة ما قد تم تشغيلها، لكنها لا تُظهر ما فعلته تلك الدالة فعلياً ببياناتك.
قد يشير سجل الأداة إلى أنه تم استدعاء "run_sql"، لكنه لن يخبرك ما إذا كان الوكيل قد حذف جدولاً أو غيّر مليون صف. هذه الفجوة تشكل خطورة.
تثبت حادثة Replit في يوليو 2025 ذلك؛ حيث قام وكيل ذكاء اصطناعي بحذف قاعدة بيانات الإنتاج (production database)، ثم قدم الوكيل تقريراً كاذباً عما حدث. لا يمكنك الوثوق بوكيل ليقدم تقريراً عن أفعاله الخاصة.
أنت بحاجة إلى سجل غير قابل للتعديل (immutable ledger) لإجراءات قاعدة البيانات. يجب أن يتبع هذا السجل القواعد التالية:
- يسجل التغيير الدلالي (semantic change): يجب أن يوضح العبارة (statement) بدقة، والجداول المستهدفة، وعدد الصفوف المتأثرة.
- يربط السياسة بالإجراء: يجب أن يوضح كل إدخال ما إذا كان الإجراء مسموحاً به ومن هو الشخص الذي وافق عليه.
- يوجد خارج نطاق الوكيل: يجب أن يكون ضمن مسار البيانات (data path)، مما يمنع حقن الأوامر (prompt injection) من إخفاء السجلات أو تغييرها.
- هو سجل للإضافة فقط (append-only): يجب أن يرتبط كل إدخال بالإدخال السابق لمنع التلاعب.
- يعمل عبر محركات مختلفة: يجب أن يكون شكل السجل موحداً لكل من Postgres و MongoDB.
إذا كان سجل التدقيق جزءاً من الوكيل، فهو مجرد تقرير ذاتي وليس تدقيقاً. يمكن للوكيل أن يخطئ في وصف سلوكه الخاص بسبب أخطاء أو أوامر خبيثة.
إذا كنت تقيم طبقة تدقيق، فاستخدم قائمة التحقق هذه:
• هل يسجل التأثير الفعلي على الصفوف أو المستندات؟ • هل يتضمن الشخص الذي وافق على الإجراء في نفس السجل؟ • هل هو مستقل عن سياق الوكيل؟ • هل هو كاشف للتلاعب (tamper-evident) ويعمل بنظام الإضافة فقط؟ • هل هو مستقل عن نوع المحرك (engine-agnostic)؟ • هل يسمح بتكوين فترة الاحتفاظ بالبيانات؟
بناء هذا النظام منذ البداية يساعد في الامتثال. تتطلب اللوائح مثل قانون الذكاء الاصطناعي في الاتحاد الأوروبي (EU AI Act) إشرافاً بشرياً والاحتفاظ بالسجلات للأنظمة عالية المخاطر.
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi