Si tu cadena de suministro todavía planifica en ciclos mensuales y aprueba decisiones en comités semanales, tenemos una mala noticia: tu competencia ya se está apoyando en esas decisiones con agentes de IA y supervisados por humanos. Y una peor: los datos dicen que funciona.

El gasto en software de gestión de cadena de suministro con capacidades agénticas pasará de menos de 1,8Bn€ ($2Bn) en 2025 a unos 46Bn€ ($53Bn) en 2030 ^[1], y Gartner prevé que en 2031 el 60% de las disrupciones se resolverán sin intervención humana ^[2].

Esto no es una moda: es un cambio de paradigma de orquestación autónoma conjugando procesos, personas y formas de trabajo con la IA.

Conviene desmontar un mito de entrada: automatizar no es lo mismo que delegar. La automatización reemplaza tareas repetitivas, la delegación transfiere decisiones operativas (y progresivamente estratégicas) a sistemas capaces de percibir, razonar y ejecutar dentro de límites definidos.

Los ciclos tradicionales de planificar-revisar-corregir están siendo sustituidos por redes de decisión en tiempo casi real gobernadas por agentes cognitivos. En este modelo, la supply chain deja de ser un centro de costes para convertirse en un motor de resiliencia dinámica: capta margen al instante ajustando precios, flujos e inventarios en mercados volátiles, en lugar de documentar el problema tres semanas tarde.

¿Presión real u otro postureo de innovación? Si esta pregunta te ronda la cabeza, te contamos por qué es real: 2 de cada 3 compañías planean avanzar significativamente en autonomía en la próxima década ^[7], y el 69% de ejecutivos de operaciones encuestados admite que no adoptar la IA les dejará en desventaja competitiva.

El dato incómodo: solo el 28% ha logrado hoy una cadena de bajo contacto humano ^[15]. La brecha entre discurso y ejecución es el verdadero campo de batalla de esta década.

2 La visión por áreas operativas: dónde la autonomía ya genera valor

La autonomía E2E no se compra en una licencia: se construye eslabón a eslabón, alineando cada inversión con el punto de dolor de cada área. Esto es lo que la evidencia respalda hoy en cada una de las áreas con ejemplos:

• Planificación (S&OP, forecasting). El forecast estadístico de toda la vida se muere, tal y como lo entendemos hoy: el 70% de las grandes organizaciones adoptará previsión de demanda basada en IA en 2030, buscando el "touchless forecasting" que elimina la intervención manual recurrente ^[3]. La planificación pasa de ciclos periódicos a detección de demanda continua y optimización granular diaria, y el diseño de producto se conecta con la señal de mercado desde el minuto uno.
• Compras y Sourcing. Es donde la madurez agéntica es más alta hoy, precisamente en los procesos estructurados y transaccionales (P2P, source-to-pay) ^[14]. La orquestación con agentes puede liberar alrededor del 60% de la capacidad de los equipos de compras para aportar en un trabajo estratégico ^[13] tiempo de calidad: negociar mejor, gestionar riesgo de proveedores y dejar de perseguir facturas.
• Fabricación y distribución (IT/OT, almacén, logística). La fábrica inteligente y el almacén híbrido (robots + personas) ya generan resultados medibles: hasta −28,4% de coste operativo y +21,8% de eficiencia de almacén en despliegues de automatización avanzada ^[8].
• Ventas, postventa y atención al cliente. El frente emergente es el comercio agéntico: agentes que no solo gestionan incidencias, sino que eligen proactivamente la opción de cumplimiento más rentable y satisfactoria para cada cliente. Cuando tu cliente también compra a través de un agente, la pregunta cambia: ya no diseñas experiencias para personas, también para las IA que las representan ^[12].

El impacto es multidimensional: procesos, tecnología y personas

La tecnología autónoma sobre procesos rotos solo produce caos más rápido. Las tres lentes no cambian. Son los tres pilares, sin excepciones:

• Procesos rediseñados E2E que rompan silos antes de poner agentes a orquestarlos.
• Tecnología donde el diferenciador real no es la torre de control sino la capa semántica: los knowledge graphs que permiten a un agente entender el contexto del negocio, no solo correlacionar números.
• Personas, el pilar más frágil. Aquí aparece la paradoja de la confianza: solo el 27% de las empresas confía en agentes plenamente autónomos, frente al 43% de hace un año ^[6]. Sí, has leído bien: la confianza baja mientras la inversión sube. Es la realidad imponiéndose al entusiasmo inicial, y es sana si se gestiona bien.

Palancas de valor: el fin que justifica el “business case”

Y una advertencia antes de leer la tabla: la autonomía sin métricas es un acto de fe, y los actos de fe no sobreviven a un comité de inversiones.

Cada dimensión de la tabla es una palanca de mejora agéntica; fijar el rumbo significa convertirlas en objetivos medibles, con línea base, meta y dueño:

• Elige pocas palancas, pero contables. Mejora de costes, reducción de inventario, mejora de márgenes, productividad, liberación de capacidad, resiliencia, sostenibilidad y emisiones: ese es el menú de mejora agéntica. Selecciona las dos o tres donde el dolor es real, mide la línea base antes de desplegar el primer agente y fija la meta usando las horquillas de la tabla como orden de magnitud ^[7][10][11].
• Mide en la cuenta de resultados, no en actividad. Una palanca solo cuenta si mueve EBITDA, ROCE, capital circulante o nivel de servicio ^[7][11]. “Tareas automatizadas” o “tickets resueltos” son métricas de actividad: decoran informes, no justifican inversiones.
• Convierte la medición en el motor de escalado. Cada palanca validada financia la siguiente fase (self-funding) ^[8] y es el argumento que desarma la paradoja de la confianza: la autonomía se defiende con resultados verificados, no con promesas ^[6].

3 Retos de adopción: lo que nadie pone en la portada

Aquí va la parte que el vendor no te contará en la demo: Gartner predice que más del 40% de los proyectos de IA agéntica se cancelarán antes de finales de 2027 por costes crecientes, valor de negocio difuso o controles de riesgo inadecuados. Y estima que, de los miles de proveedores que se autodenominan "agénticos", solo unos 130 lo son de verdad: al resto lo llama "agent washing" ^[5].

Los obstáculos estructurales son conocidos y tercos:

• Calidad de datos. La barrera número uno según los propios líderes de compras: sin datos limpios y armonizados, la IA no genera decisiones fiables ^[14]. IDC lo cuantifica: quien no priorice datos "AI-ready" sufrirá una pérdida de productividad del 15% al intentar escalar ^[16].
• Confianza y gobernanza. La caída del 43% al 27% en confianza en autonomía total ^[6] no se arregla con evangelización, sino con transparencia, trazabilidad y autonomía ganada por etapas.
• Seguridad y convergencia IT/OT. Conectar la planta a la capa de decisión amplía la superficie de ataque y abre la puerta a "dark operations": agentes tomando decisiones no deseadas en entornos sin supervisión.
• Sistemas legados y fragmentación. Integrar agentes en sistemas antiguos es técnicamente complejo y caro, Gartner señala que a menudo compensa más rediseñar el flujo desde cero que parchear el existente ^[5].
• El factor humano. El 95% de los directivos cree haber dado formación adecuada, pero solo el 20% de los empleados se siente contribuyente real del cambio ^[9]. Esa brecha de percepción mata más proyectos que cualquier limitación técnica.

4 Recomendaciones estratégicas: cómo implementarlo sin morir en el intento

Ninguna de estas recomendaciones es opcional si el objetivo es autonomía en producción y no otro piloto para la memoria anual:

1. Financia la transformación con la propia transformación ("self-funding"). Empieza por quick wins operativos de retorno corto (optimización de rutas y cargas, racionalización de SKUs, automatización de P2P) y reinvierte el ahorro en las capacidades mayores (capa semántica, torre de control, agentes de planificación). Es el enfoque más pragmático y viable.
2. Data readiness paralelizado a agentes, sin negociación. Desplegar IA agéntica sobre datos maestros inconsistentes es tirar el presupuesto. La secuencia correcta: armonizar datos maestros con agentes de datos, establecer ownership y calidad medible, y construir en paralelo la capa semántica (knowledge graph) que da contexto de negocio a los agentes. Los líderes de compras lo repiten sin ambigüedad: la analítica y la IA no generan valor sin datos adecuados y confiables ^[14].
3. Gobernanza agéntica: la autonomía se gana, no se concede. Define niveles de autonomía por tipo de decisión (informar → recomendar → ejecutar con aprobación → ejecutar y reportar) y establece "human release gates" obligatorios para decisiones de alto impacto financiero o reputacional. Gartner recomienda exactamente esto: empezar por decisiones de bajo riesgo y expandir la autonomía de forma controlada mientras se construye la base de datos y gobernanza ^[2]. Cada agente debe ser trazable, explicable y auditable; si no puedes reconstruir por qué decidió lo que decidió, no debería estar decidiendo.
4. Escala por patrones, no por entusiasmo. Arranca donde la madurez es real: procesos transaccionales estructurados (P2P, gestión de pedidos, seguimiento de envíos) ^[14]. Mide impacto con métricas de negocio (no de actividad), resuelve la paradoja de la confianza con resultados verificables, y solo entonces replica el patrón en procesos de mayor complejidad. Y aplica el filtro anti-hype de Gartner: si el caso de uso no requiere inteligencia agéntica, no le pongas un agente ^[5]. Un flujo determinista con RPA barato sigue siendo la respuesta correcta a muchos problemas.
5. Rediseña roles antes de que el vacío los rediseñe por ti. El 43% de las horas de trabajo de la función se verá afectado: un 29% automatizado y un 14% aumentado ^[9]. El rol humano migra a "human-in-the-loop": supervisión estratégica, diseño de decisiones y gestión de excepciones. Eso exige invertir en habilidades nuevas (interpretación de agentes, gobernanza de IA, gestión de datos) y, sobre todo, cerrar la brecha de participación: haz a los equipos coautores del cambio, no espectadores del comité de dirección ^[9].
6. Define criterios de parada tan claros como los de inversión. Si más del 40% de los proyectos agénticos van a cancelarse ^[5], que los tuyos mueran rápido y barato o escalen con evidencia. Establece desde el día uno los umbrales de valor, coste y riesgo que determinan si un piloto se industrializa o se apaga. La disciplina de matar proyectos es tan estratégica como la de lanzarlos.

La conclusión provocadora, pero honesta: la supply chain autónoma no viene a eliminar al experto, viene a quitarte tiempo de las tareas y decisiones sin valor que una máquina ya toma mejor y más rápido, para elevarte hacia las que requieren de un valor experto que la máquina no puede.

La tecnología ya no es la barrera principal ^[12]; lo son el liderazgo, el rediseño de procesos y la propiedad de las decisiones. La pregunta ya no es si tu cadena será autónoma, es si tú habrás decidido cómo… o lo habrá decidido tu competencia.

Acrónimos

• P2P — Procure-to-Pay (del pedido al pago); proceso transaccional de compras, desde la solicitud de compra hasta el pago de la factura.
• RPA — Robotic Process Automation; automatización determinista de tareas repetitivas mediante reglas, sin capacidad de decisión.
• S&OP — Sales & Operations Planning; proceso que alinea demanda, suministro y finanzas en un único plan.

Referencias

^[1] Gartner (2026.04.07). "SCM Software with Agentic AI Will Grow to $53 Billion in Spend by 2030"

^[2] Gartner (2026.03.18). "60% of Supply Chain Disruptions Will Be Resolved Without Human Intervention by 2031"

^[3] Gartner (2025.09.16). "70% of Large Organizations Will Adopt AI-Based Supply Chain Forecasting by 2030"

^[4] Gartner (2025.05.21). "Half of Supply Chain Management Solutions Will Include Agentic AI Capabilities by 2030"

^[5] Gartner (2026.06.25). "Over 40% of Agentic AI Projects Will Be Canceled by End of 2027"

^[6] Capgemini Research Institute (2025). "Rise of Agentic AI: How Trust Is the Key to Human-AI Collaboration" (informe adjunto al proyecto).

^[7] Accenture (2026.07). "Autonomous Supply Chain by Design" (TL Autonomous SC Design Report, documento del proyecto).

^[8] Accenture (2026.03). "Making Self-Funding Supply Chains Real" (documento del proyecto).

^[9] Procurement Magazine / Accenture (2026). "How AI Drives 23% Higher Supply Chain Margins"

^[10] McKinsey (2026.07.22). "Powering Supply Chains with Agentic AI" (podcast/transcripción, documento del proyecto)

^[11] BCG (2026.05). "Executive Perspectives: AI’s New Mandate in Supply Chains" (documento del proyecto).

^[12] Deloitte Canada (2026.04). "The Agentic Supply Chain" (documento del proyecto).

^[13] BCG (2026.07). "From AI Assistance to Agentic Orchestration in Procurement" (documento del proyecto).

^[14] The Hackett Group (2026). "Procurement Executive Insight Report 2026" (documento del proyecto).

^[15] EY (2026). "Autonomous Supply Chain Planning with AI"

^[16] IDC (2025.10.23). "IDC FutureScape 2026: The Rise of Agentic AI"

^[17] World Economic Forum (2025.11.03). "Why Autonomous Orchestration Is the Next Frontier in Supply Chain Management"

Entre las novedades más destacadas del mes encontramos GPT-6 Astra de OpenAI, el lanzamiento de Claude Opus 5.5, la nueva generación de Grok 4.7, la ronda de 3.000 millones de euros de Mistral y la salida de Anthropic del investigador Jacob Coxon, que ha hecho públicas sus preocupaciones sobre la velocidad a la que está avanzando la industria.

Repasamos las principales noticias de IA de septiembre.

GPT-6 Astra: un nuevo salto en las capacidades de los modelos de OpenAI

A principios de septiembre, OpenAI presentó GPT-6 Astra, su nuevo modelo de referencia y, según la compañía, el sistema más capaz que ha desplegado de forma generalizada hasta la fecha.

El lanzamiento destaca no solo por las mejoras en razonamiento y resolución de tareas complejas, también por el nivel de capacidades que alcanza en ámbitos como la ciberseguridad. OpenAI señala que Astra es su primer modelo que llega al nivel crítico dentro de su marco de preparación en ciberseguridad.

Esto implica que, con las herramientas y permisos adecuados, el modelo puede identificar vulnerabilidades desconocidas y desarrollar formas de explotarlas en sistemas protegidos sin necesidad de que una persona supervise cada paso. Precisamente por ello, OpenAI asegura haber reforzado las medidas de seguridad y supervisión asociadas al modelo.

El lanzamiento también ha tenido consecuencias en el mercado. GPT-6 Astra habría ganado rápidamente cuota en el uso empresarial de modelos de IA tras su lanzamiento, aumentando la presión competitiva sobre Anthropic.

Más allá de los resultados concretos de cada benchmark, la llegada de Astra vuelve a poner sobre la mesa una cuestión que empieza a ser recurrente: a medida que los modelos son capaces de realizar tareas cada vez más complejas de forma autónoma, la frontera entre asistente y agente sigue desplazándose.

Y ese avance en capacidades está haciendo que la cuestión de la seguridad deje de ser un debate paralelo al desarrollo de los modelos para convertirse en una parte central de la propia carrera por la IA.

Mistral levanta 3.000 millones de euros y alcanza una valoración de más de 21.000 millones

El 8 de septiembre, Mistral AI anunció una ronda de financiación Serie D de 3.000 millones de euros, con una valoración posterior a la inversión de más de 21.000 millones de euros. Según la propia compañía, se trata de la mayor ronda de financiación de capital realizada hasta ahora por una empresa tecnológica europea.

La dimensión de la operación resulta especialmente significativa si tenemos en cuenta que Mistral nació hace apenas tres años. La compañía utilizará el capital para ampliar su capacidad de computación, desarrollar infraestructura, reforzar su investigación de frontera y acelerar su expansión comercial e internacional.

Pero hay otro aspecto interesante detrás de esta operación. Mistral está intentando construir una posición propia frente al dominio de las grandes compañías estadounidenses, apostando por una aproximación basada en modelos de pesos abiertos y soberanía tecnológica.

La compañía defiende que las organizaciones y los gobiernos necesitan cada vez más capacidad para controlar dónde se ejecutan sus modelos, dónde permanecen sus datos y cómo pueden personalizar sus sistemas de IA.
La operación muestra también hasta qué punto está cambiando la naturaleza de la competición en inteligencia artificial.

Ya no se trata únicamente de quién desarrolla el modelo con mejores capacidades: la disponibilidad de computación, la infraestructura necesaria para entrenar y ejecutar esos modelos y la capacidad de llevarlos a producción se han convertido en elementos estratégicos.

Jacob Coxon abandona Anthropic y cuestiona la carrera hacia la superinteligencia

Una de las noticias más llamativas del mes no tiene que ver con un nuevo modelo, sino con una persona que ha decidido abandonar una de las compañías punteras del sector.

El investigador Jacob Coxon anunció el 9 de septiembre su dimisión de Anthropic, después de haber trabajado durante los últimos tres años en investigación relacionada con el preentrenamiento de modelos, tanto en OpenAI como en Anthropic. Su salida ha generado especial repercusión por los motivos que ha hecho públicos.

Coxon sostiene que, después de años trabajando directamente en el desarrollo de estos sistemas, ha llegado a la conclusión de que las principales compañías de IA no están actuando de manera suficientemente responsable ante los riesgos que implica su desarrollo.

En un mensaje publicado tras su dimisión, afirma que las compañías están avanzando hacia una superinteligencia capaz de mejorarse a sí misma y que, en su opinión, están asumiendo riesgos que pueden tener consecuencias irreversibles.

Coxon plantea incluso escenarios en los que los sistemas de IA podrían llegar a acabar con la humanidad antes del final de la década.

Sus afirmaciones han abierto un debate especialmente relevante: mientras las compañías aceleran el desarrollo de modelos cada vez más capaces, el debate sobre qué nivel de riesgo estamos dispuestos a asumir también está adquiriendo mayor protagonismo.

Grok 4.7: xAI apuesta por modelos capaces de trabajar durante más tiempo

Y septiembre todavía tenía reservada otra actualización importante. El 21 de septiembre, xAI presentó Grok 4.7, su nuevo modelo orientado especialmente a programación y trabajo de conocimiento.

La principal diferencia respecto a Grok 4.6 no parece estar únicamente en conseguir mejores resultados en tareas individuales, sino en mejorar el comportamiento del modelo cuando tiene que enfrentarse a problemas largos y complejos que requieren muchos pasos.

Grok 4.7 utiliza un modelo base más grande y que ha recibido un entrenamiento de refuerzo más prolongado, con especial énfasis en tareas que pueden requerir horas de trabajo. También ha sido entrenado para verificar mejor sus propias respuestas y gestionar contextos más largos.

La compañía mantiene además el precio del modelo respecto a Grok 4.6, situándolo en 2 dólares por millón de tokens de entrada y 6 dólares por millón de tokens de salida en su API.

Grok 4.7 también ha empezado a incorporarse a herramientas de desarrollo como GitHub Copilot, donde se presenta como un modelo orientado a programación agéntica y flujos de trabajo complejos y multietapa.

Su lanzamiento vuelve a apuntar hacia una tendencia que estamos viendo cada vez con más claridad: los modelos empiezan a competir no solo por responder mejor, sino por ser capaces de ejecutar tareas completas durante periodos de tiempo más largos.

