Un fallo del Noveno Circuito pone al agente de IA en el asiento del usuario

El 4 de agosto de 2026 un panel del Noveno Circuito anuló la orden preliminar que impedía al agente de IA de Perplexity actuar en Amazon.com por cuenta de clientes de Amazon. El panel sostuvo que quien «accedió» a los ordenadores de Amazon fue el usuario, no Perplexity. La alerta de Cooley del 6 de agosto de 2026 expone el razonamiento y, con la misma utilidad, sus dos límites.

El fallo importa más allá de un agente de compras, porque es una afirmación sobre dónde termina la persona y dónde empieza el programa que actúa por ella. Ese límite es el que los dueños de sitios llevan años adivinando desde que los agentes empezaron a rellenar formularios.

Qué decidió realmente el tribunal

Assistant, el agente dentro del navegador Comet de Perplexity, tomaba capturas de la vista del navegador en la propia máquina del usuario, las enviaba a los servidores de Perplexity y recibía instrucciones para navegar por Amazon. Perplexity no abría por sí misma una conexión con los servidores de Amazon. Sobre esa arquitectura, el panel razonó que el «whoever» de la CFAA presupone una persona, así que «acceder» significa que la persona entra en el sistema, y la persona aquí era el usuario que daba la instrucción. La reclamación por la CDAFA de California cayó por la misma razón.

El tribunal de distrito había resuelto lo contrario el 9 de marzo de 2026, al considerar probable que Amazon ganara porque el acceso de Perplexity no estaba autorizado por Amazon, hiciera lo que hiciera con sus usuarios. El Noveno Circuito revocó esa decisión y devolvió el caso.

Qué cambia para el dueño de un sitio

La conclusión práctica es estrecha y útil: no construyas una política de bots sobre una ley antiintrusión. El panel dejó abiertas las teorías contractuales y de responsabilidad civil, y dijo con claridad que otro agente podría dar otro resultado.

• Los términos de servicio siguen siendo la palanca que la propia opinión nombra.

• Un agente que habla directamente con tus servidores, sin pasar por la máquina del usuario, se acerca al supuesto que el tribunal distinguió.

• Un mayor control de la empresa de IA sobre su agente apunta en la dirección contraria.

Para el dueño de un formulario, esta es la parte que importa. Las defensas de un formulario no son teorías jurídicas: son cosas que ocurren en el momento de un POST.

En qué deberían apoyarse los controles antibot de un formulario

FormFlow ofrece un desafío Turnstile y un modelo de spam por formulario entrenado con correcciones humanas. Turnstile es el desafío de un proveedor, y falla abierto: cuando no se puede alcanzar al proveedor, una Submission no se bloquea por ese motivo. El modelo de spam pondera la evidencia de la petición contra un modelo que las propias correcciones del formulario han moldeado, y una prior del equipo puede marcar una Submission pero nunca vetarla.

Nada de eso es una garantía, ni una afirmación sobre lo que es lícito. Es un argumento contra un solo control. Un formulario que depende de una señal tiene un único punto de fallo, sea esa señal un desafío, una comprobación de user-agent o un caso judicial.

Qué no decide esto

Este recurso venía de una orden preliminar. El panel evaluó la probabilidad de éxito con el expediente actual y devolvió el caso. No celebró un juicio ni llegó a una resolución firme sobre el fondo, y la orden se anuló en lugar de sustituirse por una sentencia para cualquiera de las partes.

El fallo se limita a la CFAA y la CDAFA. No legaliza los agentes de IA, no bendice el acceso de agentes en general, no decide reclamaciones contractuales ni de responsabilidad civil, y no dice nada sobre robots.txt, términos de servicio ni cualquier otra política de acceso que un sitio adopte.

Tampoco decide nada sobre los controles de FormFlow, que son decisiones de ingeniería y no jurídicas. Lee la fuente primaria y no un resumen. Para el contrato POST que impone un formulario, lee la referencia de la API, y para el origen de ese contrato, consulta la entrada del Changelog de v1.0.0.