Del 22 al 24 de abril, el mundo cloud mirará hacia Google para ver qué cartas tiene bajo la manga. En este episodio de "Cómo conocí a nuestro cloud", nos mojamos y abrimos la veda de las predicciones para adivinar qué veremos en el evento más importante del año para el ecosistema de Google Cloud.

Escucha aquí el episodio.

Tras un año marcado por la consolidación de Gemini 3 y la resaca de la fiebre de la IA generativa, la gran pregunta es si este Next servirá para afianzar el dominio de Google o si seguiremos en una fase de "anuncios en preview".

Analizamos la agenda del evento y los datos son claros: la IA sigue devorándolo todo. Con apenas un 10% de sesiones que no mencionan palabras como GenAI o Gemini, parece que la infraestructura tradicional ha quedado relegada a ser el soporte silencioso de la inteligencia artificial.

Debatimos sobre el futuro de los protocolos de integración, con el dilema entre cuándo usar MCPs y cuándo usar A2A, y cómo la incertidumbre tecnológica está frenando la adopción masiva en el mundo enterprise.

También ponemos el foco en el hardware: ¿veremos una nueva versión de las TPUs (Ironwood) que logre romper el monopolio de NVIDIA? Además, exploramos la necesidad de que Google "cierre el círculo" integrando de verdad la IA en el flujo de trabajo diario de Workspace, para que generar una presentación de slides deje de ser una batalla contra imágenes estáticas.

Para terminar, no podíamos cerrar sin nuestra clásica sección de triples. Desde apuestas arriesgadas por el mundo multimedia y la generación de mundos, hasta la posible explosión de Project Astra o la integración total de conectores externos en la App de Gemini.

¿Cuántos de nuestros vaticinios se harán realidad? No te pierdas esta tertulia con la "aristocracia" del programa: José Berenguer, Andrés Navidad, Óscar Ferrer y Tomás Calleja.

Como todo en la nube, el Next promete emociones fuertes y algún que otro suflé que puede desinflarse.

¡Escucha el episodio completo y prepárate para el evento del año!

Sin embargo, para el perfil de Manager/Scrum Master/ Flow Master que busca no solo organizar tareas, sino garantizar la excelencia técnica y la sostenibilidad del equipo, pasar por alto XP es un error estratégico. Mientras otros marcos se centran en el flujo de gestión, XP pone el foco en la trinchera, en cómo se construye el producto para que sea robusto, flexible y rentable.

¿Qué es XP?

Si nunca has profundizado en XP, piensa en ello no como una invención radical, sino como una recopilación de aquello que funciona. Del mismo modo que J.R.R. Tolkien no inventó los mitos de elfos y enanos, sino que recopiló y sistematizó siglos de folclore europeo para crear una mitología coherente y funcional, Kent Beck hizo lo mismo con la ingeniería de software a finales de los ‘90.

Beck no inventó las pruebas, ni la revisión de código, ni la comunicación con el cliente. Lo que hizo XP fue recopilar estas "buenas prácticas" aisladas, que la industria ya sabía que mejoraban la calidad, y llevarlas al extremo de su efectividad, ordenándolas bajo un criterio unificado.

A parte de la excelencia en las buenas prácticas técnicas, en XP también destacó la importancia de tener lo que hoy entendemos por Product Owner presencialmente junto al equipo (on-site customer) para mejorar la conversación entre negocio y desarrollo (en aquel momento denominado “cliente”). Además, una de las aportaciones de XP al Agilismo, y la que tal vez sea la más recordada, son las Historias de Usuario tal y como las conocemos hoy (con las 3 C’s) para tumbar los requisitos pesados y difíciles de entender por el Dev Team.

En definitiva XP es un marco diseñado para reducir el riesgo en proyectos con requisitos vagos o cambiantes aplicando buenas prácticas técnicas, favoreciendo la comunicación entre las partes y descartando aquello que no se necesita en este momento. En resumen: priorizando la satisfacción del cliente y la calidad del software.

Hasta aquí el resumen rápido de lo que es XP para aquellos que no fueron a clase ese día.
Pero cuidado: creer que XP es solo esto (un puñado de buenas prácticas de programación) es como leer la siguiente sinopsis: "es la historia de una familia disfuncional en el espacio" y creer que ya conoces la saga de Star Wars.

Lo que esa sinopsis omite es el verdadero valor para quien lidera el equipo. XP es un sistema de gestión de riesgos y seguridad psicológica.
XP asume que la agilidad sin excelencia técnica acaba convirtiéndose en una fábrica de deuda técnica. Por eso, crea una red de seguridad inquebrantable (a través de pruebas automatizadas, integración continua y diseño simple) que garantiza que el equipo pueda ir rápido, adaptar cambios constantes y no sufrir burnout en el proceso. Es la garantía de que la velocidad no destruya la calidad.

Y es precisamente este dilema entre velocidad y seguridad el que nos golpea de lleno en la actualidad.

Hoy tenemos en nuestras manos el mayor acelerador de producción de la historia: la Inteligencia Artificial Generativa. Pero generar código a una velocidad vertiginosa no es lo mismo que generar código mantenible o correcto. ¿Cómo gobernamos esta nueva hiper-velocidad sin quemar al equipo ni romper el producto? La respuesta lleva casi 30 años inventada.

Una nueva esperanza: evolucionando XP con Inteligencia Artificial

¿Cómo encaja este marco de los ‘90 en la era de la IA Generativa? La realidad es que la irrupción de la IA no hace que XP sea obsoleto, al contrario, lo convierte en la estructura de seguridad necesaria para esta nueva velocidad. Estamos ante el nacimiento del AI-XP (término usado por Justin Beall).

La integración de la IA en XP no es solo usar herramientas de autocompletado, es una evolución sistémica que potencia los principios originales del marco a través de tres bucles de retroalimentación modernizados. Según Justin Beall, estos bucles son:

1. VISION (Planificación). Donde antes dependíamos solo de la intuición humana para definir objetivos a largo plazo, ahora la IA puede analizar datos de mercado para alinear el "Planning Game" de XP con necesidades reales y predicciones de tendencias.
2. ADAPT (Iteraciones ágiles). La IA actúa como un facilitador que mejora la capacidad de respuesta. Puede ayudar a descomponer historias de usuario complejas y asegurar que todo el equipo entienda los criterios de aceptación, eliminando la ambigüedad en la comunicación.
3. LEAP (Ejecución diaria). Aquí es donde la práctica clásica del Pair Programming evoluciona hacia el "AI Pairing". La IA asume las tareas rutinarias y de generación de código base, permitiendo que la persona de desarrollo, que llamaremos "navegante", se centre en la estrategia, la seguridad y el diseño.

Las nuevas paradojas del AI-XP

Antes de cantar victoria y asumir que la IA más las prácticas de los '90 resolverán todos nuestros problemas, como líderes técnicos y de gestión debemos pararnos a reflexionar. La adopción de este nuevo modelo trae consigo paradojas e incertidumbres que cambiarán las reglas del juego:

• La paradoja de las historias de usuario

En su origen, XP nos liberó de los tediosos documentos de requisitos de cientos de páginas creando las historias de usuario (promesas de una conversación escritas en un par de líneas). Sin embargo, hoy, para que un modelo de IA no alucine y genere código útil, necesitamos nutrirlo con un contexto profundísimo (SPECs hiper-detalladas, prompts exhaustivos, reglas de negocio escritas). ¿Estamos volviendo a la era de la hiper-documentación técnica solo para que la máquina nos entienda? El reto será que el exceso de especificaciones para la IA no mate la conversación entre humanos.

• La redefinición del "equipo híbrido"

Hace apenas un par de años, el gran debate en el management era cómo gestionar equipos híbridos, refiriéndonos exclusivamente a la dicotomía entre trabajo presencial y 100% remoto. Hoy, el concepto ha mutado radicalmente: un equipo híbrido moderno es el formado por mentes humanas y agentes de Inteligencia Artificial. Gestionar la confianza, las expectativas y el flujo de trabajo en esta nueva convivencia es el verdadero desafío del Agile Coach de esta década.

• La IA como el nuevo "silo de conocimiento"

XP promovía la Propiedad Colectiva del Código para evitar que el conocimiento residiera en una sola persona (el temido "bus factor"). Pero, ¿qué ocurre si la IA escribe la mayor parte de la base de código y los equipos de desarrollo se limitan a hacer aprobaciones rápidas? Corremos el riesgo de convertir a la IA en una "caja negra", perdiendo el control y la comprensión profunda de nuestro propio producto.

Retorno a la humanidad

Como conclusión, la IA tiene el potencial de acelerar la producción de software, pero también de acelerar el caos si no hay gobierno, y XP proporciona ese gobierno. Al automatizar la complejidad técnica y la generación de código rutinaria, la IA permite que XP cumpla su promesa original más ambiciosa: humanidad y respeto.

Al liberarnos de la tarea mecánica de "picar código" repetitivo, los equipos pueden centrarse en lo que XP siempre valoró más: la creatividad, la resolución de problemas complejos y la colaboración humana de alto valor. XP no ha muerto, simplemente ha encontrado, treinta años después, la herramienta perfecta para alcanzar su máximo potencial.

En este post os quiero enseñar cómo diseñé un pipeline de NLP para atacar este problema. No es solo "meter IA por meter", sino crear un flujo lógico que clasifica, extrae y limpia la información por nosotros. Lo bueno de este enfoque es que, con un par de ajustes, te sirve igual para riesgos que para clasificar tickets de soporte o contratos legales.

Lo que vamos a construir hace cuatro cosas clave:

• Prioriza. ¿Esto es un incendio o un aviso rutinario?
• Etiqueta. ¿Es fraude, un fallo técnico o un tema legal?
• Detecta datos. Saca IPs, cuentas, correos... lo "duro".
• Entiende el contexto. Identifica qué leyes o empresas se mencionan.

La arquitectura del flujo (Keep it simple)

No hace falta complicarse la vida con modelos gigantes para todo. Aquí combinamos lógica de negocio (reglas) con modelos estadísticos.

El flujo es este:

Documento bruto → Clasificador de Urgencia → Etiquetado de Riesgos → Extractor de Datos Técnicos → NER (Entidades) → JSON Estructurado.

Un caso real para probarlo

Para que no sea todo teoría, vamos a usar este aviso de incidencia (me lo he inventado, pero es muy parecido a lo que te podrías encontrar en un sistema real):

ALERTA DE RIESGO OPERACIONAL - ID-2026-00142 Se ha detectado un fallo crítico en el sistema de procesamiento de transacciones... afecta a tarjetas de crédito. Empezó a las 14:23 UTC y afecta a unos 15.000 clientes. Datos: IP 192.168.1.50 | Error: ERR-DB-TIMEOUT | TXNs: TXN-A7B3C9D2, TXN-F4E8A1B6. Ojo: Supera el umbral del 0.5% de la MiFID II. Hay que avisar a la CNMV.

Clasificando la quemazón: criticidad

Lo primero es saber si tenemos que mandar un mensaje al jefe o si puede esperar a mañana. Para esto, usamos un sistema de pesos. Si aparecen palabras como "sanción" o "fraude", el score sube como la espuma.

class CriticalityClassifier:
    def __init__(self):
        # Aquí definimos qué nos quita el sueño
        self.keywords_critico = {'fraude': 10, 'pérdida': 10, 'incumplimiento': 10, 'multa': 10}
        self.keywords_alto = {'riesgo': 7, 'alerta': 6, 'fallo': 5}
        # ... (otros niveles)

    def _calculate_scores(self, text: str):
        text_lower = text.lower()
        # Sumamos puntos según lo que encontremos
        return {
            'critico': sum(w for k, w in self.keywords_critico.items() if k in text_lower),
            'alto': sum(w for k, w in self.keywords_alto.items() if k in text_lower),
            # ...
        }

Resultado: en nuestro ejemplo, nos daría un nivel ALTO con una confianza del 57%. Suficiente para disparar una alerta automática.

¿De qué estamos hablando? (Categorías)

Un documento puede ser de varias cosas a la vez. Por ejemplo: tecnológico (caída de servidor) y cumplimiento (incumplimos una norma). He usado patrones de Regex precompilados porque, sinceramente, para palabras clave específicas son mucho más rápidos y baratos que una red neuronal.

# Un pequeño mapa de qué buscar para cada riesgo
self.category_keywords = {
    'operacional': ['fallo', 'error', 'caída', 'incidencia técnica'],
    'cumplimiento': ['normativa', 'sanción', 'cnmv', 'mifid'],
    'ciberseguridad': ['ataque', 'malware', 'hackeo', 'brecha']
}

Extracción de "hilos" técnicos

Aquí es donde el NLP brilla ahorrando tiempo. En lugar de que un analista copie y pegue las IPs o los códigos de error, dejamos que las expresiones regulares hagan el trabajo sucio.

Sacamos a la vez:

• IPs: 192.168.1.50
• IDs de transacción: TXN-A7B3C9D2
• Emails: incidencias@banco-ejemplo.com

NER. ¿Quién es quién?

