Líder tecnológico con más de 30 años de experiencia comparte cómo pasar de silos de IA a un modelo operativo regido por la gobernanza

Prem Kumar A S tiene más de 30 años de experiencia liderando proyectos de TI e infraestructura en la nube. Actualmente ejerce como VCTO en The Preminent.

Nos sentamos con Prem para entender cómo las organizaciones pueden pasar de focos aislados de IA a un modelo operativo gobernado. Esto es lo que nos contó.

Más de 30 años de experiencia

Tengo más de 30 años de experiencia liderando proyectos de TI e infraestructura en la nube en todo el mundo. Actualmente trabajo como VCTO, asesorando a consejos de administración y directores ejecutivos en tecnología, riesgo cibernético, resiliencia, confianza y gobernanza en la era de la IA. Mi objetivo es ayudar a los equipos directivos a tomar decisiones más claras, sólidas y preparadas para el futuro.

Además, presento PREMINENT KONCLAVE by Power of Knowing Forum — una serie de pódcast semanal de referencia que abarca tecnología, ciberseguridad, crecimiento y estrategia, con más de 370 conversaciones con líderes y un ecosistema de expertos en expansión.

Cómo pasar de focos aislados de IA a un modelo operativo gobernado

Pasamos de experimentar con herramientas a un modelo operativo gobernado, concretamente mediante la introducción de una capa de gobernanza de IA y revisión de las implementaciones antes de que cualquier solución habilitada para IA pudiera ponerse en marcha.

Antes de esto, la IA se exploraba en distintos ámbitos: asistentes, proyectos piloto de automatización, casos de uso analítico y cierta experimentación en seguridad. El problema no era la intención, sino la fragmentación. Los distintos equipos podían evaluar o incluso implementar capacidades habilitadas para IA sin un marco común para la clasificación de datos y el riesgo de exposición, los límites de uso de los modelos, las aprobaciones de herramientas de IA de terceros, la revisión y la responsabilidad humanas, o la medición de los resultados empresariales.

En términos sencillos, la IA empezaba a entrar en el entorno más rápido de lo que la gobernanza podía reaccionar. Esto crea tres riesgos para cualquier organización seria:

1. Exposición de la seguridad y la privacidad: datos empresariales o de clientes confidenciales que entran en flujos de trabajo de IA no gestionados
2. Incoherencia operativa: equipos que utilizan distintas herramientas, instrucciones y procesos sin estándares repetibles
3. Riesgo a nivel del consejo sin visibilidad: el uso de la IA crece, pero la dirección no sabe dónde se encuentran realmente la exposición o el retorno de la inversión

Por eso, introdujimos un modelo práctico de control de la IA vinculado a la forma en que se desarrolla, implementa y gobierna la tecnología, no como un documento teórico de políticas, sino como una disciplina operativa. Esto incluyó cinco cambios concretos:

1. Los casos de uso de la IA debían clasificarse antes de su adopción. Cada caso de uso de IA propuesto se clasificaba como productividad de bajo riesgo, soporte interno para la toma de decisiones, orientado al cliente o sensible/regulado/de alto riesgo. Esto cambió inmediatamente la conversación de «¿Podemos usar IA?» a «¿Qué nivel de gobernanza requiere este caso de uso de IA?»
2. La implementación de IA incorporó un punto de revisión obligatorio. Antes de que una herramienta, automatización o flujo de trabajo con IA pudiera pasar a producción, debía superar una revisión que abarcaba la sensibilidad de los datos, los controles de identidad y acceso, el riesgo del proveedor o del modelo, la gestión de las instrucciones y los resultados, los puntos de aprobación humana, los mecanismos de contingencia y reversión, y los requisitos de registro de auditoría. Esto convirtió la implementación de IA en parte de la gobernanza tecnológica, no solo en una demostración de innovación.
3. Separamos la experimentación de la producción. Se creó un modelo de entorno aislado y controlado para experimentar con IA. Los equipos podían probar ideas rápidamente —pero el uso en producción requería conjuntos de datos aprobados, herramientas y modelos aprobados, responsables definidos, resultados empresariales medibles y la aprobación de riesgos cuando fuera necesario. Fue un cambio cultural importante porque protegió la innovación sin permitir que la experimentación se convirtiera silenciosamente en una dependencia empresarial.
4. Introdujimos reglas de «persona en el circuito» para los flujos de trabajo sensibles. Exigíamos validación humana antes de la acción final para cualquier caso de uso de IA que afectara a clientes, al cumplimiento normativo, a decisiones financieras, a operaciones de seguridad o a comunicaciones empresariales críticas. Esto evitó el error clásico de tratar los resultados generados por IA como automáticamente fiables solo porque se producían rápidamente.
5. Empezamos a medir la IA por su valor operativo, no por el entusiasmo que generaba. Cada iniciativa de IA debía responder a estas preguntas: ¿Qué esfuerzo manual se está reduciendo? ¿Qué tiempos de ciclo mejoran? ¿Qué riesgos se reducen? ¿Cómo mejora la calidad de las decisiones? ¿Qué ahorro de costes, mejora de productividad o aumento de resiliencia se espera? Esto trasladó la IA de una conversación sobre tendencias tecnológicas a una conversación sobre el modelo operativo del negocio.

