A AWS publicou um projeto de referência do Amazon Quick para responder a perguntas de conformidade sobre um grande conjunto de contratos de aluguel. A ideia útil é uma transferência de responsabilidade bem definida: o modelo de chat seleciona uma ferramenta fixa e explica a resposta; um mecanismo de regras separado define a população e determina cada resultado. A publicação de 2 de outubro e o repositório de exemplo descrevem uma prova de conceito educacional, não um serviço de conformidade jurídica validado.

Para um engenheiro ou responsável por conformidade, a questão é se essa divisão serve à decisão em análise. O exemplo usa contratos sintéticos, além de regras e citações inventadas. Os totais apresentados ilustram o formato pretendido da saída; não dizem nada sobre a precisão em contratos ou leis reais.

A grande mudança

  • O que mudou: O exemplo da AWS transforma a IA em uma interface controlada para ferramentas de revisão fixas. Um mecanismo de regras determina os resultados para uma população enumerada de contratos de aluguel.
  • Por que isso importa: Regras versionadas e um comprovante de evidências permitem que os revisores inspecionem, fora do chat, como os registros selecionados foram avaliados.
  • O que observar: O comprovante não valida o inventário, a extração nem as regras jurídicas. Quem adotar o sistema precisa verificar esses dados, a atribuição aos usuários e o desempenho nos próprios dados.

A população vem antes do prompt

Um usuário pode perguntar ao Quick quais contratos de aluguel no Texas violam uma regra sobre multas por atraso em uma determinada data. O Quick encaminha a solicitação para sweep_compliance, uma das seis operações MCP nomeadas. A operação usa a jurisdição e a data especificadas para selecionar a população e as versões aplicáveis das regras. O modelo não escreve o SQL nem determina se uma cláusula está em conformidade. O mecanismo de regras aplica operadores de comparação fixos, com os valores das regras passados como parâmetros. Segundo a AWS, a varredura oficial não consulta um modelo. A AWS explica aqui o contrato da operação; o repositório descreve a implementação.

As outras ferramentas têm escopos mais restritos. simulate_rule_change fornece contagens exploratórias para um valor proposto, sem registrar constatações. explore_clauses classifica uma amostra filtrada por similaridade semântica e não responde à pergunta “quantos?”. get_finding recupera uma cadeia de evidências; list_rules mostra quais regras estavam em vigor em uma data; check_connection verifica o transporte. Essa distinção importa porque uma amostra de cláusulas relevantes não equivale a um censo.

A varredura gera um comprovante que contabiliza cada registro analisado em uma de quatro categorias: em conformidade, em violação, ambíguo ou ilegível. Antes de confirmar os resultados, o mecanismo verifica se a soma dessas contagens corresponde ao total analisado. O Quick pode exibir as contagens e uma pequena amostra, enquanto um painel do Quick Sight consulta os resultados completos no mesmo banco de dados Aurora. Cada constatação inclui o texto da cláusula, os valores extraídos e esperados, a versão da regra e a citação. Essas são características do projeto do exemplo da AWS, não uma afirmação de que a BIG CHANGE executou ou verificou os resultados de forma independente.

O comprovante contabiliza a população selecionada. Ele não demonstra que o inventário de origem contém todos os contratos, que a extração capturou corretamente todas as cláusulas relevantes nem que uma regra reflete a legislação vigente. Para isso, são necessários processos separados de conciliação, revisão da extração e aprovação jurídica. Se o denominador de “todos os contratos de aluguel no Texas” for incerto, uma contagem exata ainda poderá descrever o conjunto errado.

O que seria necessário construir

A arquitetura de exemplo coloca um agente de chat do Quick diante de um servidor MCP no AWS Lambda. O Amazon Cognito emite um token de serviço, que é verificado pelo API Gateway. O Lambda lê e grava no Aurora Serverless v2 por meio da RDS Data API. O Quick Sight acessa o mesmo banco de dados por uma conexão VPC. A AWS reserva as incorporações do Bedrock e um modelo de linguagem para a ferramenta exploratória de busca de cláusulas; a varredura oficial continua determinística.

O exemplo publicado contém um corpus sintético de 50.000 contratos de aluguel, um conjunto versionado de regras e um script de aceitação que, segundo a AWS, executa 28 verificações em uma pilha implantada. O repositório alerta explicitamente que o código não está pronto para produção, o conteúdo jurídico foi inventado e os dados reais de locatários exigem mais testes de segurança e validação jurídica independente. Inspecionamos a documentação e a descrição do repositório; não implantamos a pilha, executamos essas verificações nem testamos o roteamento de ferramentas do agente de chat.

