Agentes con modelos de lenguaje: cómo se construyen, se miden y se mantienen

Un agente en producción no es un prompt bien escrito: es un sistema con casos de prueba, registro de cada llamada, límites de gasto y alguien responsable de mantenerlo. La parte de conseguir que funcione una vez es la fácil y la que se enseña en las demos. Lo demás es lo que decide si sigue vivo en marzo.

Puntos clave

• El despliegue real de agentes sigue en cifras de un solo dígito por función de negocio, muy por debajo de lo que sugiere la conversación pública.
• Sin un conjunto de casos de prueba no puedes saber si un cambio mejoró o empeoró las cosas.
• El costo que sorprende no es el de la respuesta: son los reintentos, el contexto largo y el volumen del segundo mes.
• Un agente que responde «no lo sé» cuesta mucho menos que uno que se lo inventa.

¿Cuántas empresas tienen agentes funcionando de verdad?

Muchas menos de las que hablan de ellos. El AI Index 2026 de Stanford midió el despliegue de agentes por función de negocio y lo encontró en cifras de un solo dígito en casi todas las áreas, esto en organizaciones donde el 88% ya adoptó IA de alguna forma (Stanford HAI).

Esa distancia entre adoptar IA y tener un agente operando dice algo útil: la parte difícil no es que el modelo responda bien. Es todo lo que hay que construir alrededor para poder confiar en él sin supervisarlo llamada por llamada.

¿Qué diferencia a un agente de una automatización?

Que decide. Una automatización ejecuta los pasos que alguien definió: si pasa esto, haz aquello. Un agente recibe un objetivo y elige qué pasos dar.

Esa diferencia se paga en previsibilidad. Un workflow hace siempre lo mismo, y cuando falla, falla igual todas las veces y es fácil de depurar. Un agente puede resolver un caso que nadie anticipó, y también puede resolver mal uno que un workflow habría hecho bien.

La regla que uso para decidir entre los dos: si puedes enumerar los casos en una tarde, escribe un workflow. Los agentes empiezan a compensar cuando la variedad de entradas hace inviable enumerarlas, no cuando el proceso es complicado.

¿Cómo se mide si las respuestas son buenas?

Con un conjunto de casos de prueba escrito antes de tocar nada, y esto es lo que separa un experimento de un sistema.

Un conjunto útil son entre veinte y cincuenta casos reales sacados de tu propia operación, cada uno con la respuesta que consideras correcta. No hacen falta mil. Hacen falta suficientes para cubrir lo típico, lo raro y lo que salió mal alguna vez.

Con eso se responden las tres preguntas que van a aparecer sí o sí:

1. ¿Este cambio de prompt mejoró o solo cambió las cosas?
2. ¿La versión nueva del modelo sirve para mi caso o solo para el promedio?
3. ¿Podemos bajar a un modelo más barato sin que se note?

Sin casos de prueba, esas tres se responden por intuición y por la última queja que llegó. Con ellos, se responden en veinte minutos.

Conviene guardarlos como archivos en el repositorio, junto al código. Un conjunto de pruebas que vive en la carpeta de alguien deja de actualizarse en cuanto esa persona cambia de proyecto.

¿Cómo se controla lo que inventa?

Acotando, no prohibiendo. Un modelo de lenguaje siempre puede producir algo que suena correcto y no lo es; lo que se puede diseñar es cuánto daño hace eso.

Tres medidas que funcionan y se pueden montar desde el principio. La primera es darle solo los datos que necesita para esa tarea, porque cuanto más contexto irrelevante recibe, más material tiene para mezclar cosas que no van juntas. La segunda es pedirle que indique de dónde sacó cada afirmación, lo que además hace las revisiones mucho más rápidas. La tercera es validar contra una fuente antes de que la salida llegue a alguien: si el agente dice que un pedido está en tránsito, que lo compruebe en el sistema y no en su memoria.

Y una decisión de diseño que ahorra más problemas que las tres juntas: dejar que diga que no sabe. Un agente que escala a una persona el 15% de los casos es mejor negocio que uno que responde el 100% y se equivoca en el 8%.

¿Qué cuesta operarlo de verdad?

Más que la cuenta que hiciste, y casi nunca por el precio por respuesta.

