Quando Agentes de IA Comecam a Comprar, Quem Responde pelo Chargeback?

Trust Orchestration, alocacao de responsabilidade e o futuro das disputas no agentic commerce

A. Executive Summary

O agentic commerce representa a maior descontinuidade estrutural no ecossistema de pagamentos desde a digitalização do checkout. Quando um agente de inteligência artificial executa uma compra em nome de um consumidor, o modelo de quatro partes que sustenta o processamento de cartões há décadas ganha um quinto participante, um que não tem identidade financeira própria, não possui conta bancária, não assina contratos e, até este momento, não responde por chargebacks.

Este relatório examina a questão central: quando a compra não é iniciada diretamente por um humano, mas por um agente autônomo operando com credenciais delegadas, quem absorve a responsabilidade quando há disputa? A resposta é estruturalmente complexa e comercialmente urgente.

O que encontramos:

1. O merchant carrega o risco por padrao. Sob as regras atuais de Visa e Mastercard, quando o consumidor abre uma disputa sobre compra feita por agente, o merchant é o último elo da cadeia de responsabilidade. Bandeiras de cartao não absorvem, issuers não absorvem, e provedor do agentes não estão na cadeia contratual do pagamento.

2. Os frameworks de evidência quebram. Visa Compelling Evidence 3.0 exige match de device ID e IP address entre transações. Compras por agentes usam IPs de data centers e device IDs de infraestrutura cloud. A defesa mais poderosa do merchant em disputas torna-se inaplicável.

3. O problema é evidenciário antes de ser de pagamento. O desafio não é processar a transação, é provar que o agente estava autorizado a executar exatamente aquela ação, dentro daqueles limites, naquele contexto. Agentic commerce cria um evidentiary gap antes de criar um payment gap.

4. Novos protocolos estão emergindo rapidamente. Visa Trusted Agent Protocol, Mastercard Agent Pay, Google AP2, Stripe ACP e o Universal Commerce Protocol representam os primeiros frameworks para trust orchestration. Nenhum está completo. Nenhum resolve integralmente a questão de chargebacks.

5. O mercado é massivo e iminente. McKinsey projeta US$ 3-5 trilhões em agentic commerce global até 2030. Bain estima US$ 300-500 bilhões só nos EUA. Morgan Stanley projeta 10-20% do e-commerce americano operado por agentes. Este não é um cenário futuro, é uma realidade operacional que já movimenta bilhões.

Recomendação central: Merchants, PSPs, acquirers e issuers devem construir uma camada de Trust Orchestration, que não apenas executa pagamentos, mas comprova quem iniciou, com qual permissão, em quais limites, sob qual política e com que evidências. Quem construir essa infraestrutura primeiro terá vantagem competitiva estrutural.

B. Por Que Isso Importa Agora

O agentic commerce deixou de ser conceito e tornou-se infraestrutura. Em dezembro de 2025, Stripe lançou seu Agentic Commerce Suite com integração a Wix, WooCommerce, BigCommerce e Squarespace. No mesmo mês, Visa apresentou seu Trusted Agent Protocol com mais de 100 parceiros. A Mastercard expandiu o Agent Pay para todos os portadores nos EUA. O PayPal tornou-se agent ready para merchants existentes. O Google lançou o Universal Commerce Protocol com mais de 20 parceiros globais incluindo Walmart, Target, Etsy e Shopify.

A escala do fenômeno

Durante o Cyber Week de 2025, uma em cada cinco compras online envolveu um agente de IA, representando aproximadamente US$ 70 bilhões em GMV. A Visa reportou crescimento de 1.200% ano sobre ano no tráfego de agentes de IA em sites de varejo. O volume de queries de AI shopping cresceu 4.700% entre julho de 2024 e julho de 2025.

Estes números indicam uma curva de adoção exponencial que ultrapassa qualquer previsão anterior. A questão não é se o agentic commerce transformará o ecossistema de pagamentos, mas se o ecossistema estará preparado quando a escala atingir massa crítica.

O timing regulatório

Nenhuma jurisdição no mundo promulgou legislação específica para agentic commerce. O EU AI Act, a regulação de IA mais ambiciosa do mundo, anterior à tecnologia, não contém provisões específicas para agentes autônomos de compra. O NIST lançou sua AI Agent Standards Initiative em janeiro de 2026. A PSD3, que potencialmente formalizará delegação de pagamento para agentes, está prevista para 2026-2027. A Nova Diretiva de Responsabilidade por Produtos da UE, que explicitamente inclui software e IA como produtos, tem prazo de implementação em dezembro de 2026.

