وكلاء الذكاء الاصطناعي يزورون موقعك قانونياً. ماذا الآن؟

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

إذا كنت تدير موقعاً أو متجراً إلكترونياً أو واجهة برمجية، فهذا الحكم يغيّر الأداة التي تلجأ إليها للدفاع عن بنيتك التحتية — لا قدرتك على الدفاع عنها.

ما الذي حدث فعلياً

التسلسل الزمني قصير ويستحق الدقة، لأن كثيراً من التغطيات خلطت تفاصيله:

استندت دعوى أمازون الأساسية إلى قانون الاحتيال وإساءة استخدام الحاسوب (CFAA) — وهو قانون مكافحة الاختراق الصادر عام 1986. وكانت حجتها أن Comet تنكّر في هيئة متصفح Chrome، وتجاوز أنظمة كشف الروبوتات، وسجّل الدخول إلى حسابات عملاء محمية بكلمات مرور، وبالتالي وصل إلى حواسيب أمازون "دون تصريح" بعد أن ألغى الإنذار القانوني أي إذن سابق.

لم تقتنع هيئة الاستئناف، ولسبب تقني لا سياسي. فالسؤال الذي يطرحه القانون هو: من الذي وصل إلى الحاسوب؟ والجواب، بحسب البنية المعمارية لـ Comet، هو: المستخدم.

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

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

ما الذي لم تقرره المحكمة

هذا هو الجزء الذي تتجاهله معظم الملخصات، وهو الأهم عملياً.

الحكم يتعلق بقانون CFAA تحديداً، في مرحلة الأمر القضائي المؤقت، وعلى بنية معمارية بعينها تعمل من جهة العميل. ولم يقرر الحكم أن:

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

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

فئة لم يُصمَّم الويب لها

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

فكّر في العواقب العملية للخطأ في كلا الاتجاهين. إن حظرت الوكلاء المفوَّضين من المستخدمين بشكل شامل فأنت تحظر عملاءك الذين يدفعون، وهم يتعاملون مع متجرك عبر مساعد ذكي أكثر فأكثر. وإن سمحت بكل شيء فقدت القدرة على التمييز بين وكيل تسوّق تابع لعميل وأسطول تجريف أسعار تابع لمنافس — وكلاهما يبدو الآن كجلسة Chrome حقيقية من عنوان IP سكني.

تصفية الزيارات بناءً على سلسلة User-Agent انتهت كوسيلة تحكم. فتنكّر Comet المزعوم في هيئة Chrome هو بالضبط نموذج الفشل: أي عميل يعرض صفحتك محلياً يمكنه تقديم أي هوية يشاء، والحكم لا يعطيه أي سبب قانوني للامتناع.

اختر موقفك ثم ابنه

هناك ثلاثة مواقف متماسكة. اختر واحداً بشكل واعٍ لكل سطح من أسطح منتجك — فالجواب الصحيح لكتالوجك العام نادراً ما يكون الجواب الصحيح لعملية الدفع المرتبطة بحساب.

1. الترحيب بهم. تعامل مع زيارات الوكلاء كقناة توزيع. وهذا هو الخيار الصائب لأسطح المحتوى والكتالوج والتوثيق حيث يكون الاكتشاف هو الهدف كله. ويعني ذلك نشر ملف llms.txt، وتوفير بيانات منظمة نظيفة، وإبقاء المحتوى الحيوي خارج مسارات العرض المعتمدة على JavaScript وحدها، والتفكير في واجهة MCP تتيح للوكلاء الاستعلام منك بشكل صحيح بدلاً من تجريف لقطات الشاشة.

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

3. حظرهم. موقف مشروع ولم يغيّره الحكم — لكن عليك أن تدرك أن أداة التنفيذ لديك بعد قضية أمازون ضد Perplexity هي العقد والهندسة، لا القانون الجنائي الفيدرالي. اذكر ذلك صراحة في شروطك، وتوقّع خسارة تلك الزيارات.

هندسة الطريق الوسط

الأساس التقني الذي يجعل موقف التنظيم قابلاً للتطبيق هو الهوية المشفّرة للوكيل. فمعيار Web Bot Auth، المبني على توقيعات رسائل HTTP (المعيار RFC 9421)، يتيح للوكيل حسن السلوك أن يوقّع طلباته بمفتاح يمكنك التحقق منه عبر دليل منشور. والزيارات غير الموقّعة ليست معادية بالضرورة، بل هي ببساطة غير موثّقة، وتنتمي إلى خانة مختلفة بحدود مختلفة.

التصنيف المطلوب ثلاثي لا ثنائي:

// middleware.ts — صنّف قبل أن تقرر
import { NextResponse, type NextRequest } from 'next/server'
import { verifyBotSignature } from '@/lib/agent-identity'
 
type Visitor = 'verified-agent' | 'unattested' | 'session-user'
 
export async function middleware(req: NextRequest) {
  const signature = req.headers.get('signature')
  const hasSession = Boolean(req.cookies.get('session'))
 
  let visitor: Visitor = 'unattested'
  let agentId: string | null = null
 
  if (signature) {
    const result = await verifyBotSignature(req)
    if (result.valid) {
      visitor = 'verified-agent'
      agentId = result.keyId
    }
  } else if (hasSession) {
    visitor = 'session-user'
  }
 
  const res = NextResponse.next()
  res.headers.set('x-visitor-class', visitor)
  if (agentId) res.headers.set('x-agent-id', agentId)
  return res
}
 
export const config = { matcher: ['/api/:path*', '/products/:path*'] }

وتنبثق من هذا التصنيف ثلاث قواعد، وفيها يكمن العمل الحقيقي:

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

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

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

لماذا يهمّ هذا في منطقة الشرق الأوسط وشمال إفريقيا

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

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

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

ما ينبغي فعله هذا الأسبوع

• احسب نسبة الزيارات الآلية لديك اليوم، وكم منها ستحظره قواعدك الحالية.
• حدّد موقفك لكل سطح: المحتوى العام، القراءة الموثّقة، الكتابة المعاملاتية.
• راجع شروط الخدمة بحثاً عن فئة الوكيل المفوَّض من المستخدم. معظم الشروط لا تتضمنها.
• انقل تحديد المعدل من عنوان IP إلى الهوية حيثما أمكن.
• انشر بيانات منظمة وملف llms.txt إن كنت ترغب في زيارات الاكتشاف.

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

للاطلاع على تفاصيل آليات الهوية والتحقق، راجع دليلنا حول هندسة زيارات وكلاء الذكاء الاصطناعي بمعيار Web Bot Auth ومعيار WebMCP للمتصفحات.

تحتاج مساعدة في تحديد سياسة الوكلاء لمنصتك؟ تعمل نقطة مع فرق التجارة الإلكترونية وSaaS في تونس والخليج على بناء بنية جاهزة للوكلاء، من البيانات المنظمة وواجهات MCP إلى تحديد المعدل بالهوية الموقّعة.