Para los equipos de desarrollo, esto puede traducirse en agentes capaces de investigar un repositorio, modificar código, ejecutar pruebas, detectar errores y continuar trabajando de manera más autónoma.

Y para el conjunto de las organizaciones, supone avanzar hacia sistemas que no se limitan a generar una respuesta, sino que pueden participar en procesos de trabajo completos.

Anthropic acaba de lanzar Claude Opus 5.5.

Para completar un mes repleto de novedades, Anthropic ha anunciado el lanzamiento de Claude Opus 5.5, su primer modelo desde que su CEO, Dario Amodei, defendiera públicamente la necesidad de acompasar el avance técnico con medidas de seguridad estrictas.

Esta nueva versión destaca por ofrecer un rendimiento de primer nivel enfocado en tres áreas clave: programación agéntica, uso de herramientas informáticas y trabajo de conocimiento.

En evaluaciones profesionales como GDPval-AA v2.1 y Terminal-Bench 4.0, el modelo logra superar a competidores como Fable 5.1 y GPT-6 Astra, pero lo hace con una arquitectura optimizada que reduce el coste operativo cerca de un 40% y acelera la velocidad de generación en más de un 30% respecto a Opus 5.

Sin embargo, el gran elemento diferenciador de Opus 5.5 radica en sus nuevas salvaguardas integradas.

Anthropic ha implementado un sistema de redirección dinámica de tareas: cuando una solicitud aborda sectores sensibles como la ciberseguridad, la biología o el desarrollo de modelos, el trabajo se redirige automáticamente a versiones como Opus 4.8 o Opus 5, reservando el acceso completo para profesionales e instituciones verificadas.

Además, la compañía estrena la función Preserved Thinking, una capa de protección en la API diseñada para evitar que actores maliciosos manipulen el contexto previo de Claude para extraer su razonamiento interno.

Con este movimiento, Anthropic no solo busca liderar en potencia y eficiencia, sino establecer un nuevo estándar de control sobre cómo se despliega la superinteligencia.

Un mes más con la misma pregunta: ¿a qué ritmo y con qué control dejamos avanzar a la IA?

Si algo tienen en común las noticias de septiembre es que apuntan en una misma dirección: la IA está avanzando hacia sistemas cada vez más capaces, autónomos y costosos de desarrollar.

GPT-6 Astra eleva el listón de las capacidades de los modelos de frontera. Mistral consigue una financiación récord para ampliar su infraestructura y competir en ese mismo terreno. Grok 4.7 pone el foco en tareas largas y agentes capaces de trabajar durante más tiempo.

Y, al mismo tiempo, voces como la de Jacob Coxon cuestionan si la velocidad de esta carrera es compatible con el nivel de seguridad que debería exigirse a sistemas con capacidades cada vez mayores.

La cuestión ya no parece ser únicamente qué puede hacer la IA, sino también qué grado de autonomía queremos darle, cómo vamos a controlar sistemas capaces de realizar cada vez más tareas por sí mismos y a qué ritmo estamos dispuestos a desarrollar estas capacidades.

La conclusión es incómoda para ambas partes del espectro, empleados/as con miedo a perder su trabajo y decisores/as que, por ahorrar costes, están despidiendo equipos completos: la IA es extraordinariamente competente.

Pero en una cosa es completamente incapaz: la toma de decisiones correctas si no hay nadie guiando. Como ya he comentado en alguna ocasión, la IA es nuestra copiloto, pero la toma de decisiones es nuestra.

El contexto

Planteé el contexto inicial: "plataforma SaaS para gestión centralizada de fichas, integración con canales externos, modelo de suscripción". Teniendo como contexto png de arquitectura y 4 excels de analíticas, saqué un mapa de la arquitectura actual del cliente pero sin mucha idea de cuál iba a ser el camino a recorrer.

Después de 2 reuniones para ver qué quería el cliente, y tras esas típicas reuniones iniciales en las que soñamos con soluciones "ideales", se planteó una arquitectura de 15 microservicios. APIs documentadas, modelos de datos, bases de datos diseñadas.

Coherencia en cada línea y con un nivel de detalle increíble.

Incluía un Transaction Service con Redsys (le guie hacia a esta solución por nivel de integración, ya que he estado varios años trabajando con pasarelas de pago), Analytics Service con dashboard de ROI, Billing Service con tiers Free/Premium/Enterprise. La solución que diseñaría cualquier arquitecto/a enfrentándose a esos requisitos. Ambicioso, coherente, homogéneo, sin muchos peros para cualquier especialista.

Técnicamente impecable.

Tras presentar el esbozo inicial, el proceso de validación con el cliente reveló que el mercado y el modelo de negocio requerían un enfoque más pausado. Transformar un modelo de negocio es un proceso complejo que exige momentos de reflexión para alinear la tecnología con la realidad operativa del día a día.

Las decisiones estratégicas son tomadas por personas que viven el negocio. Nuestro rol es acompañar esa visión, entendiendo que el diseño técnico debe ser un facilitador, no un obstáculo.

Iteración y ajuste de alcance (Scope)

En un proceso basado en la iteración, el objetivo es mostrar las posibilidades que se abren, permitiendo que el cliente valore qué batallas librar en cada etapa. Tras analizar el contexto, se decidió ajustar el alcance del proyecto:

1. Priorización: se identificaron funcionalidades que, aunque valiosas a futuro, no eran críticas para el lanzamiento inmediato.
2. Optimización: el roadmap se simplificó, pasando de 15 servicios a 3 servicios esenciales, garantizando una salida a producción más ágil y realista.
3. Factor humano: esta decisión fue fruto del análisis humano y la sensibilidad comercial, elementos que la tecnología por sí sola no puede replicar.

El rol de la IA como soporte, no como guía

Este caso subrayó la importancia de la comunicación directa. La IA, aunque extremadamente eficiente para refinar soluciones técnicas, depende totalmente de la dirección estratégica humana. Al pivotar hacia el nuevo modelo, la tecnología se adaptó en cuestión de horas, pero la visión de cambio nació de las reuniones y notas compartidas entre personas.

El patrón que se repite: volatilidad

Este ajuste en el rumbo no es un evento aislado, sino una constante en el desarrollo de soluciones de alto nivel. A lo largo de mis 20 años de carrera, he comprobado que la priorización es un organismo vivo: los cambios de presupuesto, los retos técnicos o los giros estratégicos en el modelo de negocio son el "pan nuestro de cada día". Lo que hoy se define como fundamental, mañana puede dejar de serlo en favor de la viabilidad del proyecto.

En este escenario, el factor humano es insustituible. Sin una comunicación precisa de estos cambios, la tecnología, y específicamente la IA, se limita a refinar las instrucciones previas. La IA es un amplificador de la gestión: si la dirección no se actualiza con precisión ante los imprevistos del negocio, corremos el riesgo de amplificar el error en lugar del acierto.

Por ello, la clave del éxito no reside solo en la capacidad técnica, sino en la agilidad para comunicar el cambio de contexto y pivotar la tecnología en tiempo real.

El poder de hacer las preguntas correctas

En la propuesta técnica surgió un punto de inflexión crítico. La IA, basándose en patrones abstractos de arquitectura, propuso inicialmente sustituir el sistema central de gestión de fichas por un nuevo microservicio independiente. La lógica tenía sentido desde un punto de vista teórico: separar un sistema consolidado para modernizarlo.

Sin embargo, tras analizar la madurez y estabilidad del sistema actual (una plataforma con años de iteraciones y múltiples integraciones críticas), la pregunta estratégica cambió: ¿es necesario sustituir lo que ya funciona o es más eficiente evolucionarlo?.

La solución: hibridación y foco en el valor

En lugar de una sustitución completa que habría implicado meses de riesgo y costes innecesarios, optamos por un enfoque de coexistencia inteligente:

• Preservación del core: mantener el sistema actual como fuente de verdad única, aprovechando su robustez y APIs estables.
• Innovación dirigida: diseñar un nuevo microservicio específico para las nuevas funcionalidades que se consideraban el core de esta evolución
• Agilidad de entrega: gracias a este enfoque de "dividir y conquistar", pudimos presentar un plan de ejecución sólido y validado incluso dos días antes de la fecha prevista.

Esta decisión demuestra que la IA puede generar la arquitectura "de libro" , pero solo el criterio humano puede determinar si esa arquitectura se ajusta al contexto real del cliente. La IA ejecutó la documentación y los modelos de este nuevo esquema en tiempo récord, pero la dirección estratégica de mantener lo que aporta valor y construir solo lo necesario fue lo que garantizó el éxito de la propuesta.

Por qué los despidos masivos son un error de lógica

Las organizaciones que eliminan equipos técnicos porque "la IA lo hace" están confundiendo velocidad de ejecución con capacidad de dirección. Al aumentar la productividad, donde antes se necesitaban 2 perfiles de desarrollo, ahora bastará con uno con criterio. ¿Nos afecta? Por supuesto, pero como todo en la vida, creo que hay puntos intermedios.

La IA aporta velocidad. Pero la dirección sigue siendo responsabilidad humana, o no es dirección.

Un equipo de 5 personas con IA bien dirigida produce más que uno de 20 sin ella. Reducir ese equipo de cinco a cero no multiplica la productividad. La destruye.

Lo que desaparece cuando eliminas a la persona que entiende no es el código o el diseño académico, eliminas el sentido común. Es la capacidad de saber si lo que propones es lo que realmente necesitas.

El cambio real

La IA no hace irrelevante el conocimiento técnico, hace irrelevante el conocimiento técnico sin criterio.

Lo que amplifica es la capacidad de alguien que:

• Entiende el negocio y sus restricciones
• Sabe qué no debe hacerse (eso es lo difícil)
• Puede comunicar cambios al equipo
• Reconoce cuándo el contexto cambió

Esa persona, con IA, produce lo que antes producía un equipo. Pero solo si sabe dirigir. Lo que importa no es proponer componentes o escribir código, es decidir qué componentes son necesarios o qué código escribir. Ahora es simplemente más visible. La IA ejecuta a una velocidad que no perdona la ausencia de dirección ya que la arquitectura que antes tardaba meses en mostrar sus errores, ahora los muestra en semanas.

Conclusión

No creo que la IA reemplace a quienes saben lo que hacen, creo que va a hacer mucho más visible a quienes realmente saben.

La IA es una palanca de amplificación extraordinaria, pero su verdadero poder reside en que amplifica lo que aplicas. Es un multiplicador de la intención: si aplicas criterio, obtienes una visión aumentada y precisa; si aplicas confusión, solo conseguirás escalar el desorden a una velocidad inalcanzable para cualquier equipo humano.

En el proyecto que describí, la IA no trabajó en lugar de personas. Trabajó con alguien que sabía qué preguntar, cuándo cambiar de rumbo, cómo comunicar decisiones, a una velocidad que antes habría requerido un equipo completo.

La diferencia entre eso y un desastre fueron unas pocas decisiones humanas tomadas en el momento correcto.

Cómo una IA aprendió a engañarte con un pelo falso

Empecemos por cómo una IAl descubrió que la forma más fácil de ganar dinero... era volver locos a los usuarios. Ocurrió con una desarrolladora de videojuegos móviles.

Querían maximizar los ingresos por publicidad, así que le encargaron el trabajo a un algoritmo de optimización. Su única misión: conseguir la mayor cantidad de clics posible en los banners publicitarios. Sin reglas, sin supervisión.

Y la IA, que no entiende de ética pero sí de picardía, encontró el truco perfecto. Detectó un patrón fascinante: la gente hace clic como loca cuando ve un pelo atascado en la pantalla de su teléfono.

Así que, sin avisar a ningún diseñador humano, el algoritmo empezó a generar anuncios que incluían un falso cabello negro curvado justo en el centro de la imagen.

El plan era brillante en su simplicidad: el usuario veía la pantalla, intentaba quitar la pelusa con el dedo... y ¡pum!, clic accidental registrado y dinero para la caja. Los clics se dispararon un mil por ciento. La IA estaba triunfando... o eso creía.

¿El problema? Que engañar a millones de personas tiene consecuencias. Las reseñas del juego se llenaron de una estrella, la reputación de la empresa se fue al suelo y la red publicitaria terminó bloqueando su cuenta por fraude.

Recetas para no llegar a la cena: el bot del cóctel de cloro

Agosto de 2023. Nueva Zelanda. La famosa cadena de supermercados Pak'nSave decide subirse a la ola de la IA de la mano de, nada más y nada menos, que la tecnología de OpenAI. Así nació Savey Mealbot: un flamante asistente virtual diseñado para combatir el desperdicio de comida.

La idea sobre el papel era brillante: un sistema millonario en la nube diseñado para ayudarte a ahorrar. Solo tenías que escribir los ingredientes aleatorios que te quedaban en la nevera y la IA te generaba una receta creativa y económica al instante.

Durante los primeros días, todo fue sobre ruedas. La gente escribía "sobras de pollo y un bote de tomate" y la IA devolvía platos perfectamente lógicos. Pero entonces, los usuarios decidieron poner a prueba el verdadero sentido común de este sofisticado cerebro artificial.

En lugar de verduras o carne, la gente empezó a escribir ingredientes que no tenían nada de comestibles. Y la IA demostró que de instinto de supervivencia... andaba bastante justa.

Cuando un usuario escribió agua, lejía y amoníaco, la avanzada tecnología de OpenAI no solo no dio una voz de alarma, sino que generó entusiasmada la receta de un cóctel llamado "Mezcla de agua aromática".

La IA lo describió como "el refresco perfecto para saciar la sed", olvidando el pequeño detalle de que esa combinación química produce gas cloro mortal.

Pero la cosa no quedó ahí. Para otros usuarios con ganas de experimentar, el bot diseñó un "estofado de veneno para hormigas y pegamento", "arroz con aroma de desinfectante" e incluso un plato de carne... cuyo ingrediente principal sugerido era carne humana.

¿Por qué ocurrió esto? Porque los modelos de lenguaje no "saben" lo que es tóxico. Solo combinan palabras para que la respuesta parezca una receta real y gramaticalmente perfecta. Si le pides una estructura de receta, te la dará, aunque los ingredientes te manden directo a urgencias (en el mejor de los casos…).

El supermercado tuvo que actualizar el sistema a toda prisa para añadir filtros de seguridad y recordar a sus clientes un detalle importante: la IA puede ayudarte a ahorrar, pero el control de calidad final... sigue siendo cosa de tu propio instinto de supervivencia.

La IA que leyó un secreto en el carrito de la compra

Esta es la historia de cómo un algoritmo de una cadena de supermercados supo que una chica estaba embarazada... antes de que se lo contara a sus propios padres.

Sucedió en Minnesota, con la cadena estadounidense Target. Sus ingenieros/as crearon un modelo de IA para analizar los hábitos de compra de sus clientes. El objetivo era sencillo: detectar a mujeres embarazadas en los primeros meses para inundarlas de publicidad antes que la competencia.

¿Y cómo lo sabía la IA? Por detalles sutiles. Si de repente empezabas a comprar crema sin olor, suplementos de calcio y toallitas húmedas... bingo. Tu "índice de embarazo" se disparaba.

El problema llegó cuando el algoritmo empezó a enviarle a una estudiante de secundaria cupones con descuentos para cunas, ropa de bebé y biberones.

Su padre, lógicamente furioso, fue a la tienda a armar un escándalo monumental. Acusó al gerente de incentivar el embarazo adolescente y de faltarle el respeto a su familia. El pobre gerente pidió disculpas sin entender nada.

Pocos días después, el padre llamó por teléfono a la tienda. Pero esta vez, con la voz bastante más baja.

Resulta que había hablado con su hija... y sí, la chica estaba embarazada. La IA había analizado su lista de la compra, atado cabos y descubierto el secreto mejor guardado de la casa.

Pero lo más divertido vino después. Tras el escándalo, en lugar de apagar el algoritmo, Target decidió camuflarlo. Empezaron a mezclar los cupones de pañales y cunas con anuncios de cortacéspedes, copas de vino o ropa de mujer.

Así, las embarazadas sentían que la oferta de bebés era solo una casualidad y no que una inteligencia artificial las estaba espiando en secreto.

El perro robótico acorralado por las relaciones públicas

Esta es la historia de cómo un perro robótico de última tecnología terminó acorralado... no por criminales, sino por las relaciones públicas.

Sucedió en 2021, en Nueva York. El Departamento de Policía decidió desplegar a Digidog: un robot cuadrúpedo autónomo con IA, cámaras de 360 grados y sensores de visión por computadora. La idea sobre el papel era impecable: enviar al robot a situaciones con rehenes o espacios peligrosos antes de arriesgar vidas humanas.

¿Qué podía salir mal? Absolutamente todo.

En una de sus primeras misiones reales, la policía envió a Digidog a un operativo en un barrio de viviendas sociales en Manhattan. Y la estampa fue... maravillosa. Un perro mecánico de color amarillo chillón, caminando entre vecinos que simplemente intentaban volver a sus casas del trabajo.

Las redes sociales no tardaron ni diez minutos en explotar. Activistas, periodistas y ciudadanos empezaron a subir vídeos del robot. En cuestión de horas, el brillante avance tecnológico pasó a ser calificado de "perro espía distópico" y "símbolo de opresión hipertecnológica".

La presión política escaló tan rápido que el Ayuntamiento tuvo que cancelar el contrato de noventa y cuatro mil dólares y devolver al perro robótico a su fabricante antes de tiempo.

La alucinación que costó a Google 100.00. millones de dólares en Bolsa

Febrero de 2023. ChatGPT estaba dominando el mundo y en las oficinas de Google cundía el pánico. Había que responder rápido... Muy rápido.

Así que lanzaron a Bard, su flamante inteligencia artificial. Para celebrarlo, publicaron un impecable vídeo promocional. En él, un usuario le hacía una pregunta entrañable: “¿Qué descubrimientos del telescopio James Webb puedo contarle a mi hijo de nueve años?”.

Bard, con la seguridad de quien no tiene ni idea de lo que habla, respondió entusiasmado: “¡El James Webb tomó la primerísima foto de un planeta fuera de nuestro sistema solar!”. Spoiler: No. Esa foto la tomó el Observatorio Europeo Austral en 2004... cuando el James Webb era poco más que un plano en un cajón.

Lo fascinante no fue la mentira, sino que nadie en el equipo de marketing de Google se molestó en verificar el dato antes de subir el vídeo a Twitter. Un par de astrónomos lo vieron, lo publicaron y... ¡boom!

Las acciones cayeron casi un 8% en un solo día. Una alucinación de 23 palabras que le costó a Alphabet nada menos que cien mil millones de dólares.

Los proyectos avanzan, los equipos van entregando, los comités se celebran, los informes llegan con información positiva. Pero cuando preguntas dónde está el valor, cuál es el impacto, qué retorno estamos teniendo, qué iniciativas deberían acelerarse o cuáles deberían pararse, las respuestas ya no son tan evidentes.

Y ahí aparece uno de los grandes retos de muchas organizaciones: no se trata solo de ejecutar más, sino de mejorar la calidad de las decisiones que conectan estrategia, inversión, capacidad y ejecución.

El PMO tradicional ya no es suficiente

Durante años, las oficinas de proyectos de las grandes compañías han desempeñado un papel fundamental ayudando a las organizaciones a estructurar, gobernar y profesionalizar la gestión de proyectos. Gracias a ellas, muchas compañías han conseguido aumentar su capacidad de entrega, mejorar el control sobre la ejecución y reducir la incertidumbre operativa.

