حل هوية الذكاء الاصطناعي القائم على الوكالة

لأن إجراءات «اعرف عميلك» (KYC) و«التحقق من الهوية» (IDV) التقليدية لا تجيب بشكل جيد إلا على سؤال واحد: هل تم التحقق من هوية هذا الشخص عند التسجيل؟ وهي لا تجيب بشكل موثوق عن هوية أو طبيعة الجهة الفاعلة في الوقت الحالي، أو ما إذا كانت تلك الجهة لا تزال خاضعة لسيطرة العميل، أو ما إذا كان السلوك الحالي يتوافق مع الاستخدام المشروع. وتصبح هذه الفجوة خطيرة عندما تعمل عوامل الذكاء الاصطناعي، والأتمتة المبرمجة، والغش المدعوم بشريًّا، جميعها خلف حساب تم التحقق منه مسبقًا. وبالنسبة لنائب رئيس أمن المنتجات أو رئيس قسم الهوية، فإن المشكلة الحقيقية لا تكمن في استبدال نظام "اعرف عميلك" (KYC)، بل في توسيع نطاقه ليصبح نموذجًا مستمرًا لـ "اعرف الفاعل" (Know Your Actor). أنت بحاجة إلى ضوابط تصنف نوع الفاعل في الوقت الفعلي، وتكتشف متى يتحول السلوك من قيادة بشرية إلى آلية، وتميّز بين الأتمتة المفوضة ونشاط الروبوتات العدائية، وتطبق سياسات مختلفة عند تسجيل الدخول، وتغييرات الحساب، والمدفوعات، وعمليات السحب، واستعادة الحساب. تكمن المشكلة في أن الاحتيال يحدث الآن بعد عملية التسجيل، وليس فقط أثناءها.

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

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

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

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

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