Plataforma de Inteligência de Contratos da Amazon Enfrenta o Ponto Cego de Portfólio do RAG
A Amazon publicou uma arquitetura de inteligência de contratos baseada em oito campos extraídos, criando uma plataforma de inteligência de contratos da Amazon para perguntas que chats apenas com RAG lidam mal.
O design de referência visa um problema persistente nas empresas. Um chatbot muitas vezes consegue recuperar uma cláusula de pagamento de um único acordo. Ele se torna pouco confiável quando recebe a tarefa de somar valores, comparar datas ou contar documentos não assinados entre centenas de contratos.
A resposta da Amazon não é um prompt maior nem uma janela de contexto mais longa. Ela separa a compreensão de documentos da análise de portfólio. Agentes de IA extraem e verificam campos, um banco de dados realiza os cálculos, e o Amazon Quick oferece aos usuários uma única interface para ambos os fluxos de trabalho.
Essa distinção pressiona os assistentes de contratos baseados apenas em recuperação. O sistema trata a geração aumentada por recuperação, ou RAG, como um componente, e não como o banco de dados para todas as perguntas. O resultado é um teste útil de onde os agentes empresariais se encaixam e onde os sistemas de dados convencionais continuam essenciais.
O Que a Amazon Realmente Criou
O design transforma cada contrato enviado tanto em um documento pesquisável quanto em um registro estruturado de banco de dados.
A AWS publicou a arquitetura de inteligência de contratos em 29 de setembro de 2026. Trata-se de uma implementação de referência, não do anúncio de um serviço jurídico autônomo ou de uma implantação para cliente.
Um aplicativo React fornece a interface do usuário. PDFs de contratos entram em um bucket do Amazon Simple Storage Service, o que aciona um pipeline de processamento automatizado.
O primeiro agente lê cada PDF e extrai oito campos. A AWS informa que a implementação usa o Claude Sonnet 4.6 da Anthropic e retorna JSON estruturado com uma pontuação de confiança para cada campo.
Um segundo agente lê de forma independente o mesmo documento. Segundo a AWS, esse verificador usa o Claude Haiku 4.5 e compara suas conclusões com a saída do extrator.
Os dois agentes são executados por meio do SDK open source Strands Agents no Amazon Bedrock AgentCore. O AgentCore fornece o ambiente gerenciado no qual o código dos agentes é executado e escalado.
Uma divergência não significa automaticamente que o verificador vence. Para o status de assinatura, o sistema chama o Amazon Textract como critério visual de desempate. O registro verificado segue então para o Amazon Aurora PostgreSQL.
O PDF original percorre outro caminho. Ele permanece disponível por meio de uma base de conhecimento para recuperação específica de documentos, incluindo perguntas sobre termos de pagamento ou cláusulas individuais.
O Amazon Quick fica sobre ambas as fontes. Sua capacidade Quick Sight exibe dashboards criados a partir de registros do banco de dados. Sua interface conversacional pode direcionar perguntas para análises estruturadas ou recuperação de documentos.
A distinção importa porque essas fontes respondem a tipos diferentes de perguntas. A consulta de uma cláusula exige texto relevante. Um total de portfólio exige todos os registros aplicáveis e um cálculo confiável.
O design também transmite o status do pipeline ao navegador por conexões WebSocket. Os usuários podem ver se um arquivo está sendo extraído, verificado, checado ou armazenado.
Essa visibilidade é mais do que refinamento de interface. Um fluxo de trabalho empresarial torna-se mais fácil de inspecionar quando os usuários conseguem ver qual etapa de processamento produziu um atraso ou uma divergência.
A AWS afirma que um contrato pode percorrer o pipeline em segundos sob condições típicas. Isso continua sendo uma alegação de design, e o desempenho real dependerá da extensão do documento, da simultaneidade, da disponibilidade do modelo e da configuração regional.
A publicação sucede um design anterior de gestão de contratos da AWS, de janeiro de 2026. Essa versão enfatizava múltiplos agentes especialistas para tarefas jurídicas, de risco, conformidade e fluxo de trabalho.
A nova arquitetura é mais restrita e mais reveladora. Ela se concentra na precisão da extração e nas análises de portfólio, que expõem fraquezas que demonstrações conversacionais frequentemente escondem.
Por Que o RAG Não Consegue Somar um Portfólio de Contratos
O RAG seleciona trechos relevantes, enquanto a análise de portfólio exige registros completos e cálculos controlados.
A pesquisa original sobre RAG combinou um modelo de linguagem com conhecimento externo recuperado. Esse padrão ajuda um modelo a responder perguntas sem colocar uma coleção inteira de fontes dentro de seu prompt.
Um sistema típico divide documentos em trechos e cria representações vetoriais deles. Quando um usuário envia uma pergunta, a busca semântica recupera um conjunto limitado dos trechos mais relacionados.
Esse mecanismo funciona bem quando a resposta desejada existe em algumas passagens. Uma pergunta sobre linguagem de rescisão pode recuperar a cláusula relevante sem ler todas as páginas novamente.
O mecanismo se torna um passivo quando a pergunta abrange toda a coleção. Considere um líder de compras que pede o valor total comprometido em todos os acordos ativos.
O recuperador ainda seleciona os trechos que parecem mais relevantes. Ele não garante que cada acordo ativo contribua com um valor completo e corretamente normalizado.
Aumentar o número de trechos recuperados não resolve completamente o problema. Os contratos contêm rótulos repetidos, aditivos, tabelas, notas de rodapé e datas conflitantes. As passagens relevantes também podem superar o contexto utilizável pelo modelo.
A capacidade ausente não é fluência conversacional. É cobertura.
A AWS ilustra a questão com um portfólio hipotético de 250 contratos. Com 10 a 20 páginas cada, esse portfólio pode conter até 5.000 páginas.
Uma pessoa pode eventualmente inspecionar cada documento e manter uma planilha. No entanto, cada novo acordo ou aditivo pode tornar a planilha desatualizada.
Um assistente de RAG pode responder mais rapidamente, mas ainda omitir registros fora de sua janela de recuperação. A resposta pode soar completa mesmo quando o cálculo cobre apenas um subconjunto.
Esta é a principal disputa por trás da plataforma de inteligência de contratos da Amazon: chat apenas com RAG versus extração seguida de consultas ao banco de dados.
Na abordagem de extração, todos os contratos passam pelo mesmo esquema. Valores, datas, contrapartes, estados de assinatura e outros campos selecionados tornam-se linhas e colunas.
Um banco de dados pode então filtrar registros ativos, agrupá-los por fornecedor e calcular totais. Ele também pode retornar os registros por trás do resultado para inspeção adicional.
Essa arquitetura não torna o RAG obsoleto. Ela atribui ao RAG uma função mais restrita que corresponde a seus pontos fortes.
A recuperação de documentos continua valiosa para perguntas que resistem à normalização. Linguagem de pagamento, disposições de responsabilidade, exceções e obrigações incomuns frequentemente precisam de seu texto circundante.
A análise estruturada atende a uma camada diferente. Ela sustenta perguntas como quantos acordos expiraram, quais contratos não assinados têm o maior valor ou quais renovações se aproximam de uma data selecionada.
Os dois caminhos podem se complementar. Uma consulta estruturada identifica os contratos que exigem atenção, enquanto a recuperação traz de volta as cláusulas de apoio.
Essa divisão também produz um modelo de falha mais claro. Erros de recuperação afetam uma resposta sobre documento. Erros de extração podem afetar dashboards e todos os agregados construídos a partir do campo armazenado.
Isso torna o pipeline de ingestão mais relevante do que a interface de chat. A camada conversacional é tão confiável quanto os registros e as fontes de recuperação por trás dela.
Como a Plataforma de Inteligência de Contratos da Amazon Muda o Caminho dos Dados
A arquitetura transfere o trabalho mais difícil do momento da pergunta para o momento da ingestão.
Um assistente apenas com RAG adia a interpretação até que alguém faça uma pergunta. A plataforma de inteligência de contratos da Amazon interpreta campos selecionados do contrato quando cada documento entra no sistema.
Essa mudança cria uma camada analítica reutilizável. Depois que uma data de renovação é extraída, verificada e armazenada, vários dashboards e perguntas podem usar o mesmo valor normalizado.
A primeira etapa é a ingestão de documentos pelo Amazon S3. Um upload inicia o fluxo de processamento sem exigir que um analista abra o arquivo manualmente.
O agente de extração então lê o PDF de forma nativa, segundo a AWS. Ele produz os oito campos esperados e anexa pontuações de confiança que os componentes posteriores podem inspecionar.
Pontuações de confiança são sinais, não garantias. Elas podem ajudar a priorizar o trabalho de revisão, mas não estabelecem que um valor extraído corresponda ao significado jurídico de uma cláusula.
O verificador independente introduz uma segunda leitura. O uso de um membro diferente da família de modelos busca reduzir erros correlacionados pela repetição do mesmo processo de extração.
Essa ideia se assemelha à revisão por duas pessoas, mas a analogia tem limites. Dois modelos do mesmo provedor ainda podem compartilhar padrões de treinamento, pontos cegos e fraquezas no tratamento de documentos.
A AWS avaliou combinações de extrator e verificador com 20 contratos. A equipe rotulou manualmente oito campos em cada contrato, produzindo 160 valores de referência.
Essa avaliação sugeriu que o extrator importava mais do que o verificador. Segundo os autores, um modelo de extração mais capaz preservou os resultados quando combinado a um verificador mais leve.
A AWS também afirma que modelos mais robustos nem sempre proporcionaram uma melhoria significativa nesse conjunto de dados. A empresa recomenda testar os modelos disponíveis em relação aos contratos e critérios de aceitação de cada organização.
Essa ressalva é importante. Vinte contratos constituem um teste indicativo, não evidência de que a combinação selecionada se generalizará entre setores, idiomas ou estilos de redação.
Após a verificação, o banco de dados torna-se o sistema para perguntas agregadas. O Amazon Quick conecta-se ao Aurora PostgreSQL e pode consultar dados em tempo real, em vez de esperar por uma exportação separada.
O Amazon Quick também se conecta à base de conhecimento que contém os documentos de origem. Portanto, seu agente de chat pode apoiar perguntas estruturadas e consultas de documentos individuais em uma única interface.
Esse roteamento é o mecanismo arquitetural por trás de como funciona a inteligência de contratos da Amazon. O modelo não realiza todos os cálculos lendo a prosa dos contratos durante cada conversa.
Para uma solicitação agregada, a fonte estruturada fornece registros filtrados e cálculos. Para uma solicitação específica de documento, a base de conhecimento recupera o texto relevante do contrato.
A AWS apresenta exemplos de saída com base em um portfólio de amostra contendo 20 contratos. Os exemplos incluem valor do portfólio, totais de contratos expirados e contagens de acordos assinados e não assinados.
Esses números ilustram a interface. Eles não são resultados operacionais de um portfólio de cliente divulgado e não devem ser interpretados como evidência de desempenho.
Dashboards incorporados fornecem outra forma de inspecionar os mesmos dados. Os usuários podem visualizar totais do portfólio, status de assinatura, resultados de extração e comparações de confiança sem sair do aplicativo.
Essa base compartilhada pode reduzir divergências entre as saídas de dashboard e chat. Ambas as interfaces podem consultar os mesmos registros verificados do banco de dados para perguntas analíticas.
O design também preserva o acesso ao material de origem. Analistas não precisam tratar um valor de banco de dados como a palavra final quando uma decisão contratual exige a leitura da cláusula.
Esse padrão híbrido vai além dos contratos. Sinistros de seguro, registros de conformidade, contratos de locação e registros de integração podem combinar campos repetíveis com linguagem específica de documentos.
Ele também corresponde a um princípio mais amplo de combinação de conhecimento. Fatos estruturados e contexto de origem atendem a propósitos diferentes, e sistemas úteis precisam de uma ponte governada entre eles.
A Verificação Importa Mais do Que Outra Chamada ao Modelo
A parte mais instrutiva do design é sua recusa em deixar que modelos de linguagem resolvam todas as disputas.
Durante os testes, a AWS descobriu que o verificador às vezes classificava blocos de assinatura vazios como assinados. A confiança reportada chegou a ficar entre 95 e 100 por cento em alguns casos de falso positivo.
O modelo reconheceu palavras e layouts associados à assinatura. Em seguida, tratou a presença de um campo de assinatura como evidência de que alguém o havia assinado.
Essa falha expõe um problema recorrente da IA generativa. Uma pontuação de confiança pode descrever a certeza interna do modelo sem provar que a conclusão subjacente está correta.
A AWS respondeu adicionando o Textract apenas quando os dois modelos discordavam sobre o status da assinatura. O Textract examina características visuais para detectar assinaturas manuscritas ou digitais.
A escolha cria um controle em três partes. Um modelo realiza a extração, outro modelo a verifica, e um serviço especializado de visão computacional resolve uma classe definida de discordância.
Isso é mais adequado do que pedir a um terceiro modelo de linguagem que vote. Um terceiro modelo poderia reproduzir a mesma confusão semântica entre uma linha de assinatura e uma assinatura real.
O padrão também limita a verificação especializada aos casos contestados. Isso preserva o fluxo de trabalho principal ao aplicar um método técnico diferente onde os modelos demonstram incerteza.
No entanto, o Textract é um critério de desempate para a presença de uma assinatura, não um árbitro para todos os campos. Valores contratuais, regras de renovação, datas e identidades das partes podem criar ambiguidades diferentes.
Uma adenda pode substituir um valor anterior. Uma cláusula de renovação automática pode exigir interpretação contextual. Uma assinatura pode existir enquanto o acordo permanece incompleto por outro motivo.
Esses casos exigem regras explícitas de escalonamento. A publicação da AWS afirma que discordâncias não resolvidas devem ser encaminhadas a um revisor humano quando serviços determinísticos não puderem resolvê-las.
Esse caminho humano é central para uma adoção responsável. Ele determina se a automação reduz o trabalho rotineiro ou apenas esconde registros incertos dentro de um banco de dados.
O sistema deve preservar cada valor extraído, sua localização de origem, as saídas de ambos os modelos e a resolução final. Caso contrário, os revisores não conseguirão reconstruir por que um painel inclui determinado número.
As organizações também precisam de limites específicos por campo. Um nome de contato incorreto e uma data de rescisão incorreta não carregam o mesmo risco operacional.
O framework de IA do NIST enfatiza testes, avaliação, verificação e validação para sistemas de IA. Fluxos de trabalho contratuais precisam dessas práticas no nível dos campos de dados.
As equipes devem medir precisão, cobertura e desempenho de correspondência exata por campo. Também devem acompanhar taxas de discordância, substituições feitas por revisores e erros descobertos após a aprovação.
A precisão deve ser segmentada por tipo de documento. PDFs nativos, páginas digitalizadas, tabelas, adendas, anotações manuscritas e acordos multilíngues podem se comportar de forma diferente.
A avaliação da AWS com 20 contratos oferece uma metodologia inicial. Ela não proporciona diversidade suficiente para estabelecer confiabilidade em produção para o portfólio de outra organização.
Um piloto útil deve incluir os documentos que geram mais risco. Isso inclui modelos incomuns e arquivos de baixa qualidade, não apenas acordos limpos baseados em um formulário padrão.
A verificação de dois modelos do design continua valiosa porque torna a discordância observável. Ela cria um evento mensurável que pode acionar verificações determinísticas ou revisão humana.
Ainda assim, a concordância entre modelos não pode ser tratada como verdade fundamental. Dois agentes podem produzir o mesmo valor incorreto, especialmente quando o texto de origem é ambíguo.
O controle essencial é a rastreabilidade. Cada valor estruturado deve levar um revisor de volta à página, à cláusula e à decisão de extração que o produziu.
Precisão, Acesso e Economia Continuam Não Comprovados
A arquitetura de referência define um mecanismo crível, mas não estabelece prontidão para produção para todos os portfólios de contratos.
A primeira incerteza é a escala da avaliação. A AWS usou 20 contratos e 160 valores rotulados ao comparar combinações de modelos.
Essa amostra pode revelar diferenças óbvias entre configurações. Ela não consegue representar toda a variedade de padrões de formatação, redação, digitalização, idioma e adendas em acordos empresariais.
A segunda incerteza é a cobertura do esquema. Oito campos podem sustentar painéis úteis, mas as operações contratuais frequentemente dependem de obrigações mais complexas e datas condicionais.
Uma data de renovação pode depender de períodos de aviso prévio. Um valor pode combinar taxas contratadas, cobranças por consumo, créditos ou aumentos indexados.
Reduzir esses termos a um único registro pode criar uma ilusão de certeza. O esquema deve preservar qualificadores quando um campo não puder ser representado como um número ou uma data simples.
A terceira incerteza diz respeito à mudança de modelo. A AWS observa que a disponibilidade de modelos evolui e aconselha os desenvolvedores a retestarem o sistema antes de dependerem de novas opções.
Um modelo substituto pode alterar o comportamento de extração mesmo quando a aplicação ao redor permanece inalterada. Portanto, as equipes de produção precisam de conjuntos fixos de avaliação e barreiras de lançamento.
A quarta incerteza é a autorização. Os contratos podem conter preços confidenciais, informações de funcionários, obrigações de segurança e termos estratégicos de fornecedores.
A AWS afirma que o AgentCore oferece isolamento de sessão, enquanto controles de política podem ficar fora do código do agente. A documentação do AgentCore descreve ambientes de execução separados para sessões de usuários.
No entanto, o isolamento de infraestrutura não cria automaticamente permissões comerciais corretas. A documentação da AWS afirma que os backends de clientes devem manter a relação entre usuários e identificadores de sessão.
Os desenvolvedores também devem impor acesso nas camadas de documentos, banco de dados, painéis e ferramentas de agentes. Uma interface de chat não deve revelar um registro que o mesmo usuário não possa abrir em outro lugar.
A quinta incerteza é a economia operacional. A publicação da AWS fornece um modelo de custo de exemplo, mas os termos comerciais mudam e as cargas de trabalho dos portfólios diferem.
Os custos de processamento dependem de contagens de páginas, chamadas de modelo, novas tentativas, armazenamento, capacidade de banco de dados, simultaneidade e frequência das consultas dos usuários. A revisão humana pode se tornar a maior variável.
Um caso de negócio crível deve medir o custo por registro aceito, não o custo por invocação de modelo. Uma extração barata que cria trabalho extensivo de revisão não é economicamente barata.
O cenário competitivo também oferece várias rotas de implementação. O modelo de extração de contratos da Microsoft retorna campos estruturados de contratos por meio do Document Intelligence.
O Document AI do Google também converte documentos não estruturados em dados estruturados para processamento posterior.
Esses produtos diferem em esquemas, personalização, orquestração, análises e integração com a nuvem. Os compradores devem comparar o ciclo de controle completo, em vez de um único benchmark de extração.
O diferencial da Amazon nesse design é a conexão entre agentes, verificação, um banco de dados relacional, análises incorporadas e perguntas e respostas sobre documentos.
Essa integração pode atrair organizações que já operam na AWS. Ela também pode aumentar o comprometimento arquitetural entre armazenamento, modelos, bancos de dados, análises e controles de identidade.
As equipes devem testar a portabilidade antes da produção. Registros extraídos e dados de proveniência devem usar esquemas documentados que permaneçam acessíveis fora de uma única interface conversacional.
Elas também devem definir a responsabilidade por falhas. As equipes de compras, operações jurídicas, engenharia de dados e segurança podem presumir que outro grupo valida a saída.
Um fluxo de trabalho precisa de um único responsável pelas mudanças de esquema, limites de avaliação, filas de exceção e revisões de acesso. Sem essa responsabilidade, o sistema pode automatizar inconsistências.
A lição maior é que a inteligência contratual é um projeto de governança de dados com uma camada de ingestão de IA. Tratá-la como uma implantação de chatbot minimiza o trabalho envolvido.
O Que os Compradores Devem Observar em Seguida
Três sinais mostrarão se essa arquitetura se torna um sistema operacional confiável para dados contratuais ou permanece uma demonstração de referência persuasiva.
O primeiro sinal é evidência de avaliação proveniente de conjuntos de contratos maiores e mais diversos. Os compradores precisam de resultados no nível dos campos em digitalizações, adendas, tabelas, idiomas e padrões incomuns de redação.
A precisão publicada por si só não será suficiente. Evidências úteis devem divulgar a composição do conjunto de dados, categorias de erro, políticas de revisão e a frequência com que ambos os modelos concordaram em um valor incorreto.
Evidências melhores fortaleceriam a alegação central da Amazon de que a verificação independente melhora a confiabilidade. Erros correlacionados persistentes enfraqueceriam o argumento a favor do design de dois modelos.
O segundo sinal é o tratamento de exceções pronto para produção. A plataforma precisa de filas de revisão configuráveis, citações de origem, histórico de aprovação e rotas claras para discordâncias não resolvidas.
O Amazon Quick inclui recursos de humano no circuito, mas as organizações precisam mostrar como esses controles se encaixam nas operações contratuais diárias. Os revisores precisam de contexto, não de outra pontuação de confiança sem explicação.
Um fluxo de trabalho maduro deve permitir que alguém corrija um campo, documente o motivo e atualize as análises posteriores sem perder a saída original.
Implantações bem-sucedidas também separarão a automação de baixo risco das decisões de alto risco. Contagens de portfólio podem tolerar controles diferentes de notificações de rescisão ou compromissos financeiros.
O terceiro sinal é a adoção além das cargas de trabalho de demonstração. Observe implantações de clientes divulgadas que conectem a qualidade da extração a resultados operacionais mensuráveis.
Indicadores relevantes incluem tempo de revisão, taxas de correção, frequência de registros desatualizados e a porcentagem de contratos processados sem escalonamento. Essas medidas importam mais do que a velocidade de resposta do chatbot.
A concorrência também moldará a adoção. Microsoft e Google já oferecem suporte à extração estruturada de documentos, enquanto plataformas de ciclo de vida de contratos oferecem fluxos de trabalho específicos do domínio.
A Amazon deve demonstrar que Quick e AgentCore reduzem o trabalho de integração sem limitar a flexibilidade do esquema ou a governança. Os concorrentes devem demonstrar caminhos igualmente coerentes dos documentos às análises verificadas do portfólio.
A plataforma de inteligência contratual da Amazon apresenta seu argumento mais forte por meio da arquitetura, não da novidade do modelo. Ela reconhece que recuperação, extração, verificação e cálculo são tarefas separadas.
Esse reconhecimento oferece às equipes empresariais uma regra prática de decisão. Mantenha RAG para localizar e explicar trechos de origem. Use registros estruturados para contar, ordenar, comparar e totalizar.
Em seguida, coloque controles de revisão onde uma resposta incorreta alteraria uma decisão jurídica ou financeira. Nenhuma pontuação de confiança de modelo deve contornar esse julgamento automaticamente.
Para equipes que avaliam IA contratual, o próximo passo é um piloto representativo. Selecione documentos difíceis, rotule os campos necessários, defina limites de aceitação e meça o esforço dos revisores.
Pergunte se cada resposta pode ser rastreada até sua origem. Teste permissões entre usuários, contratos, painéis e sessões de chat. Recalcule agregados após correções e adendas.
Mais importante, compare a arquitetura híbrida com o processo que ela substitui. Ela produz dados de portfólio mais atualizados, com menos erros ocultos e uma trilha de auditoria defensável?
Esse é o teste que importa. Uma plataforma de inteligência contratual da Amazon é bem-sucedida quando torna todo o portfólio consultável de forma confiável, não apenas quando um contrato produz uma resposta convincente.
