Cómo elegir y mapear qué procesos automatizar con IA

No todos los procesos son buenos candidatos para un agente, y elegir mal es el error más caro de toda la implantación: un proceso sin volumen, con excepciones imprevisibles o desconectado de la cuenta de resultados produce un piloto que funciona y que nadie usa. Antes de mapear nada hay que seleccionar bien. Y una vez seleccionado, mapear un proceso es un trabajo concreto con cuatro ejes. Esto va de las dos cosas: qué procesos automatizar con IA y cómo se ponen por escrito.

Este artículo es una fase de la guía completa de cómo implementar agentes de IA, la que decide sobre qué se va a trabajar. Hacerla bien ahorra meses después.

Los criterios para elegir un buen candidato

Un buen candidato reúne cinco condiciones. No hace falta que las cumpla todas al máximo, pero si falla en varias, busca otro proceso.

Criterio	Qué buscar	Por qué importa
Volumen	Casos frecuentes y repetidos, no una vez al mes	Sin volumen, automatizar no compensa el trabajo de codificarlo
Reglas conocidas	Que exista una lógica, aunque hoy viva en la cabeza de alguien	Si nadie sabe por qué se decide lo que se decide, no hay nada que codificar
Excepciones tipificables	Que las rarezas se puedan agrupar y nombrar	Las excepciones que no se pueden tipificar acaban devolviendo el trabajo a una persona
Resultado medible	Que puedas decir si un caso salió bien o mal	Sin medida no hay evaluación, y sin evaluación no hay producción
Cercanía al negocio	Ligado a ingresos, margen o servicio	Un piloto de laboratorio, desconectado de la cuenta de resultados, acaba en la estantería

El último criterio es el que más se ignora y el que más pesa. Los pilotos que he visto morir compartían un rasgo. Eran técnicamente vistosos y comercialmente irrelevantes. Elige el proceso que le importa a alguien de negocio, no el que luce en una demo. La razón de fondo la analizo en por qué fracasan los pilotos de IA.

Los procesos que parecen buenos y no lo son

Dos trampas frecuentes. La primera: el proceso creativo o de juicio experto que se disfraza de repetitivo. Si cada caso exige criterio nuevo, no hay patrón que codificar, por mucho volumen que tenga. La segunda: el proceso con reglas que nadie sabe explicar. Cuando preguntas “¿por qué a este cliente se le trata distinto?” y la respuesta es “siempre se ha hecho así”, el primer trabajo no es técnico, sino reconstruir la regla o decidir eliminarla. Ese ejercicio suele ser tan valioso como la propia automatización.

Si el proceso no es candidato, ¿a dónde va?

Descartar un proceso deja abierta la pregunta más útil de esta fase. Qué haces entonces con él. Un descarte sin destino acaba siendo un proceso que sigue exactamente igual y una reunión que se repite dentro de seis meses. Casi todos los descartes que he visto caen en uno de estos seis destinos, y quien decide cuál es el motivo concreto por el que el proceso no pasa el filtro.

Por qué no pasa el filtro	Qué conviene hacer en su lugar
Se ejecuta siempre igual y no tiene excepciones reales	Automatización clásica o RPA. Pagar capacidad de decidir para un proceso que no decide nada es coste de más, y lo comparo en RPA o agentes de IA
Es determinista y solo encadena sistemas que ya tienen API	Una herramienta de automatización visual, más barata de montar y de mantener, como analizo en n8n o agentes a medida
El problema es que la gente no encuentra información, no que falte quien ejecute	Un chatbot con LLM sobre tu base de conocimiento, la distinción que trato en chatbot o agente de IA
Cada caso exige criterio experto y la persona debe conservarlo	Un copiloto que asista a esa persona sin quitarle la decisión, según el reparto que explico en copiloto o agente de IA
Nadie sabe explicar por qué se decide lo que se decide	Reconstruir la regla o eliminarla. Es trabajo de negocio y no de tecnología, y hay que hacerlo antes
Volumen bajo, o no sabes decir si un caso salió bien	Dejarlo donde está. Volver cuando haya volumen o cuando exista una medida del resultado

Conviene separar dos descartes que se parecen y funcionan distinto. Hay procesos que no serán candidatos nunca porque su naturaleza no lo pide: los tres primeros de la tabla seguirán estando mejor servidos por otra herramienta aunque su volumen se multiplique por diez. Y hay procesos que no lo son todavía, porque les falta una regla escrita, volumen o una forma de medir el resultado. Esos vuelven a la lista, y suelen volver en mejores condiciones que los que entraron a la primera. Confundir los dos tipos sale caro en las dos direcciones. Se fuerza un agente donde sobra, o se entierra para siempre un proceso al que solo le faltaba documentación.

Hay una razón económica para dejar este enrutado por escrito y no en la cabeza de quien hizo la selección. El coste de elegir mal un proceso no aparece en la propuesta del proveedor. Aparece meses después, en excepciones que nadie mapeó y en un mantenimiento que no compensa el trabajo ahorrado, dos de las partidas que desgloso en cuánto cuesta implantar IA con agentes. Un descarte razonado y fechado es más barato que un piloto que llega a producción y no debía haber salido de la lista.

Cómo se mapea un proceso: cuatro ejes

Seleccionado el proceso, mapearlo es hacerlo explícito en cuatro ejes. Un agente ejecuta lo que se le define, así que la calidad del mapa es el techo de la calidad del sistema.

Entradas. Qué recibe el proceso y por qué canal: un correo, un pedido en el ERP, un documento adjunto, una llamada transcrita. Incluye los formatos sucios reales, no el formato ideal. Si el 30 % de los pedidos llega en un PDF mal escaneado, eso es una entrada del proceso, no una excepción.

