Protocolo de Pagamentos por Agente (AP2) do Google

O Protocolo de Pagamentos por Agente (AP2) do Google é um padrão aberto recém-anunciado, projetado para permitir transações seguras e confiáveis iniciadas por agentes de IA em nome dos usuários. Desenvolvido em colaboração com mais de 60 organizações de pagamentos e tecnologia (incluindo grandes redes de pagamento, bancos, fintechs e empresas Web3), o AP2 estabelece uma linguagem comum para pagamentos “agênticos” – ou seja, compras e transações financeiras que um agente autônomo (como um assistente de IA ou um agente baseado em LLM) pode realizar para um usuário. A criação do AP2 é impulsionada por uma mudança fundamental: tradicionalmente, os sistemas de pagamento online assumiam que um humano estava clicando diretamente em “comprar”, mas o surgimento de agentes de IA agindo sob as instruções do usuário quebra essa suposição. O AP2 aborda os desafios resultantes de autorização, autenticidade e responsabilidade no comércio impulsionado por IA, mantendo-se compatível com a infraestrutura de pagamento existente. Este relatório examina a arquitetura técnica do AP2, seu propósito e casos de uso, integrações com agentes de IA e provedores de pagamento, considerações de segurança e conformidade, comparações com protocolos existentes, implicações para sistemas Web3/descentralizados e a adoção/roteiro da indústria.

Arquitetura Técnica: Como o AP2 Funciona

Em sua essência, o AP2 introduz uma estrutura de transação criptograficamente segura construída sobre credenciais digitais verificáveis (VDCs) – essencialmente objetos de dados assinados e à prova de adulteração que servem como “contratos” digitais do que o usuário autorizou. Na terminologia do AP2, esses contratos são chamados de Mandatos, e eles formam uma cadeia de evidências auditável para cada transação. Existem três tipos principais de mandatos na arquitetura do AP2:

• Mandato de Intenção: Captura as instruções ou condições iniciais do usuário para uma compra, especialmente para cenários “humano-ausente” (onde o agente agirá mais tarde sem o usuário online). Ele define o escopo de autoridade que o usuário concede ao agente – por exemplo, “Comprar ingressos para o show se o preço cair abaixo de $200, até 2 ingressos”. Este mandato é assinado criptograficamente antecipadamente pelo usuário e serve como prova verificável de consentimento dentro de limites específicos.
• Mandato de Carrinho: Representa os detalhes finais da transação que o usuário aprovou, usado em cenários “humano-presente” ou no momento do checkout. Inclui os itens ou serviços exatos, seu preço e outras particularidades da compra. Quando o agente está pronto para concluir a transação (por exemplo, após preencher um carrinho de compras), o comerciante primeiro assina criptograficamente o conteúdo do carrinho (garantindo os detalhes do pedido e o preço), e então o usuário (através de seu dispositivo ou interface do agente) assina para criar um Mandato de Carrinho. Isso garante o que você vê é o que você paga, fixando o pedido final exatamente como apresentado ao usuário.
• Mandato de Pagamento: Uma credencial separada que é enviada à rede de pagamento (por exemplo, rede de cartão ou banco) para sinalizar que um agente de IA está envolvido na transação. O Mandato de Pagamento inclui metadados como se o usuário estava presente ou não durante a autorização e serve como um sinalizador para sistemas de gerenciamento de risco. Ao fornecer aos bancos adquirentes e emissores evidências criptograficamente verificáveis da intenção do usuário, este mandato os ajuda a avaliar o contexto (por exemplo, distinguindo uma compra iniciada por agente de uma fraude típica) e a gerenciar a conformidade ou responsabilidade de acordo.

Todos os mandatos são implementados como credenciais verificáveis assinadas pelas chaves da parte relevante (usuário, comerciante, etc.), gerando uma trilha de auditoria não-repudiável para cada transação liderada por agente. Na prática, o AP2 usa uma arquitetura baseada em funções para proteger informações sensíveis – por exemplo, um agente pode lidar com um Mandato de Intenção sem nunca ver os detalhes brutos de pagamento, que são revelados de forma controlada apenas quando necessário, preservando a privacidade. A cadeia criptográfica de intenção do usuário → compromisso do comerciante → autorização de pagamento estabelece confiança entre todas as partes de que a transação reflete as verdadeiras instruções do usuário e que tanto o agente quanto o comerciante aderiram a essas instruções.

Fluxo de Transação: Para ilustrar como o AP2 funciona de ponta a ponta, considere um cenário de compra simples com um humano no circuito:

1. Solicitação do Usuário: O usuário pede ao seu agente de IA para comprar um item ou serviço específico (por exemplo, “Pedir este par de sapatos no meu tamanho”).
2. Construção do Carrinho: O agente se comunica com os sistemas do comerciante (usando APIs padrão ou através de uma interação agente-para-agente) para montar um carrinho de compras para o item especificado a um determinado preço.
3. Garantia do Comerciante: Antes de apresentar o carrinho ao usuário, o lado do comerciante assina criptograficamente os detalhes do carrinho (item, quantidade, preço, etc.). Esta etapa cria uma oferta assinada pelo comerciante que garante os termos exatos (evitando quaisquer alterações ocultas ou manipulação de preços).
4. Aprovação do Usuário: O agente mostra ao usuário o carrinho finalizado. O usuário confirma a compra, e esta aprovação aciona duas assinaturas criptográficas do lado do usuário: uma no Mandato de Carrinho (para aceitar o carrinho do comerciante como está) e uma no Mandato de Pagamento (para autorizar o pagamento através do provedor de pagamento escolhido). Esses mandatos assinados são então compartilhados com o comerciante e a rede de pagamento, respectivamente.
5. Execução: Munidos do Mandato de Carrinho e do Mandato de Pagamento, o comerciante e o provedor de pagamento prosseguem para executar a transação com segurança. Por exemplo, o comerciante envia a solicitação de pagamento juntamente com a prova de aprovação do usuário para a rede de pagamento (rede de cartão, banco, etc.), que pode verificar o Mandato de Pagamento. O resultado é uma transação de compra concluída com uma trilha de auditoria criptográfica que vincula a intenção do usuário ao pagamento final.