Para adaptar o exemplo, primeiro estabeleça o inventário oficial dos registros e uma regra exata de inclusão. Depois, decida quais campos podem ser extraídos com confiabilidade, quais comparações de regras são realmente mecânicas e quem aprova cada versão das regras. Preserve o texto de origem, o status da extração, a versão da regra, o operador, os valores comparados, a data e o ID da constatação para que um revisor possa reconstruir o resultado. Concilie o comprovante com o inventário fora da resposta do chat. Essas verificações de projeto se baseiam nas garantias e nos limites declarados pelo exemplo; não são etapas que testamos.

Segundo a AWS, o token de credenciais de cliente do Cognito identifica o aplicativo Quick, não a pessoa que faz a pergunta no chat. O exemplo depende da correlação entre um ID e horário de varredura e a camada de auditoria do Quick para identificar o usuário; a AWS sugere transmitir e armazenar um ID de usuário final caso o próprio repositório de conformidade precise registrar essa identidade. Uma equipe que precise que cada constatação sirva, por si só, como registro de auditoria deve definir esse projeto antes da implantação.

Acesso, limites e custos

O passo a passo da AWS pressupõe uma conta AWS, credenciais configuradas da AWS CLI v2, Python e Node 24 para o CDK, acesso aos modelos no us-east-1, além de um ambiente do Amazon Quick com um conector MCP e o Quick Sight. A publicação menciona Python 3.12; o README vinculado exige Python 3.9 ou posterior. Consulte os requisitos atuais do repositório ao escolher um ambiente local. As instruções do exemplo fixam a versão 2.261.0 da CLI do CDK, mas essa versão é uma dependência do exemplo, não um requisito geral da AWS.

O atual guia de MCP do Quick define um tempo limite fixo de 60 segundos para cada operação, permite no máximo 100 ferramentas por conexão de servidor e não transmite cabeçalhos HTTP personalizados. Esse limite de tempo merece ser testado para cargas de trabalho de grande escala: mesmo uma tarefa de banco de dados correta e demorada não pode ser concluída como operação síncrona do Quick se ultrapassar o limite do conector. O guia diz que a lista de ferramentas de um conector personalizado pode ser atualizada com Sync. Já o blog da AWS e o README do exemplo instruem os usuários a excluir e recriar a integração após alterações nas ferramentas. Siga a documentação vigente do Quick para o conector atual e verifique a lista de ferramentas registradas e o roteamento no seu próprio ambiente.

Como se trata de uma implementação com vários serviços, o material publicado não permite defender um único “preço por varredura”. A página de preços do Quick separa os termos de assinatura e de horas de agente e lista cobranças adicionais do Quick Sight para alguns recursos. A página de preços do Aurora depende da configuração de capacidade, armazenamento e E/S; o exemplo mantém ativo um mínimo de 0,5 ACU em vez de pausar o banco até zero. Também é necessário estimar a carga de trabalho para o API Gateway, o Lambda e eventuais chamadas exploratórias ao Bedrock. O repositório sugere destruir a pilha após a avaliação para evitar cobranças contínuas. Nenhum recurso da AWS foi criado para este artigo.

Uma lista de verificação para decidir

Use esse padrão somente depois que a equipe puder responder às perguntas a seguir com os próprios dados e controles:

  • Você consegue enumerar toda a população com um predicado estável e revisado e conciliá-la com um inventário oficial?
  • As regras são comparações mecânicas, com versões aprovadas, datas de vigência e citações? Quais casos devem continuar ambíguos e ser encaminhados à revisão humana?
  • É possível contabilizar falhas de extração e documentos ilegíveis em vez de excluí-los silenciosamente?
  • Cada constatação mantém a cláusula de origem, os valores comparados e a versão da regra? Você consegue recuperar o conjunto completo de evidências fora do chat?
  • A varredura consegue terminar dentro do tempo limite das operações do Quick? Como você rastreará o resultado até a pessoa que o solicitou?
  • A equipe estimou os custos de assinatura, banco de dados e serviços para o volume esperado e, em seguida, testou o desempenho e a qualidade dos resultados em dados autorizados?

Se a tarefa exigir interpretação jurídica ou julgamento sobre um padrão em aberto, um rótulo determinístico de aprovação/reprovação pode ocultar justamente a decisão que exige análise humana. Se a equipe quiser exemplos representativos, a recuperação semântica é mais simples. Se um mecanismo de regras e um painel já revisados atendem aos usuários responsáveis, a camada de conversação é opcional. Essas alternativas decorrem da própria discussão da AWS sobre “escolher a opção errada” e dos limites do exemplo sintético.

Fontes e leituras complementares