La inteligencia artificial acelera ese proceso hasta un punto en el que tecnología y negocio van de la mano formando parte de una misma conversación.

A medida que avanzó el Executive Intelligence Power Circle comenzó a consolidarse una idea compartida. El valor vuelve a desplazarse. Durante mucho tiempo la diferenciación estuvo asociada al conocimiento técnico. Hoy, a medida que ese conocimiento se democratiza, el valor se desplaza de forma más evidente hacia la capacidad para comprender el negocio, interpretar prioridades, conectar disciplinas y transformar oportunidades en decisiones ejecutables. Ese cambio modifica también el papel del liderazgo tecnológico.

El análisis también abordó la forma en que deben evolucionar las organizaciones para facilitar esa convergencia. Los modelos transversales. La proximidad entre innovación y operación. La capacidad para influir sin depender exclusivamente de estructuras jerárquicas. Y la creación de equipos multidisciplinares. Todo ello apareció como un elemento decisivo para acelerar la adopción y evitar que la tecnología evolucione desconectada de las prioridades reales del negocio.

Hubo una reflexión final que merece especial atención. La excelencia tecnológica sigue siendo necesaria. Pero deja de ser suficiente. El liderazgo tecnológico pasa a medirse por su capacidad para generar impacto sobre el negocio, acelerar la ejecución y construir valor de forma colaborativa.

El primer desafío es el dato. La IA ha elevado su importancia a otro nivel: puede haber datos sin IA, pero no hay IA útil sin dato fiable. Durante años hemos hablado de organizaciones data-driven, pero la IA obliga a profundizar. No basta con acumular información. Hay que saber qué datos son críticos, quién responde por ellos, qué calidad tienen, qué trazabilidad ofrecen, bajo qué reglas pueden usarse y si están preparados para alimentar decisiones, automatizaciones o agentes inteligentes. Una mala estrategia de dato no solo limita la analítica tradicional. En un entorno de IA, amplifica errores, sesgos, duplicidades y decisiones basadas en contextos incompletos. Por eso, el dato debe gestionarse como un activo estratégico: con propósito, gobierno, calidad, acceso seguro y responsabilidad clara. La ventaja no estará solo en el modelo, sino en el contexto que lo alimenta.

Y para terminar, uno de los grandes desafíos: cómo gobernar toda esa descentralización y heterogeneidad de la tecnología. La capacidad tecnológica ya no reside únicamente en IT. Las áreas de negocio compran soluciones, construyen automatizaciones, consumen datos, experimentan con IA y rediseñan parte de sus procesos. Esta realidad acelera la innovación, pero también puede generar fragmentación, duplicidades, riesgos de seguridad y regulatorios, costes ocultos y arquitecturas difíciles de escalar. La respuesta no puede ser volver a centralizar todo ni frenar la iniciativa del negocio. El reto es construir un modelo federado: autonomía cerca del negocio, pero con estándares comunes, plataformas reutilizables y criterios claros de arquitectura, seguridad, dato, cumplimiento y retorno. Innovar de forma distribuida, sí; pero sin perder coherencia, control ni capacidad de escalar.

Este desplazamiento tendrá implicaciones directas sobre el valor de los partners. Ya no será suficiente con aportar metodologías genéricas, mejores prácticas o conocimiento empaquetado. En un entorno donde la inteligencia es más accesible, el valor diferencial estará en ayudar a cada organización a interpretar mejor su propio contexto, tomar decisiones más informadas y acelerar la transformación sin perder criterio.

Una de las ideas centrales que compartí es que la IA no elimina al partner; elimina al partner indiferenciado. La contradicción entre vender soluciones de IA y que el cliente pueda utilizarlas para prescindir de nosotros solo existe si entendemos nuestro valor como capacidad, velocidad o ejecución. Si el papel del partner se limita a aportar horas, equipos o conocimiento técnico fácilmente replicable, entonces la IA representa una amenaza evidente. Pero si el partner actúa como un socio estratégico, capaz de ayudar al cliente a capturar valor, construir capacidades propias y transformar su operación, la IA no reduce su relevancia: la multiplica.

En sectores como Travel, Transportation & Logistics (TTL en adelante) esto se ve con mucha claridad. Una cosa es utilizar IA para automatizar la atención al cliente o acelerar determinados análisis operativos. Otra muy distinta es rediseñar cómo una aerolínea, un operador logístico, un aeropuerto o una compañía de transporte responde ante una disrupción crítica, optimiza activos, mejora la puntualidad, reduce kilómetros en vacío, gana resiliencia o disminuye su consumo energético. La tecnología por sí sola no transforma una operación crítica. Para hacerlo hacen falta criterio, conocimiento sectorial, integración, gobierno, adopción y cambio operativo.

