Cómo la IA ayuda a un CTO

Tiempo de lectura: 8 minutos

Cuando un comité de dirección pregunta «¿qué estamos haciendo con la IA?», casi siempre mira al CTO. Y la pregunta llega mezclada con otras: por qué el roadmap no va más rápido si ahora el código «se escribe solo», cuánto va a costar, qué pasa con los datos de los clientes, si hará falta menos gente.

Es fácil contestar a todo eso desde la tecnología: qué herramientas, qué piloto, qué proveedor. Pero la mayoría de esas preguntas no son técnicas. Son de dinero, de riesgo, de personas y de estrategia. Y en todas ellas la IA puede ayudar al CTO, si se usa con criterio y se mide por lo que cambia, no por lo que se genera.

Qué retos tiene hoy un CTO con la IA

1. La presión por hacer algo. Llega desde arriba («la competencia ya lo usa») y desde abajo: gente del equipo que ya usa IA por su cuenta, a veces con datos de clientes en cuentas personales. En medio, el CTO tiene que decidir sin tener todavía datos propios de qué funciona en su empresa.

2. El cuello de botella se ha movido. Cuando escribir código se vuelve casi gratis, lo lento pasa a ser revisar, integrar y decidir qué construir. Andrew Ng lo llama el cuello de botella de producto: los agentes aceleran la construcción a partir de una especificación, y lo que frena es decidir qué especificar (Ng, 2025). Si el plan no cambia, el área de tecnología produce más y entrega lo mismo. Lo conté en Generar código sin revisar no escala.

3. El coste que no sale en la factura de licencias. Las licencias son la parte pequeña. Lo caro es el uso de modelos en las funcionalidades que ya están en producción, el mantenimiento de lo generado y la deuda que deja el código que nadie entiende del todo.

4. Las personas. Los equipos pasan de hacer a validar, y eso cansa de una forma distinta. Hay quien teme por su puesto y quien corre demasiado. Las dos reacciones son razonables desde donde está cada uno, y las dos hay que gestionarlas.

5. El marco legal. El Reglamento europeo de IA ya se aplica y, desde febrero de 2025, su artículo 4 exige que quien usa IA en la empresa sepa usarla. Alguien tiene que saber qué IA se usa, con qué datos y para qué. Esa pregunta suele acabar en la mesa del CTO.

Qué oportunidades abre la IA para un CTO

La más inmediata es que probar sale barato. Antes, elegir entre dos arquitecturas o dos enfoques de producto era una discusión con diagramas. Ahora se pueden construir los dos en pequeño y comparar con datos antes de comprometer un trimestre.

La segunda es quitar trabajo recurrente al equipo. Will Larson, CTO de Imprint, cuenta que en un año pasaron de unos 6 despliegues por semana a entre 200 y 400, y que la clasificación de incidencias de soporte y la primera revisión del código ya las hacen agentes (Larson, 2026). No es magia: detrás hay tests, integración continua y entornos de prueba que hacen seguro delegar.

La tercera es reabrir decisiones que parecían cerradas. Seguir pagando un SaaS caro o construir lo justo internamente, cambiar o no el ERP o el CRM: con la IA cambian los números de esas decisiones, y merece la pena volver a hacerlos. Lo trabajé en cómo decidir si internalizar un SaaS con IA (con calculadora) y en por qué la IA reabre la decisión de cambiar tu ERP o tu CRM.

Y la cuarta, menos evidente: más peso en las decisiones de negocio. Si el área de tecnología puede probar una idea en días, el CTO deja de ser quien dice cuánto tarda algo y pasa a ser quien ayuda a decidir qué vale la pena probar. Para eso la IA también sirve fuera del código: preparar opciones con su coste, ordenar peticiones con criterios explícitos o traducir una decisión técnica al idioma del comité.

Qué cambia en el área de tecnología y cómo se convierte en palanca para el negocio

Lo que cambia, en una frase, es dónde está el trabajo caro. Antes era escribir. Ahora es especificar bien, revisar, integrar y medir. Larson lo cuenta con su última migración grande: el equipo pasó casi todo el tiempo diseñando el enfoque y revisando lo que generaban los agentes; implementar ya no era lo caro (Larson, 2026).

Eso tiene tres consecuencias prácticas para el área de tecnología:

