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

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

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

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

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