Demuéstrelo, parte 3: guía paso a paso para implementar razonamiento automatizado

En esta guía descubrirá cómo crear una política de razonamiento automatizado a partir de un documento empresarial existente, implementarla mediante Barreras de protección de Amazon Bedrock, validar respuestas de LLM con ApplyGuardrail, crear un registro de auditoría y proteger agentes de IA con Política de AgentCore. Con este proceso, los equipos pueden pasar de un documento de cumplimiento a verificación en producción en solo 30 minutos.

En la parte 1 (“Por qué ‘probablemente correcto’ no es suficiente”) explicamos por qué las startups necesitan verificación determinista. En la parte 2 (“Lógica formal, políticas de Cedar y la economía de la verificación”) explicamos la canalización de verificación y las matemáticas que hay detrás. Ahora es el momento de crear.

¿Qué necesita antes de comenzar?

Antes de comenzar, asegúrese de tener lo siguiente:

• Una cuenta de AWS con Amazon Bedrock habilitado. Si forma parte de AWS Activate, ya dispone de créditos para ello.
• Python 3.9+ con boto3. Si ya lanzó un MVP, ya tiene esto.
• Un documento de política (PDF, Markdown o texto sin formato) que describa sus reglas empresariales. Si ya superó alguna revisión de cumplimiento o diligencia debida de inversores, ya tiene esto.

Paso 1: cree su política de AR

La forma más rápida es mediante la consola de AWS. No necesita escribir lógica formal, ya que Bedrock traduce automáticamente el documento de origen a reglas de lógica formal.

1. Abra la consola de Bedrock y vaya a Razonamiento automatizado en la barra lateral izquierda.
2. Cree una política nueva. Asígnele un nombre descriptivo (por ejemplo, política de elegibilidad de hipoteca).
3. Cargue el documento de origen. Este es el archivo PDF, documento de Word o archivo de texto sin formato que describe las reglas empresariales. Para una startup de tecnología financiera, podría ser el documento de criterios de préstamo. Para atención médica, sus protocolos clínicos.
4. Proporcione instrucciones. Escriba una breve intención que describa qué valida la política e incluya entre 2 y 3 pares de preguntas y respuestas de ejemplo. Esto ayuda al sistema a comprender cómo interactuarán los usuarios con la política.

Para equipos que prefieren no usar la consola, también existe una interfaz conversacional para crear políticas que le guía por el proceso de formalización mediante lenguaje natural. Tiene algunos requisitos previos (incluido Kiro-CLI), pero elimina completamente el uso de la consola del flujo de trabajo.

Ejemplo de intención:

Esta política valida preguntas sobre elegibilidad hipotecaria. Los usuarios preguntan si los clientes cumplen los requisitos para tipos específicos de hipoteca según sus datos financieros.

Ejemplo de preguntas y respuestas:

P: Un cliente quiere comprar una vivienda de 350 000 USD con una entrada de 30 000 USD. ¿Cumple los requisitos para una hipoteca convencional?

R: No. Las hipotecas convencionales requieren una entrada mínima del 20 % (70 000 USD para una compra de 350 000 USD).

Revise el informe de fidelidad:

Después de que el sistema procese el documento, genera un informe de fidelidad con dos puntuaciones:

• Puntuación de cobertura (0,0 a 1,0): cuánto del documento de origen está representado en la política
• Puntuación de precisión (0,0 a 1,0): con qué fidelidad las reglas extraídas reflejan la intención del documento

El informe también muestra las variables y reglas específicas extraídas, vinculadas a declaraciones exactas del documento de origen. Aquí es donde verifica que el sistema haya entendido correctamente sus reglas.

Perfeccione las descripciones de variables usando ejemplos reales de la aplicación. Pruebe preguntas representativas, inspeccione cómo las traduce el sistema y mejore las descripciones allí donde las traducciones fallen. Este es el mayor factor para mejorar la precisión. Incluya unidades, sinónimos, reglas de conversión y terminología específica del dominio siempre que sea posible. Una descripción como “El pago inicial del prestatario como porcentaje del precio de compra; cuando los usuarios mencionen cantidades monetarias, conviértalas mediante (downPayment / purchasePrice) * 100” funciona mejor que “Cuánto aporta el prestatario como entrada”.

Esto no es un esfuerzo de ingeniería de varios sprints. Son 30 minutos para pasar del documento de cumplimiento existente a una política de AR funcional. Itere sobre las descripciones de variables y pruebe con preguntas de ejemplo hasta que las puntuaciones de fidelidad y los resultados coincidan con sus expectativas.

Para la ruta mediante API (útil para canalizaciones de CI/CD), consulte la referencia de la API CreateAutomatedReasoningPolicy. La API acepta un nombre, una descripción opcional y una policyDefinition que contiene reglas, variables y tipos personalizados.

Paso 2: implemente en una barrera de protección

Una vez que la política funcione correctamente en las pruebas, impleméntela para uso en producción.

