lunes, 16 de febrero de 2026

El retorno del hardware: razones y perspectivas

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


miércoles, 11 de febrero de 2026

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

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. 


lunes, 9 de febrero de 2026

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

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. 


lunes, 2 de febrero de 2026

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

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.