Existe uma janela de 12 a 24 meses na qual empresas visionárias podem construir Trust Orchestration antes que reguladores definam standards obrigatórios. Quem se mover primeiro definirá o padrão de mercado.

C. Contexto e Dimensionamento de Mercado

Projeções de mercado convergentes

As principais firmas de estratégia e análise convergem em uma conclusão: o agentic commerce será uma parcela material do e-commerce global até 2030. As estimativas variam em magnitude, mas não em direção.

Mercado atual e velocidade de adoção

O mercado de infraestrutura de agentic commerce foi avaliado em US$ 547,3 milhões em 2025 e deve atingir US$ 5,2 bilhões até 2033, com CAGR de 32,5%. O mercado mais amplo de agentes de IA alcançou US$ 7,63 bilhões em 2025, com projeção de US$ 182,97 bilhões até 2033 (CAGR de 49,6%).

Plataformas de IA já devem representar 1,5% das vendas de e-commerce nos EUA em 2026, correspondendo a US$ 20,57 bilhões, quase quadruplicando os números de 2025. A adoção entre consumidores de 18 a 34 anos é particularmente acelerada: 59% se declaram confortáveis com agentes de IA comprando em seu nome.

Implicações para chargebacks

Se mesmo 1% das transações agentic gerarem disputa nos próximos 24 meses, o volume absoluto de chargebacks em canais sem evidência adequada será material. Chargebacks globais já devem atingir 337 milhões em 2026, custando ao e-commerce US$ 33,79 bilhões. A adição de um novo vetor de disputa, a compra agentic sem trilha de evidência clara, pode acelerar esse crescimento de forma significativa.

D. O Modelo Emergente de Transacao em Agentic Commerce

Do modelo de quatro partes ao de cinco partes

O ecossistema de pagamentos com cartão opera há décadas sob um modelo de quatro partes: cardholder, issuer, acquirer e merchant. A introdução do agente de IA como initiating party cria um quinto participante que não se enquadra em nenhuma das categorias existentes. O agente não é o cardholder, embora use suas credenciais. Não é o merchant, embora negocie com ele. Não é um PSP, embora inicie o pagamento. Não é um acquirer, embora processe a transação tecnicamente. É uma entidade nova com responsabilidades indefinidas.

A cadeia de autorização se fragmenta

No modelo tradicional, a cadeia de autorização é simples: humano decide, humano autentica, humano autoriza, transação é executada. No modelo agentic, essa cadeia se fragmenta em múltiplas camadas:

Protocolos emergentes

Cinco protocolos principais estão disputando a padronização do agentic commerce:

Visa Trusted Agent Protocol: Framework ecossistêmico com verificação criptográfica de agentes, desenvolvido com Cloudflare, Adyen, Shopify e Stripe. Cada requisição é criptograficamente vinculada ao site do merchant e página específica.

Mastercard Agent Pay: Framework de tokens agentic dinâmicos baseado em tokenização. Cada agente recebe identificação única e credenciais criptograficamente seguras. Inclui Web Bot Auth para verificação na camada de CDN.

Google Agent Payments Protocol (AP2): Protocolo aberto com Verifiable Digital Credentials (VDCs) e três tipos de mandatos: Intent Mandate, Cart Mandate e Payment Mandate. Cria prova criptográfica não-repudiável de intenção do usuário.

Stripe Agentic Commerce Protocol (ACP): Padrão aberto para conexão entre merchants e ChatGPT. Merchants autenticam cada requisição, verificam assinaturas e forçam idempotency.

Google Universal Commerce Protocol (UCP): Padrão aberto compatível com AP2 e MCP, cobrindo toda a jornada do cliente: discovery, buying, post-purchase support.

E. Como Chargebacks Funcionam Hoje vs. Como Quebram no Agentic Commerce

O processo de disputa atual

O chargeback é um mecanismo de reversão de pagamento iniciado pelo issuer em nome do cardholder. O processo segue etapas bem definidas: o cardholder contesta junto ao issuer usando um codigo de motivo; o issuer inicia o chargeback junto ao acquirer do merchant; o merchant tem aproximadamente 45 dias calendário para submeter representment com evidências; se contestado, o caso pode escalar para arbitration na card network.

