Acelere el análisis de cumplimiento de contratos con Amazon Bedrock

Por Givanildo Alves, Arquitecto de Prototipado Sénior en el equipo de Prototyping and AI Customer Engineering (PACE) de AWS; Henrique Fugita, Arquitecto de Prototipado Sénior en el equipo de Prototyping and AI Customer Engineering (PACE) de AWS y Donato Azevedo, Arquitecto de Prototipado Sénior en el equipo de Prototyping and AI Customer Engineering de AWS.

Los equipos legales que verifican contratos frente a directrices internas conocen bien el desafío de acelerar el análisis de cumplimiento de contratos. En un proyecto de prototipado, observamos que los abogados tardaban en promedio casi cinco días en revisar un único contrato. En cada contrato, el equipo debe revisar las cláusulas una por una, clasificar el tema, evaluar su adecuación a las políticas de la organización y determinar el riesgo. Este proceso manual no escala a grandes volúmenes, y hacerlo sin sacrificar la consistencia requiere un enfoque diferente.

Varias etapas de este proceso corresponden a tareas de procesamiento de lenguaje natural: extraer y clasificar cláusulas y responder preguntas factuales sobre su contenido. Los modelos de lenguaje de gran tamaño (LLMs) disponibles en Amazon Bedrock tienen las capacidades necesarias para estas tareas. Sin embargo, un enfoque directo (como pedir «evalúa si este contrato cumple con las directrices») no ofrece la consistencia que exigen los contextos jurídicos. En estos contextos, cada decisión debe poder rastrearse hasta criterios específicos.

En esta publicación, describimos un enfoque que aborda este problema de forma estructurada y mostramos cómo desplegarlo y usarlo en su cuenta de AWS. Para cada cláusula, la aplicación formula preguntas objetivas de sí o no. También aplica reglas de razonamiento que indican al modelo que no debe hacer deducciones ni generalizaciones más allá del texto. La aplicación extrae cláusulas de los contratos, las clasifica por tipo, evalúa el cumplimiento con directrices predefinidas y calcula el riesgo del contrato. AWS Step Functions orquesta todo este pipeline de forma serverless. Con este enfoque, el tiempo de revisión se redujo de casi cinco días a unas pocas horas. Los abogados pasaron a concentrarse en las cláusulas marcadas por el sistema en lugar de leer cada contrato desde cero. El código fuente está disponible como ejemplo en el repositorio de GitHub.

Este prototipo no proporciona asesoramiento jurídico ni sustituye la asesoría profesional. El usuario debe realizar su propia evaluación y consultar a un profesional jurídico habilitado.

Descripción general de la solución

El análisis se ejecuta en un pipeline que recibe un contrato y devuelve una evaluación de riesgo fundamentada en directrices. El pipeline consta de cinco etapas:

1. Validación: verifica que el tipo de contrato existe y está activo
2. Preprocesamiento: extrae y separa las cláusulas del documento (PDF, DOCX o TXT)
3. Clasificación: determina el tipo de cada cláusula usando ejemplos de referencia
4. Evaluación: verifica el cumplimiento respondiendo preguntas de sí o no para cada cláusula
5. Evaluación de riesgo: agrega los resultados y determina el nivel de riesgo del contrato

Las tres primeras etapas preparan y clasifican el contenido del contrato, mientras que las dos últimas evalúan el cumplimiento y cuantifican el riesgo. Lo que distingue a este enfoque está en la etapa de evaluación, basada en preguntas. En lugar de solicitar al LLM una valoración abierta, la aplicación hace preguntas de sí o no específicas para cada tipo de cláusula, definidas y refinadas por el equipo legal de la organización. El modelo responde cada pregunta con Sí, No o No estoy seguro. Esto hace que la lógica de decisión sea transparente y que los resultados sean auditables.