Guarde una versión inmutable. En la consola, elija “Guardar como versión nueva”. Esto crea una instantánea numerada e inmutable (versión 1, 2, 3...) para que la barrera de protección de producción no se vea afectada mientras continúa editando el BORRADOR. Así es como las startups implementan con rapidez y seguridad: el equipo de cumplimiento revisa la versión 1 en producción mientras el equipo de ingeniería itera sobre la versión 2 en borrador. Sin congelar implementaciones, sin “por favor, no toquen la política hasta que hagamos el lanzamiento”.

Una vez publicada una versión de la política, asóciela a una barrera de protección para poder usarla durante la validación en tiempo de ejecución:

Detalles clave:

• policies acepta una matriz de cadenas ARN de políticas (máximo 2), no objetos
• confidenceThreshold (opcional, de 0,0 a 1,0) controla el nivel mínimo de acuerdo para que las traducciones se consideren fiables. Los valores más bajos (0,3) muestran más resultados antes; los valores más altos (1,0) optimizan estrictamente la solidez. Comience con un valor bajo durante el desarrollo y endurézcalo para producción.
• crossRegionConfig es obligatorio para las comprobaciones de AR; activa la inferencia entre regiones para la evaluación de barreras de protección. Use el perfil correspondiente a su ubicación geográfica (por ejemplo, us.guardrail.v1:0 para EE. UU. y eu.guardrail.v1:0 para la UE).
• blockedInputMessaging y blockedOutputsMessaging son obligatorios; estos son los mensajes alternativos que se muestran cuando otros componentes de la barrera de protección (no AR) bloquean contenido.
• Use una versión numerada (:1) en el ARN para producción. Reserve DRAFT solo para desarrollo.

Paso 3: valide respuestas de LLM con ApplyGuardrail

El patrón de integración recomendado es la API independiente ApplyGuardrail. Esto le da control total sobre qué contenido se valida y cuándo, y es el enfoque que la documentación de AWS recomienda explícitamente para las comprobaciones de AR.

Este es un ejemplo mínimo de integración agregado a su canalización de inferencia existente:

Llame a esto después de que el LLM genere una respuesta y antes de entregársela al usuario:

Importante: las comprobaciones de AR funcionan en modo de detección. Devuelven resultados y comentarios. No bloquean ni reescriben la respuesta automáticamente. La aplicación inspecciona los resultados y decide qué hacer.

Paso 4: gestione los resultados

Cada resultado es un tipo de unión con exactamente una clave presente. A continuación se muestra cómo analizarlos y actuar:

El patrón de corrección estándar es un bucle de validación y reescritura: valide la respuesta, devuelva las infracciones al modelo, regenere la respuesta y vuelva a validarla. Repita el proceso hasta que la respuesta sea válida o se alcance un límite de reintentos.

El usuario nunca ve el bucle de reescritura. Ve una respuesta correcta en el primer intento. La iteración ocurre en milisegundos en segundo plano.

Paso 5: cree un registro de auditoría

Cada iteración de verificación debe registrarse. Cuando su cliente empresarial solicite evidencia de SOC 2 o su regulador pregunte cómo verificó una decisión específica, puede extraer el registro JSON. Cada verificación tiene marca temporal y es rastreable.

Este registro se convierte en su artefacto de cumplimiento. Muestra qué preguntó el usuario, qué generó el LLM, qué detectó AR y qué acción realizó la aplicación. Para startups que buscan cumplir SOC 2, HIPAA o ventas empresariales, este registro de auditoría no es opcional. Es la evidencia de que el sistema funciona como se documentó.

Paso 6: proteja sus agentes con Política de AgentCore

Si su startup ha ido más allá de los chatbots y ha pasado a flujos de trabajo agénticos (la IA reserva citas, procesa reembolsos, consulta bases de datos o envía correos electrónicos), necesita límites sobre lo que el agente puede hacer, no solo sobre lo que dice.

Política en Amazon Bedrock AgentCore usa Cedar para definir estos límites. Por ejemplo, un agente de programación de citas médicas necesita políticas que restrinjan a qué registros de pacientes puede acceder, limiten las acciones de programación al horario laboral e impidan procesar reembolsos por encima de un umbral sin aprobación de un gerente. Comience en modo LOG_ONLY para observar lo que hace el agente sin bloquear nada. Cuando confíe en las políticas, cambie al modo ENFORCE para producción.

La puerta de enlace es la capa de aplicación entre el agente y sus herramientas. Cada invocación de herramienta pasa por la puerta de enlace, donde las políticas de Cedar se evalúan antes de que la solicitud llegue al destino. Esto es lo que hace que la aplicación sea determinista e independiente del razonamiento del agente: el agente no puede eludir la puerta de enlace, ignorarla ni convencerla para que lo deje pasar.

Configure una puerta de enlace y un motor de políticas mediante la CLI de AgentCore:

Escriba una política de Cedar y asóciela al motor de políticas. El siguiente ejemplo muestra políticas ilustrativas para un agente de citas médicas. En la práctica, los nombres de las acciones se generan automáticamente a partir del destino de la puerta de enlace y el esquema de herramientas (por ejemplo, HealthTarget__get_patient_record), y el recurso debe hacer referencia al ARN específico de la puerta de enlace:

Cedar aplica denegación predeterminada: cada interacción entre agente y herramienta se bloquea a menos que una política permit explícita la autorice. Sus políticas permit definen qué herramientas puede llamar el agente y en qué condiciones. Las políticas forbid siguientes establecen excepciones y bloquean situaciones concretas incluso cuando una política permit más amplia las permitiría.

Guarde esto como healthcare_policy.cedar y, a continuación, asócielo al motor de políticas:

Como alternativa, puede describir las reglas en lenguaje natural y dejar que el sistema genere Cedar automáticamente (requiere que la puerta de enlace se haya implementado primero):

El razonamiento automatizado valida las políticas en el momento de la creación y detecta reglas demasiado permisivas, demasiado restrictivas o ineficaces antes de la implementación.

Propiedades clave para startups de sectores regulados:

• Denegación predeterminada: si ninguna política permite explícitamente una acción, esta se bloquea
• Forbid siempre prevalece: las reglas de bloqueo absoluto no pueden ser reemplazadas por otras políticas
• Aplicación determinista: funciona en el límite de la puerta de enlace, fuera del razonamiento del agente. No puede eludirse mediante inyección de peticiones, alucinaciones o errores

Comience en modo LOG_ONLY para ver qué hace el agente sin romper el producto. Los registros muestran qué política se aplicó en cada solicitud a la puerta de enlace, el resultado de la decisión de política (permitir o denegar) y exponen políticas no coincidentes cuando se produce desviación de herramientas. Revise los registros. Perfeccione las políticas. Cuando tenga confianza, cambie a ENFORCE. Así se pasa del prototipo a producción sin interrumpir a los usuarios.

Para ver ejemplos completos, incluidos scripts de implementación y entornos de prueba, consulte las muestras de Amazon Bedrock AgentCore en GitHub.

¿Qué ocurre después de implementar razonamiento automatizado?

Una vez que tenga en funcionamiento las comprobaciones de AR y Política de AgentCore, obtendrá algo más valioso que la prevención de errores: una única fuente de verdad.

La política de AR representa sus reglas empresariales codificadas como lógica formal. Cuando esas reglas cambian (y siempre cambian: nuevas normativas, criterios de préstamo actualizados, protocolos clínicos revisados), actualiza el documento de origen, regenera la política e inmediatamente todos los sistemas de IA de su pila cumplen las nuevas reglas. No hay ingeniería de peticiones que actualizar. No hay que volver a entrenar modelos. No hay que confiar en que alguien recuerde cambiar la petición del sistema.

Esto elimina una categoría completa de errores por desviación. La documentación y el comportamiento de la IA están vinculados matemáticamente. No pueden dejar de estar sincronizados.

Dado que las barreras de protección son independientes del modelo, la capa de verificación permanece igual cuando cambia de modelos fundacionales. La misma política de AR que verificó las respuestas de Claude verifica las de Amazon Nova. Las reglas dependen de la lógica empresarial y no del modelo.

La integración se extiende por todo el ecosistema de Bedrock: las políticas de AR funcionan con bases de conocimientos para generación aumentada por recuperación, con agentes de AgentCore para flujos de trabajo de varios pasos y con toda la gama de modelos fundacionales. Está creando sobre una plataforma, no sobre una solución puntual.

Más información

• Documentación de comprobaciones del razonamiento automatizado
• Conceptos de AR (variables, reglas, resultados)
• Guía de integración (patrones de ApplyGuardrail)
• Documentación de Política de AgentCore
• Muestras de AgentCore en GitHub
• Información general sobre seguridad demostrable de AWS
• Qué es el razonamiento automatizado
• Lenguaje Cedar (CNCF)

Con esto concluimos nuestra serie sobre AR para startups

A lo largo de la serie Demuéstrelo, nuestra tesis ha sido la misma: las startups que crean sobre IA necesitan verificación matemática y determinista, no solo medidas de protección probabilísticas.

En la parte 1 explicamos por qué el problema de la confianza es existencial para las startups y cómo décadas de trabajo de AWS en métodos formales dieron lugar a Barreras de protección de Amazon Bedrock y Política de AgentCore.

En la parte 2 profundizamos en la lógica formal, la canalización de verificación y la economía. En esta publicación ha visto el recorrido completo de implementación, desde documentos de cumplimiento existentes hasta IA verificada lista para producción.

Las startups que triunfen en la era de la IA no solo crearán sistemas inteligentes; crearán sistemas cuya corrección puedan demostrar. El razonamiento automatizado y Política de AgentCore hacen eso posible hoy usando las políticas y documentos de cumplimiento que la mayoría de empresas ya tienen. La única pregunta que queda es: ¿empezará ahora o esperará a que el primer incidente le obligue?