Introducción — un mes de la misma conversación repetida
Julio empezó con una sesión de consejo en una empresa manufacturera mediana. El equipo directivo llegó orgulloso: tres proyectos de IA en producción, todos con dashboards impecables. Cuando pregunté qué decisión de negocio había cambiado gracias a ellos, hubo silencio.
Terminó con la misma pregunta, en una cadena de retail distinta, frente a un consejo distinto, con un proveedor distinto. La demo era excelente. El modelo estaba bien construido. Nadie podía decir con precisión qué iba a costar menos, qué iba a rotar más rápido, o qué margen iba a subir.
En medio, hubo consejos financieros, consejos de servicios, consejos de manufactura. Sectores distintos, tamaños distintos, tecnologías distintas. El patrón fue idéntico las cuatro veces: presupuestos de siete cifras aprobados sin una línea base, sin una métrica definida, sin un dueño de resultado con nombre y apellido.
Este documento reúne lo que escribí a lo largo de julio sobre ese patrón — cuatro capítulos, un diagnóstico común, un framework de tres preguntas y un checklist de auditoría. Es el resumen que le hubiera dado, al inicio del mes, a cualquiera de esos cuatro consejos si me hubieran dejado hablar antes de firmar.
El diagnóstico: por qué el mismo error se repite en sectores distintos
Antes de entrar a los cuatro capítulos, vale la pena nombrar la causa raíz que los conecta a todos, porque no es una casualidad estadística. Es un error de diseño organizacional que se repite porque nadie lo ha corregido a nivel de gobierno.
Primero: la IA se trata como tema técnico, no como decisión de negocio. Cuando un consejo delega la IA a TI —o al proveedor externo—, delega también la única pregunta que un área técnica no puede responder por sí sola: qué decisión operativa se quiere cambiar. TI ejecuta con excelencia. No decide qué vale la pena ejecutar. Esa es, y siempre ha sido, una decisión de negocio.
Segundo: el proveedor no tiene el mismo incentivo que el comprador. El proveedor de tecnología cobra cuando el proyecto arranca y avanza por fases. Su ciclo de ingreso se cierra en la firma del contrato, no en el resultado de negocio que ese proyecto debía producir. Esto no lo convierte en un actor de mala fe — es economía básica. Pero significa que la pregunta que debería frenar cualquier proyecto mal planteado no la va a hacer con rigor quien va a facturar por avanzar.
Tercero: nadie define la línea base antes de aprobar el gasto. He revisado docenas de propuestas técnicas con arquitectura detallada, cronograma preciso, especificación de modelo impecable — y una frase vaga sobre “mejorar la eficiencia operativa” en la sección de objetivos de negocio. Sin línea base, no hay forma de demostrar ROI después, porque nunca se definió qué medir.
Cuarto: el dueño del proyecto y el dueño del resultado casi nunca son la misma persona con autoridad de negocio. Cuando el dueño del resultado es el director de TI, el proyecto está condenado desde el origen: TI no tiene autoridad sobre el margen, el inventario o la cartera vencida. Puede ejecutar perfecto y aun así no mover el número, porque no controla las palancas de negocio detrás de ese número.
Estos cuatro factores no son independientes. Se refuerzan entre sí, y juntos explican por qué proyectos técnicamente sólidos, en empresas bien administradas, con equipos competentes, siguen sin generar retorno medible.
Capítulo 1 — La lección que no esperaba
El primer capítulo de esta temporada nació de una sesión de consejo real: una empresa que había implementado IA en tres áreas de su operación en menos de seis meses. Forecasting de demanda, un asistente de servicio a cliente, automatización de compras. Todo funcionando, todo con interfaces elegantes.
La lección no fue sobre tecnología. Fue sobre gobierno. El consejo había aprobado presupuesto de “digitalización” sin exigir la pregunta que precede cualquier inversión: qué objetivo de negocio resuelve esto, y cómo se va a medir. La IA no falló — el consejo falló en pedir claridad antes de aprobar el gasto.
Esa fue la tesis que sostuvo toda la temporada: la falta de objetivos claros no es un detalle operativo. Es una falla de gobierno corporativo. Cuando un consejo no exige objetivo y métrica antes de aprobar tecnología, delega su función más básica — la disciplina de la pregunta correcta.
Capítulo 2 — El CRM como decoración
El segundo capítulo bajó la misma lógica al terreno más operativo posible: el pipeline comercial. La pregunta que lo disparó fue simple: ¿por qué el forecast casi nunca cierra al nivel que promete el board deck?
La respuesta no está en el vendedor que infla el reporte. Está en el proceso que nunca definió qué documento, qué firma, qué decisión del cliente justifica mover un deal de una etapa a otra. Sin ese criterio, cada vendedor decide solo — y decide a su favor, porque el sistema lo premia por que el reporte se vea bien, no por que refleje la realidad.
El CRM no miente. Refleja con precisión un proceso que nunca exigió honestidad operativa. Y esa es la misma raíz que el Capítulo 1: falta de un criterio de negocio definido antes de que la herramienta —CRM o modelo de IA— empezara a generar datos que nadie audita.
Capítulo 3 — Las tres preguntas que el CEO debe hacerse antes de hablar con TI
El tercer capítulo convirtió el diagnóstico en un framework operativo: tres preguntas que cualquier CEO puede y debe responder por sí mismo, antes de involucrar a su equipo técnico o a un proveedor.
¿Qué decisión de negocio va a cambiar? No una aspiración genérica como “ser más eficientes”. Una decisión operativa específica: cuánto inventario se compra, en cuántos días se resuelve una cobranza, con qué frecuencia se ajusta un precio.
¿Cuál es la línea base contra la que se va a medir el resultado? Sin el estado actual documentado —en pesos, en días, en puntos de margen—, es imposible demostrar después que algo mejoró. La tecnología sin línea base es ruido con buena interfaz.
¿Quién es el dueño del resultado, no del proyecto? Alguien del área de negocio, con autoridad sobre la palanca que el proyecto pretende mover, y con su presupuesto y su nombre puestos en la línea si el número no se mueve.
Estas tres preguntas no son sofisticadas. Son incómodas, que es distinto. Si un CEO no puede responderlas con precisión antes de la primera conversación con su equipo técnico, no tiene un proyecto de IA — tiene una intención sin gobierno.
Capítulo 4 — La pregunta que nadie le hace al CEO
El cuarto capítulo cerró el ciclo señalando el error de clasificación que sostiene todo lo anterior: tratar el gobierno de datos como un tema de TI, cuando es, estructuralmente, una función de consejo.
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. No es arquitectura de sistemas. Es tan estratégico como aprobar un presupuesto de capital o definir una política de riesgo.
Cuando un consejo aprueba una inversión en IA sin ejercer gobierno sobre ella, delega su función más básica a quien tiene menos incentivo para ejercerla con rigor: el proveedor, o el equipo técnico 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. Esa responsabilidad no se subcontrata.
El framework unificado
Los cuatro capítulos, juntos, forman un solo framework de auditoría. No son cuatro ideas separadas — son cuatro capas del mismo problema, vistas desde ángulos distintos:
- Capa de origen (Capítulo 1): ¿existe un objetivo de negocio claro antes de aprobar el gasto?
- Capa de proceso (Capítulo 2): ¿el proceso operativo exige evidencia real, o solo reporte cosmético?
- Capa de filtro (Capítulo 3): ¿el proyecto pasa las tres preguntas antes de hablar con TI?
- Capa de gobierno (Capítulo 4): ¿el consejo está ejerciendo su función, o la delegó sin darse cuenta?
Un proyecto que falla en cualquiera de estas cuatro capas no va a generar retorno, sin importar qué tan sofisticada sea la tecnología detrás. Y la mayoría de los proyectos que he revisado este mes fallaban en al menos dos.
Esto importa porque la reacción natural de un consejo, cuando un proyecto no genera resultado, es corregir una sola capa — casi siempre la más visible. Cambian de proveedor. Contratan un mejor equipo de datos. Renuevan la tecnología. Y el proyecto siguiente vuelve a fallar, porque las otras tres capas —origen, proceso, gobierno— nunca se tocaron. Corregir una capa sin corregir las cuatro no resuelve el patrón; solo cambia el nombre del próximo proyecto que va a repetirlo.
Cómo se ve la diferencia en la práctica
El framework es abstracto hasta que se aplica a dos proyectos reales, técnicamente comparables, con resultados opuestos. Vale la pena verlos lado a lado, porque la diferencia entre uno y otro casi nunca está en la calidad del modelo.
El que falla. Una planta manufacturera implementó un modelo de mantenimiento predictivo sobre sus líneas críticas. El modelo funcionaba: predecía fallas con buena precisión, generaba alertas, tenía un dashboard elegante para el equipo de mantenimiento. Un año después, el tiempo de paro no planeado no había cambiado. La razón: nadie modificó el proceso de mantenimiento para actuar sobre las alertas. El equipo seguía su calendario preventivo de siempre, y el modelo corría en paralelo, ignorado. Pasaba la prueba técnica. Fallaba las cuatro capas del framework: sin decisión de negocio definida, sin línea base de paro no planeado documentada antes de empezar, sin dueño de resultado con autoridad para desviar el calendario, y sin gobierno de consejo que lo hubiera exigido.
El que funciona. Una empresa de logística de última milla enfrentaba el mismo tipo de decisión: invertir en un modelo de optimización de rutas. Antes de aprobar el presupuesto, el CEO exigió las tres preguntas por escrito. La decisión de negocio: reducir el costo por entrega en la zona metropolitana donde operaban el 60% de sus rutas. La línea base: el costo actual, documentado por semana, durante ocho semanas previas. El dueño del resultado: el director de operaciones, no el equipo de datos que construyó el modelo — con la autoridad explícita de reasignar rutas y flota según la recomendación del sistema. Seis meses después, el consejo no discutió la sofisticación del algoritmo. Discutió una cifra: el costo por entrega había bajado un porcentaje específico, medido contra la línea base que se documentó antes de arrancar.
La diferencia entre los dos no fue el talento técnico ni el presupuesto disponible. Fue que uno pasó las cuatro capas del framework antes de arrancar, y el otro nunca las tuvo definidas.
El checklist de auditoría
Esto es lo que le pido a cualquier CEO o consejo que llega a mi mesa con una propuesta de datos o IA lista para aprobar. No es una lista de buenas intenciones — es un filtro de aprobación que cualquier proyecto debería pasar antes de que se libere un peso de presupuesto.
- La decisión de negocio, por escrito y en una frase. No un objetivo general — la decisión operativa específica que va a cambiar.
- La métrica exacta y su línea base actual. Documentada, con fuente de datos verificable, no una estimación de memoria.
- La fecha en la que ese cambio se va a medir y auditar. Un proyecto sin fecha de auditoría de resultado es un proyecto sin dueño real.
- El dueño del resultado, con nombre y apellido. Alguien del área de negocio con autoridad sobre la palanca que el proyecto pretende mover — no el líder técnico del proyecto.
- El criterio de cancelación. Qué evidencia, a qué altura del proyecto, obliga a detenerlo si la métrica no se está moviendo como se proyectó.
- La evidencia de que el proceso operativo, no solo el modelo, va a cambiar. Un modelo predictivo sin un cambio de proceso detrás es tecnología decorativa, no transformación.
- La separación explícita entre “dueño del proyecto” y “dueño del resultado”. Si es la misma persona y no tiene autoridad de negocio, hay un problema de gobierno antes de empezar.
Si el proveedor no puede ayudarte a construir estos siete puntos con precisión antes de la firma, no tienes un proyecto de datos o IA. Tienes una propuesta técnica con presupuesto asignado, esperando convertirse en el próximo caso que un consejo tiene que explicar por qué no funcionó.
El punto final de la temporada
La tecnología nunca ha sido el problema en los proyectos que fracasan. El problema es la decisión que un consejo tomó —o dejó de tomar— antes de que el proyecto empezara: la decisión de exigir gobierno de negocio antes de aprobar capital técnico.
Esa decisión es del CEO y del consejo. No se delega al proveedor que va a facturar por implementarla, ni al equipo técnico que ejecuta sin mandato explícito. Es la disciplina más simple de nombrar y la más difícil de sostener, porque exige incomodidad recurrente: preguntar antes de aprobar, auditar antes de celebrar, cancelar cuando la evidencia lo pide.
Si aplicaste este framework a los proyectos de datos o IA que tu empresa tiene corriendo hoy, probablemente ya sabes cuáles pasarían la auditoría y cuáles no. Esa certeza —incómoda o no— es exactamente el punto.
Vale la pena decir algo más antes de cerrar: nada de este framework es exclusivo de la IA. Las mismas cuatro capas —origen, proceso, filtro, gobierno— aplican a cualquier decisión de capital que un consejo apruebe: una adquisición, una nueva línea de negocio, una expansión geográfica. La IA no inventó la falta de rigor en la aprobación de inversiones. Simplemente la hizo más visible, porque es la categoría de gasto que más consejos han aprobado este año sin aplicarle el mismo estándar que le exigen a cualquier otro capital.
Esa es, en el fondo, la razón por la que dediqué julio completo a este tema. No porque la IA sea especial. Porque es el síntoma más claro, hoy, de una pregunta de gobierno que muchos consejos mexicanos todavía no se hacen con la disciplina que merece.
En agosto vamos a hablar de lo que viene antes de esa aprobación: cómo se construye una tesis de inversión en datos e IA que un consejo pueda defender con el mismo rigor con el que defiende cualquier otro capital que compromete. Si julio fue sobre auditar lo que ya aprobaste, agosto es sobre no tener que auditarlo después.
Si quieres hacer esa auditoría con ayuda, sin depender solo de tu propio criterio, mi Digital Advisor+ está diseñado para eso: un diagnóstico directo, sin filtro, de si lo que tienes hoy es una inversión real o un experimento caro con nombre elegante. Puedes hacerlo en https://twin.hpm.one
Y si prefieres discutir tu caso específico conmigo directamente, este documento no tiene un formulario de contacto genérico al final — tiene una invitación a escribirme. Mándame un DM.