Para extraer entidades (organizaciones, leyes, productos), uso spaCy. Es la navaja suiza para esto. Le añadimos un diccionario personalizado porque spaCy sabe qué es una "persona", pero a veces le cuesta entender qué es la "MiFID II" o la "CNMV" si no se lo decimos.

# Combinamos spaCy con nuestras propias reglas de dominio
self.custom_entities = {
    'normativas': ['mifid ii', 'gdpr', 'pci dss'],
    'organismos': ['cnmv', 'bce', 'banco de españa']
}

El resultado final: JSON

Al final, el pipeline nos escupe algo así de limpio:

{
  "criticality": "alto",
  "categories": ["operacional", "cumplimiento", "tecnológico"],
  "indicators": {
    "ipv4": ["192.168.1.50"],
    "error_code": ["ERR-DB-TIMEOUT"]
  },
  "entities": {
    "normativas": ["MiFID II"],
    "organismos": ["CNMV"]
  }
}

¿Esto escala?

Si lo lanzas de forma secuencial, te puede dar el sueño. Pero usando ThreadPoolExecutor en Python, he conseguido procesar unos 1.500 documentos por minuto. Para la mayoría de empresas, eso sobra para procesar todo el flujo de entrada en tiempo real.

• Métricas reales:
• Latencia: 38ms (vuela).
• Precisión: ~95% (el 5% restante suele ser lenguaje muy ambiguo que requiere ojo humano).

Conclusión

Automatizar esto no es solo por ahorrar costes, es por reacción. Si un sistema detecta un incumplimiento normativo en 40 milisegundos, puedes mitigar el riesgo antes de que se convierta en una multa millonaria.

¿Qué opináis? ¿Meteríais modelos más pesados tipo Transformer (BERT/LLMs) o creéis que para clasificación de riesgos este enfoque híbrido es más estable? Os leo en comentarios.

Hoy es difícil encontrar un equipo técnico que no utilice asistentes como GitHub Copilot, Cursor o modelos conversacionales como Claude para acelerar tareas, resolver dudas o construir fragmentos de código con mayor rapidez.

La promesa inicial se ha cumplido en buena medida: escribir código es hoy más rápido que hace apenas dos años. Sin embargo, cuando el desarrollo sale del terreno individual y entra en el contexto de una gran organización, aparecen límites muy claros.

Porque una cosa es generar código que funciona y otra muy distinta generar código que encaja dentro de una arquitectura empresarial compleja, respeta estándares internos y sigue reglas técnicas que muchas veces no están escritas en un prompt.

Ese es precisamente uno de los grandes debates actuales en torno al llamado vibe coding: la idea de interactuar con la IA de forma casi conversacional, describiendo lo que se necesita y dejando que el modelo complete el resto.

En proyectos pequeños o prototipos rápidos puede resultar extremadamente eficaz, pero en sistemas corporativos con años de evolución, múltiples equipos y dependencias cruzadas, el contexto local ya no basta.

El problema de fondo es que estos asistentes trabajan, en la mayoría de los casos, con una visión parcial del sistema. Ven el archivo abierto, algunas referencias cercanas y las instrucciones inmediatas del desarrollador/a, pero no tienen acceso real a la fotografía completa de la organización: ni conocen las librerías aprobadas, ni distinguen qué patrones arquitectónicos son obligatorios, ni saben qué decisiones previas condicionan una implementación concreta.

Por eso, uno de los riesgos más frecuentes es que la IA produzca código técnicamente correcto, pero incompatible con el ecosistema real de la compañía.

Puede introducir dependencias no autorizadas, repetir soluciones ya resueltas internamente o romper convenciones críticas de diseño. A medida que crece el tamaño del sistema, también crece la entropía del software generado si no existe una guía estructurada.

En ese punto, la conversación deja de ser puramente sobre productividad y pasa a ser una cuestión de gobernanza tecnológica.

Del prompt aislado al conocimiento corporativo estructurado

La respuesta que muchas organizaciones están empezando a explorar consiste en dejar de tratar la IA como un simple asistente conversacional y empezar a integrarla dentro de una arquitectura de conocimiento empresarial.

Aquí es donde aparecen conceptos como RAG, MCP y SDD, tres piezas que juntas cambian completamente el enfoque.

El primero, Retrieval-Augmented Generation o RAG, permite que el modelo no dependa únicamente de su entrenamiento general, sino que consulte conocimiento interno antes de responder. Pero no basta con almacenar código sin más. La diferencia real aparece cuando ese conocimiento se organiza con jerarquía.

No todo el código tiene el mismo valor. Hay documentación, librerías comunes, aplicaciones históricas y, sobre todo, proyectos de referencia que representan cómo debe hacerse realmente una implementación dentro de la organización.

La IA necesita distinguir entre cualquier fragmento heredado y aquello que verdaderamente define el estándar interno.

Ese conocimiento estructurado es lo que permite que una respuesta deje de ser genérica y pase a parecerse al modo real de construir software dentro de una compañía.

MCP: el estándar que conecta la IA con el ecosistema real de desarrollo

La segunda pieza es MCP, un protocolo que está ganando protagonismo porque resuelve uno de los grandes problemas actuales: cómo conectar modelos de IA con herramientas corporativas sin crear integraciones frágiles.

En lugar de enlazar cada modelo con cada sistema interno de forma individual, MCP actúa como una capa estándar de conexión. Eso permite que distintos modelos puedan consultar las mismas fuentes sin depender de integraciones duplicadas.

En la práctica, esto significa que un modelo puede consultar información funcional de Jira, recuperar ejemplos del repositorio interno, acceder a convenciones por lenguaje o framework y mantener sesiones de trabajo consistentes sin que importe demasiado si detrás está Claude, GPT o cualquier otro modelo.

La clave no es solo conectar herramientas, sino desacoplar el conocimiento del modelo concreto que se esté utilizando.

Eso aporta algo especialmente valioso en entornos corporativos: flexibilidad tecnológica sin rehacer toda la arquitectura cada vez que cambia el modelo dominante.

El gran cambio: dejar de pedir código y empezar pidiendo intención

Donde realmente cambia el paradigma es en el flujo de trabajo. En el enfoque tradicional de asistentes, el/la desarrollador/a abre el IDE, redacta una instrucción y espera código.

Todo ocurre dentro de una conversación más o menos sofisticada. Pero cuando se trabaja con especificaciones guiadas, el proceso empieza antes del código.

Lo primero no es generar una implementación, sino una propuesta de cambio. A partir de una necesidad funcional o de una historia de usuario, el sistema construye una cadena de artefactos: especificaciones, diseño técnico, escenarios concretos y tareas de implementación. La IA deja de improvisar y empieza a trabajar sobre una intención formalizada.

Esto tiene una consecuencia importante: el contexto deja de depender de una conversación efímera y pasa a convertirse en un activo persistente.

Uno de los grandes límites del llamado context engineering es precisamente su fragilidad. Cada desarrollador/a construye manualmente el contexto que entrega al modelo, decide qué archivos incluir, qué ejemplos mostrar y qué instrucciones reforzar. Ese contexto desaparece cuando termina la sesión y no deja rastro verificable.

Además, cuando el volumen crece demasiado, aparece un fenómeno cada vez más conocido: la saturación de contexto. El modelo empieza a priorizar unas señales sobre otras, atiende menos a ciertas restricciones y pequeños ajustes pueden desalinear requisitos previamente bien resueltos. La IA no se vuelve inconsistente por azar: simplemente compite por atención dentro de una ventana finita.

Por eso el enfoque basado en especificaciones gana fuerza. Porque las specs se convierten en el verdadero contexto: estructurado, persistente, versionado y auditable.

Cuando el código no es la única fuente de verdad

En este modelo, el código ya no es el único artefacto importante. Cada decisión queda acompañada de su intención original, su diseño técnico y su validación funcional. Si algo cambia, no se corrige directamente el código: se actualiza la especificación y la implementación evoluciona desde ahí.

Esto transforma también el proceso de revisión. En un pull request, el revisor ya no ve únicamente líneas nuevas o modificadas. Ve también por qué se hizo ese cambio, qué problema resuelve y qué criterios guiaron la implementación.

El contexto viaja junto al código, y eso mejora radicalmente tanto la calidad del review como el onboarding de nuevos perfiles en el proyecto.

¿Funciona de verdad en sistemas complejos?

La pregunta crítica es si todo esto resiste cuando el entorno deja de ser controlado y aparece la complejidad real: monolitos heredados, migraciones cloud, plataformas híbridas, integraciones con Kubernetes, Terraform o Apache Kafka. Y precisamente ahí es donde más sentido cobra.

En un sistema heredado de cientos de clases, el contexto manual simplemente deja de ser viable. No cabe en la ventana del modelo ni es razonable esperar que un/a desarrollador/a decida manualmente qué partes son relevantes en cada momento.

Una de las aplicaciones más interesantes de este enfoque es la modernización de software legacy. La IA puede analizar módulos antiguos y generar especificaciones formales de comportamiento. No captura todo desde el primer momento, pero sí una parte muy significativa que luego puede refinarse iterativamente.

Esas especificaciones pasan a ser el puente entre el sistema heredado y la nueva arquitectura. Lo importante es que el conocimiento extraído persiste. Un prompt desaparece, una especificación permanece.

El “100% automático” sigue sin ser realista

A pesar del avance, el objetivo NO es que la IA entregue software listo para producción sin intervención humana. Actualmente, incluso en los mejores escenarios, el resultado suele situarse en torno al 80% o 90% del trabajo útil. El resto sigue requiriendo criterio técnico, validación y comprensión profunda del sistema.

Existe además un riesgo menos visible: el knowledge lag. Si todo lo hace la IA y el/la desarrollador/a deja de recorrer mentalmente el código, termina perdiendo conocimiento real sobre el sistema que mantiene.

Ese último tramo que todavía exige intervención humana no es una limitación accidental: es también una garantía de control.

Lo que probablemente veremos en los próximos años

El debate ahora no es si habrá agentes autónomos o no, sino dónde encajan mejor. En tareas repetitivas, scaffolding masivo o migraciones mecánicas, la orquestación pura de agentes tiene mucho sentido.

Pero cuando entra en juego lógica de negocio compleja, auditoría, cumplimiento normativo o arquitectura crítica, el enfoque cambia. Porque en una gran empresa no basta con que el código funcione, también debe poder explicarse, trazarse, revisarse y sostenerse en el tiempo.

Y ahí es donde modelos basados en especificaciones, conocimiento corporativo y control arquitectónico parecen estar marcando ya el camino de 2026.

Una de las obsesiones de la Sociología es precisamente esto, acercarse a una representación acertada de la realidad y, por tanto, de la complejidad (porque la realidad siempre es compleja).

Aquí es donde entran los datos cálidos: información relacional y transcontextual que nos permite entender cómo se sostiene (o se bloquea) un sistema más allá de los KPIs.

Datos fríos vs. datos cálidos (una distinción útil)

• Datos fríos (Hard, Cold Data): lo medible y comparable. Tiempos, costes, throughput, errores, colas, desviaciones.
• Datos cálidos (Warm Data): lo que conecta y da sentido a lo anterior. Confianza, normas implícitas, tensiones, compromisos, “lo que no se dice”, miedos, historias compartidas, contexto social y cultural, lo que en Sociología se conoce como “interacciones”.

Ambos son necesarios. El problema empieza cuando intentamos optimizar solo lo que se puede medir “fácilmente”.

Tres tesis para mirar organizaciones como sistemas vivos

Este tema fue parte fundamental del trabajo de Gregory Bateson, filósofo, sociólogo y cibernetista, como después lo fue (y es) de sus hijas Cathy y Nora Bateson. Las tesis de la familia sobre lo que tener en cuenta al analizar ecosistemas como las organizaciones, son estas:

1 La tesis de la transcontextualidad

“Ningún proceso existe en un solo contexto."

En el diseño de procesos tradicional (Business Process Model and Notation - BPMN), solemos aislar el proceso (ej. "Aprobación de crédito"). Para los Bateson, esto es un error funcional de simplificación. Los datos cálidos aportan esa información transcontextual: el proceso de aprobación está "marinado", como poco, con el contexto económico, el clima laboral de la oficina, la vida familiar del empleado y la cultura tecnológica de la empresa.

Aplicación en procesos

El Process Mining puede detectar ineficiencias técnicas como un retraso (dato frío). Los datos cálidos pueden explicar que el retraso ocurre porque el empleado prioriza la relación con el cliente sobre la métrica del sistema para evitar un conflicto cultural.

2 La tesis de la relacionalidad

"La inteligencia no está en las partes, sino en las relaciones entre ellas."

Gregory Bateson argumentaba que para entender un sistema no debemos mirar a los sujetos, sino a los mensajes que intercambian. Nora extiende esto, afirmando que los datos cálidos describen las interdependencias que mantienen vivo al sistema.

El dato frío mide el desempeño de un silo; el dato cálido mide la salud de la conexión entre silos.

Aplicación en procesos