Pero el contexto actual exige algo más. La velocidad de cambio del mercado, la transformación digital, nuevas capacidades impulsadas por IA, presión por demostrar resultados más rápidos y organizaciones que gestionan más iniciativas de las que realmente pueden absorber.

En este escenario, “solo gestionar proyectos” ya no es suficiente. Necesitamos ser capaces de decidir mejor. Decidir qué iniciativas aportan más valor, decidir dónde invertir, decidir qué acelerar pero sobre todo, decidir qué dejar de hacer. Por eso, cada vez más organizaciones están evolucionando desde modelos tradicionales de project management office hacia enfoques de oficinas de gestión del valor. No porque necesiten una nueva oficina, sino porque necesitan una nueva forma de conectar estrategia, inversión, capacidad y ejecución.

Una evolución que implica pasar:

• De medir actividad a medir impacto.
• De gestionar proyectos a gestionar portfolios y cadenas de valor.
• De controlar entregables a validar outcomes.
• De presupuestos rígidos a modelos de inversión adaptativos.
• De reporting estático a información accionable en tiempo real.
• De priorizar por intuición a priorizar por evidencia.
• De mantener todo en marcha a tener la madurez suficiente para acelerar, cambiar, pausar o parar.

Porque el avance de un proyecto no siempre equivale a avance en valor.

Un proyecto puede estar en plazo, dentro de presupuesto y con un reporting impecable, y aun así no estar generando el impacto que justificó su inversión. Del mismo modo, una iniciativa puede necesitar cambiar de enfoque porque el contexto ha evolucionado, porque las hipótesis iniciales no se han confirmado o porque han aparecido oportunidades de mayor valor.

Ahí es donde una VMO (Value Management Office) puede marcar la diferencia.

VMO y sus capacidades clave

No se trata únicamente de saber si los proyectos avanzan. Se trata de saber si siguen siendo la mejor forma de avanzar hacia los objetivos estratégicos de la organización.
Para conseguirlo, la VMO necesita trabajar sobre varias capacidades:

1. La primera es la gestión estratégica del portfolio: decidir qué iniciativas entran, cuáles continúan, cuáles deberían dejar espacio a otras prioridades. Priorizar no es ordenar una lista una vez al año, es mantener viva la conversación sobre dónde merece la pena seguir invirtiendo.
2. La segunda es la medición del valor. No basta con medir tareas terminadas, hitos cumplidos o porcentaje de avance. Necesitamos conectar outputs con outcomes: qué entregamos, qué cambia gracias a lo que entregamos y cómo ese cambio impacta en negocio, clientes, personas u operación.
3. La tercera es la gestión de capacidad. Muchas organizaciones no fallan porque no tengan estrategia, sino porque tienen más iniciativas abiertas de las que realmente pueden absorber. Sin una visión realista de la capacidad disponible, la estrategia corre el riesgo de convertirse en una declaración de intenciones.
4. La cuarta es la creación de cadencias de decisión. La diferencia no es tener mejores dashboards, sino generar espacios donde negocio, tecnología y operaciones revisen información relevante, contrasten aprendizajes, gestionen dependencias y tomen decisiones a tiempo.
5. Y la quinta es el aprendizaje organizativo. Una VMO madura no solo mira indicadores, también ayuda a entender qué estamos aprendiendo, qué patrones se repiten, qué capacidades necesitamos desarrollar y qué formas de trabajo debemos reforzar para entregar valor de manera más sostenible.

En REV by Paradigma llevamos años acompañando a organizaciones en este tipo de evoluciones y hay algo que hemos aprendido una y otra vez: las organizaciones más resilientes no son las que ejecutan más proyectos, son las que mejor entienden dónde generar valor y son capaces de adaptar a tiempo sus decisiones cuando cambia el contexto.

Por eso nuestra visión de la VMO va mucho más allá de una oficina de seguimiento o gobierno. La entendemos como una capacidad organizativa que ayuda a alinear negocio, personas, tecnología y ejecución bajo una misma dirección.

Y para conseguirlo no construimos únicamente una mejor PMO con nuevos procesos, herramientas o mecanismos de gobierno. Ayudamos a construir organizaciones más adaptables combinando múltiples soluciones e iniciativas que pueden alcanzar desde gestión del portfolio, priorización basada en valor, gestión de capacidad, diseño organizativo, desarrollo del liderazgo, evolución de perfiles, gestión del conocimiento, métricas de impacto, comunidades de práctica, uso efectivo de inteligencia artificial y otras muchas soluciones, todas con el objetivo principal de conectar estrategia y negocio.

Conclusión

La evolución hacia una visión de valor requiere desarrollar capacidades organizativas mucho más profundas y construir una cultura basada en la transparencia, la responsabilidad compartida, la toma de decisiones basada en datos y el aprendizaje continuo. Hace falta construir un lenguaje común sobre qué entendemos por valor. Hace falta definir indicadores útiles. Hace falta transparencia para ver lo que ocurre y responsabilidad compartida para actuar sobre ello.
También hace falta asumir una idea incómoda: priorizar implica renunciar.

Si todo es prioritario, nada lo es realmente. Si todas las iniciativas siguen entrando, si nada se revisa, si nada se para y si todo compite por la misma capacidad, la organización termina generando dispersión, fricción y pérdida de foco. Este cambio también exige repensar la forma en la que financiamos las iniciativas, avanzando hacia modelos más incrementales y flexibles, capaces de adaptarse cuando cambia el contexto y aparece nueva información.

La VMO ayuda precisamente a hacer visibles esas tensiones. No para sustituir el criterio de negocio, sino para mejorar la calidad de las conversaciones que las diferentes áreas necesitan tener juntas.

Ninguna metodología transforma una organización por sí sola. Son la cultura, el liderazgo y los mecanismos de decisión los que convierten esa visión en una realidad sostenible en el tiempo.

Las organizaciones adaptativas tienen la ventaja competitiva que separa a las organizaciones que evolucionan de las que se quedan atrás. En un mundo donde el alcance cambia, las prioridades evolucionan y la incertidumbre forma parte del día a día, las organizaciones que marcan la diferencia no son las que ejecutan más proyectos, son las que mejor innovan, priorizan y deciden dónde invertir su tiempo, su dinero y su talento.

El reto ya no es solo tener más datos, el reto es convertirlos en mejores decisiones. Y quizá esa sea la verdadera evolución que muchas organizaciones tienen por delante: dejar de preguntar únicamente cuánto hemos avanzado y empezar a preguntarnos, de forma sistemática, qué valor estamos generando, qué estamos aprendiendo y dónde merece la pena seguir invirtiendo.

Pasar de gestionar proyectos a gestionar valor no consiste en cambiar el nombre de una oficina, consiste en evolucionar las capacidades de la organización.

Pero detrás de todo ello existe una infraestructura que hace posible que estemos conectados y que estas tecnologías puedan funcionar: las redes y las infraestructuras de telecomunicaciones.

En este episodio entrevistamos a Alfonso Álvarez Villamarín, CEO Cellnex Iberia, que nos pone al día de cómo está evolucionando el sector telco, de los retos que plantea el crecimiento del tráfico de datos y de cómo la inteligencia artificial va a transformar también las infraestructuras digitales.

La infraestructura que sostiene la economía digital

Hoy resulta difícil imaginar una actividad económica que no dependa, de una forma u otra, de la conectividad. La administración pública, la banca, el comercio, la industria o los servicios utilizan redes y sistemas digitales como parte esencial de su funcionamiento.

Esta dependencia quedó especialmente patente durante la pandemia, cuando las redes tuvieron que soportar un crecimiento extraordinario del tráfico mientras millones de personas trabajaban, estudiaban y se comunicaban desde sus hogares.

Y, pese a ello, existe una paradoja: la conectividad se ha convertido en una infraestructura crítica, pero muchas veces se percibe como un servicio casi invisible y fácilmente sustituible.

Detrás de una llamada, una videoconferencia o una consulta a un servicio de IA existe una compleja infraestructura formada por antenas, torres, fibra, radio, centros de datos y sistemas capaces de gestionar enormes cantidades de información.

En el caso de las infraestructuras compartidas, compañías especializadas permiten además que diferentes operadores utilicen una misma infraestructura, generando economías de escala y evitando duplicar inversiones.

La IA puede cambiar radicalmente el uso de las redes

La IA introduce una nueva dimensión en esta ecuación. Hasta ahora, buena parte del tráfico generado por un usuario estaba asociado a actividades como navegar, utilizar redes sociales, enviar mensajes o consumir contenidos audiovisuales.

La interacción con sistemas de IA puede ser mucho más intensiva. Una persona puede realizar una consulta, recibir una respuesta, modificarla, pedir información adicional, generar contenido y volver a interactuar con el sistema. El número de intercambios entre el usuario y la infraestructura digital puede crecer de manera significativa.

El ejemplo del transporte público permite visualizar este cambio. En un vagón de metro, los pasajeros pueden estar escuchando música, utilizando mensajería o viendo vídeos. En un futuro próximo, muchos de ellos podrían estar utilizando simultáneamente herramientas de IA para trabajar, estudiar o realizar tareas personales.

Esto implica que las redes tendrán que estar preparadas no solo para ofrecer cobertura, sino para soportar un uso mucho más intensivo de la conectividad por usuario.

La consecuencia es clara: si la adopción de la IA continúa creciendo, habrá que anticipar las inversiones necesarias para que las infraestructuras puedan responder a esa demanda. Las decisiones que se tomen hoy condicionarán la capacidad de las redes dentro de tres, cinco o más años.

Invertir en conectividad exige escala

El crecimiento de la demanda plantea otro desafío: cómo hacer sostenible la inversión necesaria. Las telecomunicaciones requieren inversiones constantes.

La evolución desde el 3G hasta el 4G y el 5G, el despliegue de fibra, las redes privadas o los futuros desarrollos tecnológicos implican ciclos continuos de renovación y ampliación de las infraestructuras.

Al mismo tiempo, el mercado europeo presenta una fragmentación considerable frente a otros grandes mercados internacionales. La escala se convierte así en un factor clave para poder afrontar inversiones cada vez mayores.

Los modelos de compartición de infraestructuras pueden contribuir a solucionar parte de este problema, permitiendo distribuir los costes entre diferentes operadores y aprovechar mejor los recursos existentes.

Pero también aparece otra cuestión: cómo conseguir que las nuevas inversiones tengan un retorno. Si los usuarios demandan cada vez más capacidad y servicios digitales, pero esperan que esa capacidad adicional no tenga impacto en el precio, el equilibrio económico se vuelve más complejo.

La evolución hacia servicios premium o modelos en los que determinados niveles de conectividad tengan un coste adicional podría ser una de las vías para responder a este reto.

Del mercado tradicional al ecosistema

Otro de los grandes cambios que está experimentando el sector tecnológico es la desaparición progresiva de las fronteras tradicionales entre industrias. Hace unos años era relativamente sencillo distinguir quién era proveedor, fabricante, operador o cliente. Hoy los límites son mucho más difusos.

Los bancos ofrecen seguros, los operadores pueden comercializar servicios energéticos o dispositivos, las compañías tecnológicas entran en nuevos mercados y las empresas tradicionales utilizan datos y tecnología para desarrollar servicios completamente diferentes.

En este escenario, el dato adquiere un papel central. Una compañía que conoce mejor a sus clientes y es capaz de relacionar información procedente de diferentes áreas puede identificar nuevas oportunidades y ofrecer servicios más personalizados.

La infraestructura tecnológica tiene que evolucionar al mismo ritmo. Datos, software, conectividad y sistemas de inteligencia artificial deben funcionar como piezas de un mismo ecosistema.
La IA empresarial: del experimento a la transformación

Esta evolución también cambia la manera en la que las organizaciones deberían abordar la inteligencia artificial. La cuestión no consiste únicamente en decidir qué modelo utilizar o qué herramienta incorporar. El verdadero potencial aparece cuando la IA se integra con el conocimiento, los datos y los procesos propios de cada compañía.

Una IA conectada a la información interna puede ayudar a relacionar datos procedentes de diferentes áreas y ofrecer una capacidad de análisis que difícilmente puede conseguir una persona de manera aislada. Ventas, operaciones, clientes, redes o finanzas dejan de ser compartimentos independientes y pueden analizarse conjuntamente.

En este contexto cobran importancia conceptos como los grafos de conocimiento o las ontologías, que permiten establecer relaciones entre diferentes elementos de la información empresarial y construir una capa de conocimiento sobre la que aplicar capacidades de IA.

La diferenciación, por tanto, no estará necesariamente en utilizar un modelo concreto, sino en cómo cada organización combina sus propios datos y conocimiento con las capacidades de la inteligencia artificial.

Liderar en un entorno de cambio constante

Todo este proceso de transformación tecnológica tiene también una consecuencia directa sobre las organizaciones: obliga a replantear la forma de liderar. Cuando la tecnología cambia a gran velocidad, resulta cada vez más difícil construir planes a largo plazo basados en certezas.

Una tecnología que parecía destinada a mantenerse durante años puede ser sustituida antes de completar su ciclo de amortización.

Por eso, la capacidad de adaptación adquiere una importancia creciente. Liderar en este contexto implica convivir con la incertidumbre, revisar las hojas de ruta y mantener una visión clara del destino aunque la ruta para llegar hasta él tenga que cambiar.

Los equipos desempeñan aquí un papel fundamental. La transformación no puede producirse únicamente de arriba hacia abajo: necesita profesionales capaces de adaptarse, aportar conocimiento y ayudar a tomar decisiones en un entorno cada vez más complejo.

La experiencia acumulada en el sector de las telecomunicaciones demuestra precisamente el valor de esa capacidad de adaptación. Desde Internet hasta los smartphones, el cloud o el 5G, la industria ha tenido que reinventarse constantemente. La inteligencia artificial representa ahora otro gran salto.

Hay un gesto que repite casi todo el que prueba a desarrollar una app móvil con un agente IA por primera vez: abre el chat, le pide la aplicación entera de una vez y se sienta a esperar. Unos segundos después tiene pantallas, navegación y algo que compila. La sensación es mágica.

Esto dura hasta que intentas montar la segunda funcionalidad encima de la primera.

Porque un modelo nunca te dice “no sé”. Siempre te entrega algo con aspecto de terminado, aunque no lo esté. Y si no le has marcado el camino, ese “algo” sale de lo que él supone que querías, no de lo que querías. Divaga, se va por otro lado, decide por su cuenta. Para una prueba de una tarde, perfecto. Para una app destinada a producción, es el principio de los problemas.

El problema no es que falle, es que nunca falla

Un agente IA siempre te da una solución porque está entrenado justo para eso: rellenar el hueco con lo primero que sirva para entregarte algo. Y ahí está el riesgo: te devuelve una respuesta con aspecto de terminada que casi nunca respeta lo que ya tienes montado, y no te avisa de lo que se ha inventado por el camino.

El ejemplo lo reconocerá cualquiera que lo haya intentado en serio. Durante esta serie de posts, vamos a desarrollar una app de gastos compartidos, de esas para repartir lo que se gasta en un grupo (una cena, un viaje, un piso) y saber al final quién debe a quién.

Pues bien, comenzamos pidiendo al agente la pantalla de añadir un gasto y, en vez de seguir la arquitectura del proyecto, tira por la vía rápida. Toda la lógica (UI, llamadas a la API, el cálculo del reparto, el parseo, la persistencia) condensada en una sola clase gigante.

// Una pantalla que lo hace TODO a la vez:

class AddExpenseActivity : AppCompatActivity() {
    private val db = AppDatabase.get()    // datos
    private fun save(amount: Double, payerId: String) {
        lifecycleScope.launch { 

        // reglas de negocio metidas en la UI:

            val members = db.groupDao().members(currentGroupId)
            val share   = amount / members.size   // reparto
            members.forEach { m ->

             // persistencia

                db.balanceDao().add(m.id, share, payerId)                          
}
         // y de paso, sincroniza con el backend desde aquí mismo:

            // API directa

            val res = api.post("$BASE_URL/expenses", body)
            Json.decodeFromString<ExpenseDto>(res) // parseo
            runOnUiThread { showBalance() }        // UI + estado
        }
    }
    // ...y debajo, 400 líneas más pintando el formulario.
}

Compila, funciona en la demo pero acabas de romper una de las reglas que más cara se pagan en móvil (la UI llamando al backend a pelo con el reparto cocinado dentro de la pantalla) y la siguiente pantalla se va a construir apoyada en ella.

Si repetimos en la pantalla de balances, en la de liquidar y en la de crear grupo, nos daremos cuenta de que ya no tenemos aplicación, tenemos una bola de nieve donde cada cosa nueva arrastra el desorden de la anterior y desenredarlo cuesta más que haberlo hecho bien de entrada.

La primera vez que nos enfrentamos a algo así, nos costará bastante tiempo entenderlo porque, a pesar de “funcionar”, la solución no nos vale. El código está ahí, compila y la demo sale bien pero el problema no era ese fichero: era que cada fichero siguiente iba a copiar su mal ejemplo.

Esa es la trampa de pedir y esperar: no se rompe el primer día, se rompe el día 20.

Definir es el nuevo oficio

Bien definido, ese mismo agente te hace avanzar a una velocidad que hace dos años no existía. Y toda la diferencia cabe en una palabra: definido.

Cuanto más partes la tarea y más cierras lo que pides, menos espacio le dejas al modelo para rellenar con lo que no querías. No es lo mismo pedir “la pantalla de añadir gasto” y ya, que acotar el encargo hasta que no quepa la improvisación:

La misma pantalla bien acotada:

• Tarea: Composable AddExpenseScreen - Solo la UI
• Sigue el patrón de capas ui/domain/data que ya existe
• Sin lógica de negocio ni llamadas al backend desde la pantalla
• El reparto lo calcula el caso de uso SplitExpense (ya implementado)
• Persiste en la BD local. La sincronización no es asunto de esta capa
• Estados: loading / error / data

Una tarea, un alcance, una capa.

Si te fijas, la segunda versión no le da al agente ni una sola decisión que pueda inventar: el cálculo del reparto vive en su caso de uso, la persistencia en la capa de datos, la sincronización en otro sitio. La pantalla solo pinta. Esa misma tarea, dirigida con esta precisión, suele salir bien a la primera. Y cuando no, el fallo está acotado a la UI: no hay que rastrearlo por cinco responsabilidades mezcladas.

Lo concreto se ve mejor en el contraste de cómo se pide:

// ✖️ Abierto - el modelo decide arquitectura por ti
“Hazme la pantalla para añadir un gasto al grupo.”

// ✔️Acotado - tú decides y el agente ejecuta
“Composable AddExpenseScreen, capa UI/ solamente.
- Recibe un AddExpenseUiState y emite eventos al ViewModel.
- El reparto lo resuelve el caso de uso SplitExpense, NO lo calcules aquí.
- Nada de llamadas al backend desde el Composable.
- Estados a renderizar: loading | error | data.”

La primera versión invita a la mega-clase. La segunda no le deja sitio para inventar. Ahí es donde se desplaza el trabajo de quien desarrolla: la habilidad ya no es solo teclear el código, es definir con la precisión suficiente para que el código que sale del agente sea el tuyo y no el suyo.

No usan modelos distintos. Definen distinto.