Este fluxo demonstra como o AP2 constrói confiança em cada etapa de uma compra impulsionada por IA. O comerciante tem prova criptográfica do que exatamente o usuário concordou em comprar e a que preço, e o emissor/banco tem prova de que o usuário autorizou esse pagamento, mesmo que um agente de IA tenha facilitado o processo. Em caso de disputas ou erros, os mandatos assinados atuam como evidência clara, ajudando a determinar a responsabilidade (por exemplo, se o agente se desviou das instruções ou se uma cobrança não foi o que o usuário aprovou). Em essência, a arquitetura do AP2 garante que a intenção verificável do usuário – em vez da confiança no comportamento do agente – seja a base da transação, reduzindo grandemente a ambiguidade.

Propósito e Casos de Uso para o AP2

Por que o AP2 é Necessário: O propósito principal do AP2 é resolver problemas emergentes de confiança e segurança que surgem quando agentes de IA podem gastar dinheiro em nome dos usuários. O Google e seus parceiros identificaram várias questões-chave que a infraestrutura de pagamento atual não consegue responder adequadamente quando um agente autônomo está no circuito:

• Autorização: Como provar que um usuário realmente deu permissão ao agente para fazer uma compra específica? (Em outras palavras, garantir que o agente não está comprando coisas sem o consentimento informado do usuário.)
• Autenticidade: Como um comerciante pode saber que uma solicitação de compra de um agente é genuína e reflete a verdadeira intenção do usuário, em vez de um erro ou alucinação da IA?
• Responsabilidade: Se uma transação fraudulenta ou incorreta ocorrer via um agente, quem é o responsável – o usuário, o comerciante, o provedor de pagamento ou o criador do agente de IA?

Sem uma solução, essas incertezas criam uma “crise de confiança” em torno do comércio liderado por agentes. A missão do AP2 é fornecer essa solução, estabelecendo um protocolo uniforme para transações seguras de agentes. Ao introduzir mandatos padronizados e provas de intenção, o AP2 previne um ecossistema fragmentado, onde cada empresa inventa seus próprios métodos ad-hoc de pagamento por agente. Em vez disso, qualquer agente de IA compatível pode interagir com qualquer comerciante/provedor de pagamento compatível sob um conjunto comum de regras e verificações. Essa consistência não apenas evita a confusão do usuário e do comerciante, mas também oferece às instituições financeiras uma maneira clara de gerenciar o risco para pagamentos iniciados por agentes, em vez de lidar com uma colcha de retalhos de abordagens proprietárias. Em suma, o propósito do AP2 é ser uma camada fundamental de confiança que permite que a “economia de agentes” cresça sem quebrar o ecossistema de pagamentos.

Casos de Uso Pretendidos: Ao resolver os problemas acima, o AP2 abre as portas para novas experiências de comércio e casos de uso que vão além do que é possível com um humano clicando manualmente nas compras. Alguns exemplos de comércio habilitado por agente que o AP2 suporta incluem:

• Compras Mais Inteligentes: Um cliente pode instruir seu agente: “Quero esta jaqueta de inverno em verde, e estou disposto a pagar até 20% acima do preço atual por ela”. Munido de um Mandato de Intenção que codifica essas condições, o agente monitorará continuamente sites de varejistas ou bancos de dados. No momento em que a jaqueta estiver disponível em verde (e dentro do limite de preço), o agente executa automaticamente uma compra com uma transação segura e assinada – capturando uma venda que de outra forma teria sido perdida. Toda a interação, desde a solicitação inicial do usuário até o checkout automatizado, é governada pelos mandatos do AP2, garantindo que o agente compre exatamente o que foi autorizado.
• Ofertas Personalizadas: Um usuário diz ao seu agente que está procurando um produto específico (digamos, uma nova bicicleta) de um determinado comerciante para uma próxima viagem. O agente pode compartilhar esse interesse (dentro dos limites de um Mandato de Intenção) com o agente de IA do próprio comerciante, incluindo contexto relevante como a data da viagem. O agente do comerciante, conhecendo a intenção e o contexto do usuário, poderia responder com um pacote personalizado ou desconto – por exemplo, “bicicleta + capacete + bagageiro com 15% de desconto, disponível pelas próximas 48 horas”. Usando o AP2, o agente do usuário pode aceitar e concluir esta oferta personalizada com segurança, transformando uma simples consulta em uma venda mais valiosa para o comerciante.
• Tarefas Coordenadas: Um usuário planejando uma tarefa complexa (por exemplo, uma viagem de fim de semana) a delega inteiramente: “Reserve-me um voo e hotel para estas datas com um orçamento total de $700”. O agente pode interagir com agentes de vários provedores de serviços – companhias aéreas, hotéis, plataformas de viagem – para encontrar uma combinação que se ajuste ao orçamento. Uma vez identificado um pacote de voo-hotel adequado, o agente usa o AP2 para executar múltiplas reservas de uma só vez, cada uma criptograficamente assinada (por exemplo, emitindo Mandatos de Carrinho separados para a companhia aérea e o hotel, ambos autorizados sob o Mandato de Intenção do usuário). O AP2 garante que todas as partes desta transação coordenada ocorram conforme aprovado, e até permite a execução simultânea para que passagens e reservas sejam feitas juntas sem risco de uma parte falhar no meio do caminho.

Esses cenários ilustram apenas alguns dos casos de uso pretendidos do AP2. De forma mais ampla, o design flexível do AP2 suporta tanto fluxos de e-commerce convencionais quanto modelos de comércio totalmente novos. Por exemplo, o AP2 pode facilitar serviços semelhantes a assinaturas (um agente mantém você abastecido com itens essenciais comprando quando as condições são atendidas), compras orientadas por eventos (comprar ingressos ou itens no instante em que um evento acionador ocorre), negociações de agentes em grupo (agentes de múltiplos usuários agrupando mandatos para negociar um acordo em grupo) e muitos outros padrões emergentes. Em todos os casos, o fio condutor é que o AP2 fornece a estrutura de confiança – autorização clara do usuário e auditabilidade criptográfica – que permite que essas transações impulsionadas por agentes ocorram com segurança. Ao lidar com a camada de confiança e verificação, o AP2 permite que desenvolvedores e empresas se concentrem em inovar novas experiências de comércio de IA sem reinventar a segurança de pagamentos do zero.

