Blue chip

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.

Tokens, embeddings y algunos trucos de magia

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

Como es bien sabido y abundantemente citado, el escritor de ciencia-ficción, Arthur C. Clarke, decía en su libro 'Profiles of the future' que

Cualquier tecnología suficientemente avanzada es indistinguible de la magia

Y, en efecto, cuando contemplamos a la inteligencia artificial actual, muy especialmente la inteligencia artificial generativa, es difícil no maravillarse como si estuviésemos ante un espectáculo de magia, una sensación que parece acentuarse ante los resultados tan efectistas que se pueden conseguir en materia de imagen, vídeo o música.

Pero, en mi caso, sin dejar de maravillarme sus resultados externos, visibles como mero usuario, me maravillan tanto o más los elementos de diseño y arquitectura que hay por detrás que y que, aunque menos conocidos, aunque en apariencia menos brillantes, no dejan de ser un canto a la ingeniería, al diseño y, en el fondo, al ingenio humano.

Y, en este post, quiero, intentando mantenerme en un nivel más divulgativo que técnico, explicar algún truco de magia que traen consigo los modelos generativos actuales, basados, de una forma u otra en la famosa arquitectura 'transformer', base, por ejemplo, de los modelos GPT.

Antes, presentar a los protagonistas de los trucos de magia que vendrán a continuación: los tokens y los 'embeddings'.

Los tokens

¿Qué son los tokens?

Bueno, realmente no es fácil dar una definición compacta, abarcadora y a la vez comprensible de lo que son los tokens, aunque en el fondo la idea es muy sencilla. Los tokens vienen a ser como las piezas que constituyen un contenido. Dicho así, a lo mejor no queda muy claro, pero si pensamos en el caso del lenguaje, y pensamos, en primera instancia, que los tokens son las palabras, la cosa queda mucho más clara ¿no?

Ahora que seguramente nos hemos hecho a la idea un poco intuitiva de lo que son los tokens, conviene advertir que, en realidad, los tokens no tienen por qué coincidir con las palabras: en ocasiones son palabras, en ocasiones simples caracteres, en otros caso partes de una palabra (como la raíz de un verbo) y, en otras ocasiones, en fin, algunos caracteres especiales. Lo que queda claro es que los tokens son partes de un texto de forma que, combinándolas, nos dan el texto completo.

Todos los grandes modelos de lenguaje trabajan con un catálogo cerrado de tokens. Por catálogo cerrado quiero decir, que es un número acotado de tokens perfectamente conocidos. Cada modelo maneja su propio catálogo de tokens que suele incluir unos miles o decenas de miles de tokens posibles. Y, usando esos tokens, los modelos son capaces de componer o descomponer cualquier texto en tokens de ese catálogo. De hecho, el primer paso habitualmente de un gran modelo de lenguaje, ante la recepción de un texto de entrada (digamos que el 'prompt') es dividirlo en los tokens que lo constituyen.

Los 'embeddings'

Vale, pues pasemos ahora a los 'embeddngs'. ¿Qué son los 'embeddings'?

No he llegado a averiguar (ni siquiera a intuir) por qué se les asigna con ese nombre 'embeddings' (que tanto cuesta traducir al castellano de forma que se entienda), pero decir que los 'embeddings' son, básicamente, representaciones vectoriales de los tokens. Hilando muy fino en 'las tripas' de los modelos, hay casos en que los 'embedding' no representan exactamente un token, pero no me voy a meter en ese charco para que no se pierda la idea fundamental y vamos a quedarnos, aunque pueda ser una cierta simplificación, con que los 'embeddings' son representaciones vectoriales de los tokens.

Espero que el lector recuerde que, de nuevo simplificando, un vector es una colección ordenada de números reales (en realidad puede ser una colección ordenada de cualquier cosa, pero, de nuevo, voy a prescindir de ello para 'no liar la cosa'). Los vectores tienen un uso algebraico, al que en seguida volvemos, un interpretación geométrica (la representación de las coordenadas de un punto en el espacio) y una interpretación física (una magnitud con dirección). Y los 'embeddings' son representaciones vectoriales de los tokens que van a hacer uso tanto de su carácter algebraico como de la interpretación geométrica.

Van a hacer uso de la visión algebraica, haciendo que los 'embeddings' sean elementos de un espacio vectorial y que sean aplicables sobre ellos todas las operaciones con vectores, matrices y tensores del algebra lineal y todas las transformaciones lineales propias de los espacios vectoriales. Y, así, van a convertir el entrenamiento e inferencia de redes neuronales profundas de los modelos de lenguaje mayormente en operaciones de algebra lineal.

Eso si, los 'embeddings' no son vectores de tres dimensiones como los que utilizamos en geometría normal, sino de cientos o miles de dimensiones.

Primer truco de magia: semántica y conocimiento

Vale, hasta aquí, nos puede parecer bien o mal el uso de tokens y 'embeddings', pero quizá no veamos la magia.

Vayamos a por el primer truco de magia: la semántica.

Esos vectores que son los 'embeddings' no son vectores con valores arbitrarios. Nada de eso: durante el entrenamiento de los modelos se ajustan esos 'embeddings' que con ello alcanzan un valor semántico, de significado. En realidad no se trata de una semántica absoluta, no es que el valor de un 'embedding' nos proporcione, de alguna manera, un significado, como si buscásemos en un diccionario. Se trata de lo que podríamos denominar una 'semántica relativa'.

Entender lo que es esa 'semántica relativa' (término que, por cierto, me acabo de inventar) debemos acudir a la interpretación geométrica de los vectores como representación de la coordenada de un punto en un espacio. Pues bien, de la misma forma que en geometría calculamos la distancia entre dos puntos, en modelos de lenguaje podemos calcular la distancia entre dos 'embeddings', es decir, entre dos tokens, es decir, simplificando un tanto, entre dos palabras.

Y si la distancia entre dos 'embeddings' es pequeña quiere decir que tienen relación de significado y también de uso. Es decir, si la distancia entre dos 'embeddings' es pequeña, quiere decir que su significado es parecido y está relacionado y/o que habitualmente se usan juntos.

Para conseguir eso, claro, hay mucho diseño interno de las redes neuronales que constituyen los modelos, hay mucho de mecanismos como la famosísima atención y auto-atención, etc pero el caso es que, una vez entrenado un modelo, esas relaciones de distancia geométrica, acaba recogiendo, por vía en el fondo indirecta, el conocimiento de la estructura (morfología y sintaxis) del lenguaje humano y, lo que es más increíble, su significado.

¿No es increíble?

Pues espera, que este primer truco tiene una vuelta de tuerca adicional. No es sólo que hayamos conseguido unos modelos que recogen la estructura y significado del lenguaje humanos, es que además... ¡Abracadabra! ... también recoge todo el conocimiento que el ser humano ha volcado en los textos con que se ha entrenado.

Creo que esto se merece un fortísimo aplauso de admiración.

Segundo truco de magia: multimodalidad

Pero la función no ha hecho más que empezar.

Hemos hablado hasta ahora de modelos de lenguaje pero ¿y qué pasa con las imágenes, los vídeos o el sonido? ¿Qué pasa con los modelos multimodales?

Pues, por supuesto simplificando, lo que pasa es que usamos los mismos fundamentos.

Es decir, reducimos las imágenes o el sonido a un catalogo cerrado de tokens (esto, en caso de magnitudes continuas como es el sonido implica un esfuerzo de discretización). Y representamos esos tokens, de nuevo como 'embeddings' que ajustamos en el entrenamiento.

Pero, aún hay más, hacemos que los 'embeddings' de las diferentes modalidad (digamos que texto e imagen) se encuentren en el mismo espacio vectorial y hacemos un entrenamiento conjunto (por ejemplo, con imágenes y sus descripciones textuales) y, de esta forma, tenemos relaciones estructurales y semánticas entre imágenes y texto o entre texto y música pro ejemplo, de forma que luego podamos describir con palabras qué imagen o qué música queremos y el modelo 'nos entienda'

¡Tachán!

Creo que esto se merece otro fuerte aplauso.

Tercer truco de magia: el mundo físico y los robots

Pero ¡espera!, que tenemos otro truco de magia.

¿Qué pasa con el mundo físico? ¿Qué pasa con los robots?

Pues se está trabajando ya en los denominados VLAM (Vision-Language-Action Models), pensados para el mundo físico y, muy especialmente, el control de robots.

Estos modelos trabajan típicamente con dos entradas: por un lado, un 'streaming' de video con lo que recogen las cámaras del robot y una entrada lingüística, típicamente instrucciones de un operador humano.

Hasta ahí, estamos en una situación parecida a los modelos multimodales. Pero lo original es la salida: las acciones. Las acciones son representaciones de lo que tiene que hacer el robot, en algún caso acciones de alto nivel como ('coge un objeto') o, en otras instrucciones de más bajo nivel más próximas a lo que entienden los motores y actuadores del robot.

¿Y, cómo se representan las acciones? Lo has adivinado, como tokens y sus correspondientes embeddings. Y, en el entrenamiento se unen conjuntos de datos con información de video, de texto y de las acciones correctas del robot. En el fondo, es como tratar las acciones en el mundo físico como una nueva modalidad.

El público ya está en pie, aplaudiendo enfervorecido...

Ética y alineamiento ¿Un cuarto truco de magia?

Con esto, casi hemos acabado la función, pero te anuncio lo que puede ser el próximo truco de magia, y que tiene que ver con la ética y con los valores.

Cuando nos preocupamos del comportamiento de la inteligencia artificial, cuando pensamos en seguridad y en ética, hablamos, como un mecanismo de protección, del alineamiento, es decir, que los sistemas de inteligencia artificial compartan los valores humanos y se comporten con arreglo a ellos.

Aunque sugerente, este enfoque tiene alguna dificultad y, una de ellas es cómo formalizamos esos valores humanos para que los entienda una máquina.

Bueno, no voy a entrar en detalles porque en este momento no los tengo pero, minutos antes de comenzar la redacción de este post, estaba leyendo un libro en que se mencionaba (aunque sin explicarlo) algún modelo que ya recoge esta idea de los valores y algún 'dataset' para entrenar en valores.

Y he creído entender que el modelo se basa en la misma arquitectura transformer que todos los que hemos comentado. No sé si se tratan de alguna forma los valores, de nuevo, como si fuera otra modalidad, si se trata de una suerte de 'fine-tunning' de un modelo generativo o si, simplemente, de la misma forma que de manera indirecta los modelos de lenguaje recogían el conocimiento humano, se pueda conseguir mediante un, digamos, 'dataset etico', que el modelo tenga embebidos los valores éticos humanos.

