تخطَّ إلى المحتوى
FormFlow

حكم من الدائرة التاسعة يضع وكيل الذكاء الاصطناعي في مقعد المستخدم

في 4 أغسطس 2026 ألغت الدائرة التاسعة أمرًا قضائيًا ضد وكيل Perplexity، معتبرةً أن المستخدم هو من «دخل» حواسيب Amazon. ما يحسمه حكم CFAA وما يتركه مفتوحًا.

تُرجم هذا المقال آليًا. اقرأ النص الأصلي بالإنجليزية

A dark plate titled 'Who accessed the site?' with the chain User to AI agent to Website, a bracket marking the user's machine, and a CFAA access bracket under Website.

في 4 أغسطس 2026 ألغت هيئة من الدائرة التاسعة أمرًا قضائيًا مؤقتًا كان يمنع وكيل Perplexity للذكاء الاصطناعي من التصرف على Amazon.com لحساب عملاء Amazon. واعتبرت الهيئة أن الجهة التي «دخلت» حواسيب Amazon هي المستخدم لا Perplexity. ويوضح تنبيه Cooley المؤرخ 6 أغسطس 2026 الحجج، وكذلك الحدّين المرتبطين بها.

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

ما قررته المحكمة فعلًا

كان Assistant، الوكيل داخل متصفح Comet من Perplexity، يلتقط صورًا لعرض المتصفح على جهاز المستخدم نفسه، ويرسلها إلى خوادم Perplexity، ويتلقى تعليمات التنقل في Amazon. ولم تفتح Perplexity نفسها اتصالًا بخوادم Amazon. وعلى هذا البنيان استنتجت الهيئة أن كلمة «whoever» في CFAA تعني شخصًا، فـ«الدخول» يعني دخول الشخص إلى النظام، والشخص هنا هو المستخدم الذي أصدر التعليم. وسقط ادعاء CDAFA في كاليفورنيا للسبب نفسه.

كانت محكمة الدرجة الأولى قد ذهبت إلى العكس في 9 مارس 2026، إذ رأت أن Amazon مرجّحة الكسب لأن دخول Perplexity لم يكن مأذونًا من Amazon بصرف النظر عما سمح به مستخدموها. وقد نقضت الدائرة التاسعة ذلك وأعادت القضية.

ما يتغير لصاحب موقع

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

  • تبقى شروط الخدمة هي الرافعة التي يسمّيها القرار نفسه.

  • الوكيل الذي يخاطب خوادمك مباشرة، دون تمرير عبر جهاز المستخدم، أقرب إلى الوقائع التي ميّزتها المحكمة.

  • التحكم الأكبر من شركة الذكاء الاصطناعي في وكيلها يشير إلى الاتجاه الآخر.

وبالنسبة لصاحب النموذج، هذا هو الجزء المهم. فدفاعات النموذج ليست نظريات قانونية، بل أشياء تحدث لحظة POST.

على ماذا يجب أن تستند ضوابط الوكلاء في النموذج

يقدم FormFlow تحدي Turnstile ومُصنِّف إزعاج لكل نموذج يُدرَّب من تصحيحات بشرية. وTurnstile تحدي مزوّد واحد، وهو يفشل مفتوحًا: حين يتعذر الوصول إلى المزوّد، لا يُحجب الإرسال على هذا الأساس. ويوازن مُصنِّف الإزعاج أدلة الطلب مقابل مُصنِّف شكّلته تصحيحات النموذج نفسه، ويمكن للمرجع المسبق للفريق أن يضع علامة على إرسال لكنه لا يستطيع الاعتراض عليه أبدًا.

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

ما لا يحسمه هذا

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

يقتصر الحكم على CFAA وCDAFA. فهو لا يجعل وكلاء الذكاء الاصطناعي قانونيين، ولا يبارك دخول الوكلاء عمومًا، ولا يحسم ادعاءات العقد أو الضرر، ولا يقول شيئًا عن robots.txt أو شروط الخدمة أو أي سياسة وصول أخرى قد يتبناها موقع.

ولا يحسم شيئًا عن ضوابط FormFlow، فهي خيارات هندسية لا قانونية. اقرأ المصدر الأساسي لا ملخصًا. أما عقد POST الذي يفرضه النموذج، فاقرأ مرجع API، ولمنشأ ذلك العقد راجع مدخل Changelog للإصدار v1.0.0.