Personalidades y liderazgo de la inteligencia artificial

Recientemente he finalizado la lectura del libro 'The Infinity Machine: Demis Hassabis, DeepMind and the Quest for Superintelligence' escrito por Sebastian Mallaby y que se centra, fundamentalmente, en figura de Demis Hassabis, como personaje y como fundador y líder de DeepMind.

En sus páginas, sin embargo, se mencionan también a algunas otras empresas y, por lo que respecta a este post, a otros líderes de la inteligencia artificial: Sam Altman, Sunday Pichai, Yann LeCun, etc

Se trata de un libro largo pero interesante e ilustrativo que muestra, no sólo la personalidad de Hassabis, sino también todas los avatares tanto científicos y tecnológicos, como empresariales, que han rodeado el desarrollo en los últimos años de la inteligencia artificial.

Casi finalizando su lectura, me puse a reflexionar, no sólo sobre la figura de Hassabis sino, en general sobre la de los líderes actuales de la inteligencia artificial. Y es esa breve reflexión la que quisiera compartir en este post,  

Sobre el liderazgo

Antes, un breve alto para hablar de liderazgo.

Sin pretender una definición rigurosa ni académica, podemos considerar que el liderazgo es aquella capacidad o competencia de las personas que les habilita a la influencia o conducción de otras personas hacia el logro de unos objetivos, señalados por ese líder. Y suele adornarse de otras capacidades o habilidades como la visión estratégica, la comunicación, la persuasión y la resiliencia.

Se trata de una capacidad fundamental en muchos ámbitos: el político, el empresarial, el religioso y, en general, en muchas actividades que quizá consideremos menores comparadas con  las anteriores, como pudiera ser la dirección de proyectos.

Por si mismo, el liderazgo se puede considerar una capacidad muy importante y muy positiva y creo que así es, siempre que los objetivos hacia los que dirige el/la líder a sus equipos o a otras personas sean realmente buenos y deseables. 

Algunos líderes

Si ahora pasamos específicamente al campo de la inteligencia artificial reciente y repasamos, en parte con base en el libro citado, algunos líderes del campo de la IA ¿Qué nos encontramos?

Tenemos, por ejemplo, a Demis Hassabiss, el protagonista del libro, un líder visionario y hasta cierto punto idealista, con foco en la AGI ('Artificial General Inteligence') y un especial toque científico. 

Cerca de él, Sundar Pichai, CEO de Alphabet (Google) que parece ser un líder empresarial puro, con foco sobre todo en los resultados de su compañía. 

Por otro tenemos a Sam Altman, en apariencia pura ambición, quién más allá de sus discursos, parece buscar su propia promoción y la de su empresa OpenAI y el dominio del mercado.

Tenemos también a Yann LeCun, también de base científica pero, quizá, dada su ligadura actual con Meta, con ciertos intereses empresariales que le pueden condicionar.

No se si le podemos considerar un líder de la IA, pero conviene no olvidar a Mark Zuckerberg, en apariencia más concentrado, como en el caso de Pichai, en su empresa Meta aunque, en este caso, con una visión ética bastante en entredicho. 

Quizá, podemos añadir a Satya Nadella, de Microsoft, pero, de forma similar a Pichai, actuando más como puro CEO empresarial o también, todavía en el ámbito de Microsoft, a su actual líder en IA, Mustafá Suleyman, procedente de DeepMind y, en apariencia, también con una visión idealista de la IA y centrada en el bien común.

Seguramente se pueda mencionar mencionar alguno más, como Dario Amodei (Anthropic) a caballo, creo, entre la visión empresarial y la ética, a su actual empleado Andrej Karpathy, con visión claramente tecnológica, o en otro ámbito, Andrew Ng, muy moderado y más orientado a la ciencia y la educación. 

¿Es éste el liderazgo que necesitamos?

Y lo que de alguna forma me llamó la atención, lo que quisiera reflejar en este artículo son dos cosas.

Por un lado, destacar el hecho de hasta qué punto, el desarrollo de una disciplina, en este caso la inteligencia artificial, viene marcado por las circunstancias pero, sobre todo, por la visión y la personalidad de personas concretas, los líderes antes mencionados. Es cierto que en un libro como el que me inspira, es fácil que el autor caiga en un cierto tono que voy a llamar 'épico' y que resalte más esas características de los personajes, esos golpes de fortuna o desgracias, esas casualidades que siempre ocurren y cuyo peso real a lo mejor es menor de lo que un libro como éste nos puede hacer pensar. Pero aún así, y sin abandonar esas prevenciones, no deja de llamarme la atención la importancia de personas concretas y, sobre todo, personalidades concretas.

Y la segunda parte de mi reflexión, muy unida a la anterior, es preguntarme si, realmente, es bueno que algo tan importante, tan transformador, tan llamado a condicionar nuestras economías y nuestras vidas ya desde el presente y seguro que en el futuro cercano, como es la inteligencia artificial dependa de tan pocas personas, de tan pocas visiones, personalidades, objetivos y circunstancias.

 Y aunque resulta atractivo y hasta digno de loa el peso que personas concretas, líderes reales, ejerzan su influencia y su liderazgo sobre todo tipo de actividades, en este caso del desarrollo de la inteligencia artificial, no dejo de preguntarme si, desde un punto de vista no sólo económico, técnico y operativo sino también , y quizá especialmente, desde un punto de vista ético, es buena esa concentración en unas pocas cabezas y en unas pocas voluntades del destino que está llamado a ser destino de todos.

Aunque no hablando específicamente de liderazgo, sino más bien de poder, el propio Papa León XIV expresó en su famosa encíclica 'Magnifica Humanitas' su preocupación por la concentración de poder, en lo relativo al desarrollo de la inteligencia artificial, en muy pocas manos. 

Tengo la sensación de que, sin quitar el más mínimo valor al liderazgo, y épicas de narrativa empresarial aparte, no sería mejor un liderazgo más amplio, más compartido, más consensuado y con mayores posibilidades de convertirse en un liderazgo para todos, y un liderazgo seguramente más ético.

Conclusiones

Como en toda actividad humana, en el caso del desarrollo de la inteligencia artificial juega un papel muy importante el liderazgo, con su capacidad para generar visiones y movilizar recursos y voluntades. 

Pero en ese caso específico de la inteligencia artificial, dada su potencia y poder transformador en todos los ámbitos, me pregunto si no sería mejor un liderazgo menos personal, más amplio, más compartido.

Google frente a la IA: tres formas de dilema del innovador

No sé si a los lectores de este blog les habrá pasado lo mismo que a mi pero, probablemente, dentro del panorama del sector tecnológico, contemplado fundamentalmente desde un punto de vista estratégico, desde que OpenAI lanzara ChatGPT ha flotado la pregunta, que personalmente yo mismo me he formulado, de cuál era el posicionamiento Google frente a la IA, cuál su estrategia, cuál su avance técnico real.

¿Está por delante o por detrás de OpenAI o de Antrophic? ¿Arrastra los pies porque no le conviene empujar para no dañar a su negocio de publicidad ligado al buscador o porque, realmente, sus competidores le han superado?

Recientemente, con la lectura del libro 'The Infinity Machine: Demis Hassabis, DeepMind and the Quest for Superintelligence' de Sebastian Mallaby que se centra en Demis Hassabis como personaje y en DeepMind como empresa he ampliado, y hasta cierto punto cambiado, mi opinión sobre el particular.  

Una estrategia competitiva de Google, quizá no bien percibida

Mi sensación personal, hasta hace bien poco, una sensación más intuitiva que otra cosa pero reforzada por los últimos  avances en Gemini, era que Google estaba 'nadando y guardando la ropa', es decir, que tenía capacidad tecnológica de sobra (incluso con modelos no lanzados o técnicas no publicadas) como para igualar o superar a sus competidores, especialmente OpenAI, cuando quisiera, pero que no pisaba el acelerador para no perjudicar su negocio principal. 

Y pensaba que, en esa estrategia, y una vez que la destrucción de su modelo de negocio basado en el buscador fuese inevitable, se lanzaría a tumba abierta a por el liderazgo en IA. Y mi sensación era que ya estaba empezando a acercarse a ese momento, que ya los últimos modelos Gemini igualaban e incluso superaban a los de OpenAI.