En cualquier caso, el planteamiento parece perfectamente viable y muy esperanzador.

Así que, no dejen de volver para la próxima función de magia.

Conclusiones

Es maravilloso contemplar como los modelos generativos de inteligencia artificial, con base a la idea de los tokens y los 'embeddings' y usando, claro, avanzadas y sofisticadas arquitecturas de red neuronal y estrategias de entrenamiento, han sido capaces, en poco tiempo, de reconocer y saber utilizar el lenguaje humano, de recoger todo el conocimiento con él expresado, de mezclar ese conocimiento con otros medios como imagen, vídeo o música y parece que ahora están consiguiendo incluso expresar las acciones de robots u otras formas de actuadores sobre el mundo físico y, en un último e inesperado giro de guion, parece que hasta nos pueden servidor para recoger los valores humanos y hacer un guiado ético de sistemas y robots.

Ya lo decía Arthur C. Clarke... cualquier tecnología suficientemente avanzada es indistinguible de la magia.

Inteligencia artificial, creación y el proceso interior

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

Comienza a ser un debate recurrente, en algunos casos puede que hasta cansino, la relación del humano con la inteligencia artificial, si nos sustituirá o no, si sólo debe actuar como un copiloto o si afecta a nuestras capacidades cognitivas o no.

En este post quiero hacer una breve reflexión sobre el caso concreto del proceso creativo. Una reflexión que no es teórica, y que no busca realmente un posicionamiento, sino que es una visión muy individual mía, muy experiencial, aunque presumo que sensaciones parecidas las deben experimentar muchas otras personas, y por eso me parece valioso compartirlo.

El salto de la inteligencia artificial generativa

Quizá unos de los ámbitos en que más ha mejorado la inteligencia artificial en los últimos tres años, sea en todo lo que tiene que ver con la 'creación' o, si se prefiere, la generación de contenidos. Unos contenidos que inicialmente, fueron esencialmente textuales, pero en seguida saltaron a la imagen, al vídeo y a la música.

Un proceso, ese de la generación que, sobre todo en el campo del texto, va más allá de una creación mecánica de ese texto, sino que aporta 'conocimiento', datos y estructura. Y que, además, puede incluso hacer uso de resortes emocionales, quizá especialmente destacados en el caso de la generación musical.

Sobre el discutido concepto de creatividad

Se discute mucho sobre lo que es creatividad y lo que no y, sobre todo, si lo que hace la inteligencia artificial generativa es verdadera creatividad o no y, yendo más lejos, si se puede llegar a considerar arte algo creado con inteligencia artificial generativa.

No creo que sea un tema claro, realmente. Me parece, aunque me confieso un poco lego en la materia, que el propio concepto de lo que es el arte es, como diría 'el otro', algo discutido y discutible.

Pero sin llegar a la de idea de arte, y quedándonos sólo en creatividad, se alega a veces que la inteligencia artificial no es creativa porque, en el fondo, reutiliza unos patrones de base estadística que se le han enseñado y los utiliza para sus nuevas creaciones o, si se prefiere, generaciones. No sé si eso es suficiente para decir que la inteligencia artificial no es creativa, y menos teniendo en cuenta que parece que, en el fondo, la creatividad humana funciona, al menos parcialmente, de la misma forma: aplicando a ámbitos nuevos o de formas nuevas patrones que ya ha visto en el pasado.

En cualquier caso, el debate sobre la presunta o no creatividad de la inteligencia artificial, aunque atractivo, no es lo que me ocupa ahora. Para lo que sigue, el que llamemos creatividad o no a producción de contenidos de la inteligencia artificial generativa, me es irrelevante.

Lo cierto es que puede crear textos, imágenes, videos, sonidos y música nuevos y de una alta calidad factual y estética.

¿Dónde quedamos los humanos y nuestra creatividad y nuestro arte, ante todo esto?

Tomándomelo de modo personal

Todo lo que antecede es una exposición de contexto, pero a partir de aquí comienzo con mi experiencia personal. Y para esa experiencia hablaré de mi particular producción de contenidos.

Mi producción de contenidos se centra especialmente en lo textual, en la escritura. Creo textos, por ejemplo, para este mismo blog. He creado, y espero seguir creando, texto para los libros que he publicado o en los que he colaborado. He creado texto como material docente. He creado, incluso, aunque al menos de momento muy poco publicado, texto de naturaleza más artística, del ámbito literario (ensayo, narrativa e incluso alguna especie de poesía).

Para mi labor como 'speaker' y como docente, utilizo también mucho las hoy en día un poco denostadas presentaciones PowerPoint.

En bastante menor medida también creo en otros medios. Creo imágenes como complemento de artículos o presentaciones. Creo algunos vídeos como promoción, como realce de alguna charla o clase... o por el placer de hacerlo. Creo con mi voz participando en podcasts. Y he creado algo de música fundamentalmente como fondo de vídeos.

Para esta creación multimedia, imágenes, video y música hoy en día me apoyo mucho, cada vez más, en el uso de la inteligencia artificial.

Sin embargo, para la voz y, sobre todo, para la creación textual y las presentaciones, pese a que sabría perfectamente cómo hacerlo con inteligencia artificial (es más, de vez en cuando enseño cómo hacerlo) mi mecánica sigue siendo clásica, es decir, genero el texto o las presentaciones por mí mismo, más o menos manualmente, aunque, evidentemente, usando un ordenador, y esporádicamente alguna ayuda de la inteligencia artificial.

¿Por qué ese diferente planteamiento según el contenido que genero?

Pues tiene mucho que ver con lo principal que quiero transmitir en este post: con el proceso interior de creación. Pero antes, un apunte sobre la calidad del resultado generado con inteligencia artificial.

La calidad del resultado

La inteligencia artificial generativa ha avanzado una barbaridad en poco tiempo y los resultados que ofrece son cada vez mejores. Los textos están bien redactados, bien estructurados, con mucho conocimiento por detrás y, en general, 'suenan bien' o incluso muy bien.

La calidad física de imágenes, vídeos y música es muy alta. Por calidad física me refiero a calidad del sonido en música o a la resolución y calidad de imagen en imágenes estáticas y vídeo. La composición suele ser buena, pero aquí, y reconociendo antes mi escasa preparación en materia de diseño o arte visual, tengo algunas 'pegas'. Las imágenes, si uno no se pelea mucho con ellas, y usando prompts cada vez más especializados, suelen ser abigarradas y un poco repetitivas. En el vídeo, se observan todavía con cierta frecuencia las famosas alucinaciones. En general, además, y aunque me imagino que esto se podría superar con práctica, insistencia y un promting avanzado y especializado, las herramientas tienden a generar imágenes, vídeo y música, de buena apariencia, pero un poco 'según le parece' y cuesta guiarla a que realicen tu idea (cuando la tienes). Con frecuencia, si no se pelea mucho, los resultados tienden además a ser repetitivos.

En general, mi sensación es que la calidad de la producción textual, es ahora mismo bastante más alta que la de la producción multimedia, pese a que ésta última nos impresiona muchísimo más.

Y, sin embargo, pese a que la inteligencia artificial genera, en mi opinión, mejores resultados en texto que en multimedia, mi uso es justo al revés, la utilizo mucho en multimedia y poco en texto.

¿No es esto contradictorio?

Pues la respuesta tiene mucho que ver con el proceso interior.

El proceso interior y la experiencia personal

Por el proceso interior, me refiero a mi forma de trabajar en la creación de contenidos, lo que experimento cuando lo hago, y lo que eso aporta al resultado y, sobre todo, a mí mismo. Y un proceso que, aunque describo como propio, me imagino que cualquier otra persona experimenta algo parecido.

En ese proceso interior de creación aportas y recibes.

Veámoslo de forma separada

Lo que aportas cuando creas

Cuando estoy creando un texto de tipo profesional, para publicar o para docencia, aporto por un lado mi conocimiento, todo lo que he aprendido estudiando, leyendo, trabajando o escuchando a otros. Y aporto la experiencia profesional, lo que he vivido en las empresas que he trabajado, los clientes o proveedores con los que he tratado, lo que he visto en jefes y colaboradores. Y, no sólo eso, aporto mi comprensión, síntesis y en ocasiones opinión sobre el tema tratado. La inteligencia artificial puede aportar mucho en cuanto a conocimiento, datos y estructura en este ámbito pero siento, y no quiero ser presuntuoso, que con frecuencia no está a mi altura. Lo que hace es muy correcto y lo cuenta muy bien... pero le falta 'un algo', un algo de discurso, de claridad, de exposición, de perspicacia, a veces incluso de 'alma' o personalidad. Salvo en casos y temas concretos, me gusta mucho más el contenido textual que yo genero que el que me aporta la inteligencia artificial. No es un prejuicio, es lo que veo.

Es importante resaltar, y de nuevo no quisiera ser presuntuoso pero sí claro, que esto es así en parte, por mi propias capacidades, circunstancias y motivaciones. Creo que puedo generar mejores textos que la inteligencia artificial porque atesoro mucho conocimiento, experiencia, lecturas y estudio en mis ámbitos de especialidad, porque además me gusta escribir y tengo mucha práctica en ello y, finalmente, porque soy perfeccionista y me gusta 'hacer las cosas bien' y dar los mensajes correctamente, en el orden correcto, de manera comprensible y, si es posible, incluyendo motivación.

Aún así, reconozco que, en cuanto a aportación, la inteligencia artificial es un gran competidor.

Y es por mi aportación, por lo que, en parte, no utilizo la inteligencia artificial en la generación de textos pero sí en multimedia. Porque si en texto yo creo aportar mucho, en multimedia no es así.

Multimedia para mí es muy diferente. No tengo formación artística ni musical, salvo la muy básica obtenida en la enseñanza obligatoria. No tengo habilidad manual ninguna para dibujar. No le dedico demasiado tiempo a contemplar arte o a escuchar música. Y, quizá, uniendo la escasa formación y la falta de dedicación a contemplar las obras de terceros, no tengo imaginación suficiente para concebir una buena escena de vídeo y muchísimo menos una buena canción. Por todo ello, tengo muy poco que aportar a la hora de creación de imagen, vídeo o música. Y, sin embargo, la inteligencia artificial me permite crear con muy poco esfuerzo, aunque con las carencias ya reseñadas, imágenes, vídeos y canciones de alta calidad física, y razonable, aunque no perfecta, composición. Eso es mucho más de lo que yo soy capaz de hacer. Y por eso no duda en utilizar la inteligencia artificial.

