El responsable global de arquitectura de IA afirma que la IA implica un cambio en el modelo operativo, no el despliegue de una herramienta

Manish Jain es vicepresidente y responsable global de Arquitectura de IA en Firstsource, donde dirige un equipo de 50 personas. Actualmente, su enfoque se centra en crear sistemas agénticos capaces de gestionar trabajos de varios pasos.

Nos sentamos con Manish para saber cómo la IA está cambiando su modelo operativo. Esto es lo que nos contó.

Del potencial a una capacidad lista para producción

Soy Manish Jain, un líder de IA y tecnología centrado en ayudar a las organizaciones a convertir el potencial de la IA en una capacidad fiable y lista para producción. Baso mi trabajo en la realidad práctica de la transformación. Durante los últimos años, he liderado numerosas iniciativas de IA y ML, he colaborado estrechamente con equipos empresariales y he trabajado en ingeniería e implementaciones en las que el éxito depende de mucho más que de seleccionar el modelo adecuado. La arquitectura, la calidad de los datos, la seguridad, la integración, la adopción por parte de los usuarios y un valor empresarial claro deben encajar.

Actualmente lidero iniciativas de IA en una organización multifuncional de aproximadamente 50 personas, incluidos ingenieros de software y plataformas, profesionales de IA y datos, responsables de producto, socios de seguridad y expertos en dominios empresariales. El trabajo abarca la implementación de IA empresarial y la entrega avanzada directamente en las instalaciones del cliente. Los equipos trabajan estrechamente con clientes y partes interesadas internas para llevar casos de uso de alto valor desde el descubrimiento hasta una implementación segura y escalable en producción.

Nuestro enfoque es intencionadamente independiente de la nube y del modelo. Principalmente implementamos soluciones en Azure y AWS, y utilizamos Google Cloud de forma selectiva según el entorno del cliente, su ecosistema de datos y sus necesidades operativas. En lugar de diseñar en torno a un único proveedor de nube o modelo fundacional, creamos arquitecturas modulares que nos permiten elegir y evolucionar los componentes subyacentes a medida que cambian los requisitos. Esto incluye la capa de modelos, los servicios de recuperación y datos, el marco de orquestación, las herramientas de evaluación, la observabilidad y los controles de seguridad.

La verdadera complejidad no consiste simplemente en seleccionar un LLM. Consiste en integrar la IA en los flujos de trabajo empresariales a través de fuentes de datos fragmentadas, aplicaciones heredadas, permisos de usuario variables y requisitos estrictos de seguridad, fiabilidad, costes y cumplimiento. Normalmente comenzamos con un caso de uso concreto y una evaluación rigurosa, y después llevamos a producción lo que funciona mediante barreras de protección, supervisión humana cuando corresponde, monitorización e iteración continua. El objetivo es crear capacidades de IA que sigan siendo adaptables a medida que cambia la tecnología y suficientemente fiables para que los equipos puedan utilizarlas a diario.

Me interesa especialmente la transición de los copilotos individuales a sistemas agénticos capaces de gestionar trabajos de varios pasos dentro de unos límites definidos. Para los líderes tecnológicos, la oportunidad es importante, pero aprovecharla requiere una ingeniería disciplinada, una gobernanza bien planteada y un firme enfoque en los resultados.

Por qué la entrega de IA basada en la evaluación mejora los resultados

Durante el último año, he transformado la entrega de IA, pasando de una mentalidad centrada en los prototipos a una disciplina de ingeniería centrada en la evaluación. Hace un año, los equipos solían crear rápidamente pruebas de concepto impresionantes conectando flujos de trabajo a modelos individuales. Sin embargo, a menudo abordaban demasiado tarde los factores que determinan la fiabilidad de la IA en producción —calidad, fundamentación, control de acceso, gestión de fallos, costes y responsabilidad de los usuarios—.

Introdujimos un patrón de entrega compartido en el que cada caso de uso de IA comienza con una definición clara del éxito, datos de evaluación representativos, una revisión de la seguridad y del acceso a los datos, trazabilidad y monitorización continua. También creamos la arquitectura subyacente para que fuera independiente de la nube y del modelo. Esto permite a los equipos evaluar la combinación adecuada de modelos, enfoques de recuperación y patrones de orquestación para cada flujo de trabajo, sin vincular el producto a un único proveedor o generación de modelos.