En un DTO (Digital Twin of the Organization) no basta con modelar tareas. Hay que modelar la "adherencia" y la confianza al proceso, ya que este puede ser técnicamente óptimo pero relacionalmente tóxico, lo que garantiza su fracaso a largo plazo.

3 La tesis de la coalescencia

"Los cambios reales en sistemas complejos son procesos invisibles de coalescencia."

Esta tesis sostiene que antes de que un cambio sea visible en un KPI (dato frío), ocurre una "Aphanipoiesis": una acumulación de pequeñas variaciones en las relaciones y percepciones (datos cálidos), sutiles pero que varían el sistema. Lo “coalescen”, (como cuando varias gotas de lluvia se unen para formar una más grande). Si solo gestionamos lo que se mide (dato frío) y obviamos la coalescencia de variables, llegaremos tarde a la crisis o a la oportunidad.

Aplicación en procesos

Por ejemplo, en el desempeño de su trabajo, un Agile Coach no solo busca "velocidad de quemado", busca los cambios en la comunicación del equipo que preceden a un aumento de eficiencia. Antes de que un equipo sea "ágil" formalmente, (eventos, artefactos…dato frío), ocurre una “coalescencia de confianza, lenguaje común y entendimiento de reglas tácitas”. Si el consultor no ve esta coalescencia, intentará desplegar un proceso sobre un terreno que aún no ha fusionado sus raíces, con un alto riesgo de fracaso. Los datos cálidos permiten una orquestación proactiva, detectando la fatiga del sistema antes de que el log de eventos muestre una caída en el rendimiento.

Los datos cálidos en un proceso: un ejemplo práctico enriqueciendo el VSM

Imagina que mapeas un proceso y lo representas en un Value Stream Map: extraes una matriz SIPOC, tomas tiempos de actividades y tareas, clasificas ineficiencias, confirmas hipótesis. Así, detectas que un proceso administrativo tiene un 30% de desperdicio en tiempo de espera. Los datos fríos pueden sugerir una respuesta de automatización, pero los warm data pueden revelar que la demora se debe a la falta de confianza entre equipos, miedo a cometer errores, desuso de herramientas o normas implícitas que frenan la agilidad.

Sin esos datos relacionales, cualquier optimización es superficial y, muchas veces, contraproducente.

Para una persona experta en optimización, ignorar los datos cálidos es como intentar entender un bosque analizando solo la madera de los árboles (datos fríos), sin mirar la simbiosis de las raíces y el clima que les afecta (datos cálidos).

Una orquestación integral en 2026 requiere de ambos. Este enfoque puede marcar la diferencia entre una solución eficiente en papel y una transformación real y sostenible, una verdadera orquestación integrada que provea de horizontes razonables al área u organización optimizada.

Los datos cálidos han sido tradicionalmente menospreciados como "datos blandos", subjetivos, alejados de lo científico. La sociología relacional demuestra que existen y, por ello, no se pueden obviar. Capturan relaciones en lugar de variables aisladas. En colaboración con los datos fríos que muestran lo cuantificable (costes, tiempos, rendimientos), los warm data nos ayudan a entender cómo las dinámicas humanas y culturales afectan esos números, entre ellas, con los procesos y con las máquinas, como profetizaba la Autonomación Lean TPS (Jidoka).

¿Cómo integramos los datos cálidos en el análisis de procesos?

Detectar y medir los datos cálidos puede ser desafiante, por eso han sido obviados, pero como comienzo, recomendamos:

• Observar interacciones, no solo resultados. ¿Cómo se toman decisiones en la organización? ¿Qué conversaciones nunca suceden? ¿Por qué se eligen unas herramientas y no otras? ¿Cómo se relacionan los equipos de proyectos? ¿Cómo se eligen los criterios de validación? ¿Por qué? ¿Existen reglas implícitas? ¿Qué se considera un deshonor en ese equipo? ¿Y una traición?
• Analizar patrones de comportamiento en lugar de solo outputs. ¿Por qué ciertas ineficiencias persisten incluso con soluciones bien diseñadas? ¿Estamos automatizando ineficiencias no detectadas por comportamientos?
• Incluir múltiples perspectivas. No basta con los datos operativos, se necesita entender la experiencia vivida por las personas en el sistema. Si las entienden, las aceptan y qué emociones suscitan. ¿Qué modelos de liderazgo existen, cómo se trasladan e influyen? #diversitymatters
• Por último, cuestiona tus propias acciones de optimización. ¿La optimización reduce realmente la carga cognitiva o solo redistribuye el esfuerzo? ¿El cambio organizacional es adoptado o simplemente “tolerado” hasta que se revierta? Cuando el perfil de consultoría se marcha, ¿la eficiencia lograda mantiene la cohesión y confianza en los equipos o la fragmenta por competir?

Datos cálidos y agilidad: el vínculo natural

Los marcos ágiles y Lean enfatizan la adaptación y la mejora iterativa. Establecer un marco de trabajo es establecer un marco de convivencia y alineamiento y, en eso, la agilidad ha invertido mucho esfuerzo. Sin embargo, sin una comprensión profunda de las relaciones y contextos invisibles, la mejora se queda en la superficie. Los datos cálidos permiten ver las resistencias al cambio, los valores culturales subyacentes y los impactos sistémicos de cualquier intervención.

En Paradigma Lean Papers hemos hablado de la importancia del BA (contexto) para entender el sistema de trabajo, la vida diaria de los equipos, de la observación del Gen-ba como ecosistema viviente que es.

Conclusión

En un mundo obsesionado con la precisión numérica, necesitamos recordar que las organizaciones y los procesos que la vertebran, son sistemas vivos.

Si trabajas en optimización, ten presente que la complejidad es una experiencia. Si tus modelos no explican la realidad que viven los equipos, no estás optimizando, estás simplificando peligrosamente.

¿Cómo integras datos relacionales en tus proyectos ágiles? Te leo en comentarios 👇

Referencias

• Nora Bateson, Neurocognitive Academy
• Bateson Institute
• Warm Data Labs, Bateson Institute
• “Aphanipoiesis”, Nora Bateson

En este informe, Industria 2026: el salto hacia la supply chain autónoma, desgranamos las 5 tendencias que están marcando el paso en el sector de la Industria: desde la irrupción de la IA Agéntica y los Gemelos Digitales de Operación (DTO), hasta la soberanía del dato con Edge AI, la descarbonización predictiva (GreenOps) y la cobótica colaborativa de nueva generación.

La volatilidad global, la escasez de talento y las exigencias de la AI Act no dan tregua. En este escenario, la autonomía no es una opción tecnológica, es una necesidad financiera. Aquellas empresas que logren orquestar este cambio no solo ganarán eficiencia, sino una barrera competitiva infranqueable.

¿Quieres liderar la transición hacia la industria del futuro? Descarga el informe y descubre cómo transformar la incertidumbre en una ventaja operativa medible.

Treinta años después de su nacimiento, sigue siendo una de las piezas centrales del software empresarial. Y sus dos últimas versiones, Java 24 y Java 25, dejan bastante claro hacia dónde quiere ir en esta nueva etapa.

Java 2. vs. Java 25: ¿laboratorio o estabilidad?

Aunque ambas versiones llegan muy próximas en el tiempo, su papel no es exactamente el mismo. Java 24 funciona como un laboratorio de evolución, una versión donde se introducen funcionalidades en fase preview para que la comunidad empiece a probarlas. Java 25, en cambio, aterriza como versión LTS (Long Term Support), es decir, como la versión destinada a quedarse durante años en entornos productivos.

La diferencia es importante porque en el ecosistema Java las versiones LTS son las que realmente marcan los ciclos de adopción empresarial. Son las que terminan entrando en producción, las que reciben soporte prolongado y las que condicionan la evolución de frameworks y plataformas.

Adiós a la verbosidad: una sintaxis más limpia

Uno de los movimientos más visibles de estas nuevas versiones está en la sintaxis. Java lleva tiempo intentando reducir parte de la verbosidad que tradicionalmente lo ha acompañado, y en esta ocasión lo hace con novedades como los Primitive Patterns.

Esta funcionalidad permite trabajar de forma más natural con tipos primitivos dentro de estructuras como switch o instanceof, evitando conversiones explícitas y simplificando el código. Puede parecer un detalle pequeño, pero encaja en una tendencia mucho más amplia: hacer que Java se parezca cada vez menos al Java de hace diez años.

La dirección es clara: menos código ceremonial, menos fricción y una experiencia más cercana a lenguajes que desde hace tiempo priorizan agilidad y legibilidad.

Ese cambio también se nota en pequeños detalles que, sumados, pesan mucho en el día a día. En Java 25, por ejemplo, algunas declaraciones se simplifican y escribir un programa básico requiere menos estructura obligatoria que antes. No cambia la esencia del lenguaje, pero sí elimina barreras que durante años se habían asumido como inevitables.

Concurrencia y rendimiento para la era Cloud

Otro de los terrenos donde Java está acelerando con más decisión es la concurrencia. Y aquí hay una razón de fondo: el software moderno necesita gestionar cada vez más tareas simultáneas con menor coste de recursos.

Tras la llegada de los virtual threads en versiones anteriores, Java 24 y Java 25 siguen empujando esa línea con propuestas como Scoped Values y Structured Concurrency. La idea es ofrecer mecanismos más seguros para compartir contexto entre hilos y, sobre todo, facilitar que varias tareas concurrentes puedan coordinarse de forma más limpia.

Esto tiene impacto directo en algo muy práctico: menos complejidad, menos riesgo de fugas de recursos y un control más claro cuando algo falla dentro de un flujo concurrente.

A la vez, Java 25 incorpora mejoras internas orientadas al rendimiento. Menor huella de memoria, arranques más rápidos y optimizaciones en ejecución son parte de una estrategia muy alineada con entornos cloud, microservicios y despliegues donde cada milisegundo cuenta.

Estrategia de migración: ¿es el momento de saltar?

La gran pregunta para muchos equipos es cuándo dar el salto. Si se parte de Java 21, la respuesta parece bastante clara: Java 25 es hoy la apuesta más razonable. Al ser LTS, concentra el soporte futuro y ya empieza a marcar el ritmo de herramientas como Spring Boot o Quarkus.

Java 24 puede tener interés como espacio de prueba o aprendizaje, pero difícilmente será una versión de permanencia.

Eso sí, en organizaciones con código muy legacy, especialmente cuando todavía hay sistemas en Java 8 o versiones anteriores, el salto conviene hacerlo con cuidado. Migrar Java no es solo cambiar versión: también implica revisar dependencias, frameworks y comportamientos que pueden haber cambiado durante años de evolución.

Por eso están ganando protagonismo herramientas como OpenRewrite, capaces de automatizar parte de ese trabajo y reducir el coste de modernizar bases de código muy grandes.

El próximo horizonte: la Inteligencia Artificial

Y mientras, Java sigue ajustando sintaxis, rendimiento y concurrencia, ya aparece el siguiente gran frente: la inteligencia artificial.

Frameworks como Spring AI empiezan a marcar una nueva dirección, y todo apunta a que futuras versiones del lenguaje reforzarán capacidades orientadas a cargas de trabajo más intensivas, mejor gestión de memoria y nuevas optimizaciones para este tipo de escenarios.

Porque si algo deja claro esta evolución es que Java ya no compite solo por estabilidad, ahora también compite por seguir siendo relevante en el software que viene.

¿Cómo perdemos el contexto en milisegundos?

Las herramientas de procesamiento de lenguaje natural actúan a menudo como una caja negra inaccesible para el usuario medio. Introducimos una frase, esperamos una fracción de segundo y obtenemos un resultado aparentemente preciso.

El problema surge cuando analizamos casos límite donde intervienen lenguas con estructuras radicalmente distintas. Un ejemplo de este tipo de lenguas es el turco. El turco carece de género gramatical marcado para profesiones, mientras que el español obliga estructuralmente a definirlo.

Para nuestra demostración, usaremos la herramienta de Google “Google Translate”. Si escribimos "yo soy médica" y lo pasamos al turco obtenemos "Ben doktorum". Hasta aquí todo correcto porque la expresión engloba a cualquier persona que ejerce la medicina.

El fallo del sistema aparece cuando la traducción se realiza a la inversa. Al traducir "Ben doktorum" de nuevo al español, la plataforma nos devuelve "Soy médico". El sistema ha eliminado el género original introducido por el usuario. Esto mismo ocurre con el término “enfermero”, que al pasar por el filtro neutro y volver a nuestro idioma se transforma automáticamente en “enfermera”. Nos encontramos ante un bucle sin fin donde la máquina reescribe la identidad del usuario basándose puramente en suposiciones probabilísticas.

Ejemplo con "yo soy médica":

Ejemplo con "yo soy enfermero":

¿Qué impacto tiene entrenar modelos con el pasado?

Entender este comportamiento exige conocer las tripas de los sistemas de aprendizaje automático. Los motores de traducción modernos no operan mediante un diccionario estático de reglas gramaticales fijas programadas a mano. Funcionan ingiriendo cantidades masivas de texto procedentes de internet, libros digitalizados y repositorios de documentos históricos. Los algoritmos calculan probabilidades estadísticas basadas en miles de millones de interacciones pasadas para predecir cuál es la traducción más plausible.

