惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog RSS Feed
量
量子位
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
B
Blog
U
Unit 42
C
Check Point Blog
I
InfoQ
aimingoo的专栏
aimingoo的专栏
雷峰网
雷峰网
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博
博客园 - 【当耐特】
人人都是产品经理
人人都是产品经理
The Cloudflare Blog
H
Help Net Security
MongoDB | Blog
MongoDB | Blog
博
博客园 - Franky
H
Hackread – Cybersecurity News, Data Breaches, AI and More
J
Java Code Geeks
Microsoft Azure Blog
Microsoft Azure Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
云风的 BLOG
云风的 BLOG
宝玉的分享
宝玉的分享
爱范儿
爱范儿

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
De bloquear a autocorregir: una demo práctica de guardrai...
Francisco · 2026-05-02 · via DEV Community

Introducción

Hace poco estuve leyendo el artículo “Guardrails para Agentes de IA que se Autocorrigen en Lugar de Bloquear”, publicado por Elizabeth Fuentes L para AWS Español.

La idea principal me pareció muy interesante: muchos guardrails tradicionales funcionan de forma binaria. Si el agente viola una regla, se bloquea la acción y el usuario tiene que intervenir. Eso es necesario en algunos casos, pero no siempre es la mejor experiencia.

El artículo plantea una alternativa: en vez de solo bloquear, podemos guiar al agente para que corrija su acción. A ese enfoque se le llama steer. El agente recibe una corrección, ajusta los parámetros y continúa el flujo.

Quise llevar esa idea a una demo práctica usando tecnologías que manejo más en mi día a día:

Laravel
Vue
Docker Compose
MySQL
Grok / xAI
OpenSpec

Enter fullscreen mode Exit fullscreen mode

Importante: esta demo no implementa directamente Strands Agents ni Agent Control. Lo que hice fue tomar el patrón conceptual del artículo y llevarlo a un stack Laravel + Vue + Grok.

En lugar de usar Guide() para que el LLM reintente, implementé un GuardrailEngine que corrige el payload de forma determinística y devuelve una propuesta corregida al usuario.

El objetivo fue aprender el patrón, bajarlo a código y demostrar la idea central:

No bloquear por defecto.
Corregir cuando sea seguro.
Bloquear cuando realmente sea necesario.

Enter fullscreen mode Exit fullscreen mode

El problema

Imaginemos un agente de IA para agendar citas.

Un usuario escribe:

Quiero una cita mañana a las 8pm para 3 personas

Enter fullscreen mode Exit fullscreen mode

Pero el negocio tiene estas reglas:

Horario de atención: 8:00 a.m. a 6:00 p.m.
Máximo de personas por cita: 2
Duración de la cita: 30 minutos
No se pueden agendar días bloqueados
No se pueden duplicar slots ocupados

Enter fullscreen mode Exit fullscreen mode

Un guardrail tradicional podría responder:

No puedo agendar esa cita.

Enter fullscreen mode Exit fullscreen mode

Eso funciona, pero corta el flujo.

Una mejor experiencia sería:

No puedo agendar a las 8:00 p.m. ni para 3 personas.
Te puedo ofrecer mañana a las 5:30 p.m. para 2 personas.
¿Deseas confirmar?

Enter fullscreen mode Exit fullscreen mode

Ahí es donde entra la idea de autocorrección.

Qué construí

Construí una demo funcional donde un usuario puede pedir una cita por chat.

La IA interpreta la intención, genera un payload estructurado y luego el GuardrailEngine valida las reglas del negocio.

El usuario no confirma directamente lo que la IA propone. Primero pasa por una capa de control.

También agregué un frontadmin para configurar reglas, servicios, días bloqueados y revisar logs.

En simple:

La IA entiende.
El guardrail decide.
El backend ejecuta.
El admin configura.

Enter fullscreen mode Exit fullscreen mode

Arquitectura de la demo

La demo está compuesta por:

Frontend Cliente
Backend Laravel
GrokAppointmentAgent
GuardrailEngine
AppointmentController
Frontadmin
MySQL

Enter fullscreen mode Exit fullscreen mode

Arquitectura de la demo

Responsabilidades por componente

Componente Responsabilidad
Frontend Cliente Permite al usuario escribir la solicitud y confirmar la cita propuesta.
Frontadmin Permite configurar reglas, servicios, días bloqueados y revisar logs.
ChatController Recibe el mensaje del usuario y coordina el flujo del agente.
GrokAppointmentAgent Convierte lenguaje natural en un payload estructurado.
GuardrailEngine Evalúa reglas y decide ALLOW, STEER o BLOCK.
AppointmentController Crea la cita solo después de confirmación y validación.
Admin Controllers Exponen endpoints para reglas, servicios, días bloqueados y logs.
MySQL Guarda citas, reglas, servicios, días bloqueados y auditoría.

Flujo principal 

Usuario escribe una solicitud
        ↓