También abordamos una cuestión clave: la propiedad de la inteligencia generada cuando un modelo se entrena o ajusta con datos y procesos del cliente. Mi posición es clara: debemos ser radicalmente transparentes. Los datos del cliente, sus procesos y la inteligencia específica generada sobre su negocio son activos estratégicos del cliente y deben protegerse como tales. El partner puede reutilizar metodologías, aceleradores y conocimiento genérico, pero nunca información confidencial ni aprendizajes específicos que comprometan la ventaja competitiva de un cliente.

De cara a los próximos años, creo que el valor diferencial del partner estará en tres dimensiones: criterio, conocimiento sectorial y capacidad de transformación. La tecnología será cada vez más accesible y la ejecución más automatizable, pero convertir IA en impacto seguirá siendo difícil. Además, la IA no es gratis: exige decisiones sobre coste, eficiencia, arquitectura, gobierno, consumo de tokens, seguridad y escalabilidad. El negocio no compra IA; compra resultados. Y en TTL esos resultados tienen nombres muy concretos: puntualidad, utilización de activos, reducción de costes, resiliencia, seguridad, sostenibilidad y experiencia de cliente.

La mesa también me permitió reflexionar sobre la evolución de los modelos comerciales. El modelo por horas pierde fuerza cuando la IA cambia radicalmente la productividad. Los modelos ligados a impacto tienen sentido, pero exigen madurez, métricas claras, gobierno compartido y capacidad real del partner para influir en el resultado. En TTL existen casos naturales: reducción de kilómetros en vacío, mejora de puntualidad, reducción de logística inversa, eficiencia energética o mantenimiento predictivo. Pero el impacto no depende solo de la tecnología; depende también de procesos, adopción, incentivos, liderazgo y decisiones operativas del cliente.

Quienes trabajábamos en tecnología en aquella época recordamos bien la expectativa. Las API iban a abrir las capacidades de negocio de las compañías, a facilitar la creación de ecosistemas con terceros y a acelerar la innovación al permitir que otros construyeran sobre nuestras capacidades. La promesa era real, tanto que hoy resulta difícil imaginar una estrategia digital sin ellas, aunque el camino no fue tan directo como anticipaban las presentaciones de la época. La facilidad para publicar una API hizo que proliferaran sin catálogo ni criterio común: versiones que se rompían, políticas de seguridad que dependían del equipo que las había construido y, cuando un consumidor externo tenía un problema, la incómoda constatación de que nadie respondía por aquella interfaz.

Mi impresión es que con los agentes tenemos pendiente esa misma transición, del agente como proyecto al agente como producto, con un matiz que conviene no perder de vista: una API ejecuta lo que se le pide, mientras que un agente decide qué hacer para conseguir un objetivo. La delegación es de otra naturaleza y por eso el contrato también debe serlo. Ya no basta con describir una interfaz; hay que hacer explícito qué decisiones puede tomar el agente por sí mismo, sobre qué sistemas, con qué datos y cuáles debe elevar a una persona. El propietario ya no responde solo de la disponibilidad, sino de las consecuencias de esas decisiones, lo que exige nombrarlo antes del primer despliegue y no después del primer incidente.

Los números dimensionan el salto. Una organización media convive ya con más de doce agentes, la mitad operando en silos, y Gartner proyecta más de 150.000 por gran empresa en 2028, partiendo de menos de quince en 2025. Es un cambio de escala que rompe cualquier modelo pensado para desplegar soluciones una a una. Y el gobierno no acompaña: solo el 21 % de las organizaciones dice tener un modelo maduro para gobernar agentes, y Gartner anticipa que en 2027 el 40 % tendrá que degradar o retirar agentes autónomos por fallos detectados solo tras un incidente en producción. La adopción ha dejado de ser la pregunta. La pregunta es el gobierno.

Gobernar una flota distribuida tiene una dificultad concreta: no está en un sitio, está repartida por todas partes. Cada agente vive en un entorno distinto —CRM, nube, ofimática, desarrollos propios— y cada entorno gobierna solo lo suyo, con su consola, sus reglas y su factura. Nadie gobierna por encima. Esa es, para mí, la raíz del problema: no nos falta tecnología, nos falta una capa transversal que aplique las mismas reglas a lo que hoy nadie controla de forma conjunta.

Esto enlaza con la accountability, hoy más literal de lo que parece. Las identidades no humanas —agentes, tokens, cuentas de servicio— ya superan a las humanas en una proporción cercana a 45 a 1, y hasta 144 a 1 en entornos nativos de nube. Si no asignamos a cada agente una identidad, una autorización y un responsable, la pregunta «¿quién responde?» no tiene respuesta: la trazabilidad se vuelve inviable justo cuando más la necesitamos. La accountability no puede improvisarse cuando el daño ya ocurrió; tiene que estar definida antes.