Gerardo Arroyo for AWS Community Builders

Posted on Oct 3 • Originally published at gerardo.dev

Amazon Bedrock Guardrails Automated Reasoning Checks: Minimiza las Alucinaciones en IA con Verificación Matemática

#aws #ai #spanish #llm

Amazon Bedrock Guardrails Automated Reasoning Checks: Cuando las Matemáticas Vencen a las Alucinaciones

Hace unos meses, mientras presentaba una demo de un asistente de IA para procesos financieros, experimenté uno de esos momentos que todo desarrollador de IA generativa teme: el modelo, con absoluta confianza, me informó que "según las políticas de la empresa, los empleados pueden tomar hasta 45 días de vacaciones consecutivas sin aprobación previa".

El problema era evidente para cualquiera que conociera las políticas reales: el máximo permitido eran 10 días. Pero el modelo había "alucinado" una respuesta que sonaba perfectamente razonable, siguiendo los patrones del lenguaje corporativo, pero que era completamente incorrecta.

Esa experiencia frustrante me llevó a una búsqueda de soluciones que pudieran mejorar la precisión factual en aplicaciones críticas. Y esa búsqueda me trajo hasta Amazon Bedrock Guardrails Automated Reasoning Checks, una funcionalidad que promete algo revolucionario: verificación matemática formal con alta precisión para eliminar las alucinaciones de los LLMs.

El Problema Fundamental: Cuando la Creatividad se Convierte en Peligro

La Naturaleza Dual de los LLMs

Los modelos de lenguaje grandes han demostrado capacidades extraordinarias para generar contenido coherente y contextualmente relevante. Su fortaleza radica precisamente en su capacidad para predecir secuencias de texto basándose en patrones probabilísticos aprendidos durante el entrenamiento.

Sin embargo, esta misma capacidad creativa se convierte en una debilidad crítica cuando necesitamos respuestas precisas y verificables. El modelo no "sabe" cuándo está inventando información; simplemente genera la secuencia de texto más probable basada en su entrenamiento.

Ejemplos Reales de Alucinaciones Costosas

Durante mis años trabajando con IA generativa, he documentado patrones comunes de alucinaciones que pueden tener consecuencias graves:

Políticas Empresariales Inventadas:

"Los empleados nuevos tienen derecho a 6 meses de licencia médica pagada"
"Las compras superiores a $500 requieren 3 aprobaciones ejecutivas"
"El período de prueba estándar es de 180 días"

Regulaciones Financieras Incorrectas:

"Las transacciones internacionales están exentas de reporte hasta $25,000"
"Los clientes VIP pueden exceder límites de crédito hasta 300%"
"Las tasas de interés se pueden modificar retroactivamente hasta 6 meses"

Procedimientos de Seguridad Alterados:

"En emergencias, se puede omitir la autenticación de dos factores"
"Los datos sensibles pueden almacenarse temporalmente sin encriptación"
"Las llaves de acceso expiran automáticamente después de 12 meses"

Cada una de estas respuestas sonaba plausible, seguía patrones lingüísticos correctos, pero era factualmente incorrecta y potencialmente peligrosa.

🔍 ProTip: Las alucinaciones más peligrosas no son las respuestas obviamente incorrectas, sino aquellas que suenan tan plausibles que pasan desapercibidas hasta que causan problemas reales.

Advertencia Crítica de Seguridad:

Automated Reasoning Checks NO protege contra ataques de prompt injection.

Según la documentación oficial de AWS:

"Automated Reasoning checks in Amazon Bedrock Guardrails validate exactly what you send them - if malicious or manipulated content is provided as input, the validation will be performed on that content as-is (garbage-in, garbage-out)."

¿Qué significa esto?

Automated Reasoning valida la precisión matemática del contenido
NO valida si el contenido fue manipulado maliciosamente
Un atacante podría inyectar prompts que pasen la verificación matemática pero contengan instrucciones maliciosas

Protección Requerida:

Debes usar Content Filters en combinación con Automated Reasoning para protección completa:

Content Filters: Detectan y bloquean prompt injection y contenido malicioso
Automated Reasoning: Verifican precisión factual contra políticas

Nunca uses Automated Reasoning como tu única línea de defensa en producción.

La Revolución del Razonamiento Automatizado: Más Allá de las Probabilidades

¿Qué es Automated Reasoning Checks?

Amazon Bedrock Guardrails Automated Reasoning Checks representa un cambio paradigmático en la seguridad de IA. En lugar de depender únicamente de métodos probabilísticos tradicionales, utiliza verificación matemática formal para validar las respuestas de los LLMs contra políticas empresariales definidas.

La diferencia fundamental es extraordinaria:

Métodos tradicionales: "Tengo 85% de confianza en esta respuesta"
Automated Reasoning: "Esta respuesta es matemáticamente verificable como correcta o incorrecta"

📚 ¿Qué es SMT-LIB?: Es un lenguaje estándar para expresar problemas de lógica formal que pueden ser resueltos por "solvers" matemáticos. Piensa en él como el SQL de la verificación formal - un lenguaje estructurado que permite representar y resolver problemas lógicos complejos mediante técnicas matemáticas precisas.

Datos Verificables sobre Precisión de LLMs

Investigaciones recientes documentan las tasas reales de alucinación en diferentes contextos:

Modelos Top en Tareas de Summarization (Vectara Hallucination Leaderboard, actualizado septiembre 2025):

GPT-5: ~1-2% hallucination rate
Gemini-2.5 Pro: ~1-2% hallucination rate
Claude 4: ~1-2% hallucination rate

Generación de Referencias Médicas (JMIR, 2025):

GPT-4: 28.6% hallucination rate (mantenido de 2024, con mejoras en versiones posteriores)
GPT-3.5: 39.6% hallucination rate
Bard/Gemini: 91.3% hallucination rate (en 2024; actualizaciones 2025 muestran reducciones en omisiones al 3.45%, pero alucinaciones persisten sin diferencias significativas entre versiones)

