Entre enero y diciembre de 2025 trabajé en distintos momentos con doce empresas medianas espanolas que estaban implementando — o habian intentado implementar — sistemas de IA. Sector mix: tres en servicios legales y fiscales, dos en manufactura, dos en e-commerce con facturacion superior a cinco millones, dos en SaaS B2B, y tres en consultoría de distintos tamaños.
El rango iba desde empresas que habian gastado menos de 30.000 euros en un piloto hasta una que habia comprometido mas de 400.000 en un proyecto de 18 meses con una consultora grande.
El patron de fracaso era el mismo en once de las doce.
No era la tecnologia. No era el talento del equipo tecnico. No era el presupuesto.
El patron: decision rights vacuum
El patron lo llamo “decision rights vacuum”. Nadie — ni el CEO, ni el CTO, ni el responsable del proyecto — tenia 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 metricas determinaban el exito 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 politico alto, y drenando budget y atencion de los equipos que los mantienen.
No es inaccion por ignorancia. Es inaccion 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 revision manual en un 40%.
A finales de 2025, el piloto seguia activo. Habían pasado 22 meses.
Cuando entré a revisar la situacion, el sistema procesaba alrededor del 15% de las declaraciones que estaban en scope original. El resto seguian con revision manual. La tasa de intervencion humana en los outputs del sistema era superior al 80% — es decir, mas de 8 de cada 10 outputs del sistema requerian correccion o validacion extensa antes de poder usarse.
Pregunte quién tenia autoridad para cerrar el piloto si no llegaba a los objetivos. Nadie supo responder con claridad. El CTO dijo que era decision de negocio. El socio director dijo que era una decision tecnica. El responsable del proyecto habia cambiado dos veces.
El piloto seguia activo porque nadie tenia el mandato — y el coste politico aceptado — de cerrarlo.
La inversion total hasta ese punto: superior a 120.000 euros entre licencias, horas de integracion y tiempo de equipo interno.
Caso 2: el e-commerce con tres sistemas de recomendacion
Un e-commerce con facturacion anual de unos ocho millones de euros tenia, cuando hice el diagnostico, tres sistemas de recomendacion de producto activos en paralelo. No de forma experimental controlada. Los tres estaban en produccion, sirviendo recomendaciones a distintos segmentos de usuarios o en distintas partes del funnel, sin que ningun equipo tuviera una vista unificada de cual funcionaba mejor.
Cada uno tenia su defensor interno. El equipo de marketing defendia el primero porque habia visto un aumento de conversion en el periodo que siguio a su lanzamiento. El equipo de producto defendia el segundo porque habia mejorado el AOV en algunas categorias. IT era responsable del tercero, que era el mas nuevo y sobre el que habian invertido mas horas de desarrollo.
Nadie tenia autoridad para cerrar dos de los tres. El CEO sabia que la situacion era ineficiente pero no queria 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 exito. Con tres sistemas en produccion 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 unico bien optimizado.
La solucion no era tecnica. Era quien tenia mandato para decidir.
Caso 3: la consultora con el proyecto de 18 meses
Esta es la mas comun en empresas con mas de 200 empleados y presupuesto mas holgado.
Una consultora de 180 personas habia contratado a una firma grande para implementar un sistema de “asistente IA” para sus consultores. El proyecto tenia 18 meses de plazo, un precio superior a 300.000 euros, y una promesa de “reduccion significativa de tiempo en tareas de documentacion y research”.
Al mes 14, el sistema estaba tecnicamente funcionando. Los consultores lo usaban ocasionalmente. La tasa de adopcion voluntaria era de alrededor del 20%.
El problema no era la calidad del sistema. El sistema era competente para las tareas para las que habia sido construido.
El problema era que nadie habia definido, antes de firmar el contrato, que significaba “reduccion significativa”. No habia baseline documentado del tiempo actual en documentacion y research. No habia metrica acordada de adopcion. No habia criterio de exito que permitiera decir, al mes 18, si el proyecto habia funcionado o no.
En la reunion de cierre del proyecto, el proveedor presento datos de uso del sistema. La empresa presento la sensacion general del equipo directivo. Nadie pudo decir con datos si 300.000 euros habian sido una buena inversion o no.
El contrato de mantenimiento se renovó.
Por que el vacuum ocurre
El decision 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 despues de que alguien lo cierra, esa persona asume el coste politico. Si el piloto falla solo, el coste se diluye. El incentivo es mantener el piloto vivo.
Los criterios de exito 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 esta 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 mas parece menos doloroso, aunque economicamente sea peor.
El diagnostico en 20 minutos
Hay tres preguntas que uso para diagnosticar si una implementacion IA tiene este patron en cinco minutos de conversacion con el CEO o COO:
-
Si el sistema de IA falla en alcanzar sus objetivos, quien tiene autoridad para cerrarlo sin necesitar aprobacion de mas de dos personas?
-
Cual es la metrica numerica que define exito a 90 dias, y quien la fijo antes de que el proyecto empezara?
-
Si tuvieras que parar este proyecto hoy, que pasaria exactamente — quien lo decidiria, 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 decision rights vacuum esta presente.
Lo que un Fractional CAIO resuelve aqui
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: ningun piloto arranca sin una definicion escrita de que condiciones activan el cierre. Eso no es pesimismo; es lo que hace que los pilotos que siguen adelante tengan mandato real.
Decision rights explicitos: quien puede parar, quien aprueba continuar, y bajo que criterios. Una tabla de una pagina. No un framework.
Baseline y metrica pre-acordada: la metrica de exito se define y documenta antes de que empiece el proyecto, no despues. Si el proveedor no acepta una metrica de exito pre-acordada, eso dice algo sobre sus incentivos.
La doceava empresa — la que no tenia este patron — tenia estas tres cosas. No era la mas sofisticada tecnicamente. Tenia el owner mas claro y el criterio de cierre mas explicito. Su piloto acabó en seis meses, con una decision documentada de escalar. El proceso fue aburrido y efectivo.
Next action
Si tienes un piloto de IA activo desde hace mas de seis meses, hazte esta pregunta: si tuvieras que cerrarlo manana, quien toma la decision, con que criterio, y con que proceso?
Si no puedes responder en un parrafo, tienes un decision rights vacuum. Resolver eso no requiere mas tecnologia. Requiere una conversacion sobre mandato y criterio.
Para un diagnostico de gobierno de IA en tu empresa, entra en contacto o abre una sesion en cal.com/brthls.
Para el perfil completo del rol, lee Que hace realmente un Fractional CAIO (y cuando no lo necesitas).