Sin embargo, existe una capa tecnológica que rara vez recibe protagonismo y que resulta crítica para el funcionamiento diario de cualquier cadena de tiendas: el soporte IT.

La realidad es que una incidencia tecnológica en un entorno retail tiene un impacto directo sobre la operativa del negocio. Un terminal que deja de funcionar, un dispositivo móvil con problemas de conectividad o una aplicación que falla en tienda pueden traducirse en pérdida de ventas, reducción de productividad y una peor experiencia para clientes y empleados/as.

En este episodio analizamos cómo está evolucionando el soporte IT en el sector retail y por qué las compañías necesitan pasar de un modelo reactivo a uno cada vez más proactivo, automatizado y basado en datos.

El reto de gestionar miles de dispositivos distribuidos

A diferencia de otros sectores, el retail opera sobre infraestructuras altamente distribuidas. Una gran cadena puede tener cientos o miles de tiendas, cada una con múltiples dispositivos: terminales de punto de venta, equipos de back office, tablets, smartphones corporativos, impresoras, dispositivos de inventario y otros elementos conectados.

Gestionar este ecosistema supone un desafío considerable. No se trata únicamente de resolver incidencias cuando aparecen, sino de garantizar que todos esos dispositivos funcionen correctamente de forma continua.

En este contexto, el soporte tradicional basado exclusivamente en tickets y atención reactiva resulta insuficiente. Cuando una organización opera a gran escala, esperar a que el usuario reporte un problema significa que el impacto ya se ha producido.

La importancia de la monitorización proactiva

Uno de los grandes cambios que está experimentando el soporte IT es la incorporación de capacidades avanzadas de monitorización. El objetivo ya no es únicamente detectar fallos, sino anticiparse a ellos.

Gracias a la recopilación continua de métricas sobre rendimiento, capacidad, uso de recursos y estado de los dispositivos, las empresas pueden identificar anomalías antes de que se conviertan en incidencias reales.

Esta visibilidad permite actuar con antelación sobre problemas de almacenamiento, degradaciones de rendimiento, errores recurrentes o configuraciones incorrectas, reduciendo significativamente el impacto sobre la actividad diaria de las tiendas.

Además, cuando hablamos de entornos con miles o decenas de miles de dispositivos, la monitorización debe ir acompañada de capacidades automáticas de análisis. La cantidad de información generada es tan elevada que resulta imposible gestionarla manualmente.

Del soporte reactivo al soporte inteligente

La evolución natural del soporte IT pasa por incorporar mecanismos capaces de transformar datos técnicos en información útil para la toma de decisiones.

Las plataformas modernas no solo identifican incidencias, sino que generan diagnósticos, proponen acciones correctivas e incluso mantienen un histórico de actuaciones que facilita la resolución de problemas similares en el futuro.

Este enfoque permite reducir drásticamente el tiempo que los equipos dedican a tareas repetitivas y de bajo valor añadido. En lugar de que los equipos técnicos tengan que analizar individualmente cada dispositivo para localizar el origen de un problema, las herramientas proporcionan una visión consolidada de la situación y recomendaciones concretas para actuar.

El resultado es una mayor eficiencia operativa y una capacidad de respuesta mucho más rápida.

La IA como acelerador, no como sustituto

La incorporación de la inteligencia artificial está acelerando esta transformación.

Los nuevos sistemas son capaces de detectar patrones, correlacionar eventos y sugerir soluciones de forma automática. Sin embargo, esto no implica la desaparición del factor humano.

En entornos empresariales complejos sigue siendo imprescindible la supervisión de perfiles experimentados que aporten criterio, contexto y capacidad de decisión. La tecnología puede procesar grandes volúmenes de información y proponer acciones, pero la validación final continúa siendo responsabilidad de los equipos especializados.

Por eso, el futuro del soporte IT no pasa por eliminar a los/as profesionales, sino por proporcionarles herramientas que les permitan ser más eficientes y centrarse en actividades de mayor valor.

Hacia un nuevo modelo de soporte en retail

El soporte IT está evolucionando desde un modelo centrado en la resolución de incidencias hacia otro basado en la prevención, la automatización y el análisis inteligente de datos.

La combinación de monitorización continua, plataformas de observabilidad, automatización e inteligencia artificial permite construir servicios más eficientes, escalables y preparados para entornos distribuidos como los del sector retail.

En un contexto donde cada vez más procesos dependen de la tecnología, garantizar la disponibilidad y el correcto funcionamiento de los sistemas se ha convertido en una capacidad estratégica.

Y aunque muchas veces permanezca en segundo plano, el soporte IT sigue siendo uno de los pilares que hacen posible que toda la experiencia digital funcione con normalidad.

Para este post parto de una premisa importante. La IA nos aporta muchísimas cosas positivas y se ha convertido en una ayuda indispensable, tanto para perfiles de desarrollo como para otros perfiles técnicos, entre los que me incluyo como QA.

A estas alturas ya existen muchísimos artículos hablando de las ventajas de utilizar IA. Sin embargo, me cuesta encontrar contenido que hable de ciertos problemas que se están detectando cada vez con más frecuencia debido a un uso “poco consciente” de esta tecnología.

Productividad aparente vs calidad real

La IA ha multiplicado nuestra capacidad para generar código y entregar funcionalidades a una velocidad que hace unos años parecía imposible. Eso, en la mayoría de los casos, es algo muy positivo.

El problema aparece cuando empezamos a medir la productividad en cantidad de: tickets cerrados, commits, automatizaciones… incluso el número de instrucciones hechas a la IA sin tener en cuenta la calidad de los mismos.

La velocidad ha aumentado, pero eso no siempre significa que la calidad lo haya hecho también o incluso que se haya mantenido al mismo nivel.

Hay veces que tendemos a tener prisas, incluso sin que nadie nos la exija. Si el Real Betis pudo esperar 6 meses la vuelta de Isco Alarcon de su lesión, seguramente un desarrollo pueda entregarse 2 días más tarde.

Igual que un futbolista puede recaer de su lesión si vuelve antes del tiempo necesario de recuperación, seguramente haya que retrabajar en el código entregado si no se le ha dado el cariño suficiente en todas sus fases.

De hecho, en muchos proyectos empieza a ocurrir algo peligroso. Se detectan más incidencias en fases tardías, aumentan las regresiones y el mantenimiento se vuelve más complejo, aún cuando aparentemente “se está avanzando más rápido”.

El problema y sus posibles causas

Aunque el post está escrito desde mi opinión, lógicamente basada en mis experiencias, tengo que reconocer que mi motivación para escribirlo viene tras mantener conversaciones con varios compañeros del mundillo.

Después de hablar con ellos, todos habíamos detectado una problemática común, que en mayor o menor medida estaba afectando en nuestros proyectos:

El número de bugs ha aumentado de forma considerable desde que la IA llegó a nuestras vidas.

No quiero que nadie me malinterprete, esto no es ni mucho menos una crítica a la IA. Simplemente, ahora somos capaces de producir más código en menos tiempo y no solo lo bueno se maximiza. Por ello y tal y como comentaba en la introducción, quiero dejar claro lo siguiente:

El problema no es la IA, el problema es cómo la estamos usando en algunos casos.

Definición de requisitos

Los requisitos son la base de todo desarrollo. Eran importantes antes y lo son aún más ahora. Tener unos buenos requisitos es una necesidad que existe desde siempre, pero que no se cumple en tantos proyectos como nos gustaría. Esto no es un problema nuevo y lógicamente nadie con o sin IA, puede hacer magia y entregar código sin tener claro qué se quiere.

La IA tiene un “problema” importante: amplifica muchísimo la calidad de la información que recibe. Cuando los requisitos son claros y bien definidos, la IA puede convertirse en una ayuda increíble:

• Acelera desarrollos
• Genera estructuras útiles y mantenibles,
• Propone soluciones válidas,
• Reduce muchísimo tareas repetitivas.

Pero cuando los requisitos son ambiguos, incompletos o incluso cambian constantemente, el efecto puede ser contrario.

Ese efecto contrario se está haciendo notar. Generalmente no hemos mejorado el nivel de los requisitos, pero estamos entregando una mayor cantidad de código generado a través de la IA. El resultado de esto no es otro que un aumento de número de bugs considerable en los últimos tiempos.

Desprofesionalización de la calidad de software

Cada vez se está dejando más la automatización de ciertas pruebas en manos de roles no específicos de calidad. Esto suele hacerse bajo la premisa de “cualquiera puede automatizar pruebas”.

Yo, sinceramente, creo que ahí existe una confusión importante entre saber utilizar una herramienta tipo Cypress o Playwright y entender realmente cómo asegurar calidad de software.

La automatización no consiste únicamente en generar y lanzar tests automáticos. La parte realmente compleja está en decidir cosas como:

• Qué merece ser probado
• Qué riesgos existen
• Qué impacto tiene cada cambio
• Qué escenarios son críticos

Ahí es donde el conocimiento de una persona especializada en calidad sigue siendo fundamental.

La IA puede ayudar muchísimo a generar tests o incluso suites completas de una forma muchísimo más rápida que una persona humana. Eso no garantiza que las pruebas sean buenas, útiles o estratégicas. Al igual que ocurre con el código entregado de la propia aplicación, los tests se deben analizar y entender.

De hecho, hay un riesgo que ya se empieza a ver. Hay una falsa sensación de cobertura y seguridad donde vemos muchos tests, mucha automatización y pipelines verdes pero a la hora de la verdad hay poca validación real de comportamiento crítico.

Al final esto se traduce en el problema que ya os debe ir sonando: los bugs se han incrementado debido a que muchas pruebas automáticas no cumplen su función a la hora de regresionar nuevos desarrollos.

Desarrollo consciente

Antes dije que los requisitos son la base de todo desarrollo, pero tengo que reconocer que no es de todo cierto. Para mí, la base de todo es y será las personas. Creo que uno de los mayores riesgos que estamos empezando a ver es cómo cambia la relación que algunas personas tienen con el código que producen.

Un desarrollador o desarrolladora consciente (por suerte la mayoría lo son) no es simplemente alguien que consigue que “la funcionalidad funcione”, es alguien que se ha involucrado en entender el requisito, cuestionarlo cuando es necesario, analizar impactos, pensar en escenarios alternativos y preocuparse por la calidad final del software que entrega.

La IA acelera muchísimo la generación de código, pero es la propia persona de desarrollo la responsable del código generado, por lo que es igual de importante que lo analice, entienda y pruebe antes de entregarlo.

Por desgracia, cada vez se están detectando más casos en los que el código generado por la IA se entrega sin ser analizado, entendido y probado, incluso casos en los que el código se genera por IA y la PR lo da por bueno.

A largo plazo, esto puede generar diferentes problemas como:

• Código poco mantenible.
• Personas de desarrollo estancadas técnicamente.
• Personas de desarrollo que no conocen perfectamente sus apps, ni funcional ni técnicamente.

Mi experiencia me dice que la persona de desarrollo que estaba involucrada antes de la IA lo está también ahora y quien no lo estaba antes, con IA se le ven más las carencias ya que ahora está entregando bastante más código.

Y es que la IA puede ayudarnos muchísimo a ser más productivos/as, pero no debería sustituir algo fundamental: la responsabilidad técnica sobre lo que estamos entregando.

¿Qué podemos hacer?

La IA ha llegado para quedarse y quién sabe hasta dónde va a llegar. Sería absurdo renunciar a todo el valor que nos aporta. El objetivo no debe ser usarla menos, sino usarla mejor. Generar código nunca había sido tan fácil y debemos “disfrutar” de ello.

Tengamos el rol que tengamos, considero que muchas de las soluciones son comunes para todo el mundo y que de una manera u otra todos tienen en común la pasión con la que cada uno hace su trabajo.

Debemos seguir insistiendo en tener unos buenos requisitos y si no nos los proporcionan, tenemos que ayudar a definirlos, ya que nadie conoce la app como quien la ha creado.

Debemos insistir en la importancia de que cada tarea la realice una persona especializada, dejando claras las consecuencias reales de qué pasa cuando esto no ocurre.

Por último, pero quizás la más importante, debemos tener una involucración real y pasional en cada una de las fases del ciclo de vida del producto, sin olvidar que la IA debe ser una herramienta de apoyo y no un sustituto de nuestra implicación.

“El verdadero problema no es si las máquinas piensan, sino si los hombres lo hacen.” B. F. Skinner.

La forma en que se redacta y organiza un texto puede facilitar o dificultar el acceso a la información. Un contenido accesible ayuda a todas las personas, pero especialmente para aquellas que utilizan lectores de pantalla, tienen dificultades de lectura, problemas de atención, baja visión o cualquier otra limitación total o parcial que pueda modificar su forma de interactuar con la web.

Además, muchas prácticas de accesibilidad también mejoran la experiencia general de lectura: hacen que los textos sean más claros y fáciles de leer para cualquier usuario.

Por eso, en el artículo de hoy te voy a mostrar 5 buenas prácticas que puedes seguir para mejorar la redacción de tu contenido y hacerlo mucho más accesible. No se trata solo de escribir bien, sino de escribir para todos.

1 Organiza el contenido con encabezados claros

Los encabezados son fundamentales para estructurar un artículo. No solo ayudan visualmente a dividir el contenido, sino que también permiten que los usuarios comprendan rápidamente de qué trata cada sección.

Las personas que utilizan lectores de pantalla suelen navegar por una página saltando entre encabezados, por lo que estos deben describir correctamente el contenido que viene después.

Por ejemplo, un encabezado como “Información importante” resulta demasiado genérico. Sin embargo, un título como “Cómo escribir texto alternativo para imágenes” permite entender inmediatamente el tema de la sección.

También es importante mantener una estructura lógica y consistente, ya que un artículo bien organizado facilita la lectura y reduce el esfuerzo necesario para encontrar información.

Además, los encabezados deben ser jerárquicos. Esto significa que el contenido debe seguir un orden estructural claro: debe existir un único H1 que represente el tema principal de la página y, a partir de ahí, se organizan los H2 para las secciones principales, los H3 para subsecciones y así sucesivamente.

El uso correcto de encabezados está relacionado con el criterio 1.3.1 “Información y relaciones” (Ingles), que indica que la estructura y organización del contenido deben poder identificarse correctamente, por ejemplo, mediante títulos y encabezados jerárquicos.

2 Añade texto alternativo útil en las imágenes

El texto alternativo, también conocido como alt text, permite describir imágenes para personas que no pueden verlas y utilizan lectores de pantalla.

¿Cómo escribir un buen texto alternativo?

La mejor forma de saber si tu texto alternativo es bueno es hacerte esta pregunta: "Si estuviera leyendo este artículo a alguien por teléfono, ¿cómo le describiría esta imagen?"

• Mal: "Imagen de un perro."
• Bien: "Un Golden Retriever corriendo por el césped con una pelota en la boca."

Las imágenes suelen usarse para ilustrar o apoyar el mensaje del texto principal. Por ello, el texto alternativo no debe describir exactamente lo que se muestra en la imagen, sino el mensaje que se quiere transmitir con el uso de dicha imagen.

No inicies la descripción con "Imagen de..." o "Fotografía de...". El lector de pantalla ya le avisa al usuario que se trata de un elemento gráfico, así que ve directo/a al grano.

¿Cuándo añadir un texto alternativo?

No todas las imágenes requieren de una descripción, saber cuándo no usarlo es igual de importante:

• Imágenes informativas: todos los gráficos, fotos de personas hablando o iconos de contacto (ej: un sobre para el email), entre otros, requieren texto alternativo.
• Decorativas: líneas divisorias, fondos abstractos o imágenes que solo están para decorar y no añaden información no requieren texto alternativo y se dejan vacías (alt=""), lo que indica al lector de pantalla que debe ignorarlas.

Importante: si la imagen ya tiene un pie de foto que dice exactamente lo mismo, el texto alternativo puede ser más breve o incluso marcarse como decorativo para no repetir información al usuario.

El uso correcto del texto alternativo en imágenes está relacionado con el criterio 1.1.1 “Contenido no textual” (Inglés), que establece que todo contenido no textual (como imágenes) debe tener una alternativa textual que cumpla la misma función o transmita la misma información.

3 Usa enlaces descriptivos

Muchas personas que utilizan tecnologías asistivas navegan mediante listas de enlaces extraídas automáticamente de la página. Por ello, los enlaces deben tener sentido por sí mismos, incluso cuando se leen de forma aislada y fuera de su contexto original.

Un buen enlace debe funcionar por sí solo. El usuario debe saber exactamente qué encontrará al pulsar sin necesidad de leer el texto que lo rodea.

• Mal: "Para conocer nuestras ofertas, haz clic aquí." o "Para leer la noticia completa, pincha en este enlace."
• Bien: "Consulta nuestras ofertas de temporada." o "Leer la noticia sobre accesibilidad en su totalidad."

Evita frases genéricas como "Leer más", "Ver contenido" o "Saber más", si tienes varios enlaces que dicen lo mismo en una página, el usuario de un lector de pantalla escuchará una lista repetitiva y confusa de opciones idénticas.

Para que un enlace sea realmente útil, no basta con que el destino sea claro, también debe informar sobre qué tipo de interacción va a ocurrir a continuación. Para ello podemos seguir estas 3 recomendaciones:

• Anticipa la acción: si el enlace inicia una descarga o abre un formato específico, inclúyelo en la descripción. Por ejemplo: "Descargar presupuesto en formato PDF" o "Ver vídeo del evento en YouTube".
• Evita URLs crudas: no pegues la dirección web directamente (ej: https://www.ejemplo.com/descargas/archivo-final-01.pdf). Los lectores de pantalla leerán cada letra y símbolo, lo cual resulta molesto. Es mejor usar: "Descargar guía de estilo en formato PDF".
• Nueva ventana: si el enlace va a abrir una pestaña nueva, es una buena práctica indicarlo brevemente al final del texto: "Abrir portal de transparencia (se abre en ventana nueva)".

Si usas un icono para esto, asegúrate de que también sea accesible para lectores de pantalla.
Además de mejorar la accesibilidad, los enlaces descriptivos también mejoran la experiencia general de navegación.

El uso de enlaces descriptivos está relacionado con el criterio 2.4.4 “Propósito de los enlaces (en contexto)” (Inglés), que establece que el propósito de cada enlace debe poder determinarse a partir del propio texto del enlace. Esto garantiza que los usuarios sepan a dónde se dirigirán y puedan decidir si quieren pulsar o no.

4 Ten cuidado con el uso de emojis y símbolos

Los emojis pueden ayudar a dar personalidad y cercanía al contenido, pero su uso excesivo puede empeorar la experiencia de navegación y la comprensión para aquellas personas que usan lectores de pantalla.

Los lectores de pantalla traducen cada emoji en palabras, así que lo que visualmente parece un adorno, para un usuario de tecnología asistiva se convierte en una interrupción sonora que corta la frase.

• Texto: "¡Hola a todo el mundo! 👋✨ Hoy estamos muy felices 🤩 de anunciar..."
• Lectura de lector de pantalla: "¡Hola a todo el mundo! Mano saludando destellos Hoy estamos muy felices cara con ojos de estrella de anunciar..."

Si se utilizan demasiados emojis seguidos, el mensaje principal queda oculto por una lista de nombres de imágenes, lo que va a dificultar la comprensión del texto.

Lo más recomendable es no depender de símbolos o emojis para comunicar información importante y, si se usan, hacerlo en la medida adecuada.

5 Evita contenido que pueda causar ataques fotosensibles

Ciertos tipos de contenido visual, como destellos o parpadeos rápidos, pueden afectar a personas con epilepsia fotosensible y otros trastornos convulsivos fotosensibles.

La regla de los tres destellos

Para que un contenido se considere seguro, no debe contener nada que parpadee más de tres veces en un segundo. Si un elemento visual parpadea con una frecuencia mayor, podría llegar a desencadenar una crisis epiléptica.

• Mal: un banner publicitario con colores neón que parpadean rápidamente para llamar la atención.
• Bien: una animación suave y lenta que no presenta cambios bruscos de luminosidad ni contrastes extremos.

Cómo crear contenido visual seguro

Para garantizar que tu sitio sea seguro para todo el mundo, sigue estas pautas:

• Evita el "autoplay" en vídeos con destellos. Nunca reproduzcas automáticamente vídeos que contengan luces estroboscópicas o flashes.
• Permite pausar las animaciones. Cualquier elemento que se mueva o parpadee durante más de cinco segundos debe poder pausarse o detenerse por el usuario.
• Cuidado con los patrones geométricos. Algunos patrones de rayas muy contrastadas y en movimiento también pueden generar malestar. Es mejor optar por transiciones fluidas.

El cumplimiento de estas pautas está relacionado con el criterio 2.3.1 "Umbral de tres destellos o menos” (Inglés), que establece que las páginas web no deben diseñar contenido de una manera que se sepa que puede causar ataques. Esto garantiza que el acceso a la información no suponga un riesgo para la integridad física del usuario.

En este apartado también se menciona el criterio 2.2.2 "Poner en pausa, detener, ocultar” (Inglés). Este criterio exige que, para cualquier contenido que se mueva, parpadee o se actualice automáticamente (como un carrusel o un GIF), el usuario siempre tenga el control para pausarlo o quitarlo. Así evitamos que el movimiento constante se convierta en una distracción o un riesgo para personas con trastornos de atención o sensibilidad sensorial.

Conclusión

Si te soy sincera, por mucho que leas este artículo, es probable que algún detalle se te escape de vez en cuando, especialmente si escribes a diario. Pero lo importante es la intención: tener estas pautas en mente es el primer paso para que tu contenido llegue a todo el mundo.

La accesibilidad no es un objetivo que se puede alcanzar de un día para otro, es un proceso continuo y una responsabilidad compartida. No se trata de hacerlo todo perfecto desde el principio, sino de elegir el camino para mejorar cada día y que así algún día sí lo sea.

Cuando empezamos esta aventura, hace ya casi seis años, no teníamos muy claro qué iba a salir de aquello. La idea inicial ni siquiera era un podcast: eran vídeos cortos grabados en mitad de la montaña hablando de Google Cloud. Por suerte, aquella idea evolucionó y acabó convirtiéndose en algo mucho mejor.

Lo que nació como una forma de compartir conocimiento sobre Google Cloud terminó convirtiéndose en un punto de encuentro para profesionales, clientes, amigos/as y personas apasionadas de la tecnología en general.

Durante todo este tiempo hemos hablado de arquitectura cloud, Kubernetes, networking, seguridad, datos, inteligencia artificial, certificaciones, buenas prácticas y también de muchos de los cambios que han transformado nuestro sector.

Hemos tenido la suerte de contar con invitados e invitadas increíbles, tanto de Google como de clientes, partners y compañeros/as que han querido compartir su experiencia en el canal.

Y lo mejor de todo es que casi nadie nos dijo que no cuando les propusimos participar. ¡Gracias por ayudarnos a construir algo que terminó siendo mucho más grande de lo que imaginábamos!

También hemos vivido momentos que nunca aparecieron en los guiones. Episodios grabados a última hora para llegar a tiempo a la publicación del martes. Problemas técnicos que parecían imposibles de resolver. Conexiones que fallaban en el peor momento.

Ataques de risa provocados por chistes enviados por el chat mientras alguien intentaba mantener la compostura delante del micrófono. Debates imposibles entre Cloud Run, Kubernetes, máquinas virtuales o Functions. Promos grabadas con cartas Magic, disfraces improvisados y alguna que otra idea que probablemente nunca debería haber salido de una reunión.

Y, por supuesto, también hemos tenido la oportunidad de vivir experiencias únicas como asistir a Google Cloud Next y contar de primera mano las novedades que se anunciaban allí.

Durante unos días nos convertimos en corresponsales tecnológicos, tomando notas en keynotes, persiguiendo anuncios y grabando episodios desde el otro lado del Atlántico para compartir con vosotros/as lo más relevante del evento.

Si algo hemos intentado hacer siempre ha sido hablar de tecnología con honestidad. Nos apasiona Google Cloud y llevamos muchos años trabajando con esta plataforma, pero también hemos procurado señalar aquello que podía mejorar. Queríamos que el podcast fuera útil, cercano y auténtico, y esperamos haberlo conseguido al menos una parte del tiempo.

Mirando atrás, resulta difícil creer que un podcast tan especializado haya llegado tan lejos. Más de cien episodios, seis temporadas, cientos de personas invitadas y colaboradores, y más de 240.000 escuchas solo en iVoox. Pero, sobre todo, una comunidad de personas que nos ha acompañado durante todos estos años.

Queremos dar las gracias a los/as oyentes que han estado al otro lado. A quienes nos habéis escuchado mientras ibais al trabajo, entrenabais, viajabais o simplemente buscabais aprender algo nuevo sobre cloud. A quienes nos habéis saludado en eventos, escrito mensajes o recomendado episodios. Cada una de esas conversaciones nos recordó que no estábamos hablando al vacío.

También gracias a todas las personas que han hecho posible este proyecto: al equipo de Goodly, al equipo de marketing de Paradigma, a quienes editaron, revisaron y publicaron cada episodio, y a los compañeros y compañeras que participaron delante y detrás de los micrófonos.

Creemos que las buenas historias merecen un buen final. Por eso hemos querido cerrar esta etapa de forma consciente, con un episodio especial en el que repasamos cómo empezó todo, recordamos algunos de nuestros mejores momentos y hablamos sobre lo que creemos que le espera al futuro del cloud y la inteligencia artificial.

Gracias por acompañarnos durante este viaje.

¿Por qué la IA te devuelve ruido en vez de soluciones?

Estamos transicionando desde la programación determinista hacia entornos probabilísticos de los grandes modelos de lenguaje y esto cambia por completo la manera de enfrentarnos a diversas tareas.

Interactuar con esta tecnología pensando que hay un ser humano al otro lado interpretando nuestra intención es el camino más rápido hacia el fracaso. Cuando lanzamos instrucciones vagas, el sistema nos devuelve ruido y respuestas vacías que no aportan valor de negocio real. Esta falta de precisión es lo que a menudo etiquetamos injustamente como una "caja negra" incomprensible.

Para evitar este infierno operativo, debemos empezar a tratar nuestras peticiones textuales como piezas de código software. Algo así como un pseudo-código. Con este post, trataremos de explicaros cómo reducir las desviaciones y alucinaciones a las que tenemos que hacer frente con cualquier modelo de lenguaje.

¿Por qué necesitamos trocear y delimitar el contexto?

Los textos planos y carentes de estructura provocan que el modelo pierda el foco y acabe mezclando las directrices con los datos crudos. Este conglomerado de instrucciones arruina la fiabilidad del resultado final. Sobre todo, si utilizamos un modelo mediano y/o pequeño. La técnica más efectiva para bajar a tierra este problema es la segmentación modular.

Empresas punteras recomiendan encarecidamente separar el contexto, las reglas y los datos de entrada utilizando delimitadores explícitos. Usar etiquetas XML o simples marcas de Markdown ayuda al algoritmo a procesar cada bloque con la máxima claridad posible. Al crear un contrato claro de entradas y salidas, limitamos el rango de error.

¿Cómo dominamos el estilo y aseguramos la integración?

Más allá de estructurar la información, necesitamos gobernar la forma en la que el sistema se comunica. Basándonos en patrones de diseño eficientes, la adopción de un rol o persona específica obliga a la inteligencia artificial a cargar un subconjunto particular de su entrenamiento. Asignar una identidad experta transforma una respuesta genérica en un análisis profundo y ajustado a nuestro dominio.

No basta con pedir que actúe como un perfil de programación, debemos definir su nivel de formalidad, la perspectiva y el nivel de detalle esperado. Si le exigimos un tono conversacional sin jerga corporativa, el texto será mucho más digerible.

Por otro lado, si buscamos conectar la respuesta con una aplicación externa, obligar a seguir un formato de salida estructurado es un aspecto innegociable. Exigir estructuras rígidas como JSON asegura la interoperabilidad con otras piezas de nuestro software. Los modelos responden mucho mejor a directrices positivas e imperativas sobre lo que deben hacer exactamente en lugar de listas interminables de prohibiciones.

¿Para qué sirven realmente los ejemplos previos?

Esperar que el algoritmo resuelva problemas complejos a la primera y sin referencias suele ser demasiado optimista en entornos corporativos. Proporcionar un conjunto pequeño de ejemplos de entrada y salida es la manera más rápida de calibrar el comportamiento del sistema sin tocar una sola línea de código. Al mostrar explícitamente lo que consideramos correcto e incorrecto, delimitamos el alcance de la tarea.

Esta estrategia estandariza el formato devuelto y reduce las respuestas impredecibles. Veremos que esta inyección de contexto guiado actúa como una red de seguridad muy efectiva para tareas de clasificación o extracción de datos.

Desgranando el esqueleto de un buen prompt

A continuación detallo cómo sería mi prompt básico ideal:

### ROLE ### (rol): no dejes que la IA adivine cómo debe hablar. Asígnale un rol (ej. "Eres un experto desarrollador de Python" o "Eres un redactor creativo publicitario"). Esto ajusta automáticamente el tono y el vocabulario que utilizará.

### CONTEXT ### (contexto): la IA no puede leerte la mente. Explícale el "por qué" y el "para quién" (ej. "Estoy preparando una presentación para inversores sobre una nueva app"). Aquí le damos el contexto necesario para no dar respuestas genéricas.

### TASK ### (tarea): en este apartado irá tu petición de manera directa. Debe ser un verbo de acción (escribir, resumir, analizar, traducir). No es necesario pedir las cosas por favor. Esto solo hará que el coste de tus llamadas se incrementen.

### RULES & CONSTRAINTS ### (reglas y restricciones): ahora puedes delimitar la creatividad de la IA y reducir el riesgo de alucinaciones. Dile exactamente qué reglas seguir para el cumplimiento de la tarea (ej. "No uses jerga técnica", "El texto no debe superar las 200 palabras").

### CHAIN OF THOUGHT & SELF-CHECK ### (cadena de pensamiento y autocontrol): es una buena práctica obligar a la IA a pensar "paso a paso" y a revisar su propia respuesta antes de entregarla. Esto reduce los errores lógicos, especialmente en tareas que requieren un razonamiento más avanzado.

### FEW-SHOT EXAMPLES ### (ejemplos): la mejor forma de enseñar es con ejemplos de entrada y salida reales. Esto ayuda al modelo a calibrar el resultado final.

### INPUT ### (entrada): los datos crudos, el texto a analizar o la pregunta específica.

### OUTPUT FORMAT ### (formato de salida): ¿Quieres una tabla?, ¿un JSON?, ¿markdown?

Conclusiones

Dominar las técnicas básicas de prompting es el paso previo antes de escalar cualquier producto con inteligencia artificial generativa. Con estas buenas prácticas como base, podremos adentrarnos en arquitecturas más complejas, como agentes y optimizaciones recursivas.

Referencias

• Promptware Engineering: Software Engineering for Prompt-Enabled Systems
• The Architecture of Cognitive Steering
• Advanced Prompt Engineering
• Top 10 Prompting Techniques That Instantly Improve AI Output in 2025

La anatomía técnica de un registro incorruptible

En su esencia más estricta, operamos con una base de datos distribuida que encapsula información en bloques. La disrupción real no emana de este concepto, sino de tres propiedades arquitectónicas innegociables.

Primero, la inmutabilidad. Cada bloque integra el hash criptográfico del anterior. Este identificador alfanumérico funciona como un sello matemático inalterable que enlaza toda la secuencia hasta llegar al bloque original, conocido en la jerga como el bloque Génesis. Modificar un solo registro intermedio exige recalcular absolutamente toda la cadena posterior. En redes consolidadas por su volumen, este esfuerzo computacional resulta directamente prohibitivo e imposible de ejecutar en la práctica.

Segundo, la descentralización. Prescindimos por completo de servidores maestros o entidades de control. La red se sostiene sobre miles de nodos que aplican reglas idénticas mediante lo que denominamos un "protocolo de consenso". Este mecanismo matemático valida cada transacción, depositando la confianza exclusivamente en el código y eliminando cualquier punto único de fallo.

Y tercero, la transparencia. En los despliegues públicos, la información resulta visible para cualquier participante. Aunque operamos bajo seudónimos basados en direcciones alfanuméricas, la trazabilidad del activo es absoluta.

Del wallet a la mempool

Para entender el potencial, necesitamos bajar al barro y observar cómo fluye la información. El despliegue de una operación no ocurre por arte de magia: sigue una secuencia lógica y auditable.

Todo arranca en el wallet o monedero digital. Esta herramienta actúa como la puerta de enlace criptográfica del usuario hacia la red. Si decido transferir un activo, firmo la petición especificando la dirección de destino y la cantidad. Aquí entra en juego la red de nodos. Al lanzar la transacción, un primer nodo la intercepta, verifica matemáticamente su validez y la propaga en cascada al resto de la infraestructura.

Una vez validada, la petición no se ejecuta inmediatamente. Pasa a una sala de espera temporal llamada mempool (zona de memoria). Las transacciones esperan allí hasta que los nodos encargados de ensamblar bloques las seleccionan y las empaquetan. Dependiendo de las reglas del protocolo de consenso específico de esa red, un nodo concreto sellará el bloque, grabando la operación en la historia inmutable de la base de datos.

El umbral del "Internet del Valor"

Llevamos décadas acomodados en el "internet de los datos". Hasta ahora, la red nos permitía enviar simples copias de archivos digitales. Hoy, sin embargo, hemos cruzado el umbral hacia el "internet del valor".

Esta infraestructura habilita el movimiento de activos reales de igual a igual, fulminando la dependencia de bancos, cámaras de compensación o entidades validadoras tradicionales. Cuando la primera red, Bitcoin, vio la luz a finales de 2008, su única función era transferir valor nativo. No existían contratos inteligentes.

La explosión corporativa llega con ecosistemas operativos posteriores como Ethereum. Aquí, la criptomoneda nativa no opera como una simple inversión. Actúa como el combustible técnico estrictamente necesario para desplegar y ejecutar aplicaciones descentralizadas. Si como programador quiero subir un desarrollo a esta infraestructura, necesito pagar ese coste operativo en la moneda de la red.

Despliegues operativos fuera de la burbuja

El impacto financiero arrasa con los estándares heredados. Liquidamos transferencias transfronterizas en minutos frente a los días que exigen las arcaicas tuberías bancarias. Las finanzas descentralizadas (DeFi) ya soportan operativas complejas de grado institucional. Operamos con bancos algorítmicos que emiten préstamos o aplicaciones que generan rendimientos. Desde mi actual empresa, Merso, estamos inmersos en este despliegue desarrollando protocolos nativos para pagos a plazos utilizando criptomonedas.

Pero el verdadero salto cualitativo para la industria tradicional ocurre en las cadenas de suministro. La capacidad de auditar el origen y recorrido de los productos con una base inmutable soluciona déficits históricos de confianza. Estos despliegues funcionales ya dominan el mercado:

• Trazabilidad alimentaria: Navidul monitoriza la biografía completa de sus embutidos ibéricos, desde que el animal pisa la dehesa hasta el lineal del supermercado. El consumidor audita este registro inalterable, incluyendo procesos de curación y tiempos de fábrica, mediante un escaneo QR.
• Auditoría industrial: el instituto tecnológico AIJU aplica esta lógica para demostrar legalmente que los procesos de fabricación de juguetes cumplen los más exigentes estándares normativos y de seguridad en cuanto a materiales.
• Certificación de lujo: consorcios como Aura Blockchain, impulsados por marcas como Prada, Cartier y Louis Vuitton, emiten pasaportes digitales. Estos certificados blindan la autenticidad frente a las falsificaciones, trazando desde la extracción de la materia prima hasta la manufactura, habilitando además un mercado secundario seguro.
• Garantías mecánicas: el mercado de vehículos de segunda mano sufre una desconfianza crónica. Volcar el historial de mantenimientos y el kilometraje en una red distribuida neutraliza el fraude. El comprador verifica el estado real del coche, quien lo vende revaloriza su activo, y el taller certificador dispara su credibilidad frente a la competencia.

Hoja de ruta para el equipo directivo: cómo bajar esto a tierra

Llevar esta infraestructura a tu compañía exige estrategia técnica. No basta con instalar un software preempaquetado. En función de mi experiencia, la integración que siempre propongo requiere tres pasos clave:

1. Audita la base tecnológica

Estudia los fundamentos. Entender la tecnología es un requisito innegociable antes de plantear hipótesis de negocio. Bucea en recursos abiertos como el libro Mastering Ethereum o suscríbete a newsletters técnicas diarias como la que escribo personalmente. Si no comprendes la arquitectura base, el fracaso de la implantación está garantizado.

2. Rastrea la industria

Busca pioneros que hayan validado modelos similares para tu sector. La fase de prueba y error en sistemas distribuidos consume recursos a una velocidad alarmante. Valida tu idea observando casos de éxito previos para evitar quemar presupuesto en experimentos ciegos.

3. Aterriza la arquitectura

Apóyate en perfiles técnicos que analicen la viabilidad real de la infraestructura. Presenta tu modelo de negocio, diseña la solución óptima y asegúrate de "bajarla a la tierra" validando la viabilidad técnica antes de picar la primera línea de código.

El cambio de paradigma ya ha ocurrido. La única decisión pendiente es si tu organización liderará la adopción de este nuevo "Internet del Valor" o si intentará adaptarse cuando los estándares del mercado ya hayan cambiado para siempre.

La respuesta suele estar en aspectos difíciles de medir. Hablamos de confianza, colaboración, seguridad psicológica, capacidad para gestionar riesgos, comunicación o liderazgo compartido.

Son elementos que influyen directamente en el rendimiento de los equipos, pero que tradicionalmente han permanecido en el terreno de lo intangible.

La irrupción de la inteligencia artificial está cambiando este escenario. Hoy es posible analizar conversaciones, identificar patrones de comportamiento y convertir señales que antes eran invisibles en información útil para la toma de decisiones.

Pero la verdadera cuestión no es tecnológica. La pregunta es: ¿puede la IA ayudarnos a comprender mejor cómo trabajan los equipos y cómo evolucionan?

Ese fue precisamente el punto de partida de una iniciativa impulsada por María Mira, Pepe González y Mauricio Contreras, cuyo objetivo era explorar cómo la IA podía utilizarse para medir comportamientos dentro de los equipos y aplicar ese conocimiento tanto a su evolución como a la gestión de riesgos.

Del valor de los intangibles a la inteligencia de los equipos

La idea surgió a partir de dos líneas de trabajo que avanzaban en paralelo. Por un lado, la investigación sobre los llamados intangibles organizativos y los Key Behavior Indicators (KBIs), indicadores orientados a medir comportamientos observables dentro de los equipos. Por otro lado, la exploración de conceptos como la antifragilidad y el uso de inteligencia artificial para detectar patrones que normalmente pasan desapercibidos.

La hipótesis era sencilla: si la IA ya era capaz de encontrar patrones complejos en grandes volúmenes de información, quizá también podría ayudar a identificar dinámicas de colaboración, señales tempranas de riesgo o comportamientos que favorecen el alto rendimiento.

Para validar esta idea se desarrolló un primer prototipo basado en el análisis de transcripciones de reuniones de equipo. El objetivo no era evaluar personas individualmente, sino comprender mejor cómo interactúan los equipos y qué comportamientos aparecen en su día a día.

Los resultados sorprendieron incluso a sus propios impulsores. Lo que inicialmente se planteó como un experimento permitió detectar patrones que hasta entonces dependían exclusivamente de la observación humana.

Cuando la IA ayuda a medir lo que no se ve

Uno de los principales desafíos de la gestión de equipos es que muchos de los factores que explican su rendimiento no aparecen en los indicadores tradicionales.

Es relativamente sencillo medir velocidad de entrega, defectos o cumplimiento de plazos. Mucho más difícil es medir si existe confianza suficiente para expresar dudas, si se comparten los riesgos con transparencia o si determinadas personas monopolizan las conversaciones.

A través del análisis de las transcripciones, el equipo comenzó a identificar señales relacionadas con estos comportamientos. El sistema era capaz de detectar patrones de interacción, cuantificarlos y representarlos posteriormente en cuadros de mando que facilitaban su interpretación.

La clave estaba en transformar conversaciones cotidianas en información accionable. No se trataba de vigilar a las personas, sino de entender mejor la dinámica colectiva de los equipos.

Como explica María Mira, el foco no estaba en individuos concretos, sino en el equipo como unidad de análisis. Todo el proceso se planteó desde una perspectiva anonimizada y orientada a comprender qué comportamientos contribuyen realmente a generar mejores resultados.

Del análisis de equipos a la gestión inteligente de riesgos

La iniciativa dio un paso más cuando se conectó con la evolución del framework Polaris, el modelo interno de Paradigma para describir cómo deben funcionar los equipos en los proyectos.

En su nueva versión, Polaris incorporó un enfoque basado en comportamientos observables distribuidos en diferentes dominios, desde la gestión de proyectos hasta la excelencia técnica o el desarrollo de equipos.

Fue entonces cuando surgió una segunda aplicación especialmente interesante: la gestión de riesgos.

Si era posible detectar comportamientos relacionados con la colaboración o la confianza, también podía analizarse cómo los equipos identifican, comunican y gestionan los riesgos de un proyecto.

Para ello se combinaron dos fuentes de información. Por un lado, las conversaciones de los equipos y, por otro, los registros de gestión donde se documentaban riesgos, impedimentos y planes de mitigación.

El resultado fue un modelo capaz de ofrecer una visión más rica de la salud del proyecto y de detectar señales que habitualmente pueden pasar desapercibidas.

Según las personas que participaron en el piloto, uno de los aspectos más valiosos fue precisamente la capacidad de la herramienta para poner de relieve riesgos que no siempre se capturan durante las reuniones o que pueden quedar ocultos en el día a día operativo.

Lo que aprendió el piloto

Tras analizar diferentes equipos y validar los resultados con responsables de proyecto y líderes de equipo, apareció una conclusión especialmente reveladora: la herramienta aportaba más valor del esperado y los usuarios querían ir más allá.

Los/as participantes destacaron la utilidad de disponer de información adicional para comprender mejor las dinámicas de los equipos y anticipar posibles problemas. Sin embargo, también surgieron aprendizajes importantes.

El primero es que las métricas, por sí solas, nunca son suficientes. Los datos necesitan contexto. Una determinada señal puede interpretarse de formas completamente distintas dependiendo de la situación del equipo.

Un incremento en las dudas expresadas durante una reunión podría parecer un síntoma de incertidumbre. Sin embargo, también podría indicar exactamente lo contrario: un entorno donde las personas se sienten seguras para plantear preguntas y compartir preocupaciones.

Por eso, una de las conclusiones más repetidas durante el piloto fue que la IA debe complementar al criterio humano, nunca sustituirlo.

El reto ético: medir sin deshumanizar

Cualquier iniciativa que implique analizar conversaciones genera inevitablemente preguntas relacionadas con la privacidad, la ética y el uso responsable de la información.

Este fue uno de los aspectos que el equipo abordó desde el inicio. De hecho, una de las primeras preocupaciones fue encontrar una forma de obtener información valiosa sin generar sensación de vigilancia ni alterar el comportamiento natural de los equipos.

Durante el piloto aparecieron cuestiones muy relevantes: cómo evitar que los datos se utilicen fuera de contexto, cómo garantizar una gobernanza adecuada de la información o cómo impedir que las métricas deshumanicen la realidad de los equipos.

Una persona puede intervenir poco en una reunión y, sin embargo, estar realizando un esfuerzo enorme para participar. Un equipo puede mostrar muchas dudas y, precisamente por eso, estar funcionando mejor que otros donde nadie se atreve a cuestionar nada.

La tecnología aporta visibilidad, pero la interpretación sigue siendo una responsabilidad humana.

Hacia una nueva generación de herramientas para equipos

Actualmente, el sistema trabaja sobre transcripciones y genera informes posteriores. Sin embargo, la visión de futuro va mucho más allá.

Los/as participantes imaginan escenarios donde sea posible disponer de paneles en tiempo real capaces de mostrar indicadores relacionados con colaboración, dominancia en las conversaciones, apertura a las dudas o gestión de riesgos mientras las reuniones están teniendo lugar.

Incluso se plantea la posibilidad de contar con asistentes inteligentes capaces de acompañar a líderes y equipos, proporcionando recomendaciones contextuales basadas en el análisis continuo de comportamientos y dinámicas de trabajo.

Pero, pese a todas las posibilidades tecnológicas, la reflexión final del episodio es clara: la complejidad sigue estando en las personas. La IA puede ayudarnos a detectar patrones, generar alertas o aportar nuevas perspectivas, pero los factores que determinan el éxito de un equipo siguen siendo profundamente humanos.

En este artículo presentamos un benchmark automatizado con Terraform/OpenTofu para comparar el rendimiento real de estas tres aproximaciones, midiendo operaciones secuenciales de lectura y escritura sobre diferentes tamaños de archivo.

Analizaremos las IOPS, latencia y throughput de cada método, concluyendo que no existe una solución universalmente superior, sino que la elección óptima depende de las características de la carga de trabajo.

Arquitectura

El entorno de pruebas se ha definido íntegramente como código Terraform y consta de los siguientes elementos:

Cada componente cumple un rol específico:

• S3 Bucket — Almacén de objetos con versionado habilitado, cifrado SSE-KMS y acceso público bloqueado.
• EC2 Instance — Ejecuta el benchmark automáticamente al arrancar mediante user-data.
• IAM Role — Políticas de mínimo privilegio: GetObject, PutObject, DeleteObject, ListBucket y HeadObject sobre el bucket de prueba.
• S3 Files Mount Target — Punto de montaje NFS en la subred VPC que conecta la instancia EC2 con el File System de S3 Files.

Metodología

El benchmark sigue un diseño estructurado para garantizar la comparabilidad de resultados entre ambas aproximaciones:

Parámetros de prueba

Operaciones medidas

Para AWS CLI se miden cinco operaciones secuenciales:

• UPLOAD — Envío de 10 archivos al bucket.
• LIST — Listado recursivo del directorio de prueba.
• DOWNLOAD — Descarga de los 10 archivos a disco local.
• HEAD / STAT — Recuperación de metadatos de cada objeto.
• *DELETE — Eliminación de los 10 objetos del bucket.

Para s3fs-fuse y S3 Files se utilizan benchmarks con fio (v3.32) con I/O directo (libaio, direct=1), midiendo:

• IOPS — Operaciones de I/O por segundo sostenidas durante 30 segundos.
• Throughput (MB/s) — Ancho de banda efectivo.
• Latencia (μs) — Latencia media por operación.

La métrica principal es el tiempo total en milisegundos para completar cada operación (10 archivos) en CLI, complementada con IOPS y throughput en MB/s para los mounts FUSE/S3 Files.

Automatización

Todo el ciclo de vida: crear bucket, lanzar instancia, instalar dependencias, compilar s3fs-fuse desde fuente, montar S3 Files, ejecutar las pruebas y generar el CSV de resultados… se orquesta desde un único script que se ejecuta como user-data en el arranque de la instancia.

La infraestructura se encuentra definida como código con Terraform usando dos módulos reutilizables:

• modules/s3-bucket — Crea el bucket con las configuraciones de seguridad.
• modules/ec2-benchmark — Despliega la instancia, el IAM Role, el Security Group y sube el script de benchmark al bucket para que la instancia lo descargue al arrancar.

Componentes

AWS CLI (S3 nativo)

El enfoque nativo utiliza AWS CLI v2 (aws-cli/2.33.15), que internamente realiza llamadas a la API REST de S3. Cada invocación de aws s3 cp implica:

• Inicio de un nuevo proceso Python/CLI.
• Resolución de credenciales desde el servicio de metadatos del profile de la instancia.
• Establecimiento de conexión HTTPS con el endpoint de S3.
• Autenticación mediante firma SigV4.
• Transferencia del contenido (multipart upload para archivos > 8 MB).
• Cierre y limpieza del proceso.

# UPLOAD -- un archivo individual
aws s3 cp "test_10MB_1.dat" "s3://my-bucket/native/test_10MB_1.dat" --no-progress

# LIST -- listado recursivo
aws s3 ls "s3://my-bucket/native/" --recursive

# HEAD -- metadatos de un objeto
aws s3api head-object --bucket "my-bucket" --key "native/test_10MB_1.dat"

Para las operaciones de UPLOAD y DOWNLOAD se itera sobre los 10 archivos secuencialmente, midiendo el tiempo total del bloque completo.

s3fs-fuse

s3fs-fuse (v1.97, compilado desde github.com/s3fs-fuse/s3fs-fuse) monta el bucket S3 como un sistema de archivos FUSE (Filesystem in Userspace), permitiendo acceder a los objetos mediante operaciones POSIX estándar (cp, ls, stat, rm):

# Compilación desde fuente (Amazon Linux 2023)
dnf install -y fuse fuse3 fuse3-devel fuse-devel libcurl-devel \
libxml2-devel gcc-c++ make openssl-devel autoconf automake libtool git

cd /tmp && git clone https://github.com/s3fs-fuse/s3fs-fuse.git
cd s3fs-fuse && ./autogen.sh && ./configure
make -j$(nproc) && make install && ldconfig

# Montaje con credenciales temporales del IAM Role
eval $(aws configure export-credentials --format env)
s3fs "my-bucket" "/mnt/s3" \
-o access_key_id="$AWS_ACCESS_KEY_ID" \
-o secret_access_key="$AWS_SECRET_ACCESS_KEY" \
-o session_token="$AWS_SESSION_TOKEN" \
-o use_cache=/tmp \
-o use_path_request_style \
-o enable_noobj_cache \
-o sigv2

Nota: s3fs-fuse no está disponible como paquete para Amazon Linux 2023, por lo que es necesario compilarlo desde el código fuente en el arranque de la instancia.

Los parámetros de montaje son clave para el rendimiento:

El mecanismo interno de s3fs-fuse traduce cada llamada POSIX a la API correspondiente de S3. Por ejemplo, un cp a un archivo nuevo se traduce en un PUT Object, mientras que un stat se resuelve como HEAD Object.

AWS S3 Files (mount.s3files)

AWS S3 Files es el servicio nativo de Amazon para montar buckets S3 como filesystem, disponible como mount.s3files en Amazon Linux 2023. A diferencia de s3fs-fuse, S3 Files no conecta la instancia EC2 directamente a S3. El flujo de datos real es el siguiente:

La instancia EC2 monta un filesystem mediante el protocolo NFS desde una instancia EFS que actúa como caché de alto rendimiento. Esta caché se encarga de servir una copia local de ficheros y de sincronizar los cambios con el bucket S3.

# Instalación (Amazon Linux 2023)
dnf install -y amazon-efs-utils

# Montaje -- OpenTofu crea el File System y Mount Target en la VPC.
# El benchmark script monta usando el ID del File System:
mount_file_id=$(cat /root/benchmark-results/s3files_fs_id)
/usr/sbin/mount.s3files "${mount_file_id}" /root/s3files-mount

# Verificación del montaje
mount | grep s3files
# fs-0bbbd1d66142be171 on /root/s3files-mount type s3files ...

Características clave de S3 Files:

S3 Files está diseñado para ofrecer consistencia fuerte y operativa simplificada, pero su rendimiento puede diferir significativamente del de s3fs-fuse según el escenario.

Configuración del entorno

El despliegue completo se ejecuta con tres comandos:

# 1. Inicializar OpenTofu
tofu init

# 2. Revisar el plan
tofu plan -var-file=terraform.tfvars

# 3. Desplegar
tofu apply -var-file=terraform.tfvars
Tras el apply, OpenTofu devuelve la IP pública de la instancia. El benchmark arranca automáticamente en menos de un minuto:
Outputs:

instance_public_ip = "<EC2_PUBLIC_IP"
results_location = "/root/benchmark-results/"
ssh_command = "ssh -i <ssh_key>.pem ec2-user@<EC2_PUBLIC_IP>"

Los resultados se guardan en /root/benchmark-results/ con los siguientes archivos:

• results.csv — Datos crudos (test_name, operation, file_size, bw_mbps, iops, lat_us).
• fio_*.json — Logs detallados de fio por método y tamaño de archivo (latencias percentiles, distribución de I/O).
• benchmark.log — Log completo de la ejecución.
• summary.txt — Resumen con configuración y comandos para descargar los resultados.

Resultados

Los datos completos se recopilan en formato CSV. Los resultados de la CLI se miden como tiempo total para 10 operaciones secuenciales, mientras que los resultados de s3fs-fuse y S3 Files se miden con fio en modo sostenido (30 segundos, I/O directo con libaio).

Lectura secuencial — IOPS

Lectura secuencial — Latencia media (μs)

Escritura secuencial — IOPS

Escritura secuencial — Latencia media (μs)

Throughput de lectura (MB/s)

Throughput de escritura (MB/s)

Operaciones AWS CLI — Tiempos totales (ms, 10 archivos)

Análisis de resultados

1 AWS CLI tiene un overhead fijo de ~7-10 segundos

Independientemente del tamaño del archivo (1 KB o 10 MB), las operaciones con AWS CLI muestran un piso constante de 7 a 10 segundos para procesar 10 archivos (es decir, no puede bajar de ese valor). Esto se debe a que cada invocación de aws s3 cp ejecuta un proceso independiente que:

• Inicializa el runtime de Python.
• Carga la configuración de AWS (~/.aws/config, variables de entorno, servicio de metadatos).
• Establece una conexión TLS nueva con el endpoint de S3.
• Calcula la firma SigV4 (que incluye hashing del payload para uploads).

El tamaño del archivo apenas influye porque el coste de establecimiento domina sobre el coste de transferencia real, especialmente con archivos pequeños en una conexión de red suficiente.

2 s3fs-fuse aprovecha el page cache del kernel

La diferencia de rendimiento más dramática (hasta 750x en DELETE) se explica por la caché en memoria. Con la opción use_cache=/tmp, s3fs-fuse almacena en tmpfs (RAM) los archivos descargados. En Amazon Linux 2023, /tmp es un tmpfs montado en memoria, no en disco. Esto significa que el caché compite directamente con la memoria disponible de la instancia. Cuando la prueba descarga los mismos archivos que previamente subió, el kernel satisface las lecturas desde el page cache sin generar tráfico de red.

Esto no es un "engaño", refleja un patrón de uso real: en producción, los mismos archivos se leen frecuentemente más de una vez y el caché de s3fs-fuse elimina la latencia de red en accesos repetidos.

3 S3 Files: consistencia a cambio de rendimiento

AWS S3 Files ofrece un comportamiento fundamentalmente distinto al de s3fs-fuse. Los benchmarks con fio en modo directo (direct=1, libaio) revelan que S3 Files presenta latencias de lectura 7x a 53x superiores y latencias de escritura 8x a 115x superiores respecto a s3fs-fuse:

En archivos grandes (10 MB), la brecha se reduce pero sigue siendo significativa:

La causa principal es el caching en userspace de s3fs-fuse. Incluso con la opción de fio direct=1 (que ignora la page cache del kernel), s3fs-fuse mantiene su propio caché en /tmp a nivel de proceso FUSE, mientras que S3 Files realiza cada petición a través de NFS hacia S3 sin caché intermedio, priorizando la consistencia fuerte de lectura tras escritura. Esta arquitectura de doble salto (EC2 → → EFS → S3) explica parte de la latencia adicional observada en archivos grandes.

4 UPLOAD con s3fs-fuse muestra resultados variables

Los tiempos de UPLOAD con s3fs-fuse fluctúan (35-55 ms) sin correlación directa con el tamaño del archivo. Esto ocurre porque la operación cp a un mount FUSE es asíncrona por defecto: el kernel devuelve éxito cuando los datos entran en el buffer, y s3fs-fuse realiza el PUT a S3 en segundo plano. El sync posterior fuerza la escritura completa, pero la medición captura solo el retorno inicial del cp.

5 LIST es extremadamente rápido con s3fs-fuse

La operación LIST con s3fs-fuse (2-3 ms) es notablemente más rápida que con AWS CLI (721-738 ms) porque el directorio ya está cacheado tras las operaciones anteriores. AWS CLI, en cambio, ejecuta ListObjectsV2 paginado en cada invocación, recorriendo todos los prefijos del bucket.

6 HEAD/STAT: la ventaja del caché de metadatos

La opción enable_noobj_cache permite a s3fs-fuse cachear también las respuestas negativas de HeadObject. Con 15 ms constantes para cualquier tamaño de archivo, s3fs-fuse resuelve los STAT desde caché local mientras que AWS CLI debe hacer 10 llamadas HTTP independientes (una por archivo).

7 La latencia de S3 Files escala con el tamaño de archivo

Una característica distintiva de S3 Files es que su latencia crece proporcionalmente al tamaño del archivo, tanto en lectura como en escritura. Esto es esperable en un sistema sin caché local donde cada operación de I/O debe completarse a través del Mount Target NFS hacia S3 de forma síncrona: EC2 → Mount Target (VPC) → File System → S3. A diferencia de s3fs-fuse, donde la latencia por operación se mantiene baja gracias al caché en memoria local (tmpfs), S3 Files no tiene esa capa intermedia:

• Lectura 1 KB → 686 μs; lectura 10 MB → 67.888 μs (99x más lento)
• Escritura 1 KB → 4.553 μs; escritura 10 MB → 80.100 μs (18x más lento)

En comparación, s3fs-fuse muestra un crecimiento mucho más suave:

• Lectura 1 KB → 34 μs; lectura 10 MB → 8.761 μs (258x, pero partiendo de una base mucho menor)
• Escritura 1 KB → 42 μs; escritura 10 MB → 9.496 μs (226x)

8 A 100 MB: el throughput de S3 Files se acerca al de s3fs-fuse

Los datos de 100 MB revelan un patrón clave: la ventaja de s3fs-fuse se reduce significativamente en archivos grandes. En lectura, el throughput de S3 Files (210 MB/s) se acerca al de s3fs-fuse (1.496 MB/s), reduciendo la brecha de 54x (1 MB) a 7,1x (100 MB). En escritura, la tendencia es similar: S3 Files logra 216 MB/s frente a los 1.027 MB/s de s3fs-fuse, una diferencia de apenas 4,8x.

Este comportamiento es consistente con la arquitectura de S3 Files descrita por AWS: para archivos grandes (≥ 1 MB), las lecturas se transmiten directamente desde S3, bypassando la capa de caché. Como S3 ofrece alto throughput para transferencias secuenciales grandes, el rendimiento converge hacia el ancho de banda de red disponible.

Sin embargo, el throughput de s3fs-fuse en lectura para archivos grandes (1.496 MB/s para 100 MB) sugiere que su caché local sigue ofreciendo datos desde el page cache del kernel, ya que los 1,5 GB/s superan lo que una conexión de red típica puede ofrecer. Esto confirma que las pruebas de fio con direct=1 no bypassan completamente el caché de s3fs-fuse a nivel de proceso FUSE, como sí lo hacen con S3 Files.

9 S3 Files frente a s3fs-fuse en escalabilidad

La siguiente tabla resume cómo evoluciona la latencia de escritura con el tamaño de archivo:

La ventaja de s3fs-fuse disminuye convergentemente: de 108x en 1 KB a solo 4,7x en 100 MB. Esto tiene implicaciones prácticas importantes:

• Para workloads de archivos pequeños (metadata, configs, logs), s3fs-fuse es ineludible: 100x más rápido.
• Para workloads de archivos grandes (videos, datasets, backups), la diferencia se reduce a ~5x, y S3 Files ofrece consistencia fuerte a cambio de ese rendimiento menor.
• Para transfers masivos donde el throughput importa más que la latencia por operación, S3 Files a 216 MB/s de escritura puede ser suficiente para muchos pipelines.

Ventajas y desafíos

Ventajas de AWS CLI (Native S3)

• Simplicidad operativa — No requiere instalación ni compilación adicional. Viene preinstalado en todas las AMIs de Amazon Linux.
• Consistencia fuerte — Cada operación consulta directamente a S3, garantizando datos actualizados.
• Control granular — Soporte completo para todas las opciones de S3: multipart tuning, storage class transitions, tagging, lifecycle policies desde la CLI.
• Sin estado local — No depende de caché ni mounts persistentes. Ideal para pipelines efímeros (CI/CD, Lambda con container).
• Auditable — Cada operación deja un registro explícito en CloudTrail con el user-agent del CLI.

Ventajas de s3fs-fuse

• Rendimiento dramáticamente superior para accesos repetidos gracias al caché local de archivos y metadatos.
• Transparencia para aplicaciones legacy — Cualquier aplicación que funcione con el sistema de archivos POSIX funciona sin modificaciones contra S3.
• Interactividad — Exploración manual del bucket con herramientas estándar (ls, cat, less, grep).
• Integración con herramientas existentes — rsync, tar, find, scripts bash que operan sobre rutas de archivo.

Ventajas de AWS S3 Files

• Consistencia fuerte garantizada — Cada lectura refleja la última escritura sin riesgo de datos desactualizados. Ideal para workloads donde la integridad de datos es crítica.
• Gestión de credenciales simplificada — Resuelve automáticamente el IAM Role del instance profile sin necesidad de inyectar credenciales temporales manualmente.
• Protocolo NFS con Mount Target gestionado — S3 Files utiliza NFSv4.1 para comunicarse con un Mount Target en la VPC sin pasar por FUSE. AWS gestiona el endpoint de conectividad a S3, evitando el overhead del context switch kernel/userspace que introduce FUSE.
• Soporte oficial de AWS — Mantenido por Amazon, con integración nativa en Amazon Linux 2023 y soporte técnico.
• Instalación simple — Disponible como paquete del sistema (amazon-efs-utils) sin necesidad de compilar desde fuente.

Desafíos de s3fs-fuse

• Consistencia eventual — El caché local puede servir datos stale si el bucket se modifica desde otra fuente. La invalidación manual es necesaria en escenarios multi-escritura.
• Complejidad de montaje — Requiere compilar desde fuente en Amazon Linux 2023 (dependencias: fuse3-devel, autoconf, automake, libtool). Las credenciales temporales del IAM Role deben inyectarse explícitamente porque s3fs-fuse no siempre resuelve iam_role=auto correctamente.
• Limitaciones POSIX — No soporta renombrado atómico, hard links, ni operaciones que requieran locking de archivos. Las operaciones de directorio pueden ser lentas en buckets con millones de objetos.
• Gestión del ciclo de vida del mount — Las reconexiones tras fallos de red requieren scripts de monitorización o systemd mount units con x-systemd.automount.
• Overhead de memoria — El proceso s3fs consume memoria proporcional al número de objetos cacheados, lo que puede ser significativo en instancias con recursos limitados (como la t3.micro de este benchmark).

Desafíos de AWS S3 Files

• Rendimiento inferior a s3fs-fuse — Sin caché local, cada operación de I/O incurre en latencia de red contra S3. En nuestro benchmark, S3 Files muestra de 7x a 115x menos IOPS que s3fs-fuse, y latencias 7x a 108x superiores.
• Latencia proporcional al tamaño de archivo — Sin caching intermedio, el tiempo de cada operación escala linealmente con el tamaño del objeto, lo que impacta especialmente en archivos grandes (62 ms por lectura de 10 MB vs 8,7 ms en s3fs-fuse).
• Disponibilidad limitada — AWS S3 Files no está disponible en todas las regiones. Si la región no soporta S3 Files, la opción directamente no existe.
• IOPS limitados en archivos pequeños — Con solo ~1.400 IOPS de lectura para archivos de 1 KB, S3 Files queda muy por debajo de los ~30.500 de s3fs-fuse, lo que lo hace inadecuado para workloads intensivos en metadata.

Desafíos de AWS CLI

• Rendimiento por archivo — Cada archivo implica un proceso completo. Para transferencias masivas de archivos pequeños, el overhead domina sobre el tiempo de transferencia real.
• Sin caché nativo — Cada aws s3 cp descarga vuelve a solicitar los datos a S3, incluso si el archivo no ha cambiado.
• Limitaciones para aplicaciones legacy — Las aplicaciones que esperan rutas de archivo POSIX no pueden usar la CLI directamente sin un wrapper o adapter layer.

Casos de uso en producción

Más allá de los números del benchmark, estos son los escenarios donde cada método encaja mejor:

Entrenamiento ML con datasets en S3

Con S3 Files, podemos montar petabytes de datos de entrenamiento directamente como filesystem sin duplicarlos en volúmenes EBS. Los workers de entrenamiento (hasta 25.000 simultáneos) acceden a los datos como archivos locales y los grandes batches de entrenamiento se transmiten directamente desde S3.

Recomendación: S3 Files para la accesibilidad compartida; s3fs-fuse si la latencia por epoch es crítica y es tolerable la consistencia eventual.

Workspaces colaborativos para agentes de IA

Sistemas multi-agente donde cada agente lee y escribe logs, estado y memoria en un directorio compartido de S3. Hasta 25.000 recursos (EC2, Lambda, EKS pods) pueden conectarse al mismo filesystem simultáneamente.

Recomendación: S3 Files — consistencia fuerte para escrituras concurrentes y acceso bidireccional S3 ↔ NFS.

Pipelines ETL batch

Procesos que descargan archivos de S3, los transforman y los suben de vuelta. No necesitan un mount persistente.

Recomendación: AWS CLI — simplicidad, sin estado local, sin montajes que gestionar.

Exploración interactiva de buckets

Data scientists y devops que necesitan navegar un bucket con ls, cat, grep, find sin montar nada permanentemente.

Recomendación: s3fs-fuse — la caché local ofrece respuestas instantáneas para accesos repetidos, y la interactividad POSIX es insuperable.

Procesamiento de archivos grandes (> 100 MB)

Videos, datasets de imágenes, backups donde el throughput importa más que la latencia por operación.

Recomendación: S3 Files o s3fs-fuse — a 100 MB, la diferencia de throughput se reduce a 5-7x. Preferir S3 Files si se necesita consistencia fuerte o acceso simultáneo desde múltiples instancias.

Conclusión

Este benchmark demuestra que la elección entre AWS CLI nativo, s3fs-fuse y AWS S3 Files depende fundamentalmente del patrón de acceso, el tamaño de archivo y los requisitos de consistencia:

1. Para workloads batch de un solo uso (ETL, backups, migraciones puntuales), AWS CLI es la opción más sencilla y predecible, con consistencia fuerte y sin estado local.
2. Para accesos interactivos frecuentes o aplicaciones que esperan un filesystem, s3fs-fuse ofrece mejoras de rendimiento de 7x a 115x en IOPS sobre S3 Files, y latencias 7x a 108x inferiores, gracias al caché local, a cambio de gestionar la consistencia eventual y el lifecycle del mount.
3. Para workloads que requieren consistencia fuerte con escrituras concurrentes y acceso filesystem, S3 Files ofrece garantías de lectura tras escritura sin necesidad de gestionar cachés, pero con un rendimiento significativamente inferior en archivos pequeños: 1.452 IOPS de lectura para archivos de 1 KB frente a los 30.546 de s3fs-fuse, y latencias de escritura de 4,5 ms frente a 42 μs.
4. Para transferencias de archivos grandes (100 MB+), S3 Files converge hacia el throughput de s3fs-fuse: a 100 MB, S3 Files alcanza 210 MB/s de lectura (7,1x menos que s3fs-fuse), lo que puede ser aceptable cuando la consistencia fuerte es prioritaria.

Un punto clave a considerar es que los resultados de s3fs-fuse se benefician significativamente del caché de lectura. En escenarios de primera lectura (cold cache), los tiempos de descarga serán comparables a los de AWS CLI y S3 Files, ya que las tres aproximaciones deben transferir los datos desde S3 a través de la red.

La incorporación de S3 Files al benchmark revela que no existe una solución universalmente superior: s3fs-fuse sacrifica consistencia por rendimiento, S3 Files sacrifica rendimiento en archivos pequeños por consistencia y simplicidad operativa, y AWS CLI ofrece simplicidad operativa sin montaje de filesystem. La elección debe alinearse con los requisitos específicos de cada workload.

La infraestructura completa de este benchmark está disponible como módulo de OpenTofu reutilizable en este repositorio, lista para desplegar en cualquier cuenta AWS con una configuración mínima.

¿Has realizado benchmarks similares en tu infraestructura? ¿Qué estrategia usas para acceder a S3 desde tus aplicaciones? Cuéntanos tu experiencia en los comentarios.

Referencias

• AWS S3 Files Documentation — Guía completa del servicio, arquitectura, sincronización y performance.
• AWS News Blog: S3 Files GA Announcement — Anuncio de disponibilidad general (7 de abril de 2026).
• AWS Terraform provider: Release v6.40.0 - Versión del proveedor de Terraform con soporte para S3Files.
• S3 Files Performance Specifications — Especificaciones de throughput, latencia y límites.
• S3 Files Pricing — Costes de almacenamiento en caché, acceso a datos y sincronización.
• s3fs-fuse GitHub Repository — Documentación y opciones de montaje de s3fs-fuse.
• fio — Flexible I/O Tester — Herramienta de benchmark de I/O utilizada en las pruebas.
• Tutorials Dojo: Amazon S3 Files — Análisis conceptual de la arquitectura de S3 Files.

Y, aunque cada año intentamos que sea una jornada distinta, creo que hay algo que se mantiene: las ganas de hablar de transformación desde casos reales, con personas que están viviendo esos cambios dentro de sus organizaciones.

Este año hubo una pregunta que apareció de distintas formas durante toda la mañana: ahora que la inteligencia artificial parece acelerar tantas cosas, ¿tenemos claro hacia dónde queremos ir?

Porque transformar no va solo de incorporar nuevas herramientas o rediseñar procesos. También va de decidir mejor, priorizar mejor y no confundir movimiento con avance.

Si quieres saber más sobre ediciones anteriores, puedes recuperar aquí algunos aprendizajes de este camino que empezó con Agile Real Life (edición 1, 2 y 3) y que hoy continúa con Revolution Day.

AI Ready

La jornada comenzó con Aday Guerra y una idea que me parece especialmente importante en este momento: ser una empresa AI Ready no va de hacer muchos pilotos, sino de ser capaz de llevar los casos de uso a producción y convertir la inteligencia artificial en una capacidad real de la organización.

Aday nos acercó la experiencia real de Paradigma en la adopción de la inteligencia artificial, compartiendo tanto la visión estratégica como el modelo de implantación que estamos siguiendo.

Nos mostró cómo incorporar la IA de forma transversal en todos los niveles de la organización y explicó el enfoque de escalado que permite extender su impacto de manera sostenible y alineada con los objetivos de negocio.

Para ello, habló de 5 dimensiones que tienen que avanzar conectadas:

• La estrategia ayuda a priorizar.
• El gobierno permite definir normas, identificar procesos y establecer puntos de control.
• Las personas sostienen la toma de decisiones.
• La infraestructura y la plataforma de datos hacen posible escalar.
• La factoría permite convertir casos de uso en soluciones reales en producción.

Más rápido ¿hacia dónde?: estrategia más allá del producto digital

Después, César Astudillo nos hizo reflexionar sobre si la inteligencia artificial puede ayudarnos a ir mucho más rápido. Si no existe una estrategia clara, nos llevará antes al lugar equivocado.

César nos recordó que la IA amplifica lo que ya tenemos: nuestros aciertos, pero también nuestras carencias. Si nuestro roadmap no tiene una dirección real, si no conocemos bien las necesidades del cliente o si construimos capacidades que la organización no necesita, corremos el riesgo de crear productos técnicamente impecables, pero poco relevantes para el negocio.

Una de las ideas de su charla es que la dirección estratégica necesita apoyarse en tres factores: estrategia, cultura y utilidad. No basta con tener una tecnología potente ni con llenar un roadmap de iniciativas. Hace falta diagnóstico, foco, decisiones coherentes y, sobre todo, capacidad para priorizar y renunciar.

Transformar cuando no puedes fallar

Con Alfonso Alcalá entramos en un contexto muy distinto: transformar cuando no puedes fallar. Habló de un programa con una fecha marcada por la Comisión Europea, sin posibilidad de moverla, y con una plataforma crítica que debía seguir funcionando mientras se reconstruía por completo.

En su charla contó cómo, en determinados contextos, la regulación y la presión extrema pueden convertirse en catalizadores de cambio. Cuando no hay margen para el error, las organizaciones se ven obligadas a alinear intereses, simplificar decisiones y ejecutar con foco.

Una idea quedó especialmente clara: a veces, las restricciones más duras son las que provocan las transformaciones más profundas. La charla de Alfonso nos dejó una reflexión muy interesante sobre la gestión de proyectos.

Más allá del clásico triángulo de hierro (tiempo, alcance y coste), nos invitó a mirar otro triángulo menos visible, pero igual de relevante: el de las personas, formado por la motivación, el esfuerzo y la coordinación.

PRODIGI: journey de transformación de proyecto a producto

Con Fátima Casaú y Gabriel Salafranca conocimos el viaje de PRODIGI en Iberdrola: cómo pasar de una forma de trabajo más basada en proyectos, tickets, herramientas y equipos fragmentados a un enfoque más centrado en producto, usuario y flujo end-to-end.

La ponencia aterrizó una conversación cada vez más presente en muchas compañías: pasar de proyecto a producto no consiste en cambiar una palabra. Implica conversaciones, cambiar responsabilidades, procesos, métricas, colaboración entre áreas y forma de entender la entrega.

No se trata de entregar, sino de aprender si lo que entregamos genera valor de forma continua.

De guardianes del estándar a aceleradores del cambio

Víctor Cuervo, de Banco Sabadell, nos planteó una pregunta clave para cualquier transformación tecnológica: ¿la arquitectura está actuando como freno o como acelerador del cambio?

Su charla mostró el viaje del área de arquitectura desde un modelo más centrado en el control hacia uno más orientado a habilitar la entrega.

Este viaje no se presentó como un relato perfecto, sino como un camino con aciertos, errores y aprendizajes. La arquitectura no tiene por qué elegir entre coherencia técnica y agilidad de negocio. Bien enfocada, puede proteger la calidad y, al mismo tiempo, ayudar a que la organización entregue mejor y con más sostenibilidad.

La iniciativa de mejora continua del Plan Estratégico del Banco de España: optimizar procesos con foco en el valor

Sonia Bernardez y Patricia Sanabria compartieron un reto muy interesante al que se enfrentaban: cómo mejorar eficiencia y reducir complejidad en una organización donde el rigor, la calidad y la gestión del riesgo son irrenunciables.

Su enfoque partía de revisar procesos de alto impacto con una mirada orientada a valor, apoyándose en Lean, Agile y en la IA como palancas de mejora. La secuencia que compartieron era clara: elegir un proceso cross departamental del backlog priorizado según los objetivos estratégicos, visualizarlo, generar hipótesis y llevar esas hipótesis a soluciones concretas.

Además pusieron énfasis en que la mejora continua no debe quedarse como una iniciativa aislada, sino convertirse en un hábito dentro de la organización. Para ello, destacaron el uso de herramientas como el kanban de innovación y el observatorio, fundamentales para gestionar la mejora continua y fomentar el aprendizaje a través de indicadores.

Neurociencia aplicada al liderazgo en entornos de alta transformación

La jornada cerró con Marta Romo y una mirada muy necesaria después de una mañana hablando de IA, estrategia, producto, arquitectura y procesos: qué pasa con las personas cuando todo se acelera.

Nos habló de la hiperdesconexión y de algunos de los riesgos que aparecen cuando vivimos en entornos de sobrecarga constante: superficialidad, inmediatez, ansiedad, miedo, angustia, sensibilidad, inflexibilidad e inercia. En un mundo que acelera sin parar, nuestro cerebro necesita tiempo, foco y dirección.

Propuso 3 claves y un compromiso para liderar mejor en entornos de alta transformación.

1. La primera es la recuperación: tener momentos para procesar, parar y recuperarse, incluso con gestos tan sencillos como dejar diez minutos entre reuniones.
2. La segunda es la conexión: generar momentos reales de conexión humana y cultivar la empatía.
3. Y la tercera es la presencia: estar de verdad, evitando la distancia temporal, perceptiva y lingüística que muchas veces nos aleja de los demás. El compromiso que nos propone Marta pasa por reestructurar nuestras agendas, haciendo huecos para tener esos espacios de recuperación y creación.

Algunas ideas que nos llevamos

Si tuviera que resumir la jornada en unas pocas ideas, me quedaría con estas:

• Ser AI Ready no va de acumular pilotos, sino de conectar estrategia, gobierno, personas, datos y capacidad real de llevar soluciones a producción.
• La IA puede acelerar mucho, pero sin dirección también puede amplificar errores.
• La transformación real exige foco, renuncias y capacidad para decidir qué no hacer.
• Las restricciones, bien gestionadas, pueden generar claridad.
• Pasar de proyecto a producto es un cambio cultural, no solo metodológico.
• La arquitectura puede ser una palanca de cambio si actúa como habilitadora.
• La mejora continua empieza por distinguir entre valor real y complejidad innecesaria.
• Y ninguna transformación es sostenible si no tenemos en cuenta cómo lideramos, cómo cuidamos la atención y cómo acompañamos a las personas.

Las experiencias que hemos compartido durante la jornada no son casos ajenos ni ejemplos de terceros. Son iniciativas reales en las que llevamos años trabajando en Paradigma Digital y Rev by Paradigma junto a nuestros clientes, formando parte de los equipos que las han impulsado y acompañado en su evolución.

Y quién mejor para contarlas que sus propios responsables, las personas que las lideran día a día y que han vivido de primera mano los retos, aprendizajes y resultados obtenidos. Para nosotros/as es un orgullo formar parte de estas historias y seguir contribuyendo a que se hagan realidad.

Gracias por hacerlo posible

Revolution Day 2026 nos dejó aprendizajes, preguntas y muchas conversaciones interesantes. Y eso es una de las mejores señales de que un evento ha funcionado.

Gracias a Aday Guerra, César Astudillo, Alfonso Alcalá, Fátima Casaú, Gabriel Salafranca, Víctor Cuervo y Marta Romo, por compartir sus experiencias con tanta generosidad.

Gracias también a todas las personas que se acercaron a nuestras oficinas para escuchar, preguntar y conversar. Y, por supuesto, gracias a todo el equipo de Paradigma y Rev by Paradigma que ha hecho posible una nueva edición de Revolution Day.

Un año más nos vamos con la sensación de haber vivido una jornada muy especial. Porque transformar no va de cambiar más rápido, sino de cambiar a mejor.

Actualmente nos encontramos en la versión WCAG 2.2 (Inglés), publicada como recomendación el 5 de Octubre del 2023 y, hasta el momento, el enfoque de estas pautas ha sido bastante estable.

Hasta ahora el modelo era relativamente sencillo de entender: por un lado existían una serie de criterios técnicos que determinaban qué aspectos debía cumplir una web para ser accesible y, por otro, distintos niveles de conformidad (Inglés) (A, AA y AAA) que indicaban el grado de accesibilidad alcanzado.

Pero eso está cambiando y es por ello que he querido escribir este artículo.

Han pasado ya más de cinco años desde la publicación del primer borrador de las WCAG 3.0 (Inglés) y, aunque todavía sigue siendo precisamente eso, un borrador, la propuesta empieza a tomar forma y nos empieza a dejar ver hacia dónde quiere evolucionar la accesibilidad digital.

*Antes de continuar quiero aclarar que todavía no es un estándar oficial y no debe utilizarse como referencia legal o de conformidad. Por ahora, las organizaciones deben seguir trabajando con WCAG 2.2.

Cómo cambia la evaluación en WCAG 3.0

Creo que la mejor forma de entender a lo que me refiero con “esto está cambiando” es analizar cómo se va a evaluar la accesibilidad en WCAG 3.0. Porque más allá de nuevos criterios o pequeños ajustes técnicos, lo que realmente está cambiando es la forma de entender la accesibilidad.

Conformidad

Desde WCAG 1.0 (Inglés) hasta WCAG 2.2, el sistema para determinar si un sitio web era accesible se ha mantenido prácticamente igual: existían una serie de criterios de éxito y, en función de cuáles se cumplían, se obtenía un nivel de conformidad determinado.

Estos niveles eran:

• A. Este es el nivel mínimo de conformidad y se alcanza cuando la web cumple con todos los criterios de éxito del nivel A.
• AA. Este nivel es el mínimo legal exigido para la mayoría de sitios web que tienen obligación de ser accesibles. Se alcanza cuando se cumplen todos los criterios de los niveles A y AA.
• AAA. Este nivel es el más accesible y se alcanza cuando se cumplen todos los criterios A, AA y AAA.

Sin embargo, WCAG 3.0 propone abandonar este modelo tradicional y sustituirlo por un nuevo sistema de niveles:

• Bronce. Este sería el nivel mínimo de conformidad. Para alcanzarlo, todas las páginas, vistas y procesos incluidos dentro del alcance de evaluación deberán cumplir todos los requisitos principales y además una parte de los requisitos suplementarios y afirmaciones definidas dentro de cada declaración de rendimiento funcional (Inglés).
• Plata. Para alcanzar este nivel será necesario cumplir todos los requisitos principales y además una proporción mayor de requisitos suplementarios y afirmaciones que en el nivel Bronce.
• Oro. Este sería el nivel más alto de conformidad dentro de WCAG 3.0. Requerirá cumplir todos los requisitos principales y prácticamente la totalidad de requisitos suplementarios y afirmaciones aplicables.

Puedes leer más acerca de los requisitos de conformidad de las WCAG 3.0 en el borrador (Inglés).

Más adelante en este artículo explicaré con más detalle qué son los requisitos principales, los requisitos suplementarios y las afirmaciones dentro de WCAG 3.0. Por ahora, lo importante es entender que el modelo actual funciona de una forma binaria: un criterio se cumple o no se cumple.

Sin embargo, esta nueva versión (WCAG 3.0) quiere alejarse de ese enfoque y propone un sistema mucho más flexible y progresivo basado en puntuaciones, resultados y experiencia real de accesibilidad.

Declaraciones de rendimiento funcional

En esta nueva versión, se introduce el concepto de Functional Performance Statements, que amplían la forma en la que se entiende la accesibilidad. Puedes leer más sobre las declaraciones de rendimiento funcional en el borrador (Inglés).

Estas declaraciones no son criterios técnicos como en las anteriores versiones, sino descripciones de cómo una persona puede interactuar con la tecnología en función de sus capacidades funcionales, independientemente de una discapacidad concreta.

El objetivo no es obtener un listado de diferentes discapacidades, sino describir limitaciones funcionales que pueden darse en distintos contextos y que pueden afectar a cualquier persona de forma permanente, temporal o situacional.

Por ejemplo, una persona con discapacidad visual puede necesitar “uso sin visión”, pero también una persona usando el móvil al sol con mala visibilidad puede encontrarse en una situación similar.

Tipos de provisión

Y por último, al menos en este artículo, la versión 3.0 también introduce un nuevo concepto denominado tipos de provisión (types of provisions) (Inglés), que define cómo se evalúan y ponderan los distintos requisitos dentro del modelo de conformidad.

Dentro de estos tipos de provisión encontramos:

• Requisitos principales (core). Son aquellos aspectos considerados esenciales para que una experiencia sea accesible. Si alguno de estos requisitos falla, directamente no se podrá alcanzar conformidad, independientemente de la puntuación total obtenida.
• Requisitos suplementarios. Son aspectos que mejoran la experiencia de accesibilidad, pero cuyo incumplimiento no invalida completamente la conformidad. Estos requisitos ayudan a medir la calidad global de la experiencia accesible.
• Afirmaciones. Son declaraciones adicionales realizadas por la propia organización para demostrar prácticas de accesibilidad que no siempre pueden validarse automáticamente.

Cada uno de ellos tiene un peso y una función distinta dentro del nuevo sistema de evaluación que propone WCAG 3.0.

Conclusiones

WCAG 3.0 todavía está en fase de borrador, pero ya nos deja ver un cambio importante en la forma en la que entendemos la accesibilidad digital.

Más allá de nuevos niveles, nuevos términos o nuevas métricas, lo que realmente cambia es el enfoque: pasamos de un modelo basado en cumplimiento técnico estricto a un modelo más centrado en resultados, contexto y experiencia real de uso.

Esto no significa que WCAG 2.2 deje de ser relevante, al contrario: sigue siendo el estándar vigente y la referencia actual en accesibilidad web. Pero entender hacia dónde se dirige WCAG 3.0 nos ayuda a anticipar cómo evolucionará el diseño y desarrollo de productos digitales en los próximos años.

Dicho esto, espero que te haya gustado este artículo y te haya ayudado a entender un poco más qué nos podemos esperar de la nueva versión de las WCAG. ¡Te leo en comentarios!

Sin embargo, a medida que esas aplicaciones exigen más capacidad de procesamiento (edición de vídeo, videojuegos, inteligencia artificial, simulaciones o herramientas profesionales) también han empezado a aparecer límites relacionados con el rendimiento, la eficiencia y la portabilidad.

Ahí es donde entra WebAssembly, más conocido como Wasm, una tecnología que en 2026 ya ha dejado de ser una promesa experimental para convertirse en una de las piezas más relevantes del desarrollo moderno.

En este episodio analizamos qué es realmente WebAssembly, por qué está despertando tanto interés en la industria y cómo puede cambiar la forma en la que construimos aplicaciones tanto en la web como fuera de ella.

Qué es exactamente WebAssembly

WebAssembly nació con un objetivo muy concreto: permitir ejecutar código de alto rendimiento dentro del navegador. Hasta hace unos años, JavaScript era prácticamente la única opción disponible para desarrollar aplicaciones web avanzadas, pero ciertos escenarios seguían teniendo problemas de rendimiento importantes.

La propuesta de Wasm fue diferente desde el principio. En lugar de competir directamente con JavaScript, introdujo una nueva capa de ejecución capaz de correr código compilado desde lenguajes como C, C++ o Rust con una velocidad muy cercana al rendimiento nativo.

Eso cambió completamente la percepción del navegador. Dejó de ser simplemente un entorno para ejecutar JavaScript y empezó a verse como una plataforma universal donde podían convivir múltiples lenguajes y modelos de ejecución.

Y, aunque inicialmente el foco estaba puesto en el frontend, la evolución de WebAssembly ha terminado llevando la tecnología mucho más allá.

El verdadero valor de Wasm no es solo el rendimiento

Cuando se habla de WebAssembly, normalmente lo primero que aparece es la palabra “velocidad”. Y sí, el rendimiento es uno de sus puntos fuertes, pero probablemente no sea lo más importante. La gran revolución de Wasm es la portabilidad.

Un mismo módulo puede ejecutarse prácticamente igual en un navegador, en un servidor, en un entorno edge o incluso en dispositivos IoT. Esto permite construir aplicaciones mucho más ligeras y consistentes sin depender tanto del sistema operativo o de arquitecturas específicas.

Por eso muchas compañías están empezando a utilizar WebAssembly como una capa de ejecución universal. La idea de “compilar una vez y ejecutar en cualquier sitio” vuelve a cobrar fuerza, pero esta vez orientada al cloud moderno y a aplicaciones distribuidas.

Rust y WebAssembly: una combinación cada vez más habitual

Otro de los protagonistas es Rust y su crecimiento dentro del ecosistema Wasm. No es casualidad que ambos estén evolucionando juntos. Rust aporta seguridad de memoria, binarios muy pequeños y un rendimiento excelente, algo especialmente valioso en entornos donde cada milisegundo y cada megabyte cuentan.

Además, WebAssembly encaja perfectamente con la filosofía de aislamiento y eficiencia que propone Rust. Por eso, muchas herramientas modernas relacionadas con edge computing, plugins extensibles o runtimes ligeros están adoptando esta combinación tecnológica.

En los últimos años también han aparecido plataformas y runtimes específicos que están impulsando enormemente el ecosistema, permitiendo ejecutar módulos Wasm fuera del navegador de una forma cada vez más madura y estable.

El impacto en cloud y edge computing

Uno de los puntos más interesantes de WebAssembly es cómo empieza a posicionarse como alternativa parcial a determinados modelos tradicionales del cloud.

Hoy los contenedores siguen siendo la base de gran parte de las arquitecturas modernas, pero también tienen limitaciones claras relacionadas con consumo de recursos, tiempos de arranque y complejidad operativa.

Los módulos Wasm son extremadamente ligeros y pueden arrancar prácticamente de forma instantánea. Esto los convierte en una solución muy atractiva para entornos serverless, edge computing o sistemas distribuidos donde la eficiencia es crítica.

No significa que Docker o Kubernetes vayan a desaparecer, pero sí que empiezan a aparecer nuevos modelos híbridos donde WebAssembly cubre determinados escenarios de forma mucho más eficiente.

Especialmente en edge, donde ejecutar procesos cerca del usuario final es cada vez más importante, Wasm está encontrando un terreno perfecto para crecer.

Seguridad y aislamiento: otras de sus grandes ventajas

Más allá del rendimiento, muchas empresas están mirando WebAssembly por motivos de seguridad.

Los módulos Wasm funcionan dentro de un entorno aislado y muy controlado, sin acceso directo al sistema operativo. Esto reduce enormemente los riesgos y permite ejecutar código de terceros de una forma mucho más segura que otros modelos tradicionales.

Por eso empieza a utilizarse cada vez más en plataformas SaaS, sistemas multi-tenant o productos empresariales donde la seguridad y el aislamiento son especialmente importantes.

En cierto modo, WebAssembly está evolucionando hacia una especie de “sandbox universal” para ejecutar aplicaciones de manera segura y portable.

El papel de WebAssembly en la inteligencia artificial

A medida que aparecen modelos más pequeños y eficientes, cada vez tiene más sentido ejecutar parte de la inferencia directamente en navegador o en edge, reduciendo costes cloud y mejorando la latencia.

Aquí WebAssembly juega un papel importante porque permite ejecutar código altamente optimizado prácticamente en cualquier entorno. Gracias a esto estamos empezando a ver aplicaciones donde asistentes inteligentes, herramientas creativas o funciones de IA funcionan parcialmente en local, sin depender constantemente de servidores remotos.

Esto no solo mejora el rendimiento, sino también aspectos relacionados con privacidad y costes operativos.

¿WebAssembly sustituirá a JavaScript?

Probablemente no. Y, de hecho, esa no parece ser la dirección del mercado.

La tendencia real apunta hacia aplicaciones híbridas donde JavaScript sigue gestionando la experiencia de usuario y la interacción, mientras WebAssembly se encarga de las partes más exigentes desde el punto de vista computacional.

Más que un reemplazo, Wasm se está convirtiendo en un complemento estratégico.

Lo interesante es que esa convivencia permite aprovechar lo mejor de ambos mundos: la flexibilidad del ecosistema web tradicional y el rendimiento de entornos más cercanos al nativo.

Una tecnología que ya está entrando en producción

Hace unos años WebAssembly parecía reservado a demos técnicas o casos muy específicos. En 2026 eso ya ha cambiado.

Hoy estamos viendo Wasm aparecer en conversaciones reales sobre:

• Edge computing.
• Cloud distribuido.
• Plataformas SaaS.
• Videojuegos.
• Herramientas creativas.
• Seguridad.
• Inteligencia artificial.
• Y arquitecturas empresariales modernas.

Todavía no está presente en todos los proyectos, pero sí empieza a consolidarse como una de las tecnologías con más potencial de crecimiento dentro del ecosistema software.

Y todo apunta a que lo más interesante todavía está por llegar.

En el campo de la ingeniería, hemos reflexionado y nos hemos preocupado mucho sobre cómo gestionar y abordar bien este problema estructural. Una buena gestión de la deuda técnica tiende a hacer que emerja, sea identificada y se habiliten mecanismos ágiles para tratarla, de forma que se convierta en algo sostenible en el tiempo y no bloquee nuestros despliegues.

Sin embargo, existe otro tipo de deuda que tiene un impacto mucho más grande y profundo en las organizaciones y sobre la que, paradójicamente, hablamos mucho menos: la deuda organizacional.

Mientras nuestros equipos técnicos refactorizan código y optimizan infraestructuras, nuestras estructuras corporativas a menudo acumulan ineficiencias, procesos obsoletos y desalineaciones departamentales que amenazan la salud corporativa.

El origen silencioso: cuando el fin justifica los medios

Igual que ocurre con la deuda financiera, endeudarse puede ser algo bueno cuando sirve a un fin estratégico y, a la vez, somos capaces de construir un marco razonable en el tiempo con el que devolver esa deuda. Asumir una fricción temporal en la organización para capturar una oportunidad de mercado es una decisión de negocio perfectamente válida.

La deuda organizacional se produce cuando hay una decisión, ya sea explícita o implícita, que genera un coste futuro no gestionado. Esta deuda se va acumulando y comportándose como un pequeño virus que va entrando poco a poco en las organizaciones y extendiéndose paulatinamente con el tiempo.

A veces empieza como una pequeña decisión justificada por un bien mayor, ya sea el de la eficiencia operativa, la urgencia ineludible del time to market o la elección consciente del mal menor para salvar un hito crítico. Y esto no está necesariamente mal. Igual que tenemos que ser capaces de generar y asumir deuda técnica con responsabilidad en el desarrollo de un producto, debe ocurrir exactamente lo mismo con la deuda organizacional en la gestión empresarial.

El problema viene cuando, a nivel organizativo, no somos capaces de identificar la deuda que vamos generando y atacarla de forma continua. Es entonces cuando las "excepciones temporales" se cristalizan y se convierten en la norma.

El impacto en la cultura y la proactividad

La deuda organizacional puede tomar muchas formas y, si estás en una gran compañía, seguramente te suene todo esto.

Puede ser un flujo de trabajo entre departamentos que simplemente no funciona y genera cuellos de botella constantes, un procedimiento burocrático que se definió con la mejor de las intenciones pero nunca se logró implantar en la realidad operativa, una falta de definición clara de roles y responsabilidades que provoca que tareas críticas se queden huérfanas o, incluso, una forma de organizar el conocimiento interno que no es ordenada y nos obliga a redescubrir la rueda en cada nuevo proyecto.

Posiblemente hayas visto mil veces estas cosas en todas las organizaciones. E incluso es muy probable que, si has intentado preguntar sobre ello, hayas obtenido respuestas automáticas del tipo: "siempre se ha hecho así", "todos sabemos que no funciona pero no hace mal a nadie" o "es la forma habitual de hacer las cosas en nuestra cultura". Estas respuestas son un reflejo claro de nuestros sesgos cognitivos aplicados a la inercia corporativa, donde la mente prefiere mantener el status quo conocido antes que enfrentarse al esfuerzo de la reestructuración.

Muchas veces, lo más tóxico de esta deuda organizacional no es la ineficiencia del proceso en sí, sino el ejemplo que genera el hecho de que la deuda no se gestione y esté ahí expuesta, delante de todo el mundo y viéndola todos los días.

Cuando empieza a extenderse, la deuda es como un veneno que va paralizando la acción, la toma de decisiones valientes y la proactividad de los equipos. El mensaje de fondo que se está trasladando de forma implícita a la plantilla es: "no importa si no hacemos las cosas bien". Esto va generando un óxido que se deposita poco a poco en los engranajes de la compañía, erosionando la motivación y convirtiendo la innovación en un camino lleno de fricciones innecesarias.

Patrones de acción para una gestión sostenible

En estas situaciones de estancamiento, la pregunta que debemos hacernos es: ¿qué podemos hacer desde nuestro lado para ayudar a solucionar el problema de la deuda organizacional?

No existen soluciones mágicas ni frameworks infalibles, ya que cada compañía tiene su propio contexto, madurez e idiosincrasia. Pero sí que podemos aplicar algunos patrones, inspirados en principios de optimización de procesos, lean e ingeniería del software, que pueden ayudarnos a avanzar hacia una gestión verdaderamente sostenible de la deuda. Os propongo los siguientes cuatro pilares:

1 Identificar la deuda organizativa

El primer paso para resolver un problema es, invariablemente, sacarlo a la luz.

Identificar y "declarar" que existe la deuda es, en sí mismo, una declaración de intenciones vital para la cultura de la empresa. Primero, porque le ponemos un nombre concreto y definimos un perímetro acotado. Segundo, porque ya estamos reconociendo públicamente que hay un punto de mejora y que es algo que nos importa solucionar.

Solo esto, que fundamentalmente es un tema de actitud y seguridad psicológica, puede suponer un cambio radical en la tendencia del impacto negativo de la deuda organizacional.

Lo ideal es tener algún tipo de registro o backlog (idealmente público, transparente y colaborativo) de deuda organizacional, similar a cómo gestionamos nuestras historias de usuario y a través de este backlog asignar un responsable, hacer seguimiento y medir el impacto. Esto puede hacerse a nivel de gran departamento, de equipo técnico o incluso a nivel personal para la gestión del trabajo diario.

2 Definir una prioridad, una medida preliminar de esfuerzo y un beneficio esperado

No toda la deuda tiene la misma repercusión ni urge pagarla con la misma inmediatez. Es importante ser capaces de dar una dimensión al volumen de la deuda que tenemos encima de la mesa para poder medir e identificar los temas que tienen un mayor impacto directo en el negocio (el ROI de solucionarlo) y en el bienestar de las personas. Sin esta cuantificación, corremos el riesgo de malgastar energía en refactorizaciones organizativas que no aportan valor real.

3 Establecer un plan de acción con límites temporales realistas

Una vez priorizada, toca definir unos pasos a seguir.

A la hora de establecer este plan de acción, hay que tratar de ser extremadamente pragmáticos y realistas, identificando bien los puntos de dolor. ¿Cuántas veces se intenta solucionar un problema reinventando el enfoque desde cero, sin haber hecho un análisis previo de cuál era realmente la falla y acabamos construyendo un nuevo proceso totalmente diferente que adolece de los mismos males que el anterior?

Lo razonable es aplicar una aproximación progresiva, de la misma manera que una herida se cura poco a poco. En ocasiones es posible que no consigamos solucionar totalmente el problema sistémico en el primer intento. Y no pasa nada. Lo importante es que el plan que definamos se pueda ejecutar, sea viable y con él demos pasos tangibles en la dirección correcta. Si no solucionamos totalmente la deuda pero logramos mitigarla o reducir su incidencia diaria, hemos avanzado y hemos aprendido valiosas lecciones. En la siguiente iteración podremos dar el siguiente paso con mucho más contexto.

4 Reservar una capacidad orgánica para manejar la deuda

Por último, y quizás lo más importante para la directiva: la gestión de la deuda organizacional no debe entenderse como una situación de crisis excepcional, una "auditoría" puntual o un proceso de transformación radical exhaustivo. Debe concebirse como una actividad de mejora continua integrada en nuestro ADN organizacional.

Igual que los equipos de desarrollo e ingeniería destinan proactivamente un porcentaje de su capacidad a gestionar la deuda técnica para mantener las plataformas a flote, las organizaciones deben hacer exactamente lo mismo para la gestión de la deuda organizacional, de una forma ordenada, sistemática y patrocinada desde arriba.

Para que esto funcione, el liderazgo debe implicarse. Un/a CEO, igual que evalúa la rentabilidad de una línea de negocio o la adopción de nuevas innovaciones, debería preguntar con naturalidad en la reunión trimestral del Consejo: ¿qué deuda organizacional hemos gestionado y resuelto en este trimestre?

Conclusión

Lidiar con la entropía es parte del crecimiento, pero ignorarla es un riesgo que ninguna organización innovadora puede permitirse a largo plazo.

¿Qué te han parecido estas recomendaciones? ¿Ves viable aplicarlas en tu compañía? Cuéntanos qué medidas habéis probado y cuáles han funcionado de verdad.

Si aún no estás gestionando esa deuda, el mejor momento para empezar es hoy. Identifícala, estima su coste y define ese primer paso para reducirla. Y recuerda: si el desafío supera la capacidad actual de tu equipo, buscar apoyo externo es una decisión valiente y estratégica.

¡Déjanos tus reflexiones en los comentarios!

A través de anuncios masivos, giros estratégicos en el mercado Cloud y una competencia feroz por el talento, gigantes como Google, OpenAI, Microsoft, Anthropic y Meta han reconfigurado por completo el tablero de juego arquitectónico y de negocio.

Google I/O 2026 y la consolidación de la "era de los agentes"

Google ha evidenciado que la IA no es una capa experimental, sino el núcleo operativo sobre el que orbitan todos sus productos. Con un volumen de procesamiento que ya supera los 3,2 cuatrillones de tokens al mes, la compañía de Mountain View ha centrado su estrategia en dotar de autonomía e interoperabilidad multimodal a sus sistemas.

Sus principales lanzamientos han sido:

• Gemini 3.5 Flash: el nuevo modelo ligero por defecto de la compañía. Destaca por una velocidad hasta 4 veces superior a sus competidores directos y está optimizado específicamente para tareas complejas, razonamiento financiero y ejecución de código, superando en múltiples benchmarks a arquitecturas sustancialmente más pesadas.
• Gemini Omni: presentado como un "modelo del mundo" nativo. Es capaz de procesar, cruzar y sintetizar simultáneamente texto, audio, imágenes y vídeo. Genera outputs hiperrealistas entendiendo variables físicas del entorno como la gravedad y el movimiento, integrándose ya de forma nativa en herramientas creativas y YouTube Shorts.
• Gemini Spark: un agente personal autónomo que opera en segundo plano 24/7. Diseñado para orquestar flujos de trabajo complejos y automatizados, enfocado inicialmente en los suscriptores de Google AI Ultra.
• Rediseño de Google Search (Modo IA): la búsqueda evoluciona hacia una experiencia 100% conversacional sustentada en Gemini 3.5 Flash. Introduce los "agentes de información", capaces de monitorizar temáticas de forma continua y generar dashboards e interfaces dinámicas personalizadas en tiempo real.
• Novedades en consumo: destacan funciones como “Ask YouTube” (búsqueda conversacional y precisa dentro de contenidos en vídeo) y “Docs Live” (estructuración y redacción de documentos completos mediante interacciones de voz naturales en Workspace).
• Antigravity SDK: para la comunidad de equipos de desarrollo y arquitectura, el lanzamiento clave es Antigravity. Se trata de la nueva plataforma unificada y SDK de desarrollo con el que Google centraliza todas sus herramientas de IA. Permite a los equipos de ingeniería un control absoluto sobre la orquestación, gobernanza y despliegue de agentes autónomos en infraestructuras corporativas.

El fin de la exclusividad OpenAI-Microsoft: el nuevo paradigma multicloud

Aunque los movimientos se intuían en las semanas previas, este mes se ha materializado un cambio tectónico en el mercado Cloud: OpenAI ha roto la exclusividad de infraestructura con Microsoft Azure.

Este hito estratégico redefine la distribución de poder tecnológico bajo dos pilares:

• Apertura de nube: OpenAI ahora goza de total libertad para operar, desplegar y escalar sus modelos fundacionales utilizando proveedores alternativos de infraestructura cloud, abriendo las puertas a implementaciones nativas sobre Google Cloud Platform y Amazon Web Services.
• Nuevas reglas financieras: aunque Microsoft mantiene licencias no exclusivas sobre la propiedad intelectual de OpenAI hasta el año 2032, se elimina el modelo de participación directa de ingresos (revenue share) hacia la startup. Esto descarga de fricciones contractuales el mercado cloud y abre un ecosistema de infraestructura de IA sumamente competitivo y descentralizado.

La batalla por los "Defaults": los ecosistemas devoran a las interfaces aisladas

Tres años después de que Microsoft sacudiera el mercado integrando OpenAI en Bing, los datos consolidados de mayo de 2026 muestran una tendencia clara: Google ha recuperado el terreno en el usuario masivo gracias a los "Defaults".

La profunda integración vertical de Gemini dentro de Android, Google Chrome y Google Workspace demuestra que la capilaridad del sistema operativo y los hábitos arraigados del usuario pesan más que las interfaces independientes.
Este hecho está obligando a Microsoft a rediseñar de urgencia la experiencia de usuario y disminuir la fricción de Copilot dentro de Windows.

Guerra de talento al más alto nivel: Anthropic ficha a Andrej Karpathy

La competición por liderar los modelos fundacionales no es solo una cuestión de cómputo, sino de las mentes que los diseñan. El movimiento más sonado del mes ha sido el fichaje estrella de Andrej Karpathy por Anthropic.

Karpathy (cofundador de OpenAI y exdirector de IA en Tesla) es un referente absoluto en la arquitectura de redes neuronales modernas. Su incorporación busca potenciar las capacidades de razonamiento de la familia de modelos Claude, evidenciando que la fuga de cerebros y la captación de talento experto se encuentra en su punto álgido.

Meta contraataca con modelos multiagente y computación paralela

Meta continúa ejecutando una agresiva estrategia de inversión para no quedar descolgada de la carrera que lideran Google y OpenAI. Tras los movimientos iniciales de primavera, durante este mes de mayo han tomado protagonismo sus líneas de desarrollo en código abierto e infraestructura:

• Muse Spark y razonamiento paralelo: enfoques arquitectónicos centrados en que los modelos no solo procesen secuencialmente, sino que ejecuten hilos de pensamiento y validación concurrentes antes de ofrecer un output.
• Sistemas multiagente de código abierto: Meta confía en la fuerza de la comunidad open-source para competir contra entornos cerrados como Claude o ChatGPT, orientando sus esfuerzos a la IA social y a los agentes autónomos hiperconectados.

Mayo ratifica que la IA ya no se mide por lo bien que responde a un prompt, sino por la eficiencia con la que sus agentes coordinan flujos de trabajo autónomos de extremo a extremo.

Para las compañías, el desafío técnico se desplaza desde el diseño de prompts hacia la arquitectura de integración: el verdadero reto ahora es cómo conectar de forma segura, gobernada y eficiente estos nuevos agentes de IA con el backend corporativo, los silos de datos existentes y las plataformas multicloud.

La era de la experimentación ha terminado, ha comenzado la era de la automatización inteligente a escala.

¿Por qué la inteligencia artificial escribe con una estructura tan marcada?

Nos hemos acostumbrado a interactuar con cajas negras que devuelven resultados estadísticamente perfectos. Cuando le pides a un modelo generativo que redacte un artículo, su objetivo principal no es ser original o creativo. Su meta matemática consiste en predecir el siguiente token minimizando el margen de error para que el resultado suene lo más coherente posible.

El problema para el negocio surge cuando esta optimización estadística destruye por completo la identidad de las empresas. Las marcas pierden su voz real al publicar párrafos extremadamente equilibrados que nunca se mojan ni toman partido.

Los detectores automatizados nacen con la promesa de solucionar esta problemática, pero la realidad es muy diferente. Aunque evalúan la procedencia del documento, arrojan tasas de falsos positivos que arruinan el flujo de trabajo de cualquier equipo de contenidos.

Si entiendes cómo funciona el motor probabilístico del algoritmo, podrás identificar sus carencias a simple vista sin depender de software de terceros. Eso sí, por el momento, será necesario mantener el HITL (Human in the Loop) para la monitorización de esta tarea.

¿Qué delata a un modelo del lenguaje que genera texto en castellano?

El castellano tiene una riqueza estructural inmensa que choca de frente con las traducciones literales o los pesos estadísticos heredados del inglés. Los modelos más utilizados han sido entrenados mayoritariamente con corpus anglosajones, y eso deja una huella importante en su sintaxis. Reconocer estos patrones semánticos te convertirá en el mejor filtro de calidad para las publicaciones de tu equipo. A continuación te muestro algunos tips para detectar si un texto podría estar generado con IA:

• Abuso del gerundio

Este es un claro ejemplo de esta transferencia lingüística. La gramática normativa exige que el gerundio exprese una acción simultánea o anterior al verbo principal de la oración. Los algoritmos ignoran esta regla sistemáticamente porque calcan la función del participio presente del inglés. Si lees una frase del estilo "El programa compiló los datos, mostrando los resultados en pantalla", estás ante una “red flag” de manual. Aunque este uso es posible, podríamos hacer más natural esa transición y añadir una conjunción para separar las acciones.

• Estructuras correlativas

Otra señal inconfundible de la generación sintética reside en la cohesión forzada mediante estructuras correlativas. Las máquinas adoran la expresión "no solo..., sino también..." para conectar conceptos dentro de un argumento. Esta simetría constante genera una falsa apariencia de rigor académico que termina resultando agotadora para quien lee. Podemos intercalar transiciones irregulares o simplemente saltar de una idea a otra sin justificar constantemente la conexión.

• Adjetivos redundantes

La adjetivación revela igualmente el origen artificial del documento. Al carecer de experiencia física o juicio propio, los LLMs compensan la falta de profundidad añadiendo calificativos redundantes que funcionan como amplificadores cognitivos vacíos. Verás repetidos hasta la saciedad adverbios “grandilocuentes” como esencial, trascendental, crucial o elemental. También notarás que las máquinas intentan cubrir todos los frentes posibles cuando definen un concepto técnico. Construyen frases donde una simple funcionalidad de software pasa a ser "una solución innovadora y versátil" o, simplemente, “lo mejor de ambos mundos”.

• Los guiones largos “—” y el punto y coma “;”

A nivel tipográfico también detectamos algunas señales. El guión largo (—) aparece incrustado para introducir aclaraciones donde una coma haría el trabajo perfectamente. Ningún/a redactor/a teclea tres guiones largos en un mismo párrafo a menos que esté sufriendo un colapso sobre el teclado. Igual de destacable es el uso repetido del punto y coma a lo largo del texto, cuando en la mayoría de los casos, puede ser sustituido por un punto y seguido.

Estos son solo algunos ejemplos que denotan un posible uso de IA para la generación de textos. Aunque no puede ser tomado como la verdad absoluta, debido a la riqueza del lenguaje, estos patrones conforman un registro lingüístico propio que sacrifica la naturalidad en favor de una fluidez matemática.

¿Podemos medir matemáticamente esta monotonía textual?

La lingüística computacional utiliza dos conceptos para auditar la naturalidad de un escrito sin leerlo. Hablamos de la perplejidad y el concepto de “burstiness”. El primer concepto mide el factor sorpresa en la elección de palabras, mientras que el segundo evalúa la variación en la longitud de las oraciones.

El ser humano escribe combinando frases largas con afirmaciones cortas y directas.

Si quieres auditar un corpus de tu empresa sin enviar los datos a un detector de terceros, puedes aplicar un análisis básico de varianza con Python. Identificar un ritmo plano en la longitud de las frases te indicará qué secciones necesitan una revisión urgente.

Las métricas nos confirmarán lo que el ojo humano ya intuye al leer el primer párrafo. Incorporar reglas de estilo en los prompts o realizar una pasada de limpieza manual resulta muy útil si queremos mantener el valor de nuestro mensaje y la personalidad de nuestra marca.

Conclusiones

Identificar el origen de una publicación no requiere de conocimientos elevados sobre la temática. Entender la raíz probabilística de los algoritmos nos permite detectar de una pasada sus carencias narrativas y sus vicios sintácticos.

Modificar estos comportamientos mediante prompting avanzado o reescritura manual (posedición) marca la diferencia entre hacer ruido en internet o aportar conocimiento real.

Ahora sí, ya estás preparado/a para detectar esos posts de LinkedIn de tus contactos que han sido generados por IA. ¿Tienes algún otro tip para detectar el contenido generado por IA sin usar detectores? Te leo en comentarios 👇.

Referencias

• Cómo reconocer un texto escrito por IA: 12 señales inconfundibles
• Análisis Lingüístico Forense de la Huella Estilística de los Modelos de Lenguaje
• Cómo Hacer que un Texto de IA Sea Indetectable (Javadex)

En este episodio de “Cómo conocí a nuestro cloud”, nuestro equipo de Goodly se sienta a analizar las presentaciones más potentes, los lanzamientos inmediatos y los debates más picantes que nos ha dejado el evento tecnológico del año.

Modelos de lenguaje en producción: rendimiento con Gemini 3.5 Flash y Gemini Omni

El gran protagonismo de las sesiones se lo llevaron los nuevos modelos de lenguaje, destacando el desembarco de Gemini 3.5 Flash directamente en GA y disponible para Europa, demostrando que las versiones rápidas ya miran de tú a tú a las versiones Pro de generaciones anteriores.

Sin embargo, el verdadero efecto wow técnico llegó con Gemini Omni, una nueva familia multimodal capaz de comprender leyes físicas para generar entornos hiperrealistas.

Toda esta potencia se traduce también en un lavado de cara histórico para Google Search, que ahora integra Generative UIs (interfaces interactivas creadas en tiempo real) y agentes en segundo plano que funcionan como "minions" para monitorizar vuelos o noticias de forma proactiva.

Asistentes autónomos y eficiencia en flujos de trabajo conversacionales

Si hay algo que genera expectación real para el usuario de a pie es el anuncio de Gemini Spark, el asistente personal autónomo que promete gestionar nuestras tareas pendientes cruzando de manera inteligente datos de nuestro correo, calendario y documentos.

Además, Goodly analiza herramientas como Ask YouTube, que permite realizar búsquedas conversacionales cruzando vídeos e indexando contenido para eliminar de un plumazo el molesto clickbait, y Docs Live, una función que nos acerca un paso más a un flujo de trabajo donde hablarle al ordenador para crear contenido será mucho más habitual que teclear.

Antigravity 2.0 e infraestructura: ¿la era de la abstracción total del código?

El bloque de hardware e infraestructura tampoco se quedó atrás, trayendo de vuelta el concepto de unas gafas de realidad aumentada verdaderamente estéticas y llevables; además del renacimiento de Antigravity 2.0, el entorno agéntico de desarrollo de Google que quiere convertirse en el motor invisible de la programación actual.

Esto desata un interesantísimo debate en el episodio: con las nuevas facilidades de despliegue en la nube y los paquetes de suscripción unificados, ¿estamos ante la era de los/as desarrolladores/as Muggles? Perfiles completamente ajenos a la tecnología ya están perdiendo el miedo a la IA para crear y monetizar sus propias aplicaciones hechas a medida.

Desafíos críticos: privacidad, monopolio y el desfase normativo europeo

Como en todo gran evento, no todo son luces. También hay sombras que analizar en nuestra tradicional “barra de bar”, desde los desafíos críticos de la privacidad y las leyes antimonopolio hasta el eterno e incómodo retraso de ciertas funciones en suelo europeo frente a EE. UU.

Si quieres enterarte de hacia dónde se dirige el ecosistema de Google y cómo te van a afectar estos cambios de manera inmediata, no te puedes perder este episodio. ¡Dale al play!