La lectura del libro que menciono, me hace reconsiderar parcialmente esa opinión y pensar que, quizá, sólo quizá, más allá de la protección de su negocio tradicional, realmente a nivel técnico Google fue  superado técnicamente durante un tiempo y sólo ahora está consiguiendo ponerse a la altura.  

En cualquier caso, lo que quiero comentar ahora es una visión más estratégica y de negocio de Google, su eventual dilema del innovador frente a la IA, un planteamiento, como digo, más estratégico que de capacidad tecnológica propiamente dicha.

El dilema del innovador

Antes de volver al caso de Google, recordar en qué consiste el famoso dilema del innovador ('innovator's dilemma').

El dilema del innovador fue descrito por el malogrado Clayton Christensen en su famoso libro del mismo título hace ya muchos años y describía el comportamiento, y el peligro, de empresas asentadas y bien gestionadas ante la llegada de tecnologías disruptivas..

En esencia viene a decir que las empresas asentadas y bien gestionadas tienen dificultades para identificar y apostar por innovaciones disruptivas. y que, precisamente, los mecanismos de decisión que las han llevado al éxito y a ser empresas bien gestionadas son los responsables de esa ceguera y ese error estratégico.

¿Por qué?

Pues porque los mecanismos de decisión se basan en evaluar las posibilidades de una tecnología y su retorno posible. Las tecnologías disruptivas se caracterizan, por un lado, por ser apuestas inciertas y, por otro, por que habitualmente debutan con unas prestaciones inferiores a las tecnologías que podrían sustituir.

Así las cosas, la decisión racional y de buena gestión parece ser desestimarlas y no apostar por ellas. 

Y ese es el error, porque cuando esas tecnologías disruptivas evolucionan y demuestran su verdadera capacidad, la empresa que no apostó por ellas, probablemente se quede fuera del mercado.

Los tres dilemas del innovador de Google frente a la IA

En el libro que indicaba más arriba, 'The Infinity Machine: Demis Hassabis, DeepMind and the Quest for Superintelligence' de Sebastian Mallaby, en un momento dado habla abiertamente del dilema del innovador de Google frente a la IA. Para ser más exactos, no habla de un dilema del innovador sino de tres dilemas que lo que describen realmente son tres motivos por los que, en su momento, la adopción de la IA podría perjudicar a su negocio principal. Son los siguientes:

• El dominio de Google en las búsquedas dependía (y depende) de su reputación a la hora de ofrecer información fiable. Por tanto, no podía permitirse lanzar chatbots que dieran información errónea. Y, como sabemos, y especialmente al principio, los chatbots 'alucinaban' con cierta frecuencia.


• Los ingresos de Google depeden de la publicación de anuncios junto a los resultados de búsqueda. No estaba claro, en realidad sigue sin estarlo del todo, cómo se podrían integrar los anuncios en el chat, cómo monetizarlo y cómo seguir manteniendo la posición privilegiada de Google en este campo. Eso tendía a obligar a Google a evitar los chatbots.


• La enorme cuota de mercado de Google, percibida en ocasiones como un monopolio ilegal, se volvería insostenible si la empresa se ganara la antipatía de políticos, periodistas y anunciantes... y se percibía que, eventualmente, podría pasar apostando fuerte por la IA y chatbots basados en ella.

Estos son los tres motivos que, siguiendo a Mallaby, han paralizado a Google, al menos hasta cierto punto y en los dos primeros años tras ChatGPT, y que le han impedido, insisto que capacidad técnica aparte, dar poco más que una respuesta tibia al empuje de OpenAI.

¿Son esto realmente dilemas del innovador?

Los anteriores son motivos que, acertados o no, son razonables para esa cierta parálisis, o al menos lentitud de respuesta de Google ante el empuje de otros actores, muy especialmente OpenAI.

Sin embargo, estrictamente hablando, no creo que se puedan calificar exactamente de un dilema del innovador. Y creo que no porque no se trata de que Google no haya identificado a la IA como una tecnología a la vez valiosa y disruptiva (el verdadero dilema del innovador), sino que una posición, acertada o no, de proteger su negocio tradicional, le ha hecho 'no empujar', no asumir el liderazgo de la IA y dejar ese liderazgo en manos de otros actores, al menos temporalmente.

Si hago caso al libro mencionado, más allá de la posición estratégica, acertada o no, y al contrario de lo que era mi hipótesis, realmente el liderazgo técnico tampoco ha estado durante un tiempo en manos de Google, pese a ser los creadores del mecanismo de la 'atencion' y la arquitectura 'transformer' que han revolucionado toda la IA generativa.

Esto último, sí parece haber cambiado ya en el momento en que escribo estas líneas, momento en que no parece que Google esté por detrás de los otros grandes actores de la IA. Ahora mismo seguramente está más o menos a la par, aunque también es cierto que ya no sólo hablamos de OpenAI, siendo ahora mismo un rival igual de potente, Anthropic y, quien sabe si los modelos de pesos abiertos.

Conclusiones

Aparentemente, hay motivos tanto estratégicos como técnicos que explican por qué Google ha estado algo lento a la hora de responder la agresiva propuesta de Open AI. 

Y, en la parte más estratégica y de negocio, sus precauciones tienen que ver con la protección de su negocio tradicional, algo que, sin ser en mi opinión exactamente lo mismo que el famosos dilema del innovador de Christensen, si guarda algunas semejanzas.

Actualización de publicaciones del Project Management Institute (III): "PMBOK Guide 8th edition"

Y con este post cierro la pequeña serie de artículos, tres incluyendo éste, dedicados a las últimas publicaciones del PMI ('Project Management Institute').

Tras haber comentado el estándar para gestión de proyectos y el estándar específico de inteligencia artificial, llega el momento del 'documento estrella' del PMI, es decir, el PMBOK ('Project Management Book Of Knowledge') o, como el PMI puntualiza la guía al PMBOK. 

El contenido del PMBOK

En esta octava edición, el PMBOK (documento de unas 270 páginas), se estructura en cinco capítulos y cinco apéndices. Los capítulos son:

• 1. Introduction: Un breve introducción explicando la estructura del documento, la relación con el estándar y los principales cambios respecto a la edición anterior


• 2. Project Management Performance Domain El capítulo más largo y que aporta mayor estructura y conceptos, describe los denominados 'performance domains' (algo así como dominios de desempeño) que, aunque quieren evitar el nombre, son una especie de procesos de alto nivel. Los dominios son:
  
  
  • Gobernanza ('Governance')
  • Alcance ('scope')
  • Planificación ('schedule')
  • Finanzas
  • Interesados ('stakeholders')
  • Recursos ('resources')
  • Riesgos
  
  
  Por cada uno de estos dominios, y salvo en el caso de la gobernanza en que añade alguna sección adicional, las estructura del discurso es siempre la misma:
  
  
  • Conceptos principales que, en esencia, aporta definiciones más o menos explicadas, de los conceptos utilizados
  
  
  • Procesos que componen el dominio indicando, aparte de la estructura general de procesos, un cierto detalle de cada proceso en que, aparte de una explicación se esquematiza sus entradas y salidas, y las herramientas y técnicas habitualmente utilizadas. Tantos las entradas y salidas como las herramientas y técnicas sólo se encuentra enunciadas porque la explicación se proporciona en otros capítulos
  
  
  • Consideraciones sobre personalización
  
  
  • Interacción con otros dominios
  
  
  • 'Checklist' de comprobación de resultados ('outcomes').


• 3. Tailoring Un capítulo no muy largo sobre la personalización / adaptación del marco general a casos concretos donde se argumenta el por qué de esa adaptación, se identifica qué elementos de adaptan y se describe un poco ese proceso de adaptación / personalización.


• 4. Inputs and outputs Describe todas y cada una de las entradas o salidas que han aparecido en los procesos de los dominios vistos en el capítulo dos. Se trata del orden de cien entradas y o salidas, descritas siguiendo un orden meramente alfabético y aportándose en la mayoría de los casos poco mas que una definición aunque en ciertos casos se detiene bastante más.


• 5. Tools and techniques De forma muy similar a lo hecho con entradas y salidas, se censan por orden alfabético, todas las herramientas y técnicas que han aparecido en los procesos de los dominios. En este caso hablamos de una ciento setenta herramientas o técnicas. La descripción de cada una, de nuevo, es irregular, siendo en algunos caso meras definiciones pero, para otras, se aporta bastante detalle.

Tras esto, tenemos cinco apéndices:

• El primero con el listado de personas que han participado


• El segundo, de un cierto interés se ocupa de las PMO ('Project Management Office')


• El tercero habla de inteligencia artificial pero sin grandes aportaciones y supongo que preparando el terreno para lo que sería el estándar que hemos comentado en otro post.


• Un cuarto apéndice, muy bien desarrollado e interesante sobre 'procurement' que, quizá, debería haberse encajado de alguna forma en el cuerpo principal del PMBOK


• Finalmente una descripción de cómo ha ido evolucionando el PMBOK a lo largo del tiempo.

Mi valoración

Creo que la mayor diferencia de esta edición (la octava) frente a la séptima edición (que, sinceramente, creo que era muy floja) son los dos capítulos dedicados tanto a entradas y salidas como, sobre todo, el de técnicas y herramientas.

Estos dos nuevos capítulos que, en el fondo, son un complemento a la descripción de los procesos del capítulo segundo dedicado a los dominios de desempeño, aportan valor, información y rigor y recuperan parte de lo que se perdió con esa creo que desgraciada séptima edición del PMBOK.

Aunque  no he hecho una comparación rigurosa, creo que, aún, la primera edición del PMBOK que yo conocí (la que estaba vigente cuando me certifiqué como PMP), la quinta y probablemente la sexta eran más sólidas y estructuradas, pero aún así, esta octava edición reconcilia un tanto con el PMBOK y recupera parte de lo perdido en la séptima edición.

No obstante, sigo sin entender, o tal vez compartir, la diferenciación entre el estándar y el PMBOK que creo que no tiene sentido tal y como está planteada actualmente.

 Igualmente, y de cara a futuras ediciones, creo que sería bueno seguir profundizando en la parte de entradas y salidas y las técnicas y herramientas, alargando más las descripciones y entrando más en materia porque gran parte del conocimiento real y práctico de la disciplina de dirección de proyectos recae en ellas.

Conclusiones

Hemos revisado el contenido del PMKOK (guía del PMBOK realmente) en su octava edición y, aunque creo que tiene margen de mejora, recupera una parte importante del rigor y profundidad perdidos en la séptima edición.

Artículos de este blog relacionados

• Actualización de publicaciones del Project Management Institute (II): "The standard for artificial intelligence"
• Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

La inteligencia artificial y las heridas del antropocentrismo y narcisismo humano

El ser humano siempre ha sido, hay que reconocerlo, antropocéntrico, es decir, de alguna forma se ha visto a sí mismo como  centro y medida de todas las cosas...quizá con la única excepción de la relevancia que ha dado a lo largo de los siglos, a las diferentes formas de dioses y deidades (aunque algunas, en el fondo, también adopten formas muy humanas).

Esa concepción de que todo giraba alrededor del ser humano, ha recibido, con el avance de la ciencia y el conocimiento, algunas sacudidas no menores, algunas 'curas de humildad' que, poco a poco van poniendo a la humanidad en 'su sitio'.

No por ello dejamos, en el fondo, de defender la dignidad y singularidad humanas pero, quizá, con algo más de modestia y comedimiento,

Las tres heridas identificadas por Freud

Me encuentro leyendo el libro 'Pensar con Prompts: Una crítica de la razón generativa' nominalmente firmado por Jianwei Xun aunque, en el fondo, quien nos habla es el filósofo italiano Andrea Colamedici, eso sí, asistido por, y en permanente diálogo con, la inteligencia artificial.  

El caso es que, en un punto de su libro, en concreto en el segundo capítulo, nos habla de lo que denomina las heridas del narcisismo humano, que no  dejan de ser las grandes tomas de conciencia por parte del ser humano que le hacen comprender que no es tan nuclear como había creído.

En concreto nos dice que ya Sigmund Freud identificó tres de esas heridas, a saber:

• Herida cosmológica: de la mano de Copérnico que demostró que los humanos no ocupan el centro físico del universo.


• Herida biológica: con la teoría de la evolución y la selección natural de Darwin, quien muestra que la especie humana no está separada de ni es superior al resto del mundo animal.


• Herida psicológica propinada por el propio Freud que afirma que el ego, el yo, no es dueño de sí mismo.

Tres duros golpes, claro está, a esa visión tan centrada en el ser humano y tan convencida de su propia importancia y centralidad. 

La inteligencia artificial como cuarta herida

Pero de la misma forma que, imagino, Freud enumeró las heridas cosmológica y biológica para enmarcar y resaltar 'su propia herida', la psicológica, Colamedici trae a colación las tres heridas históricamente precedentes para identificar una cuarta, que es su aportación a esa visión menos antropocéntrica.

Colamedici, trasunto en Jianwei Xun, entiende que la  inteligencia artificial y, en concreto, la inteligencia artificial generativa, puede ser una cuarta herida ya que saca al ser humano del centro, o al menos de la exclusividad del conocimiento o el arte.

Nos dice:

A estas tres se ha añadido una cuarta, mucho más reciente, que socava otro pilar de la identidad: la singularidad y superioridad de nuestra inteligencia. Con la IA generativa, ya no se da por sentado que solo el ser humano produce conocimiento, conceptos, arte o cosmovisiones.

Colamedici no le da este nombre pero voy a bautizar a esta eventual cuarta herida como la herida cognitiva.

¿Es este realmente un golpe tan grande a nuestro 'orgullo', a nuestra propia importancia y a nuestra visión antropocéntrica?

Consideraciones: puede que herida...pero quizá algo menos

De que nos encontramos ante un fenómeno transformador en muchos sentidos, me cabe poca duda. 

Sin embargo creo que esta eventual cuarta herida no es del todo comparable a las tres anteriores que identificaba Freud. 

Y ello, por dos motivos: lo vemos como menos herida y no ataca del todo el antropocentrismo

Menos herida

El primero es quizá más superficial, pero cuestiona el propio término 'herida'.

No soy un experto ni en historia ni en antropología y, por supuesto, no puedo saber qué pensaban las personas corrientes de estos avances científicos devenidos en herida al narcisismo humano. Pero creo que, de alguna forma, sí supusieron un golpe muy duro a la propia concepción humana, que debieron ser difíciles de admitir, de asimilar, de normalizar.

En el caso de la inteligencia artificial generativa, sin embargo, creo que, sin negar que existen preocupaciones, perplejidades y debates, el común de los mortales la acogemos con naturalidad, casi diría que con alegría y ligereza... con lo bueno y malo que eso tiene (creo que, en efecto, esa alegre y despreocupada acogida tiene cara positiva y negativa).

Es decir, no me parece que la inteligencia artificial generativa la estemos viviendo como un cuestionamiento tan doloroso y radical del ser humano y su papel en el mundo, como en su momento creo que sí ocurrió con las anteriores.

Quizá no sea tan herida, o se trata de una herida más superficial.

No tan en contra del antropocentrismo

 

Hay otra segunda diferencia que considero muy importante.

En las tres heridas que identificaba Freud, los avances científicos nos hicieron comprender que nuestra situación en el mundo no era tan central como creíamos, nos demostraron que las cosas eran diferentes a cómo pensábamos. Pero 'se limitaron' a hacernos comprender, no cambiaron nada ni crearon nada.

Es diferente en el caso de la inteligencia artificial generativa que, como cualquier tecnología es obra del ser humano. Por decirlo de alguna forma: no estamos comprendiendo, sino que estamos creando; no estamos entendiendo, sino que estamos transformando.

Y aunque nuestra propia obra nos desafíe y cuestione, en el fondo es sigue siendo obra nuestra y, por tanto, puede que nos nos quite centralidad sino todo lo contrario, que la potencie... siempre que permanezca bajo nuestro control, claro.

Conclusiones

A lo largo de la historia, la visión antropocéntrica del mundo se ha ido poco a poco desmoronando a medida que los avances científicos nos han ido demostrando que la realidad era diferente a la que pensábamos y que el ser humano no jugaba un papel tan central en esa realidad.

El filósofo Andrea Colamedici piensa que la inteligencia artificial generativa puede ser la cuarta herida a ese antropocentrismo o, como él lo expresa, a ese narcisismo humano, tras la cosmológica, la biológica y la psicológica.

Sin embargo, la inteligencia artificial generativa presenta características que hacen que, quizá, no se trate de una herida similar, puede que ni siquiera constituya una herida,

Actualización de publicaciones del Project Management Institute (II): "The standard for artificial intelligence"

En este breve recorrido por tres documentos recientes y relevantes emitidos por el PMI ('Project Management Institute'), le llega el momento a un documento, un estándar, dedicado al campo de la inteligencia artificial. 

El nombre del documento es 'The Standard for Artificial Intelligence in Portfolio, Program, and Project Management' y es de muy reciente publicación, en concreto de Junio de 2026, así que, en el momento de redactar este post, no tiene ni dos meses de vida.

Se trata de un estándar que me generó mucho interés porque une una de mis áreas de investigación de mayor interés, la inteligencia artificial, con un área de 'expertise' en gestión como es la dirección de proyectos y porque me parecía importante ver qué tenía que decir la mayor autoridad en dirección de proyectos sobre el caso concreto de la inteligencia artificial

¿Qué me he encontrado?

El contenido del "Standard for Artificial Intelligence in Portfolio, Program, and Project Management"

Nos encontramos ante un documento de mediana extensión, cercana a las 300 páginas.

Antes de ver un poco el contenido, alguna tema relevante a tener en cuenta.

Aunque personalmente tiendo a hablar de forma un poco genérica de dirección de proyectos, en este documento, y siguiendo el modelo del PMI, se distingue entre proyectos, programas y porfolios y, en varios puntos del estándar, la distinción es nítida.

El estándar distingue, y me parece un acierto, entre la IA como producto, como resultado de proyectos, programas y porfolios y la IA como una herramienta utilizable en la propia dirección de proyectos, programas y porfolios. 

Dicho esto, el contenido del documento se estructura en siete capítulos, a saber:

• 'Introduction:' Una introducción al contenido e intenciones del estándar junto con algún recordatorio de conceptos sobre dirección de proyectos y sobre inteligencia artificial.


• 'Principles of AI in Project, Program and Porfolio Management:' De la misma forma que el estándar para dirección de proyectos, programas y porfolios establece seis principios, aquí se establecen ocho principios que, aunque se parecen, no son los mismos que los generales. Sin entrar en detalles, sólo señalar cuáles son los principios para el caso de proyectos en materia de inteligencia artificial:
  
  
  • Valor estratégico: es decir, foco en la creación de valor.
  • Riesgo: que enfatiza la necesidad de supervisión humana.
  • Gobernanza y cumplimiento normativo: orientado por un lado al alineamiento estratégico y, por otro, al respeto a la legislación y a los principios éticos.
  • Personas y cultura: desglosando entre liderazgo y el equipo de proyecto.
  • Ética y responsabilidad profesional: con foco fundamentalmente en la supervisión humana y en la responsabilidad en el sentido de rendición de cuentas.
  • Involucración de partes interesadas ('stakeholder engagement'): alineando los proyectos con las expectativas de esas partes interesadas.
  • Optimización e innovación: anima a la adopción de nuevas tecnologías y metodologías para conseguir mayor eficiencia, adaptación y calidad.
  • Calidad del dato: como mecanismo para conseguir resultados de calidad, a su vez.


• 'Performance Domains of AI in Project, Program and Porfolio Management:' Establece cinco dominios ('performance domains') que se asemejan, pero no coinciden, con los dominios identificados en el PMBOK, del que hablaremos en otro post. Los dominios para el caso de la IA serían, según este estándar, los siguientes:
  
  
  • Gestionar las expectativas de las partes interesadas sobre la IA
  • Definir el alcance de la IA
  • Definir una arquitectura IA con calidad y responsabilidad
  • Ejecutar objetivos estratégicos
  • Gestionar riesgos e incertidumbres


• 'Life Cycle management and tailoring activities:' Revisa muy brevemente los ciclos de vida predictivos, adaptativos e híbrido y su traslado a proyectos de IA y luego trata tanto las actividades de personalización ('tailoring') como de ciclo de vida y optimización distinguiendo en ambos casos entre proyectos, programas y porfolios.


• 'AI in the context of Project, Program and Porfolio Management:' hace el cambio de perspectiva a la aplicación de la IA no como producto sino en la propia actividad de dirección de proyectos, programas y porfolios aportando alguna idea sobre cómo usarla


• 'Framework for the use of AI in Project, Program and Porfolio Management:' Aporta un marco con unos pasos y consideraciones a tener en cuenta en la dirección de proyectos, programas y porfolios, centrándose en cuatro áreas: establecimiento de un caso de negocio, uso de la IA en proyectos, programas y porfolios, flujo de información y ajuste cultural y organizativo.


• 'Ethical and Legal considerations for AI use in Projects, Programs and Porfolios:' realiza alguna propuesta en los ámbitos ético y legal, como la existencia de un comité ético

En dos anexos finales identifica, por un lado, algunos esquema de evaluación de la madurez en IA y, por otro, leyes y regulaciones a tener en cuenta. 

Mi valoración

Siendo sincero, debo reconocer que este estándar me ha decepcionado y que soy bastante crítico con él.

Antes de la crítica, decir que me parece bueno que exista este estándar, o al menos una guía en este campo, por parte del PMI, y que me parece acertada la distinción entre la IA como producto de proyectos y el uso de la IA para la propia dirección de proyectos, programas y porfolios.

Pero mi visión positiva casi se acaba aquí y en seguida comienza mi crítica.

En primer lugar, y como ya expresé a propósito del "Standard for project management", esto no me parece un estándar, por más que se encuentre respaldado por ANSI. No es prescriptivo, no es asertivo, no es demasiado accionable y no es claramente certificable. En mi opinión, es más una guía o un marco de trabajo, pero no un estándar, que ANSI y el PMI me perdonen.

Por otro lado, y casi como extensión de lo anterior, lo veo muy ligero, de muy alto nivel, muy de intenciones o ideas, pero de poco detalle y 'accionabilidad'.

Creo que no es demasiado acertado al tratar de forma genérica los proyectos de inteligencia artificial sin distinciones nítidas de tipologías. En mi opinión tiene poco que ver, a nivel de ciclo de vida y gestión, un proyecto de machine learning tradicional como la creación de un modelo predictivo personalizado para una empresa, con el desarrollo de un agente, por ejemplo. 

Me sorprende, y me parece incoherente, que los principios y dominios que se identifican en este supuesto estándar sobre IA, sean diferentes, en lugar de ser una particularización, de los genéricos de dirección de proyectos identificados en el estándar de dirección de proyectos, o los dominios identificados en el PMBOK. Eso es tanto como decir que los principios y dominios genéricos no son tan genéricos, sino que diferentes tipologías de proyectos pueden necesitar principios y dominios diferentes y cuestionar los genéricos.  Como mucho, podría entender que se añada alguno principio o dominio nuevo, pero no que se redefinan todos. No tiene sentido.

También me parece incoherente que si en el caso de la documentación general del PMI, los principios se encuentran en el estándar de proyectos y los dominios y la personalización ('tailoring') en el PMBOK, aquí, en el caso de la IA, todo quepa en el estándar.

En fin, que me ha resultado bastante decepcionante.

Conclusiones

Entre los documentos más recientes lanzados por el PMI se encuentra el estándar para proyectos, programas y porfolios de inteligencia artificial.

Una, en mi opinión, buena iniciativa pero con un resultado, también en mi opinión, criticable y bastante decepcionante.

Artículos de este blog relacionados

• Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Capacidades cognitivas frente a la IA: aprendizaje versus producción

La inteligencia artificial trae consigo enormes posibilidades. Es una tecnología polivalente, transversal, disruptiva en ocasiones e, incluso, muchas veces divertida.

Pero también nos desafía en muchos sentidos y, en algunos, incluso nos puede preocupar.

 

La IA y el problema de las capacidades cognitivas

Uno de esos posibles elementos de preocupación es cómo puede afectar el uso intensivo de la IA el desarrollo (o atrofia) de nuestras capacidades cognitivas y, muy específicamente, cómo afecta al aprendizaje de conocimientos y habilidades mentales.

Carátula del episodio

Se trata de un tema en el que pienso con cierta frecuencia y que he reflejado en varios de los canales de comunicación que utilizo. Sin ir más lejos, el 22 de Julio, el día anterior a en el que esto escribo, publicaba en el podcast 'Caminos de Knowmad' en que colaboro, un episodio titulado, significativamente, 'Cuidar nuestras capacidades cognitivas en tiempos de IA' en que analizo esta problemática desde la perspectiva de un profesional del conocimiento, y traslado algunas ideas y opiniones.

El temor es, en esencia, que si nos acostumbramos a delegar tareas en la IA, si no ejercemos nuestras propias capacidades cognitivas (memoria, comprensión, análisis, planificación, resolución de problemas, etc) porque la IA nos da la tarea hecha, no desarrollemos esas capacidades o, si ya las poseíamos, se puedan ir 'atrofiando' de alguna manera por 'falta de uso'.

En este caso, la neuroplasticidad del cerebro correría en nuestra contra porque el cerebro se acostumbraría a no usar ciertas capacidades y, al 'considerarlas inútiles' las iría, de alguna manera, borrando.

El caso del aprendizaje

Y el problema se agudiza cuando estamos hablando, no sólo de conservar capacidades cognitivas, sino del aprendizaje: de la adquisición de conocimientos y habilidades, y del propio desarrollo de esas capacidades cognitivas.

Este tema lo abordé también en mi podcast personal 'Divergencias', en el episodio que publiqué en Enero de este año y que titulaba 'Facilidad y aprendizaje: un posible impacto cognitivo de la IA' y que, si lo deseas, puedes ver en su versión video abajo.

En este episodio, razono como el 'hacer', cómo el intentar realizar nosotros mismos el trabajo intelectual, el memorizar, razonar, resolver problemas, escribir, etc es importantísimo para el aprendizaje. Incluso si la IA nos proporciona el mismo resultado que nosotros hubiéramos producido e, incluso si leemos atentamente esos resultados, el aprendizaje no es igual en absoluto.

Menciono cómo, la estrategia pedagógica conocida como 'learning by doing' se basa, precisamente, en el reconocimiento de lo importante que es una actitud activa, de práctica, en el aprendizaje.

La doble apuesta

Siempre que trato este tema, mi propuesta es, de alguna forma, lo que llamo la 'doble apuesta'.

En esa doble apuesta, por un lado, invito a reconocer la potencia y utilidad de la inteligencia artificial y la casi obligatoriedad hoy en día de dominarla para ser unos profesionales valiosos, relevantes y empleables. Y animo, claro, a su conocimiento y uso intensivo.

Pero, por otro lado, urjo a todos los profesionales, a todos los jóvenes y, en realidad, a todas las personas, a que cuiden su aprendizaje y desarrollo cognitivo, prescindiendo en ocasiones de la IA (en los temas que más te importan o que son de puro aprendizaje o estudio) y realizando actividades paralelas complementarias como la lectura, la escritura, el debate o el estudio tradicional, incluso el denostado aprendizaje memorístico.

Modos aprendizaje y modo producción

Hace pocas semanas finalicé la lectura del libro 'Nosotros, digitales' de Javier Lorente y me pareció interesante la forma en que él estructura un poco este mismo problema.

Javier se centra, específicamente, en el caso de la educación y describe el problema de la siguiente forma

Si utilizamos máquinas para acelerar la generación de productos intelectuales, dejamos de desarrollar las capacidades naturales y tendremos que buscar espacios para ejercitarlas de forma artificial, como hacen con su cuerpo los que frecuentan un gimnasio.

Nos habla de distinguir dos modos. Por un lado un modo producción en que lo que buscamos son resultados y eficiencia y, en ese sentido, la IA es una gran ayuda, hoy en día casi imprescindible. Y, por otro lado, un modo aprendizaje, en que  lo que importa no es producir, sino adquirir conocimientos y desarrollar capacidades intelectuales y, en ese caso, aunque sea menos eficaz, debemos esforzarnos en hacer las cosas por nosotros mismos.

Y para ilustrarlo utiliza el ejemplo del deporte y del entrenamiento, siendo el aprendizaje el equivalente al entrenamiento.

En realidad, Javier hablar de un tercer modo, creación, en que, digamos, 'damos libertad', a nuestro cerebro para que vague libremente recombinando conocimientos e ideas.

La realización y el disfrute

Quisiera añadir un punto adicional, que en alguna ocasión también he mencionado en algún medio y que tiene que ver con aquello que disfrutamos haciendo, aquello en que el propio proceso nos es altamente satisfactorio y que, por tanto, no deberíamos ceder a la IA salvo, puntualmente, cuando nos apriete la necesidad de resultados.

En mi caso, por ejemplo, me gusta mucho escribir, escribir en muchos formatos incluyendo, entre otros, éste que recibes: un artículo de blog. Automatizar con inteligencia artificial la generación de artículos para un blog es algo bastante sencillo y que podría y sabría hacer sin problemas e, incluso, me ayudaría a aumentar mi ritmo de publicación. Pero es que, simplemente, no quiero hacer con inteligencia artificial los posts de 'Blue Chip'.

No quiero, sobre todo, porque disfruto escribiéndolos.

No quiero porque, además, en el fondo es otra forma de aprendizaje, porque escribir te obliga a pensar y, sobre todo, estructurar lo que has pensado, y eso no deja de ser una forma de aprendizaje y desarrollo cognitivo. Y te obliga, en ocasiones, a buscar alguna información o aclarar algún punto... y eso también es aprendizaje.

Y no quiero finalmente, porque, en el fondo, a pesar de la potencia de la IA y a pesar, incluso, de su capacidad de personalización y adaptación a un estilo, en este caso el mío, creo que al final tú, lector, acabarías percibiendo una cierta 'despersonalización', una cierta falta de originalidad, una especie de impostura en el mensaje.

Y no quiero, simplemente no quiero.

Conclusiones

La IA es una tecnología potente, tremendamente útil, y casi imprescindible hoy en día en el arsenal de cualquier profesional. Sin embargo, el uso excesivo y, sobre todo, la delegación exagerada de tareas en la IA sin esfuerzo o reflexión por nuestra parte, puede acabar afectando a nuestras capacidades cognitivas o puede eliminar nuestro aprendizaje.

Parecen, pues, necesario, desarrollar y aplicar estrategias de trabajo y aprendizaje en que tengamos espacio para nosotros, para hacer nosotros el trabajo intelectual. En este sentido, puede ser útil como marco conceptual, la distinción entre los modos de aprendizaje y producción que nos propone Javier Lorente.

Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Con este post inicio una serie corta de tres artículos (que probablemente se intercalen con posts de temáticas completamente diferentes) en que comentaré y valoraré brevemente algunas de las últimas publicaciones del PMI ('Project Management Institute'), la probablemente autoridad más reconocida a nivel mundial en materia de dirección de proyectos. 

En ellos, uno en cada post, comentaré brevemente tres documentos, a saber:

• The standard for project management (ANSI/PMI 99-001-2025)
• A guide to the Project Management Book Of Knowledge. PMBOK Guide. 8th edition.
• The Standard for Artificial Intelligence in Portfolio, Program, and Project Management

Antes de los breves comentarios, una pequeña explicación acerca de mis motivaciones.

Motivaciones: la importancia de los proyectos y el PMP

Hasta que en 2018 inicié mi andadura profesional por cuenta propia bajo mi marca 'Reingeniería digital', una parte muy importante de mi carrera ha estado dedicada de una forma u otra a proyectos.

He formado parte de equipos de proyecto, he actuado como jefe de proyecto y director de proyecto de iniciativas de todo tipo, algunas sencillas pero otras muy ambiciosas y de alto presupuesto, y he dirigido equipos que, a su vez, dirigían proyectos.

Y cada vez más fui apreciando la disciplina de la dirección de proyectos y, aún más, la figura del jefe de proyecto. Esta importancia se me hizo especialmente patente cuando los proyectos a que nos dedicábamos estaban dirigidos a clientes pertenecientes a las grandes cuentas de Telefónica Empresas, donde se encontraban la mayor parte de empresas del IBEX y muchas otras empresas y administraciones de gran tamaño y presupuesto. Llegué al profundo convencimiento de lo importante que era la figura del jefe de proyecto para alcanzar el éxito y no me refiero sólo a la figura en sí como un rol abstracto, que también, sino a la cualificación y voluntad de las personas concretas que ejercían ese rol. La relación con el cliente y el éxito de los proyectos, dependían en buena medida de esa figura y de la persona que la ejerciese. 

En 2012, cuando ya realmente no ejercía como director de proyecto sino como gerente, decidí, a pesar de ello, obtener la certificación PMP ('Project Management Professional'), lo cual sucedió en Junio de 2012, hace ahora catorce años, a lo largo de los cuales, y como establece el PMI, he ido renovando esa certificación que aún tengo en vigor y que pienso volver a renovar el año que viene.

Cuando obtuve la certificación, el PMBOK vigente se encontraba en su quinta edición. Desde entonces he adquirido y estudiado las siguientes ediciones, la sexta, la séptima... y ahora le toca a la octava, publicada en Enero de 2025.

Además, me interesó mucho conocer, dado mi interés y dedicación a la inteligencia artificial, que PMI junto con ANSI, habían lanzado también un estándar para proyectos de inteligencia artificial.

La idea, pues, ha sido realizar una nueva actualización y, en este caso, además, compartir con los lectores de este blog un poco del contenido objetivo de los documentos, y otro poco de mi valoración personal. 

Explicado esto, vamos con el primero de los documentos, el 'Standard for project management'

El contenido del "Standard for Project management"

Este estándar ha sido definido mediante una colaboración entre el PMI ('Project Management Institute') y ANSI ('American National Standards Institute'), colaboración que se inició, si la memoria no me falla, con la anterior versión del PMBOK (la séptima).

Aunque se trata de un documento separado, se publica en el mismo volumen que el PMBOK, del cual hablaré en otro post de esta serie.

Según reza en el propio documento, este estándar

provides a basis for understanding project management and how it facilitates intended outcomes.

y, un poco más abajo, dice

The standard describes how project management creates value and benefits in organizations as well as how organizational and project leaders can harness the power of project management for success.

 

Como se pude deducir un poco de estas declaraciones de intenciones, y como insistiré en mi comentario personal, se trata de un documento más descriptivo que normativo.

El documento de poco más de setenta páginas  y se estructura en cuatro secciones:

• 'Introduction': Establece el propósito del estándar, proporciona un vocabulario de términos y conceptos y ataca algunos aspectos generales de los proyectos como sus características, conceptos de gobernanza, relación con las operaciones de la compañía y las relaciones entre los conceptos de proyecto, programa, porfolio y operaciones.


• 'System for value delivery': Extendiendo lo ya iniciado en la séptima edición, adopta una visión muy de alto nivel y negocio para hablarnos de cómo los proyectos aportan valor y se sitúan como parte de un sistema de valor. Propone un modelo para conceptualizar ese sistema de valor y a partir de ahí comenta elementos de contexto interno y externo a proyectos, programas y porfolios, establece la relación con el 'product management' e identifica una serie de funciones y roles presentes en los proyectos.


• 'Project management principles': Identifica y explica seis principios de la dirección de proyectos, a saber:
  • Adoptar una visión holística
  • Enfocarse en el valor
  • Introducir la calidad en los procesos y los entregables
  • Ejercer un liderazgo responsable
  • Integrar la sostenibilidad en todas las áreas de proyecto
  • Construir una cultura de empoderamiento


• 'Project Life Cycles': Habla de las fases de los proyectos y luego identifica los tres grandes enfoques para la dirección de proyectos (predictivo, adaptativo e híbrido) y proporciona criterios para seleccionar un enfoque u otro. También habla de la cadencia de las entregas, mencionando el despliegue continuo propio de DevOps (aunque sin mencionar a DevOps). Finaliza identificando y describiendo las que denomina cinco áreas de foco, a saber:
  • Inicio
  • Planificación
  • Ejecución
  • Monitorización y control
  • Cierre

Una valoración: ¿Esto es un estándar?

Este estándar es un documento correcto y bien redactado (aunque en el típico estilo profesional austero) y que proporciona un vocabulario y una especie de marco de referencia común, eso sí, un poco abstracto y de bastante alto nivel.

Me parece bueno, a nivel de una disciplina, establecer ese marco de referencia y ese vocabulario comunes y no me parece mal, tampoco, comenzar por un alto nivel para luego ir bajando.

Sin embargo, insisto, es muy alto nivel y en algunas partes un poco abstracto. Le falta mucho bajar a tierra, en mi opinión. si pretende orientar realmente la acción de las organizaciones y de los profesionales.

Y aunque esto sea enmendarle la plana nada más y nada menos que a ANSI, me resisto a ver este documento como un verdadero estándar, porque no detalla nada, no da pautas asertivas, no obliga a nada y no es muy verificable si se está aplicando o no.

La verdad es que esto no es lo que yo entiendo por un estándar.

Hace muchos años, en mis primeros tiempos en Telefónica, me miré muchas normas y estándares del ámbito de las telecomunicaciones, que definían, por ejemplo, protocolos y, desde luego, no tiene nada que ver con esto. Aquello era detalladísimo, normativo, verificable y, todo hay que decirlo, muy farragoso,

No he tenido mucha ocasión de leer directamente estándares o normas del ámbito industrial pero, hasta donde sé, son de nuevo, muy detalladas, muy concretas y completamente verificables en su cumplimiento.

Este documento, pues, lo veo como divulgativo, conceptual e introductorio pero, por mucho que lo firme ANSI, me resisto a verlo como un verdadero estándar.

Conclusiones

Inicio con este artículo, una breve serie de tres posts dedicados a documentos más o menos recientes emitidos por el PMI ('Project Management Institute')

En este primer post, comento brevemente el 'The Standard For Project Management', un documento conceptual y de alto nivel, que establece vocabulario y conceptos, pero que no entra en detalles y que me cuesta mucho verlo como un verdadero estándar.

Los agentes y el martillo de oro (III): soluciones híbridas y ecosistemas de agentes

Y con este post remato la pequeña serie dedicada a los agentes como martillos de oro. Y lo hago ofreciendo algunas soluciones intermedias o híbridas al problema planteado.

Pero vamos a ir poco a poco, recapitulando primero algunos conceptos y recordando la definición del problema.

Un paso atrás: los agentes de la Agentic AI

Damos, pues, un paso a atrás para recordar conceptos. Y lo primero es recordar de qué hablamos cuando hablamos de un agente. Y antes de hacerlo, insistir en que el término 'agente' se lleva utilizando desde hace décadas, e incluso siglos, y no sólo en tecnología. Así que, de los que hablamos son de los agentes de que hablamos bajo el paraguas de la Agentic AI.

Y se trata, como vimos, de programas construidos alrededor de un modelo de lenguaje razonador que son capaces de funcionar de manera autónoma, recibir sus tareas u objetivos mediante una especificación en lenguaje natural y, con base en sus capacidades razonadoras, decidir por sí mismos, y en tiempo de ejecución el plan a ejecutar para conseguir el objetivo. Un plan que puede ser revisado conforme avanza y se obtienen resultados intermedios, y un plan en cuyos diferentes pasos se puede incluir la selección y ejecución de una herramienta externa que le permite, entre otras cosas, interactuar con el mundo exterior.

Agentes versus workflows

Estructura de un agente

Estructura de un agente

Conforme a lo comentado, la estructura de alto nivel de un agente es la que se muestra en la figura. En el núcleo tenemos un modelo de lenguaje razonador y, como apoyo, una serie de herramientas con las que puede interactuar y que, aparte de alguna posibilidad adicional, fundamentalmente le ayudan a entrar en contacto con aplicaciones y recursos externos (una web, un sistema empresarial, el correo electrónico, etc)

En la figura dibujo a trazos la unión entre el modelo de lenguaje y las herramientas queriendo indicar que, según el plan generado, se invocan o no.

Estructura de un workflow

Y es importante comparar a estos agentes basados en modelos de lenguaje razonadores con otro tipo de soluciones anteriores que funcionan bajo un paradigma de reglas y, sobre todo flujos o workflows. Denomino genéricamente 'workflows' a ese tipo de soluciones que incluye, por ejemplo, los robots RPA ('Robotic Process Automation'), a los a veces denominados workflows en la nube o IPaaS (como Make, N8N o Zapier) e, incluso, forzando un poco, a los BPMS ('Business Process Management System') y los CMS ('Case Management System').

Estructura de un workflow

A alto nivel estas soluciones que agrupo bajo la etiqueta 'workflows' exhiben patrones estructurales muy similares entre sí, e incluso con los agentes.

En el caso de los workflows, el plan está predefinido en tiempo de desarrollo y adopta la forma de un flujo con sus pasos y, eventualmente, bifurcaciones y/o bucles. Y también pueden interactuar con aplicaciones y recursos exteriores, en este caso haciendo uso, habitualmente, de conectores que recubren un API generalmente de tipo REST.

Comparativa

En el fondo, estructuralmente hablando, se trata de soluciones muy similares. En la figura inferior, los ponemos frente a frente.

Comparativa Agente-Workflow

En esa figura, e intencionadamente, he eliminado la mención explícita a herramientas (en el caso de agentes) y a conectores (en el caso de workflows). ¿Por qué? Pues porque, a despecho de alguna diferencia en cuanto a la definición, y algunas variantes en cuanto a implementación, su rol es exactamente el mismo y, por tanto, de cara a la comparativa estructural prefiero que no se muestre ninguna diferencia.

La diferencia fundamental es que, en el caso de los agentes, el plan de acción se decide y revisa de forma dinámica en tiempo de ejecución por el propio agente, mientras que en los workflows el plan de acción se define en tiempo de desarrollo por el desarrollador humano y es estático. Esta diferencia es fundamental, tanto para lo bueno de los agentes, la flexibilidad, potencia e inteligencia de los agentes, como para lo malo de los agentes: incertidumbre y consumo computacional.

Sólo por apuntar alguna otra diferencia, se puede observar en la figura que, en el caso de los agentes, y como mencioné más arriba, dibujo con trazos la unión con los nodos herramienta, mientras que en los workflows esa flecha la dibujo con trazo continuo. Lo que esto trasmite es una consecuencia del dinamismo del plan de los agentes: a priori no podemos estar seguros de qué herramientas va a invocar ni de qué forma. En el caso de los workflows sí se sabe, porque está definido en el flujo.

Podríamos apuntar algunas otras diferencias de menor calado, pero prefiero quedarme con estas que son nucleares.

Aunque me preocupan un poco las connotaciones de la palabra 'determinismo' en el ámbito de la inteligencia artificial, diría, por expresarlo de una forma aún más compacta que:

Un agente es una solución muy flexible y potente pero no determinista, mientras que un workflow es una solución más rígida y acotada, pero determinista.

 

Estableciendo el enunciado del problema

Llegados hasta aquí, y antes de pasar a la soluciones que propongo, recordar cuál es el problema a que me refiero (y que puede que el lector identifique como tal o no).

Mi argumentación parte de la idea de que, al menos a nivel de discurso, parece que los agentes son la solución a cualquier problema, especialmente de automatización de tareas y procesos. Es decir, se considera a los agentes como un martillo de oro, capaz de soluciones cualquier problema que, por tanto, vemos siempre como un clavo. 

Salvo que alguien me demuestre lo contrario, creo que los agentes, al menos en su estado de arte actual, no deben ser la solución única, que todavía hay muchas tareas que se automatizan mejor mediante una solución más clásica basada en un workflow. 

En concreto, cuando la solución al problema la tengamos clara y sepamos claramente las reglas que la gobiernan, un workflow parece mejor solución que un agente, por los siguientes motivos:

• Dado que un workflow es determinista, es mucho más sencillo de probar y, una vez probado, garantiza un comportamiento correcto, conocido y reproducible, cosa que en un agente nunca podemos estar 100% seguros.


• El coste computacional de ejecutar un agente, para una tarea similar, es muchísimo más alto que el de la misma tarea ejecutada por un workflow


• Dado que el coste computacional es mucho más alto, el coste económico es también más elevado y, además, no del todo predecible (no podemos saber con seguridad los tokens que se necesitarán).


• Finalmente, ese coste computacional se traduce en consumo eléctrico y de refrigeración, incrementando la huella de carbono y el impacto medioambiental

El razonamiento es, pues, resumiendo, que aunque los agentes son de una potencia extraordinaria y nos abren unas grandísimas posibilidades, no siempre son la mejor solución, y por lo tanto, no debemos considerarlos martillos de oro, sino elegir en cada momento la solución de automatización más adecuada.

Algunas posibles soluciones intermedias e integradoras

La verdad es que, hasta aquí, casi que lo que he hecho es nada más que resumir e ilustrar, el contenido de los dos posts anteriores. Vamos ahora con algunas soluciones o planteamientos que se me ocurren. En concreto, y aunque es posible que existan otras soluciones, o que las que propongo se puedan combinar, voy a proponer cuatro opciones, a saber:

• Solución 0: seleccionar la solución caso a caso
• Solución 1: el modelo generador de workflows
• Solución 2: orquestadores
• Solución 3: ecosistemas híbridos

En lo que sigue, comento brevemente cada una.

Solución 0: seleccionar la solución caso a caso 

Esta solución le llamo solución 0, porque, en realidad, es casi trivial. 

Si se admite que no todos los problemas se resuelven mejor con un agente pues entonces, simplemente, antes de lanzarse a desarrollar un agente o un workflow decidir conscientemente y con criterio cuál es la solución adecuada para ese caso concreto

Solución 1: el modelo generador de workflows

La solución 1 consistiría en que el propio modelo razonador que genera el plan fuese capaz de detectar, por sí mismo o con asistencia humana, qué tipo de solución es mejor y si, al inicio de su resolución detecta que es un problema basado en reglas y resoluble mediante un flujo, simplemente que genere ese flujo.

Me parece perfectamente viable técnicamente puesto que casi todas las herramientas de tipo workflow expresan ese workflow mediante un lenguaje de marcado (tipo YAML) o mediante JSON, dos formatos que un modelo de lenguaje domina muy bien.

Eso sí, no eliminamos al 100% el no determinismo, puesto que el agente puede equivocarse y no darse cuenta de que un problema se resuelve mejor mediante workflow. Tampoco es óptimo computacionalmente, porque la propia decisión de si vale la pena crear un workflow, e incluso la creación del workflow propiamente dicho sigue usando los mecanismos propios de un modelo de lenguaje.

No es pues, creo, una solución absoluta, pero alivia el problema.

Solución 2: orquestadores

La siguiente solución se apoya en la idea de que la relación de agentes entre sí, y de workflows entre sí puede hacerse jerárquica e incluso recursiva. Es decir, un agente puede invocar a otro agente (que actúa como herramienta) y un flujo puede invocar a otro flujo (usando una especie de conector). 

Esta opción, que no sólo es viable, sino que ya hay plataformas que permiten su creación, es hacer automatizaciones en que exista un nodo orquestador, y otros nodos que realizan tareas. Y, para aquellas tareas en que la solución mejor sea un workflow, pues se utiliza un workflow y para aquellas en que la mejor solución sea un agente y es el orquestador quien lo decide. El esquema de esta opción se muestra en la figura.

Orquestadores

Se puede ver que, además, esta solución tiene una doble vertiente: que el orquestador sea un agente o que el orquestador sea un workflow. Además, y aunque en la figura se muestra que un agente sólo invoca workflows y un workflow sólo invoca agentes, en realidad, ya sea orquestado por un agente o por un workflow, los nodos que ejecutan las tareas pueden ser cualquier tipo.

Como digo, este tipo de esquemas ya se pueden hacer hoy en día, no sólo en código, sino en herramientas como Make.

Solución 3: el ecosistema híbrido

La solución 2 ya anticipa un poco lo que es la solución 3 (realmente es un caso particular de la solución 3).

La solución 3, el ecosistema, parte de concebir las automatizaciones como una interacción entre unos nodos que pueden ser agentes o workflows y que se combinan en interaccionan entre sí según la naturaleza del problema. Es lo que intento mostrar en la siguiente figura: 

Ecosistemas de agentes, con workflows como forma de agente

Es una solución muy similar a la del orquestador pero sin que haya nodos con ese rol especial, sino que interactúen en un esquema más P2P. En el fondo, esta solución se basa en la idea de los ecosistemas de agentes, pero reconociendo a los workflows también como agentes.

Para que está solución sea óptima, como en el fondo también en el caso anterior, ha de cumplirse que cuando el orquestador seleccione un nodo para delegar una tarea, o cuando un agente del ecosistema delegue en otro la ejecución de una tarea, se 'acierte' siempre, en el sentido de identificar siempre cuándo una tarea se resuelve mejor mediante un workflow.

No voy a profundizar más en ello, pero se me ocurre que sino conseguimos que un modelo de lenguaje acierte siempre en la elección de workflows, se le 'podría ayudar' mediante alguna forma de catálogo de tareas que se resuelven mejor mediante workflows.

Algún pequeño 'disclaimer'

Antes de cerrar este post, hacer algún pequeño 'disclaimer'.

El primero es que las propuestas que hago no dejan de ser eso, propuestas, hechas un poco 'a bote pronto', aunque es un tema al que le doy vueltas con cierta frecuencia últimamente.

Por otro lado, ni reclamo ni dejo de reclamar la 'autoría' u originalidad de estas propuestas. No renuncio a esa supuesta 'autoría' u 'originalidad', porque es fruto de mi propia reflexión, no es nada que haya visto en ningún sitio salvo, hasta cierto punto, la idea del orquestador. Pero tampoco me atrevo a reclamar la autoría y, sobre todo, originalidad, porque me cuesta pensar que no haya ya mucho pensado e incluso escrito sobre estos temas y que existan propuestas, implementadas y/o publicadas, iguales o muy parecidas a las que hago..

Finalmente, apostaría a que hay más soluciones que yo no he planteado aquí y puede que mejores... así que me encantará o bien descubrir en alguna publicación o bien que se me ocurran a mi en un proceso de indagación y reflexión.

Conclusiones

El considerar a los agentes como martillos de oro, como la única solución para todos los problemas fundamentalmente de automatización, puede ser un error, ya que existen soluciones, especialmente las basadas en workflows, eventualmente más adecuadas y, además, más seguras, eficientes, baratas y sostenibles.

En este post, tras, revisar conceptos y la naturaleza del problema, se proponen cuatro estrategias de solución híbridas.

Artículos de este blog relacionados

• Los agentes y el martillo de oro (II): agentes y medio ambiente
• Los agentes y el martillo de oro (I): ¿por qué no un workflow?

Los agentes y el martillo de oro (II): agentes y medio ambiente

Con este post continuo la breve serie que quería dedicar a un eventual uso irreflexivo de los agentes, un uso que no se detiene a considerar que en ciertos casos existen  mejores alternativas. Es decir, continuo la serie dedicada a considerar a los agentes como un martillo de oro, la solución para cualquier problema que pasa a ser siempre un clavo. 

Si en el post anterior reflexionaba sobre si no es mejor, desde un punto de vista fundamentalmente técnico y operativo,  usar en ciertos casos soluciones basadas en reglas o workflows mejor que un agente, en este artículo torno mi mirada hacia la sostenibilidad y el impacto medioambiental.

Agentes 101

Antes, recordar brevemente, una vez más, qué es esto de los agentes y de la Agentic AI (aquellos lectores que lo tengan claro pueden saltarse esta breve sección)

Los agentes de la agentic AI, son unos programas construidos alrededor de un gran modelo de lenguaje razonador. Unos programas que son capaces de funcionar de manera autónoma buscando realizar tareas eventualmente complejas o satisfacer objetivos que reciben expresados en lenguaje natural. 

Además son capaces de usar una serie de elementos, denominados herramientas, que les permiten realizar tareas especializadas y, sobre todo, interactuar con el exterior, típicamente con otras aplicaciones.

Y, de manera muy relevante y diferencial, esos agentes, definen ellos mismos el plan de acción a aplicar para realizar la tarea o alcanzar el objetivo encomendado. Y para definir ese plan de acción, utilizan ese modelo de lenguaje razonador. Además, estos planes de acción son dinámicos y se revisan 'en vuelo' según los resultados parciales que el agente vaya obteniendo.

El precio del razonamiento

No sólo es diferencial, es que también es tremendamente atractivo y potente que el agente sea capaz de 'pensar', crear y revisar el plan de acción. Es como un alarde de inteligencia y permite que le encomendemos tareas complejas o, incluso, tareas que nosotros no sabemos resolver.

Pero esa potencia, esa brillantez, tiene un precio en forma de consumo computacional. Si el uso de cualquier modelo de lenguaje, incluso para una tarea simple como completar un texto, es costoso computacionalmente, hacer un plan es mucho más costoso. Y revisarlo también

Y por si eso fuese poco, es posible que no se trate de acciones que se realicen una sola vez. Es que el agente puede estar funcionando de manera permanente, continua, con lo que esa planificación o revisión de planificación puede estarse ejecutando repetidamente. 

La economía y el medio ambiente

Y, claro, el coste computacional se traduce en consumo energético y, por tanto, en coste económico. Un coste económico que se traduce para el proveedor del modelo en factura eléctrica y eventualmente más facturas en forma, por ejemplo, de refrigeración. Y para el que usa el agente en factura IT, por tokens consumidos o la unidad que se haya acordado.

Pero claro, a poco que esa energía utilizada provenga de fuentes no renovables, ese consumo energético se traduce en huella de carbono u otros impactos medioambientales como calentamiento de aire o agua usados en refrigeración.

No, por desgracia no parece que los agentes se lleven muy bien con el medio ambiente

Un consumo muy perceptible

Ese consumo computacional se puede percibir además, no de forma precisa, pero sí muy tangible.

No hace mucho, casi más por experimentar, me creé un agente sencillo usando la herramienta Make. Cuando lo ejecuté, me llamó mucho la atención lo que tardó en realizar la tarea, una tarea que realmente era muy simple, casi trivial.

En realidad, se trataba de una tarea que creo impropia para un agente. Creo recordar que consistía en procesar correos entrantes, crear una respuesta para esos correos y contestar al remitente con esa respuesta.

Como usuarios estamos acostumbrados hoy en día a muy bajas latencias, a tiempos de respuesta muy buenos, por lo que esta lentitud era llamativa. Pero hay que tener en cuenta que el agente tenía que entender la tarea, realizar el plan de acción e imaginarse qué herramientas de las que ponía a su disposición utilizar y de qué forma. Eso no es tan fácil.

Esa lentitud percibida era, pues, una manifestación tangible del coste computacional de lo que el agente estaba haciendo.

Workflows: cuando la eficiencia técnica se alinea con la sostenibilidad

Y, sin embargo, con esa misma herramienta Make, que habitualmente se utiliza no para hacer agentes sino workflows, podría haber creado un workflow (escenarios como se llaman en Make) muy simple para hacer la misma labor.

La ejecución de ese workflow, aparte de más fiable en cuanto a estar seguros de que iba a hacer lo encomendado, es mucho, muchísimo más rápida. Y sería muchísimo más rápida porque el flujo ya estaría pensado en tiempo de diseño, no sería necesario crear ningún plan ni revisarlo (el propio workflow es el plan y es estático). Tampoco es necesario deducir qué herramienta (el GMail en este caso) usar, porque el propio workflow indica cuál es y cómo se invoca.

Desde un punto de vista técnico y operativo interesa saber que la tarea realizada con un workflow es mucho más rápida y mucho más fiable en cuanto a resultados.

Esa eficacia y eficiencia técnica y operativa tiene, claro, también su traducción en menor consumo energético y, por tanto, menor coste.

Y, por si algo faltaba, es una solución más respetuosa con el medio  ambiente porque ese menor consumo energético va a tender a crear mucha menor huella de carbono y mucho menor calentamiento.

El martillo de oro

Por tanto, no caigamos en pensar que los agentes son un martillo de oro y que son siempre son la mejor opción.

En el post anterior razoné que de cara a la eficacia, la eficiencia y la calidad, probablemente, para ciertos casos, existan soluciones mejores, soluciones más tradicionales basadas en reglas o workflows.

En este post recuerdo que la sofisticación de un agente viene acompañada de un coste económico y medioambiental y, por tanto, se deben usar con prudencia, cuando el tipo de tarea encomendada realmente sea propia de un agente e, incluso en este caso, debería preocuparnos su impacto medioambiental.

Como se puede observar, ni los agentes son un martillo de oro, ni todos los problemas son clavos.

Conclusiones

Los agentes son unas soluciones excitantes, poderosas y abren enormes posibilidades en automatización y seguramente más campos como investigación.

Pero no son un martillo de oro. No son la mejor solución técnica para todos los problemas y, desde luego, no son la mejor solución para el medioambiente.

Seamos, pues, responsables.

Artículos de este blog relacionados

• Los agentes y el martillo de oro (I): ¿por qué no un workflow?