Aquí es donde la estadística nos juega una mala pasada. Históricamente, la palabra equivalente a "doctor" aparece rodeada de pronombres y contextos masculinos en la inmensa mayoría de los corpus de entrenamiento. La palabra "nurse" o sus derivadas sufren exactamente el mismo destino asociadas a la terminología femenina.
Cuando el modelo se enfrenta a la ambigüedad de un idioma neutro debe tomar una decisión y siempre optará por el camino matemáticamente más probable según sus datos de entrenamiento. Esta mecánica muestra sesgos sociales preexistentes porque la máquina asume que el pasado dicta la norma estricta del presente.

Desde una perspectiva puramente de negocio, lanzar productos basados en modelos no supervisados supone un gran riesgo para la empresa. Construir soluciones digitales que invisibilizan a una parte de tus usuarios genera fricción y rompe la confianza en el producto.
Imagina un software de recursos humanos que clasifique automáticamente currículums descartando a mujeres ingenieras simplemente porque su modelo de lenguaje asocia la ingeniería con perfiles masculinos. La calidad del dato de entrada determina irremediablemente el éxito o el fracaso comercial de cualquier iniciativa basada en inteligencia artificial.

Las grandes tecnológicas conocen perfectamente este comportamiento anómalo. Hemos visto intentos de mitigar el impacto mediante parches visuales en la interfaz de usuario. Al traducir frases simples del inglés al español a veces aparece un selector que ofrece ambas alternativas de género. Las capturas que analizamos hoy demuestran que estas soluciones superficiales no escalan bien. Cubrir todas las combinaciones idiomáticas y todas las estructuras sintácticas posibles mediante reglas excepcionales preprogramadas es una quimera técnica muy compleja de solucionar.

Para aportar valor a las organizaciones necesitamos arquitecturas de datos limpias y algoritmos auditables desde su concepción. Los equipos de ingeniería de datos deben incorporar métricas de equidad durante la fase de validación de los modelos antes de desplegarlos en entornos de producción reales. Evaluar continuamente el rendimiento estadístico frente a grupos demográficos es el único camino para construir tecnología robusta.

El procesamiento del lenguaje natural contemporáneo se apoya fuertemente en representaciones vectoriales del texto. Cada palabra se mapea en un espacio multidimensional donde la distancia entre vectores determina su relación semántica. Si visualizamos este espacio geométrico, observamos que la distancia vectorial entre hombre y médico es significativamente menor que la distancia entre mujer y médica. El modelo simplemente recorre el trayecto más corto en su mapa matemático.

Corregir esta desviación requiere técnicas avanzadas de mitigación de sesgos durante el preentrenamiento. Existen métodos matemáticos para aislar las dimensiones de género respecto a las dimensiones de profesión dentro de estos espacios vectoriales. Obligamos al algoritmo a desaprender esa correlación inyectando ruido controlado o penalizando la función de cálculo cuando detectamos predicciones basadas exclusivamente en estereotipos demográficos.

Integrar prácticas ágiles conscientes del sesgo permite monitorizar la degradación de estos sistemas en tiempo real. Cuando implementamos procesos de entrega continua para modelos de lenguaje necesitamos pruebas automatizadas que evalúen específicamente estas traducciones problemáticas. La tecnología debe adaptarse a la diversidad de los usuarios en lugar de forzarlos a encajar en las limitaciones estadísticas de una base de datos mal balanceada.

Conclusión

La adopción masiva de modelos de lenguaje nos exige elevar nuestro nivel de exigencia técnica y operativa. Delegar la semántica a sistemas no supervisados tiene consecuencias directas sobre la usabilidad de nuestros productos digitales y la reputación corporativa.

Referencias y enlaces

• Google Translate Help: Gender-specific translations
• Machine Learning Glossary: Bias

En este segundo artículo de nuestra serie sobre Green Quality Assurance (GQA), abandonamos el "por qué" para adentrarnos en el "cómo". Si en el primer artículo establecimos que medir la calidad en vatios y CO2 es tan importante como garantizar que el software funcione correctamente, ahora es momento de construir los cimientos que sostendrán esta nueva forma de trabajar. No se trata solo de reducir el consumo energético de nuestras pruebas o ejecutar menos casos de test; se trata de reimaginar completamente nuestro enfoque hacia la calidad del software.

La industria del software debe entender que la excelencia técnica y la responsabilidad ambiental no son objetivos excluyentes. De hecho, las organizaciones más innovadoras están descubriendo que las prácticas sostenibles en QA a menudo conducen a procesos más eficientes, equipos más productivos y, sorprendentemente, a una mejor calidad del producto final.

Pero para alcanzar este equilibrio, necesitamos un framework robusto que nos permita evaluar, implementar y mejorar continuamente nuestras prácticas.

El viaje hacia el Green QA es evolutivo. No podemos pretender que una organización pase de cero a cien de la noche a la mañana. Por eso, en las siguientes páginas explicaremos un enfoque gradual que reconoce diferentes niveles de madurez, proporciona herramientas concretas para cada etapa que nos permitan medir nuestro progreso.

Capas del framework

Abordar el cambio cultural en una organización en lo que se refiere a calidad por lo general suele ser un proceso evolutivo en el que la parte de concienciación suele tener un gran peso. Dar el salto que se propone con GQA (Green QA), implica un nuevo elemento en esa concienciación y es tener como objetivo el hacer las cosas lo más “verdes” posibles, pero, ¿somos conscientes de las cosas que hay que cambiar para alcanzar este cambio? A continuación te lo contamos.

Gobernanza

En primer lugar, es conveniente disponer de una Gobernanza adecuada a este contexto. Se trata del “mandato” oficial de la organización y es la base de todo el proceso. Sin esto, el Green QA queda en una iniciativa aislada. Qué puntos aborda la gobernanza:

• Política de calidad sostenible

No es solo un documento; es definir el "Umbral de Aceptación Verde". Establece los objetivos que persigue la empresa en lo referente a sostenibilidad, estableciendo objetivos por tipo de recurso. Una vez establecidos estos objetivos todo lo demás tiene como finalidad cumplir con los mismos. Por ejemplo: "Ningún despliegue a producción puede aumentar el consumo energético del microservicio en más de un 5%".

• Matriz de responsabilidades

Define qué hace cada miembro de la organización implicado en el ciclo de vida de los entregables.

1. QA: diseña los casos de prueba de eficiencia, define las métricas de referencia y es responsable de ejecutar las mediciones en cada ciclo.
2. Arquitectura: valida que las decisiones de diseño no introduzcan deuda energética estructural antes de que llegue a la fase de testing.
3. DevOps / Platform Engineering: garantiza que la instrumentación necesaria para medir el consumo esté disponible en los entornos de prueba. Sin infraestructura de observabilidad, QA no puede medir.
4. Sostenibilidad: provee los factores de conversión de energía a CO2CO_2 CO2​ y asegura la trazabilidad de los datos hacia el sistema de reporte ESG.
5. Compliance: verifica que la recogida, el tratamiento y el reporte de los datos cumplen con la normativa vigente, en particular la CSRD.
6. Product Owner: acepta formalmente que los criterios de aceptación incluyen métricas de eficiencia, no solo funcionalidad y rendimiento tradicional.

• Alineación con ESG y estrategia corporativa. En el post anterior, hablamos de forma extensa sobre qué es ESG y su conexión con Green QA, y es algo con lo que se ha de contar dentro de la gobernanza.

Procesos

Establece cómo Green QA se integra en el día a día del proyecto.

• Shift-Left Green: integrar criterios ambientales en la fase de Refinement. Si una funcionalidad consume demasiados datos de forma innecesaria, se rechaza antes de programar.
• Green Gateways en el Pipeline: añadir "puertas de calidad" en el CI/CD. Si las pruebas automatizadas detectan un pico inusual de uso de CPU o RAM, la build falla.Controles ambientales en diseño, desarrollo, pruebas y despliegue.
• Suministros: evaluar si nuestros proveedores de servicios (Cloud, SaaS) funcionan con energías renovables.

Es importante que, dentro de la gobernanza, se deben establecer las consecuencias que ha de tener en el proceso el incumplimiento de la normativa, bloqueando una entrega, generando deuda técnica o estableciendo los mecanismos oportunos que impidan no saltarse los objetivos fijados.

Datos y métricas

En esta capa del framework se analiza la calidad del dato que ha de servir para fundamentar las decisiones.

• Trazabilidad del dato: asegurar que el dato ESG tiene un linaje claro: desde el sensor o log de servidor hasta el reporte anual.
• Data Cleaning de QA: un proceso para borrar entornos de prueba, bases de datos temporales y logs de ejecución antiguos que empeoran el almacenamiento y consumen energía innecesaria.
• Exactitud vs. estimación: definir qué datos son medidos (reales) y cuáles son estimados (modelos matemáticos), aplicando un QA distinto a cada uno.
• Definición de KPIs ambientales y ESG.
• Controles de calidad de datos (exactitud, completitud, trazabilidad).
• Auditoría y reporting.

Tecnología

Es la capa de las herramientas. El Green QA necesita ojos técnicos para "ver" la energía. Por lo tanto, es conveniente disponer de herramientas para medir el impacto de lenguajes de programación (ej. comparar el consumo de Python vs. Rust en procesos críticos), optimizar las suites de pruebas para que no corran 2000 tests si solo han cambiado 2 líneas de código (selección de pruebas basada en riesgo), configurar el framework para que los entornos de prueba se "autodestruyen" inmediatamente después de terminar la ejecución, disponer de herramientas de medición (energía, carbono, recursos), automatización de pruebas verdes y optimización de infraestructura (cloud, hardware).

Mejora continua

Dentro de las capas del framework, es aconsejable apostar por el aspecto cultural y de mejora del mismo de cara a disponer de un framework que debe ser circular y no lineal.

Elementos como “Retro-Green”, donde en cada retrospectiva de sprint, se puede incluir una pregunta: "¿qué proceso o código hemos hecho más eficiente este mes?", la gamificación creando un ranking de los equipos de desarrollo/QA que más han reducido su huella de carbono digital, la actualización de estándares.

Al cambiar las leyes ESG, esta capa cambia y se suele revisar trimestralmente. De esta manera, el framework sigue cumpliendo con las nuevas normativas y, por último, establecer objetivos de reducción medibles de forma cuantitativa o cualitativa.

El camino hacia el Zero-waste Testing

Uno de los puntos a los que hemos hecho referencia en el apartado anterior es la medición. Es importante conocer en cada momento la situación en la que nos encontramos respecto a los objetivos para tomar las medidas y acuerdos necesarios trabajando con la gobernanza definida. Si conocéis el TMMi, es un proceso que mide el nivel de madurez en referencia a las pruebas dentro de una organización.

A este respecto, a continuación se hace un análisis de los niveles existentes en relación a GQA para entender el punto en el que estamos y cuáles deben ser los objetivos para consolidar estos niveles o cómo avanzar en ellos. Cada uno de estos niveles que se indican se deben desarrollar para ser más concretos a la hora de evaluarlos.

Nivel 1: inicial (empezamos a caminar)

En este nivel, la empresa no tiene conciencia del impacto ambiental de sus pruebas. Si hay eficiencia, es por ahorro de costes, no por propósito. Cumplimiento reactivo, sin métricas.

En este nivel, poco refinado, se ejecutan siempre todas las pruebas en entornos en los que no tenemos visibilidad de su consumo y que permanecen encendidos por lo general 24/7 las pruebas se ejecutan siempre.

Nivel 2: básico (conciencia despierta)

El conjunto de los implicados conoce qué es Green QA y se realizan los primeros esfuerzos manuales por documentar el impacto. Controles manuales, informes básicos.

En este nivel intermedio se identifican los activos como servidores y herramientas para solicitar a los proveedores informes de sostenibilidad, creando un inventario de activos digitales. Se empiezan a tratar las pruebas de una manera más coherente con esta política, borrando por ejemplo datos de pruebas antiguas.

En este punto, las acciones que emprendemos aún dependen de las personas y no de procesos automáticos.

Nivel 3: definido (el estándar verde)

La sostenibilidad se integra oficialmente en el manual de calidad. Aparecen los primeros procesos estandarizados y KPIs.

En este nivel, elementos como disponer de una checklist para el pase a producción “verde” ha de ser uno de los objetivos. Para ello se definen los KPIs verdes (como, por ejemplo, los vatios por suites de pruebas).

Justo con esta definición se busca en en este nivel que el equipo de QA tenga la formación suficiente de Green Coding y eficiencia energética.

Nivel 4: gestionado (calidad automatizada y medible)

Se ha establecido una serie de métricas y la automatización del reporte continuo a través de los pipelines está presente.

Una vez consolidados algunos aspectos, entre ellos los culturales, el uso de "dashboards de carbono en tiempo real" integrados en herramientas como Jira o Grafana para que los equipos vean su impacto diario se pone como objetivo.

