Puntos clave
- AI dirige una empresa en la que AI es el producto, no una característica. Su función difiere notablemente de la de un producto CTO que, casualmente, utiliza AI para algunas de sus características.
- La estrategia tecnológica se basa en la disyuntiva «crear o comprar» en lo que respecta a los modelos base. La mayoría de los directores técnicos de AI compran el modelo base y crean diferenciación en la recuperación, el ajuste fino, los agentes y la experiencia del producto.
- La estructura organizativa de ingeniería divide en plataforma, producto e investigación. El diseño organizativo basado en los límites de los servicios funciona peor cuando la capa del modelo abarca varias funciones.
- La evaluación y el red-teaming son disciplinas de ingeniería con personal dedicado. No son eventos solo para el lanzamiento. Los equipos que lanzan productos AI fiables tienen procesos de evaluación en la misma ruta crítica que el trabajo en las funciones.
- El coste de inferencia es el nuevo coste de infraestructura. La economía de tokens por función es una métrica de primer orden para CTO; de lo contrario, la empresa lanza demos que pierden dinero a gran escala.
El CTO cuya empresa construyó un motor de recomendaciones en 2018 y el CTO cuya empresa está construyendo un producto nativo de AI en 2026 no están realizando el mismo trabajo. El CTO de 2018 tenía un organigrama basado en los límites del servicio, una estructura de costes propia de la economía SaaS, una cadencia de evaluación trimestral centrada en el tiempo de actividad y la entrega de funcionalidades, y una lista de proveedores dominada por proveedores de infraestructura. El AI de 2026 tiene una organización de ingeniería estructurada en torno al ciclo modelo-datos-evaluación, una estructura de costes dominada por la economía de la inferencia, una disciplina de evaluación que se ejecuta de forma continua en la misma ruta crítica que el producto, y una lista de proveedores dominada por proveedores de modelos base cuyas hojas de ruta el CTO tiene que seguir con el mismo nivel de detalle que un CTO de 2018 reservaba para el proveedor de la nube.
Esta página está dirigida al CTO que se encuentra en plena transición hacia la forma nativa del rol AI, y a la junta directiva o al CEO que intenta verificar si un candidato ha creado realmente una de estas empresas anteriormente. El artículo complementario es AI CIO, que aborda la evolución paralela en empresas donde el AI se encuentra dentro del entorno de TI en lugar de en el núcleo del producto.
Construir o comprar el modelo base
La decisión estratégica determinante para una AI CTO en 2026 es la postura respecto a la capa del modelo base. La decisión tiene tres formas en la práctica, y casi todas las empresas nativas de AI por debajo de la escala de un laboratorio de modelos base se sitúan en la segunda.
Construir tu propio modelo base desde cero. El coste sigue siendo de cientos de millones de dólares para un modelo de vanguardia competitivo, el talento capaz de entrenar en la vanguardia se concentra en un puñado de laboratorios a nivel mundial (OpenAI, Anthropic, Google DeepMind, además de un pequeño grupo de competidores bien financiados), y cualquier modelo base que entrenes hoy estará entre seis y nueve meses por detrás de la vanguardia para cuando se lance. Esta vía tiene sentido para los propios laboratorios de modelos base, para contextos normativos en los que la dependencia externa es insostenible y para un pequeño grupo de empresas en las que el modelo en sí es el producto, en lugar de un componente. Para casi todas las demás empresas nativas de AI, las cuentas no cuadran.
Comprar el modelo base y construir la diferenciación a partir de él. El patrón que se ha estabilizado en la mayoría de las empresas de SaaS nativas de AI. La empresa CTO selecciona uno o dos proveedores de modelos base, los trata como proveedores estratégicos al nivel de los proveedores de nube en una empresa de SaaS tradicional y concentra la inversión en ingeniería en la capa de recuperación, el proceso de ajuste fino, el andamiaje del agente, la disciplina de evaluación y la experiencia del producto. La diferenciación reside en lo que la empresa hace con el modelo, no en el modelo en sí. Esta forma es donde se invierte la mayor parte del tiempo de las empresas nativas de SaaS.
Comprar todo, construir solo la superficie del producto. Adecuado para empresas nativas de AI en fase inicial que aún están validando el ajuste producto-mercado, donde la capacidad del equipo es demasiado limitada para invertir en las capas de recuperación y evaluación, y la pregunta inmediata es si alguien pagará por lo que produce el producto. La mayoría de las empresas que sobreviven a la validación pasan de esta forma a la anterior en un plazo de 12 a 18 meses.
«En una empresa nativa de AI, la estrategia tecnológica y la estrategia de proveedores de modelos base son la misma conversación. El CTO que trata el modelo como una relación más con un proveedor aún no ha entendido el fondo del asunto».
Diseño de la organización de ingeniería en torno a los productos nativos de AI
La estructura organizativa que se ha estabilizado en la mayoría de las empresas nativas de AI en 2026 se divide en tres funciones de primer nivel, lo que supone una forma diferente de la división por límites de servicio que domina las organizaciones de ingeniería SaaS tradicionales.
Equipo de la plataforma de modelos
Es responsable de la capa de modelos de principio a fin: la infraestructura de inferencia, la lógica de enrutamiento de modelos, el nivel de almacenamiento en caché, el proceso de evaluación, la observabilidad y la telemetría en torno al comportamiento de los modelos en producción. El tamaño varía en función de la complejidad del producto, más que del número total de empleados de la empresa. Una estructura más reducida (entre el 5 % y el 10 % del equipo de ingeniería) es la norma en las empresas nativas de AI en fase inicial; las empresas cuya complejidad de producto exige una mayor inversión en la plataforma tendrán una estructura más amplia, a veces entre el 15 % y el 25 % de una organización, cuando el aprovechamiento de la plataforma sea la restricción determinante de la velocidad del producto.
Ingeniería de producto
Organizada en torno a casos de uso verticales o interfaces de producto que consumen la plataforma de modelos. Cada equipo es responsable de su parte del producto, se integra con la capa de la plataforma y lanza funcionalidades. La estructura de equipos resultará familiar a cualquiera que provenga de una empresa SaaS tradicional, pero los resultados son diferentes. En lugar de lanzar un servicio que gestiona un flujo de trabajo CRUD, el equipo lanza un flujo de trabajo impulsado por AI que depende de que la plataforma modelo funcione correctamente en casos extremos que el equipo no puede probar fácilmente de forma aislada.
Investigación aplicada
Se encarga del ajuste fino, el trabajo con modelos personalizados, el proceso de experimentación y las apuestas técnicas más profundas sobre el comportamiento de los modelos. La mayoría de las empresas nativas de AI cuentan con una pequeña función de investigación aplicada (entre 5 y 15 personas en la mayoría de las empresas con menos de 500 empleados en total) estrechamente vinculada a la hoja de ruta del producto, en lugar de llevar a cabo agendas de investigación independientes. Su función es traducir la investigación de vanguardia en ingeniería lista para su lanzamiento, no publicar artículos.
La evaluación y el «red teaming» como ingeniería de primer orden
La disciplina de la evaluación es la diferencia más consistente entre los directores técnicos (CTO) de AI cuyos productos sobreviven al segundo año y los CTO de AI cuyos productos se deterioran silenciosamente. Tres prácticas específicas se observan en las empresas que lo hacen bien.
Conjuntos de pruebas de evaluación en la ruta crítica. Mantenidos con el mismo rigor de ingeniería que el conjunto de pruebas. Un cambio de modelo que no supera la evaluación sale al mercado con la misma frecuencia que un cambio de código que no supera el conjunto de pruebas, es decir, casi nunca. El conjunto cubre las capacidades básicas, los modos de fallo conocidos a partir de incidentes de producción y los casos extremos de cola larga que se han acumulado a medida que el producto maduraba. La cobertura crece con la superficie del producto, no con la capa del modelo.
El «red teaming» como práctica operativa continua. Un equipo dedicado (a veces dentro de la organización de la plataforma, a veces una organización hermana que depende directamente del CTO) realiza pruebas continuas para detectar inyecciones de prompts, fugas de seguridad, patrones de alucinaciones, superficies de sesgo y otros modos de fallo del modelo. La cadencia es semanal o diaria, dependiendo de la fase en la que se encuentre la empresa. Los hallazgos del equipo rojo se incorporan al conjunto de pruebas de evaluación, a la lógica de enrutamiento del modelo y a la lista de tareas pendientes del equipo de producto como incidencias estándar.
Canales de evaluación en línea. Los resultados de los modelos de producción se muestrean y se comparan de forma continua con trazas de referencia, estándares de referencia reservados o evaluaciones en las que un LLM actúa como juez. Las regresiones silenciosas —el caso en el que el producto sigue funcionando, pero la calidad se ha degradado de formas de las que ningún usuario se ha quejado aún— se señalan antes de que se acumulen y se conviertan en un problema de pérdida de clientes. Esta es la disciplina que separa a las empresas que aprenden de los datos de producción de las que lanzan el producto y rezan por lo mejor.
El marco OpenAI Evals, los patrones de evaluación publicados por Anthropic y los cursos de evaluación de DeepLearning.AI han convergido en disciplinas similares durante los últimos dos años; los patrones publicados están lo suficientemente maduros como para que no haya excusa para que un AI CTO se salte este trabajo.
La economía de la inferencia como métrica de primer orden
En la mayoría de las empresas nativas de AI en 2026, el coste de inferencia es la partida de costes variables más importante, a menudo mayor que la infraestructura y comparable a la nómina una vez que se tiene en cuenta el coste de venta. El AI CTO que no trate esto como una métrica de primer orden toma decisiones de precios a ciegas y ve cómo su margen se reduce silenciosamente a medida que crece el uso.
La disciplina que importa es la economía unitaria por característica. Para cada característica principal del producto, hay tres cifras: tokens consumidos por servicio (entrada más salida, incluyendo cualquier agente o estructura de recuperación), margen bruto por servicio en el nivel de precios actual y la curva de escalado prevista a medida que crece el uso. Los directores técnicos de AI que tienen estas cifras en mente para las diez funciones principales toman decisiones de precios, enrutamiento y arquitectura que se potencian entre sí. Los que no lo hacen acaban explicando una historia de compresión de márgenes a CFO a los 18 meses.
Hay unos cuantos patrones arquitectónicos que aparecen de forma sistemática en las empresas que han acertado con la economía de la inferencia. Enrutamiento de modelos: utilizar modelos más pequeños y baratos para las solicitudes que pueden gestionar y reservar los modelos de vanguardia para las solicitudes que los exigen. Capas de almacenamiento en caché para patrones de consulta repetidos, para incrustaciones y para completamientos parciales. Filtros de características por nivel que alinean las características que requieren mucha inferencia con los niveles de ingresos que pueden absorber el coste. La mayoría de las empresas también incorporan la observabilidad del LLM como juez, de modo que las decisiones de enrutamiento puedan ser auditadas en lugar de simplemente confiarse en ellas. Nada de esto es nuevo en 2026, pero la disciplina de tratarlas como trabajo de ingeniería fundamental, en lugar de como optimizaciones que revisar más adelante, es lo que distingue a los directores técnicos de AI cuyas empresas sobreviven a la escalabilidad del mercado de productos de aquellos cuyas empresas no lo hacen.
Lecturas relacionadas
El pilar ejecutivo de tecnología abarca el papel más amplio del que el AI CTO es una variante. La página hermana sobre AI CIO trata la evolución paralela en empresas donde el AI se encuentra dentro del entorno de TI. Para la visión a nivel de cartera por encima de la organización de ingeniería, véase AI Strategy Executive. Para la comparación de funciones entre CTO, CAIO y CDAO, consulte CAIO frente a CTO frente a CDAO. Para hablar sobre una decisión específica de «construir o comprar» o sobre la estructura organizativa, reserve una llamada con un experto.
La ruta parcial hacia AI CTO es real. Consulte fractional Chief AI Officer para la variante a tiempo parcial del mismo puesto, o AI consultoría estratégica para la alternativa en forma de proyecto cuando el trabajo tiene un inicio y un final definidos.
Preguntas frecuentes
¿Qué hace realmente un AI CTO que no haga un CTO tradicional?
Cuatro líneas de trabajo que no se plantean de la misma manera en un puesto tradicional de producto CTO. En primer lugar, la decisión de «desarrollar o adquirir» en relación con el propio modelo base: qué proveedor, con qué licencia, con qué estrategia de ajuste y con qué plan de migración para cuando aparezca un modelo mejor dentro de seis meses. En segundo lugar, la estructura organizativa de ingeniería que da soporte a un producto nativo de AI, que difiere de la estructura organizativa basada en los límites del servicio que funciona para el SaaS tradicional. En tercer lugar, la disciplina de evaluación y del equipo rojo, que se sitúa en la misma ruta crítica que el lanzamiento de funcionalidades, ya que la capa del modelo puede degradarse de forma silenciosa de maneras que la degradación de los servicios tradicionales no puede. En cuarto lugar, la economía de la inferencia: la estructura de costes de un producto nativo de AI está dominada por los tokens consumidos en lugar de por la infraestructura alquilada, y quien no trate esto como una métrica de primer orden lanzará productos que pierden dinero a gran escala.
¿Debería una empresa nativa de AI desarrollar sus propios modelos base o utilizar modelos externos?
En 2026, prácticamente ninguna empresa nativa de AI que no alcance la envergadura de un laboratorio de modelos base debería estar entrenando modelos base desde cero. El coste del preentrenamiento de un modelo base competitivo se ha mantenido en el rango de los cientos de millones de dólares, y el campo sigue avanzando tan rápido que cualquier modelo que se entrene hoy estará entre seis y nueve meses por detrás de la vanguardia para cuando se lance al mercado. La estrategia que funciona para la gran mayoría de las empresas nativas de AI es comprar el modelo base y crear la diferenciación en la capa de recuperación, el ajuste fino, el andamiaje del agente, el proceso de evaluación y la experiencia del producto. Las empresas que deberían crear sus propios modelos base son aquellas en las que el modelo en sí mismo es el producto (laboratorios de modelos base) o aquellas en las que los requisitos normativos hacen insostenible la dependencia externa (algunos contextos de defensa, sanidad y servicios financieros).
¿En qué se diferencia la estructura organizativa de una empresa de ingeniería nativa de AI de la de una empresa tradicional de SaaS?
Las organizaciones de ingeniería SaaS tradicionales se estructuran en torno a los límites de los servicios: un equipo de pago, un equipo de facturación, un equipo de búsqueda y un equipo de notificaciones. Estos límites se ajustan a la arquitectura y el organigrama los refuerza. Los productos nativos de AI tienen una estructura diferente, ya que la capa de modelos trasciende las funcionalidades del producto y el «flywheel» de datos es más importante que la descomposición de los servicios. La estructura que se ha estabilizado en 2026 en la mayoría de las empresas nativas de AI tiene tres funciones de primer nivel: un equipo de plataforma de modelos que se encarga de la capa de modelos, la infraestructura de inferencia y el proceso de evaluación; una función de ingeniería de productos organizada en torno a casos de uso verticales que consume la plataforma; y una función de investigación aplicada que se ocupa del ajuste fino, el trabajo con modelos personalizados y el proceso de experimentación. Las proporciones exactas varían según la fase de la empresa, pero la división entre plataforma, producto e investigación es constante en todas las empresas que comercializan productos AI fiables.
¿Qué disciplina de evaluación y simulacros de ataque debe desarrollar AI CTO?
La evaluación es el equivalente nativo de AI a las pruebas de regresión, salvo que la cobertura de las pruebas debe diseñarse de forma deliberada y los modos de fallo son más sutiles. Tres prácticas diferencian a las empresas que lanzan productos AI fiables de las que lanzan demos. En primer lugar, conjuntos de pruebas de evaluación mantenidos en la misma ruta crítica que el trabajo de desarrollo de funcionalidades, con el mismo nivel de calidad: un cambio de modelo que no supera el conjunto de pruebas de evaluación se lanza con la misma frecuencia que un cambio de código que no supera el conjunto de pruebas, es decir, casi nunca. En segundo lugar, el «red teaming» como práctica operativa habitual en lugar de un evento exclusivo del lanzamiento: un equipo dedicado que busca inyecciones de comandos, fugas de seguridad, patrones de alucinación y superficies de sesgo con una cadencia semanal. En tercer lugar, canalizaciones de evaluación en línea que comparan los resultados de los modelos de producción con trazas de referencia retenidas, señalando la degradación silenciosa antes de que el cliente se dé cuenta.
¿En qué consiste realmente la economía de la inferencia para un AI CTO?
El coste de la inferencia se ha convertido en la partida de costes variables más importante en la mayoría de las empresas nativas de AI, a menudo superior a la infraestructura y, en muchos casos, comparable a la nómina una vez que se tiene en cuenta el coste de ventas. La disciplina que importa: la economía unitaria por función. Para cada función, ¿cuánto cuesta en tokens atender una sola solicitud de usuario?, ¿cuál es el margen bruto por solicitud? y ¿cómo evoluciona esto a medida que crece el uso? El CTO que no dispone de esta cifra para las diez funciones principales toma decisiones de precios a ciegas. Los directores técnicos que sí la tienen tienden a converger en un patrón similar: uso agresivo del enrutamiento de modelos (modelos más pequeños y baratos para las solicitudes más sencillas, modelos de vanguardia para las más complejas), capas de almacenamiento en caché para patrones repetidos y puertas de funciones por nivel que alinean el coste de inferencia con el nivel de ingresos.
¿En qué se diferencia el modelo AI CTO del AI strategy executive o del CAIO?
El AI CTO es el responsable de desarrollar el producto. El AI strategy executive o el Chief AI Officer se encarga de la estrategia de cartera en aquellas empresas en las que el AI es una de las múltiples apuestas que la empresa está realizando, en lugar de ser el producto principal en sí mismo. En una empresa nativa de AI, el AI CTO suele asumir gran parte del papel del AI strategy executive, ya que la estrategia de producto de la empresa y su estrategia de AI son lo mismo. En una empresa tradicional que añade AI a una cartera de productos existente, el CAIO establece la estrategia de la cartera y el CTO existente (o su equivalente dentro de la organización tecnológica) se encarga de la ejecución desde el punto de vista de la ingeniería. Consulte AI Strategy Executive para el tratamiento a nivel de cartera y CAIO frente a CTO frente a CDAO para la vista de comparación de roles.
¿Cuál es la remuneración habitual para un AI CTO?
La remuneración es superior a la de un producto tradicional CTO en una empresa en una fase comparable, debido a la concentración de la demanda. La remuneración de las empresas nativas de AI en 2026 suele situarse entre 400 000 y 700 000 dólares en la ronda de financiación Serie B y posteriores, con una remuneración total que supera los 2 millones de dólares en etapas posteriores, y las concesiones de acciones se inclinan claramente hacia el alza cuando la empresa se posiciona en un sector AI en auge. Los laboratorios de modelos de base y las empresas pioneras en AI son los que pagan más, y los informes públicos de 2024-2025 muestran que la remuneración total de los líderes técnicos sénior de AI supera los 5 millones de dólares en la cima del mercado. La prima salarial se reduce a medida que la empresa madura y la etiqueta AI se convierte en un producto básico dentro de su categoría de productos.
¿Cuál es el fallo más habitual de los modelos AI y CTO?
Invertir de forma insuficiente en evaluación y en exceso en el último modelo. Este patrón se observa en las empresas nativas de AI que lanzan un producto basado en el modelo de vanguardia actual, obtienen métricas de demostración sólidas, amplían el servicio a los primeros clientes y, a continuación, ven cómo la experiencia en producción se deteriora a medida que se acumulan los casos extremos. El instinto del equipo es actualizar al siguiente modelo de vanguardia en cuanto sale al mercado, lo que da lugar a un sprint de seis semanas de integración y otra ronda de resultados con calidad de demostración sin abordar el problema subyacente: que, para empezar, no existía un conjunto de pruebas de evaluación que detectara las regresiones silenciosas. Los equipos que sobreviven al segundo año son aquellos que desarrollaron la disciplina de evaluación junto con el producto, no los que persiguieron cada actualización del modelo.
Need Expert Technology Guidance?
20+ years leading technology transformations. Get a technology executive's perspective on your biggest challenges.
