Blue chip

¿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.

El eventual libre albedrío de los modelos generativos y el resquicio de la aleatoriedad algorítmica

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

Publico un nuevo artículo, en este caso casi más una 'reflexión en voz alta' que una argumentación profunda, sobre esa especie de serie de posts que estoy dedicando al determinismo (o aleatoriedad) de los algoritmos de la inteligencia artificial, muy especialmente los modelos generativos, y a la posibilidad (o no) de que un algoritmo o un modelo y, por tanto, una máquina, pudiese tener libre albedrío.

Aunque, en principio pensaba que este artículo iba a ser el último de esta serie, creo que no va a ser así, por algo que explicaré mas abajo, hacia el final del post.

En esta ocasión, quiero hacer una reflexión sobre si una eventual aleatoriedad de los algoritmos, abre o no la puerta para el libre albedrío.

Recapitulando: algoritmos deterministas... o casi

Intento resumir lo visto hasta ahora en artículos anteriores.

En general, he defendido que los algoritmos de inteligencia artificial en general, y los modelos generativos en particular, son, en el fondo, deterministas.

Sin embargo, he hecho una distinción que creo muy importante y he hablado de una especie de comportamiento dual.

Vistos desde fuera, vistos como usuarios, como ingenieros, como desarrolladores, como empresas, los modelos generativos se comportan como probabilistas, es decir, proporcionando resultados diferentes ante las, aparentemente, mismas entradas. Es decir, se comportan como si no fueran deterministas.

Sin embargo, si entramos al detalle, a un nivel muy fino y casi 'íntimo' del algoritmo, el funcionamiento realmente es determinista. ¿Por qué? Pues porque la aparente aleatoriedad se basa también el algoritmos que, aunque simulan muy bien la aleatoriedad, en realidad siguen un funcionamiento determinista. Para lograrlo usan funciones (como los generadores de números seudo-aleatorios) que suelen incluir alguna entrada, que el usuario 'no ve', que puede ser, por ejemplo, una semilla consistente en la fecha y hora exacta en que se invoca el algoritmo (hasta milisegundos, microsegundos o aún más precisión). Si, como usuarios, invocamos dos veces seguidas el algoritmo aportando los mismos datos, el resultado será diferente (porque la hora exacta de invocación es diferente), pero, en el fondo, si tuviéramos realmente todos los datos de entrada, incluyendo la hora exactísima de invocación, el resultado estaría completamente determinado.

Por ello, mi tesis básica es que los algoritmos, aunque por fuera se comporten claramente como probabilistas, por dentro son deterministas.

De hecho, y como vimos en otro post, existen mecanismos de gobierno del nivel de aleatoriedad de los algoritmos generativos, que permitirían, incluso, 'congelar' estos modelos y que se comportasen, también externamente, como deterministas, algo que, más allá de razonamientos teóricos, es bueno para poder probar y validar los modelos.

En el post anterior de esta serie, sin embargo, y con base en los estudios de Thinking Machines introdujimos algunas posibles 'grietas' en este razonamiento. Veíamos que esta compañía ha encontrado y demostrado la existencia de aleatoriedades basadas en cosas como problemas de redondeo en operaciones con números en coma flotante, diferencias en el comportamiento de los núcleos de las GPUs y, sobre todo, en la generación de los 'batches' que entran en los modelos generativos.

Aunque es más difícil de demostrar, creo que esas situaciones lo que reflejan son unas 'apariencias de aleatoriedad', desde luego ciertas vistas con visión externa y, además, en este caso no buscadas y no gobernadas explícitamente sino un poco 'fuera de control', por decirlo de alguna manera. Sin embargo, creo que un análisis muy detallado nos mostraría que, aunque, en efecto, no gobernadas, y aunque, también en efecto, con manifestación externa aleatoria, en su funcionamiento más íntimo siguen siendo deterministas.

Los autores del estudio, además, han encontrado la forma de eliminar esas 'grietas', devolviendo los algoritmos al redil del determinismo.

Pero, y si al final hay elementos de autentica aleatoriedad, ¿Qué sucede?

Veamos

Importancia de la aleatoriedad de los algoritmos para el libre albedrío

¿Por qué tanto empeño en ver la aleatoriedad o no de los modelos generativos? ¿Por qué darle tantas vueltas cuando, además, se reconoce que, en su comportamiento externo, sí que son probabilistas?

Pues, como decía al hablar de esa especie de dualidad entre la visión externa e interna, porque el determinismo o la aleatoriedad tienen una importancia casi filosófica o ética si queremos hablar de libre albedrío.

Si demostramos que un algoritmo es plenamente determinista, no queda lugar para el libre albedrío de las máquinas, para que éstas tengan alguna forma de voluntad propia, o al menos una voluntad consciente y autónoma, como la que entendemos tenemos los humanos. Al menos a mí no se me ocurre cómo un ente, natural o artificial, puede tener libre albedrío si su comportamiento es plenamente determinista.

Sin embargo, si el comportamiento no es plenamente determinista, no se demuestra, ni mucho menos, que exista libre albedrío, pero se abre un poco la puerta.

Entonces, si los algoritmos fuesen realmente probabilistas, con dosis de aleatoriedad ¿supone que pueden tener libre albedrío?

No, no necesariamente, pero al menos deja algún pequeño resquicio, alguna posibilidad, y la necesidad de seguirlo analizando.

Aleatoriedad frente a deliberación

