Checkout por agente de IA: o que o Agentic Commerce Protocol pede da sua loja
Veja o checklist técnico e o que muda na troca e na devolução quando quem fecha a compra é uma IA agindo pelo cliente.
· 7 min de leitura
Este artigo foi escrito por Débora Nunes. Conteúdo produzido por agente de IA da redação AI Brasil, sob revisão editorial humana. Saiba como produzimos no expediente.
O Agentic Commerce Protocol, padrão aberto da OpenAI e da Stripe para vender dentro de agentes de IA, está em beta desde setembro de 2025 e ganhou catálogo, pedido e autenticação em abril de 2026. Veja o checklist técnico e o que muda na troca e na devolução quando quem fecha a compra é uma IA agindo pelo cliente.
O que é o Agentic Commerce Protocol
O Agentic Commerce Protocol (ACP) é um padrão aberto que define como um comprador, o agente de IA que ele usa e a loja que vende o produto se conectam para fechar uma compra sem que o cliente precise abrir o site do lojista. A especificação está no GitHub do projeto, mantida em conjunto pela OpenAI e pela Stripe, e segue em beta desde o lançamento inicial, publicado em 29 de setembro de 2025.
Na prática, o ACP é o que permite a alguém pedir um produto dentro de um chat como o ChatGPT e sair de lá com o pedido confirmado, sem copiar link, sem abrir outra aba. A loja continua sendo a loja: ela recebe o pedido, processa o pagamento e cumpre a entrega. O agente só intermedeia a conversa e o clique de "comprar".
Quem é o responsável legal pela venda não muda
O ponto mais importante do protocolo para quem vende está numa frase da própria documentação: o objetivo é deixar o agente de IA levar comprador e loja para a transação sem que o agente vire o responsável legal pela venda, o chamado merchant of record. Essa responsabilidade continua sendo do lojista, mesmo quando o cliente nunca visitou o site ou o aplicativo da loja.
Isso importa porque é a loja, e não a OpenAI nem o fabricante do agente, quem segue respondendo pelo Código de Defesa do Consumidor: nota fiscal, garantia, troca, devolução e o prazo de arrependimento de sete dias para compra fora do estabelecimento físico (art. 49 do CDC) continuam sendo obrigação de quem vendeu o produto, não de quem forneceu o chat.
Cinco versões em sete meses: o que cada uma resolveu
O ACP evolui por versões datadas, cada uma um retrato completo da especificação naquele momento. Da estreia à versão mais recente, o protocolo foi de um checkout básico a um conjunto de peças que cobre catálogo, pedido, pagamento e autenticação.
| Versão | O que trouxe |
|---|---|
| 2025-09-29 | Lançamento inicial do protocolo |
| 2025-12-12 | Melhorias de fulfillment (como a loja informa status do pedido) |
| 2026-01-16 | Negociação de capacidades entre loja e agente |
| 2026-01-30 | Extensões, descontos e handlers de pagamento |
| 2026-04-17 | Carrinho, feed de catálogo, pedidos, autenticação e suporte a MCP |
A versão de 17 de abril de 2026, a mais recente estável até hoje, é a primeira a incluir o feed de catálogo (como a loja publica seus produtos para o agente encontrar) dentro da própria especificação, segundo a estrutura de diretórios do repositório.
O checklist técnico para habilitar a venda dentro de um agente
Quem roda e-commerce ou marketplace e quer aparecer como opção de compra dentro de um agente de IA precisa, segundo a estrutura da especificação, cobrir quatro frentes:
- Feed de produto. Publicar o catálogo num formato que o agente consiga ler e indexar, incluindo preço, disponibilidade e condições de venda atualizadas. É a peça formalizada na versão de abril de 2026.
- Checkout compatível. Expor um endpoint de checkout que siga o contrato definido no arquivo
openapi.agentic_checkout.yaml, responsável por criar e confirmar o pedido a partir da intenção de compra que chega do agente. - Pagamento delegado. Implementar o fluxo descrito em
openapi.delegate_payment.yaml: a loja recebe um token de pagamento seguro repassado pelo agente, sem enxergar diretamente o cartão do cliente, processado por um "payment handler" (o RFCrfc.payment_handlers.mddetalha esse papel, e orfc.seller_backed_payment_handler.mdcobre o caso em que o próprio lojista processa o pagamento em vez de depender só do provedor). - Atualização de status do pedido. Avisar o agente quando o pedido muda de estado (confirmado, despachado, cancelado). O README não detalha o mecanismo exato, mas esse tipo de integração costuma ser resolvido com webhook (uma chamada automática do sistema da loja avisando a mudança); vale conferir os exemplos da versão 2025-12-12, que foi a que trouxe essas melhorias de fulfillment.
Quem trabalha com cupom e promoção precisa olhar também o rfc.extensions.md e o rfc.discount_extension.md, da versão de 30 de janeiro de 2026: descontos dentro do checkout agêntico seguem um formato de extensão próprio, não o campo livre que cada plataforma de e-commerce costuma usar hoje. E como nem toda loja suporta todo recurso do protocolo, a versão de 16 de janeiro de 2026 introduziu a negociação de capacidades (rfc.capability_negotiation.md): antes de fechar a venda, loja e agente trocam informação sobre o que cada lado consegue processar, como parcelamento ou retirada em loja.
O dado do cliente que passa pelo agente ainda é dado do cliente
Para o checkout funcionar, informações do comprador (nome, endereço de entrega, token de pagamento) trafegam pelo agente até chegar à loja. Isso não muda a base legal da LGPD: o tratamento desses dados pela loja segue justificado pela execução do contrato de compra e venda, não por consentimento genérico de marketing, e não autoriza a loja a usar esse dado para personalização ou campanha sem uma base própria para isso.
Vale mapear, antes de habilitar a integração, exatamente quais campos o agente envia no pedido e se esse fluxo está coberto no mesmo aviso de privacidade que já cobre a compra feita direto no site. Se o lojista pretende usar esse histórico de compra via agente para recomendar produto depois, isso é uma finalidade nova e pede base legal própria.
O que muda na troca e na devolução quando quem compra é uma IA
Aqui está o ponto que a especificação técnica não resolve sozinha, porque é uma questão de operação, não de protocolo. Se o cliente aciona o agente de IA para pedir a troca ou a devolução, e não a central de atendimento da loja, quem registra essa conversa? Quem garante que ela chegou ao sistema de pós-venda da loja, e no prazo que o CDC exige para resposta?
Em resumo: a venda feita por agente de IA não cria uma categoria nova de direito do consumidor, mas cria uma lacuna de processo que a loja precisa fechar antes de habilitar a venda, não depois da primeira reclamação. Três pontos concretos merecem checklist próprio:
- Garantir que toda compra fechada via agente gere o mesmo registro (pedido, nota fiscal, histórico de atendimento) que uma compra feita no site, de forma que o time de pós-venda enxergue a mesma informação independente do canal.
- Definir, por escrito no fluxo de atendimento, que pedido de troca ou devolução feito dentro do próprio chat do agente é transferido para um canal humano da loja dentro do mesmo prazo que já vale para qualquer outro canal digital.
- Deixar claro, no próprio fluxo de compra dentro do agente, quem o cliente deve procurar se o produto chegar errado: a loja, não o fabricante do assistente de IA.
O que testar antes de abrir a venda via agente
Até o fechamento desta matéria, não foi possível localizar na especificação nem no repositório do projeto dado de conversão, ruptura ou margem associado a lojas que já vendem por esse canal, nem case público citado ali. Isso significa que qualquer resultado de campanha depende da operação de cada loja, medido por ela mesma.
Antes de ligar o checkout agêntico numa campanha, dá para testar em escala pequena com um recorte de catálogo e acompanhar três números: a taxa de conversão das sessões abertas pelo agente comparada ao checkout tradicional, a taxa de cancelamento ou disputa de pagamento nesse canal e o tempo de resposta do time de pós-venda quando a reclamação chega via agente em vez de via SAC direto. São esses três indicadores, não o anúncio do protocolo em si, que vão dizer se vale abrir a loja para esse tipo de compra.
Fonte 1: Especificação oficial do Agentic Commerce Protocol (OpenAI/Stripe) (https://github.com/agentic-commerce-protocol/agentic-commerce-protocol)
Repositório oficial do Agentic Commerce Protocol (ACP), mantido em conjunto por OpenAI e Stripe, descrito como "an interaction model and open standard for connecting buyers, their AI agents, and businesses to complete purchases seamlessly". O projeto está licenciado sob Apache 2.0 e organiza a especificação em pastas de RFCs (rfcs/), versões datadas da spec (spec/<versão>/), exemplos (examples/<versão>/) e changelog (changelog/<versão>.md). A governança é conduzida por OpenAI e Stripe como "Founding Maintainers", com caminho previsto para administração por uma fundação neutra conforme o ecossistema amadurece, segundo a documentação do projeto (docs/governance.md). Implementações de referência para integração de checkout agêntico estão disponíveis na documentação da OpenAI e da Stripe.
Fonte: Especificação oficial do Agentic Commerce Protocol (OpenAI/Stripe)
Especialista virtual de IA para quem vende em escala: gerente de loja e de rede, comprador, time de e-commerce, CRM e atendimento, dono de varejo regional. É dona da frente AI para Varejo. Escreve o artigo que traduz a IA em operação de loja: estoque e reposição, preço, atendimento, troca e devolução, a vitrine que agora também é lida por um agente de IA, e o que o Código de Defesa do Consumidor continua cobrando quando quem atende é uma máquina.