El ahorro de tiempo proviene de cambiar dónde se aplica el trabajo manual. Antes, el equipo leía cada cláusula desde cero, clasificaba su tema y verificaba punto por punto frente a las políticas. Ahora recibe el contrato ya dividido en cláusulas, cada una clasificada y con las respuestas de cumplimiento y su justificación. La revisión humana pasa a concentrarse en las cláusulas que el sistema señala como no conformes, en lugar de recorrer el documento entero.

La aplicación permite configurar múltiples tipos de contrato, aislados entre sí, y opera en tres idiomas (portugués, español e inglés). Un módulo opcional de cumplimiento con legislación verifica las cláusulas frente a la legislación vigente.

Arquitectura

La aplicación tiene tres flujos de trabajo: análisis de cumplimiento con directrices, cumplimiento con legislación e importación de contrato de referencia. La construimos con servicios serverless de AWS, ya que el análisis de contratos es una carga de trabajo bajo demanda. Los recursos escalan a medida que llegan los contratos y no hay servidores ociosos entre los análisis.

AWS Step Functions orquesta estos flujos de trabajo e invoca funciones AWS Lambda (Python) para cada etapa. Amazon Bedrock proporciona la inferencia con modelos como Amazon Nova y Claude. Cada flujo de trabajo es una secuencia de etapas con necesidades distintas: algunas procesan el contrato entero y otras recorren las cláusulas una a una. Cada etapa define además su propia política de reintentos para las llamadas al modelo que fallan de forma transitoria. Modelar este flujo en Step Functions mantiene el orden de las etapas, la concurrencia de cada una y el manejo de errores fuera del código de las funciones Lambda. El flujo de directrices es el camino principal; el de legislación se ejecuta en paralelo cuando se activa, y el de importación se usa durante la configuración. El siguiente diagrama muestra la arquitectura de alto nivel y los servicios de AWS involucrados.

Para los datos, Amazon DynamoDB almacena directrices, cláusulas extraídas y resultados de análisis, y Amazon S3 almacena los documentos de contrato. Para el acceso, Amazon API Gateway expone APIs REST para el frontend React, con autenticación en Amazon Cognito. Entre los flujos de trabajo, la comunicación asíncrona pasa por Amazon EventBridge.

Cada tarea que invoca Amazon Bedrock, en cualquiera de los tres flujos de trabajo, puede usar un modelo diferente. Ese modelo se configura mediante AWS Systems Manager Parameter Store en tiempo de ejecución, sin necesidad de un nuevo despliegue. Las tareas que requieren menos razonamiento, como la extracción de cláusulas, usan modelos más pequeños y económicos. Las que demandan un análisis más sofisticado, como la evaluación de cumplimiento, recurren a modelos más avanzados. Para conocer los detalles sobre precios, consulte la página de precios de Amazon Bedrock.

Configuración de tipos de contrato y directrices

Antes de analizar contratos, debe configurar las directrices que la aplicación usa como referencia. Esta configuración define lo que la aplicación considera «conforme» para su contexto.

La configuración se organiza en dos niveles. En el nivel del contrato, usted crea un tipo (por ejemplo, «Contrato de Prestación de Servicios») y define los roles de las partes involucradas (por ejemplo, «Cliente» y «Prestador de Servicios»). También define los límites de tolerancia al riesgo y el idioma de salida (PT-BR, ES o EN). La siguiente imagen muestra el formulario de creación de un tipo de contrato.

El idioma de salida es un parámetro que recorre el pipeline e indica al modelo que genere las clasificaciones, las justificaciones y las respuestas en el idioma elegido. Los modelos Amazon Nova y Claude admiten los tres idiomas de forma nativa y no requieren una etapa de traducción separada: el pipeline solo incluye el idioma objetivo en las instrucciones del prompt.

En el nivel de las cláusulas, usted registra los tipos esperados para ese contrato (por ejemplo, «Estándares de Rendimiento», «Limitación de Responsabilidad»). Para cada tipo, define una redacción estándar que representa la cláusula ideal, ejemplos alternativos para la clasificación y preguntas de sí o no para la evaluación. Los tipos de cláusula de un contrato aparecen en la siguiente imagen, cada uno con su nivel de impacto y el número de preguntas y ejemplos.

