۴ اوت ۲۰۲۶ سال، دادگاه تجدیدنظر ناحیه نهم ایالات متحده، دستور موقت را که از مارس به مرورگر عامل Perplexity Comet اجازه دسترسی به حسابهای کاربران در آمازون را نمیداد، لغو کرد. به طور رسمی، این یک دعوای دو شرکت درباره خریدها از طریق هوش مصنوعی است. در واقع، این اولین تصمیم تجدیدنظر است که به سوالی پاسخ میدهد که فراتر از تجارت عاملانه اهمیت دارد: چه کسی به طور خاص "دسترسی" به سرور دیگران دارد، زمانی که درخواست توسط اتوماسیون ارسال میشود. و پاسخ دادگاه به طور غیرمنتظرهای به جای حقوق، به معماری شبکه مربوط میشود.
چه اتفاقی افتاد: از شکایت تا لغو ممنوعیت
زمانبندی دعوا به این صورت است:
- نوامبر ۲۰۲۵ — آمازون شکایتی علیه Perplexity AI ارائه میدهد و به قانون فدرال تقلب و سوءاستفاده از کامپیوتر (CFAA) و معادل کالیفرنیایی آن اشاره میکند. ادعا: عامل Comet به حسابهای کاربران وارد میشود، کالاها را مشاهده میکند و خریدها را آغاز میکند، یعنی در منطقهای که با رمز عبور محافظت میشود، بدون مجوز خود پلتفرم کار میکند.
- پیشینه — به گفته آمازون، این شرکت حداقل پنج بار از نوامبر ۲۰۲۴ به Perplexity هشدار داده و در اوت ۲۰۲۵ مانع فنی ایجاد کرده است، در حالی که Perplexity در عرض ۲۴ ساعت یک بهروزرسانی منتشر کرده که این مانع را دور میزند. انتقاد جداگانه: عامل خود را به عنوان یک جلسه عادی Google Chrome پنهان کرده است.
- ۹ مارس ۲۰۲۶ — قاضی مکسین چسنی (ناحیه شمالی کالیفرنیا) دستور موقت را صادر میکند و دستور میدهد که دادههای به دست آمده از آمازون نابود شوند. فرمول او: دسترسی با اجازه کاربر آمازون انجام شده، اما بدون مجوز از طرف آمازون.
- ۴ اوت ۲۰۲۶ — ناحیه نهم (پرونده شماره ۲۶-۱۴۴۴) ممنوعیت را لغو میکند: آمازون به احتمال زیاد در مورد ادعاهای CFAA پیروز نخواهد شد.
آمازون اعلام کرد که با این تصمیم موافق نیست و به دعوا ادامه خواهد داد. Perplexity پاسخ داد که حق کاربران برای انتخاب هر هوش مصنوعی را دفاع خواهد کرد. در عین حال، پرونده به هیچ وجه حل نشده است: بررسی در دادگاه نخست ادامه دارد و آمازون میتواند درخواست تجدیدنظر کند یا به بالاتر برود.
حرکت کلیدی: عامل یک ابزار است، نه یک شخص
CFAA برای دسترسی به "کامپیوتر محافظت شده" بدون مجوز مجازات میکند. تمام دعوا به یک فعل کاهش یافته است: چه کسی عمل دسترسی را انجام داده است. آمازون میگفت — Perplexity، زیرا این عامل او بود که در پلتفرم عمل میکرد. Perplexity پاسخ میداد — کاربری که به عامل دستور داده است.
دادگاه تجدیدنظر به سمت دوم ایستاد و این را به وضوح بیان کرد: هرچقدر هم که عامل پیشرفته باشد، برای اهداف قانون «این یک ابزار است، نه یک شخص» — ابزار، نه یک شخص. وقتی کاربر به عامل دستور میدهد که کاری در Amazon.com انجام دهد، دسترسی به کامپیوترهای آمازون در واقع توسط کاربر انجام میشود.
این ادامه منطقی خط دادگاه عالی در پرونده Van Buren v. United States (۲۰۲۱) است که CFAA را محدود کرد: قانون به خاطر نفوذ به جایی که اصلاً دسترسی وجود ندارد، مجازات میکند، نه به خاطر استفاده از دسترسی قانونی "غیرمجاز". کاربر آمازون یک حساب دارد و حق ورود به آن را دارد. ابزاری که او با آن این کار را انجام میدهد، به خودی خود به عنوان یک موضوع هک تبدیل نمیشود.
چرا همه چیز به معماری ترافیک بستگی داشت
جالبترین بخش تصمیم برای عملیها — فنی است. دادگاه بررسی کرد که Comet Assistant چگونه به صورت فیزیکی کار میکند و همین موضوع نتیجه را تعیین کرد.
نحوه کار به این صورت است: عامل از صفحه مرورگر در دستگاه کاربر عکس میگیرد، آنها را به سرورهای Perplexity ارسال میکند و از آنجا دستورالعملهای ناوبری به کامپیوتر کاربر ارسال میشود که اقداماتی را انجام میدهد. سرورهای Perplexity به طور مستقیم با سرورهای آمازون ارتباط ندارند. تمام ترافیکی که آمازون در خود میبیند، از دستگاه و آدرس IP خود کاربر میآید.
از اینجا نتیجه دادگاه به دست میآید. اگر درخواست به صورت فیزیکی از کاربر ناشی شود، پس "دسترسی" به معنای CFAA توسط او انجام شده است.
این چگونه با Power Ventures متفاوت است
تا کنون، داستان کلاسیک درباره دسترسی شخص ثالث با رضایت کاربر، پرونده Facebook v. Power Ventures (۲۰۱۶) بود. در آنجا، دادگاه تصمیم گرفت که پلتفرم میتواند دسترسی را از سرویس شخص ثالث پس بگیرد، حتی اگر کاربران به طور داوطلبانه اطلاعات حساب خود را به او داده باشند. قاضی دادگاه نخست به همین پیشینه استناد کرد و آن را به عاملان هوش مصنوعی گسترش داد.
ناحیه نهم این پروندهها را بر اساس یک معیار تفکیک کرد — و دوباره بر اساس معماری. در Power Ventures، سیستمهای خود متهم به طور مستقیم پیامهایی به پلتفرم Facebook ارسال میکردند و دستگاه کاربر را دور میزدند. Perplexity چنین کانالی ندارد. توپولوژی متفاوت ترافیک — پاسخ متفاوتی به سوال "چه کسی دسترسی پیدا کرد" است.
معنای عملی این تفکیک را نمیتوان نادیده گرفت. این به این معنی است که طراحی سیستم — عامل مشتری در دستگاه کاربر یا سرویس سروری که از زیرساخت خود به پلتفرم میرود — دیگر یک انتخاب صرفاً مهندسی نیست و به یک استدلال حقوقی تبدیل شده است.
چه چیزی تصمیم انجام نداد
دادگاه خود سعی کرد حداکثر محدوده تأثیر را محدود کند و به وضوح بیان کرد که یک رژیم حقوقی جدید برای هوش مصنوعی عامل ایجاد نمیکند. آنچه در حاشیه باقی ماند:
- نقض توافقنامه کاربری. ادعاهای ناشی از قرارداد، عمل غیرقانونی و قوانین پلتفرم توسط این تصمیم بسته نمیشود — آنها میتوانند به طور جداگانه مطرح شوند.
- شکایات علیه خود کاربران. اگر دسترسی توسط کاربر انجام شود، پلتفرم میتواند او را به عنوان هدف ادعاهای خود انتخاب کند.
- معماریهای سروری. نتیجهگیری تحت یک طرح خاص انجام شده است. اسکرپر ابری یا عامل SaaS که از زیرساخت خود به پلتفرم میرود، به طور خودکار تحت این منطق قرار نمیگیرد.
- مسدودسازیهای فنی. هیچ کلمهای در این تصمیم آمازون را از شناسایی و قطع اتوماسیون منع نمیکند. حق مسدود کردن هیچکجا ناپدید نشده است — امکان توجیه مسدودسازی با ماده کیفری از بین رفته است.
این، به هر حال، تغییر در تصویر معمولی است: قبلاً ریسک حقوقی بر عهده کسی بود که اتوماسیون میکند و حفاظت فنی به عنوان خط دوم در نظر گرفته میشد. اکنون برای پلتفرمها، حفاظت فنی به خط اول تبدیل شده است.
این چه تغییری در عمل ایجاد میکند
برای همه کسانی که دادهها را جمعآوری میکنند، حسابها را اتوماسیون میکنند یا عاملان میسازند، سه نتیجه عملی از این تصمیم به دست میآید.
۱. نقطه خروج ترافیک وزن حقوقی پیدا کرد
قبلاً انتخاب بین "همه چیز را از طریق مرکز داده خود میگذرانیم" و "از آدرسهایی که از آدرسهای کاربری قابل تشخیص نیستند کار میکنیم" یک سوال درباره قابلیت عبور و هزینه بود. اکنون این همچنین سوالی است درباره اینکه درخواست به چه کسی مربوط میشود. معماری که در آن درخواست به پلتفرم از سمت کاربر میآید، در دادگاه قابل دفاعتر است — و به طور همزمان، این معماری به طور تاریخی بهتر از فیلترهای ضد ربات عبور میکند. این یک مورد نادر است که انگیزههای حقوقی و فنی همزمان همراستا شده و به یک سمت اشاره میکنند: به پروکسیهای مسکونی و نقاط خروج کاربری به جای زیرشبکههای سروری. برای وظایف خنثی مانند نظارت بر قیمتهای عمومی یا بررسی نتایج در مناطق، هنوز هم پروکسیهای مرکز داده کافی است — آنجا نه منطقه ورود وجود دارد و نه دعوایی درباره حساب کسی.
۲. CFAA تضعیف شد — قرارداد و شناسایی تقویت شدند
نباید تصمیم را به عنوان "حالا میتوانیم" بخوانید. سنگینترین چماق — ماده فدرال با پتانسیل کیفری حذف شده است. توافقنامه کاربری، مسدودسازی حساب، شکایت مدنی و، مهمتر از همه، مجموعه ضد ربات باقی ماندهاند. پلتفرمها، با از دست دادن بخشی از اهرم حقوقی، این را با شناسایی جبران خواهند کرد: اثر انگشتگذاری، تحلیل رفتاری و عاملان امضا شده. درباره اینکه چگونه صنعت سعی میکند "رباتهای خوب" را با استفاده از وسایل فنی قانونی کند، ما در مقالهای درباره Web Bot Auth و عاملان امضا شده بررسی کردهایم.
۳. ریسک به سمت کاربر نهایی منتقل شد
طرف دیگر پیروزی Perplexity: اگر کاربر عمل کند، پس کاربر نیز پاسخگو است. برای سرویسهایی که به مشتریان اتوماسیون به عنوان یک محصول ارائه میدهند، این بهانهای است برای اینکه به طور صادقانه در مستندات بیان کنند که به نام چه کسی و با چه IP اقداماتی انجام میشود و چه قوانینی از پلتفرمها تحت تأثیر قرار میگیرد.
اکنون چه کار باید کرد
- توپولوژی دسترسی خود را توصیف کنید. به یک سوال پاسخ دهید: کدام IP در لاگهای پلتفرم هدف دیده میشود — سروری شما یا کاربری. این به موقعیت حقوقی و پروفایل شناسایی بستگی دارد.
- عمومی و ورود را جدا کنید. جمعآوری صفحات باز و اقدام در داخل حساب دیگران — داستانهای اصولاً متفاوتی از نظر ریسک هستند. نباید آنها را در یک خط لوله ترکیب کرد.
- پس از ممنوعیت مستقیم، به طور تهاجمی ماسک نزنید. در این پرونده، دور زدن مانع ایجاد شده و تغییر مشتری به Chrome به آمازون قویترین شواهد را داد. ادعای CFAA از بین رفت، اما سایر دلایل همچنان زندهاند.
- نوع خروج را بر اساس وظیفه انتخاب کنید. جنبه عملی — چگونه یک عامل را در Playwright یا MCP راهاندازی کنیم و ترافیک آن را به درستی بپیچیم — ما به تفصیل در راهنمای پروکسی برای عاملان هوش مصنوعی بررسی کردهایم.
نتیجهگیری
ناحیه نهم اتوماسیون را قانونی نکرد و به عاملان اجازه دسترسی به هر جایی را نداد. او کار مهمتری انجام داد: مفهوم "دسترسی" را به جایی که درخواست به صورت فیزیکی میآید، مرتبط کرد. ابزاری که بر روی دستگاه کاربر کار میکند، دسترسی ایجاد نمیکند — این انسان است که دسترسی را ایجاد میکند. زیرساختی که از خود به پلتفرم میرود، در معرض ریسکهای قدیمی باقی میماند.
برای بازار، این به معنای تغییر مرکز ثقل است. دعوای حقوقی درباره اینکه "آیا میتوانیم" به طور فزایندهای به سوال مهندسی "آدرس چه کسی در لاگ است" برخورد میکند. و خود مبارزه برای دسترسی به طور کامل به جایی که همیشه بوده است، منتقل میشود — به شناسایی ضد ربات، اثر انگشتگذاری و کیفیت نقاط خروج.