Cómo planificar el alcance de un proyecto de automatización de flujos de trabajo con IA

Si quieres automatizar un flujo de trabajo de tu negocio con IA, construirlo es la parte fácil. El error que comete casi todo el mundo es saltarse la fase de planificación del alcance: mapear el proceso a mano, clasificando cada paso según lo que puede decidir un ordenador, lo que debe juzgar un modelo y lo que tiene que aprobar una persona, antes de escribir ninguna herramienta. Este artículo repasa ese método: qué hacer antes de empezar, un proceso de seis pasos para mapear el trabajo, los errores que estancan la mayoría de los proyectos, y unas preguntas frecuentes sobre dónde trazar la línea entre un flujo de trabajo simple y un agente completo.

Antes de empezar

Qué significa realmente "automatizar" aquí

Hay dos cosas distintas a las que la gente llama automatización con IA, y confundirlas es lo que hace que la mayoría de los proyectos se desvíen. Un flujo de trabajo es una o dos llamadas a un LLM insertadas en pasos predefinidos que un desarrollador escribió de antemano. Un agente, en cambio, es un sistema en el que el modelo decide qué ocurre a continuación, qué herramienta usar y cuándo ha terminado. La propia guía de Anthropic sobre cómo construir agentes deja la distinción muy clara: los flujos de trabajo ofrecen previsibilidad y consistencia para tareas bien definidas, mientras que los agentes justifican su coste solo en problemas abiertos donde no se puede predecir de antemano el número de pasos. La mayoría de los procesos de negocio (enrutamiento de facturas, clasificación de tickets, generación de informes) son flujos de trabajo disfrazados de agente. Empieza por ahí.

Qué procesos son buenos candidatos

No todos los procesos merecen ser automatizados primero. Los que vale la pena mapear comparten algunos rasgos: se repiten con pasos consistentes, pasan por varios traspasos entre personas o sistemas, una aprobación manual los frena cada vez, o generan documentación de cumplimiento que tiene que existir en cada ejecución. La guía de Zapier sobre mapeo de procesos señala el mismo patrón desde el lado de las herramientas: la lógica condicional rinde más en procesos con mucho peso normativo o muy variables, y una tarea puntual o muy variable rara vez es un buen primer objetivo. Elige el proceso que ocurre cada semana, no el que ocurre una vez por trimestre.

Tareas que requieren juicio frente a tareas deterministas

Dentro de cualquier proceso, algunos pasos tienen exactamente una salida correcta para una entrada determinada. Esos necesitan una regla, no un modelo. Otros pasos requieren leer algo ambiguo y decidir: ¿es esta una solicitud nueva o un seguimiento?, ¿esta descripción encaja en la categoría A o en la B? Ese segundo tipo es donde un paso con LLM, a veces respaldado por RAG para que la respuesta del modelo se base en tus propios documentos en lugar de adivinar, justifica su lugar.

Paso a paso: cómo planificar el alcance del proyecto

1. Define una tarea acotada con un objetivo medible

Empieza acotado. El marco de Vercel centrado primero en el problema para proyectos agénticos pone un límite útil: la tarea debe ser lo bastante concreta como para que una persona pueda explicar todo el proceso de decisión en menos de cinco minutos. Acompáñala de un número: enrutar correctamente el 90% de las solicitudes a la cola adecuada, no "mejorar el enrutamiento".

2. Simula la tarea a mano con datos reales

Antes de escribir código, recorre tú mismo entre 10 y 20 ejemplos reales a través del proceso. Tómalos de la cola real del mes pasado, no de casos hipotéticos inventados en una pizarra. Anota cada punto de decisión y cada traspaso: dónde tuviste que abrir un segundo sistema para comprobar algo, dónde varió el formato de entrada respecto al ejemplo anterior, dónde dudaste. Este es el paso que los equipos se saltan, y es el que revela dónde se necesita acceso a herramientas, dónde una regla fija puede sustituir por completo el razonamiento del modelo, y dónde una persona todavía tiene que revisar el resultado. Veinte minutos de simulación manual suelen ahorrar una semana de retrabajo cuando la tarea "sencilla" resulta tener casos límite que nadie había anotado.

3. Clasifica cada paso en tres categorías

Cada paso del proceso cae en una de tres categorías: código determinista (una única respuesta correcta, se escribe una regla), juicio de un LLM (la entrada es ambigua, una llamada al modelo justifica su coste), o puerta de aprobación humana (lo que está en juego es suficiente como para que una persona lo firme). Esta clasificación decide si encaja un flujo de trabajo lineal simple o si el proceso necesita una estructura ramificada. El marco de Vercel llama a este mapeo el mayor predictor de si un proyecto llega a producción.

4. Define el acceso a herramientas y los puntos de conexión