Puede registrar estas directrices de dos maneras, según prefiera definir cada detalle o partir de un contrato existente:

• Configuración manual mediante la interfaz web: usted crea el tipo de contrato, agrega los tipos de cláusula con sus redacciones estándar y define las preguntas de evaluación. La interfaz permite crear, editar y desactivar tipos de contrato.
• Importación a partir de un contrato de referencia: envía un contrato que ya sigue sus directrices internas, y la aplicación deriva de él un borrador del tipo de contrato.

Para iniciar la importación, envíe un documento de contrato de referencia mediante la interfaz web. La siguiente imagen muestra el modal de importación.

La importación sigue el mismo patrón serverless que los demás flujos: un flujo de trabajo de Step Functions encadena una función Lambda por etapa. El flujo extrae el contenido del documento y, con Amazon Bedrock, deriva el tipo de contrato: nombre, partes involucradas e idioma. También identifica los tipos de cláusula presentes, con sus textos de referencia y el nivel de impacto sugerido. El resultado es un nuevo tipo de contrato inactivo: un borrador que acelera la configuración, pero todavía sin las preguntas de evaluación. Usted revisa el borrador y define las preguntas antes de activar el tipo de contrato. El siguiente diagrama muestra las etapas de este flujo de trabajo y los servicios que utiliza.

En ambos casos, puede escribir las preguntas de sí o no para la evaluación manualmente o generarlas con IA a partir de la redacción estándar. En la interfaz web, proporcione el texto de referencia y seleccione «Generar Preguntas». La aplicación genera preguntas candidatas y las presenta para su revisión antes de activarlas.

Para filtrar preguntas de baja calidad, la aplicación valida cada pregunta generada antes de presentarla. La IA genera la pregunta con razonamiento explícito. Luego, un «Crítico» (simulado en el mismo prompt) verifica si la pregunta se respondería con «Sí» al aplicarla a la cláusula de referencia. El Crítico descarta automáticamente las preguntas que responde con «No» o «No estoy seguro». El mismo mecanismo genera ejemplos alternativos de redacción, usados en la etapa de clasificación. El equipo legal revisa y aprueba el resultado final antes de que entre en uso.

Flujo de trabajo de cumplimiento con directrices

Con las directrices configuradas, puede iniciar el análisis de un contrato cargando un documento mediante la interfaz web. La carga desencadena el flujo de trabajo de cumplimiento con directrices, una secuencia de etapas en Step Functions que extrae las cláusulas del documento y clasifica cada una de ellas. El siguiente diagrama detalla este flujo de trabajo: Step Functions encadena una función Lambda por etapa, desde la validación inicial hasta la evaluación de riesgo. Las siguientes subsecciones describen las etapas de clasificación, evaluación de cumplimiento y evaluación de riesgo.

Clasificación de cláusulas

