Blue chip

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

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 31 Jul 2026 08:55:00 +0000

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

La inteligencia artificial y las heridas del antropocentrismo y narcisismo humano

noreply@blogger.com (Ignacio G.R: Gavilán) — Tue, 28 Jul 2026 11:00:00 +0000

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"

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 24 Jul 2026 08:30:00 +0000

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

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 23 Jul 2026 08:30:00 +0000

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"

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 17 Jul 2026 13:00:00 +0000

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

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 16 Jul 2026 10:40:00 +0000

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

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 08 Jul 2026 09:50:00 +0000

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?

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

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 03 Jul 2026 09:05:00 +0000

Leo mucho y también le doy muchas vueltas en los últimos meses, seguro que no soy el único, a todo lo relativo a los agentes de IA.

Por un lado, me resulta excitante el concepto y la posibilidad de que seamos capaces de construirlos y, además, con cierta facilidad.

Por otro, me generan dudas, no de manera general, sino en aspectos particulares o casos de uso particulares.

Voy a recoger algunas de esas consideraciones en una mini-serie de posts, entre tres o cuatro artículos, comenzando por el de hoy.

En concreto hoy hablaré de lo que tiene que ver con la automatización, la repetitividad y la calidad, un tema al que de alguna forma ya me he aproximado en algún artículo anterior.

Martillos y clavos. El martillo de oro

En cierto modo, y más allá de que creo que los agentes IA constituyen todavía una tecnología y un tipo de solución que tiene que mejorar mucho en cuanto a fiabilidad, pruebas y gobernanza, podría decir que mis cuitas con respecto a los agentes tienen que ver, sobre todo, con que los estemos tratando como un martillo de oro. ¿A qué me refiero? ¿Qué es un martillo de oro? En su entrada en wikipedia se expresa de una forma muy simple

Un martillo de oro (o martillo dorado) es cualquier herramienta, tecnología, paradigma o similar cuyos partidarios ensalzan de manera exagerada. Predicen que resolverá múltiples problemas, incluso aquellos para los que obviamente no es adecuada.

Aunque, quizá su formulación más conocida, también para mí, sea la que se atribuye al muy afamado psicólogo Abraham Maslow y que se denomina por ello, a veces, como martillo de Maslow, a saber:

Si sólo tienes un martillo, todo parece un clavo.

Y, en efecto, tengo la sensación de que estamos considerando a los agentes, en ocasiones a toda la IA, como un martillo y que, por tanto, sólo vemos clavos, queriendo decir con ello que todo lo queremos resolver mediante agentes, sean o no adecuados, y existiendo o no mejores soluciones alternativas.

Agentes y Agentic AI

Simplificando, y como ya he explicado en algún otro post, y como probablemente muchos lectores de este blog conozcan, los agentes (en la acepción de agente referida a los agentes IA que conforman la denominada Agentic AI) no son más (bueno, ni menos) que aplicaciones construidas alrededor de un gran modelo de lenguaje de tipo razonador, unas aplicaciones que, aunque pueden interactuar con el usuario, en general funcionan de manera autónoma y que, además, pueden realizar tareas especiales y, sobre todo, interactuar con el exterior, mediante las denominadas herramientas ('tools').

Mediante estas herramientas, el agente es capaz, por ejemplo, de leer un correo electrónico, leer datos de una pantalla, consultar datos en una aplicación y un larguísimo, casi infinito, etcétera. Y no sólo leer, también escribir o invocar acciones.

¿Hemos descubierto la pólvora?

Sin embargo, existen ya desde hace años, muchos otros tipos de aplicaciones que hacen algo similar, en el sentido de aplicar una cierta lógica para automatizar un proceso o tarea funcionando de manera autónoma e interactuando con el exterior haciendo uso, fundamentalmente, de APIs y conectores.

Cabe decir, además, que con independencia de los cambios de nombre, las herramientas funcionan de forma similar a, y de hecho se suelen apoyar en, APIs y conectores. Los afamados servidores MCP no dejan de ser una implementación algo especial de los conectores de toda la vida.

Entre ese tipo de soluciones que aplican de forma autónoma una lógica interrelacionándose vía conectores con el exterior, tenemos los chatbots basados en reglas y, sobre todo los robots RPA sobre todo en su variante no atendida, protagonistas ambos de mi libro 'Robots en la sombra'. Y, hasta cierto punto, aunque normalmente con menor autonomía, también podríamos incluir en este apartado las soluciones BPMS ('Business Process Management System').

¿Qué pasa entonces? ¿Es que con los agentes hemos 'descubierto la pólvora' o el Mediterráneo? ¿Es que no son más que un nuevo nombre o una nueva implementación de algo que ya teníamos?

Elementos diferenciales de los agentes IA

No, aunque comparten elementos comunes, bastante elementos comunes de hecho, con otras formas de automatización, tienen algunas características diferenciales, alguna tremendamente diferencial.

Me voy a centrar en dos.

La primera que, con ser importante, casi la veo secundaria, es que a un agente IA sus objetivos o la tarea a realizar se le indican en lenguaje natural, no mediante código, ni mediante reglas o flujos expresadas en un lenguaje más o menos formal. Simplemente, lenguaje natural.

Pero lo que creo que cambia radicalmente el planteamiento es que el 'cerebro', quien decide el plan y, por tanto la lógica, a aplicar, es un modelo de lenguaje razonador, no un desarrollador humano. Y esto tiene varias implicaciones muy importantes:

Decide la IA, no el humano, la lógica a aplicar en cada caso.
Por lo anterior, eventualmente un agente podría atacar la automatización de una tarea que un humano no sabe exactamente cómo resolver.
La lógica, el plan a aplicar, se decide en tiempo de ejecución, no en tiempo de diseño o desarrollo
El plan, la lógica a aplicar, es flexible, dinámico y adaptativo
El plan que se aplica puede variar de una instancia de tarea (un caso que se diría en proceso so automatización) a otra.

Son características, muy diferenciales y muy potentes, que diferencian claramente a los agentes de otras formas de automatización que, exteriormente se puedan manifestar de forma parecida.

En general, son de una potencia espectacular...pero a lo mejor eso nos lleva a considerarlos martillos de oro y es posible que, pese a su potencia, no siempre constituyan la mejor opción

Automatización

Cuando automatizamos tareas, es decir, cuando eliminamos la participación de un humano (o eventualmente un animal) de un proceso, solemos buscar los siguientes objetivos:

Ahorro de costes, ya que el trabajo humano es caro
Alta disponibilidad
Reducción de tiempos de proceso
Eliminación de errores
Control del proceso y predecibilidad de sus resultados (calidad)
Cumplimiento normativo

Los sistemas basados en reglas y workflows

Los sistemas de automatización de procesos y tareas, típicamente los BPMS (Appian, Pega, etc) , RPA (UiPath, Blue Prism, Automation Anywhere, Power Automate, etc) o workflows en la nube (Make, Zapier, N8N, etc) o incluso soluciones de automatización construidas como un desarrollo a medida, definen el flujo en tiempo de desarrollo con lo cual su lógica en producción está perfectamente determinada, perfectamente conocida por anticipado.

Por tanto, las aplicaciones de automatización construidas con estas herramientas cumplen con todos los objetivos expresados acerca de la automatización.

Sólo un matiz respecto a la frase anterior: como hoy en día estas soluciones incluyen también la posibilidad de invocar a grandes modelos de lenguaje usando APIs y conectores, la certeza en cuanto a su lógica se podría debilitar un tanto, pero esto no deja de ser una primera manifestación de las limitaciones que pueden exponer los agentes, basados precisamente en modelos de lenguaje y que expongo en la siguiente sección.

Alguna desventaja de los agentes

Paradójicamente, creo que, de todos los objetivos de la automatización mencionados más arriba, en el único en que los agentes pueden superar a otras opciones de automatización más tradicionales es en el ahorro de costes.

En principio, igualan a las soluciones tradicionales puesto que, para una tarea dada, si ambas soluciones eliminan el trabajo humano, el ahorro es el mismo. Sin embargo, a priori los agentes permiten automatizar tareas que otras soluciones no pueden, precisamente por su capacidad de decidir 'ellos mismos' qué hacer en cada momento, siendo capaces de acometer automatizaciones de tareas que un humano no sabe definir bien o tareas sometidas a muchas incertidumbres o variantes que son difíciles de reflejar en un workflow.

En cuanto al segundo punto, probablemente podamos considerar que los agentes proporcionan la misma escalabilidad que los sistemas tradicionales, quizá con una cierta penalización por su alto consumo computacional, del que me ocuparé en otro post.

Hasta aquí vamos bien con los agentes, pero en los siguientes puntos, cambian las tornas.

Así, aunque no siempre de manera grave, los agentes suelen ser más lentos de ejecución que una solución basadas en workflow. Es decir, sí que reducen el tiempo de proceso, pero algo menos que las soluciones basadas en workflow. Según el caso, la diferencia puede ser casi irrelevante o puede importar.

Pero, sobre todo, los agentes no son completamente previsibles con lo cual perdemos una parte del control y predecibilidad de otro tipo de automatizaciones. Además, podemos esperar que se produzcan algunos errores porque el agente 'alucine' o no reaccione correctamente a un escenario dado.

Exactamente por lo mismo, introducimos algún riesgo, si bien creo que pequeño, de no conseguir el cumplimiento normativo.

¿Por qué no un workflow?

Estando así las cosas, ¿Por qué, en lugar de liarnos a hacer agentes, no automatizamos directamente al modo tradicional, mediante una solución basada en un workflow?

En el fondo, y esto es lo que origina todo el post, es porque a veces parece que sólo tenemos un martillo, un martillo de oro que son los agentes, y nos parece que todo son clavos. Pero no es así, disponemos de destornilladores, llaves inglesas y mucho más, y podemos no solo clavar, sino atornillar, poner tuercas o pernos y muchas más tareas.

Probablemente, lo sensato sea diferenciar el tipo de procesos y tareas que queremos automatizar, saber si son clavos o tornillos y, con criterio, seleccionar la herramienta adecuada, no sólo el martillo.

Me reservo una posible solución

Me reservo para el último post de la serie una idea que se me ocurre, que no tengo claro cómo es de viable ni si ya se está trabajando en ella y que reconciliaría un poco las diferentes visiones y podría convertir a nuestro martillo, los agentes, en una especie de navaja suiza.

Conclusiones

Los agentes de IA son una forma de automatización que, si bien comparte bastantes ideas con otras formas de automatización existentes, aportan sobre todo su planificación y decisión en tiempo de ejecución con base en un modelo de lenguaje razonador.

Esto es enormemente potente y diferencial pero, sin embargo, puede que no sea siempre la mejor solución. A lo mejor, hay casos en que siguen siendo preferibles soluciones basadas en reglas y workflows.

La imaginación como virtud ética

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 29 Jun 2026 07:00:00 +0000

Que la imaginación es una virtud, dicho así, probablemente a nadie le parezca demasiado extraño.

Tendemos, lógicamente, a valorar positivamente la imaginación, que aparte de su interés casi diría intrínseco, puede ser fuente de ideas, algunas en el ámbito de la creación pura, como como en el caso de la creación artística, literaria, musical... y otras en otro tipo de creación como la que se produce en la innovación empresarial o, en un ámbito más general, como una capacidad útil en la resolución de problemas.

Sin embargo, con todo y lo valiosa que nos tiende a parecer la imaginación, no solemos concederle un valor ético.

Sin embargo, esa perspectiva ética de la imaginación me la he encontrado en el libro 'The AI Mirror: How to Reclaim Our Humanity in an Age of Machine Thinking' de Shanon Vallor y quisiera comentarla brevemente.

Grandes escuelas éticas

Antes de seguir, y en beneficio de quien pueda no conocerlas, una rapidísima y muy básica revisión de las tres grandes escuelas éticas en el mundo occidental. Hablaríamos de las siguientes:

Ética deontológica: Abanderada por Kant y que, en esencia dice que debemos seguir unos ciertos principios (ahí es donde encaja el famosísimo, aunque seguramente no bien conocido en el fondo, imperativo categórico). Aunque al hablar de principios, en cierto sentido estamos poniendo la ética fuera de las personas, el propio Kant es quien, en otro famoso aserto, establece que una persona es un fin en sí misma y nunca puede ser usada como un medio.

Ética consecuencialista / utilitarista Nacida de la mano de Jeremy Bentham e impulsada, y matizada, por su discípulo John Stuart Mill, pone el foco en la consecuencias de lo que hacemos con un enfoque muy económico-matemático que busca maximizar una especie de función de utilidad que de alguna forma expresa el placer o bienestar conjunto (no el de una persona específica).

Ética de las virtudes: Asociada a Aristóteles (aunque, curiosamente, muy similar a los presupuestos de Confucio). Se trata de una ética muy centrada en la persona, que debe buscar su florecimiento, su excelencia, su máxima realización, lo cual consigue en cierto sentido a través de las virtudes que se entienden como un sano equilibro entre extremos (así entre dos extremos viciosos como la cobardía y la temeridad, nos encontramos con la virtud de la valentía).

Que me perdonan filósofos y eticistas por la simplificación, pero creo que era pertinente.

Aristóteles, las virtudes y la persona

Como se ha dicho, el foco de Aristóteles es la persona y su realización. Esa realización, quizá más ese desarrollo personal, recibe un nombre difícil como es, 'eudaimonia'.

Como digo a veces en algunas clases y charlas, aunque el nombre es difícil, hoy en día podríamos decir que incluso desafortunado, el concepto es precioso y, en mi opinión, la mejor forma que he visto de enfocar la ética.

La imaginación

Y vamos ya a la imaginación.

Aristóteles parece que no consideraba a la imaginación ('phantasia') un virtud, sino, más bien, una facultad psicológica.

Sin embargo, Shanon Vallor, que se reconoce fundamentalmente como seguidora de Aristóteles y representante actual de la ética de las virtudes, en la obra citada afirma que, en su opinión, la imaginación sí es una virtud. Nos dice:

It was not named as a virtue by ancient philosophers such as Aristotle or Kongzi. But contemporary philosophers, including me, have often recognized it as one, or at least as an essential component of virtue.

Su razonamiento, tiene mucho que ver, creo, con esa idea de la eudaimonia que, ahora, voy a traducir como 'excelencia' (en seguida se verá por qué). Así, Vallor nos dice:

It is hard to envision someone entirely lacking in imagination who can still develop and express their full moral, intellectual, and creative potential. Imagination is how we envision yet unmade possibilities for ourselves and others; it is what makes autofabrication possible. Lacking any imagination might be technically survivable for an individual, as long as they can reap the benefits of the imagination of others, but it places a fundamental limit on a person’s excellence.

En esencia, la imaginación es una capacidad fundamental para que una persona pueda desarrollar su potencial de todo tipo y alcanzar la excelencia (de ahí la traducción libre de eudaimonia).

Y por esta vía, quizá un poco indirecta, la imaginación alcanza un valor ético.

Desde un punto de vista estrictamente intelectual no sé si estoy de acuerdo o no con esta consideración...pero lo cierto es que me gusta mucho la idea.

Conclusiones

Las virtudes son, para Aristóteles, elementos fundamentales de su ética y se conciben como equilibrios entre extremos digamos viciosos. Pero, además, Aristóteles propugnaba el desarrollo de la persona, su florecimiento, hasta alcanzar la famosa 'eudaimonia'

Un poco por esa necesidad de la imaginación para alcanzar el desarrollo máximo y la excelencia, es por lo que, una filósofa actual, Shanon Vallor, considera a la imaginación como una virtud y le concede valor ético.

La humanidad como metáfora (II): el caso de la robótica

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 19 Jun 2026 09:30:00 +0000

En el post anterior de este blog introduje la reflexión sobre el uso de la metáfora humana en lo que tiene que ver con la inteligencia artificial.

Esa metáfora se manifiesta fundamentalmente en lo que tiene que ver con el vocabulario usado para referirnos a las capacidades de la inteligencia artificial, comenzando por el propio término inteligencia, y siguiendo por otras términos como reflexión, introspección, memoria, visión, etc

Pero también vimos que, más allá del lenguaje usado, hay aspectos más profundos que una mera metáfora, como el uso del ser humano, en este caso su cerebro, como fuente de inspiración científica para diseñar sistemas de inteligencia artificial y quizá, sólo quizá, o sólo para algunas personas y colectivos, su emulación y superación, como objetivo final de la inteligencia artificial,

En este segundo artículo, voy a saltar al campo de la robótica, una disciplina bastante diferente pero cada vez más entremezclada con la inteligencia artificial.

El cuerpo como diferencia

Aunque el debate tendrá elementos comunes con el caso de la inteligencia artificial, la gran diferencia que se plantea en el caso de los robots, es que éstos, al menos en su mayoría (y digo esto de la mayoría para evitar el debate de si los robots software son robots), poseen un 'cuerpo' ('embodyment') una realidad física tangible con lo que la metáfora no se traslada sólo a lenguaje o funcionamiento, sino también a la forma, a la apariencia.

Robots y humanos digitales

Hay, sin embargo, un punto intermedio que conviene resaltar, y es el de los avatares o humanos digitales, es decir, una forma de chatbots que se presentan en pantalla con una forma humana, en algunos casos bastante fiel y detallada.

Por tanto, una buena parte, aunque no todo, de lo que digamos respecto a los robots 'con cuerpo', se aplica a los humanos digitales

Las capacidades cognitivas y relacionales

Antes advertir que en el caso de los robots más avanzados, en el fondo en los que me estoy centrando, vienen dotados de capacidades cognitivas de la inteligencia artificial. Esto quiere decir que todo lo que dijimos en el post anterior de esta serie tanto sobre nomenclatura de tintes humanos, como sobre inspiración científica en el cerebro humano o posible objetivo final de la inteligencia artificial se traslada completamente al caso de estos robots cognitivos.

La forma: robots sociales y humanoides

Enlazando con lo que decíamos anteriormente sobre el cuerpo, en el caso de los robots la metáfora humana afecta muy directamente a su forma, a su cuerpo.

Muchos robots, como los manipuladores industriales, los robots móviles o los robots para reparto, adoptan formas plenamente funcionales, adaptadas a su labor y que nada tienen que ver con los humanos.

Pero existen dos importantes clases de robots, con algún solape entre ellos, en que la metáfora humana es evidente en cuanto a la forma. Me refiero a los robots sociales y a los robots humanoides.

Robot Neo

Los primeros, los robots sociales, son la contrapartida física de los chatbots, es decir, se trata de robots cuya misión principal es la de relacionarse con humanos. En ese sentido, no sólo utilizan el lenguaje natural y la voz como forma de comunicación, sino también elementos de lenguaje no verbal como la mirada, la distancia social o los gestos. Aunque no todos los robots sociales son antropomórficos, una buena parte de ellos sí que lo son. Entre los representantes más conocidos de los robots sociales podríamos mencionar a Pepper y Neo, aunque existen otros, quizá más experimentales, como la famosa Sophia o Amecca... y muchos más. Aunque son antropomórficos, y en algún caso como los geminoids imitan profundamente la forma humana, la mayoría tienen un aspecto indudablemente robótico.

Robot Optimus

El otro caso, es el de los robot humanoides. Siendo rigurosos con los términos, los robots sociales antropomórficos serían también humanoides, pero en esta categoría me refiero a robots más orientados a ámbitos industriales o a realizar tareas, incluso en el hogar y, por tanto, algo menos relacionales en su objetivo. Estaría hablando de robots como Optimus o Figure, por poner un ejemplo. Son robots técnicamente mucho más sofisticados que los robots sociales, más entrenados en la realización de trabajos y con mucha mayor destreza 'manual'.

El papel de la forma humana en los robots

Aunque podamos pensar que el dotar a robots de forma humana es una forma de fantasía, de ser capaces de crear seres como nosotros, no es ésta la motivación verdadera, al menos no en la mayor parte de los casos.

Creo que se pueden identificar dos grandes motivaciones para el uso de la forma humana, una de naturaleza operativa y otra relacional (que, en el fondo, también acaba siendo operativa).

La motivación operativa

La primera naturaleza operativa tiene que ver sobre todo con los robots humanoides. En el post 'Especulando sobre un mercado para robots humanoides (I): proposición de valor', argumentaba que unos de los elementos de la proposición de valor de los robots humanoides es su versatilidad.

¿Qué quiere decir esto?

Otro tipo de robots, como los manipuladores industriales, pese a estar dotados de cierta flexibilidad, en el fondo están circunscritos a un conjunto acotado de tareas posibles. Sin embargo un robot humanoide puede acometer muchas más tareas y muy diferentes.