Frontend envía el mensaje al backend
        ↓
Grok interpreta la intención y genera un payload
        ↓
GuardrailEngine evalúa reglas de negocio
        ↓
Si es válido: ALLOW
Si es corregible: STEER
Si no puede continuar: BLOCK
        ↓
El usuario confirma la propuesta
        ↓
Laravel crea la cita en MySQL

Enter fullscreen mode Exit fullscreen mode

Flujo de administración 

Frontadmin
        ↓
Admin Controllers
        ↓
MySQL
        ↓
Reglas, servicios, días bloqueados y logs
        ↓
GuardrailEngine usa esas reglas en runtime

Enter fullscreen mode Exit fullscreen mode

La parte importante es que las reglas no viven solamente en el prompt del agente. Se pueden cambiar desde el frontadmin y el GuardrailEngine las usa en tiempo de ejecución.

Decisiones del guardrail

Implementé tres decisiones principales:

ALLOW

La acción es válida y puede continuar.

STEER

La acción tiene errores corregibles. El sistema ajusta los datos y devuelve una propuesta corregida.

BLOCK

La acción no puede continuar porque falta información o hay una regla estricta.

Ejemplo de STEER

Entrada del usuario:

Quiero una cita mañana a las 8pm para 3 personas

Enter fullscreen mode Exit fullscreen mode

Grok genera:

{
  "service": "consulta_general",
  "date": "2026-05-02",
  "time": "20:00",
  "people": 3
}

Enter fullscreen mode Exit fullscreen mode

El guardrail evalúa:

20:00 está fuera del horario permitido
3 personas supera el máximo permitido

Enter fullscreen mode Exit fullscreen mode

Respuesta del guardrail:

{
  "decision": "STEER",
  "reason": "Payload was corrected.",
  "corrections": [
    {
      "field": "time",
      "from": "20:00",
      "to": "17:30:00",
      "reason": "Requested time is after business hours."
    },
    {
      "field": "people",
      "from": 3,
      "to": 2,
      "reason": "Requested people count exceeds maximum allowed."
    }
  ]
}

Enter fullscreen mode Exit fullscreen mode

Respuesta para el usuario:

La hora solicitada no cumple las reglas. Te puedo ofrecer 17:30.
El máximo permitido es 2 persona(s).
¿Deseas confirmar esta propuesta?

Enter fullscreen mode Exit fullscreen mode

Ese es el punto clave: el sistema no bloquea de inmediato, sino que corrige cuando es seguro hacerlo.

Ejemplo de BLOCK

No todo debe autocorregirse.

Si el usuario no proporciona fecha, el sistema no debe inventarla si la intención no está clara.

Payload incompleto:

{
  "service": "consulta_general",
  "time": "10:00",
  "people": 1
}

Enter fullscreen mode Exit fullscreen mode

Respuesta:

{
  "decision": "BLOCK",
  "reason": "Date is required."
}

Enter fullscreen mode Exit fullscreen mode

Mensaje:

Necesito que me indiques la fecha para revisar disponibilidad.

Enter fullscreen mode Exit fullscreen mode

Este punto también es importante: STEER no reemplaza BLOCK. Los dos se complementan.

El artículo original también lo explica así: los bloqueos son útiles para reglas estrictas, mientras que steer funciona mejor para errores corregibles como ajustar parámetros, redactar información sensible o corregir formatos.

Reglas configurables desde el frontadmin

Una parte que quise destacar fue que las reglas no estuvieran dentro del prompt.

Desde el frontadmin se pueden cambiar:

Hora inicio
Hora fin
Máximo de personas
Duración de cita
Permitir autocorrección
Servicios activos
Días bloqueados

Enter fullscreen mode Exit fullscreen mode

Por ejemplo, si el admin cambia:

Hora fin: 17:00
Máximo personas: 1

Enter fullscreen mode Exit fullscreen mode

El mismo mensaje:

Quiero una cita mañana a las 8pm para 3 personas

Enter fullscreen mode Exit fullscreen mode

ahora se corrige a algo como:

16:30
1 persona

Enter fullscreen mode Exit fullscreen mode

Esto demuestra una idea muy importante: las reglas del negocio pueden cambiar sin tocar el prompt del agente.

¿Dónde entra Grok?

Grok entra como agente de extracción de intención.

Su trabajo es convertir lenguaje natural en un payload estructurado.

Usuario:

Quiero una cita mañana a las 8pm para 3 personas

Enter fullscreen mode Exit fullscreen mode

Grok devuelve:

{
  "service": "consulta_general",
  "date": "2026-05-02",
  "time": "20:00",
  "people": 3
}

Enter fullscreen mode Exit fullscreen mode

Pero Grok no decide si eso se puede ejecutar.

Esa responsabilidad queda en el GuardrailEngine.

Grok propone.
Guardrail controla.
Laravel ejecuta.

