Cómo elegir qué proceso automatizar primero con IA

Se elige por tres condiciones que tienen que darse a la vez: el proceso se repite lo suficiente, alguien ya revisa su resultado, y ese resultado se puede juzgar. Falta una de las tres y el proyecto no se puede mejorar ni cancelar con argumentos. El caso más vistoso casi nunca las cumple.

Puntos clave

• Repetición, revisión previa y resultado juzgable. Las tres a la vez o no es un buen primer caso.
• Antes de elegir hay que enmarcar: quién usa el proceso, qué decide, qué pasa si falla. Sin ese contexto no hay forma de comparar candidatos.
• Un proceso sin documentar no es candidato: es otro proyecto anterior.
• El primer caso no se elige por impacto máximo, se elige por capacidad de aprender rápido y barato.

¿Por qué el primer caso decide los siguientes?

Porque nadie aprueba un segundo proyecto de IA después de que el primero no se pudo evaluar.

No hace falta que fracase. Basta con que termine sin que nadie sepa decir si funcionó, que es el desenlace más común. Se monta algo, se usa unas semanas, la gente opina distinto, no hay un número que zanje la discusión y el tema se desvanece. Después de eso, conseguir presupuesto para el siguiente cuesta el triple.

Así que la pregunta al elegir no es cuál es el proceso más valioso. Es cuál te va a permitir salir con una respuesta clara en ocho semanas. Con esa respuesta en la mano, el segundo caso ya se elige por valor.

¿Cómo se enmarca un candidato antes de compararlo?

Escribiendo cuatro cosas por proceso, antes de comparar nada.

El marco de gestión de riesgo de IA que publica el NIST, un organismo público estadounidense, llama a este paso map, y lo define así: «The map function establishes the context to frame risks related to an AI system». Establecer el contexto antes de evaluar el riesgo. Suena burocrático hasta que ves lo que pasa sin hacerlo: se comparan procesos que nadie describió, con criterios que cada quien entiende distinto.

Las cuatro cosas que escribo por candidato caben en media página:

1. Quién lo ejecuta hoy y cuánto tiempo le lleva. Con nombre y con horas reales, no estimadas por su jefe.
2. Qué decide o desencadena el resultado. Si el resultado no decide nada, automatizarlo no cambia nada.
3. Qué pasa si sale mal una vez. Un correo raro es distinto de una factura equivocada, y muy distinto de un diagnóstico.
4. Cómo se ve un buen resultado. Si nadie puede describirlo, tampoco vas a poder medirlo después.

Es voluntario y estadounidense, así que no obliga a nada en México. Pero la estructura sirve, y es mejor que inventarse una.

¿Cuál es el filtro que descarta?

Las tres condiciones del principio, aplicadas sin piedad.

Se repite lo suficiente. Decenas de veces al mes como mínimo. Por debajo de eso, el esfuerzo de montarlo y mantenerlo no se recupera nunca, por bien que funcione. Y va a haber mantenimiento: cambia el modelo, cambia el proceso, cambia el formato de entrada.

Alguien ya revisa la salida. Si el resultado pasa por ojos humanos antes de tener consecuencias, el error es barato y corregible. Ese colchón es lo que te permite aprender en producción sin romper nada. Automatizar un paso que hoy nadie revisa significa que el primer error lo va a descubrir un cliente.

El resultado se puede juzgar. Alguien tiene que poder mirar dos salidas y decir cuál está mejor. Esta es la que más se salta y la que más caro sale, porque un proyecto sin criterio de calidad no se puede mejorar ni cancelar: solo se puede defender con anécdotas.

Este filtro y los tipos de proceso que conviene dejar en paz los desarrollamos en la guía de decisión de dónde entra la IA en tu operación y dónde no.

¿Por qué el caso vistoso es mala idea?

Porque casi siempre falla la tercera condición, y a veces la segunda.

El caso vistoso suele ser algo de cara al cliente: el chat que contesta todo, el correo que se escribe solo, la propuesta que se genera sin intervención. Son buenos ejemplos para una presentación y malos primeros proyectos, porque el error es caro, nadie lo revisa antes de que salga y la calidad se discute por gusto.

El caso aburrido es el contrario en todo. Clasificar y enrutar lo que entra. Sacar cuatro datos de un documento y ponerlos donde van. Resumir una conversación larga para quien la tiene que retomar. Nadie va a aplaudir en una junta, y son justo los que dejan un número al final de ocho semanas.

Hay una excepción real: cuando el proceso vistoso es tu diferenciador y llevas años sabiendo exactamente cómo se hace bien. Ahí la tercera condición sí se cumple, porque alguien en la empresa puede juzgar el resultado con autoridad.

¿Qué hago si el proceso no está documentado?

Ese es el proyecto. La IA viene después.

Automatizar algo que nadie sabe explicar lo vuelve más rápido y más difícil de arreglar. Si hoy el proceso funciona porque Ana sabe a quién llamar y en qué orden, lo primero es escribir lo que Ana sabe. No como manual de cien páginas: como la secuencia de pasos, las decisiones que se toman en cada uno y qué hace que un caso se salga del carril.

Ese ejercicio tiene una ventaja que casi nadie anticipa. La mitad de las veces, al escribirlo, aparece que el proceso tiene tres pasos que no hacen falta. Quitar esos tres pasos es más barato que automatizarlos y da resultado la misma semana.

Y si al terminar de escribirlo el proceso sigue teniendo sentido, ahora sí es candidato, y además ya tienes la descripción que el marco pedía en el paso de enmarcar.

Cómo se ve una buena elección

Un proceso que dos personas pueden describir igual, que ocurre muchas veces al mes, cuyo error lo atrapa alguien antes de que salga, y sobre el que existe una persona capaz de decir «esta respuesta está bien y esta no» sin dudar.

Con eso se puede diseñar un piloto que termine en una respuesta y no en una discusión. Y con esa respuesta, sea la que sea, se decide el segundo.

Si quieres que revisemos qué procesos de tu operación cumplen las tres condiciones, el diagnóstico inicial no tiene costo. También puedes ver cómo trabajamos la transformación con IA.

Preguntas frecuentes

¿Cuál es el mejor primer caso de uso de IA? Uno aburrido, repetitivo y cuyo resultado alguien ya revisa de todas formas. Esas tres condiciones juntas hacen que el error sea barato, el volumen justifique el esfuerzo y la calidad se pueda juzgar desde el primer día. El caso vistoso es casi siempre el peor primero.

¿Cuánta gente necesito para arrancar? Dos personas con nombre: quien conoce el proceso por dentro y quien puede decidir que se detenga. La primera define cómo se ve un buen resultado y la segunda evita que el piloto se arrastre seis meses sin que nadie quiera cancelarlo.

¿Y si mi proceso no está documentado? Entonces ese es el proyecto, y no la IA. Automatizar algo que nadie sabe explicar lo vuelve más rápido y más difícil de arreglar. Si el proceso depende de que alguien recuerde a quién llamar, primero se escribe lo que esa persona sabe.

¿Conviene empezar por algo pequeño o por algo importante? Pequeño dentro de algo importante. Un caso irrelevante no consigue atención cuando se complica, y uno crítico no perdona el primer error. La combinación que funciona es un pedazo acotado de un proceso que a alguien le importa de verdad.