Codigo de motivos e sua aplicabilidade agentic

Os codigo de motivos atuais foram criados para transações humano-merchant. Quando aplicados a compras agentic, lacunas críticas emergem:

O colapso do Visa Compelling Evidence 3.0

O Visa CE 3.0 é a ferramenta mais poderosa de defesa do merchant em disputas de fraude. Ele requer que o merchant apresente pelo menos 2 transações anteriores não-disputadas (120-365 dias) com pelo menos 2 data points correspondentes: device ID, IP address, email, shipping address, login credentials ou telefone.

Em transações agentic, o CE 3.0 se torna inaplicável: Device IDs não correspondem entre transações humanas e de agente. IPs são de data centers, não do consumidor. A behavioral biometrics desaparece. O merchant perde sua principal arma de defesa.

Sinais de fraude que desaparecem

Modelos legados de fraude dependem inteiramente de sinais comportamentais humanos. Quando um agente de IA executa uma transação a partir de um IP de data center, os sistemas de scoring tradicionais não conseguem diferenciar atividade legítima de agente de contas comprometidas ou bots fraudulentos. Device fingerprints, IP geolocation, session duration, click cadence e behavioral biometrics tornam-se irrelevantes.

F. Mapa de Responsabilidade no Ecossistema

Stack de Responsabilidade em Agentic Commerce

Desenvolvemos o Stack de Responsabilidade em Agentic Commerce, um framework proprietário que mapeia responsabilidade por camada na cadeia de valor de uma transação agentic:

Quem paga hoje?

Na ausência de implementação dos novos protocolos, a resposta é inequívoca: o merchant. Bandeiras de cartao não absorverão responsabilidade por transações de agentes que não autorizaram explicitamente. Portadores de cartao não absorverão, dado que sua responsabilidade é limitada por lei (US$ 50 sob FCBA, proteções similares sob PSD2). Issuers não absorverão, pois repassam ao acquirer via processo de chargeback. Provedor do agentes não estão na cadeia contratual do pagamento. As perdas fluem para o acquirer do merchant e, ultimamente, para o merchant.

Modelos de responsabilidade compartilhada emergentes

Mastercard Agent Pay: Assume responsabilidade por falhas de validação da network na autenticação, autorização ou validação de token. Responsabilidade do cardholder limitada a cenários de autorização negligente de agente. Merchant permanece responsável pela integridade da transação dentro do escopo do agente.

Visa Trusted Agent Protocol: Transferencia de responsabilidade similar: networks responsáveis por falhas de validação do protocolo. Merchants responsáveis pelo gerenciamento de permissões do agente.

Mastercard Verifiable Intent: Anunciado em março de 2026, cria prova tamper-resistant da autorização do consumidor vinculando identidade, instruções ao agente e transação resultante em um único registro verificável. O consumidor recebe push notification com contexto completo antes da autorização.

Ponto critico: regras de seguranca, responsabilidade e disputa permanecem indefinidas enquanto os pilotos se expandem. Estes frameworks são propostas emergentes, não padrões finalizados.

G. Cenarios de Disputa e Casos Criticos

Cenário 1: Reorder de supermercado com substituição premium

Situacao: Consumidor pede ao agente para recomprar mantimentos habituais. O agente identifica que o leite orgânico preferido está indisponível e substitui por uma versão premium a preço 40% superior. Consumidor abre disputa.

Codigo de motivo provável: Visa 13.3 (Not as Described) ou MC 4853.

Problema evidenciario: O agente tinha autoridade para substituir? Havia policy de preço máximo? O consumidor aprovou a substituição? Sem registro de politicas e rastro de consentimento, o merchant não tem defesa.

Responsabilidade provavel: Merchant, a menos que possa demonstrar consent do consumidor para substituições e que a substituição estava dentro de parâmetros aceitáveis.

Cenário 2: AI shopping assistant em marketplace

Situacao: Agente de IA compra em marketplace de seller terceiro. Produto chega diferente do esperado.

Problema: Três partes potencialmente responsáveis: provedor do agente (escolheu o seller), marketplace (hospedou o listing), seller (forneceu o produto). Nenhum framework atual define claramente a alocação de responsabilidade neste cenário triplamente intermediado.