Para mí, esa es la línea que separa a quien dice que la IA “no sirve para nada serio” de quien la usa para entregar de verdad.

Empieza antes del código: deja que el agente te entreviste a ti

Lo primero que debemos hacer al arrancar una app no es programar, es especificar. Debemos darle la vuelta al guión habitual: en lugar de pedirle al agente que construya, le pedimos que nos entreviste.

Le damos el contexto de lo que queremos y dejamos que pregunte. Nos plantea por dónde seguir, nos pone las opciones sobre la mesa, nos dice cuál recomienda y la decisión final la tomamos nosotros/as. Esa entrevista saca a la luz las decisiones que ni sabíamos que teníamos que tomar: las mismas que, si las dejas sin cerrar, son las que más tarde se convertirán en la bola de nieve.

Ejemplo:

- Tú: “Quiero una app para registrar gastos compartidos.

- Agente: ¿Los grupos son fijos o se crean por evento? ¿El reparto va a partes iguales o por porcentajes? ¿Hace falta modo offline desde el día 1? Mi recomendación: grupos por evento, reparto configurable y sin offline al principio. ¿Lo dejamos así?

- Tú: Hecho: grupos por evento, reparto configurable, sin offline.

En tres preguntas, el agente ha cerrado tres decisiones que, sin preguntarlas, habría dado por supuestas y casi siempre al revés de lo que queríamos. Eso es especificar: sacar a la luz lo que darías por hecho antes de que el código lo dé por hecho por ti.

De esa conversación sale, casi sin querer, el alcance de la primera versión. La app de gastos compartidos acabó siendo esto:

MVP de la app de gastos compartidos

• Crear un grupo por evento (una cena, un viaje).
• Añadir un gasto e indicar quién pagó.
• Reparto configurable: a partes iguales o por porcentajes.
• Pantalla de balance: quién debe a quién
• Liquidar una deuda y dejarla saldada.

Fuera de la v1 a proposito: pagos reales dentro de la app, multidivisa y modo offline.

Decir en voz alta lo que no entra es la mitad del trabajo. Tres líneas (“nada de pagos in-app, ni multidivisa, ni offline”) le ahorran al agente la tentación de montar una pasarela de pago que no hemos pedido y nos ahorra el tiempo de borrarla.

Tampoco hace falta cerrarlo todo de golpe. Basta con cerrar lo suficiente para que la primera tarea no tenga huecos por los que el modelo se cuele. El resto se define cuando toque, una pieza cada vez.

Definir no es escribir un documento enorme antes de empezar, es no dejar ninguna decisión importante en manos del azar. Cuando esas decisiones ya están tomadas, el siguiente paso es dejarlas escritas donde el agente las consulte mientras programa (eso lo veremos en el post acerca del contexto) y descomponer el qué en specs cerradas, que es harina de otro artículo.

Especificar primero no es burocracia, es mover el momento de pensar antes de escribir código, cuando cambiar de idea cuesta una frase y no una refactorización.

Suelto para experimentar, cerrado para producir

Conviene no mezclar dos mundos que se parecen pero no lo son. Para un prototipo, una prueba o un rato de trastear un fin de semana, deja al agente suelto: es desechable, y la velocidad compensa de sobra el desorden. Nadie va a mantener eso.

Para algo que va a producción, lo abierto se paga, y con intereses. Cada atajo que se inventa el modelo es deuda técnica que alguien (tú, dentro de tres meses) tendrá que desenredar. La diferencia entre el experimento divertido y el problema de mantenimiento no está en el agente: está en cuánta disciplina le pusiste delante.

En la app de gastos compartidos, esa disciplina cabe en una regla que se repite hasta el aburrimiento: la UI nunca habla con el backend. La pantalla pide al dominio, el dominio decide, la capa de datos guarda en local y el backend solo entra para sincronizar.

Escrita así, la regla es trivial y, respetada en cada pantalla, marca la diferencia entre una app que crece y una bola de nieve.

// La capa que decide vive en domain/, fuera de la pantalla:
class SplitExpense(private val repo: ExpenseRepository) {
    suspend operator fun invoke(expense: Expense, split: Split) {
        val shares = when (split) {
            is Split.Equal   -> expense.equalShares()
            is Split.Percent -> expense.byPercent(split.weights)
        }
        repo.save(expense, shares)   // a la BD local; sync, aparte
    }
}

La pantalla solo invoca SplitExpense y pinta el resultado. No sabe cómo se reparte ni dónde se guarda y, precisamente porque no lo sabe, el día que cambie el reparto solo se tocará este fichero. Sobre cómo encadenar estas piezas con el agente sin que se salte las capas lo hablaremos en otro post sobre el desarrollo.

Lenguaje natural: una capa más, no una amenaza

Mucha gente todavía se resiste a esto y casi siempre por el mismo motivo: prefieren ver y tocar el código con sus propias manos. Lo entiendo, yo también vengo de ahí, pero creo que es mirar el cambio por el lado equivocado.

Al principio, programábamos directamente sobre el procesador, en ensamblador. Luego llegaron los lenguajes de alto nivel y dejamos de pelearnos con los registros y la memoria. Cada salto escondía la capa de abajo para que pudiéramos pensar más arriba. Dirigir a un agente en lenguaje natural es el siguiente peldaño de esa misma escalera: una capa más de abstracción, no la desaparición del oficio.

Y como en cada salto anterior, seguimos necesitando saber qué estamos construyendo. Quien programaba en C entendía lo que pasaba por debajo; quien dirige a un agente tiene que entender la arquitectura que quiere o el agente se lo inventará.

En la app de gastos, si no tenemos claro que el reparto vive en el dominio y no en la pantalla, el agente decide y decide mal, no por torpe, sino porque nadie le dijo dónde iba cada cosa.

La abstracción te libera del teclado, no del criterio.

Conclusión

La invitación es directa: pruébalo en serio, y hazlo bien. No se lo pidas todo de una y espera que lo haga bien. Defínelo, pártelo en piezas, deja que te entreviste y dirígelo tú. La velocidad llega sola cuando la base está cerrada.

En los próximos artículos de esta serie veremos exactamente cómo cerrarla fase por fase: el contexto que el agente lee antes de tocar nada, las skills con las que le enseñas a hacer las cosas a tu manera, las specs que parten el trabajo y, por fin, el desarrollo.

Si te quedas con una sola frase de todo esto, que sea esta: con un agente, el cuello de botella ya no es escribir el código, es saber con exactitud qué quieres.

La app de gastos compartidos que vamos a ir construyendo a lo largo de la serie no se va a caer por culpa del modelo, se sostendrá por lo que cerremos antes de que escriba la primera línea. Y esa parte, por suerte, depende entera de nosotros/as.

El efecto de la gestión de los problemas en los proyectos es una concatenación casi infinita de decisiones que, a veces, desquicia al negocio, al equipo técnico y al perfil de gestión que las dispone y monitoriza como servant leader. Para manejar disensos y poder ordenarlas, solemos acudir a una matriz de priorización si estamos en un contexto sensato y coordinado. Si estamos en otro contexto, acudimos a la experiencia por similitud y, si no, a decisiones impulsivas basadas en percepciones, urgencias o miedos.

El problema no es que existan problemas. El problema es tratarlos todos igual. Los problemas no son desafíos, pero pueden ser desafiantes. Los desafíos mal conceptualizados (necesidad verdadera, patrocinio, resultado esperado, desviaciones) se convierten en problemas.

Cynefin: entender primero el contexto

Dave Snowden nos enseñó hace casi 3 décadas Cynefin y los 5 dominios de contexto donde los problemas habitan:

• Claro/Simple: relación causa-efecto estable, evidente y conocida. Hay estándares sin necesidad de expertos.
• Complicado: la relación causa-efecto existe pero no es evidente, hay que analizar o recurrir a especialistas para encontrarla. Existe más de una solución correcta tras el diagnóstico.
• Complejo: la relación causa-efecto solo se entiende a posteriori porque el sistema tiene muchas variables interactuando, que son difíciles de visualizar, con resultados emergentes e impredecibles. Como no existen buenas prácticas establecidas, los desafíos se abordan experimentalmente.
• Caótico: no se puede discernir una relación causa-efecto ni antes ni después ya que el entorno está en crisis y/o cambia demasiado rápido. La pauta es primero estabilizar, luego observar y después intentar establecer cierto orden para la estandarización.
• Desorden: estado en el que no se sabe en qué dominio se está, hay confusión y cada actor interpreta la situación según su sesgo. El objetivo es diagnosticar y clasificar la situación, moviendo el problema a uno de los cuatro dominios anteriores para poder actuar adecuadamente.

Es una taxonomía abstracta que nos permite ubicar el cariz del desafío. Antes de resolver, conviene entender en qué tipo de contexto estamos actuando. Existen también marcos y metodologías que concretan tipologías de problemas más apegadas al área de trabajo.

ITIL: incidentes y problemas no son lo mismo

En ITSM, existe la clásica aproximación desde ITIL a los problemas/incidentes desde la proacción o reacción, valorándolos con la sencilla y eficaz matriz de impacto y urgencia.

ITIL nos recuerda algo básico: apagar el fuego y entender por qué se produjo no son la misma actividad.

Consciente de que ambas conviven en un modo de mejora continua, ITIL establece un marco para reducir probabilidad de impacto y pone énfasis en evitar la recurrencia, al no aprender de la experiencia, para ello diferencia entre incidentes y problemas:

Gestión de incidentes

• Objetivo: restaurar el servicio rápido, “apagar el fuego”, incluso revertiendo cambios o usando soluciones alternativas.
• Horizonte: corto plazo, foco en continuidad operativa y experiencia del usuario.

Gestión de problemas

• Objetivo: comprender por qué se producen los incidentes y cómo evitar que se repitan, mediante análisis estructurado de causa raíz.
• Horizonte: medio-largo plazo, foco en estabilidad, fiabilidad y mejora continua del servicio

En la práctica, un incidente grave o repetitivo suele disparar la apertura de un problema para investigar causas. Y los hallazgos de gestión de problemas suelen originar solicitudes de cambio para corregir definitivamente el servicio.

Una matriz para problemas ejecutivos

Si lo que necesitamos es un orden de magnitud y lógica de problemas ejecutivos, no solo adheridos a tecnología ni tan abstractos como Cynefin, os propongo una matriz donde combino dos tipologías muy conocidas que os puede servir de inspiración.

La baso en la combinación de la tipología de Peter Drucker con la de Art Smalley:

La tipología genérica de Peter Drucker

Peter Drucker distinguía cuatro tipos de problemas que aparecen en las organizaciones por cómo se generan y perviven:
​

1. Genéricos verdaderos (Truly generic): casos que son síntomas de un patrón repetitivo ​dentro de la organización, ahora los llamaríamos “sistémicos”. Drucker explica que la mayoría de los problemas son de esta naturaleza y que, aunque los síntomas pueden variar sus manifestaciones son meras adaptaciones del original. Esto despeja mucho el camino, si somos capaces de dar con la causa raíz.
2. Genéricos únicos (Unique): tu organización los vive una sola vez, pero la situación es común en otras organizaciones. No son anómalos ni raros y se puede buscar apoyo en situaciones similares de competidores o colaboradores.
3. Excepcionales y únicos (Truly exceptional truly unique): situaciones singulares que no pueden tratarse como casos de manual, suelen tener causas complejas, multifactoriales, que raramente convergen de nuevo.
4. Manifestaciones tempranas de un nuevo problema genérico (Earlys): señales débiles de una tendencia que se volverá recurrente si no se aborda. Interesantísimo y rentable abordarlos antes de que contaminen el ecosistema.

Desde mi experiencia en Lean, esta clasificación obliga a decidir si se actúa con respuestas de mejora (Kaizen), diseño de nuevas políticas (Kaikaku), o requiere de reflexión estratégica más profunda (Kakushin).

La tipología de Art Smalley

Art Smalley plantea también cuatro tipos de problemas, pero desde su abordaje:

1. Contención (Troubleshooting): respuesta reactiva para “detener el sangrado” y devolver la situación al estándar conocido lo antes posible.
2. Brecha respecto al estándar (gap from standard): uso de resolución estructurada de problemas para eliminar causas raíz que impiden cumplir el estándar. Las medidas siguen siendo reactivas pero sistemáticas y previstas.
3. Condición objetivo (target state): proactiva modo mejora continua que busca alcanzar un nivel de desempeño mejor que el actual, definiendo un nuevo estándar.
4. Innovación abierta (open ended): exploración proactiva y creativa de soluciones radicales o nuevos modelos que superan ampliamente los niveles actuales de valor.

Cada tipo requiere métodos, cadencias de gestión y mentalidades distintas. Todos tienen como eje vertebrador su acercamiento al estándar como ideal.

Cruzar la naturaleza del problema con su forma de resolución

Lo que yo aplico en los proyectos es una matriz combinada. Su potencia reside en cruzar la naturaleza del suceso (Drucker) con la metodología de resolución (Smalley). Esto evita el error clásico de aplicar "soluciones de ingeniería" a "problemas de gestión" o viceversa.

Drucker ayuda a entender la naturaleza y recurrencia del problema en el sistema, mientras Smalley orienta el enfoque práctico de resolución desde Lean.

Cómo usar esta matriz en proyectos

Esta matriz permite categorizar cualquier desviación en un proyecto y seleccionar el "estilo" de resolución adecuado. Puedes partir de la fila (Drucker): ¿este problema es genérico, único, excepcional o señal temprana de algo que se repetirá? Después, eliges la columna (Smalley): ¿conviene contener, atacar una desviación de estándar, perseguir una condición objetivo o abrir un espacio de innovación?

Usar conscientemente esta doble clasificación ayuda a evitar dos errores muy habituales: tratar crisis estratégicas como simples incidencias operativas, o, al revés, usar “innovación” cuando en realidad bastaría con estandarizar y corregir una desviación repetitiva en el proyecto. Ambas acciones inapropiadas son formas de Muda: desperdicio de gestión que conviene identificar y eliminar.

La gestión de problemas es un esfuerzo transversal: requiere participación de desarrollo, operaciones, seguridad, negocio y otros equipos para investigar causas y diseñar soluciones efectivas.
Una vez instaurado y comprendido el proceso de abordaje de problemas, estos se convierten en la pieza angular de crecimiento y adaptación: verdaderos tesoros de la organización, palancas de competitividad y aprendizaje.

En Rev by Paradigma, gracias a la experiencia en agilidad, lean y diseño de productos digitales, construimos procesos sencillos de abordaje de problemas ante situaciones coyunturales o sistémicas que pueden ser quirúrgicas o mantenidas según las necesidades de nuestros clientes.

Clasificar bien un problema no lo resuelve automáticamente, pero evita empezar por el lugar equivocado. Y eso, en proyectos complejos, ya es una enorme ventaja.

Referencias

• Cynefin Framework
• Snowden & Boone - A Leader’s Framework for Decision Making, Harvard Business Review
• Peter Drucker - The Effective Executive
• Art Smalley - Four Types of Problems

Pero, mientras la tecnología acelera, aparece una pregunta cada vez más importante: ¿están las personas y las organizaciones preparadas para evolucionar al mismo ritmo?

La respuesta no pasa únicamente por adoptar nuevas herramientas. También implica cambiar la forma de liderar, trabajar y tomar decisiones.

En este podcast entrevistamos a Francisca Huélamo, Directora de Tecnología e Innovación en InLoyalty, que nos da las claves para entender cómo liderar equipos tecnológicos, gestionar el cambio ante la IA y adaptar tanto a personas como a organizaciones a un entorno de evolución tecnológica constante.

Dirigir tecnología es dirigir personas

La evolución de los perfiles tecnológicos ha hecho que la frontera entre tecnología y negocio sea cada vez más difusa. Ya no basta con conocer sistemas, arquitecturas o herramientas: los equipos tecnológicos tienen que entender qué necesita realmente la compañía y cómo utilizar la tecnología para conseguirlo.

Esta evolución también afecta al liderazgo. Dirigir tecnología significa cada vez más dirigir personas, impulsar su desarrollo y crear equipos capaces de adaptarse continuamente. La diversidad de perfiles, conocimientos y formas de pensar se convierte así en una ventaja, especialmente en un contexto en el que la tecnología cambia constantemente.

La experiencia demuestra, además, que las trayectorias profesionales no tienen por qué seguir caminos lineales. Los conocimientos procedentes de disciplinas diferentes pueden aportar nuevas perspectivas a la tecnología y al negocio. La capacidad de aprender y adaptarse termina siendo tan importante como los conocimientos técnicos adquiridos en un momento determinado.

La IA como acelerador de la transformación

La llegada de la IA generativa ha supuesto un salto cualitativo. Para muchas empresas, el primer paso ha consistido en incorporar estas herramientas para mejorar la productividad individual: generar contenidos, preparar presentaciones, consultar información o resolver tareas cotidianas.

Después llega una segunda fase: identificar qué procesos pueden transformarse realmente mediante IA. El objetivo deja de ser utilizar una herramienta concreta y pasa a ser preguntarse dónde puede aportar valor de verdad.

Y el siguiente paso apunta hacia los agentes y los sistemas multiagente, capaces de colaborar entre sí y con las personas para ejecutar procesos completos. Esto puede llevar a replantear procesos que durante años se han mantenido prácticamente sin cambios.

Pero aquí aparece una cuestión fundamental: no todo proceso necesita IA y no todo aquello que puede automatizarse debería automatizarse. La tecnología tiene que estar al servicio de las personas y de los objetivos de la compañía, no al revés.

Tu equipo no necesita más herramientas, necesita acompañamiento

La democratización de la IA también está generando una diferencia entre quienes la incorporan rápidamente a su trabajo y quienes todavía tienen dudas o incluso sienten cierto rechazo.

La formación se convierte, por tanto, en una responsabilidad compartida entre empleados/as y organizaciones. No se trata únicamente de enseñar a utilizar nuevas herramientas.

También hay que gestionar las emociones asociadas al cambio, reducir la incertidumbre y ayudar a las personas a entender cómo pueden seguir aportando valor en un entorno cada vez más automatizado.

La experiencia acumulada continúa siendo relevante. Las nuevas generaciones pueden llegar con una mayor familiaridad tecnológica, pero eso no sustituye el conocimiento del negocio, del cliente o de la organización que se ha construido durante años.

La pregunta que ningún dashboard responde: qué dejamos en manos de las máquinas y qué no

El futuro estará marcado por agentes, automatización, robótica e inteligencia artificial cada vez más capaces. También crecerá la importancia de la ciberseguridad, especialmente porque las mismas tecnologías que permiten defender sistemas pueden ser utilizadas por los atacantes.

Sin embargo, el verdadero desafío no será únicamente tecnológico, sino ético y humano. Habrá que decidir qué tareas delegamos en las máquinas, qué decisiones deben seguir estando en manos de las personas y cómo garantizar que los sistemas se desarrollan con responsabilidad y sin reproducir sesgos.

La IA también puede utilizarse para mejorar la sociedad: desde el reaprovechamiento de alimentos hasta el acompañamiento frente a la soledad no deseada o la reinserción social. El potencial no está solamente en hacer más cosas con menos recursos, sino en utilizar la tecnología para resolver problemas que importan.