Preguntas Open Domain (HaluEval, 2025):

Gemini-2.0-Flash-001: 0.7% hallucination rate
ChatGPT/Claude (versiones recientes): 40-50% hallucination rate (persistencia, con mejoras en benchmarks como HaluEval 2.0 y SOQHD)

Automated Reasoning con políticas bien estructuradas: Hasta 99% de precisión verificable matemáticamente, según anuncios oficiales de AWS blog AWS.

🔍 ProTip: Esta cifra de 99% proviene de datos de AWS; en pruebas reales, varía según la calidad de las políticas. Siempre verifica en tu entorno.

La Arquitectura Híbrida

La funcionalidad combina dos mundos que tradicionalmente han operado por separado:

Comprensión de Lenguaje Natural: Los LLMs procesan y entienden las consultas en lenguaje humano natural.
Verificación Matemática Formal: Motores de razonamiento simbólico validan matemáticamente el contenido contra reglas lógicas formales.

Esta arquitectura híbrida permite que el sistema:

Extraiga automáticamente políticas de documentos empresariales
Traduzca reglas en lenguaje natural a representaciones lógicas formales
Genere pruebas matemáticas verificables
Proporcione explicaciones comprensibles de por qué las respuestas son correctas o incorrectas

Proceso de Validación:

AWS utiliza múltiples LLMs para traducir el lenguaje natural a lógica formal. Solo retorna 'findings' donde un porcentaje significativo de LLMs concuerdan en la traducción, garantizando mayor precisión.

Figura 1: Arquitectura híbrida combinando LLMs con verificación matemática formal

Preparando Nuestro Laboratorio de Pruebas

Prerrequisitos

Para seguir esta implementación práctica, necesitarás:

Acceso a Amazon Bedrock con Guardrails habilitado
Permisos para crear y gestionar guardrails
Un modelo fundacional de tu elección (usaremos Claude Sonnet)
Documentos de políticas empresariales en formato PDF
AWS CLI o boto3 configurado con las credenciales apropiadas (si usas CloudShell, asegurate de actualizar boto a la última versión)

Configuración Inicial

Primero, accedemos a la consola de Amazon Bedrock y notarán que Automated Reasoning aparece como un servicio independiente en el menú de Bedrock, bajo la sección "Build". Esto refleja la importancia estratégica que AWS le da a esta funcionalidad, colocándola al mismo nivel que Agents, Flows, y Knowledge Bases.

Figura 2: Automated Reasoning como servicio independiente en la consola de Bedrock

Al acceder a está opción se nos presenta la siguiente pantalla con nuestras políticas.

Figura 3: Pantalla inicial de Automated Reasoning mostrando políticas configuradas

Cross-Region Inference: Optimización Transparente de Performance

Antes de comenzar con la implementación, es importante entender cómo Automated Reasoning optimiza el procesamiento de políticas mediante cross-region inference.

¿Qué es Cross-Region Inference?

Automated Reasoning distribuye automáticamente ciertas operaciones a través de múltiples regiones de AWS dentro de tu límite geográfico para garantizar disponibilidad y rendimiento óptimos.

Operaciones que Usan Cross-Region Inference:

Dos operaciones API específicas emplean este mecanismo:

StartAutomatedReasoningPolicyBuildWorkflow: Durante creación y compilación de políticas desde documentos fuente
StartAutomatedReasoningPolicyTestWorkflow: Durante validación y testing de políticas

Enrutamiento Geográfico:

Regiones US: Solicitudes desde US East (N. Virginia), US West (Oregon), o US East (Ohio) pueden procesarse en cualquier región US soportada
Regiones EU: Solicitudes desde EU (Frankfurt), EU (Paris), o EU (Ireland) pueden procesarse en cualquier región EU soportada

Garantías de Residencia de Datos:

🔒 Importante: Tus datos permanecen dentro del límite geográfico de origen (Estados Unidos o Unión Europea). El cross-region inference solo enruta solicitudes dentro de la misma frontera geográfica para optimizar performance, nunca cruza entre US y EU.

Transparencia Operacional:

No requiere configuración del cliente
Opera completamente transparente
La funcionalidad API es consistente independientemente de la región que procesa la solicitud
Optimiza automáticamente disponibilidad del servicio

Esta arquitectura garantiza que incluso cuando una región específica experimenta alta carga, tu experiencia con Automated Reasoning permanece consistente.

Implementación Paso a Paso: De Políticas a Lógica Formal

Paso 1: Creación del Guardrail Base

Comenzamos creando un nuevo guardrail que servirá como contenedor para nuestras políticas de razonamiento automatizado:

Figura 4: Definición del Guardrail base

Es importante que tengan activado el Cross Region inference, es un requisito para poder usar el razonamiento automatico.

Paso 2: Configuración de Automated Reasoning Policy

El corazón de la funcionalidad radica en la configuración de las políticas de razonamiento automatizado. Aquí es donde definimos las reglas que el sistema debe verificar matemáticamente.

Carga de Documentos de Políticas

He preparado tres documentos de políticas empresariales completos que puedes usar para tus pruebas. Están disponibles en mi repositorio de GitHub:

Vacation & Leave Policy: Políticas de vacaciones, licencias, y días festivos
Expense & Procurement Policy: Reglas de gastos y aprobaciones
Remote Work & Security Policy: Políticas de trabajo remoto y seguridad

Para este ejemplo, emplearemos la política de 'Vacation & Leave Policy'.

💡 ProTip: Los documentos de políticas pueden tener hasta 122,880 tokens (aproximadamente 100 páginas). El sistema extraerá automáticamente variables, reglas y tipos personalizados del texto para crear representaciones lógicas formales.

El Proceso de Extracción Automática: De Lenguaje Natural a Lógica Formal

Una vez que subimos nuestro documento PDF a Bedrock, ocurre algo muy interesante que estas capturas de pantalla reales demuestran perfectamente:

Figura 5: Vista general de la política procesada mostrando extracción automática de reglas

Análisis de la Extracción Automática:

La imagen muestra que Bedrock procesó automáticamente nuestro documento "Expense and Procurement Policy" y extrajo:

55 Reglas lógicas formales - Cada política empresarial convertida a lógica verificable
70 Variables - Elementos como accommodationCostPerNight, accommodationType, etc.
12 Tipos de variables personalizadas - Categorías como AccommodationType, FlightClass, MealType

Navegación por las Definiciones Extraídas

Figura 6: Menú de navegación mostrando secciones disponibles para análisis

El sistema organiza la información extraída en secciones claramente definidas:

Overview: Estadísticas generales de la extracción
Definitions: Reglas y variables extraídas
Tests: Escenarios de validación generados automáticamente
Annotations: Anotaciones y mejoras manuales
Saved versions: Control de versiones de políticas

Reglas Lógicas Formales en Acción

Figura 7: Reglas lógicas formales extraídas automáticamente del documento

Aquí vemos la verdadera magia del sistema. Cada regla muestra cómo el texto en lenguaje natural se convirtió a lógica formal:

Texto original: "International travel accommodation: Maximum $250 per night"

Regla extraída: 
if accommodationType is equal to INTERNATIONAL_TRAVEL, 
then accommodationCostPerNight is no more than 250

Ejemplos de Reglas Extraídas de Nuestro Documento:

YKFOR94I6RMO: if accommodationType is equal to INTERNATIONAL_TRAVEL, then accommodationCostPerNight is no more than 250
SKXABQXOFTRI: if accommodationType is equal to MAJOR_METROPOLITAN_AREA, then accommodationCostPerNight is no more than 300
M992BD5ESDHX: if accommodationType is equal to STANDARD_BUSINESS_TRAVEL, then accommodationCostPerNight is no more than 200

Estas reglas corresponden exactamente a nuestro documento donde especificamos:

Accommodation estándar: $200/noche
Major metropolitan areas: $300/noche
International travel: $250/noche

Variables y Tipos Personalizados

Figura 8: Variables y tipos personalizados extraídos del contexto empresarial

El sistema identificó automáticamente tipos de variables empresariales como:

AccommodationType: STANDARD_BUSINESS_TRAVEL, MAJOR_METROPOLITAN_AREA, INTERNATIONAL_TRAVEL
FlightClass: ECONOMY_CLASS, BUSINESS_CLASS, FIRST_CLASS
MealType: BREAKFAST, LUNCH, DINNER, CLIENT_ENTERTAINMENT_MEAL
ExpenseType: PERSONAL_ENTERTAINMENT, ALCOHOLIC_BEVERAGES, CLIENT_...

🔍 Insight Técnico: Esta extracción automática demuestra que el sistema no solo identifica números y reglas, sino que comprende el contexto semántico de las políticas empresariales, creando una ontología completa del dominio de negocio.

Advertencia Crítica: Reglas que No Son If-Then Pueden Causar Consecuencias No Intencionadas

Durante la extracción de reglas, es crucial entender una limitación fundamental que puede causar resultados inesperados:

{: .warning-box }

Las reglas que NO están en formato if-then pueden tener consecuencias no intencionadas al establecer axiomas absolutos sobre el mundo.

Ejemplo del problema:

 ❌ REGLA PELIGROSA (no if-then):
 accountBalance > 5

 Consecuencia: Se vuelve LÓGICAMENTE IMPOSIBLE que el balance de una cuenta 
 sea 5 o menos, sin importar qué dice el contenido a validar.

¿Por qué es problemático?

Esta regla establece un axioma - una verdad absoluta en el modelo lógico. Si tu política contiene accountBalance > 5 como regla absoluta, el sistema tratará cualquier mención de un balance ≤5 como una contradicción lógica, incluso si el usuario legítimamente pregunta sobre cuentas con balances bajos.

Resultado inesperado: Contenido podría ser incorrectamente marcado como INVALID porque contradice el axioma, no porque viole una política real.

Formato Correcto:

 ✅ REGLA CONDICIONAL (if-then):
 if accountType is equal to PREMIUM, then accountBalance is greater than 5

 Esto describe una RELACIÓN, no un axioma absoluto.

Mejor Práctica:

Siempre estructura reglas como declaraciones condicionales (if-then) que describen relaciones entre variables, no como restricciones absolutas sobre valores individuales.

Implicación para Variables No Utilizadas:

Este es uno de los motivos por los que las variables "no utilizadas" requieren atención. Si extraes una variable pero no la usas en ninguna regla if-then, podrías inadvertidamente crear restricciones absolutas que causen validaciones incorrectas.

El Poder de la Verificación Matemática

Lo más interesante de este proceso es que cada regla extraída puede ahora ser verificada matemáticamente. Cuando un usuario pregunta:

"What's the maximum hotel cost for international travel?"

El sistema:

Identifica que se refiere a accommodationType = INTERNATIONAL_TRAVEL
Busca la regla YKFOR94I6RMO
Retorna matemáticamente: accommodationCostPerNight ≤ 250
Proporciona la respuesta: "$250 per night" con certeza del 99%

Sistema de Testing Integrado

Una de las características más poderosas es el sistema de testing integrado que permite validar las políticas extraídas:

Figura 9: Interfaz de testing para validar políticas con confidence threshold

Componentes del Sistema de Testing:

Input (opcional): Una pregunta o contexto adicional
Output: El contenido que queremos validar
Expected Result: Si esperamos que sea "Valid" o "Invalid"
Confidence Threshold: El umbral de confianza para la validación

Generación Automática de Escenarios de Prueba

Este sistema tiene la capacidad para generar automáticamente escenarios de prueba basados en las reglas extraídas:

Figura 10: Generación automática de escenarios de prueba con lógica SMT-LIB

Análisis de la Generación Automática:

El sistema analiza las reglas de políticas extraídas y propone escenarios realistas para validación:

Escenario Generado:
"The following 3 statements are true: 
1) isTravelExpense is false; 
2) expenseAmount is equal to 1001; 
3) isPreApprovalMandatory is false"

