O agente já está na porta do caixa: o que acontece nos sistemas da empresa quando quem compra é uma máquina

Um cliente diz ao assistente de IA que usa: «Compre para mim o tênis preto, tamanho 27, e que chegue na sexta». O assistente abre a loja online, escolhe o produto, preenche o endereço de entrega e chega à tela de pagamento. Ali ele para e pergunta ao cliente: «Confirmo?». O cliente toca em um botão. O pedido entra no sistema.

Olhe essa cena do lado da empresa. Até antes do botão, quem visitou a loja não foi uma pessoa. E depois do botão, a operação precisa cobrar, faturar, enviar, conciliar e, se algo der errado, responder por uma compra que nenhum dos sistemas viu nascer como de costume.

Isso já não é uma hipótese de laboratório. Este artigo é para quem responde por vendas, finanças, operação ou tecnologia em um banco, uma fintech, uma seguradora, uma rede de varejo ou uma empresa regulada. Propõe deixar de lado a pergunta da moda —os agentes vão comprar sozinhos?— e fazer uma mais útil: o que acontece nos meus sistemas quando o que chega ao caixa é uma máquina? Conforme o papel de cada um, a pergunta muda: para o comércio, são o catálogo, o pedido, o CFDI e as devoluções; para o emissor, os limites, o consentimento e a revogação; para o adquirente ou processador de pagamentos, a aceitação, os sinais e a disputa; para a empresa regulada, a autorização, a rastreabilidade e os dados.

O que de fato aconteceu, e o que não

No fim de setembro de 2026, a Shopify documentou (em 28 de setembro) que os agentes de IA que operam em um navegador podem agora usar quatro ferramentas sobre a tela de pagamento da loja: ir à loja, ler o estado do pedido, atualizar dados de envio e entrega, e enviar o pedido. Essas ferramentas rodam dentro do mesmo checkout web que uma pessoa usa e com o mesmo estado que a interface mostra [1].

A nuance importa: a ferramenta que envia o pedido o faz depois da confirmação do comprador [1]. Segundo a documentação, além disso, o controle volta à pessoa quando se exige a verificação adicional do 3D Secure, a etapa com a qual o banco emissor confirma que o titular do cartão é quem está pagando [1].

Em outras palavras: no fluxo que a Shopify documentou, o agente prepara e a pessoa confirma; outros esquemas, como o AP2, já preveem compras autônomas sob autorização prévia do cliente [7]. Falar em «comprar sozinhos» neste caso seria um exagero. O que é certo é mais incômodo e mais próximo: no fluxo documentado pela Shopify, o agente já chega até a porta da cobrança, sem que a loja lhe abra uma porta especial: segundo a Shopify, essas ferramentas não expõem uma interface nova nem exigem configuração do comércio [1].

Dois dados mais foram noticiados, e convém tratá-los pelo que são. Segundo declarações de um porta-voz reproduzidas pelo GeekWire, a Amazon bloqueia o Muse, o agente de compras da Meta, entre outros motivos porque ele não se identifica quando navega pela loja [2]. O Infobae noticiou que a Adidas teria feito algo parecido, sem confirmação da empresa [2]. Nenhum dos dois casos demonstra uma tendência de mercado.

Um dado de contexto, para não inflar a expectativa. Em uma pesquisa da Visa e da Harris Poll de maio de 2026 nos Estados Unidos (2.065 consumidores; a pergunta sobre pagamentos foi feita a uma subamostra de cerca de 1.030), 23 % disseram confiar na IA generativa para fazer pagamentos em nome deles [3]. É uma pesquisa de um provedor de pagamentos, em outro país, e não mede volume de compras. Em nossa revisão de 17 de outubro de 2026 dos sites e comunicados dos protocolos e das redes citados aqui, não encontramos números públicos do volume de transações reais feitas por agentes. O que existe é a infraestrutura, e é isso que cabe à empresa revisar.

Cinco coisas que a empresa precisa resolver

Todas decorrem de uma única ideia: muitos fluxos de comércio eletrônico ainda pressupõem uma sessão humana, com cartão próprio e endereço de e-mail. Um agente pode romper cada um desses pressupostos separadamente.

1. Identidade: abre a porta ou a bloqueia?

Muitos filtros contra tráfego automatizado não distinguem entre a coleta automatizada de preços (scraping) e um cliente assistido por um agente: tratam ambos como um bot. Isso protege o site contra a coleta de preços e contra ataques, mas também pode estar recusando, sem que a empresa saiba, clientes reais que compram por meio de um assistente.

Visa e Mastercard já documentam mecanismos para identificar agentes. O protocolo de agente confiável da Visa (Trusted Agent Protocol) permite que um comércio distinga um agente legítimo de um bot por meio de assinaturas criptográficas ligadas ao comércio e ao propósito da visita, de vigência curta e não reutilizáveis [4]. Apoia-se em um padrão aberto de assinatura de mensagens HTTP, o RFC 9421 [5]. A Mastercard, por outro lado, anunciou que o marco de aceitação do Agent Pay exige registrar e verificar o agente antes de qualquer transação [6].