Integração com Agentes, LLMs e Provedores de Pagamento

O AP2 é explicitamente projetado para se integrar perfeitamente com frameworks de agentes de IA e com sistemas de pagamento existentes, atuando como uma ponte entre os dois. O Google posicionou o AP2 como uma extensão de seus padrões de protocolo Agent2Agent (A2A) e Model Context Protocol (MCP). Em outras palavras, se o A2A fornece uma linguagem genérica para agentes se comunicarem tarefas e o MCP padroniza como os modelos de IA incorporam contexto/ferramentas, então o AP2 adiciona uma camada de transações por cima para o comércio. Os protocolos são complementares: o A2A lida com a comunicação agente-para-agente (permitindo, por exemplo, que um agente de compras converse com o agente de um comerciante), enquanto o AP2 lida com a autorização de pagamento agente-para-comerciante dentro dessas interações. Como o AP2 é aberto e não proprietário, ele é destinado a ser agnóstico em relação a frameworks: os desenvolvedores podem usá-lo com o próprio Agent Development Kit (ADK) do Google ou qualquer biblioteca de agentes de IA, e da mesma forma, pode funcionar com vários modelos de IA, incluindo LLMs. Um agente baseado em LLM, por exemplo, poderia usar o AP2 gerando e trocando os payloads de mandato necessários (guiado pela especificação AP2) em vez de apenas texto livre. Ao impor um protocolo estruturado, o AP2 ajuda a transformar a intenção de alto nível de um agente de IA (que pode vir do raciocínio de um LLM) em transações concretas e seguras.

No lado dos pagamentos, o AP2 foi construído em conjunto com provedores de pagamento e padrões tradicionais, em vez de ser um sistema de substituição total. O protocolo é agnóstico em relação ao método de pagamento, o que significa que pode suportar uma variedade de trilhos de pagamento – desde redes de cartão de crédito/débito até transferências bancárias e carteiras digitais – como o método subjacente para movimentar fundos. Em sua versão inicial, o AP2 enfatiza a compatibilidade com pagamentos por cartão, já que são os mais comuns no comércio online. O Mandato de Pagamento do AP2 é projetado para se encaixar no fluxo de processamento de cartão existente: ele fornece dados adicionais à rede de pagamento (por exemplo, Visa, Mastercard, Amex) e ao banco emissor de que um agente de IA está envolvido e se o usuário estava presente, complementando assim as verificações existentes de detecção de fraude e autorização. Essencialmente, o AP2 não processa o pagamento em si; ele aumenta a solicitação de pagamento com prova criptográfica da intenção do usuário. Isso permite que os provedores de pagamento tratem as transações iniciadas por agentes com a cautela ou velocidade apropriadas (por exemplo, um emissor pode aprovar uma compra de aparência incomum se vir um mandato AP2 válido provando que o usuário a pré-aprovou). Notavelmente, o Google e seus parceiros planejam evoluir o AP2 para suportar também métodos de pagamento “push” – como transferências bancárias em tempo real (como os sistemas UPI da Índia ou PIX do Brasil) – e outros tipos emergentes de pagamento digital. Isso indica que a integração do AP2 se expandirá além dos cartões, alinhando-se às tendências de pagamento modernas em todo o mundo.

Para comerciantes e processadores de pagamento, integrar o AP2 significaria suportar as mensagens de protocolo adicionais (mandatos) e verificar assinaturas. Muitas grandes plataformas de pagamento já estão envolvidas na formação do AP2, então podemos esperar que elas construam suporte para ele. Por exemplo, empresas como Adyen, Worldpay, Paypal, Stripe (não explicitamente nomeadas no blog, mas provavelmente interessadas) e outras poderiam incorporar o AP2 em suas APIs de checkout ou SDKs, permitindo que um agente inicie um pagamento de forma padronizada. Como o AP2 é uma especificação aberta no GitHub com implementações de referência, provedores de pagamento e plataformas de tecnologia podem começar a experimentá-lo imediatamente. O Google também mencionou um AI Agent Marketplace onde agentes de terceiros podem ser listados – espera-se que esses agentes suportem o AP2 para quaisquer capacidades transacionais. Na prática, uma empresa que constrói um assistente de vendas de IA ou um agente de compras pode listá-lo neste marketplace, e graças ao AP2, esse agente pode realizar compras ou pedidos de forma confiável.

Finalmente, a história de integração do AP2 se beneficia de seu amplo apoio da indústria. Ao co-desenvolver o protocolo com grandes instituições financeiras e empresas de tecnologia, o Google garantiu que o AP2 se alinha com as regras e requisitos de conformidade existentes na indústria. A colaboração com redes de pagamento (por exemplo, Mastercard, UnionPay), emissores (por exemplo, American Express), fintechs (por exemplo, Revolut, Paypal), players de e-commerce (por exemplo, Etsy) e até provedores de identidade/segurança (por exemplo, Okta, Cloudflare) sugere que o AP2 está sendo projetado para se encaixar em sistemas do mundo real com atrito mínimo. Esses stakeholders trazem experiência em áreas como KYC (regulamentações Conheça Seu Cliente), prevenção de fraude e privacidade de dados, ajudando o AP2 a atender a essas necessidades desde o início. Em resumo, o AP2 é construído para ser amigo do agente e amigo do provedor de pagamento: ele estende os protocolos existentes de agentes de IA para lidar com transações, e se sobrepõe às redes de pagamento existentes para utilizar sua infraestrutura, adicionando as garantias de confiança necessárias.

Considerações de Segurança, Conformidade e Interoperabilidade

