Industrialización: La adopción exitosa de la IA requiere modelos operativos, gobernanza, arquitectura, talento y disciplina de producto, no experimentos aislados.
Despliegue avanzado: La ingeniería desplegada directamente en los entornos reales lleva la modernización de la IA agéntica a esos entornos, abordando desde el principio las limitaciones de datos, código y seguridad.
Modelo de confianza: Utilice un descubrimiento determinista, una implementación asistida por IA y una validación humana para modernizarse más rápido sin sacrificar la precisión, la seguridad ni la responsabilidad.
Control de costes: La economía de la inferencia es importante: el enrutamiento de modelos, el almacenamiento en caché, el procesamiento por lotes, la cuantización y el servicio optimizado pueden reducir los costes y mejorar la fiabilidad.
AI-DLC: AI-DLC rediseña la entrega en torno a la concepción, la construcción y la operación, integrando agentes, controles de seguridad, evaluación, observabilidad y mejora continua.
Saurabh Shrivastava es director global de Arquitectura de Soluciones e Ingeniería Desplegada en Campo en Amazon Web Services, donde se centra en la IA agéntica y la modernización empresarial.
Nos reunimos con Saurabh para conocer los nuevos modelos de ingeniería que utiliza en su trabajo en AWS. Esto es lo que compartió.
Industrializar la IA de forma responsable
Soy un líder de transformación tecnológica y de IA con más de 20 años de experiencia ayudando a las empresas a convertir cambios tecnológicos complejos en resultados empresariales escalables. Mi trayectoria me ha llevado por la ingeniería, la arquitectura empresarial, la ingeniería de campo alineada con los productos, la transformación en la nube y, ahora, la IA agéntica y los modelos de fábricas de software en AWS.
Al principio de mi carrera, desarrollé y dirigí plataformas empresariales a gran escala en los sectores de las telecomunicaciones, el comercio minorista, la cadena de suministro, la tecnología financiera y los entornos de investigación y desarrollo. Esto me permitió valorar profundamente el pensamiento sistémico, la fiabilidad, la complejidad de la integración y la realidad de operar tecnología a escala empresarial.
En AWS, mi función se amplió: pasé de ayudar a los clientes a modernizar su infraestructura y sus aplicaciones a liderar la arquitectura global de soluciones y las iniciativas de ingeniería desplegada en campo centradas en la IA, la modernización y las plataformas agénticas. He trabajado con líderes empresariales, socios, equipos de producto y equipos de ingeniería para pasar de la estrategia y la experimentación a plataformas gobernadas y listas para producción.
La IA ya no es solo otra ola tecnológica. Está cambiando la forma en que las organizaciones desarrollan software, cómo trabajan los empleados, cómo interactúan los clientes y cómo deben operar las organizaciones tecnológicas. El verdadero desafío de liderazgo no consiste únicamente en seleccionar modelos o herramientas. Consiste en crear el modelo operativo, la arquitectura, la gobernanza, el talento y la disciplina de producto necesarios para industrializar la IA de forma responsable.
Liderar la arquitectura de soluciones de AWS
Como director global de Arquitectura de Soluciones e Ingeniería Desplegada en Campo (FDE), lidero la organización global de AWS dedicada a la arquitectura de soluciones y la ingeniería desplegada en campo, con especial atención a las plataformas de IA agéntica, la modernización empresarial y la transformación de la nube a escala de producción.
La organización opera a escala empresarial y trabaja con grandes clientes globales, socios estratégicos, equipos de producto, equipos especializados de ingeniería y organizaciones regionales de campo. El alcance de la arquitectura es amplio: plataformas de IA y aprendizaje automático, flujos de trabajo agénticos, bases de datos y análisis, modernización de aplicaciones, infraestructura nativa de la nube, seguridad, gobernanza y soluciones integradas con socios.
Lidero, capacito e influyo en más de 200 especialistas, ingenieros de socios y líderes tecnológicos de campo a nivel global. El trabajo es muy complejo porque no creamos demostraciones aisladas. Ayudamos a las empresas a pasar de las primeras ideas de IA y los casos empresariales de modernización a plataformas repetibles, seguras y listas para producción que puedan escalar entre unidades de negocio, mercados y entornos de clientes.
Nuestro modelo de implementación combina la ingeniería desplegada en campo, mecanismos de plataforma globales, entrega liderada por socios y ciclos de retroalimentación entre producto y campo. Mi equipo desarrolla planos reutilizables, arquitecturas de referencia, demostraciones ejecutivas, manuales técnicos, patrones de gobernanza y modelos de soluciones componibles que aceleran la adopción, al tiempo que mantienen la calidad, la seguridad y la disciplina operativa.
Por qué un modelo de ingeniería desplegada en campo es esencial con la IA