O que nenhuma dessas peças decide pela empresa é a política: quais agentes entram, com quais limites de consulta e de valor, e quem mantém a lista. E as duas opções têm custo. Bloquear todos pode perder vendas que já estavam feitas. Abrir sem critério expõe o catálogo, os preços e o estoque a consultas em massa. Identifique quem é o responsável por essa decisão na organização.

2. Autorização: quem disse sim a este pagamento?

Quando compra uma pessoa, a autorização está na tela: ela digita, confirma, o banco valida. Com um agente, isso depende do esquema. Há fluxos em que o comprador continua confirmando no checkout, como o da Shopify e o do protocolo da OpenAI e da Stripe [1][9]. Mas nos esquemas delegados ou pré-autorizados, a permissão foi dada antes, em outro lugar, e a empresa precisa de evidência de que foi dada.

Os protocolos atacam esse problema com ideias parecidas. O AP2, do Google, usa «mandatos» assinados: uma permissão do cliente com regras —teto de preço, vigência— e um carrinho aprovado, que buscam deixar um rastro verificável do que foi autorizado [7]. A Visa combina um token de pagamento feito para agentes com verificação reforçada do titular por meio de passkey (chave de acesso) [8]. O protocolo da OpenAI e da Stripe usa um token de pagamento delimitado que não expõe o cartão do cliente e deixa o comércio como responsável pela venda [9].

Para uma empresa, surge um terceiro tipo de credencial que não é nem o cartão do cliente nem a carteira digital do cliente: um token com valor, comércio e vigência limitados, nas mãos de um programa. Nos fluxos que usam credenciais delimitadas, convém confirmar com o processador de pagamentos ou o adquirente como elas são recebidas, validadas e reportadas; o mecanismo depende do protocolo e da rota de pagamento. Para um banco emissor, a pergunta é outra: como apresenta ao cliente o que o agente dele pode gastar, e como revoga isso para ele.

3. Disputas: quem responde quando o agente erra?

Pense em um chargeback (contestação de cobrança no cartão) com um motivo novo: «eu não pedi isto; meu agente errou». Foi erro do cliente, do comércio, da plataforma do agente ou do emissor? Os protocolos buscam preservar a evidência da instrução original: o AP2 com os mandatos que define [7] e a Visa com o que chama de «sinais comerciais» para resolver disputas [8].

Mas evidência não é critério. Em nossa revisão de 17 de outubro de 2026 das publicações da CNBV, do Banxico e da CONDUSEF (o regulador bancário, o banco central e o órgão de defesa dos usuários de serviços financeiros do México), não encontramos uma regra mexicana que atribua expressamente a responsabilidade por um erro de um agente; não é uma revisão jurídica exaustiva. Convém revisar contratos de rede e de adquirência e as obrigações aplicáveis antes de fixar uma política. Enquanto isso, a proteção da empresa depende do que ela consiga demonstrar: que instrução recebeu, de qual agente, com qual permissão e o que a loja mostrou naquele momento. Que evidência guardar e por quanto tempo, conforme a política de retenção aplicável, é algo a decidir hoje, porque reconstruí-la depois da primeira disputa pode não ser possível.

4. Dados fiscais: a quem se fatura?

Aqui está o problema mais local e o mais fácil de passar despercebido. No México, o CFDI 4.0 (a nota fiscal eletrônica mexicana) exige dados do receptor: o RFC (cadastro fiscal do contribuinte), o nome ou razão social, o regime fiscal e o código postal do domicílio fiscal [10]. Uma pessoa os digita em um formulário, ou a conta dela já os tem. Um agente pode não levá-los.

Sem os dados do receptor, não será possível emitir um CFDI nominativo durante o checkout (timbrar: obter o selo fiscal do CFDI). Então a equipe tem três caminhos, e os três custam: pedir os dados ao cliente depois, com o atrito e a defasagem que isso traz; aplicar uma política de faturamento posterior; ou incluir a operação na nota global (factura global), que se aplica a operações com o público em geral, nas condições da regra 2.7.1.21 da Resolución Miscelánea Fiscal (as regras fiscais anuais do México) [14], e que não substitui o CFDI nominativo quando o cliente o solicita. Nenhuma das fontes que consultamos resolve quem é o receptor fiscal de uma compra feita por meio de um agente. É uma pergunta aberta e convém respondê-la antes que os casos se multipliquem.

5. Fraude: como distinguir uma compra legítima de uma roubada?

Os modelos de risco que protegem um comércio se alimentam, em boa parte, de sinais de uma pessoa: o dispositivo, o padrão de navegação, o horário, o ritmo de digitação. Quando há um agente, esses sinais podem faltar: o tráfego chega de um programa, e os modelos calibrados para tráfego humano podem precisar de revalidação.

Isso obriga a revisar regras, a decidir quando se pede uma confirmação humana adicional e a incorporar os sinais novos que as redes oferecem. E obriga a algo mais básico: saber que o pedido veio de um agente. Se esse dado não fica registrado no pedido junto com quem autorizou, a conciliação e a defesa diante de um chargeback viram trabalho manual. O mesmo vale para as devoluções: convém definir com o adquirente a rota pela qual elas voltam.