Segurança e confiança estão no cerne do design do AP2. O uso de criptografia pelo protocolo (assinaturas digitais em mandatos) garante que cada ação crítica em uma transação agêntica seja verificável e rastreável. Essa não-repudiação é crucial: nem o usuário nem o comerciante podem negar posteriormente o que foi autorizado e acordado, já que os mandatos servem como registros seguros. Um benefício direto é na prevenção de fraudes e resolução de disputas – com o AP2, se um agente malicioso ou com bugs tentar uma compra não autorizada, a falta de um mandato válido assinado pelo usuário seria evidente, e a transação pode ser recusada ou revertida. Inversamente, se um usuário alegar “Eu nunca aprovei esta compra”, mas um Mandato de Carrinho existir com sua assinatura criptográfica, o comerciante e o emissor têm fortes evidências para apoiar a cobrança. Essa clareza de responsabilidade responde a uma grande preocupação de conformidade para a indústria de pagamentos.

Autorização e Privacidade: O AP2 impõe uma etapa (ou etapas) de autorização explícita do usuário para transações lideradas por agentes, o que se alinha às tendências regulatórias como a autenticação forte do cliente. O princípio de Controle do Usuário incorporado ao AP2 significa que um agente não pode gastar fundos a menos que o usuário (ou alguém delegado pelo usuário) tenha fornecido uma instrução verificável para fazê-lo. Mesmo em cenários totalmente autônomos, o usuário predefine as regras por meio de um Mandato de Intenção. Essa abordagem pode ser vista como análoga a conceder uma procuração ao agente para transações específicas, mas de forma digitalmente assinada e granular. Do ponto de vista da privacidade, o AP2 é cuidadoso com o compartilhamento de dados: o protocolo usa uma arquitetura de dados baseada em funções para garantir que informações sensíveis (como credenciais de pagamento ou detalhes pessoais) sejam compartilhadas apenas com as partes que absolutamente precisam delas. Por exemplo, um agente pode enviar um Mandato de Carrinho a um comerciante contendo informações de item e preço, mas o número real do cartão do usuário pode ser compartilhado apenas através do Mandato de Pagamento com o processador de pagamento, não com o agente ou comerciante. Isso minimiza a exposição desnecessária de dados, auxiliando na conformidade com as leis de privacidade e as regras PCI-DSS para o tratamento de dados de pagamento.

Conformidade e Padrões: Como o AP2 foi desenvolvido com a contribuição de entidades financeiras estabelecidas, ele foi projetado para atender ou complementar os padrões de conformidade existentes em pagamentos. O protocolo não ignora os fluxos usuais de autorização de pagamento – em vez disso, ele os aumenta com evidências e sinalizadores adicionais. Isso significa que as transações AP2 ainda podem aproveitar sistemas de detecção de fraude, verificações 3-D Secure ou quaisquer verificações regulatórias exigidas, com os mandatos do AP2 atuando como fatores de autenticação extras ou pistas de contexto. Por exemplo, um banco poderia tratar um Mandato de Pagamento como a assinatura digital de um cliente em uma transação, potencialmente simplificando a conformidade com os requisitos de consentimento do usuário. Além disso, os designers do AP2 mencionam explicitamente o trabalho “em conjunto com as regras e padrões da indústria”. Podemos inferir que, à medida que o AP2 evolui, ele pode ser levado a órgãos de padronização formais (como W3C, EMVCo ou ISO) para garantir que se alinhe aos padrões financeiros globais. O Google declarou compromisso com uma evolução aberta e colaborativa do AP2, possivelmente através de organizações de padronização. Esse processo aberto ajudará a resolver quaisquer preocupações regulatórias e a alcançar ampla aceitação, semelhante a como os padrões de pagamento anteriores (cartões com chip EMV, 3-D Secure, etc.) passaram por colaboração em toda a indústria.

Interoperabilidade: Evitar a fragmentação é um objetivo chave do AP2. Para isso, o protocolo é publicado abertamente e disponibilizado para qualquer pessoa implementar ou integrar. Não está vinculado aos serviços do Google Cloud – na verdade, o AP2 é código aberto (licença Apache-2) e a especificação, além do código de referência, está em um repositório público do GitHub. Isso incentiva a interoperabilidade porque vários fornecedores podem adotar o AP2 e ainda ter seus sistemas funcionando juntos. Já, o princípio da interoperabilidade é destacado: o AP2 é uma extensão de protocolos abertos existentes (A2A, MCP) e não é proprietário, o que significa que ele promove um ecossistema competitivo de implementações, em vez de uma solução de um único fornecedor. Em termos práticos, um agente de IA construído pela Empresa A poderia iniciar uma transação com um sistema de comerciante da Empresa B se ambos seguirem o AP2 – nenhum dos lados está preso a uma única plataforma.

Uma possível preocupação é garantir a adoção consistente: se alguns grandes players escolhessem um protocolo diferente ou uma abordagem fechada, a fragmentação ainda poderia ocorrer. No entanto, dada a ampla coalizão por trás do AP2, ele parece pronto para se tornar um padrão de fato. A inclusão de muitas empresas focadas em identidade e segurança (por exemplo, Okta, Cloudflare, Ping Identity) no ecossistema do AP2 Figura: Mais de 60 empresas de finanças, tecnologia e cripto estão colaborando no AP2 (lista parcial de parceiros). sugere que a interoperabilidade e a segurança estão sendo abordadas em conjunto. Esses parceiros podem ajudar a integrar o AP2 em fluxos de trabalho de verificação de identidade e ferramentas de prevenção de fraude, garantindo que uma transação AP2 possa ser confiável em todos os sistemas.

Do ponto de vista tecnológico, o uso de técnicas criptográficas amplamente aceitas pelo AP2 (provavelmente credenciais verificáveis baseadas em JSON-LD ou JWT, assinaturas de chave pública, etc.) o torna compatível com a infraestrutura de segurança existente. As organizações podem usar sua PKI (Infraestrutura de Chave Pública) existente para gerenciar chaves para assinar mandatos. O AP2 também parece antecipar a integração com sistemas de identidade descentralizada: o Google menciona que o AP2 cria oportunidades para inovar em áreas como identidade descentralizada para autorização de agentes. Isso significa que, no futuro, o AP2 poderia alavancar padrões DID (Identificador Descentralizado) ou verificação de identificador descentralizado para identificar agentes e usuários de forma confiável. Tal abordagem aprimoraria ainda mais a interoperabilidade, não dependendo de nenhum provedor de identidade único. Em resumo, o AP2 enfatiza a segurança através da criptografia e da responsabilidade clara, visa estar pronto para a conformidade por design e promove a interoperabilidade através de sua natureza de padrão aberto e amplo suporte da indústria.