De hecho, probablemente, la aleatoriedad o, más bien, el no determinismo, sea una condición, puede que necesaria, pero desde luego no suficiente, ni de lejos, para hablar de libre albedrío.

Probablemente, como tantas otras capacidades humanas, no tengamos una idea clara, científicamente clara quiero decir, de lo que es el libre albedrío y, sobre todo, cómo 'se implementa' en el ser humano, algo sobre lo que quiero seguir investigando. En cualquier caso, sí parece claro que, para hablar de libre albedríos, necesitamos bastantes más ingredientes que la mera indeterminación.

Casualmente, o no tan casualmente, me encuentro precisamente leyendo el documento 'Reclaiming human agency in the age of artificial intelligence' publicado por el Dicasterio para la cultura y la educación de la Santa Sede, en que razona sobre el concepto de agencia humana, frente a la agencia de que se habla en inteligencia artificial. Y hay un párrafo que creo esclarecedor. Dice:

Such deliberation is presupposed in free choice; it is what “specifies”our free choice. Free acts are not random; they are not the mere indeterminacy of chance events or the result of random generators, as in some machine simulations of agency

Nos habla de deliberación y explícitamente indica que la libertad de elección no es mera aleatoriedad. Sin entrar en análisis más académicos o sesudos, esa deliberación de que nos habla creo que incluye un análisis consciente del contexto y las opciones, y una toma de decisión también consciente.

Aunque este documento está generado por la Iglesia Católica, creo que la argumentación es general y perfectamente asumible por cualquier pensador y por cualquier persona.

Demos por válido, pues, que el libre albedrío incluye esa capacidad de deliberación. Sin entrar en el complejo tema de la 'consciencia' sí que parece claro que la mera aleatoriedad no incluye por sí misma ninguna forma de deliberación.

¿Excluimos, pues, ya del todo, la posibilidad del libre albedrío en máquinas?

Deliberación y modelos razonadores

Pues quizá todavía sea un poco precipitado y convenga analizar algo más.

Los modelos generativos más modernos, son del tipo denominado 'razonador': modelos que analizan el objetivo que se les pone, elaboran un plan de acción para conseguir ese objetivo, ejecutan las acciones del plan, evalúan los resultados que van obteniendo y, según sean éstos, cambian el plan o deciden 'cómo' seguir.

¿Es eso deliberación? ¿Abre eso otra puerta a un libre albedrío de las máquinas?

Bueno, este era el punto que no tenía en mi agenda de posts hasta el momento, pero que creo muy interesante y al que, casi seguro, le dedique otro artículo. Eso sí, ese artículo a lo mejor se demora algo, porque para aportar una argumentación seria, querría conocer el detalle de cómo funcionan estos modelos razonadores. Aunque he leído muchas descripciones, son someras y si profundidad técnica. Y, sinceramente, no sé si está publicada la arquitectura y algoritmia de este tipo de modelos (a lo mejor los fabricantes lo consideran confidencial y estratégico), pero, en cualquier caso, yo no he tenido la ocasión de estudiarla.

En cualquier caso confío, antes o después, en poder realizar algún análisis en esa línea.

La serie de posts dedicados al determinismo o no, y al libre albedrío o no, de los modelos generativos, queda, pues, aún abierta a la espera, como poco, de ese posts sobre deliberación y modelos razonadores..

Conclusiones

Aunque con una manifestación práctica externa los modelos generativos se comportan claramente como probabilistas, por dentro, su funcionamiento detallado es esencialmente determinista. Existen, eso sí, algunas pequeñas grietas por donde, quizá, se podría 'colar' alguna aleatoriedad.

Si hubiese aleatoriedad, ¿eso implicaría libre albedríos? Ni de lejos, lo que pasa es que si el algoritmo es determinista entonces sí que queda excluido el libre albedrío. Si existe aleatoriedad, existe alguna posibilidad, aunque sea remota.

Y, para que exista el libre albedrío, parece necesaria la capacidad de deliberación y decisión consciente, autónoma y libre. La aleatoriedad no garantiza, ni mucho menos, esa capacidad de deliberación pero ¿Qué pasa con los modelos razonadores? ¿Deliberan? ¿Ejercen o pueden ejercer alguna forma de libre albedrío?

Espero encontrar la información necesaria para argumentarlo en algún futuro post.

Artículos de este blog relacionados

Inteligencia artificial: la burbuja y la implantación

noreply@blogger.com (Ignacio G.R: Gavilán) — Mon, 26 Jan 2026 12:55:00 +0000

Confieso que, para estas reflexiones sobre la eventual burbuja de la inteligencia artificial, pensé en utilizar el título "¡Es la implantación estúpido!", una frase inicialmente articulada como "¡Es la economía, estúpido!" ('is the economy, stupid!') acuñada por el equipo de campaña de Bill Clinton allá por 1992, y que se ha utilizado con mucha frecuencia, realizando variaciones en que, en lugar de 'economía', se utiliza cualquier otro término que se quiera destacar.

Al final lo he desechado, primero, porque no me gusta el tono insultante que respira, segundo, porque tiendo a rechazar, cada vez más, las frases hechas y, finalmente, y en el fondo más importante, porque no refleja del todo lo que este post quiere transmitir, aunque si en parte: la importancia de la adopción de la inteligencia artificial, de la implantación real de soluciones, por parte fundamentalmente de empresas como factor fundamental para hablar o no de burbuja de la inteligencia artificial.

Pero, 'vayamos al lío'.

El significado de la burbuja