En la práctica, esto se tradujo en menos retrabajo y mayor confianza en las implementaciones en producción. Los equipos pueden identificar las regresiones de calidad o costes antes de que afecten a los usuarios, tomar decisiones explícitas sobre dónde debe intervenir la revisión humana y mejorar los sistemas basándose en evidencias en lugar de comentarios anecdóticos.

De cara al futuro, creo que esto constituye la base de una IA agéntica responsable. A medida que los sistemas dejan de limitarse a responder preguntas y comienzan a realizar acciones de varios pasos en los flujos de trabajo empresariales, no podemos añadir posteriormente la evaluación, la observabilidad, los permisos y la gobernanza. Deben formar parte del tejido de ingeniería desde el primer día.

Cómo las personas adquieren más importancia con la ingeniería agéntica

Utilizamos la IA durante todo el ciclo de vida del producto. En la fase de descubrimiento, convierte las aportaciones de las partes interesadas, los comentarios de los clientes y la documentación existente en requisitos iniciales, historias de usuario, criterios de aceptación y cuestiones técnicas. En ingeniería, ayuda a explorar el código base, elaborar documentación, implementar y refactorizar, preparar solicitudes de incorporación de cambios y generar pruebas. En operaciones, resume registros, correlaciona alertas con versiones recientes, recupera el contexto de incidentes anteriores y reduce el espacio de búsqueda durante el triaje. Los equipos dedican menos tiempo a reunir contexto entre herramientas y más a validar decisiones, resolver problemas complejos y avanzar en la entrega.

Mantenemos en manos humanas la responsabilidad sobre la arquitectura, la aprobación de seguridad, las decisiones de acceso a los datos, la aprobación de las versiones y las decisiones de priorización. Estas decisiones requieren contexto empresarial, responsabilidad y una comprensión de las consecuencias que va más allá de lo que contiene un ticket, una instrucción o un repositorio de código. La IA puede analizar alternativas, identificar dependencias, señalar problemas de seguridad y reunir pruebas, pero la decisión la toma un ingeniero o líder responsable.

Establecemos deliberadamente esta distinción a medida que avanzamos hacia una ingeniería más agéntica. Espero que la IA asuma una ejecución más acotada, como implementar cambios bien definidos, generar y ejecutar pruebas, validar criterios de despliegue o proponer pasos para remediar incidentes. A medida que esto ocurre, el papel humano se vuelve más importante, no menos. Los ingenieros definen la intención, los permisos, los umbrales de calidad y los límites de reversión, y después validan si el sistema ha logrado el resultado previsto.

Cómo impulsa la IA eficazmente los flujos de trabajo de ingeniería de principio a fin

Este es nuestro flujo de trabajo integral, que lleva una solicitud de producto bien definida desde el diseño hasta la implementación, la validación y el lanzamiento en producción. Comienza cuando un responsable de producto y un líder de ingeniería definen el resultado para el cliente, las restricciones y los criterios de aceptación. A continuación, la IA sintetiza el contexto empresarial relevante, la documentación existente, los patrones arquitectónicos y las dependencias para elaborar un borrador del diseño técnico, el plan de implementación y la estrategia de pruebas. Un ingeniero revisa ese plan, toma las decisiones de arquitectura y divide el trabajo en cambios pequeños que se pueden verificar de forma independiente.

Durante la implementación, los ingenieros utilizan la IA dentro del código base para comprender los servicios relevantes, generar el código inicial y los cambios de configuración, actualizar la documentación y crear pruebas unitarias y de integración. Cada cambio sigue pasando por el control de versiones, las comprobaciones automatizadas de integración continua, la revisión por pares, el análisis de seguridad y el proceso de lanzamiento establecido. Si una prueba falla, la IA interpreta el fallo, identifica la dependencia o regresión probable y propone una corrección, pero el ingeniero verifica la solución antes de que avance.

Después del despliegue, el flujo de trabajo continúa. La IA resume los registros de la aplicación, correlaciona las anomalías con las versiones recientes y muestra incidentes anteriores o manuales de operación relevantes para el ingeniero de guardia. Medimos el ciclo completo mediante el tiempo de entrega, la cobertura de pruebas, la tasa de fallos de los cambios, la frecuencia de las reversiones y el tiempo hasta la resolución.