Os protocolos, por camada

Os nomes se multiplicam —ACP, UCP, AP2, Visa, Mastercard— e é fácil acreditar que é preciso escolher um. Não competem pelo mesmo: cada um resolve uma camada diferente. E estão em etapas diferentes de maturidade, que convém não confundir.

Uma empresa poderia acabar falando vários desses protocolos ao mesmo tempo. Por isso a pergunta útil não é «qual adotamos?», e sim «o que meus sistemas precisam ter resolvido para falar qualquer um deles?».

O que têm em comum é o que cabe à empresa: um catálogo, preços e estoque que uma máquina possa consultar por interface e sem uma pessoa no meio; um pedido que registre de onde veio; e um registro de quem autorizou o quê.

Cenário: uma loja online com 10.000 pedidos por mês

Cenário ilustrativo, com números inventados para mostrar o efeito. Não descreve nenhuma empresa.

Uma loja online recebe 10.000 pedidos por mês. Suponha que 3 % passem a chegar por agentes: 300 pedidos. Até aqui, um número pequeno. Agora suponha que um quinto desses clientes peça nota fiscal e que o agente não levou o regime fiscal nem o uso do comprovante: são 60 notas que não podem ser timbradas na hora.

Se um analista dedica 15 minutos a cada uma, são 15 horas por mês de trabalho manual que antes não existiam. Se o percentual de agentes subir para 10 %, essas horas passam a 50. E não contamos um único chargeback, uma única devolução por um pedido mal entendido pelo agente, nem uma única conciliação que não encontra de qual agente veio a cobrança.

A lição do exemplo não é o número: o cenário permite estimar horas, atrasos de fechamento e evidência faltante.

O que convém fazer esta semana

Não é preciso um projeto para começar. É preciso responder a cinco perguntas com as pessoas certas à mesma mesa:

1. Tráfego. Quanto do que o site recusa como bot poderia ser um agente de um cliente? Se hoje não se mede, essa é a primeira resposta.
2. Política de portas. Quem decide quais agentes entram, com quais limites, e qual é o custo de cada decisão?
3. Evidência. Quando um pedido vier de um agente, o que fica registrado: quem autorizou, o que foi mostrado, o que foi cobrado?
4. Faturamento. O que a área fiscal faz com um pedido sem dados do receptor, e quem avisa o cliente?
5. Responsabilidade. Se o agente errar, quem absorve o custo: o cliente, a empresa, o emissor ou a plataforma, e onde isso está escrito?

Para que as respostas deixem de ser opinião, convém medir três coisas que a equipe pode levantar hoje, sem números de ninguém mais:

• Tráfego recusado como bot. Que percentual das visitas que o site bloqueia ou desafia corresponde a padrões que poderiam ser um agente de um cliente? Quem revisa isso e com que frequência?
• Custo de reconstruir uma nota fiscal. Quanto tempo e quantas pessoas leva hoje refazer uma nota quando o pedido chegou sem dados fiscais completos? Multiplique pelo número de pedidos que poderiam chegar assim.
• Custo de um chargeback. Quanto custa hoje atender um chargeback de ponta a ponta —tempo, comissão, mercadoria e evidência— e quanto mais custaria se o motivo fosse «meu agente errou»?

Se duas ou mais das respostas forem «não sei» ou «depende de quem responda», não é uma falha da equipe: são perguntas que, até poucos meses atrás, ninguém tinha motivo para se fazer. O que mudou é que o ritmo já não é marcado apenas pela agenda interna: está sendo marcado pelo ecossistema.

Há ainda uma parte técnica que já tem guia. Que um agente consiga consultar o catálogo, tentar de novo sem duplicar um pedido e receber erros que entenda não é um tema só do checkout: é uma propriedade das interfaces. Nós a desenvolvemos no artigo APIs prontas para agentes de IA: o que o sistema precisa para que um agente o use com controle.

O que a Hábil faz

Os problemas acima têm algo em comum: ocorrem na união entre sistemas. O pedido nasce em um canal, a cobrança em outro, a nota fiscal em um terceiro e a conciliação em um quarto, e a nenhum cabe saber que quem comprou foi um agente. A Hábil se dedica a essa união: integrar sistemas existentes com o objetivo de que as operações deixem rastro de quem as autorizou e de que um canal novo não obrigue a reescrever os anteriores.

Se a empresa está pensando em como receber —ou como limitar— os agentes de IA, a página Hábil AI explica o que fazemos com eles, e o artigo APIs prontas para agentes de IA detalha o que o sistema precisa para que um agente o use com controle.

O próximo passo é simples: escreva para nós pelo WhatsApp. Em uma primeira conversa, sem custo, dizemos onde provavelmente se perdem dinheiro, tempo ou evidência nas interfaces da operação e se vale a pena um diagnóstico a fundo, com escopo acordado.