El año pasado introduje un modelo de ingeniería desplegada en campo para la modernización impulsada por la IA.
En la era de la nube, contábamos con arquitecturas de referencia reutilizables, planos de soluciones, patrones de implementación y puntos de control de gobernanza. Estos elementos eran necesarios, pero no suficientes con la IA. Los clientes seguían teniendo dificultades para pasar de la prueba de concepto a producción porque el trabajo más difícil se producía dentro de su entorno real: los datos, el conjunto de aplicaciones, la complejidad del código, las limitaciones de seguridad y el modelo operativo.
Por eso introduje un mecanismo de FDE que integra a los ingenieros mucho más cerca de las cargas de trabajo reales del cliente. En lugar de ofrecer asesoramiento desde fuera, el equipo de FDE trabaja con los datos, el código, la arquitectura y los equipos de entrega del cliente para identificar candidatos para la modernización, crear activos utilizables y llevar la primera carga de trabajo a producción.
También introduje un modelo sencillo 3-3-3: 3 días para el descubrimiento, 3 semanas para la evaluación y 3 meses para llevar la primera carga de trabajo a producción. Esto proporcionó a los ejecutivos un camino claro desde la ambición de IA hasta el valor medible.
El impacto fue significativo. Los clientes pudieron acelerar su trayectoria de modernización entre 2 y 4 veces, reducir los costes hasta a la mitad y superar las demostraciones para obtener un ROI real. Más importante aún, cambió la conversación ejecutiva. La IA dejó de ser un experimento secundario y se convirtió en un mecanismo práctico para modernizar cargas de trabajo reales, mejorar la productividad de ingeniería y crear un valor empresarial medible.
Cómo modernizar más rápido sin perder la confianza
La IA se vuelve más poderosa en el trabajo del estado futuro: generar opciones de modernización, proponer nuevas arquitecturas, definir límites de servicios, desarrollar patrones de migración, escribir código, generar pruebas y acelerar la implementación. Esa parte puede ser más probabilística porque la IA puede explorar opciones y mejorar la velocidad de ingeniería. Pero incluso ahí, la decisión final sigue siendo humana.
Utilizo mucho la IA para acelerar la comprensión técnica, el reconocimiento de patrones y el rendimiento de ingeniería, pero no delego la responsabilidad en la IA.
En empresas complejas, el negocio suele basarse en décadas de código, deuda técnica, dependencias no documentadas y reglas de negocio integradas. En ese entorno, necesitamos enfoques tanto deterministas como probabilísticos. No se puede depender únicamente del descubrimiento probabilístico mediante IA al intentar comprender sistemas críticos para la misión.
Para el descubrimiento de código, la extracción de reglas de negocio, el análisis de dependencias, el mapeo de funcionalidades y la evaluación del estado actual, prefiero un enfoque más determinista. Necesitamos trazabilidad, repetibilidad, evidencias y confianza en lo que hace el sistema. La IA puede ayudar a resumir, agrupar y acelerar el análisis, pero la base debe estar formada por hechos verificables provenientes del código, los registros, los flujos de datos, el comportamiento en tiempo de ejecución y las evidencias arquitectónicas.
La IA se vuelve más poderosa en el trabajo del estado futuro: generar opciones de modernización, proponer nuevas arquitecturas, definir límites de servicios, desarrollar patrones de migración, escribir código, generar pruebas y acelerar la implementación. Esa parte puede ser más probabilística porque la IA puede explorar opciones y mejorar la velocidad de ingeniería.
Pero incluso ahí, la decisión final sigue siendo humana. Los ingenieros y líderes responsables deben validar las decisiones arquitectónicas, la postura de seguridad, la preparación para producción, el riesgo de cumplimiento, el impacto en los clientes y las compensaciones de inversión.
Por eso, mi modelo es: descubrimiento determinista, diseño e implementación acelerados por IA y validación gobernada por personas. Esta combinación nos permite modernizar más rápido sin perder la confianza, el control ni la responsabilidad empresarial.
Las desventajas de la IA en los flujos de trabajo de ingeniería
El resultado positivo más importante fue que la IA acortó significativamente el camino desde el descubrimiento hasta la producción cuando se integró en un flujo de trabajo de ingeniería disciplinado.
La IA también aceleró la comprensión del código, la extracción de reglas de negocio, el análisis de dependencias, la generación de pruebas, la documentación y la planificación de la modernización. Redujo el tiempo de análisis manual y ayudó a los equipos de ingeniería a centrarse más en las decisiones arquitectónicas, la validación y la preparación para producción.
Pero la IA puede volverse muy costosa con gran rapidez si los equipos no diseñan teniendo en cuenta la economía de la inferencia. En grandes empresas con millones de usuarios, los costos de tokens de los modelos de vanguardia pueden alcanzar millones de dólares si cada interacción depende de modelos fundacionales externos de terceros sin optimización.
Una lección es que la arquitectura de IA debe incluir una arquitectura de costos. Para algunas cargas de trabajo, las empresas deberían evaluar la inferencia autoalojada o alojada en la nube mediante GPU o aceleradores, incluidas opciones como vLLM en infraestructura en la nube. Esto proporciona un mayor control sobre el costo, la latencia, los límites de los datos y la estrategia de prestación de modelos. Técnicas como el almacenamiento en caché KV, el procesamiento por lotes continuo, la cuantización y la optimización de kernels pueden mejorar considerablemente la utilización de las GPU y reducir el costo de inferencia.
El costo no es la única desventaja. La IA también puede generar una falsa confianza si los equipos la utilizan sin gobernanza. Los riesgos incluyen una comprensión incompleta del código, dependencias alucinadas, una cobertura de pruebas deficiente, brechas de seguridad y equipos que pasan demasiado rápido del prototipo a la producción.
Por qué la IA tiene dificultades con la modernización integral de sistemas heredados

