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

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

ثم يقول الزبون: لم أطلب ذلك أبداً.

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

أصبح لهذا الفارق اسم الآن. يسميه الناس "اعرف وكيلك"، أو KYA .

لماذا KYC و KYB لا تجب عليه

KYC يجيب على سؤال واحد: هل هذا الشخص هو من يدعي أنه هو؟ KYB يجيب كلاهما على نفس السؤال حول شركة ما. ويفترض كلاهما أن الطرف الذي تحققت منه هو الطرف الذي يتصرف.

يُخالف أحد العوامل هذا الافتراض. ويترك ذلك أربعة أسئلة مفتوحة.

1. أي وكيل يقوم بالعمل؟ ليس أي عميل. أي برنامج، تديره أي شركة، على أي منصة.

2. من هو الوكيل؟ ما هو الشخص أو الشركة الموثوقة التي تقف وراءه؟

3. بأي إذن؟ ما الذي قيل لها أنه مسموح لها أن تفعله: كم، ومع من، وحتى متى.

4. من يتحمل المسؤولية؟ عندما تكون عملية الشراء خاطئة، من يتحمل الخسارة، وما هي الأدلة التي تحسم النزاع.

لم نبتكر هذا المصطلح. فقد وصفت شركتا Trulioo وPayOS إطار عمل "اعرف وكيلك" بالتعاون مع Worldpay في أغسطس 2025. (يفتح في علامة تبويب جديدة) وتصف ورقة مؤسسة OpenID حول هوية الوكيل بروتوكول KYAPay بأنه امتداد لـ KYC و KYB التحقق "للوكيل نفسه" (يفتح في علامة تبويب جديدة) . نشرت إكسبريان تعريفها الخاص (يفتح في علامة تبويب جديدة) في يونيو 2026. وحتى أكتوبر 2026، لم يكن هناك معيار متفق عليه موحد لهذا المصطلح. إنه توجيه وليس مواصفة.

ما أنجزته الصناعة بالفعل

تم شحن كمية كبيرة منذ أوائل عام 2025. كل قطعة تثبت شيئًا حقيقيًا وتترك شيئًا مفتوحًا.

• أعلنت ماستركارد عن خدمة الدفع عبر الوكلاء (29 أبريل 2025)، والتي تُقدّم رموز الوكلاء، مُشيرةً إلى أن البرنامج سيُلزم وكلاء الذكاء الاصطناعي الموثوق بهم بالتسجيل والتحقق (يفتح في علامة تبويب جديدة) قبل قيامهم بالدفع نيابةً عن مستخدميهم. يُثبت هذا الإجراء أن الوكيل معروف لدى الشبكة، ويضمن للمستهلكين التحكم في مشتريات الوكيل. لم يُوضّح الإعلان شكل هذا الإذن، أو الجهة التي يُمكنها الاطلاع عليه لاحقًا.

• وقّعت Cloudflare اتفاقيات وكلاء ومصادقة روبوتات الويب (28 أغسطس 2025). وتقوم (يفتح في علامة تبويب جديدة) منصة الوكلاء بتوقيع اتفاقياتها الخاصة.HTTP تُرسل هذه الطلبات (يفتح في علامة تبويب جديدة) إلى موقع الويب للتحقق من هوية المتصل. IETF تُصرّح المجموعة العاملة التي تعمل على توحيد هذا الأمر بوضوح بشأن حدودها: "إنّ التحقق من هوية المستخدم النهائي خارج نطاق هذا العمل" (يفتح في علامة تبويب جديدة) . وهي تجيب على السؤال الأول وتتوقف عند هذا الحد عمداً.

• بروتوكول مدفوعات وكلاء جوجل، AP2 (16 سبتمبر 2025). المحاولة الأكثر مباشرة للإجابة على السؤالين الثالث والرابع. يوقع المستخدم على تفويض، والذي تصفه جوجل بأنه "دليل قابل للتحقق على تعليمات المستخدم" (يفتح في علامة تبويب جديدة) : تفويض النية مع تحديد حدود للمهام المفوضة، وتفويض سلة التسوق لتحديد المنتجات والسعر بدقة. وهو دليل على الإذن. لم يوضح الإعلان الجهة التي تتحقق من هوية المستخدم الموقع.