La clasificación determina qué preguntas de evaluación se aplican a cada cláusula en la etapa siguiente. Para clasificar cada cláusula, el pipeline envía al LLM un system prompt con tres elementos: la lista de tipos posibles, ejemplos de referencia para cada tipo y reglas estrictas de razonamiento. Los ejemplos funcionan como few-shot, una técnica que proporciona ejemplos en el propio prompt para guiar al 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>
...
"""

Estas reglas orientan al modelo a evitar deducciones, premisas, generalizaciones e inferencias de contenido implícito. La clasificación debe basarse solo en lo que está escrito explícitamente en la cláusula, sin interpretaciones creativas. En nuestra experiencia, sin estas restricciones, la clasificación tiende a ser demasiado amplia y genera falsos positivos que invalidan el análisis.

El modelo produce los tipos aplicables en etiquetas XML estructuradas, cada una con su justificación.

La clasificación procesa las cláusulas de forma secuencial, en un estado Map de Step Functions. El system prompt contiene todas las directrices y ejemplos, y suele concentrar la mayor parte de los tokens de entrada. Como es el mismo en cada llamada, procesar en secuencia mantiene ese contenido en caché con el prompt caching de Amazon Bedrock. Así, en cada llamada solo se cobra el texto de la cláusula individual como tokens nuevos, lo que reduce el costo.

Evaluación de cumplimiento basada en preguntas

La etapa de evaluación verifica si cada cláusula cumple las directrices de la organización. En lugar de solicitar un análisis abierto, presenta preguntas de sí o no específicas para cada tipo de cláusula. Como las cláusulas se evalúan de forma independiente y con prompts más pequeños, esta etapa se ejecuta en paralelo en su propio estado Map de Step Functions.

Usted define las directrices en un JSON estructurado. Cada tipo de cláusula incluye un nombre, un nivel de impacto, ejemplos de referencia y preguntas de sí o no:

{
  "name": "Estándares de Rendimiento",
  "level": "medium",
  "evaluation_questions": [
    "¿La cláusula especifica que el Prestador de Servicios debe realizar los servicios de manera profesional?",
    "¿La cláusula requiere que el Prestador de Servicios realice los servicios de manera oportuna?",
    "¿La cláusula indica que los servicios deben realizarse de acuerdo con los estándares de la industria?",
    "..."
  ],
  "examples": [
    "El Prestador de Servicios desarrollará el sistema de software ERP de acuerdo con las especificaciones...",
    "..."
  ]
}

La lógica de cumplimiento es clara: si todas las respuestas son «Sí», la cláusula cumple para ese tipo. Cualquier respuesta «No» o «No estoy seguro» hace que la cláusula sea no conforme.

Este enfoque tiene dos ventajas. Las preguntas son auditables: el equipo legal revisa exactamente qué criterios evaluó la aplicación y cuál fue la respuesta para cada uno. El equipo tampoco necesita escribir las preguntas manualmente, ya que la IA puede generarlas con apoyo de validación, como se describe en la sección «Configuración de tipos de contrato y directrices».

Tras el análisis, el informe muestra para cada cláusula el texto original, la clasificación identificada, el estado de cumplimiento y la justificación de cada pregunta evaluada. La siguiente imagen muestra el análisis de una cláusula, con las preguntas de evaluación y sus respuestas.

Evaluación de riesgo

La etapa final combina los resultados de todas las cláusulas en una evaluación de riesgo del contrato. Cada tipo de cláusula tiene un nivel de impacto (alto, medio o bajo), y la aplicación determina la contribución de cada cláusula al riesgo agregado combinando ese impacto con el estado de cumplimiento. Si el contrato no contiene un tipo de cláusula que la directriz espera, esa ausencia también genera riesgo, proporcional al impacto de ese tipo.

Cada tipo de contrato define sus propios límites de tolerancia. Por ejemplo: cero ocurrencias de riesgo alto, máximo 1 de riesgo medio, máximo 3 de riesgo bajo. Si el contrato excede cualquier límite, la aplicación lo marca como no conforme. La siguiente imagen muestra la matriz de cumplimiento y la evaluación de riesgo resultante, con el veredicto final del contrato.

Flujo de trabajo de cumplimiento con legislación

Además del cumplimiento con directrices internas, puede ser necesario verificar si las cláusulas se ajustan a la legislación vigente. La aplicación ofrece un módulo opcional que usa RAG (Retrieval-Augmented Generation) para fundamentar el análisis en los textos legales reales. RAG es una técnica que combina la búsqueda en documentos con la generación de texto por IA. El módulo usa Amazon Bedrock Knowledge Bases con Amazon OpenSearch Serverless con este fin.

Amazon EventBridge activa el módulo automáticamente cuando la opción de configuración legislationCheck está habilitada en la tarea de evaluación del contrato. Después de que el preprocesamiento extrae las cláusulas, un evento PreProcessedContract dispara el flujo de trabajo de legislación en paralelo al pipeline principal de cumplimiento con directrices.

La arquitectura usa Amazon Bedrock AgentCore para ejecutar un agente que consulta una Knowledge Base que contiene documentos de legislación indexados (por ejemplo, el Código Civil brasileño). Para cada cláusula, el agente busca fragmentos relevantes de la legislación y produce un análisis detallado con referencias a artículos específicos. El resultado indica si la cláusula cumple con la legislación consultada.

El siguiente diagrama muestra este flujo de trabajo y los servicios que lo componen.

Despliegue la aplicación

La aplicación se despliega en su propia cuenta de AWS: el backend con AWS CDK, el frontend que se conecta a él y, opcionalmente, el módulo de legislación en un stack separado. Las siguientes subsecciones cubren cada etapa, desde la preparación del entorno hasta la eliminación de los recursos.

Requisitos previos

La aplicación usa AWS Cloud Development Kit (AWS CDK) para la infraestructura como código. Para el backend, necesita una cuenta de AWS, Python 3.11+, Docker (CDK lo usa para empaquetar las funciones Lambda), AWS CDK Toolkit y AWS CLI configurado. El frontend requiere Node.js y pnpm. Para confirmar que todo está instalado, ejecute el siguiente comando:

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

También necesita acceso a los modelos en Amazon Bedrock. Los modelos Amazon Nova se activan automáticamente; los modelos Claude, usados en el módulo de legislación, requieren habilitación previa.

Backend

Para desplegar el 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

El MainBackendStack contiene los flujos de trabajo de Step Functions, las funciones Lambda, las tablas de DynamoDB, los buckets de S3 y el grupo de usuarios de Cognito. Una vez completado el despliegue, CDK muestra los outputs con el endpoint de la API y el ID del grupo de usuarios.

Con el backend desplegado, prepare la aplicación para el primer uso.

Para usar los modelos Claude, habilite el acceso con el siguiente script, que registra el caso de uso requerido una vez por cuenta (ejecute el script sin argumentos para el modo interactivo):

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

Cargue las directrices de ejemplo en la tabla de DynamoDB, indicando el archivo del idioma deseado con la flag --json-file:

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

Estas directrices sirven para una demostración rápida. Para un caso real, configure un tipo de contrato propio: manualmente mediante la interfaz web o importándolo a partir de un contrato específico. La sección «Configuración de tipos de contrato y directrices» describe los dos caminos.

Si desea cambiar el modelo predeterminado por tarea, genere el archivo de configuración, edite los valores y aplíquelos al Parameter Store:

python scripts/init_app_properties.py        # genera app_properties.yaml
python scripts/apply_app_properties.py        # aplica al Parameter Store

Para iniciar sesión en la interfaz web, cree un usuario en Amazon Cognito. El comando cdk deploy muestra el ID del grupo de usuarios en los outputs. Con ese ID, seleccione el grupo de usuarios en la consola de Amazon Cognito y cree un usuario. El usuario recibe una contraseña temporal para el primer acceso.

El módulo de cumplimiento con legislación se encuentra en un stack separado y opcional. El CheckLegislationStack contiene la Knowledge Base, la colección de Amazon OpenSearch Serverless y el agente en Amazon Bedrock AgentCore. Despliéguelo con cdk deploy CheckLegislationStack solo si necesita verificar cláusulas frente a la legislación vigente. A diferencia del resto de la aplicación, que se cobra por uso, OpenSearch Serverless tiene un costo base continuo, incluso cuando está inactivo.

Estos scripts se encuentran en la carpeta scripts del backend. El repositorio del proyecto detalla los parámetros de cada uno.

Frontend

La interfaz web se conecta al backend mediante los outputs de CDK. Recupere los valores del stack, cree el archivo .env a partir de example.env completándolo con esos outputs, instale las dependencias e inicie la aplicación:

cd ../frontend
aws cloudformation describe-stacks --stack-name MainBackendStack --query "Stacks[0].Outputs"
cp example.env .env   # complete con los outputs anteriores
pnpm install
pnpm dev

El archivo .env asigna esos outputs (endpoint de la API, IDs del grupo de usuarios de Cognito, nombre del bucket) a las variables del frontend React. El frontend las consume durante el inicio de sesión y en las llamadas autenticadas.

Analice su primer contrato

Con la aplicación desplegada, inicie un análisis mediante la interfaz web. Seleccione «Nuevo Análisis», cargue el contrato e indique el tipo de contrato y el idioma del informe. Si quiere verificar frente a la legislación, active «Verificación de Legislación». La siguiente imagen muestra este formulario.

Cuando confirma, la carga dispara el pipeline de Step Functions descrito en las secciones anteriores. El análisis aparece en la lista con su estado y, cuando termina, los indicadores de cumplimiento con las directrices y con la legislación, además del veredicto final. La siguiente imagen muestra la lista de análisis.

Limpieza de recursos

Para evitar cargos futuros, elimine los stacks al terminar. Si desplegó el módulo de legislación, elimine el CheckLegislationStack antes del MainBackendStack, debido a la dependencia entre ellos:

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

CDK elimina automáticamente los buckets de Amazon S3 y las tablas de DynamoDB con su contenido. Algunos recursos, como los grupos de logs de Amazon CloudWatch, pueden persistir y requerir eliminación manual.

Conclusión

En esta publicación, presentamos una aplicación que acelera el análisis de cumplimiento de contratos usando IA generativa con Amazon Bedrock. En el proyecto de prototipado, la revisión de un contrato pasó de casi cinco días a unas pocas horas. El enfoque basado en preguntas de sí o no con restricciones lógicas estrictas mantiene cada decisión anclada en criterios explícitos, en lugar de una valoración abierta del modelo. Cada decisión es rastreable hasta la pregunta que la originó, lo que hace que el resultado sea auditable. La aplicación permite configurar múltiples tipos de contrato con directrices propias, opera en tres idiomas y puede verificar cláusulas frente a la legislación vigente mediante RAG con Amazon Bedrock Knowledge Bases. En todos los casos, el sistema apoya el trabajo del equipo legal, que mantiene la palabra final sobre cada análisis.

Como próximos pasos, puede adaptar el sample a su contexto. Por ejemplo, agregue nuevas fuentes de legislación a la Knowledge Base. También puede elegir, para cada etapa, el modelo de Amazon Bedrock que mejor equilibre costo y capacidad en su caso.

Para comenzar:

• Acceda al repositorio en GitHub y despliegue la aplicación en su cuenta
• Explore Amazon Bedrock y los modelos Amazon Nova en la consola
• Conozca más sobre Amazon Bedrock Knowledge Bases, la base del módulo de cumplimiento con legislación

¡Comparta su experiencia en los comentarios!

Acerca de los autores

	Givanildo Alves es Arquitecto de Prototipado Sénior en el equipo de Prototyping and AI Customer Engineering (PACE) de AWS, donde ayuda a los clientes a innovar y acelerar en la nube demostrando el arte de lo posible, con foco en machine learning e IA generativa. Con más de 20 años de experiencia en ingeniería de software, anteriormente trabajó como Ingeniero de Software en Amazon.com.br.
	Henrique Fugita es Arquitecto de Prototipado Sénior en el equipo de Prototyping and AI Customer Engineering (PACE) de AWS, donde apoya a clientes y socios en la construcción de prototipos innovadores y en la adopción de inteligencia artificial y machine learning.
	Donato Azevedo es Arquitecto de Prototipado Sénior en el equipo de Prototyping and AI Customer Engineering de AWS, donde ayuda a los clientes a alcanzar su potencial usando servicios de nube. Tiene experiencia en ingeniería de software con foco en inteligencia y optimización de supply chain. En su tiempo libre le gusta hacer senderismo en las montañas de Minas Gerais con su hija.

Este contenido ha sido traducido de la publicación original del blog, que se puede encontrar aquí.