Reglas. La lógica que transforma la entrada en resultado: qué se comprueba, contra qué se coteja, qué decide el siguiente paso. Aquí es donde aflora el conocimiento tácito. La prueba de que el mapa está completo es que una persona ajena al departamento podría seguir las reglas y llegar al mismo resultado.

Excepciones. Los casos que se salen de las reglas, agrupados y con su motivo. Para cada una, una decisión de diseño: ¿la resuelve el agente dentro de reglas ampliadas, o la escala a una persona con el contexto preparado? Esta columna es la que separa una demo de una operación.

Resultado. Qué significa que el caso terminó bien: el estado final, el registro actualizado, el documento emitido. Y cómo se comprueba. Sin un resultado definido con precisión no puedes construir la evaluación de la que depende el paso a producción, que detallo en evaluación de agentes de IA.

Ese mapa de cuatro ejes es la primera fase de convertir el modelo operativo en código, y la entrada de todo lo que viene después.

Un ejemplo hipotético: la conciliación de facturas de una distribuidora

Imagina una distribuidora de 80 M€ que recibe unas 4.000 facturas de proveedor al mes. Es un ejemplo inventado para ilustrar el mapeo, no un caso real. Lo elijo porque reúne los cinco criterios: volumen alto, reglas conocidas, excepciones agrupables, resultado medible (conciliada o no) y cercanía directa al margen.

• Entradas: facturas en PDF por correo, con calidad variable, y el pedido y el albarán correspondientes en el ERP.
• Reglas: cotejar importe, cantidades y referencias de la factura con el pedido y el albarán, conciliar y marcar para pago dentro de una tolerancia pactada, y retener fuera de tolerancia.
• Excepciones: facturas sin pedido asociado, diferencias de precio dentro de un margen negociado con ciertos proveedores, entregas parciales que se facturan completas, un proveedor que factura en otra divisa. Cada grupo tiene un motivo y una decisión: los tres primeros el agente puede resolverlos con reglas ampliadas, y el de la divisa se escala mientras no se defina la regla.
• Resultado: factura conciliada y marcada para pago, o retenida con el motivo anotado y, si procede, escalada a la persona correcta.

Mapear este proceso en serio destapa cosas antes de tocar tecnología: que la “tolerancia” no estaba escrita en ningún sitio, que dos personas la aplicaban distinto, y que el 10 % de las retenciones se debían a un único proveedor con un acuerdo especial que nadie había documentado. Ese hallazgo ya justifica el ejercicio, haya agente o no.

De la selección al mapa, y del mapa a la implantación

Elegir bien y mapear con rigor es lo que convierte una idea de automatización en algo que se puede desplegar. El mapa dice qué permisos necesita el agente, qué excepciones hay que cerrar antes de producción y qué mide la evaluación. Sin él, el salto del piloto a producción se hace a ciegas.

Antes incluso de mapear, conviene comprobar que la casa está preparada —datos accesibles y un responsable con autoridad—, que es lo que reviso en preparar tu empresa para agentes. Y el terreno completo de qué procesos operan hoy con agentes, por función, está en agentes de IA en operaciones y en el pilar sobre agentes de IA para empresas.

Preguntas frecuentes

¿Qué procesos conviene automatizar primero con IA?

Los que reúnen cinco condiciones: volumen suficiente, reglas conocidas, excepciones que se pueden tipificar, resultado medible y cercanía a ingresos, margen o servicio. Conciliación de facturas, seguimiento de pedidos, casos de soporte con patrón o back office documental suelen cumplirlas. Cuanto más medible el resultado, mejor primer candidato.

¿Cómo sé si un proceso es demasiado complejo para un agente?

Si cada caso exige criterio experto nuevo, o si nadie sabe explicar por qué se decide lo que se decide, el proceso no está listo para codificarse. Eso no siempre lo descalifica: a veces el primer trabajo es reconstruir la regla o documentar la excepción, y ese ejercicio ya aporta valor por sí mismo.

¿En qué consiste mapear un proceso para automatizarlo?

En ponerlo por escrito en cuatro ejes: las entradas que recibe (con sus formatos reales, no los ideales), las reglas que lo gobiernan, las excepciones agrupadas con su motivo, y el resultado que define que un caso terminó bien. Ese mapa es la materia prima del sistema: su calidad marca el techo de lo que el agente puede hacer.

Si mi proceso no es candidato para un agente, ¿qué hago con él?

Enrútalo según el motivo por el que ha caído. Si no tiene excepciones, RPA o automatización clásica. Si es determinista y los sistemas tienen API, una herramienta de automatización visual. Si lo que falta es que la gente encuentre información, un chatbot sobre tu base de conocimiento. Y si nadie sabe explicar la regla, el trabajo previo es reconstruirla, que es de negocio y no de tecnología.

¿Un proceso descartado hoy puede ser candidato más adelante?

Sí, y conviene distinguirlo del que no lo será nunca. Un proceso determinista sin excepciones seguirá estando mejor servido por otra herramienta por mucho que crezca. En cambio, uno descartado por falta de volumen, de reglas escritas o de una medida del resultado vuelve a la lista en cuanto se corrige eso, y suele desplegarse mejor que los que entraron a la primera. Anota la fecha del descarte y el motivo, para revisarlo con criterio y no por insistencia.

¿Cuánto se tarda en mapear un proceso?

Para un proceso candidato acotado, semanas, no meses. El tiempo se va en hacer explícitas las reglas y excepciones que hoy viven en la cabeza de dos o tres personas. Intentar mapear la empresa entera de golpe convierte un requisito sencillo en un programa anual y aplaza la primera prueba.