Lo que recibes cuando creas

Pero luego está lo que yo recibo. Y probablemente eso sea muchísimo más importante y más decisivo a la hora de no utilizar la inteligencia artificial que la visión de lo que aporto.

He expresado más de una vez que 'pienso cuando escribo'. Cuando redacto un texto, del tipo que sea, reflexiono sobre lo que estoy escribiendo, maduro y cuestiono ideas, estructuro el mensaje. Incluso temas que domino, pasan por ese tamiz de la reflexión, el cuestionamiento y la reestructuración. Y todo ese proceso, aparte de ayudar a generar un mejor resultado, es enormemente enriquecedor para mí mismo, y diría que es también una forma de aprendizaje.

La reflexión, cuestionamiento y reestructuración del contenido es en sí mismo, como decía, un proceso de aprendizaje. Te ayuda a entender mejor, a estructurar mejor y a recordar. Es muy agradable, muy satisfactorio desde el punto de vista intelectual y muy enriquecedor. Te hace mejorar y a la vez te hace disfrutar. Al menos a mí.

Lo anterior aplica sobre todo a la escritura profesional.

En el caso de la escritura literaria, también aplica en buena medida lo anterior, sobre todo la reflexión, pero hay algo más y diferencial, que es la emoción. En el caso de algunos textos de carácter literario (alguno publicado y alguno no), la propia escritura me ha despertado emociones, porque al fin y al cabo escribes sobre cosas que, de alguna manera, te importan. Puede parecer absurdo, pero alguna vez hasta he soltado alguna lagrimita al releer algo que acaba de escribir. Me creo que la inteligencia artificial escriba un texto que te pueda llegar a conmover...pero estoy seguro de que no es lo mismo, en absoluto, que cuando es un texto tuyo, escrito por ti y sobre lo que te importa.

Como he dejado patente, no realizo verdadera creación artística en materia de imagen, vídeo o música. Pero presumo que, algo paralelo a lo que yo experimento al escribir, lo puede vivir un pintor o diseñador gráfico al crear una imagen, un cineasta al crear un corto o un compositor al crear una nueva pieza musical.

E, incluso, si supusiésemos, y puede llegar a ser cierto, que la inteligencia artificial llegue a generar textos, imágenes, vídeos y música de calidad, no solo física sino también artística, superior o similar a la humana, sólo por el hecho de experimentar en uno mismo el proceso interior de la creación, valdría la pena no utilizar la inteligencia artificial, o al menos no de vez en cuando, al menos no para aquello que realmente te importa.

Y el proceso exterior

Sólo un apunte final, que ya no hace mención al proceso interior, sino al proceso exterior.

Para el caso de creación de tipo profesional, para documentos, logotipos, presentaciones, vídeos promocionales, tiendo a pensar que al público receptor de la creación, le importe poco si lo ha hecho la inteligencia artificial, una persona o a medias. Tiendo a pensar que lo que vale es el resultado.

Pero ¿y en el caso de la creación puramente artística? ¿Y en el caso en que al autor trasmita experiencia y emociones propias?

¿Le importaría al lector de una poesía o una novela introspectiva que haya una persona detrás que vivido, sufrido y disfrutado, o quiere sólo el texto?

Y lo mismo diría de cualquier otra creación puramente artística ¿Nos importa sólo el producto o también la persona y experiencia que hay detrás?

De la contestación a esas preguntas no estoy seguro. Creo que, probablemente, a muchas personas les dará igual quién sea el autor o autora de la obra, y si es una persona o la inteligencia artificial. Pero también quiero suponer, y supongo realmente, que habrá personas que esperan que haya una persona al otro lado, un escritor para una novela, un poeta para una poesía, un compositor para una melodía.

Conclusiones

La inteligencia artificial es capaz de generar contenidos de una altísima calidad formal y una buena calidad en cuanto a composición. Y pudiera, en esa labor de creación, llegar a sustituir a los humanos.

Sin embargo, en ciertas ocasiones, los humanos bien preparados, creo que pueden generar mejores resultados.

Y, sobre todo, lo más importante y más allá del resultado, el propio proceso interior asociado a la creación, es tan agradable, tan satisfactorio y tan enriquecedor que aunque sólo sea por experimentarlo, vale la pena no delegar en la inteligencia artificial según qué cosas.

¿Qué inteligencia artificial queremos enseñar?

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

Ante el auge imparable de la inteligencia artificial, ante la riqueza de opciones de adopción y casos de uso disponibles, se produce una enorme demanda de formación en inteligencia artificial. una demanda de la que, por supuesto, no puedo dejar de alegrarme.

Es una reacción lógica de empresas e incluso individuos: si estamos ante una tecnología tan transformadora y tan disponible, debemos, como personas y como empresas, ponernos manos a la obra cuanto antes para conocerle y utilizarla

Existe, incluso, una demanda por parte de regulaciones como la AI Act que habla, aunque de forma algo borrosa, de alfabetización en IA.

Sin embargo, creo que con frecuencia, precisamente porque es una tecnología que todavía se está conociendo, no existe claridad en la demanda de formación, ni por parte de individuos ni de organizaciones, puede que muchas veces ni siquiera por parte de las propias entidades dedicadas a formación: escuelas de negocio, academias, universidades, etc.

Y lo cierto es que es muy diferente no sólo el currículum a desarrollar, sino incluso el estilo y profundidad de una docencia en inteligencia artificial según el colectivo a que nos dirijamos, su punto de partida y sus expectativas.

Aunque muchas son las posibilidades, veo tres grandes currícula muy comunes, a saber:

Inteligencia artificial para usuarios
Inteligencia artificial para directivos
Inteligencia artificial para desarrolladores

Pero en realidad, las opciones son muchas y, aunque quizá, se trate de caso algo más particulares, voy a comentar otros dos:

Inteligencia artificial para científicos de datos
Inteligencia artificial para juristas

No voy a entrar en currícula detallados, pero sí brevemente voy a comentar qué se espera, o debería esperar, de una formación en cada una de estas visiones.

Inteligencia artificial para usuarios

Probablemente sea lo más demandado ahora mismo. Ante el auge de la inteligencia artificial generativa, ante lo sencillo que es utilizarla y ante las inmensas posibilidades que ofrece, una gran demanda cae en este campo: ¿Cómo utilizar la IA generativa en mi día a día?

Fundamentalmente se trata de formación muy práctica, con escasa teoría, en ingeniería de instrucciones ('prompt engineering') adornada con presentar diversas herramientas como, por supuesto, los chatbots generativos (ChatGPT, Gemini, Claude, etc) pero también otras herramientas algo más especializadas para crear presentaciones, videos, música, etc. Y todo ello aderezado con la identificación de muchos casos de uso, unos casos de uso normalmente centrados en el trabajo individual.

Es una formación en cierto sentido superficial, pero muy útil en el día a día, muy demandada y muy bien recibida en general porque es, a la vez, útil y divertida.

Inteligencia artificial para directivos

Un currículm algo más heterogéneo y más difícil de centrar es la formación en inteligencia artificial para directivos. De nuevo, y como en el caso del colectivo anterior, los directivos, creo que de forma algo equivocada, huyen de la teoría, por lo que, aunque creo que se debe aportar algún fundamento, los contenidos suelen estar orientados a dónde y cómo aplicar la inteligencia artificial en la empresas.

Un peligro actualmente es centrarse sólo en las soluciones generativas cuando, en el ámbito de la empresa, siguen teniendo mucho peso e interés los modelos de machine learning más tradicionales usados en analítica inteligente y modelos predictivos y prescriptivos.

De nuevo, tienen mucho interés los casos de uso pero en este caso, se deben ver con una perspectiva algo más amplia e incluir, no sólo el empleo individual de herramientas generativas sino la aplicación corporativa de la inteligencia artifivial en materia de analítica y automatización.

Aunque no siempre los directivos (salvo que pertenezcan a un área de IT) están interesado en ello, creo que es bueno que conozcan, además, algo de los servicios ofrecidos en la nube, especialmente por hiper-escaladores y, en general el mercado de soluciones existentes.

A eso, añadir elementos importantes de gestión del dato, de gobernanza, de ética, de legislación y 'compliance'.

Inteligencia artificial para desarrolladores

Un perfil completamente diferente es el de los desarrolladores: personas técnicas que van a construir, 'con sus manos', soluciones de inteligencia artificial.

En este caso creo que precisan de algo más de teoría en cuanto a algoritmia y arquitectura. Por supuesto, es inexcusable el conocimiento de python (aunque puede ser interesante alguno otro lenguaje como R) y de las librerías que se utilizan en el ámbito del machine learning tradicional y para el uso de modelos generativos.

Deberían conocer también las plataformas en la nube y alguna comunidad, muy especialmente Hugging Face.

Probablemente también sea conveniente formación en gobierno del datos y en las pruebas y evaluación de modelos.

Y, quizá, se debería comenzar a comentar elementos de 'vibe coding' o desarrollo software asistidopor inteligencia artificial.

*****

Creo que, aunque de una forma simplificada, estos son los tres grandes perfiles, pero, por supuesto, la formación se puede y debe adaptar a diferentes colectivos, diferentes expectativas y diferentes puntos de partida. Y, un poco en esa línea, voy a comentar otros dos perfiles posibles.

*****

Inteligencia artificial para científicos de datos

Se trata de un perfil parecido al de desarrollador, pero, en aquellas empresas que distinguen entre los ingenieros de datos (más próximos a la pelea con los datos y al desarrollo) y los científicos de datos, más próximos a los modelos propiamente dichos y al negocio, la formación de este colectivo, puede diferir ligeramente.

Por ejemplo, puede poner más énfasis el conocimiento de los diferentes modelos y algoritmos de machine learning y cuándo aplicarlos así como todo lo relativo a la evaluación de los modelos. Deben ponerse énfasis también en aquella parte de las plataformas orientadas a la selección de modelos con especial interés en que conozcan los posibilidades de Auto ML.

Quizá, en este colectivo, pueda ser interesante también poner algo más de foco en los aspectos de responsabilidad y ética, y alguna pincelada de 'compliance'.

