Em 2 de outubro de 2026, a OpenAI publicou um case study sobre a Chatham Financial, uma empresa de advisory em mercado de capitais. O estudo descreve uma aplicação de validação de trade que, segundo a Chatham, reduziu o tempo de revisão de aproximadamente 30 minutos para menos de 4 minutos em medições iniciais. A Chatham usa Codex para construir ferramentas internas e para clientes, e GPT-5.6 para alimentar as features de IA, com trabalho que atravessa aplicações construídas pelos próprios funcionários, o sistema operacional de mercado de capitais Chatham Onyx, e o serviço de consultoria de reengenharia Process Zero.
Esse artigo explica o que o material da OpenAI diz sobre o mecanismo por trás desse ganho, e também o que ele não diz. A fonte é um case study comercial, então a parte de arquitetura precisa ser lida com cuidado: ela descreve o que a aplicação faz, não como foi implementada em detalhe.
O que a validação de trade faz, concretamente
Antes de falar de modelo, vale entender o problema. O time de Controls and Data Integrity da Chatham protege a acurácia dos dados transacionais validando que cada registro no sistema reflete o que o cliente autorizou e o que foi efetivamente executado. Em capital markets isso é uma reconciliação de três lados: o que o cliente pediu (autorização), o que o mercado executou (confirmação da contraparte), e o que entrou no sistema de registro.
Pense num extrato de cartão de crédito. Quando você bate o olho, está fazendo três comparações rápidas: a loja é uma que você reconhece, o valor bate com o que você lembra de ter gastado, e a data faz sentido. Se alguma coisa não casa, você marca para investigar. Validação de trade é a mesma mecânica, só que com dez a vinte campos por operação (notional, taxa fixa, taxa flutuante, índice de referência, datas de reset, convenção de day count, counterparty, netting agreement) e com tolerância de erro muito menor. A analogia do extrato quebra num ponto importante: no cartão você compara contra memória, aqui o validador compara contra documentos formais (term sheet, confirmação ISDA, booking no sistema), e cada discrepância precisa de trilha auditável.
Usando Codex, a Chatham desenvolveu uma aplicação de validação de trade que reúne as evidências de suporte da transação, compara os termos-chave e sinaliza discrepâncias para revisão, e a empresa está comparando os resultados da aplicação com os de revisores experientes. Em uma frase: coleta, compara, sinaliza, e ainda está em fase de calibração contra humanos.
Como o mecanismo funciona segundo o que a fonte descreve
O case study da OpenAI deixa explícito que o ganho de tempo não veio de rodar o mesmo processo mais rápido. Veio de redesenhar o processo. Matt Henry, CEO da Chatham, descreveu a abordagem assim: “We are not approaching AI simply as a faster way to run every process. With OpenAI, we can start with the outcome we want, identify where judgment matters, and design the best way to deliver it using the capabilities now available.”
Esse é o conceito central do que a Chatham chama de Process Zero. Trade validation é um exemplo inicial. Para cada workflow, a firma estabelece os inputs e evidências mínimas necessárias, fixa onde o julgamento humano permanece essencial, e especifica como a IA e as ferramentas construídas com IA devem apoiar o trabalho.
Traduzindo isso para engenharia: o workflow não é “pegue o processo humano de 30 minutos e peça para um LLM fazê-lo”. É “defina o resultado (um relatório de validação auditável), liste as evidências mínimas que sustentam esse resultado, decida quais passos exigem julgamento humano (as exceções), e automatize o resto”. A diferença prática é grande. No primeiro caso, o modelo tenta imitar a navegação humana entre telas. No segundo, você acessa as mesmas APIs direto, em paralelo, e usa o modelo só onde ele agrega: estruturar texto não-padronizado, extrair termos de documentos, redigir o relatório final.
Divisão de papéis entre Codex e GPT-5.6
A fonte oficial trata os dois produtos com funções distintas. A Chatham usa Codex para construir ferramentas internas e voltadas ao cliente, e GPT-5.6 para alimentar features de IA. Codex, aqui, é a ferramenta de desenvolvimento (o agente de código, versão corrente da família Codex da OpenAI que roda sobre modelos GPT-5.x), usada por engenheiros e funcionários para escrever a aplicação em si. GPT-5.6 é o modelo que roda dentro da aplicação, em tempo de execução, quando um trade chega para validar.
É importante não confundir essas duas camadas. Codex não valida trade. Codex escreve o código que valida trade. Quem valida trade é o GPT-5.6 orquestrando as leituras de dados, comparações e geração do relatório final. É a mesma distinção entre o engenheiro que escreveu seu software de folha de pagamento e o servidor que roda esse software todo mês.
O que a fonte oficial não detalha
A documentação pública da OpenAI não especifica a arquitetura interna: não diz quantas chamadas de modelo por trade, quais tool calls estão definidas, se há function calling estruturado, se usa RAG sobre a base de term sheets, se há um loop de verificação com segundo modelo, nada disso. Existem artigos secundários inferindo arquitetura (chamadas paralelas, dual-model, agentes), mas isso é interpretação de terceiros, não o que a Chatham ou a OpenAI publicaram.
O que isso significa na prática para quem quer reproduzir o padrão
Mesmo sem a arquitetura interna detalhada, o padrão de redesign é replicável. A ideia é separar três camadas em qualquer workflow que você queira automatizar:
- Coleta de evidência: APIs, bancos de dados, documentos. Determinística.
- Comparação e extração: pegar termos de um PDF semi-estruturado (como uma confirmação ISDA) e casar com campos de uma tabela. Aqui o LLM ajuda, porque formato varia.
- Decisão: aprovar, reprovar, escalar. Essa camada precisa ser auditável e, no caso da Chatham, ainda tem humano revisando.
Um esqueleto bem simplificado do fluxo, em pseudo-código, para ancorar o raciocínio:
def validate_trade(trade_id):
# 1. coleta determinística
booking = trading_system.get(trade_id)
confirm = counterparty_api.get_confirmation(trade_id)
authz = client_portal.get_authorization(trade_id)
# 2. extração estruturada via LLM
# (o PDF da confirmação nunca tem o mesmo layout)
confirm_fields = llm_extract(
document=confirm.pdf,
schema=TRADE_SCHEMA
)
# 3. comparação de termos-chave
diffs = compare_fields(booking, confirm_fields, authz)
# 4. relatório auditável
report = llm_write_report(
booking=booking,
confirm=confirm_fields,
authz=authz,
diffs=diffs
)
# 5. decisão com humano no loop para exceções
if diffs.has_material_discrepancy():
queue_for_human_review(trade_id, report)
else:
mark_validated(trade_id, report)
Esse esqueleto não é o que a Chatham roda. É só a materialização do padrão descrito: o LLM aparece onde o formato varia e onde é preciso redigir texto natural auditável, e sai do caminho onde API resolve.
Onde esse padrão quebra
Alguns limites concretos para quem for tentar:
- Volume baixo não paga a reengenharia. Se você valida 20 trades por mês, o esforço de modelar schema, calibrar prompts, escrever testes contra revisor humano e manter a aplicação custa mais do que o tempo que economiza.
- Documentos muito heterogêneos ainda falham silenciosamente. Extração de PDF de confirmação é a parte mais frágil. Quando o layout é novo, o modelo pode preencher campo com valor plausível em vez de admitir que não achou. Isso vira erro de validação invisível. Daí a importância do passo de comparação contra revisor humano que a Chatham está rodando.
- Latência vs custo. Rodar GPT-5.6 em cada trade, com várias chamadas por trade, tem custo real. A fonte não divulga preço por operação. Qualquer estimativa aqui é chute.
- Mercado regulado tem exigências de auditoria. Não basta chegar à resposta certa. Precisa ser possível reconstruir por que o sistema decidiu daquele jeito, meses depois. Isso empurra para prompts versionados, logs de todas as tool calls, e armazenamento das evidências brutas junto do laudo.
O que não dá para afirmar ainda
A fonte é um case study comercial da OpenAI com citações de executivos da Chatham, não um paper técnico nem documentação de arquitetura. Então:
- Não dá para afirmar que a arquitetura envolve agente autônomo, chamadas paralelas, RAG, ou dual-model. Artigos de terceiros descrevem isso, mas não é o que a Chatham ou a OpenAI publicaram.
- Os números são de “early measurement” segundo o próprio texto. “In early measurement, the application reduced review from approximately 30 minutes to under 4 minutes. Just as important, we are validating its performance against real transactions and experienced reviewers before we expand automation.” Ou seja, ainda não é um sistema em escala total nem com acurácia publicamente auditada.
- Não há dado público sobre taxa de erro, taxa de falsos positivos/negativos, nem sobre quantos trades escalam para humano. Esses são os números que decidem se o sistema é bom ou só rápido.
- Não há informação sobre custo por trade validado, nem sobre a infra que roda ao redor do modelo.
Como testar isso você mesmo
Se você quer sentir o padrão na mão, sem precisar de dados de capital markets, dá para fazer um exercício equivalente em escala pequena numa tarde:
- Escolha um workflow seu que hoje é manual e envolve conferir três ou quatro fontes. Exemplos: fechamento de notas fiscais contra pedidos de compra, bate de extrato bancário contra lançamentos contábeis, revisão de contratos recebidos contra um template padrão.
- Antes de abrir qualquer código, escreva em uma folha: qual é o output final (o laudo), quais são as evidências mínimas, e em que ponto você, humano, quer ser chamado. Essa é a parte “Process Zero” do exercício.
- Separe o fluxo em três camadas: coleta (API/arquivo), extração estruturada (LLM com schema fixo, use JSON mode ou structured outputs), comparação (código normal).
- Rode em uma amostra pequena, uns 20 casos, e compare o output do sistema com o seu julgamento. Anote todas as divergências. Esse é o passo que a Chatham diz estar fazendo em escala maior.
- Só depois dessa calibração, pense em volume. A ordem importa: se você automatizar antes de medir contra humano, está fabricando erro em escala.
O que o case study da Chatham ensina, no fim, é menos sobre o modelo específico e mais sobre a ordem das decisões. Primeiro o resultado desejado, depois a evidência mínima, depois onde o humano ainda assina, e só então o código. O ganho de 30 para 4 minutos é a consequência dessa ordem, não a causa.
