Aprobar un proyecto y vigilar que se ejecute bien son dos responsabilidades distintas, aunque en la mayoría de los consejos de administración se traten como si fueran la misma. La primera le corresponde al equipo directivo. La segunda le corresponde al consejo — y en proyectos de datos o inteligencia artificial, es la que con más frecuencia se ejerce mal, no por falta de interés, sino por falta de un marco simple para saber qué preguntar.
Asesorar y vigilar: dos roles frente al mismo proyecto
Un equipo directivo que evalúa un proyecto de datos o IA se enfoca, de forma natural, en la ejecución: qué tan bien está estructurado el caso de negocio, qué tan realista es el plazo, qué tan calificado es el proveedor o el equipo interno que lo va a construir. Es un rol cercano al detalle técnico y a la persona que finalmente va a tomar la decisión de avanzar.
El consejo de administración opera en un nivel distinto. Rara vez ve el detalle técnico del proyecto — ve una presentación, un resumen ejecutivo, una recomendación ya validada por el equipo que la propone. Su función no es rehacer ese análisis. Es verificar que el análisis se hizo con el rigor que el capital comprometido exige, antes de aprobarlo.
Ambos roles usan el mismo vocabulario — ROI, modelo predictivo, business case, riesgo — lo que facilita que se confundan entre sí. Pero uno construye la respuesta a la pregunta de negocio, y el otro tiene que verificar que la pregunta se planteó correctamente antes de que se construyera una respuesta.
Lo que un equipo directivo pregunta — y lo que un consejo debería preguntar
Frente a un proyecto de datos o IA, un equipo directivo generalmente evalúa tres cosas: si el proyecto va a funcionar, cuánto cuesta, y cuánto tiempo toma. Son preguntas legítimas y necesarias — son las que determinan si el proyecto avanza operativamente.
Un consejo debería estar evaluando algo distinto: cómo se va a saber si el proyecto funcionó, quién es responsable si no funciona, y qué tan confiables son los datos sobre los que se construyó la recomendación que está a punto de aprobarse. Esta tercera pregunta es la que con menor frecuencia se hace, y es la que más determina si el proyecto tiene una base sólida — porque un modelo bien construido sobre datos sin gobernar produce una recomendación con apariencia de rigor que no lo tiene.
¿Por qué la mayoría de los consejos no hacen la tercera pregunta?
La razón más común no es falta de interés por parte de los consejeros. Es falta de vocabulario. La mayoría de los integrantes de un consejo no tienen un perfil técnico, y en la mayoría de las organizaciones no existe un marco simple que les permita evaluar una propuesta de datos o IA sin necesidad de entender el modelo línea por línea.
Ante esa falta de vocabulario, la reacción más común frente a una propuesta técnica se divide en dos: aprobarla con base en la confianza que genera quien la presenta, o rechazarla por instinto sin poder argumentar técnicamente el motivo. Ninguna de las dos constituye gobierno corporativo efectivo — la primera equivale a delegar la vigilancia por completo, y la segunda genera fricción sin un fundamento que el equipo directivo pueda atender.
Existe una tercera opción, menos común en la práctica pero más útil: establecer un conjunto reducido de preguntas no técnicas que permitan evaluar si el trabajo de fondo se hizo con rigor, sin requerir experiencia en ciencia de datos.
Las tres preguntas que un consejo debería hacer antes de aprobar
1. ¿Qué decisión de negocio específica va a cambiar con este proyecto, y quién es responsable de que cambie? No qué tecnología se va a implementar, sino qué decisión, tomada por quién, va a ser distinta como resultado del proyecto.
2. ¿Cómo se va a saber, con evidencia, que la decisión efectivamente cambió y que el cambio valió la pena? Si el equipo que presenta no puede nombrar la métrica que lo va a confirmar, el proyecto todavía no está listo para aprobarse — es una intención con presupuesto asignado.
3. ¿Qué tan confiables son los datos sobre los que se construyó esta recomendación? Un consejo no necesita auditar el dato línea por línea. Necesita confirmar que alguien ya lo hizo, y qué encontró al hacerlo.
Estas tres preguntas no sustituyen el trabajo técnico del equipo que propone el proyecto. Lo complementan desde el nivel que le corresponde a un consejo: no construir la respuesta, sino verificar que la pregunta se formuló con rigor antes de comprometer el capital.
¿Cómo institucionalizar estas preguntas sin tecnificar a todo el consejo?
No es necesario rediseñar la estructura de gobierno corporativo para aplicar este marco. Basta un acuerdo simple: ningún proyecto de datos o IA se presenta al consejo sin que el equipo que lo propone pueda responder las tres preguntas por escrito, antes de la sesión.
Ese cambio modifica la dinámica de la reunión. En lugar de que el consejo evalúe una presentación en tiempo real y decida con base en qué tan convincente resultó, llega con las respuestas ya documentadas, y la discusión se enfoca en si esas respuestas son suficientes — el nivel de vigilancia que le corresponde a un consejo, sin necesidad de entrar al detalle técnico.
Tampoco es necesario que todos los integrantes del consejo adquieran un perfil técnico. Es suficiente con que una persona — un consejero independiente, el presidente del comité de auditoría, o quien tenga el mandato explícito — sea responsable de plantear estas tres preguntas en cada propuesta relevante, hasta que se conviertan en parte habitual de cómo el consejo evalúa cualquier proyecto de datos o IA.
¿Qué pasa cuando estas preguntas no se hacen?
La ausencia de estas tres preguntas no siempre se traduce en un proyecto que falla de forma visible. Con más frecuencia, se traduce en un proyecto que se aprueba, se ejecuta, y produce resultados ambiguos — ni un fracaso evidente que obligue a detenerlo, ni un éxito claro que justifique haberlo aprobado sin las preguntas de por medio.
Ese resultado ambiguo es, en la práctica, el escenario más costoso para un consejo. Un proyecto que falla de forma evidente genera una lección clara y una corrección de rumbo. Un proyecto que produce resultados ambiguos consume presupuesto, tiempo del equipo directivo, y capital político dentro de la organización, sin que nadie pueda determinar con certeza si valió la pena — porque nunca se definió, desde el principio, cómo se iba a medir el éxito ni qué tan confiables eran los datos de origen.
Con el tiempo, ese patrón erosiona algo más difícil de recuperar que el presupuesto de un solo proyecto: la confianza del consejo en su propia capacidad de evaluar propuestas de datos o IA. Cuando eso ocurre, la reacción más común no es exigir mejores preguntas — es exigir menos proyectos, lo que frena la adopción de tecnología que sí podría generar valor, simplemente porque el mecanismo de vigilancia nunca se estableció con claridad.
Preguntas frecuentes
- ¿Estas preguntas aplican solo a proyectos grandes de IA? No. Aplican a cualquier proyecto de datos o IA que requiera aprobación del consejo, sin importar el tamaño del presupuesto — la tercera pregunta, sobre confiabilidad de los datos, suele ser igual de relevante en un proyecto pequeño que en uno de varios millones de dólares.
- ¿Quién debería ser responsable de hacer estas preguntas dentro del consejo? No tiene que ser un perfil técnico. Puede ser cualquier consejero al que se le asigne explícitamente esa responsabilidad — lo importante es que exista alguien con el mandato de hacerlo en cada propuesta, no que se dé por hecho que alguien más ya lo preguntó.
- ¿Qué pasa si el equipo que propone el proyecto no puede responder las tres preguntas? Eso no significa que el proyecto deba rechazarse. Significa que todavía no está listo para aprobarse con el capital completo — es una señal para pedir que se resuelvan esas respuestas antes de la siguiente sesión, o para aprobar una fase inicial más acotada mientras se construyen.
- ¿Estas preguntas retrasan la aprobación de un proyecto? No deberían, si se piden por escrito antes de la sesión y no durante ella. El objetivo no es agregar un filtro adicional al final del proceso, sino que el equipo que propone el proyecto llegue con esas respuestas ya resueltas — lo cual, en la mayoría de los casos, acelera la conversación en lugar de alargarla.
Siguiente paso
En MaIA by Scanda trabajamos con consejos de administración y comités directivos que necesitan un marco simple para evaluar proyectos de datos o IA sin depender de un perfil técnico dentro del consejo. Si tu organización está por presentar o aprobar un proyecto de este tipo, conversemos.
Español 
English