Adicionalmente, y aunque adaptado a cada caso, dado que los científicos de datos se orientan a las necesidades del negocio, puede ser bueno una formación específica en vocabulario, aspectos sectoriales y particularidades del sector o área funcional a que se dirigen sus modelos. Por ejemplo, podría ser relevante la formación en marketing digital.

Inteligencia artificial para juristas

Un colectivo muy interesado en la inteligencia artificial es el de los juristas. En este caso, podrían recibir una formación similar a la de directivos cuando lo que buscan es la aplicación en su bufette o empresa, pero cuando los distingo como colectivo es pensando en una formación orientada a aplicar las regulaciones sobre IA o a orientar a sus clientes en los mecanismos de protección y 'compliance'.

En este aspecto, por supuesto, deberían recibir formación, si no la tienen ya, en las regulaciones existentes, notoriamente en Europa en RGPD y AI Act.

Pero sería muy conveniente una formación algo más teórica sobre fundamentos de inteligencia artificial, sobre cómo funcionan y manejan los datos los algoritmos tanto de machine learning tradicional como lo s generativos.

Igualmente, deberían recibir formación en gobernanza de datos y de sistemas de inteligencia artificial y en normativa como el estándar ISO 42001.

Muchas otras opciones

No se acaban aquí, las opciones, pudieran existir formaciones mixtas o dedicadas a aspectos particulares como la ciberseguridad, pero creo que lo dibujado más arriba traza un poco las opciones existentes y, sobre todo, destaca, que es lo que en el fondo pretendía con el post, que no es realista ni practico hablar de formación o alfabetización en inteligencia artificial sin más, sino que debemos saber de dónde partimos, a que colectivo nos dirigimos y que necesitamos realmente que sepan de la inteligencia artificial.

Conclusiones

Es muy necesario hoy en día formarnos, individualmente y como organizaciones en inteligencia artificial, pero a la hora de realizar una demanda de formación, conviene 'centrar el tiro' y saber qué pretendemos realmente.

La cadena de producción en computación: el viaje de la especialización de los procesadores

noreply@blogger.com (Ignacio G.R: Gavilán) — Thu, 26 Feb 2026 09:00:00 +0000

Termino con este post una serie un poco espontánea (no tenía decidido realmente hacer una serie, sino que ha salido así) que he dedicado al mundo del hardware y los procesadores, tema que, la verdad sea dicho, apenas había abordado antes en este blog.

Y mi interés sobre el particular ha surgido suscitado por las reflexiones sobre algunos episodios en que he participado del podcast 'Código abierto' y en que hemos hablado del tema, y de forma más inmediata por la lectura del libro 'Mastering NVIDIA CUDA and Tensor Cores' que explica la arquitectura de procesadores de NVIDIA y cómo se programa con ellos.

En este post, simplemente quiero resaltar una paradoja y una metáfora respecto a los procesadores.

La paradoja es que, a medida que queremos conseguir más potencia, acudimos a procesadores más sencillos en cierto sentido. La metáfora es la de una cadena de producción en computación.

Y todo ello, aderezado con una especie de arqueología tecnológica o 'memoria histórica' de la computación.

Recordando los microprocesadores para PC

Y empiezo un poco con esa memoria histórica, casi con esa nostalgia.

Pues si, no puedo dejar de recordar los tardíos años ochenta o principios de los noventa cuando asistimos, y en mi caso con mucha implicación, a la aparición y expansión súbita de los ordenadores personales, los famosos PC.

Recuerdo que mi primer ordenador personal, un Inves 640-X, incorporaba un microprocesador Intel 8088, aunque en aquel momento ya la mayoría de PCs venían dotados de un Intel 8086. Y si, para quien no lo recuerde y a lo mejor hoy en día le resulte extraño, Intel dominaba de forma aplastante el mundo de los microprocesadores para ordenador personal y marcaba completamente la pauta.

Todas las revistas de informática, abundantes en aquella época, y todos los aficionados, asistíamos con expectación a cada lanzamiento de un nuevo microprocesador de Intel. El siguiente de importancia fue el 80286. Luego vendría el 80386, hasta que Intel decidió cambiar un poco la marca y, al que debía llamarse, siguiendo la misma lógica, como 80596, decidió denominarlo 'Pentium'.

Más allá de la curiosidad y la nostalgia, lo relevante de cara a este post es hacer ver que cada nuevo microprocesador, que era más potente que el anterior, aparte de mejoras como acelerar la señal de reloj, se hacía más y más complejo, soportaba más y más instrucciones, se hacía físicamente más y más grande y, energéticamente, disipaba más y más calor.

Un poco como anticipo de lo que vendría después, y que en seguida comento, para algunos ordenadores un poquito más especializados y más potentes, se les dotaba del llamado coprocesador matemático, una especie de microprocesador pero ya no de propósito general sino especializado en operaciones matemáticas.

Arquitecturas CISC y RISC

No recuerdo bien los años, pero creo que, aunque tiene antecedentes más antiguos, hacia los años 90 se comenzó a hablar con más fuerza del concepto de RISC. ¿Qué era eso?

Bueno, los microprocesadores como los de Intel, evolucionaban soportando más y más instrucciones y constituían, pues, lo que se denominaba CISC ('Complex Instruction Set Computers').

Sin embargo, RISC ('Reduced Instruction Set Computers'), y a pesar de buscar precisamente una mayor eficiencia en la computación, apostaba en la dirección contraria: procesadores con un juego de instrucciones pequeño (reducido) y que, aparte de otras optimizaciones y mejoras ya buscaba el paralelismo en la computación. Y, realmente, hablar de RISC se convirtió en una especie de sinónimo de altas prestaciones.

Si la memoria no me falla, más que a los ordenadores personales, ésta filosofía se aplicaba a servidores o a las entonces llamadas 'workstations' (típicamente de Hewlett-Packard o Sun Microsystems) que, aunque tenían características parecidas a los ordenadores personales, eran más potentes, utilizaban sistemas operativos UNIX y se las consideraba más del ámbito profesional que personal.

Las GPU

Abandono un poco ya la memoria nostálgica para situarme en el presente. En este presente, y aunque ya están entre nosotros hace algunos años, son populares las famosas GPU ('Graphical Processing Units').

En cierto modo, las GPU son herederas de los coprocesadores matemáticos porque, en el fondo, eso es o que son. Salvo en casos muy particulares, las GPU no son una alternativa a las CPU ('Central Processsing Unit'), es decir, los microprocesadores tradicionales, sino unas compañeras de estos. La computación general suele correr a cargo de CPUs, pero ciertos tipos de cálculos, se delegan en GPUs.

¿Qué cálculos?

Pues las GPU están especializadas en operaciones algebraicas del mundo de los vectores, las matrices y los tensores. Se trata de un tipo de cálculos que son fundamentales en todo lo que tiene que ver con gráficos y movimiento y por eso las GPUs surgieron para apoyar el mundo de los videojuegos y aplicaciones similares, de ahí el nombre de 'gráfico' que puede sorprender hoy en día.

Y es que, no sólo el mundo de la imagen en movimiento se apoya en cálculos algebraicos, sino que también el 'machine learning' y muy particularmente el 'deep learning' se implementa, fundamentalmente con ese álgebra lineal en espacios vectoriales... y eso explica la popularidad y demanda actual de GPUs... y el éxito empresarial de NVIDIA.

Las GPUs apuestan muy decididamente por el paralelismo, condicionando, como vimos en un post anterior, la forma de programar con ellas en el bajo nivel. Pero hago notar que, en el fondo, en busca de la eficiencia computacional, sufren una enorme especialización: ya no son procesadores de propósito general como las CPU, sino procesadores muy especializados en computación algebraica paralela.

La transacción: especialización a cambio de potencia.

Las TPU

Y un caso más particular son las TPU ('Tensor Processing Units') o, al menos, los 'tensor cores' de NVIDIA, que se centran en una única operación: la multiplicación de matrices con acumulación consiguiendo una espectacular eficiencia en esa operación.

Estamos ante una 'super-especialización' pero que tiene sentido porque se trata de una operación usada masivamente en el deep learning actual, que ya sabemos que es enormemente demandante, especialmente en el caso de los grandes modelos generativos.

Estamos extremando en este caso la transacción de especialización a cambio de potencia, pero sigue teniendo una total lógica técnica e incluso económica.

La especialización y las cadenas de producción en computación

Y esto me lleva a la metáfora. No he podido dejar de pensar en los principios de la organización científica de Taylor, origen de las cadenas de producción industriales.

En esas cadenas de producción, los trabajadores (y también las máquinas) dejan de ser personas o máquinas de propósito general, como ocurriría en el caso de la artesanía o del trabajo intelectual, para especializarse en tareas muy concretas, tareas que realizan una y otra vez de forma muy eficaz y, sobre todo, muy eficiente.

Procesadores como las GPUs o las TPUs no dejan de ser, en la computación, algo así como los trabajadores especializados de una cadena de producción, en este caso una cadena de producción de la computación, mientas que las CPU se quedan un poco como los artesanos o intelectuales de esa computación.

Y, ante la demanda masiva de computación, procedente sobre todo de la inteligencia artificial, hemos debido poner en marcha una capacidad productiva en computación, altamente especializada y, por ello, altamente eficiente, pero apoyada en procesadores especializados.

Conclusiones

El conseguir unas mayores dosis de eficiencia en computación ha llevado, a lo largo de los años, a buscar esquemas de procesadores especializados en operaciones concretas y con altas dosis de paralelismo.

En ese sentido, y aunque sea metafóricamente, lo que buscamos son 'trabajadores especializados', y muy eficientes integrados en una suerte de cadena de producción de computación.

Artículos de este blog relacionados

Una aparente paradoja: el retorno de la programación de bajo nivel

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

En los dos últimos post he hablado de dos fenómenos, en apariencia independientes y casi contradictorios y que, precisamente, van a colisionar en este artículo.

Hablo, por un lado, de la evolución del desarrollo software que explicaba en 'La evolución del desarrollo software: productividad frente a deskilling' y que nos muestra una clara evolución a una programación cada vez más alejada de los detalles técnicos y más centrada en la productividad y cercanía a las necesidades funcionales. Una programación, en fin, de alto nivel.

Por otro, en el último post, 'El retorno del hardware: razones y perspectivas', destacaba cómo el hardware, al que hacía años que apenas dábamos importancia, ha vuelto a cobrar valor técnico, económico y estratégico, debido en buena medida a las demandas técnicas y de volumen que impone la inteligencia artificial generativa.

