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

Para um engenheiro ou responsável pela conformidade, a questão é saber se esta separação é adequada à decisão em análise. O exemplo utiliza contratos sintéticos, regras inventadas e citações fictícias. As contagens ilustram o formato de saída pretendido; nada revelam sobre a precisão em contratos ou legislação reais.

A grande mudança

  • O que mudou: O exemplo da AWS transforma a IA numa interface controlada para ferramentas de revisão fixas. Um motor de regras determina os resultados para uma população de contratos de arrendamento enumerada.
  • Por que isso importa: As regras versionadas e um comprovativo das evidências permitem aos revisores inspecionar, fora do chat, a forma como os registos selecionados foram avaliados.
  • O que observar: O comprovativo não valida o inventário, a extração nem as regras jurídicas. Quem adotar a solução terá de verificar esses elementos, a atribuição dos pedidos aos utilizadores e o desempenho com dados próprios.

A população tem de ser definida antes do prompt

Um utilizador pode perguntar ao Quick quais os contratos de arrendamento no Texas que violam uma regra relativa a penalizações por atraso numa data específica. O Quick encaminha o pedido para sweep_compliance, uma das seis operações MCP identificadas. A operação utiliza a jurisdição e a data indicadas 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 cumpre a regra. O motor de regras aplica operadores de comparação fixos, recebendo os valores das regras como parâmetros. Segundo a AWS, a verificação oficial não consulta nenhum modelo. A AWS explica aqui o contrato da operação; o repositório descreve a implementação.

As outras ferramentas têm âmbitos mais restritos. simulate_rule_change fornece contagens exploratórias para um valor proposto, sem registar ocorrências. explore_clauses ordena por semelhança semântica uma amostra filtrada e não consegue responder a «quantos?». get_finding recupera uma cadeia de evidências; list_rules mostra quais as regras em vigor numa determinada data; check_connection verifica a ligação ao serviço. A distinção é importante porque uma amostra de cláusulas relevantes não equivale a um levantamento exaustivo.

O varrimento gera um comprovativo que contabiliza todos os registos analisados em quatro categorias: em conformidade, em violação, ambíguos ou ilegíveis. Antes de gravar os resultados, o motor verifica se a soma das contagens corresponde ao total analisado. O Quick pode apresentar as contagens e uma pequena amostra, enquanto um painel do Quick Sight consulta os resultados completos no mesmo repositório de dados Aurora. Cada ocorrência inclui o texto da cláusula, os valores extraídos e esperados, a versão da regra e a citação. Estas são características do projeto de exemplo da AWS; não significam que a BIG CHANGE tenha executado ou verificado os resultados de forma independente.

O comprovativo contabiliza a população selecionada. Não demonstra que o inventário de origem inclua todos os contratos, que a extração tenha captado corretamente todas as cláusulas relevantes nem que uma regra reflita a legislação em vigor. Para validar esses pontos são necessários processos separados de conciliação, revisão da extração e aprovação jurídica. Se não for claro o que se entende por «todos os contratos de arrendamento no Texas», uma contagem exata pode ainda assim descrever o conjunto errado.

O que teria de construir

A arquitetura de exemplo coloca um agente de chat do Quick à frente de um servidor MCP executado no AWS Lambda. O Amazon Cognito emite um token de serviço, que o API Gateway valida. O Lambda lê e grava dados no Aurora Serverless v2 através da RDS Data API. O Quick Sight acede à mesma base de dados através de uma ligação VPC. A AWS reserva os embeddings do Bedrock e um modelo de linguagem para a ferramenta exploratória de pesquisa de cláusulas; o varrimento oficial continua a ser determinístico.

O exemplo publicado inclui um corpus sintético de 50.000 contratos, um conjunto de regras versionado e um script de aceitação que, segundo a AWS, executa 28 verificações num ambiente implementado. O repositório alerta expressamente que o código não está pronto para produção, que o conteúdo jurídico é inventado e que os dados reais dos arrendatários exigem testes de segurança adicionais e validação jurídica independente. Analisámos a documentação e a descrição do repositório; não implementámos o ambiente, executámos essas verificações nem testámos o encaminhamento de ferramentas do agente de chat.