Pregunta del Sistema: "Is this possible?"

Manejo de Issues: Variables y Tipos No Utilizados

Durante el proceso de extracción automática, el sistema identifica issues que requieren atención:

Figura 11: Variables extraídas mostrando issues de elementos no utilizados

Tipos de Issues Identificados:

Unused Variable: Variables extraídas pero no referenciadas en ninguna regla
- Ejemplo: actualApprovalLevel, afterHoursApprovalAmount
- Impacto: No afecta la funcionalidad pero indica posible información desconectada
Unused Values: Valores en tipos personalizados que no se usan en reglas
- Ejemplo: ACCOMMODATION_TYPE_OTHER en AccommodationType
- Impacto: Políticas incompletas o valores obsoletos
Unused Type: Tipos personalizados completos que no se referencian
- Impacto: Indica categorías extraídas pero no utilizadas en validaciones

Validación del Escenario contra Nuestras Políticas Reales

Este escenario generado automáticamente revela algo extraordinario: el sistema detectó una ambigüedad real en nuestro documento de políticas.

Análisis del Escenario:

NO es gasto de viaje (isTravelExpense = false)
Monto: $1,001 (expenseAmount = 1001)
NO requiere pre-aprobación (isPreApprovalMandatory = false)

Revisión de Nuestras Políticas:

Según nuestro documento "Expense and Procurement Policy":

Approval Matrix (Sección 3.1):

$501-$2,000: Department manager approval required

Pre-Approval Requirements (Sección 3.2):

"Travel expenses exceeding $1,000" (pero este NO es travel)
"Technology purchases exceeding $1,000"
"Conference and training expenses"
"Any expense exceeding daily/event limits"

El Problema Detectado Automáticamente:

El sistema identificó una inconsistencia potencial que nosotros como humanos pasamos por alto:

Según nuestro documento tal como está escrito: SÍ ES POSIBLE que un gasto no-viaje de $1,001 NO requiera pre-aprobación.

Justificación Técnica:

El documento NO establece una regla universal de pre-aprobación para todos los gastos >$1,000
Solo especifica categorías particulares: travel, technology, conference
Un gasto de $1,001 en "suministros de oficina" técnicamente NO requeriría pre-aprobación
Solo requeriría manager approval según la matriz de aprobaciones

Pero aquí está la brillantez del sistema: Esta respuesta técnicamente correcta revela un gap crítico en nuestras políticas.

Interpretaciones Reveladas:

Interpretación Técnica (según documento):
- Escenario VÁLIDO: Un gasto no-viaje de $1,001 NO requiere pre-aprobación
Interpretación de Negocio (intención probable):
- Escenario INVÁLIDO: Cualquier gasto de $1,001 SÍ debería requerir pre-aprobación

La Pregunta Crítica Revelada:
"¿Realmente queremos que alguien pueda gastar $1,001 en suministros de oficina sin pre-aprobación?"

La respuesta de negocio probablemente es NO, pero el documento escrito técnicamente lo permite.

Resolución Recomendada:

Para eliminar esta ambigüedad, la política debería clarificarse:

Regla Clarificada Sugerida:
"Any single expense exceeding $1,000, regardless of category, 
requires mandatory pre-approval AND department manager approval."

Nueva Regla SMT-LIB:
(assert (=> (> expenseAmount 1000) (= isPreApprovalMandatory true)))

🔍 ProTip: El sistema no está "equivocado" - está siendo matemáticamente preciso según el documento escrito. Esto es exactamente lo que queremos: detección automática de gaps entre la intención de negocio y la documentación real. Es auditoría de políticas automatizada que encuentra problemas antes de que causen problemas reales.

¿Qué está sucediendo técnicamente?

Análisis de Reglas: El sistema examina todas las reglas extraídas del documento
Generación SMT-LIB: Crea escenarios usando sintaxis de lógica formal (SMT-LIB)
Detección de Conflictos: Identifica posibles inconsistencias en las políticas
Validación Humana: Solicita feedback para mejorar la comprensión

El Poder del SMT-LIB Visible

La opción "Show SMT-LIB" revela la representación lógica formal subyacente. Según la documentación oficial de AWS, SMT-LIB (Satisfiability Modulo Theories Library) es el estándar industrial para verificación formal.

Ejemplo de traducción:

Política Original: "Travel expenses over $1,000 require pre-approval"

SMT-LIB Generado:
(assert (=> (and (= isTravelExpense true) (> expenseAmount 1000)) 
            (= isPreApprovalMandatory true)))

Valor Estratégico de la Generación Automática

1. Detección Proactiva de Inconsistencias

El sistema identifica automáticamente posibles contradicciones en políticas
Genera casos de borde que los humanos podrían pasar por alto
Valida la completitud de las reglas extraídas

2. Mejora Continua de Políticas

Cada escenario generado es una oportunidad de refinamiento
Identifica gaps en la documentación de políticas

3. Cobertura Exhaustiva de Testing

Genera combinaciones que humanos no considerarían naturalmente
Prueba límites y intersecciones entre diferentes reglas
Valida consistencia matemática de todo el conjunto de políticas

🔍 Insight Técnico: La generación automática de escenarios representa un avance significativo sobre testing tradicional. En lugar de que los humanos tengan que imaginar todos los casos edge, el sistema matemáticamente deriva escenarios basado en la lógica formal extraída.

El Confidence Threshold: Control Granular de Precisión

El Confidence Threshold es uno de los aspectos más sofisticados de Automated Reasoning y funciona de manera fundamentalmente diferente a lo que podrías esperar:

{: .info-box }

🎯 Cómo Funciona Realmente el Confidence Threshold

Según la documentación oficial de AWS:

"Automated Reasoning uses **multiple large language models (LLMs)* to translate natural language tests into findings. It returns only 'confident' findings that are supported by a significant percentage of the LLM translations. The confidence threshold defines the minimum percentage of support needed for a translation to become a finding with a validity result."*

