Acelere a análise de conformidade de contratos com Amazon Bedrock

Por Givanildo Alves, Arquiteto de Prototipação Sênior na equipe de Prototyping and AI Customer Engineering (PACE) da AWS; Henrique Fugita, Arquiteto de Prototipação Sênior na equipe de Prototyping and AI Customer Engineering (PACE) da AWS e Donato Azevedo, Arquiteto de Prototipação Sênior na equipe de Prototyping and AI Customer Engineering da AWS.

As equipes jurídicas que verificam contratos contra diretrizes internas conhecem bem o desafio de acelerar a análise de conformidade de contratos. Em um projeto de prototipação, observamos advogados levarem em média quase cinco dias para revisar um único contrato. Em cada contrato, o time precisa revisar as cláusulas uma a uma, classificar o assunto, avaliar aderência às políticas da organização e determinar o risco. Esse processo manual não escala para grandes volumes, e fazer isso sem sacrificar consistência requer uma abordagem diferente.

Várias etapas desse processo correspondem a tarefas de processamento de linguagem natural: extrair e classificar cláusulas e responder perguntas factuais sobre seu conteúdo. Os modelos de linguagem de grande porte (LLMs) disponíveis no Amazon Bedrock têm as capacidades necessárias para essas tarefas. No entanto, uma abordagem direta (como pedir “avalie se esse contrato está em conformidade com as diretrizes”) não oferece a consistência que contextos jurídicos demandam. Nesses contextos, cada decisão precisa ser rastreável a critérios específicos.

Neste post, descrevemos uma abordagem que trata esse problema de forma estruturada e mostramos como implantá-la e usá-la na sua conta AWS. Para cada cláusula, ela formula perguntas objetivas de sim ou não e aplica regras de raciocínio que instruem o modelo a não fazer deduções ou generalizações além do texto. A aplicação extrai cláusulas de contratos, classifica-as por tipo, avalia conformidade com diretrizes predefinidas e calcula o risco do contrato. O AWS Step Functions orquestra todo esse pipeline de forma serverless. Com essa abordagem, o tempo de revisão caiu daqueles quase cinco dias para poucas horas. Os advogados passaram a focar nos pontos sinalizados em vez de ler cada contrato do zero. O código-fonte está disponível como exemplo no repositório GitHub.

Este protótipo não fornece consultoria jurídica nem substitui aconselhamento profissional. O usuário deve realizar sua própria avaliação e consultar um profissional jurídico habilitado.

Visão geral da solução

A análise acontece em um pipeline que recebe um contrato e devolve uma avaliação de risco fundamentada em diretrizes. O pipeline executa cinco etapas:

1. Validação: verifica que o tipo de contrato existe e está ativo
2. Pré-processamento: extrai e separa as cláusulas do documento (PDF, DOCX ou TXT)
3. Classificação: determina o tipo de cada cláusula usando exemplos de referência
4. Avaliação: verifica conformidade respondendo perguntas de sim ou não para cada cláusula
5. Avaliação de risco: agrega resultados e determina o nível de risco do contrato

As três primeiras etapas preparam e classificam o conteúdo do contrato, enquanto as duas últimas avaliam a conformidade e quantificam o risco. O diferencial está na etapa de avaliação, com o modelo baseado em perguntas. Em vez de solicitar ao LLM um julgamento aberto, a aplicação faz perguntas de sim ou não específicas para cada tipo de cláusula, definidas e refinadas pela equipe jurídica da organização. O modelo responde cada pergunta com Sim, Não ou Não tenho certeza. Isso torna a lógica de decisão transparente e os resultados auditáveis.

O ganho de tempo vem de mudar onde o trabalho manual é aplicado. Antes, a equipe lia cada cláusula do zero, classificava o assunto e checava item a item contra as políticas. Agora, recebe o contrato já dividido em cláusulas, cada uma classificada e com as respostas de conformidade e a justificativa. A revisão humana passa a se concentrar nas cláusulas que o sistema sinaliza como não conformes, em vez de percorrer o documento inteiro.