Pensemos que la anatomía del ser humano es fruto de milenios de evolución y capacita al ser humano para realizar todo tipo de tareas, incluyendo el desplazamiento por todo tipo de terrenos. Imitar la forma humana, no deja de ser una forma de biomímesis que hereda todo lo que de bueno tiene el cuerpo humano para acometer tareas de todo tipo y que posibilita a su vez a robots con esta morfología el acometer una gran variedad de tareas.

Esta flexibilidad, tiene indudable valor de negocio e ingeniería y facilita la producción masiva y las economías de escala que se derivan.

Además, en muchas de las tareas que queremos confiar a los robots humanoides, sustituirían a los humanos y parece que el que los robots estén dotados de una morfología similar a la del ser humano contribuye a que puedan realizar tareas similares a éste.

La motivación relacional

La motivación relacional, aunque afecta también a los robots humanoides, tiene mas que ver con los robots sociales e incluso los humanos digitales.

Parece lógico pensar que el uso de mecanismos 'humanos' en la relación, no sólo el lenguaje verbal (procesamiento de voz y lenguaje natural), sino también el lenguaje no verbal con sus gestos, miradas, entonaciones etc facilita la comunicación entre personas y robots.

Dado que las características relacionales humanas se desarrollaron evolutivamente, fundamentalmente para engrasar las relaciones entre personas, si los robots son capaces de utilizar o emular los mismos mecanismos verbales y no verbales, la comunicación persona-robot fluirá de manera natural y sin necesidad de adaptación o aprendizaje por parte del humano.

En el fondo se trata de una manera algo particular y especializada de biomímesis.

Y esa comunicación, especialmente en sus aspectos no verbales, se beneficia también de una forma más o menos humana del robot, no sólo porque le permite al robot hacer gestos o usar miradas de forma más similar a un humano sino porque, en el fondo, lo vamos a aceptar mucho mejor.

Decía más arriba que esta motivación relacional en el fondo es también operativa porque es el robot el que se adapta al humano y por tanto para éste, para el humano, es muy sencillo, casi trivial, relacionarse con el robot, lo que elimina la necesidad de entrenamiento, aprendizaje o adaptación por parte del humano y facilita la adopción de la tecnología y su uso e interacción en el día a día.

El valle inquietante

Sin embargo, existe una limitación, no demostrada pero claramente admitida en esa imitación a la morfología humana: el valle inquietante ('uncanny valley').

Está bastante admitido que los humanos acogemos mejor a un robot cuanto más se va pareciendo a nosotros...pero eso tiene un límite. Si se parece 'demasiado' a un humano, si es casi igual (aunque sin llegar a ser igual) lo que era aceptación se convierte de repente en un profundo rechazo.

Dicho de manera familiar, queremos que los robots se parezcan a los humanos pero 'que no se pasen', que no dejen de seguir teniendo un aspecto razonablemente robótico.

El aprendizaje de los robots y la inspiración humana

Hay otro aspecto menos conocido de los robots en que se experimenta con mecanismos de clara inspiración humana: el aprendizaje.

Pese a que los robots avanzados, los robots cognitivos, obtienen sus capacidades cognitivas de la inteligencia artificial, presentan en ocasiones particularidades en cuanto a su entrenamiento que difieren de los mecanismos usados en la inteligencia artificial generalista.

Algunas de las dificultades del aprendizaje, que podrían considerarse generales pero que afectan sobre todo a robots cognitivos son el 'grounding', es decir, que sepan ligar los conceptos a las realidades físicas del mundo y la adquisición de conocimientos de naturaleza más cultural.

Aunque es posible que mecanismos como los VLAM (Vison-Language-Action Models) y los World Models a ellos asociados, resuelvan de una forma algo más algorítmica y similar al entrenamiento de otros modelos generativos, esos problemas, ya desde hace un tiempo se experimenta con formas de aprendizaje inspiradas en el aprendizaje humano, como son el aprendizaje por imitación ('imitation learning') o toda la propuesta de la robótica del desarrollo ('developmental robotics') en que se imita en cierto modo el aprendizaje en niños.

Estaríamos hablando en este caso, pues, de la metáfora humana como inspiración científica. De nuevo, una forma especial de biomímesis.

Personalidad y empatía

Un punto en que se comienza a extremar la metáfora humana es lo que tiene que ver con personalidad y empatía.

Ya desde hace años, con chatbots relativamente básicos, uno de los primeros pasos del diseño del chatbot es la decisión de la personalidad que deseamos que exhiba. En general, cualquier chatbot moderno y robot social, salvo que por algún motivo se decida lo contrario, va ser amable y servicial. Pero lo importante es que la metáfora no afecta sólo a la forma y a procesos cognitivos más intelectuales, sino también a la dotación a chatbots y robots de personalidad propia, una personalidad, por supuesto, perceptible por los humanos con que dialoga.

No sólo eso, se dota a este tipo de soluciones de una cierta empatía. Por supuesto, se trata de una empatía impostada, no sentida, pero a efectos prácticos y relacionales eso es casi irrelevante: el robot o el chatbot se muestran empáticos y las personas los perciben como tales.

Y, por cierto, no estoy hablando de una metáfora sólo como terminología, sino como comportamiento absolutamente real.

Las emociones

En la misma línea, pero yendo un poco más allá, la metáfora se extiende hasta las emociones. Los chatbots y robots avanzados son capaces en algunos casos de percibir las emociones del humano tanto por su lenguaje verbal como, en los casos más avanzados, por el lenguaje no verbal.

Y, claro, no es sólo que sepan percibir las emociones de los humanos, es que pueden tener capacidad para simular, de forma consistente, sus propias emociones.

De nuevo, no se trata de una metáfora meramente terminológica, sino plenamente operativa y perceptible.

El problema de la vinculación afectiva

No voy a profundizar mucho en esto ahora, pero sí mencionar que entre las problemáticas éticas que generan estos robots sociales o humanos digitales avanzados, varios de los más representativas tienen que ver con la vinculación afectiva que se puede producir, tiende a producirse de hecho, entre el humano y el robot o chatbot.

Un tema delicado, sin duda, y que conduce a otros riesgos relacionados con la influencia y la autonomía.

El problema del engaño

En los casos más avanzados, y quizá implicando a humanos poco advertidos o poco maduros, se puede producir un engaño, una confusión, en que el humano piense que realmente el robot o chatbot con que se relaciona, es más o menos consciente y tiene verdadera inteligencia, verdadera personalidad, verdaderos sentimientos.

En este caso, la metáfora casi, casi, dejaría de ser tal, porque algunas personas se la tomarían no como metáfora, sino como realidad.

Esto, aparte de falso, es peligroso y, de hecho, el reglamento europeo de inteligencia artificial pide explícitamente que estos artefactos se identifiquen claramente como tales, evitando o intentando evitar el engaño.

De todas formas, evitar el engaño creo que, más allá de leyes, depende también de cierta divulgación correcta de lo que son este tipo de ingenios, y casi diría también de cierto sentido común por parte de las personas.

Conclusiones

La metáfora humana en el caso de los robots o ingenios con ciertas características similares, adopta características diferenciales respecto a las que vimos de la pura inteligencia artificial en gran medida porque los robots incluyen un cuerpo físico, que también en su forma adopta la metáfora

Pero además, tiende, con mas intensidad que en el caso de la pura inteligencia artificial, a extenderse a elementos relacionales que implican personalidad, empatía y emociones.

Y eso conlleva algunos riesgos, incluyendo que la metáfora deje de ser reconocida como tal y se convierta en un engaño, quizá un auto-engaño.

Artículos de este blog relacionados

La humanidad como metáfora (I): El caso de la inteligencia artificial

La humanidad como metáfora (I): El caso de la inteligencia artificial

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 17 Jun 2026 08:00:00 +0000

En ciertos campos tecnológicos, muy en especial con lo que tiene que ver con inteligencia artificial, se utiliza un lenguaje que mimetiza las características y aportaciones de esa tecnología con características con capacidades humanas. Así, hablamos de capacidades cognitivas, de razonamiento, de reflexión, etc.

Y la cosa no creo que se reduzca al lenguaje, existen dudas y debates sobre si lo que estamos haciendo va mucho más allá de la terminología, y si la verdadera aspiración, como así se afirma, sin duda, es alcanzar o incluso sustituir a la inteligencia humana.

Me encuentro inmerso en la lectura del libro 'Agentic Mesh: The GenAI-Powered Autonomous Agent Ecosystem' de Eric Broda y Davis Broda, un libro eminentemente técnico, pero en el cual, en el tercer capítulo, 'Agents basics', se dedica completamente a poner en paralelo y comparar a los agentes con los seres humanos, a mostrar capacidades humanas, tanto individuales como grupales, y cómo éstas se trasladan puntualmente al caso de agentes. De hecho, los autores afirman que esa analogía con las personas es una excelente forma de entender cómo funcionan los agentes, como exponen en la primera sección de ese capítulo 'Agent analogy: agents as people'.

Y es precisamente la lectura de ese capítulo la que me ha hecho preguntarme hasta qué punto es beneficiosa, y hasta qué punto real, esa analogía, esa metáfora. Y, también, si esa analogía va más allá de un paralelismo para convertirse en una aspiración.

Con ello tengo material para una 'miniserie' de dos o tres posts, de la cual éste es el primero, y en él me centro en el caso concreto de la inteligencia artificial.

Inteligencia artificial y metáfora

Lo cierto es que desde su mismo nacimiento, la inteligencia artificial sostiene, en su nomenclatura y en algo más, ese paralelismo con la humanidad o con la cognición humana.

El propio nombre de inteligencia hace pensar en seres vivos y, sobre todo, en humanos, y la propia declaración de visión, en la conferencia de Darmouth, 'hacer que las máquinas se comporten de una forma que consideraríamos inteligente si un humano se comportase de esa forma', pone de alguna manera al ser humano como medida y casi como aspiración de la inteligencia artificial.

Y ese paralelismo, esa analogía, esa nomenclatura y esa aspiración, siguen entre nosotros e inundan el discurso y en parte la actividad en materia de inteligencia artificial.

Pero, en realidad, esa forma de hablar acerca de la inteligencia artificial, esa insistencia en términos provenientes de la psicología o la neurociencia como razonamiento, reflexión, introspección, memorias de corto y largo plazo, etc va más allá de una pura metáfora, de un puro paralelismo.

También es una inspiración, inspiración en el doble sentido científico y aspiracional y, puede, sólo puede, que constituya un objetivo.

Más allá de la metáfora: el cerebro como inspiración científica

En efecto, el ser humano, y en concreto su cerebro y su sistema nervioso, han funcionado y funcionan como fuente de inspiración desde un punto de vista científico y técnico, es decir, como un elemento que podemos estudiar y que las conclusiones nos pueden servir en el diseño técnico de las soluciones de inteligencia artificial.

En la época en que estaba en boga la inteligencia artificial simbólica, se estudió e intento aplicar, con regular éxito, los mecanismos de pensamiento consciente del ser humano. Se trabajó con las leyes de la lógica y con la representación del conocimiento y se atendía a los procesos cognitivos del ser humano.

Y cuando la orientación viró hacia el machine learning, hacia el reconocimiento de patrones y el aprendizaje basado en datos, las muy exitosas actualmente redes neuronales se inspiraron, y de qué manera, en el cerebro humano. Los perceptrones, las primeras neuronas artificiales, abstraían (y abstraen) el funcionamiento de una neurona humana, y la distribución en capas emula, creo que de forma ya algo menos fiel, la profunda interconexión entre neuronas que existe en el cerebro humano.

He leído, aunque tengo alguna duda al respecto, que las redes neuronales de convolución, que permitieron un enorme salto en materia de visión artificial, también emulaban el funcionamiento de las neuronas dedicadas a visión.

En el fondo no se trata de nada nuevo ni de nada ilógico. Dado que muchas de las características que aspira a conseguir la inteligencia artificial las exhiben con notable éxito los seres vivos y en especial los humanos, parece muy razonable estudiar a esos seres vivos e intentar trasladar lo aprendido a diseños técnicos. Es lo que se denomina biomímesis y es algo que se ha hecho durante décadas e incluso siglos y tiene toda la lógica del mundo.

Pero es preciso ser conscientes de que con frecuencia se trata solo de un punto de partida inicial. El diseño fino de esas redes neuronales, o de cualquier artefacto basado en biomímesis, se suele apartar luego en parte de su inspiración original, y se guía luego más por resultados y técnicas de ingeniería que por una verdadera copia del mecanismo biológico que, además, con frecuencia, y este es el caso del cerebro, no se conoce del todo.

El cerebro como objeto

A veces se afirma, y es una afirmación de base científica, que lo que aprendemos del funcionamiento de algoritmos de inteligencia artificial, lo que experimentamos con ella, puede ser un mecanismo para ayudarnos a comprender nuestro propio cerebro.

En este caso, en el fondo, el objeto es el propio cerebro, o su conocimiento, más que la tecnología de inteligencia artificial en sí misma que sería un medio para experimentar.

Es una afirmación razonable e inspiradora, pero no estoy seguro de cuántos resultados se han producido en esta orientación.

El cerebro como aspiración

Lo que de alguna forma es técnicamente más retador, y también éticamente más problemático, es si la aspiración real es el cerebro humano, o por mejor decir, conseguir hacer un cerebro artificial que emule, e incluso supere, al cerebro humano.

Esto tendería a llevarnos al campo de la AGI ('Artificial General Intelligence') o de la superinteligencia y nos pudiera dejar en los umbrales de la famosa singularidad.

A pesar de discursos sensacionalistas y catastrofistas, no creo que este objetivo domine hoy en día el desarrollo de la inteligencia artificial, pero tampoco diría que no está presente y que no tiene su peso. De hecho, un objetivo declarado de OpenAI es conseguir esa AGI. Así que, cuidado.

Si esto se consiguiera, o si la AGI o la super-inteligencia son el verdadero objetivo, estamos hablando no de una metáfora, sino de una imitación e incluso una sustitución y con muchas y serias implicaciones.

Ingeniería versus utopía

Lo cierto es que, al menos eso creo yo, una gran parte del trabajo en materia de inteligencia artificial, tanto en los diseñadores y fabricantes de los algoritmos y los grandes modelos, como en las empresas que adoptan soluciones, creo que está mucho, muchísimo más guiado por objetivos de negocio e ingeniería, por la aplicación de tecnología para conseguir unos objetivos más concretos, más prácticos y, en cierto sentido, más inmediatos, acercándose o usando la inspiración humana sólo cuándo éste sea un recurso prometedor.

Y la metáfora humana con frecuencia creo que se queda más en eso, metáfora, más usada en términos de comunicación y marketing o a veces, sólo a veces, se orienta hacia la venta de una utopía (puede que en realidad una distopía)

La conveniencia de la metáfora humana

Personalmente, no me parece mal del todo el uso de la metáfora humana hasta cierto punto.

En el fondo, es cierto que con frecuencia la inteligencia artificial imita capacidades cognitivas humanas, y no está mal reconocerlo, explicarlo e, incluso, con prudencia, adoptar nombres que se reutilicen de la neurociencia o la psicología para denominar capacidades más o menos equivalentes de la inteligencia artificial.

Además, la metáfora bien usada y explicada, puede ayudar a entender de una forma más sencilla qué mecanismos implementa la inteligencia artificial.

Pero tampoco creo que haya que extremar la metáfora.

En primer lugar, no se debe exagerar, no se deben usar palabras que hagan pensar que la inteligencia artificial hace más de lo que realmente hace. Y también se debe emplear con cierta contención y prudencia, porque un uso poco explicado, o peor, mal explicado de la metáfora humana, puede despistar al público, puede, en lugar de ayudar, confundir e incluso puede generar rechazo. Hace unos pocos meses pude asistir, por ejemplo, al rechazo que generaba el mero uso del término agente, en una comunidad orientada hacia la filosofía e incluso la teología donde el término agente tiene un significado propio y de connotaciones morales.

Y, por supuesto, si el objetivo es realmente crear un cerebro artificial, una super-inteligencia que nos supere, lo cual ya no es metáfora en absoluto, eso tiene muchas otras implicaciones éticas, humanísticas e, incluso de seguridad, pero eso es ya harina de otro costal.

Conclusiones

La metáfora humana se ha usado y se usa con frecuencia en el campo de la inteligencia artificial. Su empleo es justo y razonable en la medida en que realmente la inteligencia artificial implemente mecanismos similares o paralelos a los de la cognición humana, pero un uso incorrecto o exagerado de esa metáfora puede generar rechazo y puede confundir, y creo que confunde, de hecho.

Cuatro patrones para la monitorización de agentes IA en producción

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 12 Jun 2026 07:45:00 +0000

Probablemente, una de las áreas en que más se trabaje, o al menos que, digamos, más 'preocupación' genere en el tema de los agentes IA sea la gobernanza de éstos y, más específicamente, como gestionarlos adecuadamente en producción, cómo hacer que sean seguros, cómo vigilar que tengan un comportamiento correcto, cómo asegurar que funcionan como esperamos que funcionen.

Inteligentes pero imprevisibles

Y esta labor no es trivial en absoluto pese a la cantidad de años que llevamos monitorizando todo tipo de sistemas, garantizando su seguridad, sus prestaciones y su escalabilidad, y a pesar de la abundancia de soluciones y herramientas que existen para ello.

Y la dificultad surge, no del hecho de que los agentes sean un tipo de software novedoso, sino de la naturaleza misma de este tipo de solución basada en IA, de lo que les diferencia y les da valor.

Los agentes son un tipo de software autónomo, pero eso no es nada nuevo. Existen desde hace décadas sistemas que se comportan de manera autónoma. Y sabemos monitorizarlos y operarlos.

Los agentes, como su propio nombre indica, son también capaces de actuar, esto es, de realizar acciones sobre sistemas de ficheros, sobre bases de datos o sobre otras aplicaciones. Pero esto no es tampoco nada nuevo y nada que en general no sepamos controlar. Esa misma capacidad de actuación, además de una forma bastante parecida, la tienen también muchos otros sistemas autónomos, como los robots RPA que describía en mi libro 'Robots en la sombra' o los modernos workflows en la nube que construimos con plataformas como Make, N8N, Zapier o Power Automate Cloud.

No, la verdadera dificultad no está ahí, no está en la autonomía y ni en la capacidad de actuación. sino en la forma en que estos sistemas autónomos 'deciden' que hay que hacer. Todos los demás sistemas autónomos que les han precedido y con los que conviven, tienen marcada, de una forma rigurosa y cerrada, la lógica que deben seguir para llevar a cabo la tarea que tienen encomendada y automatizarla. Esta lógica se establece en tiempo de desarrollo por el propio desarrollador y suele adoptar la forma de un flujo, un workflow, aunque pueden existir otras formas de fijar reglas de comportamiento.

El caso de los agentes es muy diferente. No tienen una lógica pre-establecida, sino un objetivo o tarea, unas reglas de comportamiento muy generales expresadas en lenguaje natural y una serie de capacidades de actuación mediante las denominadas herramientas ('tools'). Pero la verdadera lógica de solución la decide el agente usando sus capacidades razonadoras basadas en un gran modelo de lenguaje, y lo hace en tiempo de ejecución, no de desarrollo.

Eso nos lleva a un comportamiento sin duda más inteligente, más flexible y más adaptativo, pero precisamente por eso, hasta cierto punto imprevisible. No quiero decir con ello que sean completamente imprevisibles, pero sí que no existen unas reglas exactas y que el agente tiene, digamos, grados de libertad.

Difíciles de probar, difíciles de monitorizar

Esa imprevisibilidad los hace difíciles de probar, porque no podemos establecer un catálogo exhaustivo y cerrado de casos de prueba que garanticen haber ejercitado con éxito todas los escenarios posibles. Ni siquiera es siempre posible definir con claridad cuál es el resultado que consideraríamos correcto para dar por bueno el caso.

Esas mismas dificultades se trasladan a a la monitorización en producción. Podemos monitorizar, claro, ciertas manifestaciones externas de su comportamiento como, por ejemplo, invocaciones de cada herramienta a su disposición o los datos que generan. Pero como el comportamiento es abierto, y hasta cierto punto imprevisible, es difícil disponer de unos mecanismos claros y cerrados para asegurar que el agente se comporta adecuadamente, que no incurre en riesgos no admisibles y que, por supuesto, no comete errores.

Cuatro patrones para la monitorización de agentes

Es por eso que me ha interesado la propuesta de patrones para esa monitorización que he encontrado en el libro 'Building Applications with AI Agents' de Michael Albada donde nos plantea cuatro patrones de monitorización. Son los siguientes:

Shadow mode (modo sombra): Se trata, en realidad, de un mecanismo transitorio hasta que ganemos confianza en un agente nuevo. La idea es, cuando despleguemos un agente nuevo, mantener a este recibiendo datos reales pero sin enviar salidas a los usuarios y sin realizar acciones reales. De esta forma, durante un tiempo se puede observar su comportamiento en situaciones reales y ver que se comporta bien, antes de otorgarle 'plenos poderes'. En realidad, es casi más un mecanismo de prueba que de monitorización.

Canary deployments (despliegues 'canario'): También se sitúa un poco en la línea de poner a prueba un agente nuevo en situaciones reales sin dejarle hacer daño, pero va un poco más lejos que la opción anterior. En este caso lo que se hace es que el nuevo agente sólo actúe en un porcentaje bajo (digamos entre un 3% y un 5%) de las situaciones reales, mientras que el resto se tratan 'normalmente' (con una versión anterior del agente, con un sistema más tradicional o manualmente, si es el caso). Estrictamente hablando, no impedimos que el agente pueda hacer daño, pero minimizamos el riesgo y el posible impacto

Regression trace collection (recolección de trazas de regresión): Ahora, más bien, lo que tratamos es de aprender del pasado. Y lo hacemos también mediante un mecanismo bien conocido: la recolección y análisis de trazas. Para ello se recopilan trazas (logs) y, cuando se produce un fallo, se estudian para intentar entender qué ha pasado y arreglarlo de cara al futro.

Self-healing agentes (agentes auto-curativos): Se trata de agentes que reciben los propios datos de monitorización, y las propias métricas y son capaces de implementar mecanismos de recuperación ante fallos.

La verdad es que de estos cuatro mecanismos, sólo el último es realmente novedoso. Los otros tres ya se han venido aplicando con mayor o menor intensidad en la monitorización y operación de otro tipo de sistemas.

Se trata de mecanismos que disminuyen el riesgo y el impacto de posibles malos funcionamientos, pero, por supuesto, no los evitan completamente.

En cualquier caso, parecen buenas prácticas que 'van a favor de obra' en busca de ese objetivo de tener a los agentes bajo control.

Conclusiones

Los agentes de IA, por su propia naturaleza, son difíciles de probar, de monitorizar y de operar.

Hemos visto cuatro patrones de operación de agentes que, si bien no eliminan el riesgo, sí pueden ayudar a tenerlo bajo control.

'Magnifica Humanitas' y la voz

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 05 Jun 2026 13:05:00 +0000

Es probablemente de todos los lectores conocido la reciente publicación de la primera encíclica del Papa León XIV, la ya muy conocida y comentada 'Magnifica Humanitas'.

Cuando supe de su publicación me propuse, por supuesto leerla, pero además publicar un post como este, en que la comentase.

Por cierto, que pensaba que publicar un post sobre una encíclica, por más que ésta se centrase en la inteligencia artificial, era un paso de una cierta originalidad por mi parte, pero viendo todo lo que se ha hablado de ella, no sólo en medios como la radio y la televisión, sino también en redes sociales incluyendo las profesionales, creo que no es así, que no soy original para nada, y que, incluso, este post podría verse casi como 'cansino', más aún cuando ya hace unos 20 días desde que la encíclica fue publicada, y ya se ha producido toda una avalancha de artículos, pronunciamientos y opiniones.

Recogimiento para la formación de una opinión

Y sin embargo, publico estos comentarios porque me sigue apeteciendo hacerlo, y pese a que ya pueda haber perdido una cierta oportunidad.

Lo cierto es que cuando supe de la publicación de la encíclica, decidí atender lo menos posible a los comentarios y publicaciones que se produjeran, porque quería crearme una opinión propia, sin influencias ni condicionamientos.

Y, además, quería leerla tranquilamente, capítulo a capítulo, y no 'de un tirón'.

De ese aislamiento, o recogimiento, buscado, y de esa calma...conviviendo con un gran pico de trabajo, nace esa distancia en el tiempo que pueda parecer una pérdida de oportunidad.

Un mini resumen

Aunque inicialmente pensaba en hacer una especie de resumen comentado de la encíclica, al final casi prefiero transmitir algunas sensaciones generales y alguna reflexión, pero antes, para quien no se haya leído la encíclica (y, por cierto, se sea creyente o no, creo que es aconsejable leerla), hago un resumen rápido.

La encíclica, es bien conocido que tiene como protagonista a la inteligencia artificial, pero lo cierto es que es un documento más amplio y que, posiciones aparte específicas sobre la inteligencia artificial, también transmite otro tipo de preocupaciones morales y, además, realza, y mucho, lo que ha sido y es la doctrina social de la Iglesia, algo que era previsible porque el propio nombre adoptado por el actual Papa, León XIV, era ya desde elección, una clara referencia a León XIII, impulsor de esa doctrina social de la Iglesia.

Brevemente, el contenido de los capítulos es el siguiente:

Introducción: Utiliza como apertura y metáfora bíblica, la contraposición entre la torre de Babel, representando el poder sin referencia a Dios que dispersa y deshumaniza, y la reconstrucción de Jerusalén por Nehemías representando la corresponsabilidad, la escucha y trabajo compartido orientado al bien común.

Capítulo I — Un pensamiento dinámico fiel al Evangelio: Hace un recorrido por la evolución de la doctrina social de la Iglesia, fundamentalmente recorriendo las diferentes encíclicas que se han concentrado en ella. Un recorrido que, claro, tiene en su origen la 'Rerum novarum' de León XIII.

Capítulo II — Fundamentos y principios de la Doctrina Social de la Iglesia: resume los principales planteamiento de esa doctrina social, destacando elementos como el bien común, el destino universal de los bienes, la subsidiariedad, la solidaridad o la justicia social, principios que traslada al mundo digital actual. Añade una cierta autocrítica o examen de conciencia hacia la propia Iglesia católica en materia de trasparencia, rendición de cuentas o la escucha a víctimas.

Capítulo III — Técnica y dominio. La grandeza de la persona humana ante las promesas de la IA: Es, probablemente, junto con el siguiente, el capítulo más centrado realmente en la inteligencia artificial, revisando algunos de sus riesgos e implicaciones para la persona humana. Critica el denominado paradigma tecnocrático y también, y esto no lo esperaba, el transhumanismo y poshumanismo.

Capítulo IV — Custodiar lo humano en la transformación. Verdad, trabajo, libertad: aborda cuatro ámbitos de lo humano a proteger: la verdad, la dignidad del trabajo, la familia y la libertad frente a esclavitudes. En un punto que también me ha resultado sorprendente, no por el hecho en sí, sino por verlo en esta encíclica, el Papa reconoce que la Iglesia no siempre ha reaccionado a la velocidad debida a ciertos fenómenos y, en concreto, lo centra en la esclavitud y pide perdón por esa falta de respuesta de la Iglesia en su momento.

Capítulo V — La cultura del poder y la civilización del amor: Abandona parcialmente, aunque no del todo, el tema de la inteligencia artificial, para centrarse más en el poder y, sobre todo, la guerra.

Conclusión: Propone un programa de vida que se concentra en la fidelidad a la verdad, la inversión en educación, el cuidado de las relaciones y el amor a la justicia y la paz.

Algunas ideas y sensaciones

Más allá de contenidos objetivos que he condensado muy brevemente en la sección anterior, comentar algunas ideas que extraigo o algunas sensaciones que me produce.

En primer lugar, es un documento bien informado. Eso es algo que espero de cualquiera que se pronuncie en este caso sobre la inteligencia artificial: que sepa de lo que está hablando, que hable con conocimiento de causa, no 'de oídas' o con base en mitos. Por supuesto, no me sorprende que una encíclica sea un documento 'bien informado', pero creo que vale la pena ponerlo de relieve

Me parece un documento que aúna firmeza y moderación. Es moderado en el sentido de que no es agresivo ni altisonante pero, a la vez, es firme, criticando claramente, aunque sea con esa moderación, lo que considera que es incorrecto.

Aunque repasa los riesgos de la IA, la perspectiva es sobre todo, la de proteger la dignidad humana en su conjunto. En ese sentido, tienen poco protagonismo problemáticas éticas digamos tradicionales, de la IA, como es lo que tiene que ver con la privacidad.

Me ha dado la sensación de que lo que más preocupa al Papa de la IA, más allá de sus riesgos, es la concentración de poder, que el destino de la IA se encuentre en manos de unos pocos.

Igualmente, y aunque a nivel mediático lo que se ha destacado es la inteligencia artificial, la encíclica pone mucho foco en otros dos aspectos de los que destacaría esa concentración de poder y la guerra.

Igualmente decir que me ha llamado la atención, y me ha gustado, todo el viaje por la doctrina social de la Iglesia. Me ha gustado, digamos intelectualmente, porque explica muy bien, aunque sea de forma breve, en qué consiste y cómo ha evolucionado hasta llegar al momento actual. Pero me gusta, además, por esa sensación que transmite de continuidad, de coherencia, en cierto modo de tradición, que muestra que, por más que la IA sea ahora el último grito y que esta encíclica pudiera parecer disruptiva, lo cierto es que se enmarca en toda una historia, toda una tradición y todo un pensamiento coherente.

De la ética aplicada a la religión aplicada

Cuando se cuenta la evolución de la filosofía, y sobre todo de la ética, se cuenta, yo mismo lo he hecho varias veces, cómo tras unos siglos en el pasado en que gozaron de atención, la filosofía y la ética, como disciplinas, estaban un poco 'muertas', hasta que surgió el enfoque de la 'ética aplicada' en que en lugar de teorizar, de 'filosofar' podríamos decir, decidió centrarse en problemas concretos, modernos e incluso del día a día: la biotecnología, la eutanasia, la ecología... y la tecnología. Y esto ha supuesto un renacer de filosofía.

No puedo evitar pensar que, en cierto sentido, esta 'Magnifica humanitas', como probablemente toda la doctrina social de la Iglesia, más allá de su evidente trasfondo religioso, tengo un algo de esa ética aplicada y si no estaríamos hablando, y me acabo de inventar el término, de una 'religión aplicada'. Y me pregunto si ese enfoque aplicado, aunque quizá más susceptible de polémicas, no puede ayudar a un nuevo impulso de la Iglesia que, al menos en Europa, a ratos parece languidecer.

Una forma de marketing religioso

No sé si es pretendido o no, pero diría que esta encíclica ha sido una especie de 'golpe de marketing' para la Iglesia católica y para el Papa León XIV.

El nombre de la encíclica, 'Magnifica humanitas' me parece precioso y excelente para una encíclica que habla de Inteligencia Artificial y de proteger la dignidad humana. Aunque desconozco el proceso, no tengo ninguna duda de que los nombres de las encíclicas se eligen cuidadosamente. Pero en este caso, la elección me parece singularmente acertada.

Otra cosa que me llamó la atención es que se anunciara por anticipado que se iba a publicar y la atención que concitó. No sé si en ocasiones anteriores se anunciaron los 'lanzamientos' de las encíclicas, pero estoy convencido de que pocas o ninguna, generó tanta expectación.

Conscientemente o no, buscado o no, creo que esta encíclica y su publicación han tenido alto impacto mediático, mucho más allá de la comunidad cristiana católica, y han realzado la imagen de la Iglesia y, sobre todo, del Papa León XIV.

Sobre la voz

Hace unos meses, concretamente a finales de Octubre de 2025, fui invitado como ponente en unas jornadas sobre Teología e Inteligencia artificial, en la Universidad Pontificia de Salamanca, una experiencia que recogí en el post ' La Iglesia y el diálogo ético sobre inteligencia artificial: una experiencia, unas lágrimas y un mensaje'.

En ese post explicaba cómo, por cierto celo en el control de tiempos, mi intervención fue 'cortada' sin que pudiera llegar al final, sin poder llegar a las conclusiones y transmitir los verdaderos mensajes que quería transmitir.

Pero publiqué el vídeo de lo que hubiera sido la ponencia completa, incluidos esos mensajes. Es este

Y me satisface ver que, en cierto sentido, esta encíclica recoge algunas de las que eran mis propuestas.

Antes decía que esta encíclica me parecía un documento informado, que 'no tocaba de oídas'. Pues bien, entre los mensajes que no pude pronunciar en las jornadas, estaba el de que cuando abordasen el tema de la inteligencia artificial, que lo estudiaran bien y se informasen, que no 'tocaran de oídas' (en el video 2:56).

Además les hubiera querido decir, que ante los debates éticos en que no tenemos claro qué hacer, la brújula es siempre el valor de la vida humana (en el video, 2:50) y cómo se ve afectado por una tecnología o una solución. 'Magnifica humanitas', ya casi desde el título, adopta la perspectiva de proteger la dignidad humana.

Pero, sobre todo, lo que les quería haber dicho, era que, ante los dilemas éticos planteados por la inteligencia artificial, que la Iglesia católica tenía la posibilidad y casi del deber, de dejar oír su voz (en el video 2:55)

Conclusiones

La encíclica 'Magnifica humanitas' es un documento informado y muy relevante en muchos aspectos incluyendo los debates éticos alrededor de la inteligencia artificial.

Y me alegra comprobar que resuena con los principales mensajes de aquella ponencia inconclusa que protagonicé en la Universidad de Salamanca.

¿Cómo aprenden los agentes de IA?

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 01 Jun 2026 12:30:00 +0000

Los agentes basados en IA, aunque aún en proceso de maduración, son una cosa que roza en muchas ocasiones lo extraordinario, explotando, de formas muy potentes, las capacidades que ofrecen los grandes modelos de lenguaje.

Dejando aparte su autonomía o su capacidad para elaborar razonamiento y planes, ahora me fijo ahora en su capacidad para aprender, aprender a partir ejemplos o de la experiencia en un asombroso remedo de lo que hacen los seres vivos en general y los seres humanos en particular.

Me encuentro leyendo el libro 'Building Applications with AI Agents' de Michael Albada , que me está gustando mucho por cierto, y no he podido dejar de fijarme con mucha atención en la explicación que aporta en el capítulo dedicado al aprendizaje en sistemas agénticos y, en especial, a los denominados métodos no paramétricos de aprendizaje.

Métodos no paramétricos

Es bien sabido que el aprendizaje durante el entrenamiento de modelos de machine learning se produce, en la inmensa mayoría de los casos, mediante el ajuste de los parámetros del modelo.

Y es bien sabido que los modelos de IA generativa se basan en formas más o menos sofisticadas de redes neuronales donde, en general aunque no únicamente, los parámetros que se ajustan son los pesos de las conexiones entre neuronas.

Sin embargo, una propiedad que podemos comprobar casi como meros usuarios de ChatGPT o Claude, es que estos sistemas son capaces también de aprender sin un 're-entrenamiento' explícito o, por mejor decir, sin necesidad de ajustar sus parámetros.

Y es a estos métodos no paramétricos a los que quiero referirme en este post.

En concreto, en la obra citada más arriba, se nos hablan de tres:

Aprendizaje mediante ejemplos
Reflexión
Aprendizaje mediante la experiencia

Veamos estos tres tipos brevemente.

Aprendizaje mediante ejemplos: 'few-shot prompting' estático y dinámico

Esta primera forma es muy conocida y está abundantemente explicada y documentada. Se trata, simplemente, de proporcionar en el propio 'prompt' ejemplos de cómo se realiza la tarea. Estaríamos hablando, pues, de la técnica conocida como 'few-shot prompting'.

Sin embargo, en ese formato, en que los ejemplos se incluyen en el propio 'prompt', hablamos de un 'few-shot prompting estático , donde realmente, es el usuario el que 'manda'.

