Hay una pregunta que se hizo hace poco en un debate entre directivos de transformación y que nadie pudo contestar. La pregunta era esta: ¿ha visto alguna vez un programa de transformación plenamente aprobado, financiado y patrocinado que se parase porque su propósito o su valor esperado hubieran dejado de estar claros? Hubo respuestas sobre alcances que cambiaron, programas que se retrasaron y enfoques que se reconsideraron. Nadie recordaba una parada.
Conviene detenerse en lo que esa ausencia significa, porque es más grave de lo que parece. No es que las empresas sean incapaces de cancelar: cancelan continuamente iniciativas pequeñas, pilotos y pruebas de concepto. Lo que no ocurre casi nunca es que se detenga algo que ya tiene presupuesto aprobado, un patrocinador de primer nivel y una estructura de entrega montada. Una vez que existen esas tres cosas, la inercia organizativa juega entera a favor de continuar, con independencia de si el valor sigue ahí. Y si no existe el mecanismo que distingue una transformación que todavía merece la pena de otra que ya no, entonces lo que la empresa tiene no es una cartera: es una lista de cosas empezadas.
El resultado de eso se reconoce enseguida en cualquier empresa grande. Imagine una compañía que en ocho años ha hecho cinco transformaciones: un canal digital nuevo, una migración a la nube, un sistema de atención al cliente, un programa de automatización de procesos y, ahora, agentes de inteligencia artificial. Las cinco se cerraron. Las cinco pasaron su comité de cierre con los objetivos cumplidos y el acta firmada. Y sin embargo, cualquiera que trabaje allí dirá que hoy cuesta más hacer las cosas que hace ocho años: hay más sistemas que consultar, más excepciones que recordar, más gente a la que preguntar y más pasos para aprobar lo mismo. Todos los proyectos salieron bien y el conjunto funciona peor.
Esa es la observación que ordena todo lo que viene después, y conviene decirla sin rodeos: una empresa puede volverse cada vez más competente ejecutando transformaciones y, al mismo tiempo, cada vez menos eficiente operando el conjunto que esas transformaciones dejan detrás. No es una paradoja ni un juego de palabras. Es la consecuencia aritmética de medir cada proyecto por lo que entrega y a ninguno por lo que retira.
Este artículo trata de hacia dónde va la gestión de la transformación en los próximos tres años, y lo hace en tres movimientos. El primero es el diagnóstico: por qué casi todas las tendencias que vienen son consecuencia del mismo desajuste de fondo. El segundo es el inventario de esas tendencias, separando con cuidado lo que ya está ocurriendo y se puede medir de lo que todavía es promesa de fabricante. Y el tercero es el que más le va a servir: qué prácticas de gestión han dejado de tener sentido, cuáles sobreviven y qué se hace distinto el lunes. La pregunta que recorre el artículo entero no es qué debe permanecer mientras todo cambia, sino qué debería desaparecer con cada transformación para que la siguiente no tenga que cargar con todo lo anterior.
Nadie sabe cuántas transformaciones fracasan, y eso es el dato
Antes de hablar de tendencias hay que limpiar el suelo, porque la conversación sobre transformación empresarial arrastra una cifra que lo contamina todo. La afirmación de que el setenta por ciento de las transformaciones fracasa no tiene detrás ninguna medición que la sostenga. Es un dato que circula desde hace dos décadas, que se cita sin fuente y que cuando se rastrea hasta su origen se disuelve: las fuentes más citadas no aportan evidencia. Lo relevante no es que la cifra sea falsa, sino lo que ocupa su lugar cuando se retira.
Lo que hay en su lugar es un reparto mucho más interesante, publicado por una consultora que, excepcionalmente, declaró su método. En su análisis de setenta transformaciones propias más una encuesta a ochocientos veinticinco directivos, el resultado se divide en tres zonas: el treinta por ciento alcanzó o superó el valor objetivo y creó un cambio sostenible, el cuarenta y cuatro por ciento creó valor pero no alcanzó sus objetivos, y el veintiséis por ciento creó un valor limitado, por debajo de la mitad de lo prometido. El famoso setenta por ciento se obtiene sumando las dos últimas zonas, es decir, contando como fracaso todo lo que no cumplió el plan original. Con ese criterio fracasa casi cualquier cosa que hace una empresa, incluida la construcción de su sede y el lanzamiento de sus productos.
El contraste se vuelve incómodo cuando se pregunta a quienes ejecutan los proyectos en lugar de a quienes los venden. En la encuesta anual del Project Management Institute, con un análisis sobre dos mil doscientos cincuenta y cuatro profesionales de proyecto, la tasa de fracaso que esos profesionales declaran sobre sus propios proyectos está entre el ocho y el once por ciento, y el cumplimiento de objetivos de negocio ronda el ochenta por ciento. Tres cifras sobre el mismo fenómeno —el setenta por ciento del consultor, el ocho al once por ciento del jefe de proyecto y el reparto treinta-cuarenta y cuatro-veintiséis— no pueden ser ciertas a la vez, y las tres están autoinformadas por alguien con un incentivo distinto. El consultor que vende transformación necesita que la tasa de fracaso sea alta; el profesional que responde una encuesta de su asociación necesita que sea baja; el director de un programa en curso necesita que vaya bien.
De modo que la pregunta útil no es cuántas transformaciones fracasan, sino por qué la promesa inicial es sistemáticamente más alta que el resultado. Y ahí sí hay una medida que vale la pena llevarse, porque no clasifica en éxito o fracaso sino que cuantifica la brecha: entre las grandes empresas con una transformación digital o de inteligencia artificial en marcha, se ha capturado de media alrededor del treinta por ciento del aumento de ingresos esperado y la cuarta parte del ahorro de costes esperado. Esa cifra admite dos lecturas que conviene tener las dos en la cabeza: puede ser que la ejecución sea mala, o puede ser que la expectativa con la que se aprobó fuera el triple de lo razonable. La segunda es la más interesante, porque apunta a un problema en el momento de la aprobación y no en el de la entrega.
Hay un último dato de esa misma literatura que conviene retener, porque es el único que aparece en una investigación revisada por pares y con datos parcialmente objetivos. Un estudio sobre ciento cincuenta y cuatro organizaciones publicado en 2024 en el European Journal of Information Systems encuentra que lo que predice el éxito de una transformación no es la capacidad técnica por sí sola, ni la orientación al mercado por sí sola, sino la combinación de tres: leer el mercado, conectar lo externo con lo interno y ejecutar técnicamente. Lo que distingue a quien lo consigue no es ninguna de las tres capacidades, es el puente entre ellas. Y un puente, por definición, no es un proyecto: es algo que tiene que seguir existiendo cuando el proyecto acabe.
El desajuste de fondo: se introduce cambio más deprisa de lo que se absorbe
Casi todas las tendencias de gestión que vienen son consecuencia de un solo hecho, y merece la pena enunciarlo con precisión antes de desplegarlo. El ciclo con el que una empresa introduce cambio se ha hecho más corto que el ciclo con el que lo absorbe, y la diferencia entre los dos se acumula. Absorber un cambio no es implantarlo: es que la gente trabaje de otra manera de forma estable, que los procesos antiguos se retiren, que las excepciones que se crearon para la transición se cierren y que el conocimiento de por qué se hizo así quede en algún sitio distinto de la cabeza de quien lo decidió.
Hay una medida de exposición que da la escala del problema y que, a diferencia de casi todo lo demás en este terreno, cuenta algo objetivo en lugar de preguntar una opinión. Según la investigación de Gartner publicada por sus propios investigadores en Harvard Business Review en mayo de 2023, el empleado medio atravesó diez cambios empresariales planificados en 2022, frente a dos en 2016: una reestructuración para ganar eficiencia, una transformación cultural, la sustitución de un sistema heredado. Cinco veces más en seis años. No es una encuesta de actitud sobre si a la gente le gusta el cambio, es un recuento de cuántas iniciativas le pasan por encima.
La consecuencia que casi nadie saca de ahí es la que da sentido a este artículo. Si la capacidad de absorción es finita —y lo es, porque la atención directiva y la paciencia de los equipos son recursos como cualquier otro—, entonces cada iniciativa nueva debería obligar a retirar otra, igual que un presupuesto cerrado obliga a elegir. El motivo por el que se acumulan diez cambios simultáneos no es que nadie sepa que son demasiados. Es que nadie tiene ni la autoridad ni el incentivo para cancelar los otros nueve. La fatiga del cambio no es un problema de comunicación ni de resiliencia de los empleados: es el síntoma visible de una cartera sin mecanismo de cierre.
Y aquí hay que hacer un matiz que recorre el artículo entero y que lo separa de la literatura habitual sobre inteligencia artificial. La IA no crea este problema: retira el colchón que lo escondía. Un directivo lo formuló bien en el debate del que parte este artículo: la inteligencia artificial es otra tecnología, aunque con esteroides, y lo que está haciendo es sacar a la luz problemas organizativos que siempre estuvieron ahí. Es, por cierto, lo que ocurrió con las grandes disrupciones anteriores, donde el retraso nunca estuvo en la tecnología sino en lo que había que cambiar alrededor de ella. Cuando el ritmo de cambio era más lento, una empresa podía permitirse cierto desorden porque tenía tiempo de rodear los problemas antes de la siguiente ola. Ese tiempo es lo que ha desaparecido. Las consecuencias de las decisiones llegan mucho antes, y lo que antes se absorbía entre dos olas ahora se encuentra con la siguiente a medio digerir.
Eso tiene una implicación práctica que conviene no perder, porque es la que permite actuar: las organizaciones que se entienden a sí mismas, que tienen visibilidad de lo que hacen y que son capaces de priorizar y decidir con rapidez, normalmente gestionan bien los cambios tecnológicos. El problema casi nunca es la tecnología que llega; es lo que esa tecnología deja al descubierto de lo que ya había. De modo que la pregunta que un comité de dirección debería hacerse antes de aprobar el siguiente programa no es si la tecnología está madura, sino si la empresa sabe lo bastante de sí misma como para absorberla sin dejar otra capa encima.
Las cinco deudas que deja cada transformación
Lo que una transformación deja detrás no es solo tecnología, y confundir la parte con el todo es el error de diagnóstico más caro que comete una dirección. Cada ola de cambio deja cinco rastros distintos, y solo el primero aparece en algún inventario. Merece la pena nombrarlos uno a uno, con su origen real, porque la forma de detectar cada uno es distinta y la de pagarlo también.
La primera es la deuda tecnológica, y conviene empezar por ella aunque sea la conocida, porque su formulación original dice algo distinto de lo que se cree. Ward Cunningham, que acuñó la metáfora en 1992, no estaba describiendo código mal escrito: estaba describiendo la distancia entre lo que el código hace y lo que ahora se entiende del problema. Su advertencia era que el exceso de código inmaduro hace que un programa sea imposible de dominar, lo que lleva a una especialización extrema de los programadores y, al final, a un producto inflexible. Es decir, la deuda técnica no se paga en horas de refactorización: se paga en que cada vez menos gente entiende el sistema entero.
La segunda es la deuda de procesos, que es la que el cliente nota primero. Son los procedimientos duplicados que conviven porque el nuevo no llegó a sustituir al viejo, las excepciones que se crearon para la transición y se quedaron, y las actividades que siguen ejecutándose porque nadie se atrevió a comprobar si alguien las usa. Hay literatura académica reciente sobre esto, pero no hace falta: basta con contar cuántos caminos distintos recorre un mismo tipo de caso en el sistema que ya lo registra.
La tercera es la deuda organizativa, el término que Steve Blank popularizó en 2015 para los equipos que se solapan, las responsabilidades que quedaron ambiguas y los comités que se crearon para coordinar algo que ya terminó. Es más difícil de ver que las dos anteriores porque no tiene inventario, pero tiene un síntoma preciso y medible: cuántas firmas necesita hoy una decisión del mismo tipo e importe que hace dos años. Si el número ha subido y nadie decidió subirlo, eso es deuda organizativa.
La cuarta es la deuda de conocimiento, y es la primera que no se puede inventariar en absoluto. Son las decisiones cuyo contexto se perdió: por qué esta excepción existe, qué alternativa se descartó y con qué argumento, qué cliente pidió ese tratamiento especial y si sigue siendo cliente. El conocimiento de por qué un sistema hace lo que hace se pierde sistemáticamente antes que el sistema, lo que convierte cada retirada en un proyecto de arqueología en lugar de una decisión de gestión.
Y la quinta es la que de verdad importa, la que en el debate del que parte este artículo alguien llamó deuda de capacidades. Conviene decir con honestidad que el término es folclore profesional y no un concepto de la literatura: no tiene artículo fundacional y no aparece en los índices académicos con ese sentido. Eso no lo invalida, porque describe algo real que los otros cuatro no capturan. La empresa sigue funcionando porque sus profesionales compensan las deficiencias del sistema organizativo: hay personas que conocen las excepciones, recuerdan por qué se tomó una decisión, saben a qué departamento llamar y resuelven problemas que el modelo formal no contempla. Eso mantiene el negocio operativo y, exactamente por eso, oculta la complejidad acumulada.
El problema de esa quinta deuda es su perfil temporal, y de ahí viene la pregunta que quedó abierta en aquel debate y que este artículo responde más adelante. La deuda de capacidades no se manifiesta de forma gradual: se manifiesta de golpe, cuando las personas que la sostenían se van. Y cuando aparece en los resultados —decisiones más lentas, menos capacidad de hacer cosas nuevas, dependencia de cuatro nombres propios— lleva años acumulándose sin que ningún indicador se haya movido. Un directivo lo resumió con la pregunta correcta: lo interesante no es describir esa deuda, es saber cómo detectarla antes de que el rendimiento se resienta.
Hay que añadir un matiz que impide caer en el fatalismo, porque la tentación del párrafo anterior es concluir que esto no tiene arreglo. Sí lo tiene, y hay un caso público que lo demuestra por la vía negativa, que es la más instructiva. En octubre de 2015, Deutsche Bank publicó objetivos de simplificación con una concreción poco habitual: pasar de cuarenta y cinco sistemas operativos a cuatro, de ciento sesenta y seis elementos de hardware y software fuera de soporte a cero, y de unas mil reconciliaciones entre sus propios sistemas a unas trescientas. En su informe anual del ejercicio 2019, ninguno de esos indicadores vuelve a aparecer, y lo que sí aparece, en la sección de riesgos, es esta frase: «Actualmente operamos una infraestructura altamente compleja, lo que puede comprometer la calidad del entorno de control general». Cuatro años después de fijarse el objetivo, el banco se describía a sí mismo con las mismas palabras del día cero.
Conviene contrastarlo con el caso contrario, porque demuestra que esto se puede hacer: la simplificación de Starbucks consistió en eliminar un treinta por ciento del menú antes de tocar la tecnología, y la secuencia importa tanto como la decisión. No hace falta acusar a nadie de nada para extraer la lección, y por eso el caso del banco es mejor que cualquier ejemplo de éxito. Una empresa publicó indicadores de complejidad una vez, se puso objetivos sobre ellos, y después dejó de medirlos. Esa es la secuencia completa, y es la que hay que romper. La única organización que conozco que sí audita el seguimiento es la oficina de control del Gobierno federal estadounidense, y lo que encontró es coherente: de los diez sistemas heredados más críticos que señaló en 2019, en febrero de 2025 solo tres estaban retirados, y la lista nueva de los once más críticos es más vieja —entre veintitrés y sesenta años— y más cara —unos setecientos cincuenta y cuatro millones de dólares anuales frente a los trescientos treinta y siete de la anterior—. La cartera no se racionalizó: envejeció.
El riesgo de automatizar la complejidad: cómo la IA puede perpetuar procesos y excepciones innecesarias
Llegamos al punto donde la inteligencia artificial cambia de verdad el cálculo, y no es donde se suele buscar. La preocupación habitual es que la IA sustituya personas o que cometa errores. La preocupación que debería tener un director de operaciones es otra y es más sutil: la IA puede hacer tan barato mantener una excepción que desaparezca el incentivo económico para eliminarla. Conviene presentar esto como lo que es —un razonamiento, no una medición, porque no existe ningún estudio que lo haya medido— y después enseñar por qué el razonamiento es sólido, con cuatro piezas que vienen de cuatro tradiciones que no se hablan entre sí.
La primera es de 1990 y la firma Michael Hammer en Harvard Business Review. Su frase conocida es que había llegado el momento de dejar de pavimentar los caminos de las vacas, pero el párrafo que importa es el anterior: las fuertes inversiones en tecnología daban resultados decepcionantes porque las empresas usaban la tecnología para mecanizar viejas formas de hacer negocios, dejando los procesos intactos y usando los ordenadores simplemente para acelerarlos. Nótese la precisión de lo que Hammer dice: no dice que automatizar un proceso malo lo empeore. Dice que lo congela. Una excepción que tiene código deja de ser una excepción discutible y pasa a ser una especificación.
El caso que usa para demostrarlo sigue siendo el mejor que existe, y la cifra que lo cierra es la que conviene llevarse a un comité. El departamento de cuentas a pagar de Ford en Norteamérica empleaba a más de quinientas personas, y la dirección pensaba que racionalizando el proceso e instalando sistemas nuevos podía bajar a cuatrocientas, un veinte por ciento menos. Al mirar cómo lo hacía Mazda descubrieron que allí el departamento equivalente tenía cinco personas. Ford rediseñó el proceso entero y pidió a sus proveedores que directamente no enviaran factura, con una reducción del setenta y cinco por ciento de la plantilla. La diferencia entre aquel veinte por ciento y aquel setenta y cinco es exactamente la diferencia entre automatizar la excepción y eliminarla.
La segunda pieza es de 1983, está escrita para centrales eléctricas y cabinas de vuelo, y describe el problema de los agentes de inteligencia artificial mejor que la mayor parte de lo publicado en 2026. Lisanne Bainbridge enumeró en Automatica lo que llamó las ironías de la automatización, y la segunda es literalmente nuestra tesis: «el diseñador que intenta eliminar al operador le deja de todos modos las tareas que el diseñador no sabe cómo automatizar», de modo que al operador «se le puede dejar con una colección arbitraria de tareas, y puede que se haya pensado poco en darle apoyo para ellas». Dicho de otro modo: la automatización no reparte el trabajo de forma racional, se queda con lo fácil y deja lo difícil. Y lo difícil, por construcción, son los casos raros, mal definidos y sin dueño. Son las excepciones.
Del mismo artículo salen otras dos ideas que un responsable de operaciones debería tener presentes antes de dar autonomía a nada. Una es que las capacidades se atrofian si no se usan, de modo que un operador antes experimentado que lleva tiempo vigilando un proceso automatizado es ahora un operador inexperto, justo cuando hay que tomar el control manual porque algo ha ido mal y hacen falta acciones inusuales. La otra es la ironía final del artículo, que Bainbridge enuncia así: son los sistemas automatizados más exitosos, aquellos que rara vez necesitan intervención manual, los que pueden necesitar la mayor inversión en formación del operador humano. Es exactamente la situación de un equipo cuando se cae el agente que llevaba año y medio tramitando las excepciones.
La tercera pieza es económica y tiene la gracia de que la ha popularizado el propio sector. Cuando en enero de 2025 el consejero delegado de Microsoft celebró públicamente que abaratar la inteligencia artificial dispararía su uso hasta convertirla en una mercancía de la que no podríamos tener suficiente, estaba invocando la paradoja de Jevons como argumento alcista. Aplicado a las excepciones de proceso, el mismo mecanismo es bajista: si mantener una excepción se abarata, no se mantendrán menos excepciones, se mantendrán más. La paradoja de Jevons no distingue entre consumo deseable y consumo indeseable. Quien la cite para justificar su inversión en IA está citando, sin advertirlo, el argumento de que su cartera de excepciones va a crecer.
La cuarta pieza la escribieron diez ingenieros de Google en 2015, y vale porque no la firma un crítico sino gente que estaba construyendo esos sistemas. Su tesis, en la primera frase: desarrollar y desplegar sistemas de aprendizaje automático es relativamente rápido y barato, pero mantenerlos a lo largo del tiempo es difícil y caro. Dos de sus conceptos se trasladan tal cual a 2026. Uno es la proporción: un sistema maduro acaba siendo como mucho un cinco por ciento de código de aprendizaje automático y como mínimo un noventa y cinco por ciento de código pegamento. Lo que se compra es el modelo; lo que se mantiene durante diez años es la fontanería. El otro son los consumidores no declarados: otros sistemas se enganchan a la salida de un modelo sin que su dueño lo sepa, creando un acoplamiento oculto que hace que cualquier cambio —incluso una mejora— los rompa. Esa es la razón técnica por la que los sistemas viejos no se pueden apagar: no porque alguien los defienda, sino porque nadie sabe quién se cae si se apagan.
Juntando las cuatro piezas, la formulación honesta es esta. Antes de la inteligencia artificial, mantener una excepción costaba trabajo humano recurrente y visible: alguien tenía que hacerla todos los meses, se quejaba, y antes o después aparecía en una lista de mejoras. Ese coste no era solo un coste: era la señal de precio de la complejidad, y era el único mecanismo que ponía la excepción en la agenda. Cuando un agente tramita el caso raro sin quejarse, por céntimos y sin pedir vacaciones, la excepción deja de doler. Y lo que no duele, no se arregla.
De ahí sale la distinción que, en mi opinión, un comité de dirección debería incorporar a su forma de evaluar cualquier propuesta que lleve la palabra agente, y que es la misma que separa automatizar de reimaginar un proceso. ¿Estamos usando la inteligencia artificial para simplificar la organización, o para conseguir que siga funcionando una organización innecesariamente compleja? Las dos estrategias mejoran la productividad a corto plazo y las dos se pueden defender con un caso de negocio. Solo la primera cambia el modelo operativo. Y la segunda tiene un problema añadido que no aparece en ningún caso de negocio: construye una capa de inteligencia sofisticada cuya única función es gestionar una complejidad que nadie ha decidido conservar.
De financiar proyectos a gestionar capacidades de negocio: equipos estables e inversión flexible
La primera tendencia es la que lleva más tiempo anunciándose y la que menos ha avanzado, y conviene contarla con esa doble cara porque es la más fácil de comprar y la más fácil de simular. La idea es dejar de financiar proyectos temporales y empezar a financiar equipos permanentes alrededor de capacidades de negocio que siempre van a existir. En una operadora de telecomunicaciones, por ejemplo, la capacidad de asegurar la calidad del servicio de punta a punta tiene que existir siempre; lo que puede cambiar continuamente son sus herramientas de observabilidad, sus modelos de diagnóstico, sus agentes, sus procesos y sus estructuras. La capacidad permanece, la implementación rota.
El argumento es bueno y tiene detrás ocho años de literatura. La adopción medida, en cambio, es escasa. La encuesta anual del mayor proveedor de herramientas de este campo situaba en 2023 —cinco años después de la publicación del libro que dio nombre al movimiento— que solo el ocho por ciento de los encuestados había llevado el modelo de producto a operación, con trescientas veintiséis respuestas individuales de doscientas cincuenta y tres empresas y autoevaluación sin verificación externa. Hay que decir con claridad que esa cifra la publica quien vende el software que la instrumenta, y que el ocho por ciento no significa «ocho por ciento de las empresas» sino de las respuestas. Pero incluso tomándola con todas las reservas, el orden de magnitud es informativo: ocho años después, esto sigue siendo minoritario.
La razón por la que avanza tan despacio aparece en cuanto se mira dónde se atasca, y hay dos atascos documentados. El primero es el cambio de vocabulario sin cambio de sistema: los proyectos pasan a llamarse productos y los equipos reciben nombres nuevos, pero la financiación sigue aprobándose una vez al año contra un alcance fijo, los derechos de decisión no se mueven y las métricas de éxito siguen siendo las del proyecto. La organización asume los costes de coordinación del modelo nuevo sin obtener ninguno de sus beneficios. El segundo atasco es más sutil y lo describen bien los autores de Team Topologies: la empresa bautiza como producto todo lo que tiene, descubre que no tiene gente suficiente para dotar un equipo estable a cada uno, y acaba creando fronteras artificiales que en lugar de reducir las dependencias las multiplican.
De ahí sale el primer consejo concreto de esta sección, y va contra la versión maximalista del modelo: no todo tiene que convertirse en producto. Los proyectos de cumplimiento normativo, las actividades que cruzan fronteras organizativas y las preocupaciones transversales funcionan mejor fuera de ese esquema. Lo que conviene identificar no es un catálogo de productos, sino un conjunto corto de capacidades de negocio que van a seguir existiendo dentro de diez años, con un responsable que tenga autoridad para introducir soluciones nuevas y también para retirar las anteriores. Es, por cierto, la misma disciplina que separa un arranque de transformación bien preparado de uno que empieza por el comité de lanzamiento. Y con una condición que casi nadie pone: las capacidades también tienen que poder desaparecer. Preservar una capacidad de forma permanente solo porque tiene propietario, presupuesto e indicadores es exactamente el mismo error, con otra etiqueta.
Sobre la financiación hay un hallazgo que conviene conocer antes de embarcarse, porque es el que falta en todas las presentaciones sobre este asunto. En julio de 2024, el European Accounting Review publicó el estudio de un banco que abandonó el presupuesto corporativo y después volvió a implantarlo. Lo interesante no es la vuelta atrás, sino el motivo: el presupuesto regresó porque hacía falta un control estrecho y prospectivo para rendir cuentas hacia fuera. El presupuesto anual no sobrevive por inercia burocrática, sino porque alguien externo a la organización —el mercado, la matriz, el regulador o el consejo— exige un compromiso en firme sobre una cifra en una fecha. Mientras esa exigencia exista, la financiación persistente puede funcionar hacia dentro, pero no elimina el compromiso agregado hacia fuera. Cualquier propuesta de eliminar el presupuesto que no responda a quién rinde cuentas ante quién está incompleta.
Y hay una confusión que conviene deshacer, porque es donde esta tendencia se pervierte con más facilidad. Financiación persistente no significa financiación inmutable. Si el dinero se asigna a equipos estables y después nunca se reasigna, no se ha construido una capacidad: se ha construido una renta. El rasgo que define el modelo no es la permanencia del equipo, es la cadencia de revisión. Y ahí sí hay evidencia que viene del lado de las finanzas corporativas y no del mundo ágil: en un análisis de mil seiscientas dieciséis empresas cotizadas estadounidenses entre 1990 y 2005, las del tercio que más capital reasignaba entre unidades de negocio obtuvieron un 10,2 por ciento de crecimiento anual compuesto del retorno al accionista, frente al 7,8 por ciento del tercio que menos reasignaba. Son dos puntos y medio de diferencia anual —no «un treinta por ciento más», como suele titularse—, es correlación y no causalidad, y la serie termina hace veinte años. Pero apunta en la dirección correcta: lo que paga no es financiar de forma estable, es atreverse a mover el dinero.
Sobre las estructuras que gobiernan todo esto, conviene saber qué no está respaldado por ninguna evidencia, porque ahorra discusiones. Cruzando las fuentes que declaran método, no aparece asociado al éxito de una transformación tener un director de transformación, tener una oficina de proyectos, usar un marco concreto ni el porcentaje de personas dedicadas a tiempo completo. Lo que sí aparece, de forma consistente, es el compromiso real del primer nivel medido en tiempo dedicado y no en patrocinio nominal, la estabilidad de los equipos, involucrar a los responsables de cada frente cuando todavía no hay plan, y tener una única definición de éxito. Esta última merece un comentario: cuando una iniciativa tiene varias métricas de éxito, siempre hay alguna por la que se puede declarar victoria. La ambigüedad en la métrica no es un detalle de medición, es el permiso para no cambiar nada.
IA y productividad: el desplazamiento del cuello de botella de la ejecución a la verificación
Esta es, para un responsable de entrega, la tendencia más consecuente de todas, y la mayoría de las empresas está reaccionando a ella exactamente al revés de como debería. La inteligencia artificial ha abaratado producir y no ha abaratado verificar, de modo que el cuello de botella se ha desplazado de un eslabón al siguiente. Y la reacción habitual —aplicar más inteligencia artificial a generar— empeora la cola en lugar de aliviarla, porque mete más trabajo en la boca de un embudo que no se ha ensanchado.
Lo notable es que cinco fuentes con métodos y sesgos muy distintos convergen en el mismo mecanismo. El equipo de investigación DORA, con cerca de cinco mil profesionales encuestados, encuentra que en 2025 la adopción de inteligencia artificial ya mejora el rendimiento de entrega —un cambio respecto al año anterior— pero sigue aumentando la inestabilidad, y lo explica diciendo que los equipos se han adaptado a la velocidad mientras sus sistemas subyacentes todavía no han evolucionado para gestionar con seguridad ese ritmo. En su informe de 2026 le ponen nombre al coste: lo llaman impuesto de verificación, y es un acierto terminológico porque convierte la revisión en una partida de coste en lugar de en un acto moral.
La medición más gráfica la aporta un análisis de ocho millones cien mil solicitudes de cambio publicado en 2026. Una solicitud generada con un agente espera una mediana de diecisiete horas y media hasta que alguien la mira, frente a tres horas y media de una no asistida; y a treinta días, solo el 32,7 por ciento de las solicitudes agénticas se ha incorporado, frente al 84,4 por ciento de las demás. Conviene señalar una laguna de ese estudio antes de usarlo: quien lo publica no explica cómo clasifica una solicitud como agéntica, lo que es una debilidad metodológica real. Pero la dirección coincide con todo lo demás.
Hay un experimento que invierte el signo de la intuición y que merece ser conocido por cualquiera que vaya a prometer ganancias de productividad. En un ensayo aleatorizado de 2025 con dieciséis desarrolladores experimentados y doscientas cuarenta y seis incidencias en código que conocían a fondo, el uso de herramientas de inteligencia artificial los hizo un diecinueve por ciento más lentos, mientras ellos creían haber sido un veinte por ciento más rápidos. Es una muestra pequeña y en condiciones muy concretas —gente experta sobre código propio—, y no se puede generalizar. Lo que sí se puede generalizar es la brecha entre la percepción y la medición, porque es la que explica por qué tantos programas de productividad se declaran exitosos sin que el resultado aparezca en ningún sitio.
Y en el lado de lo que queda construido hay un conjunto de series que, aunque las publica una empresa con producto que vender, apuntan todas en la misma dirección. Analizando seiscientos veintitrés millones de cambios entre 2023 y 2026, la duplicación de bloques de código sube un ochenta y uno por ciento, el código movido —que es el indicio de que alguien está reorganizando en lugar de añadir— cae del veintiuno por ciento de las líneas cambiadas al 3,8 por ciento, y copiar y pegar sube del 9,4 al 15,7 por ciento. Pero el dato que mejor cuenta la historia es otro: el porcentaje de cambios que tocan código antiguo cayó del 1,7 por ciento en 2023 al 0,46 en 2026. El código viejo cada vez se toca menos. No se retira: se abandona encendido. Que es exactamente lo que este artículo viene diciendo de los sistemas, los procesos y los comités.
La consecuencia de gestión es directa y es la que conviene llevarse de esta sección. Si la restricción está en verificar, entonces las dos decisiones que mueven la aguja no son comprar más licencias ni formar a más gente en instrucciones: son reducir el tamaño del cambio y convertir la comprobación de calidad en una puerta automática que nadie pueda saltarse. Lo primero es lo que hace que una revisión sea posible; lo segundo es lo que evita que la revisión dependa de la disponibilidad y el ánimo de quien revisa. Las dos son baratas, las dos son aburridas, y ninguna de las dos aparece en un catálogo de proveedor. Quien quiera el detalle de cómo se monta esto sobre herramientas concretas lo tiene en el artículo sobre cómo organizar el trabajo de punta a punta.
IA agéntica: capacidades disponibles, estándares de integración y limitaciones de gobierno
En el terreno tecnológico, la distinción que de verdad sirve no es qué tecnología viene, sino qué está disponible hoy y qué sigue siendo una promesa con fecha. Y es una distinción que cualquiera puede comprobar en diez minutos, porque los fabricantes publican sus notas de versión con fecha y con estado. Quien las lee descubre un panorama bastante distinto del que se cuenta en las presentaciones, y que se resume en una frase: lo que está disponible es el inventario; lo que falta es el freno.
Lo disponible es más de lo que mucha gente cree. A lo largo de 2026 los grandes fabricantes han llevado a disponibilidad general la identidad propia para agentes: cada agente tiene su entrada en el directorio corporativo, sus permisos y su registro de actividad. Hay una pieza especialmente bien resuelta y que conviene conocer porque es trasladable a cualquier organización: cada identidad de agente tiene un humano patrocinador, y si ese humano deja la empresa el patrocinio se transfiere automáticamente a su responsable, de modo que siempre hay una persona que responde del acceso y del ciclo de vida de ese agente. No es una idea de marketing: es la consecuencia inevitable de haber dado credenciales a software que decide.
Lo que no está disponible es lo que a un banco o a una aseguradora le haría falta para dormir tranquilo. Hoy se puede saber qué agentes hay y darles de baja; todavía no se puede frenar a un agente en mitad de una acción ni revocar en caliente un permiso ya concedido. Esas piezas están anunciadas y en vista previa en los cuatro grandes proveedores, con fecha prometida para finales de 2026 o 2027. Y hay un indicador que vale más que cualquier predicción sobre la autonomía real: la capacidad de que un agente pague seguía en vista previa en octubre de 2026. La autonomía termina donde empieza el dinero, y ahí los fabricantes todavía no firman.
Hay una anécdota del propio mercado que enseña mejor que ninguna explicación lo joven que es esta capa. Uno de los grandes fabricantes cambió de sitio su registro de agentes y obligó a volver a registrarlos todos, doce meses después de haberlo lanzado. Quien había construido integraciones contra la primera versión tuvo que rehacerlas. Algo parecido ocurrió con el protocolo de coordinación entre agentes, que en diez meses rompió la compatibilidad tres veces, incluida una por el nombre del fichero donde se publica la identidad de un agente. Eso no es un defecto de nadie: es la condición normal de un estándar de dos años. Pero es la razón por la que apoyarse en estándares abiertos no elimina el riesgo de integración en 2026 y 2027: lo cambia de sitio.
Sobre los protocolos, la noticia buena y la mala caben en el mismo párrafo. La buena es que el protocolo de conexión de herramientas y datos se ha convertido en el estándar de hecho, está en una fundación neutral desde diciembre de 2025 y tiene adopción medible. La mala está escrita en su propia especificación: «el protocolo no puede hacer cumplir estos principios de seguridad a nivel de protocolo», de modo que el consentimiento y la autorización quedan del lado de quien implementa. Es un protocolo de conexión, no de confianza. Y el de coordinación entre agentes, por su parte, no aborda la autoridad delegada: no hay un mecanismo estándar para que el agente de una empresa actúe con los permisos de una persona concreta al pedirle algo al agente de otra. En 2026 hay estándares abiertos para conectar agentes y soluciones propietarias para confiar en ellos, y mientras eso siga así la portabilidad entre proveedores es teórica. El detalle de cómo se monta esa capa está en el artículo sobre la plataforma de agentes sobre sistemas existentes.
Gestión del contexto para agentes de IA: la desconexión entre las plataformas de datos y su utilización real
Si hay un dato de 2026 que merece una reunión de comité, es este. A lo largo de tres oleadas de un mismo seguimiento —junio, julio y agosto de 2026—, la proporción de organizaciones que tienen una capa de contexto gobernada en marcha o en construcción subió del 58 al 63 y al 67 por ciento. En el mismo periodo, la proporción que señala esa capa como fuente principal de contexto de sus agentes cayó del 21 al 19 y al 13 por ciento. Los agentes van a buscar el contexto donde lo encuentran: documentos sueltos, consultas directas al sistema vivo, ventanas de contexto gigantes. Hay dos proyectos en la misma empresa —el de datos y el de agentes— en departamentos distintos y sin hablarse.
Ese mismo seguimiento trae un dato que se puede usar mal con mucha facilidad, y conviene blindarlo. Quienes tienen capa de contexto gobernada reportan más fallos atribuibles al contexto que quienes no la tienen: un setenta y ocho frente a un treinta y siete por ciento. La lectura perezosa sería concluir que la capa empeora las cosas. La lectura correcta es que quien la tiene es el único que puede detectar que una respuesta era inconsistente: el treinta y siete por ciento de los que no la tienen no es un dato mejor, es un dato ciego. Conviene nombrar ese sesgo de detección en voz alta, porque si no se nombra, la cifra se usará para justificar no hacer nada. Hay que advertir también que se trata de encuestas de un medio, con muestras pequeñas y sin panel estable: la dirección es informativa, el nivel no.
Esto conecta con el hallazgo más robusto del año sobre retorno de la inversión en inteligencia artificial, que viene de la encuesta anual de McKinsey y que conviene citar con su matiz. Alrededor del seis por ciento de las organizaciones puede atribuir al menos un cinco por ciento de su resultado operativo a la inteligencia artificial. Y lo que separa a ese seis por ciento del resto no es el modelo ni el proveedor: es haber rediseñado el flujo de trabajo de punta a punta, algo que han hecho cerca de tres cuartas partes de ellos frente a una cuarta parte de los demás. Dicho de otro modo, el retorno no lo da la tecnología: lo da la decisión de cambiar el proceso, que es precisamente la que exige la autoridad que casi nadie tiene y a la que llegaremos al final de este artículo. Y rediseñar el flujo no es construir un agente que consulte el sistema de gestión: es componer varias capacidades distintas, de las que el modelo de lenguaje aporta una.
Modelos de pago por resultado en IA: cómo definir, medir y contratar los resultados
La tesis de que el software dejará de venderse por puestos y pasará a venderse por resultado está pasando a medias, y la letra pequeña es más instructiva que la tendencia. Hay un proveedor de atención al cliente que cobra noventa y nueve céntimos por resultado y que define «resultado» así, literalmente, en su propia página de precios: cuando el cliente confirma que su problema está resuelto, o cuando no vuelve a pedir ayuda después de que el sistema responda, o cuando se completa un flujo, incluido el traspaso a un humano. Léase despacio la segunda condición: el silencio del cliente factura igual que su satisfacción. Y la tercera: derivar el caso a una persona también cuenta como éxito.
Esto no es mala fe, y probablemente sea la definición operativa más practicable que existe. Pero demuestra dónde está el riesgo de un modelo que suena a alineación perfecta de intereses. «Precio por resultado» significa «precio por una definición de resultado que escribe el proveedor», y esa definición es lo que hay que negociar, mucho más que la tarifa. Para un director de operaciones que vaya a firmar uno de estos contratos, la pregunta no es cuánto cuesta un resultado, sino qué cuenta como resultado y quién decide que lo ha sido.
Conviene además no dar por hecho un cambio de modelo que todavía no ha ocurrido. El mayor proveedor mundial de software de negocio no ha sustituido el precio por puesto: lo ha mantenido junto al nuevo. En su tarifa pública conviven los dos dólares por conversación con complementos de ciento veinticinco, ciento cincuenta y quinientos cincuenta dólares por usuario y mes. El precio por resultado es una opción del catálogo, no el modelo de la casa. La prueba de que la transición es real llegará el día que un gran proveedor retire sus referencias por puesto; hasta entonces, lo que hay es un modelo más.
Evolución de los costes de IA: modelos más baratos, mayor consumo y nuevos criterios de inversión
Hay dos frases sobre el coste de la inteligencia artificial que son ciertas a la vez y que la prensa publica siempre por separado, con lo que una empresa puede tomar una decisión de inversión sobre media verdad. La primera: a capacidad constante, el precio se ha hundido. Medido como cuánto cuesta alcanzar un nivel fijo de rendimiento en una prueba concreta, las caídas documentadas van de nueve a novecientas veces por año según el hito. La segunda: a capacidad de frontera, el precio no ha bajado. El modelo tope de gama de 2026 cuesta alrededor de diez dólares de entrada y cincuenta de salida por millón de unidades de texto, frente a los treinta y sesenta de la referencia de 2023. Es prácticamente el mismo orden de magnitud, tres años después.
La consecuencia para una decisión concreta es inmediata. Si su caso de uso se resuelve con el modelo de hace dos años, su coste unitario ha caído un orden de magnitud; si necesita el mejor modelo disponible, no ha bajado nada. Y los casos agénticos complejos necesitan la frontera, porque los errores se acumulan a lo largo de la cadena de pasos. A eso se añade que un flujo con agentes consume órdenes de magnitud más texto que una consulta de chat, porque razona en varios pasos, llama herramientas, lee los resultados, se corrige y vuelve a intentarlo. Precio unitario a la baja y factura al alza es un resultado perfectamente previsible.
Hay que ser honesto en un punto: no existe ninguna serie pública que mida el gasto total en inferencia de las empresas, y ese es el mayor agujero de datos de todo este terreno. Nadie publica lo que cuesta operar agentes. Pero hay una prueba indirecta difícil de rebatir: los fabricantes han construido medidores de consumo, topes de gasto en tiempo real y créditos prepago que caducan a los doce meses sin posibilidad de arrastrarlos. Nadie instala un contador para algo que no preocupa. Y por detrás hay un límite que no se negocia: la Agencia Internacional de la Energía estima que cerca del veinte por ciento de los proyectos de centro de datos planificados corre riesgo de retraso por restricciones de la red eléctrica. El cuello de botella de 2027 y 2028 puede no ser el modelo ni el dato: puede ser el transformador.
IA, empleo y organización: evolución de las competencias, contratación junior y mandos intermedios
En el capítulo de personas hay que separar con especial cuidado lo que alguien ha medido de lo que alguien ha predicho, porque es el terreno donde más se mezclan las dos cosas. Y hay un contraste que merece abrir la sección porque es el tipo de hallazgo que justifica leer las fuentes en lugar de los titulares. En el año de mayor retórica sobre competencias que caducan, el indicador que el Foro Económico Mundial usa para medir precisamente esa obsolescencia ha bajado dos ediciones consecutivas. La proporción de competencias que los empleadores esperan que se transformen o queden obsoletas pasó del cincuenta y siete por ciento en 2020 al cuarenta y cuatro en 2023 y al treinta y nueve en 2025, sobre más de mil empleadores que representan catorce millones de trabajadores.
Conviene decir qué es y qué no es esa cifra. Son expectativas declaradas por empleadores, no una medición de competencias reales, y que proyecten menos inestabilidad puede significar que la inestabilidad baja o que los empleadores se han acostumbrado. Pero la metodología es la misma año tras año, de modo que la tendencia es informativa aunque el nivel no lo sea, y la tendencia va en dirección contraria a la narrativa que alimenta el mismo organismo que publica el dato. Eso no significa que no haya que formar a nadie: significa que la urgencia con la que se vende la formación no está respaldada por quien mide la urgencia.
Lo que sí está midiendo alguien con datos administrativos, y no con encuestas, es otra cosa y es más seria. Usando nóminas reales, un equipo de la Universidad de Stanford encuentra que el empleo de los trabajadores de veintidós a veinticinco años en las ocupaciones más expuestas a la inteligencia artificial está en torno a un diecinueve por ciento por debajo de donde estaría si hubiera seguido el ritmo de sus pares en ocupaciones menos expuestas, entre noviembre de 2022 y mediados de 2026, frente al quince por ciento que medían un año antes. El efecto opera por la vía de no contratar, no por la de despedir. Y los propios autores ponen el freno que hay que citar siempre con el dato: son patrones descriptivos, no estimaciones causales, y no observan desplazamiento generalizado de empleo en el conjunto de la economía.
Ese cierre de la puerta de entrada plantea una pregunta que casi nadie hace en voz alta: si se contrata menos gente joven, ¿de dónde salen los profesionales experimentados dentro de diez años? La respuesta más interesante no viene de un informe, sino de tres consultoras que han hecho exactamente lo contrario de lo que haría un optimizador de costes y han explicado por qué. Una de ellas subió dos veces en el mismo año su objetivo de contratación de titulados, hasta un veinticinco por ciento más que el ejercicio anterior, y su socia directora dio el motivo: necesitan gente junior trabajando al lado de expertos senior para que puedan desarrollar el juicio, la experiencia y el conocimiento de patrones de cómo se impulsa un cambio. No es filantropía ni relaciones públicas: es que el juicio se forma por aprendizaje junto a alguien que ya lo tiene, y no se conoce otra vía de producirlo.
Si eso es cierto, la consecuencia para una empresa que recorte su cantera es incómoda y tiene un desfase largo. No está ahorrando: está consumiendo capital de juicio sin reponerlo, y la factura llega diez años después, cuando ya no hay quien supervise. Y hay una contradicción que cierra el círculo con lo que viene en la siguiente sección: formar a alguien requiere mandos con tiempo, y la tendencia es justo la contraria.
Sobre la estructura hay que ser prudente, porque es donde más cifras circulan y menos resisten. La narrativa del «gran aplanamiento» dice que la inteligencia artificial hace innecesaria la capa de coordinación y que los organigramas se vuelven planos. La medición dice tres cosas más modestas. La primera es que el número de personas que reportan a un mismo mando lleva subiendo desde mucho antes de que existieran los modelos de lenguaje, de modo que atribuir el aplanamiento a la inteligencia artificial es, antes que nada, un error de cronología. La segunda es que las series más llamativas vienen de pequeñas y medianas empresas estadounidenses o de agregadores de perfiles profesionales, y en una gran empresa española, con convenio colectivo y estructuras reguladas, aplanar es mucho más caro y mucho más lento. La tercera, y es la decisiva: no existe ninguna medición que vincule el aumento de la amplitud de mando con la adopción de inteligencia artificial en los mismos datos. La coincidencia temporal existe; la causalidad no la ha establecido nadie.
Lo que sí se puede argumentar, y es más útil que una cifra dudosa, es que el trabajo de un mando intermedio no es una cosa sino cuatro, y que la automatización no las afecta igual. Coordinar —asignar trabajo, resolver dependencias, hacer seguimiento— es la parte que las plataformas y la automatización sí absorben, y es la que ha permitido que un mando lleve más gente. Decidir en condiciones de ambigüedad no se absorbe: con agentes ejecutando hace falta más de esto, porque aumenta el número de excepciones que alguien tiene que resolver. Verificar es trabajo nuevo, no trabajo que desaparece. Y desarrollar personas es la función sin presión a corto plazo y, por tanto, la primera que se sacrifica cuando sube la amplitud de mando.
Juntando las cuatro, la conclusión defendible es que el aplanamiento no elimina trabajo de dirección: cambia su mezcla, con menos coordinación y más decisión y verificación, y amputa la formación. Y señala una contradicción que conviene llevar a cualquier comité que esté decidiendo ensanchar equipos: se está reduciendo la capacidad de supervisar y de enseñar exactamente en el momento en que se multiplica lo que hay que supervisar y lo que hay que enseñar.
Regulación y gobierno de la IA: obligaciones europeas, plazos y marcos de cumplimiento
Esta es la sección más corta y la más accionable del artículo, porque es la única donde las fechas son obligatorias y no indicativas. Y empieza con un malentendido que va a costar dinero. El titular de 2026 fue que Europa retrasaba su ley de inteligencia artificial, y es cierto: el Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026, movió las obligaciones de los sistemas de alto riesgo del anexo III desde agosto de 2026 hasta el 2 de diciembre de 2027, y las del anexo I hasta el 2 de agosto de 2028. Pero lo que se aplazó no es lo que afecta a la empresa que usa inteligencia artificial, sino lo que afecta a quien la fabrica.
Lo que no se movió es la obligación de transparencia, que se aplica desde el 2 de agosto de 2026 con un techo sancionador de quince millones de euros o el tres por ciento de la facturación mundial. En términos prácticos: una empresa española que atiende a clientes con un agente ya está obligada a decirle a esa persona que está hablando con una inteligencia artificial. El reglamento modificador introdujo un periodo transitorio de cuatro meses para adaptar las prácticas de marcado de los sistemas generativos que ya estaban en el mercado antes de esa fecha, pero la obligación está vigente. Y si el agente toca contratación, crédito, evaluación del desempeño o biometría, la fecha es diciembre de 2027: dieciséis meses, no una exención. Un proyecto que se diseñe hoy y entre en producción en 2027 nace ya bajo esa obligación, lo que significa que el diseño tiene que incorporarla ahora y no después.
Para un lector español hay que añadir un hecho incómodo y poco comentado. La Comisión Europea ha llevado a España ante el Tribunal de Justicia de la Unión Europea por no haber transpuesto la directiva de ciberseguridad NIS2, cuyo plazo venció en octubre de 2024, junto con Irlanda, Francia y los Países Bajos. Eso deja a una empresa sujeta en la peor situación posible: la directiva la obliga, el Estado no ha publicado la norma nacional que concreta cómo, y la Comisión ha demandado al Estado por ello. No hay un «no aplica»; hay una incertidumbre sobre el cómo que acabará resolviéndose de golpe y con poco plazo. Lo prudente para quien esté diseñando el gobierno de sus agentes es construir contra el texto de la directiva y contra el Esquema Nacional de Seguridad, sin esperar a la ley.
Y hay una conexión que casi nadie hace y que vale para cualquier entidad financiera. Si un banco despliega un agente que se apoya en el modelo de un gran proveedor de nube, ese modelo es un servicio de tecnología prestado por un tercero y entra en el registro de información que exige el reglamento europeo de resiliencia operativa digital, con todo lo que eso conlleva: evaluación del riesgo de concentración, estrategia de salida y derechos de auditoría. No es una cuestión de inteligencia artificial: es una cuestión de externalización, y esa normativa ya existía y se aplica desde enero de 2025.
Por último, dos marcos que se confunden constantemente en los comités y cuya diferencia se resuelve en una frase. El marco de gestión de riesgos de inteligencia artificial del NIST es voluntario, no certificable y está actualmente en revisión; la norma ISO/IEC 42001 sí es certificable por un tercero y produce un certificado que se puede enseñar a un cliente o a un regulador. Si la pregunta del comité es «qué podemos enseñar», la respuesta es la norma certificable; si la pregunta es «cómo pensamos el riesgo», la respuesta es el marco. Confundirlos lleva a comprar consultoría para lo que no da certificado.
Las tendencias, ordenadas por lo que de verdad se sabe de cada una
Antes de pasar a la parte práctica conviene poner las tendencias en una sola tabla, porque la pregunta útil no es cuáles existen sino cuánta evidencia tiene cada una. La columna que importa es la última: qué habría que ver para creerse una tendencia que todavía no se puede medir. Es la que permite volver dentro de seis meses y comprobar si algo ha cambiado, en lugar de releer la misma predicción con otra fecha.
| Tendencia | Qué sabemos | Qué habría que ver para creérsela |
| El protocolo abierto de conexión a herramientas y datos como estándar | Ya ocurre y es medible: versión fechada, fundación neutral, más de diez mil servidores públicos | Nada: es la tendencia más segura de todas |
| Identidad propia para cada agente en el directorio corporativo | Ya ocurre: disponibilidad general en los cuatro grandes a lo largo de 2026, con precio de lista publicado | Nada, salvo que a octubre de 2026 cuatro de cada cinco agentes en producción todavía se autentican con credenciales que no son suyas |
| Obligación legal de avisar al cliente de que habla con una IA | Ya obliga: en vigor desde el 2 de agosto de 2026, con sanción de hasta quince millones o el tres por ciento | Nada: está en el Diario Oficial |
| El contexto, y no el modelo, como cuello de botella | Ya ocurre: dos tercios atribuyen las respuestas erróneas a contexto de negocio ausente o inconsistente | Nada, aunque las muestras son flojas y conviene tratarlas como dirección y no como nivel |
| El rediseño del flujo de trabajo como condición del retorno | Ya ocurre: tres cuartos de quienes obtienen impacto en resultados rediseñaron el trabajo, frente a un cuarto de los demás | Nada: es probablemente el hallazgo más robusto del año |
| Agentes nativos del propio sistema de gestión para tareas acotadas | Ya ocurre en finanzas y compras, con fechas de disponibilidad publicadas | Que los catálogos de centenares de agentes publiquen el estado de cada uno, y no solo el recuento |
| El cierre de la puerta de entrada laboral | Ya ocurre en Estados Unidos y está medido con datos de nómina, no con encuestas | Un estudio equivalente con datos administrativos españoles. No existe |
| Frenar a un agente en mitad de una acción y revocar permisos en caliente | Empieza: anunciado y en vista previa en los cuatro grandes | Que esas piezas pasen a disponibilidad general y que alguien publique una revocación funcionando en producción |
| Precio por resultado con el proveedor asumiendo el riesgo | Empieza: existe, pero la definición de resultado la escribe el proveedor | Un contrato público donde el proveedor no cobre cuando el caso acaba en manos de una persona |
| La capa de contexto gobernada como fuente real de los agentes | Empieza, con una desconexión: se construye y no se usa | Que la proporción que la señala como fuente principal suba del trece por ciento en el que está |
| Repatriación de cargas a nubes soberanas | Empieza: hay producto y hay presión regulatoria real | Una medición de cuántas cargas se han repatriado de verdad. Hoy no la publica nadie |
| Que un agente pague | Promesa: seguía en vista previa en octubre de 2026 | Que salga de vista previa y que algún banco publique un marco de responsabilidad |
| Identidad de agente que funcione entre fabricantes distintos | Promesa: hay respaldo declarado y ningún despliegue público | Un caso documentado donde un agente actúe con los permisos de una persona a través de dos proveedores de identidad distintos |
| La sustitución del precio por puesto por el precio por resultado | Promesa: los dos modelos conviven en la misma tarifa | Que un gran proveedor retire sus referencias por puesto. Mientras convivan, no hay sustitución |
| El sistema de gestión autónomo de punta a punta | Promesa: todo está en hoja de ruta | Un cierre contable o un ciclo de compra completo ejecutado por agentes, auditado y publicado |
| El efecto de la caída de precios sobre el gasto total en IA | Sin medición: nadie publica lo que cuesta operar agentes | Una serie de gasto total en inferencia por empresa. Es el mayor hueco de datos de todo este terreno |
De esa tabla sale una regla de higiene que conviene aplicar a cualquier cifra sobre inteligencia artificial empresarial, incluidas las de este artículo: desconfíe de toda cifra cuyo denominador no esté explícito. «El cuarenta por ciento de los proyectos se cancelará» no dice sobre qué base; «el noventa y cinco por ciento no da retorno» no dice de qué conjunto —mide, en realidad, el embudo de los sistemas hechos a medida, y el mismo informe dice que cerca del cuarenta por ciento de las organizaciones tiene desplegadas herramientas genéricas—; «el setenta y cinco por ciento invertirá» no dice qué cuenta como invertir. El denominador es donde se esconde el truco.
Agilidad en la era de la IA: qué prácticas de Scrum, Kanban y escalado siguen aportando valor
Aquí llega la parte que más discusión genera, y conviene empezar por el veredicto. La intuición de que las ceremonias de sprint han perdido sentido mientras Kanban lo conserva es correcta, pero el argumento con el que normalmente se defiende es malo y conviene cambiarlo. No es que un método esté mejor diseñado que el otro, ni que uno sea más moderno. Es algo más preciso y más difícil de rebatir.
Los dos mecanismos hacen lo mismo: limitan el tamaño del lote de trabajo que puede estar en curso. La diferencia está en la unidad con la que lo miden. El límite de trabajo en curso mide el lote en unidades de trabajo; el sprint lo mide en unidades de tiempo. Un límite de cinco elementos sigue siendo cinco elementos cuando el tiempo de ciclo cae de dos semanas a dos horas. Una caja de dos semanas, en cambio, pasa de contener un lote a contener cuarenta. Dicho de otro modo: el límite de trabajo en curso es invariante a la aceleración y la caja temporal no lo es. Esa es toda la diferencia, y explica por qué una sobrevive al cambio de ritmo y la otra no.
Hay un segundo nivel del argumento que es aún más sólido y que conviene tener a mano cuando alguien defienda la ortodoxia. El límite de trabajo en curso descansa sobre una identidad contable —la ley de Little— y las ceremonias descansan sobre una hipótesis conductual: la de que celebrar el evento produce el comportamiento. Esa hipótesis se ha puesto a prueba. En un estudio con quince mil setenta y ocho personas de cuatro mil trece equipos, la elección de marco de escalado explica entre el uno y el dos por ciento de la varianza en efectividad del equipo, mientras que el contexto explica hasta el 47,5 por ciento. Y las cinco variables que sí explican, hasta un 75,6 por ciento combinadas, son la autonomía del equipo, el clima de mejora continua, la preocupación por el destinatario del trabajo, la capacidad de respuesta y el apoyo de la dirección. Ninguna de las cinco es una ceremonia.
Conviene además señalar algo que casi nadie que practica Scrum sabe, y es que la mayor parte de lo que se hace en su nombre contraviene su propio manual. La guía oficial dice que los sprints garantizan la inspección y la adaptación «al menos cada mes natural», lo que es un suelo y no un techo: quien inspecciona en continuo lo cumple con holgura. Dice también que la revisión de sprint «nunca debería considerarse una puerta para liberar valor», y que un incremento puede entregarse antes de que el sprint termine. De modo que las dos prácticas más extendidas —tratar la revisión como comité de aprobación y esperar al final del sprint para entregar— no son fidelidad al marco: son su incumplimiento.
Antes de la tabla hay que poner sobre la mesa el dato que más daña esta tesis, porque un artículo que desmonta cifras ajenas tiene que empezar por no esconder las que le incomodan. La única muestra grande que ha comparado procesos de estimación —nueve mil seiscientos veintinueve equipos— encontró que los que no estimaban nada tenían la peor calidad del conjunto, con una diferencia de densidad de defectos de hasta el doscientos cincuenta por ciento, y que el mejor resultado global correspondía a una versión ligera de Scrum, no a la ausencia de proceso. Es un dato de 2013, de un proveedor y correlacional. Pero existe, y matiza el entusiasmo: lo que falla no es tener proceso, es tener un proceso cuyas unidades ya no corresponden con la realidad del trabajo.
| Práctica | Qué problema resolvía | Veredicto | Por qué |
| El sprint como caja de dos semanas | Poner un suelo a la frecuencia de inspección, dar cadencia de coordinación y acotar el lote comprometido | Transformado | Como límite de lote expresado en tiempo pierde sentido cuando el ciclo baja a horas. Como contenedor de coordinación, puede que no. Sustituir por límite de trabajo en curso más una cadencia de coordinación desacoplada de la de entrega |
| Estimación en puntos de historia | Dimensionar el compromiso y dar previsibilidad | No para el elemento; sí para el agregado | Sobrecoste medio del treinta por ciento sin mejora desde los años ochenta. Con agentes la distribución se vuelve bimodal y la media deja de informar. Funciona el dato histórico, no la sesión deliberativa |
| Planificación de sprint | Decidir qué es lo siguiente y comprometer un lote que quepa | Transformada | Sobrevive decidir la prioridad y explicar por qué algo es valioso; muere el compromiso de lote en unidades de esfuerzo |
| Reunión diaria | Coordinarse y detectar impedimentos | Transformada, hacia su mejor parte | Observando ciento dos reuniones en quince equipos, solo un tercio del tiempo se dedica a las tres preguntas rituales y otro tercio a elaborar y resolver problemas. La parte automatizable es justo la que la estropea: quitarla la mejora |
| Refinamiento y especificación | Evitar empezar algo mal definido | Gana importancia | Un agente no pregunta cuando algo es ambiguo: lo resuelve inventando, y produce algo que se parece notablemente a lo correcto. Y se invierte menos esfuerzo en especificar que en producir |
| Revisión de sprint | Obtener retroalimentación de quien va a usar la cosa | Transformada | El propio manual dice que nunca debe ser una puerta de liberación. Sobrevive el contacto con el destinatario, que es una de las cinco variables que sí explican la efectividad; muere la demostración por lotes |
| Retrospectiva | Convertir experiencia en mejora | Gana importancia | Es la única ceremonia que no agrupa trabajo sino aprendizaje, y la única cuyo contenido no se puede automatizar. El clima de mejora continua es la variable de mayor fiabilidad de las cinco que explican la efectividad |
| Definición de listo y de terminado | Cerrar la distancia entre «he acabado» y «funciona en producción» | Ganan importancia y cambian de soporte | Cuando producir un candidato cuesta minutos de máquina desaparece el freno natural a declarar cosas terminadas. Pasan de acuerdo social a puerta automática que un agente no puede saltarse |
| Límite de trabajo en curso | Controlar el tiempo de ciclo y la calidad limitando lo empezado | Sí, y es lo que más gana | Es aritmética, no doctrina, y mide el lote en unidades que la aceleración no altera. Con una advertencia: bajarlo demasiado reduce el rendimiento hasta un treinta y cuatro por ciento. Hay óptimo, no mínimo |
| Marcos de escalado | Coordinar muchos equipos | No como palanca | El marco explica entre el uno y el dos por ciento de la varianza en efectividad; el contexto, hasta el 47,5 por ciento |
De esa tabla sale un principio que ordena el resto del artículo y que conviene retener porque se aplica mucho más allá del software. Muere lo que gobernaba el calendario y sobrevive lo que gobierna el flujo y la calidad. Todo lo que existía para sincronizar a la gente en una fecha pierde función cuando el trabajo deja de llegar en lotes fechados; todo lo que existía para decidir si algo está bien hecho gana función cuando producir cuesta minutos y verificar cuesta horas.
Y hay un consejo de orden que es contrario a la intuición y que probablemente sea lo más útil de esta sección. La tentación es quitar las ceremonias. El riesgo documentado es que lo que aparece cuando se quita la caja temporal sin poner nada en su lugar no es flujo continuo: es interrupción continua. En una encuesta a doce mil treinta y cinco trabajadores del conocimiento, el ochenta y siete por ciento declara no tener tiempo ni capacidad para coordinarse porque todo el mundo está en modo ejecución. La inteligencia artificial ha subido la velocidad individual sin subir la coordinación, y eso es un argumento a favor de la cadencia, no en contra. De modo que el orden correcto es el inverso del que sugiere el entusiasmo: primero se instala el límite de trabajo en curso y la puerta automática de calidad; cuando las dos funcionan, el sprint se cae por su propio peso sin que nadie tenga que abolirlo.
Evolución del gobierno de la transformación: comités, aprobaciones, planificación y presupuestos
Lo anterior interesa a quien dirige entrega de software, que es una minoría de los lectores de este artículo. Lo que viene ahora afecta a cualquier comité de dirección, y tiene la particularidad de que la evidencia más dura disponible no es sobre software: es sobre comités. Dos fuentes independientes y de naturaleza completamente distinta coinciden en que el comité de aprobación de cambios, que es el control más extendido de la empresa grande, no hace el trabajo por el que existe.
La primera es un estudio sectorial de 2019: los encuestados cuyos cambios pasaban por un órgano externo de aprobación tenían 2,6 veces más probabilidad de estar entre los de peor rendimiento, y —esto es lo decisivo— los investigadores declaran que buscaron si un proceso de aprobación más formal se asociaba a tasas de fallo más bajas y no encontraron ninguna evidencia que apoyara esa hipótesis. El comité no solo frena: no cumple la función por la que fue creado.
La segunda es mucho mejor y casi nadie la usa, porque no la publica una consultora sino un regulador financiero, con datos operativos obligatorios de veintitrés entidades y más de un millón de cambios en producción. Lo que encontró: los comités de cambio aprobaron más del noventa por ciento de los cambios mayores que llegaron a revisar, y en algunas entidades no rechazaron ni uno solo en todo el año, hasta el punto de que el regulador los describe como un papel de «control de tráfico aéreo» más que como una función de aseguramiento. Un control que aprueba nueve de cada diez casos no es un control: es un trámite con acta.
Y el remate de ese mismo estudio es el dato que conviene llevar a la reunión donde se defienda el comité. Los cambios de emergencia, que por definición se saltan el proceso de gobierno, fallaron el 1,5 por ciento de las veces, frente al 3,8 por ciento de los cambios mayores que sí pasaron por el comité. El regulador ofrece explicaciones prudentes y alternativas para eso, y conviene recogerlas: los cambios de emergencia suelen ser más pequeños y más urgentes, lo que no es lo mismo que mejor gobernados. Pero su propia conclusión sobre la causa del riesgo no es la falta de aprobaciones: es el tamaño del lote, es decir, que los cambios grandes fallan por su complejidad y por la incapacidad de descomponerlos en partes más pequeñas.
El mismo razonamiento se aplica, con menos evidencia pero con la misma lógica, a otras cuatro prácticas de gobierno que conviene revisar. Las puertas de inversión por etapas no previenen el fracaso: un proyecto puede pasar todas las puertas y fracasar comercialmente, porque el proceso entero se orienta a las puertas y no al destinatario, y porque el nivel de conocimiento de quien hace de guardián suele ser bajo. Lo que sustituye a la puerta no es otra puerta, es el experimento: en las organizaciones que miden en serio el efecto de lo que lanzan, solo un tercio de las ideas mejora la métrica que pretendía mejorar.
El informe de estado semanal es la pregunta «¿qué hiciste ayer?» escalada a la organización entera, y es justamente la parte que la evidencia señala como destructora del valor de la reunión diaria. Con inteligencia artificial cuesta cero producirlo y cero leerlo, de modo que pierde contenido informativo por los dos extremos a la vez. Lo que lo sustituye es enseñar el sistema funcionando. El plan a dieciocho meses deja de valer como compromiso y sigue valiendo como hipótesis, por el mismo motivo por el que la estimación detallada dejó de valer: es un compromiso temprano con un número sobre un alcance grande. Y el registro de riesgos, supuestos, incidencias y dependencias, que parecía burocracia pura, se revaloriza por una razón nueva: declara supuestos y dependencias, que es exactamente el material que un agente no puede inferir y que, si no está escrito, resuelve inventando. Con una condición: tiene que estar vivo y ser legible por una máquina, no ser un anexo de comité.
Queda el presupuesto anual, que es el cambio más consecuente de todos y el único sobre el que no hay evidencia cuantitativa sólida en ninguna dirección. El argumento estructural es simple: es el lote más grande de la empresa —doce meses— y el coste unitario de lo que presupuesta cambia varias veces dentro del mismo ejercicio. Pero ya hemos visto por qué no desaparece: porque alguien de fuera exige un compromiso en firme sobre una cifra en una fecha. La salida razonable no es abolirlo, es reducir su granularidad hacia dentro —revisar la asignación trimestralmente en lugar de anualmente— manteniendo el compromiso agregado hacia fuera.
Seis indicadores para detectar la complejidad organizativa antes de que afecte al rendimiento
Esta sección responde la pregunta que quedó abierta al principio, y es la más práctica del artículo. Cuando la deuda de capacidades llega a los resultados ya lleva años acumulándose, de modo que el único momento útil para verla es antes. Las seis señales que siguen tienen una propiedad en común que las hace viables: ninguna requiere una encuesta, ninguna exige instrumentación nueva y todas se calculan con datos que la empresa ya paga por tener.
La primera señal es que las decisiones del mismo tipo tardan más que hace dos años. Se mide contando cuántas firmas necesita hoy una decisión de un importe dado y comparándolo con la misma decisión en el pasado. Si el número ha subido y nadie tomó la decisión de subirlo, eso es deuda organizativa acumulada: alguien añadió un control después de un incidente y nadie lo retiró cuando el incidente dejó de ser probable.
La segunda es que crece la proporción de casos que no siguen el camino estándar. Todo sistema de gestión de casos registra lo que se sale de la ruta principal: reclamaciones, retrabajos, escalados, autorizaciones manuales. La tasa de excepciones está en los datos y casi nunca se extrae como serie temporal. Es la medida más barata de complejidad de proceso que existe, y es la que primero se mueve cuando una transformación deja cosas a medias.
La tercera es que todo pasa por las mismas personas. No hace falta un estudio de redes: basta con mirar quién aparece en los escalados y quién resuelve las excepciones de la señal anterior. Si en una función de doscientas personas hay cuatro nombres que aparecen en todo, la empresa no tiene un equipo: tiene cuatro personas y ciento noventa y seis que dependen de ellas. Esa es la deuda de capacidades en su forma medible, y su particularidad es que no se nota mientras esas cuatro personas sigan ahí.
La cuarta es la que nadie lleva y que este artículo propone incorporar: cuántas iniciativas de cambio caen a la vez sobre un mismo equipo. Se calcula cruzando la cartera de proyectos con el organigrama, no cuesta nada y es exactamente la cifra que convirtió «de dos a diez cambios por empleado» en un dato en lugar de una queja. Ninguna empresa que he visto tiene ese número de sí misma, y es el que explica por qué un equipo concreto no absorbe lo que se le pide.
La quinta es que hay sistemas que nadie toca. La antigüedad del último cambio funcional, por sistema, sale del propio control de versiones o del registro de cambios. Un sistema que nadie ha tocado en cuatro años no está estable: está abandonado con la luz encendida. Y la sexta cierra el conjunto: se encienden más sistemas de los que se apagan. La tasa de retirada —sistemas apagados divididos por sistemas puestos en producción en el mismo periodo— es calculable mañana con el inventario de activos y la contabilidad de proveedores. Si ese cociente lleva años por debajo de uno, la cartera solo puede crecer, y ninguna cantidad de voluntad directiva lo cambia.
Dos advertencias sobre cómo usar esto, porque sin ellas el conjunto se convierte en otro cuadro de mando que nadie mira. La primera: ninguna de las seis significa nada por sí sola, y lo que informa no es el valor absoluto sino la dirección de la serie. Tener un quince por ciento de excepciones puede ser normal en un negocio y catastrófico en otro; pasar del ocho al quince en dieciocho meses es siempre una señal. La segunda: estas seis son medibles hoy, y ese es precisamente su mérito. Si en la primera versión del cuadro de mando se incluye alguna métrica que exija instrumentación nueva —realización de valor con línea base, cobertura de verificación, tiempo real de supervisión—, el dato llegará con un año de retraso y la conversación se desplazará a por qué no hay datos. Cinco medidas toscas disponibles mañana valen más que quince exactas prometidas para el año que viene.
Simplificación empresarial: cómo incorporar la retirada de sistemas, procesos y controles a cada transformación
Hay un hallazgo científico que explica, mejor que cualquier teoría de gestión, por qué la cartera de iniciativas de cualquier empresa grande solo puede crecer. Y lo bueno es que viene con su propio remedio. En 2021, un equipo de la Universidad de Virginia publicó en Nature un trabajo sobre lo que llamaron la ceguera sustractiva, y su hallazgo no es el que suele contarse. No demostraron que la gente rechace quitar: demostraron que la opción de quitar no llega a formularse. Las ideas aditivas vienen a la mente rápida y fácilmente; las sustractivas requieren más esfuerzo, y como la gente trabaja deprisa y con las primeras ideas que se le ocurren, acaba aceptando soluciones aditivas sin haber considerado nunca la sustracción.
El dato que mejor traslada eso a una empresa no es ninguno de sus ocho experimentos de laboratorio, sino un recuento de campo que está en el material complementario. El rector entrante de una universidad grande abrió una llamada pública de sugerencias y recibió mil doscientas una propuestas. De las seiscientas cincuenta y una que eran claramente aditivas o sustractivas, el ochenta y nueve por ciento pedía añadir algo y el once por ciento pedía quitarlo. No es un experimento: es un recuento. Y describe con precisión lo que ocurre cuando una empresa abre un buzón de ideas de transformación.
El remedio es casi insultante de barato y es lo que convierte este hallazgo en accionable. En uno de los experimentos, decir explícitamente a los participantes que podían quitar algo llevó las ideas sustractivas del veintiuno al cuarenta y ocho por ciento. Y no redujo ni una sola de las ideas aditivas: la proporción de participantes que proponía añadir se quedó igual. La petición no sustituye una categoría por otra, desbloquea una categoría entera que estaba cerrada. Traducido: un comité de inversiones que exija en cada propuesta un apartado de «qué se apaga» no está aplicando una moda de gestión, está aplicando la manipulación experimental que funcionó en el laboratorio.
Por honestidad hay que citar la réplica. En 2024, un equipo repitió las dos tareas principales corrigiendo dos problemas metodológicos del original y, con cincuenta y ocho adultos, no halló el sesgo en la tarea de construcción ni diferencias en la de cuadrícula con estímulos neutros; sí halló diferencias culturales y de edad. La réplica tiene una muestra pequeña y es conceptual, no exacta: no tumba el hallazgo, lo acota. Lo defendible es que el sesgo aditivo está bien documentado en laboratorio y, sobre todo, en una observación de campo con más de mil propuestas reales; que su magnitud depende de la tarea y del contexto; y que no es una ley física. Lo que no depende de la réplica es el recuento de las mil doscientas sugerencias, porque ahí no hay experimento que replicar.
Ahora bien, antes de salir corriendo a implantar la regla de «por cada cosa nueva, una fuera», conviene saber que esa regla ya se probó a gran escala, se auditó de forma independiente, se endureció dos veces y se acabó abandonando. Lo que produjo no fue disciplina de cartera: produjo reetiquetado para que lo nuevo no contase, poda concentrada en lo más visible en lugar de en lo más costoso, y agotamiento progresivo del mecanismo, porque cada vuelta deja menos cosas fáciles de quitar. Eso no significa renunciar al principio. Significa aplicarlo con la pieza que en el experimento que funcionó estaba presente y en el que falló no: un tercero independiente que valide la cifra del ahorro antes de aceptarla. Sin ese tercero, la regla es una invitación a inflar el beneficio de la salida tanto como ya se infla el beneficio de la entrada.
Con esas dos piezas —pedir la sustracción por escrito y hacer que alguien valide la cifra— se puede escribir la regla operativa, que es muy concreta y cabe en un formulario. Una transformación no está terminada porque algo nuevo funcione, sino porque el modelo nuevo ha sustituido efectivamente al anterior. De modo que toda propuesta de inversión debería declarar qué aplicaciones, procesos, controles o actividades sustituye, en qué fecha quedarán apagados, quién firma ese apagado, y qué pasa si llega la fecha y siguen encendidos. Esa última pregunta es la que separa un compromiso de una intención, y es la que casi nunca se hace.
Por qué no se retira nada, y no es por falta de voluntad
Llegados aquí, la pregunta obvia es por qué, si todo esto es tan evidente, no se hace. La respuesta habitual —cultura, miedo al cambio, resistencia— es cómoda y es falsa, o al menos es innecesaria. Hay cuatro incentivos perfectamente medibles para no apagar nada, y tres de ellos están escritos en normas que nadie discute. Conviene conocerlos porque cada uno tiene un remedio distinto y ninguno de los remedios es una campaña de concienciación.
El primero es contable y es el menos citado de todos. El software desarrollado para uso interno que se ha capitalizado es un activo en el balance. Implantar un sistema crea ese activo y reparte su coste entre varios ejercicios; retirarlo obliga a evaluar el deterioro y materializa una pérdida en el ejercicio en que se decide. Y es una pérdida con nombre y apellidos, porque hay un responsable identificable de aquella inversión. Un sistema que ya no sirve pero sigue amortizándose no genera ningún cargo extraordinario; el mismo sistema apagado, sí. El tratamiento contable premia la acumulación y castiga la limpieza, con independencia del valor económico subyacente.
El segundo es presupuestario y opera por otra vía. Construir se capitaliza; mantener, migrar, simplificar y apagar se van a gasto. Dentro de un mismo presupuesto, «construir algo nuevo» compite en una categoría favorecida y «retirar lo viejo» en una castigada, que es precisamente la que un director financiero recorta cuando aprieta. No hace falta mala intención: basta la asimetría del tratamiento. Y hay un detalle que lo agrava: las actividades de simplificación se parecen mucho a mantenimiento en el papeleo, de modo que incluso cuando se hacen tienden a imputarse a gasto.
El tercero es temporal. Los objetivos se fijan en diciembre para el año siguiente, y una retirada bien hecha de una plataforma grande tarda de dieciocho a treinta meses, con lo que no cabe en ningún objetivo anual y quien la empieza entrega el resultado a su sucesor. El cuarto es el más humano de los cuatro y el más racional: si se apaga un sistema y algo se rompe, el fallo tiene fecha, hora y responsable; si no se apaga, el coste es un gasto recurrente que nadie atribuye a nadie. El cálculo individual de un directivo es no apagar, y es racional precisamente porque la organización ha hecho que lo sea.
Esto no es nuevo ni es propio de la era digital. La literatura de agencia de los años ochenta ya describió el mecanismo general: los directivos tienen incentivos fuertes para hacer crecer sus unidades más allá del tamaño óptimo, porque la organización premia el tamaño del equipo y del presupuesto gestionado, no el valor creado. Quien reduce ambos empeora su propio expediente. Lo que la inteligencia artificial añade no es un problema nuevo, es velocidad: construir cuesta cada vez menos, de modo que la tasa de acumulación sube mientras la tasa de retirada sigue donde estaba.
Los remedios, por tanto, son simétricos a los problemas y resultan decepcionantemente administrativos, que es justo lo que les da credibilidad. Provisionar por anticipado el cargo contable de la retirada como partida de la propia transformación, para que la decisión no dependa de quién tendría que absorber esa pérdida en su cuenta de resultados del año. Crear la figura que aprueba retiradas, igual que ya existe la que aprueba inversiones, con presupuesto propio. Y poner la cifra de sistemas apagados en la retribución variable de alguien con nombre y apellidos. No es una cuestión de convicción: es una cuestión de que alguien tenga esa cifra en su objetivo. Mientras la retirada no esté en el objetivo de nadie, seguirá ocurriendo como episodio —cuando aprieta el coste, durante dos ejercicios— y revirtiendo en cuanto aparezca algo nuevo que comprar.
Quién tiene autoridad para retirar: Gobierno de procesos de extremo a extremo, autoridad, presupuesto y responsabilidad para simplificar
Todo lo propuesto hasta aquí tiene un modo de fallo común y es tan predecible que conviene anticiparlo. Se designa un responsable de punta a punta, se le da un título, y no se le da nada más. Entonces la responsabilidad de punta a punta se convierte en otro concepto elegante sin autoridad real, y el único resultado tangible del ejercicio es una casilla más en el organigrama.
La doctrina de gestión por procesos nunca dijo que bastara con nombrar a alguien. Michael Hammer, en el modelo de madurez que publicó en 2007, definió el nivel alto de madurez del responsable de proceso por dos atributos muy concretos: autoridad sobre el presupuesto del proceso e influencia fuerte sobre las personas que lo ejecutan. Es decir, definió la madurez precisamente por las dos cosas que casi ninguna organización matricial concede. Veinte años de práctica han consistido, mayoritariamente, en nombrar al responsable y no darle ni lo uno ni lo otro. Eso no es un fallo de ejecución: es la decisión de no transferir poder, tomada de forma implícita y repetida.
Conviene aquí una nota de honestidad, porque es un terreno donde abundan las afirmaciones rotundas sin medición. No existe ningún estudio cuantitativo, con muestra y método publicados, que mida qué autoridad formal tienen los responsables de proceso de punta a punta en empresas grandes. Lo que hay es literatura profesional que lo afirma de forma consistente sin medirlo, y literatura académica sobre la tensión entre propiedad de proceso y jerarquía de línea. Es una laguna que conviene declarar en lugar de rellenarla con una cifra inventada.
Lo que sí se puede explicar con solidez es por qué un título no basta, y la explicación viene de la literatura de poder organizativo. El poder en una organización es un fenómeno estructural que deriva del control de recursos, del acceso a la información y de la dependencia que otros tienen de ti; no nace del nombramiento. Un responsable que no controla el presupuesto de la plataforma, ni a las personas que ejecutan, ni la decisión de apagar, tiene autoridad formal sin poder estructural, y la predicción de esa literatura es inequívoca: no gana los conflictos.
Vale la pena mirar la anatomía concreta del bloqueo, porque enseña dónde hay que intervenir. Retirar algo viejo en una empresa grande exige típicamente tres decisiones de tres sitios distintos. Apagar la plataforma lo decide quien gestiona los sistemas, que tiene el contrato con el proveedor, el presupuesto de mantenimiento y el riesgo operativo de apagar. Eliminar el proceso lo decide quien responde del servicio y de los controles. Reasignar a las personas lo decide quien tiene la responsabilidad jerárquica, con los límites y los plazos de información que correspondan. Ninguno de los tres tiene incentivo propio para iniciar la retirada y los tres tienen poder de veto de hecho.
De ahí sale la formulación que mejor resume el problema, y que debería incomodar a cualquier comité de dirección: la complejidad muchas veces no sobrevive por razones técnicas, sino porque cada parte del sistema tiene un propietario que defiende su parcela mientras nadie tiene suficiente autoridad sobre el conjunto. La consecuencia práctica es que la retirada no se consigue con un comité, porque un comité es precisamente el mecanismo que agrega vetos. Se consigue asignando la decisión a una persona con tres cosas: presupuesto, fecha y un objetivo anual expresado en lo que debe quedar apagado. Si no se le puede dar al menos una de las tres —el presupuesto de la plataforma, el objetivo de apagarla, o la firma que hoy la mantiene viva—, es preferible no nombrar a nadie que nombrar a alguien para que fracase.
Quién verifica cuando el volumen hace imposible verificarlo todo. Supervisión de agentes de IA: controles independientes, trazabilidad y verificación por muestreo
Hay un control que lleva siglos en la empresa y que está desapareciendo sin que nadie lo haya derogado. El principio de los cuatro ojos —que toda decisión crítica la proponga una persona y la apruebe otra independiente— es el control interno más antiguo y más extendido que existe, y gobierna desde la liberación de pagos hasta el acceso a información sensible. La pregunta que nadie se ha hecho formalmente es qué queda de ese principio cuando uno de los dos pares de ojos es una máquina. Porque el principio no pide dos revisiones: pide dos juicios independientes.
Existe un caso documentado con fechas que recorre el ciclo completo en seis meses y en un producto que usan millones de personas, y vale la pena contarlo porque es lo que va a pasar en todas las empresas. Al principio la regla era estricta y bien razonada: la aprobación de la persona que había lanzado al agente no contaba como revisión, porque a esa persona se la trata como autora del cambio y no como revisora. La máquina no es un segundo par de ojos: es la mano del humano que la invocó. Esa es, probablemente, la mejor formulación disponible de la regla de gobierno para agentes, y no viene de un marco de consultoría sino de un documento operativo.
Lo que ocurrió después es lo instructivo. A los pocos meses apareció un ajuste para que los administradores pudieran saltarse la aprobación humana previa, con una justificación de seguridad razonable. Y al final del mismo año, el agente recibió la capacidad de aprobar, y esa aprobación puede contar para la regla de aprobaciones requeridas, desactivada por defecto y configurable. Cada paso era defendible por sí solo; el resultado conjunto es que el control más antiguo de la empresa puede quedar satisfecho sin ningún juicio humano independiente, por configuración. Nadie lo derogó: se fue vaciando.
De ahí sale la recomendación más concreta y menos tópica de todo este artículo: hay que versionar la configuración de los controles, no solo registrar las aprobaciones. Una empresa que solo guarda el registro de quién aprobó qué no puede reconstruir, un año después, si en marzo el control estaba activo y en septiembre ya no. La pregunta de gobierno deja de ser «quién aprobó» y pasa a ser «qué identidad aprobó, con qué autoridad delegada, bajo qué configuración vigente en ese momento, y quién cambió esa configuración». Y conviene decidir esa configuración por adelantado y por tipo de acción, con la misma escala de autonomía de cero a cinco que ya usamos en este blog: informar, recomendar, preparar, ejecutar dejando traza, ejecutar salvo excepción y operar de forma autónoma.
La respuesta habitual a esto es poner a gente experimentada a supervisar, y hay tres décadas de literatura experimental que dicen que no funciona. El fenómeno tiene nombre técnico desde 1997 —sesgo de automatización— y réplicas modernas que son demoledoras. En 2023, veintisiete radiólogos leyendo cincuenta mamografías con la asistencia de un sistema cuyas sugerencias estaban manipuladas pasaron del 82,3 por ciento de acierto cuando la sugerencia era correcta al 45,5 por ciento cuando era incorrecta, y el efecto alcanzó también a quienes tenían más de quince años de experiencia. En 2025, en un ensayo aleatorizado, médicos que habían recibido veinte horas de formación específica en evaluar críticamente la salida de una inteligencia artificial perdieron catorce puntos de precisión diagnóstica al recibir recomendaciones defectuosas. La antigüedad no protege y la formación tampoco. Es el mismo fenómeno que explica por qué tener más información no mejora automáticamente las decisiones: la restricción no está en el dato, está en el juicio que lo recibe.
Y en 2026 apareció el dato que ninguna política de gobierno contempla y que debería cambiar cómo se diseñan estos sistemas. En un estudio con cuarenta y seis médicos, mostrar las fuentes que respaldaban una respuesta elevó la adopción del consejo correcto del treinta y cuatro al 76,9 por ciento. Pero cuando la respuesta era incorrecta y venía acompañada de citas, la resistencia del profesional a aceptarla cayó del noventa y dos al 34,8 por ciento. Es decir: la trazabilidad, que es la medida de control que todo el mundo está implantando, funciona también como amplificador del sesgo. El remedio y el veneno son el mismo artefacto. Conviene señalar que se trata de un preprint y que el terreno es clínico, no empresarial; pero la dirección es coherente con treinta años de literatura y la implicación es inmediata: no basta con exigir que el agente muestre sus fuentes, hay que medir si el revisor llega a abrirlas.
La salida a todo esto no hay que inventarla, y esa es la buena noticia de esta sección. Dos disciplinas maduras llevan décadas resolviendo exactamente el problema de «no puedo revisarlo todo» con método estadístico: la auditoría y el control de calidad industrial. La norma internacional de auditoría sobre muestreo define las cuatro piezas con sus nombres: la población sobre la que se quiere concluir, la tasa tolerable de desviación fijada por anticipado, la obligación de proyectar a toda la población lo encontrado en la muestra, y el reconocimiento explícito del riesgo de muestreo en las dos direcciones. Lo que una empresa necesita para gobernar agentes no es un marco nuevo: es decir en voz alta «aceptamos hasta un dos por ciento de error en esta clase de decisión» y muestrear en consecuencia.
El argumento que convence a un consejo de administración es este, y conviene llevarlo tal cual. La aprobación caso a caso, cuando el volumen la hace imposible, produce la ilusión de cobertura total y una cobertura real desconocida; el muestreo produce menos cobertura nominal y una incertidumbre cuantificada. La segunda es defendible ante un regulador y la primera no. Y conviene además ponerle precio al asunto, porque convierte una discusión moral en una decisión de gestión: verificar cuesta, hay un presupuesto para ello, y la pregunta que falta en casi todos los comités es cuánto estamos dispuestos a pagar y qué dejamos deliberadamente sin verificar.
Qué medir: cinco métricas para medir complejidad, simplificación y eficiencia
Hay una discusión que consume reuniones enteras y que se puede desactivar con una cita. El equipo de investigación que más autoridad tiene sobre métricas de entrega de software escribe en su informe más reciente que no está allí para recomendar un marco sobre otro, que muchas de las medidas subyacentes son las mismas en todos, y que el marco correcto es el que consiga que su organización actúe. Viniendo de quien podría vender el suyo, esa frase desinfla la discusión de marcos y deja en pie la única pregunta que importa: quién va a actuar con esto y si tiene autoridad para hacerlo.
Con eso resuelto, la elección de métricas se vuelve un problema práctico, y el criterio que propongo es incómodo para quien quiera un cuadro de mando elegante. En la primera versión del cuadro de mando de una transformación permanente no debería figurar ninguna métrica que exija instrumentación nueva. La razón es operativa: si se incluye, se promete un dato que llegará con un año de retraso, y durante ese año todas las reuniones se irán en explicar por qué no hay datos. Es preferible empezar con cinco medidas toscas disponibles mañana.
Las cinco que propongo salen todas de sistemas que la empresa ya paga. Sistemas retirados al año, que sale del inventario de activos y de la contabilidad de proveedores, y que es la única de las cinco que no se puede falsear añadiendo actividad. Casos que se salen del camino estándar, que el gestor de casos ya registra. Sistemas distintos que toca una persona para completar una tarea, que se obtiene de los registros de acceso y mide fricción real sin preguntar a nadie. Iniciativas de cambio concurrentes sobre un mismo equipo, que sale de cruzar la cartera con el organigrama. Y coste de servir por operación, que es el coste total de la función dividido por el volumen: tosco, pero comparable consigo mismo en el tiempo, que es lo que importa.
Lo que queda fuera conviene nombrarlo, porque es exactamente lo que suele proponerse primero. La realización de valor —comparar lo prometido con lo cobrado— exige que el caso de negocio se registre con una línea base y que alguien vuelva a medirla doce meses después, y casi ninguna empresa tiene ese registro, de modo que el dato no se puede reconstruir hacia atrás. La cobertura de verificación exige marcar cada decisión automatizada como revisada o no. El tiempo real de supervisión exige instrumentar la herramienta de revisión. Las tres son las métricas correctas y las tres son inversiones, no decisiones. Conviene presupuestarlas antes de prometerlas.
Gestión del conocimiento y memoria de decisiones: cómo mantener el contexto que necesitan los agentes de IA
Hay una pieza que resuelve el problema de la deuda de conocimiento, que es barata, que tiene quince años y que casi nadie usa fuera del mundo técnico. Es un documento de una página con cinco apartados: título, contexto —las fuerzas en juego, incluidas las políticas y las de negocio—, decisión en voz activa, estado y consecuencias. Su autor lo justificó con una frase que vale para cualquier registro: los documentos grandes nunca se mantienen al día; los documentos pequeños y modulares tienen al menos una posibilidad.
El apartado que marca la diferencia, y el que explica por qué las actas de comité no sirven para esto, es el de estado: permite declarar que una decisión ha sido sustituida sin borrarla. Ninguna acta de comité dice «esta decisión queda sustituida por la del comité de octubre». Los casos de negocio registran la justificación pero están diseñados para obtener la aprobación, no para consultarse después, y por eso nadie vuelve a abrirlos. El registro de riesgos sí tiene estado y sí se revisa, pero registra lo que podría pasar, no lo que se decidió. La pieza que falta en el gobierno de negocio no es un sistema: es un formato de una página con un campo que diga si una decisión sigue vigente.
Y aquí está la razón por la que esto deja de ser una buena práctica y pasa a ser una necesidad operativa. Si una parte del trabajo lo ejecutan agentes a partir de instrucciones y de contexto, el registro de decisiones deja de ser documentación y se convierte en entrada del sistema. Un agente que no sabe qué decisiones están vigentes y cuáles fueron sustituidas reproducirá las obsoletas, con la particularidad de que lo hará deprisa, de forma consistente y sin quejarse. La memoria de decisiones pasa de ser una cortesía con los futuros compañeros a ser configuración.
Conviene saber cómo falla esto, porque falla siempre del mismo modo. El registro se convierte en acta de lo que se decidió en otro sitio: nace ya en estado «aceptado», sin recoger las fuerzas en juego ni las alternativas descartadas, que era justamente su función. Si el registro no contiene qué se consideró y se rechazó, no es memoria: es un resumen. El esfuerzo de escribir las dos líneas de lo que se descartó es lo único que distingue un registro útil de un trámite más.
Los próximos noventa días
Nada de lo que sigue necesita presupuesto nuevo, herramienta nueva ni un programa con nombre. Es, deliberadamente, lo más pequeño que se puede hacer y que cambia algo. Y conviene empezar por algo pequeño precisamente porque el diagnóstico de este artículo es que la empresa ya tiene demasiadas cosas grandes en marcha.
En los primeros treinta días, contar lo que ya se puede contar. Cuántos sistemas se apagaron el año pasado y cuántos se encendieron. Cuántas iniciativas de cambio caen a la vez sobre el equipo que peor está respondiendo. Y, en un solo proceso —el que más reclamaciones genere—, cuántos casos se salen del camino estándar. Tres cifras, tres conversaciones con tres personas, ninguna herramienta. La primera de las tres suele ser la que más incomoda, porque en la mayoría de las empresas nadie la tiene y, cuando se calcula, el cociente lleva años por debajo de uno.
Entre los días treinta y uno y sesenta, cambiar un solo formulario. Añadir al caso de inversión un apartado obligatorio que diga qué aplicaciones, procesos, controles o actividades quedan apagados, en qué fecha y con qué firma; exigir que alguien independiente de quien propone valide esa cifra de ahorro; y establecer que sin ese apartado la propuesta no entra en el orden del día. Es literalmente la manipulación experimental que dobló las propuestas de retirada sin reducir ni una de las de adición, aplicada a un comité de inversiones.
Entre los días sesenta y uno y noventa, poner la retirada en el objetivo de alguien con nombre y apellidos. Una persona, con presupuesto propio, con una fecha y con la cifra de sistemas apagados en su retribución variable. Y con la provisión del cargo contable asociado presupuestada por anticipado como partida de la transformación, para que la decisión no dependa de quién tendría que absorber esa pérdida en su cuenta del año. De todos los casos de simplificación documentados que he podido revisar, los que funcionaron tenían esto y los que no funcionaron, no.
Y tres cosas que conviene no hacer en esos noventa días, porque consumen el plazo entero y no cambian nada. No elegir un marco, porque la evidencia dice que la elección de marco explica entre el uno y el dos por ciento de la varianza en efectividad. No crear un comité, porque un comité es el mecanismo que agrega vetos y el problema de la retirada es precisamente un exceso de vetos. Y no prometer ninguna métrica que exija instrumentación nueva, porque llegará tarde y mientras tanto sustituirá la conversación sobre los resultados por una conversación sobre los datos.
Lo que de verdad va a decidir quién gana: velocidad, continuidad y simplificación
Si hay que resumir todo lo anterior en una sola idea, es esta. La ventaja competitiva de los próximos años no estará en la velocidad para adoptar tecnología nueva, sino en la capacidad de absorber cambio sin aumentar proporcionalmente la complejidad estructural de la organización. Adoptar deprisa lo van a hacer todos: las herramientas son las mismas, los proveedores son los mismos y los plazos de disponibilidad son los mismos para todo el mundo. Lo que va a diferenciar a unas empresas de otras es cuánto pesan después de haber adoptado.
Eso se puede expresar como una tensión entre tres capacidades que compiten por el mismo presupuesto y la misma atención directiva. Velocidad, que es introducir capacidades nuevas. Continuidad, que es preservar el propósito, el conocimiento, la responsabilidad y el valor mientras cambia todo lo demás. Y simplificación, que es retirar lo que ha dejado de aportar. Casi todas las empresas tienen dueño para las dos primeras. La tercera no tiene dueño en ninguna parte, y por eso pierde todas las veces.
Conviene cerrar con una cautela, porque lo contrario sería caer en lo que este artículo critica. No estamos todavía en un escenario donde las grandes empresas puedan rediseñar continuamente su modelo operativo gracias a la inteligencia artificial. Las limitaciones de integración, de gobierno, de fiabilidad y de cambio organizativo siguen siendo muy importantes, y buena parte de lo que se vende como disponible sigue en vista previa. Pero el fenómeno que describe este artículo ya existe y no depende de que esas limitaciones se resuelvan: las empresas acumulan generaciones de tecnologías y procesos mucho más deprisa de lo que consiguen retirar las anteriores, y la inteligencia artificial ensancha esa diferencia por los dos extremos a la vez, porque abarata construir y abarata mantener encendido lo que habría que apagar.
Por eso la evolución que viene en la gestión de la transformación no es un marco nuevo ni una oficina nueva. Es un cambio de objeto: pasar de gestionar programas de cambio a gestionar continuamente la evolución y la simplificación de las capacidades de la empresa. Eso cambia el papel de la oficina de transformación, los mecanismos de gobierno, las responsabilidades de punta a punta, los criterios de inversión y la forma de medir el éxito. Y cambia, sobre todo, la pregunta que se hace al aprobar algo.
Resumen ejecutivo: cómo transformar la empresa sin seguir acumulando complejidad
Si de todo este artículo hay que llevarse algo que se pueda repetir en una reunión sin consultar nada, es este párrafo. Está escrito para decirlo en voz alta, no para proyectarlo en una lámina.
Llevamos cinco transformaciones en ocho años, todas cerradas con éxito, y operar el conjunto nos cuesta más que antes. Eso pasa porque cada proyecto se mide por lo que entrega y ninguno por lo que retira, así que acumulamos sistemas, procesos, excepciones y comités sin que nadie responda de la suma. La inteligencia artificial no crea ese problema, pero lo acelera: abarata construir y, sobre todo, abarata mantener encendida una excepción hasta el punto de que deja de doler, y lo que no duele no se arregla. Lo que proponemos no es otro programa. Es contar tres cifras que ya tenemos —cuántos sistemas apagamos frente a los que encendimos, cuántas iniciativas caen a la vez sobre el mismo equipo y cuántos casos se salen del camino estándar—, añadir al caso de inversión un apartado obligatorio que diga qué se apaga, con fecha y con una firma, validado por alguien independiente de quien propone, y poner esa cifra de retirada en el objetivo anual de una persona con presupuesto. Nada de esto es una transformación: es dejar de pagar la de hace cinco años.
El debate del que parte este artículo acertaba al preguntar qué debe permanecer mientras todo cambia, y la respuesta —propósito, conocimiento, responsabilidad, resultados y valor— es correcta. Pero preservar lo valioso no basta si seguimos acumulando procesos, decisiones, estructuras y aplicaciones, porque la capacidad de absorber lo nuevo depende de cuánto espacio hayamos dejado libre. De modo que la pregunta que falta, y que es la que convierte una reflexión interesante sobre continuidad en un planteamiento práctico de transformación, es la segunda: qué debería desaparecer con cada transformación para que la siguiente no tenga que cargar con todo lo anterior.
El primer paso no cuesta una licencia ni un programa: cuesta calcular cuántos sistemas apagó su empresa el año pasado y cuántos encendió. Si el cociente es menor que uno —y casi siempre lo es—, ya tiene el punto de partida de la conversación. Si quiere que miremos juntos cuáles de estas piezas ya tiene su organización y cuáles le faltan, hablemos.