A aplicação permite configurar múltiplos tipos de contrato, isolados entre si, e opera em três idiomas (português, espanhol e inglês). Um módulo opcional de conformidade com legislação verifica as cláusulas contra a legislação vigente.

Arquitetura

A solução tem três workflows: análise de conformidade com diretrizes, conformidade com legislação e importação de contrato referência. Construímos a aplicação com serviços serverless da AWS, já que a análise de contratos é uma carga sob demanda: os recursos escalam conforme os contratos chegam e não há servidores ociosos entre as análises.

O AWS Step Functions orquestra esses workflows, invocando funções AWS Lambda (Python) para cada etapa, e o Amazon Bedrock fornece inferência com modelos como Amazon Nova e Claude. Cada workflow é uma sequência de etapas com necessidades distintas: algumas processam o contrato inteiro, outras iteram cláusula a cláusula. Cada etapa ainda define sua própria política de novas tentativas para chamadas de modelo que falham de forma transitória. Modelar esse fluxo no Step Functions mantém a ordem das etapas, a concorrência de cada uma e o tratamento de falhas fora do código das funções Lambda. O workflow de diretrizes é o caminho principal; o de legislação roda em paralelo quando acionado, e o de importação é usado na configuração. O diagrama a seguir mostra a arquitetura de alto nível e os serviços AWS envolvidos.

Para os dados, o Amazon DynamoDB guarda diretrizes, cláusulas extraídas e resultados de análise, e o Amazon S3 guarda os documentos de contrato. No acesso, o Amazon API Gateway expõe APIs REST para o frontend React, com autenticação no Amazon Cognito. Entre os workflows, a comunicação assíncrona passa pelo Amazon EventBridge.

Cada tarefa que invoca o Amazon Bedrock, em qualquer um dos três workflows, pode usar um modelo diferente, configurado via AWS Systems Manager Parameter Store em tempo de execução, sem nova implantação. Tarefas que pedem menos raciocínio, como a extração de cláusulas, usam modelos menores e mais econômicos. Já o julgamento mais sofisticado, como a avaliação de conformidade, roda em modelos mais capazes. Para detalhes sobre preços, consulte a página de preços do Amazon Bedrock.

Configuração de tipos de contrato e diretrizes

Antes de analisar contratos, você precisa configurar as diretrizes que a aplicação usa como referência. Essa configuração define o que ela considera “conforme” para o seu contexto.

A configuração se organiza em dois níveis. No nível do contrato, você cria um tipo (ex: “Contrato de Prestação de Serviços”) e define os papéis das partes envolvidas (ex: “Cliente” e “Prestador de Serviços”). Você também define os limites de tolerância de risco e o idioma de saída (PT-BR, ES ou EN). A imagem a seguir mostra o formulário de criação de um tipo de contrato.

O idioma de saída é um parâmetro que percorre o pipeline e instrui o modelo a gerar classificações, justificativas e respostas no idioma escolhido. Os modelos Amazon Nova e Claude trabalham com os três idiomas de forma nativa e dispensam uma etapa de tradução separada: o pipeline apenas inclui o idioma alvo nas instruções do prompt.

No nível das cláusulas, você registra os tipos esperados para aquele contrato (ex: “Padrões de Desempenho”, “Limitação de Responsabilidade”). Para cada tipo, você define uma redação padrão que representa a cláusula ideal, exemplos alternativos de redação para classificação e perguntas de sim ou não para avaliação. Os tipos de cláusula de um contrato aparecem na imagem a seguir, cada um com seu nível de impacto e a contagem de perguntas e exemplos.

Você pode registrar essas diretrizes de duas maneiras, conforme prefira definir cada detalhe ou partir de um contrato existente:

• Configuração manual via interface web: você cria o tipo de contrato, adiciona os tipos de cláusula com suas redações padrão e define as perguntas de avaliação. A interface permite criar, editar e desativar tipos de contrato sem alterar código.
• Importação a partir de um contrato referência: você envia um contrato que já segue suas diretrizes internas, e a aplicação deriva dele um rascunho do tipo de contrato.

Você inicia a importação pela interface web, enviando um documento de contrato de referência. A imagem a seguir mostra o modal de importação.

A importação segue o mesmo padrão serverless dos demais workflows: um workflow de Step Functions encadeia uma função Lambda por etapa. Ele extrai o conteúdo do documento e, com o Amazon Bedrock, deriva o tipo de contrato: nome, partes envolvidas e idioma. Também identifica os tipos de cláusula presentes, com seus textos referência e o nível de impacto sugerido. O resultado é um novo tipo de contrato inativo: um rascunho que acelera a configuração, mas ainda sem as perguntas de avaliação. Você revisa o que foi extraído e define as perguntas antes de ativá-lo. O diagrama a seguir mostra as etapas desse workflow e os serviços que ele usa.

Em ambos os casos, as perguntas de sim ou não para avaliação podem ser escritas manualmente ou geradas por IA a partir da redação padrão. Na interface web, você fornece o texto referência e seleciona “Gerar Perguntas”. A aplicação gera candidatas e as apresenta para revisão antes de ativá-las.

Para filtrar perguntas de baixa qualidade, a aplicação valida cada pergunta gerada antes de apresentá-la. A IA gera a pergunta com raciocínio explícito, depois um “Crítico” (simulado no mesmo prompt) verifica se a pergunta seria respondida como “Sim” quando aplicada à cláusula referência. O Crítico descarta automaticamente as perguntas que responde com “Não” ou “Não tenho certeza”. O mesmo mecanismo gera exemplos alternativos de redação, usados na etapa de classificação. A equipe jurídica revisa e aprova o resultado final antes que entre em uso.

Workflow de conformidade com diretrizes

Com as diretrizes configuradas, você pode iniciar a análise de um contrato fazendo upload de um documento pela interface web. O upload dispara o workflow de conformidade com diretrizes, uma sequência de etapas no Step Functions que extrai as cláusulas do documento e classifica cada uma. O diagrama a seguir detalha esse workflow, em que o Step Functions encadeia uma função Lambda por etapa, da validação à avaliação de risco. As subseções a seguir descrevem as etapas de classificação, avaliação de conformidade e avaliação de risco.

Classificação de cláusulas

Para classificar cada cláusula, o pipeline envia ao LLM um system prompt com três elementos: a lista de tipos possíveis, exemplos de referência para cada tipo e regras de raciocínio estritas. Os exemplos funcionam como few-shot, técnica que fornece exemplos no próprio prompt para guiar o modelo:

SYSTEM_PROMPT_TEMPLATE = """You are a Senior Specialist in Law, very skilled 
in understanding of contracts, and you work for company {company_name}.
...

You task is to say whether any of the following possible types is highly 
applicable to the clause:
<possible_types>
{possible_types}
</possible_types>

Rules of thought process:
<rules_of_thought_process>
- Making deductions is forbidden
- Proposing premises is forbidden.
- Making generalizations is forbidden.
- Making implications/deductions about implicit content is forbidden.
</rules_of_thought_process>

Examples:
<examples>
{examples}
</examples>
...
"""

Essas regras orientam o modelo a evitar deduções, premissas, generalizações e inferências de conteúdo implícito. A classificação deve se basear apenas no que está explicitamente escrito na cláusula, sem interpretações criativas. Na nossa experiência, sem essas restrições, a classificação tende a ser excessivamente ampla, gerando falsos positivos que invalidam a análise.

O modelo produz os tipos aplicáveis em tags XML estruturadas, cada uma com sua justificativa.

A classificação processa as cláusulas sequencialmente, em um estado Map do Step Functions. O system prompt contém todas as diretrizes e exemplos e costuma concentrar a maior parte dos tokens de entrada. Como ele é o mesmo a cada chamada, processar em sequência mantém esse conteúdo em cache com o prompt caching do Amazon Bedrock. Cada chamada cobra então apenas o texto da cláusula individual como tokens novos, o que reduz o custo.

