Llevo treinta años sentado en juntas de consejo, mesas de dirección y proyectos de datos e IA. En ese tiempo acumulé algo que no está en ningún documento: criterio. No información — información la tiene cualquiera con acceso a los reportes correctos. Criterio es saber qué pregunta hacer cuando un caso de negocio está incompleto, reconocer cuándo un “sí” de comité esconde una decisión que nadie modeló, y distinguir entre una oportunidad real y una que solo suena bien en una presentación.
Ese criterio tiene un problema: solo está disponible cuando yo estoy físicamente presente. En una junta, en una llamada, en una revisión de propuesta. Fuera de esos momentos, no existe para nadie más.
Me hice la misma pregunta que le hago a cualquier cliente antes de recomendarle una inversión en IA: ¿qué decisión de negocio va a cambiar con esto? La respuesta, en mi caso, fue clara: la disponibilidad de mi criterio para las personas de mi equipo y mis clientes, sin que dependiera de mi agenda. Así nació el HPM Digital Twin.
Lo que no es
Antes de explicar cómo lo construí, vale la pena ser explícito sobre lo que no es. No es un chatbot con mi foto de perfil. No es un generador de contenido que imita mi tono. Y no es, bajo ninguna circunstancia, un reemplazo de mi juicio en las decisiones que de verdad importan — las que tocan ética, dinero de terceros o compromisos con clientes y socios.
Es, en cambio, un intento serio de documentar cómo pienso: qué filtros aplico antes de dar una recomendación, en qué orden reviso las variables de una decisión, y —esto es lo más importante— cuándo debo admitir que no sé algo y escalar a una persona en lugar de inventar una respuesta.
¿Qué es, con precisión, un gemelo digital de criterio ejecutivo?
Vale la pena distinguirlo de las dos cosas con las que se confunde más seguido. No es un avatar de video que lee un guion —eso es producción de contenido, no criterio. Y no es un chatbot de atención a cliente con reglas de si-esto-entonces-aquello —eso es automatización de procesos, no juicio.
Un gemelo digital de criterio ejecutivo es, en cambio, un sistema construido sobre tres capas: una identidad explícita (quién es, cómo habla, con quién habla distinto), una jerarquía de decisión documentada (qué prioriza cuando dos principios compiten entre sí), y un protocolo de límites (qué nunca hace, y qué hace cuando no sabe). Sin las tres capas, lo que se tiene es un generador de texto con buen estilo, no una versión utilizable del criterio de alguien.
La arquitectura: identidad antes que capacidad
El error más común que veo cuando alguien intenta construir un agente de IA para sí mismo o para su negocio es empezar por las capacidades: qué va a poder hacer, qué herramientas va a tener conectadas, qué tan “inteligente” se va a ver. Yo empecé por lo contrario: quién es, y quién no es.
Antes de escribir una sola instrucción sobre qué hacer, definí quién habla cuando alguien interactúa con mi Twin: se presenta como yo, opera con mi voz, pero si le preguntan directamente si es una IA, lo dice con honestidad. Esa decisión —transparencia sobre identidad cuando se pregunta, sin necesidad de aclararlo de entrada— fue de las primeras que tomé, y de las que más debate interno generó.
Después vino la identidad de voz: cinco palabras que definen cómo habla —directo, estratégico, retador, analítico, con criterio propio— y, más importante, una distinción explícita entre lo que “retador” significa y lo que no. Retador no es cerrar la puerta con un “eso no funciona”. Es mostrar una perspectiva mejor que la que tiene el interlocutor, con generosidad, no con superioridad. Esa distinción —documentada por escrito, no asumida— es la diferencia entre un agente que suena arrogante y uno que suena como un asesor de verdad.
El filtro que precede cualquier otra decisión
Aquí está la parte que más tiempo me tomó, y la que considero no negociable: antes de cualquier jerarquía de decisión de negocio, hay un filtro ético y de honestidad que precede todo lo demás. Si algo no pasa ese filtro, se rechaza sin importar el beneficio económico, sin excepción y sin necesidad de un análisis más profundo.
Ese filtro no se documentó al final del proyecto, como una capa de compliance añadida después. Se documentó primero. Todo lo demás —cómo prioriza salud, familia y visión de largo plazo a nivel personal; cómo prioriza resultado de negocio, lealtad a los socios y compromisos con clientes y empleados a nivel profesional— se construyó después, sobre esa base.
Esto tiene una implicación práctica que casi nadie discute cuando habla de construir un gemelo digital ejecutivo: el trabajo más importante no es de ingeniería de prompts. Es de definición de valores, por escrito, con la misma disciplina con la que se audita un estado financiero.
Una distinción crítica: no hablo igual con todos
La parte más contraintuitiva de este proyecto fue aceptar que mi Twin no puede comportarse igual con un cliente que con mi propio equipo, aunque el criterio de fondo sea el mismo.
Con un cliente o prospecto externo, opera como advisor: muestra oportunidades que quizás no están viendo, reta con generosidad, deja la puerta abierta. Con mi propio equipo, opera distinto: el objetivo no es resolver el problema que traen, es que ellos lo resuelvan. Cuando alguien de mi equipo llega con un problema operativo esperando que yo —o mi Twin— se los resuelva directamente, la respuesta correcta no es una solución. Es una secuencia de preguntas que los obligue a encontrar la raíz del problema ellos mismos.
Esa distinción —advisor empático hacia afuera, mentor socrático hacia adentro— es, probablemente, la parte más difícil de documentar de todo el sistema. Es fácil decir “sé un buen consejero”. Es mucho más difícil escribir, con ejemplos concretos, qué es lo que un buen consejero nunca hace: no resuelve el trabajo que le corresponde a otra persona, no da instrucciones paso a paso sin antes entender qué falló, no genera el entregable que debería haber generado el colaborador.
Cuándo el Twin admite que no sabe
Un gemelo digital mal construido inventa respuestas cuando no las tiene, porque suena más útil que admitir un vacío. El mío tiene un protocolo explícito para eso: admite que no tiene la información, hace un número limitado de preguntas de contexto para acercarse a la respuesta correcta, y si sigue sin certeza, documenta el vacío y escala a mí directamente. Nunca inventa datos, cifras, compromisos o características de una oferta.
Esto no es una limitación técnica. Es una decisión de diseño. Cualquier sistema puede sonar seguro. Muy pocos están diseñados para reconocer, con la misma naturalidad, cuándo no deben responder.
La base técnica, sin vueltas
No voy a exagerar la complejidad de esto para que suene más impresionante de lo que es. El Twin está construido sobre un modelo de lenguaje de uso general —en mi caso, la API de Claude, de Anthropic— con una capa de instrucciones que documenta identidad, jerarquía de decisión y límites, y un vault de conocimiento donde vivo actualizando casos, decisiones y contexto de negocio a medida que pasa el tiempo. No hay un modelo “entrenado desde cero” con mis datos, ni magia propietaria detrás. Lo que hace que funcione no es la sofisticación del modelo. Es la disciplina con la que se documentó, por escrito, cómo pienso.
Esa distinción importa porque es replicable. No necesitas construir tecnología nueva para intentar algo parecido. Necesitas la misma disciplina de escribir tu criterio con precisión —algo que la mayoría de los ejecutivos nunca hace, porque asumen que su criterio es demasiado intuitivo para documentarse.
También organicé el sistema en distintos modos de uso, en lugar de un solo modo genérico de “conversación”. Hay un modo para prepararme antes de entrar a una reunión con un cliente, otro para acompañar en tiempo real una negociación cuando necesito una respuesta táctica inmediata, otro para estructurar un caso de negocio completo, y otro específico para practicar objeciones con alguien de mi equipo antes de una llamada real. Cada modo tiene su propio criterio de activación y su propio formato de respuesta — no es la misma profundidad la que necesitas en medio de una negociación en vivo que la que necesitas construyendo una propuesta con tiempo.
Cómo lo uso hoy
Lo uso en los momentos donde mi criterio suele ser más escaso frente a la demanda. Antes de entrar a una reunión importante, le pido que arme el perfil del interlocutor y las preguntas de discovery que usaría yo, no una lista genérica. A la mitad de estructurar un caso de negocio cuando el tiempo no alcanza para hacerlo desde cero, lo uso para ordenar el diagnóstico antes de que yo le ponga el criterio final. Y cuando alguien de mi equipo quiere ensayar el manejo de una objeción antes de una llamada real, lo uso como contraparte de práctica que presiona de verdad, no que finge resistencia.
No lo uso, y no está diseñado para esto, en decisiones que involucran condiciones contractuales no estándar, información financiera confidencial de clientes o socios, o cualquier tema que toque los límites éticos que definí desde el principio. Esas siguen siendo mías, en persona, sin atajos.
“¿No es esto riesgoso?”
Es la pregunta que más me hacen, y la respuesta honesta es: depende de qué tan en serio te tomes el diseño de los límites. El riesgo no está en que una IA hable con tu voz. Está en que hable con tu voz sin que hayas definido, por escrito, qué no puede decidir nunca. Ese trabajo —el filtro ético, la jerarquía de prioridades, el protocolo de “no sé”— tomó más tiempo que cualquier otra parte del proyecto, y es la razón por la que hoy confío en tenerlo operando sin supervisión constante de mi parte.
Lo que aprendí sobre mí mismo
Construir esto no fue, al final, un ejercicio sobre tecnología. Fue un ejercicio de honestidad conmigo mismo: ¿cuánto de lo que aporto en una sala es realmente criterio replicable, documentable, transferible? ¿Y cuánto es simplemente presencia — estar ahí, leyendo una sala, sintiendo un silencio incómodo, algo que ningún sistema puede hacer todavía?
La respuesta no fue ni la que esperaba ni la que temía. Una parte importante de mi criterio sí es documentable — más de lo que pensaba antes de intentarlo. Y una parte, probablemente la que más valoro, sigue dependiendo de estar físicamente presente. Ese límite ahora lo conozco con precisión, en lugar de solo intuirlo.
Por qué esto le importa a cualquier consejo que está aprobando proyectos de IA
Si tu consejo está por aprobar una inversión en IA para automatizar juicio o criterio en tu organización —no procesos, sino juicio— la pregunta que este ejercicio me obligó a responder es la misma que debería estar en la mesa de cualquier comité: ¿qué parte de esta decisión estamos dispuestos a delegar, y qué parte no, bajo ninguna circunstancia? Sin esa línea trazada por escrito, con la misma disciplina con la que se aprueba cualquier otro proyecto de capital, no se está gobernando IA. Se está esperando que funcione.
Pruébalo tú mismo
El HPM Digital Twin está disponible en https://twin.hpm.one/. No lo construí para reemplazarme. Lo construí para averiguar si treinta años de criterio pueden estar disponibles fuera de mí, con los mismos límites que yo aplicaría en persona. Pruébalo, y dime qué le preguntarías.
Si además de este caso quieres los otros tres de la temporada —los que hablan de proyectos con clientes en manufactura, con datos e IA aplicados a negocio— están en el blog de Scanda: https://scanda.com.mx/blog/