Cuándo necesitas un agente de IA y cuándo basta una automatización

Una solicitud comercial puede llegar como un formulario con campos definidos o como un mensaje: «Estamos preparando un lanzamiento y necesitamos ayuda para conseguir clientes». Ambas entradas expresan interés, pero no plantean el mismo problema técnico.

En el primer caso, probablemente necesitas validar datos y trasladarlos a un sistema. En el segundo, debes interpretar qué se pide y determinar qué información falta. Incluso ahí, un agente no es necesariamente la primera respuesta: puede bastar un modelo dentro de un flujo controlado.

Mi criterio de construcción es separar tres cosas antes de elegir tecnología: qué está definido por reglas, qué requiere interpretación y qué exige decidir el siguiente paso durante la ejecución.

Automatización, modelo y agente no son lo mismo

Para elegir una arquitectura, conviene usar una distinción operativa:

• Una automatización ejecuta un recorrido definido. Puede tener condiciones, bifurcaciones y reintentos sin dejar de ser una automatización.
• Un modelo interpreta o genera información dentro de una tarea delimitada: extraer una necesidad de un mensaje, clasificarla o redactar una pregunta.
• Un agente combina un modelo con herramientas y un ciclo de ejecución: observa información, selecciona una acción permitida, evalúa su resultado y decide cómo continuar.

La diferencia no es que una opción sea básica y otra avanzada. Es dónde reside la decisión. Si el recorrido puede especificarse de antemano, no hace falta delegárselo a un agente.

Añadir un modelo a una automatización tampoco la convierte automáticamente en un sistema agéntico.

Caso 1: registrar un formulario en un CRM

Consideremos un ejemplo hipotético. Una empresa recibe solicitudes mediante un formulario con nombre, correo, empresa, servicio de interés y descripción opcional. El objetivo es crear una solicitud en su CRM y asignarla según el servicio elegido.

El recorrido puede definirse con reglas:

1. Comprobar los campos obligatorios y el formato del correo.
2. Validar que el servicio pertenece a una lista admitida.
3. Buscar si el contacto ya existe mediante un criterio acordado.
4. Crear o actualizar el contacto y registrar la nueva solicitud.
5. Asignarla al equipo correspondiente mediante una tabla de rutas.

Aquí no hay una decisión abierta que justifique un agente. Hay condiciones conocidas y operaciones sobre datos estructurados.

La implementación sí exige cuidado. Por ejemplo, conviene asignar un identificador único a cada envío para que un reintento no cree dos solicitudes. También hay que definir qué ocurre si el CRM no responde y qué campos pueden actualizarse sin sobrescribir información válida.

Son problemas de ingeniería de integración. Introducir un modelo no los resuelve y añade una dependencia innecesaria si solo debe trasladar campos.

Caso 2: interpretar una solicitud abierta

Supongamos ahora que llega este mensaje, también hipotético:

Tenemos una tienda online y queremos apoyo con el próximo lanzamiento. Nos interesa trabajar contenido y anuncios, pero todavía estamos definiendo el alcance.

El texto no encaja limpiamente en una única opción del formulario. Un modelo puede convertirlo en una propuesta estructurada:

• Necesidad explícita: apoyo para un lanzamiento.
• Áreas mencionadas: contenido y anuncios.
• Datos ausentes: fecha del lanzamiento y alcance esperado.
• Siguiente paso propuesto: preguntar por la fecha y qué apoyo necesitan en cada área.

La distinción entre dato e interpretación debe conservarse. «Menciona anuncios» está respaldado por el mensaje; «tiene presupuesto disponible» no lo está. Si falta un dato, el sistema debe representarlo como ausente, no completarlo con una suposición plausible.

Para resolver este caso todavía podría bastar un flujo fijo: recibir mensaje, pedir al modelo una extracción con un esquema definido, validar la respuesta y presentar un borrador de seguimiento a una persona.

El modelo aporta interpretación. La automatización conserva el control del recorrido.

Cuándo sí aporta un agente

Un agente empieza a tener sentido cuando el siguiente paso depende de lo que va descubriendo y no solo de una secuencia prefijada.

En una ampliación hipotética del caso, podría disponer de herramientas para consultar la ficha del contacto, recuperar solicitudes anteriores y buscar información en un catálogo de servicios. Tal vez la fecha del lanzamiento ya esté registrada. Tal vez exista una solicitud relacionada que haga innecesario abrir otra conversación.

El agente podría decidir qué consultar y, con los resultados, proponer una pregunta pertinente. Esa capacidad aporta flexibilidad, pero también exige construir un entorno acotado: herramientas permitidas, permisos de acceso, condiciones de parada y una salida definida cuando no consigue resolver la tarea.

Si esas consultas siempre ocurren en el mismo orden y sus bifurcaciones son manejables, seguiría prefiriendo un flujo explícito. Que una tarea tenga varios pasos no basta para justificar un agente.

Una arquitectura combinada y comprobable

Para este ejemplo, una separación útil sería dejar la validación, la deduplicación y la escritura en el CRM bajo reglas; usar el modelo para interpretar el mensaje; e incorporar un agente solo si necesita seleccionar consultas durante la ejecución.

La supervisión puede concentrarse en la interpretación ambigua y en el siguiente paso propuesto. El componente que interpreta no necesita recibir permiso para modificar cualquier campo ni contactar al solicitante por su cuenta.

Antes de desplegar, probaría entradas completas, mensajes ambiguos, datos contradictorios y fallos de las herramientas. Evaluaría cada capa por separado: si el registro se crea correctamente, si la extracción respeta el texto y si las consultas elegidas aportan información necesaria.

La elección no es «automatización o agente» como alternativas excluyentes. Es asignar a cada parte el grado de autonomía que necesita. Una buena arquitectura usa reglas donde conoce el camino, interpretación donde el lenguaje lo exige y un agente cuando decidir el recorrido aporta algo concreto.