Avaliação de conformidade baseada em perguntas

A etapa de avaliação verifica se cada cláusula atende às diretrizes da organização. Em vez de solicitar uma análise aberta, ela apresenta perguntas de sim ou não específicas para cada tipo de cláusula. Como as cláusulas são avaliadas de forma independente e com prompts menores, essa etapa roda em paralelo em seu próprio estado Map do Step Functions.

Você define as diretrizes em um JSON estruturado. Cada tipo de cláusula inclui um nome, nível de impacto, exemplos de referência e perguntas de sim ou não:

{
  "name": "Padrões de Desempenho",
  "level": "medium",
  "evaluation_questions": [
    "A cláusula especifica que o Prestador de Serviços deve executar os serviços de maneira profissional?",
    "A cláusula exige que o Prestador de Serviços execute os serviços de maneira pontual?",
    "A cláusula estabelece que os serviços devem ser executados de acordo com os padrões da indústria?",
    "..."
  ],
  "examples": [
    "O Prestador de Serviços deve desenvolver o sistema de software ERP de acordo com as especificações...",
    "..."
  ]
}

A lógica de conformidade é clara: se todas as respostas forem “Sim”, a cláusula está conforme para aquele tipo. Qualquer resposta “Não” ou “Não tenho certeza” torna a cláusula não conforme.

Essa abordagem tem duas vantagens. As perguntas são auditáveis: a equipe jurídica revisa exatamente quais critérios a aplicação avaliou e qual foi a resposta para cada um. A equipe também não precisa escrever as perguntas manualmente, já que a IA pode gerá-las com apoio de validação, como descrito na seção “Configuração de tipos de contrato e diretrizes”.

Após a análise, o relatório mostra para cada cláusula o texto original, a classificação identificada, o status de conformidade e a justificativa para cada pergunta avaliada. A imagem a seguir mostra a análise de uma cláusula, com as perguntas de avaliação e suas respostas.

Avaliação de risco

A etapa final combina os resultados de todas as cláusulas numa avaliação de risco do contrato. Cada tipo de cláusula tem um nível de impacto (alto, médio ou baixo), e a aplicação determina a contribuição de cada cláusula ao risco agregado combinando esse impacto com o status de conformidade. Um tipo de cláusula esperado pela diretriz que o contrato não contém também gera risco, proporcional ao impacto desse tipo.

Cada tipo de contrato define seus próprios limites de tolerância. Por exemplo: zero ocorrências de alto risco, máximo 1 de médio, máximo 3 de baixo. Se o contrato excede qualquer limite, a aplicação o marca como não conforme. A imagem a seguir exibe a matriz de conformidade e a avaliação de risco resultante, com o veredicto final do contrato.

Workflow de conformidade com legislação

Além da conformidade com diretrizes internas, pode ser necessário verificar se as cláusulas estão de acordo com a legislação vigente. A aplicação oferece um módulo opcional que usa RAG (Retrieval-Augmented Generation), uma técnica que combina busca em documentos com geração de texto por IA, para fundamentar a análise nos textos legais reais. O módulo usa Amazon Bedrock Knowledge Bases com Amazon OpenSearch Serverless para essa finalidade.

O Amazon EventBridge aciona o módulo automaticamente quando a opção de configuração legislationCheck está habilitada na tarefa de avaliação do contrato. Após o pré-processamento extrair as cláusulas, um evento PreProcessedContract dispara o workflow de legislação em paralelo ao pipeline principal de conformidade com diretrizes.

A arquitetura usa o Amazon Bedrock AgentCore para executar um agente que consulta uma Knowledge Base contendo documentos de legislação indexados (por exemplo, o Código Civil brasileiro). Para cada cláusula, o agente busca trechos relevantes da legislação e produz uma análise detalhada com referências a artigos específicos. A análise indica se a cláusula atende à legislação consultada.

