Agentes de IA o automatización: cómo elegir el primer proyecto de la empresa

La elección comienza por el proceso, no por la tecnología

El primer proyecto de IA debe elegirse según la estructura del trabajo. Enumere una solicitud real, las entradas recibidas, las decisiones necesarias, los sistemas consultados y el resultado esperado. Después, pregunte cuántas excepciones existen y si el camino para llegar al resultado puede describirse de antemano.

La automatización es la mejor candidata cuando las reglas son explícitas, las entradas están estructuradas y cada salida puede validarse mediante código. Un workflow con un modelo de lenguaje sirve cuando hay texto variable, pero las etapas siguen siendo conocidas. Un agente tiene sentido cuando el sistema debe decidir qué etapas ejecutar y en qué orden, utilizar herramientas y avanzar a partir de resultados intermedios.

La recomendación editorial es comenzar por la solución más sencilla que pueda medirse. Los sistemas basados en agentes suelen añadir latencia, coste operativo y puntos de fallo. La referencia de Anthropic también distingue los workflows, guiados por caminos predefinidos, de los agentes, que dirigen dinámicamente su propio proceso. Recomienda aumentar la complejidad solo cuando esto demuestre una mejora en el resultado.

Fuentes y referencias: [1]

Árbol de decisión para el primer proyecto

Use este árbol antes de elegir una plataforma o un modelo. Convierte una discusión abstracta en un diagnóstico del proceso.

• 1. ¿El trabajo puede describirse mediante reglas del tipo si, entonces, con pocos casos ambiguos? Si la respuesta es sí, empiece con automatización tradicional, integraciones, validaciones y colas. Si no, continúe.
• 2. ¿El trabajo tiene etapas fijas, como clasificar, extraer campos, consultar un sistema y redactar una respuesta? Si la respuesta es sí, implemente un workflow. El modelo puede interpretar el lenguaje, pero el código controla la secuencia.
• 3. ¿Las categorías están claramente separadas y cada una tiene instrucciones o herramientas propias? Si la respuesta es sí, use enrutamiento para enviar la solicitud a un flujo especializado. No convierta cada categoría en un agente separado sin pruebas de que eso mejore el resultado.
• 4. ¿La cantidad o el orden de las etapas depende del contenido de cada solicitud? Si la respuesta es sí, considere un agente con herramientas limitadas. Exija condiciones de parada, límites de iteración y registros de las decisiones.
• 5. ¿El sistema puede modificar datos, enviar mensajes, conceder crédito, cancelar pedidos o ejecutar cualquier otra acción irreversible? Si la respuesta es sí, trátelo como un proyecto de control, no solo de generación de texto. Separe la lectura de la escritura, valide los argumentos y exija confirmación o autorización en el punto de acción.
• 6. ¿Puede definir qué significa resolver el caso? Si no puede, posponga el proyecto o reduzca su alcance. Sin un resultado observable, resulta difícil saber si la autonomía aportó valor o solo añadió complejidad.

Fuentes y referencias: [1][3]

Ejemplo hipotético: clasificación de solicitudes internas

Imagine una empresa que recibe solicitudes por correo electrónico y mediante un portal interno. Los pedidos incluyen acceso a sistemas, dudas sobre reembolsos, fallos técnicos y cambios de datos personales. El objetivo inicial no es responderlo todo automáticamente. Es identificar la categoría, extraer datos útiles, enviar el caso al equipo correcto e informar al solicitante del siguiente paso.

La primera versión recomendada sería un workflow. Un modelo clasifica la solicitud como acceso, finanzas, soporte técnico, datos personales o indefinida. Después, otro paso extrae campos estructurados, como identificador del empleado, sistema afectado, plazo y número del caso. El código valida los formatos, consulta las reglas existentes y envía el caso a la cola correspondiente. Si la categoría es indefinida, falta un campo obligatorio o existe un conflicto entre los datos, el sistema envía el caso a una cola de excepciones, sin intentar adivinar.

Ejemplo de entrada: “Necesito recuperar el acceso al sistema de compras. Mi usuario es ana.silva y tiene que estar resuelto antes del cierre de hoy”. La salida estructurada podría ser categoría acceso, sistema compras, usuario ana.silva, urgencia solicitada hoy y acción abrir solicitud de acceso. La respuesta al usuario solo confirma la recepción y el envío al equipo correspondiente. No concede acceso ni modifica permisos.

