Con los MCP, los LLMs pueden conectarse a nuestras BBDD, APIs, herramientas internas… pero cada llamada externa al mundo es latencia y latencias. Si a esta ecuación le añadimos los Virtual Threads de Java, esta orquestación de agentes empieza a buscar una forma eficiente para no saturar nuestros servidores.

En este post iremos desde la integración del MCP dentro de Java con Spring AI, pasando por los hilos virtuales y su forma de salvarnos la vida cuando miles de agentes se ejecutan de manera paralela. Os doy la bienvenida al mundo de la IA escalable con Java.

Por qué usar Virtual Threads con MCP

Querer (y necesitar) ir a la alta concurrencia en IA

Debemos saber qué pasa cuando un LLM utiliza una herramienta mediante un MCP, ya que el cómputo masivo de CPU es verdad que lo abstraemos a los propios modelos, pero sí que estamos ante un problema de I/O puro y duro. El agente suele estar esperando el 99% del tiempo: esperando que el LLM decida qué herramienta utilizar, esperando a la propia red o esperando al MCP para que le devuelva los datos del sistema.

Imaginemos esto pero elevado a miles de usuarios concurrentes usando pools de hilos tradicionales. El resultado también lo podemos imaginar: servidor sin memoria antes de que el LLM acabe de escribir su primer token. Por lo tanto, si realmente necesitas desplegar agentes de IA en producción, es cuando tienes que dar el salto a los hilos virtuales.

Una vez decidido, ¿por qué este combo?

El Model Context Protocol (MCP) es el nuevo estándar abierto para conectar clientes de IA con servidores de datos y herramientas. Al integrar Spring AI con soporte MCP sobre una JVM con hilos virtuales activos, obtenemos ventajas competitivas brutales:

• Bloqueo sin coste: los Virtual Threads (disponibles desde Java 21) son hilos ultra ligeros gestionados por la JVM, como podemos leer en este post de nuestro compañero Daniel Peña. Cuando un agente hace una llamada HTTP o gRPC bloqueante a un servidor MCP, la JVM "desmonta" ese hilo virtual y libera el hilo de la plataforma real para que siga atendiendo peticiones.
• Modelo imperativo y limpio: olvídate de encadenar flujos reactivos complejos tipo WebFlux solo para gestionar la asincronía de las APIs de IA. Puedes escribir código secuencial clásico, fácil de depurar y mantener.
• Escalabilidad masiva: pasar de soportar unos pocos de agentes simultáneos a miles en la misma máquina, reduciendo los costes de infraestructura cloud drásticamente (y la pela es la pela!).

Conceptos clave: Host, Server y Virtual Threads

La arquitectura de MCP combinada con Java moderno gira en torno a tres elementos:

• MCP Host (cliente): en nuestro caso, nuestra aplicación Spring Boot/Spring AI. Es nuestro Isco en el centro del campo, es nuestro cerebro que habla con el LLM y decide orquestar las llamadas.
• MCP Server: el microservicio o proceso independiente que expone las herramientas reales (por ejemplo: los conectores de las bases de datos, herramientas de sistema, APIs).
• Virtual Threads: el motor de ejecución subyacente en Java que permite que cada sesión de agente corra en su propio hilo dedicado sin penalización de rendimiento.

Teniendo claro qué es cada uno, ¿cómo configuramos este ecosistema? Te lo mostramos con un ejemplo práctico.

Preparar nuestro proyecto Java para IA y MCP

Una vez decidido que vamos a montar agentes de alta disponibilidad, iremos paso a paso configurando nuestro entorno con Spring Boot y Spring AI.
Primero, generamos nuestro proyecto (si no lo tenemos ya) utilizando, por ejemplo, Spring Initializr, asegurándonos de utilizar una versión de Java 21 o superior.

En nuestro build.grade (o pom.xml si utilizamos maven), añadimos las dependencias necesarias para Spring AI y el starter de soporte para MCP:

plugins {
    id 'java'
    id 'org.springframework.boot' version '4.0.6'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
    maven { url 'https://repo.spring.io/milestone' }
}

ext {
    set('springAiVersion', "2.0.0-M4")
}