O diagrama a seguir mostra esse workflow e os serviços que o compõem.

Implante a aplicação

Você implanta a aplicação na sua própria conta AWS: o backend com o AWS CDK, o frontend que se conecta a ele e, opcionalmente, o módulo de legislação em uma stack separada. As subseções a seguir cobrem cada etapa, da preparação do ambiente à remoção dos recursos.

Pré-requisitos

A aplicação usa o AWS Cloud Development Kit (AWS CDK) para infraestrutura como código. Para o backend, você precisa de uma conta AWS, Python 3.11+, Docker (o CDK o usa para empacotar as funções Lambda), o AWS CDK Toolkit e o AWS CLI configurado. O frontend exige Node.js e pnpm. Para confirmar que tudo está instalado, execute o comando a seguir:

python3 -V && cdk --version && docker info -f "{{.OperatingSystem}}"

Você também precisa de acesso aos modelos no Amazon Bedrock. Os modelos Amazon Nova ficam disponíveis automaticamente; os modelos Claude, usados no módulo de legislação, exigem habilitação prévia.

Backend

Para implantar o backend:

git clone https://github.com/aws-samples/generative-ai-cdk-constructs-samples.git
cd samples/contract-compliance-analysis/backend
pip install -r requirements.txt
cdk bootstrap
cdk deploy MainBackendStack --require-approval=never

A MainBackendStack contém os workflows de Step Functions, as funções Lambda, as tabelas do DynamoDB, os buckets do S3 e o pool do Cognito. Concluída a implantação, o CDK exibe os outputs com o endpoint da API e o ID do pool de usuários.

Com o backend implantado, você prepara a aplicação para o primeiro uso.

Para usar os modelos Claude, habilite o acesso com o script a seguir, que faz a submissão de caso de uso exigida uma vez por conta (execute o script sem argumentos para o modo interativo):

python scripts/enable_anthropic_models.py \
  --company-name "AnyCompany" \
  --use-cases "Contract compliance analysis using AI" \
  --industry "Technology"

Carregue as diretrizes de exemplo na tabela do DynamoDB, escolhendo o idioma com a flag --json-file:

python scripts/load_guidelines.py --json-file ../guidelines/guidelines_example_pt_BR.json

Essas diretrizes servem para uma demonstração rápida. Para um caso real, configure um tipo de contrato próprio: manualmente pela interface web ou por importação a partir de um contrato específico. A seção “Configuração de tipos de contrato e diretrizes” descreve os dois caminhos.

Caso queira mudar o modelo padrão por tarefa, gere o arquivo de configuração, edite os valores e aplique-os ao Parameter Store:

python scripts/init_app_properties.py        # gera app_properties.yaml
python scripts/apply_app_properties.py        # aplica ao Parameter Store

Para fazer login na interface web, crie um usuário no Amazon Cognito. O cdk deploy exibe o ID do pool de usuários nos outputs. Com esse ID, selecione o pool no console do Amazon Cognito e crie um usuário. O usuário recebe uma senha temporária para o primeiro acesso.

O módulo de conformidade com legislação fica em uma stack separada e opcional. A CheckLegislationStack contém a Knowledge Base, a coleção do Amazon OpenSearch Serverless e o agente no Amazon Bedrock AgentCore. Implante-a com cdk deploy CheckLegislationStack apenas se precisar verificar cláusulas contra a legislação vigente. Ao contrário do restante da aplicação, que é cobrado por uso, o OpenSearch Serverless tem um custo de base contínuo, mesmo quando ocioso.

Esses scripts ficam na pasta scripts do backend. O repositório do projeto detalha os parâmetros de cada um.

Frontend

A interface web conecta-se ao backend pelos outputs do CDK. Recupere os valores da stack, crie o arquivo .env a partir do example.env preenchendo com esses outputs, instale as dependências e inicie a aplicação:

cd ../frontend
aws cloudformation describe-stacks --stack-name MainBackendStack --query "Stacks[0].Outputs"
cp example.env .env   # preencha com os outputs acima
pnpm install
pnpm dev

O .env mapeia os outputs (endpoint da API, IDs do pool do Cognito, nome do bucket) para as variáveis que o frontend React consome no login e nas chamadas autenticadas.

Analise seu primeiro contrato

Com a aplicação implantada, você inicia uma análise pela interface web. Escolha “Nova Análise”, faça upload do contrato, selecione o tipo de contrato e o idioma do relatório e, se quiser checar contra a legislação, ative “Verificação de Legislação”. A imagem a seguir mostra esse formulário.

Quando você confirma, o upload dispara o pipeline de Step Functions descrito nas seções anteriores. A análise aparece na lista com seu status e, quando termina, os indicadores de conformidade com diretrizes, com legislação e o veredicto final. A imagem a seguir exibe a lista de análises.

Limpeza de recursos

Para evitar cobranças futuras, exclua as stacks ao terminar. Se você implantou o módulo de legislação, exclua a CheckLegislationStack antes da MainBackendStack, por causa da dependência entre elas:

aws cloudformation delete-stack --stack-name CheckLegislationStack
aws cloudformation delete-stack --stack-name MainBackendStack

O CDK remove automaticamente os buckets do Amazon S3 e as tabelas do DynamoDB com seu conteúdo. Alguns recursos, como grupos de log do Amazon CloudWatch, podem persistir e exigir remoção manual.

Conclusão

Neste post, apresentamos uma aplicação que acelera a análise de conformidade de contratos usando IA generativa com o Amazon Bedrock. No projeto de prototipação, a revisão de um contrato caiu de quase cinco dias para poucas horas. A abordagem baseada em perguntas de sim ou não com restrições lógicas estritas mantém cada decisão ancorada em critérios explícitos, em vez de um julgamento aberto do modelo. Cada decisão é rastreável à pergunta que a originou, o que torna o resultado auditável. A aplicação permite configurar múltiplos tipos de contrato com diretrizes próprias, opera em três idiomas e pode verificar cláusulas contra legislação vigente usando RAG com Amazon Bedrock Knowledge Bases. Em todos os casos, a aplicação apoia o trabalho da equipe jurídica, que mantém a palavra final sobre cada análise.

Como próximos passos, você pode adaptar o sample para o seu contexto. Por exemplo, adicione novas fontes de legislação à Knowledge Base. Você também pode escolher, para cada etapa, o modelo do Amazon Bedrock que melhor equilibra custo e capacidade no seu caso.

Para começar:

• Acesse o repositório no GitHub e implante a aplicação na sua conta
• Explore o Amazon Bedrock e os modelos Amazon Nova no console
• Saiba mais sobre Amazon Bedrock Knowledge Bases, a base do módulo de conformidade com legislação

Compartilhe sua experiência nos comentários!

Autores

	Givanildo Alves é Arquiteto de Prototipação Sênior na equipe de Prototyping and AI Customer Engineering (PACE) da AWS, onde ajuda clientes a inovar e acelerar na nuvem demonstrando a arte do possível, com foco em machine learning e IA generativa. Com mais de 20 anos de experiência em engenharia de software, ele anteriormente trabalhou como Engenheiro de Software na Amazon.com.br.
	Henrique Fugita é Arquiteto de Prototipação Sênior na equipe de Prototyping and AI Customer Engineering (PACE) da AWS, apoiando clientes e parceiros na construção de protótipos inovadores e na adoção de inteligência artificial e machine learning.
	Donato Azevedo é Arquiteto de Prototipação Sênior na equipe de Prototyping and AI Customer Engineering da AWS, onde ajuda clientes a realizar seu potencial usando serviços de nuvem. Ele tem experiência em engenharia de software com foco em inteligência e otimização de supply chain. Nas horas vagas ele gosta de fazer trilhas nas montanhas de Minas Gerais com sua filha.