Comparação com Protocolos Existentes

O AP2 é um protocolo inovador que aborda uma lacuna que os frameworks de pagamento e agentes existentes não cobriram: permitir que agentes autônomos realizem pagamentos de maneira segura e padronizada. Em termos de protocolos de comunicação de agentes, o AP2 se baseia em trabalhos anteriores como o protocolo Agent2Agent (A2A). O A2A (código aberto no início de 2025) permite que diferentes agentes de IA conversem entre si, independentemente de seus frameworks subjacentes. No entanto, o A2A por si só não define como os agentes devem conduzir transações ou pagamentos – é mais sobre negociação de tarefas e troca de dados. O AP2 estende esse cenário adicionando uma camada de transação que qualquer agente pode usar quando uma conversa leva a uma compra. Em essência, o AP2 pode ser visto como complementar ao A2A e ao MCP, em vez de sobreposto: o A2A cobre os aspectos de comunicação e colaboração, o MCP cobre o uso de ferramentas/APIs externas, e o AP2 cobre pagamentos e comércio. Juntos, eles formam uma pilha de padrões para uma futura “economia de agentes”. Essa abordagem modular é um tanto análoga aos protocolos de internet: por exemplo, HTTP para comunicação de dados e SSL/TLS para segurança – aqui o A2A pode ser como o HTTP dos agentes, e o AP2 a camada transacional segura por cima para o comércio.

Ao comparar o AP2 com protocolos e padrões de pagamento tradicionais, existem paralelos e diferenças. Pagamentos online tradicionais (checkouts de cartão de crédito, transações PayPal, etc.) tipicamente envolvem protocolos como HTTPS para transmissão segura, e padrões como PCI DSS para lidar com dados de cartão, além de possivelmente 3-D Secure para autenticação adicional do usuário. Estes assumem um fluxo impulsionado pelo usuário (o usuário clica e talvez insere um código único). O AP2, por outro lado, introduz uma maneira para um terceiro (o agente) participar do fluxo sem comprometer a segurança. Poderíamos comparar o conceito de mandato do AP2 a uma extensão da autoridade delegada no estilo OAuth, mas aplicada a pagamentos. No OAuth, um usuário pode conceder a um aplicativo acesso limitado a uma conta via tokens; similarmente no AP2, um usuário concede a um agente autoridade para gastar sob certas condições via mandatos. A principal diferença é que os “tokens” do AP2 (mandatos) são instruções específicas e assinadas para transações financeiras, o que é mais granular do que as autorizações de pagamento existentes.

Outro ponto de comparação é como o AP2 se relaciona com os fluxos de checkout de e-commerce existentes. Por exemplo, muitos sites de e-commerce usam protocolos como a API Payment Request do W3C ou SDKs específicos de plataforma para agilizar pagamentos. Estes padronizam principalmente como navegadores ou aplicativos coletam informações de pagamento de um usuário, enquanto o AP2 padroniza como um agente provaria a intenção do usuário a um comerciante e processador de pagamento. O foco do AP2 na intenção verificável e na não-repudiação o diferencia de APIs de pagamento mais simples. Ele está adicionando uma camada adicional de confiança sobre as redes de pagamento. Poderíamos dizer que o AP2 não está substituindo as redes de pagamento (Visa, ACH, blockchain, etc.), mas sim as aumentando. O protocolo suporta explicitamente todos os tipos de métodos de pagamento (até cripto), então trata-se mais de padronizar a interação do agente com esses sistemas, não de criar um novo trilho de pagamento do zero.

No domínio dos protocolos de segurança e autenticação, o AP2 compartilha algum espírito com coisas como assinaturas digitais em cartões com chip EMV ou a notarização em contratos digitais. Por exemplo, transações com cartão com chip EMV geram criptogramas para provar que o cartão estava presente; o AP2 gera prova criptográfica de que o agente do usuário foi autorizado. Ambos visam prevenir fraudes, mas o escopo do AP2 é o relacionamento agente-usuário e a comunicação agente-comerciante, o que nenhum padrão de pagamento existente aborda. Outra comparação emergente é com a abstração de contas em cripto (por exemplo, ERC-4337) onde os usuários podem autorizar ações de carteira pré-programadas. Carteiras de cripto podem ser configuradas para permitir certas transações automatizadas (como pagar automaticamente uma assinatura via um contrato inteligente), mas essas são tipicamente confinadas a um ambiente de blockchain. O AP2, por outro lado, visa ser multiplataforma – ele pode alavancar blockchain para alguns pagamentos (através de suas extensões), mas também funciona com bancos tradicionais.

Não há um protocolo “concorrente” direto ao AP2 na indústria de pagamentos mainstream ainda – parece ser o primeiro esforço concertado em um padrão aberto para pagamentos por agentes de IA. Tentativas proprietárias podem surgir (ou já podem estar em andamento dentro de empresas individuais), mas o amplo suporte do AP2 lhe dá uma vantagem para se tornar o padrão. Vale a pena notar que a IBM e outros têm um Protocolo de Comunicação de Agentes (ACP) e iniciativas semelhantes para interoperabilidade de agentes, mas estas não abrangem o aspecto de pagamento de forma tão abrangente quanto o AP2. Se houver, o AP2 pode se integrar ou alavancar esses esforços (por exemplo, os frameworks de agentes da IBM poderiam implementar o AP2 para quaisquer tarefas de comércio).

Em resumo, o AP2 se distingue por visar a intersecção única de IA e pagamentos: onde protocolos de pagamento mais antigos assumiam um usuário humano, o AP2 assume um intermediário de IA e preenche a lacuna de confiança resultante. Ele estende, em vez de conflitar, os processos de pagamento existentes e complementa os protocolos de agentes existentes como o A2A. No futuro, pode-se ver o AP2 sendo usado juntamente com padrões estabelecidos – por exemplo, um Mandato de Carrinho AP2 pode funcionar em conjunto com uma chamada de API de gateway de pagamento tradicional, ou um Mandato de Pagamento AP2 pode ser anexado a uma mensagem ISO 8583 em bancos. A natureza aberta do AP2 também significa que, se surgirem abordagens alternativas, o AP2 poderia potencialmente absorvê-las ou se alinhar a elas através da colaboração da comunidade. Nesta fase, o AP2 está estabelecendo uma base que não existia antes, efetivamente pioneirando uma nova camada de protocolo na pilha de IA e pagamentos.

