Agentes IA en producción: guardrails, evals y cuándo NO usarlos
Wilson Vargas Martínez 9 min7 de mayo de 2026Lo que aprendimos ayudando a construir CyberFort Lab, con 9 agentes corriendo 24/7. Sin teoría — solo las decisiones que evitan que un agente haga daño o queme dinero.
CyberFort Lab corre con 9 agentes IA especializados, 24/7, sobre infraestructura de clientes reales. Sabemos lo que duele lanzar agentes a producción. Lo que sigue es lo que no encuentras en tutoriales: lo que ya nos costó dinero o tiempo aprender.
Cuándo NO usar un agente
Si el flujo es determinístico (input claro → output claro, sin ambigüedad), no uses un agente. Usa código. Los agentes son caros, lentos y no determinísticos. Buenos para: clasificación de texto no estructurado, extracción, redacción, ruteo basado en juicio. Malos para: cálculos, transformaciones de datos, integraciones con APIs deterministas (eso es solo código que llama otra API).
Guardrails de salida — siempre
Tres capas: validación estructural (Pydantic, Zod, JSON Schema) — el output debe parsearse o se descarta; validación semántica — segundo modelo o reglas verifican que el output tenga sentido para el contexto; rate limits y kill switches — si un agente está haciendo más de N acciones por minuto, se apaga automáticamente.
Evals antes de cambios — siempre
Un agente sin suite de evals es como código sin tests. Construye un dataset de 50–100 casos con outputs esperados. Cuando cambies prompt, modelo o herramientas, corre los evals. Si la calidad baja, no haces deploy. Es laborioso al inicio y la mejor inversión a 12 meses.
Observabilidad — más alta que en código normal
Cada llamada de modelo: logueas prompt, response, tokens, latencia, costo, herramienta llamada. LangSmith, Helicone, Langfuse o lo que sea, pero todo. Sin esto, debuggear un comportamiento extraño se vuelve imposible.
Cost control — el problema oculto
Un loop mal diseñado puede gastar 500 USD en una hora. Soft caps por usuario, hard cap por agente, alerta cuando se acerca al cap. Aprendimos esto a las malas.
Modelo principal vs modelo barato
Usa el modelo grande para la tarea principal y un modelo barato para validar o pre-clasificar. Cascade: si el modelo barato está seguro, no llames al grande. Reducción típica: 60–80% del costo total sin perder calidad medida en evals.
Human in the loop — define dónde
Para acciones reversibles (mandar mensaje a usuario): el agente decide. Para acciones irreversibles (transferir dinero, borrar datos, contactar a un cliente importante): siempre human approval. La regla: si te equivocas, ¿se puede deshacer? Si no, hay aprobación humana.
Cómo te ayudamos en Athrun Data Intelligence
Construimos agentes IA en producción con este modelo. Llamada de 30 min para ver si tu caso de uso encaja con agentes o conviene resolverlo con código normal. Hablamos honesto sobre cuándo no aplicar IA.
Fuentes
- Anthropic — Building effective agentshttps://www.anthropic.com/research/building-effective-agents
- Anthropic — Prompt engineering overviewhttps://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
- OpenAI Evals frameworkhttps://github.com/openai/evals
- LangChain documentationhttps://python.langchain.com/docs/
- Anthropic — Responsible scaling policyhttps://www.anthropic.com/news/anthropics-responsible-scaling-policy
Quién lo escribió

- Azure ya exige MFA para cambiar recursos desde la CLI: qué se rompe en tu automatización
- npm v12 dejó de ejecutar los scripts de instalación: qué cambia en tu pipeline
- SQL Server 2016 se quedó sin soporte: ¿pagar ESU, actualizar o migrar?
¿Te pasa algo parecido? Pide el diagnóstico.
Nos cuentas el reto y en 24 horas hábiles te respondemos por escrito si es viable y por dónde empezar. Sin compromiso.