OpenAI e Ironclad: Como Funciona o Treino de Agentes de Computer Use em Fluxos de Contrato

Em 6 de outubro de 2026, a OpenAI publicou no próprio site um texto chamado Advancing computer use with Ironclad, descrevendo uma colaboração de pesquisa com a Ironclad, empresa de gestão de ciclo de vida de contratos. A proposta: usar o produto da Ironclad como terreno de treino e avaliação para agentes de computer use em trabalho profissional. O anúncio foi replicado por veículos como Seeking Alpha e CryptoBriefing no mesmo dia.

O que o anúncio diz, em uma frase: a Ironclad e a OpenAI identificaram 11 tarefas em trabalho jurídico, comercial e de compras, como configurar NDAs, criar processos de aprovação de compras e atualizar uma cláusula reutilizável para refletir a jurisdição selecionada, tarefas que levariam de 30 a 40 minutos para um usuário experiente. O resto do artigo é sobre como esse tipo de setup funciona por baixo e o que ele realmente ensina (e o que não ensina).

Como funciona o treino descrito no anúncio

Antes de entrar no mecanismo, vale separar duas coisas que estão sendo misturadas na imprensa: computer use (a capacidade geral do modelo de operar uma interface gráfica) e o treino específico em um domínio (contratos). O anúncio da OpenAI é sobre a segunda. A primeira já existia.

O laço base do computer use

Um agente de computer use da OpenAI, publicamente documentado desde o CUA, roda em um laço fechado de três passos. O modelo processa pixels brutos para entender o que está na tela e usa mouse e teclado virtuais para completar ações, navegando tarefas de vários passos, lidando com erros e adaptando-se a mudanças inesperadas.

Na prática, o ciclo é:

1. Perceber: um screenshot da tela entra no modelo como imagem.
2. Decidir: o modelo emite uma ação estruturada. O modelo examina o screenshot e sugere ações, emitindo computer_call com instruções como click(x,y) ou type(text), que você precisa executar no seu ambiente e devolver screenshots dos resultados.
3. Executar e observar: seu runtime (um browser, um sandbox, um VM) executa a ação e devolve um novo screenshot.
4. Volta ao passo 1 até o modelo declarar que terminou ou pedir ajuda.

Pense num jogo de perguntas em que você tem os olhos vendados e um amigo descreve a tela a cada jogada. Você fala “clica no botão azul em cima” e ele clica, descreve de novo, você decide o próximo movimento. O modelo é você. A venda são os pixels. O amigo é o runtime que executa o clique. A pilha de screenshots acumulados é a memória de curto prazo da partida. A analogia quebra num ponto importante: o modelo não enxerga continuamente, ele enxerga em frames discretos, e tudo que acontece entre um screenshot e outro é invisível para ele. Animações, redirecionamentos, popups que fecham sozinhos, nada disso existe se não aparecer no próximo frame.

O que a colaboração com a Ironclad acrescenta

O anúncio descreve três ingredientes somados ao laço base:

• Ambientes hospedados do produto real. A Ironclad forneceu ambientes de software hospedados do produto onde os modelos podiam praticar essas tarefas. Isso significa instâncias isoladas do Ironclad onde o agente pode clicar à vontade sem destruir dados de cliente.
• Tarefas sintéticas em cima dos workflows reais. Os pesquisadores desenvolveram tarefas sintéticas de treino em torno de workflows representativos e usaram aprendizado por reforço para ajudar os modelos a melhorar por meio de prática e feedback.
• Avaliação por critério, não por nota única. Cada tarefa foi avaliada contra 8 a 50 critérios, dependendo da complexidade, o que permite ver quais partes o modelo acertou e onde errou.

Esse terceiro ponto é o mais interessante do ponto de vista de engenharia. Avaliar um agente que faz 40 cliques num produto com um único booleano “deu certo ou não” descarta informação. Com 8 a 50 critérios por tarefa, dá para medir, por exemplo, “preencheu o campo de jurisdição corretamente”, “anexou o PDF certo”, “notificou o aprovador”, de forma independente. Isso vira sinal denso para reinforcement learning: o modelo recebe recompensa parcial por cumprir subcritérios, não só por fechar a tarefa inteira.

Sobre o resultado numérico, segundo o CryptoBriefing, o modelo GPT-6 Astra marcou em média 55,0% nas 11 tarefas de contrato, contra 41,6% do antecessor GPT-5.6 Sol, e o tempo médio por tarefa caiu de 37,0 minutos para 19,2 minutos, uma melhora de 48% em eficiência. Esses números não estão explícitos no resumo que capturei do post original da OpenAI, então trato como relato de terceiros.

O que isso significa na prática

Se você vai construir um agente que opera uma ferramenta de SaaS por fora da API, o padrão de referência que o anúncio reforça tem três partes replicáveis sem precisar de parceria com a OpenAI.

Um esqueleto do laço de computer use

Em pseudocódigo, usando a Responses API da OpenAI com a ferramenta de computer use:

# laco minimo de computer use
screenshot = capturar_tela()
historia = [{"role": "user", "content": tarefa, "image": screenshot}]

while True:
 resposta = client.responses.create(
 model="...",
 tools=[{"type": "computer_use", "display_width": 1280, "display_height": 800}],
 input=historia
 )

 chamadas = [i for i in resposta.output if i.type == "computer_call"]
 if not chamadas:
 break # modelo declarou fim

 for c in chamadas:
 executar_no_browser(c.action) # click, type, scroll, etc
 novo_shot = capturar_tela()
 historia.append({"role": "tool", "call_id": c.id, "image": novo_shot})

