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!

Y hay algo que suele marcar la diferencia: que la interfaz reaccione. Sentir que lo que haces tiene una respuesta inmediata hace que todo se perciba más vivo y cuidado. Es verdad que no siempre tiene sentido añadir este tipo de interacciones, pero cuando se usan bien en el contexto y momento adecuados, mejoran muchísimo el resultado final.

Uno de los efectos más simples y llamativos es el cursor tracking. Y aunque pueda parecer complejo a primera vista, es súper sencillo de hacer.

¿Qué es exactamente el cursor tracking?

El cursor tracking consiste en detectar la posición del cursor y usarla para actualizar la posición de un elemento en pantalla.

A nivel técnico, se resume en tres pasos:

1. Escuchar el movimiento del mouse (mousemove)
2. Obtener sus coordenadas (clientX, clientY)
3. Actualizar el DOM utilizando esos valores para crear la interacción.

Implementación básica del cursor tracking

Ahora vamos a ver cómo podemos implementar un efecto sencillo de cursor tracking. En este caso, vamos a construir una pequeña estela que sigue al cursor de forma fluida utilizando GSAP, ya que nos permite gestionar las animaciones de forma mucho más fácil y rápida que con CSS puro.

Aquí vemos el ejemplo completo en CodePen:

El HTML: preparando los elementos de la estela

Para este efecto, necesitamos varios elementos que formarán la estela. Cada uno de estos divs será una “partícula” que seguirá la posición del cursor con un ligero retraso respecto a la anterior.

<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>

El CSS: posicionamiento y estilo

A continuación, les damos un estilo básico para que funcionen como pequeños puntos. Lo más importante aquí es el position: fixed para que se muevan respecto a la ventana y el pointer-events: none para que los círculos no intercepten los clics destinados a otros botones o enlaces de la web.

body {
  height: 200vh;
  background: #111111;
  overflow: hidden;
}

.trail {
  width: 20px;
  height: 20px;
  background: #d9ed92;
  border-radius: 50%;
  position: fixed;
  top: 0;
  left: 0;
  pointer-events: none;
}

Con esto conseguimos que cada elemento sea un círculo fijo que podremos mover libremente por la pantalla.

El JavaScript: animando con GSAP

Aquí es donde entra GSAP para ayudarnos a hacer la animación de forma más fácil. El truco para que no se muevan todos a la vez como un bloque pegado al ratón está en el delay progresivo.

Primero, seleccionamos todos los divs que hemos creado:

const trails = document.querySelectorAll(".trail");

Luego vamos a centrar las partículas al cargar la página. Si no lo hacemos, el efecto empezaría de golpe desde la esquina superior izquierda de la pantalla (0,0) en cuanto movamos el ratón por primera vez. Con gsap.set las posicionamos directamente en el centro:

// Center the particles on load to avoid the default (0,0) position
const centerX = window.innerWidth / 2;
const centerY = window.innerHeight / 2;

trails.forEach((el) => {
  gsap.set(el, {
    x: centerX,
    y: centerY
  });
});

Es importante decir que esto no es imprescindible. Hay muchas formas de enfocarlo. Por ejemplo, podrías ocultar las partículas con opacidad cero y hacer que aparezcan solo cuando el usuario mueva el ratón. Pero en nuestro ejemplo, como no hay nada más en la pantalla, tiene más sentido que los elementos estén colocados y listos para reaccionar desde el centro.

Por último, añadimos un event listener que detectará el movimiento del ratón. En cada movimiento, lanzaremos una animación de GSAP para cada partícula:

// Cursor tracking with staggered delay to create a smooth trailing effect
window.addEventListener("mousemove", (e) => {
  trails.forEach((el, index) => {
    gsap.to(el, {
      x: e.clientX,
      y: e.clientY,
      duration: 0.2 + index * 0.05, // We use the index so each particle is slightly slower than the previous one
      ease: "power2.out"
    });
  });
});

Al usar el index del array para calcular la duración, conseguimos que la primera partícula sea casi instantánea y las siguientes vayan con un pequeño retraso. El resultado es esa sensación de movimiento orgánico que hace que el efecto sea mucho más visual.

Importante: para que este ejemplo funcione correctamente, necesitamos incluir GSAP en nuestro proyecto. Podemos hacerlo añadiendo el siguiente script:

<script src="https://cdn.jsdelivr.net/npm/gsap@3.15/dist/gsap.min.js"></script>

Cursor tracking avanzado: creando unos ojos que te siguen

Ya hemos visto cómo hacer que algo siga al cursor, pero el cursor tracking no siempre tiene por qué ser un desplazamiento total por la pantalla. Podemos usar esa misma lógica de coordenadas para crear interacciones más sutiles y divertidas, como unos ojos que sigan el movimiento del ratón.

En este caso, en lugar de mover los elementos, vamos a calcular el ángulo y la distancia para que las pupilas se muevan siempre dentro del ojo.

Puedes ver el resultado en Codepen.

El HTML: estructura de los ojos

Para que esto funcione, necesitamos un contenedor para cada ojo y un elemento interno para la pupila.

<div class="eyes-container">
  <div class="eye">
    <div class="pupil"></div>
  </div>
  <div class="eye">
    <div class="pupil"></div>
  </div>
</div>

El CSS: delimitando el movimiento

El truco aquí es que el contenedor .eye tenga un overflow: hidden. Esto nos asegura que, aunque nos pasemos con los cálculos, la pupila nunca se saldrá de la parte blanca del ojo (o si llegase a sobrepasar su contenedor, con esto, no lo veremos).

body {
  margin: 0;
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100dvh;
  background-color: #f5f5f5;
  overflow: hidden;
}

.eyes-container {
  display: flex;
  gap: 20px;
}

.eye {
  width: 100px;
  height: 100px;
  background-color: white;
  border: 4px solid #1a1a1a;
  border-radius: 50%;
  position: relative;
  display: flex;
  justify-content: center;
  align-items: center;
  overflow: hidden;
}

.pupil {
  width: 40px;
  height: 40px;
  background-color: #1a1a1a;
  border-radius: 50%;
  position: absolute;
}

El JavaScript: un poco de trigonometría y GSAP

Aquí la cosa se pone interesante. Para que los ojos miren hacia donde está el ratón, necesitamos saber el ángulo entre el centro del ojo y el cursor.

Primero, seleccionamos las pupilas que es lo que vamos a mover:

const pupils = document.querySelectorAll(".pupil");

Y ahora calculamos el movimiento. Math.atan2 nos da el ángulo y Math.cos / Math.sin nos dice cuánto desplazar la pupila en los ejes X e Y para que mire en esa dirección:

window.addEventListener("mousemove", (e) => {
  pupils.forEach((pupil) => {


    // Get the parent eye element and its center position
    const eye = pupil.parentElement;
    const rect = eye.getBoundingClientRect();
    const eyeCenterX = rect.left + rect.width / 2;
    const eyeCenterY = rect.top + rect.height / 2;

    // Calculate the angle between the mouse and the eye center
    const angle = Math.atan2(
      e.clientY - eyeCenterY,
      e.clientX - eyeCenterX
    );

    // Define the maximum movement radius for the pupil
    const maxDistance = 25;

    // Measure mouse distance from the eye center and clamp it
    const mouseDistance = Math.hypot(
      e.clientX - eyeCenterX,
      e.clientY - eyeCenterY
    );

    const distance = Math.min(mouseDistance / 10, maxDistance);

    // Calculate pupil offset based on angle and clamped distance
    const moveX = Math.cos(angle) * distance;
    const moveY = Math.sin(angle) * distance;

    // Animate the pupil for a smooth
    gsap.to(pupil, {
      x: moveX,
      y: moveY,
      duration: 0.4,
      ease: "power2.out",
      overwrite: "auto"
    });
  });
});

Importante: al igual que en ejemplo anterior, para que este ejemplo funcione correctamente, necesitamos incluir GSAP en nuestro proyecto. Podemos hacerlo añadiendo el siguiente script:

<script src="https://cdn.jsdelivr.net/npm/gsap@3.15/dist/gsap.min.js"></script>

Como has podido ver, una vez que entiendes cómo capturar las coordenadas del ratón, las posibilidades son casi infinitas (y digo “casi” porque siempre habrá alguna cosa un poco imposible). Pero, con esta base, podemos pasar de una simple estela a una animación más compleja con apenas unos cambios en la lógica del JavaScript.

Y lo mejor de usar GSAP para estos efectos es que nos quita de encima el trabajo pesado de gestionar los frames y los suavizados, permitiéndonos centrar la atención en lo que realmente importa: que la interacción se sienta natural y aporte valor a la experiencia de usuario.

Espero que este post te haya gustado y haya podido ayudarte (aunque sea un poquito) a entender mejor cómo funciona GSAP y puedas hacer tus propias animaciones. ¡A experimentar!

Hoy en día ya no nos estamos enfrentando a un problema de falta de talento, nos estamos enfrentado a equipos saturados, ciclos de entrega prolongados y dependencia de perfiles senior para tareas repetitivas, actuando como freno para la innovación.

Para superar esta barrera, tenemos que cambiar la forma de construir productos digitales. Así nace Paradigma Context Delivery Framework, un cambio de paradigma que mueve el eje de gravedad hacia el desarrollo AI First.

Este framework transforma el conocimiento en inteligencia activa, generando código automático, probado y seguro, permitiendo orquestar la tecnología de forma inteligente y escalar sin incrementar proporcionalmente los costes.

¿Necesitas una hoja de ruta? Échale un vistazo al informe que hemos preparado y libera la inversión para lo que realmente importa: la innovación.

¡Descárgatelo ya! 👇

El auge de la IA: de algoritmos a agentes operativos

Ya no hablamos de qué modelo elegir, sino de cómo escalarlo, gobernarlo y llevarlo a producción. El gran reto del sector energético es que su actividad principal ocurre en el mundo físico: en las infraestructuras de generación, transporte y distribución.

Para que los agentes de IA funcionen, los datos deben estar preparados y cerca del negocio. Esto está obligando a las compañías a realizar una ingeniería real, limpiando modelos de datos y procesos que llevaban años abandonados, permitiendo que la IA generativa ayude a transformar el acceso a la información mediante lenguaje natural gracias a metadatos bien estructurados.

Soberanía y compartición de datos: el fin de los silos

En 2026, la soberanía del dato ha dejado de ser un tema puramente regulatorio para convertirse en una prioridad estratégica y de resiliencia ante ciberataques en infraestructuras críticas.

Ecosistemas de compartición: Europa impulsa espacios de datos donde las compañías comparten información para avanzar en la transición energética.

El balance del CEO: existe una línea delgada entre proteger el core del negocio y compartir datos con competidores para lograr una eficiencia grupal que fortalezca a todo el sector.

Eficiencia energética y gemelos digitales

La sostenibilidad ya no es un concepto intangible, ahora afecta directamente a la cuenta de resultados. En este escenario, el gemelo digital ha evolucionado para ser algo más que un entorno de pruebas, convirtiéndose en una herramienta operativa que permite tomar decisiones con menor latencia.

Integrar infraestructuras con décadas de antigüedad en modelos digitales es un reto ambicioso, pero vital para modernizar la red. Mientras que las nuevas instalaciones nacen digitalizadas desde el diseño, el verdadero éxito de 2026 reside en la capacidad de operar remotamente el legado histórico de nuestras redes eléctricas.

Transformación cultural: el binomio Oficina-Campo

La tecnología por sí sola no resolverá los retos del sector, se requiere un cambio de cultura profundo que abarque desde IT hasta el negocio y toda la cadena de proveedores.

No existe una herramienta de "caja" que solucione la complejidad actual si no se rediseña la toma de decisiones.

El éxito de cualquier iniciativa digital en 2026 depende de entender lo que ocurre en la calle, donde los técnicos de mantenimiento se enfrentan a riesgos reales.

Para transformar el sector, es fundamental que quienes diseñan las soluciones en las oficinas comprendan las casuísticas operativas del campo, asegurando que la tecnología aporte valor real en el punto donde se gestiona la infraestructura.

Si quieres saber más sobre energía...

Te recomendamos echar un vistazo al post: Analizando el mercado energético: ¿qué hacemos con la deuda técnica?

Ahora que ya hemos conocido qué es esta metodología y cómo implementarla, solo nos queda por saber cómo podemos medirla. En este último post nos centramos en la base de todo el proceso, la medición, abordando los KPIs que se pueden usar para materializar las necesidades con datos y para abordar los progresos de una forma lo más precisa posible en base a informaciones objetivas.

No es una tarea sencilla disponer de todas las herramientas y frameworks necesarios para realizar estas mediciones, por lo que el proceso es progresivo y requiere de un compromiso por parte de todos los miembros de la empresa.

En Green QA, las métricas son el termómetro de nuestra eficiencia. No medimos por burocracia, sino para identificar "fugas energéticas" y "desperdicio digital".

A lo hora de establecer los KPIs y OKRs necesarios para evaluar los distintos puntos que componen GQA, hemos realizado una agrupación de los mismos de la siguiente manera a través de las categorías de medición:

• Energía y software (eficiencia técnica)
• Carbono y residuos (impacto en el planeta)
• Calidad de datos ESG (confianza y cumplimiento)
• Eficiencia operativa y "Digital Waste" (mejora del proceso)

KPIs de energía y software (eficiencia técnica)

Aquí medimos el esfuerzo físico que el hardware realiza para ejecutar nuestro software. Los KPIs usados para esta parte son los siguientes:

KPIs de carbono y residuos (impacto en el planeta)

Transformamos los vatios en impacto ambiental real. Los KPIs usados para esta parte son los siguientes:

KPIs de calidad de datos ESG (confianza y cumplimiento)

Si los datos sobre sostenibilidad son malos, la estrategia falla. Los KPIs usados para medir esta parte son los siguientes:

KPIs de eficiencia operativa y "Digital Waste" (mejora del proceso)

No basta con que el test consuma poco; se trata de no ejecutar lo que no es necesario. El desperdicio digital es contaminación silenciosa. Los datos que usan para medir esta parte son los siguientes:

Estándares y cumplimiento

No basta con "ser verde", hay que demostrarlo ante los reguladores internacionales. El Green QA es el último filtro que garantiza que la empresa no incurra en riesgos legales por reportar datos erróneos.

En el anterior post comentamos aspectos legales para los que es interesante aplicar el GreenQA dentro de una empresa. En este punto vamos a ver cómo asegurar con datos el cumplimiento de la normativa y cómo podemos verificar si el proceso de calidad que hemos seguido ha contribuido al cumplimiento de la normativa apoyándose en los KPIs que han sido definidos en el punto anterior.

CSRD (directiva de la UE) + ESRS

La CSRD (directiva sobre informes de sostenibilidad corporativa) es la normativa europea (vigente desde 2024) que obliga a grandes empresas y cotizadas a reportar información detallada de sostenibilidad bajo criterios ambientales, sociales y de gobernanza (ESG).

En España se aprobó el 29 de octubre de 2024 el Proyecto de Ley de Información empresarial sobre sostenibilidad que es una trasposición CSRD. Los ESRS (Estándares Europeos de Información sobre Sostenibilidad) son las normas técnicas obligatorias para cumplir con la CSRD.

A nivel de QA podemos auditar los datos de sostenibilidad. El Green QA aquí es el "Auditor de Datos". Debe asegurar que los datos ESG (como el consumo de los servidores en Staging) no son una estimación a dedo, sino que tienen trazabilidad técnica. Si el software de reporte falla, la empresa se enfrenta a sanciones por Greenwashing. Podemos usar la siguiente checklist para comprobar el cumplimiento:

• Trazabilidad de datos. ¿Es posible rastrear el dato de emisión desde el sensor/log original hasta el informe final sin alteraciones manuales?
• Validación de APIs ESG. ¿Se ha testeado que la integración con proveedores Cloud (AWS/Azure/GCP) extrae los datos de consumo sin pérdidas?
• Auditabilidad. ¿Posee la métrica de QA evidencia técnica verificable para una auditoría externa?
• Exactitud vs. estimación. ¿Se han sustituido las estimaciones genéricas por datos reales de consumo de hardware siempre que sea posible?

GHG Protocol (Alcance 3 - Software)

El GHG Protocol (Alcance 3) es el estándar global más utilizado para medir y reportar las emisiones indirectas de gases de efecto invernadero (GEI) que ocurren en la cadena de valor de una empresa, excluyendo las de energía comprada (Alcance 2).

Desde el punto de vista de QA, se debe validar que las herramientas de terceros (SaaS de testing, CDNs, APIs de pago) proporcionan datos de emisiones reales. Se pueden crear Quality Gates que bloqueen un despliegue si el "presupuesto de carbono" de ese microservicio supera lo permitido por el protocolo. Podemos usar la siguiente checklist para comprobar el cumplimiento:

• Cálculo de huella. ¿Se han aplicado los factores de conversión de CO2 actualizados a la energía consumida en el despliegue?
• Filtro de proveedores. ¿Se ha verificado que los partners (SaaS de testing, CDNs) tienen certificación ISO 14001 o Energy Star?
• Presupuesto de carbono. ¿El release actual se mantiene dentro del límite de emisiones establecido respecto al periodo anterior?
• Validación de fórmulas. ¿Se ha realizado un test unitario sobre las fórmulas de cálculo de emisiones para asegurar precisión matemática?

ISO/IEC 21031 (Software Carbon Intensity - SCI)

Es el Unit Testing de la huella de carbono. Estándar internacional para calcular la intensidad de carbono del software (SCI).

El rol de Green QA aquí es integrar la medición de la huella de carbono en la pirámide de pruebas. Igual que validamos el tiempo de respuesta, el QA valida el coste energético por transacción. Si un cambio en la base de datos aumenta los ciclos de CPU, el QA actúa como garante para evitar que ese "desperdicio energético" llegue a producción.

• Análisis de intensidad. ¿Se ha medido el consumo de kWh por cada ejecución de la suite de pruebas?
• Optimización de CPU. ¿El código evita ciclos innecesarios o "Green Smells" (loops infinitos, llamadas API redundantes)?
• Pruebas headless. ¿Se han ejecutado los tests en modo headless para reducir el consumo energético del renderizado gráfico?
• Validación de Idle Energy. ¿Se ha verificado que los entornos de Staging se apagan o auto-escalan a cero tras la ejecución?

Directiva de empoderamiento de los consumidores (Anti-Greenwashing)

La UE está prohibiendo afirmaciones ambientales genéricas sin pruebas ("software 100% ecológico"). Desde el punto de vista de QA, se debe certificar las evidencias. Si el marketing dice que la app consume un 30% menos de batería, el QA debe haber ejecutado pruebas de regresión energética (con herramientas como GreenFrame o Lighthouse) que respaldan esa afirmación con datos empíricos y repetibles.

Accesibilidad web (WAD / WCAG) como sostenibilidad

Existe una correlación directa: un sitio web accesible y ligero es un sitio web de bajo consumo. Desde el punto de vista de QA, se debe validar que el DOM sea eficiente. Menos elementos innecesarios y peticiones redundantes significan menos ciclos de CPU en el dispositivo del cliente. Aquí el QA une impacto social (inclusión) con impacto ambiental (eficiencia).

Tabla de mediciones de huella de carbono

En este punto se muestra una tabla con datos que pueden ser útiles y que se usan para automatizar los cálculos de la huella de carbono. Estos datos van variando según mejoran las tecnologías y se hacen más eficientes por lo que se han de tomar como una estimación.

Conclusiones

A lo largo de esta serie de tres post sobre Green Quality Assurance hemos podido ir viendo las posibilidades que hay dentro del mundo de la tecnología y, en concreto, dentro del mundo del software, para poder emprender acciones y mejorar la eficiencia energética.

Esto ocurre, principalmente, por lo que podríamos llamar una especie de "ceguera sistémica". Cuando miras la empresa desde la mesa del Comité de Dirección, todo parece un organigrama perfecto, limpio y ordenado. La realidad operativa, en cambio, es una red compleja de interdependencias tanto humanas como técnicas. Intentar gestionar un cambio profundo basándose solo en el organigrama es, básicamente, gestionar una ilusión.