En este post examino un fenómeno en cierto modo sorprendente y contradictorio: el retorno, no ya del hardware, sino de la programación de bajo nivel.

Programación de bajo nivel

Como paso previo, y por si algún lector no esta suficientemente advertido, aclarar a qué nos referimos con lo de la programación de bajo nivel.

La programación de bajo nivel es la creación de un software que trabaja en temas de detalle y, sobre todo, muy cerca del procesador, ya sea un microprocesador de tipo CPU ('Central Processing Unit') tradicional, o los modernos GPU ('Graphical Processing Unit') o TPU ('Tensor Processing Unit'). La programación de bajo nivel suele implicar conocer bien el hardware, tanto los procesadores como la estructura de registros y de la memoria o cómo relacionarse directamente con dispositivos y periféricos.

Con la programación de bajo nivel normalmente no podemos resolver grandes problemas funcionales, pero, a cambio, podemos conseguir nuevas capacidades y, sobre todo, si se hace bien, unas altísimas prestaciones y una gran optimización computacional. Y eso es así porque al trabajar muy cerca del hardware y conociendo cómo funciona, explotamos al máximo sus capacidades y, además, hacemos ´únicamente lo que se necesita'.

El software de alto nivel, por su lado, en su búsqueda de generalidad y facilidad de uso, añade ingentes cantidades de lógica adicional no estrictamente necesaria en muchos casos y, además, al alejarse del hardware no optimiza su uso. Prima la productividad y facilidad de uso frente a la optimización computacional.

¿Por que realizar programación de alto nivel?

En realidad lo acabamos de mencionar y lo vimos también en un post anterior: favorecemos la programación de alto nivel porque es muchísimo más productiva en términos de cantidad de software producido, porque además es más sencilla de llevar a cabo (lo que redunda en productividad y, además, elimina barreras de entrada de profesionales) y, finalmente, porque permite concentrarse más en los problemas de negocio o en lo que realmente queremos proporcionar.

Por eso, una vez que el hardware alcanzó una potencia tal que ya no nos exigía su optimización para tener buenos resultados de prestaciones, se ha ido favoreciendo la programación de alto nivel

¿Y por qué realizar programación de bajo nivel?

Y, entonces ¿Por qué podríamos interesados, a estas alturas, en hacer programación de bajo nivel?

Bueno, en algunos casos no hay más remedio. Por ejemplo, para relacionarse con un nuevo dispositivo o periférico, hay que comenzar trabajando en el bajo nivel, aunque luego, de cara a otros programadores se preparen ya APIs o conectores simplificados.

Un poco en esa misma línea, si estás programando un sistema operativo no tienes más remedio que enfrentarte al bajo nivel porque una de las funciones principales de un sistema operativo es precisamente relacionarse con el hardware y ofrecer, hacia el exterior, un modo abstracto, una máquina virtual que independice a aplicaciones y programadores de ese hardware. Los programadores de esas aplicaciones pueden trabajar en el alto nivel, pero los del sistema operativo están obligados a relacionarse con el bajo nivel.

Pero hay algo que me importa mucho más ahora mismo, en relación con lo que quiero exponer en este artículo: utilizas la programación de bajo nivel porque cuando quieres optimizar el funcionamiento, cuando quieres maximizar las prestaciones, cuando quieres 'exprimir al máximo' la capacidad del hardware, tienes que acercarte al hardware, tienes que conocerlo, tienes que, en fin, realizar programación de bajo nivel.

Nuevas arquitecturas de procesadores

Durante bastantes años, los procesadores, aunque evidentemente evolucionaban, y no poco, eran de tipo CPU.

Con el auge de aplicaciones de gran riqueza gráfica como los videojuegos, nacieron y cobraron importancia las GPU ('Graphical Processing Unit'). Pero la auténtica explosión ha venido de la mano del machine learning al 'descubrir' que las operaciones algebraicas que se utilizan en el mundo gráfico, son similares a las que se utilizan en machine learning, fundamentalmente en redes neuronales. En ambos mundos abundan las operaciones con vectores, matrices y tensores. Y las GPU lo que hacen es optimizar esas operaciones.

En un paso más allá en especialización, existen las TPU ('Tensor Processing Unit') o los 'tensor cores' de NVIDIA que, pese a que suenen a algo muy potente, en realidad se especializan en una única operación: la multiplicación de dos matrices y acumulación del resultado en una de ellas. En cierto modo, son elementos muy sencillos, pero altamente especializados y optimizados.

La nueva programación de bajo nivel

Aunque la programación de bajo nivel, pese a su escasa visibilidad, nunca se había ido, ahora cobra una gran importancia para explotar estos nuevos procesadores.

¿Por qué?

Pues porque estos procesadores son muy especializados pero, para que produzcan los resultados esperados, hay que programarlos conociendo cómo funcionan. Así, para explotar bien las GPU hay que convertir la resolución de nuestros problemas en operaciones de algebra lineal y, además ser capaces de definir la resolución de un problema en términos de unas funciones, los denominados 'kernel', en que la misma lógica pueda trabajar en paralelo sobre diferentes datos (por ejemplo, sobre diferentes partes de una misma matriz).

Más específico aún es el caso de los 'tensor cores' en que, para aprovecharlos, hay que ser capaces de identificar o forzar operaciones que consistan en una multiplicación de matrices seguidas por una acumulación.

Y esto no se puede hacer con sólo conocer un problema de negocio o la sintaxis de un lenguaje de programación. Para ello hay que comprender el hardware con que se trabaja y la mejor forma de obtener todo su rendimiento.

Es decir, hay que trabajar en el bajo nivel.

Deshaciendo la aparente contradicción

Y llega el momento de deshacer la aparente contradicción.

¿No habíamos dicho que la evolución del software nos conducía a una visión cada vez más alejada del hardware, una visión que en sus vertientes 'No Code' o 'Vibe coding' ni siquiera trabajaba con código fuente e incluso que en las soluciones de más alto nivel el desarrollador expresaba sus necesidades en lenguaje natural?

Si, lo habíamos dicho y así es.

Lo que ocurre que el trabajo en el bajo nivel lo realizan, comparativamente, muy pocas personas organizadas en equipos especializados. Esas pocas personas programan el software más exigente y, además, preparan componentes optimizados para su uso en el alto nivel por desarrolladores menos especializados.

