Entre enero y diciembre de 2025 trabajé en distintos momentos con doce empresas medianas españolas que estaban implementando — o habían intentado implementar — sistemas de IA. Sector mix: tres en servicios legales y fiscales, dos en manufactura, dos en e-commerce con facturación superior a cinco millones, dos en SaaS B2B, y tres en consultoría de distintos tamaños.
El rango iba desde empresas que habían gastado menos de 30.000 euros en un piloto hasta una que había comprometido más de 400.000 en un proyecto de 18 meses con una consultora grande.
El patrón de fracaso era el mismo en once de las doce.
No era la tecnología. No era el talento del equipo técnico. No era el presupuesto.
El patrón: decisión rights vacuum
El patrón lo llamo “decisión rights vacuum”. Nadie — ni el CEO, ni el CTO, ni el responsable del proyecto — tenía autoridad clara para hacer tres cosas:
- Decidir que casos de uso matar cuando no funcionaban
- Definir que outputs del sistema eran aceptables y cuales no
- Establecer que métricas determinaban el éxito o el fracaso real
La consecuencia es siempre la misma: pilotos que siguen vivos durante 18-24 meses sin que nadie pueda explicar por que siguen vivos, sin que nadie pueda cerrarlos sin un coste político alto, y drenando budget y atención de los equipos que los mantienen.
No es inacción por ignorancia. Es inacción por estructura.
Caso 1: la empresa de servicios fiscales con el piloto eterno
Una empresa de asesoría fiscal con 80 empleados lanzó en enero de 2024 un piloto de automatización de revisión de declaraciones. El objetivo inicial: reducir el tiempo de revisión manual en un 40%.
A finales de 2025, el piloto seguía activo. Habían pasado 22 meses.
Cuando entré a revisar la situación, el sistema procesaba alrededor del 15% de las declaraciones que estaban en scope original. El resto seguían con revisión manual. La tasa de intervención humana en los outputs del sistema era superior al 80% — es decir, más de 8 de cada 10 outputs del sistema requerían corrección o validación extensa antes de poder usarse.
Pregunte quién tenía autoridad para cerrar el piloto si no llegaba a los objetivos. Nadie supo responder con claridad. El CTO dijo que era decisión de negocio. El socio director dijo que era una decisión técnica. El responsable del proyecto había cambiado dos veces.
El piloto seguía activo porque nadie tenía el mandato — y el coste político aceptado — de cerrarlo.
La inversión total hasta ese punto: superior a 120.000 euros entre licencias, horas de integración y tiempo de equipo interno.
Caso 2: el e-commerce con tres sistemas de recomendación
Un e-commerce con facturación anual de unos ocho millones de euros tenía, cuando hice el diagnóstico, tres sistemas de recomendación de producto activos en paralelo. No de forma experimental controlada. Los tres estaban en producción, sirviendo recomendaciones a distintos segmentos de usuarios o en distintas partes del funnel, sin que ningún equipo tuviera una vista unificada de cual funcionaba mejor.
Cada uno tenía su defensor interno. El equipo de marketing defendía el primero porque había visto un aumento de conversión en el periodo que siguió a su lanzamiento. El equipo de producto defendía el segundo porque había mejorado el AOV en algunas categorías. IT era responsable del tercero, que era el más nuevo y sobre el que habían invertido más horas de desarrollo.
Nadie tenía autoridad para cerrar dos de los tres. El CEO sabia que la situación era ineficiente pero no quería crear conflicto entre equipos antes de tener datos “definitivos”.
El problema: los datos nunca son definitivos si no hay criterio previo de lo que define éxito. Con tres sistemas en producción mezclando señales, los datos de cada uno estaban contaminados por los otros dos.
El coste: licencias de los tres sistemas, horas de mantenimiento y el coste de oportunidad de no tener un sistema único bien optimizado.
La solución no era técnica. Era quien tenía mandato para decidir.
Caso 3: la consultora con el proyecto de 18 meses
Esta es la más común en empresas con más de 200 empleados y presupuesto más holgado.
Una consultora de 180 personas había contratado a una firma grande para implementar un sistema de “asistente IA” para sus consultores. El proyecto tenía 18 meses de plazo, un precio superior a 300.000 euros, y una promesa de “reducción significativa de tiempo en tareas de documentación y research”.
Al mes 14, el sistema estaba técnicamente funcionando. Los consultores lo usaban ocasionalmente. La tasa de adopción voluntaria era de alrededor del 20%.
El problema no era la calidad del sistema. El sistema era competente para las tareas para las que había sido construido.
El problema era que nadie había definido, antes de firmar el contrato, que significaba “reducción significativa”. No había baseline documentado del tiempo actual en documentación y research. No había métrica acordada de adopción. No había criterio de éxito que permitiera decir, al mes 18, si el proyecto había funcionado o no.
En la reunión de cierre del proyecto, el proveedor presento datos de uso del sistema. La empresa presento la sensación general del equipo directivo. Nadie pudo decir con datos si 300.000 euros habían sido una buena inversión o no.
El contrato de mantenimiento se renovó.
Por que el vacuum ocurre
El decisión rights vacuum en implementaciones IA no es un accidente. Tiene causas estructurales:
La IA llega como iniciativa transversal. Cruza IT, operaciones, producto y negocio. Cuando algo es responsabilidad de todos, no es responsabilidad de nadie.
Nadie quiere ser quien mata la iniciativa. Si el piloto falla después de que alguien lo cierra, esa persona asume el coste político. Si el piloto falla solo, el coste se diluye. El incentivo es mantener el piloto vivo.
Los criterios de éxito son vagos por diseño. Cuando los criterios son imprecisos (“mejorar la eficiencia”, “aumentar la productividad”), es imposible determinar cuando se ha fallado. Eso es conveniente para el proveedor y para el champion interno del proyecto.
El presupuesto ya está comprometido. Una vez que una empresa ha gastado 80.000 euros en un piloto, cerrar el piloto convierte ese gasto en perdida visible. Seguir gastando 20.000 más parece menos doloroso, aunque económicamente sea peor.
El diagnóstico en 20 minutos
Hay tres preguntas que uso para diagnosticar si una implementación IA tiene este patrón en cinco minutos de conversación con el CEO o COO:
-
Si el sistema de IA falla en alcanzar sus objetivos, quien tiene autoridad para cerrarlo sin necesitar aprobación de más de dos personas?
-
Cual es la métrica numérica que define éxito a 90 días, y quien la fijo antes de que el proyecto empezara?
-
Si tuvieras que parar este proyecto hoy, que pasaría exactamente — quien lo decidiría, con que proceso, y cual seria el coste operativo real?
Si las respuestas son ambiguas o la persona no puede responder en menos de dos minutos, el decisión rights vacuum esta presente.
Lo que un Fractional CAIO resuelve aquí
La promesa de un Fractional CAIO no es “hacer que la IA funcione”. Es instalar gobierno operativo para que las decisiones sobre IA — incluyendo la de cerrar lo que no funciona — tengan owner, criterio y proceso.
Las tres cosas concretas que resuelve en este contexto:
Kill criteria antes de lanzar: ningún piloto arranca sin una definición escrita de que condiciones activan el cierre. Eso no es pesimismo; es lo que hace que los pilotos que siguen adelante tengan mandato real.
Decisión rights explícitos: quien puede parar, quien aprueba continuar, y bajo que criterios. Una tabla de una página. No un framework.
Baseline y métrica pre-acordada: la métrica de éxito se define y documenta antes de que empiece el proyecto, no después. Si el proveedor no acepta una métrica de éxito pre-acordada, eso dice algo sobre sus incentivos.
La doceava empresa — la que no tenía este patrón — tenía estas tres cosas. No era la más sofisticada técnicamente. Tenía el owner más claro y el criterio de cierre más explícito. Su piloto acabó en seis meses, con una decisión documentada de escalar. El proceso fue aburrido y efectivo.
Next action
Si tienes un piloto de IA activo desde hace más de seis meses, hazte esta pregunta: si tuvieras que cerrarlo mañana, quien toma la decisión, con que criterio, y con que proceso?
Si no puedes responder en un párrafo, tienes un decisión rights vacuum. Resolver eso no requiere más tecnología. Requiere una conversación sobre mandato y criterio.
Para un diagnóstico de gobierno de IA en tu empresa, entra en contacto o abre una sesión en cal.com/brthls.
Para el perfil completo del rol, lee Que hace realmente un Fractional CAIO (y cuando no lo necesitas).