Si de verdad queremos conectar la estrategia con la ejecución del día a día y proteger los beneficios de una transformación exitosa, toca mirar tres dimensiones invisibles que pocos tienen en cuenta. No aparecen en los informes financieros pero son las fuerzas que impulsan o frenan el avance de la compañía:

1. Dimensión cognitiva: la capacidad mental y emocional disponible de tu equipo.
2. Dimensión estructural: las reglas del juego reales (como incentivos e interacciones entre las personas y departamentos) más allá de los cargos.
3. Dimensión del flujo: el camino real que recorre el valor, independiente de la jerarquía.

Veamos cómo estas barreras invisibles pueden bloquear la ejecución con ejemplos reales.

1 Barrera cognitiva: el coste oculto de la incertidumbre

Esta dimensión se refiere al "ancho de banda mental" de la organización. Pensemos: si el cerebro de los y las profesionales gasta su energía en sobrevivir al miedo o la duda, biológicamente no tiene recursos ni para innovar ni para pensar a largo plazo.

Pongamos un ejemplo típico. Imaginemos una empresa que anuncia una fusión o una reestructuración con la promesa de "ganar agilidad". Pasan los meses y nadie sabe cuál es exactamente su rol, si su responsable seguirá siendo su responsable o si su puesto peligra porque está duplicado.

La Dirección revisa los perfiles y piensa: "Tenemos al mejor talento del mercado, ¿por qué hay tanta resistencia y tan poca proactividad?".

No es un problema de actitud, es pura biología. El cerebro humano procesa la incertidumbre social como si fuera una amenaza física. Diferentes estudios e investigaciones tratan este tema y llegan a las siguientes conclusiones:

• El alto rendimiento colapsa sin seguridad psicológica (como demostró el famoso Proyecto Aristóteles de Google).
• Vivir bajo el estrés de la incertidumbre llega a reducir el Coeficiente Intelectual funcional en unos 13 puntos (según las investigaciones de Mullainathan y Shafir -Harvard/Princeton).

Añadamos, aunque no lo resolvamos aquí, el punto de cómo la IA puede ayudar o limitar la inteligencia humana y la incertidumbre que ello está generando.

¿Cómo superarlo?

Entendiendo la seguridad psicológica como una gestión de riesgos para proteger la inteligencia del equipo y no como un tema de "buenismo". Y sí, se puede medir, dando un paso más allá de los clásicos KPI de resultados, empezando a utilizar Key Behaviour Indicators (KBI): indicadores que miden conductas reales, como la frecuencia con la que el equipo reporta errores sin miedo (que conecta directamente con la seguridad psicológica) o la colaboración entre áreas… Así visualizamos qué nos hace tener éxito y que es necesario mejorar.

2 Barrera estructural: la trampa de la optimización local

Esta dimensión trata sobre cómo se diseñan las interacciones y los incentivos entre las cajas del organigrama, no sobre cómo se pintan esas cajas.

Imaginemos el clásico cierre de trimestre. La dirección comercial tiene un bonus por volumen de ventas. Por su parte, la dirección de tecnología/operaciones tiene su propio incentivo por estabilidad y reducción de costes. ¿El resultado? Ventas cierra contratos metiendo "customizaciones" complejas que implican mucho trabajo para llegar a su cuota. Mientras, Operaciones frena los despliegues o reduce “customizaciones” para reducir coste y conseguir sus objetivos.

El resultado es que ambos departamentos cumplen estrictamente sus objetivos o KPI individuales pero los clientes no tienen lo que esperaban, la empresa pierde dinero, los equipos derrochan tiempo y esfuerzo y, en conjunto, se dedica un tiempo inestimable a buscar culpables.

Como explicaba Russell Ackoff, es frecuente caer en esta trampa de la optimización local: cuando mejoras las piezas por separado, a menudo se acaba destruyendo el rendimiento del todo.

¿Cómo superarlo?

Rediseñando las interacciones: mientras los incentivos premien el silo vertical, las formas de trabajo colaborativas y las metodologías ágiles será difícil que funcionen. Aquí, el rol del C-Level tendrá que, entre otras funciones, rediseñar cómo interactúan las diferentes áreas y no tener en cuenta solo el performance de cada una de ellas de forma aislada.

Por tanto, se necesitan objetivos que impacten directamente en toda la empresa, haciendo que Ventas y Operaciones (en este caso) trabajen conjuntamente para conseguirlos. Objetivos compartidos con los que se gana (o se pierde) juntos.

3 Barrera del flujo: lo que no ves te está costando dinero

Esta dimensión se centra en la diferencia entre "gente ocupada" y "trabajo terminado".

Pongamos un escenario en el que si miras alrededor ves a todo el mundo sin parar, saturados de tareas: todas las agendas están llenas y la gente al 100% de capacidad. Sin embargo, una iniciativa clave tarda 12 meses en llegar al mercado. ¿Te suena?. Y claro, surge la pregunta “¿Cómo podemos tardar tanto con todo lo que se trabaja?".

La realidad es que el valor no se mueve cuando la gente trabaja; se mueve cuando el trabajo fluye. En la mayoría de empresas, las tareas pasan una parte importante del tiempo en "colas invisibles" (esperando presupuesto, esperando validación, esperando un entorno de pruebas…).

¿Cómo superarlo?

Utilizando Value Stream Management (VSM). Imaginémoslo como una capa de "Rayos X" que ignora la jerarquía y visualiza el flujo de trabajo y de información hasta convertirse en valor. Como indica Mik Kersten en Project to Product, al gestionar el flujo en lugar de los proyectos aislados, eliminas las esperas que ningún organigrama es capaz de mostrar.

Conclusión: del control a la arquitectura

Existe una inercia tradicional en el mundo empresarial: si algo falla, solemos culpar a las personas e intentamos "arreglarlas" metiéndolas más presión o formación. Pero W. Edwards Deming ya demostró con su Regla 94/6 que el 94% de los problemas pertenecen al sistema y solo el 6% al individuo.

Las organizaciones que lideran hoy el mercado, se dedican a "arquitecturar el entorno". Tener en cuenta los datos cálidos en procesos de cambio y optimización puede contribuir a pasos más robustos en la evolución de la organización.

¿Y qué significa "arquitecturar el entorno"?

Significa diseñar deliberadamente un ecosistema de trabajo donde “hacer lo correcto” sea lo más fácil. De esa forma:

• Se protege el intelecto colectivo (Neurociencia).
• Se alinean incentivos y formas trabajo para que se colabore (Sistemas).
• Se eliminan obstáculos para que el trabajo fluya (VSM).

Como señalan Skelton y Pais en Team Topologies, la ventaja competitiva no es para quien presiona más a sus equipos, sino para quien diseña mejores sistemas.

La pregunta que queda en el aire es: ¿estamos gestionando personas o estamos diseñando el sistema para el éxito?

