Perplexity ganó a Amazon por el lugar donde se ejecuta su código (2026)

Surya Pratap
By Surya Pratap

9 de agosto de 2026

10 min read

AI & Technology
Desglose del fallo del Noveno Circuito sobre Perplexity: a la izquierda, la arquitectura del lado del cliente que decidió el caso; a la derecha, las reclamaciones que siguen en pie

El 4 de agosto, un tribunal del Noveno Circuito anuló por unanimidad la medida cautelar que mantenía el navegador y asistente de compras Comet de Perplexity fuera de Amazon.com. La conclusión: según la Computer Fraud and Abuse Act, un agente de IA es una herramienta, no una persona. Cuando un usuario dirige un agente a un sitio web, quien accede es el usuario.

Esta semana se está leyendo como luz verde para el comercio agéntico. No lo es, y la distancia entre lo que dijo el tribunal y lo que la gente cree que dijo es donde los fundadores van a salir perjudicados. Lo más útil de la sentencia es más estrecho y más accionable: el hecho que decidió el caso fue de arquitectura. Perplexity ganó, en parte, por cómo construyó Comet.

El hecho que lo decidió

Comet no funciona como la mayoría imagina que funciona un agente de compras con IA. Los servidores de Perplexity nunca hablan con los servidores de Amazon. El asistente hace una captura de la página en el propio equipo del usuario, envía esa imagen a Perplexity para procesarla y recibe instrucciones de navegación que luego ejecuta el ordenador del usuario. Cada paquete que llega a Amazon sale del dispositivo del usuario, por su conexión y dentro de su sesión.

El razonamiento del tribunal se deriva directamente de eso. El «acceso» según la CFAA significa entrar en un sistema informático, y la ley contempla el acceso por parte de una persona. El agente es el instrumento: el tribunal escribió que es «una herramienta, no una persona a efectos legales», y que «el foco de la investigación sigue estando en la persona que accede o que provoca el acceso». Así que quien accedió a Amazon fue el usuario, con la ayuda del agente de Perplexity.

El tribunal reforzó esto con la regla de lenidad. La CFAA es una ley penal. Si la teoría de Amazon fuera correcta —que quien accede es el operador del agente—, la misma lógica expondría a personas corrientes a responsabilidad penal por usar un asistente de IA para comprar algo. Los tribunales evitan interpretaciones tan amplias de las leyes penales, y este lo hizo.

Por qué esto debería cambiar cómo lees tu propio diagrama de arquitectura

Ejecutar del lado del cliente o del servidor siempre ha sido una decisión sobre latencia, coste y dónde viven las credenciales. Desde el 4 de agosto, también es una decisión sobre tu posición jurídica. El análisis del Noveno Circuito se apoya en la ausencia de comunicación entre servidores. Un agente cuyo backend descarga la página por sí mismo no queda obviamente cubierto por este razonamiento, y el tribunal no dijo que lo estuviera.

Lo que el fallo no hizo

El tribunal fue inusualmente explícito sobre sus propios límites: «No establecemos un nuevo régimen jurídico que regule la IA agéntica». Tómalo al pie de la letra. Hay cinco cosas que no cambiaron.

  • Las condiciones de uso siguen siendo vinculantes. El tribunal se ocupó de las leyes contra la intrusión informática y dejó expresamente abiertas las reclamaciones contractuales. Si las condiciones de un sitio prohíben el acceso automatizado, esa prohibición es hoy tan exigible como el mes pasado. Ahora es el principal campo de batalla, no una nota al pie.
  • Las teorías de responsabilidad civil siguen vivas. La sentencia las deja abiertas de forma expresa. La interferencia en relaciones contractuales, la competencia desleal y reclamaciones similares no se tocaron.
  • Es un fallo sobre una medida cautelar. El estándar es la probabilidad de éxito, no el fondo del asunto. El caso vuelve a la instancia inferior y Amazon sigue litigando.
  • Vincula a un solo circuito. El Noveno Circuito abarca California y la costa oeste, donde está buena parte de este sector, pero no es derecho nacional, y otro circuito puede discrepar.
  • No se puso a prueba la autonomía. El razonamiento gira en torno a un usuario que dirige una herramienta en el momento. Un agente que funciona sin supervisión según una programación, haciendo cosas que ningún humano inició expresamente, es un supuesto de hecho sustancialmente distinto que esta sentencia no resuelve.

La consecuencia que nadie celebra

Esta es la parte que debería preocuparte más de lo que te tranquiliza la victoria.

