Hace unas semanas estuve en una sesión de consejo con una empresa manufacturera mediana. El equipo directivo llegó orgulloso: habían implementado inteligencia artificial en tres áreas de la operación en menos de seis meses. Un modelo de forecasting de demanda, un asistente para servicio a cliente, automatización en el proceso de compras. Todo funcionando. Todo con dashboards impecables.
Le hice al director general la única pregunta que importa en ese momento: “¿qué decisión de negocio están tomando distinto gracias a esto?”
Silencio. Después, una respuesta genérica sobre “eficiencia” que no aterrizaba en ningún número. Revisamos juntos los tres proyectos y la conclusión fue incómoda: tenían tecnología corriendo en tres frentes y ningún KPI de negocio que se hubiera movido. No había pipeline más rápido, ni margen mejor, ni desperdicio a la baja. Tenían dashboards. No tenían resultados.
Ese consejo no tiene un problema de tecnología. Tiene un problema de gobierno. Y es el mismo problema que veo repetirse, con variaciones menores, en la mayoría de los proyectos de datos e IA que llegan a los consejos donde participo. La decisión que arruina el proyecto no ocurre durante la implementación. Ocurre antes — en la conversación que nadie audita, cuando se aprueba el presupuesto sin haber definido qué significa éxito.
El mito de la tecnología: implementar no es transformar
La confusión más costosa en los consejos mexicanos hoy es tratar “implementación” y “transformación” como sinónimos. No lo son, y la diferencia no es semántica — es la diferencia entre gastar capital y generar retorno.
Implementar es instalar una capacidad. Transformar es cambiar una decisión de negocio de forma sostenida y medible. Puedes tener un modelo de forecasting corriendo en producción, con datos limpios, con una interfaz elegante, y seguir tomando exactamente las mismas decisiones de compra que tomabas antes de tenerlo. Eso no es transformación. Es tecnología decorativa con presupuesto aprobado.
El error de origen es tratar la tecnología como el objetivo del proyecto. No lo es. Es un habilitador. El objetivo es la decisión de negocio que va a cambiar — cuánto inventario compras, a qué cliente le das prioridad, qué línea de producción detienes antes de que falle. Si ese cambio de decisión no está definido con precisión antes de escribir una línea de código o firmar un contrato de licencias, el proyecto ya fracasó, aunque tarde dieciocho meses en notarse.
Esto es lo que le digo a cualquier consejo que llega pidiendo “aprobar el roadmap de IA”: el roadmap no es la pregunta. La pregunta es qué decisión distinta va a tomar la organización el día después de que el roadmap esté implementado. Si nadie en la sala puede responder eso con una frase concreta, no hay roadmap que aprobar todavía.
Anatomía de la primera conversación: ahí se gana o se pierde el ROI
Todo proyecto de datos tiene un momento fundacional que decide su destino mucho antes de la primera línea de código: la primera conversación entre el comprador y el proveedor. Ahí se define el alcance, el presupuesto, el cronograma — y casi nunca se define lo único que realmente importa, que es la métrica de negocio y su línea base.
He revisado docenas de propuestas de proyectos de IA y datos en los últimos años. El patrón es casi idéntico: arquitectura detallada, desglose de horas por fase, especificación técnica precisa, cronograma con hitos. Y en la sección de “objetivos de negocio”, una frase vaga sobre “mejorar la eficiencia operativa” o “habilitar decisiones basadas en datos”. Nada medible. Nada que se pueda auditar seis meses después.
Esa vaguedad no es un accidente. Es el resultado natural de una conversación donde ninguna de las dos partes tiene incentivo para forzar la precisión. El proveedor no la fuerza porque cada requisito adicional de negocio es un riesgo de que el alcance se reduzca o el contrato no cierre. El comprador no la fuerza porque no lo han entrenado para exigirla — llega a la conversación pensando en tecnología, no en la decisión de negocio que quiere cambiar.
El resultado es un proyecto que arranca con toda la precisión técnica del mundo y ninguna precisión de negocio. Y un proyecto sin métrica de negocio definida en el origen no puede, por definición, demostrar ROI al final. No es que el ROI sea difícil de medir. Es que nunca se definió qué medir.
El conflicto de interés: comprador y proveedor no están alineados donde importa
Aquí hay algo que pocos consejos quieren escuchar, y que digo sin rodeos porque es mi trabajo decirlo: tu proveedor de tecnología no tiene el mismo incentivo que tú. El proveedor cobra cuando el proyecto arranca y avanza por fases. Su ciclo de ingreso se cierra en la firma del contrato y en los entregables del cronograma — no en el resultado de negocio que ese proyecto debía producir.
Esto no convierte al proveedor en un actor de mala fe. Es economía básica: cada actor optimiza para lo que le paga. Y a un proveedor de tecnología le pagan por implementar, no por que tu margen mejore o tu ciclo de venta se acorte. La pregunta que debería frenar cualquier proyecto de datos — “¿qué decisión de negocio vamos a tomar distinto con esto?” — no la va a hacer con rigor quien va a facturar por avanzar el proyecto, porque hacerla juega en contra de su propio ciclo comercial.
Como Board Advisor, mi función en ese momento no es desconfiar del proveedor. Es asegurar que el rigor exista del lado correcto de la mesa. Un conflicto de interés estructural no se resuelve pidiéndole al vendedor que se audite a sí mismo. Se resuelve poniendo la exigencia de precisión donde corresponde: en el comprador, antes de firmar.
El marco de gobierno: gobierno de datos no es un tema de TI
Aquí es donde la mayoría de los consejos mexicanos se equivocan de raíz. Delegan el “gobierno de datos” al área de TI, como si fuera un asunto de arquitectura de sistemas o de calidad de bases de datos. Es un error de clasificación con consecuencias reales.
Gobierno de datos es la disciplina de decidir, con autoridad de negocio, qué datos existen, quién es dueño de su calidad, qué decisiones se toman con ellos y cómo se audita que esas decisiones efectivamente cambiaron. Eso no es una función técnica. Es una función de gobierno corporativo, tan estratégica como la aprobación de un presupuesto de capital o la definición de una política de riesgo.
Cuando un consejo aprueba una inversión en IA sin ejercer gobierno sobre ella, está delegando su función más básica — la disciplina de la pregunta correcta — a quien tiene menos incentivo para hacerla: el proveedor, o el equipo interno de TI que ejecuta sin mandato de negocio explícito. El consejo, no el CIO, es responsable de que exista una definición de éxito medible antes de que se apruebe el gasto. Eso no se subcontrata.
La guía de acción: qué debe exigir un CEO antes de firmar cualquier roadmap
Esto es lo que le pido a cualquier CEO o consejo que llega a mi mesa con una propuesta de tecnología lista para firmar. No es una lista de buenas intenciones. Es un filtro de aprobación:
- La métrica de negocio, por escrito. No “mejorar eficiencia” — el KPI específico que se va a mover: margen, ciclo de venta, desperdicio, rotación de inventario.
- La línea base actual de esa métrica. Sin punto de partida documentado, no hay forma de demostrar cambio después.
- La fecha en la que ese cambio se va a medir. Un proyecto sin fecha de auditoría de resultado es un proyecto sin dueño.
- El dueño de negocio del resultado — no del proyecto. Alguien con autoridad sobre la decisión que va a cambiar, no solo sobre el presupuesto de implementación.
- El criterio de cancelación. Qué evidencia, a qué altura del proyecto, obliga a detenerlo si la métrica no se está moviendo.
Si el proveedor no puede ayudarte a construir esas cinco líneas con precisión antes de la firma, no tienes un proyecto. Tienes una promesa con arquitectura técnica.
Conclusión
La tecnología nunca ha sido el problema en los proyectos de datos que fracasan. El problema es la decisión que se tomó — o que no se tomó — antes de que el proyecto empezara: la decisión de exigir claridad de negocio antes de aprobar capital. Esa decisión es tuya, no de tu proveedor, y no se delega.
Antes de tu próxima junta de comité, audita tu plan con mi Digital Advisor+ en twin.hpm.one.