Los proyectos de IA empresarial rara vez se estancan porque falle la tecnología. Lo más habitual es que, tras un piloto exitoso, choquen con barreras de gestión y responsabilidad. Jean-François Clercx explica por qué el ownership debe diseñarse desde el inicio de cualquier iniciativa de IA, y qué cambia cuando la gestión forma parte del proceso de construcción.
Ideas clave
- El «vacío de ownership» significa que ningún líder asume el resultado, lo que deja a la mayoría de los proyectos de IA atascados entre 6 y 18 meses después de un piloto exitoso.
- Construir primero y gestionar después genera bloqueos de compliance que echan por tierra un buen trabajo, incluso cuando la IA en sí funciona bien.
- La gestión integrada en el proceso desde el principio es lo que lleva la IA a producción. Los resultados lo demuestran: más de un 50 % de mejora en eficiencia frente a un 5-10 % cuando solo se añaden herramientas.
En los últimos dieciocho meses he participado en muchas conversaciones sobre IA empresarial. El patrón es casi siempre el mismo. Llegan los resultados del piloto de IA: buenas cifras, un caso de uso sólido, el equipo ha hecho un trabajo real. La sala está entusiasmada. Y entonces alguien hace unas preguntas que lo cambian todo: ¿quién es responsable de los resultados que genera?, ¿qué estructura de costes tenemos definida?, ¿cumple con toda nuestra normativa?, ¿cómo estamos en materia de seguridad? El silencio que sigue nunca es cómodo, porque la gestión de la IA no es opcional, y nuestros clientes lo saben.
En mi trabajo en Mimacom veo en la práctica lo que confirman los datos: solo el 33 % de los pilotos de IA empresarial llega a producción. En 2025, una iniciativa abandonada costó de media 7,2 millones de dólares.
Si miramos de cerca el motivo, casi nunca es la tecnología. El obstáculo principal es lo que los analistas llaman el «vacío de ownership»: los data scientists son responsables del experimento, pero ningún líder de negocio asume el resultado. Sin eso, no hay nadie con la autoridad ni la responsabilidad para tomar la decisión de pasar a producción. Esa brecha (no el rendimiento del modelo, ni la calidad de los datos, ni la infraestructura) es lo que mantiene a la mayoría de los proyectos de IA atrapados entre seis y dieciocho meses en el «purgatorio del piloto».
A menudo, las empresas lo plantean como un problema de escalado tecnológico. Por lo que veo en las conversaciones con clientes, es un problema de arquitectura de responsabilidad. Y ambos requieren soluciones muy distintas.
Una conversación a la que vuelvo una y otra vez
Hace unos meses tuve una conversación con un cliente que se me quedó grabada. El responsable de soporte de una gran empresa había pasado tres meses construyendo una aplicación de IA con su equipo. Automatizaba una parte importante de su flujo de soporte interno. El negocio la adoraba, el equipo estaba orgulloso de ella. Nunca llegó a salir a producción. No porque no funcionara, sino porque se bloqueó en la fase de gestión. El equipo de gestión de TI hizo las preguntas correctas: ¿con qué datos trabaja el modelo?, ¿cómo se registran las decisiones?, ¿qué ocurre cuando genera un resultado que afecta a una interacción con un cliente y alguien pregunta por qué?
Nadie había construido la aplicación pensando en responder esas preguntas. La IA funcionaba bien; lo que faltaba era la infraestructura de responsabilidad. Y ese es un tipo de fallo muy distinto, y mucho más caro, que el de una tecnología que no funciona. No creo que esto pase por descuido de los equipos: es realmente difícil diseñar para la responsabilidad antes de saber qué se va a construir. La gestión se añade al final porque necesita algo que gestionar.
La pregunta sobre responsabilidad para la que nadie estaba preparado
El 40 % de los consejeros de administración señaló la IA como el tema más difícil de supervisar en 2026. Lo que preocupa a los consejos es exactamente lo que sigo viendo en las conversaciones con clientes: cuando un sistema de IA genera un resultado que afecta a una decisión de un cliente, a un proceso de negocio o a una presentación regulatoria, ¿quién responde por ello?
Tres públicos acaban haciendo esa pregunta: el legal, el cliente y la gestión central de TI. Por experiencia, tarde o temprano se encuentran. Pero normalmente eso ocurre cuando ya hay un problema que impide que la IA genere valor.
El legal, el cliente y la gestión de TI siempre acaban encontrándose. La pregunta es si tu proyecto de IA sobrevive a esa conversación.
Jean-François Clercx, VP Customer Success & Strategic Alliances, Mimacom
Por qué el valor de la IA viene de las personas que asumen la responsabilidad
Vale la pena detenerse en los datos. El informe DORA 2025 de Google Cloud encontró que el 70 % del valor de una transformación de IA proviene de las personas, los procesos y el cambio organizativo, no de la tecnología en sí. Sin embargo, solo el 37 % de las organizaciones había invertido de forma significativa en gestión del cambio, incentivos o formación junto a sus despliegues de IA. Esa brecha entre dónde viene realmente el valor y dónde va realmente la inversión es un reto de responsabilidad, ownership y gobernanza en general.
Y las tendencias actuales lo agravan: unos requisitos de due diligence cada vez mayores por parte de los clientes, una regulación creciente como la Ley de IA de la UE, y marcos de gestión central de TI cada vez más estructurados avanzan todos en la misma dirección: el listón de la responsabilidad sube más rápido de lo que la mayoría de los procesos de construcción han sabido adaptarse.
Cómo es en la práctica la gestión integrada
Prefiero darte un ejemplo concreto antes que un principio.
A principios de este año, Mimacom trabajó con una empresa alemana de SaaS del sector HR tech. Su plataforma de reclutamiento funciona en más de 2.000 portales de empleo y gestiona cinco variantes distintas de código base, con un equipo de desarrollo que ya había empezado a adoptar herramientas de IA de forma informal. El reto era uno conocido: la adopción de IA estaba ocurriendo, pero sin estructura. Sin marco de gestión, sin directrices para datos personales, sin marco para la Ley de IA de la UE. Cada cambio arriesgaba regresiones que solo salían a la luz en producción.
Lo que construimos con ellos no fue un conjunto de herramientas añadidas al flujo de trabajo existente. Fue una transformación que partió de la gestión como restricción de diseño, no como último paso.
Los primeros resultados medibles llegaron en ocho semanas. La eficiencia de ingeniería mejoró más de un 50 %, con el mismo equipo y sin contratar a nadie más. Los equipos que habían adoptado herramientas de IA sin transformar el flujo de trabajo veían mejoras de entre un 5 y un 10 %. La diferencia no estaba en la tecnología, sino en si la gestión se diseñaba desde el principio o se añadía al final.
La pregunta sobre responsabilidad será cada vez más difícil de ignorar
La Ley de IA de la UE. Unas expectativas de due diligence cada vez mayores por parte de los clientes. Una gestión central de TI cada vez más estructurada. No son tendencias que vayan a remitir.
Las aplicaciones de IA pueden salir a producción rápido. Solo necesitan un punto de partida distinto. Ese es el cambio que creo que necesita la mayoría de los equipos empresariales: no un paso de gestión más grande al final, sino un punto de partida diferente. Los equipos que construyen pensando en la responsabilidad desde el principio consiguen lanzar. Obtienen mejores resultados y pasan menos tiempo en el ciclo de construir, bloquear y reconstruir. Los que sigan añadiendo la gestión al final seguirán chocando contra la misma pared.
Si estás lidiando con esto, si estás construyendo capacidades de IA en tu organización y te topas con el problema de la responsabilidad, estaré encantado de hablarlo contigo.
