Qué hace un CTO de IA en una empresa (y cuándo hace falta uno)

El síntoma real: nadie sabe qué priorizar y se busca un cargo para taparlo

La conversación empieza casi siempre igual. Un gerente general me cuenta que la empresa lleva un año «haciendo cosas de IA»: un piloto de atención al cliente que quedó a medias, automatizaciones que armó alguien de marketing y que nadie mantiene, una propuesta de agencia que el directorio no sabe si aprobar. Y cierra con la frase que ya me sé de memoria: creo que necesitamos a alguien que lidere esto. Lo que describe no es falta de liderazgo técnico. Es falta de criterio para decidir qué vale la pena y qué no.

La IA entró a las empresas por abajo y por los costados, no por el plan estratégico. Cuando eso se acumula un año, la empresa tiene actividad pero no tiene sistema. Y sin sistema, la reacción natural del directorio es contratar un cargo senior que ponga orden. El riesgo es conocido: un cargo caro sin una pregunta clara adelante construye su propio imperio técnico en vez de resolver el dolor que originó todo.

Qué es de verdad este rol (y por qué el anuncio de empleo lo describe mal)

Las descripciones de puesto de CTO de IA repiten siempre la misma lista: arquitecturas de modelos, experiencia en MLOps, dominio de proveedores de nube, maestría deseable. Esa lista describe un perfil técnico, no un rol de dirección. Y es la razón por la que muchas empresas terminan contratando a alguien brillante en lo suyo que no mueve un solo indicador de negocio en dieciocho meses.

Lo que hace difícil este rol no es la parte de IA. Es la parte de análisis de procesos y de gestión. Un CTO de IA pasa más tiempo entendiendo por qué cobranzas tarda once días en cerrar un caso que eligiendo entre dos arquitecturas. Tiene que mapear el flujo real (no el del manual), ver dónde se pierde dinero, traducir eso a una intervención concreta y defender ante el directorio por qué esa y no otra. La parte técnica es la última milla, no la primera.

Qué hace en la semana real: decide, corta y responde

Fuera del papel, el trabajo se parece poco a lo que imagina el directorio. No está entrenando modelos. Está tomando decisiones que la empresa no puede deshacer barato, y sosteniéndolas cuando algo falla en producción. Esta es la carga real del rol:

• Decide qué se construye y qué se compra. La mayoría de casos de uso de una empresa mediana ya tienen solución comprable. Construir internamente solo se justifica cuando el proceso es ventaja competitiva real o cuando ningún proveedor puede tocar esos datos.
• Define la arquitectura de datos antes que la de modelos. Sin datos ordenados, accesibles y con dueño, cualquier proyecto se queda en demo. Buena parte del primer año se va en trabajo de plomería que nadie aplaude en el directorio.
• Establece qué riesgos se aceptan. Qué información puede salir de la empresa, qué decisiones puede tomar un sistema sin humano revisando, qué pasa cuando el modelo se equivoca frente a un cliente. Se escribe antes del incidente, no después.
• Negocia y audita proveedores. Contratos, niveles de servicio, propiedad del código y de los datos, condiciones de salida. Quien no sabe leer un contrato deja a la empresa amarrada sin darse cuenta.
• Corta proyectos. Es la función más impopular y la más valiosa. Un portafolio de IA sano tiene más cosas apagadas que encendidas, y alguien tiene que tener el estómago para apagarlas.

Se contrata por resultados entregados, no por certificaciones

Este es el punto donde más empresas se equivocan, y quiero dejarlo explícito. El rol se evalúa por el resultado de negocio que produce y por la capacidad de análisis y gestión de procesos que exige, no por el stack técnico que domina ni por los títulos que suele pedir un anuncio de empleo. Un CTO de IA que responde todo en jerga técnica y no puede explicar el impacto en el negocio es exactamente el perfil que hay que evitar. No porque sea mal profesional, sino porque ese perfil pertenece a otro rol.

Las certificaciones de nube y los cursos de especialización dicen algo sobre la capacidad de estudiar de una persona. No dicen nada sobre su capacidad de entrar a una empresa desordenada, entender por qué facturación tarda lo que tarda, convencer a un gerente escéptico y entregar algo que en seis meses siga funcionando sin que nadie lo empuje. Esa segunda capacidad es la escasa.

Qué preguntar en la entrevista si quieres filtrar de verdad

• Cuéntame un proceso que rediseñaste: qué medías antes, qué mides ahora y cuánto tiempo pasó entre las dos mediciones.
• Qué proyecto de IA cancelaste tú mismo, y cómo se lo explicaste a quien lo estaba pidiendo.
• Dame un caso donde recomendaste no usar IA. Qué se hizo en su lugar.
• Qué salió mal en producción con un sistema tuyo y cómo lo detectaste. Si nunca se le rompió nada, o no ha operado de verdad, o no está siendo honesto.
• Explícame tu último proyecto como se lo explicarías a mi gerente de finanzas, sin una sola palabra técnica.

Ninguna de esas preguntas indaga en el stack. La solvencia técnica importa, y se verifica aparte con alguien del equipo que sepa, pero es requisito de entrada, no criterio de selección. El criterio es si esta persona convierte un dolor operativo confuso en una intervención acotada que produzca un número distinto al final del trimestre.

Qué NO es y qué no resuelve un CTO de IA

