O Agreement Analyzer é uma ferramenta de revisão de minutas desenvolvida pela Sullivan & Cromwell em colaboração com a OpenAI. O caso divulgado em 15 de outubro de 2026 mostra como organizar conhecimento de um escritório para apoiar a análise de contratos. O anúncio não confirma uma oferta comercial da ferramenta no Brasil.
Para uma equipe brasileira, a aplicação prática é desenhar uma revisão em que cada sugestão possa ser conferida, discutida e recusada. Nossa análise propõe um piloto de organização documental e avaliação de qualidade. Não descreve uma implementação oficial da Sullivan & Cromwell nem oferece interpretação jurídica para um contrato específico.
Resumo rápido
- O anúncio apresenta uma aplicação criada para o trabalho de um escritório.
- Um bom piloto separa minuta, referências autorizadas e orientação do cliente.
- Sugestões precisam manter vínculo com os documentos usados na análise.
- Comparar respostas de agentes não substitui a conferência das evidências.
- A avaliação deve incluir omissões, dúvidas e esforço de revisão.
O que foi anunciado pela Sullivan & Cromwell
Segundo o relato oficial da OpenAI, o Agreement Analyzer reúne precedentes selecionados pelo escritório, orientações de negociação e ChatGPT Enterprise. O projeto começou como uma prova de conceito construída com Codex. A ferramenta produz um memorando e propostas de alterações para revisão de advogados. O relato também descreve a exposição de fontes e incertezas, incluindo a contestação de conclusões por outros agentes.
O caso merece atenção pelo desenho do trabalho. Uma pergunta ampla como “revise este contrato” deixa implícitas decisões sobre documentos de referência, interesses da parte representada e prioridades da negociação. Nossa proposta é tornar essas decisões visíveis antes de solicitar a análise. Isso permite entender por que uma sugestão foi feita e qual informação faltou quando o resultado ficou incompleto.
Não basta observar se a resposta parece bem escrita. O teste relevante é conseguir reconstruir sua origem: qual versão da minuta foi lida, qual orientação foi aplicada e qual trecho motivou a proposta. Se o revisor precisa refazer toda a pesquisa para descobrir isso, o texto pode ter pouca utilidade operacional, mesmo quando sua redação é clara.
Três conjuntos de informações para organizar antes do piloto
Comece pela minuta que será analisada. Registre seu identificador e preserve o arquivo recebido. Quando houver anexos ou documentos associados, mantenha uma lista explícita. Não trate a ausência de um anexo como um detalhe técnico: ela altera o alcance da revisão. A aplicação deve mostrar quais materiais estavam disponíveis e quais ficaram pendentes.
O segundo conjunto é a biblioteca de referências autorizadas. Nesta proposta, cada documento recebe um responsável pela inclusão e uma descrição do contexto em que pode ser usado. Um texto aprovado em outra negociação não deveria virar padrão automaticamente. A seleção precisa ser compreensível para quem revisa e não apenas para quem configurou a busca.
O terceiro conjunto contém as instruções específicas da demanda. Registre quem será atendido, quais perguntas foram feitas e o que ficou fora do escopo. A equipe pode usar um formulário curto em vez de uma conversa extensa. Campos bem definidos ajudam a distinguir uma preferência comercial recebida do cliente de uma conclusão produzida durante a leitura.
| Material | Função no piloto | Controle proposto |
|---|---|---|
| Minuta e anexos | Objeto da análise | Versão, inventário e integridade do arquivo |
| Referências selecionadas | Base para comparação | Contexto, origem e autorização de uso |
| Instruções da demanda | Delimitação do trabalho | Responsável, escopo e registro de mudanças |
| Resultado revisado | Registro da avaliação | Decisão humana e justificativa da alteração |
Esse inventário também facilita a manutenção. Se uma referência for retirada, a equipe consegue localizar avaliações que a utilizaram. Se uma instrução mudar durante a negociação, é possível identificar quais sugestões precisam ser revistas. O benefício pretendido é preservar contexto, não criar uma biblioteca cada vez maior sem critérios claros.
Como transformar observações em registros verificáveis
Propomos começar com uma pergunta específica por rodada, como localizar referências a anexos e verificar se os arquivos correspondentes foram fornecidos. A saída deve conter observação, trecho, documento e estado da conferência. Evite iniciar com uma classificação genérica de risco do contrato inteiro, que pode ocultar diferenças entre problemas documentais e questões de interpretação.
A documentação de Structured Outputs apresenta respostas organizadas segundo um esquema JSON, um formato de troca de dados. Essa capacidade pode ajudar a manter os campos consistentes. A aplicação ainda precisa conferir se o trecho existe, se pertence ao documento informado e se sustenta a observação. Formato válido não comprova conteúdo correto.
Uma revisão proposta deve permanecer distinta do texto original. Mostre ao usuário o antes, o depois e a justificativa. Permita aceitar parte da sugestão, corrigir a redação ou rejeitar tudo. Guarde essas decisões separadamente para que uma nova rodada de análise não apague escolhas já feitas pelo responsável.
Quando a observação depender de várias partes do documento, mostre todas as referências relevantes. Recuperar apenas um parágrafo pode esconder uma definição ou exceção. O guia sobre busca hierárquica em documentos jurídicos aborda uma técnica relacionada à preservação de contexto. A escolha técnica deve ser testada com a estrutura real dos arquivos.
Também defina um estado para o que não pôde ser verificado. Uma dúvida pendente não deve aparecer na mesma lista de uma inconsistência confirmada. O usuário precisa saber se falta um arquivo, se a extração falhou ou se há uma questão que exige avaliação especializada. Essa distinção orienta a próxima ação sem criar certeza artificial.
Exemplo: revisão documental em um escritório de Recife
Imagine um escritório de Recife que atende empresas de serviços e recebe minutas acompanhadas de anexos operacionais. O cenário é ilustrativo e não apresenta resultados medidos. A equipe escolhe um piloto restrito: conferir referências documentais e organizar perguntas para a pessoa responsável pela revisão, sem emitir pareceres ou enviar alterações automaticamente.
Uma assistente registra a versão recebida e os anexos disponíveis. O profissional responsável seleciona os documentos que podem servir de comparação e escreve o escopo da rodada. A ferramenta procura menções a anexos, identifica os arquivos correspondentes e prepara uma lista de itens para conferência. Cada item permite abrir o trecho de origem.
Em um dos testes, a minuta menciona um cronograma que não foi enviado. A resposta esperada é registrar a ausência no conjunto recebido. O sistema não deve preencher o cronograma com base em outro cliente nem concluir que o documento inexiste. A formulação correta delimita o que foi observado, sem extrapolar o material analisado.
Em outro teste, dois anexos têm nomes semelhantes. A aplicação apresenta a ambiguidade para o revisor, que escolhe o documento pertinente ou pede esclarecimento. A decisão fica registrada. Esse caso ajuda a avaliar a experiência real: se o usuário não consegue entender por que o sistema ficou em dúvida, a interface ainda precisa
melhorar.
Ao terminar, o escritório compara a lista gerada com uma conferência manual previamente preparada. Mede o tempo de leitura, correção e registro. Também anota perguntas indevidas e referências esquecidas. A decisão de ampliar o piloto depende dessas observações, não da capacidade de produzir um relatório longo ou de usar muitos agentes.
Como avaliar qualidade e proteger o contexto
A documentação de avaliações da OpenAI descreve testes com dados e critérios de verificação. Para este cenário, sugerimos uma coleção de casos cuja resposta esperada tenha sido revisada pela equipe. Inclua documentos completos, anexos ausentes, versões concorrentes e arquivos em que a extração de texto apresente problemas.
Avalie cada dimensão separadamente. A localização do trecho pode estar correta e a conclusão, inadequada. Uma observação relevante pode vir com uma referência impossível de abrir. Uma resposta prudente pode ser útil mesmo sem apresentar uma conclusão. Contar apenas quantas sugestões foram produzidas incentiva volume e não mede a contribuição para o trabalho.
Compare versões do fluxo usando o mesmo conjunto de teste. Quando houver mudança no modelo, nas instruções ou na busca, repita os casos críticos. O conteúdo sobre testes de regressão de agentes ajuda a estruturar essa rotina. Uma melhoria em exemplos fáceis não compensa perder um comportamento importante nos casos difíceis.
A página de privacidade empresarial da OpenAI descreve compromissos e controles para serviços empresariais. Na implementação proposta, a equipe também precisa definir acesso por demanda, autorização para exportação e retirada de documentos. As condições do fornecedor e os controles da aplicação são camadas distintas de uma mesma operação.
Faça um teste específico de isolamento: uma pessoa autorizada para uma demanda não deve receber trechos de outra ao formular uma pergunta parecida. Verifique também exportações e registros de execução. Um relatório técnico que copie o conteúdo integral dos documentos pode ampliar desnecessariamente sua circulação. Registre apenas o que a operação precisa para investigar falhas.
Antes de contratar componentes, consulte a página de integrações OpenAI e ChatGPT e confirme as condições da solução escolhida. O anúncio do Agreement Analyzer não demonstra que uma configuração diferente produzirá os mesmos comportamentos. A equipe deve validar seu próprio conjunto de documentos, permissões e rotinas de revisão.
Erros comuns
- Usar qualquer contrato como referência. Selecione materiais por contexto e autorização, com responsabilidade definida pela inclusão.
- Esconder incerteza em uma nota final. Mostre a dúvida junto da observação e explique qual informação falta para avançar.
- Avaliar apenas a redação. Verifique também origem, contexto, omissões e capacidade de localizar a evidência.
- Considerar concordância entre agentes uma prova. Respostas semelhantes ainda precisam ser confrontadas com documentos e critérios definidos.
- Apagar decisões anteriores. Preserve correções e rejeições quando repetir uma rodada, indicando a versão analisada.
- Automatizar o envio cedo demais. Primeiro demonstre que a equipe consegue revisar e aprovar o resultado com clareza.
Perguntas frequentes
O Agreement Analyzer pode ser contratado no Brasil?
O anúncio consultado não confirma uma oferta comercial no Brasil. Ele apresenta uma aplicação desenvolvida para o trabalho de um escritório. Não confunda a disponibilidade de componentes da OpenAI com acesso à ferramenta específica ou à biblioteca usada por ela.
É necessário usar vários agentes desde o início?
Não na proposta deste piloto. Comece com uma tarefa delimitada e uma revisão compreensível. Acrescente etapas quando os testes demonstrarem uma necessidade concreta. Mais etapas também criam resultados intermediários que precisam ser observados e mantidos.
Como escolher os primeiros documentos?
Use materiais autorizados e representativos da tarefa definida. Inclua variações de formato e casos incompletos. Reserve alguns exemplos para avaliação posterior, evitando ajustar o fluxo somente aos documentos usados durante a construção.
O que significa uma boa entrega para o revisor?
Uma lista de observações que permita verificar origem, entender limites e registrar decisões. O tamanho do memorando não é o principal critério. O profissional deve conseguir separar o que foi encontrado do que ainda precisa ser esclarecido.