1. Las especificaciones vuelven a ser trabajo de primera. Un agente con una especificación vaga devuelve algo plausible y equivocado. Con criterios de aceptación claros, el resultado se revisa en minutos. Es lo que desarrollo en Spec-Driven Development: specs que la IA convierte en código sin retrabajo.

2. El arnés técnico deja de ser opcional. Tests, integración continua, entornos de prueba y comprobaciones automáticas son lo que permite revisar rápido sin bajar la guardia. Sin ellos, delegar en agentes solo cambia el riesgo de sitio.

3. Se mide el flujo, no el volumen. Contar líneas generadas o tareas cerradas premia justo lo que no se busca. El informe DORA de 2025 describe la IA como un amplificador: mejora a los equipos que ya funcionaban bien y agrava los problemas de los que no (DORA, 2025). El tiempo de ciclo, la frecuencia de despliegue y los fallos en producción dicen si la IA ayuda o solo acelera el caos. Tienes la chuleta de métricas DORA y de flujo para empezar.

Como palanca para el negocio, lo que se gana no es «más código». Es menos tiempo entre una idea y la evidencia de si funciona. Un área de tecnología que puede poner delante de clientes reales tres variantes de una funcionalidad en una semana cambia la conversación con negocio: ya no se discute qué opinión gana, se mira qué dicen los datos.

Lo vivo a pequeña escala. La web de ITNOVE la desarrollo yo solo, con agentes. Lo que más me ha cambiado no es la velocidad. Es que cada cambio grande de cara al público queda apuntado con su fecha, y lo cruzo con visitas, conversiones e ingresos para saber si sirvió o no.

Qué implica para liderar personas y equipos

Cuando el trabajo pasa de hacer a validar, liderar cambia en cuatro puntos.

1. La carga. Validar lo que generan varios agentes a la vez cansa más de lo que parece, porque cada agente que termina es una interrupción. Lo que funciona es tener pocos frentes abiertos por persona, no lanzar nada sin especificación y revisar en franjas fijas. Lo explico con detalle en cómo trabajar con agentes sin quemar al equipo.

2. Los acuerdos. Si cada persona usa la IA a su manera, aparecen la desconfianza y la incoherencia. Unos pocos acuerdos de equipo para usar IA y una Definición de Done adaptada, en la que «hecho» incluye «revisado por alguien que puede explicarlo», evitan la mayoría de los problemas.

3. El aprendizaje. Aprender a trabajar con agentes lleva tiempo, y ese tiempo sale de algún sitio. Lo que funciona es ponerlo en el calendario y descontarlo de la carga del sprint, no pedirlo «además de». La hoja de readiness para empezar con IA en tu equipo ayuda a ver qué preparar primero y en qué orden.

4. Tú. Larson lo dice sin rodeos: si quieres liderar la adopción de IA, tienes que usar las herramientas tú mismo (Larson, 2025). Quien no las usa no sabe qué pedir ni qué revisar, y acaba aprobando presupuestos a ciegas.

Dos avisos que valen para el CTO y para todo el equipo. En el estudio de Harvard y BCG con 758 consultores, en las tareas que la IA hacía bien la calidad subió un 40 %; en una tarea fuera de su alcance, quienes la usaban acertaron entre un 60 y un 70 % de las veces, frente al 84 % de quienes no la usaban (Mollick, 2023). Y los asistentes tienden a coincidir con la opinión de quien pregunta, aunque esté equivocado (Anthropic, 2024). Si se usa la IA para contrastar una decisión, hay que pedirle expresamente que argumente en contra.

Cómo contribuye el CTO al gobierno de la IA

El gobierno de la IA no es un documento legal. Es saber qué IA se usa, con qué datos, para qué decisiones y quién responde si se equivoca. El CTO aporta cuatro cosas que nadie más en el comité puede aportar igual.

1. El inventario real. Qué herramientas y modelos se usan, quién los usa y qué datos pasan por ellos. Incluida la IA que la gente usa por su cuenta, que suele ser la mayor parte al principio.

2. El criterio de riesgo técnico. Qué automatizaciones tocan datos de personas o decisiones sobre clientes, y dónde un error se descubre tarde.

3. Los controles dentro del sistema, no en un PDF. Permisos, registros y revisiones obligatorias donde el riesgo es alto. Un control que vive en el flujo de trabajo se cumple; uno que vive en un documento depende de la memoria de cada persona.

