Llevo dos años sentado, cada vez con más frecuencia, del lado del consejo — no del lado del CEO que presenta, sino del lado de quien tiene que decidir si lo que se está presentando merece luz verde. Y hay una tensión que se repite en casi cada sesión donde el tema es datos o inteligencia artificial: alguien presenta con seguridad, el resto de la mesa no tiene el criterio técnico para cuestionar el fondo, y el proyecto se aprueba con base en qué tan convincente sonó la presentación, no en qué tan sólida era.
Esa tensión es la que me llevó, a construir algo que llevaba tiempo posponiendo: un Asesor de Consejo Virtual — un agente de IA entrenado específicamente en las preguntas que un consejero con criterio técnico debería hacer frente a un proyecto de datos o IA, antes de aprobarlo.
Por qué construí esto
Los dos capítulos anteriores de esta temporada describen el mismo vacío desde dos ángulos. El primero, desde mi propia experiencia: lo que un consejo ve que un CEO no ve, y por qué asesorar y vigilar son dos oficios distintos aunque compartan el vocabulario. El segundo, desde el diseño del consejo mismo: por qué el perfil tradicional — financiero, legal, de industria — ya no cubre el riesgo de aprobar un proyecto de datos o IA sin criterio técnico en la mesa.
El problema con ambos diagnósticos es que describen algo verdadero pero difícil de resolver rápido. Formar a un consejero con criterio técnico toma años. Incorporar uno nuevo a la mesa toma un proceso de gobierno corporativo que muchas organizaciones no van a completar este trimestre, ni el que sigue. Mientras tanto, los consejos siguen aprobando proyectos de IA en las próximas sesiones, con o sin ese perfil presente.
Quise probar si había algo que se pudiera hacer mientras tanto. No como sustituto del criterio — como puente hacia él.
No es la primera vez que pruebo esta idea conmigo mismo antes de escribir sobre ella. En agosto construí el HPM Digital Twin como un experimento personal distinto: un espacio donde cualquiera puede conversar con una versión mía entrenada en cómo pienso los problemas de negocio. Este proyecto nace de la misma lógica — construir la herramienta primero, probarla con casos propios, y solo después escribir sobre lo que funcionó y lo que no —, pero resuelve un problema distinto y mucho más específico: no cómo pienso yo en general, sino qué pregunta un consejero con criterio técnico frente a un proyecto de datos o IA, en el momento exacto en que ese criterio hace falta.
El problema que quise resolver: la pregunta que nadie hace a tiempo
En la mayoría de los consejos donde he estado, el patrón se repite: un proyecto de datos o IA llega con un caso de negocio bien armado, una proyección de retorno atractiva, y una recomendación presentada con seguridad. Nadie en la sala pregunta cómo se obtuvo esa proyección, ni qué tan confiables son los datos que la sostienen, ni qué pasa si el supuesto central resulta equivocado.
No es que a nadie le importe. Es que hacer esa pregunta requiere un tipo específico de criterio — no dominar la ciencia de datos, sino saber qué preguntar y cuándo. Y ese criterio, hoy, vive en muy pocas personas dentro de la mayoría de los consejos.
Lo que quise construir no era un sustituto de ese criterio. Era una forma de estructurar el patrón de preguntas que ese criterio produce, para que estuviera disponible incluso cuando la persona con el criterio técnico todavía no está en la mesa.
Lo que no quise construir: un agente que decide
Antes de escribir la primera línea de instrucciones para el agente, decidí algo que terminó siendo más importante que cualquier detalle técnico: este agente no iba a recomendar, no iba a opinar sobre si un proyecto debía aprobarse, y no iba a sustituir el juicio de nadie.
La razón no es solo ética, aunque también lo es. Es práctica. Un agente que recomienda traslada el problema original a un lugar peor: en vez de que el consejo confíe ciegamente en quien presenta, empezaría a confiar ciegamente en el agente. Eso no resuelve el vacío de criterio técnico — lo esconde detrás de una herramienta con apariencia de autoridad.
Por eso el diseño quedó limitado, a propósito, a una sola función: preguntar. El agente identifica en qué está débil una propuesta de datos o IA y formula la pregunta que expone esa debilidad. Lo que se hace con la respuesta — aprobar, rechazar, pedir más información — sigue siendo, exclusivamente, decisión del consejo.
Cómo lo entrené, a grandes rasgos
No voy a entrar en el detalle técnico de la construcción — eso pertenece a otra conversación. Pero vale la pena explicar la lógica general, porque es la parte que hace que esto funcione o no.
Partí del mismo patrón de preguntas que describí en el Cap. 2: qué decisión de negocio cambia con este proyecto, cómo se va a medir el éxito, y qué tan confiables son los datos de origen. A partir de ahí, entrené al agente para reconocer, dentro de la descripción de un proyecto de datos o IA, en qué punto específico esa cadena se debilita — un dato sin fuente clara, una métrica de éxito ausente, una proyección que depende de un supuesto no verificado — y para convertir esa debilidad en una pregunta concreta, no en una advertencia genérica.
La diferencia entre “esto parece riesgoso” y “¿cómo se validó el supuesto de adopción del 40% que sostiene esta proyección de retorno?” es exactamente la diferencia entre un consejo que no sabe qué preguntar y uno que sí.
Las preguntas que hace — y por qué esas y no otras
Algunos ejemplos del tipo de pregunta que el agente formula frente a un proyecto de datos o IA:
¿Qué decisión de negocio específica cambia si este proyecto tiene éxito, y quién es responsable de tomarla? ¿Cómo se va a medir el éxito antes de que el proyecto arranque, no después? ¿De dónde vienen los datos que sostienen esta recomendación, y quién verificó su calidad? ¿Qué supuesto, si resulta falso, hace que todo el caso de negocio se caiga? ¿Qué pasa si el proyecto solo cumple la mitad de lo prometido — sigue siendo una inversión razonable?
Ninguna de estas preguntas requiere formación técnica para hacerse. Todas requieren que alguien se detenga a hacerlas antes de aprobar, no después de que el proyecto ya consumió presupuesto y tiempo.
Lo que aprendí al probarlo con mis propios casos
Antes de compartir esto con nadie, lo probé con proyectos reales en los que he estado involucrado — sin nombrar clientes, sin exponer información confidencial de nadie. Quería ver si el patrón de preguntas se sostenía frente a casos concretos, no solo frente a ejemplos hipotéticos.
El resultado me sorprendió por dos razones que, en su momento, no esperaba sentir al mismo tiempo. La primera fue de validación: varias de las preguntas que el agente formuló eran, palabra por palabra, las que yo habría hecho en esa mesa. Eso confirmó que el patrón sí se puede estructurar, al menos hasta cierto punto.
La segunda fue más incómoda: en un par de casos, el agente hizo una pregunta que a mí, en su momento, se me había pasado. No porque me faltara criterio, sino porque en una sesión real hay presión de tiempo, hay cansancio, y hay presentaciones bien armadas que generan una confianza que no siempre está justificada. El agente no tiene esa presión. Pregunta lo mismo un lunes cansado que un viernes fresco.
Eso no significa que el agente tenga mejor criterio que un consejero experimentado. Significa que puede sostener la disciplina de preguntar de forma más consistente de lo que cualquier persona puede sostenerla, sesión tras sesión, año tras año.
Los límites que le puse a propósito
Además de no dejarlo recomendar ni decidir, le puse otros límites deliberados. No tiene acceso a información confidencial de ninguna organización — trabaja sobre lo que el usuario le comparte en la conversación, nada más. No genera un veredicto de aprobar o rechazar, ni siquiera de forma indirecta a través del tono de sus preguntas. Y cuando una propuesta no tiene suficiente información para formular una pregunta específica, lo dice explícitamente, en vez de inventar una pregunta genérica solo para parecer útil.
Ese último límite fue, quizás, el más difícil de construir bien. Es fácil hacer que un agente siempre tenga algo que decir. Es más difícil, y más honesto, hacer que reconozca cuándo no tiene suficiente para preguntar algo con sentido.
Hubo un caso concreto que terminó de convencerme de que ese límite valía la pena. Le describí un proyecto con información deliberadamente incompleta — sin mencionar cómo se calculó el retorno esperado. En lugar de inventar una pregunta genérica sobre “la viabilidad del proyecto”, el agente señaló exactamente qué dato faltaba para poder cuestionar algo con precisión, y se detuvo ahí. Eso es, en el fondo, lo que distingue una pregunta útil de una que solo aparenta rigor: la pregunta útil sabe cuándo no tiene suficiente para hacerse.
Qué significa esto para tu consejo
No creo que este agente resuelva el vacío de criterio técnico que describí en el Cap. 2. Un consejo que necesita ese criterio de forma sostenida necesita, eventualmente, a una persona con ese criterio en la mesa — no una herramienta que la sustituya.
Lo que sí creo es que hay un espacio real, mientras ese perfil se incorpora, para que un consejo llegue a cada sesión con mejores preguntas de las que llegaría por su cuenta. Eso no es gobierno corporativo resuelto. Es una forma de no aprobar a ciegas mientras se construye la capacidad real.
Hay, además, un uso menos evidente que descubrí probándolo: sirve como entrenamiento para la persona que eventualmente va a ocupar ese rol en la mesa. Un consejero que todavía no tiene el criterio completamente desarrollado puede usar el agente antes de cada sesión para anticipar qué preguntas debería estar listo para hacer o para responder. No sustituye la experiencia — la acelera.
Pruébalo tú mismo
El Asesor de Consejo Virtual está disponible para que lo pruebes con tu propio caso — sin necesidad de compartir información confidencial, solo la descripción de un proyecto de datos o IA que tu organización esté evaluando.
→ Prueba el Asesor de Consejo Virtual aquí
Preguntas frecuentes
¿Este agente sustituye a un consejero con criterio técnico? No. Estructura un patrón de preguntas útil mientras ese criterio se incorpora a la mesa, pero no reemplaza el juicio de una persona con experiencia real en el tema.
¿El agente puede recomendar si un proyecto debe aprobarse? No, por diseño. Solo formula preguntas. La decisión de qué hacer con las respuestas sigue siendo, en todos los casos, del consejo.
¿Funciona para comités distintos a un consejo de administración? El mismo patrón de preguntas aplica a cualquier órgano colegiado que tenga que aprobar capital para un proyecto de datos o IA — comités directivos, comités de inversión, y estructuras similares.
¿Qué pasa con la información que comparto al probarlo? El agente trabaja únicamente con lo que se escribe en la conversación — no accede a ningún sistema, base de datos o información previa de tu organización. Aun así, la recomendación es la misma que daría para cualquier herramienta de IA: no compartas información confidencial específica, describe el proyecto en términos generales.
Este experimento nació de una pregunta simple: si el criterio no se automatiza, ¿se puede al menos estructurar la pregunta que ese criterio produce? Después de probarlo con mis propios casos, creo que la respuesta es sí, dentro de límites claros.
→ Pruébalo tú mismo y dime si tu experiencia coincide.