Curado por: Jorge Valdés Garciatorres

«La tecnología cambia exponencialmente; las organizaciones cambian logarítmicamente.»
— Scott Brinker, Martec’s Law (2013)

En el laboratorio RiskFlow y en otras interacciones con profesionales,  hay una pregunta que se repite con frecuencia, sin importar el sector de los participantes.

Alguien comenta o plantea alguna variante de lo mismo: si la inteligencia artificial va a hacer buena parte del trabajo, ¿qué queda del rol del director de proyecto?

Mi respuesta ha sido consistente: el rol se desplaza de hacer hacia curar y decidir y eso, desde mi punto de vista eleva el nivel de exigencia.

La respuesta suele satisfacer en la sala. Pero cuando terminé de releer el apéndice X3 de la octava edición de la Guía del PMBOK^®, me di cuenta de que la respuesta estaba incompleta en un punto que importa: no he mencionado dónde exactamente ocurre ese desplazamiento, ni de dónde saca el director de proyecto el respaldo para decidir cuando decide.

El mapeo que casi nadie hace

La octava edición trata la inteligencia artificial en un apéndice, no en el cuerpo del estándar y esa ubicación ya dice algo.

Dentro de ese apéndice, PMI^® incluye una tabla que mapea casos de uso de IA contra los dominios de desempeño de la dirección de proyectos, clasificados en tres estrategias de adopción: automatizar, asistir y aumentar. La lógica del mapeo es la complejidad de la tarea y la intervención humana que requiere para producir un resultado de calidad.

Si uno recorre esa tabla con los siete dominios en la mano, aparece algo que ninguna infografía de LinkedIn menciona.

Gobernanza concentra la mayoría de los casos documentados: informes y tableros generados de forma automática, monitoreo contra línea base con alertas de desviación, actas y acuerdos de reunión, señalización de advertencia temprana mediante reconocimiento de patrones cuando los indicadores formales todavía se ven en verde.

Es el dominio con más cobertura, y la mayor parte cae en automatizar.

Riesgo viene después, con identificación y evaluación a partir de datos históricos y referencias del sector, análisis de impacto sobre tiempo, costo y calidad y ROI ajustado al riesgo.

Aquí las estrategias se reparten entre asistir y aumentar, lo cual es coherente: la identificación de un riesgo emergente no se despacha sin criterio.

Interesados aporta dos casos, ambos en aumentar: análisis de sentimiento sobre las comunicaciones del proyecto y comunicación adaptada al canal y a la frecuencia que cada interesado necesita.

Cronograma aparece con planificación dinámica ante cambios internos y externos, detección de conflictos de programación y evaluación de riesgos inherentes a ramificaciones y fusiones de rutas.

Todos clasificados como asistir, con la advertencia explícita de que el primer resultado no se considera terminado.

Y ahí se acaba la tabla.

Alcance, finanzas y recursos, tres de los siete dominios de desempeño, no tienen un solo caso de uso documentado en el apéndice, sin contar adquisiciones, que el estándar trata en un apéndice aparte.

No aparece la gestión autónoma del presupuesto, ni la asignación de personas a actividades, ni el control de cambios de alcance, ni el screening de proveedores

Justamente los tres territorios donde el discurso de mercado promete más autonomía.

Antes de sacar conclusiones conviene leer con cuidado cómo el propio estándar presenta esa tabla.

La introduce como demostración de cómo la IA puede mejorar varios aspectos de la dirección de proyectos y la enumeración que sigue viene precedida por un «como». Es lenguaje ilustrativo. La tabla nunca declara ser exhaustiva.

Eso deja abierta una pregunta que el apéndice no resuelve.

La omisión de alcance, finanzas y recursos admite dos lecturas, y el texto no permite elegir entre ellas.

La primera es de alcance editorial. El apéndice ilustra, no cataloga; los tres dominios faltantes se quedaron fuera por economía de espacio, y los casos existen aunque no estén escritos ahí. Bajo esta lectura, el vacío no dice nada sobre la práctica.

La segunda es de madurez. Los cuatro dominios que sí aparecen comparten una característica: operan sobre información que el proyecto ya produjo. Gobernanza consolida lo reportado, riesgo reconoce patrones en datos históricos, interesados analiza comunicaciones existentes, cronograma recalcula sobre dependencias declaradas.

Los tres ausentes exigen algo distinto: comprometer dinero, asignar personas, aceptar o rechazar un cambio de alcance. Bajo esta lectura, el vacío señala dónde la práctica documentada todavía no llega.

No tengo forma de determinar cuál de las dos operó en el comité editorial de PMI^® y sospechar una intención donde solo hay una omisión sería sobreinterpretar el documento.

Lo relevante es que ninguna de las dos lecturas te sirve como respaldo. Si el apéndice solo ilustra, no puedes citarlo para justificar que automatizaste la asignación de recursos. Si refleja madurez de la práctica, tampoco. En ambos casos el director de proyecto que decide automatizar en esos tres dominios queda sin referencia normativa que lo cubra, y esa es la definición operativa del residuo: el estándar no prohíbe, guarda silencio, y el silencio no exime.