Referencias

• PMI-The Economist (2013). Why good strategies fail: Lessons for the C-suite.
• CIO Magazine (April,2026).
• Google re:Work - Project Aristotle.
• Mullainathan, S., & Shafir, E. (2013). Scarcity: Why Having Too Little Means So Much.
• Ackoff, R. L. (1994). The Democratic Corporation. Oxford Univ. Press.
• Kersten, M. (2018). Project to Product. IT Revolution.
• Deming, W. E. (1986). Out of the Crisis. MIT Press.
• Skelton, M., & Pais, M. (2019). Team Topologies.

Esta es una noticia de las que cambian el juego, porque nos abre la puerta a customizar la inteligencia artificial de nuestras empresas sin tener que pasar por el calvario (y el coste) de entrenar modelos desde cero.

En este episodio, el equipo de Goodly al completo se reúne para analizar estos dos aliados que prometen jubilar las integraciones hechas "a pedal".

Poniendo orden al caos de las integraciones con MCP

Para entender dónde estamos, primero hay que mirar atrás. Pasamos de modelos encerrados en sí mismos a las famosas Function Calling y los RAG, pero seguíamos teniendo un problema: el crecimiento exponencial de integraciones tipo "M x N".

Si querías que tu IA hablara con diez sistemas, tenías que picar diez conectores distintos. El protocolo MCP, de Anthropic, llega para poner orden en este caos tecnológico, ofreciendo un marco estandarizado para que cualquier sistema pueda exponer sus herramientas a los agentes de IA de forma segura y reutilizable.

Skills en Gemini: definiendo capacidades con Markdown

Pero no todo es conectar cables, también hace falta saber qué hacer con ellos. Aquí es donde entran las Skills. Si el MCP son los ingredientes y las herramientas de cocina, la Skill es la receta detallada.

A través de un sencillo fichero Markdown, podemos darle a la IA capacidades específicas (como generar presentaciones corporativas siguiendo una plantilla o analizar informes financieros) sin sobrecargar el contexto del modelo.

Es, en esencia, un "salvar partida" de un flujo de trabajo que funciona, permitiendo que la IA sea mucho más determinista y eficiente.

Cómo encontrar el equilibrio perfecto entre MCPs y Skills

La gran pregunta que resolvemos en este episodio es: ¿cuándo usar cada uno? Aunque existe la tentación de "sobre-skilear" o convertirlo todo en MCP, la verdadera potencia reside en el equilibrio.

Hablamos de cómo empresas como Supabase ya están demostrando que combinar ambos mundos dobla la precisión y capacidad de los agentes. Además, hablamos de la portabilidad: cómo una misma Skill puede saltar de Cursor a Claude o Gemini casi sin despeinarse, dándonos una flexibilidad que hasta hace poco era ciencia ficción.

Orquestación inteligente: el futuro de la arquitectura en la nube

Como todo en este mundo de la IA, el secreto no está solo en la herramienta, sino en cómo orquestas el talento de tu nube.

No te pierdas este repaso por la "arqueología" y el futuro inmediato del cloud en el nuevo episodio de “Cómo conocí a nuestro cloud”.

¡Dale al play y actualiza tu arquitectura!

Más sobre el Google Next 2026

A pesar de usar una implementación mono hilo, Redis, el sistema de almacenamiento clave-valor en memoria de alto rendimiento, es conocido por su increíble velocidad.

¿Cómo es posible que Redis pueda gestionar cientos de miles de solicitudes por segundo? Antes que nada, hay que aclarar que Redis sí usa múltiples hilos, no es estrictamente un sistema monohilo.

Aunque es cierto que mantiene un hilo responsable del procesado de las peticiones de cliente y para el manejo de las estructuras de datos, Redis usa otros hilos de fondo para ejecutar otras tareas necesarias para su funcionamiento.

Entonces, ¿por qué es tan rápido?

• Redis mantiene todos los datos en memoria, favoreciendo la velocidad de acceso a los mismos.
• El uso de un sencillo modelo de datos clave-valor permite tener una complejidad O para las búsquedas de claves.
• El uso de multiplexación de E/S con E/S no bloqueante permite gestionar múltiples operaciones de E/S de forma eficiente.
• Uso de comandos simples que requieren poco uso de CPU.
• Uso de tipos de datos optimizados para operaciones en memoria.

Optimizaciones multihilo

• Asynchronous Memory Release: a partir de Redis 4.0, se introdujo el mecanismo de liberación diferida (lazy-free mecanismo) para liberar memoria de forma asíncrona. La liberación de memoria al eliminar claves de gran tamaño se realiza en un hilo en segundo plano.
• Multi-threading: podemos leer en el blog de Redis que “a partir de la versión 6.0, Redis hace uso de hilos de E/S para gestionar las peticiones de clientes, incluyendo sockets de lectura y escritura, y el parseo de comandos. Sin embargo, la implementación no llega a aprovechar al máximo las ventajas en cuanto a rendimiento.”

El uso de ejecución multihilo permite reducir la presión que se tiene en la ejecución monohilo de las peticiones entrantes en escenarios de alta concurrencia. Este proceso multihilo se aplica únicamente al análisis del protocolo de peticiones de datos, manteniendo la ejecución monohilo en el procesado de comandos y la manipulación de datos.

Con la publicación de Redis 8.0 llegó una nueva implementación E/S multihilo que anunciaba grandes mejoras en la transferencia de datos (entre el 37% y el 112%, según los datos publicados por Redis) en CPUs multinúcleo.

Probando la nueva implementación multihilo

Como ya hemos comentado, Redis procesa las peticiones en un único hilo, dividiendo la ejecución en los siguientes 4 pasos:

1. Lectura de la petición desde el socket
2. Análisis de la petición
3. Procesado de la petición, ejecutando las operaciones necesarias sobre los datos
4. Escritura de la respuesta en el socket

No se comenzará a procesar una nueva petición hasta que estos 4 pasos se hayan completado en orden para la petición actual.

La escritura de los resultados en el socket que se realiza en el paso 4 es típicamente una operación lenta en cuanto al tiempo necesario para completarla. Es en este punto donde podemos beneficiarnos de la nueva implementación multihilo de la E/S, configurando nuestro Redis para que ejecute las operaciones E/S en un nuevo hilo. De esta forma, Redis está en disposición de comenzar a procesar una nueva petición en paralelo, mejorando así el rendimiento.

La propiedad io-threads de Redis (esta propiedad es inmutable) será la que utilicemos para configurar la escritura multihilo en el socket. Recordemos que esta propiedad se inicializa a 1 por defecto, y que se usa para indicar el número de hilos máximo que se podrán crear para las escrituras en el socket.

