La pregunta con la que casi siempre arranca un proyecto de IA no es técnica: es «¿por dónde empezamos?». Y la respuesta suele venir de la presión del día a día. Se automatiza el proceso que más ruido hace, el que queja el área más vocal, o el que el vendor mostró en la demo. El resultado es previsible: el primer proyecto se come el presupuesto, la confianza y el entusiasmo del equipo, y la organización concluye que "la IA no funcionó" cuando lo que falló fue la selección.

Elegir el primer proceso a automatizar es una decisión de operaciones, no una decisión de herramientas. Se puede tomar con criterio y con evidencia. Este artículo describe un método práctico para hacerlo.

Primero: distinguir qué tipo de proceso estamos mirando

No todos los procesos candidatos piden la misma tecnología, y mezclarlas es una de las causas más comunes de frustración temprana. Deloitte, en su encuesta de automatización inteligente a 479 ejecutivos de 35 países, separa con claridad: la automatización robótica de procesos (RPA) ejecuta procesos basados en reglas que pueden codificarse, mientras que la IA procesa datos no estructurados y automatiza tareas que hasta ahora requerían criterio o conocimiento tácito. La confusión entre ambas lleva a intentar "poner IA" sobre procesos que solo necesitaban reglas claras, o a programar robots frágiles sobre procesos que cambian todas las semanas.

Antes de priorizar, conviene poder describir el proceso con una frase: qué entra, qué sale, quién decide y bajo qué criterio. Si esa frase cambia según a quién le preguntes, el proceso todavía no está listo para ser automatizado, con ninguna tecnología.

El proceso que conviene automatizar primero no es el proceso real que crees tener

Los procesos rara vez funcionan como dicen los diagramas oficiales. IBM describe el process mining como el uso de algoritmos sobre los registros de eventos de los sistemas (ERP, CRM) para reconstruir cómo ocurre el proceso de verdad, detectar cuellos de botella y variaciones, y tres tipos de trabajo sobre ese modelo: descubrimiento (reconstruir el proceso real), verificación (comparar el proceso deseado con el que ocurre) y mejora (optimizarlo). Celonis suma el punto de gestión: la visión objetiva de cómo corren los procesos permite cuantificar el impacto de una mejora antes y después, y priorizar iniciativas transformacionales direccionando energía y recursos a las áreas de mayor impacto.

La consecuencia práctica es incómoda pero útil: el mejor primer candidato suele ser el proceso del que existen datos de ejecución, no el que más ilusión hace. Un proceso con registros de eventos permite medir una línea base, elegir un alcance acotado y demostrar después si funcionó. Un proceso que vive en reuniones y correos no da ni el antes ni el después.

Siete criterios para elegir el primer candidato

Cuando hay una lista de procesos posibles (cobranzas, conciliaciones, ingreso de pedidos, soporte de primer nivel, control de stock, alta de proveedores), estos criterios ordenan la decisión:

Volumen y repetitividad. El proceso se ejecuta muchas veces por semana y con poca variación en su estructura. Lo que ocurre dos veces por mes no va a pagar un proyecto.
Reglas expresables. Alguien del equipo puede escribir, con bastantes ejemplos, qué es correcto y qué no. Si el criterio es "depende", hay que explicitarlo antes de automatizarlo.
Tasa de exceiones manejable. Si más de una parte importante de los casos necesita una decisión no prevista, la automatización va a pasar la mayor parte del tiempo derivando trabajo, no reduciéndolo.
Error de costo acotado. Equivocarse debe ser detectable y reversible. Un error barato y visible se puede automatizar con revisión humana; un error caro o silencioso no es candidato inicial.
Datos disponibles y confiables. La información que el proceso necesita existe, está accesible y no depende de que alguien la copie a mano entre planillas.
Dueño del proceso identificado. Hay una persona responsable de definir criterios, aprobar excepciones y responder por el resultado. Sin dueño, no hay quién decida cuando el sistema se equivoque.
Se puede medir hoy. Existe al menos una métrica de línea base: tiempo de ciclo, cantidad de pasos manuales, retrabajo, errores o demora. Sin línea base, no hay forma de saber si el proyecto sirvió.

Cuatro señales de que todavía no toca automatizar

Hay procesos que se ven listos y no lo están. Cuatro señales para frenar:

Nadie lo describe igual dos veces. Significa que el proceso real no está entendido, y que automatizarlo sería congelar una de varias versiones posibles.
El criterio vive en la cabeza de una persona. Ese conocimiento hay que hacerlo explícito primero. La IA no adivina criterio: lo expone, y si no existe, lo sustituye por una respuesta genérica.
El costo del error es alto y no hay revisión posible. Decisiones con efecto financiero, legal o sobre clientes requieren un humano en el circuito, especialmente al arrancar.
No se puede medir el antes. Si no hay línea base, el proyecto no va a poder demostrar nada, y la discusión sobre continuar se va a resolver por percepción.

Estas señales no son motivos para no automatizar nunca. Son motivos para ordenar el proceso antes: documentar, medir, definir criterios y recién entonces volver a evaluarlo.

Una secuencia de arranque que no depende de la suerte

Un primer proyecto bien planteado se ve así:

Reconstruir el proceso real a partir de datos y observación, no del diagrama ideal. Aunque no haya process mining formal, alcanza con reunir los últimos casos reales y trazar qué pasó de hecho.
Fijar la línea base: tiempo por caso, cantidad de intervenciones manuales, errores, excepciones y demora. Sin número inicial, no hay resultado que discutir.
Elegir un alcance acotado: un escenario, un área, un tipo de caso. El primer proceso se automatiza en una esquina, no de punta a punta.
Definir el circuito de decisión: qué puede resolver el sistema solo, con qué evidencia, qué deriva a una persona, con qué contexto y cómo queda registrado. Este punto es donde se decide si la automatización escala criterio o esconde ambigüedad.
Revisar contra una línea base a las pocas semanas: se mantiene, se amplía o se frena, con datos.

El perfil de IA generativa del NIST (AI 600-1) insiste en incorporar consideraciones de confiabilidad y riesgo durante el diseño, desarrollo, uso y evaluación de los sistemas de IA. Aplicado a un primer proyecto, eso significa que el umbral de autonomía, el nivel de revisión y la forma de evaluación se definen antes de arrancar, no después del primer error.

El primer proceso es una decisión pedagógica

Elegir el primer proceso a automatizar no es solo elegir dónde capturar valor. Es decidir con qué criterios va a aprender la organización a automatizar. Un candidato con volumen, reglas expresables, excepciones manejables, error reversible, datos disponibles, dueño definido y métrica de línea base va a entregar algo más importante que ahorro: va a crear el hábito de medir, acotar y revisar.

Por eso la pregunta no es "cuál proceso duele más". Es "cuál proceso nos va a enseñar a automatizar bien". El resto de los candidatos va a esperar, y va a esperar mejor.

Fuentes

Deloitte - Automation with intelligence: encuesta a 479 ejecutivos de 35 países; definiciones de RPA, IA, process mining, task mining y automatización de punta a punta.
IBM - What is process mining?: reconstrucción del proceso real desde registros de eventos; tipos descubrimiento, verificación y mejora; detección de cuellos de botella.
Celonis - What is process mining?: visión objetiva de los procesos, cuantificación de impacto antes/después y priorización de iniciativas transformacionales.
NIST AI 600-1 - AI Risk Management Framework: Generative AI Profile: gestión de riesgos y confiabilidad durante diseño, uso y evaluación de sistemas de IA.