Implicações para Web3 e Sistemas Descentralizados

Desde o início, o AP2 foi projetado para ser inclusivo de pagamentos baseados em Web3 e criptomoedas. O protocolo reconhece que o comércio futuro abrangerá tanto os canais fiduciários tradicionais quanto as redes blockchain descentralizadas. Como observado anteriormente, o AP2 suporta tipos de pagamento que vão desde cartões de crédito e transferências bancárias até stablecoins e criptomoedas. Na verdade, juntamente com o lançamento do AP2, o Google anunciou uma extensão específica para pagamentos cripto chamada A2A x402. Esta extensão, desenvolvida em colaboração com players da indústria cripto como Coinbase, Ethereum Foundation e MetaMask, é uma “solução pronta para produção para pagamentos cripto baseados em agentes”. O nome “x402” é uma homenagem ao código de status HTTP 402 “Payment Required”, que nunca foi amplamente utilizado na Web – a extensão cripto do AP2 efetivamente revive o espírito do HTTP 402 para agentes descentralizados que desejam cobrar ou pagar uns aos outros on-chain. Em termos práticos, a extensão x402 adapta o conceito de mandato do AP2 para transações blockchain. Por exemplo, um agente poderia manter um Mandato de Intenção assinado de um usuário e então executar um pagamento on-chain (digamos, enviar uma stablecoin) uma vez que as condições sejam atendidas, anexando a prova do mandato a essa transação on-chain. Isso une a estrutura de confiança off-chain do AP2 com a natureza sem confiança da blockchain, oferecendo o melhor dos dois mundos: um pagamento on-chain que partes off-chain (usuários, comerciantes) podem confiar que foi autorizado pelo usuário.

A sinergia entre AP2 e Web3 é evidente na lista de colaboradores. Exchanges de cripto (Coinbase), fundações blockchain (Ethereum Foundation), carteiras cripto (MetaMask) e startups Web3 (por exemplo, Mysten Labs da Sui, Lightspark para Lightning Network) estão envolvidas no desenvolvimento do AP2. Sua participação sugere que o AP2 é visto como complementar às finanças descentralizadas, em vez de competitivo. Ao criar uma maneira padrão para agentes de IA interagirem com pagamentos cripto, o AP2 pode impulsionar mais o uso de cripto em aplicações impulsionadas por IA. Por exemplo, um agente de IA pode usar o AP2 para alternar perfeitamente entre pagar com cartão de crédito ou pagar com uma stablecoin, dependendo da preferência do usuário ou da aceitação do comerciante. A extensão A2A x402 permite especificamente que os agentes monetizem ou paguem por serviços por meios on-chain, o que pode ser crucial em mercados descentralizados do futuro. Isso sugere que agentes possivelmente operando como atores econômicos autônomos em blockchain (um conceito que alguns se referem como DACs ou DAOs) serão capazes de lidar com pagamentos necessários para serviços (como pagar uma pequena taxa a outro agente por informações). O AP2 poderia fornecer a língua franca para tais transações, garantindo que, mesmo em uma rede descentralizada, o agente tenha um mandato comprovável para o que está fazendo.

Em termos de concorrência, poderíamos perguntar: soluções puramente descentralizadas tornam o AP2 desnecessário, ou vice-versa? É provável que o AP2 coexistirá com soluções Web3 em uma abordagem em camadas. As finanças descentralizadas oferecem execução sem confiança (contratos inteligentes, etc.), mas não resolvem inerentemente o problema de “Um IA teve permissão de um humano para fazer isso?”. O AP2 aborda exatamente esse elo de confiança humano-para-IA, que continua sendo importante mesmo que o pagamento em si seja on-chain. Em vez de competir com protocolos blockchain, o AP2 pode ser visto como uma ponte entre eles e o mundo off-chain. Por exemplo, um contrato inteligente pode aceitar uma determinada transação apenas se ela incluir uma referência a uma assinatura de mandato AP2 válida – algo que poderia ser implementado para combinar a prova de intenção off-chain com a execução on-chain. Inversamente, se houver frameworks de agentes cripto-nativos (alguns projetos blockchain exploram agentes autônomos que operam com fundos cripto), eles podem desenvolver seus próprios métodos de autorização. O amplo suporte da indústria ao AP2, no entanto, pode levar até mesmo esses projetos a adotar ou integrar-se ao AP2 para consistência.

Outro ângulo é a identidade e credenciais descentralizadas. O uso de credenciais verificáveis pelo AP2 está muito alinhado com a abordagem da Web3 para a identidade (por exemplo, DIDs e VCs padronizados pelo W3C). Isso significa que o AP2 poderia se conectar a sistemas de identidade descentralizada – por exemplo, o DID de um usuário poderia ser usado para assinar um mandato AP2, que um comerciante poderia verificar contra uma blockchain ou um hub de identidade. A menção de explorar a identidade descentralizada para autorização de agentes reforça que o AP2 pode alavancar inovações de identidade Web3 para verificar identidades de agentes e usuários de forma descentralizada, em vez de depender apenas de autoridades centralizadas. Este é um ponto de sinergia, pois tanto o AP2 quanto a Web3 visam dar aos usuários mais controle e prova criptográfica de suas ações.