Así, las típicas librerías python usadas en machine learning y deep learning, están fuertemente optimizadas a nivel interno, aunque el común de los programadores las utilicen directamente sin preocuparse de los detalles. Y no digamos ya nada cuando ni siquiera se trabaja con las librerías sino con componentes gráficos que las abstraen (caso del 'low-code / 'no-code') o cuando incluso es la inteligencia artificial la que general el código que invoca a las librerías, sin que el desarrollador sea necesariamente consciente de ello.

En el fondo, esa ha sido siempre la relación entre al bajo y el alto nivel: unos pocos equipos especializados trabajan en el bajo nivel, cerca del hardware, y preparan componentes optimizados reutilizables en el alto nivel.

Lo único que ocurre es que ahora, con la enorme demanda computacional existente y procedente de la inteligencia artificial, muy especialmente en su vertiente generativa., cobra nueva importancia el contar con algunos de esos equipos especializados para sacar jugo a un hardware especializado y que, pese a las enormes inversiones, se nos está quedando corto en volumen.

Conclusiones

La gran demanda computacional exigida por la inteligencia artificial generativa ha llevado al desarrollo de procesadores especializados a nivel hardware, pero el uso adecuado y óptimo de ese hardware implica el trabajo en el bajo nivel aunque luego los resultados puedan ser reutilizados vía librerías y APIs, en la programación de alto nivel.

El retorno del hardware: razones y perspectivas

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 16 Feb 2026 08:45:00 +0000

¿No resulta llamativo la frecuencia con que ahora oímos hablar de asuntos que tienen que ver con el hardware?

No paramos de escuchar hablar de GPUs, de NVIDIA, la empresa estrella del momento, del papel estratégico de la producción de semiconductores, de la lucha por las tierras raras y tantas cosas relacionadas con los aspectos físicos de la computación, con la microelectrónica y el hardware.

¿Qué está pasando?

El hardware como 'commodity'

Hasta no hace mucho, el hardware ha sido 'el hermano pobre' de la tecnología digital, algo de lo que se hablaba relativamente poco fuera de ámbitos especializados.

Pasada ya hace mucho la fiebre de los ordenadores personales en que sí que nos volvíamos locos los aficionados a la informática conociendo las nuevas características del último microprocesador Intel, y ahora que la gran proliferación de servicios en la nube nos hace muchas veces casi invisible el hardware corporativo, al menos los servidores, durante muchos años apenas nos hemos fijado en el hardware.

A nivel de programación, y como revisamos en el reciente post 'La evolución del desarrollo software: productividad frente a deskilling' también nos hemos ido alejando de la realidad física que soportaba la computación, de los procesadores, las CPUs, las GPUs, etc.

Sabíamos que era necesario, claro, y que evolucionaba y mejoraba, pero lo valorábamos poco, le prestábamos poca atención y, seguramente, el número de profesionales, ya no digamos aficionados, del software, supera con mucho, con muchísimo, al de los dedicados al hardware.

Además nos acostumbramos a que el hardware fuese relativamente barato, en el caso de ordenadores personales o portátiles, y casi invisible en el caso de los servidores, por mor de los servicios en la nube.

En cierto modo, habíamos convertido al hardware en una 'commodity', necesario, pero sin valor diferencial.

Y de repente ha vuelto

Y de repente, en los últimos meses, quizá algún año, vuelve a ser importante. Vuelve a estar en el discurso técnico y en el geoestratégico. ¿Por qué?

Voy a aventurar cuatro razones:

La escasez relativa de la capacidad de computación
La escasez relativa de materiales concretos
La especialización de la demanda
Un conocimiento escaso y concentrado

Veamos

La escasez relativa de capacidad de computación

La primera es que, lo que en su momento pudimos considerar abundante, la capacidad de computación, se nos ha vuelto escasa.

Hablo de escasez relativa porque no es que no exista capacidad de computación. Existe mucha capacidad de computación distribuida en unidades relativamente modestas como ordenadores de sobremesa, portátiles, tablets y smartphones. Existe muchísima capacidad de computación concentrada en centros de Proceso de Datos corporativos y existe, sobre todo, una ingente capacidad de computación en los data centers de los grandes proveedores de la nube (Amazon, Microsoft, Google, IBM, etc)

Lo que pasa es que la demanda crece aun más. En parte por la digitalización creciente pero muy singularmente por la explosión de la inteligencia artificial basada en modelos muy demandantes de computación tanto en entrenamiento como en inferencia, y por la previsión de que esa demanda no vaya a hacer otra cosa que crecer y trasladarse a otros ámbitos como robots, vehículos, etc, la oferta de hardware parece que se nos está quedando corta, o amenaza con quedarse corta.

Y ya se sabe que, desde un punto de vista económico y estratégico, un recurso gana importancia cuando es escaso.

La escasez de materiales concretos

Ante la enorme demanda de microelectrónica y hardware cuando algunos de sus componentes es en sí mismos escasos, como las famosas tierras raras, se perciben como aún más escasos y, por tanto, con mucho mayor valor económico y geoestratégico.

La especialización de la demanda de hardware

Quizá en menor medida, pero también influye creo, que ya no nos vale con un hardware más generalista, digamos una CPUs tradicionales agregadas mediante mecanismos de virtualización. Ahora los cálculos en el ámbito de la inteligencia artificial. de los videojuegos, de la realidad virtual o de la simulación, nos reclaman procesadores especializados, procesadores especializados en los cálculos algebraicos y su realización de operaciones en paralelo (caso de los GPU, 'Graphical Processing Units') y especializados en alguna operación muy específica realizada con muchísima frecuencia (caso, por ejemplo, de las TPUs, ('Tensor Processing Units')).

La necesidad de esa especialización, de esa búsqueda de procesadores más potentes y especializados, realza y revitaliza la industria del hardware pero, además, le añade más valor diferencial. Y si no, que se lo digan a NVIDIA.

La concentración y escasez de conocimientos

Además, y a nivel casi más geoestratégico que económico, la industria de los semiconductores está muy concentrada.

Está muy concentrada geográficamente, siendo tremendamente relevante el papel de Taiwan y está concentrada en empresas, siendo tremendamente especial el caso de la empresa holandesa ASML poseedora, hasta ahora en exclusiva, de la tecnología EUVL ('Extreme Ultra Violet Lithography').

Aunque esa concentración pudiera tener sentido económico como una forma de eficiencia considerando una cadena de suministro global, lo cierto es que es también un unto de fragilidad y, en el convulso mapa geoestratégico actual, un elemento de lucha competitiva, no ya de empresas, sino de grandes potencias.

A eso añadiría, aunque confieso que más como intuición que con base en datos, que creo que existen muy pocos profesionales en el mundo con conocimientos avanzados de microelectrónica y diseño hardware.

Perspectivas: los algoritmos frugales y la computación cuántica

¿Existe alguna vía para que se suavice esa demanda de hardware, incluso esa lucha competitiva por el mismo?

Sinceramente, a corto plazo no veo que la atención en el hardware y, sobre todo, la lucha competitiva y geoestratégica él mismo vaya a disminuir. No veo que la demanda vaya a bajar, sino todo lo contrario, y no veo mecanismos para aumentar de forma sencilla y eficiente la oferta.

Fantaseando un poco, no obstante, apuntaría a dos posibilidades, aunque la segunda no es de corto plazo.

La primera sería que la industria virase, pensando en este caso en la inteligencia artificial, del uso de los grandes modelos de lenguaje, a los denominados pequeños modelos de lenguaje y/o que se encontrase una algoritmia radicalmente diferente a la utilizada últimamente, muy apoyada en la arquitectura transformer, y que esa nueva algoritmia fuese muchísimo más frugal en necesidades de computación. No es que crea que esa es una posibilidad del todo realista en sí misma e, incluso, caso de conseguirse esa algoritmia, a lo mejor nos encontrábamos con más despliegues, más caso de uso con lo que, aunque cada modelo consumiese mucho menos, la demanda global podría seguir creciendo.

Otra posibilidad, pero no es de corto plazo, es la llegada real, con viabilidad comercial y a gran escala, de la computación cuántica. Dada su enormemente superior capacidad de computación para cierto tipo de aplicaciones (incluyendo el machine learning), eso podría llevar a una drástica disminución de demanda del hardware basado en semiconductores. Pero este escenario, caso de ser realista, no es inminente y, como mínimo, parece que habrá que esperar cinco años, si no diez, o quién sabe cuánto.

Conclusiones

El hardware parece que se ha vuelto a poner de moda. Y hay razones de aumento de demanda, de especialización y de escasez de recursos que justifican el aumento de su valor discursivo, económico y geoestratégico.

Y parece que, al menos durante unos pocos años, esa importancia se va a mantener.

La evolución del desarrollo software: productividad frente a deskilling

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 11 Feb 2026 10:55:00 +0000

El desarrollo de software ha sido siempre una actividad que me ha encantado y con la que, en su momento, he disfrutado muchísimo. Y digo en su momento porque tanto en los últimos años de mis estudios universitarios, como en los primeros de mi carrera profesional, dediqué muchísimas horas a esta actividad, como aficionado como ingeniero de software.

Y he podido asistir, dada mi edad, a casi toda su historia (me perdí un poco del principio) y a cómo ha ido evolucionando. Y lo cierto es que la transformación es enorme. Ha cambiado en filosofía, lenguajes, herramientas y requisitos profesionales del desarrollador.

En este post quisiera revisar esa evolución, y lo que los cambios suponen, de bueno y de malo

Un análisis en cinco fases

Y, para ello, propongo identificar las fases principales de la evolución.

Que yo sepa, no existe ninguna forma de marco concreta para clasificar esta evolución de la forma de construir software, (aunque sí se habla a veces de generaciones, sobre todo tercera y cuarta, pero con base en mi percepción personal, hablaría de cinco fases, a saber:

Fase 1: código máquina
Fase 2: ensamblador
Fase 3: lenguajes de alto nivel
Fase 4: 'low-code' / 'no-code'
Fase 5: 'vibe coding' o 'prompt based coding'

Veamos brevemente lo que significa y aporta cada una de ellas.

Fase 1: código máquina

En esta fase, que sinceramente creo que pocos desarrolladores han vivido salvo, como mucho, durante sus estudios, se trabaja directamente con el hardware, con el microprocesador y se expresa el programa en los famosos unos y ceros que caso nadie ha visto.

Es una programación muy, muy cercana al hardware, e implica conocer en detalle el microprocesador, sus registros, las instrucciones que maneja y cómo se codifican, las direcciones de la memoria etc. Los programas son, a poco que el programador sepa lo que hace, extraordinariamente eficientes en recursos computacionales y rápidos en ejecución, pero eso sí, son muy dificultosos de desarrollar y depurar y, por tanto, en general de un alcance muy modesto.

Fase 2: ensamblador

En realidad, es muy similar a la anterior, pero ahora hay un cierto lenguaje, el ensamblador, que al menos expresa las instrucciones mediante nemónicos textuales (típicamente de tres letras) con lo que, aunque con criterios de hoy en día siguen siendo enormemente crípticos, para su momento fueron una gran aportación en cuanto a claridad.

Fase 3: lenguajes de alto nivel

Son, quizá, el primer tipo de lenguajes ampliamente conocidos. En ellos el lenguaje de programación se basa en formas textuales más o menos destiladas del inglés, pero circunscritos a una serie de instrucciones muy concretas y con una estructura en general muy bien definida. Aunque hable de una forma de inglés no tiene nada que ver con el lenguaje natural: se trata de lenguajes muy acotados, muy estructurados y muy ligados a gramáticas estrictas.

Introducen ya los tipos de datos, las variables, las estructuras de control del tipo de bucles y condiciones o la capacidad de crear funciones. Con el tiempo, con el auge de la orientación a objetos, se introduce también esta idea de los objetos (que unen datos y comportamiento) y a capacidad de crearlos y utilizarlos.

Son lenguajes ya independientes del microprocesador e incluso del sistema operativo en que se ejecutan y un programa auxiliar, el compilador o el intérprete según el caso, se encarga de traducir esas instrucciones textuales de alto nivel al código máquina.

Se fueron acompañando de entornos de desarrollo del tipo IDE ('Integrated Development Environment') que incluyen capacidades de control y organización del código, capacidades de depuración, ayudas, etc.

En esta categoría caben casi todos los lenguajes de programación más conocidos, desde algunos más antiguos como COBOL o Pascal, y pasando por Basic, C, C++, Java o python, por decir algunos.

El salto de productividad es inmenso respecto a la programación en ensamblador, una productividad que se refuerza por la posibilidad de creación y reutilización de librerías de funciones u objetos que proporcionan, ya empaquetadas y listas para ser usadas, capacidades más o menos sofisticadas. Creo que es con base estos lenguajes que se produce el verdadero 'boom' del software.

Aunque en varios momentos me he referido a ellos en pasado, siguen estando muy presentes hoy en día, muy especialmente python.

Interludio: los lenguajes de cuarta generación 4GL

No los he llegado a proponer como una fase diferenciada, pero por encima de los lenguajes de alto nivel (que a estos efectos se consideran de tercera generación), proporcionan mayores niveles de abstracción y un enfoque algo más declarativo, normalmente orientados a software de características bastante comunes y estructuradas como la gestión de bases de datos.

Hay quien los considera como un antecedente de lo que veremos a continuación: el 'low-code'.

Fase 4: low-code / no-code

La fase 4 nos conduce a la filosofía y soluciones 'low-code' o, en su extremo, 'no-code'.

La idea es que el desarrollador ya no trabaje con código fuente (que se expresa en un lenguaje de tercera generación) o que lo haga en la menor medida posible. ¿Cómo se consigue eso? Pues proporcionando entornos de desarrollo gráficos o semi-gráficos, donde con frecuencia los bloques de ejecución se representan por cuadrados o círculos, que se unen mediante líneas o flechas para representar una lógica completa. Además, el entorno de desarrollo ofrece ya una amplia librería (normalmente ampliable) de bloques constructivos

En general el desarrollo tiende a convertirse en 'dibujar' la lógica de ejecución complementada por la configuración (habitualmente mediante cuadros de diálogo) de los parámetros y variantes de ejecución de cada uno de los bloques constructivos, así como la definición de variables.

En los casos más extremos ('no-code') no es necesario incluir código fuente tradicional y en otros casos ('low-code') sí existen determinados puntos donde se complementa la lógica, digamos gráfica, con pequeños elementos de lenguaje de programación de tercera generación.

Esta filosofía es cada vez más común para construir todo tipo de soluciones, pero, por citar algunas muy representativas, tendríamos, en el ámbito de la automatización, casi todos los entornos RPA ('Robotic Process Automation') o BPMS ('Business Process Management Systems'), así como soluciones de automatización de workflow (como Make o N8N) e, incluso, algún entorno de construcción de agentes IA como LangFlow. También es común, por ejemplo, en visualizadores de datos como Power BI.

En este salto, no es ya que nos hayamos alejado del hardware y el microprocesador, es que incluso nos hemos alejado de los lenguajes de programación como tales, si entendemos los lenguajes de programación como algo con base textual. Incluso, gran parte de la lógica detallada, viene resuelta por los bloques constructivos disponibles sinq ue el desarrollador la conozca en detalle, sino sólo por su comportamiento externo.

Fase 5: Vive coding o 'prompt based coding'

El último salto, es la creación de software a partir de prompts usando herramientas de inteligencia artificial generativa. En el primer post de este blog que dediqué al 'vibe coding', comentaba la diferenciación entre el uso de inteligencia artificial como una especie de ayuda o copiloto, lo que Addy Osmani denominaba 'Ingeniería de software asistida por IA' frente al uso de la IA para construir toda la aplicación, siendo esto último a lo que asignaba el término 'Vibe coding'.

En realidad, si usamos la IA como copiloto, estamos realmente reforzando una de las dos fases anteriores (lenguaje de alto nivel o 'low-code'/'no-code') pero no sería una fase realmente diferenciada.

Lo que considero como una fase diferenciada es cuando usamos la herramienta para la generación completa de aplicaciones o módulos a partir de prompts en lenguaje natural. Como en este caso la forma de actuar que tiene el desarrollador es únicamente mediante 'prompts', me he querido inventar el término 'prompt based coding'.

En este caso el alejamiento ya es total: el desarrollador no es que no conozca el hardware o el sistema operativo, y no es ya que no utilice un lenguaje de programación, es que, incluso, salvo que se preocupe por ello, hasta desconoce la lógica interna del software que ha generado o cómo está estructurado. El desarrollador, en teoría, se centra sólo en la necesidad, que expresa mediante lenguaje natural, no en los detalles internos del software.

Se trata de una fase probablemente poco madura en estos momentos y que hay que ver hasta dónde es capaz de llegar, pero, en teoría, es una fase de altísima productividad y, además, casi al alcance de cualquiera, una fase donde el propio término 'desarrollador', al menos tal y como lo hemos entendido hasta ahora, puede que pierda sentido.

Consecuencias

A medida que se avanza en las diferentes fases, creo que se producen los siguientes efectos:

Se aumenta (y mucho) la productividad del desarrollo software
Se baja la barrera de entrada (los conocimientos y la especialización necesarios) para crear software
El desarrollador pierde conocimiento del detalle de lo que está haciendo (el hardware, el sistema operativo, las lógicas internas, etc)
Debido a esa pérdida de conocimiento (y gestión) del detalle, en general el software generado es menos eficiente en el uso de recursos computacionales: memoria, tiempo de CPU, disco, etc

En general, la evolución de la industria ha apostado por los dos primeros beneficios (productividad y bajada de la barrera de entrada) frente a los dos últimos inconvenientes (perdida de conocimiento y menor eficiencia en recursos computacionales).

Voy pararme un momento en dos aspectos.

La productividad y las barreras de entrada

En efecto, el gran beneficio de esta evolución es, sobre todo, la altísima mejora de productividad en la construcción de software, no sólo en cuanto a cantidad de código creado sino en cuanto a potencia y capacidades de las soluciones generadas. Por ejemplo, hace 20 o 30 años, hacer la interfaz de usuario (las ventanas, por entendernos) de un sistema, era tremendamente trabajoso... y hoy es casi trivial en algunos casos.

A esto se une, especialmente en las dos últimas fases, en unos menores requisitos, una menor cualificación, para ser creador de software, llegándose ya hace unos años al concepto acuñado por Microsoft de 'Citizen developer' (un concepto muy ligado al 'low-code') en que ya parte del software empresarial podría ser creado, no por desarrolladores profesionales del departamento de IT, sino por profesionales del ámbito del negocio (ventas, marketing, operaciones, etc)

El deskilling

Sin embargo, ese menor conocimiento requerido supone en parte un peligro para el propio software en el sentido de que el desarrollador puede ser mucho menos capaz de hacer un software eficiente, escalable e incluso seguro, o que le puede costar depurar los errores más extraños.

De cara al desarrollador, como profesión, el avance en estas fases, muy especialmente la última, pone en riesgo la profesión en sí misma, en riesgo de desaparición o, quizá más probable, de profunda redefinición y, quizá, sólo quizá, menor cualificación y por tanto consideración profesional.

En el fondo, se produce una forma particular de 'deskilling' (término del que he hablado en los dos últimos posts), en que el desarrollador cada vez sabe menos de sistemas, cada vez sabe menos, por supuesto del hardware, pero también sabe menos de las mejores arquitecturas, de los mejores criterios y mejores prácticas de construcción de software. Y eso es un riesgo potencial para la propia calidad del software y para su mantenibilidad y, quizá, un empobrecimiento personal y profesional del desarrollador.

Conclusiones

El desarrollo de software ha sufrido a lo largo de las últimas décadas, una enorme transformación en su forma de realización, una evolución que le ha conducido, a través de cinco fases, a recorrer un camino en el que ha ganado una enorme productividad y sencillez, pero a cambio de una menor eficiencia en recursos computacionales y en una progresiva descualificación técnica de los profesionales que la ejercen.

La peligrosa combinación del 'automation blindness' y el 'deskilling' y cómo afrontarla

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

Una de las preocupaciones que surgen con la inteligencia artificial es, más allá de otras problemáticas éticas como la privacidad, los sesgos o la explicabilidad, cómo va a afectarnos a nosotros, humanos, en nuestro propio desarrollo, en nuestras propias capacidades cognitivas, a medida que nos entreguemos a ella, que la utilicemos intensivamente tanto en el ámbito laboral como doméstico.

Y creo que, en efecto, existe a la vez un interrogante, porque realmente no estanos seguros, y un riesgo, porque creo que realmente podemos perder cosas valiosas por el camino.

En este post quisiera mostrar cómo dos aspectos que ya he tratado en otros posts, se podrían combinar de una forma perjudicial y potencialmente peligrosa. Hablo de los así llamados 'automation blindness' y el 'deskilling'.

Veamos.

Recordando el 'automation blindness'

De 'automation blidness' hablé en el post anterior a éste titulado 'Automation blindness o el riesgo para human-in-the-loop'. Este fenómeno, en esencia consiste en que los humanos, cuando están apoyados en sus decisiones por sistemas automatizados, poco a poco se 'van confiando' y pasando de realizar una supervisión efectiva y responsable de las decisiones automatizadas, a confiar ciegamente en ellas eliminando, 'de facto', la supervisión e incluso su autonomía.

Se trata de un fenómeno no específico de la inteligencia artificial pero que se acentúa en sistemas inteligentes, tanto por su potencia, como por actuar en situaciones tradicionalmente reservadas al juicio humano.

Recordando la idea de 'deskilling'

Del 'deskilling' hablé brevemente hace un par de meses en el artículo 'Inteligencia artificial, capacidades y las tres olas hacia el desempleo'. En este caso, de lo que hablamos es que, dado el efecto sustitutivo que la tecnología tiene respecto a tareas humanas, a medida que vamos delegando en la tecnología esas tareas, perdemos la capacidad para llevarlas a cabo nosotros mismos, es decir, perdemos capacidades y habilidades.

Se trata de un fenómeno que tampoco es exclusivo, ni mucho menos, de la inteligencia artificial. Lo que ocurre es que, en el pasado, las habilidades que delegábamos y perdíamos eran de naturaleza más bien manual, pero con la digitalización, y sobre todo con el advenimiento de la inteligencia artificial, estamos, cada vez más, delegando capacidades cognitivas y, eventualmente, perdiendo esas capacidades o al menos en riesgo de perderlas.

Una combinación doblemente peligrosa

Si veo ambos fenómenos, creo que cuando se combinan, y me parece muy fácil que se combinen, nos hallamos ante una situación peligrosa en un doble sentido, un sentido más operativo y práctico, y otro más cognitivo y profundo.

Un peligro operativo

En primer lugar, y desde un punto de vista que voy a denominar operativo, es peligrosa porque se pierde la supervisión real de los sistemas automatizados. Ya no es sólo que tendamos a confiarnos ('automation blindness'), es que podríamos incluso perder la capacidad real para entender y controlar un sistema automatizado ('deskilling'). Dado que, por desgracia, los sistemas automatizados pueden fallar, y más si se pretenden apoyar en inteligencia artificial generativa que, como ya analicé en otros posts, no conduce a comportamientos completamente predecibles ni sujetos a reglas, perder la capacidad de supervisión y control puede llevar a puntualmente a comportamientos del sistema incorrectos y eventualmente catastróficos.

Es cierto que los sistemas automatizados, sobre todos los de misión crítica, tienden a ser muy fiables, incluso con frecuencia mucho más que un humano, pero aún así, perder la capacidad última de decisión y control, me parece operativamente arriesgado.

Un riesgo cognitivo y ético

Pero quizá me preocupa más la segunda vertiente, la que voy a denominar cognitiva. En este caso, tiene mucho que ver con el 'deskilling', es decir, con la pérdida de capacidades cognitivas. Esa pérdida de capacidades cognitivas, por sí misma, me parece un empobrecimiento de la persona pero, además, en a medida que se confía más y más en sistemas automatizados, puede devenir en una menor autonomía, una mayor dependencia.

Es cierto que en el pasado, nos hemos deshecho de capacidades que hemos delegado en máquinas y tecnología, y no parece que nos haya ido mal ni que estemos descontentos. Incluso es posible, sólo posible, que a cambio de ceder algunas capacidades, resultemos potenciados en otras, que desarrollásemos nuevas habilidades.

Pero, claro, hablamos de capacidades cognitivas, muy esenciales de lo que significa ser humano. Y no sé si estamos dispuestos a asumir (yo, personalmente, no), esa suerte de degradación cognitiva o el riesgo de un incierto cambio de capacidades cognitivas.

Sin recetas, pero con un planteamiento a corto plazo

La verdad es que creo que nadie puede tener claro lo que va a ocurrir en el futuro, y cómo vamos a evolucionar. Es posible que, al final, los riesgos y peligros no sean tan grandes o, al menos, que sepamos encauzarlos y el resultado final sea bueno. Y como estamos ante un panorama incierto, es difícil saber cuál es el camino adecuado.

Sin embargo, pase lo que pase en el futuro, creo que los riesgos que he mencionado son reales y afectan a temas muy importantes, de seguridad y casi a nuestra propia naturaleza. Así que, si existen riesgos reales, pero tenemos poco clara la visión futura, creo que conviene actuar, al menos a corto plazo. Desde luego, creo que podemos, casi diría que debemos, utilizar, y utilizar mucho, una tecnología tan potente y versátil como es la inteligencia artificial. Pero debemos hacerlo de una forma consciente y responsable, responsable con los demás y con nosotros mismos.

Y así, creo que cada uno de nosotros deberíamos exigirnos y esforzarnos en la supervisión de aquello que delegamos en la inteligencia artificial, desde grandes automatizaciones corporativas, hasta simples consultas a ChatGPT. Aunque nos cueste, aunque nuestra naturaleza nos impulse a ser cómodos y confiarnos, debemos esforzarnos conscientemente en ejercer el juicio crítico, el control y la autonomía.

Y, además, deberíamos cuidar nuestras capacidades cognitivas, intentando no sólo no perderlas sino incluso aumentarlas. Y para ello, dado que no vamos a dejar de utilizar la inteligencia artificial, quizá debamos reforzar nuestras capacidades, y hacerlo conscientemente, mediante actividades en paralelo que cuiden y desarrollen esas capacidades: lectura, estudio, actividades artísticas, interacción humana, etc

Es cierto que pongo mucho énfasis en la responsabilidad individual, en el auto-cuidado cognitivo, es cierto que, además, lo que propongo exige acción consciente y puede que esforzada, y es cierto, finalmente, que puede que las cosas cambien, y que en unos años o que las valoremos de una forma diferente, pero ahora mismo, a corto plazo, creo que es lo mejor que podemos hacer... y hacerlo cada uno de nosotros.

Conclusiones

El uso intensivo de las tecnologías, muy en especial la inteligencia artificial, puede conducir, por un lado, a una confianza excesiva en de las decisiones automatizadas y, por otro, a una progresiva degradación de nuestras capacidades cognitivas.

La combinación de ambos fenómenos, creo que es peligrosa tanto desde un punto de vista operativo como humano, cognitivo y casi ético.

Existe mucha incertidumbre sobre el nivel de riesgo real o cómo afrontarlo pero, a corto plazo, lo que creo que debemos hacer es reforzar, conscientemente, nuestra supervisión de los sistemas y, sobre todo, nuestro propio desarrollo cognitivo.

Automation blindness o el riesgo para human-in-the-loop

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

Una de las cosas que a veces asusta de la inteligencia artificial y a la que, de alguna manera, se intenta poner coto o controlar, es a la posibilidad de que los algoritmos tomen decisiones de forma automática, sin control humano.

Y por ello, entre otros mecanismos, se propone y se utiliza el denominado 'human-in-the-loop'. Sin embargo, esto también puede tener un riesgo.

Vayamos paso a paso.

Decisiones automatizadas

Nos asusta que una máquina pueda decidir de manera autónoma qué hacer. Y, en cierto sentido, podría parecer paradójico que a estas alturas nos preocupe esa automatización, cuando en muchos ámbitos de nuestra vida ya existe una profunda automatización .

La decisión automatizada existe, por supuesto, en plantas industriales, pero existe también en muchos sistemas de información de los que comúnmente se utilizan en empresas y administraciones.

Hasta máquinas de uso común, como los coches, tienen muchos elementos automatizados.

¿Por qué nos asuste entonces que decidan algoritmos de inteligencia artificial?

Aventuro que por tres motivos.

Por un lado, por la naturaleza de las decisiones. Ya que la inteligencia artificial automatiza tareas cognitivas, los algoritmos pueden automatizar decisiones tradicionalmente reservadas a humanos (por ejemplo, un diagnóstico médico o la decisión de concesión de un préstamo) y, justificadamente o no, nos resistimos a ceder ese poder.

En segundo lugar, porque con frecuencia no entendemos del todo cómo se toman esas decisiones. La mayor parte de los algoritmos de inteligencia artificial no toma las decisiones conforme a unas reglas claras, sino con base en unos patrones no del todo evidentes... o no evidentes en absoluto.

Quizá añadiría en tercer lugar el hecho de a veces, por suerte con poca o muy poca frecuencia, como no siguen los mismos razonamiento humanos, a veces fallan de forma inesperada y casi absurda, lo que, en alguna situación podría ser, aparte de imprevisible, directamente catastrófico.

Explicabilidad

Como una forma de eliminar, al menos parcialmente el segundo de los factores, el no saber cómo se toman las decisiones, existe desde hace años el concepto de explicabilidad de la inteligencia artificial (XAI, eXplainable AI) que busca, precisamente, que los algoritmos sí puedan explicar, de forma comprensible por los humanos, cómo toman las decisiones.

Se trata de un tema técnicamente complejo porque los algoritmos más potentes, los que proceden del campo de las redes neuronales y el deep learning, son esencialmente no explicables,

Pero, por sí sola, la explicabilidad, que además no se encuentra plenamente conseguida, no nos elimina el miedo a dejar en manos de un algoritmo una decisión automatizada. Si no hacemos nada más, la explicabilidad nos dice cómo ha decidido el algoritmo, pero lo hace 'a posteriori', una vez que la decisión ha sido tomada y, eventualmente, ejecutadas las acciones que siguen a esa decisión.

Human-in-the-loop

El mecanismo adicional es el denominado 'human-in-the-loop' que, estrictamente hablando, elimina la automatización.

Se trata, simplemente, de que en último término quien decide es un humano. El algoritmo evalúa la situación y propone una decisión...pero no la aplica automáticamente, sino que la somete a la supervisión de un humano que es quien decide si ejecuta realmente esa decisión o no.

En el fondo, como decía, la decisión ya no es automática aunque sí puede aprovechar la rápida y potente capacidad de análisis del algoritmo.

El riesgo de confiarse y dejarse ir

El riesgo al que se refiere el título de este artículo, un riesgo si se quiere un poco tonto, pero muy real, e incluso grave, es que el comportamiento humano habitual es que cuando el trabajar con el algoritmos se convierte en algo habitual, rutinario, y cuando, además, el algoritmo demuestra que en la práctica suele proponer cosas acertadas, el humano se confía, deja de analizar con tanto rigor lo que se le propone, deja de aplicar juicio crítico y comienza a aceptar sin más lo que el algoritmo propone.

A efectos teóricos hemos eliminado la automatización (y también algunos de sus beneficios de eficiencia y rapidez) pero, a efectos de control nos hallamos en la misma situación que si el algoritmo estuviese completamente automatizado, con la única diferencia, quizá, de que ahora tengamos un claro responsable ético y legal: el humano que, en teoría, es quien toma la decisión.

Pero el riesgo original de la decisión automatizada no lo eliminamos.

Automation blindness

Es efecto, el confiarse, es un iregso que ya había identificado, apreciado y comentado en diversos medios, pero lo que he descubierto recientemente es que tiene nombre, y ese nombre es 'automation blindness'.

Y lo descubro en el capítulo final, sobre responsabilidad, del libro 'Visualizing Generative AI' de Priyanka Vergadia y Valliappa Lakshmanan. En concreto, los autores lo explican, en el caso de la inteligencia artificia generativa, diciendo

As GenAI becomes better and its errors rarer, human users may fail to even perceive the few errors that remain or are introduced. They become less and less aware of the details and nuances involved.

Y nos cuentan que, en realidad, este término no procede del campo de la inteligencia artificial, sino de la aviación, donde se observó esa confianza en el mecanismo automatizado en el caso de pilotos de avión asistidos por pilotos automáticos.

The term automation blindness comes from aviation, where it describes how pilots become over-reliant on their automated systems, lose their situational awareness, and fail to recognize potential hazards or anomalies.

Un fenómeno confirmado, además, por estudios realizados por la NASA.

Improvisando algunas opciones de mitigación

¿Qué opciones nos quedan antes este fenómeno?

Pues, sinceramente, no creo que haya ninguna solución absoluta ni mágica pero, se me ocurre, un poco a bote pronto:

Por supuesto, poner aún más énfasis en que los algoritmos tomen la decisión adecuada desde el principio, por si acaso el humano no está muy atento

Incrementar, hasta donde se pueda, la calidad y simplicidad de las eventuales explicaciones que ofrezca el algoritmo, para simplificar que el humano entienda rápidamente la decisión y sus motivaciones.

Incluir, de serie, avisos por parte del algoritmo o de la aplicación de los eventuales riesgos e implicaciones de la decisión, visualizar esos avisos de manera muy clara y, si se detecta algún riesgo importante, usar los recurso gráficos y sonoros pertinentes para alertar al decisor humano.

Incluir mecanismos en las aplicaciones que fuercen al decisor humano a confirmar que toma la decisión conscientemente (por ejemplo, resumiendo muy brevemente en un texto, por qué lo decide). Esto sería ineficiente y algo 'pesado' y, además, no creo que elimine del todo la posibilidad de que el humano actúe sin pensar, pero supongo que sí lo disminuiría.

Finalmente, y aunque sea triste decirlo, incrementar los 'castigos' en caso de decisión equivocada y no eficazmente supervisada para que, aunque sólo sea por miedo, el humano preste más artención.

Ninguna de las opciones, por supuesto no excluyentes sino todo lo contrario, me parece completamente efectiva y alguna, como las dos últimas, la verdad es que no me gustan demasiado.

Lo cierto es que no veo una forma de eliminar completamente este 'automation blindness' que, en el fondo, es muy humano.

Supongo que sólo queda ser conscientes del mismo e intentar disminuirlo en la medida de lo posible.

Conclusiones

De cara a prevenir que los algoritmos de inteligencia artificial adopten de manera automatizada decisiones que puedan ser equivocadas, dañinas o poco éticas, una de las estrategias es la de su supervisión, y decisión final, por parte de un humano, lo que se conoce como 'human-in-the-loop'.

Sin embargo, esta estrategia se tropieza con algo tan simple como que a los humanos les cuesta mantener la atención y se confían cuando ven que, en general, las decisiones del algoritmo son acertadas, un fenómeno denominado 'automation blindness' y para el cual, por desgracia, no identifico ninguna estrategia definitiva, sólo mecanismos de mitigación.