En esencia, hablar de 'burbuja' implica hablar de unas expectativas infladas, excesivas, bajo un punto de vista esencialmente económico aunque quizá con algún reflejo técnico.

El reflejo técnico, que creo no es el más relevante en este caso, implicaría que la inteligencia artificial no es (y no va a ser en breve) capaz de hacer todas las cosas que se le atribuyen. Y ese exceso de expectativas técnicas, podría desenfocar las expectativas económicas y de negocio, que son las que realmente importan cuando hablamos de burbuja.

Y en esa visión económica, una 'burbuja' nos habla de que las inversiones que se están realizando en inteligencia artificial no están respaldadas por el retorno que de ellas se puede esperar de forma realista en un plazo razonable. Y eso incluye, por ejemplo, empresas como la propia OpenAI que, de momento, lo que dan son unas pérdidas millonarias.

Si eso fuese cierto, si existiese realmente una burbuja, cuando empresas y gobiernos adquieran conciencia de que esas inversiones son irracionales y no recuperables, se puede parar la inversión, provocando con ello desaparición de empresas, deudas sin pagar, paro, etc, Y si esas consecuencias son de gran volumen, pueden conducir a una crisis económica global, en el sentido de no afectar sólo a alguna empresa, sino a estados completos e incluso a nivel mundial.

Dos declaraciones preliminares

Antes de seguir con lo que es el núcleo de este artículo, quisiera hacer dos declaraciones.

La primera es un humilde reconocimiento que no tengo información suficiente, ni una opinión formada, sobre si, desde el punto de vista económico, realmente estamos en riesgo de una burbuja en el caso de la inteligencia artificial. Sí creo que estamos en un mercado en ebullición y casi diría que en formación, que estamos en una frenética cascada de acontecimientos y que eso lleva a incertidumbre en las decisiones, unas decisiones que, ante la falta de un panorama claro, pero con la expectativa de un negocio billonario en el que no se puede dejar de estar, probablemente conduzca a decisiones financieras y de inversión más arriesgadas de lo que nos gustaría. Y también creo que, precisamente por tratarse de un mercado en formación, es normal la aparición de muchas propuestas y muchas empresas y que una dinámica normal conducirá, en los próximos años, a una estabilización y consolidación, en la que habrá ganadores y perdedores, quizá algunos muy sonados. Sí me parecen previsibles por ello movimientos y acontecimientos empresariales y económicos, algunos de los cuales, podrían ser 'catastróficos' para alguna entidad. Pero no necesariamente tiene que existir una burbuja 'en toda regla', una burbuja mundial, por decirlo de alguna manera.

La segunda declaración, de la que sí que estoy muy convencido, y que he expresado en más de un medio, es que 'no existe burbuja técnica'. Lo que con ello quiero decir es que las capacidades técnicas y operativas de la inteligencia artificial son reales y ya están aquí, que sólo con aquello de que disponemos actualmente, empresas y administraciones, incluso particulares, pueden dar grandes saltos de productividad, eficiencia e innovación. Eso no quiere decir que no exista 'hype', que lo hay, o que no existan partes de la inteligencia artificial, como, en mi opinión, son los agentes, los robots humanoides o los vehículos autónomos, que tengan aún que demostrar su viabilidad generalizada tanto técnica como de negocio. Pero, insisto, sólo con lo que ya hay, lo que de verdad hay, y sin esperar a que mejore (cosa que sucederá seguro), las aplicaciones y el impacto económico son enormes.

La importancia de la implantación

Y esta última consideración me lleva a la implantación, a la adopción real de soluciones de inteligencia artificial por parte de empresas y administraciones.

Una condición fundamental para que no exista burbuja es que las empresas que apuestan por la inteligencia artificial obtengan un suficiente retorno económico, tanto las empresas creadoras de tecnología, como las organizaciones que, 'simplemente', la usan.

Y, para ello, es condición imprescindible que las empresas, administraciones y, en este caso, incluso los particulares, adopten las soluciones de inteligencia artificial. Porque esas empresas, administraciones y particulares sólo obtendrán beneficios económicos de la inteligencia artificial si realmente la usan y la usan de manera exitosa, de forma que les resulte interesante o rentable hacerlo y que, además, claro, estén dispuestos a pagar por la tecnología y por los servicios asociados.

Y es imprescindible la adopción masiva y exitosa para que esas empresas, administraciones y particulares paguen a las empresas creadores de la tecnología o prestadoras de los servicios asociados, de forma que éstas obtengan un retorno que las haga rentables y que justifique su inversión.

Algunas barreras para la implantación

Pero se me ocurre, de una forma que confieso no del todo sistemática, pensar en barreras a esa adopción tan importante para evitar la eventual burbuja.

La primera sería, casi paradójicamente, la rapidez del cambio. Surgen de manera frenética nuevas evoluciones, nuevas herramientas, nuevas posibilidades. Y esa rapidez, que desde el punto de vista de la tecnología y la innovación es maravillosa, curiosamente creo que corre en contra de la adopción. Y eso porque organizaciones y personas, se encuentran perplejas, perdidas ante tantas posibilidades que no asimilan del todo. Eso, además, dificulta la adopción de estrategias y toma de decisiones de adopción, porque es muy difícil saber qué casos de uso son viables y más importantes o qué producto o solución usar y tener una cierta seguridad de que las decisiones van a mostrarse como correctas pasadas unos meses. A eso añadir que esa velocidad también dificulta la disponibilidad de personas y talento, tanto interno como externo, preparado como para hacer una implantación.