Cenário 3: Renovação automática ou upsell por agente

Situacao: Agente identifica que subscription de software está próxima do vencimento e renova automaticamente, incluindo upgrade para tier superior baseado em padrões de uso.

Problema: Visa 13.2 (Canceled Recurring) ou 13.3 (Not as Described). A renovação estava no escopo? O upgrade? Diferenciação entre recurring transaction (MIT) e agent-initiated upsell (nova ação) é crítica.

Cenário 4: Reserva de viagem não reembolsável

Situacao: Agente de viagem reserva tarifa não reembolsável com base em preferências inferidas. Consumidor disputa.

Problema: Alto valor, irreversibilidade e inferiência de preferências criam risco máximo. Sem confirmação explícita do consumidor para a tarifa específica, o merchant (companhia aérea/hotel) fica extremamente exposto.

Cenário 5: Compra B2B por procurement bot

Situacao: Agent de procurement compra suprimentos dentro de budget aprovado, mas de fornecedor não homologado.

Problema: Politica de gastos cumprida (valor), politica de fornecedores violada (fornecedor). A distinção entre compliance de valor e compliance de política é granular e requer motor de politicas sofisticado.

Cenário 6: Prompt ambíguo com interpretação errônea

Situacao: Consumidor diz compre algo bom para o jantar. Agente interpreta como delivery de restaurante premium. Consumidor esperava ingredientes para cozinhar.

Problema: A ambiguidade do prompt cria um disputa por alucinacao. Não é fraude, não é erro técnico, é gap de interpretação. Nenhum codigo de motivo atual cobre adequadamente este cenário.

Cenário 7: Agente comprometido ou manipulado

Situacao: Agente é manipulado via prompt injection ou API spoofing para realizar compras não autorizadas.

Problema: MC 4837 (No Cardholder Authorization) se aplica, mas quem é responsável pela segurança do agente? Provedor do agente por vulnerabilidade? Merchant por aceitar transação de agente comprometido? Consumer por usar agente inseguro?

Cenário 8: Multi-agent chain

Situacao: Agente de planejamento decide que consumidor precisa de novo fone de ouvido e delega a compra a um agente de shopping. O agente de shopping escolhe e compra autonomamente.

Problema: A cadeia de delegação se estende por múltiplos agentes. O consent do consumidor cobriu toda a cadeia? A motor de politicas do primeiro agente vincula o segundo? Não existe framework para delegacao em cadeia em pagamentos.

Cenário 9: Shared account em contexto familiar

Situacao: Dispositivo compartilhado com agente configurado. Membro da família usa o agente para comprar usando credenciais do titular.

Problema: UETA define que o empregador de uma ferramenta é responsável pelos resultados. Mas em contexto familiar, quem é o principal? O titular do cartão pode disputar alegando que não foi ele quem instruiu o agente?

H. Implicacoes Legais, Compliance e Regras de Bandeira

O gap entre payment authorization e authorization to act

O conceito mais crítico neste relatório é a distinção entre dois significados da palavra autorização que até agora eram tratados como sinônimos:

Payment authorization: A confirmação de que informações de pagamento foram verificadas e que o pagamento pode ser feito. Foco: Has the payment information been verified?

Authorization to act (agency sense): A confirmação de que o agente tinha permissão do principal para executar aquela ação específica. Foco: Did the principal authorize the agent to make this purchase?

Um agente de IA pode executar uma authorized transaction (network aprova) que não era uma authorized action (principal não autorizou aquela compra específica). Os frameworks regulatórios atuais conflam esses conceitos no nível de responsabilidade.

Regulation E e EFTA

O Electronic Fund Transfer Act define transferência eletrônica não autorizada como aquela iniciada por pessoa que não o consumidor sem autoridade real para iniciar a transferência e da qual o consumidor não recebe benefício. A proliferação de ferramentas de IA tem o potencial de aumentar dramaticamente a responsabilidade dos bancos sob EFTA e Regulation E. A questão central: uma transação agentic de IA é autorizada pelo consumidor?

A responsabilidade do consumidor é limitada a US$ 50 para cobranças não autorizadas, com prazo de 60+ dias para disputar. O CFPB determinou que negligência do consumidor não pode servir de base para impor responsabilidade maior do que a permitida pela Regulation E.

EU AI Act e Diretivas correlatas

A EU AI Act exige supervisão humana efetiva para agentes de IA, particularmente para decisões com consequências significativas. Traders permanecem integralmente responsáveis por todas as comunicações com consumidores, incluindo aquelas conduzidas por chatbots de IA. A AI Liability Directive reduz incerteza jurídica e garante que vítimas possam buscar reparação efetiva. A Revised Product Liability Directive inclui explicitamente software e IA como produtos com responsabilidade objetiva por defeitos.

PCI DSS para agentes de IA

O PCI Security Standards Council publicou princípios específicos para uso de IA em ambientes de pagamento. Agentes de IA devem ter credenciais próprias rastreáveis e revogáveis, vinculadas ao sistema de IA específico. LLMs nunca devem tocar dados sensíveis de cartão. Operações de pagamento devem usar credenciais tokenizadas com tokens encriptados em repouso. Organizações frequentemente asseguram IDs de funcionários mas negligenciam o que um agente de IA pode acessar ou executar, criando agentes com privilégios excessivos.

I. Framework de Trust Orchestration

Definição

Trust Orchestration é uma camada de infraestrutura que não apenas executa pagamentos, mas comprova quem iniciou a transação, com qual permissão, em quais limites, sob qual política e com que evidências. Não é branding, não é compliance checkbox, é infraestrutura técnica e operacional que gera evidência defensável em tempo real.

Trust Orchestration Maturity Model

Desenvolvemos um modelo de maturidade em cinco níveis que permite que organizações avaliem sua prontidão e planejem evolução incremental:

Arquitetura de referência

Uma arquitetura de Trust Orchestration de referência deve conter seis componentes integrados:

1. Identity & Delegation Layer: Verificação de identidade do agente, registro de delegação, credenciais vinculadas. Integração com OIDC-A, Visa Trusted Agent Protocol e Mastercard Agent Pay.

2. Policy Engine: Motor de regras que define e aplica spending limits, merchant categories, product categories, valor máximo por transação, frequência e whitelists/blacklists. Deve suportar policy hierarchies para multi-agent chains.

3. Consent Management: Captura granular de consentimento com timestamps, escopo, duração e revogação. Princípio de menor privilégio: agente recebe apenas permissões necessárias para a ação planejada.

4. Evidence Generation Engine: Geração automática de trilha de evidências em cada etapa: intent capture, delegation proof, authentication log, authorization record, policy check result, execution confirmation.

5. Dispute Defense Module: Empacota evidências automaticamente no formato exigido por cada card network para representment. Mapeia evidence disponível para codigo de motivos específicos.

6. Monitoring & Analytics: Dashboards em tempo real de agent activity, policy violations, dispute rates, evidence completeness scores.

Chargeback Evidence Gap Matrix

O framework abaixo cruza cenários de disputa com evidência disponível e gaps operacionais:

J. Implicacoes para o Modelo Operacional de Merchants e PSPs

Para Merchants

Dispute Operations: Equipes de chargeback precisarão de novas competências: compreensão de agent protocols, capacidade de extrair e interpretar registro de politicass e delegation proofs, e habilidade para construir evidence packages com dados não tradicionais. O volume de disputas com evidência insuficiente tende a crescer significativamente.

Fraud Tooling: Ferramentas de fraude legadas baseadas em device fingerprint e behavioral biometrics perderão eficácia. Intent consistency, verificada contra histórico comportamental do cardholder, emerge como o sinal primário. A Riskified e Signifyd já estão adaptando modelos para scoring agentic.

Terms and Conditions: T&Cs de merchants precisam ser atualizados para endereçar explicitamente compras por agentes de IA. A Target já reescreveu seus termos de serviço para permitir que agentes comprem em nome do consumidor, transferindo risco para o varejista. Este é um modelo clean but aggressive de transferência de risco.

Evidence Management: Merchants precisarão de infrastructure dedicada para capturar, armazenar e recuperar agent logs, timestamps de autorização, policy check results e delegation proofs. Cada dólar investido em prevenção economiza US$ 5-7 em custos de disputa.

Para PSPs e Acquirers

Protocol Integration: PSPs precisam suportar múltiplos protocolos agentic (AP2, Visa TAP, Mastercard Agent Pay, ACP) simultaneamente. Stripe já lançou Shared Payment Tokens (SPTs) com suporte a todos os principais protocolos. A Adyen lançou o Universal Token Vault.

Risk Scoring Evolution: Modelos de risk scoring precisam ser redesenhados para incorporar sinais agentic: agent authentication credentials, permission alignment, request signature validity, API header patterns. A Stripe Radar reporta 38% de redução média em fraude com seus novos modelos.

Merchant Enablement: PSPs que oferecerem ferramentas de Trust Orchestration como serviço criarão vantagem competitiva significativa. A camada de orquestração de pagamentos está se tornando a camada de confiança neutra do ecossistema.

K. Arquitetura de Controle e Evidencia

Controles pré-transação

Agent Registration & Verification: Todo agente deve ser registrado e verificado antes de poder transacionar. Mastercard Agent Pay e Visa TAP implementam este controle. Agentes não registrados devem ser bloqueados.

Consent Capture: Captura granular de consentimento com scope explícito: categorias de produto, faixa de preço, merchants permitidos, frequência, duração da autorização. Deve ser machine-readable e auditable.

Policy Definition: Regras de negócio codificadas em motor de politicas: spending limits por transação e período, merchant category restrictions, product category restrictions, geographic restrictions.

Controles durante a transação

Real-time Policy Check: Cada transação deve ser validada contra motor de politicas antes de autorização. Transações fora do escopo devem ser escaladas para human-in-the-loop ou rejeitadas.

Cryptographic Signing: Cada etapa da transação deve gerar assinatura criptográfica vinculando identidade do agente, permissões e ação executada. AP2 Payment Mandates fornecem este mecanismo.

Human-in-the-Loop Escalation: Para transações acima de thresholds definidos ou fora de categories aprovadas, o sistema deve exigir confirmação humana antes de prosseguir. Mastercard Verifiable Intent implementa push notification pré-autorização.

Controles pós-transação

Immutable Audit Trail: Registro imutável de toda a cadeia: intent, delegation, authentication, policy check, authorization, execution, fulfillment. Uma vez registrado, não pode ser alterado sem gerar trail adicional.

Evidence Packaging: Sistema automatizado que empacota evidências no formato exigido por cada card network. Deve mapear evidence disponível para codigo de motivos específicos.

Continuous Monitoring: Dashboards de agent behavior, policy violations, dispute rates e evidence completeness. Detecção de anomalias em padrões de compra do agente.

L. Recomendacoes Estrategicas por Stakeholder

Para Merchants

Now (0-6 meses): Atualizar T&Cs para endereçar compras agentic. Implementar consent capture básico. Iniciar captura de agent transaction logs. Treinar equipe de disputes em protocolos agentic. Mapear exposure atual em categorias de alto risco (grocery reorder, subscription, travel).

Next (6-12 meses): Integrar com pelo menos um protocolo agentic (AP2, Visa TAP ou Mastercard Agent Pay). Implementar motor de politicas básico. Redesenhar fraud scoring para sinais agentic. Construir evidence management automatizado.

Later (12-24 meses): Atingir Level 4 do Trust Orchestration Maturity Model. Implementar cryptographic mandates end-to-end. Desenvolver dispute defense automatizado. Considerar Trust Orchestration como serviço para sellers em marketplace.

Para PSPs e Acquirers

Now: Suportar Shared Payment Tokens e agentic tokens. Iniciar certificação em protocolos agentic. Adaptar risk scoring para sinais de agente.

Next: Lançar Trust Orchestration como produto/serviço. Integrar múltiplos protocolos simultaneamente. Oferecer evidence packaging automatizado.

Later: Construir dispute analytics preditivo. Implementar cross-agent governance. Posicionar-se como neutral trust layer do ecossistema.

Para Issuers

Now: Definir políticas de agent registration para portadores de cartao. Preparar infraestrutura para Verifiable Intent (Mastercard).

Next: Implementar push notification pré-autorização para transações agentic. Desenvolver agent management no app do cardholder.

Later: Oferecer agent liability products. Considerar agent insurance como produto financeiro.

Para Card Networks

Now: Finalizar regras de disputa específicas para transações agentic. Definir novos codigo de motivos para agent-specific disputes. Atualizar CE 3.0 para acomodar sinais agentic.

Next: Implementar transferencia de responsabilidade claro para transações com full protocol compliance. Criar certification program para provedor do agentes.

Later: Estabelecer interoperability standards entre protocolos. Desenvolver network-level agent scoring.

Para Agent Providers

Now: Implementar motor de politicas robusto com spending limits, merchant restrictions e scope controls. Gerar logs detalhados de decisão do agente. Integrar com pelo menos um protocolo de pagamento agentic.

Next: Implementar cryptographic signing de ações do agente. Desenvolver consent management granular com revogação em tempo real.

Later: Oferecer trust scores para merchants e networks. Construir multi-agent governance framework. Considerar liability-sharing arrangements com merchants.

M. 12-24 Month Outlook

Q2-Q3 2026: Consolidação de protocolos

Os cinco protocolos agentic (Visa TAP, Mastercard Agent Pay, AP2, ACP, UCP) entrarão em fases de implementação mais amplas. Espera-se convergência em torno de dois ou três padrões dominantes. A compatível com AP2 do Google deve ganhar tração significativa dado o ecossistema de parceiros (Mastercard, PayPal, American Express, Shopify, Etsy).

Q4 2026: Primeiros chargebacks agentic em escala

Com o crescimento exponencial de transações agentic durante a temporada de festas de 2026, os primeiros chargebacks agentic em volume significativo devem surgir. Merchants sem infraestrutura de Trust Orchestration terão dificuldade extrema em defender disputas. Espera-se pressão das bandeiras de cartao para definição de regras específicas.

H1 2027: Regulamentação toma forma

A implementação da PSD3 na Europa e da Nova Diretiva de Responsabilidade por Produtos deve formalizar regras para transações agentic. Nos EUA, o resultado da AI Agent Standards Initiative do NIST e possíveis ações do CFPB devem criar o primeiro framework regulatório federal.

Projeções quantitativas

Quem ganha vantagem competitiva

Empresas que construírem trust infrastructure antes do mercado amadurecer terão vantagem estrutural em três dimensões: menor taxa de chargebacks (redução de custos), maior taxa de aceitação de transações agentic (aumento de receita), e posição regulatória favorável (compliance antecipado).

Stripe, Adyen e Mastercard estão melhor posicionados no lado da infraestrutura. Entre merchants, aqueles com operações de grocery e CPG (como Walmart e Target) têm o incentivo mais imediato dado o perfil de suas transações. Entre provedor do agentes, OpenAI (via ChatGPT + Stripe) e Google (via Gemini + AP2) lideram em escala e integração vertical com protocolos de pagamento.

N. Appendices

Appendix A: Responsibility Allocation Matrix

Para cada cenário de disputa, a matriz identifica as partes responsáveis em cada dimensão:

Appendix B: Glossary

Agentic Commerce: Modelo de comércio onde agentes de IA autônomos executam transações comerciais em nome de consumidores ou empresas.

Trust Orchestration: Camada de infraestrutura que comprova autorização, intenção, permissão e evidência em transações agentic.

Shared Payment Token (SPT): Primitiva de pagamento criada pela Stripe que permite que agentes de IA transacionem com credenciais de pagamento scoped.

Verifiable Digital Credential (VDC): Objeto digital criptograficamente assinado que rastreia a cadeia de autorização em transações agentic (protocolo AP2).

Payment Mandate: Assinatura criptográfica do usuário que fornece prova não-repudiável de intenção de pagamento (protocolo AP2).

Agent Pay: Framework da Mastercard para registro, verificação e tokenização de agentes de IA em transações com cartão.

Compelling Evidence 3.0 (CE 3.0): Framework da Visa que permite merchants defender chargebacks de fraude apresentando transações anteriores com data points correspondentes.

MIT (Merchant-Initiated Transaction): Transação onde o cardholder não está disponível para participar diretamente. Classificação atualmente usada como proxy para transações agentic.

OIDC-A: OpenID Connect for Agents, extensão do OpenID Connect Core 1.0 para autenticação e autorização de agentes de IA baseados em LLM.

Appendix C: Disclaimer

Este relatório foi elaborado com base em fontes publicamente disponíveis e análise independente. Onde dados precisos não estavam disponíveis, hipóteses informadas foram utilizadas e sinalizadas explicitamente. Projeções de mercado representam cenários baseados em análises de terceiros citados. O relatório não constitui aconselhamento jurídico, financeiro ou regulatório. Organizações devem consultar seus respectivos assessores jurídicos e de compliance para aplicação específica ao seu contexto.