É basicamente o fluxo que a documentação pública descreve: o usuário envia uma requisição ao modelo incluindo a ferramenta de computer no tools com tamanho de display e detalhes de ambiente, podendo anexar um screenshot do estado inicial, recebe a resposta e procura por itens computer_call que sugerem ações como clicar, digitar, rolar ou esperar, executa a ação no computador ou browser e captura o estado atualizado como screenshot. Repete até acabar.

A parte que a maioria ignora: a avaliação

A lição mais acionável do anúncio não é “use computer use”, é “decomponha o critério de sucesso”. Em vez de medir “o NDA foi criado?” como booleano, construa uma rubrica. Por exemplo, para a tarefa de atualizar uma cláusula por jurisdição:

criterios = [
 {"id": "abriu_clausula_certa", "peso": 1},
 {"id": "identificou_jurisdicao_na_request", "peso": 1},
 {"id": "substituiu_texto_governing_law", "peso": 2},
 {"id": "preservou_outras_secoes", "peso": 2},
 {"id": "salvou_versao", "peso": 1},
 {"id": "notificou_requester", "peso": 1},
]

Com isso você consegue, numa rodada de 50 execuções, dizer onde o modelo erra. Erra sempre no último passo? Erra em preservar seções? Esse é o sinal que você precisa para decidir se o problema é prompt, é ambiente, é modelo ou é desenho de tarefa.

Em projetos que fiz, inclusive num sistema multi-agente de captura e enriquecimento de lead, essa separação por critério foi o que permitiu discutir onde o sistema estava fraco sem debate religioso. Rubrica explícita vira linguagem comum entre quem escreve o prompt e quem olha os logs.

Onde isso quebra

Computer use baseado em pixels tem limites que não desaparecem porque o modelo ficou melhor. Alguns deles aparecem no próprio anúncio por omissão, outros são conhecidos da documentação pública.

Latência e custo por laço

Cada passo do laço é uma chamada de modelo com uma imagem no input. Uma tarefa de 30 a 40 minutos para um humano, mesmo que o modelo faça em 19 minutos, pode significar dezenas ou centenas de chamadas de visão. Isso tem custo monetário e tem custo de wall clock. Para processos síncronos (um usuário esperando), isso quase nunca compensa; para batch e off-hours, compensa muito mais.

Fragilidade visual

O agente enxerga pixels. Mudança de tema, modal novo, A/B test, redirect inesperado, tudo isso é oportunidade de perder o fio. O tratamento de tarefas complexas ainda tem taxas de sucesso que mostram espaço para melhoria em comparação com desempenho humano, e a generalização para uma variedade maior de casos de uso exige mais treino e fine-tuning.

O ganho vem do treino em domínio, não só do modelo

É importante não ler o resultado da Ironclad como “o modelo ficou melhor em computer use em geral”. A metodologia descrita, ambientes hospedados do próprio produto mais tarefas sintéticas em cima de workflows representativos mais RL, é treino em domínio. Fora do Ironclad, não há garantia de ganho equivalente. O artigo não afirma generalização, e seria leitura precipitada supor que sim.

Orquestração explícita ainda ganha de framework em agente que você vai manter

Para sistemas de agente onde eu precisava de depurabilidade, acabei escolhendo orquestração explícita em vez de framework, porque quando quebra você precisa saber exatamente qual passo quebrou. O mesmo princípio vale aqui: um laço de computer use enroladinho em três camadas de abstração parece bonito até o dia em que você precisa entender por que o modelo clicou no lugar errado no passo 47.

O que não dá para afirmar ainda

Alguns pontos onde o material é curto ou ausente, e eu não vou extrapolar:

• O resumo publicado da OpenAI que capturei não detalha a função de recompensa do RL, nem como foram geradas as tarefas sintéticas, nem se o modelo treinado é um checkpoint do GPT-6 Astra geral ou um fork específico de domínio. Os números divulgados por imprensa de 55% versus 41,6% vêm de uma fonte secundária, não confirmei no post original.
• Não está claro, pelo material que vi, se os ambientes hospedados usados no treino são variantes do produto público ou builds dedicados com instrumentação extra para capturar critérios. Isso muda bastante como alguém de fora conseguiria reproduzir algo parecido.
• Não há informação sobre como o modelo lida com tarefas que exigem comunicação com humanos (pedir aprovação, esperar resposta de um aprovador), um pedaço central de workflow de contrato.
• Não testei o GPT-6 Astra em computer use diretamente. Tudo que falei do laço vem da documentação pública do CUA e da Responses API.

Como testar isso você mesmo

Sem parceria com a OpenAI, dá para reproduzir o padrão, não o resultado. Um caminho pequeno:

1. Escolha uma ferramenta SaaS que você já usa muito e um workflow de 5 a 10 minutos dentro dela. Algo repetitivo o bastante para você ter opinião sobre o que é “feito direito”.
2. Suba um ambiente de teste da ferramenta (sandbox, conta de dev, workspace separado). Nunca aponte o agente para produção na primeira tentativa.
3. Escreva a rubrica antes de escrever o agente. 8 a 15 critérios booleanos. Se você não consegue listar os critérios, você não consegue avaliar.
4. Implemente o laço mínimo de computer use acima, usando a Responses API da OpenAI ou a Computer Use da Anthropic. Rode 20 execuções da mesma tarefa.
5. Em vez de olhar “deu certo?”, conte quantos critérios cada rodada acertou. O gráfico vai te dizer onde está o buraco.

O passo 3 é o que a maioria dos projetos pula e depois vira debate de “achismo contra achismo”. A metodologia da OpenAI com a Ironclad, para além do modelo em si, é um lembrete de que a avaliação granular é o que transforma agente numa coisa que você pode melhorar de verdade.