Este caso no exige un agente al principio porque las etapas son conocidas. Podría considerarse un agente más adelante si las solicitudes complejas exigieran consultar varios sistemas, descubrir qué información falta, comparar políticas y elegir una secuencia variable de consultas. Incluso en ese escenario, las herramientas deberían ser limitadas, con argumentos validados y permisos mínimos.

Fuentes y referencias: [1][3]

Cuándo convertir el workflow en un agente

La conversión debe ser una decisión basada en casos observados, no en una preferencia arquitectónica. Reúna solicitudes representativas, incluidos textos breves, errores tipográficos, múltiples intenciones, archivos adjuntos y pedidos que mezclen asuntos. Registre dónde falla el workflow: clasificación ambigua, falta de datos, consulta insuficiente o necesidad de un orden variable de acciones.

Un agente se justifica cuando el camino no puede anticiparse sin crear un árbol de reglas demasiado grande y cuando existe retroalimentación verificable en cada etapa. Por ejemplo, una herramienta informa que el sistema consultado no está disponible. Entonces, el agente intenta una fuente alternativa autorizada o detiene el caso con una explicación. Esto es distinto de permitir que el modelo improvise acciones sin observar el entorno.

Mantenga pequeño el agente. Dé acceso solo a las herramientas necesarias, describa con precisión sus parámetros, incluya ejemplos de entradas válidas y haga que las operaciones peligrosas sean difíciles de activar por error. Los textos externos, como los mensajes recibidos, pueden contener instrucciones maliciosas. Los datos no confiables deben aislarse, transformarse en campos estructurados cuando sea posible y no deben controlar directamente herramientas privilegiadas.

Fuentes y referencias: [1][3]

Cómo evaluar antes de ponerlo en producción

No evalúe el proyecto según la impresión de que las respuestas parecen buenas. Prepare un conjunto de casos históricos o sintéticos que represente el tráfico esperado. Incluya ejemplos normales, fronteras entre categorías, solicitudes incompletas, múltiples intenciones, intentos de inducir al sistema a equivocarse y respuestas inesperadas de las herramientas.

Para la clasificación hipotética, mida al menos: categoría correcta, extracción correcta de los campos, cola elegida, ausencia de acciones indebidas, tratamiento de datos faltantes y claridad del mensaje enviado. En un agente, añada selección de la herramienta, precisión de los argumentos, número de etapas, respeto de los límites y cierre apropiado. La orientación de evaluación de OpenAI recomienda realizar pruebas específicas para la tarea, registrar los casos y evaluar de forma continua cada cambio.

Compare también el coste de un fallo. Equivocarse de cola en una duda común no tiene el mismo impacto que conceder acceso, modificar datos personales o enviar información privada. La arquitectura inicial debe ser más conservadora allí donde la consecuencia sea mayor. Una buena prueba puede exigir que el sistema devuelva “no clasificado” en vez de producir una decisión segura de sí misma sin fundamento.

Fuentes y referencias: [2]

Lista de comprobación para decidir e implementar

Use esta lista en una reunión de definición del alcance. Si varias respuestas son negativas, reduzca el proyecto antes de añadir autonomía.

• Definir una única solicitud o una familia limitada de solicitudes.
• Describir el resultado esperado en términos observables.
• Separar las tareas de lectura, clasificación, consulta y escritura.
• Verificar si las etapas son fijas o si realmente dependen del caso.
• Elegir automatización, workflow o agente según esta diferencia.
• Definir categorías, campos obligatorios, estados de excepción y condiciones de parada.
• Limitar las herramientas por función y validar todos los argumentos antes de ejecutarlas.

Preguntas que evitan un primer proyecto deficiente

¿El proceso necesita interpretar lenguaje o solo transportar datos entre sistemas? Si se trata de transportar datos, probablemente sea suficiente una integración convencional.

¿Cuál es la acción más grave que el sistema podría ejecutar por error? La respuesta define los permisos, las confirmaciones, las pruebas y el límite de autonomía.

¿Qué evidencia demostrará que la nueva versión es mejor que la actual? Si no hay una métrica, casos de prueba o criterio de cierre, el proyecto todavía no está listo para implementarse.