Esto no es desarrollo de software autónomo. Es un sistema de entrega dirigido por personas y aumentado por IA, en el que la IA agiliza la recopilación de contexto y la ejecución, mientras los ingenieros conservan la responsabilidad sobre el diseño, la calidad, la seguridad y el resultado en producción.

Manish nos cuenta

La IA ha reducido significativamente el tiempo que los ingenieros dedican a recopilar contexto y producir la primera versión del trabajo rutinario. Ayuda a los equipos a pasar más rápidamente de un requisito inicial a un enfoque técnico estructurado, una implementación, una cobertura de pruebas y documentación.

Cómo crea la IA un mejor flujo entre las distintas funciones

En cuanto a los resultados, la IA ha reducido significativamente el tiempo que los ingenieros dedican a recopilar contexto y producir la primera versión del trabajo rutinario. Ayuda a los equipos a pasar más rápidamente de un requisito inicial a un enfoque técnico estructurado, una implementación, una cobertura de pruebas y documentación. Ha acelerado el desarrollo de nuevas funciones y capacidades de producto, especialmente cuando los ingenieros necesitan analizar un código base desconocido, rastrear dependencias o trabajar en varios servicios.

La IA también proporciona información para las decisiones de arquitectura. Puede sintetizar rápidamente la documentación existente del sistema, identificar dependencias, comparar opciones de implementación, mostrar posibles compromisos y ayudar a los equipos a crear registros de decisiones de arquitectura. Las personas toman las decisiones finales de arquitectura, pero los equipos llegan a esas conversaciones con un contexto más completo. Pueden dedicar más tiempo a debatir las decisiones que realmente importan, como la escalabilidad, la resiliencia, la seguridad, el coste y la mantenibilidad a largo plazo.

La mejora no consiste simplemente en generar código más rápido. Observamos un mejor flujo a lo largo del ciclo de vida porque producto, ingeniería, control de calidad y operaciones comienzan con un contexto más completo y coherente. Los ingenieros dedican más tiempo al diseño del sistema, los casos límite, la complejidad de la integración y el impacto en el cliente, en lugar de recopilar manualmente información de repositorios, tickets, paneles, registros e incidentes anteriores.

Cómo debería medirse el éxito con IA

También hemos aprendido lecciones importantes sobre las desventajas. La IA puede crear una falsa sensación de velocidad cuando los equipos aceptan resultados plausibles sin una validación suficiente. Puede generar código que parece correcto, pero que no encaja con la arquitectura circundante, pasa por alto reglas empresariales sutiles, introduce una complejidad innecesaria o crea problemas de seguridad y mantenibilidad. Las mejoras de productividad también son desiguales. Los ingenieros que entienden el sistema, formulan el trabajo con precisión y validan los resultados rigurosamente son quienes más se benefician.

Por eso medimos el éxito a través de la calidad de la entrega, en lugar de mediante métricas de actividad de la IA. Los resultados que nos importan son una entrega más rápida de funcionalidades, ciclos más cortos, versiones estables, una cobertura de pruebas más sólida, menos trabajo repetido, una resolución más rápida de incidentes y una fiabilidad sostenida. La oportunidad a largo plazo es significativa, pero solo si la IA mejora el criterio y la ejecución de ingeniería en lugar de convertirse en un sustituto de cualquiera de ellos.

Cómo las nuevas limitaciones cambian las estructuras de los equipos

La generación de código ya no es el factor limitante de la velocidad de ingeniería. Las verdaderas limitaciones suelen ser unos requisitos poco claros, un contexto empresarial fragmentado, dependencias arquitectónicas, la revisión de seguridad, la integración entre sistemas y el tiempo necesario para validar que un cambio funciona de forma segura en producción. Los datos del sector apuntan en la misma dirección: la programación representa una parte relativamente pequeña de la jornada de un ingeniero, y la adopción de la IA en la programación no se traduce automáticamente en aumentos proporcionales del rendimiento.

Eso cambió mi forma de pensar sobre la estructura de los equipos. En lugar de considerar simplemente la IA como una forma de reducir el esfuerzo de entrega, estamos avanzando hacia equipos más pequeños y multifuncionales, con una mayor responsabilidad desde el descubrimiento hasta el aprendizaje en producción. Los ingenieros deben dedicar menos tiempo a crear primeros borradores y más tiempo a definir la intención, dar forma a la arquitectura, validar los resultados y mejorar el sistema después del lanzamiento.

