Agentes de IA en la empresa: lo que funciona en producción
Soporte, cualificación de leads, documentos, herramientas internas. Dónde aguantan los agentes de IA en producción, dónde fallan y cómo medir si uno funciona.
6 min de lectura

Casi todas las demos de agentes funcionan. La pregunta es qué pasa con la petición número 400, un martes, cuando el cliente escribe mitad en español, mitad en inglés y adjunta una foto borrosa de una factura.
Un agente es un modelo que lee una petición, decide qué hacer, llama a sus herramientas y actúa. Esa última parte es la que cambia el proyecto.
Un chatbot que responde mal da una mala respuesta. Un agente que actúa mal emite un reembolso dos veces, o envía un lead al comercial equivocado.
Si alguien en su comité de dirección ha preguntado este trimestre "¿y los agentes?", esta es la versión corta: cuatro casos de uso que aguantan, cuatro formas en que fallan y tres cosas que conviene tener antes de que uno entre en producción.
Casos de uso de agentes de IA que aguantan en producción
Los casos de uso que sobreviven tienen la misma forma. La tarea es frecuente, las entradas son desordenadas y una persona puede revisar el resultado más rápido de lo que tardaría en producirlo.
Atención al cliente. El agente lee el ticket, consulta el pedido o la cuenta y responde, o redacta una respuesta para el equipo. Estado del pedido, cambios de dirección, condiciones de devolución: las preguntas que llenan la cola cada mañana. No necesita cerrar todos los tickets: quitar de la cola la parte repetitiva ya cambia la semana del equipo.
Cualificación de leads. Llega un formulario, o un correo. El agente lo completa con lo que es público, lo contrasta con sus criterios y lo deriva: a ventas, a una secuencia de nurturing o a ninguna parte. Los comerciales dejan de leer cada entrada para encontrar las tres que importan.
Procesamiento de documentos. Facturas, órdenes de compra, contratos, documentos de identidad, siniestros. El agente extrae los campos, los contrasta con sus sistemas y señala lo que no cuadra. Suele ser el caso de uso menos visible, y a menudo el primero que se amortiza, porque el volumen es alto y el trabajo, tedioso.
Herramientas internas. Un agente que responde "dónde está la última tabla de precios" o "qué acordamos con este cliente en marzo" a partir de sus propios documentos y herramientas. Funciona cuando las fuentes están limpias y el agente las cita. Falla en silencio cuando no lo están.
Dónde fallan
Los agentes fallan de formas previsibles. Conocerlas de antemano es la mayor parte del trabajo de definir el alcance de uno.
La primera es la cola larga. Un agente que resuelve bien la mayoría de los casos puede seguir siendo un mal producto si el resto son los caros: el cliente enfadado, el contrato con una cláusula fuera de lo habitual, el lead que en realidad es un competidor. Hay que saber cuáles son esos casos antes de decidir qué puede hacer el agente por su cuenta.
La segunda son los datos: si el historial de pedidos vive en tres sistemas que no coinciden, el agente se contradirá a sí mismo. Ningún modelo arregla eso.
A veces el primer proyecto útil es una API limpia sobre los datos, y el agente viene después. Es menos llamativo de anunciar, y es lo que hace que el agente funcione.
La tercera es la ampliación del alcance. A un agente que hace bien una tarea le piden que haga cinco. Cada nueva herramienta que puede llamar añade formas de fallar, y la evaluación que se construyó para la primera tarea no dice nada de las demás.
La cuarta es el coste: cada paso que da un agente es una llamada al modelo, a veces varias. Un flujo que encadena diez llamadas por petición parece barato en una demo y muy distinto con 20.000 peticiones al mes. Gran parte de ese coste desaparece con un modelo más pequeño en los pasos fáciles y una caché en los repetidos, pero solo si alguien lo mide antes del lanzamiento.
Cómo medir si un agente de IA funciona
"Parece que va bien" no es una medida. Antes de que un agente entre en producción, deberían existir tres cosas.
Un conjunto de pruebas con casos reales. Tome unos cientos de peticiones reales de los últimos meses, con la respuesta que habría dado un buen empleado. Ejecute el agente sobre ellas antes de cada cambio en el prompt, el modelo o las herramientas. Sin ese conjunto, cada mejora es una suposición y cada actualización del modelo es un riesgo que no se ve.
Una línea clara de revisión humana. Decida qué hace el agente solo y qué se limita a proponer. Un reparto habitual: el agente actúa solo en acciones de bajo riesgo y reversibles, y redacta todo lo demás para que una persona lo apruebe con un clic. Mida con qué frecuencia la gente modifica el borrador y, cuando esa tasa baje en una categoría, deje que el agente actúe solo en ella.
Un coste por tarea. No la factura mensual de la API: el coste de un ticket atendido o de una factura procesada, contando llamadas al modelo, infraestructura y los minutos que una persona dedica a revisar. Póngalo al lado de lo que cuesta hoy la misma tarea. Si esa cifra no se sostiene con su volumen real, el proyecto tampoco, por buena que fuera la demo.
Conjunto de pruebas, línea de revisión, coste por tarea. Si falta uno, el agente no está listo.
Una vez en producción, siga midiendo: registre cada ejecución, revise una muestra cada semana y vuelva a puntuarla. El proveedor del modelo publica una nueva versión, y la pregunta sobre reembolsos que funcionaba el mes pasado recibe ahora una respuesta educada y errónea. Un agente que nadie vigila empeora sin que nadie lo note.
Cómo es una primera versión
Un buen primer agente es acotado. Una tarea, un equipo, unas pocas herramientas y un paso de revisión que el equipo use de verdad.
Es tiempo suficiente para conectar el agente a los sistemas reales, construir el conjunto de pruebas con el equipo que hace hoy el trabajo y ponerlo ante peticiones reales con una persona revisando. No es tiempo suficiente para automatizar un departamento entero. Las primeras semanas en producción dicen más que cualquier piloto.
Pronto surgen dos preguntas. La primera es adónde van los datos: pueden quedarse alojados en Europa, en su nube o en sus propios servidores, con sus reglas. Para un agente esto importa más que para un chatbot, porque lee sus pedidos, contratos y fichas de clientes para hacer su trabajo (más sobre datos, RGPD y el AI Act).
La segunda es quién opera el agente después del lanzamiento. Alguien tiene que hacerse cargo del conjunto de pruebas, de la cola de revisión y del coste por tarea. Si nadie en su equipo tiene todavía ese cometido, planifíquelo desde el principio: por eso nosotros operamos lo que construimos, con las mismas personas que lo construyeron.
Empiece por una tarea
La primera pregunta útil no es "dónde podemos usar agentes", sino "qué tarea repite aquí una persona cien veces por semana". La auditoría gratuita es una hora sobre esa pregunta, seguida de un documento breve que dice qué tareas merecen un agente y cuáles no.
Reserve una auditoría gratuita y traiga la primera tarea que delegaría. Si un agente no es la respuesta, el documento lo dirá.


