Automatizar sin rediseñar es la forma más cara de preservar el pasado
Hay una secuencia de decisiones que se repite con sorprendente consistencia en empresas grandes con presupuestos de transformación digital cuantiosos: identifican un proceso que les genera fricciones, contratan tecnología de automatización, despliegan la herramienta sobre el flujo existente y reportan avances. Los tableros ejecutivos muestran velocidad. Las presentaciones de comité hablan de eficiencia. Y seis meses después, los mismos problemas reaparecen, ahora empaquetados en un sistema más difícil de desmontar.
No es un fenómeno anecdótico. McKinsey reporta que el 88% de las organizaciones utiliza inteligencia artificial en al menos una función de negocio, pero solo el 39% atribuye impacto en su margen operativo. La diferencia entre ambos grupos no reside en el proveedor elegido ni en el presupuesto asignado. Reside, casi invariablemente, en si la organización rediseñó sus flujos de trabajo antes de introducir la automatización o simplemente los cubrió con una capa de tecnología.
La magnitud de ese gap merece ser leída con detenimiento. No estamos ante un problema de adopción tecnológica. Estamos ante un problema de diseño organizacional que la tecnología está haciendo visible a mayor escala y a mayor costo.
Cuando la automatización convierte el error en velocidad
La automatización tradicional, basada en reglas definidas y flujos estrechos, ya tenía esta fragilidad. Si un proceso contenía excepciones no documentadas, pasos que dependían del criterio tácito de ciertos empleados o datos incompletos que alguien corregía manualmente antes de que el sistema los viera, la automatización de ese proceso producía resultados inconsistentes. Pero los volúmenes eran acotados y el daño era manejable.
La IA agéntica opera de forma distinta. Interpreta objetivos, genera recomendaciones, activa flujos y toma decisiones en múltiples sistemas a la vez. Eso la hace más potente en contextos bien diseñados y significativamente más dañina en contextos mal diseñados. Un agente desplegado sobre un proceso con lógica de decisión ambigua no detecta la ambigüedad: la ejecuta con consistencia y volumen. Lo que antes un analista senior resolvía con juicio, escalación e intuición institucional, ahora se convierte en un patrón automatizado de error que circula por el sistema antes de que nadie lo note.
El caso documentado de una aseguradora Fortune 500 ilustra el mecanismo con precisión. La compañía tenía procedimientos operativos documentados y una base de automatización madura. Sin embargo, el procesamiento directo de casos había caído de forma pronunciada. El diagnóstico reveló que la automatización había sido desplegada sobre flujos cargados de excepciones. El resultado era un sistema frágil y costoso. La solución no fue más tecnología: fueron expertos del negocio que rediseñaron el flujo, eliminaron cuellos de botella y asignaron responsabilidades claras a líderes concretos. Después de eso, el desempeño mejoró de forma sostenida.
El patrón que revela ese caso no es técnico. Es de diseño organizacional. La automatización amplificó la estructura previa, con sus defectos incluidos. Lo que faltaba no era un mejor modelo de IA, sino un proceso que mereciera ser automatizado.
La trampa que no aparece en los informes de avance
Hay una dinámica que rara vez llega a los informes ejecutivos de proyectos de transformación: las organizaciones tienden a confundir actividad con fundamento. Cuando se despliega automatización, hay métricas que mejoran de inmediato, al menos superficialmente: velocidad de procesamiento, reducción de intervenciones manuales visibles, tiempo de ciclo aparente. Esos indicadores alimentan las presentaciones trimestrales y refuerzan la percepción de avance.
Lo que no aparece en esos reportes es el costo de los trabajos no documentados que desaparecieron con la automatización. No el trabajo manual que el sistema reemplazó, sino el trabajo invisible de corrección, validación informal y juicio situacional que los empleados hacían para compensar las deficiencias del proceso. Cuando la automatización elimina ese trabajo humano sin haber resuelto primero las deficiencias que lo hacían necesario, esas deficiencias siguen presentes en el sistema, solo que ahora sin amortiguación.
BCG nombra este error con claridad: la tentación frecuente es automatizar lo que ya existe. El valor proviene de partir desde el resultado deseado y reinventar cómo entregarlo. Esa distinción no es semántica. Tiene consecuencias estructurales. Una organización que parte del resultado tiene que preguntarse qué flujo de decisiones, datos y responsabilidades se necesitan para producirlo de forma sostenida. Una organización que parte del proceso existente solo está convirtiendo en código lo que ya ocurría, con sus ineficiencias integradas.
El costo de esa diferencia escala. Desmontar automatización mal diseñada requiere reingeniería de sistemas, reentrenamiento de modelos, revisión de gobernanza y, en muchos casos, gestión del daño que el sistema produjo durante el tiempo en que operó. El gasto no es solo financiero: incluye confianza perdida en los equipos que dependían del proceso y en los clientes que lo experimentaron.
Los cinco movimientos que separan la corrección de la escalada del daño
Para las organizaciones que ya desplegaron automatización sobre procesos con fundamentos débiles, pausar no es suficiente. Parar el despliegue limita el daño incremental, pero no corrige la fuente. Las cinco acciones que marcan la diferencia entre corrección real y parche temporal apuntan todas al mismo núcleo: hacer visible el proceso antes de intentar gobernarlo con tecnología.
El primer movimiento es identificar los flujos de mayor riesgo y detener su expansión. No todos los procesos mal diseñados tienen el mismo perfil de daño. Los que combinan alta frecuencia, decisiones difíciles de revertir y exposición regulatoria o financiera son el lugar donde el costo de la demora es mayor. Esos necesitan atención prioritaria, no análisis adicional.
El segundo movimiento es mapear el proceso que realmente existe, no el que está documentado. En la mayoría de las organizaciones, el proceso documentado y el proceso operado divergen de formas que los equipos de TI o de automatización no ven desde sus posiciones. Las excepciones, los workarounds y las intervenciones informales que mantuvieron el flujo en marcha no están en los diagramas. Están en la práctica cotidiana de las personas que los ejecutan. Hacerlos visibles no es un ejercicio de auditoría: es un requisito previo para cualquier rediseño que vaya a funcionar.
El tercer movimiento es asignar responsabilidad sobre el proceso, no sobre la herramienta. Cuando la rendición de cuentas está fragmentada entre el equipo de tecnología, el equipo de operaciones y el área de negocio, el proceso no tiene dueño. Tiene custodios parciales que optimizan su parte sin responsabilizarse del resultado total. La IA agéntica corta horizontalmente múltiples funciones, decisiones y datos. Sin un líder responsable de ese resultado de punta a punta, la automatización mejora tareas aisladas mientras el indicador de negocio permanece estancado o deteriorado.
El cuarto movimiento es reconstruir la validación humana en los puntos donde el error es costoso. Esto no significa frenar la automatización indefinidamente ni recuperar pasos manuales que no agregan valor. Significa identificar los nodos de decisión donde una salida incorrecta tiene consecuencias materiales difíciles de revertir y mantener supervisión activa en esos puntos mientras el proceso se estabiliza. La autonomía de los agentes debe ganarse progresivamente, no asumirse desde el inicio.
El quinto movimiento es cambiar las métricas de éxito. Velocidad de ciclo y reducción de intervenciones manuales son indicadores de actividad, no de resultado. Las organizaciones que logran correcciones sostenidas monitorean calidad de decisión, costo de recuperación de errores, solidez de cumplimiento normativo e impacto sobre la experiencia del cliente. Esos indicadores no mejoran con más automatización sobre procesos débiles. Mejoran cuando el proceso subyacente es sólido.
El momento de la crisis ya ocurrió antes de que llegara la IA
Hay una lectura del problema que merece no perderse de vista: cuando la automatización de IA produce resultados deficientes, la crisis que se manifiesta en ese momento no fue creada por la IA. Fue creada antes, en el momento en que la organización optó por no invertir en el diseño de sus procesos. La IA solo hizo visible, a mayor escala y con mayor urgencia, una fragilidad estructural que ya existía.
Eso cambia la naturaleza del diagnóstico. No estamos ante un problema de adopción tecnológica que se resuelve con más inversión en herramientas, mejor gestión del cambio o más capacitación técnica. Estamos ante organizaciones que utilizaron la promesa de la automatización para diferir una decisión de diseño que en algún momento se volvió incómoda o costosa de tomar.
El caso de la empresa tecnológica con proyecciones de ingresos erróneas es revelador en ese sentido. Los flujos de trabajo de proyección involucraban múltiples transferencias de responsabilidad y actualizaciones asincrónicas que producían pronósticos incorrectos. Esas proyecciones distorsionaban decisiones de contratación, planificación y márgenes. La solución no fue un modelo de forecasting más sofisticado. Fue un proceso rediseñado con puntos de control claros y responsabilidad asignada a líderes interfuncionales. Una vez que el fundamento se corrigió, la automatización que había amplificado el problema comenzó a cerrar la brecha.
La lección no es que la IA no funciona. La lección es que la IA funciona exactamente como está diseñado el proceso que la rodea. Las organizaciones que escalan con confianza son aquellas que tratan la claridad del proceso como un activo estratégico antes de tratarlo como un destino para la tecnología.
Una organización que automatiza lo que ya tiene mal diseñado no está acelerando su transformación. Está acelerando su distancia respecto del punto desde el que eventualmente tendrá que partir de nuevo.