Además, nuestro enfoque de contratación ha pasado de centrarse exclusivamente en la producción de código a hacerlo en el pensamiento sistémico, el criterio de producto y la validación del trabajo asistido por IA. Valoramos a los ingenieros capaces de gestionar la ambigüedad, tomar decisiones acertadas sobre arquitectura y seguridad, y asumir la responsabilidad de los resultados en producción.

Manish nos cuenta

El futuro no consiste solo en una implementación más rápida. Consiste en una alineación más rápida y un ciclo más estrecho entre una idea, un resultado en producción y el aprendizaje que informa la siguiente decisión.

El futuro no consiste solo en una implementación más rápida. Consiste en una alineación más rápida y un ciclo más estrecho entre una idea, un resultado en producción y el aprendizaje que informa la siguiente decisión.

Por qué las pruebas deben rediseñarse para un futuro aumentado por la IA

Las pruebas deben rediseñarse.

La IA está haciendo que crear código sea mucho más rápido, lo que significa que el aseguramiento de la calidad debe ser continuo, automatizado e integrarse en el flujo de entrega, en lugar de tratarse como una barrera final. Los equipos necesitan generación de pruebas asistida por IA, conjuntos de datos de evaluación realistas, comprobaciones de seguridad y rendimiento, supervisión en producción y una responsabilidad humana clara para las excepciones.

En un ciclo de vida aumentado por la IA, la ventaja competitiva no será quién genere código más rápido, sino quién pueda validar los cambios de forma segura y aprender de la producción con mayor rapidez.

Cómo evitar las fricciones con la IA desde el principio

Subestimamos las realidades operativas de la IA. El consumo de tokens y los límites de uso pueden restringir considerablemente la entrega, especialmente en flujos de trabajo de programación agénticos que necesitan el contexto de grandes bases de código o iteraciones repetidas. Ahora tratamos el gasto en IA como una decisión sobre la capacidad de ingeniería, con visibilidad sobre el uso, el enrutamiento de modelos, la gestión del contexto y el valor producido, no solo sobre el coste de la licencia. La fiabilidad del servicio también importa. Un modelo externo o una plataforma de programación pueden experimentar problemas de latencia, limitación de solicitudes o disponibilidad, por lo que los flujos de trabajo críticos necesitan modelos de respaldo, una degradación controlada y formas de que los ingenieros puedan seguir trabajando sin el servicio de IA.

Podríamos haber evitado las fricciones iniciales definiendo desde el principio herramientas aprobadas, límites de datos claros, expectativas de revisión, controles de costes y patrones de respaldo.

Tampoco impondría prematuramente una única herramienta o flujo de trabajo. La tecnología está cambiando demasiado rápido. El mejor enfoque consiste en proporcionar acceso seguro, mecanismos de control reutilizables, oportunidades de aprendizaje entre pares y una responsabilidad clara. Un ingeniero sigue siendo responsable de lo que diseña, revisa, fusiona y opera en producción.

Por qué la IA debe tratarse como un cambio del modelo operativo

Mi consejo para los CTO es que traten la IA como un cambio del modelo operativo, no como el despliegue de una herramienta. Empiecen con un pequeño número de flujos de trabajo de gran valor en los que puedan establecer una referencia, medir el impacto y aprender rápidamente. Construyan una plataforma de IA compartida y una disciplina de entrega en torno a modelos aprobados, acceso seguro a los datos, evaluación, observabilidad y patrones de integración reutilizables, y mantengan la arquitectura independiente de la nube y del modelo. Esto evita que cada equipo reinvente los mismos controles o quede vinculado demasiado pronto a un proveedor.

Igual de importante es invertir en las personas. Las organizaciones que más se beneficiarán no serán las que simplemente generen más código. Serán las que ayuden a los ingenieros, los equipos de producto, los responsables de seguridad y los líderes empresariales a aprender a plantear claramente el trabajo, validar los resultados de la IA y operar sistemas basados en agentes dentro de unos límites definidos. Actúen con urgencia, pero hagan que la confianza, la calidad, la seguridad y los resultados medibles sean innegociables.

La IA se está convirtiendo en una capa central de ejecución para la empresa, por lo que el papel del CTO consiste en crear la arquitectura, la gobernanza y la cultura que permitan escalarla de forma responsable.

Sigue sus novedades

Puedes seguir el trabajo de Manish Jain en su Substack y su LinkedIn.

¡Próximamente habrá más entrevistas con expertos en The CTO Club!