Diseñe el flujo de trabajo, no la característica
La mayoría de la IA empresarial fracasa porque implementa características en flujos de trabajo que no fueron diseñados para recibirlas. Así es como secuenciamos el trabajo en su lugar.
La trampa de la funcionalidad
Cuando un equipo directivo pide «una funcionalidad de IA», normalmente está describiendo un síntoma. La petición de fondo casi siempre es: haz que este proceso sea más rápido, más preciso o más aburrido. Eso son resultados de proceso, y una funcionalidad es un instrumento pobre para alcanzarlos.
Desplegar una funcionalidad sobre un proceso sin rediseñar es la forma más barata posible de parecer moderno sin cambiar nada. La demo funciona porque la demo controla sus entradas. Producción no: el documento llega como fotografía de una pantalla, los datos de referencia tienen once días y la persona que debía revisar la salida tiene noventa en cola.
El fallo rara vez es el modelo. Es que nadie describió el proceso al que el modelo se incorporaba, así que nadie se dio cuenta de que el paso que automatizó no era el paso lento.
Empieza por el traspaso, no por la tarea
Mapeamos procesos con la granularidad de un único traspaso: el momento en que el trabajo cambia de manos, de sistema o de estado. En los traspasos se acumula la latencia, se pierde el contexto y se introducen errores por reintroducción de datos. Son también, convenientemente, donde vive la evidencia: marcas de tiempo, transiciones de tickets, hilos de correo.
Cada traspaso recibe una de tres etiquetas. Conservarlo, porque ahí ocurre un juicio humano real. Automatizarlo, porque es movimiento determinista de datos que alguien hace a mano. Eliminarlo, porque existe solo para verificar el paso anterior, y la verificación sale más barata integrada en ese paso que ejecutada después.
La tercera categoría es la que importa y la que los proyectos de automatización pasan por alto sistemáticamente. Un paso de verificación es un síntoma de baja confianza aguas arriba. Automatizar la comprobación conserva la baja confianza y añade un sistema que mantener. Eliminar la causa borra ambos.
Por qué la secuencia importa más que la herramienta
Solo cuando existe el mapa de traspasos elegimos modelos, y solo después elegimos herramientas. Invertir el orden es como las organizaciones acaban con una decisión de plataforma que condiciona una arquitectura que nunca se diseñó.
La prueba práctica es si puedes enunciar, en una frase y sin nombrar a ningún proveedor, qué hará el sistema y cómo sabrás si funcionó. Si no puedes, la decisión de herramienta es prematura. Si puedes, esa decisión suele ser fácil y a menudo aburrida, que es exactamente la sensación correcta ante una infraestructura.
La selección de modelo sigue la misma disciplina. La pregunta no es qué modelo puntúa más alto en una tabla pública, sino cuál supera tu umbral de precisión dentro de tu presupuesto de latencia, dentro de tu perímetro de datos y a un coste por caso que puedas defender. Esas cuatro restricciones suelen eliminar a la mayoría de candidatos antes siquiera de hablar de calidad.
Diseñar para el día en que se equivoque
Todo proceso que incorpora un modelo necesita una respuesta a una pregunta que el pensamiento orientado a funcionalidades nunca formula: qué pasa cuando la salida es incorrecta, y cuánto tarda alguien en enterarse.
Es una decisión de diseño, no de monitorización. Si una respuesta errónea la detecta después una persona que iba a leer el documento de todos modos, el coste del error es bajo y el sistema puede ser agresivo. Si se escribe directamente en un sistema de registro que ve un cliente, el coste es alto y el diseño necesita un punto de revisión, un umbral de confianza, o ambos.
La revisión es cara y se degrada. Un revisor al que se le pide aprobar cada salida deja de leer en la segunda semana; un revisor al que se le pide aprobar el diez por ciento sobre el que el sistema tiene menos certeza se mantiene atento. Colocar la revisión donde cambia un resultado, y retirarla donde es teatro, forma parte de la arquitectura y no es un añadido operativo.
Qué aspecto tiene lo que funciona
Un proyecto bien secuenciado produce un proceso con menos pasos, no el mismo proceso con un modelo pegado. El entregable es una descripción del proceso, un conjunto de evaluación y un plan de despliegue. En ese orden.
El conjunto de evaluación es la parte que más equipos se saltan y la que hace auditable todo lo demás. Es una colección de casos reales del proceso, con el resultado correcto anotado, montada antes de construir nada. Es lo que convierte «el modelo parece mejor» en un número, y es lo único que dentro de seis meses te dirá si un cambio fue una mejora o una regresión.
Nada de esto es exótico. Es ingeniería de procesos corriente con un componente nuevo en la caja de herramientas. Si parece un diferenciador es porque el sector pasó tres años tratando el componente como si fuera el proyecto.
Dos modos de fallo a vigilar
El primero es el piloto que triunfa y nunca se amplía. Funciona porque un equipo motivado le dio de comer entradas limpias durante ocho semanas, y se atasca en cuanto se enfrenta a la cola que debía aliviar. La señal es que nadie registró cómo eran las entradas durante el piloto, así que nadie sabe explicar la caída.
El segundo es la plataforma comprada antes de entender el proceso. La herramienta condiciona el diseño, el diseño se justifica después para encajar en la licencia, y dos años más tarde la organización defiende una arquitectura que nadie eligió. La señal es un documento de requisitos escrito con el vocabulario del proveedor.
Ambos se evitan con la misma disciplina: describe el proceso, registra una línea base y acuerda la métrica de éxito antes de comprar o construir nada.
El orden, otra vez
Mapea los traspasos. Decide cuáles se conservan, se automatizan o se eliminan. Registra una línea base de la métrica que pretendes mover. Monta un conjunto de evaluación con casos reales. Después elige modelo, y solo entonces elige las herramientas de alrededor.
Cada paso de ese orden es barato de hacer y caro de saltarse, y cada uno produce un artefacto que otra persona puede comprobar. Ese es el verdadero argumento de la secuencia: no que sea más rigurosa, sino que es más auditable cuando alguien cuestiona los resultados.
Entregar empezando por la funcionalidad produce una demo y una esperanza. Empezar por el proceso produce un flujo de trabajo, un número y una forma de saber si ese número se movió.