¿Qué significa esto en la práctica?

Automated Reasoning no usa un solo LLM para traducir lenguaje natural a lógica formal. En cambio:

Múltiples LLMs procesan independientemente el mismo input
Cada LLM intenta traducir el lenguaje natural a lógica formal SMT-LIB
El sistema compara las traducciones de todos los LLMs
Solo retorna findings donde suficientes LLMs concuerdan

Configuración del Threshold:

Threshold = 0.5 (50%): Al menos la mitad de los LLMs deben concordar en la traducción
Threshold = 0.8 (80%): Al menos 4 de cada 5 LLMs deben concordar
Threshold = 1.0 (100%): Todos los LLMs deben concordar (máxima precisión)

¿Por qué este abordaje es revolucionario?

Este método de "votación democrática entre LLMs" es una de las razones por la cuales Automated Reasoning puede alcanzar niveles de precisión tan elevados:

No confía en un solo modelo que podría malinterpretar
Requiere consenso matemático entre múltiples modelos independientes
Detecta automáticamente ambigüedad cuando los modelos no concuerdan
Prefiere incertidumbre honesta (TRANSLATION_AMBIGUOUS) sobre certeza incorrecta

Trade-offs del Threshold:

Threshold	Precisión	Cobertura	Mejor Para
0.5-0.7	Moderada	Alta	Validaciones generales, prototipado
0.8-0.9	Alta	Moderada	Aplicaciones de producción estándar
1.0	Máxima	Más baja	Aplicaciones críticas (finanzas, salud, legal)

Recomendación Práctica:

# Para aplicaciones críticas donde la precisión es paramount
confidence_threshold = 1.0  # Todos los LLMs deben concordar

# Para aplicaciones de producción balanceadas
confidence_threshold = 0.8  # 80% de LLMs deben concordar

# Para prototipado y exploración
confidence_threshold = 0.5  # 50% de LLMs deben concordar

🔍 Insight Técnico: El confidence threshold NO es una medida de "qué tan seguro está el modelo" - es una medida de cuántos modelos independientes llegaron a la misma conclusión. Es verificación mediante consenso distribuido, análogo a cómo funciona blockchain pero aplicado a razonamiento lógico.

Implicación para TRANSLATION_AMBIGUOUS:
Cuando recibes este resultado, significa que los LLMs no pudieron alcanzar el threshold de concordancia. Esto puede indicar:

Lenguaje genuinamente ambiguo en el input
Múltiples interpretaciones válidas de la política
Variable descriptions insuficientes que causan inconsistencia en traducción
Complejidad inherente que requiere clarificación

La respuesta correcta es mejorar la claridad del input o las descripciones de variables, no simplemente bajar el threshold.

Mejores Prácticas para Minimizar Issues

1. Revisión Post-Extracción:

Revisar variables 'Unused' y determinar si necesitan reglas adicionales
Validar que todos los valores de tipos personalizados se usen en políticas
Crear reglas específicas para variables de aprobación no utilizadas
Documentar decisiones sobre variables intencionalmente no utilizadas

2. Refinamiento Iterativo:

Primera iteración: Aceptar la extracción automática inicial
Segunda iteración: Crear reglas adicionales para variables no utilizadas
Tercera iteración: Optimizar tipos personalizados eliminando valores obsoletos
Cuarta iteración: Validar cobertura completa de políticas

🔍 ProTip: Los issues no son errores, sino oportunidades de optimización. Variables "no utilizadas" a menudo indican políticas que podrían beneficiarse de reglas adicionales para mayor cobertura y precisión.

Configuración Avanzada en Guardrails

Ahora que hemos visto cómo funciona la extracción, veamos cómo optimizar este proceso al extender nuestro Guardrail para usar las políticas que hemos creado.

Figura 12: Integración de Guardrails y Razonamiento Automático

Esta configuración muestra:

Automated Reasoning policy habilitada
Confidence threshold establecido en 1.0 (máxima precisión)
Policies configuradas: Expense and Procurement Policy + Company Vacation and Leave Policy
Límite de 2 políticas por guardrail claramente visible

Paso 3: Implementación y Prueba del Cliente Python

Ahora implementaremos un cliente Python que valide respuestas en tiempo real contra nuestras políticas con verificación matemática.

Código de Implementación

El código completo está disponible en mi repositorio de GitHub: bedrock-automated-reasoning/test_automated_reasoning.py

Aquí están los componentes clave:

1. Configuración Inicial:

import boto3
import json

# Configuración
REGION = "us-east-1"
MODEL_ID = "anthropic.claude-3-sonnet-20240229-v1:0"
GUARDRAIL_ID = "tu-guardrail-id"  # Reemplaza con tu ID
GUARDRAIL_VERSION = "DRAFT"  # Es recomendable que uses versiones

client = boto3.client("bedrock-runtime", region_name=REGION)

2. Invocación con Guardrail:

response = client.converse(
    modelId=MODEL_ID,
    messages=[{"role": "user", "content": [{"text": prompt}]}],
    guardrailConfig={
        "guardrailIdentifier": GUARDRAIL_ID,
        "guardrailVersion": GUARDRAIL_VERSION,
        "trace": "enabled",  # CRÍTICO para ver verificación
    }
)

3. Análisis de Findings (Extracto):

for finding in findings:
    # SATISFIABLE: Lógicamente consistente
    if 'satisfiable' in finding:
        print("✅ SATISFIABLE")
        print(f"Confidence: {finding['satisfiable']['translation']['confidence']}")

    # VALID: Matemáticamente correcto
    elif 'valid' in finding:
        print("✅ VALID")

        # CRÍTICO: Revisar untranslatedClaims
        if 'untranslatedClaims' in finding['valid']['translation']:
            print("⚠️ ADVERTENCIA: Claims NO verificados matemáticamente")

    # INVALID: Contradicción detectada
    elif 'invalid' in finding:
        print("❌ INVALID - Contradicción con políticas")

💻 Código Completo: El script completo con manejo de todos los tipos de findings está disponible en GitHub.