El reto es integrar estos datos con el resto de la empresa (ESG). Los pipelines de CI/CD incluyen herramientas que miden el consumo de CPU/RAM de los tests automáticamente. Si una prueba es ineficiente, se genera una alerta.

Nivel 5: optimizado (ADN Green QA)

GQA ya no es un "extra", es la única forma de trabajar. Está alineado con la estrategia global de la empresa.

Ahora, la empresa utiliza IA para predecir y minimizar el consumo energético de las pruebas. El ahorro de carbono logrado por el equipo de QA se reporta directamente en el informe anual de sostenibilidad (ESG) de la compañía. El reto está en mantener la innovación y liderar estándares en la industria.

Aspectos como la "economía circular del dato", donde los datos de prueba se reutilizan de forma inteligente para evitar generar nuevos procesos de carga, son aspectos que se empiezan a cuidar para consolidar los objetivos “verdes”.

Estrategia y metodología

La estrategia es el marco de decisión en el que se definen los elementos necesarios para abordar en la práctica GQA, alineado con todas las capas del framework que se han definido en los apartados anteriores.

​​La metodología describe cómo hemos de implementar la estrategia que hemos definido y se encarga de definir cómo ejecutar GQA.

En el contexto de GQA (o sostenibilidad en el ciclo de vida del software), estas herramientas no solo miden emisiones, sino que se integran en el proceso de calidad para asegurar que el software sea eficiente y cumpla con normativas medioambientales (ESG).

Una vez que se ha establecido una estrategia alineada con los objetivos, se establecen las herramientas y frameworks que se usarán para su implementación. A continuación vemos algunos ejemplos.

Medición de eficiencia de software (Green Testing)

Aquí es donde el QA tiene control directo. Se mide el consumo de energía de un proceso o suite de pruebas. Se utilizan para establecer la línea base (Baseline).

Antes de optimizar una sola línea de código, el QA necesita saber cuántos gramos de CO2 genera el hardware donde corre la aplicación. Sin este dato, no podemos medir la mejora tras una optimización.

Herramienta: Scaphandre (metrología energética)

Es un agente de métricas de consumo eléctrico de código abierto diseñado para Kubernetes y servidores Bare-metal.

• Para qué sirve

Mide exactamente cuántos vatios consume un proceso específico (ej. tu suite de Selenium o un microservicio bajo carga).

• Configuración y uso

1. Instalación: se instala como un binario o contenedor Docker en el servidor donde corren los tests.
2. Uso: expone métricas en formato Prometheus.
3. Green QA Step: configura un dashboard en Grafana que cruce "consumo CPU" vs "consumo Watts". Si tras una optimización de código los tests pasan en el mismo tiempo pero consumen menos Watts, el GQA ha tenido éxito.

Herramienta: Eco-Code / SonarQube (Green Rules)

• Para qué sirve

Análisis estático de código enfocado en la eficiencia energética.

• Configuración

1. Instalación: añadir el plugin "Green IT" o "Eco-Code" a tu instancia de SonarQube.
2. Uso: QA define Gateways de calidad. Si el código contiene patrones que "despiertan" la CPU innecesariamente (bucles ineficientes, llamadas a API redundantes), el test de calidad falla.

Herramienta: SimaPro y GaBi

Son los estándares industriales, en el ecosistema de QA se pueden adaptar de la siguiente manera:

• ¿En qué consisten para el entorno IT?

Permiten modelar el impacto de nuestra infraestructura digital (servidores, dispositivos móviles de prueba o redes). No solo miden el gasto energético, sino también la "deuda de carbono" del hardware que sostiene nuestro software.

• Su uso estratégico en Green QA

Se utilizan para establecer la línea base (Baseline). Antes de optimizar una sola línea de código, QA necesita saber cuántos gramos de CO2 genera el hardware donde corre la aplicación. Sin este dato, no podemos medir la mejora tras una optimización.

• Configuración y fuentes de datos

Para poder controlar la huella ambiental de nuestra aplicaciones, Green QA mapea:

• Inventarios de hardware: CPUs, RAM y sistemas de almacenamiento utilizados en los entornos de Staging y producción.
• Bases de datos ambientales: se integran fuentes como Ecoinvent para calcular el impacto del "mix energético" (no es lo mismo ejecutar un test en un servidor de Noruega con energía hidroeléctrica que en uno de una zona que depende del carbón).
• Ejemplo práctico de decisión técnica

Gracias a estas herramientas, el equipo de QA puede realizar comparativas basadas en datos reales:

Caso de estudio: ¿es más sostenible ejecutar nuestra suite de regresión en servidores locales antiguos (On-premise) o migrar las pruebas a una instancia de nube con certificación Energy Star y auto-escalado? El Green QA utiliza el LCA para demostrar que la migración reduce la huella de carbono en un X%.

Medición de Cloud Carbon Footprint (CCF)

Si no quieres usar las herramientas nativas (que a veces son opacas), Cloud Carbon Footprint es el estándar abierto.

Herramienta: Cloud Carbon Footprint (CCF)

• Para qué sirve

Visualizar emisiones de AWS, Azure y GCP en un solo lugar con una metodología de cálculo transparente.

• Configuración

1. Conexión: necesitas permisos de lectura en los archivos de facturación (CUR en AWS, Billing Export en GCP).
2. Uso: permite al equipo de QA comparar regiones.
3. Decisión técnica: QA puede demostrar que mover el entorno de Staging de una región basada en carbón (ej. Virginia, US-East-1) a una con energía limpia (ej. Suecia o Francia) reduce la huella de carbono instantáneamente sin cambiar una sola línea de código.

Herramientas: Watershed, Persefoni, Plan A

Son plataformas SaaS para medir la huella de carbono corporativa.

• En qué consisten

Automatizan el cálculo de emisiones de Alcance 1, 2 y 3 (Scope 1, 2, 3).

• Uso en Green QA

El software entra en el Alcance 3 (emisiones indirectas). Estas herramientas recolectan datos de tus facturas de luz y proveedores cloud.

• Configuración

Se conectan vía API a tus sistemas de inventario. El equipo de QA reporta aquí el consumo energético de las granjas de servidores de prueba para que la empresa tenga el dato real de impacto del departamento de IT.

Medición de sostenibilidad en el Frontend

El GQA también mide el impacto en el dispositivo del usuario final.

Herramienta: GreenFrame.io o Lighthouse (Carbon Indicator)

• Para qué sirve

Medir la huella de carbono de una sesión de usuario en el navegador.

• Configuración y uso

1. CI/CD Integration: se integra en los GitHub Actions o Jenkins.
2. Uso: cada vez que se lanza un test de regresión visual, Green Frame estima los gramos de CO2 producidos por la carga de la página (transferencia de datos + ejecución de JS en el cliente).
3. Métrica de QA: esta nueva versión de la Home pesa 2MB más y genera 0.5g de CO2 extra por visita. Reportado como Bug de Sostenibilidad.

QA y auditoría: gestión de calidad verde

Aquí es donde conectas los datos con el proceso de testing.

Jira y TestRail

• Uso en Green QA: no miden carbono por sí mismos, pero se configuran para gestionar requisitos verdes.
• Configuración
  • Jira: crear "Custom Fields" como Estimated Carbon Cost en las User Stories.
  • TextRail: crear una sección de "Green Test Cases" donde se valide que la app entra en modo ahorro de energía o que no hace peticiones API innecesarias.

Plataformas de datos ESG (Environmental, Social, and Governance)

• En qué consisten

Repositorios donde se guarda toda la evidencia para auditorías legales.

• Uso en Green QA

El resultado de tus tests verdes se sube aquí como prueba de cumplimiento normativo (ej. para cumplir con la directiva CSRD en Europa).

• Configuración en el Pipeline

Para que esto sea "Green QA" real, el flujo debe ser:

1. Definir umbrales: en Jira, establecer un límite de consumo energético por feature.
2. Medir: durante la ejecución (Cucumber/Playwright), monitorear el consumo con herramientas como Scaphander o Intel Power Gadget.
3. Visualizar: cruzar esos datos con el Azure Emissions Dashboard.
4. Auditar: exportar reportes a Persefoni o Plan A para la contabilidad anual.

Buenas prácticas

Conclusiones

El proceso de transición en una organización para abrazar el GCA conlleva una serie de pasos ineludibles y un proceso de adaptación a todos los niveles.

Requiere de una implicación tanto por parte de los negocios como de la parte técnica, empezando por el cambio cultural y siguiendo por la adaptación metodológica y estratégica.

Todos estos cambios ayudarán a la empresa a cumplir con la legalidad que ya se mencionó en el anterior post.

Este post no es para contarte qué es un Sprint ni para aclarar lo que implica o no el término “time-box”, sino para darle un lugar a este espacio de tiempo que se necesita en el arranque del proyecto.

Podemos llamarlo como queramos, pero el Sprint Cero es un bien necesario para no llevarnos sorpresas a mitad de partido… o, incluso, al final.

Mi experiencia

Llevo casi quince años gestionando proyectos, antes bajo metodología waterfall, ahora soy agilista (o lo intento) y lo hago desde Scrum.

Cuando la humanidad dio ese gran paso hacia la verdadera entrega de valor, olvidando los interminables documentos del Project Management Plan impresos en A3, se olvidaron de asegurar mediante un time-box este espacio de tiempo para conocer el proyecto, el cliente y el equipo, hacer las primeras tomas de contacto, ponernos cara y empezar a hacernos los unos a los otros.

Establecer las reglas del juego, las necesidades, alimentar el backlog, dar las primeras estimaciones… Todo esto es tan importante como entregar un mínimo producto viable (MVP). De hecho, es imprescindible para que el resultado del MVP sea el esperado por todas las partes.

Porque a veces, solo a veces, ocurre que en esa primera toma de contacto una de las dos partes se da cuenta de que la otra parte no le puede ofrecer lo que esperaba y evitamos que esta conclusión sea tangible cuando ya esté la mitad del pescado vendido.

Bien es cierto que no es lo mismo trabajar en consultoría que si lo haces en cliente final. Los consultores damos servicio a clientes finales que tienen un producto que vender y que, de alguna manera, se convierte también en nuestro producto.

Pero este servicio tiene fecha fin, así que, por regla general, en consultoría tendemos más a solicitar estos espacios de tiempo para tratar de estar alineados y de asegurar el entregable con mayor fiabilidad. En el caso del cliente final, que tiene la información más directa, más rápida y más segura, tiende a pensar que estos espacios en los que el equipo piensa, planifica, acuerda y se informa, no son necesarios.

Esta fase inicial del proyecto nos va a proporcionar una serie de ventajas que nos permitirán arrancar el primer Sprint con una mayor garantía de éxito frente a desarrollar la genial idea de tirarnos a la piscina de ese primer Sprint sin conocer al detalle la profundidad de aquello a lo que nos enfrentamos:

1. Conocerás a tu cliente

Y, para ello, sacarás tiempo de donde no lo haya para hacer reuniones de arranque del proyecto que permitirán al equipo exponer lo que se ha entendido del alcance acordado (o conocido como acta de constitución) y las conclusiones extraídas de esta fase inicial, donde muchas veces uno entiende solo lo que quiere entender (o lo que puede).

De estas reuniones, se extraerán dudas que, posiblemente (o no) cambien el alcance del producto e, incluso, puedan aumentar su valor porque, sinceramente, ni siquiera se habían pensado antes. ¿Y qué mejor entrega de valor que regalarle valor a tu propio producto?

2. Conocerás al equipo y empezarás a estrechar lazos.

Y no hablo de tener “un buen equipo” en abstracto, hablo de crear esa sensación de ir a una, de remar en la misma dirección. En los primeros días también empiezas a ver, y a verte: fortalezas, manías, estilos y cómo reacciona cada uno cuando hay prisa o incertidumbre.

Ese conocimiento vale oro, porque te permite adelantarte y gestionar riesgos y dependencias que al principio ni se ven: malentendidos, expectativas distintas, silencios que se interpretan mal o decisiones que nadie se atreve a tomar si no está claro el marco.

3. Harás que el equipo y el cliente se conozcan.

En esas primeras reuniones de dudas y aclaraciones (de negocio, técnicas y de “esto cómo lo hacemos”) se construye el punto de partida real. Y si en este periodo nos ganamos la confianza mutuamente, luego todo fluye mejor: cuando el equipo proponga algo que no estaba en el guión, el cliente al menos lo escuchará, y cuando negocio cambie prioridades a mitad de camino, el equipo lo gestionará como lo que es: un ajuste incómodo… no un drama imposible.

4. Entre todos estableceremos las reglas del juego

Ya son la mitad del éxito del entregable: duración de los sprints, hora de la daily, agendas de planning/review/retro, cómo vamos a estimar y cómo vamos a escribir las historias. También dejamos encarrilado lo básico de “la casa”: repositorios, accesos, herramientas (¿Jira sí o Jira no?) y unas primeras decisiones técnicas para no improvisar. Y con todo eso, dibujamos un roadmap inicial y ligero para saber por dónde empezamos y qué hitos vemos en el horizonte.

5. El Product Owner puede salir de este arranque con una primera versión del Product Backlog

