La promesa era enorme: automatizar más, decidir mejorar y ahorrar tiempo. Pero la realidad de muchos proyectos de inteligencia artificial está siendo mucho menos brillante de lo que prometían las presentaciones, con pilotos que se quedan en pruebas¹, inversiones que no escalan² y resultados que nunca llegan a traducirse en valor real para el negocio.

Pero lo importante no es cuántos fracasan. Lo importante es cuándo fracasan.

Llevo años trabajando en proyectos de datos e IA en firmas como KPMG, Capgemini, PwC, SDG Group y Accenture, en sectores muy distintos: salud, energía, banca, retail, principalmente. Y lo que he visto, una y otra vez, es que los proyectos no fracasan al final, cuando el modelo no ofrece los resultados esperados o la infraestructura flaquea. Fracasan al principio. Antes de que se haya escrito una línea de código.

Fracasan porque nadie se ha sentado a responder tres preguntas básicas.

No es el proyecto. El problema "Queremos implementar IA generativa" no es un problema. Es una solución buscando problema. Cuando alguien dice que quiere automatizar la generación de informes con IA, mi primera pregunta es: ¿por qué se generan esos informes? ¿Quién los lee? ¿Qué decisión se toma con ellos?

En más de una ocasión, la respuesta suele ser un silencio incómodo. Y entonces queda claro que no hace falta IA, hace falta repensar un proceso.

Las tres condiciones son acumulativas. Que existan no significa que sean fiables. Que sean fiables no significa que tengas derecho a entrenarlos. Y aquí es donde la mayoría de proyectos se estrellan sin darse cuenta. Un modelo entrenado sobre datos mal gobernados no es un activo, es una bomba de relojería.

Cuando el regulador pregunte, cuando un cliente se queje, cuando un auditor mire, la respuesta "lo sacamos de esta base de datos" no basta.

Porque sin respaldo de dirección, sin colaboración entre equipos técnicos y de negocio, sin criterio jurídico que acompañe, cualquier proyecto acaba siendo un proyecto huérfano. Y los proyectos huérfanos mueren.

Lo interesante es que estas tres preguntas no son técnicas. Son estratégicas, de gobierno y regulatorias. Exactamente los tres ángulos que normalmente no se cruzan en una reunión de proyecto. El responsable técnico habla de modelos. El de negocio, de objetivos. El jurídico llega al final, cuando ya no se puede cambiar nada.

Criterio existe para habitar ese espacio, el punto donde las tres conversaciones tienen que cruzarse antes de que empiece cualquier proyecto. No para dar respuestas fáciles, sino para formular mejores preguntas.

Porque la IA no decide sin datos. Los datos no permiten tomar decisiones sin un marco de gobierno apropiado. Y un marco de gobierno que no vaya de la mano de la regulación no resuelve nada por sí mismo.

Lo que SI decide es el criterio con el que se usan.

◆ ◆ ◆

Las primeras obligaciones del Reglamento entraron en vigor hace unos meses. En 2026 se activan las obligaciones relativas a modelos de propósito general siendo el 2 de agosto la fecha límite para su aplicación plena, con multas que pueden llegar hasta el 7% de la facturación global o 35 millones de euros.

El debate relevante ya no es qué modelo es más capaz, es cuál es más auditable, explicable y defendible ante un cliente, un regulador o un comité de riesgos. La dimensión de "defensibilidad" va a separar a los proveedores viables de los que no.

Anthropic pone el acento en la “IA constitucional” y en la seguridad del comportamiento del modelo, mientras que OpenAI empuja más fuerte en amplitud de capacidades y ecosistema.

En España, por ejemplo, se afirma que el 72% de los CAIO informa directamente al CEO o COO, superando al promedio global (57%) aunque solo la mitad controla el presupuesto de IA, lo que apunta a una influencia todavía incompleta.

La pregunta clave es si ese rol tiene poder real o es cosmético. Sin presupuesto, sin reporting directo al CEO y sin autoridad sobre datos, el CAIO es un título vacío, por lo que su impacto todavía depende mucho del diseño organizativo.

◆ ◆ ◆

Hace unos meses, un cliente me pidió construir un reporte que le permitiera consultar y consumir de forma automatizada la información financiera anualizada de su compañía. Sus informes mensuales estaban separados, y la idea parecía clara: consolidarlos en una herramienta que hiciera ese trabajo por ellos.

Empezamos a construir y enseguida apareció el problema. El nombre de los descriptores, los códigos de negocio y, en definitiva, la propia información financiera variaban entre periodos. Lo que en enero se llamaba de una forma, en septiembre se llamaba de otra. Los mismos ingresos aparecían reportados bajo dos etiquetas distintas según el mes. No era un problema de herramientas. Era un problema de gobierno del dato inexistente.

Lo que empezó como una petición de automatización terminó siendo una propuesta de proyecto distinta: lanzar un trabajo de gobierno del dato aplicado que armonizara la información histórica y, sobre todo, definiera reglas claras para que este desalineamiento no volviera a producirse. Sin esa base, cualquier reporte automático habría sido un generador automatizado de inconsistencias.

A veces la petición del cliente describe lo que quiere ver, no lo que necesita arreglar. El trabajo del consultor no es entregar la herramienta solicitada. Es saber identificar cuándo esa herramienta no va a funcionar sin resolver antes algo más profundo.

◆ ◆ ◆

Un libro que se lee en un fin de semana y que cambia la manera de pensar qué significa construir una organización "con IA dentro" en lugar de "usar IA".

Si tuvieras que identificar en tu organización un único proyecto de IA o datos que está avanzando sin haber respondido a las tres preguntas del principio — ¿cuál sería, y qué crees que pasará cuando llegue a producción?

Me interesa leer tu respuesta. Contesta directamente a este email o escríbeme en LinkedIn.

Hasta el próximo número.

Guillermo