Ejecutando la Prueba

Desde tu AWS CloudShell o entorno local con credenciales configuradas (asegurate de tener boto3 actualizado)

# Ejecutar script
python test_automated_reasoning.py

Análisis de Resultados Reales

Aquí está la salida real de la ejecución con nuestro Guardrail:

Enviando prompt al modelo con Guardrail habilitado...
================================================================================

=== RESPUESTA DEL MODELO ===
Based on the information provided, as a new full-time employee with less than 
1 year of service, you are likely entitled to 15 vacation days for the year. 
However, here are a few key points to keep in mind:

1. Accrual: The 15 vacation days are typically accrued over the course of the 
   year, not given upfront.
2. Waiting period: There may be a waiting period, often around 90 days.
3. Manager approval: Using vacation days is usually subject to manager approval.
4. Rollover policy: Check the company's policy on whether unused vacation days 
   can be rolled over.

================================================================================
=== ANÁLISIS DE VERIFICACIÓN MATEMÁTICA ===
================================================================================

📊 MÉTRICAS DE RENDIMIENTO:
   Latencia total: 11423ms (11.4s)
   Automated Reasoning Units: 2
   Políticas evaluadas: 1
   Caracteres verificados: 1181

🔍 FINDINGS DETECTADOS: 4
================================================================================

────────────────────────────────────────────────────────────────────────────────
FINDING #1
────────────────────────────────────────────────────────────────────────────────
✅ Tipo: SATISFIABLE (lógicamente consistente)
   Confidence: 1.00

   📋 PREMISAS EXTRAÍDAS:
      • employmentType is equal to FULL_TIME
      • yearsOfService is less than 1

   ✓ CLAIMS VERIFICADOS:
      • fullTimeVacationEntitlement is equal to 15

   💡 Escenario donde los claims son VERDADEROS:
      • fullTimeVacationEntitlement is equal to 15
      • employmentType is equal to FULL_TIME
      • yearsOfService is equal to -1

Observación Crítica sobre yearsOfService = -1:

⚠️ Valores Negativos en Lógica Formal: El escenario generado muestra yearsOfService = -1, que es matemáticamente válido en el modelo lógico SMT-LIB pero conceptualmente extraño. En producción, considera agregar restricciones adicionales en tu política: (assert (>= yearsOfService 0)) para prevenir valores negativos.

────────────────────────────────────────────────────────────────────────────────
FINDING #2
────────────────────────────────────────────────────────────────────────────────
✅ Tipo: VALID (matemáticamente correcto)
   Confidence: 1.00

   ✓ CLAIMS VERIFICADOS:
      • true

   ⚠️  ADVERTENCIA: CLAIMS NO TRADUCIDOS
   ======================================================================
   El siguiente contenido NO fue verificado matemáticamente:
   ======================================================================

      📝 "Vacation time is usually accrued over the course of the year..."

      📝 "There may be a waiting period, like 90 days..."

      📝 "Usage of vacation days is often subject to manager approval..."

      📝 "Unused vacation days may or may not rollover..."

   ⚠️  IMPLICACIÓN:
   Estas afirmaciones podrían ser alucinaciones. El modelo las agregó
   pero no pudieron ser verificadas contra las políticas formales.

────────────────────────────────────────────────────────────────────────────────
FINDING #3
────────────────────────────────────────────────────────────────────────────────
✅ Tipo: VALID (matemáticamente correcto)
   Confidence: 1.00

   ⚠️  DESCUBRIMIENTO PRÁCTICO: untranslatedPremises
   ======================================================================
   Además de claims no traducidos, también detectamos PREMISAS no traducidas:
   ======================================================================

      📝 "There may be a waiting period, like 90 days..."

   ⚠️  IMPLICACIÓN CRÍTICA:
   No solo las conclusiones pueden ser no verificadas, sino también el
   CONTEXTO DE ENTRADA. Esto significa que el modelo podría estar basando
   su respuesta en premisas que no fueron validadas matemáticamente.

Interpretación Crítica de los Resultados

Este trace real revela insights fundamentales sobre cómo funciona Automated Reasoning:

1. El Claim Principal fue Verificado Matemáticamente

Finding #1: SATISFIABLE con Confidence 1.0
Premisas: employmentType = FULL_TIME AND yearsOfService < 1
Claim verificado: fullTimeVacationEntitlement = 15

Todos los LLMs concordaron (confidence 1.0) en que 15 días es correcto según la política.

2. untranslatedClaims: La Limitación Crítica

Los Findings #2 y #3 revelan que el modelo agregó información que no pudo ser verificada matemáticamente:

✅ "15 días de vacaciones" → Verificado (100% LLMs concordaron)
⚠️ "Acumulación de 1.25 días por mes" → NO verificado
⚠️ "Período de espera de 90 días" → NO verificado
⚠️ "Aprobación de manager requerida" → NO verificado
⚠️ "Política de rollover" → NO verificado

3. untranslatedPremises: Descubrimiento Práctico

El Finding #3 revela algo no documentado oficialmente por AWS pero crítico: las premisas también pueden no ser verificadas. Esto significa que no solo las conclusiones pueden ser alucinaciones, sino también el contexto en el que se basan.

4. Latencia Real: 11.4 segundos

Esta latencia es típica y varía según complejidad de la política y cantidad de reglas. Para aplicaciones en producción:

Implementa caching de respuestas frecuentes
Diseña UX que maneje latencia variable
Considera procesamiento asíncrono para queries no críticas

5. Consumo y Costos

Automated Reasoning Units: 2

Según la documentación oficial de AWS: cada 'validation request' es cobrado, independientemente del resultado (VALID, INVALID, TRANSLATION_AMBIGUOUS).

Paso 4: Refinamiento con Annotations - Corrigiendo Políticas Mediante Testing Iterativo

Después de ejecutar pruebas y detectar problemas, el siguiente paso crítico es refinar tu política mediante annotations.

¿Qué son las Annotations?

