Segundo uma reportagem da GeekWire de 20 de setembro, a Amazon bloqueou o Muse, da Meta, de fazer compras em seu site para os clientes. A Amazon disse à publicação que o Muse operava sem acordo ou identificação adequada do agente e levantou preocupações sobre a captura e o armazenamento de credenciais dos clientes. A reportagem incluiu uma captura de tela do bloqueio fornecida pela Amazon. Até a noite de domingo, quando o texto foi publicado, a Meta não havia respondido. Essas são objeções da Amazon, não constatações de que ocorreu uma violação de segurança. Reportagem original da GeekWire
Para o consumidor, a interrupção traz uma pergunta incômoda. Se você escolhe um assistente para comparar produtos e fazer um pedido, quanto dessa escolha continua valendo diante da decisão da loja sobre quais assistentes aceita?
A resposta ajudará a determinar se os agentes de compras facilitam a comparação entre empresas ou confinam os consumidores a outro conjunto de parceiros aprovados. Isso também importa para varejistas menores, que podem receber de bom grado uma nova fonte de pedidos, mas se preocupar com quem explicará seus produtos e resolverá problemas. A delegação do consumidor, a participação da loja e a autorização do pagamento tratam de partes diferentes da transação.
Uma conexão de pagamento funcional ainda depende de uma loja disposta a participar
A Meta apresentou o Muse em 8 de setembro como um agente pessoal que pode continuar tarefas em um computador em nuvem dedicado. A descrição de lançamento inclui compras e diz que ações com consequências, como compras, exigem aprovação. Essas são descrições da empresa, não resultados de testes realizados pela BIG CHANGE. Anúncio do Muse pela Meta
A Stripe apresenta uma descrição mais específica da conexão de pagamento. Em seu anúncio de 8 de setembro, a empresa informa que consumidores dos Estados Unidos podem conectar o Link ao Muse. Em lojas que usam o Link, o agente pode utilizar o método preferido salvo pelo cliente. Em outras, o Link pode emitir um cartão virtual de uso único, limitado à compra aprovada. O cliente aprova o valor total na conversa, e o Muse não recebe os dados de pagamento subjacentes. Anúncio da integração pela Stripe
Um método de pagamento protegido pode reduzir o que um agente precisa saber para pagar. Mas não consegue, por si só, fazer um varejista aceitar a visita do agente. Da mesma forma, a instrução do consumidor para comprar um item específico não diz à loja como distinguir esse pedido de uma automação indesejada. Os sistemas precisam de um modo de reconhecer a autoridade do consumidor sem presumir que toda ação tentada pelo software esteja dentro dos limites dessa autoridade.
Nossa análise anterior sobre as permissões de pagamento de agentes de IA examinou os controles sobre os gastos. Esta disputa revela uma dependência anterior: o assistente precisa acessar uma parte suficiente do processo de compra para preparar um pedido que o cliente possa aprovar.
Considere um pedido hipotético para comprar uma peça de reposição de eletrodoméstico dentro de um orçamento fixo e com entrega antes de uma visita técnica. O assistente precisa encontrar o modelo exatamente compatível, verificar o estoque e o prazo de entrega e chegar à finalização da compra. Uma instrução de pagamento aprovada só ajuda depois que essas condições são atendidas. Um bloqueio durante a busca pode alterar os produtos que o agente considera; um bloqueio na finalização pode obrigar o consumidor a refazer um trabalho que já havia delegado.
Armazenamento de senhas e visibilidade do modelo são questões diferentes
O relato técnico da Meta diz que as credenciais ficam armazenadas em um serviço seguro dentro da máquina virtual do usuário, fora do ambiente de execução do agente principal. O navegador as recebe quando necessário; o agente principal não as vê. Um componente separado de supervisão verifica as ações e pode exigir aprovação. A Meta também afirma que seus controles operacionais atuais não a impedem tecnicamente de acessar a máquina virtual quando necessário para operar o serviço. Uma versão com computação confidencial seria uma etapa futura. Projeto de segurança e proteção da Meta
Manter uma senha fora do contexto do modelo pode limitar uma das formas pelas quais ela poderia ser exposta. Ainda assim, o serviço precisa armazenar ou usar as credenciais em algum lugar. Os leitores devem perguntar quem pode acessar esse armazenamento, quais permissões de conta a sessão concede e como revogar o acesso. Uma afirmação sobre um componente não responde a todas essas perguntas.
Um documento de projeto técnico tampouco comprova, de forma independente, a segurança do comportamento de um sistema implantado. Uma avaliação útil examinaria o que um agente consegue fazer após o login, como reage a conteúdo enganoso nas páginas e se o consumidor consegue reconstruir uma ação inesperada. Essa investigação é mais ampla do que verificar se o modelo teve acesso a uma senha.
O interesse comercial da Amazon em manter o relacionamento de compras não torna falsas suas preocupações de segurança. É preciso examinar de forma independente as proteções descritas pela Meta. Evidências sobre acesso e falhas reais seriam mais úteis do que a descrição que cada empresa prefere fazer da outra.
A Amazon também quer que agentes comprem fora da própria loja
A descrição publicada pela Amazon do Buy for Me explica um serviço que compra em sites de marcas externas por meio do aplicativo de compras da empresa. O consumidor confirma o pedido; a marca cuida da entrega, das devoluções e do atendimento ao cliente. A Amazon diz que as marcas podem escolher se querem participar. A página descreve o lançamento beta do serviço e não deve ser interpretada como uma lista atual de todas as lojas compatíveis. Descrição do Buy for Me pela Amazon
Esse arranjo mostra por que os termos de participação merecem análise. Um varejista pode aceitar de bom grado pedidos automatizados quando conhece o intermediário e há um processo acordado para resolver problemas. O mesmo varejista pode se opor a um agente desconhecido que usa contas de clientes em um navegador genérico. Diferenças na implementação podem justificar tratamentos distintos.
Elas também abrem espaço para um tratamento seletivo que beneficie um intermediário poderoso. Se cada grande varejista exigir uma parceria separada, o alcance de um assistente poderá depender de acordos comerciais que os consumidores não veem. Um desenvolvedor pequeno, mesmo com um bom produto, pode ter dificuldade para conseguir o mesmo acesso de uma grande plataforma. Um comerciante pode conquistar novos clientes e, ao mesmo tempo, tornar-se dependente do assistente que o recomenda.
Na nossa avaliação, as regras de acesso devem ser específicas o suficiente para permitir análise. Exigências de identificação, permissões limitadas e um processo confiável para reclamações são mais fáceis de avaliar do que uma garantia genérica de que parceiros aprovados são seguros. Quando agentes comparáveis recebem tratamentos diferentes, os varejistas devem explicar a diferença operacional. Isso permitiria que os consumidores distinguissem uma proteção mensurável de uma preferência por determinada relação comercial.
A decisão sobre o Comet não resolve a disputa do Muse
Em 4 de agosto, o Tribunal de Apelações do Nono Circuito anulou uma liminar contra a Perplexity e devolveu o processo para novas etapas. Com base naquele registro, o tribunal concluiu que era improvável que a Amazon demonstrasse o requisito de acesso previsto na lei federal Computer Fraud and Abuse Act e em sua equivalente californiana. O navegador Comet era executado no computador do usuário; o tribunal considerou que o usuário acessava a Amazon com uma ferramenta de IA. O tribunal preservou expressamente a capacidade da Amazon de regular os usuários por meio de termos de serviço privados. Parecer original do tribunal de apelações
O Muse usa uma máquina virtual e um navegador hospedados, uma configuração materialmente diferente daquela descrita no processo. O parecer não decidiu a situação do Muse nem estabeleceu um direito universal de agentes de compras entrarem em sites. Seu raciocínio limitado é motivo para examinar a implementação antes de prever um resultado jurídico.
Por isso, para empresas que planejam um serviço baseado em agentes, uma decisão favorável envolvendo outro produto é um substituto inadequado para entender seus próprios acordos de acesso. Uma promessa feita aos clientes deve descrever onde o serviço realmente funciona e o que acontece quando há uma contestação à permissão.
“Melhor opção disponível” exige limites de busca visíveis
O principal argumento a favor dos agentes de compras para os consumidores é a redução de tarefas repetitivas. Uma pessoa deveria poder especificar o que importa uma única vez, comparar ofertas adequadas e manter o controle da compra final. Alguém que tenha dificuldade com formulários ou pouco tempo para pesquisar uma peça de reposição exata poderia se beneficiar muito de uma assistência confiável.
Esse benefício depende de uma descrição honesta da busca. Se um agente não consegue usar uma loja importante, sua recomendação ainda pode ser útil, mas a cobertura ausente muda o que ele pode afirmar. A oferta acessível mais barata não é necessariamente a mais barata que o consumidor encontraria diretamente.
Para a compra hipotética da peça de eletrodoméstico, um resultado útil mostraria quais lojas foram consultadas, quais não puderam ser acessadas e o preço total com entrega. Se a melhor opção exigir uma visita presencial, o assistente deve preservar a referência do produto e explicar a etapa não concluída. Substituir silenciosamente a loja por outra acessível pode custar dinheiro ao consumidor ou fazer com que perca o prazo do reparo.
A mesma clareza deve valer para o status do pedido. O comprador precisa distinguir um carrinho preparado, um pagamento aprovado e um pedido confirmado. Após uma falha, o assistente deve informar com clareza se houve alguma compra antes de sugerir outra tentativa. São padrões propostos para um serviço útil, não recursos do Muse que tenhamos verificado.
Uma resposta bem formulada em tom de conversa pode esconder uma busca restrita mais facilmente do que uma lista visível de lojas. Nossa análise anterior dos incentivos comerciais do Muse considerou quem se beneficia com as recomendações do assistente. As restrições de acesso acrescentam outra influência: alguns vendedores talvez nem apareçam na comparação.
Varejistas precisam de evidências sobre pedidos concluídos
Um comerciante menor que esteja decidindo se aceita agentes deve começar com um caso de uso restrito e observável. Um assistente poderia ajudar os consumidores a encontrar o item correto e preparar um pedido, deixando as alterações importantes sujeitas a uma confirmação explícita. O comerciante poderia então examinar compras concluídas, itens incorretos e o tempo gasto no suporte, inclusive nos casos em que o assistente abandonou a tarefa.
Contar visitas de agentes diria pouco sobre a utilidade desse canal. Mais tráfego poderia gerar mais pedidos pagos ou mais clientes confusos, pedindo que a equipe resolva promessas feitas por um intermediário. As devoluções devem ser contabilizadas junto com as conversões. O comerciante também precisa saber se o agente descreve corretamente as condições de entrega e reembolso e se o consumidor consegue identificar o vendedor responsável após a finalização da compra.
Os consumidores poderiam escolher entre assistentes úteis, enquanto os comerciantes os aceitariam sob regras compreensíveis e proporcionais. Mas, se o acesso depender de uma série de acordos exclusivos, os compradores poderão acabar em redes restritas, cada uma apresentando um conjunto parcial de ofertas como se fosse um aconselhamento pessoal conveniente.
O bloqueio relatado deixa uma pergunta concreta para os consumidores fazerem antes de delegar a próxima compra: quais lojas este assistente vai consultar e o que me dirá se uma delas recusar o acesso? Um serviço que responde com clareza pode continuar útil mesmo com cobertura limitada. Esconder esse limite tornaria suas recomendações menos confiáveis.
