Agentes de IA en producción: guardrails y evals
Sergio Jimenez21 de octubre de 20266 min de lectura
La demo tomó dos semanas y encantó a todos. Después conoció a usuarios reales, y la pregunta que nadie supo responder era la única que importaba: ¿está mejorando o empeorando?
Sin evaluación no puedes responderla, lo que significa que cada cambio después del lanzamiento es una apuesta. Esto es lo que separa las funciones de IA que sobreviven de las que se apagan en silencio tras un trimestre.
Guardrails y evals no son lo mismo
| Guardrails | Evals | |
|---|---|---|
| Cuándo corren | En cada petición, en producción | Antes de publicar un cambio |
| Qué hacen | Impedir que una salida mala llegue a un usuario | Decirte si la calidad se movió |
| Qué fallo previenen | Una respuesta dañina | Una regresión silenciosa en miles |
| Costo de saltárselo | Un incidente | Meses de cambios que no puedes justificar |
Necesitas los dos, y los equipos suelen construir el primero y saltarse el segundo, porque los guardrails se sienten urgentes y los evals se sienten como tarea.
Guardrails que se ganan su sitio
Restringe la forma de la salida
Si la respuesta debe ser JSON conforme a un esquema, impón el esquema en vez de pedirlo amablemente en el prompt. Lo que no valide se reintenta una vez y luego falla de forma ruidosa. Una respuesta malformada que se convierte en silencio en un nulo de tu base de datos es peor que un error.
Pon los permisos en la capa de herramientas, no en el prompt
Este es el que más importa y el que más se hace mal. "No borres nada" en un prompt de sistema es una sugerencia a un sistema probabilístico. Si el agente no debe borrar, la credencial que sostiene no debe tener permiso de borrado. Los prompts expresan intención; la infraestructura la impone, y solo una de las dos es auditable.
Pon una puerta a lo irreversible
Todo lo que mueva dinero, contacte a un cliente o destruya datos pasa por una aprobación humana, al menos hasta que el registro de evaluación justifique lo contrario. Ese "al menos hasta" hace trabajo real en la frase: la puerta no es permanente, es lo que quitas cuando tienes evidencia.
Acota el bucle
Limita las llamadas a herramientas por turno y el gasto total por conversación. Un agente en bucle de reintentos es la forma más común de convertir un bug pequeño en una factura grande, y pasa a las 3 de la mañana de un fin de semana.
Haz que toda decisión sea reproducible
Registra las entradas, el contexto recuperado, las llamadas a herramientas y la salida, en cada ejecución. Cuando alguien pregunte por qué el agente hizo algo hace tres semanas, esa es la diferencia entre una respuesta y un encogimiento de hombros. También es la materia prima de tu conjunto de evaluación.
Los evals, que es la parte que se salta la gente
Un eval es un conjunto fijo de entradas con salidas correctas conocidas, más una forma de puntuar lo que el sistema produjo de verdad. Esa es toda la idea, y la razón de que se sienta como tarea es que armar el conjunto es trabajo poco lucido sin resultado visible el día que lo haces.
Empieza con veinte casos, no con doscientos
Veinte ejemplos reales valen más que doscientos inventados, y puedes reunir veinte en una tarde con tus propios logs. Incluye los casos obvios, los que te avergonzaron el mes pasado, y tres que deberían rechazarse de plano. Ese último grupo atrapa más regresiones que todo el resto junto.
Puntúa lo que se pueda puntuar barato
Coincidencia exacta para lo estructurado. Comprobaciones de texto o numéricas para campos extraídos. Para texto abierto, un segundo modelo puntuando contra una rúbrica corta funciona lo bastante bien para detectar regresiones, que es el objetivo: no estás calificando un ensayo, estás detectando movimiento.
Córrelo en cada cambio
Ediciones de prompt, cambios de modelo, ajustes de recuperación, una herramienta nueva. Todos. Todo el valor de un conjunto de evaluación es que corre solo y te dice que un cambio empeoró las cosas antes de que lo haga un usuario. Una suite de evals que corres a mano cuando te acuerdas es una suite que no tienes.
Hazlo crecer desde producción
Cada incidente se convierte en un caso. Cada queja se convierte en un caso. A los seis meses el conjunto codifica lo que tu organización ha aprendido de verdad sobre la tarea, y eso es un activo que nadie te puede copiar.
El orden en que construimos
- Logging primero. Antes que los guardrails, antes que los evals. No puedes mejorar lo que no ves, y no puedes armar un conjunto de evaluación sin ejemplos.
- Permisos en la capa de herramientas. El agente recibe credenciales acotadas exactamente a lo que puede hacer.
- Conjunto de veinte casos. Desde logs reales, con los rechazos incluidos.
- Aprobación humana en lo irreversible. Se quita después con evidencia, no con confianza.
- Límites de bucle y de gasto. Baratos, y evitan la sorpresa cara.
Fíjate en que nada de esto va del modelo. Cambiar de modelo es un cambio de una línea cuando este andamiaje existe y un acto de fe cuando no, que es exactamente por qué los equipos con evals actualizan modelos con tranquilidad y los que no tienen se quedan un año con uno viejo.
Cuánto cuesta esto
De dos a cuatro semanas encima del agente, y es la diferencia entre una función que puedes seguir cambiando y una que te da miedo tocar. Nuestro desglose de cuánto cuesta un agente de IA pone este trabajo en contexto, y es la partida que más se recorta y más se lamenta.
Preguntas frecuentes
¿Qué son los guardrails en un sistema de IA?
Controles que corren en cada petición en producción para impedir que una salida mala llegue a un usuario: validación de esquema en la respuesta, permisos impuestos en la capa de herramientas y no en el prompt, aprobación humana en acciones irreversibles, y topes de llamadas y de gasto por conversación.
¿Qué es un eval y por qué lo necesito?
Un conjunto fijo de entradas con salidas correctas conocidas, más una forma de puntuar lo que el sistema produjo. Lo necesitas porque sin él no puedes saber si un cambio de prompt, una actualización de modelo o un ajuste de recuperación mejoraron o empeoraron las cosas, así que cada cambio después del lanzamiento es una apuesta.
¿Cuántos casos necesita un conjunto de evaluación?
Empieza con veinte casos reales sacados de tus propios logs, incluidos tres que el sistema debería rechazar de plano. Veinte ejemplos reales atrapan más que doscientos inventados. Haz crecer el conjunto desde producción: cada incidente y cada queja se convierte en un caso nuevo.
¿No basta con poner las reglas en el prompt de sistema?
Para tono y formato, sí. Para permisos, no. Un prompt de sistema es una sugerencia a un sistema probabilístico, y "no borres nada" no es un control. Si el agente no debe borrar, la credencial que sostiene no debe llevar permiso de borrado. Los prompts expresan intención, la infraestructura la impone.
¿Cómo evito que mi agente de IA dispare la factura?
Limita las llamadas a herramientas por turno y el gasto total de tokens por conversación, y pon alertas en ambos. La causa habitual es un bucle de reintentos contra una herramienta que falla, que convierte un bug pequeño en una factura grande de la noche a la mañana. Registrar cada ejecución es lo que te permite encontrar el bucle después.
¿Cuándo puedo quitar el paso de aprobación humana?
Cuando el registro de evaluación lo justifique para esa acción concreta, no cuando el sistema se sienta fiable. Mide la precisión de esa acción contra tu conjunto de evaluación sobre tráfico real, decide de antemano qué umbral es aceptable, y quita la puerta con la evidencia. La confianza no es evidencia.
Por dónde empezar
Abre tus logs y saca las veinte interacciones reales más recientes. Marca cada una como buena o mala. Ya tienes un conjunto de evaluación, y probablemente una sorpresa sobre el nivel de calidad actual.
Si los logs todavía no existen, eso es lo primero que hay que arreglar, y podemos decirte qué capturar para que el conjunto se construya solo mientras sigues publicando.