• بروتوكول التجارة الآلية من OpenAI وStripe (29 سبتمبر 2025). تُصدر Stripe رمز دفع مشتركًا "مُخصصًا لتاجر مُحدد وإجمالي سلة مشتريات مُعين" (يفتح في علامة تبويب جديدة) . يُعد هذا الإذن محدودًا ويصعب إساءة استخدامه، إذ يغطي عملية شراء واحدة أكدها المشتري للتو، وليس تفويضًا دائمًا.

• بروتوكول الوكيل الموثوق من فيزا (14 أكتوبر 2025). تم تطويره باستخدام Cloudflare، ويتيح للوكلاء المعتمدين إرسال معلومات حول نواياهم، وبيانات تعريف المستهلك، ومعلومات الدفع (يفتح في علامة تبويب جديدة) إلى التاجر. يساعد ذلك التاجر على التمييز بين وكيل التسوق الحقيقي والروبوت، ومعرفة ما إذا كان المتسوق معروفًا لديه مسبقًا. المعلومات التي قدمها المتسوق للوكيل ليست من بين هذه المعلومات الثلاث.

• x402. معيار دفع لـ HTTP موقعهم الإلكتروني نفسه يعد بـ "عدم الحاجة إلى حسابات أو معلومات شخصية" (يفتح في علامة تبويب جديدة) . هذا خيار تصميم معاكس تمامًا: دفع بدون أي هوية. من الصعب التوفيق بينه وبين أي التزام بمعرفة العميل.

في الخفاء، يقوم مجتمع الهوية بعمل أبطأ.

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

• فرد​ IETF مسودة (يفتح في علامة تبويب جديدة) مقترحة لمعلمات OAuth التي تحدد اسم الوكيل في طلب الموافقة وفي الرمز المميز. انتهت صلاحيتها: إنها مجرد فكرة مسجلة، وليست معيارًا.

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

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

ما قاله المنظمون: ليس الكثير حتى الآن

بحثنا عن القواعد ووجدنا في الغالب النية.

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

• في سنغافورة، تعمل مجموعة صناعية تحت مظلة MAS نشرت المبادرة وثيقة "ضمانات التمويل الوكيل أثناء التشغيل" (يفتح في علامة تبويب جديدة) في 3 يوليو 2026. وتقترح الوثيقة التحقق من كل إجراء يقوم به الوكيل قبل تنفيذه، بدءًا من خطوة التحقق من هوية الوكيل وانتهاءً بسجل تدقيق يُضاف إليه البيانات فقط. وتؤكد الوثيقة نفسها (يفتح في علامة تبويب جديدة) أنها "لا تُشكل توجيهات تنظيمية أو متطلبات إشرافية".

• ال FSB تم التشاور في يونيو 2026 بشأن الممارسات السليمة لتبني الذكاء الاصطناعي بشكل مسؤول، ويقولون إنها "لا تهدف إلى وضع معيار دولي" (يفتح في علامة تبويب جديدة) .

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

ما الذي يبقى على حاله؟

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

لذا فإن أساس KYA عادي KYC و KYB الجديد يتربع في المقدمة:

• الربط. رابط دائم وقابل للتحقق بين هذا الوكيل وهذا الكيان المعتمد.

• النطاق. سجل لما سمح به الموكل، دقيق بما يكفي للمقارنة مع ما فعله الوكيل.

• الحضور. وسيلة لإعادة الجانب الإنساني عندما ترتفع المخاطر، لأن الإذن الدائم لا ينبغي أن يغطي كل شيء.

• سجل. دليل على من أو ما الذي قرر، تم الاحتفاظ به في ذلك الوقت، ولا يزال واضحاً بعد مرور عام.

ماذا نفعل الآن؟

إذا اشتريت أو امتلكت، فأنت تتحمل المخاطر. قرر هذه الأمور قبل أن يقررها عملاؤك نيابةً عنك.

• هل ستسمحون للوكلاء بالتصرف في حسابات العملاء على الإطلاق، وما هي الإجراءات التي سيقومون بها؟

• هل يمكنك اليوم التمييز بين جلسة وكيل وجلسة بشرية؟ إذا لم يكن الأمر كذلك، فهذه هي الفجوة الأولى.

• ما هو المقدار أو الإجراء الذي يجب على الإنسان تأكيده شخصياً؟

• عندما يعترض أحد العملاء على تصرفات أحد الوكلاء، ما هي الأدلة التي ستحتفظ بها، ومن يتحمل الخسارة بموجب شروطك؟

• اسأل كل مزود خدمة عن ما يثبته بروتوكول الوكيل الخاص به، وما يتركه لك.