Enter fullscreen mode Exit fullscreen mode

Esto ayuda a separar responsabilidades y evita que el modelo sea quien tenga la última palabra sobre reglas de negocio.

¿Dónde entra OpenSpec?

Usé OpenSpec para definir el cambio antes de implementarlo.

La demo quedó documentada con:

proposal.md
design.md
tasks.md
specs/ai-guardrails/spec.md
specs/appointment-booking/spec.md
specs/admin-rules/spec.md

Enter fullscreen mode Exit fullscreen mode

Esto me ayudó a mantener trazabilidad:

Requisito → Diseño → Implementación → Prueba

Enter fullscreen mode Exit fullscreen mode

Por ejemplo, el requisito decía:

El sistema debe evaluar todas las acciones generadas por la IA antes de llamar al API de citas.

Enter fullscreen mode Exit fullscreen mode

Y eso terminó implementado en el flujo:

ChatController
↓
GrokAppointmentAgent
↓
GuardrailEngine
↓
AppointmentController

Enter fullscreen mode Exit fullscreen mode

Diferencia con Agent Control y Strands

El artículo original trabaja el concepto desde Strands Agents y Agent Control.

En ese enfoque, el agente puede recibir una instrucción correctiva mediante algo similar a Guide(). Luego el agente reintenta la acción con los parámetros corregidos.

En mi demo hice una adaptación más sencilla:

Grok genera un payload.
GuardrailEngine valida el payload.
Si es corregible, el backend devuelve corrected_payload.
El usuario confirma.
Laravel ejecuta.

Enter fullscreen mode Exit fullscreen mode

Es decir, no hay un reintento automático del LLM guiado por Guide(). La corrección ocurre de forma determinística en el backend.

Aun así, el patrón conceptual se mantiene:

IA propone.
Guardrail evalúa.
Sistema corrige o bloquea.
Backend ejecuta solo si corresponde.

Enter fullscreen mode Exit fullscreen mode

Casos probados

Probé estos escenarios:

ALLOW  → cita válida
STEER  → hora fuera de horario
STEER  → demasiadas personas
STEER  → día bloqueado
STEER  → slot ocupado con alternativa disponible
BLOCK  → falta fecha
BLOCK  → servicio inválido
BLOCK  → autocorrección desactivada
BLOCK  → slot ocupado sin alternativa disponible

Enter fullscreen mode Exit fullscreen mode

Uno de los más interesantes fue el de slot ocupado.

En lugar de bloquear inmediatamente, el guardrail busca el siguiente horario disponible.

Slot solicitado ocupado
↓
Buscar siguiente slot disponible
↓
Si existe: STEER
↓
Si no existe: BLOCK

Enter fullscreen mode Exit fullscreen mode

Eso se acerca mucho a la idea del blog original: si el agente puede corregirse, no detengas el flujo.

Lo que aprendí

La principal lección fue esta:

No todo error del agente debe terminar en bloqueo.

Enter fullscreen mode Exit fullscreen mode

Hay errores que se pueden corregir de forma segura:

Hora fuera de horario
Cantidad mayor al máximo
Formato incorrecto
Día bloqueado
Slot ocupado

Enter fullscreen mode Exit fullscreen mode

Pero también hay casos donde el sistema debe detenerse:

Falta información crítica
Servicio no existe
No hay disponibilidad
Autocorrección desactivada
Regla estricta de negocio

Enter fullscreen mode Exit fullscreen mode

La clave está en clasificar bien las reglas.

Conclusión

Esta demo me ayudó a entender mejor cómo llevar los guardrails más allá del “permitir o bloquear”.

El patrón final quedó así:

Usuario pide algo
↓
IA interpreta
↓
Guardrail evalúa
↓
ALLOW / STEER / BLOCK
↓
Usuario confirma
↓
Backend ejecuta

Enter fullscreen mode Exit fullscreen mode

No es una implementación idéntica a Agent Control, pero sí aplica la misma idea central del artículo original: usar guardrails para guiar al agente cuando la corrección es segura, y bloquear solo cuando realmente es necesario.

Para mí, este enfoque tiene mucho valor en aplicaciones reales: citas, reservas, soporte, cotizaciones, DevOps, APIs internas y cualquier flujo donde una IA pueda intentar ejecutar acciones.

Lo más importante es mantener clara la separación:

La IA entiende.
El guardrail decide.
El backend ejecuta.
El admin configura.

Enter fullscreen mode Exit fullscreen mode

Código fuente

El código de la demo está disponible en GitHub:

https://github.com/fmarchena/appointment-agent-demo/tree/main

En el repositorio se incluye:

Laravel API
Vue frontend
Docker Compose
MySQL
GuardrailEngine
Integración con Grok / xAI
OpenSpec con proposal, design, tasks y specs

Enter fullscreen mode Exit fullscreen mode

Referencias

Artículo base:

Documentación relacionada:

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。