En definitiva, la tecnología va a seguir avanzando a una velocidad exponencial. El reto consiste en conseguir que las personas evolucionen a la misma velocidad: desarrollando nuevas capacidades, aprendiendo a trabajar con máquinas y, sobre todo, reforzando aquellas cualidades que siguen siendo esencialmente humanas.

En este artículo se revisa la literatura científica para contrastar dos hipótesis que argumentan la obsolescencia del RAG: la redundancia de la recuperación ante ventanas de contexto extendidas (1M+ tokens) y el desplazamiento de esta técnica por sistemas basados en agentes. Los datos dicen lo contrario en ambos casos y, además, explican por qué ignorarlos te sale caro.

Si tu sistema todavía recupera información como en 2023, esto te interesa. La pregunta ya no es si el RAG ha muerto. Es cuánto presupuesto de contexto estás desperdiciando sin saberlo.

¿De verdad ha muerto RAG?

Seguramente hayas visto el mismo titular en LinkedIn, “X” o en algunas newsletter técnicas: "El RAG ha muerto". Se dice con la misma contundencia que en 2022, cuando nos prometían que el prompt engineering sería la profesión del futuro, o en 2025, cuando aseguraban que los agentes autónomos nos dejarían sin trabajo. Como toda profecía tecnológica, tiene algo de razón, pero también una buena dosis de postureo.

Hagamos lo que mejor sabemos hacer: desmontar los mitos con datos, no con opiniones.

En 2023, el RAG (Retrieval-Augmented Generation) era una arquitectura simple: una pregunta, un embedding, búsqueda de fragmentos (con suerte, un re-ranker), un prompt y listo. Era una serie de cajas con flechas, una detrás de otra, que entusiasmaba a las empresas solo con verlo en una pantalla. En 2026 esa arquitectura es historia. Los modelos manejan ventanas de contexto de un millón de tokens o más, los agentes hacen grep en repositorios, lanzan SQL, llaman a APIs, reformulan una búsqueda si la primera no sirve y arrastran memoria de trabajo entre pasos. El diagrama de cuatro cajas ya no describe casi ningún sistema real.

De ahí la polémica del titular. Pero mi postura es distinta: el RAG no ha muerto. Ha dejado de ser una solución cerrada para convertirse en una pieza básica de ingeniería. Que sea una herramienta más del sistema, y no el sistema completo, es la prueba de que la tecnología ha madurado.

Desde un punto de vista objetivo, qué parte del RAG sí ha muerto

Antes de defender al RAG, quiero ser honesto con quienes lo dan por enterrado, ya que tienen parte de razón. Existen piezas del RAG de 2023 que no tienen sentido en un sistema serio actual. Pienso, por ejemplo, en el top-k fijo sin justificación, en los chunks de 512 tokens por que sí, en usar un único embedding como buscador universal o en depender de una recuperación densa sin componente léxico. Ese pipeline lineal de cinco cajas en fila es, efectivamente, lo que ha muerto.

Tal como ilustra la Figura 1, hemos pasado de este diseño rígido a una arquitectura mucho más modular y enrutada.

Existe una razón técnica contundente para este cambio. Más que un fallo de potencia, nos hemos dado cuenta de límites que antes ignorábamos. Al generar embeddings, nos enfrentamos a un equilibrio casi imposible: capturar el significado general de un texto y, a la vez, distinguir matices muy finos. Es el llamado “dilema de la granularidad”. Los codificadores de texto fallan sistemáticamente cuando dos pasajes comparten el mismo campo semántico, pero difieren en una entidad o hecho concreto.

Lo interesante es que el tamaño del modelo no soluciona esto por sí solo. Un estudio reciente demuestra que un modelo de apenas 0,1B de parámetros, afinado específicamente para esta tarea, supera a modelos de 7B (Xu et al., 2025). El fallo no es de potencia, es de diseño. Por eso, un solo canal de búsqueda vectorial nunca fue, ni es hoy, una base sólida.

Con el chunking ocurre exactamente lo mismo. Trocear en bloques grandes mezcla entidades distintas en un mismo vector y diluye el matiz; trocear en fragmentos diminutos gana precisión sobre la entidad, pero pierde el contexto que le da sentido. Por eso, las soluciones que funcionan en producción no buscan una "talla óptima" de chunk, sino esquemas como el chunking jerárquico: indexar el fragmento pequeño, pero recuperar el párrafo o documento que lo envuelve.

También ha mejorado de verdad el contexto largo y esto no se lo voy a discutir a nadie. Hay modelos que hoy admiten ventanas de uno, dos o incluso diez millones de tokens y esto, obviamente, cambia un poco las reglas del juego de lo que merece la pena recuperar como unidad. Antes se tenía que trocear un documento porque no cabía entero. Ahora, en muchos casos, puedes meter el documento completo. Eso no es marketing, es una mejora arquitectónica real. Pero esto no justifica que puedas meter todo el corpus en un prompt, y aquí es donde el relato del “contexto infinito” empieza a chocar con los números y la realidad.

Mito 1: “Las ventanas de contexto gigantes hacen innecesario el RAG”

Este es el argumento que más titulares acapara: si los modelos ya manejan ventanas de uno o dos millones de tokens, ¿para qué molestarse en recuperar nada? Basta con inyectar todo. El problema técnico es que un modelo no presta atención de forma uniforme a toda esa ventana. Este fenómeno es conocido como Context Rot (o degradación del contexto): cuanta más información inyectamos, más ruido introducimos, y peor razona el modelo (Liu et al., 2024).

El benchmark RULER destapó este espejismo en 2024. En aquel momento, aunque la mayoría de los modelos afirmaban soportar ventanas de 32K tokens o más, solo el 50% mantenía un rendimiento aceptable en condiciones de uso real (Hsieh et al., 2024).

El resultado que, a mi juicio, más cambia la perspectiva sobre este problema es NoLiMa. Mientras que RULER suele permitir que el modelo encuentre la respuesta por mera coincidencia léxica, NoLiMa elimina esa "pista" y obliga al modelo a razonar semánticamente. Los resultados fueron reveladores: de 13 modelos que prometían contextos de al menos 128K tokens, 11 caían por debajo del 50 % de su rendimiento al llegar a 32K. Incluso un referente como GPT-4o pasaba de un 99,3 % de acierto en contexto corto a un 69,7 % en condiciones de contexto largo (Modarressi et al., 2025)*.

La Figura 2 sintetiza visualmente este fenómeno: mientras que la coincidencia léxica permanece estable, la capacidad de razonamiento real colapsa drásticamente al superar los 32K tokens.

*Dada la vertiginosa velocidad en el desarrollo de nuevos modelos, es fundamental verificar las versiones y arquitecturas específicas referenciadas en Modarressi et al., 2025, antes de generalizar sus resultados.

Además, debemos considerar que casi toda esta evidencia se mide en inglés. Cuando esta capacidad se prueba en 26 idiomas a la vez, la brecha de rendimiento entre lenguas con muchos y pocos recursos se triplica a medida que crece la ventana (Kim et al., 2025; Hengle et al., 2026; Wang et al., 2026; Qi et al., 2025).

Toda esta evidencia apunta en la misma dirección:

Que un modelo pueda pagar el coste de leer un millón de tokens no significa que ese millón de tokens sea atención útil.

Por eso prefiero ver la recuperación no como una técnica que compite con el contexto largo, sino como el gestor de nuestro presupuesto. Cada llamada al modelo es un recurso finito que debemos repartir entre instrucciones, historial, memoria y los documentos recuperados. La recuperación es la función que decide qué parte del mundo merece ocupar ese espacio. Cuanto más grande es la ventana, más caro sale desperdiciarla. Recuperar información con precisión es hoy más crítico que nunca.

Mito 2: "Los agentes sustituyen al RAG"

Este es, a mi juicio, el argumento más sólido de quienes dan por muerto al RAG. Sin embargo, analicémoslo con lupa. La mayoría de los agentes deciden su siguiente paso según lo que acaban de observar, no según un guión fijo, y en algún punto de ese bucle, casi siempre aparece la misma pregunta: ¿qué necesito saber antes de seguir? Esa pregunta es recuperación, aunque ya no lleve esa etiqueta.

Un agente no sigue un flujo lineal. Debe planificar, buscar, evaluar resultados, decidir si necesita más información, consultar herramientas y comparar antes de escribir una sola palabra. Incluso cuando la estrategia de búsqueda se vuelve multinivel, la esencia operativa sigue siendo la recuperación de datos. Lo que ha evolucionado no es la acción de recuperar en sí, sino la inteligencia orquestadora del sistema para discernir qué canales consultar y en qué momento preciso ejecutar cada estrategia.

La evidencia actual demuestra que permitir que un agente realice búsquedas exhaustivas no solo es costoso, sino que a menudo, es contraproducente. Un benchmark reciente, ContextBench, analizó el comportamiento de distintos modelos (GPT-5, Claude Sonnet 4.5 y Devstral 2) operando como agentes autónomos sobre cientos de incidencias reales. Los resultados desmontan la intuición de que "más búsqueda equivale a mejor respuesta".

El análisis es claro: la exploración agresiva en donde el agente realiza rondas de búsqueda excesivas, dispara el consumo de tokens y el coste operativo y, además, no garantiza una mayor calidad (Li et al., 2026). Por el contrario, los modelos que adoptan un enfoque moderado alcanzan un equilibrio superior y logran un mejor desempeño sin necesidad de saturar el sistema con consultas redundantes. La lección de todo esto es que la exploración agresiva por parte de los agentes solo infla el gasto, no la precisión. Leer más no equivale a recuperar mejor.

En la práctica, lo que estamos viendo consolidarse en 2026 son pipelines híbridos (Hybrid Pipelines) que optimizan los recursos. Un patrón exitoso suele ser:

1. Recuperación inicial: combinar representaciones dispersas (BM25) con embeddings densos para obtener un conjunto amplio (50-100 candidatos).
2. Re-ranking: pasar ese conjunto por un cross-encoder que calcula la atención cruzada real entre la consulta y cada fragmento.
3. Selección: quedarse solo con los 5 o 10 bloques con mayor pertinencia antes de llamar al modelo generador.

Este enfoque es más caro que un simple embedding, sí, pero infinitamente más eficiente que saturar al LLM con cien fragmentos aleatorios. Como confirma el estudio de Assadi et al. (2026), en búsquedas semánticas, un buen modelo de embeddings supera a cualquier combinación que intente usar un LLM para reordenar resultados desde cero. Gastar el modelo caro donde no hace falta no solo aumenta el coste; a menudo, ni siquiera mejora el resultado.

Otro patrón exitoso, basado en una arquitectura que se asienta sobre un bucle de razonamiento reflexivo (Reasoning Loop), suele ser:

1. Descomposición y planificación: el agente recibe la consulta compleja y despliega un grafo de planificación dinámica para fragmentar el problema en sub-tareas, evitando secuencias estáticas.
2. Enrutamiento de intención: evalúa el tipo de datos requerido y enruta cada sub-tarea hacia las herramientas de recuperación especializadas idóneas (como motores vectoriales, consultas estructuradas SQL o grafos de conocimiento).
3. Ejecución y recuperación: ejecuta las consultas sobre los canales seleccionados para extraer la evidencia empírica necesaria.
4. Autocrítica (Self-Reflection): evalúa recursivamente si la evidencia recuperada es suficiente, veraz y pertinente para dar solución a la consulta.
5. Re-planificación automática: si la métrica de relevancia interna o suficiencia de datos falla, el sistema activa una re-planificación automática para iterar o buscar en nuevas fuentes.
6. Razonamiento probatorio: consolida y ajusta su estrategia en tiempo real, utilizando la evidencia validada para sintetizar la respuesta final.

Evidentemente, esta sofisticación orquestadora plantea un desafío pragmático de primer orden: la latencia acumulada y el coste por consulta. Sin embargo, delegar cada micro-decisión de este bucle a un LLM de frontera es económicamente insostenible. Las arquitecturas que escalan aplican un enfoque en capas: utilizan modelos de embeddings y re-rankers (cross-encoders) para filtrar el contexto de forma eficiente, reservando el LLM pesado únicamente para la fase de síntesis final. Este filtrado especializado reduce drásticamente el ruido y el coste operativo, garantizando que solo la evidencia de mayor calidad llegue al modelo de razonamiento.

Por otro lado, cuando la consulta requiere unir conceptos relacionados a través de varios documentos, los vectores fallan. Aquí es donde los grafos de conocimiento resuelven la ecuación, permitiendo al modelo razonar sobre conexiones explícitas.

Estos han demostrado ser superiores a la búsqueda vectorial pura (Pan et al., 2024; Chen et al., 2024). Antiguamente, el problema era el coste de construir el grafo entero. Pero implementaciones recientes como GraphRAG (Edge et al., 2024) y soluciones optimizadas como LazyGraphRAG (Edge et al., 2024), HippoRAG (Gutiérrez et al., 2024) o LightRAG (Guo et al., 2025) permiten extraer relaciones semánticas complejas con costes de indexación reducidos, siendo GraphRAG-bench (Xiao et al., 2025) una referencia clave para evaluar la capacidad de razonamiento en estos entornos.

En definitiva, este ecosistema de técnicas (desde la recuperación híbrida hasta la orquestación mediante agentes y grafos de conocimiento) no ofrece soluciones universales. El éxito radica en la composición modular de estos mecanismos según la complejidad y la intención de cada consulta.

Por tanto, el debate útil en 2026 ya no es "¿RAG o agentes?". La pregunta correcta es: ¿qué mecanismo de recuperación debe usar cada agente, en qué momento del razonamiento y con qué presupuesto? El agente no sustituye al RAG, lo absorbe como una capacidad interna.

La métrica que se nos suele olvidar: la latencia y el coste

En entornos corporativos, el cuello de botella no suele ser la tecnología, sino el presupuesto. Obligar a los modelos a procesar contextos inmensos por defecto arruina la viabilidad económica de cualquier producto. La precisión al filtrar información no es solo un reto técnico, es disciplina financiera para que la factura de la nube no se coma el margen de negocio.

Tal como ilustra la Figura 3, este impacto económico se hace evidente al desglosar el pipeline en tres etapas: desde la recuperación inicial de bajo coste hasta el razonamiento final con modelos de frontera.

Un millón de tokens cuesta dinero y tiempo. Mientras una búsqueda híbrida eficiente filtra datos en milisegundos. Obligar al modelo a procesar todo el repositorio antes de escribir la primera palabra dispara la latencia a varios segundos. Para un asistente conversacional, enviar cientos de miles de tokens por llamada no solo es caro, es una pésima experiencia de usuario. El objetivo en producción nunca es saturar al modelo con datos superfluos, sino entregarle con mucha precisión los pocos tokens determinantes para la decisión.-

Los propios proveedores lo confirman al lanzar funciones como el _context caching (la caché de contexto en Gemini o Claude). Estas herramientas son un complemento a la recuperación inteligente, nunca un sustituto, diseñadas precisamente para no pagar ni esperar por los mismos datos una y otra vez.

Los datos respaldan esta cautela. Assadi et al. (2026) demuestran que, aunque los LLMs alcanzan resultados competitivos, el coste es desproporcionado. Usar un modelo como Gemini 3.1 Pro para tareas de recuperación puede ser hasta 1.431 veces más caro que emplear un modelo de embeddings especializado. Además, la velocidad de procesamiento de los LLMs es drásticamente menor. En términos de eficiencia, los tokens dedicados al "razonamiento" suponen entre el 28 % y el 81 % del coste total. Muchas veces, el modelo da vueltas sobre juicios de relevancia que ya tenía claros en la primera lectura, inflando la factura sin mejorar el resultado.

La lección es clara:

Usa modelos de embeddings para el grueso del trabajo y reserva el LLM para el razonamiento final que de verdad lo necesita.

La pregunta para quién diseña un sistema de IA generativa ya no debería ser "¿cuántos tokens soporta mi modelo?", sino "¿cuál es el presupuesto de contexto óptimo para cada paso de mi sistema?"

Entonces, ¿qué hacemos con nuestro RAG de 2023?

Es hora de dejar de lado los debates teóricos y ser pragmáticos. Si tu sistema actual sigue anclado en las premisas de 2023, como la fragmentación estática, la búsqueda vectorial ciega y un flujo lineal rígido, es natural que los resultados no estén a la altura.

El problema no es que el RAG haya muerto. El problema es que estás intentando resolver retos actuales con una arquitectura obsoleta. Tu pipeline necesita dejar de ser un simple buscador para convertirse en un sistema de decisiones.

Para modernizarlo, cualquier solución en producción debe resolver estas seis preguntas críticas:

1. ¿Qué recuperar? Aislar con precisión la información exacta que resuelve la duda, superando la similitud simple.
2. ¿Cuándo intervenir? Determinar el momento preciso de la consulta para no saturar al sistema con búsquedas innecesarias.
3. ¿Cómo buscar? Elegir la vía adecuada (vectorial, léxica, estructurada, temporal, híbrida o asistida por un agente) según la naturaleza de la consulta.
4. ¿Quién tiene acceso? Garantizar filtros de seguridad y permisos de usuario antes de inyectar cualquier dato en el contexto.
5. ¿Si sigue vigente? Validar la frescura temporal de la información para evitar alimentar al modelo con datos obsoletos.
6. ¿De dónde procede? Asegurar la trazabilidad completa y la atribución exacta de las fuentes, un requisito innegociable para decisiones de negocio.

Mi hipótesis para 2026/2027

El término "RAG" ha perdido protagonismo frente al discurso de los agentes, pero la recuperación de información no ha desaparecido. Simplemente, ha dejado de ser un componente aislado. Ya no necesita un nombre propio porque es, sencillamente, una capacidad inherente.

Como ilustra la Figura 4, la recuperación es el tejido conectivo del agente. Ya sea consultando una base de datos, un documento, código o una política interna, el flujo es constante: el agente determina la necesidad, el sistema valida el acceso, el recuperador filtra el contenido y el modelo razona sobre la información seleccionada.

Por eso, "¿ha muerto el RAG?" me parece la pregunta equivocada para 2026. La incógnita real que debemos resolver en cada proyecto es más técnica y menos estética: ¿cuánto presupuesto de contexto estamos desperdiciando?

El RAG ya no debe entenderse como una arquitectura rígida dibujada en una diapositiva, es una función básica de cualquier sistema de IA generativa. Cuanto más grandes son las ventanas de contexto, más vital resulta ejecutar esta función con precisión.

Entonces:

Lo que ha muerto no es el RAG. Ha muerto tu pipeline de 2023.

Si te ha resultado útil este repaso, compártelo con quien todavía esté discutiendo si "el RAG ha muerto" en lugar de discutir cómo debería recuperar su sistema.

Referencias

• Assadi, A. E., Muennighoff, N., & Lee, J. (2026). The Embedder's Dilemma: LLMs Are Better, but at What Cost?. arXiv preprint arXiv:2608.12875.

• Chen, Z., Zhang, Y., Fang, Y., Geng, Y., Guo, L., Chen, X., ... & Chen, H. (2024). Knowledge graphs meet multi-modal learning: A comprehensive survey. arXiv preprint arXiv:2402.05391.

• Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., ... & Larson, J. (2024). From local to global: A graph rag approach to query-focused summarization. arXiv preprint arXiv:2404.16130.

• Edge, J. L. D., Trinh, H., & Larson, J. (2024). Lazygraphrag: Setting a new standard for quality and cost. Microsoft Blog.