Mantén pequeña la primera versión: de dos a cuatro herramientas, no una docena. Si el modelo necesita llegar a sistemas externos, ya sea un CRM, una cola de tickets o una base de datos interna, Model Context Protocol es la capa de conexión estándar que conviene conocer aquí, porque define una forma consistente de que un modelo descubra y llame a herramientas en lugar de que cada integración sea a medida.

5. Coloca una puerta de aprobación en todo lo irreversible

Las transacciones financieras, los despliegues a producción, cualquier cosa que toque datos sensibles de clientes y cualquier acción que no se pueda deshacer: todo esto necesita un punto de control humano, decidido en el momento del diseño y no añadido después de que algo se rompa. La guía de OpenAI sobre seguridad de agentes plantea esto como una defensa por capas: puertas de aprobación para acciones irreversibles, permisos de herramientas acotados para que el modelo no pueda acceder a más datos de los que la tarea necesita, y esquemas de salida estructurados para que una respuesta tenga que ajustarse a una forma definida en lugar de texto libre. Nuestro propio artículo sobre puertas de aprobación y registros de auditoría profundiza en cómo integrar ese punto de control en un sistema real.

6. Instrumenta antes de escalar

Añade trazabilidad, un límite de turnos y un seguimiento básico de costes desde la primera versión, no después de la décima ejecución. Un bucle atascado o un pico de coste debería ser visible en minutos, no descubrirse a final de mes. Registra cada entrada, cada llamada a herramienta y cada salida en un lugar donde una persona pueda buscarlo. Ese registro es lo que convierte "la automatización se equivocó" en un paso concreto y corregible, en lugar de un encogimiento de hombros.

Errores comunes que estancan los proyectos de automatización con IA

Los proyectos que se estancan casi siempre comparten el mismo puñado de errores. Algunos equipos se saltan el recorrido manual y van directo a elegir una herramienta, así que la primera sorpresa real ocurre en producción en lugar de en una pizarra. Otros recurren a un agente dinámico cuando un flujo de trabajo fijo habría bastado, lo que eleva tanto el coste como la probabilidad de un error acumulativo, ya que un agente que se equivoca en el paso dos arrastra ese error a todos los pasos siguientes. Unos pocos añaden la puerta de aprobación solo después de un incidente, cuando debería haber formado parte del alcance desde la primera frase. Un acceso amplio a herramientas o datos, concedido de entrada en lugar del mínimo que la tarea necesita, convierte un error de planificación en un problema de seguridad. Y muchos equipos miden el éxito por si la demostración impresiona, en lugar de por el número concreto anotado en el paso uno, así que nadie puede afirmar con seguridad si la cosa realmente está funcionando tres meses después.

Ninguno de estos errores requiere herramientas exóticas para evitarse. Requieren hacer primero el aburrido trabajo de mapeo, anotar un número que defina el éxito, y ser honesto sobre qué pasos realmente necesitan juicio frente a cuáles solo necesitan una regla que nadie se molestó en escribir.

Este es el mismo proceso de planificación que aplicamos antes de cualquier proyecto de automatización en Kallos Labs: mapear el proceso, clasificar los pasos, bloquear lo que no se puede deshacer, y solo entonces decidir qué construir. Si estás valorando si un proceso está listo para esto, nuestro trabajo de automatización con IA es un buen lugar para ver cómo se aplica el método de principio a fin.

Preguntas frecuentes

¿Cuánto debería durar la planificación antes de empezar a construir una automatización con IA?

Para una sola tarea acotada, uno o dos días de simulación manual y mapeo de pasos suele bastar. Si el proceso no se puede explicar de principio a fin en pocos minutos, todavía no está bien planificado, y necesita otra revisión antes de construir ninguna herramienta.

¿Necesito un agente de IA completo, o bastará con un flujo de trabajo más simple?

Empieza con un flujo de trabajo: pasos predefinidos con una llamada al modelo en uno o dos puntos. Recurre a un agente dinámico solo cuando la tarea no tenga un número fijo de pasos y el modelo realmente tenga que decidir qué ocurre a continuación, ya que los agentes cuestan más y acumulan errores más rápido que un camino fijo.

¿Qué partes de un proceso de negocio nunca deberían ejecutarse sin una revisión humana?

Las transacciones financieras, los despliegues a producción, cualquier cosa que toque datos sensibles de clientes y cualquier acción que no se pueda deshacer. Esas requieren una puerta de aprobación en el momento del diseño, no después de que algo salga mal.

¿Cómo sé si un flujo de trabajo es un buen candidato para la automatización?

Busca tareas recurrentes con pasos consistentes, múltiples traspasos entre personas o sistemas, aprobaciones manuales que ralentizan las cosas, o documentación de cumplimiento que tiene que existir en cada ejecución. Las tareas puntuales o muy variables suelen ser un mal primer candidato.