Existe una variante muy interesante que es el 'few-shot prompintg' dinámico. En este caso, se dispone de una base de datos vectorial (como las que se utilizan en la técnica de RAG 'Retrieval Augmented Generation' donde almacenamos los ejemplos de que disponemos. En este caso, ante un 'prompt', es el agente el que busca el o los ejemplos más adecuados en esa base de datos vectorial, usando mecanismos de búsqueda semántica (basada en significado no en coincidencia exacta de palabras clave), de la misma forma de nuevo, que se hace en RAG.

De hecho, creo que no sería incorrecto considerar que este 'few-shot promting dinámico es una forma particular de RAG.

Además, entiendo que, una vez que se dispone de esa base de datos de ejemplos, ésta puede ser enriquecida por el propio agente (o una comunidad de agentes), con lo cual el efecto aprendizaje es mucho más real, mas dinámico y evolutivo.

Reflexión

Siempre me ha llamado la atención este mecanismo de reflexión ('reflection'), identificado mediante un nombre que me resulta misterioso en la medida en que emula en ese nombre, evidentemente de forma intencionada, a una capacidad cognitiva humana tan profunda como es la reflexión.

Sin embargo, cuando se entiende bien, no es tan mágico (siempre que no consideremos casi mágico, claro, el propio funcionamiento de los grandes modelos de lenguaje.

Explicado como reflexión ('reflection') suena muy espectacular y sofisticado y, en cierto sentido lo es, pero lo es en la medida en que un gran modelo de lenguaje es realmente sofisticado porque, disponiendo de un buen modelo de lenguaje, el mecanismo de reflexión no es tan complejo

Lo que se hace es que el sistema agentico hace auto-crítica ('self-critique') ante un intento fallido de realizar una tarea. Para ello, claro, tiene que en primer lugar detectar que la tarea no se ha realizado correctamente (para esto, en algunos casos, podría tener ayuda externa en forma de feedback humano o medida de algún tipo de sensor, indicador o mensaje de error).

Una vez que ha comprendido que algo no ha ido bien, hace esa crítica y almacena 'sus conclusiones' en una memoria específica en que une esa reflexión con las acciones realizadas y lo observado.

Y luego, cada vez que el agente va a realizar una nueva acción, busca las últimas 'reflexiones' en esa memoria y adecúa su comportamiento (es como incluir esas reflexiones en el contexto o el prompt... de hecho, eso es lo que hace).

Aprendizaje experiencial

El aprendizaje experiencial, en el fondo, es una evolución o ampliación del mecanismo de reflexión pero añadiendo un aprendizaje cruzado entre tareas. Es decir, no se trabaja sólo con las reflexiones de la misma tarea sino también de otras diferentes que se contienen en los denominados 'insights'.

Y existe una, digamos, gestión dinámica en el tiempo de 'insights' en que unos aparecen, otros desaparecen y existe una suerte de votación para que el agente tenga nociones de cuáles son los más relevantes o útiles.

Perplejidad

Sorprende, o al menos a mi lo hace, cómo un mecanismo cognitivo tan sofisticado como es el aprendizaje, se consigue de una forma relativamente sencilla y fácil de entender.

Creo que esto es una demostración de dos cosas: por un lado de la enorme potencia y versatilidad de los grandes modelos de lenguaje y, por otra, del indudable ingenio de las personas que diseñan estos mecanismos.

Siempre nos quedará el 'fine-tuning'

De todas formas, la cosa no acaba a aquí. Si estas formas no paramétricas de que los sistemas agénticos aprendan no son suficientes, siempre nos quedarán los métodos paramétricos, el famoso 'fine-tunning' en que, mediante un entrenamiento adecuadamente dirigido podemos añadir nuevas capacidades o una mejor adecuación a los modelos de lenguaje en que se basan los agentes.

Conclusiones

Los sistemas agénticos presentan unas notorias capacidades de aprendizaje, sorprendiendo, por un lado, que son relativamente simples de entender e implementar y, por otro, que no precisan en general de un re-entrenamiento, al menos no un re-entrenamiento de los que alteran los parámetros del modelo: Y, por si esto fuera poco, una vez implementadas estas capacidades de aprendizaje, pueden funcionar de manera autónoma.

Increíble ¿verdad?

Gran Vía. El valor de la tradición y los símbolos

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 28 May 2026 11:45:00 +0000

No sé, estimado lector, si habrás escuchado las noticias del mundo de los negocios que anuncian que está a punto de cerrarse la venta del edificio de Telefónica en la Gran Vía de Madrid.

Como empleado que fui durante más de 25 años de esta compañía, y como alguien que siempre ha estado orgulloso de ese pasado 'telefónico, en este post, quisiera realizar una breve, pero sentida, valoración de esta operación.

La operación

No he tenido apenas tiempo para informarme del detalle de la operación pero, al parecer, la transacción, aún no cerrada en el momento de escribir este post, estaría en una horquilla entre los 120 y 200 millones de euros.

Ignoro el destino que le daría al edificio el principal candidato a comprador actual, el empresario Tomás Olivo, pero dada la naturaleza de sus negocios y la situación del edificio, parece que estaría destinado a convertirse en centro comercial.

Para Telefónica, en apariencia, el objetivo es puramente financiero, fundamentalmente reducir deuda y se enmarca un un plan de 'desinversión' (es decir, venta) de activos 'no estratégicos'.

¿Es una buena operación?

Una 'no valoración' financiera y estratégica

Sinceramente, no me atrevo a juzgarlo de forma rigurosa y por ello, aunque voy a apuntar un par de cosas, no lo considero una verdadera valoración si hablamos de puro negocio.

Hombre, reducir deuda, así dicho, me parece bien y, hasta donde sé, desde hace unos años Telefónica arrastra un problema de deuda que parece que, aunque no sólo sea por eso, le supone un lastre en bolsa. Eso sí, e insistiendo en que no conozco los detalles y que no tengo perfil financiero, prefiero que la deuda se salde a partir de excedentes en beneficios por operaciones que 'desinvirtiendo', porque esa desinversión siempre supone una reducción de tus activos, en cierto modo de tu valor, por más que esos activos los consideres no estratégicos.

Por lo poco que he leído, Telefónica esperaba obtener 300 millones de euros por esta venta. Si eso era una expectativa real (no una especie de 'farol' para comenzar la negociación) y si realmente la horquilla superior de lo que se decide puede obtener son 200 millones de euros, quizá, desde un punto de vista meramente financiero, estaría malvendiendo este activo, quizá presionada por la necesidad de saldar la deuda o, quizá, porque entiende que sobrevaloró el valor de mercado del inmueble. Pero, vaya Vd. a saber...

Lo de la estrategia, claro, es bastante más intangible. ¿Qué hace que un activo tenga o no valor estratégico?

En cualquier caso, y esto es sólo una impresión personal, no me parece que en este punto Telefónica esté actuando con una visión realmente estratégica. Las visiones estratégicas apuntan al futuro, y no un futuro inmediato, y buscan mejorar la posición competitiva. En esta operación, e insisto una vez mas que es sólo mi impresión, creo que Telefónica actúa 'a corto' sólo buscando reducir una deuda (una herencia del pasado) que la debe estar asfixiando y no está mirando para nada hacia un futuro que no sea inmediato.

Pero no va de esto...

Pero este 'post' no va realmente de una valoración estratégica ni financiera de la operación, temas en los que no me considero especialista y, además, para los cuales necesitaría más información de la que no dispongo.

El post, mis reflexiones y casi diría mis sentimientos, van más en línea con los valores intangibles.

El valor simbólico

El edificio de Gran Vía tiene valor histórico. Se construyó entre 1926 y 1929, fue uno de los primeros rascacielos de Europa y el edificio más alto de Madrid hasta 1953.

Y la dirección de la compañía estuvo durante muchísimos años ubicada en ese edificio, aunque en los últimos años ganara peso Distrito C como sede real de la dirección. Pero, incluso hasta 2025, fue donde se realizaban los consejos de administración.

Es un edificio emblemático de Madrid también con valor turístico.

Y ha sido, especialmente, un edificio emblemático para la propia empresa, la imagen que aparecía una y otra vez en todo tipo de comunicaciones como imagen de Telefónica.

¿Cómo se cuantifica ese valor simbólico? ¿Cómo se pone en la balanza de una operación financiera?

Es cierto que es un intangible pero, sin embargo, a otros intangibles como son las propias marcas (digamos Movistar) se les da mucha importancia estratégica y se les asigna valor económico y no menor. Y, en general, en marketing y comunicación se invierte y, mucho, pese a que cómo dijo hace John Wanamaker, la mitad de eso que se invierte en marketing es un desperdicio (y lo difícil es saber qué mitad).

¿Nos es un activo como el edificio de Gran Vía, con su valor histórico y simbólico, algo parecido a una inversión en marketing? ¿No tiene de verdad ningún valor de mercado? ¿O es que ese valor de mercado es inferior a, digamos, 200 millones de euros?

Tradición, orgullo y pertenencia

Más allá del valor de mercado (un valor externo) ¿Qué hay del valor para la propia compañía y, sobre todo, para sus empleados?

En los discursos oficiales se valora mucho, y cada vez más, el compromiso del empleado, su sentimiento de pertenencia, su orgullo de pertenencia.

Prescindir de un edificio tan emblemático, que ha representado desde siempre a Telefónica, que conecta a la Telefónica actual con la del pasado, que crea una sensación de continuidad, historia y tradición, de algo grande ¿No va en la dirección de despersonalizar a la compañía y sus símbolos y no puede por tanto, afectar a ese orgullo de pertenencia?

¿Influye el directivo?

Me pregunto si esta operación es posible porque al frente de Telefónica se encuentra Marc Murtra, un directivo venido, digamos, 'del exterior', casi 'recién llegado', un directivo que, sin atreverme a juzgar su cualificación y motivaciones, quizá, digo sólo quizá, 'no sienta los colores'.

Me pregunto si esta operación sería posible bajo el mandato del anterior presidente, José María Álvarez-Pallete, quien sí que había estado muchísimos años en Telefónica antes de asumir su presidencia. Y se me ocurre pensar que tal vez, sólo tal vez, Pallete no hubiese vendido el edificio de Gran Vía porque me hago a la idea de que si 'sentía los colores' y probablemente percibiría más ese valor simbólico.

Tristeza

En cualquier caso, no me atrevo, y lo digo ya por enésima vez, a juzgar objetivamente la operación, su sentido financiero y estratégico. Expertos habrá que lo hagan o hayan hecho

Lo que sí digo es que en esta operación, aparte de un inmueble, se venden elementos intangibles que creo que son muy valiosos.

Y también digo que, de forma absolutamente subjetiva, como ex-empleado de Telefónica, como alguien que ha sentido, y siente, profundamente ese orgullo de pertenencia, y he dejado buena huella de ello en varios posts en este mismo blog a lo largo del tiempo) esta operación me produce tristeza, una gran tristeza.

Conclusiones

Según nos dicen las noticias, está cercana a cerrarse la venta del emblemático edificio de Telefónica en la Gran Vía Madrileña.

Más allá de posibles valoraciones estratégicas y financieras, están en juegos elementos simbólicos, casi diría que culturales, y no puedo evitar, a nivel personal, que eso me produzca una gran tristeza y desconsuelo.

El desarrollo asistido por inteligencia artificial y la motivación del desarrollador

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 21 May 2026 08:15:00 +0000

Parece que ningún campo de la actividad profesional es inmune a las transformaciones radicales que la inteligencia artificial trae consigo.

Una de esas actividades es el desarrollo software. Aunque ya desde hace un tiempo una de las modalidades típicas de los modelos generativos era el código, últimamente parece que hemos dado un salto enorme en calidad con aportaciones de agentes de IA integrados en cada vez más entornos de desarrollo, herramientas como Codex o Claude Code y soluciones de Vibe coding como Lovable, Windsurf o Cursor.

Cuando recuerdo mi etapa como desarrollador software, primero desarrollador aficionado y posteriormente como desarrollador profesional en los primeros pasos de mi carrera, no puedo dejar de reflexionar, no sólo acerca de cómo cambia la operativa de desarrollo sino también, lo que motiva a o puede motivar a un desarrollador actual.

Y de eso, de la motivación, es de lo que quería hablar en este post.

La labor del desarrollador tradicional

La labor del desarrollador tradicional, la que yo pude hacer en los años ochenta, noventa o primeros años de este sigo XXI consistía, básicamente, en tomar un problema a resolver o una funcionalidad a conseguir, y trabajar para traducir la solución solicitada o imaginada a un conjunto de instrucciones expresadas en un lenguaje de programación de los denominados 'de alto nivel' como en su momento se hacía con C, C++, C#, Java, Visual Basic o similares. Hoy pensaríamos más, por ejemplo, en python.

A continuación se compilaba (entonces se trabajaba poco con lenguajes interpretados) y se depuraban los errores sintácticos cometidos. Cuando ya se superaba la fase digamos sintáctica, venía el probar el software desarrollado, primero individualmente, lo que uno había hecho y luego, cuando se trabajaba en equipo como era lo normal en entornos profesionales, conjuntamente con lo que habían hecho otros desarrolladores.

Pero destaco, por lo que a motivación se refiere, la fase en que tenías que imaginar cómo traducir a instrucciones de un lenguaje aquello que te habían solicitado o, mejor aún, aquello que habías imaginado que querías hacer.

Solo un apunte metodológico: aunque hablo de imaginar cómo traducir una necesidad u objetivo en instrucciones como parte de la tarea del desarrollador, conocí, por suerte un poco de lejos, entornos en que ese traducir un problema a instrucciones lo hacía un analista funcional, no el desarrollador, y el desarrollador era un mero codificador que no diseñaba, sino que creaba el código fuente a partir de lo que se le indicaba. Esto era común en los desarrollos de sistemas empresariales en lenguaje COBOL y ejecutados sobre mainframe IBM.

Pero los entornos en que yo trabajé, tanto profesionalmente como en forma de afición, eran abiertos y el desarrollador era también el analista y diseñador de lo que hacía.

Mis elementos de motivación

Con frecuencia comento que una de las etapas de mi carrera profesional en que más me divertí, que más disfrute, fue esa etapa de desarrollador.

Primero disfruté una barbaridad cuando trabajaba por puro 'hobby', haciendo código simplemente por divertirme y para conseguir las cosas que yo me imaginaba y usando el inolvidable Turbo PASCAL.

Luego de forma profesional, aunque con mucha libertad de diseño, primero en la empresa asturiana GADD y luego en Telefónica Investigación y Desarrollo.

He dicho que me divertía y que disfrutaba, y mucho.

¿Cuáles eran los elementos de ese disfrute? ¿Cuál era la motivación?

Aunque es difícil racionalizar mucho qué es lo que te motiva, qué es lo que te hace disfrutar, voy a concentrar en cuatro elementos lo que creo que eran mis motores, mis motivaciones, que supongo que compartirían muchos desarrolladores de entonces, puede que también actuales.

El reto

Hablaría, en primer lugar del reto. Encontrar la forma de traducir una idea que tenías en tu cabeza (cuando actuaba como desarrollador aficionado) o que te habían solicitado, en un marco limitado de instrucciones que te ofrecía el lenguaje. Por supuesto, había traducciones obvias, pero lo interesante era cuando bordeabas lo evidente o te metías en campos nuevos. Hoy en día no impresiona, pero en aquella época, hacer elementos gráficos, o introducir música no era absolutamente nada evidente. En otros casos, conseguir eficiencia algorítmica, que el software se ejecutase a buena velocidad y buenos tiempos de respuesta no era tampoco fácil.

El descubrimiento

El segundo elemento, muy relacionado con el anterior, tenía que ver con la investigación y el descubrimiento. Leías manuales, libros y revistas, preguntabas a compañeros, y experimentabas y experimentabas (entonces Internet no estaba generalizado) hasta conseguir lo que te proponías. Tras el reto, venía el descubrimiento de la solución. Aún recuerdo con orgullo cómo descubrí la forma de mezclar código ensamblador con PASCAL, y cómo apoyándome en eso y estudiando la arquitectura HW del ordenador personal, conseguí escribir directamente en la memoria de pantalla (la mayoría de los desarrolladores actuales no creo que sepan siquiera qué era eso, ni siquiera estoy seguro, calculo que no, que el mismo concepto de memoria de pantalla exista hoy en día) y con ello conseguir unas velocidades de escritura entonces casi inimaginables y que me permitieron trabajar con gráficos y animaciones en una época en que ninguna librería ni herramienta te lo daba. Aún recuerdo con orgullo cómo logré generar movimiento de elementos gráficos o cómo logré introducir música apoyada en partituras (si, partituras) que compraba en tiendas de música.

La maestría

Consecuencia de ese descubrimiento buscabas y alcanzabas, o al menos eso sentías, la maestría, el dominio del lenguaje de programación y del ordenador. Sentirte hábil, maestro, es extraordinario, al menos para mí que siempre he apreciado tanto el conocimiento.

El logro

Finalmente, hablaría de la sensación de logro. Un logro que se producía en un doble sentido. Un sentido personal, que tiene que ver con esa maestría que mencionaba en el punto anterior. Pero también una sensación de logro por lo que conseguías, por el programa que funcionaba. Sólo hacer el 'Hola mundo' en un nuevo lenguaje o entorno era altamente satisfactorio pero, mucho más allá de eso, conseguir realizar eso que te habías imaginado y que inicialmente no sabías cómo llevar acabo, como personalmente me sucedió en los casos que he relatado de los gráficos o la música, pero que en realidad fueron muchos más, era una sensación de emoción y plenitud extraordinarias.

Descremado

Con el tiempo, el desarrollo de software, los lenguajes y, sobre todo, las herramientas y entornos de desarrollo han evolucionado y crecido, en busca de hacer esa tarea mucho más fácil y mucho más productiva.

Esa mayor facilidad y productividad, que tiene todo el sentido del mundo desde un punto de vista de negocio, creo que, sin embargo, de cara al desarrollador, al profesional y sobre todo la persona 'desarrollador', ha supuesto una forma de 'descremado', de eliminación de parte de las esencias y diría que encantos, de lo que inicialmente fue el desarrollo de software y también de las exigencias y cualificación requeridas.

Un gran paso de 'descremado': 'low-code' y 'no-code'

Esa evolución hacia la simplificación y la productividad ha sido continua y ha adoptado muchas formas, empezando por el uso de lenguajes de alto nivel frente a ensambladores, la creciente existencia de librerías de componentes reutilizables incluyendo componentes gráficos, etc

Pero quizá un gran salto en el 'descremado' lo hayan supuesto los entornos 'low-code' y 'no-code' que, como su propio nombre indica, apuestan por disminuir e incluso eliminar el código fuente, convirtiendo el desarrollo de software en el uso de herramientas normalmente semi-gráficas, con plantillas y componentes reutilizables y donde se desdibuja la idea de código.

Y tanto se desdibuja que incluso Microsoft acuñó hace unos años el término 'Citizen developer' para designar a un desarrollador no profesional o no especializado, es decir, personas que sin formación en informática ni programación, personas pertenecientes quizá a departamentos de ventas o recursos humanos, capaces de construir sus propias aplicaciones.

Aunque en teoría los elementos de motivación que describí en la sección anterior podrían mantenerse, tengo la sensación de que lo hacen en una medida mucho menor. El reto es menor, puesto que el entorno es mucho más sencillo, aunque siempre hay trucos y aspectos avanzados y el descubrimiento es limitado y, por tanto, la sensación de maestría, aunque calculo que existe, también es menor.

Sólo albergo alguna duda en cuanto a la sensación de logro. Calculo que inicialmente, o cuando utiliza una de estas herramientas un auténticos 'citizen developer' sí puede existir esa sensación de logro, acentuado por el hecho de que, al ser herramientas muy productivos se pueden conseguir aplicaciones muy interesantes. Pero también imagino que esa sensación de logro debe de disminuir a medida que el desarrollador se acostumbra y todas las aplicaciones comienzan a parecerse entre sí.

El desarrollador en tiempos de inteligencia artificial

Y ahora llega la inteligencia artificial a irrumpir, y de qué manera, en el campo del desarrollo software.

Por un lado, tomando la forma de asistentes integrados en los entornos de desarrollo, tradicionales y 'low-code'. Asistentes que te sugieren qué hacer, crean secciones de código (o de flujos en ciertas herramientas low-code), depuran ese código o te hacen sugerencias de depuración.

Por otro lado, como una especie de entorno completo o casi completo de desarrollo donde el no sé si seguirle llamando desarrollador, pide en lenguaje natural lo que quiere, incluyendo entornos que prometen la capacidad de crear aplicaciones completas a partir de 'prompts'.

La motivación del desarrollador en tiempos de IA

Actualmente hay preguntas y debates acerca del propio futuro del desarrollador como puesto de trabajo o categoría profesional, sus perspectivas de empleo y si, incluso, desaparecerán.

Pero ahora me enfoco desde el punto de vista de la motivación.

Parece que cuando te apoyas en IA de forma masiva para desarrollar, queda en cierto entredicho cuánto aportas tú realmente, cuánto hay de reto, cuánto de descubrimiento o cuánto de maestría.

Tiendo a pensar que, de forma similar a lo que comentaba en el caso del 'low-code', algunos restos pueden quedar de los antiguos elementos de motivación. Al fin y al cabo, todavía hay que saber definir la solución y hay que saber proporcionar los prompts adecuados. Quedan vestigios de lo que, al menos en mi caso personal, eran los elementos de motivación, pero me parece que no son comparables en cuanto a intensidad.

Y planteo de nuevo lo relativo al logro. Por una parte, me parece que en cuanto a la aportación a la persona, se consigue mucho menos, que la persona se desarrolla menos y consigue menos para sí misma, pero es cierto que el desarrollo apoyado en IA, o incluso completamente hecho por IA, puede permitir conseguir cosas impresionante en poco tiempo. Puede ser enormemente satisfactoria en cuanto a logro entendido como resultados conseguidos. Y eso sí que puede ser un fuerte elemento de motivación.

Quizá, es que más que de desarrollador, convenga hablar de creadores de soluciones. Quizá es que los elementos de motivación que describía más arriba se centraban más en el propio proceso de creación del software y ahora haya que centrarse más en el producto final, en los resultados, en lo que se consigue.

No sé, se mueve todo tan rápido que es difícil llegar a conclusiones sólidas y, además, la motivación es algo tan personal que no creo que se deba pontificar demasiado al respecto.

Me encantaría saber lo que piensan desarrolladores jóvenes actuales, cuáles son sus factores de motivación y si este desarrollo apoyado, o incluso hecho completamente con IA, les proporciona motivación o no, y en caso afirmativo, con base en qué factores.

Conclusiones

El desarrollo software ha evolucionado muchísimo a lo largo de los años, siendo especialmente relevante la explosión de la inteligencia artificial como ayudante, e incluso casi sustituto, del desarrollador tradicional.

Si, al menos para mí, el desarrollo software ofrecía como elementos de motivación el reto, el descubrimiento, la maestría y el logro ¿Cuáles son los elementos de motivación para un desarrollador actual muy apoyado en IA? ¿Son los mismos? ¿Son otros? ¿Existen?

Figure 03, el caso de negocio y la credibilidad de los robots humanoides

noreply@blogger.com (Ignacio G.R: Gavilán) — Tue, 19 May 2026 13:45:00 +0000

Para cualquiera que me siga en mis medios digitales, no es nada oculto que me fascinan los robots.

Me han fascinado desde pequeñito, desde que leí los primeros relatos de robots de Isaac Asimov. Me fascinaron de adolescente o adulto joven cuando los estudié como parte de la asignaturas, no sé si de 'computadores' o 'regulación automática de mi carrera en Ingeniería industrial

Y me han seguido fascinando desde todos los puntos de vista incluido el ético, que he desarrollado por estudio propio y por mi actividad en OdiseIA (Observatorio del Impacto social y ético de la Inteligencia Artificial) al frente del área de Relación Robots-Personas.

Así que no he podido dejar de asistir embelesado, a la par que reflexivo, a la explosión de los robots humanoides en medios y, cada vez más, en experiencias reales.

Sin embargo, sí que he abrigado alguna duda en bastantes momentos sobre sus plazos de adopción, casos de uso e impacto reales en la industria, en los negocios y en el ámbito doméstico.

Y por ello, ya en este blog he dedicado una serie de posts a especular sobre ellos. En concreto, en Marzo del año pasado, realicé una especulación sobre un eventual mercado para los robots humanoides que recogí en tres artículos:

Especulando sobre un mercado para robots humanoides (I): proposición de valor

Especulando sobre un mercado para robots humanoides (II): segmentos de clientes

Especulando sobre un mercado para robots humanoides (y III): estrategias de desarrollo de mercado

Recientemente, uno de los actores que más están dando que hablar en el mundo de los robots humanoides, Figure, con su robot Figure 03 (F.03), ha saltado a los medios por una experiencia compartida en vivo por YouTube.

Y esa experiencia me hace revisitar algún aspecto de la visión de negocio de los robots humanoides.

La experiencia de Figure

La experiencia de Figure consiste en que ha puesto un equipo de robots Figure 03 trabajando ininterrumpidamente (el equipo, aunque los robots se turnan) en una tarea simple del sector logístico y en competencia con un equipo de personas humanas.

No he visto la descripción de la tarea (que seguramente esté en alguna parte y no difícilmente accesible) pero sólo con observarlo unos minutos creo que se deduce: al robot (o humano), le llegan por una cinta transportadora paquetes. Estos paquetes se presentan en dos formatos: por un lado lo que parecen unas bolsas de plástico de tamaño bastante uniforme, y, por otra, cajas de cartón de diversos tamaños.

Las bolsas o cajas contienen algo en su interior que parece bastante ligero. Y tanto las bolsas como las cajas llevan pegada una etiqueta de cierto tamaño.

Lo que hacen los robots (o los humanos) es, simplemente, colocar tanto bolsas como cajas de forma que la etiqueta quede en la parte inferior, mirando hacia abajo, y luego empujan a la bolsa o caja para que siga su camino por la cinta transportadora.

Imagino que, en una línea de producción, más adelante hay algún lector de esas etiquetas (quizá otro robot) que necesita que éstas se encuentren boca abajo

En el momento que esto escribo, aunque se puede ver todavía la emisión en directo, creo que no existe un vídeo ya grabado, así que adjunto un vídeo anterior de Figure en que se ve a un robot haciendo una tarea similar.

Y, en el momento en que esto escribo, el equipo de robots lleva trabajando 6 días consecutivos (en concreto, 140 horas) y clasificado más de 175.00 paquetes.

Cuando vi a los robots, me quedé con la idea de que era una tarea artificial, de laboratorio, sólo para poner a prueba algunos aspectos de los robots.

Tras ver un video de los humanos haciendo la misma labor, empiezo a tener alguna duda de si se trata de una actividad artificial o, realmente, en centros logísticos hay personas haciendo exactamente esto o algo muy parecido.

Razonamientos sobre la proposición de valor

Cuando hace ya más de un año especulé sobre la proposición de valor de los robots humanoides, aportaba como un factor a su favor, la versatilidad y, como posibles factores en contra hablaba del coste, de la madurez tecnológica y del valle inquietante.

Dejo para más abajo el razonamiento sobre versatilidad y coste, pero quiero hacer un par de observaciones sobre los otros dos puntos.

En cuanto a la madurez tecnológica, creo que esta demostración muestra que, aunque quizá todavía para ciertos casos de uso aún nos falte un tantito, existen algunos otros casos de uso, como éste, en que ya es suficiente o estamos muy cerca con la capacidades actuales de robots humanoides.

He oído que el equipo de robots cometió más errores que los humanos (aunque desconozco las cifras) pero, con base en lo que he podido observar personalmente en la emisión en directo, está claro que los robots cometen pocos errores. Esto quiere decir que, a poco que se mejore el algoritmo o se les entrene más, pueden estar al nivel humano o superior. Es más, especulo que si ponemos a dos equipos de robots en serie, haciendo lo mismo, la tasa de errores será mínima, aunque eso duplicaría el coste.

Y, si eso es así, si los robots son capaces de realizar la tarea razonablemente bien, y si es una tarea real, sólo hay que razonar el aspecto económico que viene luego.

En cuanto al valle inquietante, observo que el diseño de Figure, como el de Optimus, como el de Atlas y como, en general, el del resto de propuestas de robots humanoides, lo evitan claramente. Aunque el robot es humanoide, no tiene cara ni intenta extremar para nada el parecido con un humano. Es decir, evitan el valle inquietante, lo que tiene mucho sentido.

Razonamientos sobre el mercado y el sector industrial

En cuanto al mercado (segmentos de cliente), entre los que consideraba hace un año, mostraba alguna reserva con el sector industrial, sobre todo porque pensaba (en el fondo todavía tengo alguna reserva) si para ese entorno no pueden ser más adecuados los robots industriales más clásicos.

Estrictamente hablando, la demostración de Figure no es del sector industrial, sino del logístico, pero no parece un escenario demasiado alejado de casos de uso industriales, aunque, en el caso de esta demostración se centre en un caso extremadamente simple y la manipulación industrial muchas veces sea más compleja.

Lo que me pregunto, y no sólo desde la mera capacidad, sino desde factores más de negocio, si esta misma tarea no la podría realizar, por ejemplo, un 'simple' cobot.

Razonamiento sobre el caso de negocio

Pero quizá, lo más interesante, me parece, es razonar sobre el caso de negocio, es decir, sobre los aspectos económicos del mismo. La verdad es que los precios de los robots humanoides no se publican demasiado. Creo que, en parte, es porque los mismos fabricantes están intentando decidir su precio y, por otro, porque, en general, son altos y no les conviene mucho publicitarlos.

Desde luego, hay que pensar en varias decenas de miles de dólares o euros.

No veo en la web de Figure el precio de su robot Figue 03, pero en humanoid.guide aparece un precio de 130.000$. Sin embargo, en más de un sitio he visto declaraciones de precio objetivo (insisto que es un precio objetivo) para robots humanoides de en torno a los 20.000$ - 30.000$.

En la demostración que vemos, el equipo de robots sustituye a humanos que, entiendo, por el tipo de tarea, no serían muy cualificados y no cabría esperar una remuneración muy alta. ¿Podríamos pensar, por poner números redondos, en un coste del humano de 25.000$ - 30.000$ anuales?

Dado que el robot trabaja 7x24, podríamos decir que sustituye a tres turnos de trabajo humano (es decir, entre 75.000$ y 90.000$ anuales). Pero es cierto que, también, se necesita más de un robot (aunque sólo sea para que recarguen baterías). De todas formas, si este escenario se reprodujese a escala, creo que podríamos despreciar el tiempo de recarga (podría haber muy pocos robots recargando mientras el resto trabaja) con lo cual, en media, saldría poco más que un robot por línea de producción, es decir, poco más de un robot por cada tres humanos. Es decir, no creo nos equivoquemos demasiado si pensamos en que un robot sustituye, casi, a tres humanos.

Digamos, por ejemplo, que sustituye a 2,5 humanos, es decir, ahorra unos 200.000$ al año. Aunque ahora mismo este análisis tan a 'bote pronto' no parece ni mucho menos definitivo (habría que considerar más costes y circunstancias), sí parece que en menos de un año, el robot podría estar amortizado. ¿Cuánto es el tiempo de vida de un robot humanoide? No he oído ninguna referencia al respecto, pero parece razonable pensar que nos situamos en el orden de varios años.

No quiero, ni mucho menos, trasladar esta conclusión como rigurosa, ni definitiva, pero sí parece que los números pueden empezar a salir.

Versatilidad y economías de escala

Y es el momento de recordar el tema de la versatilidad.

La versatilidad de los robots humanoides, su capacidad para ser empleados en casos de uso muy diferentes, les facilita el llegar a alcanzar despliegues masivos y, sobre todo, producciones masivas que, con las curvas de aprendizaje y economías de escala que eso supondría, parece que hacen pensar en una bajada muy relevante del precio, quizá hasta esos 25.000$ o 30.000$ que se plantean como objetivo.

Y, en ese escenario, y a falta de análisis más detallados y rigurosos, creo que el caso de negocio sale sobradamente positivo.

Hay una regla muy sencilla: si valoramos en 25.000$ o 30.000$ la remuneración de un trabajador poco cualificado, y se llega a conseguir que ese sea, precisamente, el coste de un robot humanoide, tenemos un 'coste similar' de robot y humano, pero con dos particularidades a favor del robot:

Por un lado, que un robot puede trabajar en 7x24 o casi, es decir, que casi sustituye a tres trabajadores (en tareas en que realmente sea aplicable un trabajo continuo)

Que el coste del robot es una inversión, que aplica el primer año. Aunque posteriormente sea preciso asumir costes de mantenimiento, los costes en años posteriores parece que deben ser mucho más bajos que el primero y eso mejora aún mucho más el caso de negocio

Según eso, parece que, si se alcanza realmente el coste objetivo de los 25.000$ 30.000$ en el robot humanoide, creo que el caso de negocio va a ser muy rentable.

Insisto en que estas son valoraciones 'a vuela pluma', no un análisis riguroso, así que no quiero que se entienda como una conclusión definitiva.

Sí me quedo con las ganas (a ver si en algún momento lo hago) de estimar cómo veríamos este caso de negocio si, en lugar de un robot humanoide, usásemos un robot industrial tradicional o, casi mejor, un cobot.

La credibilidad

Pero hay algo que quiero sacar en conclusión de todo esto, y es lo relativo a la credibilidad de las robots humanoides.

Una demostración como la de 'Figure 03', en directo, durante muchos días, es una prueba de que estamos ya más allá de los meros vídeos demostrativos, y que, aunque aún se produzcan errores, aunque aún haya muchas cosas que afinar, el funcionamiento de los robots humanoides empieza a ser ya una realidad, y que empieza a ser bastante creíble su viabilidad técnica para muchos casos de uso.

Y, por otro lado, y a falta de cierta estabilización de mercado (me refiero en realidad a estabilización de costes y precios), empieza a ser creíble que los casos de negocio puedan salir y que el uso de los robots humanoides pueda llegar a ser (o sea ya en algunos casos) económicamente rentable.

No obstante, aún nos queda mucho que ver, y creo que, de hecho, veremos mucho en los próximos meses.

Conclusiones

Aunque los robots humanoides aún están en evolución tecnológica y no completamente maduros, demostraciones como las de Figure 03 empieza a hacer creíble que los robots humanoides pueden cubrir con éxito casos de uso reales y que pueden ser económicamente rentables.

Operativizar la accesibilidad digital: de la ética a los resultados y la eficiencia

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 14 May 2026 13:10:00 +0000

Por motivos que no viene al caso, desde hace un par de años o así, tengo la oportunidad de participar en acciones de formación en materia de accesibilidad digital.

Se trata de una formación bastante básica, que no me exige la profundización pero, a pesar de ello, esa actividad me ha llevado ya a leer varios libros y documentos en materia de accesibilidad.

Y justo por la superposición de una reciente lectura con una clase sobre accesibilidad, me surgió la reflexión que quisiera compartir en este post.

Accesibilidad digital

Antes de entrar en la reflexión, y para aquel posible lector o lectora poco conocedora del campo de la accesibilidad, un par de explicaciones poco académicas.

Siguiendo a la que probablemente sea la mayor autoridad española en esta materia, Olga Carreras, en su libro 'Accesibilidad Web. WCAG 2.2. de forma sencilla' podríamos definir la accesibilidad (en este caso, 'sólo' accesibilidad web) como:

el conjunto de características que debe incorporar un sitio web, una aplicación móvil o un documento digital para que el mayor número posible de personas en el mayor número posible de circunstancias pueda acceder a él, usarlo y comprenderlo.

Para que lo entendamos: se trata, fundamental, aunque no únicamente, de luchar contra la discapacidad, de hacer que cualquier persona, aunque tenga condiciones que afecten a su capacidad visual, auditiva, motora o cognitiva, pueda navegar, entender y trabajar con un sitio web o una aplicación móvil (y eventualmente con documentos como los PDF que se puedan encontrar en esa web).

Para conseguirlo hay que hacer un diseño web que tenga en cuenta aspectos como los colores (por ejemplo que sean perceptibles y distinguibles por personas con daltonismo), el tamaño de letra, el contraste de colores en texto e imágenes, el tamaño de botones y así un largo etcétera.

Aparte de estos elementos de diseño, y para conseguir que personas con condiciones diferentes puedan ajustar el sitio web a su situación particular, se necesita poder configurar o seleccionar esos tamaños, juegos de colores, tiempos de respuesta, etc

Además, y como apoyo a las denominadas tecnologías de asistencia, muy especialmente lectores de pantalla (JAWS, NVDA, VoiceOver, etc), teclados adaptados, líneas braille, etc, es necesario incluir utilizar de forma muy rigurosa (respectando su semántica) las etiquetas HTML y añadir atributos con información que pueda ser utilizada por estas tecnologías, como el famoso texto alternativo (atributo 'alt') en imágenes.

Aún hay más, es necesario dar alternativas, digamos multimodales, a los contenidos: añadir subtítulos y, si es posible, lengua de signos a los vídeos para que puedan ser percibidos por personas con condiciones que afecten a su audición, añadir variantes tanto visuales como sonoras a cualquier aviso o alarma y así sucesivamente.

Un imperativo ético, a veces legal y con algún interés de negocio

Dotar a los sitios web de accesibilidad es, ante todo, un imperativo ético, porque contribuye a crear igualdad de oportunidades para todas las personas independientemente de su condición. Y en algún caso, como las administraciones públicas, puede ser también un imperativo legal.

Pero, además, para aquellas empresas (o 'influencers') que compiten por la atención o para aquellas empresas que usen masivamente el marketing de atracción y el comercio electrónico puede tener beneficios de negocio al llegar a un público más amplio y facilitar la conversión (obtener pedidos, vaya).

Algunas dificultades objetivas de la accesibilidad digital

Sin embargo, hay que reconocer que, si lo miramos desde un punto de vista técnico y operativo, conseguir la plena accesibilidad de un sitio web no es una tarea ni sencilla ni ligera.

Dejando aparte la necesidad de disponer de diseñadores y desarrolladores de front-end formados en accesibilidad web, hay muchas otras dificultades o trabajos añadidos.

Hay que hacer trabajo adicional (por ejemplo añadir las etiquetas describiendo imágenes o añadir los subtítulos), hay que preparar al sitio web para que sea configurable, hay que añadir opciones multimodales que en otro caso podrían no ser necesarias, hay que añadir subtítulos y lengua de signos y así un largo etcétera. Lo que quiero decir es, eso, que hay trabajo adicional.

Además, hay que tener en cuenta muchísimos factores, porque las discapacidades y condiciones de las personas son muy variadas y llevan a necesidades diferentes que incluso pueden ser contradictorias.

Es muy aconsejable que las pruebas del sitio web se realicen, al menos en algunas fases, con personas con todo el abanico de condiciones sensoriales y cognitivas porque para una persona que no presente estas condiciones es muy difícil juzgar la experiencia que recibe una persona que sí las detente. Pero eso lleva a un equipo de pruebas no tan fácil de conseguir, no pequeño y a pruebas muy manuales, muy artesanales.

Y, por supuesto, hay que disponer de tecnologías de asistencia para probar con todas ellas.

En resumen, si somos realistas, hacer un sitio web accesible supone un equipo con cualificación especial, realizar trabajo adicional y que una parte de ese trabajo sea muy artesanal.

El 'quid' de la cuestión

El 'quid' de la cuestión, la clave de mi argumento y opinión es que, si aspiramos a que se generalice la accesibilidad digital, si queremos que todos los sitios web sean plenamente accesibles, tenemos que dar un gran salto de eficiencia, tenemos que aplicar tecnología y conceptos rigurosos de ingeniería software y de operación.

Un benchmarking con el 'mainstream' de ingeniería de software

Pero tenemos espejos donde mirarnos y muchas tecnologías y metodologías que nos pueden echar una mano.

Algunas son casi, la aplicación directa de técnicas usadas en otros ámbitos, fundamentalmente del software, y otras sería algo más específicas, aunque siempre inspiradas en lo que ya se hace o ya se dispone a nivel metodológico o técnico.

Un poco a bote pronto, propongo, y luego explicaré brevemente, siete vías, siete soluciones o buenas prácticas que creo que se podrían y deberían aplicar. Son las siguientes:

Reutilización y componentes accesibles
Low-code accesible
Un 'responsive' para la accesibilidad
Accesibilidad por diseño
DevOps y automatización
Aprovechar la multimodalidad de la IA
LLMs entrenados en accesibilidad

Algunas de estas propuestas entiendo que ya existen y se aplican, aunque probablemente no de forma generalizada) pero alguna podría resultar novedosa. Paso a describir cada una muy brevemente.