Esto nos proporcionó un mayor control sin frenar el impulso. La gobernanza dejó de percibirse como un obstáculo. Al crear un camino claro —experimentar aquí, gobernar aquí, implementar aquí— los equipos avanzaron más rápido, con menos confusión y menos riesgos ocultos.

También redujo el riesgo de la IA en la sombra. Obtuvimos mucha más visibilidad sobre qué herramientas se utilizaban, qué equipos las usaban, qué datos se introducían en ellas y qué casos de uso tenían un valor empresarial real. Esto es fundamental porque la adopción de IA no gestionada se está convirtiendo rápidamente en la nueva TI en la sombra.

Cómo implementar la IA sin crear caos

A continuación se ofrecen algunos consejos para quienes están empezando, si quieren evitar el caos:

1. Empieza con flujos de trabajo de gran volumen y bajo riesgo. No empieces con decisiones fundamentales de arquitectura ni con cambios autónomos críticos para la producción. Comienza con la documentación, la creación de pruebas, la clasificación inicial del soporte interno, los resúmenes de registros, la redacción de procedimientos operativos o la generación de notas de versión.
2. Establece medidas de protección antes de escalar. Cada implementación de ingeniería de IA debe definir las herramientas aprobadas, la política de uso de instrucciones y datos, las reglas de revisión del código, los requisitos de análisis de seguridad, los límites de aprobación humana y el registro y la posibilidad de auditoría.
3. Mide el antes y el después. Haz un seguimiento del tiempo de ciclo, la frecuencia de las implementaciones, los defectos que llegan a producción, el MTTR, la tasa de reversiones, el tiempo dedicado a tareas repetitivas y los comentarios de los ingenieros sobre satisfacción y productividad.
4. Mantén la responsabilidad en las personas. La IA debe ayudar a los ingenieros, no sustituir la responsabilidad de ingeniería. El modelo puede sugerir. El equipo debe seguir tomando decisiones, validando, protegiendo y asumiendo la responsabilidad del resultado.

Los mejores casos de uso técnico de la IA

Cuando se implementa correctamente, la IA en los flujos de trabajo técnicos puede mejorar de forma significativa la velocidad, la visibilidad, la productividad y la calidad de las decisiones. Cuando se implementa mal, puede amplificar los defectos, aumentar el riesgo operativo y crear una falsa sensación de confianza a gran escala.

Estos son los casos de uso y beneficios que estoy observando:

Mayor capacidad de producción de ingeniería cuando la IA se utiliza para el trabajo adecuado: Los mayores beneficios suelen aparecer en trabajos de complejidad baja o media, como la generación de código repetitivo, la creación de casos de prueba, la redacción de documentación y procedimientos operativos, la elaboración de resúmenes de registros y la clasificación inicial de incidentes, la creación de plantillas de infraestructura como código, la clasificación de tickets y las sugerencias de resolución de problemas de primer nivel. Entre los resultados cuantitativos que estoy observando se incluyen:

• Reducción del 20–40 % en el tiempo de ciclo de las tareas de ingeniería repetibles
• Mejora del 15–30 % en el rendimiento de los desarrolladores para trabajos bien definidos
• Triaje de incidentes entre un 25–50 % más rápido cuando la IA resume registros, alertas y posibles causas raíz
• Reducción del 30–60 % en el esfuerzo de documentación para procedimientos operativos estándar, manuales de operaciones y artículos de conocimiento

Mayor eficiencia de DevOps y de las plataformas: La IA es especialmente eficaz en las operaciones de DevOps/SRE/infraestructura cuando se utiliza como copiloto para el análisis, en lugar de como responsable autónomo de la toma de decisiones. Por ejemplo, la correlación de registros entre herramientas se vuelve más rápida, las alertas ruidosas se agrupan y resumen, las notas de despliegue y los pasos de reversión se generan automáticamente, los patrones de capacidad se detectan antes y las comprobaciones operativas repetitivas se automatizan. Las mejoras cuantitativas suelen incluir:

• Mejora del MTTR del 20–35 % en entornos con gran cantidad de incidentes
• Entre un 10–25 % menos de escalados a ingenieros sénior para patrones de problemas conocidos
• Mejora del 15–20 % en la tasa de éxito de los cambios cuando la IA se utiliza para aplicar listas de comprobación de despliegue, notas de versión y validación de dependencias
• Reducción del trabajo rutinario para los equipos de soporte y operaciones de nivel L1/L2, lo que libera a los ingenieros sénior para trabajar en arquitectura y resiliencia

Prem Kumar comparte

Cuando se implementa correctamente, la IA en los flujos de trabajo técnicos puede mejorar notablemente la velocidad, la visibilidad, la productividad y la calidad de las decisiones. Cuando se implementa mal, puede amplificar los defectos, aumentar el riesgo operativo y crear una falsa sensación de confianza a gran escala.

Mejora de la ingeniería de pruebas y de la cobertura de calidad: Uno de los casos de uso más prácticos son las pruebas asistidas por IA. Esto incluye generar casos de prueba a partir de requisitos o historias de usuario, identificar escenarios límite, crear patrones de datos de prueba y ayudar a los equipos a mejorar más rápidamente la cobertura de regresión. Los resultados positivos pueden incluir:

• Creación de casos de prueba entre un 20–35 % más rápida
• Mayor cobertura de pruebas en el mismo periodo del sprint
• Ciclos de preparación de regresión más cortos
• Mejor detección temprana de defectos en el ciclo de vida si las indicaciones y la validación son sólidas

Gestión del conocimiento y proceso de incorporación más sólidos: La IA está infravalorada en un área crítica: la captura del conocimiento tácito. En muchos equipos de ingeniería, gran parte de la experiencia operativa reside en la mente de unas pocas personas. La IA ayuda a convertirla en manuales de operaciones consultables, guías de resolución de problemas, resúmenes de arquitectura, guías de incorporación y resúmenes de RCA. Entre los beneficios habituales se incluyen:

• Incorporación más rápida de nuevos ingenieros
• Menor dependencia de unas pocas personas “imprescindibles”
• Mejor transferencia de conocimientos entre equipos
• Menos tiempo dedicado a revisar tickets antiguos y conversaciones de Slack/Teams

Para las pymes y las organizaciones de ingeniería medianas en crecimiento, este puede ser uno de los casos de uso con mayor retorno de la inversión, ya que mejora la escalabilidad del conocimiento de ingeniería, no solo la producción de código.

Las desventajas de la IA

Por supuesto, los resultados no son todos positivos:

• Las tasas de defectos pueden aumentar si la IA se lleva a producción demasiado rápido. El mayor error que observamos es tratar el código generado por IA como “productividad del desarrollador” sin reforzar la revisión, las pruebas y la validación de seguridad.
• El riesgo de seguridad y cumplimiento aumenta sin medidas de protección. Esta es una preocupación importante en entornos regulados o sensibles.

• Los equipos pueden volverse más rápidos, pero menos reflexivos. Una desventaja sutil es la descarga cognitiva. La IA debe reducir el esfuerzo mecánico, no reducir el pensamiento de ingeniería.
• El tiempo de ciclo mejora, pero la calidad de la entrega no. Esta es una de las trampas más habituales para los ejecutivos: los equipos celebran una producción de código más rápida, pero ignoran si ha mejorado el resultado empresarial. El éxito de la IA no puede medirse únicamente por “cuánto más rápido escriben código los desarrolladores”. Debe medirse en función de la frecuencia de despliegue, la tasa de fallos de los cambios, la tasa de defectos que llegan a producción, el MTTR, los hallazgos de seguridad, el coste por versión y las horas de ingeniería ahorradas frente al retrabajo generado.

Lo que la IA nunca debería tocar

Estas son las áreas en las que la IA debe ayudar en el análisis, pero nunca sustituir al responsable humano que debe rendir cuentas.

• Aceptación del riesgo. Ninguna IA debería decidir si se acepta un riesgo de seguridad, si se aplaza un parche, si se opera con una brecha de control conocida o si se continúa con un lanzamiento que presenta problemas sin resolver. Esa decisión corresponde al líder responsable, porque tiene consecuencias financieras, legales y reputacionales.
• Liderazgo en situaciones de crisis. Ante una interrupción importante, un incidente cibernético, una filtración de datos o una escalada regulatoria, la IA puede ayudar con los datos y las opciones. Pero las personas deben asumir la responsabilidad de los mensajes dirigidos a las partes interesadas, la relación con los reguladores, las decisiones sobre la confianza de los clientes, la comunicación del liderazgo y la dirección de la sala de crisis.
• Ética, privacidad y compensaciones empresariales. La IA no puede ser la autoridad final para determinar si el uso de los datos es éticamente aceptable, si una decisión es justa para los clientes o empleados, si un control de vigilancia o supervisión es proporcional o si la conveniencia empresarial debe prevalecer sobre los principios de confianza. Estas son decisiones de liderazgo.

