Qué es un agente de IA y en qué se diferencia de un chatbot
Un agente de IA es un sistema que recibe un objetivo, decide por su cuenta qué pasos dar para alcanzarlo y ejecuta esos pasos usando herramientas externas: consultar una base de datos, leer un buzón de correo, crear un ticket o llamar a una API. La diferencia con un chatbot no está en el modelo de lenguaje, que puede ser el mismo, sino en que el agente actúa sobre sistemas reales en lugar de limitarse a devolver texto. Dicho de otro modo: un chatbot responde, un agente hace.
Chatbot, automatización y agente: tres cosas distintas
En las conversaciones con dirección estas tres palabras se usan como sinónimos y no lo son. La confusión sale cara, porque cada una tiene un coste de implantación, un perfil de riesgo y un mantenimiento muy diferentes.
Un chatbot conversa. En su versión clásica sigue un árbol de decisiones escrito a mano; en su versión moderna genera texto con un modelo de lenguaje. En ambos casos, el resultado es una respuesta en pantalla y el trabajo de verdad lo sigue haciendo una persona.
Una automatización ejecuta una secuencia fija. Cuando entra una factura, se extraen estos campos, se comprueba este dato y se guarda en este sitio. Es determinista, se puede auditar paso a paso y es la mejor opción para todo proceso que sea siempre igual. Si un flujo se puede describir en un diagrama sin ambigüedad, no hace falta un agente.
Un agente combina las dos cosas y añade la parte incómoda: decide. Ante un objetivo, elige qué herramienta usar, en qué orden, cuándo repetir un paso y cuándo darse por satisfecho. Esa capacidad de decisión es lo que le permite abordar tareas donde no existe un camino único, y es exactamente lo que hace que necesite controles que una automatización no necesita.
- Chatbot: entrada de texto, salida de texto. No toca ningún sistema.
- Automatización: mismo camino siempre, resultado predecible, fácil de auditar.
- Agente: elige el camino en cada ejecución y actúa sobre sistemas reales.
Qué necesita un agente para funcionar en producción
La demostración de un agente es fácil de montar y engaña. Lo que separa una demo de algo que aguanta un año en producción son cuatro piezas poco vistosas.
Herramientas bien definidas
Un agente sin herramientas es un chatbot. Cada herramienta es una función concreta que el sistema puede invocar: buscar un cliente en el ERP, comprobar el estado de un pedido, enviar un correo. Cuanto más estrecha y mejor descrita esté cada una, mejor funciona el conjunto. El error habitual es dar al agente una herramienta genérica y potente, del tipo ejecutar cualquier consulta SQL, esperando flexibilidad. Lo que se obtiene es un sistema impredecible y difícil de revisar.
Contexto de la empresa
El modelo sabe mucho del mundo y nada de vuestra empresa. No conoce vuestro catálogo, vuestras condiciones comerciales ni cómo llamáis internamente a las cosas. Ese conocimiento hay que entregárselo en cada ejecución, normalmente mediante recuperación sobre documentación interna. Sin ese contexto, el agente responde con generalidades correctas e inútiles.
Permisos propios y trazabilidad
Un agente debe tener identidad propia dentro de vuestros sistemas, con sus propios permisos, y no reutilizar la cuenta de un administrador porque era lo más rápido de montar. Debe poder ver solo lo que necesita para su tarea y dejar registro de cada acción: qué consultó, qué decidió y qué modificó. Sin ese registro, el día que algo salga mal no habrá forma de reconstruir lo que pasó.
Criterio de parada
Es la pieza que más se olvida. Un agente necesita saber cuándo ha terminado, cuándo debe rendirse y cuándo tiene que pasar el asunto a una persona. Sin un criterio de parada explícito, un agente entra en bucle, repite llamadas, consume presupuesto y, en el peor caso, insiste en una acción equivocada. Definir la condición de fin y el punto de escalado a un humano es parte del diseño, no un detalle de implementación.
Un agente sin criterio de parada no es autónomo: es un proceso sin supervisión al que le hemos dado credenciales.
Dónde aporta valor un agente
Los casos que funcionan tienen un patrón reconocible: mucho volumen, decisiones de baja consecuencia individual y una fuente de verdad accesible por API. Clasificar y enrutar correo entrante, preparar el borrador de una respuesta con los datos del cliente ya cargados, revisar si un pedido cumple las condiciones acordadas, recopilar información dispersa en varios sistemas antes de una reunión.
Fíjese en que en casi todos esos ejemplos el agente prepara el trabajo y una persona lo aprueba. Ese reparto no es una fase transitoria hacia la autonomía total: en muchos procesos es el diseño definitivo y el más rentable. El agente elimina la parte mecánica, que es donde estaba el coste, y deja la decisión donde debe estar.
Los riesgos que no aparecen en la demostración
El primero es el error silencioso. Una automatización que falla suele romperse de forma ruidosa y alguien se entera. Un agente que se equivoca produce un resultado con el aspecto de ser correcto: un correo bien redactado con el importe equivocado. Por eso hacen falta verificaciones automáticas sobre las acciones críticas y revisión humana en las que tienen consecuencias externas.
El segundo es el alcance de los permisos. Un agente puede leer un documento, un correo o una página web cuyo contenido contenga instrucciones dirigidas a él. Si tiene permisos amplios, ese texto puede acabar provocando acciones que nadie pidió. La defensa no es pedirle que ignore instrucciones sospechosas, sino limitar de antemano lo que puede hacer.
El tercero es el coste variable. Cada ejecución consume llamadas al modelo, y un agente que reintenta consume varias veces. Conviene medir el coste medio por tarea desde el primer día y ponerle un tope, porque un fallo de diseño se paga en factura antes de que se note en los resultados.
El cuarto es organizativo y suele ser el que hunde el proyecto: nadie es responsable del agente. Un agente es un sistema en producción y necesita un propietario que revise sus decisiones, atienda las quejas y decida cuándo se apaga.
Cuándo no compensa
Conviene decirlo con claridad, porque la mitad de los proyectos que fracasan no deberían haber empezado.
- El proceso es siempre igual: use una automatización clásica. Es más barata, más rápida y se audita mejor.
- El volumen es bajo: si la tarea ocurre cinco veces al mes, el mantenimiento del agente costará más que hacerla a mano.
- El error no es tolerable: si equivocarse implica un pago mal hecho o un dato enviado a quien no debe, empiece por que el sistema proponga y una persona apruebe.
- La información está solo en la cabeza de la gente: si no hay documentación ni datos accesibles, el agente no tiene con qué trabajar y el primer proyecto real es ordenar esa información.
- Nadie va a mantenerlo: sin un responsable, el agente se degrada en cuanto cambie un proceso o una API.
Conclusión práctica
Un agente de IA es una herramienta razonable para tareas repetitivas, con volumen y con margen de error tolerable, siempre que se le den herramientas concretas, permisos mínimos, contexto de la empresa y una condición de parada clara. Fuera de ese perfil, casi siempre hay una solución más simple que funciona mejor.
La forma sensata de abordarlo es elegir un proceso concreto y medible, medir cuánto cuesta hoy en tiempo, montar el agente con una persona aprobando las acciones y comparar al cabo de unas semanas. Si el ahorro es real, se amplía el alcance y se van soltando controles. Si no lo es, se ha perdido poco y se ha aprendido dónde está de verdad el cuello de botella, que rara vez es donde se pensaba.