4. La alfabetización. Que quien usa IA sepa qué delegar y qué revisar. Es lo que pide el artículo 4 del Reglamento, y el curso gratuito de alfabetización en IA cubre ese mínimo en 90 minutos.

Para empezar, la política de uso de la IA en la empresa es una plantilla editable lista para adaptar, y el checklist de preparación para el AI Act te dice en cinco minutos en qué punto estás. Lo que hicimos en nuestra propia web está en El AI Act ya aplica: cómo hemos preparado nuestra propia web, y el marco completo en Legalidad de la IA en la empresa: RGPD, EU AI Act y gobernanza.

Cómo evitar que el gobierno de la IA se convierta en burocracia

El riesgo contrario es igual de real: un comité que tiene que aprobar cada uso, formularios para todo y una política que nadie lee. El resultado es que la gente sigue usando IA, pero a escondidas, que es justo lo que el gobierno quería evitar.

Lo que funciona es un gobierno proporcional al riesgo: el caso habitual no necesita permiso y el caso arriesgado no pasa sin dueño.

Tres hábitos ayudan a que se mantenga así:

1. Las peticiones tienen respuesta con fecha. Si alguien pide usar una herramienta nueva, sabe cuándo tendrá respuesta. Un gobierno que tarda un mes en contestar empuja a la gente a no preguntar.

2. La política se revisa, no se engorda. Cada trimestre se mira qué reglas han servido y cuáles nadie ha necesitado. Añadir una regla por cada susto acaba en un documento que nadie lee.

3. El control va al sistema antes que a la reunión. Larson lo plantea igual para los procesos de ingeniería: automatizar el caso habitual y reservar el criterio humano para las zonas de más riesgo (Larson, 2026).

Si quieres montarlo con ayuda, en ITNOVE hacemos un diagnóstico de gobierno de IA en tres semanas, y el curso Gobernanza de IA: del AI Act al sistema que no frena lo cuenta paso a paso.

Cómo usar la IA por su impacto en el cliente y en la empresa, no por moda

La forma más rápida de saber si una iniciativa de IA va por moda es mirar qué mide. Si mide licencias activas, número de consultas o porcentaje de código generado, está midiendo esfuerzo, no resultado.

El modelo lógico de proyecto (project logic model) ayuda a ponerlo en su sitio. Distingue cinco etapas en la creación de valor: recursos, actividades, producto, resultados para el cliente e impacto para la empresa. Lo explico en el modelo lógico de proyecto en EBM. Separar resultados e impacto importa: lo primero mira si al cliente le va mejor; lo segundo, si a la empresa le compensa.

Con el caso que usamos en formación, GymTonic, se ve claro. La cadena de gimnasios quiere usar IA para responder las consultas de sus socios en la app GymApp.

Es fácil quedarse en las dos primeras etapas, porque son las que se miden solas. Lo práctico es decidir antes de empezar qué resultado y qué impacto se esperan, con qué métrica y en qué fecha se decide si la iniciativa sigue, cambia o se para. Parar también es un resultado: si los socios no resuelven antes sus dudas, da igual cuántas consultas haya respondido la IA.

Esto conecta con tres artículos que pueden servirte de filtro: cuándo un agente de IA aporta valor de verdad y cuándo es humo, por qué generar código con IA es fácil pero crear impacto no tanto y las preguntas que se hace un comité antes de invertir en IA.

Cómo puede ayudar el CTO a alinear la estrategia y la agilidad de la empresa

Aquí está, para mí, la oportunidad más grande. Cuando probar es barato, el área de tecnología puede convertirse en el sitio donde la estrategia se pone a prueba, no solo donde se ejecuta. Eso le pide al CTO tres cosas.

1. Traducir la estrategia en apuestas medibles. Cada objetivo de negocio, convertido en hipótesis que se pueden probar con un plazo y una métrica de resultado. Los OKR ayudan si se usan así, como cuento en OKR + IA: objetivos que la IA te ayuda a ejecutar, no a inflar.

2. Hacer visible la capacidad real. Con IA, la tentación es aceptar más iniciativas «porque ahora se puede». Enseñar cuánto trabajo hay abierto y cuánto tarda en salir obliga a priorizar de verdad. Es la conversación de cómo alinear liderazgo, estrategia y equipos.