La IA ha tenido más dificultades cuando los equipos le piden que tome decisiones técnicas sin contar con suficiente contexto del sistema.
Un ejemplo común es la modernización de sistemas heredados. La IA puede resumir código, generar ideas de migración e incluso producir código nuevo rápidamente. Sin embargo, en las grandes empresas, la complejidad real va más allá del código. Implica décadas de reglas de negocio, integraciones no documentadas, trabajos por lotes, dependencias de datos, excepciones operativas, restricciones de seguridad y responsabilidades organizativas. Si se pide a la IA que modernice ese entorno con una visión parcial, puede producir respuestas convincentes, pero incompletas.
La preparación para producción es otro ámbito en el que tiene dificultades. La IA puede crear prototipos muy rápidamente, pero muchos prototipos no se convierten automáticamente en sistemas de producción seguros, observables, resilientes y rentables. A veces, los equipos subestiman el trabajo necesario para las pruebas, la gobernanza, la respuesta ante incidentes, la supervisión, la evaluación de modelos, la calidad de los datos y la gestión del ciclo de vida.
Cómo pueden los ingenieros mejorar los productos mientras controlan los costes y la fiabilidad de la inferencia
Este es un ejemplo de una gran plataforma de creación de contenidos para medios y marketing, en la que la IA ayuda a los usuarios a pasar de la intención a los activos digitales terminados a escala empresarial.
El flujo de trabajo comienza cuando un usuario describe lo que quiere crear: una campaña de lanzamiento de producto, una pieza creativa para redes sociales, una presentación de ventas, un fragmento de vídeo o un activo de marketing localizado. La IA interpreta la intención del usuario, incluidos la audiencia, el formato, el tono, las directrices de marca, los activos necesarios, las restricciones del canal y los requisitos de cumplimiento.
A partir de ahí, la plataforma utiliza un flujo de trabajo basado en agentes. Un agente recupera plantillas, logotipos, fuentes, colores y activos de campaña aprobados por la marca. Otro genera textos y variaciones creativas. Otro propone diseños. Otro comprueba el cumplimiento de la marca, la accesibilidad, las políticas y la seguridad del contenido. Una capa final de orquestación ensambla el resultado en activos editables y lo dirige a través de los flujos de aprobación o publicación.
A esta escala, la ingeniería se enfrentó a desafíos no solo relacionados con la calidad de los modelos, sino también con la economía de la inferencia, la latencia, la fiabilidad y la gobernanza. El equipo optimizó un entorno de inferencia a muy gran escala compatible con aproximadamente 10.000 nodos de procesamiento y unos 80.000 GPU. La arquitectura combinaba capacidad de GPU de varios proveedores de nube y terceros aprobados, conectando esos entornos mediante una capa de red híbrida. Esto proporcionó a la plataforma flexibilidad para ubicar las cargas de trabajo según el coste, la latencia, la disponibilidad y la localidad de los datos.
\u003cstrong\u003eLos seres humanos mantuvieron el control en los puntos clave de decisión. La IA generaba opciones, recomendaba diseños, redactaba textos y aceleraba la producción, pero el usuario o el responsable de la marca aprobaba el activo final.\u003c/strong\u003e
El equipo también implementó una estrategia más disciplinada para servir modelos. En lugar de enviar cada solicitud al modelo de frontera más costoso, la plataforma distribuía las solicitudes entre modelos adecuados para cada propósito, incluidos modelos abiertos como Kimi y Qwen, servidos mediante entornos de ejecución optimizados como vLLM y patrones de estilo Ollama. El equipo también aplicó técnicas de optimización de la inferencia, como el almacenamiento en caché de KV, el procesamiento por lotes continuo, la cuantización, la optimización de la memoria y el ajuste a nivel de núcleo, para mejorar la utilización de las GPU y reducir los costes.
Los seres humanos mantuvieron el control en los puntos clave de decisión. La IA generaba opciones, recomendaba diseños, redactaba textos y aceleraba la producción, pero el usuario o el responsable de la marca aprobaba el activo final. Los equipos de ingeniería eran responsables de las barreras de protección: seguridad, acceso a los datos, selección de modelos, observabilidad, latencia, controles de costes, comprobaciones de seguridad y ciclos de retroalimentación.
El resultado fue un flujo de trabajo de IA que pasó a formar parte de la experiencia del producto, no solo una herramienta interna de productividad. Redujo el tiempo desde la idea hasta el activo, mejoró la personalización, aumentó la reutilización de componentes de marca aprobados y creó un ciclo de retroalimentación en el que las ediciones de los usuarios y los datos de interacción mejoraban las recomendaciones futuras. Al mismo tiempo, la arquitectura proporcionó a la empresa un control mucho mayor sobre el coste de la inferencia, la fiabilidad y la gobernanza.
Por qué los despliegues de IA requieren una mentalidad de producto
La implementación de herramientas de IA tiene menos que ver con la adopción de herramientas y más con cambiar el modelo operativo de ingeniería.
Al principio, muchas organizaciones creen que el desafío consiste en dar a los ingenieros acceso a copilotos, asistentes de programación, API de modelos o plataformas internas de IA. Eso ayuda, pero no es suficiente. Sin patrones claros, los equipos utilizan la IA de forma incoherente. Algunos la usan únicamente para generar código. Otros la utilizan para la documentación. Algunos confían demasiado en ella. Otros la evitan porque no están seguros de los riesgos relacionados con la seguridad, la propiedad intelectual o la calidad.
Si tuviera que empezar de nuevo, definiría mucho antes el flujo de trabajo de ingeniería de IA: dónde debería y dónde no debería utilizarse la IA, qué pruebas se requieren, qué deben revisar los seres humanos y cómo se prueban, protegen y promueven los resultados a producción.
Esto habría evitado algunos problemas. Primero, podríamos haber reducido el uso incoherente entre los equipos. Segundo, podríamos haber evitado una confianza mal fundamentada en código o análisis generado por IA que parecía correcto, pero carecía del contexto suficiente. Tercero, podríamos haber controlado los costes antes mediante la implementación desde el principio del enrutamiento de modelos, la presupuestación de tokens, el almacenamiento en caché y la gobernanza de la inferencia. Cuarto, podríamos haber creado mejores patrones reutilizables en lugar de permitir que cada equipo inventara su propio enfoque.
La mayor lección es que la implementación de la IA requiere una mentalidad de producto y de plataforma. Se necesitan capacitación, controles preventivos, observabilidad, controles de costes, revisiones de seguridad, indicaciones y agentes reutilizables, patrones de evaluación y una responsabilidad humana clara. De lo contrario, la IA aumenta la actividad sin incrementar siempre la calidad de la ingeniería ni el valor empresarial.
Por qué el SDLC debe convertirse en el AI-DLC
Los CTO deberían rediseñar activamente el propio ciclo de vida de entrega de software. Yo concibo esto como una transición del SDLC tradicional al AI-DLC, un ciclo de vida de entrega aumentado por IA para la era de la IA agéntica.
En el SDLC tradicional, a menudo seguimos fases lineales: requisitos, diseño, desarrollo, implementación y soporte. Esto funcionaba razonablemente bien cuando el objetivo principal era crear software determinista mediante traspasos estructurados. Pero con la IA, especialmente con la IA agéntica, el ciclo de vida se vuelve más iterativo y compacto.
Simplifico el AI-DLC en tres fases principales: inicio, construcción y operación.
- En la fase de inicio, la IA ayuda con el descubrimiento, la comprensión del código, la extracción de reglas de negocio, el análisis de dependencias, la aclaración de requisitos, la identificación de riesgos y la planificación del estado objetivo.
- En la fase de construcción, la IA ayuda con las opciones arquitectónicas, la descomposición de servicios, la generación de código y pruebas, la documentación, las revisiones de seguridad, los patrones de infraestructura y la ejecución de la modernización.
- En la fase de operación, la IA facilita la observabilidad, la clasificación inicial de incidentes, los ciclos de retroalimentación, la evaluación de modelos, la optimización de costes, la gobernanza y la mejora continua.
El punto importante es que el AI-DLC no es simplemente un SDLC al que se ha añadido un asistente de programación. Es un modelo operativo de ingeniería rediseñado. Integra agentes de IA, descubrimiento determinista, validación humana, controles de seguridad, preparación para producción y gobernanza de costes en un único flujo de trabajo.
Cómo están cambiando los equipos de ingeniería debido a la IA
La IA ha desplazado a los equipos de ingeniería de una ejecución secuencial basada en funciones hacia equipos más integrados y orientados a resultados.
En el pasado, nos organizábamos en torno a funciones diferenciadas: arquitectos, ingenieros de aplicaciones, ingenieros de datos, DevOps, seguridad, control de calidad y operaciones. Estas funciones siguen siendo importantes, pero la IA comprime el ciclo de vida y reduce el valor de los traspasos prolongados. Los equipos con mejor rendimiento son más multifuncionales y están más cerca del problema empresarial.
Para la modernización impulsada por IA y la ingeniería de productos, ahora busco equipos que combinen varias capacidades: sólidos fundamentos de ingeniería de software, ingeniería de nube y de plataformas, dominio de los datos y la IA, conciencia de seguridad, mentalidad de producto y criterio operativo. También valoro a los ingenieros que trabajan en entornos ambiguos, razonan desde los primeros principios y validan los resultados de la IA en lugar de aceptarlos ciegamente.
El modelo de ingeniería desplegada en primera línea es un buen ejemplo. En lugar de mantener la arquitectura, la ingeniería de IA, DevOps y la seguridad en carriles secuenciales separados, acercamos esas capacidades al entorno del cliente o del negocio. El equipo trabaja con código, datos, restricciones y métricas de éxito reales.
La contratación también ha cambiado. Sigo valorando profundamente la profundidad técnica, pero también busco pensadores sistémicos: personas que entiendan la arquitectura, utilicen la IA de forma responsable, se comuniquen con las partes interesadas del negocio y asuman la responsabilidad de los resultados en producción. En la era de la IA, los mejores ingenieros no son solo productores de código. Son formuladores de problemas, validadores y creadores de sistemas repetibles.
Cómo medir la eficacia de la IA
Los CTO no deberían medir la IA únicamente por el número de pilotos o copilotos implementados, ni por la precisión del modelo de forma aislada. Estas son señales útiles, pero no demuestran una transformación…Los CTO deben convertir la actividad relacionada con la IA en una capacidad repetible.
Una pregunta que me gustaría que más personas hicieran es: ¿Cómo deberían medir los CTO si la IA está creando un valor empresarial duradero?
Los CTO no deberían medir la IA únicamente por el número de pilotos o copilotos implementados, ni por la precisión del modelo de forma aislada. Estas son señales útiles, pero no demuestran una transformación.
Los CTO deberían medir la IA en cuatro dimensiones:
- Productividad de ingeniería: ¿La IA está reduciendo el tiempo de ciclo, mejorando la calidad del código, aumentando la cobertura de pruebas, acelerando la modernización y reduciendo la deuda técnica?
- Impacto empresarial: ¿La IA está mejorando la experiencia del cliente, la productividad de los empleados, la conversión de ingresos, la eficiencia de costes o la velocidad de lanzamiento al mercado?
- Madurez de producción: ¿Los sistemas de IA son seguros, observables, fiables, están gobernados y tienen los costes controlados? ¿Cuentan con una responsabilidad humana clara y criterios definidos de preparación para producción?
- Reutilización y escalabilidad: ¿Los equipos están creando servicios de IA, agentes, indicaciones, patrones, productos de datos y capacidades de plataforma reutilizables, o están creando demostraciones aisladas?
Esto es importante porque la IA puede generar una gran cantidad de actividad visible sin crear un valor duradero. Los CTO deben convertir la actividad relacionada con la IA en una capacidad repetible. Esto significa conectar la estrategia, la arquitectura, el modelo operativo, la gobernanza y la economía.
Por qué los CTO deben separar la experimentación de la industrialización