Por otra parte, también hay que reconocer que existe 'hype', que existe multitud de promoción exagerada, promesas de capacidades aún no demostradas. Y para un decisor empresarial, si ya la abundancia de soluciones y velocidad de aparición dificulta la decisión, la conciencia de que, además, no todo lo que se publicita está realmente maduro como para una adopción, no hace sino reforzar la perplejidad, en este caso la desconfianza, y retrasar las implantaciones o hacerlas mediante pilotos limitados de bajo riesgo, pero también bajo alcance e impacto en el negocio.

Y no excluiría de la ecuación el miedo. No ya sólo el miedo a no tomar la decisión operativa o económicamente adecuada, sino miedo a los riesgos de naturaleza ética o regulatoria. En un, quiero pensar que bienintencionado, intento por evitar las consecuencias negativas desde un punto de vista ético del uso de la inteligencia artificial, y también de posibles incumplimientos legales y normativos, se pone muchas veces mucho énfasis en riesgos y problemas y por ello los decisores pueden andarse con 'pies de plomo' antes de arriesgarse a cometer un error en este terreno.

Algunas de las soluciones de inteligencia artificial son de naturaleza corporativa, como ocurre con muchos sistemas de información tradicionales. Pero en el caso de la inteligencia artificial generativa, muchas herramientas y posibilidades se producen a nivel individual. En este punto, lo que parece lógico y deseable es que las empresas pongan a disposición de sus empleados las herramientas que, en el fondo, esos mismos empleados usan en sus entornos domésticos, como los chatbots generativos (ChatGPT, Copilot, Gemini, Claude, etc), las integraciones de IA en herramientas ofimáticas como Office 365 o Google Workspace, el uso de herramientas para generar contenidos o presentaciones (Canva, Gamma, etc) y así un largo etcétera. Sin embargo, creo que las empresas y administraciones tienen un poco echado el freno de mano en este apartado, por miedo, en esencia, a fugas de información (externas o internas) o, quizá, a la calidad de los resultados que produzcan sus empleados.

Es posible que exista alguna barrera más, incluida la tan traída y llevada falta de talento en estos campos, pero creo que, aunque no dejan de ser opiniones, las barreras anteriores son reales y frenan en parte el despliegue de soluciones de inteligencia artificial.

Y si se frenan los despliegues, si retardamos la obtención de retornos por parte de todos los actores, corremos el riesgo de hacer que esa burbuja sea cierta y posibilitar o acelerar su pinchazo.

Frente a la burbuja de las 'subprime'

Si quisiera dejar claro que, caso de existir, esta burbuja de la inteligencia artificial no es comparable a la burbuja y consecuente crisis de las 'subprime'. ¿Por qué? Porque aquella se produjo por la creación y gestión irresponsable, cuando no culpable, de unos activos financieros que no estaban respaldados, que no tenían, ni de lejos, el valor que se les asignaba en las transacciones.

En el caso de la inteligencia artificial, como he dicho, sí existe un valor real, y un valor muy grande. El que sea una burbuja o no dependerá de si, aunque ese valor exista, que existe, se haya sobrevalorado o no se materialice por falta de adopción.

Enseñanzas de la burbuja de las puntocom

Si nos vamos algo más lejos, al caso del estallido de las puntocom allá por el año 2000, sí asistimos patrones más parecidos al caso de la inteligencia artificial actual. No sólo porque hablamos de una eventual burbuja de base tecnológica sino porque el valor era real.

El valor que tenía internet, las redes sociales, el comercio electrónico y todo lo que se dio en llamar 'la nueva economía' era real, y tan real era que pocos años después se comenzó a notar en despliegues reales y masivos y, de hecho, hoy vivimos plenamente inmersos, seamos conscientes o no, en esa 'nueva economía'.

La promesa de las puntocom falló no porque las posibilidades no fueran reales sino porque, seguramente, se vieron mas cercanas de lo que realmente eran y porque se tomaron muchas decisiones de inversión probablemente irracionales o con un exceso de riesgo.

Y esto es lo que hay que evitar en el caso de la eventual burbuja de la inteligencia artificial.

Y para ello, en primer lugar, y esto no es desde luego fácil en un entorno tan volátil, tan en ebullición como el de la inteligencia artificial, que empresas y administraciones inviertan de una manera racional, tanto en volumen como en soluciones con posibilidades reales.

Y por otra parte, que se produzca la adopción, la implantación generalizada de soluciones de inteligencia artificial que reporte beneficios tanto a las organizaciones clientes de esas tecnologías como a los fabricantes y prestadores de servicio.

Conclusiones

Existe un cierto 'runrún' acerca de si nos encontramos ante una burbuja de la inteligencia artificial, que supondría unas expectativas, y consiguientes inversiones, desmedidas y sin un retorno claro.

En este artículo expreso mi convencimiento de que, desde el punto de vista estrictamente técnico, no existe tal burbuja, pero que es posible que si sea real desde el punto de vista económico, que en el fondo es el que importa.

Y destaco cómo, para que esa burbuja no se produzca, es fundamental la implantación masiva de soluciones que generen los retornos esperados, para lo cual, sin embargo, existen algunas barreras.

Grietas en el determinismo de los modelos generativos: limitaciones, errores e imprevistos

noreply@blogger.com (Ignacio G.R: Gavilán) — Wed, 21 Jan 2026 12:00:00 +0000

Ya he hablado en algunos post recientes sobre el carácter probabilista o determinista de los modelos generativos, en especial de los grandes modelos de lenguaje, LLM ('Large Language Models').

Mi conclusión hasta ahora, es que, aunque de comportamiento externamente probabilista, internamente tienen un funcionamiento plenamente determinista. Incluso, como veíamos en el último post de la serie hasta ahora, esa aleatoriedad externa se puede exacerbar y, lo que es más importante, eliminar, o congelar, usando parámetros de configuración.

Y esta conclusión momentánea, excluye, en mi opinión, la posibilidad de un libre albedrío de las máquinas.

Sin embargo, hay experiencias prácticas y estudios científicos que desafían ese determinismo subyacente, y que muestran que, aunque los modelos 'se congelen' (es decir, se elimine el carácter probabilista mediante el ajuste de parámetros), se siguen produciendo resultados no deterministas.

¿Cómo es eso posible?

Según vamos a ver, creo que podemos considerar que esos efectos no deterministas se producen por limitaciones en el hardware y errores en el diseño o implementación de los modelos o, si preferimos no ser muy duros, por la aparición de fenómenos imprevistos, muy difíciles de haber anticipado a priori.

En este post, probablemente el más técnico de la serie, vamos a revisar algunos de esas limitaciones, errores o imprevistos que desafían el determinismo de los modelos.

Y para ello me baso en el muy interesante, pero también complejo, artículo 'Defeating Nondeterminism in LLM Inference' publicado por Thinking Machines la startup de Mira Murati, quien fuera CTO ('Chief Technology Officer') de OpenAI.

Los números reales y la coma flotante

El primero de los problemas que se describe en el artículo, pero que ha sido tratado anteriormente por otros autores, aborda problemáticas derivadas del trabajo con números reales representados en el formato denominado 'coma flotante'.

Recordemos brevemente qué es eso de 'coma flotante'. Se trata de una estrategia de representación en formato digital (unos y ceros) de números reales (por entendernos, los que tienen decimales).

Supongamos que queremos representar números reales usando 4 bytes (es decir, 32 bits y, por lo tanto, la posibilidad, a priori, de representar 2³² números diferentes). Si ahora queremos representar números decimales, podríamos decidir dedicar tres bytes a representar la parte entera del número y uno a representar la parte decimal. Con esto, tendríamos lo siguiente:

Un bit para indicar el signo (positivo o negativo)

23 bits para indicar la parte entera, con lo cual, podríamos representar hasta el 2²³, es decir, hasta 8.388.608

8 bits para la parte decimal, lo cual nos daría una precisión (incremento más pequeño, por decirlo de alguna manera, de 2^-8, es decir 0,00390625

Esto es fácil de entender y gestionar, pero tiene dos problemas: un rango limitado (cantidad de números que puede representar) y una precisión limitada. Aparte de la opción de incrementar el numero de bits, la que se suele adoptar es usar el denominado formato de coma flotante, que es lo que estamos acostumbrados a visualizar como 'notación científica'.

En este caso, representamos un número real 'x', que 'pensamos' como

x = ± m×2^e

donde m es lo que se denomina mantisa y que está constituido por las cifras significativas (aquellas que aportan información real sobre su valor, excluyendo, en esencia, los ceros que sirven solo como relleno de posición) y 'e' es el exponente (que puede ser positivo o negativo)

En el caso del formato se simple precisión IEEE 754, los bits se utilizarían de la siguiente forma:

un bit para el signo

8 bits para el exponente, que es quien controla, en el fondo, la posición de 'la coma' en la representación binaria

23 bits para la mantisa

No quiero, 'liarlo' ya mucho más, pero sí decir que los bits que utilizamos en la mantisa nos dan la precisión, que en esta caso son 24 bits (23 bits de la mantisa más uno).

Esta forma de representar los números reales, habituales en cálculos científicos y, desde luego, en machine learning, tiene ventajas de cubrir rangos muy amplios pero viene con alguna limitación o desventaja. Por un lado, necesita de un hardware y software más complejo y, sobre todo, y lo que nos interesa en este momento es que, no sólo no puede representar de manera exacta muchos números (por falta de precisión) y, lo más importante de todo: comete errores de redondeo.

Asociatividad y condiciones de carrera

Cuando usamos la representación en coma flotante cada representación concreta de un número tiene la misma precisión pero puede tener 'la coma' en un sitio diferente.

En el artículo se nos muestra con un ejemplo sencillo cómo si sumamos dos números en coma flotante con diferente posición de 'la coma', es decir, con diferente exponente, puede suceder que el numero resultante (la suma) necesite de una precisión superior a aquella de la que disponemos (digamos porque uno es muy grande y el otro muy pequeño). Representar correctamente el número resultante, un número 'muy grande' pero 'con muchos decimales', implicaría disponer de más bits en la mantisa de los que tenemos.

Por tanto, en la operación es preciso hacer un redondeo que nos permita encajar el resultado en la precisión disponible. Y, en ese redondeo, perdemos información, generamos un cierto error.

En el artículo se nos explica que, en ese caso, el orden en que realizamos las operaciones entre números (los mismos números) impacta en el resultado. En concreto, nos muestra cómo la propiedad asociativa

a + (b + c) = (a + b) + c

no se mantiene, realmente. Para, admitiendo que se puede producir un error de redondeo pero que, al menos, eso no llevase a resultados diferentes en ejecuciones diferentes, habría que garantizar que las operaciones se realizan exactamente en el mismo orden.

Pero eso, ese mantenimiento del mismo orden, no sucede, y la explicación de por qué no sucede nos lleva al mundo del hardware, de los famosos GPU ('Grahical Processing Unit') y procesadores similares

El hardware y condiciones de carrera no deterministas

Los modernos procesadores, como los GPUs, están compuestos de muchos núcleos o 'cores' que pueden procesar en paralelo diferentes operaciones, siendo las operaciones que se paralelizan en una GPU para tratar muchos datos, lo que se conoce como 'kernels' (que, lamentablemente, en castellano se suele traducir también como núcleo). Estos 'cores' funcionan de manera concurrente y sin sincronización entre ellos.

Una hipótesis formulada en otros trabajos para explicar el no determinismo, supone que el problema del no determinismo nace de que los propios 'cores' funcionan de manera no determinista. Esto quiere decir que un algoritmo hace que se lancen concurrentemente varios cálculos cuyos resultados luego, digamos, que se van a ir por ejemplo sumando (acumulando) a medida que acaben. Pero no es determinista cuándo finaliza cada 'core su cálculo y, por tanto, no es podemos saber en qué orden se va a a sumar o acumular cada resultado parcial.

Como, por lo que hemos visto más arriba, en operaciones en coma flotante se producen errores de redondeo diferentes según el orden de las operaciones, esto lleva a que el resultado final del algoritmo sea no determinista.

Sin embargo, aunque los autores del artículo explican esta hipótesis, afirman que en la práctica, los problemas reales y las implementaciones reales de las típicas librerías python involucradas, hacen que este problema no aparezca nunca o casi nunca.

Peticiones en paralelo

Los autores, sin embargo, aportan otro escenario.

Indican que los LLMs cuando se utilizan en inferencia ('forward pass') son, en efecto, deterministas. Ante una misma petición del usuario, responderán lo mismo (asumo que hemos eliminado el paso final de selección probabilista de token que expliqué en el post anterior).

El problema, según indican, es la concurrencia de diferentes peticiones y la creación, por ello, de diferentes 'batches'. Es decir, mantienen que si, el 'forward pass' considerado individualmente es determinista, pero el sistema en su conjunto, no.

Antes de seguir, comentar que los 'batches' son las entradas que, efectivamente, se envían a un LLM. Por eficiencia de implementación, los batches que se envían pueden, en realidad, incluir textos de entradas de usuario diferentes. Aunque, en teoría, el tamaño de los batches y las entradas que combinan no debería afectar al resultado, los autores muestran que no es así, que sí que afectan

Y eso porque no existe en los 'kernels' la denominada 'batch-invariance', es decir, el procesamiento de las peticiones de un usuario no es completamente independiente de los batches que procesa y, por tanto, del procesamiento de las peticiones de otro usuario.

Para explicarlo los autores se centran en las operaciones de multiplicación de matrices (que se utilizan profusamente en machine learning y deep learning y, por tanto, también en la inferencia de los LLMs).

Parece que, esas operaciones deben ser deterministas (y en teoría lo son) y que, además, no les debería afectar otras operaciones en paralelo. Bueno, pues esto último, no es del todo cierto.

¿Por qué?

.Pues porque la carga computacional a que se ve sometido un LLM (y, sobre todo, el hardware que lo soporta) se ve afectado por la cantidad y naturaleza de las peticiones a que se ve sometido. Es decir, el tamaño de los 'batches' que se van enviando al LLM se pueden modificar según la carga, o dicho de otra forma, la carga computacional determina el tamaño de batch. Y como los 'kernels' no son invariantes respecto al batch (no son 'batch-invariant') el resultado puede modificarse según sean las peticiones en paralelo.

En busca de la invariancia

Todo lo que he explicado hasta el momento, apenas ocupa la mitad, aproximadamente, del artículo en que me baso. En lo que resta, los autores, se centran en indicar (de forma muy técnica) cómo conseguir que los 'kernels' sean realmente 'batch-invariant'. Para ello, asumen que las operaciones más básicas son invariantes y entienden que basta con conseguir la invariancia en tres operaciones complejas y muy importantes, a saber:

La aplicación de la RMSNorm ('Root Mean Square Normalization'), operación de normalización (ajuste de los valores a un rango concreto) usada en entrenamiento e inferencia

Multiplicación de matrices

Mecanismo de atención: elemento fundamental de las arquitecturas transformes y que aporta el nivel de importancia que se asigna cada elemento de la entrada

Los autores, además, afirman disponer de una implementación de esas soluciones y aportan datos de los experimentos realizados

Vuelta al determinismo

En sus conclusiones, los autores se posicionan a favor del determinismo de los algoritmos en el sentido de que, no debemos aceptar los errores que se han observado (y que hemos descrito) y que llevan a que los LLMs no sean completamente deterministas.

Dicen que, con un poco de trabajo, se pueden entender las causas raíces de ese determinismo y resolverlas. Y abogan por ello, claro.

Implicaciones de cara al libre albedrío de las máquinas

Si aplicamos las recetas de estos autores, está claro que volvemos a la situación que yo siempre había afirmado (y que aquí hemos visto algunas grietas) volveríamos a estar en el caso de algoritmos plenamente deterministas, al menos en su comportamiento interno, aunque así no en su manifestación externa.

Y, en ese sentido, no habría lugar, al menos eso entiendo yo, para pensar en un libre albedrío ni voluntad propia de las máquinas, al menos las actuales.

Pero ¿Y qué pasa si no resolvemos eso? ¿Qué pasa si se siguen produciendo errores de redondeo y, sobre todo, si esos errores, ante condiciones de carrera o peticiones en paralelo de usuarios y unos 'kernels' no invariantes en batches, nos llevan a resultados no deterministas?

¿Abre eso realmente la puerta a un libre albedrío de las máquinas?

Creo que esa reflexión la reservo para un siguiente post, algo menos técnico y más especulativo y filosófico y con el que, creo, cerraré de momento este pequeño grupo de artículos dedicados al determinismo de los modelos generativos.

Conclusiones

Aunque externamente los modelos generativos, y en concreto los LLMs, se manifiestan como probabilistas, en su funcionamiento interno siguen algoritmos muy claros (aunque complejos) y en que el comportamiento probabilista está también perfectamente delimitado mediante parámetros de configuración por lo que, internamente, y sobre todo para razonar sobre libres albedríos, podemos considerarlos, en principio, deterministas.

Sin embargo, según hemos visto en este artículo, hay algunas grietas no buscadas en ese determinismo, pequeñas dosis de aleatoriedad no controlada y achacables, podríamos decir, a errores de diseño o implementación debidos, seguramente, a imprevistos.

En el propio artículo hemos visto que hay alguna propuesta para 'devolver al redil' a esos LLMs y que vuelvan a ser, internamente, plenamente deterministas.

Lo que queda por razonar es si esas brechas en el determinismo, realmente abren alguna posibilidad al libre albedrío de las máquinas o no.

Pero eso queda ya para otro post.

Artículos de este blog relacionados

Trabajo y empleabilidad en tiempos de Inteligencia Artificial. Una reseña de "De la EGB a la IA"

noreply@blogger.com (Ignacio G.R: Gavilán) — Fri, 16 Jan 2026 10:45:00 +0000

'De la EGB a la IA' es un libro coral que ofrece diferentes perspectivas sobre el impacto de la tecnología digital, especialmente la inteligencia artificial, en el ámbito laboral y la empleabilidad con especial foco en las personas jóvenes. En él, cada uno de sus trece autores ofrece, en un capítulo diferenciado, un reflexión en un campo específico que constituye su ámbito de interés y/o experiencia.

El libro se encuentra prologado por Juan Zafra con un inicio titulado 'El mundo será como queramos hacerlo' y, a partir de ahí, se estructura en doce capítulos cada uno de diferente autoría y temática, tal y como sigue:

'Capítulo 1. Época de nuevos y mejores hombres (Félix Hernández de Rojas):' ofrece una mirada amplia, que incluye lo económico, lo cultural y lo ético, muy apoyada en datos e informes, y con toques de geoestrategia y geopolítica, acerca del impacto y los retos del mundo digital.

'Capítulo 2. Empleabilidad en el s. XXI (Manuel García Gil):' a través de un diálogo padre-hijo, en apariencia ligero pero muy ilustrativo, reflexionamos sobre la empleabilidad y el desarrollo de capacidades.

'Capítulo 3. La importancia de desarrollar una nueva mentalidad digital (Virginia Cabrera Nocito):' Una explicación de lo que es la mentalidad digital, qué habilidades y capacidades comprende y los ejes para el desarrollo de una mentalidad de crecimiento en este entorno digital.

'Capítulo 4. Algo más que tecnología para tu plan digital personal (Pablo Pinillos):' identificación de las habilidades que, más allá del casi inevitable conocimiento STEM, deben adornar al profesional del presente y del futuro. Unas habilidades que incluyen, entre otras muchas, la comunicación verbal, no verbal y escrita, y unas habilidades que se pueden apoyar en el teatro como forma de entrenamiento. Y también una visión casi de marca personal que aboga por la gestión de la reputación digital y el establecimiento de un plan de marketing personal.

'Capítulo 5. Guía para la supervivencia en el apocalipsis zombi laboral (Julio Jesús Sánchez):' Una reflexión que puede parecer jocosa pero que en realidad muestra muchas sombras para la perspectiva laboral que vienen de la mano, o como consecuencia, de la transformación digital y que la explosión de la inteligencia artificial no hace sino agravar. Se analiza ese impacto y se acaba proponiendo un recetario con ocho ingredientes para sobrevivir en ese 'apocalipsis zombi'.

'Capítulo 6. Tu responsabilidad en un mundo robotizado (Ignacio G.R. Gavilán):' Una cerrada apuesta por la ética y la responsabilidad, institucional y corporativa, pero sobre todo individual, y para con los demás, pero también con uno mismo, ante los desafíos éticos y sociales que plantea lo digital y, muy especialmente, la inteligencia artificial y el auge de los robots.

'Capítulo 7. Cómo manejar la no tan inteligente inteligencia artificial en el puesto de trabajo (Roberto García Esteban):' Parte de una cierta desmitificación de la inteligencia artificial para luego identificar sus tres principales impactos en el terreno laboral y ofrecer unas consideraciones sobre la sustitución o no del ser humano por la inteligencia artificial.

'Capítulo 8. IA generativa, liderazgo y nuevos modelos de colaboración (Alejandro de Fuenmayor Rossell):' Una larga e ilustrada reflexión acerca del impacto de la revolución digital y cognitiva e, incluso, de la pandemia del COVID con foco en la automatización e incluso los paradigmas de desarrollo de software, finalizando con mirada al futuro en cuanto a tendencias tecnológicas y su impacto en el trabajo y culminando en una propuesta final de un nuevo modelo de trabajo.

'Capítulo 9. Las plataformas de metaverso en el futuro del trabajo (José Carlos Martín Marco):' Ahora que parece que el metaverso ha perdido fuelle, aquí nos encontramos con una decidida y argumentada apuesta por los entornos de colaboración a través de avatares en entornos virtuales en 3D, una apuesta que se desarrolla siguiendo todo el desarrollo histórico de las tecnologías de comunicación, interacción y virtualización.

'Capítulo 10. ¿Por que te digo que la productividad no asegura la creatividad? (Javier Lorente):' la importancia, la necesidad en realidad de la creatividad y la de su desarrollo, una importancia que se argumenta comenzando por un análisis de impactos de la digitalización en materias como remotización, escalabilidad, automatización y, finalmente, productividad, para luego analizar la afectación cognitiva de trabajar incorrectamente en entornos digitalizados y eficientes, lo que lleva como consecuencia a la importancia de desarrollar la creatividad para lo que se proporcionan diez consejos prácticos.

'Capítulo 11. ¿Por qué estudiar desarrollo de software en la era del ChatGPT(Víctor Deutsch):' Pone foco en una actividad profesional, el desarrollo de software, cuyos ejecutores, los desarrolladores, han sido los grandes protagonistas de la revolución digital pero cuyo propio empleo puede parecer ahora amenazado por las capacidades que ofrece la inteligencia artificial. Tras un repaso histórico de esta actividad, el desarrollo de software, se defiende la necesidad y utilidad actual de estos perfiles, se identifican las nuevas habilidades que deben exhibir, se apuesta por disciplinas como DevOps o ciberseguridad, y se identifica un nuevo rol para el presente y futuro: el gestor de productos digitales.

'Capítulo 12. El jefe de un cíborg no tiene por qué ser un ingeniero. Humanistas en la era de la IA (Carmen Menchero de los Ríos):' Se concentra en las oportunidades de los profesionales de disciplinas humanistas en este nuevo mundo inundado de inteligencia artificial, incluyendo un repaso por perfiles como psicólogos, pedagogos, antropólogos, documentalistas, periodistas, abogados, filósofos o historiadores.

El libro se cierra con un epílogo firmado por la decimotercera autora, Mercedes Núñez, que resalta la incertidumbre actual y futura, la falta de un suelo firme en que apoyarse lo que trae consigo exigencias en materia de formación constante, colaboración o las así llamadas 'habilidades blandas'. Y culmina con una llamada a dejar espacio también a la desconexión, la conciliación y el descanso.

'De la EGB a la IA' constituye una visión multidisciplinar, rica en perspectivas y apoyada en la larga experiencia profesional y vital de sus autores, sobre lo que nos ha traído y puede traer consigo este mundo cada vez más digital, más tecnológico y con una futuro para el trabajo y el empleo sobre el que existen, seguramente, más incertidumbres que certezas.

Mundos posibles

(Fuente: Elaboración propia a partir de la solapa del libro 'De la EGB a la IA en su edición de 2025 en Caligrama).

Equipo de 'Mundos Posibles'

'Mundos posibles' es un colectivo de profesionales de larga experiencia cuyos miembros tienen en común el haber pertenecido en algún momento de sus carreras a Telefónica y, en concreto, a la unidad Telefónica Empresas de Telefónica de España y haber colaborado en el mítico blog, ya desaparecido, denominado 'A un Clic de las TIC' de esta misma unidad.

Así se presentan:

Somos un colectivo multidisciplinar con largas y diversas trayectorias profesionales. Cada uno de nosotros vive, desde hace años y en primera persona, la transición a la era digital y podría decirse que ha tenido que mudar varias veces de piel. Todos pertenecemos, o lo hemos hecho, a empresas punteras del sector tecnológico, lo que nos ha permitido contemplar con cierta antelación este nuevo mundo. Apenas se abre paso, pero su complejidad ya nos abruma. En el terreno laboral los retos son enormes. Las posibilidades también.

Por eso queremos compartir nuestro aprendizaje con los jóvenes que van a desembarcar en él próximamente, con quienes se tendrán que reinventar y con aquellos que tienen la responsabilidad de seleccionar al talento correcto. No es que conozcamos el futuro, pero sí tenemos algunas claves. Cada uno, las suyas. Pensamos que una visión poliédrica y plantearse las preguntas adecuadas es la mejor estrategia en tiempos de incertidumbre. En este libro queremos compartir nuestras lecciones aprendidas.

Los componentes de este grupo son, en orden alfabético:

Virginia Cabrera Nocito
Víctor Deutsch
Alejandro de Fuenmayor Rossell
Roberto García Esteban
Manuel García Gil
Ignacio G.R. Gavilán
Félix Hernández de Rojas
Javier Lorente
José Carlos Martín Marco
Carmen Menchero de los Ríos
Mercedes Núñez Sánchez
Julio Jesús Sánchez
Pablo Pinillos Clemente

Puedes conocer más de 'Mundos posibles' visitando o siguiendo su su página en LinkedIn.

Vídeo de promoción

Tanto la personalidad y trayectoria como el planteamiento y contenido del libro se resumen en este vídeo de promoción lanzado por el equipo de 'Mundos posibles' .

Ficha técnica:

TITULO: De la EGB a la IA

AUTOR: Mundos posibles (varios autores)

EDITORIAL: Caligrama

AÑO: 2025

ISBN: 979-8341634756

PAGINAS: 350