3. Devolver evidencia rápido. Si una apuesta no funciona, que se sepa en semanas y no al cierre del año. Ahí la IA sí acelera: prototipos, análisis de datos de uso, resúmenes de entrevistas con clientes.

Larson añade una condición: la IA solo aporta de verdad si las decisiones se toman rápido, bien y se sostienen. Y muchas veces el CTO es la única persona que puede tomar una decisión vinculante cuando los equipos no se ponen de acuerdo (Larson, 2026). Eso ya no es agilidad del área de tecnología: es agilidad del negocio.

Si quieres ver cómo se organiza una empresa alrededor de productos y resultados, el Agile Product Operating Model es un buen punto de partida, y la guía de formaciones Business Agility para roles de negocio ordena qué aprender según el rol de cada persona del comité.

Por dónde empezar: un plan de seis semanas

Este plan pide unas horas por semana del CTO y de las personas que aparecen en la tabla, sobre todo en las semanas 1, 3 y 6. Si tu empresa ya tiene un comité de IA que funciona, empieza en la semana 3. El error más habitual es saltarse la semana 3 y empezar por la herramienta: es lo que convierte un piloto en una demo que nadie sabe si sirvió.

Si quieres saber en qué punto está tu organización antes de empezar, el diagnóstico del gobierno de la IA tarda tres minutos y te da un informe con por dónde seguir. Y si el problema es que los pilotos no llegan a producción ni a resultados, es justo lo que trabajamos en IA sin resultados.

Preguntas frecuentes

¿Cómo puede la IA ayudar a un CTO en su trabajo? De dos formas. En el área de tecnología, abaratando las pruebas, quitando trabajo recurrente al equipo y acelerando el paso de una idea a la evidencia de si funciona. En su papel de directivo, ayudándole a preparar opciones con su coste, ordenar prioridades con criterios explícitos y traducir decisiones técnicas al idioma del negocio. En los dos casos la decisión sigue siendo suya, y conviene pedirle a la IA que argumente en contra.

¿Qué papel tiene el CTO en el gobierno de la IA de una empresa? Aporta el inventario real de qué IA se usa y con qué datos, el criterio de riesgo técnico, los controles dentro del sistema (permisos, registros, revisiones) y la alfabetización del equipo que exige el artículo 4 del Reglamento europeo de IA. Legal, RRHH y negocio aportan el resto. Sin el CTO, el gobierno se queda en un documento que no se cumple.

¿Cómo se evita que el gobierno de la IA frene a los equipos? Con un gobierno proporcional al riesgo: los usos de riesgo bajo están permitidos por defecto con una política de una página, los de riesgo medio llevan revisión humana dentro del flujo de trabajo y solo los de riesgo alto pasan por un comité. Ayuda que cada petición tenga respuesta con fecha y que la política se revise cada trimestre en vez de crecer con cada susto.

¿Cómo se mide el impacto de la IA en una empresa? Con el modelo lógico de proyecto, que separa recursos, actividades, producto, resultados para el cliente e impacto para la empresa. Las licencias, las consultas o el código generado miden esfuerzo. El valor se mide en las dos últimas etapas, decidiendo antes de empezar qué resultado e impacto se esperan, con qué métrica y en qué fecha se decide si la iniciativa sigue, cambia o se para.

¿Qué cambia en el liderazgo de un equipo técnico que trabaja con agentes de IA? El trabajo pasa de hacer a validar, y eso cambia la carga, los acuerdos y el aprendizaje. Funciona limitar los frentes abiertos por persona, acordar qué se revisa y quién, incluir «revisado por alguien que puede explicarlo» en la Definición de Done y reservar tiempo de aprendizaje en el calendario. Y quien lidera tiene que usar las herramientas para saber qué pedir y qué revisar.

Recursos relacionados

• 7 preguntas que un directivo debería hacerse sobre la IA
• Política de uso de la IA en la empresa (plantilla)
• Checklist de preparación para el AI Act
• El modelo lógico de proyecto en EBM
• Generar código sin revisar no escala
• Cómo trabajar con agentes sin quemar al equipo
• IA sin gobernanza es un riesgo: cómo Scrum y OKR amplifican (y protegen) tu IA