También tenemos disponible la propiedad de configuración io-threads-do-reads en Redis que nos daría la posibilidad de usar ejecuciones multihilo en la lectura y análisis de peticiones desde el socket (pasos 1 y 2 descritos anteriormente). Esta opción, sin embargo, y de acuerdo a la información que dan desde Redis, no tiene un impacto significativo sobre el rendimiento.

Por tanto, vamos a centrarnos únicamente en el impacto que tiene la configuración de io-threads.

Tests sintéticos: ¿cómo se han ejecutado?

Herramienta de benchmarking

Para las pruebas se ha usado memtier_benchmark, una herramienta de benchmarking Open Source desarrollada por Redis Labs que integran en sus procesos de desarrollo, principalmente para hacer tests de no regresión y optimización de rendimiento.

memtier_benchmark fue presentada en el blog oficial de Redis y el proyecto está disponible en GitHub.

Nuestro Redis de pruebas

Vamos a usar un cluster Redis, desplegado en un Openshift Container Platform (OCP), con la siguiente configuración:

• Nodos del cluster: 5
• CPUs por nodo: 4
• Memoria por nodo: 4Gi

Usaremos 4 imágenes diferentes para montar los nodos, así podremos hacer una comparativa de rendimiento entre las distintas versiones:

• redis.redis-stack-server:7.2.0-v10 (imagen basada en la imagen oficial redis-stack-server en la que se habilitan algunos módulos)
• redis:7-bookworm (imagen oficial)
• valkey/valkey:8-bookworm (imagen oficial)
• redis:8-bookworm (imagen oficial)

Objetivos de los tests

Con la ejecución de estos tests perseguimos:

• Determinar el valor óptimo del parámetro de configuración io-threads.
• Decidir con qué sabor de Redis nos quedamos: el viejo y bien conocido Redis o el fresco y joven Valkey

Como hemos visto, podemos establecer cualquier valor por encima del valor por defecto de un hilo en el parámetro io-threads. Nos interesa ver el impacto en el rendimiento que tienen los cambios en esta configuración.

Por otro lado, sabemos que tras el anuncio que hizo Redis en el que se explicaba que dejaría de ser open source surgieron unos cuantos forks del proyecto. Tras revisar aquellos que habían tenido más actividad y que más habían crecido en número de contribuidores, decidimos limitar las pruebas a Valkey.

También nos interesa comparar el rendimiento de Valkey frente a las últimas versiones de Redis. Este último ha recibido muy buenos comentarios en cuanto a la mejora en términos de rendimiento desde la publicación de su versión 8.

Resultados de los tests

Cada test se comienza con un cluster Redis recién creado en un namespace concreto en nuestro OCP. Igualmente, se crea un pod nuevo desde el que se ejecutará la herramienta de benchmarking al comienzo de cada prueba.

Los valores utilizados para io-threads fueron: 1, 8, 12 y 16.

En la siguiente tabla se recogen los valores obtenidos en los distintos tests, mostrando la media de operaciones por segundo, para cada imagen y cada una de las configuraciones de io-threads.

Estos mismos datos en forma de gráfica:

Parece que el punto óptimo se sitúa en una configuración de io-threads correspondiendo a 2 veces el número de CPUs configuradas por nodo de Redis.

A partir de este valor vemos cómo el rendimiento se ve degradado en Valkey 8, mientras que Redis 8 mantiene un rendimiento estable si vamos más allá de este punto óptimo. Por tanto, los resultados de Redis 8 son más consistentes.

Como esperábamos, no se ha observado ninguna mejora de rendimiento en Redis 7 con el incremento de io-threads. Al contrario, nos ha sorprendido observar una degradación.

Redis 8 ha rendido mejor que Valkey 8 en todos los escenarios. Por tanto, nos quedamos con la regla de 2xCPU como configuración por defecto para io-threads y, en principio, la balanza se decanta, al menos por ahora, por el uso de Redis 8 como la imagen a usar para nuestros clusters de Redis.

Aplicando el conocimiento adquirido: optimización de recursos en un escenario real

El escenario: una aplicación desplegada en Kubernetes, haciendo uso intensivo de un cluster de Redis, requiriendo de tasas realmente altas de peticiones por segundo.

El cluster de Redis, en periodos de pico de uso de la aplicación se ha de escalar a 100 nodos para poder soportar el rendimiento requerido. Actualmente, este cluster está formado por nodos instanciados a partir de la imagen Redis Stack 7.2, con 1 CPU por nodo.

Nuestro objetivo es intentar reducir el número de nodos del cluster a la mitad, pasando de 100 a 50 nodos, usando la imagen Redis 8. Para ello, duplicaremos el número de CPUs por nodo, pasando de 1 a 2 CPUs, y estableciendo la configuración de io-threads en 4, como habíamos determinado, con el fin de beneficiarnos de las mejoras que ofrece la nueva implementación del I/O threading.

Para validar que la plataforma con esta nueva configuración es capaz de soportar el uso en periodos de pico, se usa un conjunto de tests complejos elaborados precisamente para someterla a cargas similares a las previstas en esos periodos y así poder validar que estamos en disposición de aguantar los periodos de demanda extrema.