Lo que se dispara son otras tres cosas. Los reintentos, porque un agente que falla y vuelve a intentar puede costar tres veces lo previsto en los casos difíciles, que además son los más frecuentes de lo que parece. El contexto, porque conforme el sistema madura se le da más información en cada llamada y el costo crece con ella. Y el volumen del segundo mes, cuando el equipo descubre que funciona y empieza a usarlo para cosas que nadie presupuestó.

La forma práctica de no llevarse el susto: calcula el gasto de un mes con tu peor caso de volumen, multiplícalo por dos, y decide con esa cifra. Y pon un tope duro por día en la plataforma, no solo una alerta. Una alerta a las tres de la mañana no detiene nada.

¿Qué hay que registrar de cada llamada?

Entrada, salida, versión del modelo, versión del prompt, costo y latencia. Los seis, desde el primer día.

Suena excesivo hasta la primera vez que alguien te reporta una respuesta rara y no puedes reproducirla porque no sabes con qué versión de qué prompt se generó. A partir de ahí nadie discute el registro.

Con esos seis campos se contesta lo que se va a preguntar en las juntas: cuánto costó el mes, qué porcentaje escaló a una persona, si la calidad se movió después del último cambio, y cuáles son los diez casos más caros. Sin ellos, el agente es una caja negra que factura.

¿Cómo se conecta esto al CRM sin romper nada?

Empezando por escribir en un solo sitio y en un solo sentido. La tentación es darle al agente permiso para actualizar todo; el resultado suele ser un CRM con datos que nadie sabe de dónde salieron.

Lo que funciona: que el agente escriba en propiedades propias, marcadas como generadas automáticamente, y que una persona o una regla promueva ese valor al campo oficial. Así, cuando algo sale mal, se ve exactamente qué escribió el modelo y se puede revertir sin tocar el histórico.

Y antes de todo esto, la base tiene que estar limpia. Un agente que clasifica sobre registros duplicados va a dar tres respuestas distintas para la misma empresa. Eso se trata primero, en cómo limpiar los datos de tu CRM, y la decisión de si este caso de uso merece la pena está en dónde entra la IA en tu operación.

¿Qué pasa cuando cambia el modelo debajo?

Cambia el comportamiento, y muchas veces sin aviso. Un proveedor actualiza su modelo, mejora el promedio en sus pruebas, y tu caso concreto empeora sin que nadie lo note hasta que llega una queja.

Por eso la respuesta a esta pregunta es la misma que a la de medir calidad: el conjunto de casos de prueba. Fijar la versión del modelo cuando la plataforma lo permita, correr las pruebas antes de aceptar una versión nueva, y tener a alguien con el mantenimiento asignado por escrito.

Ese último punto es el que más agentes ha matado. No fallan de golpe: se degradan mientras nadie tiene el encargo de mirarlos.

Por dónde empezar

Con un caso de uso donde la salida ya la revisa alguien, veinte casos de prueba escritos a mano, y registro completo desde la primera llamada. En ese orden.

Montarlo así cuesta unos días más que hacer una demo, y es la diferencia entre un proyecto que sigue funcionando en seis meses y uno que se apaga en silencio cuando la persona que lo montó se ocupa de otra cosa.

Si quieres que revisemos qué caso tuyo aguanta producción, el diagnóstico inicial no tiene costo. También puedes ver cómo trabajamos la transformación con IA.

Preguntas frecuentes

¿Qué diferencia hay entre un agente y una automatización normal? Una automatización ejecuta pasos que tú definiste. Un agente decide qué pasos dar. Esa diferencia le da flexibilidad y le quita previsibilidad, así que solo compensa cuando las entradas varían tanto que enumerar los casos a mano es inviable.

¿Cuánto cuesta operar un agente al mes? El costo por respuesta rara vez es el problema: el problema es el volumen y los reintentos. Antes de lanzar, calcula el gasto de un mes con el peor caso de volumen y multiplícalo por dos. Si esa cifra te incomoda, el caso de uso no está listo para producción.

¿Cómo evito que invente cosas? No se elimina, se acota. Dale al modelo solo los datos que necesita, pídele que cite de dónde salió cada afirmación, y valida las salidas contra una fuente antes de que lleguen al cliente. Un agente que dice «no lo sé» es más barato que uno que se lo inventa.

¿Qué pasa cuando el proveedor cambia el modelo? Cambia el comportamiento, aunque nadie te avise. Por eso el conjunto de casos de prueba no es opcional: es lo único que te permite saber si la versión nueva mejoró o empeoró tu caso concreto, en lugar de enterarte por una queja.