Ojo, primera versión, pero suficiente para poner en pie un MVP que sirva de raíz para todo lo demás. El backlog, como dicta Scrum, irá evolucionando durante toda la vida del producto pero, si dejamos claras las primeras épicas, historias y tareas que ya conocemos, arrancamos con un punto de partida sólido para empezar a construir (y aprender) desde el Sprint 1.

6. De cada una de las reuniones, impresiones, toma de ideas, decisiones que se acuerden podrá realizarse una gestión de riesgos iniciales

Esto nos permitirá montar una primera foto sobre los posibles escenarios que el equipo se encontrará en su quehacer y tratar de eliminarlos o aliviarlos antes de que se conviertan en un problema.

Todo esto asentará las bases del proyecto y desde aquí se iniciará el camino que nos conducirá, ya no solo al éxito en cada uno de los entregables, sino al buen hacer de las cosas, siempre, siempre, consensuadas.

En la vida real…

Voy a contaros uno de los casos que he vivido que me terminó de confirmar todo esto. Me asignaron un proyecto para un cliente con el que se había trabajado anteriormente y con el que, en teoría, nada debería sorprendernos.

Proyecto corto, con urgencia: el cliente quería un entregable a principios de año y a nosotros nos lo pasaron a mediados de noviembre. Diciembre por medio, con puentes y vacaciones ya cerradas… así que el margen era el que era.

Viendo un poco el futuro, encontramos que era necesario descubrirnos para poder apuntalar el producto e ir construyendo lo máximo posible a la mayor velocidad permitida y entregar, con la previsión que nos daban esas fechas establecidas, un MVP de calidad con la mayor cantidad posible que sirviera para hacerlo crecer en las proporciones adecuadas.

Fueron 2 semanas de conocernos: 10 días hábiles donde, a partir del documento de inicio del proyecto, trabajamos codo con codo con el cliente para resolver todas las dudas que nos fueron surgiendo de los requisitos, extrajimos todas las Historias de Usuario necesarias para llevarlo a cabo, las estimaciones de cada una de ellas y, por lo tanto, de todo el proyecto.

Ante la inviabilidad de poder entregar todo lo deseable en la fecha pretendida por el cliente, la idea era ofrecer una propuesta de MVP que se alimentara en entregas de valor cada dos semanas con funcionalidades nuevas e hitos de despliegues a entornos superiores hasta completar todo lo detallado en el documento de requisitos.

Lo iniciamos con muchas ganas, queríamos hacerlo bien. Comenzamos las reuniones con cliente, le explicamos que los time-box definidos para cada Sprint serían de 2 semanas, utilizamos todos los huecos posibles para solicitar más información sobre temas inconclusos, resolver dudas, definir en qué forma podían ser más efectivas algunas funcionalidades y desarrollar un roadmap con todos los hitos definidos (y sus entregas de valor) hasta completar el proyecto.

La primera semana todo parecía ir sobre ruedas: cliente entregado, equipo ilusionado… ¿qué podía salir mal? A la segunda semana, el cliente empezó a no asistir, se volvió difuso en sus respuestas y dejó de contestar.

Y, antes de que pudiéramos cerrar el roadmap y propuesta de entregables, decidió cancelar el proyecto. ¿Fracaso? Para mí, al revés: fue la señal temprana que nos ahorró semanas de presión y desgaste. Sin ese arranque, lo habríamos descubierto mucho más tarde, con trabajo ya hecho, el equipo agotado y el cliente frustrado.

¿Qué conclusión sacamos de este ejercicio?

Con todo lo hablado, ¿se equivocó Scrum por no “inventarse” un Sprint de arranque, Sprint inicial o Sprint Cero? Si nos ponemos estrictos, desde la ortodoxia Scrum no tendría mucho sentido: un Sprint es un Sprint, y punto.

Pero la vida real, y más en consultoría, no siempre arranca con las condiciones ideales y ahí es donde este timebox de descubrimiento se vuelve un aliado.
En los tiempos que corren, con la sed de adaptabilidad que cada vez demandan más los proyectos y los clientes, no está de más pasar con el cliente por esa fase de descubrimiento, que existe desde los orígenes de la gestión de proyectos.

¿Qué hubiera pasado con ese proyecto en el que en la segunda semana el cliente decidió retirarse? ¿Nos habríamos dado cuenta en tan poco tiempo, de un lado o de otro, que no estábamos en la misma línea de tiempo o en la misma perspectiva?

Posiblemente, habríamos vivido un mes y medio de presión absoluta para que se llegara a algo a lo que no se podía llegar, equipo estresado, cliente frustrado, metodología en entredicho, calidad en entredicho también… ya por evitar eso, creo que es realmente necesario pasar por esta fase.

Durante años, la gestión de proyectos “clásica” ya contemplaba algo parecido: antes de ejecutar, había que iniciar y planificar, entender el contexto, alinear expectativas y dibujar una hoja de ruta.

Llámalo como quieras, pero la necesidad de conocer al cliente, el problema y las condiciones del proyecto no es nueva; lo que ha cambiado es cómo lo hacemos.

La diferencia hoy es que no buscamos una planificación exhaustiva al estilo waterfall, sino un arranque ligero y adaptativo: empatizar con los objetivos del cliente y del equipo, clarificar necesidades, hacer visibles supuestos y restricciones, identificar riesgos iniciales y salir con una primera visión de trabajo que nos permita empezar a entregar con sentido.

En resumen: pensar lo justo al principio para no pagar después por no haber pensado nada.

Pensemos que todo en la vida es adaptarse. En Paradigma lo hemos llevar a la práctica en cómo trabajamos: con Polaris, nuestro marco de trabajo, buscamos mantener la esencia ágil en proyectos, productos y servicios, pero con suficiente flexibilidad como para adaptarnos al ciclo de vida de cada cliente, buscando la excelencia de los entregables, donde:

• Mantenemos la esencia Agile pero la llevamos a otro nivel, a través de la regla 80/20, en la que entendemos que el 80% de la gestión del proyecto es la actitud del equipo, mientras que el 20% es la práctica, las herramientas con las que trabajamos y la experiencia que tenemos.
• El Scrum Master evoluciona hacia un rol de Agile Delivery Leader, asegurando coordinación, foco en valor y visión clara de lo que estamos construyendo.
• Nos guiamos a través del True North, esa brújula compartida, visible para todos, que nos ayuda a resolver dudas sin caer en debates y a mantener el rumbo cuando el día a día aprieta.
• Trabajamos dentro de un marco 100 % adaptativo con fases y objetivos claros en cada una de ellas: fase de pre-proyecto, fase de arranque (o nuestro Sprint Cero), distintas iteraciones y fase de cierre.
• Ponemos foco a los riesgos en la forma en que se merecen, de cara a tenerlos bajo control desde el primer minuto de vida del proyecto / producto o servicio, yendo siempre por delante en cada una de las fases del proyecto.
• Buscamos un modo productivo, empezando por hacer lo necesario, luego haciendo lo posible y terminando, por qué no, consiguiendo lo imposible. No solo buscamos la productividad dentro del proyecto, creemos que la productividad tiene que empezar por uno mismo.
• Nos basamos en métricas para tomar decisiones con un catálogo en el que seleccionar lo que mejor se adapte a tu cliente, a tu proyecto, a tu equipo y a tu manera de gestionar.
• La calidad no se negocia, ya que nos aseguramos de que el producto sea superior al de la competencia, poniendo la tecnología al servicio del mismo y entendiendo la entrega temprana y continua como una garantía de éxito.
• Entendemos que el desarrollo de software no consiste solamente en entregar funcionalidades, sino en resolver problemas de negocio y por ello, nuestro enfoque siempre va a ir alineado con el del cliente.
• La experiencia del equipo es un must, el equipo es lo primero y la relación con el cliente debe ser cuidada y mimada. Porque sabemos que tenemos que entendernos para garantizar el éxito. Y nos funciona.

Y cierro con algo sencillo: la vida nos da la posibilidad de elegir, también cuando gestionamos proyectos y cuando dejamos nuestro producto en manos de otros.

Nada garantiza el éxito al 100%, pero si podemos elegir, yo lo tengo claro: mejor conocernos antes de sacar conclusiones precipitadas, mejor empatizar antes de llegar a reproches.

Mejor descubrirnos a tiempo que acabar con una lista de “yo te dije” que no lleva a ningún sitio… y mucho menos al éxito del producto.

Los grandes laboratorios están centrando sus esfuerzos en agentes capaces de programar, investigar, coordinar herramientas y operar en distintos entornos de forma cada vez más autónoma.

Claude Code sale del terminal y se integra en Telegram y Discord

Una de las novedades más relevantes del mes llega desde Anthropic, que ha ampliado las capacidades de Claude Code con una nueva funcionalidad conocida internamente como Channels.

Esta actualización permite controlar sesiones activas del agente directamente desde plataformas como Telegram y Discord, así como desde otros canales conectados mediante webhook.

Este avance modifica profundamente la forma en que se utilizan los agentes de programación. Ahora un/a desarrollador/a puede iniciar tareas desde el móvil, continuar una sesión abierta en el ordenador, solicitar revisiones de código o ejecutar instrucciones remotas sin necesidad de acceder directamente al entorno local.

En la práctica, Claude Code deja de ser un simple asistente de terminal para convertirse en un agente persistente, accesible desde múltiples canales de comunicación y preparado para acompañar el trabajo diario de forma continua.

OpenAI explica cómo supervisa a sus agentes de código

Por su parte, OpenAI ha publicado uno de sus documentos de seguridad más relevantes hasta la fecha, detallando cómo supervisa internamente a sus propios agentes de programación para detectar comportamientos anómalos o desviaciones respecto a las instrucciones originales.

El sistema utiliza actualmente un modelo interno denominado GPT-5.4 Thinking, encargado de analizar prácticamente toda la actividad del agente:

• Qué información recibe.
• Qué código ejecuta.
• Qué herramientas invoca.
• Cómo estructura su razonamiento interno.
• Qué modificaciones introduce en el código.

Cuando se detectan patrones inesperados (como escalados no previstos, acciones no solicitadas o decisiones alejadas del objetivo inicial) los casos se escalan a revisión humana en menos de treinta minutos.

Este movimiento confirma una preocupación creciente en el sector: los agentes avanzados no solo pueden cometer errores, sino también desarrollar estrategias no previstas si no se monitorizan de forma adecuada.

La carrera del código: OpenAI acelera frente al crecimiento de Claude Code

Marzo también está evidenciando una competencia cada vez más intensa entre OpenAI y Anthropic en el terreno del desarrollo asistido por IA.

Diversos análisis publicados este mes apuntan a que Claude Code se ha convertido en uno de los agentes de programación con mayor adopción entre equipos de desarrollo profesionales, lo que ha llevado a OpenAI a reforzar internamente el desarrollo de Codex.

Dentro de OpenAI se han creado equipos específicos para mejorar áreas como:

• Navegación inteligente de repositorios.
• Edición autónoma de múltiples archivos.
• Testing automático.
• Ciclos completos de refactorización.

Todo ello confirma que en 2026 el verdadero campo de batalla ya no es solo el chatbot conversacional, sino el dominio del desarrollo de software autónomo.

Novedades en vídeo e imagen generativa

Más allá de los agentes, marzo también está dejando avances muy relevantes en vídeo e imagen generativa, donde la competencia se centra cada vez más en control, consistencia y utilidad profesional.

Seedance 2.0: el modelo chino que más presiona al mercado occidental

ByteDance continúa consolidando el impacto de Seedance 2.0, uno de los modelos de vídeo más observados del momento por su combinación de realismo visual, sincronización de audio y control cinematográfico.

La principal novedad de marzo es su avance en control multimodal:

• Admite texto, imagen, audio y vídeo como entrada simultánea,
• Permite trabajar con múltiples referencias visuales,
• Mejora notablemente la continuidad entre planos,
• Genera clips con una estética muy próxima a producción audiovisual profesional.

Uno de sus puntos fuertes sigue siendo la capacidad de mantener coherencia de personajes entre escenas, algo donde muchos competidores aún presentan limitaciones.

Sin embargo, solo genera vídeos de hasta 15 segundos, su acceso está bloqueado fuera de China y tiene una estricta censura que impide usar rostros reales por derechos de autor.

Fuera de China, sin embargo, el acceso sigue siendo limitado, lo que está alimentando el interés internacional.

Veo 3.1: Google mejora movimiento, cámara y continuidad

En el terreno del vídeo, Google continúa reforzando Veo 3.1, orientándolo cada vez más a usos profesionales.

Entre las mejoras destacadas de marzo se encuentran:

• Mejor interpretación de prompts complejos,
• Movimientos de cámara más naturales,
• Reducción visible del flickering,
• Continuidad temporal más estable,
• Mejor física visual en escenas dinámicas.

La novedad más relevante es Ingredients to Video, que permite trabajar con varias imágenes de referencia para mantener consistencia visual en escenas largas, la generación nativa en formato vertical (9:16) y el escalado neuronal a 4K real.