Si la legislación contra la intrusión informática ya no alcanza al operador del agente, las plataformas llevarán la pelea al contrato. Es la respuesta obvia, y Eric Goldman ya ha señalado adónde conduce: los sitios endurecen sus condiciones para prohibir el acceso asistido por agentes, y quien queda vinculado por esas condiciones es el titular de la cuenta. Tu usuario.

Vuelve a leer la lógica de la victoria y verás la trampa que contiene. El tribunal resolvió que quien accede al sitio es tu usuario. Esa es exactamente la premisa que necesita una plataforma para sostener que quien incumple es tu usuario, y para suspender su cuenta en lugar de demandarte a ti. Te libras de la responsabilidad argumentando con éxito que el actor es tu cliente. Ganar ese argumento dos veces no es obviamente bueno para tu producto.

Así que el futuro realista a corto plazo no es el acceso abierto de los agentes. Es una mezcla de condiciones más estrictas, detección de bots más agresiva y sanciones a nivel de cuenta contra los usuarios finales, con una cuestión jurídica resuelta a favor del sector de los agentes por debajo, haciendo menos de lo que sugieren los titulares.

Qué hacer si construyes agentes que tocan sitios ajenos

  • Sabe con precisión de dónde salen tus peticiones. Dibuja la ruta real de los paquetes en cada interacción con terceros: dispositivo del usuario, tu backend o un navegador headless en tu nube. Si la respuesta es «lo descarga nuestro backend», estás fuera de la arquitectura que avaló este fallo. Puede seguir siendo la decisión de ingeniería correcta; simplemente tómala a sabiendas, no por defecto.
  • Lee las condiciones de los sitios de los que dependes. Ahora son la restricción real, y además puedes comprobarla. Si el bucle central de tu producto exige una interacción que prohíben las condiciones de una gran plataforma, tienes un riesgo de negocio que ningún fallo judicial arregla.
  • No dejes que tus usuarios se sorprendan de lo que están aceptando. Si una plataforma puede considerar de forma plausible el uso de agentes como un incumplimiento del titular de la cuenta, tus usuarios están asumiendo un riesgo por ti. Dilo con claridad, mantén las acciones del agente visibles y revisables, y no tomes nunca una acción a nivel de cuenta que el usuario no entendiera que estaba autorizando.
  • Trata la gestión de credenciales como lo que te llevará a juicio. La demanda de Amazon alegaba que el agente accedía de forma encubierta a cuentas protegidas con contraseña. La reclamación por la CFAA fracasó por quién accedía, no porque la gestión de credenciales fuera defendible. Mantén las credenciales en el dispositivo del usuario o en un almacén que él controle, y nunca en un lugar cuyo diseño te costaría explicar a un regulador.
  • No construyas un foso a base de ser indetectable. Si tu ventaja es que una plataforma no puede distinguir a tu agente de un humano, estás a una mejora de detección de tener un producto muerto. La detección de bots se va a volver más agresiva precisamente porque la vía legal se ha estrechado.
  • Prefiere las vías autorizadas cuando existan. Una API, una alianza o un programa de afiliación son una peor experiencia de producto y un negocio mucho mejor. Merece la pena evitar por completo la pelea entre agente y sitio web cuando alguien te ofrece una puerta.

La lectura estratégica

No soy abogado y nada de esto es asesoramiento jurídico: si el acceso de agentes a plataformas de terceros es esencial para tu producto, esa conversación es con un abogado, no con un artículo de blog. Lo que sí puedo aportar es la observación de ingeniería, y es la que merece la pena llevarse.

Una decisión de diseño de sistemas tomada por motivos de latencia y de gestión de credenciales acabó determinando el resultado de una apelación federal. Es casi seguro que Perplexity no construyó Comet del lado del cliente para ganar un caso de la CFAA. Lo construyó así porque hacer la captura en local es una forma sensata de operar dentro de la sesión autenticada de un usuario, y el beneficio legal vino por añadidura.

Ese es el patrón que hay que interiorizar. Ha sido la semana para ello: el viernes, una empresa de chips apostando a que el lugar donde vive físicamente un modelo cambia su economía; hoy, un tribunal concluyendo que el lugar donde se ejecuta físicamente un agente cambia quién actúa legalmente. En ambos casos, la frontera que importaba era una frontera de despliegue, no una decisión de producto. A medida que los agentes empiezan a hacer cosas con consecuencias reales —gastar dinero, darse de alta, enviar correo, custodiar credenciales—, la pregunta «¿en qué ordenador se está ejecutando esto?» deja de ser un detalle de implementación y pasa a ser uno de los hechos esenciales de tu empresa.

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :