Gateway de Pagamentos com Camada de Inteligência Artificial: a Fronteira entre Dinheiro e IA

Por isso, estruturei toda a arquitetura sobre um princípio que guia cada decisão de design que tomei desde a primeira linha do desenho: o núcleo financeiro é determinístico, e a inteligência artificial atua exclusivamente como uma camada assistiva de risco. Não é uma frase de efeito, é uma decisão arquitetural registrada e formalizada, que arbitra qualquer conflito técnico que surja ao longo da implementação.

Neste artigo, explico primeiro a arquitetura geral do Gateway, sem entrar nas ferramentas específicas que escolhi, porque quero que o raciocínio arquitetural fique claro independentemente da stack. Depois, na segunda parte, descrevo em profundidade e com evidência concreta como implementei a camada de inteligência artificial: onde ela atua, como atua, que tipos de automação desenvolvi e qual é a stack que sustenta essa camada.

Parte 1: Arquitetura do Gateway de Pagamentos

O problema que este sistema resolve

Todo Gateway de Pagamentos precisa responder, em milissegundos, a uma pergunta com implicação financeira direta: esta transação deve ser aprovada, negada ou enviada para revisão. Essa resposta precisa considerar sinais como valor fora do padrão histórico do cliente, múltiplas tentativas em curto período, divergência de localização entre cartão e dispositivo, histórico de chargeback do merchant, e comportamento recente do titular da conta.

Regras fixas resolvem bem os casos óbvios. O problema real está na zona cinzenta, nos casos ambíguos em que um conjunto de sinais fracos, isolados, não dispara nenhuma regra, mas combinados sugerem risco elevado. É exatamente nessa zona cinzenta que decidi introduzir inteligência artificial, e detalho isso na segunda parte deste artigo. Por ora, foco na espinha dorsal determinística que sustenta tudo.

Princípios que orientaram cada decisão

Estabeleci dez princípios arquiteturais antes de desenhar qualquer componente, e trato esses princípios como restrições de design, não como sugestões:

1. Separação absoluta entre fluxo determinístico e fluxo probabilístico.
2. Inteligência artificial como apoio à decisão, nunca como executora financeira.
3. Idempotência obrigatória em toda operação transacional.
4. Eventos como mecanismo de desacoplamento entre componentes.
5. Auditoria de ponta a ponta, por transação, sem exceção.
6. Observabilidade desde a primeira linha de código, não como retrofit.
7. Minimização de dados sensíveis antes de qualquer processamento externo.
8. Fallback seguro sempre que um componente assistivo falhar.
9. Um motor de decisão único como ponto final de arbitragem.
10. Núcleo financeiro determinístico, sem exceção, sob nenhuma circunstância.

Visão lógica do fluxo transacional

O fluxo começa na camada de checkout, que captura a intenção de pagamento e nada mais. Essa camada não carrega regra de negócio financeira, apenas inicia a jornada e acompanha o status.

A solicitação chega então ao núcleo transacional, responsável por validar contrato, autenticar e autorizar a chamada, aplicar idempotência, criar a transação, persistir o estado oficial e publicar um evento de criação. Esse núcleo controla uma máquina de estados rígida, e nenhuma transição de estado acontece fora dela. Estados como criado, em análise de risco, aprovado por risco, negado por risco, revisão necessária, autorizado, capturado, cancelado e reembolsado seguem transições estritamente controladas, e qualquer tentativa de transição inválida é rejeitada na origem.

A persistência do estado oficial acontece em um banco relacional transacional, e a publicação de eventos segue o padrão Outbox: toda mudança de estado que gera evento é gravada na mesma transação de banco que grava o estado, o que elimina o risco clássico de um evento se perder ou de um evento ser publicado sem a transação correspondente ter sido persistida. Um processo assíncrono lê os eventos pendentes e os publica em um barramento de eventos distribuído, o que desacopla o núcleo transacional de todos os consumidores downstream, entre eles o serviço de antifraude.

O serviço de antifraude consome o evento de criação, monta o contexto de risco, executa um motor de regras determinísticas versionadas e auditáveis, calcula um score inicial e consulta um armazenamento de alta performance para verificações de velocidade, como múltiplas tentativas em curto intervalo. Se o risco for claramente baixo ou claramente alto, a decisão sai direto desse fluxo determinístico. Se o risco for ambíguo, é neste ponto exato que a camada de inteligência artificial entra, e detalho isso na segunda parte.

A decisão final, seja ela vinda puramente das regras ou enriquecida pela análise de IA, é consolidada por um motor de decisão único, que também considera a política específica do merchant, o histórico da conta e os limites operacionais vigentes. Esse motor de decisão é o único ponto do sistema autorizado a produzir uma decisão financeira final, e essa decisão é sempre determinística, auditável, explicável, reproduzível e rastreável.

Hot Path e Cold Path

Uma decisão arquitetural que considero central para a robustez do sistema é a separação entre Hot Path e Cold Path. O Hot Path é o caminho crítico de baixa latência, responsável por validar o pagamento, aplicar regras rápidas, consultar features em cache e definir decisões simples, sempre evitando qualquer dependência síncrona pesada de um modelo de linguagem. O Cold Path é o caminho assíncrono e investigativo, responsável por análise profunda, geração de dossiê de risco, explicação detalhada e apoio ao analista humano.

Essa separação existe porque tratar inteligência artificial como dependência síncrona crítica é um erro de design que compromete disponibilidade. Um modelo de linguagem indisponível, lento ou instável nunca pode travar a autorização de um pagamento. Por isso, mantenho a IA majoritariamente fora do caminho crítico, reservando essa camada para os casos que realmente justificam análise mais profunda.

Idempotência, consistência e resiliência

Cobri idempotência em toda operação transacional, com chaves específicas que garantem que a mesma solicitação, com o mesmo payload, sempre retorne a mesma transação, e que a mesma chave com payload diferente gere erro de conflito explícito. Isso vale para criação de pagamento, autorização, captura, estorno, processamento de eventos e webhooks de provedor externo.

Para resiliência, apliquei retry com backoff exponencial, timeout configurado por dependência, circuit breaker para provedores externos e processamento assíncrono como padrão. O princípio operacional que sustento é simples de enunciar e difícil de violar: na dúvida, o sistema degrada com segurança, nunca assume um estado otimista sem confirmação.

Segurança e observabilidade como requisitos de primeira classe

Trato segurança e observabilidade como requisitos funcionais, não como preocupações de infraestrutura à parte. Isso significa criptografia em trânsito e em repouso, autenticação forte entre serviços, tokenização de dados de cartão, mascaramento de dados sensíveis e retenção controlada conforme legislação de proteção de dados e normas do setor de pagamentos.

Na observabilidade, garanto rastreabilidade fim a fim através de identificadores propagados em toda a cadeia, correlacionando requisição, transação, evento e análise de risco. Acompanho métricas técnicas de latência por componente, métricas de negócio como taxa de aprovação, negação e revisão manual, e métricas específicas de qualidade da análise de risco, como taxa de falso positivo e falso negativo.

Parte 2: A Camada de Inteligência Artificial

Onde a IA atua

O AI Risk Agent, nome que dei à minha camada de inteligência artificial, atua em um ponto muito específico da arquitetura: exclusivamente dentro do serviço de antifraude, depois que o motor de regras determinísticas já processou a transação e calculou um score inicial, e apenas quando esse resultado é ambíguo ou indica risco elevado. A IA nunca é acionada para toda transação. Ela é acionada seletivamente, o que reduz custo, reduz latência agregada do sistema e concentra a capacidade analítica exatamente onde ela agrega valor real.

Isso significa que, para a maioria das transações, o fluxo é resolvido inteiramente por regras determinísticas, rápidas e previsíveis. A IA entra apenas na fatia de casos em que sinais fracos e combinados não permitem uma decisão automática confiável apenas com lógica de regras.

Como a IA atua, com evidência de contrato

O AI Risk Agent nunca recebe dados brutos da transação. Antes de qualquer chamada ao modelo, executo uma etapa obrigatória de sanitização de contexto, que remove qualquer dado sensível bruto, como número completo de cartão, código de segurança, senhas ou tokens internos. Não envio para a IA número de cartão, código de segurança, dados brutos de titular, senhas, tokens sensíveis, dados pessoais desnecessários ou segredos internos de infraestrutura. Envio apenas contexto derivado: perfil agregado do cliente e do merchant, sinais de comportamento, histórico resumido, regras determinísticas acionadas, score parcial e indicadores de risco.

A entrada esperada pelo agente segue um contrato fixo: identificador da transação, identificador do merchant, valor, moeda, tipo de método de pagamento, resumo do perfil do cliente, resumo do perfil do merchant, resumo do dispositivo, resumo de localização, sinais de velocidade, regras acionadas e indicadores históricos de risco. Nada além disso atravessa a fronteira de sanitização.

A saída é sempre um objeto estruturado, validado contra schema rígido antes de qualquer uso posterior. Este é um exemplo real do formato de saída que o agente produz:

{
  "risk_summary": "Transação com risco elevado por combinação de alto valor, múltiplas tentativas recentes e divergência de localização.",
  "risk_factors": [
    "high_value_transaction",
    "velocity_attempts",
    "country_mismatch"
  ],
  "anomaly_indicators": [
    "unusual_device_behavior",
    "new_customer_high_value"
  ],
  "confidence": 0.82,
  "suggested_action": "REVIEW_REQUIRED"
}

Esse suggested_action nunca é executado diretamente. Ele é consumido pelo motor de decisão como mais um sinal, junto com o resultado das regras determinísticas, o score de risco, a política do merchant e o histórico da conta. O evento final que sai desse processo consolidado carrega o identificador da execução de IA como campo de auditoria, nunca como campo de autoridade:

{
  "event_id": "uuid",
  "event_type": "risk.final_decision.created",
  "occurred_at": "2026-01-01T10:00:02Z",
  "transaction_id": "uuid",
  "merchant_id": "uuid",
  "decision": "REVIEW_REQUIRED",
  "risk_score": 82,
  "reason_codes": [
    "HIGH_VALUE",
    "VELOCITY_ATTEMPTS",
    "COUNTRY_MISMATCH"
  ],
  "ai_run_id": "uuid"
}

Reparo neste contrato um ponto que considero central: o campo decision é produzido pelo motor determinístico, não pela IA. O campo ai_run_id existe para rastreabilidade, para que eu consiga reconstruir, a qualquer momento, qual análise de IA contribuiu como sinal para aquela decisão específica, sem que isso implique que a IA tenha decidido algo.

Tipos de automação e inteligência desenvolvidos

Desenvolvi quatro capacidades centrais de inteligência artificial dentro desta camada.

A primeira é a análise assistida de risco, em que o modelo interpreta a combinação de sinais fracos que, isoladamente, não disparariam nenhuma regra, mas que juntos sugerem um padrão suspeito, como um cliente novo realizando uma transação de alto valor, com múltiplas tentativas recentes e divergência entre o país do cartão e o país do dispositivo.

A segunda é a geração de explicabilidade, transformar sinais técnicos, muitas vezes numéricos e fragmentados, em uma narrativa compreensível tanto para o motor de decisão quanto para um analista humano que eventualmente revise o caso. Considero essa capacidade tão importante quanto a análise em si, porque uma decisão de risco sem explicação auditável é uma decisão que não sobrevive a uma auditoria regulatória ou a uma disputa de chargeback.

A terceira é o apoio à revisão manual, em que a IA gera um resumo priorizado dos pontos mais relevantes do caso, reduzindo o tempo que um analista humano gasta reconstruindo o contexto de uma transação sinalizada para revisão.

A quarta é a produção de um resumo auditável, um artefato estruturado que fica anexado à transação e que documenta exatamente qual foi o raciocínio assistivo apresentado, com que nível de confiança, e como esse raciocínio se relacionou com a decisão final tomada pelo motor determinístico. Esse artefato é o que permite reconstruir, meses depois, exatamente por que uma transação específica recebeu uma decisão específica.

Arquitetura interna do AI Risk Agent, componente a componente

Estruturei o agente em três sub camadas internas, deliberadamente isoladas para permitir teste independente de cada responsabilidade. Esta é a decomposição real de componentes que implementei:

Sub camada de entrada

• RiskContextValidator, valida que o payload recebido está completo e consistente antes de qualquer processamento.
• PiiSanitizer, remove qualquer dado sensível residual que não deveria estar presente no contexto.
• SchemaValidator, garante que a estrutura de entrada respeita o contrato esperado pelo modelo.

Sub camada de raciocínio

• RiskPromptBuilder, monta a instrução enviada ao modelo a partir do contexto já sanitizado, sempre usando um prompt versionado, nunca editado livremente em produção.
• LLMRiskReasoner, invoca o modelo de linguagem via API e conduz o raciocínio sobre os sinais recebidos.
• AnomalyExplainer, interpreta e articula os sinais de anomalia identificados pelo raciocínio.
• ConfidenceEvaluator, calibra o nível de certeza que acompanha a recomendação final.

Sub camada de saída

• GuardrailValidator, aplica regras de segurança sobre a resposta do modelo antes de qualquer uso posterior.
• StructuredOutputParser, converte o retorno do modelo em um objeto tipado e validado contra schema.
• AIAnalysisPublisher, publica o resultado consolidado para consumo do motor de decisão.
• AuditWriter, persiste o run completo em um repositório dedicado de auditoria de IA.

Essa decomposição não é estética. Cada componente tem um contrato de entrada e saída próprio, o que me permite testar isoladamente, por exemplo, o comportamento do GuardrailValidator diante de uma saída de modelo malformada, sem precisar simular uma chamada real ao modelo de linguagem.

Governança e auditoria, com o schema real de rastreabilidade

