Hace tres semanas estuve en una sesión de consejo con una cadena de retail que factura varios cientos de millones de pesos al año. El director de tecnología presentó, con una demo impecable, un proyecto de IA generativa para atención a cliente y un modelo predictivo de reabasto para sus 40 tiendas.
La sala aplaudió. El CEO, visiblemente orgulloso, cerró la presentación diciendo que esto los ponía “a la vanguardia del sector”. Yo hice la única pregunta que importaba en ese momento.
“¿Qué decisión de negocio va a cambiar con esto, y en cuánto?”
Silencio. Después, una respuesta sobre “mejorar la experiencia del cliente” que no aterrizaba en ningún número. Nadie en la sala — ni el CEO, ni el director de tecnología, ni el resto del consejo — 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.
Ese consejo no tenía un problema de tecnología. La demo funcionaba, el modelo estaba bien construido, el proveedor era competente. Tenían un problema de gobierno: estaban a punto de aprobar un presupuesto de siete cifras sin haber definido qué significaba éxito.
Esto no es un caso aislado. Es el patrón que veo repetirse, con variaciones menores de sector, en la mayoría de los proyectos de IA que llegan a consejo. Y la razón por la que fracasan no se descubre seis meses después, cuando el proyecto ya está implementado. Se decide en la sala de consejo, el día que se aprueba sin las preguntas correctas.
El diagnóstico: por qué el CEO delega lo que no debería delegar
El error de clasificación
La mayoría de los consejos mexicanos comete el mismo error de origen: tratan la IA como un tema técnico y, por lo tanto, lo delegan al director de TI o al CIO. Es un error de clasificación con consecuencias financieras reales.
La IA no es una decisión de infraestructura. Es una decisión de negocio con un componente técnico. Confundir las dos cosas es como delegarle a Finanzas la decisión de qué producto lanzar solo porque hay que calcular el precio. El área técnica ejecuta. No define el objetivo.
Cuando el CEO delega la IA a TI, delega también la pregunta que solo él puede responder: qué decisión operativa quiere cambiar. TI puede construir casi cualquier cosa que se le pida. Lo que no puede hacer es decidir qué vale la pena construir — esa es una decisión de negocio, y como tal, es del CEO y del consejo.
El resultado de esta delegación mal hecha es previsible: TI construye con excelencia técnica un proyecto que nadie ató a un resultado de negocio. Seis, doce meses después, el consejo pregunta por el ROI y no hay nada que mostrar, porque nunca se definió qué medir.
El conflicto de interés que nadie nombra
Hay una segunda causa raíz, más incómoda: el proveedor de tecnología no tiene el mismo incentivo que tú. 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 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 IA le pagan por implementar, no por que tu margen mejore o tu ciclo de cobranza se acorte.
La pregunta que debería frenar cualquier proyecto de IA —”¿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. Hacerla juega en contra de su propio ciclo comercial.
El rigor, entonces, tiene que venir del lado del comprador. No porque el proveedor sea deshonesto, sino porque estructuralmente nadie más en la mesa tiene el incentivo de exigirlo.
El framework: las 3 preguntas que sí importan
Después de ver fracasar suficientes proyectos por la misma razón, llegué a un framework de tres preguntas. No son sofisticadas. Son incómodas, que es distinto. Si un CEO no puede responderlas con precisión antes de hablar con su equipo técnico, no tiene un proyecto de IA — tiene una intención sin gobierno.
Pregunta 1: ¿Qué decisión de negocio va a cambiar?
No se trata de “ser más eficientes” ni de “mejorar la experiencia del cliente”. Esas frases son cómodas precisamente porque no comprometen a nada medible. Se trata de precisión quirúrgica sobre una decisión operativa concreta.
¿Vas a comprar menos inventario de una categoría específica? ¿Vas a reducir el tiempo de respuesta de cobranza en X días? ¿Vas a cambiar la frecuencia de ajuste de precios en una línea de producto? Si la respuesta sigue siendo una aspiración genérica después de la tercera vez que preguntas “¿y eso qué decisión cambia?”, no tienes un proyecto. Tienes una intención.
Esta pregunta filtra más proyectos de IA de los que cualquier comité de inversión filtra por presupuesto. Y debería hacerlo antes, no después de gastar el capital.
Pregunta 2: ¿Cuál es la línea base contra la que voy a medir el resultado?
La tecnología sin línea base es ruido con buena interfaz. Si no sabes cuánto te cuesta hoy el proceso que quieres transformar —en pesos, en días, en puntos de margen— es imposible demostrar, seis meses después, que estás mejor.
He visto propuestas técnicas extraordinariamente detalladas —arquitectura, cronograma, especificación de modelo— sin una sola línea sobre el estado actual del proceso que se busca mejorar. Esa omisión no es casualidad. Es la consecuencia de una conversación centrada en la tecnología y no en el negocio.
No audites el software antes de aprobarlo. Audita si existe la métrica y su línea base. Si no existe, ese es el primer proyecto que hay que aprobar — no el modelo de IA.
Pregunta 3: ¿Quién es el dueño del resultado — no del proyecto?
Esta es la pregunta que más consejos se saltan, y la que más caro sale. Hay una diferencia crítica entre el dueño del proyecto —quien administra el cronograma y el presupuesto de implementación— y el dueño del resultado —quien tiene autoridad sobre la decisión de negocio que el proyecto debía cambiar.
Si 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 con excelencia y aun así no mover el número, porque no es quien controla las palancas de negocio detrás de ese número.
El dueño del resultado tiene que ser alguien del área de negocio, con el presupuesto y la responsabilidad puestos en la línea si el número no se mueve. Si nadie en la sala está dispuesto a poner su nombre ahí, esa es la señal más clara de que el proyecto no está listo para aprobarse.
Tecnología decorativa vs. transformación operativa: dos casos
Caso 1 — manufactura
Una planta 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 de mantenimiento preventivo de siempre, y el modelo predictivo corría en paralelo, ignorado. Tenían tecnología. No tenían un cambio de decisión operativa.
La diferencia con una planta que sí transforma: ahí el gerente de mantenimiento tiene autoridad y mandato explícito para desviar el calendario preventivo cuando el modelo predictivo lo indica. El modelo no es decoración — es insumo de una decisión que alguien está autorizado y obligado a tomar distinto.
Caso 2 — servicios financieros
Una empresa de servicios financieros implementó un modelo de scoring de riesgo más sofisticado que el anterior. Mejor precisión estadística, validado por su equipo de datos, aprobado por comité técnico.
La política de originación de crédito, sin embargo, no cambió: los mismos umbrales, los mismos comités de aprobación, las mismas excepciones manuales de siempre. El modelo mejoró la calidad de la predicción y no cambió una sola decisión de a quién se le presta y en qué condiciones.
La transformación real ocurre cuando el nuevo scoring viene acompañado de una política de originación rediseñada, con umbrales y autoridades de aprobación ajustados al nuevo modelo. Sin ese rediseño, el modelo es un ejercicio de ciencia de datos con cero impacto en la cartera.
En ambos casos la tecnología era sólida. Lo que faltó, en los dos, fue la decisión de negocio que debía cambiar como consecuencia directa de tenerla. Ese es el patrón que se repite en la enorme mayoría de los proyectos que no generan retorno.
El gobierno de datos no es un tema de TI — es función del consejo
Aquí es donde la mayoría de los consejos mexicanos se equivocan de raíz. Tratan el “gobierno de datos” como un asunto de arquitectura de sistemas, delegable a TI o a un comité técnico. Es un error de clasificación con las mismas consecuencias que delegar la estrategia de precios al área de sistemas.
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 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 —la disciplina de la pregunta correcta— a quien tiene menos incentivo para hacerla 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, y no debería delegarse en ningún comité que no tenga autoridad sobre el resultado de negocio.
Guía de auditoría: qué debe exigir el CEO antes de firmar
Esto es lo que le pido a cualquier CEO o consejo que llega a mi mesa con una propuesta de 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 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 seis puntos con precisión antes de la firma, no tienes un proyecto de 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
La IA no falla por el algoritmo. Falla por 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, y no se subcontrata al proveedor que va a facturar por implementarla.
Antes de tu próxima junta de consejo, audita tu plan con mi Digital Advisor+ en twin.hpm.one.