Esto acerca Veo a aplicaciones mucho más serias en publicidad, branded content, previsualización cinematográfica y producción de campañas visuales.

Gemini Image: precisión visual y edición contextual

Google también ha reforzado su sistema Gemini Image, vinculado al reciente lanzamiento de Gemini 3.1 Pro.

Las mejoras más visibles de marzo se concentran en:

• Interpretación de relaciones espaciales complejas.
• Edición contextual sobre imágenes existentes.
• Consistencia visual en múltiples iteraciones.
• Comprensión más precisa de prompts largos y técnicos.

Esto se traduce en un mejor rendimiento en tareas como branding visual, diseño de producto, mockups complejos y campañas consistentes.

Además, Gemini Image se integra cada vez más dentro de entornos de trabajo tipo workspace creativo, donde la generación visual deja de ser una herramienta aislada y pasa a formar parte del flujo continuo de producción.

Un nuevo equilibrio en la IA visual

La conclusión de este mes es clara: la competencia ya no consiste únicamente en generar imágenes o vídeos más impactantes, sino en ofrecer control real para producción profesional.

Hoy el panorama se perfila así:

• Seedance lidera en sensación cinematográfica.
• Veo destaca en consistencia técnica y control de escena.
• Gemini Image avanza con fuerza en workflows visuales aplicados al trabajo real.

Para guiar a las organizaciones en este cambio de paradigma, presentamos las 7 buenas prácticas para evolucionar tu PMO a VMO, un recurso que detalla la transición hacia una Value Management Office (VMO). Este modelo alinea la estrategia con la ejecución operativa, transformando la oficina de proyectos en un motor de agilidad que prioriza el impacto en el negocio y la satisfacción del cliente final.

La adopción de estas buenas prácticas no es solo un cambio metodológico, sino una evolución cultural necesaria para maximizar la rentabilidad. Además, complementamos estas buenas prácticas con la contribución de la IA en algunos aspectos como la priorización, la toma de decisiones y el seguimiento del flujo de valor.

¡Descárgatelo ya! 👇

En este episodio, nuestro equipo de Goodly, especialistas en el ecosistema de Google, hace una criba para traernos los experimentos más alucinantes de Google Labs e intentar adivinar cuál se convertirá en el próximo estándar del mercado.

Para creadores/as de contenido, especialistas de marketing y diseño, las nuevas herramientas vienen pisando muy fuerte. Analizamos:

• Pomelli, capaz de generar campañas de marketing digital y recursos gráficos solo con pasarle la url de tu negocio.
• Mixboard, el tablero interactivo definitivo para combinar y trabajar con imágenes.
• Produce AI, que promete convertirte en productor musical con un par de prompts.
• Stitch, un generador de interfaces web y móvil que exporta código y se integra directamente con Figma.

Pero los equipos de desarrollo y gamers no se quedan atrás, con herramientas que parecen sacadas de la ciencia ficción.

Hablamos de Project Genie, un hito impresionante capaz de generar mundos interactivos y jugables a partir de una simple frase, revolucionando potencialmente la industria del videojuego.

Además, profundizamos en Jules, el agente de codificación asíncrono y autónomo de Google que ya trabaja directamente en tus repositorios de GitHub creando Pull Requests, y Stax, la prometedora suite visual para evaluar y comparar diferentes modelos LLM.

Por último, exploramos cómo la IA se está volviendo más personal, predictiva y agéntica.

Te contamos nuestra peculiar experiencia con Portraits, la plataforma que te permite conversar con avatares digitales de especialistas y coaches, y echamos un vistazo al futuro de la navegación con Disco, un concepto de navegador basado en Chromium capaz de crear aplicaciones al vuelo.

Todo esto nos lleva a una conclusión inevitable: la era de las aplicaciones AI Native ya es una realidad absoluta.

Como todo buen experimento en fase beta, algunos de estos proyectos ya están listos para brillar y otros aún tienen mucho margen de mejora.

Si quieres descubrir cuáles merecen tus preciados créditos, cómo probarlos (con o sin viaje virtual a EE. UU.) y qué apuestas hace nuestro equipo de Goodly sobre el éxito tecnológico del 2026, ¡no te pierdas este episodio de “Cómo conocí a nuestro cloud”!

La buena noticia es que la industria ya ha dado con la solución, y no es un invento de un día. La respuesta, como hemos venido sosteniendo, pasa por aplicar la disciplina más rigurosa que tenemos: Platform Engineering. Se acabaron “las pruebas con gaseosa” (la fase de preparación de la IA) y ahora toca la fase de aplicación de la IA en producción, a escala, con responsabilidad y velocidad.

La necesidad de tener una plataforma de IA no es solo una moda, es la infraestructura AI-nativa que las empresas referentes, entre las que se encuentran algunos de nuestros clientes, ya están construyendo a día de hoy en el mercado.

La industria ya está ahí y hay soluciones de referencia

La verdad es que no tenemos que ser el conejillo de indias. Los pesos pesados ya están diciendo claramente lo que estamos viendo, la IA necesita de Platform Engineering.

Google y Thoughtworks son solo dos ejemplos de cómo la visión de la industria está convergiendo. El mensaje es claro: si quieres escalar MLOps de forma consistente, necesitas los Golden Paths y la abstracción que solo la Platform Engineering te puede dar. No es solo cuestión de tener más GPUs, sino de hacer que esas GPUs sean consumibles sin un manual de 300 páginas.

¿Y qué significa esto? Significa que el objetivo no es solo soportar los modelos actuales, sino crear una Infraestructura AI-Nativa. Es decir, una plataforma que está diseñada desde cero para orquestar la complejidad de los agentes de IA, los datos vectoriales y el flujo de MLOps. Estamos hablando de una plataforma que tiene la automatización y la inteligencia integradas.

Si los líderes del sector ya han validado este blueprint, la duda no es si debemos construirlo, sino cuándo empezamos.
Una plataforma de IA rara vez se construye desde cero con un solo producto. Se basa en una orquestación inteligente de componentes que reducen la fricción y dan flexibilidad. Para los equipos que comienzan el viaje, es crucial identificar el stack que sirva como los mejores cimientos para soportar todo. Un ejemplo de Golden Path industrializado utiliza herramientas como:

• Orquestación de Pipelines: Kubeflow o MLflow para estandarizar el flujo de trabajo (entrenamiento, empaquetado y despliegue del modelo).
• Gestión del dato de entrenamiento (Feature Store): herramientas como Feast para garantizar la coherencia de los datos entre el entrenamiento (offline) y la predicción (online).
• Model Serving y MLOps Core: utilizar Kubernetes para el despliegue es solo el principio. Soluciones especializadas como KServe te pueden ayudar a gestionar la complejidad del escalado y la monitorización de los modelos.

La clave no es adoptar todas estas herramientas, sino que la Plataforma de IA las abstraiga para que el perfil de Data Scientist solo interactúe con el Golden Path simple que hayamos definido.

Casos de uso reales: un ROI tangible

A los CxOs les encanta la palabra ROI. ¿Cómo les evangelizamos el valor de esta plataforma? Yo lo tengo claro, ¡¡con hechos!! Mostrando dónde el self-service y la trazabilidad generan dinero o mitigan riesgos.

Vamos a intentar aterrizarlo con tres ejemplos donde la Plataforma de IA genera los cimientos más robustos:

• Retail y personalización a escala

Una plataforma que permite desplegar un motor de recomendación para cada segmento de cliente (o incluso individual) en cuestión de horas. La ventaja: si el perfil de Data Scientist puede iterar en la recomendación diez veces más rápido gracias a un Golden Path automatizado, la empresa vende más. El foco de negocio es el TTM de la mejora del algoritmo.

• Detección dinámica de fraude

Análisis de riesgo. Aquí, la plataforma de IA no solo despliega el modelo de detección, sino que garantiza la auditabilidad y la monitorización en tiempo real de la deriva del modelo (model drift). Si el modelo empieza a fallar, la plataforma lo detecta y lo revierte automáticamente, protegiendo a la empresa de pérdidas millonarias o fallos regulatorios.

• IT interna y automatización

Podemos usar la plataforma de IA para que Data Scientist generen agentes de IA internos que automaticen la gestión de tickets de soporte o la optimización de recursos cloud. Pasar de "tenemos un agente de IA en pruebas" a "el agente está resolviendo el 20% de las incidencias de L1" es solo posible si tienes una plataforma que gestiona su ciclo de vida y estado de forma fiable.

Los casos son múltiples y variados. Como especialistas de vuestra vertical y de vuestro negocio, seguro que identificáis otros muchos que llevar a buen puerto.

La hoja de ruta CxO, más allá del código o la tecnología

Aquí es donde el CxO entra en modo consultor estratégico. La tecnología es el cómo, pero la estrategia y las personas son el qué. No podemos hablar de Plataforma de IA sin abordar la gestión del cambio.

Alineación estratégica: conectar DORA con el balance sheet

Hay que traducir la jerga de Feature Stores al idioma del negocio, de quienes habilitan las palancas de inversión. Usaremos los principios que ya cubrimos en nuestra serie de Platform Engineering:

• KPIs de negocio y métricas MLOps: enseñar que la reducción del Lead Time for Changes (métrica DORA que deberíamos usar para medir en la plataforma) se traduce directamente en la velocidad de lanzamiento de nuevos productos y en la reducción del riesgo. Es la única manera de justificar, con hechos, la inversión.

Y además, pensando en la IA y los modelos, podríamos añadir métricos concretas:

• Tasa de productivización de pruebas de concepto (PoC-to-Prod Ratio): el porcentaje de Pruebas de Concepto (PoC) que pasan a producción en menos de 90 días. La Plataforma debe elevar este ratio del 10-20% (el estándar actual) a más del 70%.
• Valor agregado del modelo (Model Lift): medir la mejora incremental en métricas de negocio (ej. aumento en la conversión, reducción de fraude) que el modelo aporta antes y después de su despliegue con la plataforma.
• Reducción del TCO de MLOps: cuantificar el coste operativo total reducido gracias al self-service y la automatización, eliminando la dependencia del TicketOps y la configuración manual de infraestructura.

Gestión del cambio: uniendo los mundos de Data Science e ingeniería

Este es, quizás, el punto más difícil. Hay que conciliar y reivindicar a la vez:

• Los/as Data Scientists no son DevOps y no tienen por qué serlo. Por eso es tan importante construir esa plataforma que debe ser el puente. Hay que establecer la cultura de producto interna: el equipo de plataforma es el proveedor de servicios y/o capacidades, y el equipo de Data Scientist es su cliente.
• Formación y nuevos roles. Hay que invertir en formar lo que la industria llama Machine Learning Engineer, el pegamento entre el Data Scientist y el Platform Engineer.

El primer paso es siempre la abstracción tecnológica y afrontar la necesidad desde el negocio y las necesidades reales

La industria lo está haciendo, en Paradigma ya lo estamos haciendo, vemos que los beneficios son tangibles y, sobre todo, vemos que el riesgo de quedarse atrás es inasumible. La IA es el nuevo campo de batalla competitivo.

Entonces, ¿por dónde empezamos?

Mi recomendación para todos los “C-Level”, decisores, o responsables de equipos o unidades de negocio que tengan que tomar decisiones tecnológicas es sencilla: empezar por el o los componentes de mayor fricción, los que provoquen que los equipos tengan que dedicar los mayores esfuerzos y que esos esfuerzos no repercutan en el negocio de forma directa.

Comenzar por todo aquello que sea sensible de optimizar, de industrializar y que acelere el poder llevar una idea a producción en el menor tiempo posible.

• No intentéis construir la IDP completa de golpe. Eso sería una locura, hay que ser pragmáticos.
• Comenzar por ejemplo por capacidades como la nombrada Feature Store para resolver el dolor de la calidad del dato, o por el Model Registry (registro central de modelos) para abordar la trazabilidad y la gobernanza del uso de los mismos dentro de vuestra compañía.

Sin duda son solo un par de ejemplos, pero quienes conozcáis el proceso y sus diferentes puntos de dolor, seréis capaces de identificar “pequeños logros”, que irán poco a poco cimentando todo y que van dando cuerpo a esa Plataforma de IA.

Cualquier esfuerzo que reduzca el self-service manual y aumente la estandarización está pavimentando el camino para esa inevitable Plataforma de IA. La plataforma no se construye en un día, es un viaje, y la mejor forma de evangelizar y generar tracción es empezar a demostrar el valor con pequeños, pero sólidos, Golden Paths.

Espero que con esta serie de posts, haya sido capaz de despertar esa inquietud de por qué es tan importante esta temática, proporcionarte cierta justificación estratégica a través de hechos tan objetivos como son los problemas de poner todo esto en marcha y, sobre todo, haberte dado ideas de por dónde comenzar a la hora de generar esa hoja de ruta de acción (que aporte valor) para liderar la conversación sobre IA en tu organización.

Si quieres echar un vistazo a los dos posts anteriores de la serie, te los dejo a continuación:

• 2026 será el año de las plataformas de IA
• De la PoC a la producción: muchas pruebas de concepto, pero pocas productivas

