Servicios de Ciberseguridad Gestionados: El CISO no asume la responsabilidad exclusiva
Benedikt Langer
8 Min. de lectura En muchas empresas, el CISO es considerado la persona responsable de la seguridad. ...
Leer artículo
10 Min. Tiempo de lectura
El estudio de liderazgo tecnológico de Deloitte lista el 71 por ciento de las empresas con cinco o más líderes tecnológicos en el nivel C. De operador a orquestador, dice la diapositiva. Quién es realmente el responsable de la orquestación en las corporaciones no suele ser un nivel C, sino un PMO. Y precisamente la ocupación de este puesto decide si los despliegues de IA en 2026 tendrán éxito.
Lo más importante en resumen
- Los PMO son el papel de cuello de botella silencioso en los despliegues de IA. Mientras que el liderazgo tecnológico de nivel C es visible en las diapositivas de la junta directiva, los despliegues fallan en el punto donde se unen el alcance, los proveedores y las partes interesadas internas. Esto no es la agenda del CIO, es la realidad del PMO.
- Tres configuraciones hacen que el despliegue sea fiable. PMO como lugar de cumplimiento, PMO como brazo extendido del CIO sin mandato propio, PMO sin autoridad para establecer métodos. Quien tenga alguno de estos, no construye un despliegue de IA funcional.
- El método no es el problema principal, el mandato lo es. Un PMO sin un mandato claro para definir el alcance corre detrás de cada parte interesada. Los marcos y herramientas en esta configuración son meros calmantes, no reemplazan la decisión de quién puede decir no en el programa.
RelacionadoEl talento tecnológico senior se vuelve más escaso / Mandatos tecnológicos en el consejo de administración
Por qué los marcos de orquestador se deciden en el PMO
El estudio de Deloitte de 2026 toca un punto verdadero. El liderazgo tecnológico de nivel C está más fragmentado que hace cinco años. CIO, CDO, CISO, CAIO, Director Digital, Jefe de Datos a menudo se sientan paralelamente en la junta directiva o en informes directos. Lo que el estudio no dice es que estas cinco funciones no se encuentran operativamente en el nivel C. Se encuentran en los grandes programas, y allí es donde el PMO es el lugar donde la coordinación entre ellos funciona o se rompe.
He acompañado a tres despliegues de IA en corporaciones alemanas en los últimos 18 meses que comenzaron como un tema de la junta directiva. Los tres tenían una configuración de patrocinio de nivel C que parecía buena en la presentación de la junta directiva. Dos de ellos se han quedado dormidos en la fase del programa en los últimos nueve meses. El lugar donde se quedaron dormidos fue el PMO. No porque hubiera personas malas allí. Sino porque faltaba el mandato.
Un Daily Standup dura tres minutos demasiado largos en la mayoría de los equipos. No dieciséis minutos demasiado largos, tres. Exactamente esta es la escala en la que se decide la madurez del PMO. Tres minutos son la diferencia entre una reunión que produce decisiones y una que intercambia informes de estado. En un despliegue de IA, esto se multiplica rápidamente por semanas.
Configuración 1: PMO como unidad de cumplimiento
Esta configuración es la más común. El PMO se ubica en la organización como el brazo extendido de la función de cumplimiento y riesgo. Su mandato consiste en informar, no en decidir. Se mantienen registros de riesgos, se actualizan registros RAID y se preparan revisiones de Stage-Gate. Si una parte interesada solicita un requisito adicional, éste se agrega al backlog. Si un proveedor cambia una fecha de entrega, se actualiza el registro de riesgos.
Los registros de riesgos son inútiles si se mantienen por razones de cumplimiento. Se convierten en carpetas donde se ordenan los temas abiertos sin que se tome una decisión. En una transformación normal, esta configuración puede durar dos años. Sin embargo, en la implementación de IA en 2026 no. La velocidad de iteración es tan alta que un PMO que solo clasifica se queda rezagado después de cada sprint.
Ejemplo concreto de un grupo de tamaño mediano, anonimizado: El PMO de un proveedor de energía registró 47 entradas de riesgo en los primeros nueve meses de implementación de IA y concluyó cuatro de ellas con escalada a la dirección del programa. Las otras 43 se reevaluaron trimestralmente. En el noveno mes, un auditor visitó el programa y preguntó quién decidía sobre las 43 entradas. Nadie sabía la respuesta. La dirección del programa cesó dos meses después.
Configuración 2: PMO sin mandato propio
El PMO se encuentra directamente bajo el CIO o CAIO y hace lo que esta función le dice. Metodológicamente, esto suena razonable: caminos cortos, informes claros, un patrocinador. En la práctica, falta la palanca cuando la implementación supera los límites de la organización del CIO. Y esto siempre ocurre en las implementaciones de IA. Los datos provienen de las áreas de negocio, el cumplimiento de la ley, la gestión del cambio de RRHH, el presupuesto de finanzas.
Si el PMO en esta configuración solicita datos a un propietario de área de negocio, el propietario del área de negocio pregunta primero a su propio supervisor. El supervisor rara vez tiene ganas de asumir un esfuerzo adicional, y el PMO no tiene una vía de escalada directa. La solicitud se pierde. El PMO escala al CIO. El CIO escala al consejo de administración. El consejo de administración se refiere a la configuración de patrocinio del programa. Tres semanas perdidas, un requisito no respondido.
Si nadie puede decir no a un alcance, no necesitas una herramienta de PM. Necesitas una conversación. Y esta conversación no tiene lugar en el PMO sin mandato, porque el PMO no es el lugar donde se decide la pregunta.
Configuración 3: PMO sin autoridad para establecer métodos
Esta configuración es la más insidiosa porque parece saludable a primera vista. El PMO tiene un mandato, un presupuesto, una vía de informe directa al CFO o COO. Lo que le falta es la autoridad para establecer métodos de forma vinculante en la organización. Cada subproyecto elige su propio enfoque. Uno trabaja según SAFe, otro según Disciplined Agile, otro según el modelo en cascada clásico, otro según un modelo híbrido definido internamente.
Metodológicamente, esto no es incorrecto, incluso es moderno según el libro de texto. En la práctica, impide cualquier control de flujo de trabajo cruzado. Una implementación de IA que requiere simultáneamente canalizaciones de datos de tres áreas de negocio, una plataforma MLOps, una capa de gobernanza y una gestión de riesgo de modelo no se puede coordinar con cuatro enfoques diferentes. No porque los métodos sean incorrectos, sino porque las transferencias entre ellos se vuelven demasiado costosas.
La transformación más común que he visto es aquella que después de dos años se parece a la antigua organización con nuevos títulos de rol. Exactamente esto produce la configuración 3 de manera fiable: mucha variedad de métodos, poca coordinación, al final una implementación que formalmente vive y fácticamente es llevada a cabo por flujos de trabajo individuales.
Qué debe aclarar el equipo directivo antes de la próxima implementación de un programa de IA
- Quién en la Oficina de Gestión de Proyectos (PMO) puede decir «no». Si esta pregunta no tiene una respuesta clara antes de que comience el primer sprint, la PMO se convertirá en un centro de escalada. Los centros de escalada no toman decisiones, solo las trasladan. Definan antes del inicio qué decisiones sobre el alcance y el presupuesto se pueden tomar en la PMO y cuáles deben ir a la reunión de la junta directiva.
- Quién establece de manera vinculante el método para el programa. No cada subproyecto tiene la opción de elegir. Un enfoque con corredores de ajuste claros para los sub-flujos de trabajo. Sin autoridad para establecer métodos en la PMO, no coordinan, solo piden.
- Cómo se ocupará la PMO: ¿profesionales experimentados en operaciones o expertos en métodos. Una PMO con tres formadores certificados en SAFe y sin nadie que haya salvado un programa fallido es un riesgo. La profundidad de la experiencia supera la amplitud de los certificados.
Preguntas frecuentes
¿Debería el PMO informar directamente al consejo de administración o al CIO durante la implementación de la IA?
En implementaciones de IA con un claro alcance funcional cruzado, a un patrocinador de programa que se sitúa transversalmente al CIO. El CFO o COO son los puestos más comunes que tienen la autoridad suficiente. Los informes directos al CIO solo funcionan si el propio CIO tiene la influencia funcional cruzada en el consejo de administración. Esto no es el estándar en muchas corporaciones en 2026.
¿Qué método es más adecuado para una implementación de IA: SAFe, Disciplined Agile o Stage-Gate clásico?
Ninguno de ellos completamente. Las implementaciones de IA exitosas suelen combinar un marco de Stage-Gate estable para las entregas regulatorias delicadas con ciclos de iteración ágiles en los flujos de trabajo de modelos y datos. Quien implemente un método puro, pagará el precio como tarde en la gestión de riesgos del modelo o en la auditoría de cumplimiento.
¿Cuándo es hora de reemplazar al PMO en el programa en curso?
Cuando la proporción de decisiones del programa que se toman en el PMO cae por debajo del 30 por ciento y se mantiene estable durante varios sprints. Esto no es normal en una fase de madurez, sino un indicador de que el PMO ha perdido su papel de control. Como muy tarde, es entonces cuando surge la pregunta de si el problema es el PMO o el mandato. Reemplazar ambos suele ser más barato que dejar que ambos sufran.
¿Cuán grande debe ser un PMO para una implementación de IA corporativa?
Más pequeño de lo que la mayoría de los programas planean. En las tres implementaciones que he visto, el límite funcional inferior estaba en cinco equivalentes de tiempo completo: un gerente de programa, un propietario de método, un coordinador de partes interesadas, un propietario de informes y un responsable de calidad. El PMO solo adquiere más sentido cuando hay sub-PMO propios sentados por flujo de trabajo y el lugar central solo coordina.
¿Qué papel desempeña el CAIO junto al PMO?
El CAIO define la estrategia de IA y decide sobre el portafolio de modelos, la política de datos y la priorización de casos de uso. El PMO lleva a cabo la ejecución del programa. Si ambas funciones se mezclan, una de ellas colapsa. Si funciona, el CAIO tiene un corredor de escalada y decisión claramente definido en el PMO, no un papel de trabajo diario.
Más del network de MBF Media
- cloudmagazinAWS y Nvidia: un millón de GPU obliga a los equipos de plataforma
- MyBusinessFutureBanco de Hidrógeno de la UE: 1.300 millones cambian la distribución
- SecurityTodayIdentidades de máquina: las cuentas que nadie cuenta
Fuente de la imagen: generada por IA (mayo de 2026), certificado C2PA disponible.
Imágenes del artículo: generadas por IA (mayo de 2026)