El PMI le puso reglas al uso de IA en proyectos: qué dice el nuevo estándar y qué cambia en la práctica

Hace unos meses, en una reunión de seguimiento, alguien del equipo tiró sobre la mesa un cronograma "optimizado por IA". Nadie en la sala sabía qué datos había usado la herramienta, con qué criterio había reordenado las tareas, ni quién se hacía responsable si la estimación fallaba. Terminamos la reunión igual que empezamos: revisando el cronograma a mano. La herramienta no estaba mal. Lo que faltaba era un marco para usarla.

Ese vacío es, más o menos, lo que el PMI vino a llenar con su último estándar: "El Estándar para la Inteligencia Artificial en la Dirección de Portafolios, Programas y Proyectos". No es una guía de herramientas ni un curso de prompting. Es, en esencia, lo mismo que hace el PMBOK con la dirección de proyectos tradicional: ponerle estructura, principios y vocabulario común a algo que la mayoría de las organizaciones ya está haciendo de forma desordenada.

Por qué esto no es "un documento más sobre IA"

Si dirigís proyectos hace un tiempo, ya viste este patrón: una tecnología nueva entra por la ventana, alguien la adopta porque "hay que estar", y dos años después nadie sabe bien quién decidió qué ni con qué criterio. Pasó con las herramientas de gestión ágil mal implementadas, pasó con la migración a la nube sin plan de gobierno, y está pasando ahora con la IA.

El estándar parte de una idea que a cualquiera que haya liderado un equipo le va a resultar familiar: la tecnología no fracasa sola, fracasa la gestión alrededor de ella. Por eso el documento no se mete demasiado en cómo funciona un modelo por dentro. Se mete en algo mucho más cercano a nuestro trabajo diario: cómo se decide usarla, quién responde por sus resultados y cómo se sostiene en el tiempo.

Siete principios que ya conocés, aplicados a un problema nuevo

El estándar organiza su base en siete principios. Ninguno te va a sonar extraño si venís del mundo de calidad o de dirección de proyectos, porque son primos hermanos de cosas que ya aplicás:

• Valor estratégico: la IA se justifica si empuja objetivos de negocio, no porque "hay que tener IA".
• Riesgo: gestionar los riesgos propios de la IA sin sacar al humano de la ecuación (el famoso human-in-the-loop, que en criollo es: alguien con criterio y responsabilidad firma antes de que algo pase a producción).
• Gobernanza y cumplimiento: reglas claras de quién decide, quién audita y quién responde.
• Personas y cultura: sin un equipo dispuesto a trabajar distinto, la mejor herramienta se cae sola.
• Ética y responsabilidad profesional: transparencia y equidad, no como discurso sino como criterio de diseño.
• Involucramiento de los interesados: a los interesados no se los informa al final, se los suma desde el principio.
• Optimización e innovación, y calidad de los datos: sin datos confiables, cualquier modelo es una calculadora cara equivocándose con seguridad.

Lo interesante es que ninguno de estos principios es nuevo para quien gestiona calidad. Son, con otro nombre, los mismos pilares que sostienen un sistema de gestión ISO 9001 bien implementado: alineación estratégica, gestión de riesgos por cláusula 6.1 (acciones para abordar riesgos y oportunidades), involucramiento de interesados, mejora continua. La IA no inventó la disciplina que necesita para no fracasar; esa disciplina ya existe desde hace tiempo si venías trabajando en un ámbito de gestión de procesos en serio.

Cinco frentes de trabajo, no una checklist

Después de los principios, el estándar define dominios de desempeño: gestión de expectativas de los interesados frente a la IA, definición del alcance, diseño de arquitectura con calidad y confiabilidad, ejecución de objetivos estratégicos, y gestión de riesgos e incertidumbre. No es una lista para tildar casilleros un viernes a la tarde antes de irte más temprano; es una manera de repartir responsabilidades reales. Cada uno de esos frentes debe tener un responsable, aunque sea la misma persona con distintos sombreros.

Para quien dirige portafolios, esto se traduce en priorizar iniciativas de IA por impacto real, no por moda. Para quien dirige programas, en coordinar que la adopción no se vuelva un mosaico de herramientas sueltas entre proyectos. Y para quien está en la trinchera del día a día del proyecto, en algo bien concreto: una matriz RACI que diga, sin ambigüedad, quién es responsable cuando el modelo se equivoca, haya pasado o no la revisión correspondiente.

El ciclo de vida no se tira a la basura, se adapta

Uno de los aportes más prácticos del estándar es que no propone reinventar el ciclo de vida de portafolios, programas y proyectos que ya se usa. Lo adapta: inicio y planificación, recopilación y preparación de datos, desarrollo del modelo, despliegue, monitoreo, optimización y —esto se suele olvidar— fin de vida y desmantelamiento del sistema de IA cuando ya no aporta valor o queda obsoleto.

Ese último punto vale la pena subrayarlo, porque casi nadie lo planifica, y no nos olvidemos que planificar es "traer el futuro al presente para poder hacer algo": ¿qué pasa el día que hay que apagar el modelo? ¿Quién decide, con qué criterio, y qué pasa con los datos y las decisiones que se tomaron con él? Si no lo pensás desde el diseño del proyecto, lo vas a resolver mal y apurado.

Lo que esto significa si venís del mundo de la calidad

Para quien ya trabaja con Six Sigma o con sistemas de gestión ISO, el estándar no exige aprender un lenguaje nuevo. Exige extender el mismo rigor a un objeto distinto: en vez de auditar un proceso productivo, auditás un sistema de IA. En vez de medir la capacidad de un proceso, medís la confiabilidad y el sesgo de un modelo. El estándar incluso dedica un capítulo entero a consideraciones éticas y legales —propiedad intelectual, responsabilidad, auditorías— que a cualquiera que haya armado un plan de auditoría interna le va a resultar un terreno conocido, aunque con vocabulario nuevo.

Qué hacer con esto, en la práctica

No hace falta certificarse —aunque obviamente es recomendable— para empezar a aplicar el criterio del estándar. Alcanza con tres movimientos concretos:

1. Nombrar responsables, no solo usuarios, de cada herramienta de IA que ya esté circulando en tus proyectos.
2. Escribir el caso de uso antes que la herramienta: qué problema de negocio resuelve, con qué datos, y cómo se mide si funcionó.
3. Definir quién frena: si un resultado generado por IA se ve raro, tiene que estar claro quién tiene la autoridad —y la obligación— de pararlo antes de que llegue al cliente o a otro interesado.

Ninguno de estos tres puntos requiere presupuesto. Requiere, como casi todo en dirección de proyectos, sentarse a definirlo antes de que el problema aparezca solo.

La IA no vino a reemplazar el criterio de quien dirige proyectos. Vino a exigirle que lo aplique con la misma seriedad de siempre, a un objeto nuevo. El estándar del PMI, en el fondo, no dice mucho más que eso, pero lo dice con la estructura necesaria para evitar improvisaciones.