Probar todo en todo momento puede no ser lo más óptimo ni lo más ecológico, por lo que la mejora de los ciclos de prueba y adaptar, tanto la calidad del proceso como del producto, para reducir emisiones se convierte en un nuevo reto dentro de los equipos.

En esta serie de tres post sobre Green Quality Assurance trataremos de adentrarnos en esta nueva visión para entender en qué consiste, qué framework puede ser el más adecuado para alcanzar nuestros fines y establecer los KPIs y métricas en una organización o en un proyecto para orientar nuestras prácticas a que sean más eficientes y sostenibles.

En esta primera parte nos centraremos en contar en qué consiste ser ecológico dentro del mundo de QA y cómo surge la necesidad a partir de normativas europeas como CSR (Corporate Sustainability Reporting Directive) y conceptos como ESG (Environmental, Social, and Governance).

¿Qué es Green QA?

Imagina que tu proceso de calidad se vuelve “atleta”: más rápido, más fuerte y mucho más eficiente. El Green Quality Assurance (GQA) redefine los procesos de QA, QC y testing para que cada uno de ellos cuente, reduciendo el consumo de energía y la huella de carbono sin perder la rigurosidad requerida.

Integrar la sostenibilidad en la calidad del proceso (actividades de QA durante la construcción del software) y en la calidad del producto (QC y testing, validar y verificar el producto construido), consiste en buscar que no sea solo bueno en términos de calidad del software, sino que sea eficiente a nivel de consumo energético, sostenibilidad y que se alineen con principios ESG que veremos más adelante.

Aquellas organizaciones que integren la responsabilidad social en su ciclo de desarrollo, manteniendo el rendimiento y controlando los costos, presentan ante sus potenciales clientes una ventaja frente al resto de sus competidores, al permitirles a estos últimos lograr mejorar los números en lo referente a la sostenibilidad conservando otros objetivos.

Alineados con el concepto de GQA está el de GreenCode, que tiene como finalidad la codificación, buscando la eficiencia energética mediante el uso de elementos como la carga diferida, los microservicios frente a monolitos y una codificación no muy pesada que permita prolongar la vida útil de los dispositivos sobre los que se ejecuta, entre otros puntos.

El Green IT va de la mano de los anteriores y es la base de estos. Se refiere al uso de hardware con certificación de eficiencia energética alta, uso de cloud frente a otros ya que los grandes proveedores como Amazon y Google suelen usar, en parte, energías renovables como la solar para su mantenimiento.

En la actualidad, y para hablar de la parte legal de todo este proceso, existe la normativa que obliga a las empresas a presentar el reporte RSE (o Memoria de Sostenibilidad) y que se denomina directiva CARD a nivel europeo. En España se ha integrado principalmente a través de la Ley de Información Empresarial sobre Sostenibilidad (LIES). Recordemos que la directiva CARD exige usar los estándares ESRS (Normas Europeas de Información sobre Sostenibilidad). Estas normas obligan a algunas empresas a desglosar su consumo energético y sus emisiones en función del tamaño y tipo de empresa. Cómo veis, Green QA tiene una cobertura legal y, si se logran alcanzar sus objetivos, ayuda a la empresa a cumplir en estos aspectos.

Como ejemplo de uso de estas normativas y del uso de GreenQA, un reporte de RSE tradicional diría: "queremos ser verdes", mientras que un reporte bajo la CARD requiere decir: "nuestra suite de Green QA redujo el consumo de CPU en un 12%, ahorrando X toneladas de CO2 este año".

ESG como ADN

Siguiendo con los conceptos que rodean y acompañan a GQA, y como se va a hacer muchas referencias a ello, vamos a explicar brevemente en qué consiste ESG.

ESG (Environmental, Social, and Governance) es el conjunto de criterios que inversores, gobiernos y clientes usan para medir si una empresa es responsable con el medioambiente, los aspectos sociales y la gobernanza interna.

Cuando hablamos de Environmental (ambiental), nos referimos al impacto ambiental que la empresa tiene en el planeta. Green QA tiene un peso específico alto en esta parte, ya que ayuda entre otros puntos con:

• Temas clave: huella de carbono, eficiencia energética, gestión de residuos y cambio climático.
• En software: ¿cuánta energía consumen tus servidores? ¿Está tu código optimizado para no calentar los procesadores innecesariamente?

Cuando hablamos de Social, nos referimos a cómo gestiona la empresa las relaciones con las personas y la sociedad.

• Temas clave: diversidad, derechos humanos, seguridad laboral y protección de datos.
• En software: aquí entra la accesibilidad (que tu app la pueda usar alguien con discapacidad) y la ética de los datos (privacidad del usuario).

Y, por último, al hablar de Governance (gobernanza), nos referimos a cómo se administra la empresa "por dentro". Es la parte de las reglas y la transparencia.

• Temas clave: ética empresarial, transparencia en los sueldos de los directivos, lucha contra la corrupción y cumplimiento de leyes.
• En software: auditorías de calidad, cumplimiento de normativas de software y transparencia en los procesos de desarrollo.

Una vez que ya conocemos que es ESG, vamos a ver cómo se puede evolucionar el perfil técnico de la calidad, de ser el garante del método y del producto a añadir el cumplimiento ESG y, por lo tanto, ser un garante también de la sostenibilidad.

Sabiendo cuáles son los grandes puntos que aborda el ESG (impacto de las empresas en el medio ambiente, impacto social y gobernanza interna), GQA se encarga de ayudar a conseguir los objetivos en el ámbito tecnológico:

• 🍃 Environmental: optimización de suites automatizadas y eficiencia en el uso de la nube para reducir directamente la huella de carbono del software.
• 🤝 Social: impulso a la inclusión digital. Un código eficiente consume menos recursos y rinde mejor en dispositivos antiguos, combatiendo la obsolescencia programada.
• ⚖️ Governance: generación de métricas técnicas y reportes transparentes sobre el consumo energético, facilitando el cumplimiento de auditorías verdes.

Las organizaciones que alineen los procesos de gestión del ciclo de vida de la calidad con los objetivos ESG sin comprometer la velocidad, el coste ni el rendimiento, obtendrán una ventaja decisiva en un mercado saturado de requisitos de RSE de alto rendimiento.

Cuáles son los objetivos principales

Los principales objetivos que buscamos con esta filosofía son, por un lado, la optimización de recursos, la eficiencia operativa y la rentabilidad. Y entre las metas que perseguimos se encuentran la reducción del impacto ambiental mediante la disminución del consumo, la reducción de residuos y emisiones, así como la optimización del uso de recursos de materiales y computación.

Sabemos que cada vez que se ejecuta una suite de pruebas (especialmente en la nube o en grandes servidores) se consume electricidad y esto implica la generación de una huella de carbono. La reducción de este impacto mediante pruebas selectivas y la eficiencia del código de las pruebas ha de ser una meta para la consecución de este objetivo

Otro de los objetivos de Green QA es la alineación con ESG, proporcionando datos a través de métricas ambientales.

• Facilitará informes de sostenibilidad auditables (consumo por ciclo de test, etc)
• Aportará información para la gobernanza de datos sostenible (reduciendo la duplicidad de datos en entornos de prueba TDM - Test Data Management), lo que disminuye el almacenamiento físico necesario en los centros de datos.
• Facilitará trazas de auditoría que demuestren que los procesos de calidad cumplen con las políticas de "Net Zero" de la organización.

En el siguiente cuadro podemos ver un resumen de las metas más importantes a las que aspiramos con uso de GreensQA:

Áreas de impacto, donde la calidad se vuelve verde

Para alcanzar los objetivos y metas de Green QA, debemos intervenir en los activos digitales clave. No se trata solo de probar que el software "funcione", sino de asegurar que sea sostenible. Para ello, se debe de actuar sobre los siguientes puntos:

Validación de productos y procesos digitales

• Análisis del ciclo de vida del software (S-LCA): QA ya no solo valida el "Go-Live", ahora audita el impacto ambiental desde el desarrollo y las pruebas, hasta el despliegue y el eventual desuso (decommissioning) del software. Su rol es asegurar que los cálculos de consumo energético en cada etapa sean precisos y reales.
• Verificación de sostenibilidad del código: implementación de protocolos para medir la "densidad energética" de las funciones. QA realiza pruebas de eficiencia para evitar el bloatware (software innecesariamente pesado) y garantizar que el producto no fuerce la obsolescencia del hardware del usuario.

Auditorías de sostenibilidad en la infraestructura

• Validación de proveedores de cloud: QA verifica que la infraestructura donde corre el software cumpla con certificaciones de energía renovable (PUE - Power Usage Effectiveness). No solo probamos en la nube, auditamos que la nube sea verde.
• Optimización de la cadena de suministro digital: revisión de librerías de terceros y dependencias. QA verde detecta dependencias ineficientes que consumen recursos en segundo plano sin aportar valor.

Validación de ecodiseño de software

• Criterios de "reparabilidad" y modularidad: validar que el código esté estructurado de forma que sea fácil de mantener y actualizar sin tener que refactorizar (y re-ejecutar) todo el sistema, ahorrando ciclos de computación innecesarios.
• Eficiencia en la transferencia de datos: pruebas específicas para reducir el peso de las peticiones API y el tráfico de datos, lo cual reduce directamente el consumo eléctrico en los centros de datos y redes de telecomunicaciones.
• Pruebas de cargas con conciencia de carbono: No solo medir cuántos usuarios soporta el sistema, sino cuánto CO2 emite el servidor bajo ese estrés.

Aseguramiento de los datos usados en ESG

Para que un informe de sostenibilidad sea válido, los datos deben de tener gran precisión. El Green QA se convierte en el auditor técnico que garantiza la integridad de cada métrica, todo ello requiere de la formación adecuada que permita a este rol certificar la información que se proporciona:

1. Validación de KPIs de emisiones

El perfil de QA debe asegurar que los algoritmos de cálculo y las fuentes de datos reflejen la realidad energética del ecosistema digital:

• Emisiones directas: primer nivel. Validación de datos provenientes de la infraestructura propia y servidores locales (On-premise).
• Energía comprada: segundo nivel.Verificación de los informes de consumo eléctrico de los centros de datos contratados y su mix energético (renovable o. fósil).
• Cadena de valor: tercer nivel. Es el mayor reto. QA audita la eficiencia de las APIs de terceros y el consumo de energía que nuestro software genera en los dispositivos de los usuarios finales.

2. Exactitud y fiabilidad de los informes

No basta con tener datos; deben ser correctos. Aplicamos técnicas para evitar sesgos en los reportes de sostenibilidad:

• Pruebas de estrés sobre los modelos de cálculo de huella de carbono.
• Validación de que no existan duplicidades en el conteo de emisiones entre diferentes departamentos.

3. Trazabilidad y auditoría (Data Lineage)

Implementación de pruebas de trazabilidad para asegurar que cada dato en el informe anual puede rastrearse hasta su origen técnico (logs de servidor, métricas de CPU, etc.). Si un auditor pregunta de dónde sale un número, el Green QA tiene la respuesta documentada.

4. Coherencia en la divulgación ESG

Garantizar que los datos publicados en la web, en la App y en el reporte legal de la directiva CARD sean idénticos. Se debe buscar un proceso automatizado para la validación cruzada de cara a evitar discrepancias que podrían suponer sanciones legales.

Aplicación de estándares y normativas

Existen varios marcos normativos y estándares que permiten aplicar todos estos procesos “verdes” de una forma coherente. En este punto damos un breve repaso a esas normas y en los siguientes artículos hablaremos sobre cómo se irán aplicando a nivel estratégico y metodológico:

• Marcos ISO (14001 y 50001): cómo los procesos de QA deben estar documentados para pasar auditorías externas de gestión ambiental y energía.
• CARD (Directiva de Reportes de Sostenibilidad Corporativa): esta es la nueva normativa europea. Se debe garantizar que lo que pide la ley se cumpla técnicamente.
• Taxonomía UE: validar que las actividades de la empresa se clasifican correctamente como "verdes" según los criterios técnicos de la Unión Europea.
• GHG Protocol (Greenhouse Gas Protocol): establecer la metodología estándar para contabilizar las emisiones de carbono derivadas del ciclo de vida del software. QA debe validar la recolección de datos de consumo energético en el Alcance 2 (energía de servidores/nube propia) y Alcance 3 (servicios en la nube de terceros y uso del software por el cliente final), asegurando que los factores de emisión aplicados sean precisos para los reportes de huella de carbono.

Conclusión

Hemos visto cómo, dentro del mundo de la calidad software, existe un aspecto que pocas veces se tiene en cuenta y que, sin embargo, tiene un considerable impacto.

Aplicar GQA no solo mejora la sostenibilidad sino que también mejora la eficiencia y esto implica un menor coste en los procesos y en la generación de productos.

Todos estos procesos vienen avalados por un conjunto de leyes europeas y sus transposiciones a la normativa española que lo hace más interesante ya que para las empresas no cumplirlas implica el pago de multas.

GreenQA es en definitiva como poner nuestro granito de arena para mejorar la vida desde el hacer de la calidad.