La inteligencia artificial no arregla una empresa mal diseñada: la acelera. Un modelo de lenguaje conectado a un proceso confuso no produce claridad, produce confusión a mayor velocidad y a mayor escala. Esta es la razón por la que tantas compañías que han desplegado IA no encuentran el retorno en ninguna línea de su cuenta de resultados: no compraron una solución, compraron un multiplicador, y lo aplicaron sobre algo que no estaba listo para ser multiplicado.
No es una posición anti-IA. Es exactamente lo contrario. La IA merece aplicarse donde puede generar ventaja real, y para eso hay que dejar de tratarla como un producto que se instala y empezar a tratarla como una capacidad que se integra en un sistema que funciona.
Un proceso empresarial es una cadena de decisiones, responsables, datos y excepciones. Cuando esa cadena está bien definida, automatizarla libera capacidad. Cuando no lo está, automatizarla convierte la ambigüedad en output.
Piensa en qué ocurre exactamente cuando se conecta un asistente de IA a un proceso de aprobación de pedidos que nadie ha documentado. El modelo no sabe qué pedidos requieren doble firma, porque esa regla vive en la cabeza de una persona del departamento. No sabe qué hacer cuando el cliente tiene una incidencia abierta, porque esa condición nunca se escribió. No sabe qué es una excepción, porque las excepciones se resolvían por conversación.
El resultado no es que el sistema falle de forma visible. El resultado es peor: el sistema funciona, produce respuestas plausibles, y esas respuestas circulan por la organización con la autoridad implícita de haber salido de un sistema. El error deja de ser detectable a simple vista y pasa a ser sistemático.
Esta es la diferencia entre una herramienta y un amplificador. Una herramienta hace una tarea. Un amplificador aumenta la señal que recibe, y no distingue entre señal y ruido.
McKinsey, en su encuesta global State of AI de 2025 (1.993 participantes en 105 países), encontró que el 88% de las organizaciones usa IA de forma habitual en al menos una función de negocio. Ese titular se ha repetido en todas las presentaciones comerciales del último año.
El resto del informe se repite mucho menos. Solo el 39% reporta algún impacto en EBIT a nivel de empresa. Solo un 6% califica como *high performers*, con más de un 5% de EBIT atribuible a la IA. Y la conclusión de McKinsey es literal: el impacto significativo en la cuenta de resultados sigue siendo raro.
IBM llegó al mismo sitio por otro camino. Su CEO Study de 2025, con 2.000 directores generales de 33 países, encontró que solo el 25% de las iniciativas de IA había producido el retorno esperado, y solo el 16% se había escalado a nivel de organización.
La pregunta interesante no es por qué fallan tantas, sino qué distingue a las que funcionan. McKinsey identifica un factor que correlaciona más que ningún otro con el impacto en EBIT: haber rediseñado los flujos de trabajo de forma fundamental. Solo el 21% de las organizaciones que adoptaron IA generativa lo había hecho.
Es decir: la variable que separa a quien gana dinero de quien no, no es el modelo. Es el trabajo previo.
No significa una empresa mal gestionada ni una empresa poco rentable. Muchas compañías con procesos deficientes son rentables, porque compensan el desorden con esfuerzo humano. El problema aparece cuando se intenta automatizar ese esfuerzo.
Estos son los cuatro síntomas que encontramos con más frecuencia en un diagnóstico:
El proceso solo existe en la cabeza de alguien. Hay una persona que sabe cómo se hace realmente. Cuando esa persona está de vacaciones, el proceso se degrada. Un proceso no documentado no se puede automatizar: se puede, como mucho, imitar parcialmente.
No hay una única fuente de verdad. El dato del cliente está en el CRM, en una hoja de cálculo del comercial y en el ERP, y los tres son ligeramente distintos. La IA no resuelve esa contradicción; elige una de las tres versiones sin decírtelo.
Las excepciones no están diseñadas, se descubren. Nadie ha listado los casos raros. Se van resolviendo según aparecen. En producción, esos casos raros son entre el 15% y el 30% del volumen real, y son justamente donde la automatización se rompe.
No hay responsable del resultado, solo de la tarea. Hay alguien que aprueba, alguien que registra y alguien que factura, pero nadie responde del proceso completo. Cuando se automatiza, el hueco de responsabilidad no desaparece: se hace más grande, porque ahora hay un sistema en medio al que se le puede echar la culpa.
Ninguno de estos cuatro problemas es un problema de tecnología. Los cuatro se agravan al añadir tecnología.
La secuencia importa más que las herramientas. Este es el contraste entre las dos formas de abordarlo:
Enfoque | Empezar por la IA | Empezar por el proceso |
Primer paso | Elegir modelo o proveedor | Mapear decisiones, datos y excepciones |
Métrica inicial | Número de usuarios, consultas, demos | Tiempo de ciclo, tasa de error, coste por caso |
Dónde aparece el problema | En producción, a los tres meses | En la fase de diagnóstico, sobre papel |
Coste de corregir | Alto: hay que rehacer integraciones | Bajo: se corrige un diagrama |
Qué queda al final | Una herramienta que nadie usa | Un proceso mejor, con o sin IA |
La columna de la derecha tiene una propiedad que la de la izquierda no tiene: produce valor aunque la IA se descarte. Si al terminar el análisis se concluye que el caso no justifica un modelo, la empresa se queda igualmente con un proceso mapeado, con las excepciones identificadas y con los cuellos de botella localizados. Ese trabajo no se pierde nunca.
En The Cloud Group esa secuencia está formalizada en nuestra metodología TCG-SAF™: primero se define la visión del ecosistema, después se mapean los dominios funcionales, después se estructuran los módulos con sus contratos, y solo entonces se entra en ingeniería. Cuando el análisis de procesos precede al desarrollo, el debate sobre qué modelo usar se convierte en lo que debería ser: una decisión técnica reversible, no la decisión estratégica del proyecto.
Este mismo principio es el que aplicamos en nuestros servicios de rediseño de procesos y consultoría tecnológica [enlace interno], donde el mapa de procesos y la identificación de cuellos de botella preceden siempre a cualquier recomendación de automatización.
Sería deshonesto sostener que nunca hay que empezar por ahí. Hay tres situaciones en las que arrancar directamente con un modelo es la decisión correcta:
Cuando el proceso ya está limpio y el cuello de botella es el volumen. Si la clasificación de tickets está bien definida, con criterios explícitos y datos consistentes, y el problema es que llegan diez mil al mes, no hace falta rediseñar nada. Hace falta capacidad.
Cuando el objetivo declarado es aprender, no producir. Un experimento acotado, con presupuesto cerrado y criterio de parada, es una inversión razonable en capacidad organizativa. El error no es experimentar: es llamar «proyecto» a un experimento y esperar retorno de él.
Cuando el caso de uso vive en el lenguaje. Resumir documentación, extraer información de contratos, analizar sentimiento en conversaciones de soporte. Son problemas que el software clásico resuelve mal por naturaleza, y donde el modelo aporta una capacidad que antes no existía.
Fuera de esos tres escenarios, empezar por el modelo es empezar por el final.
La conversación en los comités de dirección suele plantearse como «¿dónde metemos IA?». Es una pregunta que garantiza una respuesta mediocre, porque parte de la solución y busca el problema.
La versión útil de esa pregunta tiene tres partes:
Una empresa que responde honestamente a esas tres preguntas descubre, casi siempre, que su primer proyecto de IA no es un proyecto de IA. Es un proyecto de claridad operativa que, más adelante, incorporará modelos donde aporten ventaja.
Esa es la diferencia entre una empresa que gasta en IA y una empresa que gana con ella.
No. La IA amplifica el proceso al que se conecta: si el proceso tiene reglas ambiguas, datos contradictorios o excepciones no documentadas, la automatización reproduce esos defectos a mayor velocidad y escala. El rediseño del proceso debe preceder a la automatización, no seguirla.
Cuatro cosas: documentar las decisiones y quién las toma, establecer una única fuente de verdad para los datos implicados, listar y diseñar las excepciones, y asignar un responsable del resultado completo del proceso, no solo de tareas sueltas.
Según el CEO Study de IBM de 2025, solo el 25% de las iniciativas de IA ha dado el retorno esperado y solo el 16% se ha escalado. McKinsey identifica el rediseño profundo de los flujos de trabajo como el factor que más correlaciona con el impacto en EBIT, y solo el 21% de las organizaciones lo había hecho.
Depende del alcance, pero un diagnóstico de un proceso concreto —mapa de decisiones, datos, excepciones y responsables— suele resolverse en semanas, no en meses. Es un plazo mucho menor que el de corregir una automatización mal planteada una vez está en producción.
Cuando el proceso ya está definido y el problema es de volumen, cuando el objetivo declarado es aprender mediante un experimento acotado con criterio de parada, o cuando el caso de uso vive en el lenguaje natural (resumen documental, extracción de información, análisis de sentimiento).
Digitalizar es trasladar el proceso actual a una herramienta. Rediseñar es cuestionar el proceso antes de trasladarlo. Digitalizar un proceso ineficiente produce un proceso ineficiente más rápido; rediseñarlo produce un cambio en el resultado del negocio.
¿Quieres saber si tu proceso está listo para automatizarse? En The Cloud Group empezamos por un diagnóstico, no por una propuesta técnica. Analizamos tu caso concreto en dos horas de consultoría sin compromiso y te decimos qué merece rediseñarse y qué merece automatizarse — aunque la respuesta sea que todavía no toca. Hablemos → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