Componentes accesibles

La reutilización de componentes forma parte del ABC de la ingeniería software, algo que se viene promoviendo y llevando a cabo desde hace décadas en el desarrollo de software.

Es una técnica básica de productividad, mantenibilidad y robustez de una arquitectura software. Y presenta otro beneficio y es que, en el caso de algoritmos o tecnologías complejas, un desarrollador muy especializado puede crear ese componente reutilizable, que luego puede ser empleado por desarrolladores con menos conocimientos. específicos.

Aparte de la mera productividad, la reutilización haría que si los componentes básicos son accesibles, los desarrolladores menos expertos podrían construir soluciones accesibles sólo mediante la reutilización de componentes accesibles.

Low-code / No-code accesible

Ya desde hace años existen soluciones denominadas 'Low-code' / 'No-code' que permiten construir software sin apenas conocer, o sin conocer en absoluto, un lenguaje de programación. El 'truco' es, básicamente, que la lógica se define de manera gráfica y que, además, se apoya en componentes y elementos ya predefinidos y de alto nivel (alto nivel en el sentido de ser fáciles de usar pero que implementan lógica compleja).

Por un lado, es una mecánica de desarrollo muy productiva y, por otro, un uso intensivo, consciente o no, de la reutilización que hemos visto en el punto anterior.

La idea sería que las herramientas Low-Code / No-code, muy especialmente las orientadas a front-end, como WebFlow o Bubble, o aquellas que crean interfaces de usuario como Glide o PowerApps, por ejemplo, ya generasen 'de serie', una interfaz accesible o, 'lo más accesible posible'.

La verdad es que no he comprobado ni investigado si ya lo hacen o cuáles sí y cuáles no, pero no soy demasiado optimista. Ojalá me equivoque.

Un 'responsive' para la accesibilidad

Desde hace años, básicamente desde que se generalizó el uso de smartphones y tablets, existe el concepto del diseño 'responsive' (responsivo, en castellano)

Básicamente se tarta de adaptar el tamaño y distribución de los elementos de la interfaz de usuario al tamaño y orientación de la pantalla. Para eso, el código detecta el tipo de dispositivo en que se encuentra y reacciona presentando la interfaz de usuario adecuada.

Se me ocurre que, dado que la accesibilidad lleva a sitios web que se deben poder configurar para que el usuario elija las opciones que mejor le resultan, se podría pensar una forma de 'responsive' en que la interfaz de usuario se adapta a unos perfiles.

Podrían existir perfiles predefinidos para, por ejemplo, personas con daltonismo y la capacidad de definir perfiles personalizados.

La interfaz de usuario, además de averiguar el dispositivo, debería averiguar el perfil para para adaptarse.

¿Existe ya algo así? Es posible, pero no lo he oído mencionar.

El ciclo de vida y la accesibilidad por diseño

Existe un cierto patrón que podríamos denominar 'metodológico' que promueve que, aspectos concretos de una solución software se tengan en cuenta, no al final, en la fase de pruebas, sino en todo el ciclo de vida del desarrollo software, desde el diseño a las pruebas y puesta en producción pasando por el desarrollo.

Así, por ejemplo, en el ámbito de la ética de la inteligencia artificial, se habla de la ética por diseño o, de forma más específica, de la privacidad por diseño.

En el ámbito de la ciberseguridad, nos encontramos con la filosofía 'shift-left' que va un poco en la misma línea, tener en cuenta los aspectos de seguridad en la parte 'izquierda' es decir, el principio) del ciclo de vida.

Pues bien, de una forma más metodológica que técnica, debería hacerse, no sé hasta qué punto se hace, en materia de accesibilidad y podríamos hablar, parafraseando el caso de la ética, de una 'accesibilidad por diseño'.

Automatización de pruebas de accesibilidad

Una gran dificultad son, como hemos dicho, las pruebas de accesibilidad, tanto porque hay que probar casuísticas muy diferentes como porque resulta aconsejable el concurso de personas con diferentes condiciones y discapacidades.

Algo en que se ha avanzado mucho en software es, precisamente, en la automatización de pruebas, un trabajo otrora tremendamente artesanal e intensivo en mano de obra.

Deberíamos de conseguir la automatización 'extrema' de las pruebas de accesibilidad disminuyendo al mínimo la manualidad.

Lo cierto es que existen ya herramientas de evaluación de accesibilidad (por decir una, WAVE, de WebAIM) pero, hasta donde percibo, son relativamente simples y creo que no evitan la necesidad de que sean complementadas por bastantes pruebas manuales.

Creo que harían falta tres cosas.

Por un lado, y suponiendo que yo esté en lo cierto, habría profundizar en las capacidades de las herramientas de prueba (que probasen más cosas).

Por otro lado creo (y a lo mejor esto ya está hecho, pero no me lo parece) habría que darles un, digamos, 'formato', que permitiese integrarlas más fácilmente en el ciclo del software. Por ejemplo, podría disponerse de ellas como librerías python, o como contenedores en entornos cloud o como conectores y/o APIs para entornos Low-Code. No sé, habría que ver la mejor solución (o conjunto de soluciones) pero creo que se entiende la idea.

El tercer punto, puede que sea el más difícil... o no: sería evitar al máximo posible la necesidad (o conveniencia) de emplear como 'testers' a personas con discapacidad. Aunque esto es una apuesta, creo que hay buena base para pensar que se podrían hacer usando inteligencia artificial generativa, sólo entrenando modelos de manera adecuada. Me apoyo para decirlo que ya existen modelos generativos que sirven para 'simular' expertos que prueben otros modelos.

Pues bien, se trataría de preparar a modelos, mediante el entrenamiento o 'fine-tunning' adecuado que actuasen como personas con diferentes condiciones sensoriales o cognitivas (probablemente aplicando luego una especie de 'Mixture of experts'). Es posible que crear estos modelos sea costoso, pero una vez hecho por 'alguien' (Google, ¿Qué te parece?) , podría usarse como una herramienta más.

Ya puestos, hasta podríamos pensar en agentes que comprobasen la accesibilidad, incluso de sitios ya en producción.

DevOps

Y, diría que por supuesto, habría que aplicar la filosofía DevOps, o mejor aún, integrar la accesibilidad como un aspecto más en los pipelines DevOps.

De la misma forma que, en el ámbito de la ciberseguridad se habla de DevSecOps, para una forma de DevOps que tiene en cuenta todos los aspectos de ciberseguridad, debemos hacer una DevAccOps que tenga en cuenta los elementos de la accesibilidad.

Y si hemos hecho los deberes anteriores, convirtiendo los elementos de accesibilidad en componentes estándar, y si hemos logrado automatizar las pruebas de accesibilidad, parece que el resto viene casi por añadidura.

Pero es fundamental: DevOps es, probablemente uno de los mayores saltos en productividad y eficiencia en ingeniería software. No deberíamos dejar la accesibilidad fuera de este marco.

Vibe coding para la accesibilidad

Y ahora que estamos en el 'boom', no solo de los agentes, sino también del código generado con inteligencia artificial, ahora que nos asombran Codex o Claude Code, que se usan cada vez más Lovable, Cursor o Windsurf, qué tal si entrenamos a los modelos que hay por detrás para que el código que generen en materia de interfaz de usuario sea accesible?

Aquí debo apuntar que, quizá, ya lo generen, la verdad es que no lo he podido investigar. Si ya generan interfaces de usuario accesibles, entonces sería fantástico que se usasen cada vez más y, si no es así, sería bueno que sus creadores tomasen nota y tuviesen en cuenta la accesibilidad a la hora de entrenarlos y probarlos

Unas palabras de prudencia y una invitación a la retroalimentación

Unas palabras de prudencia antes de ir concluyendo.

No he podido materialmente investigar hasta qué punto las soluciones y prácticas actuales utilizan las tecnologías, técnicas y metodologías que he propuesto.

Mi sensación es que, caso de que ya se haga, no es de manera generalizada... pero puedo estar equivocado.

En ese sentido, me encantaría recibir 'feedback' y comentarios.

La ética, la voluntad y la inteligencia

La accesibilidad digital, aunque, como he dicho, puede en algunos casos reportar beneficios económicos, es ante todo una aspiración y un deber de base ética.

Pero hablar de ética no debe llevarnos a pensar sólo en buenos deseos o aspiraciones, hablar de ética no debe suponer sólo acciones heroicas o buena voluntad.

Hace unas semanas en mi podcast 'Divergencias' publicaba un episodio que titulaba 'Caridad e inteligencia' que, en esencia, venía a defender el uso de la inteligencia en el ámbito de la caridad, en forma de criterios prácticos orientados a los resultados, la eficiencia y la escalabilidad.

La idea es la misma para el caso de la accesibilidad.

Soy ingeniero y enormemente orgulloso de serlo. Ingeniería es tecnología sí, pero es también resultados, eficacia y eficiencia.

Y creo que en el caso de la accesibilidad, aunque nuestra inspiración sea ética, debemos de actuar como ingenieros y aplicar las tecnologías, metodologías y buenas prácticas que nos lleven a resultados masivos, escalables y eficientes.

Creo que la única manera de conseguir que la accesibilidad sea una realidad, una realidad generalizada, es que sepamos dar el salto de la ética a la ingeniería, que optimicemos y automaticemos, que logremos ser eficaces y, sobre todo, eficientes.

Conclusiones

La accesibilidad digital es una aspiración de base ética en algunos casos reforzada por elementos legales. Pero, por desgracia, estamos lejos, probablemente muy lejos, de conseguir que esté generalizada.

Y me parece, estoy convencido en realidad, de que si queremos que se generalice es preciso ser realistas y prácticos, es preciso simplificar y automatizar, es preciso ser baratos, es preciso aplicar las mejores tecnologías y las mejores prácticas para conseguir ser eficaces y eficientes y conseguir así que el construir sitio web o una solución digital accesible sea rápido y barato.

Geometría y cinemática en grandes modelos de lenguaje: una iluminación y algunas especulaciones

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 06 May 2026 08:30:00 +0000

Es intelectualmente muy bonito, al menos para mí, cuando disciplinas o teorías en apariencia desconectadas, se solapan, convergen y se apoyan.

Es intelectualmente inspirador pero, además, suelo verlo como una forma de confirmación de que vamos en el sentido correcto: si desde puntos de partida o intereses muy diferentes, acabamos en conclusiones parecidas o en solapes, me parece un síntoma de haber acertado.

Recientemente, debido a una interesante lectura, he tenido una suerte de iluminación, o de inspiración, al entrever una conexión entre el funcionamiento de los grandes modelos de lenguaje (en realidad de muchos modelos generativos), no sólo con la geometría sino, más allá de eso, con la física y, en concreto, la cinemática.

En este post, tras detenerme a explicar algunos fundamentos de los modelos de lenguaje, intento explicar la naturaleza de esa iluminación y realizo alguna especulación o alguna pregunta aún sin respuesta.

Recordando fundamentos (I): tokens

Supongo que algunos de los lectores de este blog ya conocerán algunos fundamentos, o puede que más que fundamentos, acerca de cómo funcionan una buena parte de los modelos generativos derivados de la arquitectura transformer, es decir, la mayoría de los que usamos mediante las herramientas habituales como ChatGPT, Gemini o Claude.

En cualquier caso para beneficio de aquellos que pudieran no conocerlos, y para ganar un punto de partida común, recuerdo un par de conceptos.

Así, en primer lugar recordar el concepto de token. El token es la unidad con la que trabajan los grandes modelos de lenguaje, generando token a token. Cuando nos centramos en los grandes modelos de lenguaje, estos tokens son secuencias de caracteres. En muchos casos, los tokens coinciden con palabras. Pero en otros casos pueden ser simples caracteres (incluyendo signos de puntuación), o la raíz de un verbo o un sustantivo. Además, existen tokens para representar elementos especiales como fin de texto o una máscara. Para una visión intuitiva, aunque no exacta, podemos pensar en los tokens palabras, pero sabiendo que no siempre es así.

Cada modelo utiliza un vocabulario cerrado (una especie de catálogo) de tokens, que difiere de modelo a modelo. En esos catálogos cada token tiene un identificador ('token ID') que no es más que un número entero que identifica al token en ese vocabulario. Un modelo sólo es capaz de generar texto de salida recombinando esos tokens de su vocabulario. Estos catálogos tienen del orden de decenas de miles (e incluso centenas de miles) de tokens. Así, por ejemplo, el modelo GPT-4o de OpenAI usa un vocabulario en el orden de los cien mil tokens diferentes.

Recordando fundamentos (II): embeddings

Externamente, la visión de un gran modelo de lenguaje se basa en los tokens: nuestro prompt de entrada se descompone en tokens antes de ser procesado, la ventana de contexto contiene tokens y su tamaño se 'mide' en tokens, el texto de salida se genera token a token y no es rara la facturación o límite de uso con base en tokens.

Sin embargo, internamente, los modelos trabajan no exactamente con tokens sino con 'embeddings', .

¿Qué es un 'embedding'?

Un 'embedding' es un vector, un vector que no es más que una serie ordenada de números (habitualmente números reales). La dimensión (cantidad de números del vector) es diferente según el modelo: en los caso más modestos solemos estamos hablando de una dimensión de en torno a varias centenas y, en los mayores, de unos pocos miles.

Uno de los grandes 'trucos' de los modelos de lenguaje, es que estos vectores, estos 'embeddings', no son arbitrarios, sino que son portadores de contenido estructural (morfo-sintáctico) y, sobre todo, semántico, es decir de una forma de significado. Este contenido semántico, esta especie de significado. se le confiere durante el entrenamiento.

En efecto, a cada token del vocabulario, y durante el entrenamiento, se le asigna un 'embedding'

Sin embargo no sólo se utilizan los 'embeddings' estáticos de los tokens: durante el funcionamiento del modelo, se calculan y/o añaden otros 'embeddings' como los posicionales que dan cuenta de la posición de un token en un texto como el 'prompt'.

En cualquier caso, lo importante, es que trabajamos con vectores que nos añaden, fundamentalmente dos cosas:

Capacidad de tratamiento mediante álgebra lineal
Contenido estructural y semántico

Espacios vectoriales y espacios de significados

Desde un punto de vista algebraico, pues, los 'embeddings' se sitúan en una estructura que, en álgebra lineal, se denomina espacio vectorial.

Estos espacios vectoriales tienen unas ciertas características y disponen de una serie de operaciones como suma de vectores, producto escalar o producto vectorial, operaciones que, por cierto, se utilizan en el entrenamiento y la inferencia.

Geometría de grandes modelos de lenguaje

Pero, en cierto sentido, el utilizar vectores en un espacio vectorial, nos lleva a unas primeras ideas de geometría.

En efecto, la forma más sencilla e intuitiva de un espacio vectorial, los constituyen los sistemas de coordenadas en dos o tres dimensiones que usamos para fijar posiciones de objetos 2D o 3D (las famosas coordenadas x,y,z). En estos sistemas de coordenadas, un vector nos fija fundamentalmente la posición de un punto.

En estos espacios podemos disponer de rectas o planos. Y si consideramos que los vértices de figuras bidimensionales como un rectángulo o un hexágono, o tridimensionales como un cubo o pirámide, son puntos en ese espacio de coordenadas, podemos también describir y posicionar objetos geométricos.

Claro, en el caso de los grandes modelos de lenguaje, hablamos de unos vectores, los 'embeddings', no de dos o tres coordenadas sino de cientos o miles, pero las reglas matemáticas que los gobiernan son exactamente las mismas (son todo espacios vectoriales con las mismas características y operaciones).

Distancias

Tan es así que si, la interpretación geométrica de los 'embeddings' es tan cierta, que, si en espacios de coordenadas podemos calcular distancias entre puntos, en el caso de los los 'embedding' se calculan distancias entre 'embeddings'.

Y esas distancias son fundamentales, porque, dado que los 'embeddings' portan contenido estructural y semántico, una distancia corta nos habla de significados parecidos o uso conjunto habitual, mientras que una gran distancia nos habla de lo contrario, de un significado muy diferente o un uso conjunto muy poco habitual.

Y en la generación de un texto de salida, determinamos 'por dónde' debe andar el 'embedding' de salida y, con base a él, qué token o tokens son los más probables.

Espacios vectoriales y espacios de significados

Por tanto, los modelos de lenguaje, utilizan los 'embeddings' que son vectores y que forman parte de un espacio vectorial.

Pero, dado que los 'embeddings' son portadores de significado, dado que sus coordenadas en ese espacio vectorial indican significado, podríamos hablar de un 'espacio de significados' (término que no me he inventado yo, sino que he encontrado en una referencia bibliográfica que en seguida citaré).

Trayectorias

La fuente a que me refiero es el libro 'What Is ChatGPT Doing ... and Why Does It Work?' de Stephen Wolfram cuya lectura he finalizado recientemente, un libro sugerente y 'iluminador'.

En este libro menciona otro concepto, en cierto sentido geométrico, pero que ya nos acerca una visión cinemática: las trayectorias.

Aunque no profundiza mucho en este concepto, la idea vendría a ser: dado que los 'embeddings' forman parte de un espacio vectorial, y dado que sus dimensiones son coordenadas en ese espacio vectorial, cualquier forma de desplazamiento en ese espacio vectorial sería la descripción de una trayectoria.

Quizá, podemos entender que cuando entrenamos un modelo, los embeddings que representan a los tokens describen una trayectoria hasta asentarse en el lugar (las coordenadas) que les corresponden. O podemos entender que cuando en inferencia realizamos lo que se denomina un condicionamiento (mediante un 'prompt u otro mecanismo orientamos que texto, o qué imagen o qué vídeo o que música queremos generar) le estamos marcando al modelo la dirección o trayectoria que debería seguir

Excurso: cinemática

La cinemática es una rama de la física y, en concreto, de la mecánica que estudia el movimiento de puntos y objetos con independencia de las fuerzas que lo puedan motivar.

Se ocupa de cosas como trayectorias, velocidades y aceleraciones para lo cual, además, suele necesitar de unos sistemas de coordenadas (esto es, unos vectores y un espacio vectorial) y, cuando trabajamos en objetos sólidos, no con puntos, eso nos lleva con frecuencia a usar el álgebra lineal.

¿Una cinemática de grandes modelos de lenguaje?

Ya hemos visto que los 'embeddings', y por tanto los grandes modelos de lenguaje y, en cierto modo, gran parte de los modelos generativos, se sitúan en un espacio vectorial con sus coordenadas y operaciones algebraicas.

Ya hemos visto que se pueden calcular, y se calculan, de hecho, distancias.

Y ya hemos visto, aunque de forma algo más vaga e intuitiva que, en cierto sentido, dentro de ese espacio vectorial se describen trayectorias.

Lo que me pregunto es ¿hasta dónde llega o puede llegar una visión no sólo geométrica sino cinemática de los grandes modelos de lenguaje y sus 'embeddings'?

¿Podemos detallar más el uso de trayectorias? ¿Podemos buscar trayectorias optimizadas (mínima distancia) para acelerar, por ejemplo, la inferencia?

¿Y qué significa una velocidad en este espacio de significados? ¿Significa el ritmo a que nos acercamos, siguiendo una trayectoria, al significado adecuado? ¿Significa lo rápido que hacemos inferencia?

Y, si vamos más allá, ¿Podríamos hablar de aceleración? ¿Qué significaría y cómo la implementaríamos?

¿Tiene sentido todo esta visión cinemática? Y, si lo tiene ¿Cómo podríamos usar lo que sabemos de cinemática para, trasladado a los grandes modelos de lenguaje mejorar sus resultados, su rapidez o su eficiencia? ¿Están usando ya, equipos de desarrollo, laboratorios de empresas o laboratorios de universidades ideas en este sentido?

No sé o no tengo claras las respuestas a esas preguntas porque, de momento, esta idea de una cinemática de modelos de lenguaje (modelos generativos en realidad), es sólo una suerte de iluminación a raíz de una lectura, y no lo he podido investigar ni pensar mucho más.

Pero me resulta inspiradora y, incluso, puede que sea prometedora.

A ver si le doy una vuelta o si consigo leer algo más en esta línea.

Conclusiones

El solape del funcionamiento grandes modelos de lenguaje o modelos generativos en general con la geometría es bastante conocido, reflejado en el concepto de distancia, pero más inspirador, más desafiante y de conclusiones menos claras es cómo podríamos extender ese solape al ámbito de la física y, en concreto, la cinemática, y si tendría sentido usar conceptos cinemáticos como trayectoria o velocidad en entrenamiento, inferencia o cualquier otro aspecto del diseño y funcionamiento de modelos generativos

Ética del riesgo y cuatro posiciones preliminares

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 29 Apr 2026 07:30:00 +0000

El campo de la ética aplicada y, en concreto, de la ética de la tecnología, vive un momento de florecimiento, auge y casi diría popularidad. Y por ello surgen nuevas ideas, nuevos enfoques o nuevas áreas de trabajo.

Un área que he descubierto muy recientemente (no sé si es tan nueva o es sólo que yo la acabo de descubrir) es la llamada ética del riesgo ('risk ethics') y, quizá como otra forma de expresarlo, o como un subconjunto, la ética de la imposición de riesgo.

Ética del riesgo

Descubro este nuevo campo de trabajo en materia ética en el libro 'The ethics of artificial intelligence' de Sven Nyholm', quien aborda brevemente este tema en el último capítulo del libro. El autor nos presenta este subconjunto de la ética de la siguiente manera:

The ethics of risk is, so far, a fairly small subfield within ethics. But it is a field that is quickly growing as philosophical ethics concerns itself increasingly with emerging technologies, on the one hand, and the relation between current generations and future generations of people, on the other hand.

Lo vemos, pues, como un campo emergente de la ética, pequeño pero en rápido crecimiento y que debe dar respuesta de alguna manera a si es ético asumir ciertos riesgos o, quizá más importante, imponer a otros esos riesgos.

Según Nyholm, algunas de las preguntas a que la ética del riesgo debe responder serían:

¿Es admisible desde un punto de vista ético imponer riesgos a otras personas?
Si no está claro que se pueda hacer ¿En qué consiste realmente ese problema ético?
O también ¿Bajo qué circunstancias es éticamente aceptable imponer riesgos a otros?

Para que se entienda el contexto, y aunque el autor se centra sobre todo en el campo de la inteligencia artificial y sus riesgos, existen muchas otras tecnologías que tienen riesgos y que, sin embargo, hemos aceptado, la energía nuclear o los propios coches, por poner un ejemplo. Ambas aportan beneficios pero también comportan ciertos riesgos en forma fundamentalmente de accidentes, que, conscientemente o no, hemos aceptado como asumibles.

Riesgos

Antes de proseguir, un breve recordatorio o aclaración.

Un riego, se puede definir, de manera muy sencilla y compacta, como un problema potencial. Por potencial quiero decir que no es seguro que ocurra, que puede darse o no, y por problema indicamos que, caso de concretarse, su resultado es negativo o dañino.

Esta definición tan compacta, además, nos ilumina sobre lo que, en la pura gestión de riesgos propia de la dirección de proyectos, de la ciberseguridad o de tantos otros campos de gestión, se evalúa fundamentalmente en un riesgo, a saber:

La probabilidad de que ocurra
El impacto en caso de ocurrir

Decisiones

Aunque la ética del riesgo podría aplicar a muchas cosas, parece encajar muy bien con la ética de la tecnología o, más allá, la ética de los negocios.

En efecto, en el ámbito de los negocios (aunque no exclusivamente) se deben adoptar decisiones, decisiones, que siguiendo la sencilla y lógica clasificación que el autor nos sugiere, serán de tres tipos:

Decisiones con certidumbre
Decisiones con riesgo
Decisiones con total incertidumbre

Las dos últimas suponen la asunción de riesgos y, eventualmente, la imposición a terceros de algunos de esos riesgos.

Cuatro grandes posiciones preliminares ante el riesgo

En general, desde el punto de vista ético se considera como mínimo problemático (que no necesariamente inaceptable) el imponer riesgos a otras personas. El autor no profundiza mucho, y tampoco lo voy a hacer yo aquí, en el análisis ético, pero sí nos presenta cuatro grandes respuestas o cuatro grandes posiciones que se pueden dar, desde un punto de vista ético a esa imposición de riesgos.

Primera posición: Se considera ético imponer riesgos siempre que no suceda nada malo realmente. Esta es una posición no muy popular y bastante discutida. De hecho, personalmente la considero un poco absurda: es como decidir a posteriori si algo fue ético, en función de que el problema, el daño, se haya concretado. A lo mejor es útil desde un punto de vista legal, pero no lo veo como una guía ética para la toma de decisiones.

Segunda posición: Se pueden imponer riesgos a terceros si eso forma parte de un empeño que, en conjunto, puede beneficiar a la media de la sociedad. Es una visión, como reconocerá el lector avezado en ética, claramente utilitarista. Es discutida desde puntos de vista que apelan a la falta de equidad en la distribución de riesgos o a que no se tienen en cuenta los derechos de las personas.

Tercera posición: se puede imponer riesgos a otras personas si éstas consienten en asumirlos. No puedo evitar que esto me recuerde al 'consentimiento informado' utilizado en atención sanitaria o, aunque no es exactamente lo mismo, al consentimiento al tratamiento de datos personales que exige el reglamento de protección de datos. Se piense lo que se piense de esta opción, hay que tener en cuenta que, con frecuencia, no es viable consultar a todas las personas afectadas por un riesgo

Cuarta posición: un poco para salvar eta dificultad, la cuarta opción propuesta es considerar los riesgos que las personas tendrían buenos motivos para aceptar, en caso de que se las pudiera consultar. Tiene lógica, creo, pero es un poco especulativa.

Es evidente que hay mucho más que analizar y debatir todavía, pero lo dejaré aquí porque este era un post meramente introductorio y porque la fuente en que me baso tampoco se extiende mucho más.

Conclusiones

El riesgo es inherente a la actividad humana y, cuando adoptamos decisiones, es prudente tenerlo en cuenta. Esa prudencia no sólo afecta a consideraciones prácticas sino, también éticas, especialmente cuando nuestras decisiones imponen un riesgo a otras personas.

Por ello existe un campo emergente en la ética que trata, precisamente, con el riesgo e intenta dar respuesta ética a cuándo es lícito imponer riesgos a terceros.

Amazon AWS 'breaks guitars': un caso de mal servicio y una queja sin respuesta

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 27 Apr 2026 09:55:00 +0000

Este es una especie de 'post protesta', un lanzar una queja al aire con la esperanza, que no la expectativa, de que alguien tome nota.

Ese alguien debería ser Amazon AWS, que es la empresa de la que me voy a quejar, pero ese alguien también podría ser cualquier cliente potencial de Amazon AWS...para que esté advertido, se lo piense y tome precauciones antes de contratar a Amazon AWS, incluyendo la de buscar una alternativa.

Tengo varias críticas que formular a Amazon AWS, pero la más importante, la verdaderamente importante, es la de su pésimo, en realidad inexistente, servicio de soporte.

Y, a la hora de redactar este artículo, no he podido evitar acordarme del, en su momento, muy famoso caso de Dave Carroll y United Airtlines, que dio origen a un fenómeno viral en Internet con la canción titulada 'United breaks guitars'.

Sobre Amazon AWS

Aunque Amazon AWS ('Amazon Web Services') creo que es bien conocida, por si acaso recuerdo que se trata de la división de cloud computing de Amazon, una división que le genera grandes beneficios al gigante online, una división a la que le cabe el mérito de haber sido quien inventó de alguna manera este concepto de los servicios en la nube, y además, una división líder mundial desde entonces del sector, con más de un 30% de cuota, en competencia, fundamentalmente, con los otros dos hiper-escaladores: Microsoft Azure y Google Cloud Platform.

Dada esa relevancia, hace años que la sigo, que he leído libros e informes sobre ella, y que he hablado sobre ella, e incluso hecho sencillas demos, en mis clases, tanto en el ámbito de tecnología y transformación digitales, como de innovación.

Y por eso, desde hace años, la verdad es que no recuerdo cuántos, tengo una cuenta de formación gratuita (supuestamente) en Amazon AWS.

Antecedentes

Hace unos par de meses o así, y de cara a una formación, decidí que era una buena idea hacer un pequeña demo, una demo grabada, del funcionamiento de Amazon SageMaker, el conjunto de herramientas y servicios de Amazon en materia de Machine learning.

Cursé un pequeño MOOC sobre SageMaker y, siguiendo los ejemplos que allí se exponían, configuré un dominio y los recursos mínimos necesarios para, simplemente, visualizar SageMaker, navegar por él y entender mejor lo que ofrece. Al hacer esto, utilicé mi cuenta gratuita y entendí al profesor del MOOC que lo que estaba configurando también era gratuito.

De hecho, sólo hice la configuración, pero no llegué a crear ningún Notebook, no cargué datos, no entrené ningún modelo, no lancé ningún trabajo. Apenas hice nada más que configurar y entender el entorno.

Esto fue suficiente para poder luego hacer una recorrido demo y grabar lo que pretendía.

Y me quedé tan tranquilo.

Esto debió ocurrir a principios de Marzo.

Los hechos (I): esto no era gratuito

Cual no sería mi sorpresa cuando, dos o tres semanas más tarde, me llega un correo de Amazon diciendo que tenían problemas con mis medios pago para cobrar la factura de Marzo.

¿Factura? ¿Cobrar? ¿De qué me hablan? ¿Pero esto no era gratuito?

Bueno, me pongo a mirarlo y, en efecto, me estaban intentando cobrar la friolera de 743,18$, en una cuenta que se supone es gratuita, por algo que yo había entendido que era gratuito y por no hacer prácticamente nada de computación real.

Aunque yo había entendido que todo lo que había utilizado era gratuito, y aunque me parece una pasada cobrar esa cantidad por no hacer realmente nada, asumí que el error había sido mío, que seguramente en alguna parte en que yo no había reparado, había alguna cláusula que especificaba que eso que había hecho no era gratuito. Así que decidí pagar esa factura por más que me doliese en el bolsillo y que me molestase en su concepto.

En Abril, 6-Abril, exactamente. abrí un ticket de soporte quejándome de los hechos, pidiendo que me lo explicaran y solicitando (aunque sin ninguna expectativa real de conseguirlo) la devolución del dinero. La devolución del dinero no esperaba que se produjera, pero la explicación, sinceramente, sí.

Los hechos (II): defectos de usabilidad e información en Amazon AWS

Lo siguiente, por supuesto, fue darme de baja de SageMaker y de cualquier servicio que pudiera tener contratado sin yo ser consciente, con Amazon AWS,

¿Debería ser fácil, verdad?

Pues no lo es.

No existe una forma sencilla (en realidad, no me consta que haya una forma en absoluto) de visualizar qué servicios tienes contratados con Amazon AWS. Sí que existe una forma bastante razonable de visualizar aquello que te han facturado hasta el momento e, incluso, una previsión de lo que te pueden facturar en el futuro.

Esa visión de facturación, sin embargo, no te lleva directamente a conocer qué tienes realmente contratado. Me explico: Amazon AWS no tiene un esquema sencillo de servicios, sino que unos dependen de otros e, incluso, en el caso por ejemplo de SageMaker, lo que te cobran depende de recursos concretos que hayas creado, no del servicio como tal. Y no existe, al menos que yo haya encontrado, una forma panorámica, directa y razonablemente sencilla de saber qué servicios y recursos tienes y por los que te están cobrando.

Tengo que suponer, y de hecho supongo, que sí existe alguna forma. No me puedo imaginar que una empresa que contrate variedad de servicios de Amazon AWS, que haga uso intensivo de ellos, que pague mucho por ello y no pueda saber qué tiene contratado y configurado realmente. No lo puedo creer, y no lo creo de hecho, pero lo que sí digo es que no es sencillo o, al menos, no evidente.

Y esa dificultad en la interfaz de usuario, ese mal planteamiento de la consola, me parece lamentable en los tiempos actuales y más para el líder mundial de servicios en la nube.

pero lo realmente grave no es esto.

Los hechos (III): la inexistente respuesta de Amazon AWS

A todas estas, claro, mi prioridad era darme de baja inmediatamente de todo, y para eso necesitaba saber qué era exactamente ese 'todo' de lo que me tenía que dar de baja.

Aparte de consultar en la web de Amazon AWS y a ChatGPT, abrí, el 8 de Abril, tres nuevos tickets de soporte pidiendo ayuda para darme de baja en los servicios, cada vez más desesperado ante la para mí inexplicable dificultad de la tarea de ejecutar tal baja y la falta de respuesta de Amazon AWS.

Debo decir, además, que cuando abrí los últimos tickets ya había comprobado que cada día que pasaba sin que lograra dar de baja lo que fuera que tuviese que dar de baja, me seguían apuntando un debe de unas decenas de dólares (¡cada día!).

Al final, llegué a abrir cuatro tickets de soporte en tres días (muestro imagen en la herramienta AWS Support)

¿Respuesta?

De esos cuatro tickets sólo llegaron a contestar a uno de ellos, pero con una respuesta automática, creada con inteligencia artificial generativa y que era insuficiente por genérica, cosa que les hice saber. Lo que me decían, y mejor, ya lo sabía yo a partir de consultas a ChatGPT.

Es decir, es el día en que esto escribo, 27 de Abril, no han contestado al ticket original del 6 de Abril (¡¡¡ 21 días sin contestar!!!), no han contestado a dos de los tickets que abrí el 8 de Abril (¡¡¡19 días sin contestar!!!) y sólo han contestado a uno de los tickets de 8 de Abril, pero no han contestado a mi observación de que esa respuesta era demasiado genérica, respuesta que les di el 9 de Abril (¡¡¡ 18 días sin contestar!!!).

Los hechos (IV): ni siquiera en X (twitter)

Desesperado, acudí a X (antiguo Twitter) lanzando un post de queja y mencionando a diversas cuentas de Amazon AWS: la cuenta de España (@awscloud_es), alguna cuenta general (@aws, @awscloud) y la cuenta de soporte (@AWSSupport) e, incluso, la de Jeff Bezos (@JeffBezos)..

Lo normal cuando haces eso es que, una hora o dos después del mensaje, alguna cuenta te conteste (suponía que la de España), te pida que le sigas, te sigue, y continuas la conversación mediante mensajes directos y, con mayor o menor acierto te ayudan. Al menos esa era mi experiencia hasta ahora con otras empresas.

¿Qué hizo en este caso Amazon AWS?

De nuevo, nada.

Bueno, casi nada. Al final contestó de forma pública la cuenta @AWSSupport, diciendo que habían hablado con su equipo para que revisasen los tickets. Adjunto el post

¿Algún resultado tras esto? ¿Alguna contestación adicional? ¿Algún otro contacto? No, cero 'patatero'. Los tickets siguieron igual, y no hubo más acción por parte de la cuenta de AWSSupport.

Los hechos (V): el fin de la historia

Escribo esto cuando, desde hace unos días, parece que he logrado resolver el problema. A base de consultar a ChatGPT y explorar y recorrer por arriba y por abajo la consola de Amazon SageMaker, parece que he logrado localizar y borrar todos los recursos por los que me estaban cobrando. Desde hace unos días, ya no me acumulan nuevos costes.

Pero, me ha llevado mucho tiempo conseguirlo, en un momento, además, en que tenía un pico de trabajo brutal y lo último que quería era dedicar esfuerzos a nada que no fuese mi verdadero trabajo. Además, y mientras he logrado borrarlo y no, este mes de Abril me han seguido acumulando costas hasta un total de 171,54 $ que seguro que, esto si, me cobran puntualmente sin la más mínima dilación.

Inciso: Dave Carroll y United

Como decía al inicio de este post, he utilizado como metáfora y título el caso 'United breaks guitars'.

Se trata de un caso que se hizo muy famoso ocurrido en 2009, en pleno 'boom' de la web 2.0. El caso se refiere al cantante country Dave Carroll. En un viaje que éste realizó con la aerolínea United Airlines' fue avisado de que los empleados de equipaje estaban lanzando por los aires su guitarra 'Taylor' (que costaba unos 3.500$). El cantante intento advertir de ello, pero no le hicieron ni caso. Al llegar a su destino comprobó que, en efecto, habían roto la guitarra. A esto siguió una larga cadena de acciones por parte del cantante para que United Airlines asumiese su responsabilidad, todo ello sin encontrar respuesta.

Harto de ello, grabó la canción 'United breaks guitars' que se hizo viral (150.000 visualizaciones el primer día). Dejo aquí el famoso vídeo.

Con esto, United no tuvo más remedio que que reaccionar y atender a Dave Carroll

El verdadero problema no son las guitarras rotas

En el caso de Carroll, hubo un fallo de raíz por parte de United, que fue romper la guitarra por descuido o incluso desprecio por parte de sus empleados. Pero, más allá de este error de partida, lo realmente exasperante y mucho más grave, fue la negativa de United a atender la justa reclamación de Dave Carrol.

En mi caso, creo que Amazon AWS muestra fallos en su servicio cuando no explicita claramente qué te da gratuito y por qué te cobra, o cuando no ofrece una consola razonable para tener perspectiva clara y sencilla de tus servicios y recursos y facilitar su gestión y, en mi caso, su baja inmediata. Pero asumo como propio el no haberme informado suficientemente de los costes en que estaba incurriendo o no estar más ducho en el manejo de la consola, y sólo me referiré a esto que creo fallos de Amazon AWS como meras oportunidades de mejora.

En ese sentido, a lo mejor en mi caso debo asumir como problema propio el que la 'guitarra se haya roto' (en forma de servicio de pago) y que 'la broma' me vaya a costar más de 900$.

Lo que realmente es de todo punto inaceptable, es que Amazon AWS no responda (¡¡¡ 21 días sin dar una respuesta!!!)

He pensado que, quizá, 'tardan' tanto en contestar porque estoy en esa cuenta presuntamente gratuita y, quizá, es que por eso no me consideran un verdadero cliente.

Pero, por un lado, la cuenta no ha sido tan gratuita, como ha quedado claramente demostrado y, por otro, para facturarme y cobrarme sí que me han tratado como a un cliente. Es para darme soporte y para atenderme para lo que no me han considerado como un cliente y no me han atendido ni ayudado en absoluto.

¿O es que Amazon AWS trata así a todos sus clientes?

En el estribillo de su canción, Dave Carroll dice:

I should have flown with somewhere else or gone by car... cause United breaks guitars

Y, claro, esa es la sensación que me queda, que debería haber usado otra plataforma en la nube en lugar de Amazon AWS. Y, claro, para futuras formaciones, exploraré Microsoft Azure o Google Cloud Platform e intentaré no volver a recurrir a Amazon AWS. Y pongo en alerta, a quien me quiera escuchar, que tenga cuidado con Amazon AWS y, sobre todo, con su servicio de soporte.

Y es que, aunque sea de manera figurada 'Amazon AWS breaks guitars'.

Conclusiones

Pese a que Amazon AWS es el creador de la categoría de servicios en la nube, pese a que se trata del líder mundial de este mercado, su servicio de soporte deja mucho que desear, en realizad es casi inexistente, al menos esa es mi experiencia personal.

La inteligencia artificial y su contribución a una vida significativa: cinco puntos a considerar

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 22 Apr 2026 08:30:00 +0000

Mucho se debate acerca del impacto innegable de la inteligencia artificial. Su impacto en lo económico, en lo laboral, en nuestro día a día... Y también se habla de las implicaciones éticas, muchas veces, eso sí, acentuando más el aspecto de los riesgos que implica que los beneficios.

En este post quisiera, con base en mi lectura actual del libro 'The ethics of artificial intelligence' de unos de mis filósofos favoritos, Sven Nyholm, ' comentar ese impacto de la inteligencia artificial en un aspecto mucho más importante, aunque quizá elusivo, de nuestras vidas: el significado.

Mi enfoque favorito de la ética

Suelo defender, cuando tengo ocasión en clases o charlas, un enfoque de la ética, que creo que encaja bien con el planteamiento de la eudaimonia de Aristóteles, y que más que en normas, más que en prohibiciones o exigencias, más que en el dictado estricto de lo que debemos o no debemos hacer, pone el foco en el propio valor de la vida humana, en su respeto y, sobre todo, en el desarrollo de sus potenciales, como guía para determinar qué consideramos bueno y qué no y, con base en eso ayudarnos a determinar nuestro comportamiento y nuestras apuestas.

El significado

Y creo que esa visión entronca bien con lo que se suele mencionar como el significado ('meaning') o el propósito.

Se tratará pues, de alguna manera, de hacer que nuestra vida sea digna, sí, pero también significativa, que nos desarrollemos y que aportemos. Cuando Nyholm introduce el tema nos dice:

We will primery focus on wether AI technologies might make us into morally better people, on the one hand, and whether they might make our lives more meaningful, on the other.

Aunque creo que está relacionado, dejamos para otro momento la cuestión de si la tecnología nos puede hacer moralmente mejores o no y nos centramos en el significado.

¿Qué es una vida significativa?

Es cierto que el concepto de significado o vida significativa. puede no estar claro. Puede que cada uno de nosotros considere que una vida es significativa o no por motivos diferentes. Pero, para 'centrar las cosas', acudo a una explicación que procede de la misma fuente unas pocas líneas más abajo, y que nos dice:

The idea of meaning in life is often associated with things such as whether one is part of something “bigger than oneself,” whether one has a sense of purpose in life, and so on. Sometimes philosophers associate meaning in life with “the good, the true, and the beautiful,” so that a meaningful human life is a life in which one does good, one is a truth-seeker, and one gets to enjoy and appreciate different kinds of beauty. Meaning in life is also sometimes associated with notable achievements and accomplishments. Meaning in life is also often associated with living not just for oneself, but also doing things for others and being part of a community. This, in turn, is sometimes related to the idea of making important contributions of different kinds.

En ese párrafo, se identifican una serie de aspectos que dan significado a la vida::

Formar parte de 'algo mayor'
Hacer el bien
Buscar la verdad
Apreciar las diferentes formas de belleza
Alcanzar logros
Hacer cosas por los demás
Formar parte de una comunidad
Hacer contribuciones importantes

Seguramente se le pueda 'dar más vueltas' a qué hace una vida significativa, pero creo que, con esto tenemos suficiente ahora mismo para saber de qué estamos hablando..

Los cinco puntos a considerar

Bueno, pues con ese marco, Nyholm identifica cinco aspectos en que la inteligencia artificial puede influir en el significado de las vidas humanas, ya sea en el sentido de aumentarlo o disminuirlo. Los cinco puntos sobre los que reflexiona Nyholm son los siguientes:

Asunción por la IA de tareas que nos resultan significativas: pensamos que, en efecto, la inteligencia artificial se irá haciendo cargo cada vez de más y más tareas. Si esas tareas que delegamos en la inteligencia artificial son del tipo de las que, por el estímulo intelectual que suponen, por el desarrollo de nuestras capacidades que implican, por la sensación de logro que conseguimos con ellas, o por cualquier otro motivo, son tareas que consideramos significativas, la introducción de la inteligencia artificial podría ir en la línea de disminuir el significado de nuestras vidas al quitarnos tareas que le confieren significado.

Si, por el contrario, la inteligencia artificial nos libera de tareas que no nos resultan satisfactorias pero que nos consumen tiempo y, gracias a eso, podemos dedicar nuestros esfuerzos a tareas que sí nos importan y realizan, entonces, por el contrario, estaría contribuyendo a hacer nuestras vidas más significativas.

En un sentido diferente, si la inteligencia artificial, en realidad como muchas tecnologías, nos potencia, multiplica nuestra capacidad y, por tanto, aumenta nuestras posibilidades de conseguir más cosas, de alcanzar más logros o que estos sean de mayor calado, la inteligencia artificial estará contribuyendo a hacer nuestras vidas más significativas, aunque queda la reserva de lo que se denomina el 'achievement gap', que hace referencia a que, tal vez, el mérito de esos logros pueda no ser nuestro, sino de la inteligencia artificial...lo que podría menoscabar nuestro propio mérito y, por tanto, significado del logro.

En un aspecto quizá más polémico, el cuarto punto se adentra en el terreno de las relaciones, un aspecto que solemos considerar valioso pero en este caso, hablaríamos de las relaciones hombre-máquina. y, en la medida que las máquinas sean más y más 'inteligentes' y en la medida (sometida a mucho debate ético y filosófico) que para la persona la relación con ciertas máquinas pueda ser significativa, la inteligencia artificial estaría contribuyendo al significado vía relaciones.

El último aspecto que considera Nyholm, va justamente en dirección contraria al anterior: si esas relaciones que creemos significativas, en realidad no lo son, si en realidad no son más que una forma de engaño, la contribución de la inteligencia artificial al significado de nuestras vidas, sería negativo.

Es posible que pudiéramos identificar más aspectos en que la inteligencia artificial pueda influir en el significado de nuestras vidas, en un sentido u otro, pero me quedo con éstas que son las que se analizan en mi reciente lectura.

No queda cerrado, ni mucho menos, el debate, ni en este post ni en el libro que lo inspira. En realidad queda planteado, abierto a reflexión, muy abierto.

Conclusiones

La única conclusión clara, creo, es que la inteligencia artificial, desde luego, impacta en nuestras vidas y es posible, sólo posible, que pueda hacer contribuciones a que éstas puedan ser más o menos significativas.

La tecnología como solución: tecnología para la ética y la gobernanza de la IA

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 08 Apr 2026 09:00:00 +0000

Forma parte del discurso habitual sobre ética de la tecnología, particularmente ética de la inteligencia artificial, el ver a la tecnología, en este caso la inteligencia artificial, como culpable, y ya de paso, trasladar esa culpabilidad también a los ingenieros que la crean.

Hace ya algún tiempo hice en este mismo blog un alegato en defensa de los ingenieros y en contra de ese discurso culpabilizador, en el post 'Con el debido respeto: los ingenieros y la ética de la inteligencia artificial' .

En el post que ahora comienzo, salgo en cierto sentido en defensa, no específicamente de los ingenieros como personas y profesionales, sino de la tecnología en sí misma, explicando un poco y destacando el importante papel que tiene en la consecución de una inteligencia artificial responsable y ética.

Y para ello, rescato un discurso que suelo hacer en las charlas y formaciones en que tengo la ocasión de hablar de ética de la tecnología, complementado con algún hallazgo bibliográfico reciente.

Vamos allá.

Tecnología como solución

En esencia, lo que intento trasladar es que, de cara a conseguir una inteligencia artificial ética, no sólo debemos pensar en regular y prohibir, sino que hay otros campos de actuación y uno de ellos, y muy importante, es precisamente la propia tecnología, que ofrece multitud de herramientas, ayudas y soluciones orientadas a conseguir esa inteligencia artificial responsable.

Ya hace un tiempo encontré en 'Manual de ética aplicada en inteligencia artificial' de Mónica Villas y Javier Camacho, una buena panorámica de herramientas tecnológicas.

Vamos a repasar brevemente algunas.

Herramientas para la privacidad

Existen muchas técnicas maduras para garantizar la privacidad y el derecho a la intimidad. En a obra citada los autores nos explican varias que, más a modo de referencia que de verdadera explicación, menciono a continuación:

Anonimización: eliminación de la información personal, privada o sensible de los datos de manera que la información resultante no pueda ser asociada a ninguna persona o colectivo

Privacidad diferencial: Mecanismo que introduce aleatoriedad en la toma de datos de forma que no se puedan asociar a la persona y, sin embargo, es posible eliminar posteriormente el ruido.

Encriptación homomórfica: mecanismos que permiten trabajar sobre datos encriptados sin necesidad de ninguna clave.

Computación multiparte segura: distribuye el cálculo sobre datos entre múltiples partes de forma que ninguna tenga una visión completa.

Aprendizaje federado: modelo de aprendizaje distribuido en machine learning lo que evita que los usuarios tengan que ceder datos.

Datos sintéticos: datos generados artificialmente a partir de datos reales que conservan sus propiedades estadísticas.

Herramientas para la equidad

De cara a la eliminación de sesgos y, por tanto, en busca de garantizar la equidad, también existen una amplia variedad de técnicas y apoyo de herramientas.

En esa línea, y siguiendo la referencia anterior, se dispone de variedad de 'toolkits' (en general implementados como librerías python) para la detección y mitigación de sesgos. Entre ellos, se nos mencionan los siguientes:

Fairml
Fairlearn
Fairness 360 (IBM)
What-if-tool (Google)
Aequitas
Audit-AI
LIFT
Fairmodel
scikit-fairness

Herramientas para la explicabilidad

Algo más complejo es el panorama de la explicabilidad. Pero incluso en este campo, existen planteamientos técnicos y, quizá, como he comentado en algún otro post, los modelos generativos, muy especialmente los razonadores, pueden arrojar una solución completamente nueva y casi definitiva.

Un poco en 'ralentí' a ver si, en efecto, esos modelos son una solución cercana a lo definitivo, algunas técnicas usadas en busca de la explicabilidad, serían:

Modelos inherentemente interpretables: Es decir, siempre que sea posible, usar modelos explicables como puede ser un árbol de decisión, en lugar de modelos no interpretables como una red neuronal.

Sistemas descomponibles: En cierto modo una extensión de lo anterior y donde lo que se propone es descomponer un sistema en subsistemas e intentar que, al menos en sus partes críticas, se usen modelos explicables.

Modelos proxy: Aunque se inicie la resolución de un problema con un modelo no interpretable, como una red neuronal, desarrollar en paralelo otro, sí interpretable, que produzca similares resultados y utilizar ese segundo modelo para las explicaciones. En esta técnica siempre me he preguntado su viabilidad real puesto que si utilizamos un modelo no interpretable es porque consigue mejores resultados que uno interpretable (es decir, los resultados no son iguales y por tanto tengo dudas sobre la calidad de ese 'proxy').

Mapa de prominencia: No es una solución general pero puede ayudar en casos concretos y normalmente a posteriori. Se trata de averiguar el peso que tiene cada entrada del modelo en el resultado final, jugando con escenarios de 'que pasa si' varío el valor de una entrada dejando fijas el resto.

Explicaciones contrafactuales: Parecido a lo anterior intenta, ante un resultado obtenido, averiguar qué tendría que cambiar en las entradas para obtener un resultado diferente.

Guardarraíles como servicio

En una línea algo diferente, hace poco, descubría, con sorpresa y agrado, que en la plataforma 'cloud' líder, Amazon AWS, entre la multitud de servicios de todo tipo y en concreto de machine learning e inteligencia artificial, también se ofrece un servicio ya construido de guardarraíles éticos pensando sobre todo en la creación de aplicaciones basadas en modelos generativos que incorporen estas salvaguardas.

Algunas métricas

En una lectura posterior a la ya citada, en concreto en 'Gobernar la inteligencia artificial' de Benjamin Pride (seudónimo), me encuentro un resumen compacto de algunas de métricas importantes de cara a medir la calidad de los resultados que obtenemos en las soluciones de inteligencia artificial, desde un punto de vista técnico y operativo, pero también ético e incluso de seguridad. Así, el autor nos menciona:

Métricas de precisión y rendimiento técnico: medidas clásicas como accuracy, recall, precision o F1-score y que permiten saber si el modelo sigue acertando en su tarea principal. Se trata de unas medidas más operativas o de calidad, pero también tienen su impacto ético, puesto que decisiones equivocadas, pueden ser injustas.

AUC ('Area Under Curve', Área Bajo la Curva ROC): métrica crítica en modelos de clasificación binaria. Una caída de más de 3 puntos porcentuales frente a la línea base suele activar una revisión.

Indicadores de equidad intergrupal: diferencias de resultados entre colectivos. Indicadores como 'Equal Opportunity' (tasa de verdaderos positivos) o 'Demographic Parity' ayudan a detectar sesgos. El umbral u objetivo que habitualmente se considera es que no se produzcan diferencias de más de un 5 % entre grupos protegidos.

Population Stability Index (PSI): compara la distribución actual de variables con la usada en el entrenamiento. Valores superiores a 0,2 suelen indicar deriva ('drift') de datos significativa y, por tanto, la necesidad de revisión y, probablemente, reentrenamiento.

Métricas de explicabilidad y confianza: métricas derivadas de técnicas como SHAP values o LIME. Miden si las variables que el modelo usa para decidir siguen siendo coherentes con lo esperado.

Pruebas de robustez frente a ataques adversarios: pruebas diseñadas para evaluar la resistencia del modelo a perturbaciones intencionadas. No se trata de medir precisión, sino de comprobar resistencia.

Herramientas para la monitorización

El mismo autor anterior apuesta, con toda lógica, por la monitorización continua, una monitorización basada en las métricas anteriores y automatizada, elevando alarmas y generando evidencias de comportamiento.

El mensaje

Estoy seguro de que existen muchas más metodologías, técnicas y herramientas, pero el mensaje es claro: la tecnología no es 'la culpable' de resultados no éticos. Es cierto que genera problemáticas como los sesgos, pero también es cierto que aporta un abanico rico y amplio de soluciones a esos mismos problemas.

Ahora es 'cosa nuestra' el ser realmente responsables, utilizar esas soluciones y, ya de paso, 'absolver' a la tecnología.

Conclusiones

Aunque es cierto que la tecnología, fundamentalmente en su forma de inteligencia artificial, genera riesgos éticos, la propia tecnología nos ofrece soluciones para esos mismos riesgos.

No culpabilicemos, pues, a la tecnología, y utilicemos de forma responsable las soluciones que nos brinda.

Tecnologías socialmente disruptivas

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 25 Mar 2026 09:00:00 +0000

Estamos acostumbrados a hablar de disrupción cuando la conversación gira en torno a los negocios, en torno a la influencia de la tecnología en los mercados o en torno a innovación y emprendimiento.

Sin embargo, la disrupción puede ir, y de hecho va, más allá, y puede alcanzar a los hábitos y comportamientos sociales y los valores morales. Y, de hecho, recientemente he descubierto el concepto de tecnologías socialmente disruptivas ('socially disruptive technologies') que es el objeto de este post.

Disrupción tecnológica

Antes, y de manera muy breve y no especialmente académica, recordar que, en el ámbito de la innovación tecnológica y de los negocios, se considera que una tecnología es disruptiva cuando, de alguna forma, cambia las reglas del juego de ese mercado, posibilitando nuevos productos y servicios, nuevos entrantes y, sobre todo, desafiando los modelos de negocio establecidos, lo que pone en riesgo líneas de productos, empresas e incluso sectores enteros.

Tecnologías socialmente disruptivas

La idea de tecnologías socialmente disruptivas, no es tan diferente en su núcleo a lo anterior, pero ahora el ámbito es el impacto social y también ético.

He descubierto el planteamiento leyendo el libro 'Social Robots and Cultural Sustainability' editado por Raul Hakli , Sven Nyholm, Marco Nørskov y Sladjana Nørskov y, en concreto, en el penúltimo capítulo escrito por Sven Nyholm donde el autor dice, citando el eBook 'Ethics of socially disruptive technologgies. An introduction' en que el mismo es co-autor, que:

new technologies may also challenge or put pressure on social norms, some of the fundamental concepts we use (such as moral responsibility, personhood, agency, nature, and so on), as well as our conception of ourselves as human beings

En este caso, pues, tenemos un cambio profundo causado por la tecnología, pero cuyo objeto no son los mercados sino nuestras creencias y valores y la concepción de la propia naturaleza humana.

Y, como se ve, se hace este análisis en el ámbito de la robótica social que, como he expuesto en posts en este mismo blog y en cursos y presentaciones, trae, efectivamente, desafíos aún no resueltos a nuestras creencias y a cuestionarnos ciertos aspectos de la naturaleza humana.

Dimensiones para la valoración de tecnologías socialmente disruptivas

A la hora de realizar un análisis de este tipo de tecnologías, insisto que con un enfoque social y sobre todo ético, existe un modelo de siete dimensiones a tener en cuenta, un modelo que se explica en 'What are socially disruptive technologies' de Jeroen Hopster.

Las dimensiones que ahí se sugieren, con algún comentario propio, serían las siguientes:

Profundidad de los impactos: que, con un enfoque fundamentalmente ético, implica hasta qué punto la tecnología desafía o incluso cambia creencias, valores o normas socialmente muy arraigadas.

Rango de los impactos: es decir, cuantos ámbitos de la vida humana se ven afectados por la tecnología en cuestión.

Valencia de los impactos: simplemente, si los impactos son positivos o negativos. Digo simplemente, indicando que es fácil explicar qué es esta dimensión, pero en mi opinión, hay muchos casos en que esa valencia puede estar en discusión, precisamente por estar desafiando, como se decía en la primera dimensión, creencias y valores.

Importancia ética de los impactos: es decir, hasta qué puntos los retos que plantea la tecnología son moralmente relevantes y si, por ejemplo, nos obligan, de nuevo como se decía en la primera dimensión, a reconsiderar nuestras creencias y valores.

Nivel de incertidumbre: es decir, hasta qué punto están claros o no los impactos de la tecnología, considerándose más disruptivos los casos en que esos impactos están menos claros.

Ritmo del cambio: o lo que es lo mismo, la velocidad a que se están produciendo los cambios

Reversibilidad de los impactos: considerándose que, en la medida en que los cambios sean más reversibles, son menos disruptivos.

Se trata de un planteamiento de dimensiones que es razonable, y que 'a toro pasado' parece casi obvio. Y un planteamiento de análisis que, en el fondo, no difiere tanto de cómo podríamos analizar una disrupción tecnológica en marcados.

La necesidad de la reflexión ética

Antes de finalizar esta breve exposición, simplemente insistir en que este tipo de tecnologías nos lleva a replantearnos nuestros valores e, incluso, elementos de la naturaleza humana. Y que, además, al menos en mi opinión, abren debates éticos para los cuales no tenemos una respuesta consensuada.

A bote pronto diría que, en este campo caen, en efecto, tecnologías todas ellas con base de alguna manera en la inteligencia artificial avanzada como podrían ser la propia robótica social, pero también los avatares y humanos digitales o la neurotecnología y alguna tecnología de otros ámbitos como la edición genética.

Conclusiones

Las nuevas tecnologías pueden cambiar radicalmente las reglas del juego, no sólo en los mercados, sino también en nuestras creencias y valores. Y esto da lugar al concepto de tecnologías socialmente disruptivas, que cuestionan nuestro valores y creencias en modos para los cuales, con frecuencia, no tenemos una respuesta clara.

Robots humanoides y la convergencia pendiente a un diseño dominante

noreply@blogger.com (Ignacio G.R: Gavilán) — Tue, 17 Mar 2026 10:25:00 +0000

Asistimos a una cierta efervescencia en el, digamos mercado, de robots humanoides. Lo cierto es que esa efervescencia se produce quizá más en el terreno mediático que en el mercado propiamente dicho, pero sí que hay movimiento a nivel de implicación de grandes empresas, de inversiones, de prototipos.

Alguna reflexión preliminar sobre el mercado de robots humanoides

Algo se mueve, como decía, en este sector o mercado emergente que, sin embargo, está lejos, puede que muy lejos, de ser un mercado consolidado.

En este momento creo que se encuentra en un estado de exploración y de búsqueda.

Busca, creo, en primer lugar, una solución tecnológica suficientemente robusta y, a la vez, suficientemente escalable. Hay grandes avances, pero seguramente no la 'solución definitiva'. Además, hablo de una solución tecnológica pero, en realidad, son muchas decisiones tecnológicas que afectan a aspectos que van desde morfología y materiales, a energía y llegando, probablemente, al nudo 'gordiano' de la inteligencia, el control y el entrenamiento.

Busca, además, quizá sobre todo, el o los casos de uso que, de forma realista, permitan un suficientemente rentable lanzamiento y creación de verdadero mercado.

Y busca, claro, un modelo de negocio, aunque creo que, si los dos elementos anteriores se resuelven, éste tercero no será un obstáculo.

Y pensando en esta situación del mercado de robots humanoides, no sé por qué, esta noche me dio por conectarlo con el concepto de 'diseño dominante' tan importante en el terreno de la innovación tecnológica y que, aunque muy brevemente, ya mencioné en el post 'Especulando sobre un mercado para robots humanoides (y III): estrategias de desarrollo de mercado' . Y del caso de los robots humanoides, es de lo que, brevemente, expondré hacia el final alguna idea, pero antes una parada para recordar en qué consiste esto del diseño dominante

El concepto de diseño dominante en innovación tecnológica

El diseño dominante es un concepto que se maneja en el campo de la estrategia de innovación tecnológica, que creo fue introducido por Anderson y Tushman pero que yo descubrí, hace ya unos cuantos años en el libro 'Strategic Management of Technological Innovation' de Melissa Scheling.

En esta fuente nos dice que el diseño es uno de los patrones comunes en innovación tecnológica y que:

the technology cycle almost invariably exhibits a stage in which the industry selects a dominant design. Once this design is selected, producers and customers focus their efforts on improving their efficiency in manufacturing, delivering, marketing or deploying this dominant design, rather than continue to develop and consider alternative designs.

Claramente, la idea de diseño dominante nos habla, por un lado de una cierta madurez y claridad tecnológica que permite seleccionar ese diseño y, por otro, y como un cierto signo también de madurez, en este caso más de mercado, la búsqueda de un planteamiento más escalable y eficiente que la continua exploración tecnológica.

Motivos para la convergencia a un diseño dominante

Creo que el concepto es bastante explicativo, sobre todo en cuanto a su lógica, pero de todas formas, puede ser bueno revisar los principales beneficios o motivaciones para que una industria, converja y, de alguna manera se ponga de acuerdo, en un diseño dominante.

En la fuente citada, nos explica que las motivaciones giran con frecuencia en torno a lo que se denomina el retorno incremental por adopción (traducción mía de 'increasing returns to adoption'). Lo que esto quiere decir es que en muchas industrias mientras más se adopta más una tecnología, esa tecnología se convierte en más valiosa.

Entre otras cosas, cuanto más se adopta una tecnología, existe, por un lado más recursos económicos para seguirla desarrollando y refinando.

Además, se produce una mayor experiencia acerca de su uso y resultados y, también una mayor conocimiento y entendimiento de la tecnología propiamente dicha lo cual, de nuevo, permite refinarla y mejorarla.

Además, si una tecnología se convierte en dominante, se produce un crecimiento de la oferta de productos complementarios especializados en interactuar con esa tecnología.

En conjunto, todo esto produce una especie de círculo virtuoso, que hace que el diseño dominante gane ventaja y se convierta en más dominante todavía.

Acompañando y potenciando esos retornos incrementales por adopción, tenemos otros dos elementos: el efecto aprendizaje y las externalidades de red.

El efecto aprendizaje nos habla de un hecho comprobado empíricamente y es que, a medida que una tecnología madura y se conoce mejor, ésta se convierte en más efectiva y más eficiente, tanto en su uso como en su diseño y producción. El diseño dominante, al generar mayor adopción, favorece este efecto aprendizaje que, de nuevo, realimenta a ese diseño dominante.

Las externalidades de red, por su parte, nos hablan de productos o servicios cuyo valor aumenta por el hecho de tener más usuarios (como ocurre, por ejemplo, con las redes de todo tipo, ya sean redes sociales, redes de telecomunicaciones o redes de transporte). Estas externalidades de red no sólo se producen en redes como tales sino, por ejemplo, en casos donde la compatibilidad es importante o cuando lo son los bienes o productos complementarios.

Una precaución estratégica: los mercados 'todo para el ganador'

Una advertencia de naturaleza estratégica es que en muchos mercados tecnológicos y, especialmente cuando consolidan en un diseño dominante, esto empuja hacia una gran consolidación e, incluso, a monopolios naturales.

Este efecto 'todo para el ganador', aparte de las eventuales consideraciones regulatorias, impone ciertas dinámicas competitivas porque, evidentemente, cuando todavía el mercado o tecnología no están maduros, las diferentes propuestas lucharán entre sí para intentar que el suyo se convierta en ese diseño dominante y conseguir con ello la posición central y privilegiada en el mercado.

Dicho de alguna manera: para el desarrollo de la tecnología y su mercado seguramente sea muy positivo la consolidación en un diseño dominante, pero para los actores en competencia, supone una oportunidad, pero también un notable riesgo.

La situación en el caso de robots humanoides

Si ahora pensamos en el mercado de robots humanoides, diría que aún es un poco pronto para una consolidación en un diseño dominante. Y lo es porque, pese a los importantes y rápidos avances, no me parece que la tecnología se encuentre suficientemente madura y, además, el mercado como tal es aún muy pequeño.

Por otro lado, en el caso de los robots humanoides, estamos hablando de unas soluciones tan complejas que, en realidad, reúnen muchas tecnologías, varias de las cuales son novedosas y en pleno desarrollo. Quizá, cuando lleguen, podríamos hablar de varios diseños dominantes, cada uno para uno de los elementos tecnológicos.

Aún así, hay pequeños atisbos o gérmenes de posibles diseños dominantes.

Aunque no creo que sea lo más relevante en este caso, en cuanto a aspectos morfológicos, sí observo que varios robots humanoides se parecen físicamente mucho entre sí.

Quizá el aspecto más a tener en cuenta tenga que ver con el hardware y los procesadores, donde NVIDIA, con todo su poder en este campo, se ha situado de forma muy potente con sus últimas propuestas como Jetson Thor.

En el campo de la inteligencia parece que los modelos VLAM (Visión-Language-Action Models), con toda su sinergia con el 'mainstream' actual en modelos generativos (que comenté en el post 'tokens, embeddings y algunos trucos de magia'), pudiera ser la opción favorita, supongo que apoyada en mecanismos más tradicionales de control en el bajo nivel.

En contra de una consolidación a corto plazo de modelos dominantes, se encuentra el que a nivel tecnológico, como digo, creo que aún estamos inmersos en mucha investigación y exploración y que, en cuanto a mercado, también es muy reducido. El diseño dominante parece que exige una cierta madurez (no absoluta, pero si en cierta medida) a la que creo que aún no se ha llegado, y un mercado razonable al que dirigirse

Y probablemente opere en contra la propia lucha competitiva, porque todos los fabricantes principales de robots humanoides, o de algunos de sus elementos, parece lógico que aspiren a establecer su diseño como diseño dominante para conseguir esa posición privilegiada en el sector que les conduzca a ser los ganadores. Así que, parece esperable que, al menos durante un tiempo, se resistan a adoptar diseños ajenos y preferirán seguir desarrollando su propia tecnología.

Eso sí, aunque creo que ni la tecnología ni el mercado están maduros ahora mismo para la adopción de un diseño dominante, las 'cosas' se mueven muy rápido y, a lo mejor, especialmente en lo que a la tecnología se refiere, los avances son rápidos y permiten empezar a avistar posibles arquitecturas o soluciones ganadoras muy pronto.

Habrá que seguir observando muy de cerca.

Conclusiones

El concepto de 'diseño dominante' es muy importante en innovación tecnológica. Si lo intento trasladar al campo de los robots humanoides, me da la sensación de que aún es prematuro pensar en un diseño dominante, tanto por falta de madurez tecnológica como de mercado Sin embargo se trata de un campo que avanza muy rápidamente, así que es posible que no tardemos en ver algún movimiento de consolidación tecnológica o de convergencia de soluciones, que anticipen ese diseño dominante.