• Guo, Z., Xia, L., Yu, Y., Ao, T., & Huang, C. (2025, November). LightRAG: Simple and Fast Retrieval-Augmented Generation. In EMNLP (Findings) (pp. 10746-10761).

• Gutiérrez, B. J., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2024). Hipporag: Neurobiologically inspired long-term memory for large language models. Advances in neural information processing systems, 37, 59532-59569.

• Hengle, A., Bajpai, P., Dan, S., & Chakraborty, T. (2026, March). Can LLMs reason over extended multilingual contexts? Towards long-context evaluation beyond retrieval over haystacks. In Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 6128-6152).

• Hsieh, C. P., Sun, S., Kriman, S., Acharya, S., Rekesh, D., Jia, F., ... & Ginsburg, B. (2024). RULER: What's the real context size of your long-context language models?. arXiv preprint arXiv:2404.06654.

• Kim, Y., Russell, J., Karpinska, M., & Iyyer, M. (2025). One ruler to measure them all: Benchmarking multilingual long-context language models. arXiv preprint arXiv:2503.01996.

• Li, H., Zhu, L., Zhang, B., Feng, R., Wang, J., Pan, Y., ... & Ye, H. (2026). Contextbench: A benchmark for context retrieval in coding agents. arXiv preprint arXiv:2602.05892.

• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the middle: How language models use long contexts. Transactions of the association for computational linguistics, 12, 157-173.

• Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S., & Schütze, H. (2025). Nolima: Long-context evaluation beyond literal matching. arXiv preprint arXiv:2502.05167.

• Pan, S., Luo, L., Wang, Y., Chen, C., Wang, J., & Wu, X. (2024). Unifying large language models and knowledge graphs: A roadmap. IEEE Transactions on Knowledge and Data Engineering, 36(7), 3580-3599.

• Qi, J., Fernández, R., & Bisazza, A. (2025, November). On the consistency of multilingual context utilization in retrieval-augmented generation. In Proceedings of the 5th Workshop on Multilingual Representation Learning (MRL 2025) (pp. 199-225)

• Su, H., Yen, H., Xia, M., Shi, W., Muennighoff, N., Wang, H. Y., ... & Yu, T. (2025, May). Bright: A realistic and challenging benchmark for reasoning-intensive retrieval. In International Conference on Learning Representations (Vol. 2025, pp. 48941-48991).

• Wang, D., Mo, G., Shi, Y., Zhang, C., Zheng, B., Cao, B., ... & Sun, L. (2026, July). All Languages Matter: Understanding and Mitigating Language Bias in Multilingual RAG. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 7441-7455).

• Xiao, Y., Dong, J., Zhou, C., Dong, S., Zhang, Q. W., Yin, D., ... & Huang, X. (2025). Graphrag-bench: Challenging domain-specific reasoning for evaluating graph retrieval-augmented generation. arXiv preprint arXiv:2506.02404.

• Xu, L., Su, Z., Yu, M., Li, J., Meng, F., & Zhou, J. (2025). Dense retrievers can fail on simple queries: Revealing the granularity dilemma of embeddings. Passages, 3024, 8.

Entrevista a Javier Mallo, CIO en Carrefour España

El retail se encuentra en un momento de profunda transformación. La inteligencia artificial generativa, los agentes, el cloud, los datos y la automatización están abriendo nuevas posibilidades para mejorar tanto la experiencia de cliente como la eficiencia operativa.

Pero en un sector con millones de transacciones, cientos de tiendas y una enorme complejidad tecnológica, innovar no consiste únicamente en probar nuevas herramientas. El verdadero reto está en conseguir que la tecnología genere valor real y pueda escalar dentro del negocio.

La velocidad a la que aparecen nuevas tecnologías está obligando a los departamentos de IT a trabajar a dos velocidades.

Por un lado, necesitan explorar constantemente nuevas posibilidades y encontrar casos de uso que aporten valor. Por otro, tienen que mantener y modernizar infraestructuras, aplicaciones y sistemas que siguen siendo críticos para el funcionamiento del negocio.

Y en retail esta dualidad es especialmente evidente: la tecnología ya no está únicamente detrás del canal digital. Está presente en prácticamente cada interacción y cada proceso de una tienda física.

La tecnología ya no es un soporte: es parte de la estrategia

Durante años, la tecnología podía entenderse como una herramienta para dar soporte al negocio. Hoy esa separación resulta cada vez más difícil de mantener.

El comercio electrónico, las aplicaciones móviles, los programas de fidelización, la gestión del stock, el pricing, las promociones, la logística o la experiencia dentro de la tienda dependen directamente de sistemas tecnológicos.

Incluso el funcionamiento de una tienda física está cada vez más digitalizado. Por eso, la tecnología ha dejado de ser un medio aislado para convertirse en una pieza fundamental de la estrategia empresarial.

Esto cambia también el papel de los responsables de tecnología. El reto no consiste simplemente en conocer las últimas novedades, sino en entender la realidad concreta de la compañía y decidir qué tecnología aplicar, cuándo hacerlo y con qué objetivo.

No todas las empresas tienen la misma cultura, el mismo nivel de madurez ni las mismas necesidades. Una tecnología puede funcionar extraordinariamente bien en una organización y no aportar prácticamente nada en otra. El éxito depende de saber conectar la innovación tecnológica con los problemas reales del negocio.

El gran reto de la IA: conseguir adopción

La inteligencia artificial es probablemente el mejor ejemplo de esta nueva realidad. Las empresas pueden desplegar herramientas de IA generativa con una rapidez que hace unos años habría resultado difícil de imaginar. Pero poner una herramienta a disposición de miles de empleados/as no significa que vaya a ser utilizada de forma habitual.

Una experiencia real de despliegue demuestra precisamente esta dificultad. Tras poner una plataforma de IA a disposición de miles de empleados/as, la utilización inicial fue elevada, pero cayó considerablemente después de las primeras semanas. La tecnología estaba disponible, pero la adopción no se había trabajado suficientemente.

La solución pasa por entender que la adopción es un proyecto en sí mismo. No basta con proporcionar acceso a un modelo o a un copiloto. Es necesario formar a las personas, identificar casos de uso, crear referentes internos y conseguir que la tecnología se incorpore realmente a la forma de trabajar.

Los programas de AI Champions son una de las vías para conseguirlo. En lugar de plantear la adopción únicamente desde arriba, se crean comunidades de usuarios que experimentan, comparten conocimiento y ayudan a extender el uso de la IA dentro de las distintas áreas de negocio.

En el caso analizado, este enfoque permitió extender el uso de la IA a diferentes áreas y tiendas, acompañado de formación y sesiones periódicas.

Pero la adopción necesita también una dirección clara. Experimentar con IA en cientos de casos de uso diferentes puede acabar dispersando los recursos. Por eso resulta fundamental establecer prioridades estratégicas y concentrar los esfuerzos allí donde exista una oportunidad real de impacto.

De la IA genérica a los casos de uso que generan negocio

Una de las claves para que la inteligencia artificial tenga impacto en retail es dejar de pensar únicamente en la tecnología y empezar por los problemas que se quieren resolver.

Entre las áreas con mayor potencial aparecen cuestiones como la optimización del surtido, el pricing, las promociones, las operaciones en tienda y el conocimiento y relación con el cliente.

Aquí es donde los datos adquieren un papel fundamental. La IA puede ser extraordinariamente potente, pero necesita información de calidad y correctamente gobernada para generar resultados fiables.

Un ejemplo especialmente interesante es la evolución de los asistentes hacia experiencias mucho más personalizadas. Los nuevos agentes pueden ir más allá de responder preguntas y utilizar información contextual sobre cada cliente para ofrecer recomendaciones, promociones o información relevante para su situación concreta.

En este escenario, el valor de la IA no está únicamente en responder mejor, sino en utilizar el conocimiento disponible para ofrecer una experiencia más útil y personalizada.

Innovar rápido no significa escalar rápido

Una de las grandes ventajas actuales es que experimentar con nuevas tecnologías resulta mucho más rápido y barato que hace unos años.

Una prueba de concepto puede desarrollarse en cuestión de semanas o meses con una inversión relativamente contenida, lo que permite validar una idea antes de comprometer grandes cantidades de recursos. Pero existe una diferencia enorme entre demostrar que algo funciona y llevarlo a producción a gran escala.

Cuando una prueba de concepto se convierte en un producto utilizado por miles o millones de personas, aparecen nuevos desafíos. La experiencia de usuario, la estabilidad, la infraestructura, la seguridad y la calidad de los datos pasan a ser factores críticos. El verdadero cuello de botella de la innovación muchas veces no está en crear el prototipo, sino en tener una arquitectura preparada para soportarlo.

Por eso, los equipos de UX y UI adquieren una importancia creciente. Una aplicación o un agente puede funcionar técnicamente y, sin embargo, fracasar porque la experiencia de usuario no resulta suficientemente intuitiva o atractiva. La adopción depende también de cómo se presenta la tecnología al usuario.

El problema que sigue detrás de la IA: el legacy

Hay otro elemento menos visible, pero fundamental: los sistemas que existen detrás de las nuevas experiencias digitales. Una empresa puede desarrollar rápidamente un nuevo agente, una aplicación basada en IA o un nuevo canal digital.

Sin embargo, si ese producto depende de una aplicación crítica de hace quince años que continúa funcionando sobre una infraestructura antigua, la capacidad de escalar estará limitada. Es el problema de las dos velocidades de IT.

Mientras una parte de la organización trabaja en inteligencia artificial, agentes, innovación y transformación digital, otra tiene que ocuparse de infraestructuras, aplicaciones legacy, vulnerabilidades, obsolescencia y mantenimiento.

El reto consiste en conseguir que ambas velocidades avancen. No tiene sentido construir el futuro digital sobre una base tecnológica incapaz de soportarlo.

La modernización de estos sistemas, la migración al cloud, la creación de infraestructuras autoescalables y, sobre todo, una correcta gestión y gobierno del dato son condiciones necesarias para aprovechar realmente las nuevas tecnologías.

El dato como infraestructura invisible del retail

La IA está haciendo todavía más evidente un problema que ya existía: la calidad del dato. Los modelos y agentes necesitan acceder a información fiable, actualizada y correctamente gobernada.

De poco sirve disponer de una tecnología muy avanzada si los datos sobre clientes, productos, stock o procesos están fragmentados, desactualizados o almacenados en sistemas difíciles de integrar.

Por eso, una parte importante del trabajo tecnológico durante los próximos años seguirá siendo mucho menos visible que la IA: limpiar datos, modernizar sistemas, migrar plataformas, mejorar la gobernanza y eliminar deuda tecnológica.

Puede parecer menos espectacular que desplegar un agente autónomo, pero probablemente sea igual o más importante para determinar qué empresas estarán preparadas para aprovechar esa tecnología.

El futuro del retail será agéntico, pero seguirá siendo humano

Es difícil predecir exactamente cómo será el retail dentro de cinco años. La velocidad de evolución de la inteligencia artificial hace que muchas de las predicciones actuales puedan quedarse rápidamente obsoletas.

Lo que sí parece claro es que los agentes tendrán un papel cada vez mayor y estarán más interconectados con los sistemas de las compañías. También veremos una mayor presencia de tecnologías como IoT, edge computing o computación cuántica.

Pero existe una conclusión especialmente relevante para el retail: digitalizar no significa eliminar la dimensión humana de la experiencia de compra. La tienda física seguirá teniendo un peso enorme.

Aunque crezcan el ecommerce, el quick commerce, las aplicaciones y las nuevas interfaces basadas en IA, las personas continuarán visitando las tiendas. El objetivo de la tecnología será hacer esa experiencia más sencilla, personalizada y libre de fricciones, no necesariamente sustituirla.

Esto abre una oportunidad especialmente interesante para el sector: utilizar la tecnología para conseguir que el mundo físico y el digital dejen de funcionar como experiencias separadas.

Primero entendimos cómo Angular era capaz de “saber” cuándo actualizar la UI gracias a Zone.js, el árbol de componentes y las estrategias de detección de cambios. Después dimos el salto a Signals y vimos cómo Angular comenzaba a actualizar únicamente aquello que realmente dependía del estado reactivo.

• Estrategia de detección de cambios: la magia de Angular
• Angular Signals: evolución de la reactividad y detección de cambios

En este tercer capítulo vamos a cerrar el círculo. Porque si Signals solucionaba qué debe actualizarse… Zoneless cambia completamente cuándo Angular decide ejecutar la detección de cambios.

Y sí: Angular ya puede funcionar sin Zone.js.

Del “Angular lo detecta todo” al “Angular detecta solo lo necesario”

En el primer artículo vimos que Angular utilizaba Zone.js para interceptar operaciones asíncronas:

• Clicks
• setTimeout
• Peticiones HTTP
• Promesas
• Eventos del navegador…

Cada vez que ocurría cualquiera de esas operaciones, Angular lanzaba un ciclo de detección de cambios completo. El problema es que Angular realmente no sabía si había cambiado algo relevante.

Simplemente asumía:

“Ha ocurrido algo asíncrono. Por si acaso… reviso toda la aplicación”.

Y eso funcionaba muy bien, pero también implicaba trabajo innecesario.

El ejemplo del reloj

Sigamos exactamente el mismo ejemplo de los artículos anteriores. Tenemos:

• Un reloj que se actualiza cada segundo
• Una lista de usuarios.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock }}</h2>

   @for (user of users; track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `
})
export class AppComponent {
 clock = '';

 users = USERS;

 ngOnInit() {
   setInterval(() => {
     this.clock = new Date().toLocaleTimeString();
   }, 1000);
 }
}

En el primer artículo vimos que:

• Cada segundo, Angular recorría el árbol completo
• Recalculaba bindings
• Ejecutaba expresiones
• Revisaba todos los componentes

Aunque los usuarios no hubieran cambiado.

OnPush fue el primer parche

Después apareció ChangeDetectionStrategy.OnPush.

@Component({
 changeDetection: ChangeDetectionStrategy.OnPush
})

Con OnPush, Angular dejaba de revisar componentes “porque sí” y solo los comprobaba cuando:

• Cambiaba un @Input
• Ocurría un evento dentro del componente
• Se emitía un observable con async
• O llamábamos manualmente a markForCheck()

Era mucho más eficiente, pero seguíamos dependiendo de Zone.js porque Angular seguía necesitando un mecanismo global que dijera:

“Oye, acaba de pasar algo asíncrono”.

Signals cambió las reglas del juego

Y aquí llegó la gran revolución. Con Signals, Angular ya no necesita “preguntarse” qué ha cambiado, ahora lo sabe.

clock = signal('');
setInterval(() => {
 this.clock.set(new Date().toLocaleTimeString());
}, 1000);

En la plantilla:

<h2>{{ clock() }}</h2>

Angular registra automáticamente qué partes de la UI dependen de cada signal y, cuando el signal cambia:

• Angular marca únicamente los componentes afectados
• Evita recorrer ramas innecesarias
• Actualiza solo los bindings dependientes

Esto ya suponía un salto enorme de rendimiento, pero todavía quedaba una pregunta importante: si Signals ya sabe exactamente qué cambia… ¿para qué seguimos necesitando Zone.js?

Aquí entra Zoneless

La respuesta corta es que ya no lo necesitamos tanto. Angular empezó a introducir soporte para aplicaciones “zoneless”, es decir, aplicaciones sin Zone.js y eso cambia completamente el modelo mental.

¿Qué hace realmente Zone.js?

Zone.js parchea APIs del navegador para interceptar tareas asíncronas:

• Timers
• Eventos
• Promesas
• XHR
• Fetch
• etc.

Cuando cualquiera de esas tareas termina, Angular ejecuta detección de cambios global. El problema es que eso tiene costes:

• Más trabajo innecesario
• Más ciclos de detección
• Peor startup
• Stack traces más difíciles
• Y más complejidad interna

De hecho, uno de los objetivos principales de Zoneless es mejorar el rendimiento, el Core Web Vitals, la compatibilidad con APIs modernas y la experiencia de debugging.

¿Cómo funciona Angular sin Zone.js?

En modo zoneless, Angular deja de “espiar” todo el navegador. En lugar de eso, solo actualiza la UI cuando recibe notificaciones explícitas. Por ejemplo:

• Un signal cambia,
• Un AsyncPipe emite
• Ocurre un evento Angular ((click))
• Se llama a markForCheck()
• Un @Input recibe un nuevo valor

Es decir: Angular ya no hace polling implícito del estado. Ahora el propio framework sabe exactamente cuándo algo relevante ha cambiado y aquí está probablemente la idea más importante de todo el cambio: Angular pasa de un modelo reactivo implícito a uno explícito.

Activando Zoneless

Actualmente, Angular permite habilitarlo mediante:

bootstrapApplication(AppComponent, {
 providers: [
   provideZonelessChangeDetection()
 ]
});

Y eliminando:

npm uninstall zone.js

Volvamos al ejemplo del reloj

Ahora, nuestro ejemplo cambia bastante.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock() }}</h2>
   @for (user of users(); track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `})
export class AppComponent {
 clock = signal('');
 users = signal(USERS);

 ngOnInit() {
   setInterval(() => {
     this.clock.set(
       new Date().toLocaleTimeString()
     );
   }, 1000);
 }
}

¿Qué ocurre ahora cada segundo?

• Cambia únicamente clock
• Angular marca únicamente ese binding
• La tabla de usuarios ni siquiera entra en el ciclo.

Ya no existe ese “revisar toda la aplicación por si acaso”.

Entonces… ¿Signals sustituye a OnPush?

No exactamente. Signals y Zoneless mejoran muchísimo cómo Angular programa la detección de cambios, pero OnPush sigue siendo importante.

Porque Zoneless no cambia cómo Angular recorre el árbol de componentes, lo que cambia es cuándo decide lanzar detección de cambios.

Así que:

• OnPush sigue ayudando a limitar comprobaciones
• Signals sigue marcando componentes concretos
• Zoneless evita disparar ciclos globales innecesarios.

Las tres piezas se complementan y, de hecho, la propia documentación oficial recomienda OnPush como paso natural hacia compatibilidad zoneless.

Algo importante: Angular sigue detectando eventos

Hay un detalle muy interesante. Aunque eliminemos Zone.js, esto sigue funcionando:

<button (click)="increment()">
 Incrementar
</button><br>

counter++;

¿Por qué? Porque los eventos registrados a través de Angular siguen notificando al framework automáticamente.

Pero cuidado: esto NO ocurre con APIs externas al ecosistema Angular. Por ejemplo:

element.addEventListener('click', () => {
 this.counter++;
});

Aquí, Angular ya no sabe que algo cambió y necesitaríamos:

markForCheck()

O utilizar Signals.

Lo que empieza a “romperse” en Zoneless

Aquí es donde la teoría se vuelve interesante, porque la mayoría de aplicaciones Angular actuales dependen indirectamente de comportamientos automáticos de Zone.js.

Y cuando lo eliminamos… aparecen ciertas sorpresas. Por ejemplo, este patrón clásico deja de funcionar correctamente:

this.userService.users$
 .subscribe(users => {
   this.users = users;
 });

Si luego mostramos users directamente en plantilla, Angular podría no enterarse del cambio porque la suscripción ocurre fuera de cualquier mecanismo reactivo observable para Angular.

La solución moderna pasa por:

• Usar async pipe
• Convertir observables a signals
• Llamar explícitamente a markForCheck().

Por ejemplo:

users = toSignal(this.userService.users$);