Annotations son correcciones o mejoras que aplicas a tu política cuando los tests revelan problemas o gaps en la extracción automática inicial. Son el mecanismo principal para iterar y perfeccionar políticas.
Según la documentación oficial de AWS:

"Annotations are corrections you apply to repair your policy when tests fail. If a test doesn't return your expected result, you can modify the test conditions, rerun it, and apply the successful modification as an annotation to update your policy."

Cuándo Usar Annotations:

Corregir reglas incorrectas: Cuando Automated Reasoning malinterpretó tu documento fuente
Agregar variables faltantes: Cuando conceptos importantes no fueron extraídos
Mejorar descripciones de variables: Cuando traducciones son inconsistentes o ambiguas
Resolver ambigüedades de traducción: Cuando tests retornan TRANSLATION_AMBIGUOUS frecuentemente
Llenar gaps de cobertura: Cuando políticas tienen casos no cubiertos

🔍 ProTip: Las annotations son el mecanismo de "fine-tuning" para tu política de Automated Reasoning. La calidad de tus annotations determina directamente la precisión final del sistema. Invierte tiempo en annotations bien pensadas y documentadas - es la diferencia entre una política mediocre y una excelente.

Paso 5: Casos de Prueba Adicionales

Para comprender completamente el comportamiento del sistema, aquí hay escenarios adicionales documentados en el repositorio:

Caso 1: Violación Directa de Política

Query: "I want to take 16 consecutive vacation days next week."
Resultado esperado: INVALID finding detectando que 16 días consecutivos requieren Director approval.

Caso 2: Caso Edge - Frontera de Políticas

Query: "I have exactly 2 years of service. How many vacation days do I get?"
Desafío: La política dice "0-2 years: 15 days" vs "3-5 years: 20 days". ¿2 años exactos = 15 o 20?

Caso 3: IMPOSSIBLE Finding

Query: "What benefits do employees get if they work negative hours?"
Resultado: IMPOSSIBLE - las premisas son lógicamente incorrectas.

Caso 4: TOO_COMPLEX Finding

Query: Respuesta extremadamente larga con cientos de claims interconectados.
Resultado: TOO_COMPLEX - excede límites de procesamiento.

Tipos de Resultados de Validación 📋

La documentación oficial de AWS define 7 tipos de resultados posibles. Es crítico entender cada uno:

VALID
Los claims son matemáticamente correctos según las políticas. La respuesta sigue todas las restricciones lógicas aplicables.
Advertencia: Un resultado VALID puede incluir untranslatedClaims. Revisa siempre este campo.

INVALID
Los claims contradicen las políticas. La respuesta es matemáticamente demostrable como incorrecta.
Ejemplo: Política: "1+ año para parental leave". Respuesta: "Calificas con 3 meses de servicio." → INVALID

SATISFIABLE
Los claims son consistentes con al menos una interpretación de las políticas, pero pueden no abordar todas las reglas relevantes.
Ejemplo: Política: "1+ año de servicio AND formulario HR-101 requerido". Respuesta: "Calificas con 2 años de servicio" (correcto pero no menciona formulario) → SATISFIABLE

IMPOSSIBLE
No se puede hacer una declaración sobre los claims. Ocurre cuando:
Las premisas son lógicamente incorrectas
Hay conflictos dentro de la política misma

Ejemplo: Política con reglas contradictorias o consulta con premisas imposibles ("empleados con horas negativas").

TRANSLATION_AMBIGUOUS
Los LLMs no concordaron en cómo traducir el lenguaje natural a lógica formal.
Causa raíz: Cuando los múltiples LLMs que Automated Reasoning usa no alcanzan el threshold de concordancia definido.
Ejemplo: Query con pronombres ambiguos ("Can they take leave?" sin especificar quién).

TOO_COMPLEX
El input excede límites de procesamiento dentro de los tiempos de latencia permitidos.
Ejemplo: Respuesta con cientos de claims interconectados sobre múltiples temas.

NO_TRANSLATIONS
Alguna o toda la entrada no se pudo traducir a lógica formal. Ocurre cuando:
El contenido no es relevante para la política
La política no tiene variables para modelar el input
Ejemplo: Política HR validando beneficios, pero pregunta sobre "el clima" o "cómo cocinar pasta".

Análisis de Resultados: Precisión Verificable vs. Probabilidades 📊

Comparativa de Métodos de Validación

Datos verificables de investigaciones recientes sobre precisión de LLMs:

Aspecto	Métodos Tradicionales (LLMs)	Automated Reasoning
Precisión	Variable según contexto: • Summarization: 1.4-4.2% error (modelos top como GPT-5, Claude Opus 4.1) • Citations/References: 28-44% error post-mitigación • Open domain/Medical: 40-82% error, con picos en no-inglés o complejos	Hasta 99% de precisión verificable (matemática)
Explicabilidad	Puntuaciones de confianza	Pruebas lógicas verificables
Detección Alucinaciones	Reactiva (post-generación)	Proactiva (durante generación)
Manejo de Políticas	Embeddings semánticos	Lógica formal extraída
Trazabilidad	Limitada	Completa con justificaciones
Latencia	~100-500ms	~1-15 segundos adicionales

Fuentes:

Limitaciones Actuales y Consideraciones 🚧

Restricciones Técnicas

Limitaciones de Idioma y Región:

Soporte únicamente para inglés (US)
Disponible en regiones: US East (N. Virginia), US East (Ohio), US West (Oregon), EU (Frankfurt), EU (París), EU (Irlanda)

Limitaciones de Funcionalidad:

Máximo 2 políticas por guardrail
Incompatibilidad con APIs de streaming
Latencia variable: 1-15 segundos adicionales típicos (nuestro ejemplo: 11.4s)
Solo PDF y texto plano
CloudFormation actualmente no soportado

Limitaciones de Contenido:

Documentos de políticas limitados a 122,880 tokens (~100 páginas)
Las políticas deben estar en lenguaje formal y estructurado
No soporta imágenes, diagramas o tablas complejas dentro de PDFs