• No reemplaza una estrategia de negocio. Si la empresa no sabe dónde quiere crecer ni qué la está frenando, va a construir sistemas correctos para preguntas equivocadas. La IA no arregla una mala estrategia: la expone más rápido y más caro.
• No sustituye el trabajo de las áreas. Nadie rediseña el proceso de cobranzas desde tecnología si el gerente de cobranzas no quiere cambiar nada. El rol necesita mandato explícito de gerencia general para tocar procesos ajenos.
• No arregla datos sucios por decreto. Si la información de clientes vive en tres sistemas que no se hablan, el primer año es limpieza, no innovación. Conviene saberlo antes de firmar, para ambos lados.
• No es un vendedor interno de IA. Si el encargo real es evangelizar para que la empresa se vea moderna, eso es marketing corporativo y cuesta mucho menos.
• No absorbe solo la responsabilidad de gobierno. Marcos como el de gestión de riesgos de IA del NIST plantean el riesgo como algo transversal, con roles en legal, negocio y dirección. Un solo cargo no puede ser dueño de todo el riesgo.

Cuándo el rol se justifica de verdad y cuándo es una contratación cara

La pregunta no es si la IA es importante para tu empresa. Lo es. La pregunta es si el cuello de botella actual se destraba con un cargo permanente de dirección tecnológica o con algo más barato y más rápido. El estudio anual de McKinsey sobre el estado de la IA muestra que el uso se expandió mucho más rápido que la capacidad de capturar valor con él. Ese desfase rara vez se cierra contratando: se cierra priorizando.

Cuándo sí tiene sentido contratarlo

• Ya tienes dos o tres sistemas de IA en producción real, usados por gente que no es del equipo de tecnología, y necesitan mantenimiento continuo.
• La IA toca datos sensibles de clientes o decisiones con consecuencia regulatoria, y hoy nadie responde formalmente por eso.
• El gasto anual comprometido en licencias, proveedores e infraestructura ya es tan alto que una mala decisión de arquitectura cuesta más que el sueldo del rol.
• La IA es parte de lo que la empresa vende, no solo una mejora interna. Ahí el rol es de producto, no de soporte.
• Hay equipo técnico interno que dirigir y mandato de gerencia general para cambiar procesos de otras áreas, incluso cuando esas áreas se resistan.

Cuándo es una contratación cara que tapa un problema de estrategia

• Nadie puede nombrar los tres procesos que más dinero o tiempo están perdiendo hoy. Eso es un problema de diagnóstico, no de dirección técnica.
• Los pilotos anteriores fracasaron y nadie hizo la autopsia. Contratar a alguien nuevo sin entender por qué falló lo anterior garantiza repetirlo con más presupuesto.
• Se busca el rol para responderle al directorio o para poder decir en el mercado que la empresa tiene uno.
• El volumen de operación todavía es bajo. Con poco volumen, el ahorro absoluto nunca paga el costo del rol y su equipo.
• Lo que se necesita en realidad es un responsable de adopción y portafolio, más cercano a operaciones que a tecnología. Cuesta menos y destraba más rápido.

Errores típicos en empresas que ya lo contrataron

• Colgarlo del área de sistemas sin voz en el comité de dirección. Si reporta tres niveles abajo, no puede cambiar procesos de otras áreas y termina haciendo soporte técnico avanzado.
• Contratar por el currículum más impresionante en vez del más pertinente. Quien construyó modelos con equipos grandes puede naufragar en una empresa mediana donde hay que hacer todo con dos personas y sistemas viejos.
• No definir qué decisiones puede tomar solo. Sin límites claros de presupuesto y autonomía, cada decisión sube a gerencia general y el rol se vuelve un cuello de botella.
• Medir su desempeño por cantidad de proyectos lanzados. Eso premia el volumen y castiga el criterio. Un buen trimestre puede ser dos cosas lanzadas y cuatro descartadas con argumento.
• Dejar que el rol sea el único lugar donde reside el conocimiento de IA. Si esa persona se va y con ella se van los criterios y los contratos, la empresa vuelve al punto cero.

Cómo medir si la contratación funcionó

El primer error de medición es evaluar el rol por actividad. Iniciativas abiertas, herramientas evaluadas, capacitaciones dictadas: todo eso se puede llenar sin que la empresa opere distinto. La evaluación honesta necesita señales que un gerente de finanzas entienda sin traducción:

• Procesos de negocio que hoy funcionan distinto que hace seis meses, nombrados uno por uno, con el responsable de área confirmando el cambio.
• Tiempo de ciclo del proceso intervenido, medido antes y después con el mismo método. Sin línea base previa, el número de después no prueba nada.
• Porcentaje de casos que el sistema resuelve sin intervención humana, y qué pasó con los que sí la necesitaron.
• Costo total de operar lo construido: licencias, infraestructura y horas de mantenimiento. No el costo del proyecto, el costo de que siga vivo.
• Uso sostenido por las áreas pasado el tercer mes, cuando ya nadie está encima empujando la adopción.
• Decisiones documentadas de qué no se hizo y por qué. Un portafolio sin descartes es un portafolio sin criterio.
• Incidentes en producción y tiempo de detección. Que haya incidentes es normal; que nadie los detecte hasta que se queja un cliente, no.

Si al año la evaluación se sostiene con esas señales, la contratación funcionó, aunque haya menos proyectos lanzados de los que el directorio esperaba. Si se sostiene con nombres de tecnologías y planes de plataforma, la empresa contrató un cargo técnico caro y sigue sin resolver lo que la trajo hasta acá. Esa corrección conviene hacerla al primer año, no al tercero.