Estos tests End-to-End (E2E) se han desarrollado a medida basándose en Spring Framework, haciendo uso del cliente de [Redis Lettuce(https://github.com/redis/lettuce).

Aprovechando la ventana de disponibilidad de la plataforma, se ejecutó la suite completa de tests con las siguientes configuraciones, para poder comparar los resultados:

• Redis Stack 7.2 - 100 nodos (1 CPU)
• Redis 8 - 50 nodos (2 CPU)
• Valley 8 - 50 nodos (2 CPU)

Aprovechamos que el Operador de Redis desarrollado para gestionar todos los clusters de Redis (actualmente liberado como Open Source) despliega, junto a los pods del propio cluster, un pod encargado de extraer una gran cantidad de métricas y las expone para poder ser recuperadas por Prometheus, junto a las métricas propias de Kubernetes, y mostradas en un panel en Grafana.

Pasemos a revisar los resultados obtenidos.

Comandos procesados

Vemos como el cluster montado con Redis 8 aprovecha la ventaja de la configuración de io-threads y la nueva implementación, llegando prácticamente a alcanzar el número de comandos por unidad de tiempo del cluster de referencia con Redis Strack 7.2. Vemos que cada nodo prácticamente llega a duplicar el número de comandos procesados por unidad de tiempo respecto a los valores de Redis Stack 7.2.

Valkey 8 presenta un comportamiento similar a Redis 8. Lamentablemente, al comienzo del test se produjo el desalojo de el pod de uno de los nodos, lo que explica la pequeña caída que se aprecia en la gráfica.

Hits

El mismo comportamiento que vimos en los comandos procesados por unidad de tiempo se repite en el número de hits. Se llega casi a alcanzar el rendimiento de referencia de Redis Stack 7.2 con la mitad de nodos tanto en Redis 8 como en Valkey 8.

Para dar una idea de la cantidad de datos que se manejan durante los tests, se incluyen las siguientes gráficas que muestran el número de keys almacenadas por nodo.

Cache entries

Si echamos un vistazo al uso de CPU, vemos resultados más consistentes en Redis 8 que en Valkey 8.

CPU usage

Para finalizar la comparativa de las métricas obtenidas, echemos un vistazo a la tasa de transferencia de salida de red de los nodos.

Network out throughput

Conclusiones finales

La nueva implementación de I/O threading incluida en Redis 8 y Valkey 8 realmente marca la diferencia con las antiguas implementaciones. Haciendo uso de múltiples hilos para hacer la escritura de los resultados de los comandos al socket se alivia significativamente la carga en el hilo principal, permitiendo un incremento impresionante del rendimiento por nodo.

De los datos de los tests podemos extraer que se ha alcanzado una mejora de rendimiento del 90-95%.

Usando Redis 8, con las mejoras que introduce y, sobre todo, con la implementación de I/O Threading, podemos llegar a una reducción considerable de recursos. Tras las pruebas pudimos pasar los periodos de pico con la mitad de nodos por cluster, subiendo la CPU de 1 a 2.

Si nos basamos únicamente en las métricas de Redis aquí expuestas (y algunas más que no se han incluido por no resultar tan interesantes) Redis 8 y Valkey 8 presentan rendimientos muy similares. Sin embargo, también revisamos logs y métricas de la aplicación cliente. En estas observamos que Redis 8 se comportó de forma más estable que Valkey 8. Consiguió mantener tasas de transferencia durante todos los tests más estables, mientras que Valkey 8 mostró algunas fluctuaciones.

Redis 8, tras su vuelta al mundo Open Source, ha demostrado un rendimiento impecable. También ha mostrado tener un mayor nivel de optimización, además de comportarse más estable y más consistente antes las distintas configuraciones de io-thread.

Por todo esto, nos quedamos con Redis 8, al menos por ahora.

Referencias

• Redis 8.0-M03 is out. Even more performance & new features, Blog de Redis
• memtier_benchmark: A High-Throughput Benchmarking Tool for Redis & Memcached, Blog de Redis
• Github RedisLabs
• Github Redis Lettuce

¿Qué cambia, para quién cambia y cómo sabremos que ha cambiado?

Cuando eso no está claro, suele pasar que hemos arrancado con energía, el backlog crece, entregamos cosas… y a las pocas semanas alguien pregunta: “vale, ¿y esto para qué era?” Y no suele ser un problema de esfuerzo, sino un problema de enfoque.

Para mí, la mentalidad de producto no va de roles, ceremonias o herramientas. Se trata de poner el foco en tres cosas antes de lanzarnos a construir: qué problema queremos resolver, para quién y qué valor esperamos generar.

El error más habitual es arrancar por el “qué”. Las primeras conversaciones giran alrededor de lo que hay que construir, los entregables que se esperan, para cuándo, quién lo hace y dónde lo seguimos. Son preguntas válidas. El problema es que, si arrancamos así, corremos el riesgo de organizarnos en torno a la ejecución de algo que quizá no era lo más importante.

Por eso, antes de bajar a la operativa, conviene aterrizar el propósito, el usuario y el valor con estas preguntas:

• ¿Por qué hacemos esto? ¿Qué problema estamos intentando resolver?
• ¿Quién es el usuario real?
• ¿Qué mejora esperamos ver y cómo la vamos a notar?

Si esto no está claro, bajar al backlog demasiado pronto no nos va a ayudar. Esto sucede con frecuencia con iniciativas que ya llegan formuladas de esta forma:

• “Necesitamos un dashboard.”
• “Hay que automatizar este proceso.”
• “Queremos una nueva pantalla.”

Ahí el riesgo es aceptar la solución sin haber entendido bien la necesidad. Pasa, por ejemplo, con peticiones como esta: “automatizar la aprobación de solicitudes”. Hasta ahí, lo que tenemos es una solución. La conversación útil empieza cuando preguntas: “vale, ¿para qué?”. Y entonces aparece el problema real: reducir tiempos de respuesta y evitar errores. A partir de ahí ya puedes concretar mejor:

• Usuario: el equipo operativo que gestiona las solicitudes y el cliente final que sufre las esperas.
• Valor esperado: pasar de 5 días a 24 horas y reducir retrabajo.
• Decisión: quizá antes de automatizar es recomendable eliminar validaciones redundantes, aclarar criterios y definir excepciones.

La necesidad de fondo no ha cambiado. Lo que cambia es la calidad de la decisión.

Producto es el compendio de propósito, usuario y valor

Cuando hablamos de producto, para mí hay tres elementos que no pueden faltar: propósito, usuario y valor. Si falta uno de estos tres, es fácil caer en una dinámica peligrosa donde trabajamos mucho pero con un impacto difuso.

• Sin usuario, el valor se vuelve abstracto: no sabemos para quién estamos mejorando algo ni qué cambio queremos provocar. Y esto aplica también cuando el usuario es interno. Que el usuario esté en Operaciones, Tecnología, Riesgos o Finanzas no cambia nada de fondo: también ahí hay que concretar quién es, qué fricción tiene y qué mejora sería realmente valiosa para esa persona.
• Sin valor, el usuario se queda en una descripción vacía. En este post no vamos a entrar en detalle en qué se entiende por valor, pero sí quiero aclarar que cuando hablo de valor, no me refiero solo a negocio. Puede aparecer en varias capas, ya sea:
  • Valor para el usuario: menos fricción, más claridad, menos esperas, menos errores.
  • Valor para el negocio: más adopción, menos coste, menos riesgo, mejor conversión.
  • Valor para el sistema de entrega: más calidad, más estabilidad, menos retrabajo, menos urgencias artificiales.
• Sin propósito, todo suena razonable, pero cuesta priorizar. Aquí hay una distinción que me parece útil y que conecta con el Círculo Dorado de Simon Sinek: no es lo mismo hablar del porqué que del para qué. El porqué habla del propósito de la iniciativa. El para qué aterriza ese propósito en impacto, en el cambio que queremos provocar.

Lo importante es que algo cambie de forma observable. Si no cambia nada visible, probablemente no estamos generando valor; únicamente estamos haciendo cosas.

Una buena pregunta para aterrizarlo es: ¿Qué mejora real se producirá para el usuario si esto funciona?

Cómo aterrizar esto en el día a día

1. Arrancar por problema y valor, no por entregable.

Antes de hablar de solución, deja claro qué dolor quieres resolver, para quién y qué mejora esperas ver. Herramientas como una Inception bien enfocada ayudan justo a eso: alinear propósito, usuario, valor y cómo sabremos si vamos bien.

Para ese arranque ayuda de forma sustancial dejar por escrito algo tan simple como:

• Nuestro objetivo: estamos aquí para...
• El problema actual: hoy en día pasa que...
• A quién afecta: esto afecta sobre todo a...
• Lo que esperamos: si todo va bien, debería cambiar...
• Cómo lo sabremos: lo notaremos porque veremos...

No lo veas como burocracia. Tómalo como una manera de alinear mejor y de evitar que el backlog se convierta en lista de tareas.

2. Conectar estrategia, foco y backlog.

Si una iniciativa no está conectada con una prioridad real, el backlog acaba lleno de trabajo, pero no necesariamente de valor. Por eso conviene enlazar bien estrategia, priorización y roadmap.

3. Traducir intención en seguimiento real.

Si dices que buscas impacto, luego tienes que revisarlo. Y ahí ayuda formular bien los objetivos y acompañarlos de resultados observables, sin confundir actividad con impacto. Para eso, puedes complementar bien con el uso de OKRs, prestando atención a sus anti-patrones.

En conclusión

Trabajar con mentalidad de producto va de tomar mejores decisiones desde el principio. La próxima vez que arranques una iniciativa, yo me pararía un minuto en estas tres preguntas:

• ¿Qué valor concreto queremos generar?
• ¿Para quién, exactamente?
• ¿Y cómo sabremos que lo estamos consiguiendo?

Porque el valor no aparece al final. Se decide desde el inicio y se revisa durante el camino.

Tu backlog no debería demostrar que trabajas. Debería demostrar que estás cambiando algo valioso para alguien. ¡Te leo en comentarios! 👇

Las compañías ya no solo tienen que garantizar que sus productos funcionen bien, sino también que sean sostenibles, medibles y alineados con nuevas exigencias regulatorias y sociales.

En este contexto surge Green QA, un enfoque que amplía el concepto tradicional de calidad incorporando variables como la eficiencia energética, la huella de carbono y la trazabilidad ambiental del software.

Más allá del testing: qué es Green QA y por qué importa

Green QA parte de una idea sencilla pero potente: no basta con validar que un sistema funciona, también hay que entender cómo se ha construido y qué impacto ha generado en el proceso.

Tradicionalmente, los equipos de calidad se han centrado en verificar entregables. Pero rara vez se ha tenido en cuenta el coste energético de ejecutar pruebas, el consumo de infraestructura o la huella de carbono asociada a todo el ciclo de desarrollo. Green QA introduce precisamente esa capa de conciencia.

Este cambio no es solo conceptual, también responde a dos grandes fuerzas. Por un lado, el creciente peso de la regulación, con normativas como la directiva europea CSRD o las leyes nacionales de sostenibilidad empresarial.

Por otro lado, la propia competitividad del mercado: las empresas que integran sostenibilidad en su ciclo de desarrollo no solo cumplen, también se diferencian.

ESG y software: una relación cada vez más directa

El auge de los criterios ESG (Environmental, Social & Governance) ha llevado a las empresas a medir su impacto más allá de lo financiero. En este marco, Green QA se convierte en una pieza clave para trasladar esos principios al desarrollo de software.

Desde el punto de vista ambiental, permite medir y optimizar aspectos como el consumo energético de servidores o la eficiencia del código. En la dimensión social, introduce variables como la accesibilidad o la ética en el uso de datos.

Y en el ámbito de la gobernanza, aporta trazabilidad, auditoría y cumplimiento normativo en los procesos de desarrollo. En otras palabras, Green QA traduce los principios ESG en métricas técnicas accionables dentro del ciclo de vida del software.

Este enfoque está redefiniendo profundamente el papel del QA. Ya no se trata solo de probar más, sino de probar mejor.

Uno de los cambios más relevantes es el paso de un testing exhaustivo a un testing contextual. Ejecutar todas las pruebas posibles ya no es siempre la mejor opción, especialmente si implica un coste energético elevado. En su lugar, se busca optimizar qué se prueba, cuándo y cómo.

Además, aparecen nuevos indicadores en los cuadros de mando: la eficiencia energética pasa a ser un KPI más, junto a los tradicionales de calidad o rendimiento. También cobra importancia la gestión del “desperdicio digital”, es decir, el uso innecesario de recursos en automatizaciones, datos o infraestructuras.

A esto se suma un cambio cultural: la sostenibilidad debe integrarse desde el inicio del desarrollo, no añadirse al final como una capa adicional.

Impacto real en el ciclo de vida del software

Green QA no es una teoría, es un enfoque con impacto tangible en todas las fases del desarrollo. Desde la validación, donde ya no solo se verifica el funcionamiento sino también el impacto ambiental, hasta el diseño del código, que se optimiza para ser más eficiente y mantenible.

Un código más limpio no solo es más fácil de entender, sino que reduce costes y consumo a largo plazo.

También influye en la infraestructura, promoviendo entornos temporales y bajo demanda frente a sistemas permanentemente activos. Incluso en la gestión de datos, donde se pone el foco en eliminar información innecesaria que consume recursos sin aportar valor.

Un dato ilustrativo: almacenar información sin uso durante días puede tener un impacto energético comparable al de mantener dispositivos encendidos de forma continua. El software también consume, aunque no siempre lo veamos.

Medir para mejorar: las nuevas métricas de la calidad sostenible

Uno de los grandes retos de este enfoque es la medición. Sin embargo, cada vez existen más herramientas que permiten cuantificar el impacto del software.

Algunas de las métricas que empiezan a cobrar relevancia incluyen el consumo energético por ciclo de pruebas, las emisiones de CO₂ por despliegue o la eficiencia en el uso de CPU y memoria. Estos datos permiten detectar anomalías, optimizar procesos y tomar decisiones informadas.

Lo importante no es solo medir, también hacerlo de forma continua y automatizada, integrando estas métricas en los pipelines y en los sistemas de observabilidad del proyecto.

Cómo empezar: de la conciencia a la estrategia

Adoptar Green QA no ocurre de un día para otro. Requiere un proceso progresivo que comienza con la formación y la concienciación de los equipos. En una primera fase, muchas organizaciones ni siquiera son conscientes del impacto ambiental de sus procesos de testing. A medida que avanzan, empiezan a identificar recursos, incorporar métricas y definir procesos más eficientes.

El siguiente paso es la estandarización, con KPIs claros y prácticas sostenibles integradas en el día a día. Posteriormente, se alcanza un nivel en el que la medición es continua y automatizada, y finalmente, las compañías más maduras alinean completamente su estrategia de software con los objetivos ESG.

Green QA representa un cambio profundo en la forma de entender la calidad. Ya no se trata solo de entregar software que funcione, sino de hacerlo de manera responsable, eficiente y alineada con el entorno: la sostenibilidad no es un coste añadido, es una oportunidad para ser más eficientes, reducir gastos y mejorar la competitividad.

En un contexto donde la tecnología es responsable de una parte creciente del consumo energético global, integrar este enfoque no es solo una ventaja estratégica: empieza a ser una necesidad.