Por qué la arquitectura ya no se limita a la escala y el rendimiento

La IA me obligó a replantearme la idea de que la arquitectura es algo que se diseña una vez y se optimiza con el tiempo. Ese modelo funcionaba cuando los sistemas cambiaban de forma gradual. Deja de funcionar cuando los agentes de IA, los copilotos, las capas de automatización y las canalizaciones de datos empiezan a influir dinámicamente en el comportamiento de producción.

Prem Kumar comparte

La arquitectura ya no se limita a la escala y el rendimiento. Ahora se centra en la adaptabilidad, la trazabilidad, la resiliencia y la gobernanza.

Hoy, la arquitectura debe tratarse como un sistema de control vivo, no como un plano fijo. Eso significa que:

• Los sistemas deben diseñarse para una adaptación continua.
• La observabilidad debe extenderse más allá de la infraestructura para abarcar el comportamiento de la IA y la calidad de las decisiones.
• La seguridad debe pasar de la defensa perimetral a la confianza, el control y la resiliencia integrados.

En otras palabras, la arquitectura ya no se limita a la escala y el rendimiento. Ahora se centra en la adaptabilidad, la trazabilidad, la resiliencia y la gobernanza.

Consejos para los CTO

Mi consejo para los CTO es sencillo: no tratéis la IA únicamente como una carrera tecnológica; tratadla como una oportunidad de liderazgo empresarial. En este momento, demasiadas organizaciones persiguen proyectos piloto, herramientas y casos de uso de IA sin plantearse antes las preguntas más importantes: ¿Qué problema empresarial estamos resolviendo? ¿Qué riesgo estamos introduciendo? ¿Qué capacidad estamos desarrollando a largo plazo?

Los CTO deben liderar el cambio impulsado por la IA en cinco frentes:

1. Empieza por el valor empresarial, no por la exageración en torno a la IA. Si la IA no está vinculada al crecimiento de los ingresos, la productividad, la experiencia del cliente, la reducción de riesgos o la velocidad de ejecución, se convierte en experimentación sin impacto.
2. Construye la IA sobre unos cimientos sólidos. La IA no puede compensar una infraestructura débil, datos fragmentados, una gobernanza deficiente o una asignación de responsabilidades poco clara. Los CTO deben asegurarse primero de que la organización cuenta con la disciplina adecuada en materia de datos, preparación para la nube, medidas de protección de la ciberseguridad y una arquitectura de integración. Sin ello, la IA escala la confusión más rápido de lo que escala el valor.
3. Considera la ciberseguridad, la privacidad y la gobernanza como principios de diseño. Este no es el momento de añadir la seguridad más adelante. La IA introduce nuevos riesgos —filtraciones de datos, uso indebido de modelos, sesgos, alucinaciones, deficiencias de cumplimiento y uso de IA no supervisado en los distintos equipos—. Los mejores CTO integrarán desde el primer día la gobernanza de la IA, los controles de acceso, la protección de datos, la rendición de cuentas de los modelos y la supervisión humana en el modelo operativo.
4. Redefine el papel del líder tecnológico. En esta era, el CTO ya no es solo el custodio de los sistemas. El CTO debe convertirse en un traductor entre la ambición empresarial y la realidad técnica, ayudando al consejo y al equipo directivo a comprender qué puede hacer realmente la IA, dónde puede fallar y cómo adoptarla de forma responsable. Esto tiene tanto que ver con la formación, la priorización y la generación de confianza como con la arquitectura.
5. Céntrate en la ampliación de las capacidades antes que en la automatización. La estrategia de IA más sólida no es «¿Cómo sustituimos a las personas?», sino «¿Cómo hacemos que nuestros empleados sean más rápidos, precisos y eficaces?». La IA debe ampliar primero las capacidades de los equipos: mejorar la toma de decisiones, reducir el trabajo repetitivo, acelerar el análisis y liberar talento para contribuciones de mayor valor. Ahí es donde se genera confianza, mejora la adopción y la transformación se vuelve sostenible.

Sigue las novedades

Puedes seguir el trabajo de Prem en LinkedIn. También puedes escuchar su pódcast, PREMINENT KONCLAVE.

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