Este es mi consejo.
En primer lugar, no traten la IA como un experimento secundario. Trátenla como una nueva capa operativa para la empresa. La IA afectará a la forma en que se desarrolla el software, a cómo trabajan los empleados, a cómo interactúan los clientes y a cómo se toman las decisiones. El trabajo del CTO consiste en llevar a la organización de pilotos dispersos a una estrategia de plataforma de IA gobernada y escalable.
En segundo lugar, separen la experimentación de la industrialización. Está bien experimentar con rapidez, pero la IA de producción necesita arquitectura, seguridad, gobernanza de datos, evaluación, observabilidad, controles de costes y una responsabilidad humana clara. Muchas empresas están estancadas porque tienen numerosas demostraciones, pero no cuentan con un camino repetible hacia producción. Los CTO deben construir ese camino.
En tercer lugar, céntrense en el valor empresarial, no en la novedad del modelo. Las organizaciones ganadoras no serán las que simplemente utilicen el modelo más reciente. Serán las que integren la IA en flujos de trabajo reales, modernicen sus cimientos tecnológicos, mejoren la productividad de ingeniería y midan resultados como el tiempo de ciclo, la eficiencia de costes, la experiencia del cliente, el impacto en los ingresos y la reducción del riesgo.
Y, en cuarto lugar, mi consejo práctico es crear conjuntamente una plataforma de IA y un modelo de ingeniería desplegada directamente. La plataforma proporciona reutilización, gobernanza y escala. El modelo FDE lleva la IA a cargas de trabajo reales de clientes y empresas, utilizando datos reales, código real y limitaciones reales. Así es como los CTO pueden pasar de la ambición en materia de IA a un retorno de la inversión materializado.
Sigue su trabajo
Sigue el trabajo de Saurabh Shrivastava en LinkedIn y en su página de autor de Amazon.
¡Próximamente habrá más entrevistas con expertos en The CTO Club!