dependencies {
    implementation 'org.springframework.ai:spring-ai-starter-mcp-client'

    implementation 'org.springframework.ai:spring-ai-starter-model-ollama'

    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.ai:spring-ai-bom:${springAiVersion}"
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

Para activar la magia de la que hemos hablado para la concurrencia masiva, debemos irnos a nuestro nuestro archivo de configuración application.properties y añadir la siguiente línea, que le indicará a Spring Boot que delegue ese trabajo pesado a los hilos virtuales:

spring.threads.virtual.enabled=true

Una vez configurado, vamos a crear un servicio de IA muy básico. Este componente actuará como MCP Host, conectándose a un servidor MCP local (por ejemplo, un script de Node o Python que consulta información corporativa) y resuelve las peticiones de los usuarios:

package com.example.ai.mcp;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.tool.ToolCallback;
import org.springframework.stereotype.Service;
import java.util.List;

@Service
public class AgentService {

    private final ChatClient chatClient;

    // Spring AI autoconfigura el cliente MCP y expone sus herramientas como beans de tipo ToolCallback.
    public AgentService(ChatClient.Builder chatClientBuilder, List<ToolCallback> mcpTools) {
        this.chatClient = chatClientBuilder
                .defaultTools((Object) mcpTools.toArray(new ToolCallback[0])) // Vincula las herramientas del servidor MCP
                .build();
    }

    public String askAgent(final String userPrompt) {
        return this.chatClient.prompt()
                .user(userPrompt)
                .call()
                .content();
    }
}

En este código, el ChatClient recupera dinámicamente las herramientas (getTools()) que el servidor MCP tiene disponibles. Cuando invocamos askAgent, el LLM evalúa el prompt del usuario y, si necesita datos externos, ejecuta de manera transparente la herramienta del servidor MCP a través de una llamada de red bloqueante.

Gracias a que activamos los hilos virtuales, mientras la red resuelve esa petición de herramientas, el hilo queda completamente libre para procesar otras interacciones de IA.

El "Efecto Matrioska" del bloqueo en agentes de IA

En una aplicación web de toda la vida, por ejemplo, una API que consulta una base de datos, el hilo atiende la petición HTTP, bloquea mientras lee de la BD, recibe el dato y responde. Hay un único bloqueo de I/O.

En un agente de IA con un MCP externo, se produce lo que me gusta llamar el bloqueo en Matrioska, que basicamente es un bloqueo dentro de otro bloqueo. Cuando invocamos nuestro método askAgent, pasa lo siguiente en un único hilo:

1. Primer bloqueo (Envío al LLM): el cliente de Spring AI envía el prompt del usuario al LLM. El hilo se bloquea esperando la respuesta de la red.
2. El LLM decide: el modelo analiza el texto y dice: "No tengo este dato, necesito ejecutar la herramienta consultarFactura". Y no, no busques ese método en el código anterior, esa es la magia, el MCP le indica las tools que tiene disponibles y él es capaz de decidir que necesita esa.
3. Segundo bloqueo (llamada al MCP Server): Spring AI intercepta esa decisión del LLM y, a través del MCP, realiza una petición de red al servidor MCP externo donde reside la herramienta corporativa. El hilo se vuelve a bloquear esperando al servidor MCP.
4. Tercer bloqueo (vuelta al LLM): el servidor MCP responde, Spring AI recoge el JSON, y se lo vuelve a enviar al LLM para que procese la respuesta final. El hilo se bloquea por tercera vez.

Si utilizamos hilos de la plataforma tradicionales (java.lang.Thread nativos del S.O.), un solo usuario consultando al agente mantendría secuestrado un hilo físico durante varios segundos a través de múltiples llamadas de red anidadas.

Con los Virtual Threads, la JVM realiza magia: cada vez que se inicia uno de estos 3 bloqueos de red, el hilo virtual cede el hilo físico (Carrier Thread) instantáneamente. El hilo físico pasa a atender a otros usuarios, y el hilo virtual "vuelve a la vida" en cualquier otro hilo físico libre solo cuando los bytes de la red están listos.

“Lo creo pero no lo veo”. Destripando los hilos en los logs

No hay nada mejor que una demostración para ver si todo esto que os estoy contando es cierto. Para ello, vamos a modificar el servicio que hemos creado para imprimir el hilo actual antes de llamar al ChatClient, y así poder ver la concurrencia:

 package com.example.ai.mcp;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.mcp.SyncMcpToolCallbackProvider;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
public class AgentService {

    private final ChatClient chatClient;

    // Usamos ObjectProvider para que el cliente MCP sea opcional y no rompa al arrancar en local
    public AgentService(ChatClient.Builder chatClientBuilder, ObjectProvider<SyncMcpToolCallbackProvider> mcpToolCallbackProvider) {

        mcpToolCallbackProvider.ifAvailable(provider -> chatClientBuilder.defaultToolCallbacks(provider.getToolCallbacks()));

        this.chatClient = chatClientBuilder.build();
    }

    public String askAgent(final String userPrompt) {
        System.out.println("DEBUG HILOS -> " + Thread.currentThread());

        return this.chatClient.prompt()
                .user(userPrompt)
                .call()
                .content();
    }
}

Al levantar nuestra aplicación Spring Boot 4 y lanzar un par de peticiones, la consola nos arrojará algo como esto:

¿Cómo se lee esta traza?

• VirtualThread[#57...]: nos confirma que la petición ya no corre en un hilo de Tomcat, sino en un VirtualThread independiente creado para esa petición.
• ForkJoinPool-1-worker-2: es el hilo real del Sistema Operativo (Carrier Thread) que está transportando e interpretando ese hilo virtual en ese milisegundo exacto.

Si tuviéramos activadas las trazas del cliente MCP de Spring AI, veríamos que durante la llamada al servidor de herramientas, el identificador VirtualThread[#57] se pausa, liberando al worker-1 para que otra petición (como la del VirtualThread[#65]) pueda usar la CPU inmediatamente.

Simulando escenarios de alta concurrencia

Para ver el verdadero potencial, podemos exponer este servicio mediante un controlador REST muy sencillo. Si recibimos una gran cantidad de peticiones entrantes, podremos comprobar cómo el sistema responde de forma instantánea sin degradación del pool de conexiones:

package com.example.ai.mcp;

import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/v1/agent")
public class AgentController {

    private final AgentService agentService;

    public AgentController(AgentService agentService) {
        this.agentService = agentService;
    }

    @PostMapping("/ask")
    public String ask(@RequestBody String prompt) {
        // Spring Boot mapea esta petición automáticamente en un hilo virtual
        return agentService.askAgent(prompt);
    }
}

Si hiciéramos una prueba de carga simulando 500 usuarios preguntando al agente en el mismo segundo (donde cada uno requiere que el LLM llame a herramientas que tardan 1.5 segundos en responder), un servidor tradicional con un pool de 200 hilos colapsaría por falta de recursos de ejecución.

Con este enfoque, la JVM creará 500 hilos virtuales ligeros que nacerán, esperarán el I/O del protocolo MCP sin penalización y morirán limpiamente tras entregar la respuesta. Todo en orden, todo correcto.

Algunos errores comunes y cómo podemos evitarlos

• Confundir velocidad de CPU con concurrencia

Los Virtual Threads no hacen que nuestros algoritmos de IA locales o el parseo de JSON sean más rápidos. El único poder (y no es poco) es optimizar los tiempos de espera de las entradas y salidas. Si nuestra tarea requiere procesar matrices pesadas en local, un hilo tradicional o un pool dedicado sigue siendo la opción adecuada.

• Olvidar los límites de los sistemas externos

Que nuestra aplicación pueda soportar miles de conexiones no significa que nuestra base de datos o el servidor MCP remoto que usamos pueda soportar 10.000 conexiones concurrentes. Debemos ajustar siempre los timeouts y los límites de los pools de conexiones de nuestros clientes HTTP/gRPC.

• No monitorizar la JVM

Al trabajar con herramientas de IA que disparan miles de hilos virtuales, es vital usar herramientas de monitoreo como JDK Flight Recorder (JFR) por ejemplo, para trackear que no se estén produciendo bloqueos indeseados en el planificador de la JVM.

Conclusión

Ya tenemos entre nuestras manos las piezas clave para construir la próxima generación de arquitecturas de IAl empresarial utilizando los estándares más actuales del sector. Unir la flexibilidad del MCP para desacoplar las herramientas de negocio, con la robustez y ligereza de los Virtual Threads en Java, nos permite derribar definitivamente el mito de que Java es un lenguaje pesado o lento para el desarrollo de ecosistemas ágiles de IA (¡larga vida a Java!).

Si venías del desarrollo web clásico, el cambio de mentalidad al diseñar agentes autónomos conectados por red es radical. Lo importante es experimentar, medir el comportamiento de la infraestructura bajo estrés y ajustar los flujos de herramientas. El camino hacia agentes de producción estables y masivos ya no es una utopía inalcanzable y con las próximas actualizaciones estoy seguro de que se irá avanzando aún más en este punto.

Referencias

• Model Context Protocol (MCP) Official Documentation by Anthropic
• Spring AI Project Official Reference and MCP Integration Guide
• JEP 444: Virtual Threads Specification - OpenJDK
• Spring Boot Reference Guide: Production-ready Features & Virtual Threads
• Anthropic MCP GitHub Repository and Ecosystem Tools

También es fácil caer en el error de pensar que utilizarla nos lleva a ser más baratos, eficaces y rápidos.

En este escenario de saturación tecnológica, nuestra metodología no se diluye frente a la IA; se fortalece. Construimos sistemas donde la IA potencia la ejecución, pero la soberanía operativa y la visión estratégica siguen siendo humanas.

Hace ocho años, Paradigma ya advertía que tu empresa no necesita tribus y squads. Aquella tesis sigue vigente: confundir la forma con el fondo es el camino más rápido a la irrelevancia. Los frameworks deben evolucionar a partir de necesidades reales, no de modas metodológicas y este es el framework que utilizamos aquí, que está funcionando en junio de 2026 y del que no debemos enamorarnos.

De dónde partimos

La madurez tecnológica en Paradigma se articula sobre tres pilares de valor: personas, procesos y tecnología, asegurando que cada inversión en IA se traduzca en una ventaja competitiva tangible.

1. El eje de personas recoge todos los planes de formación práctica que realizamos a los equipos y que nos sirven para dar soluciones tangibles a los problemas . Estas deformaciones “Breaking AI” sirven de repositorio de materiales, videos y de recogida de casos.
2. El eje de procesos se basa en una solución, framework, proyecto o cambio en la forma de trabajar.
3. El eje de tecnología se apoya en los desarrollos que activamos sobre tecnologías existentes que nos permiten acceder a información de forma tangible.

El principal elemento que hemos aprendido es que, para consolidar procesos, sistemas o tecnologías es necesario construir sobre procesos establecidos en lugar de sobre framework externos o flujos completos.

¿Y dónde está el valor diferencial? En la integración. Si el equipo de CRO habla y construye bajo los mismos estándares de eficiencia que Desarrollo o Agile, eliminamos los silos y aceleramos el time-to-market.

Aterrizándolo en los equipos de CRO

El framework de CRO ha madurado hasta convertirse en una herramienta de precisión. Lejos de generalidades, nuestra propuesta se asienta en tres ejes que garantizan la escalabilidad: estructura, modularidad y persistencia.

¿A qué nos referimos con la estructura, modularidad y persistencia?

• La estructura garantiza la interoperabilidad con equipos internos y externos.
• La modularidad permite que cada solución aporte valor inmediato de forma independiente o como parte de un ecosistema conectado.
• La persistencia asegura que el input y output sean estables, eliminando la incertidumbre y garantizando que las decisiones se tomen sobre una base sólida de confianza.

Resumiendo: un enfoque de "piezas de Lego" donde cada componente es autónomo y genera valor por sí mismo, compatibles entre sí y estandarizados para garantizar consistencia.

Ejemplo sobre el análisis

En Paradigma no utilizamos gemas, skills o soluciones genéricas: los "skills" o gemas pueden parecer eficaces, pero son cajas negras propensas a alucinaciones, bloqueos por sistemas anti-bot y resultados inconsistentes.

¿Cómo puede una empresa basar su estrategia en un resultado que cambia según el contexto del prompt o la carga de tokens del día? La falta de control técnico es el enemigo de la rentabilidad.

Nuestra solución consiste en sustituir el azar por el control técnico. Utilizamos plugins propios que operan directamente sobre el DOM, componentes y tiempos de carga.
Este enfoque garantiza velocidad, consistencia estructural y una trazabilidad absoluta de los recursos consumidos. No nos quedamos solo en el análisis, pasamos a la auditoría técnica de alto nivel. Evitas arrastrar un sesgo apretando un botón.

¿Por qué trabajar con el DOM en lugar de con el chat?

Marsal McLuhan, una de las referencias en modelos de comunicación, decía que el medio es el mensaje. Estudios recientes muestran que, más allá del mensaje, el medio es el sesgo y, en procesos de valor, la pérdida de información entre iniciativas y soluciones es algo a destacar.

No es lo mismo hacer un prompt con texto que hacer una consulta con JSON, hacerla sobre el DOM o pegando una imagen. Diferente contexto o sesgo.

Un ejemplo sobre los insights y el research

Los experimentos de MeasureIQ confirman que los usuarios sintéticos son excelentes para la amplitud, pero fallan en la profundidad. Confiar ciegamente en ellos sin criterio humano es diluir la voz del cliente.
Yo no creo que deban sustituir nunca al usuario, creo que cuando no hay opción de preguntar a los usuarios, ayudan a traer un punto de vista adicional.

De igual manera creo que pervertimos el concepto de formas increíbles. Yo no puedo describir a la perfección un usuario sintético a la IA, no puedo darle el sabor, contexto, penetración entre mi base de clientes, representatividad entre el volumen de mis compras o wording.

Yo puedo diseñar un proceso de ingesta de información para que la IA levante los usuarios con su contexto (y luego me los describa).

Generando los usuarios sintéticos

Qué usuarios, en qué volumen, con qué interés, qué transacciones o fricciones es un contexto difícil de contar y fácil de automatizar.

El proceso que seguimos para los usuarios sintéticos parte de una ingesta de diferentes fuentes internas y externas de datos:

• Procesamiento de lenguaje natural (NLP) sobre verbatims anonimizados.
• Enriquecidos con datos sociodemográficos de cliente.
• Completados con datos transaccionales.
• Ampliados con NPS y expandidos con literales de reviews de Google My Business, Truspilot, Glassdoor cuando procede…

El resultado: la IA revela patrones de comportamiento que la observación manual ignora, generando una base de conocimientos robusta sobre la que aplicar nuestro objetivo, a la vez que tiene el contexto de volumetrías.

La IA tiene muy claros unos perfiles que nosotros no conocemos.

Entendiendo los usuarios sintéticos

Lo siguiente que hacemos es descargar el modelado de los usuarios sintéticos sobre plantillas de protopersonas. De esta forma podemos entender, comunicar y transmitir el punto de vista aplicado a cada análisis.

Nos sirve como ancla para aterrizar y crear racord y, sobre todo, para poder revisar en profundidad si los sesgos, contexto o expectativas se cumplen.

Modulando la respuesta

La modularidad de nuestras plantillas garantiza que los insights sean transversales. No trabajamos para un departamento, trabajamos para la consistencia del ecosistema digital, asegurando que cada optimización refuerce el valor de marca.

Otras soluciones con IA para equipos de CRO

Cada fase de nuestra metodología, desde el diseño de escenarios y el análisis de rendimiento en el DOM hasta la validación de prototipos y generación de snippets, está diseñada bajo un patrón de excelencia técnica:

1. Todas las soluciones tienen que estar pensadas para poder conectarse con otros equipos (sean o no de Growth).
2. Todas las soluciones han de dar valor de forma autónoma y poder integrarse en otros procesos.
3. Todas las soluciones han de limitar el error y la incertidumbre.

De forma que en la siguiente versión, cuando sigamos mejorando el proceso de CRO, todo evolucione de forma consistente y coherente.

Sin embargo, la experiencia demuestra que los proyectos más complejos rara vez fracasan únicamente por cuestiones técnicas o presupuestarias. Detrás de la mayoría de los problemas suele encontrarse un factor mucho más determinante: la gestión de las personas.

En un entorno donde las empresas afrontan transformaciones cada vez más ambiciosas, con múltiples equipos, tecnologías y objetivos de negocio, el liderazgo se convierte en una capacidad crítica.

No se trata únicamente de coordinar tareas o gestionar riesgos, sino de crear las condiciones necesarias para que las personas puedan aportar su mejor versión incluso en escenarios de alta presión.

El mayor riesgo suele estar en lo que no queremos ver

Uno de los errores más habituales en la gestión de proyectos es retrasar la toma de decisiones cuando aparecen las primeras señales de alerta.

En muchas ocasiones los problemas son visibles desde fases muy tempranas, pero existe la tendencia natural a pensar que acabarán resolviéndose por sí solos o que el equipo encontrará la manera de recuperar el tiempo perdido.

Sin embargo, cuanto más se retrasa una decisión necesaria, mayor suele ser el impacto posterior. Los proyectos no suelen fracasar de forma repentina, normalmente acumulan pequeñas desviaciones que no se abordan a tiempo.

La diferencia entre un proyecto que se reconduce y otro que termina en dificultades suele estar en la rapidez con la que se reconoce la realidad y se actúa en consecuencia.

Más allá del alcance, el plazo y el presupuesto

Existe otra dimensión menos visible que condiciona el resultado de cualquier iniciativa: la capacidad del equipo para sostener el esfuerzo en el tiempo. Tres elementos resultan especialmente importantes:

1. El primero es la competencia, es decir, el conocimiento y la capacidad técnica necesarios para afrontar los retos del proyecto.
2. El segundo es la energía, entendida como motivación, compromiso y capacidad de mantener el rendimiento a lo largo del tiempo.
3. El tercero es el propósito, la comprensión compartida de por qué se está haciendo el trabajo y qué impacto tiene.

Cuando alguno de estos factores se deteriora, los resultados empiezan a resentirse. Y cuando la presión del proyecto termina afectando simultáneamente a los tres, aparecen síntomas como la desmotivación, la rotación, los conflictos internos o la pérdida de compromiso.

En muchas compañías todavía persiste la idea de que los mejores resultados se obtienen incrementando la presión sobre los equipos. Sin embargo, la experiencia demuestra que la presión sostenida rara vez mejora el rendimiento a largo plazo.

Los equipos funcionan mejor cuando existe claridad, autonomía y confianza. Las personas necesitan comprender qué se espera de ellas, disponer de espacio para tomar decisiones y sentir que forman parte de una misión compartida.

Por eso, el liderazgo efectivo no consiste en exigir más, sino en crear las condiciones necesarias para que el equipo pueda dar lo mejor de sí mismo. La diferencia puede parecer sutil, pero tiene un impacto enorme en la forma en que las personas afrontan los desafíos cotidianos.

Los comportamientos importan más que las etiquetas

Otro error frecuente consiste en interpretar a las personas a partir de juicios subjetivos. Expresiones como “tiene mala actitud” o “no está comprometido/a” son habituales en muchos entornos profesionales, pero aportan poca información útil para mejorar una situación.

Resulta mucho más efectivo centrarse en comportamientos observables. Los comportamientos pueden describirse, analizarse y modificarse. Las interpretaciones, en cambio, suelen generar discusiones estériles y dificultan la búsqueda de soluciones.

Esta aproximación permite mantener conversaciones más objetivas y constructivas, tanto en la gestión de equipos como en los procesos de feedback y desarrollo profesional.

Toda organización convive con tensiones, desacuerdos y conflictos. Forman parte natural de cualquier proyecto donde intervienen múltiples personas con objetivos, experiencias y perspectivas diferentes.

El verdadero problema no es la existencia del conflicto, sino su gestión. Cuando las conversaciones difíciles se posponen de manera sistemática, los problemas tienden a crecer y a volverse más complejos. Lo que inicialmente era una diferencia de opinión puede acabar convirtiéndose en una fractura dentro del equipo.

La capacidad para abordar estas situaciones de forma temprana y constructiva es una de las competencias más importantes del liderazgo moderno.

La preparación sigue siendo una ventaja competitiva

En un contexto marcado por la velocidad, existe una tendencia creciente a comenzar proyectos cuanto antes. Sin embargo, acelerar el inicio no siempre implica avanzar más rápido.

Las iniciativas complejas requieren una fase previa de preparación en la que se definan aspectos fundamentales como el modelo de gobierno, los criterios de decisión, las responsabilidades, la arquitectura o la gestión de stakeholders. Dedicar tiempo a construir estos cimientos suele reducir significativamente los problemas posteriores.

La preparación no es burocracia. Es una inversión que permite ejecutar con mayor claridad, reducir incertidumbres y evitar retrabajos costosos.

No existe un único estilo de liderazgo válido

Uno de los grandes errores en la gestión de empresas consiste en pensar que existe un perfil de líder universal capaz de funcionar en cualquier situación.

La realidad es mucho más compleja. Un proyecto de innovación, una transformación tecnológica, una integración empresarial o una iniciativa internacional requieren capacidades y comportamientos diferentes. El liderazgo efectivo depende siempre del contexto.

La pregunta correcta no es quién es el mejor líder, sino quién es el líder más adecuado para cada desafío.

Al final, todos los proyectos terminan enfrentándose a una misma verdad: la realidad acaba imponiéndose. Los riesgos que no se gestionan siguen existiendo. Los problemas que se ignoran no desaparecen. Las decisiones aplazadas terminan teniendo consecuencias.

Por eso, una de las funciones más importantes del liderazgo consiste en mirar la realidad de frente, comprenderla y actuar sobre ella con criterio y honestidad.

Porque detrás de cualquier transformación tecnológica, metodología o estrategia empresarial siempre hay personas. Y son ellas quienes, en última instancia, determinan el éxito o el fracaso de un proyecto.

El desarrollo de los sistemas conversacionales representa una de las trayectorias científicas y tecnológicas más transformadoras dentro del campo de la IA y el PLN. Durante décadas, la ambición de la informática ha sido dotar a las máquinas de la capacidad para comprender, interpretar, asimilar y generar el lenguaje humano con toda su inherente riqueza estructural.

Esta evolución histórica ha transitado a través de múltiples enfoques radicalmente distintos. Comenzamos con sistemas rígidos basados en heurísticas estructurales, pasando por la adopción de modelos estadísticos y probabilísticos, hasta desembocar finalmente en las arquitecturas neuronales de aprendizaje profundo que dominan el panorama científico actual.

El análisis de esta progresión revela una transformación en la representación del lenguaje. En sus inicios, el lenguaje fue tratado como una secuencia de símbolos gobernados por reglas sintácticas. Con el tiempo, esta concepción determinista cedió ante una comprensión estocástica, donde las palabras se convirtieron en distribuciones de probabilidad. Hoy en día, el lenguaje se concibe matemáticamente como un espacio semántico y multidimensional codificable en vectores.

Esta transición ha permitido que las máquinas capturen matices sutiles, dependencias a largo plazo y contextos de una manera que imita, e incluso supera en ciertas tareas de clasificación y generación, la capacidad de procesamiento del cerebro humano. En esta serie de posts vamos a examinar los hitos fundacionales que han estructurado la evolución de los sistemas conversacionales.

ELIZA, el primer asistente conversacional

En las etapas iniciales de la inteligencia artificial, durante las décadas de 1950 y 1960, se asumía de manera generalizada que la comprensión del lenguaje humano por parte de una máquina podía lograrse mediante la codificación de reglas gramaticales, diccionarios sintácticos y árboles de decisión algorítmicos. En este contexto, surgió ELIZA (1966), el primer hito verdaderamente disruptivo en la simulación de interacciones conversacionales.

ELIZA fue diseñado como una plataforma de investigación para el estudio de la comunicación en lenguaje natural entre el ser humano y la máquina. No poseía una comprensión ontológica del significado de las palabras que procesaba. En su lugar, implementaba un sistema de reconocimiento de patrones léxicos y emparejamiento de secuencias textuales.

El núcleo arquitectónico de ELIZA dependía de un conjunto de reglas que se activaban mediante la detección de palabras clave (keywords) en el texto de entrada introducido por el usuario humano. Una vez que el sistema identificaba una palabra clave dentro de la cadena de caracteres de entrada, activaba las reglas asociadas a esa palabra para generar una respuesta que resultara superficialmente coherente y con conexión con el enunciado original.

Para lograr esta ilusión de comprensión interactiva, su creador tuvo que estructurar la ingeniería de su sistema abordando cinco problemas técnicos que, en retrospectiva, sentaron las bases operativas de todos los primeros sistemas conversacionales:

1. La identificación algorítmica y jerarquización de palabras clave dentro de una oración.
2. El descubrimiento y aislamiento del contexto mínimo necesario para emitir una respuesta adecuada.
3. La elección de transformaciones sintácticas para invertir pronombres (por ejemplo, transformar "mi" en "tu").
4. La generación de respuestas predeterminadas genéricas en ausencia de palabras clave reconocibles en el input del usuario.
5. La capacidad de edición modular que permitiera a los programadores actualizar y expandir los scripts del programa de forma dinámica, sin tener que reescribir el motor central.

El guión más famoso y estudiado de ELIZA, denominado DOCTOR, simulaba la interacción con un psicoterapeuta de la escuela rogeriana. Su papel se centraba en reflejar las afirmaciones del paciente a través de preguntas abiertas y reiteraciones. De esta manera, minimizaba casi por completo la necesidad de que el sistema aportara nuevo conocimiento del mundo real o emitiera juicios inventados.

A pesar de su total dependencia del emparejamiento de patrones y de operar sin ninguna retención de contexto a largo plazo, ELIZA transmitía una ilusión psicológica de empatía, inteligencia y comprensión profunda en sus usuarios. Muchos de ellos, incluyendo al propio personal del laboratorio, llegaron a establecer vínculos emocionales con el programa, confiándole intimidades personales. Este fenómeno de antropomorfización de sistemas informáticos fue posteriormente acuñado en la literatura científica como el "Efecto ELIZA".

A pesar del triunfo de ELIZA, las limitaciones de los enfoques puramente basados en reglas pronto se hicieron evidentes para la comunidad de investigación. Fenómenos lingüísticos cotidianos como la ambigüedad polisémica, la ironía, el sarcasmo, la dependencia del contexto pragmático, las anáforas y la infinita riqueza estructural de la sintaxis humana hacían imposible compilar un conjunto de reglas manuales lo suficientemente exhaustivas como para manejar cualquier tipo de conversación.

La escalabilidad de estos sistemas era nula. Añadir nuevas reglas generaba conflictos lógicos con las reglas preexistentes, y los sistemas fallaban. Se necesitaba urgentemente un cambio hacia sistemas que pudieran aprender de los datos en lugar de depender del conocimiento codificado a mano.

La transición estocástica: modelos estadísticos y enfoques basados en aprendizaje automático

Para superar la rigidez del enfoque actual, el campo del PLN experimentó un cambio entre las décadas de 1980 y 1990. La comunidad científica adoptó progresivamente modelos estadísticos y enfoques pioneros basados en el aprendizaje automático. Estas técnicas, basadas en modelos de n-gramas y otros métodos probabilísticos (por ejemplo, los HMM, Hidden Markov Models), permitieron superar algunas de las limitaciones de los sistemas puramente basados en reglas.

Este nuevo paradigma abandonó por completo la formulación manual de reglas gramaticales en favor de la extracción automática de patrones de co-ocurrencia a partir de grandes corpus de texto estructurado. El pensamiento en el que se apoyaban era que la gramática y el significado no necesitaban ser codificados si podían ser inferidos estadísticamente observando cómo las personas realmente empleaban el lenguaje en la práctica.

Un modelo de n-gramas busca predecir la probabilidad estadística de la aparición de una palabra específica condicionada por la secuencia de las palabras que la preceden inmediatamente. Este enfoque se basa en la asunción matemática de Markov, la cual postula de manera simplificada que la probabilidad de un estado futuro (la próxima palabra) depende única y exclusivamente de un número limitado e inmediato de estados pasados, ignorando por completo el contexto histórico previo a esa ventana de palabras.

Aunque estos modelos probabilísticos permitieron a las máquinas generar texto de manera autónoma y mejoraron significativamente la precisión en tareas críticas de la época como el reconocimiento automático de voz, la corrección ortográfica y la traducción automática, arrastraban problemas matemáticos. El más destacado de ellos era el problema de la dispersión de datos. A medida que el tamaño de la ventana de contexto aumentaba para intentar capturar dependencias gramaticales más largas y complejas, la probabilidad de encontrar esa secuencia exacta de palabras en los datos de entrenamiento disminuía exponencialmente.

A pesar de que las técnicas estocásticas y probabilísticas supusieron un avance monumental frente a los sistemas basados en reglas, seguían acarreando un problema representacional. Las representaciones computacionales comúnmente utilizadas en esta época eran vectores dispersos del tipo "one-hot encoding", donde cada palabra del vocabulario correspondía a un vector que tenía la longitud exacta de todo el vocabulario conocido (a menudo decenas de miles de dimensiones), con un único valor de "1" en el índice correspondiente a la palabra y "0" en todos los demás índices.

Para la máquina, esta representación binaria no se correspondía con una similitud semántica. El modelo estadístico no poseía ninguna forma de reconocer estructuralmente que las palabras "perro" y "gato" compartían un campo semántico cercano al ser animales domésticos, y las trataba con la misma distancia conceptual que tendría "perro" respecto a la palabra "coche" o "depuradora". Es decir, para que el sistema pudiera aprender las propiedades de cada palabra de forma completamente aislada, necesitaba apoyarse en grandes volúmenes de datos.

Conclusiones

La evolución de los primeros sistemas conversacionales nos demuestra que la fuerza bruta nunca supera a la adaptabilidad técnica. Pasar de arquitecturas basadas en el trabajo manual de reglas a motores probabilísticos sentó las bases de la automatización moderna. En el siguiente post continuaremos avanzando cronológicamente en la evolución de los sistemas conversacionales y procesamiento del lenguaje natural.

Referencias y enlaces

• ELIZA
• http://deixilabs.com/eliza.html#
• Modelos de n-gramas y evaluación estadística
• Modelos Ocultos de Markov (HMM)

Más allá de los lanzamientos individuales, las novedades de las últimas semanas reflejan cuatro tendencias de fondo:

• La aparición de una nueva generación de modelos con capacidades agénticas avanzadas.
• La integración de la IA en plataformas de consumo masivo.
• La convergencia entre infraestructura y desarrollo de software asistido por IA.
• La creciente importancia de la identidad y el cumplimiento normativo.

Claude Fable 5: cuando un modelo de IA se convierte en un asunto de seguridad nacional

Anthropic presentó Claude Fable 5 como una versión comercialmente accesible de Mythos 5, el modelo que muchos analistas consideran el sistema de IA más avanzado desarrollado hasta la fecha.

Según la compañía, Fable 5 comparte la misma arquitectura y capacidades fundamentales que Mythos, aunque incorpora salvaguardas adicionales para limitar determinados usos y facilitar su despliegue público.

Los primeros benchmarks y pruebas independientes apuntan a mejoras significativas en programación, razonamiento complejo y, especialmente, en capacidades agénticas.

La diferencia respecto a generaciones anteriores no parece estar únicamente en la calidad de las respuestas, sino en la capacidad del modelo para planificar, ejecutar y supervisar tareas de forma autónoma durante periodos prolongados.

Sin embargo, el lanzamiento ha estado marcado por un acontecimiento inesperado. Apenas unos días después de su presentación, el Gobierno de Estados Unidos emitió una directiva de control de exportaciones que obligó a Anthropic a suspender el acceso a Fable 5 y Mythos 5 para ciudadanos extranjeros.

Ante la dificultad de aplicar la restricción de forma inmediata y selectiva, la compañía decidió desactivar temporalmente ambos modelos para todos los usuarios mientras trabajaba en mecanismos de cumplimiento.

La justificación oficial estaría relacionada con preocupaciones sobre posibles técnicas de jailbreak capaces de eludir algunas de las protecciones del modelo.

Anthropic, sin embargo, ha cuestionado públicamente la gravedad de estas vulnerabilidades y sostiene que los escenarios mostrados por el gobierno no representan capacidades exclusivas de Fable 5, sino comportamientos que también pueden observarse en otros modelos avanzados disponibles en el mercado.

Apple redefine Siri apoyándose en Google

Dos años después de anunciar sus ambiciones en inteligencia artificial, Apple ha presentado la nueva generación de Siri. El movimiento resulta especialmente interesante porque confirma una estrategia híbrida que combina modelos de Google con la infraestructura de privacidad de Apple.

Según las informaciones publicadas, Apple estaría pagando aproximadamente mil millones de dólares anuales por licenciar una versión personalizada de Gemini. Sin embargo, la compañía no se limita a integrar un chatbot externo.

En lugar de ello, utiliza procesos de destilación para crear versiones optimizadas capaces de ejecutarse localmente en iPhone y Mac, manteniendo al mismo tiempo una arquitectura compatible con su infraestructura de Private Cloud Compute.

Desde una perspectiva técnica, el enfoque es significativo porque demuestra que la diferenciación ya no reside únicamente en entrenar el modelo más potente. Apple ha optado por aprovechar la capacidad de investigación de Google mientras mantiene el control sobre la experiencia de usuario, el hardware y la privacidad.

Las nuevas capacidades de Siri reflejan esta evolución. El asistente puede interpretar el contexto de la pantalla, coordinar información entre aplicaciones, ejecutar múltiples acciones en paralelo y utilizar datos personales para resolver tareas complejas sin necesidad de instrucciones detalladas.

En la práctica, Siri deja de comportarse como una interfaz de búsqueda avanzada y comienza a acercarse al concepto de asistente digital contextual.

La apuesta de Apple también evidencia otra realidad del mercado: el desarrollo de modelos fundacionales se está concentrando en un número cada vez más reducido de actores, mientras que otros gigantes tecnológicos compiten mediante integración, distribución y experiencia de usuario.

SpaceX adquiere Cursor y refuerza la integración vertical de la IA

Otro movimiento especialmente relevante ha sido la adquisición de Cursor por parte de SpaceX.

Cursor se había convertido en uno de los agentes de programación más populares del mercado, compitiendo directamente con soluciones como Claude Code, Codex o Antigravity. Sin embargo, como muchas compañías especializadas en IA aplicada, dependía de infraestructura de terceros para ejecutar y entrenar sus modelos.

La operación permite a SpaceX integrar en una misma organización tres elementos estratégicos: infraestructura computacional, desarrollo de modelos y herramientas de productividad para equipos de desarrollo.

Esta integración vertical se está convirtiendo en una tendencia cada vez más visible. Las compañías que controlan simultáneamente capacidad de cómputo, modelos y distribución poseen ventajas significativas en costes, velocidad de iteración y optimización del producto final.

Para Cursor, el acceso directo a recursos computacionales elimina una de las principales limitaciones que enfrentaba en su crecimiento. Para SpaceX, supone incorporar un producto con una fuerte adopción entre equipos de desarrollo y una posición consolidada dentro del ecosistema de agentes de software.

La identidad digital llega a los modelos de IA

Anthropic también ha anunciado un cambio relevante en su estrategia de acceso a Claude: determinadas funcionalidades avanzadas requerirán verificación mediante documento oficial de identidad y selfie.

Aunque la compañía asegura que estos datos no se utilizarán para entrenar modelos, la decisión marca un punto de inflexión para toda la industria. Durante años, el acceso a los modelos más avanzados ha sido prácticamente anónimo.

La introducción de mecanismos de verificación sugiere que los laboratorios comienzan a considerar la identidad digital como un componente necesario para gestionar riesgos asociados a sistemas cada vez más potentes.

Es probable que este enfoque se extienda durante los próximos años, especialmente en capacidades relacionadas con automatización avanzada, ejecución de acciones en nombre del usuario o acceso a herramientas de alto impacto.

La evolución recuerda a procesos ya observados en sectores como la banca digital o los servicios financieros: a medida que aumenta el poder operativo de las plataformas, crece también la necesidad de mecanismos robustos de identificación.

Suiza impulsa una alternativa open source compatible con la regulación europea

Mientras Estados Unidos continúa liderando el desarrollo de modelos comerciales de gran escala, Europa sigue buscando fórmulas para combinar innovación tecnológica y cumplimiento normativo.

En este contexto, la Swiss AI Initiative, impulsada por EPFL y ETH Zurich, ha presentado Apertus Mini, una familia de dieciséis modelos abiertos desarrollados específicamente para alinearse con los requisitos del AI Act europeo.

La iniciativa resulta especialmente interesante porque publica no solo los pesos de los modelos, sino también los conjuntos de datos y la documentación asociada. Este nivel de transparencia responde directamente a las exigencias regulatorias que están emergiendo en Europa.

Aunque las capacidades actuales de Apertus Mini parecen orientadas principalmente a sistemas RAG y aplicaciones empresariales de bajo riesgo, el proyecto ofrece una visión clara de cómo podría evolucionar el ecosistema europeo de IA: modelos más pequeños, completamente auditables y diseñados desde el inicio para operar dentro de marcos regulatorios estrictos.

Conclusiones

Las novedades de junio de 2026 muestran una industria que está entrando en una nueva fase de madurez.
Los modelos ya no compiten únicamente por obtener mejores resultados en benchmarks, sino por convertirse en agentes capaces de ejecutar tareas complejas de forma autónoma.

Al mismo tiempo, la inteligencia artificial se integra de manera cada vez más profunda en productos de consumo masivo, mientras que las cuestiones relacionadas con infraestructura, identidad digital y cumplimiento regulatorio adquieren una relevancia creciente.

Si 2024 y 2025 fueron los años de la carrera por construir modelos cada vez más potentes, 2026 empieza a perfilarse como el año en que la industria busca convertir esa potencia en sistemas útiles, gobernables y escalables para millones de usuarios.

Imagina sustituir la entrega de un panel con veinte gráficos por una interfaz conversacional conectada a tus datos. No se trata de eliminar los dashboards, sino de romper ese bucle infinito de modificaciones manuales. Pero cuidado: sin una capa semántica sólida y métricas bien definidas, solo estaremos acelerando la velocidad a la que obtenemos respuestas equivocadas.

¿Y si el próximo informe no fuera un informe? La analítica conversacional

Seguro que te suena esta escena: un/a responsable de negocio necesita saber por qué han caído las ventas en la última semana. Abre un panel en Data Studio, empieza a cruzar dimensiones, aplica varios filtros y, al final, acaba llamando al/la analista ya sea porque no se fía del número que ve o porque aparece una pregunta imprevista, como un cambio en el rendimiento de una campaña, y el flujo se rompe.

El dashboard ha pasado de ser una herramienta de democratización a convertirse en una barrera técnica que requiere interpretación constante.

La analítica conversacional cambia por completo este paradigma. No consiste en colocar un clon de ChatGPT para que acceda alegremente a tus bases de datos, sino en estructurar interfaces en lenguaje natural capaces de interpretar el contexto de negocio. Pasamos de una exploración basada en hacer clics en filtros visuales a un modelo donde el origen está gobernado, un agente procesa la pregunta, devuelve la respuesta estructurada y sugiere los siguientes pasos. Los paneles visuales mantendrán su utilidad para la monitorización de KPIs recurrentes, pero dejarán de ser la única ventanilla disponible para interrogar al dato.

Por qué necesitas una capa semántica antes de hablar con tus datos

Poner un modelo de lenguaje frente a una base de datos sin intermediarios es una receta segura para el desastre operativo. Los modelos de inteligencia artificial no entienden por defecto la lógica de tu negocio. Si una consulta pide calcular el volumen de usuarios del último mes, el sistema puede ejecutar una consulta sobre una tabla de forma perfecta técnicamente, pero conceptualmente errónea para tus analistas.

La IA no es adivina, es un procesador de contexto. Si le preguntamos por los ingresos del último mes, el agente debe saber si nos referimos a pedidos realizados, cobrados o netos de devoluciones. Sin una capa semántica que actúe como diccionario oficial, el sistema mezclará dimensiones incompatibles y nos meterá en un infierno operativo de decisiones basadas en datos falsos. El reto no es el chat en sí, sino la gobernanza que hay detrás. Una capa semántica actúa como el traductor universal que estandariza las definiciones de negocio antes de que lleguen al modelo.

Herramientas como Looker estructuran su propuesta sobre este principio. Looker Conversational Analytics no realiza consultas directas al almacenamiento, sino que interactúa con su capa semántica compartida. Cuando preguntas cómo ha funcionado el funnel de conversión, la tecnología traduce esa petición basándose en las reglas, dimensiones y métricas ya centralizadas y auditadas por el equipo de datos. Si tu organización no cuenta con un criterio unificado sobre qué es un cliente activo o una venta neta, el agente analítico no lo va a solucionar por arte de magia, sino que propagará el error a mayor velocidad.

¿Qué hay bajo el capó de un agente analítico?

¿Qué diferencia realmente a un bot de preguntas frecuentes de un verdadero agente analítico? Un chatbot convencional se limita a predecir la siguiente palabra basándose en un entrenamiento estático. Un agente analítico cuenta con capacidades de ejecución para conectarse a APIs, analizar esquemas de datos, generar visualizaciones dinámicas en tiempo real y respetar de forma estricta los permisos de acceso del usuario.

En el ecosistema actual vemos movimientos muy definidos en esta dirección:

• El servidor MCP para Google Analytics 4

El Model Context Protocol permite conectar sistemas LLM externos de forma directa con la API de GA4. Actualmente esta integración está restringida a operaciones de lectura, permitiendo consultar datos y dimensiones de comportamiento digital sin riesgo de alterar la configuración de la propiedad.

• Looker Conversational Analytics y Dashboard Agents

Esta infraestructura de Google Cloud combina modelos fundacionales con BigQuery para habilitar exploraciones multiturno. Esto permite al usuario preguntar la causa de una bajada de ingresos y repreguntar sobre el dato devuelto, manteniendo el hilo de la investigación sin perder las restricciones de seguridad por filas o columnas que tenga asignadas su rol.

Cuando el chatbot alucina con tu embudo de conversión

El mayor enemigo de la analítica conversacional no es el coste del procesamiento, sino la pérdida de confianza de los equipos de negocio. Si un/a responsable de negocio detecta una sola cifra incoherente en un informe generado por un agente, descartará el sistema por completo y volverá al tradicional dashboard en Data Studio, o peor aún, a las hojas de cálculo.

Los riesgos en este entorno son técnicos y operativos:

• La trampa de los términos ambiguos

El concepto "usuario" puede significar una cookie registrada en GA4, un registro único en el CRM o un cliente con transacciones activas en el backend. Sin un mapeo estricto, el agente mezclará orígenes incompatibles ofreciendo un dato inexacto.

• La ilusión de la respuesta coherente

Un modelo de lenguaje siempre estructurará sus respuestas de forma convincente y con un tono profesional, incluso cuando haya interpretado erróneamente un intervalo temporal o un filtro geográfico.

• El infierno operativo de los permisos

Si el agente no hereda las políticas de seguridad de la empresa, un usuario de marketing podría terminar consultando datos salariales o márgenes de beneficio restringidos mediante una simple pregunta bien redactada.

¿Cómo se redefine el rol del analista digital?

Vamos con algo importante: con la llegada de los agentes analíticos, el rol de analistas digitales y analistas de datos se transforma por completo. El perfil de analista deja de dedicar su jornada laboral a recolocar gráficos en un lienzo para convertirse en arquitecto/a funcional del ecosistema de información. Su valor ya no se mide por la cantidad de paneles que construye, sino por la robustez del contexto que proporciona a las máquinas.

Las tareas prioritarias del nuevo perfil analítico se desplazan hacia el diseño de diccionarios de datos detallados, la auditoría continua de las respuestas que devuelven los agentes y la conversión de las preguntas de negocio más frecuentes en activos analíticos reutilizables.

El perfil de analista pasa a tener el rol de validación final, asegurar que las reglas de atribución y los objetivos de conversión estén correctamente documentados para que el modelo no trabaje a ciegas en una caja negra algorítmica.

¿Por dónde empezamos a construir este nuevo ecosistema?

Antes de lanzarte a conectar cualquier modelo de inteligencia artificial a tus repositorios de información, es necesario asegurar unos cimientos mínimos. Si intentas automatizar el acceso a un ecosistema de datos desorganizado, solo conseguirás automatizar el caos a gran escala. Puedes utilizar esta lista de verificación para evaluar la madurez de tu sistema:

1. Construye un catálogo de métricas unificado. Documenta por escrito cada indicador de rendimiento, detallando su fórmula exacta de cálculo y las fuentes de origen implicadas.
2. Garantiza la consistencia en el naming. Establece reglas de nomenclatura estrictas para eventos, parámetros de URLs y nombres de columnas en tus almacenes de datos.
3. Implementa una capa semántica. Configura herramientas que actúen como intermediarias entre las consultas del modelo y tus bases de datos productivas.
4. Define una batería de preguntas de validación. Diseña un conjunto de consultas críticas con respuestas conocidas para auditar periódicamente el comportamiento del agente.
5. Establece límites de consumo y acción. Restringe la ejecución de los agentes a entornos de lectura y limita el número de peticiones consecutivas para evitar costes desmedidos.

La analítica conversacional no viene a sustituir el criterio humano, sino a liberar a los equipos del trabajo rutinario de extracción de informes. El éxito de estos sistemas de inteligencia artificial agéntica dependerá directamente de la calidad de la arquitectura y el gobierno que les demos por detrás.

¿Tu organización está preparada para estructurar una capa semántica fiable o vas a seguir enviando correos cada vez que un KPI se desvíe de lo esperado?

Referencias y enlaces

• Model Context Protocol de Anthropic
• Documentación Oficial de Looker Semantic Layer
• API de Google Analytics 4

Uno de los terrenos donde su impacto es más inmediato es la validación documental. Muchas empresas revisan a diario expedientes, contratos, nóminas, documentos identificativos, justificantes, extractos o formularios. Son procesos necesarios, pero a menudo repetitivos, lentos y difíciles de escalar cuando el volumen aumenta.

La idea de escribir este artículo nace de una conversación con un amigo que se enfrenta precisamente a este tipo de trabajo: revisar documentación, comprobar que todo está correcto, detectar ausencias o incoherencias y repetir el mismo proceso expediente tras expediente. A partir de esa necesidad real surgió una pregunta práctica: ¿se podría construir una solución que realizase una primera validación automática y simplificara parte de ese trabajo tedioso sin eliminar el control profesional?

A partir de esa pregunta, este artículo muestra un caso de uso concreto: aplicar document intelligence, inteligencia artificial generativa y procesamiento asíncrono en una arquitectura cloud para automatizar parte de la validación documental en procesos administrativos. No se plantea como un chatbot, sino como una solución de negocio orientada a convertir documentos dispersos en información estructurada, verificable y útil para la toma de decisiones.

El problema: el coste invisible del trabajo administrativo

En muchas organizaciones, una parte importante del trabajo no consiste en tomar grandes decisiones o resolver problemas complejos, sino en comprobar que todo está en orden.

Un expediente llega con varios documentos. Alguien tiene que abrirlos, revisar que están completos, verificar datos, fechas e importes, detectar posibles incoherencias y decidir si el caso puede avanzar. Visto de forma aislada parece sencillo, pero el problema aparece cuando se repite decenas, cientos o miles de veces.

En procesos de alquiler o compra/venta de viviendas, estudios de hipotecas, contabilidad de facturas u operaciones internas, esta revisión puede incluir DNI o NIE, nóminas, contratos laborales, declaraciones de la renta, extractos bancarios, justificantes u otra documentación complementaria. Cada documento exige atención, cada expediente requiere contexto y cada excepción obliga a detenerse.

Ahí aparece la fricción operativa: tiempo administrativo perdido, documentos faltantes que se detectan tarde, errores que pasan desapercibidos, revisiones duplicadas, baja trazabilidad y dificultad para saber en qué estado real se encuentra cada expediente.

El problema no está solo en decidir si un expediente puede avanzar. Muchas veces, el verdadero cuello de botella está en llegar hasta esa decisión: ordenar documentos, clasificarlos, buscar datos relevantes, comprobar faltantes, detectar incoherencias y reconstruir el estado real del expediente.

La idea no es meter IA por meter. La idea es identificar en qué puntos del proceso hay más trabajo repetitivo, más riesgo de error y más pérdida de tiempo. Ahí es donde la IA puede aportar más valor: clasificando documentos, extrayendo información, detectando advertencias y preparando una primera lectura estructurada.

Los porcentajes de mejora siempre deberían medirse en cada caso real, pero como hipótesis de trabajo se puede esperar una reducción significativa del trabajo mecánico de revisión y de los errores detectados tarde. No porque la IA sea infalible, sino porque ayuda a revisar antes, mejor y con más contexto.

El papeleo rara vez parece urgente hasta que se convierte en cuello de botella

Y ahí es donde la inteligencia artificial puede aportar valor. No sustituyendo el criterio profesional, sino cambiando el punto de partida. En lugar de enfrentarse a una carpeta llena de documentos sin procesar, la persona puede recibir una primera lectura estructurada: qué documentos hay, cuáles faltan, qué datos se han extraído, qué incoherencias aparecen y qué casos requieren atención prioritaria.

La IA no elimina la revisión, la ordena

Ya no es necesario revisar todo desde cero. La persona al cargo puede centrarse en las excepciones, los casos dudosos y las decisiones que realmente requieren criterio humano.

¿Qué aporta la IA generativa en este contexto?

La inteligencia artificial generativa es especialmente útil cuando la información no llega como datos limpios, sino en documentos heterogéneos, texto libre, PDFs, imágenes o formularios con estructuras diferentes.

Muchas empresas no tienen un problema de falta de información. Tienen demasiada información, pero dispersa.

En una aplicación documental, el valor de la IA generativa está en interpretar contenido, clasificar documentos, extraer campos relevantes, generar salidas normalizadas y señalar advertencias que una persona pueda revisar.

La clave, bajo mi punto de vista, está en no tratar la IA como una fuente infalible de verdad, sino como una capa de asistencia. Una herramienta capaz de preparar el terreno: leer, ordenar, señalar y priorizar.

El objetivo no es quitar a la persona de la ecuación, sino evitar que tenga que empezar siempre desde cero.

De la idea a la solución

Hasta este punto, la idea es sencilla: usar inteligencia artificial para reducir parte del trabajo manual asociado a la validación documental.

Pero para que esa idea tenga valor real, no basta con conectar un modelo generativo y esperar una respuesta. Una solución útil necesita integrarse en un flujo completo: recibir documentos, almacenarlos, procesarlos de forma segura, extraer información, interpretarla, guardar resultados, mostrar incidencias y permitir que una persona revise el estado del expediente.

Y esto es clave. En un proyecto de este tipo, la IA es solo una parte de la solución. También hacen falta piezas capaces de encajar con el proceso: una interfaz para subir documentos, un backend que orqueste el flujo, almacenamiento seguro, procesamiento asíncrono, servicios de extracción, modelos capaces de interpretar el contenido y una forma clara de presentar resultados.

El objetivo no es que la IA tome la decisión final, sino que haga el trabajo previo más pesado. La idea es que la persona encargada de esta tarea deje de enfrentarse a una carpeta desordenada de archivos y pase a trabajar sobre un resumen claro, trazable y priorizado.

A partir de ahí, la solución se puede entender desde dos niveles complementarios: la arquitectura funcional, que explica qué hace el sistema y cómo fluye el proceso, y la arquitectura cloud, que muestra cómo se implementa técnicamente sobre AWS para que sea segura, escalable y mantenible.

Arquitectura funcional: del documento disperso al expediente validable

El flujo funcional del sistema se puede resumir en una idea: convertir documentos dispersos en un expediente estructurado y revisable.

Para conseguirlo, la solución se plantea como una cadena de responsabilidades. Cada pieza cumple una función concreta dentro del proceso.

El usuario interactúa con una interfaz sencilla para crear expedientes, subir documentos y consultar el estado de la validación. Por debajo, el backend actúa como orquestador: registra cada documento, lo asocia al expediente correspondiente, crea trabajos de procesamiento y coordina el resto del flujo.

A partir de ahí, el sistema evita uno de los errores más habituales en este tipo de soluciones: procesarlo todo durante la subida. En lugar de bloquear al usuario, delega el análisis a un procesamiento asíncrono. Esto permite extraer texto, interpretar contenido y generar resultados sin convertir la experiencia en una espera innecesaria.

La IA entra cuando el documento ya está preparado para ser analizado. Primero se obtiene texto y estructura; después, la inteligencia generativa ayuda a clasificar, extraer campos relevantes, detectar posibles incoherencias y producir una salida normalizada.

El resultado final no es una respuesta aislada de un modelo, sino una visión trazable del expediente: documentos recibidos, estados de procesamiento, datos extraídos, advertencias, incidencias y elementos que requieren revisión profesional.

La clave es que la IA no sustituye el flujo: se integra en él.

Arquitectura cloud: llevar el flujo funcional a AWS

Una vez definida la arquitectura funcional, el siguiente paso es preguntarse cómo llevar ese flujo a un entorno real: seguro, escalable y mantenible.

Una solución de este tipo necesita una base técnica sólida. Los documentos deben almacenarse correctamente, los procesos pesados no deben bloquear al usuario, los resultados tienen que persistirse, los componentes deben comunicarse de forma controlada y los permisos deben gestionarse sin exponer credenciales innecesarias.

Ahí es donde entra la arquitectura cloud.

En esta solución, el flujo funcional se implementa en AWS mediante una combinación de contenedores, servicios gestionados, procesamiento serverless, mensajería asíncrona, base de datos relacional e inteligencia artificial generativa.

No voy a profundizar en la configuración interna de red de la nube, Terraform, Kubernetes o cada servicio AWS utilizado. El objetivo aquí es otro: entender el flujo, el papel de cada componente y cómo la arquitectura permite que la IA transforme documentos dispersos en información útil para la revisión profesional.

A partir de ahí, la arquitectura puede leerse como una cadena de responsabilidades técnicas al servicio del proceso de validación.

El usuario interactúa con una aplicación web para crear expedientes, subir documentos y consultar resultados. Por debajo, React y Nginx construyen el frontend, mientras que FastAPI sobre EKS orquesta el proceso.

Al subir un documento, el backend lo guarda en Amazon S3, registra el trabajo en RDS PostgreSQL y publica un evento en Amazon SQS. AWS Lambda consume ese evento y ejecuta el análisis en segundo plano, evitando bloquear al usuario.

Una vez que Lambda recupera el documento desde S3, empieza la parte realmente diferencial del sistema: transformar un archivo en información útil. Para ello, la solución separa dos responsabilidades. La primera es extraer el contenido; la segunda es interpretarlo.

Amazon Textract se encarga de la extracción. Su papel es obtener texto y estructura a partir de documentos que pueden venir en formatos distintos: PDFs, imágenes, formularios o documentos escaneados. En otras palabras, convierte un archivo visual o semiestructurado en contenido procesable.

Pero leer el documento no basta. En un proceso de validación no solo interesa saber qué pone en un archivo, sino qué significa dentro del expediente.

Ahí entra Amazon Bedrock, que actúa como capa de inteligencia generativa. A partir del contenido extraído, ayuda a clasificar el tipo de documento, localizar campos relevantes, normalizar la información, detectar posibles incoherencias y generar advertencias revisables.

La idea puede resumirse así:

• Textract convierte el documento en contenido. Bedrock convierte el contenido en contexto.
• Textract responde a una pregunta técnica: ¿qué texto y estructura hay en este documento?
• Bedrock ayuda a responder preguntas de negocio: ¿qué tipo de documento es?, ¿qué datos relevantes contiene?, ¿falta algo?, ¿hay alguna incoherencia?, ¿qué debería revisar una persona?

De esta forma, la IA no actúa como una verdad absoluta ni como un juicio final. Actúa como una capa de asistencia que prepara el expediente para que la persona al cargo pueda revisarlo mejor, más rápido y con más contexto.

Qué aporta realmente esta solución

Más allá de la tecnología utilizada, el valor del proyecto está en cambiar la forma de trabajar con documentación:

• Reduce la revisión manual repetitiva.
• Permite detectar antes documentos faltantes o incoherencias.
• Mejora la trazabilidad del expediente.
• Separa la subida del documento del procesamiento pesado.
• Permite que la persona revise incidencias, no carpetas desordenadas de documentos.
• Convierte la IA en una capa de asistencia, no en una caja negra de decisión.

El beneficio no es solo ahorrar tiempo. Es mejorar el punto de partida desde el que trabajan las personas.

Código del proyecto

El código está disponible en este GitHub. El repositorio recoge la implementación completa de la solución: frontend, backend, procesamiento asíncrono, IA y arquitectura cloud.

Conclusión: menos papeleo, más criterio

La solución implementada muestra una idea sencilla: la IA aporta más valor cuando deja de ser una demostración aislada y se integra en un proceso real.

En este caso, la inteligencia artificial no se usa para sustituir al/la profesional, sino para preparar el trabajo: extraer información, clasificar documentos, detectar advertencias y convertir archivos dispersos en un expediente estructurado.

La arquitectura cloud sostiene el flujo. Textract extrae el contenido. Bedrock interpreta la información. Pero la decisión final sigue estando donde debe estar: en la persona que entiende el contexto, y ese es el equilibrio interesante.

No se trata de automatizar por automatizar ni de delegar decisiones sensibles en un modelo. Se trata de quitar ruido, reducir trabajo repetitivo y permitir que los y las profesionales dediquen más tiempo a revisar lo importante.

La IA no viene a quitarte el trabajo todavía pero, si está bien diseñada, sí puede quitarte mucho papeleo. Y quizá ese sea el verdadero impacto inmediato de la IA en muchas empresas: no sustituir de golpe profesiones enteras, sino eliminar el trabajo repetitivo que impide a los y las profesionales aportar más valor.

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

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

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

El reto de gestionar miles de dispositivos distribuidos

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

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

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

La importancia de la monitorización proactiva

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

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

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

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

Del soporte reactivo al soporte inteligente

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

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

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

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

La IA como acelerador, no como sustituto

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

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

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

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

Hacia un nuevo modelo de soporte en retail

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

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

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

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

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

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

Productividad aparente vs calidad real

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

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

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

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

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

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

El problema y sus posibles causas

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

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

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

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

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

Definición de requisitos

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

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

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

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

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

Desprofesionalización de la calidad de software

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

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

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

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

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

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

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

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

Desarrollo consciente

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

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

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

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

A largo plazo, esto puede generar diferentes problemas como:

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

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

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

¿Qué podemos hacer?

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

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

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

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

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

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

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

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

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

1 Organiza el contenido con encabezados claros

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

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

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

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

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

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

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

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

¿Cómo escribir un buen texto alternativo?

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

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

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

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

¿Cuándo añadir un texto alternativo?

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

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

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

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

3 Usa enlaces descriptivos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Evita contenido que pueda causar ataques fotosensibles

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

La regla de los tres destellos

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

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

Cómo crear contenido visual seguro

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

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

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

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

Conclusión

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gracias por acompañarnos durante este viaje.

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

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

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

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

¿Por qué necesitamos trocear y delimitar el contexto?

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

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

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

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

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

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

¿Para qué sirven realmente los ejemplos previos?

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

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

Desgranando el esqueleto de un buen prompt

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

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

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

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

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

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

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

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

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

Conclusiones

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

Referencias

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

La anatomía técnica de un registro incorruptible

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

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

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

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

Del wallet a la mempool

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

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

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

El umbral del "Internet del Valor"

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

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

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

Despliegues operativos fuera de la burbuja

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

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

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

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

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

1. Audita la base tecnológica

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

2. Rastrea la industria

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

3. Aterriza la arquitectura

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

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

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

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

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

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

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

Del valor de los intangibles a la inteligencia de los equipos

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

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

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

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

Cuando la IA ayuda a medir lo que no se ve

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

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

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

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

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

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

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

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

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

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

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

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

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

Lo que aprendió el piloto

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

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

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

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

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

El reto ético: medir sin deshumanizar

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

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

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

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

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

Hacia una nueva generación de herramientas para equipos

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

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

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

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

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

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

Arquitectura

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

Cada componente cumple un rol específico:

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

Metodología

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

Parámetros de prueba

Operaciones medidas

Para AWS CLI se miden cinco operaciones secuenciales:

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

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

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

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

Automatización

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

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

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

Componentes

AWS CLI (S3 nativo)

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

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

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

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

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

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

s3fs-fuse

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

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

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

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

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

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

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

AWS S3 Files (mount.s3files)

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

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

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

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

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

Características clave de S3 Files:

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

Configuración del entorno

El despliegue completo se ejecuta con tres comandos:

# 1. Inicializar OpenTofu
tofu init

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

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

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

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

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

Resultados

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

Lectura secuencial — IOPS

Lectura secuencial — Latencia media (μs)

Escritura secuencial — IOPS

Escritura secuencial — Latencia media (μs)

Throughput de lectura (MB/s)

Throughput de escritura (MB/s)

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

Análisis de resultados

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

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

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

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

2 s3fs-fuse aprovecha el page cache del kernel

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

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

3 S3 Files: consistencia a cambio de rendimiento

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

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

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

4 UPLOAD con s3fs-fuse muestra resultados variables

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

5 LIST es extremadamente rápido con s3fs-fuse

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

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

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

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

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

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

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

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

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

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

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

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

9 S3 Files frente a s3fs-fuse en escalabilidad

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

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

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

Ventajas y desafíos

Ventajas de AWS CLI (Native S3)

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

Ventajas de s3fs-fuse

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

Ventajas de AWS S3 Files

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

Desafíos de s3fs-fuse

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

Desafíos de AWS S3 Files

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

Desafíos de AWS CLI

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

Casos de uso en producción

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

Entrenamiento ML con datasets en S3

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

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

Workspaces colaborativos para agentes de IA

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

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

Pipelines ETL batch

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

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

Exploración interactiva de buckets

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

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

Procesamiento de archivos grandes (> 100 MB)

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

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

Conclusión

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

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

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

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

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

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

Referencias

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