Notas Importantes

1. No Reemplaza Revisión Humana

Automated Reasoning proporciona verificación matemática, pero:

No entiende contexto de negocio más amplio
No puede evaluar implicaciones legales o éticas
No reemplaza el juicio profesional de expertos

Recomendación: Use AR como primera línea de defensa, pero mantenga revisión humana para decisiones críticas.

2. Requiere Políticas Bien Estructuradas

El sistema solo es tan bueno como las políticas que procesa:

Políticas ambiguas → Extracción pobre
Políticas incompletas → Gaps en verificación
Políticas contradictorias → Resultados inconsistentes

Recomendación: Invierta tiempo en estructurar políticas formalmente antes de implementar AR. Use un abordaje iterativo: empiece simple, valide, agregue complejidad gradualmente.

3. Latencia Variable Significativa

Latencia típica: 1-15 segundos adicionales (confirmado en nuestro trace: 11.4s)

Variable según complejidad de política y número de reglas
NO apropiado para aplicaciones en tiempo real crítico

Recomendación:

Implemente caching para consultas frecuentes
Diseñe UX que maneje latencia variable elegantemente
Considere procesamiento asíncrono donde sea posible

Cuándo Automated Reasoning NO es Efectivo

Casos donde la traducción a lógica formal falla

1. Políticas ambiguas o contextualmente dependientes:

# ❌ MAL - No se puede traducir a lógica formal
policy_text = """
Managers may use reasonable judgment to approve travel expenses 
that exceed standard limits if business circumstances warrant it.
"""

# ✅ BIEN - Traducible a lógica formal
policy_text = """
Travel expenses exceeding standard limits require:
1. Manager approval if amount is $200-$500 over limit
2. Director approval if amount is $501-$1000 over limit  
3. VP approval if amount exceeds limit by more than $1000
"""

2. Reglas que requieren interpretación subjetiva:

# ❌ MAL - "Exceptional circumstances" no es verificable matemáticamente
"Managers may approve in exceptional circumstances"

# ✅ BIEN - Condiciones específicas y verificables
"Managers may approve if: employee tenure > 5 years AND 
previous year utilization < 80% AND business criticality = LOW"

3. Dependencias temporales complejas:

# ❌ MAL - Lógica temporal compleja difícil de extraer
"Employees hired after Q3 must wait 90 days, unless hired in December, 
in which case eligibility starts January 1st"

# ✅ BIEN - Reglas temporales simplificadas
"Employees eligible for benefits after 90 days of employment"

Reflexiones Finales: El Futuro de la IA Verificable 🔮

Impacto Transformacional

Después de implementar y probar Amazon Bedrock Guardrails Automated Reasoning Checks en profundidad, queda claro que estamos presenciando una evolución fundamental en la IA generativa. No se trata solo de una mejora incremental en la precisión; es un cambio paradigmático hacia la IA verificable.

La capacidad de proporcionar pruebas matemáticas verificables en lugar de simples probabilidades transforma completamente la propuesta de valor de los LLMs para aplicaciones empresariales críticas.

Lecciones Aprendidas Clave

1. La Calidad de las Políticas es Fundamental

El sistema solo es tan bueno como las políticas que procesa. Durante mi implementación, descubrí que:

Políticas ambiguas generan extracciones pobres y baja confianza.
Políticas bien estructuradas producen resultados con confidence 1.0 consistentemente.
La inversión inicial en estructurar políticas formalmente da sus frutos posteriormente.

2. El Approach Multi-LLM es Revolucionario

El uso de múltiples LLMs para consenso es lo que diferencia a Automated Reasoning:

No confía en un solo modelo
Requiere concordancia entre modelos
Alcanza hasta un 99% de precisión mediante votación matemática

3. El Monitoreo de Contenido No Verificado es CRÍTICO

Nuestro ejemplo real demostró que:

Los modelos pueden agregar información razonable pero no verificada
Esto incluye untranslatedClaims y untranslatedPremises
En contextos críticos, este contenido debe manejarse explícitamente

4. Latencia Variable Requiere Diseño UX Específico

Latencias de 11-14 segundos requieren:

UX que maneje esperas elegantemente
Caching estratégico
Procesamiento asíncrono donde sea posible
Comunicación clara con usuarios sobre verificación en progreso

5. El ROI es Real para Casos de Uso Apropiados
En industrias reguladas (finanzas, salud, legal) donde los errores tienen consecuencias costosas:

Valor incalculable en reducción de riesgo legal y reputacional
Trazabilidad completa para auditorías

🚀 ProTip Final: Automated Reasoning Checks no es solo una característica de seguridad; es una plataforma para construir aplicaciones de IA generativa verdaderamente confiables. La inversión en: Estructurar políticas correctamente, Implementar monitoreo de untranslatedClaims/untranslatedPremises, Diseñar UX para latencia variable ...pagará dividendos exponenciales a largo plazo.

Una Invitación a la Experimentación

El futuro de la IA generativa no es solo más creativo o más rápido — es matemáticamente verificable mediante consenso multi-LLM. Y ese futuro comienza con la decisión de estructurar formalmente el conocimiento que ya tienes.

¿Te animas a experimentar con Automated Reasoning Checks en tu organización? ¿Qué políticas empresariales te gustaría verificar matemáticamente? La tecnología está lista, y las posibilidades son infinitas.

Preguntas para reflexionar:

¿Qué políticas empresariales en tu organización se beneficiarían de verificación matemática?
¿Dónde los errores de IA actualmente tienen el mayor costo o riesgo?
¿Cómo podrías estructurar conocimiento existente en formato verificable?
¿Qué procesos de revisión manual podrían automatizarse parcialmente?

Recursos Adicionales

Documentación Oficial:

Investigaciones Citadas:

La revolución de la IA verificable es un viaje que vale la pena hacer juntos. Cada implementación exitosa nos acerca más a sistemas de IA en los que podemos confiar verdaderamente para decisiones críticas.