Para adaptar o exemplo, comece por estabelecer o inventário oficial dos registos e um critério de inclusão preciso. Depois, decida que campos podem ser extraídos de forma fiável, que comparações entre regras são realmente mecânicas e quem aprova cada versão das regras. Registe o texto de origem, o estado da extração, a versão da regra, o operador, os valores comparados, a data e o ID da ocorrência, para que um revisor possa reconstituir o resultado. Reconcilie o comprovativo com o inventário fora da resposta do chat. Estas são verificações de conceção baseadas nas garantias e nos limites declarados pelo exemplo; não são etapas que tenhamos testado.

Segundo a AWS, o token de credenciais de cliente do Cognito identifica a aplicação Quick, não a pessoa que coloca a pergunta no chat. O exemplo depende da correlação entre o ID e a hora do varrimento e a camada de auditoria do Quick para identificar o utilizador; a AWS sugere transmitir e armazenar o ID do utilizador final se o próprio repositório de conformidade tiver de registar essa identidade. Uma equipa que precise de tratar cada ocorrência como um registo de auditoria autónomo deve definir essa arquitetura antes da implementação.

Acesso, limites e custos

O guia da AWS pressupõe a existência de uma conta AWS, credenciais configuradas para a AWS CLI v2, Python e Node 24 para o CDK, acesso aos modelos no us-east-1, bem como um ambiente Amazon Quick com um conector MCP e o Quick Sight. A publicação indica Python 3.12; o README associado 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 trata-se de uma dependência do exemplo, não de 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 ligação ao servidor e não transmite cabeçalhos HTTP personalizados. Esse limite de tempo deve ser testado para um varrimento de grande dimensão: mesmo uma tarefa de base 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 indica que a lista de ferramentas de um conector personalizado pode ser atualizada com Sync. O blogue da AWS e o README do exemplo, por outro lado, instruem os utilizadores a eliminar e recriar a integração depois de alterações às ferramentas. Siga a documentação atual do Quick para o conector em uso e verifique a lista de ferramentas registadas e o respetivo encaminhamento no seu próprio ambiente.

Como esta solução recorre a vários serviços, a informação publicada não permite calcular um «preço por varrimento» único e defensável. A página de preços do Quick distingue os custos de subscrição dos custos por hora de agente e indica encargos adicionais do Quick Sight para algumas funcionalidades. 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 suspender a base de dados quando o consumo chega a zero. Também é necessário estimar a carga de trabalho do API Gateway, do Lambda e de eventuais chamadas exploratórias ao Bedrock. O repositório recomenda destruir o ambiente após a avaliação para evitar custos contínuos. Não foram criados recursos AWS para este artigo.

Lista de verificação para apoiar a decisão

Utilize esta abordagem apenas depois de a equipa conseguir responder às seguintes perguntas com os seus próprios dados e controlos:

  • Consegue enumerar a população completa com um critério de seleção estável e revisto, e conciliá-la com um inventário oficial?
  • As regras consistem em comparações mecânicas, com versões aprovadas, datas de entrada em vigor e citações? Que casos devem permanecer ambíguos e ser encaminhados para revisão humana?
  • Consegue contabilizar as falhas de extração e os documentos ilegíveis, em vez de os excluir silenciosamente?
  • Cada ocorrência conserva a cláusula de origem, os valores comparados e a versão da regra? É possível recuperar o conjunto completo de evidências fora do chat?
  • O varrimento consegue terminar dentro do tempo limite das operações do Quick? Como irá associar um resultado à pessoa que o solicitou?
  • A equipa estimou os custos de subscrição, da base de dados e dos serviços para o volume previsto e testou o desempenho e a qualidade dos resultados com dados cuja utilização é permitida?

Se a tarefa exigir interpretação jurídica ou juízo sobre uma norma aberta, um rótulo determinístico de aprovado/reprovado pode ocultar precisamente a decisão que requer avaliação humana. Se a equipa pretender exemplos representativos, a recuperação semântica é mais simples. Se um motor de regras revisto e um painel já servirem os utilizadores responsáveis pelas decisões, a camada conversacional é opcional. Estas alternativas decorrem da própria discussão da AWS sobre a «escolha errada» e dos limites do seu exemplo sintético.

Fontes e leituras complementares