Otro punto que vale la pena destacar, la octava edición no usa el término «IA Agéntica», hoy la etiqueta más repetida en las publicaciones del mundo de IA. No es que el concepto no existiera: Gartner lo había nombrado tendencia estratégica para 2025 desde octubre de 2024, más de un año antes de que el estándar llegara a las librerías.

Lo que la ausencia muestra es el desfase que Brinker describió con la ley de Martec, y que en el caso de los estándares tiene una razón adicional: un cuerpo normativo se cierra editorialmente meses antes de publicarse y documenta prácticas establecidas, no vocabulario en circulación. La brecha no es un descuido del comité; es la consecuencia de que la herramienta cambie a una velocidad y el documento que la norma a otra.

Es exactamente ahí donde ocurre el desplazamiento que describo y por eso la respuesta que daba en la sala estaba incompleta. Curar no es una postura ni una actitud; son tres operaciones con costo. Seleccionar qué tarea entra al flujo automatizado y cuál no. Verificar una salida que llega redactada con la fluidez de algo revisado, cuando no lo ha sido. Descartar lo que no aguanta, incluso después de haber invertido tiempo en configurarlo.

El criterio que sí trae el estándar

Aquí es donde el apéndice X3 deja de ser un catálogo y se vuelve útil. Además de los casos de uso, PMI enumera los factores éticos y de riesgo que atraviesan cualquier adopción de inteligencia artificial en proyectos.

Leídos como lista de precauciones, se parecen a los que circulan en todas partes. Leídos como criterio de decisión en el terreno sin cobertura, se vuelven operativos.

Responsabilidad. El estándar es explícito en que un ser humano debe responder por cada decisión y que esa responsabilidad tiene que quedar definida con claridad.

La prueba operativa es simple: si no puedes nombrar a la persona que responde por una decisión antes de automatizarla, no la automatices.

Confiabilidad. Toda salida se verifica y se valida, porque puede ser parcial, incorrecta o irrelevante. La consecuencia práctica es que el tiempo de verificación debe presupuestarse.

Un flujo automatizado que ahorra cuatro horas y exige dos de revisión ahorra dos, no cuatro y esa es la cifra que va al caso de negocio.

Privacidad. Los datos de proyecto suelen estar regulados por contrato, por política interna o por ley. El estándar señala que las versiones gratuitas de estas herramientas rara vez permiten restringir el uso de los datos para reentrenar los modelos.

Antes de que un agente lea tu registro de riesgos, alguien tuvo que verificar en qué condiciones lo lee.

Sesgo. Los datos históricos de una organización cargan sus propios patrones. Un sistema entrenado sobre proyectos que sistemáticamente subestimaron el esfuerzo va a recomendar estimaciones que también lo subestiman, con la ventaja retórica de venir acompañadas de un porcentaje.

Transparencia, o mejor dicho trazabilidad. El estándar pide transparencia sobre el uso de los datos y el funcionamiento de los algoritmos; en la operación de un proyecto hace falta algo más estrecho y más exigible: quién usó qué herramienta, con qué datos y bajo qué criterio, en un registro que pueda explicarse a los afectados.

Sin ese registro, la decisión no es auditable, y una decisión no auditable no es defendible ante un patrocinador, un cliente o un revisor externo.

Derechos de autor. La titularidad de lo generado depende del nivel de elaboración humana aportado.

Para quien produce entregables contractuales, esto no es un detalle académico.

Sostenibilidad. Cada consulta consume electricidad y agua y el estándar lo pone como factor a considerar al decidir el uso.

Es el criterio que menos aparece en el contenido que circula sobre el tema, y viene del propio PMI.

Estos siete factores no resuelven el residuo. Lo que hacen es convertirlo en una decisión documentable: el director de proyecto que automatiza en alcance, finanzas o recursos sin referencia normativa disponible al menos puede dejar constancia del criterio con el que decidió y de quién responde por el resultado.

Esa es la exigencia mayor que menciono en la sala, dicha con más precisión. El trabajo de producción no se reduce, se transmuta: lo que queda quizás represente menos horas, pero implica una mayor responsabilidad y por tanto es de mayor exigencia. Y la parte que queda es la que no tiene manual, en dominios que ahora podemos nombrar.

Los tres dominios sin cobertura documentada no son los mismos en todas las organizaciones, porque la disponibilidad de datos íntegros cambia dónde se puede automatizar con sentido.

En la tuya, ¿cuál de los tres tiene los datos más limpios y cuál los tendrías que reconstruir antes de dejar que algo decida sobre ellos? Esa respuesta ordena el mapa de adopción mejor que cualquier catálogo de casos de uso.

Referencias

Brinker, S. (2013, 13 de junio). Martec’s Law: Technology changes exponentially, organizations change logarithmically. Chief Martec. https://chiefmartec.com/2013/06/martecs-law-technology-changes-exponentially-organizations-change-logarithmically/

Gartner. (2024, 21 de octubre). Gartner identifies the top 10 strategic technology trends for 2025. https://www.gartner.com/en/newsroom/press-releases/2024-10-21-gartner-identifies-the-top-10-strategic-technology-trends-for-2025

Project Management Institute. (2025). El estándar para la dirección de proyectos y Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK®) (8.ª ed.). Project Management Institute.