Potenciais conflitos podem surgir apenas se alguém imaginar um ecossistema de comércio totalmente descentralizado sem papel para grandes intermediários – nesse cenário, o AP2 (inicialmente impulsionado pelo Google e parceiros) poderia ser muito centralizado ou governado por players tradicionais? É importante notar que o AP2 é de código aberto e destinado a ser padronizável, portanto, não é proprietário do Google. Isso o torna mais palatável para a comunidade Web3, que valoriza protocolos abertos. Se o AP2 for amplamente adotado, ele pode reduzir a necessidade de protocolos de pagamento específicos da Web3 separados para agentes, unificando assim os esforços. Por outro lado, alguns projetos blockchain podem preferir mecanismos de autorização puramente on-chain (como carteiras multi-assinatura ou lógica de custódia on-chain) para transações de agentes, especialmente em ambientes sem confiança e sem autoridades centralizadas. Essas poderiam ser vistas como abordagens alternativas, mas provavelmente permaneceriam nichadas, a menos que possam interagir com sistemas off-chain. O AP2, ao cobrir ambos os mundos, pode realmente acelerar a adoção da Web3 ao tornar a cripto apenas mais um método de pagamento que um agente de IA pode usar perfeitamente. De fato, um parceiro observou que “stablecoins fornecem uma solução óbvia para desafios de escalabilidade [para] sistemas agênticos com infraestrutura legada”, destacando que a cripto pode complementar o AP2 no tratamento de escala ou cenários transfronteiriços. Enquanto isso, o líder de engenharia da Coinbase observou que trazer a extensão cripto x402 para o AP2 “fez sentido – é um playground natural para agentes... emocionante ver agentes pagando uns aos outros ressoar com a comunidade de IA”. Isso implica uma visão onde agentes de IA transacionando via redes cripto não é apenas uma ideia teórica, mas um resultado esperado, com o AP2 atuando como um catalisador.

Em resumo, o AP2 é altamente relevante para a Web3: ele incorpora pagamentos cripto como um cidadão de primeira classe e está se alinhando com padrões de identidade e credenciais descentralizadas. Em vez de competir diretamente com protocolos de pagamento descentralizados, o AP2 provavelmente interoperará com eles – fornecendo a camada de autorização enquanto os sistemas descentralizados lidam com a transferência de valor. À medida que a linha entre finanças tradicionais e cripto se confunde (com stablecoins, CBDCs, etc.), um protocolo unificado como o AP2 poderia servir como um adaptador universal entre agentes de IA e qualquer forma de dinheiro, centralizada ou descentralizada.

Adoção da Indústria, Parcerias e Roteiro

Uma das maiores forças do AP2 é o extenso apoio da indústria por trás dele, mesmo nesta fase inicial. O Google Cloud anunciou que está “colaborando com um grupo diversificado de mais de 60 organizações” no AP2. Isso inclui grandes redes de cartão de crédito (por exemplo, Mastercard, American Express, JCB, UnionPay), líderes em fintech e processadores de pagamento (PayPal, Worldpay, Adyen, Checkout.com, concorrentes da Stripe), e-commerce e mercados online (Etsy, Shopify (via parceiros como Stripe ou outros), Lazada, Zalora), empresas de tecnologia empresarial (Salesforce, ServiceNow, Oracle possivelmente via parceiros, Dell, Red Hat), empresas de identidade e segurança (Okta, Ping Identity, Cloudflare), empresas de consultoria (Deloitte, Accenture), e organizações de cripto/Web3 (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark), entre outras. Uma gama tão ampla de participantes é um forte indicador do interesse da indústria e da provável adoção. Muitos desses parceiros expressaram publicamente seu apoio. Por exemplo, o Co-CEO da Adyen destacou a necessidade de um “livro de regras comum” para o comércio agêntico e vê o AP2 como uma extensão natural de sua missão de apoiar os comerciantes com novos blocos de construção de pagamento. O EVP da American Express afirmou que o AP2 é importante para “a próxima geração de pagamentos digitais” onde a confiança e a responsabilidade são primordiais. A equipe da Coinbase, como observado, está animada com a integração de pagamentos cripto no AP2. Esse coro de apoio mostra que muitos na indústria veem o AP2 como o provável padrão para pagamentos impulsionados por IA, e estão ansiosos para moldá-lo para garantir que atenda aos seus requisitos.

Do ponto de vista da adoção, o AP2 está atualmente na fase de especificação e implementação inicial (anunciado em setembro de 2025). A especificação técnica completa, a documentação e algumas implementações de referência (em linguagens como Python) estão disponíveis no GitHub do projeto para os desenvolvedores experimentarem. O Google também indicou que o AP2 será incorporado em seus produtos e serviços para agentes. Um exemplo notável é o AI Agent Marketplace mencionado anteriormente: esta é uma plataforma onde agentes de IA de terceiros podem ser oferecidos aos usuários (provavelmente parte do ecossistema de IA generativa do Google). O Google diz que muitos parceiros que constroem agentes os disponibilizarão no marketplace com “novas experiências transacionáveis habilitadas pelo AP2”. Isso implica que, à medida que o marketplace for lançado ou crescer, o AP2 será a espinha dorsal para qualquer agente que precise realizar uma transação, seja comprando software do Google Cloud Marketplace autonomamente ou um agente comprando bens/serviços para um usuário. Casos de uso empresariais como aquisição autônoma (um agente comprando de outro em nome de uma empresa) e escalonamento automático de licenças foram especificamente mencionados como áreas que o AP2 poderia facilitar em breve.

Em termos de roteiro, a documentação do AP2 e o anúncio do Google fornecem algumas indicações claras:

• Curto prazo: Continuar o desenvolvimento aberto do protocolo com a contribuição da comunidade. O repositório do GitHub será atualizado com implementações de referência adicionais e melhorias à medida que os testes no mundo real ocorrerem. Podemos esperar o surgimento de bibliotecas/SDKs, tornando mais fácil integrar o AP2 em aplicações de agentes. Além disso, programas piloto iniciais ou provas de conceito podem ser conduzidos pelas empresas parceiras. Dado que muitas grandes empresas de pagamento estão envolvidas, elas podem testar o AP2 em ambientes controlados (por exemplo, uma opção de checkout habilitada para AP2 em uma pequena versão beta para usuários).
• Padrões e Governança: O Google expressou o compromisso de mover o AP2 para um modelo de governança aberta, possivelmente através de órgãos de padronização. Isso pode significar submeter o AP2 a organizações como a Linux Foundation (como foi feito com o protocolo A2A) ou formar um consórcio para mantê-lo. A Linux Foundation, W3C ou até mesmo órgãos como ISO/TC68 (serviços financeiros) podem estar nos planos para formalizar o AP2. Uma governança aberta tranquilizaria a indústria de que o AP2 não está sob o controle de uma única empresa e permanecerá neutro e inclusivo.
• Expansão de Recursos: Tecnicamente, o roteiro inclui a expansão do suporte para mais tipos de pagamento e casos de uso. Como observado na especificação, após os cartões, o foco mudará para pagamentos “push” como transferências bancárias e esquemas de pagamento locais em tempo real, e moedas digitais. Isso significa que o AP2 delineará como um Mandato de Intenção/Carrinho/Pagamento funciona para, digamos, uma transferência bancária direta ou uma transferência de carteira cripto, onde o fluxo é um pouco diferente das retiradas de cartão. A extensão A2A x402 é uma dessas expansões para cripto; da mesma forma, podemos ver uma extensão para APIs de open banking ou uma para cenários de faturamento B2B.
• Aprimoramentos de Segurança e Conformidade: À medida que as transações reais começarem a fluir através do AP2, haverá escrutínio de reguladores e pesquisadores de segurança. O processo aberto provavelmente iterará para tornar os mandatos ainda mais robustos (por exemplo, garantindo que os formatos de mandato sejam padronizados, possivelmente usando o formato W3C Verifiable Credentials, etc.). A integração com soluções de identidade (talvez alavancando biometria para a assinatura de mandatos pelo usuário, ou vinculando mandatos a carteiras de identidade digital) pode fazer parte do roteiro para aumentar a confiança.
• Ferramentas do Ecossistema: Um ecossistema emergente é provável. Já, startups estão percebendo lacunas – por exemplo, a análise da Vellum.ai menciona uma startup chamada Autumn construindo “infraestrutura de faturamento para IA”, essencialmente ferramentas sobre o Stripe para lidar com preços complexos para serviços de IA. À medida que o AP2 ganhar tração, podemos esperar mais ferramentas como gateways de pagamento focados em agentes, painéis de gerenciamento de mandatos, serviços de verificação de identidade de agentes, etc., aparecerem. O envolvimento do Google significa que o AP2 também pode ser integrado em seus produtos Cloud – imagine o suporte AP2 em ferramentas Dialogflow ou Vertex AI Agents, tornando-o um clique para permitir que um agente lide com transações (com todas as chaves e certificados necessários gerenciados no Google Cloud).

No geral, a trajetória do AP2 lembra outros grandes padrões da indústria: um lançamento inicial com um forte patrocinador (Google), ampla coalizão da indústria, código de referência de código aberto, seguido por melhorias iterativas e adoção gradual em produtos reais. O fato de o AP2 convidar todos os players “a construir este futuro conosco” ressalta que o roteiro é sobre colaboração. Se o impulso continuar, o AP2 poderá se tornar tão comum em alguns anos quanto protocolos como OAuth ou OpenID Connect são hoje em seus domínios – uma camada invisível, mas crítica, que permite a funcionalidade entre serviços.

Conclusão

O AP2 (Protocolo de Pagamentos por Agente) representa um passo significativo em direção a um futuro onde agentes de IA podem transacionar de forma tão confiável e segura quanto os humanos. Tecnicamente, ele introduz um mecanismo inteligente de mandatos e credenciais verificáveis que instilam confiança em transações lideradas por agentes, garantindo que a intenção do usuário seja explícita e aplicável. Sua arquitetura aberta e extensível permite que ele se integre tanto aos crescentes frameworks de agentes de IA quanto à infraestrutura financeira estabelecida. Ao abordar as principais preocupações de autorização, autenticidade e responsabilidade, o AP2 estabelece as bases para que o comércio impulsionado por IA floresça sem sacrificar a segurança ou o controle do usuário.

A introdução do AP2 pode ser vista como o estabelecimento de uma nova fundação – muito parecido com os primeiros protocolos da internet que habilitaram a web – para o que alguns chamam de “economia de agentes”. Ele abre caminho para inúmeras inovações: agentes de compras pessoais, bots de busca automática de ofertas, agentes autônomos de cadeia de suprimentos e muito mais, todos operando sob uma estrutura de confiança comum. Importante, o design inclusivo do AP2 (abrangendo tudo, desde cartões de crédito até cripto) o posiciona na interseção das finanças tradicionais e da Web3, potencialmente unindo esses mundos através de um protocolo comum mediado por agentes.

A resposta da indústria até agora tem sido muito positiva, com uma ampla coalizão sinalizando que o AP2 provavelmente se tornará um padrão amplamente adotado. O sucesso do AP2 dependerá da colaboração contínua e de testes no mundo real, mas suas perspectivas são fortes dada a clara necessidade que ele aborda. Em um sentido mais amplo, o AP2 exemplifica como a tecnologia evolui: uma nova capacidade (agentes de IA) surgiu que quebrou velhas suposições, e a solução foi desenvolver um novo padrão aberto para acomodar essa capacidade. Ao investir em um protocolo aberto e com segurança em primeiro lugar agora, o Google e seus parceiros estão efetivamente construindo a arquitetura de confiança necessária para a próxima era do comércio. Como diz o ditado, “a melhor maneira de prever o futuro é construí-lo” – o AP2 é uma aposta em um futuro onde agentes de IA lidam perfeitamente com transações para nós, e está ativamente construindo a confiança e as regras necessárias para tornar esse futuro viável.

Fontes:

• Blog do Google Cloud – “Impulsionando o comércio de IA com o novo Protocolo de Pagamentos por Agente (AP2)” (16 de setembro de 2025)
• Documentação do AP2 no GitHub – “Especificação e Visão Geral do Protocolo de Pagamentos por Agente”
• Blog da Vellum AI – “AP2 do Google: Um novo protocolo para pagamentos de agentes de IA” (Análise)
• Artigo do Medium – “Protocolo de Pagamentos por Agente (AP2) do Google” (Resumo por Tahir, setembro de 2025)
• Citações de Parceiros sobre o AP2 (Blog do Google Cloud)
• Extensão A2A x402 (extensão de pagamentos cripto do AP2) – README do GitHub