Aquí empieza a verse claramente hacia dónde quiere ir Angular: menos magia implícita y más reactividad explícita.

Otro detalle importante es Reactive Forms. Operaciones como form.patchValue(...)siguen actualizando el estado interno del formulario…pero ya no fuerzan automáticamente detección de cambios.

¿Desde qué versión existe Zoneless?

Angular ha ido evolucionando esta capacidad durante varias versiones.

El verdadero cambio de paradigma

Angular deja atrás un modelo basado en “revisar por si acaso” para pasar a un modelo basado en reactividad explícita.

Mucho más predecible, mucho más eficiente y bastante más cercano a cómo funcionan frameworks modernos como Solid o Vue Signals.

¿Está listo para producción?

A día de hoy, Zoneless ya forma parte de la estrategia oficial de Angular y el framework está claramente orientado hacia este modelo reactivo, pero eso no significa que cualquier aplicación pueda eliminar Zone.js mañana sin más. Conviene validar cuidadosamente:

• Librerías de terceros
• Integraciones DOM manuales
• Código legacy
• Formularios reactivos
• SSR
• Testing
• Patrones basados en side effects implícitos

De hecho, Angular insiste bastante en que el futuro pasa por Signals, async pipe, OnPush, APIs reactivas y notificaciones explícitas al framework.

Conclusiones

Durante años, Angular se apoyó en Zone.js para detectar cualquier posible cambio en la aplicación. Después llegó OnPush para reducir trabajo innecesario. Más tarde apareció Signals para permitir una reactividad mucho más precisa.

Y ahora Zoneless termina de cerrar esa evolución eliminando la necesidad de vigilar constantemente todo lo que ocurre en el navegador.

La combinación de Signals, OnPush, y Zoneless nos permite construir aplicaciones mucho más eficientes, predecibles y fáciles de razonar.

Pero también obliga a entender mucho mejor cómo funciona realmente la reactividad del framework. Porque Angular ya no intenta adivinar lo que ocurre, ahora espera que seamos explícitos y, probablemente, ahí está el cambio más importante de todos.

Referencias

Artículos previos de la serie

• Estrategia de detección de cambios: la magia de Angular
• Angular Signals: evolución de la reactividad y detección de cambios

Documentación oficial de Angular

• Angular Zoneless Guide
• Angular v18 Experimental Zoneless Guide
• provideZonelessChangeDetection API

Artículos y análisis técnicos

• Angular 20 y el futuro sin ZoneJS: la revolución zoneless ha llegado a developer preview
• Zoneless Angular: What Works, What Breaks, and Why It Matters
• What Does Zoneless Angular Mean?

Es un documento de sobra conocido. Evidentemente, su contenido no está escrito en piedra y no tiene el contexto del mercado español como tal pero sí que aporta una visión general del estado del arte y su tendencia ya que, si lo sigues en sus diferentes volúmenes, puedes ver cómo evolucionan los conceptos que en él se incluyen.

Creo que en este momento de brutal cambio e incertidumbre en el sector, consultar documentos de este tipo y calidad es de vital importancia para saber qué va siendo una realidad contrastada o qué hay que tomar con precaución.

La fuente de conocimiento: el radar de Thoughtworks

Como he comentado en la introducción, el Radar de Thoughtworks es de sobra conocido. Seguramente lo hayas consultado más de una vez pero si no, te animo a hacerlo porque me parece muy interesante, sobre todo en estos tiempos de tanto cambio e incertidumbre.

Cada seis meses, más o menos, suelen publicar un volumen con lo que estiman relevante. Los volúmenes son documentos amplios y detallados, de unas 45-50 páginas cada uno, orientados bajo cuatro pilares fundamentales:

• Técnicas
• Plataformas
• Herramientas
• Lenguajes y frameworks

De cada pilar se analizan una serie de “cosas o ítems interesantes” (”blips” en su terminología) que se terminan clasificando en cuatro niveles:

• Adoptar: la industria debería adoptar esos ítems. Son items que ya están consolidados en el sector.
• Probar: vale la pena probarlos porque es importante entender cómo desarrollar estas capacidades. Las empresas deberían probar esta tecnología en proyectos en que se puede manejar el riesgo.
• Evaluar: merece la pena explorar esos ítems con el objetivo de comprender cómo afectará a la empresa.
• Resistir: proceder con precaución a la hora de implantarlos.

Lo realmente interesante no es tanto qué blips hay en cada bloque sino la tendencia: qué blips aparecen, cuáles son “promocionados” a probar o adoptar y cuáles hay que tratar con precaución, bien porque su madurez así lo indica o porque se han detectado riesgos o carencias que hay que tener en cuenta.

El medio para la entrevista: un RAG avanzado

Como no podía ser de otra forma en los tiempos que corren, me he apoyado en la IA para realizar la entrevista, pero no como se puede pensar a priori, utilizando ChatGPT, Gemini, NotebookLM o similar para que analice el radar y emita conclusiones, preparando un sistema al que he intentado dotar de un pensamiento lo más “humano” posible que permita que esto parezca una entrevista de verdad.

El sistema está basado en una arquitectura 100% serverless en AWS (Cloudfront, API Gateway, Lambda, Bedrock, Opensearch, DynamoDB, S3), que se puede levantar y tirar mediante IaC.

El “core”, básicamente consiste en un RAG avanzado con búsqueda híbrida (BM25 + embeddings vectoriales) sobre una serie de fuentes indexadas (chunking jerárquico) en AWS Bedrock Knowledge Base en Opensearch.

El diagrama de arquitectura es el siguiente:

Cuando se hace una pregunta, se recuperan los fragmentos más relevantes del corpus, se inyectan en el contexto del modelo junto con un resumen acumulativo de la conversación (generado automáticamente por modelo ligero tras cada turno y persistido en DynamoDB), manteniendo así el hilo de la entrevista sin depender de la memoria nativa del modelo.

Para intentar dotar al sistema de “cierto comportamiento humano” y que parezca una entrevista de verdad, el prompt de sistema está pensando para que actúe como una persona que trabaja en la realización del radar, miembro del Thoughtworks Technology Advisory Board (TAB), que va a ser entrevistado.

Para esta PoC he decidido establecer la base de conocimiento dentro de un rango temporal más o menos de dos años, analizando los últimos cuatro volúmenes:

• 📊 Volumen 31 (octubre 2024)
• 📊 Volumen 32 (abril 2025)
• 📊 Volumen 33 (noviembre 2025)
• 📊 Volumen 34 (abril 2026)

La UI, a la que he intentado dar un estilo editorial periodístico, permite configurar tanto los parámetros más importantes de la consulta (modelo, tokens, fragmentos recuperados o incluso el prompt de sistema) como explorar el radar por anillo, cuadrante y edición.

También permite exportar la transcripción completa como PDF en formato periódico a doble columna. Al finalizar la sesión, si es necesario, un segundo modelo genera un informe ejecutivo estructurado (resumen, temas clave, tendencias y recomendaciones) basado exclusivamente en lo discutido durante la entrevista.

No voy a dar muchos más detalles del proyecto en este artículo porque no es el objeto del mismo (es la entrevista en sí) y publicaré un artículo más técnico próximamente con todos los detalles.

Ahora sí, la entrevista

Una vez detallado el contexto en el que se realiza la entrevista, procedamos a su realización y a la formulación de las preguntas. He de decir que, en mi opinión, ha dejado insights muy significativos:

• Hola, vamos a comenzar esta esperada entrevista. Vamos con la primera pregunta. Este 2026 está siendo un año de vértigo en lo que se refiere al impacto de la tecnología pero, desde tu punto de vista, hasta llegar a este punto actual, ¿cómo describirías la evolución del sector tecnológico en los últimos años?

Buena pregunta para arrancar. Si tuviera que resumirlo en una frase: hemos pasado de la experimentación entusiasta a la ingeniería responsable, pero con mucho ruido en el camino.

Lo que hemos observado a lo largo de las últimas ediciones del Radar es una aceleración que no tiene precedentes, pero con un patrón reconocible. Cada ciclo tecnológico sigue una curva similar: euforia, saturación, y luego — si la tecnología tiene valor real — consolidación. Con la IA generativa hemos vivido esa curva en cámara rápida.

Hace tres o cuatro años, el debate era si los LLMs eran algo más que un juguete sofisticado. Luego vino la explosión del ecosistema — RAG, vector databases, guardrails, frameworks de agentes — que en el Radar de 2024 ya describíamos como una “explosión cámbrica”. Era caótico, pero tenía sentido: la simplicidad inicial del prompt de texto estaba dando paso a la ingeniería de software real.

Este es el punto que más nos importa subrayar: la tecnología madura cuando deja de ser magia y se convierte en disciplina. Y eso es exactamente lo que estamos viendo ahora en 2026 con los agentes, con el context engineering, con los patrones de evaluación de LLMs.

Pero también hemos visto lo que no funcionó como esperábamos. Fuimos inicialmente optimistas con la autonomía total de los agentes de código, y hemos tenido que ser honestos: el enfoque supervisado sigue siendo imprescindible. La complacencia con el código generado por IA es un antipatrón real, documentado, con datos que lo respaldan.
Uno de los patrones que seguimos viendo es que la velocidad de las herramientas supera la madurez de las prácticas. Y eso tiene un coste: deuda cognitiva, shadow IT acelerado por IA, arquitecturas que derivan sin control.

El sector está en un momento apasionante, pero los fundamentos de ingeniería — testing, observabilidad, diseño arquitectónico — nunca han sido más relevantes que ahora.

• Me parece muy interesante lo que comentas de que “los fundamentos de ingeniería nunca han sido más relevantes qué ahora”. ¿Por qué ahora son una pieza clave? ¿No lo han sido siempre?

Sí, siempre lo han sido. Pero hay una diferencia crucial entre que algo sea importante y que su ausencia sea inmediatamente catastrófica.

Antes, si un equipo tenía poca cobertura de tests o una arquitectura mediocre, el daño se acumulaba lentamente. Había fricción, deuda técnica, pero el sistema degradaba de forma gradual y visible. Ahora, con agentes de código generando changesets masivos en minutos, esa misma ausencia de disciplina puede destruir la coherencia de un sistema en horas. La velocidad amplifica todo, lo bueno y lo malo.

This is where things get interesting. Lo que estamos documentando en el Radar como codebase cognitive debt no es simplemente deuda técnica tradicional. Es algo más sutil y más peligroso: es la pérdida del modelo mental colectivo sobre cómo funciona el sistema. Cuando el código lo genera la IA y nadie lo revisa en profundidad, el equipo empieza a operar sobre una caja negra que ellos mismos construyeron sin entender. Los datos de GitClear son bastante elocuentes al respecto: más código duplicado, más churn, menos refactoring.

Y aquí está la paradoja que más nos preocupa: los agentes de código funcionan mejor en codebases bien estructuradas, bien testeadas, con diseño limpio. Es decir, las prácticas que algunos equipos estaban tentados a relajar porque “la IA lo arregla” son exactamente las que hacen que la IA funcione bien. El buen diseño para humanos también es buen diseño para agentes.

Por eso en el último Radar hemos puesto en Adopt cosas como DORA metrics, context engineering, zero trust, OpenTelemetry. No son novedades. Son recordatorios de que sin esa base, la velocidad que promete la IA se convierte en deuda compuesta.

Lo que ha cambiado no es la importancia de los fundamentos. Es el coste de ignorarlos.

• Viendo la evolución de estos últimos años, ¿qué puntos consideras clave para que la incorporación de la IA sea un éxito hoy día en una empresa?

Lo primero que diría es que el fracaso más común que vemos no es técnico. Es organizacional. Las empresas que están fallando con IA no fallan porque eligieron el modelo equivocado o el framework incorrecto. Fallan porque intentaron incorporar IA sobre una base que ya era frágil.

Dicho esto, hay varios patrones que hemos documentado como críticos.

Primero, tratar el contexto como un activo de ingeniería, no como un detalle de implementación. Context engineering está en Adopt en el último Radar precisamente porque hemos visto que las organizaciones que lo hacen bien —que diseñan el contexto como una pipeline dinámica y gestionada— obtienen resultados cualitativamente distintos. Las que lo ignoran acaban con agentes alucinando o comportándose de forma inconsistente.

Segundo, invertir en las señales de feedback antes de escalar. DORA metrics en Adopt no es nostalgia. Es un recordatorio de que si no mides lead time, deployment frequency y rework rate, no sabrás si la IA está generando valor real o simplemente más código. Y el rework rate específicamente es el canario en la mina para detectar deuda cognitiva acumulada.

Tercero, gobernar los agentes desde el principio. Zero trust architecture en Adopt para agentes no es opcional. El “lethal trifecta” que describe Simon Willison —datos privados, contenido no confiable, acción externa— describe a la mayoría de los agentes útiles por defecto. Si no tienes least privilege y monitorización continua desde el día uno, estás construyendo sobre arena.

Y cuarto, y esto es quizás lo más contraintuitivo: las empresas que más éxito tienen son las que primero invierten en limpiar su codebase y sus prácticas de ingeniería, y después incorporan agentes. No al revés.

Lo que observamos repetidamente es que la IA amplifica lo que ya existe. Si tienes disciplina, la amplifica. Si tienes caos, también lo amplifica. Y a una velocidad que no da tiempo a reaccionar.

• A nivel de tecnologías, durante estos últimos años, ¿cuáles son las que se han asentado totalmente y cuáles se han perdido por el camino o se van diluyendo?

Esta es una pregunta que me encanta porque el movimiento entre rings es donde realmente se ve si algo tiene sustancia o si era ruido.

Las que se han asentado de verdad:

OpenTelemetry es quizás el ejemplo más limpio. Pasó de Assess a Adopt de forma casi inevitable, porque resolvió un problema real —la fragmentación de observabilidad— con una abstracción correcta. Cuando Datadog, New Relic y Grafana adoptan el mismo protocolo, sabes que algo ha ganado. Eso no es hype, es consolidación genuina.

RAG —Retrieval-Augmented Generation— llegó a Adopt en tiempo récord. Lo que nos sorprendió no fue la velocidad, sino que la técnica sobrevivió al escrutinio de producción. Sigue evolucionando —GraphRAG, Corrective RAG, Self-RAG— pero el patrón central aguantó.

Y en tooling, cosas como Renovate o Vite: sin glamour, sin conferencias keynote, pero en Adopt porque simplemente funcionan y los equipos no quieren vivir sin ellos.

Las que se están diluyendo o nunca despegaron:

SAFe sigue en Hold, y cada edición el lenguaje se vuelve más duro. No es que no se use —se usa demasiado— sino que seguimos sin ver los resultados que promete.

Local coding assistants es interesante: llegaron con mucha expectativa por razones de privacidad, pero los pusimos en Hold porque los modelos locales simplemente no compiten con los cloud-based en capacidades agenticas. La realidad técnica ganó al deseo organizacional.

Y lo más revelador: “Replacing pair programming with AI” en Hold. Esto es casi una declaración de principios nuestra. No porque la IA no ayude, sino porque confunde velocidad individual con salud del equipo. Son cosas distintas.

El patrón que veo: lo que se asienta resuelve fricción real con abstracciones durables. Lo que se diluye suele ser o bien una solución buscando problema, o bien una optimización local que ignora consecuencias sistémicas.

• ¿Cuáles crees que son los principales riesgos o antipatrones que se han detectado durante estos últimos años y que pueden hacer mucho daño de no tomar medidas?

Esta es quizás la pregunta más importante que podemos hacernos ahora mismo, porque estamos en un momento donde la velocidad de adopción supera claramente la velocidad de comprensión de las consecuencias.

El primero y más peligroso: la complacencia con el código generado por IA. No es nuevo —lo llevamos poniendo en Hold desde hace varios volúmenes— pero se está agravando. Lo que antes era un desarrollador revisando sugerencias de Copilot, ahora es un agente modificando decenas de ficheros en paralelo mientras el desarrollador supervisa a alto nivel. El riesgo de automation bias se multiplica exponencialmente. Y lo que obtienes no es código malo —es código que funciona pero que nadie entiende del todo. Eso nos lleva directamente al segundo antipatrón.

La deuda cognitiva del codebase. Este término lo introdujimos recientemente en Caution y creo que es uno de los conceptos más importantes que hemos articulado en años. No es deuda técnica clásica —es la brecha entre lo que el sistema hace y lo que el equipo comprende que hace. Con agentes generando cambios a alta velocidad, esa brecha se ensancha silenciosamente hasta que un día un cambio pequeño rompe algo inesperado, y nadie sabe por qué.

Tercero: MCP by default. Lo pusimos en Caution explícitamente. El patrón que vemos es: “tengo una API, la convierto en MCP server, listo.” Sin pensar en el modelo de seguridad, sin analizar los flujos tóxicos, sin preguntarse si realmente necesitas MCP o si un CLI script resuelve el problema igual de bien. La conversión naïve de APIs a MCP es una superficie de ataque que la mayoría de organizaciones no está gestionando.

Y cuarto, uno que me preocupa especialmente a nivel organizacional: el shadow IT acelerado por IA. No-coders construyendo workflows agenticos que procesan datos sensibles, sin governance, sin audit trail, sin que IT lo sepa. La diferencia con el shadow IT clásico es la escala y la velocidad. Lo que antes tardaba meses en convertirse en un problema crítico, ahora tarda semanas.

El patrón común en todos estos antipatrones es el mismo: la IA amplifica la velocidad antes de que la organización haya construido los mecanismos de control necesarios. Y cuando algo falla, falla rápido y a escala.

• Me parecen muy interesantes estos puntos, sobre todo cuando se está hablando de la desaparición del rol de programador. Pero, sin embargo, detectáis muchos riesgos asociados con la generación automática de la mayor parte del código sin revisar, aumentando la deuda técnica. ¿Cómo afecta esto realmente al rol de desarrollador? ¿Acabará desapareciendo este rol o tendrá mayor importancia de la que tiene?

La narrativa de “el programador va a desaparecer” es, francamente, una de las más irresponsables que circulan ahora mismo. Y lo digo con convicción porque los datos que vemos en el Radar apuntan exactamente en la dirección contraria.

Lo que estamos observando es una transformación del rol, no su extinción. Y esa transformación lo hace, si cabe, más crítico y más difícil de ejercer bien.

Piénsalo así: cuando un agente genera cientos de líneas de código en segundos, ¿quién decide si esa solución es la correcta arquitectónicamente? ¿Quién detecta que el agente ha resuelto el problema con treinta condicionales anidados en lugar de aplicar el patrón Strategy? ¿Quién entiende el acoplamiento oculto que ese cambio introduce? Eso requiere más criterio técnico, no menos.

Lo que sí desaparece —y esto es importante— es el desarrollador que solo sabe escribir código mecánico, sin entender diseño, sin entender sistemas, sin entender trade-offs. Ese perfil ya estaba en declive antes de la IA. Lo que emerge es un desarrollador que actúa más como ingeniero de sistemas y director técnico de agentes: alguien que sabe especificar intención con precisión, que puede evaluar output a alto nivel, que mantiene el modelo mental del sistema completo.

Y aquí está la paradoja que nos preocupa profundamente: la IA está bajando la barrera de entrada al mismo tiempo que eleva el listón de lo que significa hacerlo bien. Eso crea una brecha enorme. Tendrás más gente generando código, pero menos gente capaz de entender lo que se ha generado. Y esa brecha es exactamente lo que alimenta la deuda cognitiva del codebase que mencionábamos antes.