Cada execução da inteligência artificial gera um registro completo e imutável na tabela ai_risk_runs, com os seguintes campos: identificador único da execução, identificador da transação analisada, nome do modelo, versão do modelo, versão do prompt, hash do input, hash do output, nível de confiança, ação sugerida, latência em milissegundos, consumo de tokens, custo estimado e timestamp de criação. Uma segunda tabela, ai_risk_outputs, armazena o conteúdo estruturado da análise em si, sempre vinculado por chave estrangeira ao identificador da execução: resumo de risco, fatores de risco, indicadores de anomalia, explicação e ação sugerida.

Esse nível de granularidade é o que permite responder, com precisão factual e não por inferência, perguntas como qual versão de prompt estava ativa quando uma decisão específica foi tomada, ou qual foi o custo agregado de inteligência artificial em determinado período, por merchant ou por faixa de risco.

Os controles de governança que trato como não negociáveis são: versionamento explícito de prompt e de modelo, registro de todo input sanitizado e todo output estruturado, guardrails aplicados tanto na entrada quanto na saída, validação rígida de schema em toda resposta do modelo, bloqueio automático de qualquer resposta que viole o schema esperado, e fallback determinístico sempre disponível.

Isso está formalizado em duas decisões arquiteturais que trato como cláusulas pétreas do sistema. A primeira estabelece que o AI Risk Agent analisa e recomenda, o Decision Engine decide, e o Gateway executa, nessa ordem, sem exceção. A segunda estabelece que a IA deve operar preferencialmente fora do caminho crítico de latência, sendo usada para análise contextual, casos ambíguos, revisão e explicação, com o objetivo explícito de reduzir latência, reduzir dependência de modelo, evitar indisponibilidade e controlar custo.

Resiliência da camada de IA, cenário a cenário

Mapeei o comportamento esperado para cada modo de falha da IA, porque um componente assistivo sem plano de degradação explícito se torna, na prática, um ponto único de falha disfarçado:

Essa tabela é validada em testes específicos que mantenho na suíte de testes da camada de risco: idempotency key repetida, webhook duplicado, evento Kafka duplicado, IA indisponível, IA retornando JSON inválido, e o caso que considero mais revelador de todos, o Rules Engine negando enquanto a IA sugere aprovação. Esse último caso existe exatamente para provar, em ambiente controlado, que a arbitragem final nunca pende para o lado da IA por padrão.

Os riscos que mapeei especificamente para esta camada, com a mitigação correspondente:

Observabilidade específica de IA

Além das métricas técnicas e de negócio do Gateway como um todo, mantenho um conjunto de métricas exclusivas da camada de IA: custo por análise, tokens por análise, tempo médio de resposta do modelo, taxa de fallback acionada, taxa de resposta inválida bloqueada por guardrail, confiança média das análises e, o indicador que considero mais valioso do ponto de vista de governança, a taxa de divergência entre a recomendação da IA e a decisão final efetivamente tomada pelo motor determinístico.

Esse último indicador é o que me permite avaliar, com dado real e não com percepção, se a inteligência artificial está de fato agregando sinal útil ao processo de decisão ou se está sistematicamente destoando do julgamento consolidado das regras e políticas de negócio. Uma divergência alta e persistente é sinal de que o prompt, o modelo ou a calibração de confiança precisam de revisão, não de que o motor de decisão deveria confiar mais na IA.

Evolução planejada da camada de IA

O desenho atual não é o ponto final da capacidade de inteligência artificial nesta arquitetura, é a base sobre a qual pretendo evoluir. Nas próximas fases, planejo introduzir uma camada de recuperação aumentada por geração, apoiada em um banco de dados vetorial, para consultar políticas internas de risco e precedentes de casos similares durante a análise. Planejo também construir um dossiê de risco mais completo por transação, um assistente dedicado para apoiar analistas humanos durante a revisão manual, um ciclo de feedback estruturado que capture a decisão final de cada revisão humana como sinal de calibração, uma rotina de avaliação contínua da qualidade das análises geradas, e a introdução seletiva de modelos clássicos de aprendizado de máquina para tarefas específicas de scoring, complementando, e não substituindo, a análise assistiva do modelo de linguagem.

Fechamento

A decisão arquitetural que sustenta todo este sistema pode ser resumida em uma frase que uso internamente como critério de design: eu uso inteligência artificial para analisar e explicar risco, e uso regras determinísticas para executar dinheiro. Essa arquitetura é, na camada de inteligência de risco, orientada por IA em primeiro lugar. No núcleo financeiro, é determinística em primeiro lugar, sem exceção. É essa fronteira, mantida com rigor arquitetural, com contrato de dados explícito, com auditoria completa e com plano de degradação para todo modo de falha, e não apenas como boa intenção de design, que permite usar inteligência artificial onde ela realmente agrega valor, sem jamais comprometer segurança financeira, rastreabilidade, consistência transacional e governança regulatória.