El director de IT vive atrapado entre dos versiones contradictorias de la misma tecnología: la que ve dirección, alimentada de titulares que prometen que la IA resuelve cualquier problema en semanas, y la que él mismo conoce de cerca, con sus límites técnicos, sus riesgos de seguridad y su deuda técnica acumulada que ninguna herramienta nueva arregla por arte de magia. Si el CTO comunica con el mismo entusiasmo genérico que circula fuera de la empresa, se compromete a plazos imposibles que luego tendrá que incumplir. Si comunica solo desde la cautela técnica, se gana fama de freno permanente y dirección empieza a tomar decisiones tecnológicas sin contar con él.
Ese doble riesgo hace que la forma de comunicar del CTO sea, quizá más que en ningún otro puesto directivo, un ejercicio constante de traducción entre dos lenguajes que rara vez coinciden de forma natural: el de la posibilidad técnica y el de la expectativa de negocio.
Qué mensaje debe transmitir el CTO (y cuál debe evitar)
El mensaje correcto es de viabilidad realista: qué es técnicamente posible con los sistemas y los datos actuales de la empresa, qué requiere una inversión previa en infraestructura o en calidad de datos antes de dar resultados fiables, y qué plazos son razonables frente a los que circulan en la conversación pública sobre IA, que casi siempre están pensados para una startup tecnológica y no para una empresa con sistemas heredados y procesos consolidados. Ese realismo, bien explicado, no frena la ambición del proyecto: la hace sostenible.
Lo que hay que evitar son los dos extremos que resultan igual de cómodos a corto plazo y perjudiciales a medio: el discurso de "podemos construir lo que sea, es solo cuestión de tiempo", que genera expectativas que ningún equipo técnico puede cumplir al ritmo que se promete, y el discurso opuesto de "esto es demasiado complejo y arriesgado, mejor no tocarlo", que convierte a IT en el departamento que siempre dice que no y empuja a otros equipos a contratar herramientas de IA por su cuenta, sin supervisión técnica ni de seguridad, que es exactamente el escenario más peligroso de todos.
Cómo adapta el CTO el mensaje según la audiencia
Ante dirección y consejo, el CTO traduce la complejidad técnica a impacto de negocio: qué es posible hacer ya, qué necesita una fase previa de preparación de datos o de infraestructura, y qué riesgos de seguridad o de dependencia tecnológica hay que asumir conscientemente antes de avanzar. Aquí el error más común es hablar en términos demasiado técnicos y perder a una audiencia que necesita decidir con criterios de negocio, no de arquitectura.
Ante los responsables de otros departamentos que van a incorporar herramientas de IA en sus equipos, el CTO traduce el mensaje a condiciones prácticas de uso: qué herramientas están validadas por seguridad y cuáles no, qué integraciones con los sistemas existentes son viables a corto plazo y cuáles requieren más desarrollo, y con qué rapidez pueden esperar respuesta cuando piden soporte para una nueva herramienta, para que no sientan que pedir ayuda a IT es sinónimo de bloqueo indefinido.
Ante el propio equipo técnico, el mensaje tiene una dimensión adicional que otros directivos no enfrentan de la misma forma: muchos desarrolladores y administradores de sistemas se preguntan si la IA generativa va a devaluar su propio oficio. Aquí el CTO debe ser tan honesto con su equipo como pide que sea el resto de la empresa con el suyo, reconociendo que ciertas tareas de programación rutinaria cambian de forma real, y explicando con datos, no con eslóganes, por qué el criterio de arquitectura, la seguridad y la resolución de problemas complejos siguen siendo insustituibles, en la línea de lo que desarrollamos sobre qué trabajos desaparecen y cuáles se multiplican con la IA.
Cómo gestiona el CTO las preguntas incómodas sobre el empleo
Dentro de su propio equipo, la pregunta llega con una carga particular: "si la IA ya escribe código, ¿me vais a necesitar dentro de dos años?". Responder con el argumento genérico de que "siempre hará falta gente para supervisar" suena hueco si no se acompaña de una explicación honesta de cómo cambia el perfil del puesto.
La respuesta honesta reconoce que la proporción de tiempo dedicado a escribir código desde cero frente a revisar, integrar y asegurar lo que genera una herramienta va a cambiar, y que eso exige un perfil técnico distinto, más centrado en arquitectura, seguridad y criterio de sistema que en producción manual de líneas de código. Si esa transición implica que el equipo necesita formación específica y tiempo protegido para adquirirla, el CTO debe conseguir ese tiempo y ese presupuesto de dirección, no limitarse a pedirle al equipo que se adapte por su cuenta en las horas libres. Esta transición del perfil técnico es exactamente el terreno donde más ayuda un plan de upskilling para retener el talento durante la adopción de IA: sin ese plan, la pregunta sobre el futuro del puesto se queda sin respuesta creíble.
Qué canales y momentos funcionan mejor para esta comunicación
Con dirección, funciona mejor un ritmo de comités técnicos breves y recurrentes, con lenguaje de negocio y no de arquitectura, donde el CTO informa de avances reales y de obstáculos encontrados, en lugar de una única presentación inicial que crea expectativas que luego nadie actualiza. La honestidad sobre los retrasos, comunicada pronto, genera más confianza a largo plazo que el silencio hasta que el problema ya no se puede ocultar.
Con el resto de la empresa, un canal de soporte claro y con tiempos de respuesta conocidos para dudas sobre herramientas de IA reduce mucho la tentación de que cada departamento improvise por su cuenta. Y con su propio equipo técnico, las reuniones habituales de planificación son el mejor momento para introducir de forma continua, y no como un anuncio puntual, cómo evoluciona el perfil del puesto, qué se está aprendiendo y qué resultados está dando esa nueva forma de trabajar, para que el cambio se viva como una evolución del oficio y no como una imposición repentina desde dirección.
Conclusión
Cómo comunica el CTO la estrategia de IA decide si la empresa avanza con expectativas realistas y una adopción segura, o si se mueve entre la promesa incumplida y el bloqueo permanente. El mensaje correcto habla de viabilidad y plazos honestos, nunca de soluciones mágicas ni de prohibiciones sin alternativa; se adapta según hable con dirección, otros departamentos o su propio equipo técnico; responde con honestidad sobre cómo cambia el perfil técnico y qué formación lo sostiene; y se apoya en comités recurrentes y en un canal de soporte claro, no en una única presentación inicial.
En MG Solutions ayudamos a equipos de IT a construir esta comunicación y a formar a sus equipos para la transición técnica que exige la IA. Si quieres preparar este mensaje antes de lanzarlo, pide información sobre formación en IA y lo trabajamos juntos.