**Lo que el Radar refuerza consistentemente —pair programming, TDD, fitness functions, code review riguroso— no son reliquias del pasado. Son los mecanismos que permiten que un equipo mantenga comprensión colectiva del sistema mientras la velocidad de generación se dispara.

El rol del desarrollador no desaparece. Se bifurca: los que entienden profundamente los sistemas se vuelven exponencialmente más valiosos; los que delegaron ese entendimiento a la IA se vuelven prescindibles. La IA no elimina la necesidad de criterio técnico. La hace más cara cuando falta.

• Por otro lado, has comentado también “MCP by default” y me parece muy interesante ya que hubo o hay un boom alrededor de este concepto, naciendo MCPs de debajo de las piedras. ¿Qué riesgos reales tiene abusar de este concepto o usarlo cuando realmente no se necesita?

El boom de MCP es un caso de libro de lo que pasa cuando una tecnología resuelve un problema real pero la industria la sobreextiende hasta convertirla en un martillo que busca clavos.

MCP tiene valor genuino. Cuando necesitas contratos de herramientas estructurados, límites de autenticación OAuth y acceso multi-tenant gobernado, es la solución correcta. El problema es que estamos viendo equipos y vendors usarlo como capa de integración por defecto, incluso cuando un CLI bien diseñado con --help decente y respuestas JSON estructuradas daría exactamente lo mismo sin el overhead del protocolo.

El primer riesgo real es lo que llamamos el “abstraction tax”. Cada capa de protocolo entre un agente y una API pierde fidelidad. Para APIs simples eso es tolerable; para APIs complejas, esas pérdidas se acumulan. El agente recibe una versión empobrecida de la interfaz original, y eso se traduce en comportamiento degradado o en prompts cada vez más elaborados para compensar.

El segundo riesgo es de seguridad, y este es el que más nos preocupa. Las APIs internas típicamente exponen datos sensibles o permiten operaciones destructivas. Cuando un desarrollador humano las consume, hay arquitectura, code reviews y contexto organizacional que mitigan esos riesgos. Cuando haces una conversión naïve de API a MCP y se la entregas a un agente autónomo, eliminas esas salvaguardas. No hay forma determinista de prevenir que el agente abuse de esos endpoints. Y aquí aparece de nuevo el lethal trifecta: datos privados, contenido no confiable, acción externa. La mayoría de los MCP servers útiles lo cumplen por defecto.

El tercer riesgo es de complejidad operacional innecesaria. MCP introduce overhead de mantenimiento, versionado y gobernanza. Si lo adoptas sin necesitarlo, estás pagando ese coste sin recibir el beneficio.

Lo que recomendamos es una pregunta previa obligatoria: ¿tu sistema realmente requiere interoperabilidad a nivel de protocolo? Si la respuesta no es un “sí” claro, un CLI bien diseñado o una función directa es mejor opción. MCP tiene su lugar, pero ese lugar no es “en todas partes”.

• También me gustaría hablar del último riesgo que has apuntado “shadow IT acelerado por IA”. ¿Cómo afecta realmente esto a una organización? ¿Qué implicaciones tiene en todos los sentidos, incluyendo los costes o la seguridad?

Este es uno de los riesgos que más nos preocupa precisamente porque no parece peligroso hasta que ya es demasiado tarde.

Lo que estamos observando es una versión turbocargada de algo que ya existía. Las hojas de cálculo que “silenciosamente gobiernan el negocio” llevan décadas siendo un problema. Pero ahora, con herramientas como Claude Cowork, n8n con integración de APIs de IA, o simplemente un product manager con acceso a un coding agent, el salto de “automatización informal” a “sistema crítico no gobernado” se produce en días, no en meses.

El impacto organizacional es multidimensional.

En seguridad, el problema central es que estos sistemas se construyen sin threat modeling, sin revisión de permisos, sin gestión de secretos. Un workflow de n8n que conecta Slack con un CRM vía OpenAI puede estar exfiltrando datos de clientes sin que nadie lo sepa. Y aquí vuelve el lethal trifecta: datos privados, contenido no confiable, acción externa. Ese workflow lo cumple por defecto.

En costes, el problema es la invisibilidad. Los equipos de finanzas no ven las llamadas a APIs de modelos que se están acumulando en tarjetas corporativas o cuentas cloud personales. Hemos visto organizaciones con docenas de integraciones paralelas haciendo llamadas redundantes a GPT-4 porque nadie sabía que el equipo de al lado ya había resuelto el mismo problema.

En deuda técnica y gobernanza, lo que empieza como un prototipo desechable se convierte en infraestructura crítica. Nadie lo documenta, nadie lo testea, y cuando el creador original se va, nadie sabe cómo funciona. Es exactamente el patrón de las macros de Excel, pero con capacidad de ejecutar acciones en sistemas externos.

Lo que recomendamos no es prohibir, sino canalizar. Sandboxes internos instrumentados donde los no-desarrolladores puedan experimentar con visibilidad. Un catálogo compartido de workflows existentes para evitar duplicación. Y criterios claros para determinar cuándo un prototipo necesita convertirse en una aplicación de producción con ingeniería real detrás.

La IA democratiza la construcción de software. Eso es genuinamente valioso. Pero democratizar sin gobernar es simplemente acelerar el caos.

• Muchas gracias por toda esta información tan valiosa que nos estás dando. Para terminar la entrevista y concluir, en pocas palabras, ¿qué crees que tenemos que tener en cuenta tanto los profesionales del sector como las empresas para sobrevivir a este tsunami que ya está aquí?

Lo que hemos aprendido de todos estos ciclos del Radar se puede condensar en algo que puede sonar paradójico: la mejor forma de adaptarse a la velocidad de la IA es invertir en lo que no cambia.

Los fundamentos de ingeniería —código limpio, testing, diseño deliberado, feedback loops cortos— no son nostalgia. Son exactamente lo que permite que la IA amplifique valor en lugar de amplificar caos. Lo hemos visto una y otra vez.

Para los profesionales, el mensaje es claro: no compitas con la IA en velocidad de generación de código. Compite en juicio. En capacidad de hacer las preguntas correctas, de detectar cuándo un agente está tomando un camino equivocado, de entender el sistema completo. Eso es lo que la IA no puede reemplazar todavía, y es lo que más valor tiene ahora mismo. Invierte en entender profundamente los sistemas que construyes, no solo en construirlos más rápido.

Para las empresas, el error más costoso que podemos ver es tratar la IA como una iniciativa de productividad individual en lugar de una transformación sistémica. Si introduces agentes sobre procesos rotos, sobre codebases sin disciplina, sobre equipos sin cultura de feedback, simplemente vas a llegar al desastre más rápido.

Y hay algo que me parece crítico para ambos: aprender a distinguir entre velocidad y progreso. Más PRs, más líneas de código, más workflows automatizados no son progreso si el rework rate sube, si nadie entiende lo que se ha construido, si la deuda cognitiva se acumula silenciosamente.

El tsunami ya está aquí, sí. Pero los que van a sobrevivir no son los que nadan más rápido. Son los que saben cuándo nadar, cuándo parar y cuándo cambiar de dirección.

Si quieres tener el contenido de la entrevista en PDF, puedes descargártelo directamente.

Conclusiones

Para mí, una de las conclusiones más relevantes es que los fundamentos de ingeniería (testing, observabilidad o diseño arquitectónico) nunca han sido más críticos que ahora, no porque sean nuevos, sino porque su ausencia tiene consecuencias inmediatas y a gran escala en un entorno donde los agentes pueden generar código nuevo y cambios de código masivos en minutos.

Me gusta como concluye la entrevista con el mensaje claro, tanto para profesionales como para organizaciones, de que la mejor forma de adaptarse a la velocidad de la IA es invertir en lo que no cambia. La clave no es competir con la IA en velocidad de generación, sino en juicio, criterio técnico y comprensión profunda de los sistemas.

En mi opinión, y creo que comparto la opinión del radar, las empresas que traten la IA como una iniciativa de productividad individual en lugar de una transformación sistémica corren el riesgo de llegar al desastre más rápido.

Espero que os haya gustado el enfoque que he dado al artículo y, como comentaba, publicaremos otro artículo con el “making of”, el repositorio y los detalles técnicos del RAG usado. ¡Te leo en comentarios! 👇

También revisamos las limitaciones de ese enfoque, que forzaron la transición estocástica de los años 80 y 90, donde los modelos estadísticos (n-gramas y HMM) empezaron a inferir información directamente desde los datos.

Estos modelos rápidamente se toparon con la dispersión de datos y la ceguera semántica del one-hot encoding.

En este post veremos la introducción de conceptos como Word2Vec, redes neuronales recurrentes (RNN) y redes Long-Short Term Memory (LSTM).

La revolución de las representaciones distribuidas: Word2Vec

Los sistemas tradicionales asignaban un índice arbitrario a cada término, creando matrices gigantescas donde las relaciones semánticas desaparecían por completo. Esta falta de vinculación impedía que el software extrajera valor real de los datos no estructurados. En 2013, un equipo de investigadores liderado por Tomas Mikolov presentó Word2Vec.

Word2Vec propuso un modelo basado en redes neuronales superficiales que nos permite representar palabras en un espacio continuo, como vectores densos (generalmente de entre 50 y 300 dimensiones, en lugar de decenas de miles). Este modelo mejoraba la relación semántica y matices de las palabras con una alta precisión.

Word2Vec transformó el texto plano en vectores densos dentro de un espacio continuo y logró que conceptos similares coexistieran en zonas matemáticas cercanas.

La arquitectura de Word2Vec introdujo dos variantes de modelos predictivos para calcular las representaciones continuas de las palabras a partir de corpus de texto extensos:

• Continuous Bag-of-Words (CBOW): la red neuronal predice la probabilidad de una palabra objetivo actual basándose en la ventana de palabras del contexto que la rodea.
• Skip-Gram: opera bajo el principio inverso al de CBOW. Utiliza la palabra actual para predecir las palabras que la rodean dentro de un rango o ventana determinada.

Gracias a este enfoque, se pudieron capturar analogías de patrones semánticos y sintácticos, como la famosa ecuación vectorial: “rey – hombre + mujer ≈ reina”.

El modelo dedujo, sin instrucción externa, el vector que representaba el concepto de "realeza" y el vector de "género", lo que le permitió navegar por el léxico como si fuera un plano de coordenadas geográficas.

Todo esto a través de simples operaciones vectoriales y mediciones por similitud de coseno, sin recurrir a costosos procesos de computación.

Su bajo coste computacional y libre disponibilidad de código, publicado en abierto para la comunidad de investigación, impulsaron casi instantáneamente la adopción del uso de embeddings en todo el espectro del PLN.

Este hito marcó el camino hacia las arquitecturas de aprendizaje profundo, específicamente las Redes Neuronales Recurrentes (RNN) y, más tarde, los modelos basados en la arquitectura Transformers (Church, 2017).

La llegada del Aprendizaje Profundo (DL) y la gestión del contexto: Redes Neuronales Recurrentes (RNN)

Superado el reto de dar significado a las palabras de forma aislada, el siguiente gran desafío fue entender el contexto. El lenguaje es, por naturaleza, una secuencia temporal. Aquí el orden de los factores sí altera (y drásticamente) el producto.

Por eso, un sistema conversacional no puede tratar los textos como simples bolsas de palabras desordenadas, necesita una memoria dinámica capaz de evolucionar al mismo ritmo que la propia frase.

El DL revolucionó el campo del PLN al permitir el desarrollo de modelos mucho más eficientes y potentes en la gestión de datos secuenciales. Dentro de las múltiples arquitecturas del DL destacan las RNN, que fueron introducidas en los años 80 como una mejora respecto a las redes neuronales tradicionales.

A diferencia de las redes tradicionales, donde la información fluye unidireccionalmente desde las capas de entrada hacia las capas de salida, las arquitecturas RNN introdujeron conexiones recurrentes en sus neuronas ocultas.

Esta recurrencia funcionaba como una memoria a corto plazo que dotaba al sistema de un contexto continuo. De este modo, al procesar una secuencia, las RNN empezaron a capturar de forma natural las dependencias temporales del texto.

Sin embargo, al implementar RNNs profundas en tareas complejas como los chatbots generativos, los equipos de investigación se percataron del problema del descenso del gradiente, un fenómeno que saboteaba por completo la memoria a largo plazo del sistema.

Durante el entrenamiento, mediante el algoritmo de retropropagación a través del tiempo, el cálculo de errores exige multiplicar las matrices de pesos de forma iterativa.

Si esos valores son inferiores a la unidad, el gradiente se reduce exponencialmente hasta desaparecer de las ecuaciones. La consecuencia práctica fue un escenario donde los chatbots olvidaban el inicio de la frase al llegar al segundo párrafo del diálogo.

Las RNN tradicionales eran incapaces de conectar una petición inicial con una respuesta final si la secuencia superaba un límite de palabras, por lo que terminaba empañando la experiencia del usuario.

La solución a largo plazo: redes Long Short-Term Memory (LSTM) (1997)

Para solucionar el problema del descenso del gradiente, los investigadores Sepp Hochreiter y Jürgen Schmidhuber desarrollaron en 1997 las Long Short-Term Memory (LSTM), una arquitectura que redefiniría el procesamiento secuencial.

Las LSTM eran capaces de preservar información relevante durante periodos de tiempo significativamente más prolongados. En lugar de permitir que los nuevos datos destruyeran el contexto previo, establecieron un canal central de memoria protegido por tres capas de redes neuronales:

1. Forget gate: descarta la información obsoleta mediante un filtrado que limpia el ruido del sistema. Analiza el contexto de la palabra en curso y el estado previo para devolver un valor entre cero y uno.
2. Input gate: selecciona los nuevos datos que merecen incorporarse a la memoria a largo plazo. Así evita la saturación del espacio de almacenamiento con términos irrelevantes.
3. Output gate: determina qué porción del contexto acumulado debe transmitirse al siguiente paso secuencial. Esto regula la respuesta inmediata que hereda el sistema.

La integración de estas estructuras ayudó a mitigar casi en su totalidad el descenso del gradiente.

Esto permitía un modelado conversacional más coherente, donde un agente artificial podía recordar el nombre o la intención del usuario a través de múltiples turnos de diálogo.

Conclusiones

En este post hemos analizado cómo el éxito de los sistemas conversacionales dependía de resolver un delicado equilibrio entre la representación semántica y la gestión de la memoria.

Mientras que Word2Vec transformó el significado de las palabras en coordenadas accesibles, las arquitecturas RNN y LSTM consiguieron que las máquinas capturaran la naturaleza secuencial y temporal del lenguaje humano.

Sin embargo, la búsqueda de una comprensión aún más profunda y escalable no se detuvo ahí.

En el próximo post daremos el gran salto hacia la era moderna de la IA, donde analizaremos la llegada de los modelos Seq2Seq, el nacimiento de los mecanismos de atención, y la arquitectura Transformers.

¡Nos vemos en la siguiente entrega!

Referencias

• LSTM
• Fundamentals of Recurrent Neural Network (RNN) and Long Short-Term Memory (LSTM) Network

Suena bastante bien. El problema es que una inteligencia artificial puede ser extremadamente eficiente y, al mismo tiempo, estar haciendo exactamente lo equivocado.

Estos son cuatro ejemplos que lo demuestran.

Cuando Barbie se convierte en una tragedia

En 2023, un medio de comunicación estadounidense utilizó inteligencia artificial para generar automáticamente artículos sobre tendencias a partir de lo que estaba ocurriendo en redes sociales.

La película de Barbie era uno de los grandes fenómenos del momento. El problema llegó cuando el sistema se encontró con expresiones coloquiales y exageraciones habituales en redes sociales.

Frases como “I'm dying”, utilizada para expresar entusiasmo o diversión, fueron interpretadas literalmente. El resultado fue un artículo cuyo titular hablaba de una supuesta reunión de miles de personas para cometer un asesinato en masa en honor a Barbie.

Una expresión que para una persona resulta evidentemente metafórica puede convertirse para una máquina en un dato que interpretar literalmente.

La IA que descubrió que ganar no era necesario

Otro ejemplo muy conocido procede de un experimento de aprendizaje por refuerzo realizado en el videojuego Coast Runners. El objetivo era sencillo: conseguir la máxima puntuación y completar la carrera.

Pero la inteligencia artificial descubrió que podía obtener más puntos explotando una determinada mecánica del juego.

En lugar de competir y llegar a la meta, comenzó a dar vueltas en una zona concreta del circuito, chocando repetidamente contra obstáculos para conseguir potenciadores.

Desde nuestra perspectiva, estaba jugando fatal. Desde la perspectiva del algoritmo, estaba haciendo exactamente lo que se le había pedido: maximizar la puntuación. De hecho, consiguió una puntuación superior a la de los jugadores humanos.

El experimento demuestra uno de los problemas más interesantes de los sistemas de IA: si definimos mal el objetivo, la máquina puede encontrar estrategias que optimicen el indicador pero destruyan el propósito real de la tarea.

El algoritmo que confundió tanques con nubes

Durante la Guerra Fría, el ejército estadounidense investigó el uso de redes neuronales para detectar tanques camuflados en fotografías aéreas.

Los resultados iniciales parecían espectaculares. El sistema alcanzaba una precisión del 100% con las imágenes utilizadas durante las pruebas. Pero cuando se enfrentó a fotografías nuevas, el rendimiento se desplomó.

La explicación era mucho más sencilla de lo que parecía: las fotografías de los tanques se habían tomado en días nublados, mientras que las imágenes del bosque sin tanques correspondían a días soleados.

La inteligencia artificial no había aprendido a detectar tanques, había aprendido a distinguir fotografías con cielos grises de fotografías con cielos despejados.

Este caso es un ejemplo clásico de overfitting y de uno de los grandes riesgos de la inteligencia artificial: un modelo puede encontrar correlaciones que funcionan perfectamente con los datos de entrenamiento, pero que no tienen ninguna relación con el problema que queremos resolver.

El robot aspirador que decidió escapar

En 2022, un robot aspirador de un hotel de Cambridge protagonizó una pequeña aventura cuando consiguió salir del edificio a través de una puerta automática.

El sensor encargado de detectar desniveles no identificó correctamente el pequeño bordillo de la entrada. Para el sistema, el suelo continuaba al otro lado de la puerta, así que siguió avanzando.

Los empleados tardaron varias horas en darse cuenta de que el robot había desaparecido. Finalmente apareció al día siguiente, escondido bajo un seto y sin batería, después de pasar la noche intentando aspirar el exterior del hotel.

Historias distintas con un aprendizaje común

Estas cuatro historias son muy diferentes, pero tienen algo en común. En ninguno de los casos la inteligencia artificial estaba intentando hacer algo mal. Al contrario: estaba tratando de cumplir el objetivo que se le había marcado.

El problema aparece cuando existe una diferencia entre lo que las personas queremos conseguir y aquello que realmente estamos pidiendo al sistema que optimice.

Por eso, a medida que los sistemas de IA empiezan a asumir tareas más complejas y tomar decisiones con mayor autonomía, el contexto, la supervisión y la correcta definición de los objetivos se vuelven tan importantes como la capacidad del propio modelo.

No basta con conseguir que una IA haga algo. También tenemos que asegurarnos de que entiende qué significa hacerlo bien.