إذا قمت بالبناء، فلا شيء هنا يحتاج إلى معيار جديد ليوجد.

1. تحقق من هوية العميل أولاً. لا يُسمح بوصول الوكلاء للعملاء أو الشركات غير الموثقة.

2. امنح الوكيل بيانات اعتماد خاصة به. لا تستخدم أبدًا كلمة مرور العميل أو جلسة العمل. أصدر رمزًا مميزًا منفصلاً وقابلاً للإلغاء حتى يمكن تمييز إجراءاته في سجلاتك الخاصة.

3. احمل معك مرجع العميل في كل إجراء. يجب أن يذكر كل دفع أو تسجيل دخول أو تغيير يقوم به الموظف اسم العميل الذي يمثله، وأن هذا الإجراء صادر عن موظف.

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

5. يتطلب الأمر تدخلاً بشرياً عند تجاوز حد معين. في حالة وجود مستلم جديد، أو مبلغ كبير، أو تغيير في بيانات الاتصال: اسأل الشخص المعني، وليس الموظف.

6. سجّل القرار عند اتخاذه. ما الذي طُلب، وما الذي سُمح به، ومن أو ما الذي اتخذ القرار.

ماذا تشاهد؟AP2 عندما تتلاقى متطلبات التفويض ورموز وكلاء شبكات البطاقات، IETF وثائق مصادقة روبوتات الويب، وعمل وزارة الخزانة البريطانية على قواعد الدفع، والنسخ النهائية من MAS و FSB أوراق.

ما هو موجود اليوم في Toden

بكل صراحة: Toden لا يوجد لديه وكيل للتحقق أو KYA المنتج اليوم. نحن لا نتحقق من الوكلاء، ولا نصدر أوراق اعتمادهم، ولا نصدق على تفويضاتهم. ما نقوم به اليوم يقتصر على المنتج والتنفيذ.

• تحقق من هوية المستخدم. يتم التحقق من هوية الأفراد والتحقق من هوية الشركات، ويتم تخزين كل منهما مقابل بياناتك الشخصية.externalUserIdلذا فإن العميل الذي تحققت منه هو نفس السجل الذي تقوم بفحصه ومراقبته.

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

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

• احتفظ بسجل لمن اتخذ القرار. يتم الاحتفاظ بكل تغيير في حالة التحقق مع مصدره: المراجع، أو نظامك الخلفي. API مفتاح أو سير عمل. تبقى القرارات السابقة مسجلة. توضح الرسوم البيانية للقرارات كيفية تسجيل القواعد.

• وثائق مصممة خصيصًا لوكلاء البرمجة. كل صفحة بصيغة Markdown، وllms.txtالفهرس، وعقود OpenAPI، وموجه التكامل، والوثائق MCP الخادم (يفتح في علامة تبويب جديدة) . يبحث هذا الخادم في المستندات ولا يقوم بتشغيل أي شيء API المكالمات. هناك مكالمة واحدة تعمل مع حسابك قيد التخطيط وليست متاحة بعد.

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

ما نعتقد أنه يجب بناؤه

هذا القسم يمثل وجهة نظرنا. وهو ليس إعلانًا عن منتج، أو خطة عمل، أو التزامًا.

نعتقد أن بنية الثقة تحتاج إلى ركيزة رابعة بجانبها KYC ، KYB وقرارات المخاطرة.

• يتم التحقق من هوية العميل دائمًا، ويمكن التحقق من الرابط. لذا، فإن بيانات اعتماد الوكيل التي لا يمكن تتبعها إلى شخص أو شركة موثقة لا قيمة لها تقريبًا.

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

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

• يُكتب السجل قبل وقوع الحدث، ولا يُعاد بناؤه بعده. أي وكيل، ولمن، وبموجب أي إذن، وبموجب ماذا قرر.

• تلتقي هوية الوكيل وهوية العميل. اليوم، بروتوكولات الوكيل و KYC يتم تسجيل البيانات مباشرةً في أنظمة مختلفة. والجهة التي تمتلك بالفعل عميلاً موثقاً هي المكان الطبيعي للانضمام إليهم.

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

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

هل تريد البدء بالجزء الموجود؟ افتح Toden قم بتحديد مساحة العمل (يفتح في علامة تبويب جديدة) أو توجيه وكيل البرمجة الخاص بك إلى المستندات (يفتح في علامة تبويب جديدة) .