No digo que la Inteligencia Artificial no vaya a destruir tareas. Ya lo está haciendo. Tampoco digo que no haya empleos en riesgo. Sería ingenuo. Lo que me cuesta aceptar es la idea simple de que más IA significa automáticamente menos empleo. La historia de la tecnología suele ser bastante más incómoda que ese titular.

La imagen que compartía Apollo con datos semanales de empleo privado de ADP me parece una buena excusa para hablar de esto. El gráfico se titulaba “Jevons paradox in real time” y mostraba una creación de empleo positiva en Estados Unidos, no una caída abrupta. No prueba que la IA esté creando puestos por sí sola, pero sí desmonta una parte del relato más alarmista: si la destrucción masiva de empleo por IA ya estuviera en marcha de forma evidente, deberíamos verla con más claridad en los datos agregados.

A mí me parece que estamos mirando mal el problema. La IA no solo sustituye trabajo. También reduce el coste de hacer determinadas cosas. Y cuando algo se vuelve más barato, más rápido y más accesible, muchas veces no se usa menos. Se usa mucho más.

La paradoja de Jevons aplicada al trabajo intelectual

William Stanley Jevons explicó en 1865 algo que sigue siendo muy útil para entender la tecnología. Cuando las máquinas de vapor se hicieron más eficientes y necesitaron menos carbón por unidad de trabajo, el consumo total de carbón no cayó. Aumentó. La eficiencia abarató el uso de la energía, permitió nuevas industrias y multiplicó la demanda total.

Esa es la paradoja de Jevons: una mejora de eficiencia puede aumentar el consumo total del recurso que parecía que iba a ahorrar.

Con la IA puede estar ocurriendo algo parecido, pero aplicado al trabajo intelectual. Si redactar un informe cuesta menos, se harán más informes. Si programar una funcionalidad cuesta menos, se intentarán más productos. Si analizar un contrato es más rápido, se revisarán más contratos. Si crear campañas, documentación, soporte, análisis financiero o código es más barato, aparecen proyectos que antes no compensaban.

La Inteligencia Artificial baja el coste de producir conocimiento. Y cuando baja ese coste, el mercado no siempre responde reduciendo empleo. Puede responder ampliando el número de cosas que quiere hacer.

Esto ya pasó con los ordenadores personales. A finales de los 80 y principios de los 90 también se decía que el PC acabaría con gran parte del trabajo de oficina. Y sí, eliminó tareas. Desaparecieron muchos procesos manuales, cambiaron perfiles y se automatizaron trabajos repetitivos. Pero también nacieron categorías enteras: soporte técnico, administración de sistemas, software empresarial, diseño digital, bases de datos, comercio electrónico, marketing online, ciberseguridad, cloud, analítica, ERP, CRM y un largo etcétera.

La oficina no desapareció. Se llenó de pantallas.

Con la IA puede ocurrir algo parecido. No desaparecerá el trabajo intelectual, pero se va a llenar de agentes, modelos, copilotos, automatizaciones y nuevas expectativas de productividad.

Datos que invitan a frenar el alarmismo

Los datos de empleo no deben leerse como una verdad absoluta sobre la Inteligencia Artificial. El mercado laboral depende de tipos de interés, consumo, inversión, demografía, salarios, geopolítica y muchos otros factores. Pero sí sirven para poner límites al relato.

En abril de 2026, ADP estimó que el sector privado de Estados Unidos añadió 109.000 empleos y que el salario anual subió un 4,4 %. BLS, la oficina de estadísticas laborales estadounidense, publicó que el empleo no agrícola aumentó en 115.000 puestos ese mismo mes y que la tasa de paro se mantuvo en el 4,3 %. ADP también señalaba que, para las cuatro semanas terminadas el 9 de mayo de 2026, los empleadores privados añadieron una media de 35.750 puestos semanales.

No son datos de euforia, pero tampoco de colapso.

Lo interesante no es negar los riesgos. Lo interesante es separar tres cosas que se mezclan demasiado: sustitución de tareas, reestructuración de empresas y destrucción neta de empleo.

Una empresa puede despedir usando la IA como argumento. Otra puede estar corrigiendo excesos de contratación de 2021 y 2022. Otra puede externalizar. Otra puede automatizar tareas administrativas. Otra puede contratar perfiles de datos, automatización, seguridad o integración de IA. Meter todo eso en la misma frase, “la IA destruye empleo”, es cómodo, pero poco preciso.

También hay que mirar dónde se está moviendo la demanda. BLS proyecta que los empleos de oficina y soporte administrativo disminuirán durante la década 2024-2034, aunque seguirán generando unos 2 millones de vacantes anuales por sustitución de trabajadores que dejan esos puestos. Al mismo tiempo, las ocupaciones de informática y tecnología tenían en mayo de 2024 un salario anual mediano de 105.990 dólares, frente a 49.500 dólares para el conjunto de ocupaciones. Y dentro de esa familia, perfiles como analistas de sistemas o investigadores informáticos siguen proyectando crecimientos superiores a la media.

La foto real no es “todos pierden” ni “todos ganan”. Es una redistribución. Y, como casi siempre, quien se adapta antes captura más valor.

Ejemplos donde la eficiencia aumentó la demanda

La paradoja de Jevons no es una curiosidad histórica. La vemos una y otra vez.

Cuando el cloud hizo más barato lanzar infraestructura, no redujo el uso de servidores. Lo multiplicó. Antes una empresa tenía que comprar máquinas, provisionar espacio, montar red, prever capacidad y amortizar hardware. Con el cloud, desplegar una aplicación se volvió más fácil. Resultado: más aplicaciones, más entornos, más pruebas, más datos, más consumo de infraestructura.

Cuando las cámaras digitales y los móviles hicieron casi gratis sacar fotos, no hicimos menos fotos. Hicimos millones más.

Cuando el coste de publicar cayó con WordPress, redes sociales y newsletters, no se publicaron menos artículos. Se publicó una cantidad inmensa de contenido.

Cuando crear una tienda online se volvió más fácil con Shopify, WooCommerce o Prestashop, no desapareció el comercio. Aparecieron miles de pequeños comercios digitales que antes no habrían podido asumir el coste técnico.

Con la Inteligencia Artificial ocurre algo parecido. Si una pyme puede preparar una propuesta comercial en una hora en lugar de en una tarde, quizá no reduzca plantilla. Quizá prepare cinco propuestas más al mes. Si un desarrollador puede crear una prueba de concepto en dos días en lugar de dos semanas, quizá la empresa no despida al equipo. Quizá pruebe diez ideas que antes no pasaban del PowerPoint.

La clave es esta: cuando la unidad de trabajo baja de precio, el volumen puede subir.

El riesgo real: el empleo junior y la brecha de productividad

Ahora bien, no quiero caer en un optimismo ingenuo. Hay riesgos claros.

El primero está en los perfiles junior. Muchas tareas de entrada al mercado consisten en hacer borradores, revisar documentación, preparar informes, limpiar datos, redactar textos básicos, hacer pruebas, contestar tickets sencillos o escribir código poco complejo. Justo ahí la IA ayuda mucho.

Si las empresas eliminan demasiadas posiciones de entrada, pueden romper la cantera. Hoy parece eficiente sustituir parte del trabajo junior con IA. Mañana puede faltar gente con experiencia media porque nadie aprendió haciendo ese trabajo básico.

El segundo riesgo está en la brecha entre profesionales. Un abogado con IA no sustituye automáticamente a todos los abogados. Pero un abogado que usa IA bien puede trabajar mucho más rápido que otro que no la usa. Lo mismo ocurre con programadores, consultores, financieros, periodistas, técnicos de sistemas o responsables de marketing.

El tercero está en la concentración empresarial. Las grandes compañías pueden pagar mejores modelos, más contexto, más agentes, más integración con datos internos y más automatización. Las pymes pueden quedarse con versiones más limitadas si no tienen estrategia, presupuesto o conocimiento técnico. Esto puede abrir una brecha productiva muy seria.

El cuarto está en la energía y la infraestructura. Si la paradoja de Jevons se cumple en IA, no consumiremos menos cómputo por hacer modelos más eficientes. Consumiremos más. Más agentes, más inferencia, más centros de datos, más memoria, más redes, más electricidad. La eficiencia puede abaratar la inteligencia y, precisamente por eso, disparar su uso.

Mi lectura personal

Mi sensación es que la IA no va a destruir el trabajo de una forma lineal. Va a cambiar su precio.

Algunas tareas valdrán menos porque serán más fáciles de automatizar. Otras valdrán más porque coordinarán sistemas, personas, datos y decisiones. El valor se desplazará desde “hacer la tarea” hacia “saber qué tarea merece la pena hacer, con qué datos, bajo qué criterios y con qué responsabilidad”.

Esto me parece importante para cualquiera que dirija una empresa o un equipo. La pregunta no debería ser solo “¿cuánta gente puedo ahorrar con IA?”. Esa es una pregunta pobre. La pregunta buena es: “¿qué puedo hacer ahora que antes no era viable?”.

¿Puedo atender mejor a mis clientes? ¿Puedo documentar procesos que nunca documentábamos? ¿Puedo detectar errores antes? ¿Puedo lanzar más experimentos? ¿Puedo vender en más mercados? ¿Puedo hacer mejor seguimiento financiero? ¿Puedo mejorar seguridad? ¿Puedo dar herramientas a personas que antes estaban bloqueadas por falta de tiempo?

Ahí está la parte interesante.

La IA no elimina la necesidad de criterio. Al revés. Cuando producir se vuelve barato, decidir qué producir se vuelve más importante. Cuando generar texto es fácil, tener algo que decir importa más. Cuando escribir código se acelera, entender el problema pesa más. Cuando un agente puede ejecutar tareas, definir límites, permisos y objetivos se vuelve esencial.

La paradoja de Jevons aplicada a la IA no significa que todo vaya a ir bien. Significa que la eficiencia no garantiza una reducción del trabajo humano. Puede producir más demanda, más presión, más competencia y más actividad. También puede dejar atrás a quienes no se adapten.

No veo todavía una evidencia clara de que la IA esté destruyendo empleo de forma masiva en los datos agregados. Sí veo otra cosa: está cambiando la frontera de productividad. Y cuando esa frontera se mueve, cada empresa, cada profesional y cada país tiene que decidir si se queda mirando o aprende a trabajar con la nueva herramienta.

Los PCs no acabaron con la oficina. La transformaron.

La IA probablemente no acabará con el trabajo intelectual. Lo hará más exigente, más medido y más competitivo.

Preguntas frecuentes

¿Qué es la paradoja de Jevons aplicada a la IA?
Es la idea de que, si la IA hace más barato y eficiente producir conocimiento, código, análisis o contenido, la demanda total de esas tareas puede aumentar en lugar de caer.

¿La IA destruirá empleo?
Destruirá tareas y algunos puestos concretos, especialmente los más repetitivos. Pero los datos agregados aún no muestran una destrucción masiva de empleo atribuible claramente a la IA.

¿Qué perfiles pueden estar más presionados?
Los perfiles junior y las tareas de entrada basadas en trabajo repetitivo, revisión básica, redacción simple, soporte inicial o código poco complejo pueden verse más expuestos.

¿Qué deberían hacer empresas y profesionales?
Medir dónde la IA mejora productividad real, formar equipos, rediseñar procesos y usarla para ampliar capacidad, no solo para recortar costes a corto plazo.

Fuentes:

• Apollo, “Zero Evidence of AI-Related Job Losses”.
• Apollo, “The Jevons Employment Effect From AI”.
• ADP Research, National Employment Report y NER Pulse.
• U.S. Bureau of Labor Statistics, Employment Situation, abril de 2026.
• U.S. Bureau of Labor Statistics, Occupational Outlook Handbook.
• Yale Energy History, William Stanley Jevons, The Coal Question.
• OECD, trabajos sobre inteligencia artificial y empleo.

La entrada La IA no está destruyendo empleo: está cambiando el precio del trabajo aparece primero en Carrero.

Porque la inflación no es una sola. Vivimos dentro de dos inflaciones distintas. Una afecta a los bienes que la tecnología, la globalización, la logística y la escala han conseguido abaratar de forma brutal. La otra afecta a todo aquello que sigue dependiendo de tiempo humano, presencia física, suelo escaso, talento irrepetible o experiencias limitadas. En la primera economía, el salario compra mucho más que hace treinta años. En la segunda, compra bastante menos.

Lo que se pudo fabricar mejor se volvió barato

Hay una parte de nuestra vida cotidiana que se ha abaratado tanto que casi hemos dejado de verla como riqueza. Un televisor de gran formato, que antes era un lujo reservado a pocos hogares, hoy se compra por una fracción de lo que costaba en términos reales. Un móvil de gama media actual tiene más capacidad de cálculo, cámara, pantalla y conectividad que equipos profesionales de hace no tanto. La ropa básica, con todos los problemas laborales y ambientales que puede haber detrás de ciertas cadenas de producción, cuesta muy poco si la comparamos con los salarios de hace tres décadas.

Lo mismo ha ocurrido con las comunicaciones. Quien vivió los noventa recuerda llamar con cuidado, mirar el reloj, pagar llamadas de larga distancia, usar tarjetas telefónicas o conectarse a Internet con la sensación de que cada minuto contaba. Hoy damos por hecho que podemos hablar, enviar vídeos, hacer videollamadas, escuchar música, trabajar en remoto y navegar casi sin límite desde un dispositivo que cabe en el bolsillo.

También viajar cambió de escala. Volar a Londres, Roma o París era antes una decisión importante para muchas familias. Hoy puede costar menos que una cena para dos si se compra con antelación y se aceptan las reglas del bajo coste. No siempre es cómodo, no siempre es tan barato como parece al principio, pero el salto es real.

Esto no ha pasado por casualidad. La productividad en la fabricación, la logística internacional, el software, la automatización y la competencia global han cambiado la estructura de costes. Donde antes había procesos lentos, caros y locales, ahora hay cadenas mundiales capaces de producir millones de unidades con una eficiencia difícil de imaginar hace treinta años.

Una camiseta básica lo explica bien. En 1995 podía costar unas 1.800 pesetas, alrededor de 11 euros. Hoy puede encontrarse entre 3 y 12 euros. No porque el algodón haya dejado de costar dinero, sino porque la cadena completa, desde el diseño hasta el transporte en contenedor, se ha comprimido. La productividad por trabajador ha crecido muchísimo.

Lo que exige tiempo humano se encareció

El contraste aparece cuando miramos un corte de pelo. En 1995 podía costar unas 600 pesetas, unos 3 euros, al menos en mi ciudad natal Herencia (Ciudad Real). Hoy es fácil pagar no menos de 21 ó 22 euros. Y, sin embargo, el servicio es básicamente el mismo: una persona, unas tijeras, un local, media hora y tu cabeza quieta.

No se puede producir un corte de pelo en una fábrica del sudeste asiático y traerlo en barco. No se puede acelerar demasiado sin estropear el resultado. No se puede atender a diez personas a la vez sin convertir el servicio en otra cosa. Esa es la clave.

William Baumol explicó este fenómeno en los años sesenta con la llamada enfermedad de los costes. Hay sectores donde la productividad mejora mucho, como la industria, la tecnología o el transporte. Y hay otros donde apenas puede mejorar sin destruir la esencia del servicio: educación presencial, cuidados, restauración, peluquería, música en directo, teatro, sanidad, clases particulares o servicios personales.

Un cuarteto de cuerda necesita hoy casi el mismo tiempo y los mismos músicos para tocar una pieza que hace dos siglos. Un profesor particular no puede dar una clase realmente personalizada a cien alumnos a la vez. Un camarero no puede multiplicar indefinidamente su productividad sin que el restaurante pierda calidad. Un cuidador de mayores no puede atender a muchas personas con la misma atención que a pocas.

Pero todos esos sectores compiten por trabajadores dentro de la misma economía. Si los salarios generales suben, ellos también tienen que pagar más, aunque su productividad no crezca al mismo ritmo. Por eso sus precios tienden a subir más.

Aquí está una parte importante del malestar actual. Muchas cosas materiales son más baratas que nunca, pero muchas experiencias y servicios presenciales son más caros que nunca. Podemos tener un televisor enorme en casa por poco dinero, pero ir al cine con la familia se ha convertido en una pequeña decisión presupuestaria. Podemos comprar ropa barata, pero cenar fuera con cierta frecuencia pesa mucho más en la cuenta. Podemos hablar gratis por videollamada con medio mundo, pero una clase particular, una consulta, una actividad infantil o una hora de pádel se pagan a precio de tiempo humano.

La experiencia se convirtió en estatus

Sobre esta diferencia económica hay otra capa: el estatus. Antes demostrar cierta posición podía consistir en tener coche, televisor, equipo de música o ropa de marca. Hoy muchos de esos bienes se han democratizado. Casi todo el mundo tiene una pantalla grande, un móvil capaz, acceso a plataformas y ropa suficiente.

El estatus se ha desplazado hacia lo vivido. Haber estado en ese concierto. Haber ido a ese restaurante. Haber viajado a ese destino. Haber conseguido entradas para ese partido. Haber llevado a los niños a ese parque temático. Haber participado en esa experiencia que otros ven en redes sociales.

Pine y Gilmore llamaron a esto la economía de la experiencia a finales de los noventa. Hoy lo vemos con claridad. La experiencia tiene dos características que empujan el precio: es limitada y se puede exhibir. Un artista internacional solo puede actuar unas noches en una ciudad. Un estadio tiene asientos finitos. Un restaurante de moda no puede duplicar mesas sin cambiar por completo la experiencia. Un parque temático tiene capacidad máxima. Una ciudad deseada tiene suelo limitado.

Cuando la demanda crece y la oferta no puede crecer igual, el precio sube. Y si además hay redes sociales, reventa, precios dinámicos y una cultura cada vez más basada en contar lo que se ha vivido, el efecto se amplifica.

Por eso no nos sorprende ver entradas de conciertos a 150, 200 o 500 euros. O partidos de fútbol que antes eran ocio popular y ahora empiezan a parecer un producto premium, al que ya no puede acceder cualquiera. O restaurantes donde reservar es parte del valor. O parques temáticos que ya no venden solo una entrada, sino acceso prioritario, paquetes, experiencias añadidas y hoteles.

No es solo inflación. Es escasez organizada alrededor del deseo.

La vivienda es el caso más doloroso

La vivienda merece un apartado propio, porque no encaja exactamente en la categoría de experiencia, pero comparte algo fundamental: no puede fabricarse libremente donde hace falta.

Un televisor se produce en una fábrica y se distribuye por todo el mundo. Una vivienda en Madrid, Barcelona, Málaga, Valencia o cualquier ciudad tensionada depende de suelo, permisos, financiación, normativa, construcción, ubicación, transporte, empleo cercano y expectativas de inversión. No puedes fabricar miles de pisos en otro continente y traerlos en contenedores.

Por eso la vivienda se ha convertido en el gran divisor generacional. Quien compró hace décadas accedió a un activo relativamente más barato y luego vio cómo se revalorizaba. Quien intenta comprar hoy se encuentra con precios altos desde el principio, salarios que no han crecido al mismo ritmo y alquileres que dificultan ahorrar para la entrada.

Esta es quizá la expresión más dura de las dos inflaciones. La tecnología te da más por menos. La vivienda te pide más por lo mismo, o incluso por menos. Puedes llevar en el bolsillo un móvil que habría parecido ciencia ficción en 1995, pero te cuesta mucho más vivir cerca de tu trabajo o formar una familia sin depender de ayuda externa.

No todo era mejor antes, pero algunas cosas estaban más cerca

Conviene no caer en la nostalgia fácil. En 1995 había menos opciones, menos conectividad, menos comodidad digital, menos acceso a información, menos facilidad para viajar y menos herramientas para crear, aprender o emprender. Muchas cosas eran peores. Muchas eran más lentas. Algunas, directamente, no existían.

Pero también es verdad que ciertos objetivos básicos estaban más cerca para una parte de la clase media. Comprar una vivienda, formar una familia, pagar actividades de los hijos o acceder a cierto ocio local no parecían tan alejados del salario. No porque todo fuera barato, sino porque la estructura de precios era distinta.

Hoy la abundancia se concentra en lo replicable. Tenemos música infinita, vídeo infinito, información infinita, ropa barata, pantallas baratas, comunicación barata y vuelos más accesibles. La escasez se concentra en lo presencial, lo localizado, lo humano y lo simbólico. Tiempo, suelo, cuidado, atención, talento, exclusividad y experiencias.

Ahí nace la paradoja de nuestro tiempo: vivimos rodeados de tecnología extraordinaria, pero muchas personas sienten que la vida normal se ha vuelto más cara. Y no están necesariamente equivocadas. Lo que ocurre es que “vida normal” ya no se compone solo de bienes industriales baratos. También incluye vivienda, ocio familiar, cuidados, educación, salud, deporte, restauración y pertenencia social. Justo las categorías donde la productividad no ha crecido igual o donde la oferta es limitada.

No vivimos simplemente en una economía cara. Vivimos en una economía partida. Donde hay escala, software y competencia global, somos más ricos que nunca. Donde hay presencia humana, suelo escaso y experiencias deseadas, somos más pobres de lo que esperábamos.

Por eso alguien puede decir con razón que nunca hemos tenido tanto por tan poco. Y otro puede contestar, también con razón, que salir una tarde con su familia se ha convertido en un lujo. Los dos están mirando precios reales. Solo que miran inflaciones distintas.

Preguntas frecuentes

¿Qué significa que vivimos dentro de dos inflaciones?

Significa que algunos bienes, como tecnología, ropa básica o telecomunicaciones, se han abaratado en términos relativos, mientras muchos servicios presenciales, ocio, vivienda y experiencias se han encarecido mucho más que los salarios.

¿Qué es la enfermedad de costes de Baumol?

Es una teoría económica que explica por qué ciertos servicios suben de precio aunque no mejoren mucho su productividad. Si requieren tiempo humano difícil de automatizar, sus costes crecen con los salarios generales.

¿Por qué los conciertos, restaurantes o partidos son cada vez más caros?

Porque son experiencias con oferta limitada y demanda creciente. Un estadio tiene asientos finitos, un artista solo puede actuar ciertos días y un restaurante no puede duplicar mesas sin cambiar su propuesta.

¿Por qué la tecnología parece tan barata comparada con otros gastos?

Porque la fabricación, el software, la automatización y la logística global han multiplicado la productividad. Eso permite vender productos mucho mejores por menos dinero relativo que hace treinta años.

La entrada Vivimos dentro de dos inflaciones distintas aparece primero en Carrero.

Durante mucho tiempo se ha hablado de Amazon como si fuera una tienda online enorme. Esa descripción se quedó corta hace años. Amazon es marketplace, operador logístico, proveedor cloud, red publicitaria, plataforma audiovisual, fabricante de dispositivos, actor en salud, empresa de satélites, proveedor de Inteligencia Artificial y ahora también quiere vender al mundo su cadena de suministro como servicio. No es una empresa que haya crecido mucho en un sector. Es una compañía que ha ido entrando en las capas que conectan al consumidor, al vendedor, al desarrollador, al anunciante y al proveedor de infraestructura.

En 2025, Amazon alcanzó 716.900 millones de dólares en ventas netas. AWS facturó 128.700 millones y generó 45.600 millones de beneficio operativo. Ese dato importa porque muestra que el cloud no es una línea secundaria, sino una de las grandes fuentes de rentabilidad del grupo. Mientras tanto, la compañía reconoce crecimientos fuertes en publicidad, suscripciones, ventas de terceros e infraestructura tecnológica, con inversiones crecientes en Inteligencia Artificial.

El patrón Amazon: construir para sí misma y venderlo después

AWS nació porque Amazon necesitaba infraestructura tecnológica para su propio negocio. Con el tiempo, esa capacidad interna se convirtió en un producto para terceros y acabó cambiando la industria cloud. Ahora Amazon está intentando una jugada parecida con la logística.

El lanzamiento de Amazon Supply Chain Services (ASCS) abre su red de transporte, distribución, fulfillment y paquetería a empresas de todos los tamaños, aunque no vendan en Amazon. La compañía habla de mover, almacenar y entregar desde materias primas hasta productos terminados usando la misma cadena de suministro que sostiene Amazon y a sus vendedores independientes. Entre los primeros clientes figuran Procter & Gamble, 3M, Lands’ End y American Eagle Outfitters.

La parte inquietante no es que Amazon compita con UPS, FedEx o DHL. Eso ya era evidente desde hace tiempo. La parte relevante es que Amazon no quiere ser simplemente un operador logístico. Quiere controlar la cadena completa: la demanda, el inventario, el anuncio, el almacén, la entrega, la devolución y, cada vez más, la infraestructura digital donde se ejecuta todo eso.

Si una marca vende en Amazon, paga comisiones. Si quiere destacar, paga publicidad. Si quiere entregar rápido, usa FBA. Si quiere mover mercancía entre países, ahora puede usar ASCS. Si quiere alojar tecnología, puede usar AWS. Si quiere Inteligencia Artificial, puede usar Bedrock, Trainium, Inferentia o servicios de terceros dentro de AWS. Cada servicio puede tener sentido por separado. La suma empieza a parecer una dependencia estructural.

No diría que Amazon tenga un monopolio legal en todos los mercados donde opera. Eso sería impreciso. En cloud compite con Microsoft y Google. En logística compite con UPS, FedEx, DHL, Maersk, DSV o Kuehne+Nagel. En ecommerce compite con Walmart, Alibaba, Temu, Shein, Shopify, eBay y muchos retailers tradicionales. En publicidad sigue lejos de Google y Meta en muchos segmentos. Pero el problema real no está solo en la cuota de cada mercado. Está en la capacidad de conectar mercados.

Esta tabla es el resumen del problema. Cada rival ve una parte. UPS ve la logística. Microsoft ve el cloud. Google ve la publicidad y la IA. Walmart ve el retail. Netflix ve el entretenimiento. Pero Amazon conecta esas piezas en una misma maquinaria.

Europa ve el riesgo, pero llega tarde

Desde Europa, esto debería preocuparnos más de lo que parece. Aquí hablamos mucho de soberanía digital, protección de datos, competencia y dependencia tecnológica, pero la realidad es bastante dura: las grandes plataformas estadounidenses siguen ocupando las capas críticas de nuestra economía digital.

El Parlamento Europeo ha señalado que AWS, Microsoft Azure y Google Cloud concentran alrededor del 70 % del mercado cloud de la UE, mientras la cuota conjunta de los proveedores europeos cayó hasta aproximadamente el 13 % en 2022. También apunta que alrededor del 80 % del gasto corporativo europeo en software y cloud fluye hacia proveedores estadounidenses.

Esto no significa que haya que dejar de usar tecnología estadounidense ni caer en un discurso simplista. Yo mismo trabajo en infraestructura y sé perfectamente que muchas empresas usan AWS, Azure o Google Cloud porque resuelven problemas reales, tienen servicios maduros y permiten avanzar rápido. El problema aparece cuando esa comodidad se convierte en una trampa de dependencia.

Europa ha empezado a reaccionar. La Comisión Europea designó a Amazon como gatekeeper bajo la Ley de Mercados Digitales para dos servicios de plataforma: Marketplace y Amazon Advertising. Eso reconoce que Amazon no es solo un comercio grande, sino un intermediario con capacidad para influir en el acceso de empresas y consumidores al mercado digital.

Amazon Store también aparece bajo la supervisión de la Comisión como very large online platform dentro del marco del Reglamento de Servicios Digitales, con 181,3 millones de usuarios activos mensuales medios en la UE según la información publicada por Bruselas. Esa categoría implica obligaciones reforzadas en transparencia, gestión de riesgos y rendición de cuentas.

También existe el Data Act, que busca facilitar el cambio entre proveedores cloud, reducir el bloqueo de cliente y hacer que la portabilidad sea más sencilla. La Comisión Europea habla de switching rápido, gratuito y tecnológicamente fluido entre proveedores, además de más interoperabilidad y salvaguardas sobre transferencias internacionales de datos.

Todo esto va en la buena dirección. Pero llega tarde y va por partes. Un expediente mira el marketplace. Otro mira la publicidad. Otro mira el cloud. Otro mira la protección de datos. Otro mira la logística. Amazon, mientras tanto, no piensa por expedientes. Piensa por capas.

La comodidad como jaula

Me preocupa especialmente que muchas empresas entren en esta dependencia sin percibirla. Primero venden en Amazon porque ahí están los clientes. Después contratan fulfillment porque necesitan entregar rápido. Más tarde pagan publicidad porque, si no, desaparecen en los resultados. Luego usan AWS porque sus equipos técnicos ya lo conocen. Ahora podrían usar ASCS para mover inventario incluso fuera del marketplace.

Visto paso a paso, todo parece racional. Visto en conjunto, la empresa va dejando partes sensibles de su operación en manos del mismo proveedor. Y cuando quieres salir, descubres que no se trata solo de cambiar una herramienta, sino de reconstruir procesos, datos, contratos, hábitos de usuario y flujos de venta.

En tecnología conocemos bien este problema. Lo llamamos vendor lock-in. En ecommerce y logística deberíamos empezar a usar una expresión parecida: operational lock-in. No estás atado solo por APIs o bases de datos propietarias. Estás atado porque tu negocio funciona a través de una red que no controlas.

Amazon no necesita obligarte a quedarte. Le basta con hacer que salir sea más incómodo que entrar.

Ahí es donde el discurso del monopolio necesita matices. No hace falta imaginar una conspiración. Amazon hace lo que debe hacer una empresa privada: crecer, vender más, mejorar márgenes y aprovechar sus ventajas. El problema es que, cuando una compañía alcanza esa escala, sus decisiones dejan de afectar solo a sus accionistas y clientes. Empiezan a condicionar mercados enteros.

La pregunta no es si Amazon innova. Claro que innova. La pregunta es si queremos que una misma empresa controle tantas capas de la economía digital y física que competir fuera de su órbita sea cada vez más difícil.

Qué deberíamos hacer desde Europa

Europa no puede responder solo con multas años después. Tampoco puede limitarse a pedir “soberanía digital” en discursos mientras administraciones, empresas públicas y grandes corporaciones siguen concentrando cargas, datos y procesos en los mismos tres o cuatro proveedores.

La respuesta tiene que ser más práctica. Primero, compras públicas que valoren de verdad la portabilidad, la reversibilidad y la soberanía operativa. Segundo, empresas que diseñen arquitecturas pensando en poder salir, no solo en desplegar rápido. Tercero, apoyo real a proveedores europeos de cloud, ciberseguridad, software empresarial, logística tecnológica y servicios gestionados. Cuarto, regulación que mire el poder acumulado entre capas, no solo el abuso aislado en una categoría.

También hace falta más cultura empresarial. Muchos directivos todavía ven la infraestructura como un coste y la plataforma como una comodidad. Pero la infraestructura decide hasta dónde puedes negociar, migrar, proteger datos y mantener margen de maniobra. Esto vale para cloud, para IA, para logística, para ecommerce y para cualquier negocio que dependa de plataformas.

No se trata de demonizar Amazon. Sería absurdo. La compañía ha construido servicios excelentes, ha elevado expectativas de entrega y ha simplificado operaciones a millones de empresas. Pero precisamente por eso hay que mirarla con más cuidado. Las infraestructuras que funcionan muy bien se vuelven invisibles. Y cuando una infraestructura privada se vuelve invisible, también se vuelve muy difícil de cuestionar.

Mi lectura personal es sencilla: Amazon no está “entrando” en nuevos sectores de forma casual. Está ocupando los puntos de control de la economía moderna. Donde hay demanda, datos, logística, cómputo, publicidad o relación con el cliente, Amazon intenta estar. Y cuando está en varias capas a la vez, su poder no se mide solo por cuota de mercado, sino por dependencia.

ASCS es una señal más. No será la última. La pregunta es si Europa, sus empresas y sus reguladores van a aprender a tiempo que la competencia del futuro no se juega solo entre productos, sino entre infraestructuras. Y si no construimos alternativas reales, abiertas y cercanas, acabaremos llamando “eficiencia” a lo que en la práctica será dependencia.

Preguntas frecuentes

¿Amazon es un monopolio?
No en sentido legal absoluto en todos los mercados. Pero sí acumula poder en muchas capas a la vez: ecommerce, cloud, logística, publicidad, dispositivos, entretenimiento, salud e Inteligencia Artificial. Esa acumulación puede crear dependencias muy difíciles de romper.

¿Por qué ASCS es tan importante?
Porque convierte la red logística de Amazon en un servicio abierto a terceros. No se limita a entregar paquetes: puede mover mercancías, almacenar inventario, preparar pedidos y gestionar entregas fuera del marketplace de Amazon.

¿Qué riesgo tiene esto para Europa?
Europa ya depende mucho de proveedores estadounidenses en cloud, software y plataformas digitales. Si además la logística, la publicidad y la IA se concentran en los mismos actores, la soberanía digital y operativa se debilita.

¿Qué pueden hacer las empresas?
Diseñar desde el principio estrategias de salida, evitar dependencias innecesarias, negociar portabilidad, diversificar proveedores y valorar opciones europeas cuando tengan sentido técnico, económico y regulatorio.

La entrada Amazon no está creciendo: está ocupando capas enteras de la economía aparece primero en Carrero.

Gemini CLI tenía licencia Apache 2.0, repositorio público, miles de estrellas en GitHub y una comunidad que aportó errores, mejoras, extensiones y conocimiento práctico. Pero el 18 de junio de 2026 dejará de servir peticiones para usuarios gratuitos, Google AI Pro, Ultra y Gemini Code Assist para individuos. El reemplazo es Antigravity CLI, integrado en la plataforma Google Antigravity y que, por ahora, Google no ha publicado como open source. Los clientes empresariales, en cambio, mantienen acceso, igual que quienes paguen mediante claves de API de Gemini y de Gemini Enterprise Agent Platform. Para muchos desarrolladores, el mensaje es difícil de digerir: quienes ayudaron a convertir la herramienta en algo útil son los primeros en quedarse fuera.

El código abierto protege el código, no siempre la dependencia

El caso de Gemini CLI resume una nueva tensión del software moderno. Durante años, una licencia open source daba una salida real: si una empresa cambiaba el rumbo, la comunidad podía hacer un fork y continuar. Eso ocurrió con OpenSearch tras Elasticsearch, con OpenTofu tras Terraform o con Valkey tras Redis. No siempre fue fácil, pero era posible porque el valor principal estaba en el código.

Con la inteligencia artificial la situación cambia. Gemini CLI puede seguir teniendo el código abierto, pero el motor real está en los modelos, las cuotas, la autenticación, los endpoints y la infraestructura de Google. Se puede copiar el volante, pero no el motor. Y cuando el proveedor decide cortar el acceso o mover el producto a otro modelo, la comunidad descubre que su capacidad de reacción era mucho menor de lo que parecía.

Esa es la lección incómoda. No basta con preguntar si un proyecto tiene licencia open source. Hay que preguntar quién controla el servicio, quién decide el roadmap, quién gestiona las claves, si hay modelos alternativos, si los workflows son portables y si la gobernanza permite a la comunidad influir de verdad. En la era de la IA agéntica, una herramienta abierta puede ser solo la interfaz bonita de una dependencia cerrada.

Google argumentará que Antigravity CLI responde mejor a los nuevos flujos multiagente y que Gemini CLI ya no encaja con la dirección del producto. Puede ser cierto. Las empresas tienen derecho a reorganizar sus productos. Pero cuando una compañía invita a una comunidad a contribuir, acepta también una responsabilidad moral: no tratar ese trabajo como combustible desechable cuando cambia la estrategia.

No es un caso aislado: una década de cambios de reglas

Lo de Google encaja en una historia más amplia. En los últimos años varias empresas han cambiado licencias, limitado accesos o movido productos abiertos hacia modelos “source available”, comerciales o directamente propietarios. Casi siempre el argumento es parecido: sostener el negocio, defenderse de los grandes proveedores cloud, evitar que terceros moneticen el trabajo propio o financiar el desarrollo futuro.

El problema no es que una empresa quiera ganar dinero. El problema aparece cuando el crecimiento se apoya durante años en la etiqueta open source, en contribuciones externas y en adopción comunitaria, y después las reglas cambian cuando el producto ya es crítico para miles de organizaciones.

Cada caso tiene matices. No es lo mismo MongoDB que Redis, ni Docker Desktop que Red Hat, ni Terraform que Gemini CLI. Pero todos comparten una pregunta de fondo: ¿qué ocurre cuando una comunidad adopta una herramienta bajo unas expectativas y la empresa que la controla cambia las reglas?

En algunos casos, la comunidad respondió con forks fuertes y gobernanza más neutral. OpenTofu y Valkey son buenos ejemplos porque no se quedaron en una protesta. Se organizaron, buscaron respaldo institucional y ofrecieron continuidad técnica. La presión fue tan eficaz que en algunos casos forzó a las propias empresas a recular: Elastic volvió a ofrecer una licencia open source con AGPLv3 en agosto de 2024 y Redis hizo lo mismo con Redis 8 en mayo de 2025. En otros casos, la respuesta fue más fragmentada.

Y aquí está la diferencia incómoda con la IA. Esa válvula de escape —forkear el código, sostenerlo en una fundación neutral y, a veces, obligar a la empresa a rectificar— existe porque el valor estaba en el código. Con herramientas de IA dependientes de modelos cerrados, no hay nada equivalente que forkear: puedes quedarte con el cliente, pero no con el modelo, las cuotas ni la infraestructura. La salida será todavía más difícil.

La confianza es una infraestructura

Durante años se ha tratado el open source como si fuera solo una licencia. No lo es. Es también una expectativa de continuidad, una forma de colaboración y una señal de confianza. Cuando alguien contribuye a un proyecto, no solo entrega código. Entrega tiempo, pruebas, documentación, reputación y conocimiento acumulado. A veces también construye negocio encima.

Por eso estos cambios duelen. No porque las empresas tengan prohibido evolucionar, sino porque muchas se benefician primero del capital social del open source y después actúan como si ese capital no existiera. Usan la apertura para crecer y el cierre para capturar valor. Puede ser legal. Puede ser incluso comprensible desde una presentación a inversores. Pero rompe algo que cuesta mucho reconstruir.

En mi opinión, la comunidad tecnológica debe dejar de confundir “repositorio público” con “proyecto abierto”. Un proyecto abierto de verdad necesita licencia, sí, pero también gobernanza, portabilidad, documentación, compatibilidad, neutralidad razonable y capacidad real de continuidad. Si todo depende de una única empresa, el riesgo está ahí desde el primer día.

Esto es especialmente importante con las herramientas de inteligencia artificial para desarrollo. Los agentes de código se están convirtiendo en una capa de trabajo diaria: revisan repositorios, escriben pruebas, generan documentación, ejecutan comandos y pronto tocarán procesos de despliegue. Si esas herramientas pueden desaparecer o cambiar de modelo con 30 días de aviso, no son solo una comodidad. Son una dependencia crítica mal gobernada.

La respuesta no tiene que ser abandonar Google, OpenAI, Anthropic o cualquier proveedor grande. Sería ingenuo. La respuesta debe ser diseñar con menos dependencia: prompts y workflows bajo control propio, compatibilidad con varios modelos, protocolos abiertos como MCP cuando tenga sentido, abstracciones internas, rutas alternativas y una política clara sobre qué herramientas pueden entrar en procesos críticos.

También deberíamos valorar más los proyectos con fundaciones neutrales, modelos abiertos reales y gobernanza comunitaria. No porque sean perfectos, sino porque reducen el riesgo de que una sola reunión de producto cambie el futuro de miles de usuarios.

Google no ha violado necesariamente la licencia de Gemini CLI. Ese no es el debate principal. El problema es que ha recordado a todos algo muy sencillo: el open source corporativo puede darte código, pero no siempre te da poder. Y cuando una empresa controla el motor, la carretera y la llave de contacto, la libertad de modificar el volante sirve de poco.

Preguntas frecuentes

¿Gemini CLI deja de ser open source? No necesariamente. El código puede seguir publicado bajo licencia Apache 2.0 y Google ha dicho que mantendrá el repositorio. Lo que cambia es el acceso práctico al servicio para muchos usuarios: a partir del 18 de junio de 2026 deja de servir peticiones en los planes gratuito, Pro y Ultra y para Gemini Code Assist de individuos, aunque seguirá accesible mediante claves de API de pago y para clientes empresariales.

¿Por qué este caso es distinto a otros cierres de Google? Porque Gemini CLI no era solo un producto cerrado. Era una herramienta open source con contribuciones de la comunidad, integrada en flujos reales de desarrollo y ahora sustituida por una alternativa más controlada, Antigravity CLI, que de momento no se ha publicado como open source.

¿Qué diferencia hay entre open source y source available? Open source implica libertades reconocidas para usar, estudiar, modificar y redistribuir el software bajo licencias aprobadas por la comunidad. Source available permite ver el código, pero puede imponer restricciones que impiden considerarlo open source.

¿Sirve de algo la presión de la comunidad cuando una empresa cierra un proyecto? A veces sí. En bases de datos, los forks respaldados por fundaciones neutrales (OpenTofu, Valkey, OpenSearch) ofrecieron continuidad e incluso forzaron rectificaciones: Elastic y Redis acabaron volviendo a una licencia open source con AGPLv3. Con herramientas de IA dependientes de modelos cerrados esa salida es mucho más difícil, porque no se puede forkear el modelo ni la infraestructura.

¿Qué deberían hacer las empresas que usan herramientas de IA para desarrollar? Deben tratarlas como dependencias críticas: revisar licencias, proveedor, portabilidad, costes, continuidad, acceso a modelos y posibilidad de migrar si el servicio cambia o desaparece.

Fuentes:

• Google Developers Blog: transición de Gemini CLI a Antigravity CLI (19/05/2026).
• MongoDB: anuncio de la licencia SSPL para MongoDB Community Server (16/10/2018).
• Cockroach Labs: adopción de la Business Source License (04/06/2019).
• Elastic: cambio de Elasticsearch y Kibana de Apache 2.0 a SSPL / Elastic License (14/01/2021) y posterior adición de AGPLv3 (29/08/2024).
• Linux Foundation: lanzamiento de OpenTofu tras el cambio de licencia de Terraform.
• HashiCorp: adopción de la Business Source License (10/08/2023).
• Redis: cambio a licencias RSALv2 y SSPLv1 desde Redis 7.4 (20/03/2024) y regreso al open source con AGPLv3 en Redis 8 (mayo de 2025).
• Linux Foundation: Valkey como alternativa abierta tras el cambio de licencia de Redis.
• Red Hat: cambios en la disponibilidad pública del código fuente de RHEL (21/06/2023).
• Docker: actualización de las suscripciones de Docker Desktop (31/08/2021).

La entrada Open source, IA y confianza: cuando el código abierto no basta aparece primero en Carrero.

No creo que la conclusión correcta sea “Linux está roto”. Sería injusto y demasiado simple. Linux sigue siendo una de las piezas de software más auditadas, probadas y mantenidas del mundo. Pero sí creo que estamos entrando en una etapa distinta, más incómoda, en la que vamos a descubrir muchas vulnerabilidades antiguas, profundas y difíciles de detectar con las herramientas tradicionales. Y eso obliga a cambiar la forma en la que administramos sistemas.

DirtyFrag y Copy Fail: dos síntomas de un problema mayor

DirtyFrag ha sido descrita por Hyunwoo Kim, conocido como V4bel, como una clase de vulnerabilidades que encadena dos fallos de escritura en la caché de páginas del kernel: uno relacionado con xfrm-ESP, asociado a IPsec, y otro vinculado a RxRPC. La primera parte ha recibido el identificador CVE-2026-43284 y ya cuenta con corrección en mainline; la segunda aparece reservada como CVE-2026-43500 para seguimiento. Según Red Hat, estas vulnerabilidades permiten que un usuario con cuenta local pueda activar los fallos y obtener privilegios de administrador.

El detalle que más debería preocupar a cualquier administrador Linux es que DirtyFrag no se presenta como un exploit frágil basado en una carrera de tiempos difícil de reproducir. Su autor lo describe como un bug lógico determinista, sin necesidad de race condition y con alta tasa de éxito cuando se cumplen las condiciones. En sistemas multiusuario, servidores compartidos, nodos Kubernetes, runners de CI/CD o entornos donde se ejecuta código de terceros, esa diferencia importa mucho.

Copy Fail, por su parte, ya había dejado el aviso. CVE-2026-31431 afecta al subsistema criptográfico del kernel, concretamente a algif_aead, y permite corromper la caché de páginas de archivos legibles, incluidos binarios setuid, lo que puede terminar en ejecución con privilegios de root. Microsoft explicó que el fallo puede ser usado por usuarios sin privilegios para alterar la caché de cualquier archivo legible y escalar privilegios en Linux.

La conexión entre ambos casos no es solo temporal. DirtyFrag y Copy Fail se mueven en una zona técnica parecida: operaciones in-place, page cache, fragmentos compartidos, rutas rápidas de rendimiento y supuestos de propiedad de memoria que, al combinarse mal, permiten escribir donde no debería poder escribirse. Es la misma clase de lección que ya nos dio Dirty Pipe en 2022: un pequeño error en la forma de tratar páginas compartidas puede convertirse en una escalada total de privilegios.

Y aquí es donde creo que debemos mirar más allá del parche concreto. Copy Fail y DirtyFrag no son solo dos CVE para añadir al inventario. Son una señal de que el kernel Linux, como cualquier pieza enorme de software con décadas de evolución, guarda todavía rutas oscuras que pueden contener errores de alto impacto. Algunos nacieron de optimizaciones razonables. Otros de interacciones entre subsistemas. Otros, probablemente, de cambios que parecían seguros por separado, pero no cuando se combinan años después con nuevas rutas de ejecución.

La IA está acelerando el descubrimiento de fallos antiguos

Hace poco escribía sobre Mozilla, Firefox y Claude Mythos Preview. Mozilla corrigió en abril 423 bugs de seguridad en Firefox, una cifra muy superior a la habitual. De ellos, 271 se atribuyeron al uso de Claude Mythos Preview en Firefox 150, dentro de una tubería de análisis propia que combinaba modelos de IA, fuzzing, generación de casos de prueba, triage humano y proceso completo de parcheo.

Lo relevante no era solo la cifra. Mozilla publicó ejemplos de bugs de 15 y 20 años, sandbox escapes y vulnerabilidades que habían sobrevivido durante mucho tiempo a fuzzing y revisión humana. La conclusión que saqué entonces es la misma que refuerzo ahora con Linux: la IA no solo va a encontrar fallos nuevos. Va a encontrar fallos viejos que llevaban años esperando en código crítico.

Copy Fail fue descubierto con ayuda de análisis asistido por IA, según la cobertura técnica publicada sobre el caso. DirtyFrag aparece justo después, motivado por esa misma línea de investigación y dentro de una familia de errores relacionada. Esto no significa que todos los bugs vayan a salir automáticamente ni que la IA sustituya al investigador humano, pero sí cambia la velocidad y la escala del descubrimiento.

Esta es la parte que más me preocupa de cara a lo que viene. Si los equipos defensivos pueden usar IA para encontrar vulnerabilidades antiguas, los atacantes también. La ventaja estará en quién lo haga antes, quién tenga capacidad de parchear más rápido y quién tenga una arquitectura preparada para resistir cuando aparezca una nueva PoC pública.

Durante años hemos trabajado con una idea relativamente cómoda: descubrir un bug profundo en el kernel o en un navegador requería muchísimo conocimiento, tiempo y paciencia. Eso elevaba el coste para el atacante. Ahora ese coste empieza a bajar. No desaparece, pero baja. Y cuando baja el coste de encontrar vulnerabilidades, sube la presión sobre todos los equipos de sistemas, seguridad y desarrollo.

La escalada local ya no es un riesgo menor

Hay una frase que escucho a veces y que me parece peligrosa: “es local, no es tan grave”. En 2026, local no significa lo que significaba hace veinte años. Local puede ser un contenedor comprometido. Un runner de CI que ejecuta código de un pull request. Una aplicación web con ejecución limitada. Un usuario SFTP. Un notebook de datos. Un servicio interno con permisos bajos. Un pod en Kubernetes. Un proceso en una máquina de desarrollo compartida.

Si desde cualquiera de esos puntos un atacante puede convertirse en root, el problema deja de ser menor. Una LPE fiable puede ser la pieza que convierte una intrusión limitada en control completo del host. En entornos cloud, hosting, Kubernetes, laboratorios, plataformas de datos o sistemas multi-tenant, eso puede romper el aislamiento sobre el que se apoya toda la arquitectura.

Por eso DirtyFrag y Copy Fail deberían activar una revisión práctica. No basta con mirar si tenemos “servidores expuestos a Internet”. Hay que mirar qué hosts ejecutan código no confiable, qué nodos tienen contenedores con capacidades amplias, qué runners compilan código de terceros, qué sistemas permiten user namespaces no privilegiados, qué módulos del kernel están cargados y qué kernels están realmente ejecutándose.

La palabra “realmente” es importante. Instalar el paquete del kernel no significa estar protegido. En Linux, si no reinicias o no haces un cambio controlado al kernel corregido, sigues ejecutando el kernel vulnerable. Esto es básico, pero en producción pasa más de lo que queremos admitir. Se actualiza, se deja el reboot para la próxima ventana y el riesgo sigue ahí.

Qué deberíamos hacer desde ya

Lo primero es inventario. Saber qué kernels tenemos, en qué versiones, en qué distribuciones y con qué módulos cargados. Servidores físicos, máquinas virtuales, nodos de contenedores, Proxmox, Kubernetes, runners de CI/CD, bastiones, servidores de desarrollo y entornos de laboratorio. Lo que no está inventariado no se puede parchear bien.

Lo segundo es priorizar. No todos los sistemas tienen el mismo riesgo. Un servidor aislado, sin usuarios locales y con servicios muy controlados, no tiene la misma exposición que un nodo Kubernetes con workloads de terceros o un runner que ejecuta código de ramas externas. Los primeros parches y reinicios deben ir donde una escalada local tenga más opciones de convertirse en compromiso real.

Lo tercero es aplicar mitigaciones temporales solo con criterio. En DirtyFrag se han recomendado bloqueos de módulos como esp4, esp6 o rxrpc, y algunos avisos amplían el foco a módulos relacionados con IPsec. Pero deshabilitar módulos puede romper servicios legítimos. Si una organización usa IPsec, AFS/RxRPC o funciones concretas del kernel, hay que probar antes de aplicar una mitigación a ciegas.

Lo cuarto es parchear y reiniciar. Sin drama, pero con urgencia. En sistemas con alta disponibilidad, esto debería formar parte de una rutina: drenar nodos, migrar cargas, reiniciar de forma escalonada, comprobar uname -r y validar que el kernel en ejecución es el corregido. En sistemas sin alta disponibilidad, toca valorar ventanas extraordinarias cuando la exposición lo justifique.

Lo quinto es endurecer contenedores y CI/CD. Menos contenedores privilegiados. Menos capacidades Linux innecesarias. Menos hostPath. Menos runners compartidos sin aislamiento fuerte. Más seccomp, AppArmor o SELinux. Más separación entre workloads confiables y no confiables. Más cuidado con pipelines que ejecutan código externo.

Y lo sexto, aunque parezca de otro tema, es reforzar copias de seguridad y recuperación. Una escalada a root puede terminar en borrado, cifrado, manipulación de datos o persistencia. Los backups inmutables, las pruebas de restauración, la segmentación y la monitorización siguen siendo esenciales. La IA nos ayudará a encontrar bugs, pero no va a restaurar por nosotros una infraestructura mal preparada.

Lo que viene no será tranquilo

Mi impresión es que DirtyFrag y Copy Fail son solo el principio de una etapa de descubrimiento acelerado. Igual que Mozilla ha usado modelos como Claude Mythos Preview para revisar Firefox a una escala que antes parecía impensable, vamos a ver análisis similares sobre kernels, librerías, hipervisores, herramientas de red, software de backup, paneles de administración, bases de datos y proyectos open source críticos.

Eso es bueno y malo a la vez. Bueno porque podremos cerrar vulnerabilidades antiguas. Malo porque durante un tiempo van a aparecer muchas más, y no todas llegarán con una coordinación perfecta ni con parches listos para todo el mundo. Los embargos se romperán, las PoC circularán rápido y los equipos pequeños tendrán dificultades para seguir el ritmo.

Aquí también hay una cuestión de equidad tecnológica. Las grandes corporaciones ya tienen acceso temprano a modelos, laboratorios, equipos de red team, herramientas internas y capacidad para auditar millones de líneas de código. Las pymes, los proveedores pequeños, los mantenedores open source y muchas empresas medianas no pueden quedarse en desventaja. Si las IAs capaces de encontrar vulnerabilidades profundas solo se abren a unos pocos, la brecha defensiva será enorme.

Necesitamos que estas capacidades lleguen, con controles y responsabilidad, a más organizaciones. No para publicar exploits ni para convertir la seguridad en una carrera de titulares, sino para auditar código, validar parches, revisar dependencias y proteger infraestructuras reales. La seguridad de Internet no depende solo de Microsoft, Google, Amazon, Mozilla o Red Hat. También depende de miles de proyectos pequeños y medianos que sostienen servicios críticos sin grandes equipos detrás.

Linux no está muerto ni roto. Pero el mensaje es claro: ya no podemos administrar sistemas como si el kernel fuese una caja negra intocable que se actualiza cuando toca. El kernel es una superficie viva, compleja y crítica. Y la nueva generación de IA aplicada a seguridad va a mirar dentro con una profundidad que antes estaba reservada a muy pocos investigadores.

La pregunta no es si aparecerán más DirtyFrag o Copy Fail. Aparecerán. La pregunta es si estaremos preparados para responder más rápido, con mejores procesos y con menos improvisación. Porque lo que viene no va de miedo a la IA. Va de usarla antes de que la usen contra nosotros.

Preguntas frecuentes

¿DirtyFrag permite atacar Linux desde Internet directamente?
No directamente. DirtyFrag es una escalada local de privilegios. El atacante necesita ejecutar código en el sistema, pero ese punto inicial puede venir de un contenedor, un runner de CI/CD, una aplicación comprometida o un usuario con permisos limitados.

¿Qué relación tiene DirtyFrag con Copy Fail?
Ambos fallos afectan a zonas sensibles del kernel relacionadas con escrituras indebidas en la caché de páginas y operaciones que no deberían modificar datos compartidos. DirtyFrag se presenta como una extensión de la misma familia conceptual que Dirty Pipe y Copy Fail.

¿Por qué se habla de IA en este contexto?
Porque herramientas avanzadas de IA ya están ayudando a descubrir vulnerabilidades complejas en software crítico. Mozilla ha mostrado cómo Claude Mythos Preview y otros modelos ayudaron a encontrar cientos de bugs en Firefox, y Copy Fail también se ha vinculado a análisis asistido por IA.

¿Qué debería hacer una empresa ahora?
Inventariar kernels, revisar módulos cargados, priorizar sistemas multiusuario o con contenedores, aplicar mitigaciones de proveedor, actualizar y reiniciar, endurecer CI/CD y reforzar backups, monitorización y recuperación.

La entrada DirtyFrag, Copy Fail y el aviso que Linux no puede ignorar aparece primero en Carrero.

La diferencia parece pequeña, pero no lo es. Una IP de Akamai, Cloudflare, Fastly, BunnyCDN, Vercel, GitHub Pages o cualquier gran red de distribución no es una dirección “de una web”. Puede ser la puerta de entrada a multitud de dominios completamente legales. Cortarla para impedir una retransmisión pirata es como cortar la luz de toda una ciudad porque se cometen delitos en un edificio. Sí, quizá consigues apagar ese edificio. Pero también dejas sin luz a hospitales, tiendas, colegios, empresas y viviendas. Y luego alguien pretende venderlo como una medida eficaz.

El caso Redsys demuestra que el daño colateral ya no es teórico

Según ha documentado BandaAncha.eu, el sistema de filtrado de Vodafone ha interferido de forma intermitente con la pasarela de pagos Redsys, utilizada por miles de tiendas online en España para aceptar pagos con tarjeta. El problema aparece al acceder a 3ds.redsys.es, alojado en Akamai, cuando el dominio resuelve hacia IPs concretas interceptadas por Vodafone, entre ellas 95.101.38.170 y 95.101.38.179. En HTTP puede aparecer un mensaje de bloqueo de Vodafone. En HTTPS, lo más probable es que el usuario solo vea un error o un pago que no termina de cargar.

Esto es especialmente grave porque Redsys no es una web cualquiera. Es infraestructura de pago. Su TPV Virtual se integra en comercios online y dispone de documentación y módulos para plataformas como WooCommerce, PrestaShop y Magento. Si se rompe el acceso en el momento de la autenticación o redirección de pago, la tienda puede perder una venta sin saber que el origen está en un bloqueo de red ajeno a su sistema.

El comercio ve pedidos no completados. El usuario piensa que la tienda no funciona. El banco puede no tener nada que ver. El desarrollador revisa plugins, logs, módulos de pago, configuración de Redsys y certificados, cuando el problema real está en que una operadora ha decidido interceptar una IP compartida dentro de un sistema de bloqueo relacionado con el fútbol.

Y esto no afecta solo a tiendas online. Afecta o puede afectar a blogs personales como este, a portales de desarrolladores como programacion.net, a medios locales y digitales como herencia.net o noticias.madrid, y a miles de webs de empresas, profesionales, asociaciones, proyectos personales y servicios críticos que usan infraestructura compartida. Muchos usuarios llevan meses denunciándolo en redes sociales, foros y comunidades técnicas sin éxito real, porque estamos a merced de gente que no sabe cómo funciona Internet o, peor aún, sí lo sabe y aun así prefiere mirar hacia otro lado.

Bloquear dominios es una cosa; bloquear IPs compartidas es otra

El punto técnico es sencillo. Si una web pirata opera desde un dominio, el bloqueo debería dirigirse contra ese dominio o nombre de host. Puede hacerse por DNS, por SNI cuando sea aplicable, por listas verificadas de hostnames o por mecanismos proporcionados y auditables. Ninguna solución es perfecta, y quien quiera saltársela probablemente buscará otros caminos. Pero al menos se reduce el daño sobre terceros.

Bloquear una IP compartida es mucho más burdo. En una CDN, una misma IP puede responder por muchos dominios distintos. El navegador sabe a qué dominio quiere ir y lo indica durante la conexión, por ejemplo mediante SNI en el inicio de la negociación TLS. Esa capa existe precisamente porque Internet moderna no asigna una IP exclusiva a cada web. El propio concepto de hosting, CDN y cloud se apoya desde hace años en compartir direcciones, balancear tráfico y servir múltiples sitios desde nodos distribuidos. Cloudflare explica que SNI permite indicar el nombre de dominio al que se intenta acceder durante el handshake TLS, algo necesario para que múltiples servicios puedan operar sobre infraestructura compartida.

Por eso bloquear IPs de CDNs es una medida de fuerza bruta. Puede ser cómoda para quien quiere cortar rápido, pero es peligrosa para todos los demás. La web hayahora.futbol resume el problema de forma clara: debido a una sentencia judicial, LaLiga ordena a proveedores de Internet en España bloquear ciertas IPs pertenecientes a redes de distribución de contenido cuando hay partidos. BandaAncha.eu entre otros medios libres de Internet mantienen además un seguimiento de estos bloqueos y señala IPs de servicios como Cloudflare, BunnyCDN, Vercel, GitHub y otros proveedores en la nube utilizados por miles de webs.

LaLiga podría reportar dominios concretos. Podría exigir bloqueos más finos. Podría asumir que no todo vale para proteger su negocio. Pero el sistema que se ha permitido en España termina perjudicando a terceros. Y lo hace de forma consciente si, después de todos los casos documentados, se sigue aceptando el bloqueo de IPs compartidas como una herramienta normal.

¿Esto es legal?

La pregunta no tiene una respuesta cómoda. Puede estar amparado por resoluciones judiciales concretas, sí. El País publicó en abril de 2026 que Movistar Plus+ había recibido autorización judicial para bloquear de forma dinámica y en tiempo real retransmisiones piratas de eventos deportivos, incluyendo sitios web y direcciones IP, con actuación en un plazo de 30 minutos tras la notificación.

Pero legalidad formal no equivale a corrección técnica ni a proporcionalidad. Una medida puede estar autorizada y aun así ejecutarse de forma desproporcionada, causar daños a terceros o necesitar una revisión urgente. El problema no es que exista una orden para perseguir retransmisiones piratas. El problema es que esa persecución se ejecute mediante bloqueos que alcanzan infraestructura compartida donde también viven servicios legítimos.

LaLiga ha negado en otras ocasiones que promueva bloqueos “masivos e indiscriminados” y ha acusado a Cloudflare de servir como escudo para actividades ilegales. Esa es su posición. Pero incluso aceptando que existan servicios pirata usando CDNs, eso no justifica convertir a todos los demás usuarios de esas IPs en daños colaterales.

La pregunta jurídica importante debería ser otra: si una entidad privada solicita o facilita bloqueos que terminan afectando a comercios, medios, blogs, servicios de pago o plataformas legítimas, ¿quién responde? ¿LaLiga? ¿La operadora? ¿El juzgado que autoriza el mecanismo? ¿El Estado que lo permite? ¿El regulador que no actúa? Si una tienda pierde ventas porque un pago con Redsys no se completa, ¿a quién reclama? Si un medio pierde tráfico, si una empresa pierde leads, si un servicio esencial deja de funcionar en determinadas redes, ¿quién asume el coste?

Ahora mismo la respuesta práctica parece ser: nadie. Y esa es la parte más preocupante.

La dejación política también forma parte del problema

Lo más llamativo de todo esto es el silencio institucional. En España se habla mucho de digitalización, de pymes, de economía digital, de startups, de comercio electrónico y de transformación tecnológica. Pero cuando una entidad del fútbol consigue que se acepten bloqueos que pueden interferir con servicios legítimos, los responsables políticos desaparecen.

Pan y circo, pero con CDNs, resoluciones judiciales y operadores de telecomunicaciones ejecutando filtros que muchos usuarios no entienden y que demasiados responsables públicos no parecen querer entender. Se está permitiendo que el fútbol tenga una capacidad extraordinaria para condicionar el acceso a Internet durante los partidos, mientras ciudadanos, empresas y pequeños proyectos digitales quedan expuestos a errores que nadie repara.

No se trata de defender la piratería. La piratería existe, perjudica a creadores, clubes, plataformas y titulares de derechos, y debe perseguirse. Pero una cosa es perseguir a quien comete una infracción y otra aceptar un sistema que puede dejar sin acceso a servicios legítimos porque comparten IP con algo que alguien quiere bloquear.

La comparación con cortar la luz de una ciudad no es exagerada. Es exactamente la lógica que se está aplicando: hay delito en algún punto de la red, así que cortamos una parte más grande de la infraestructura, aunque afecte a inocentes. Después ya veremos. O ni siquiera veremos, porque si los afectados son pequeños comercios, blogs, medios locales o usuarios anónimos, su capacidad de presión es mínima frente al fútbol profesional.

Internet no puede gestionarse a martillazos

Internet funciona por capas. DNS, IP, TLS, HTTP, CDNs, cachés, balanceadores, certificados, nombres de host y rutas forman parte de una arquitectura compleja. Quien toma decisiones de bloqueo debería conocer esa arquitectura antes de tocarla. Y si no la conoce, no debería tener capacidad de ordenar medidas que afectan a terceros.

Un bloqueo razonable tendría que cumplir varias condiciones: ser preciso, limitarse al dominio infractor, estar auditado, tener duración concreta, permitir revisión urgente, excluir servicios críticos y generar responsabilidad cuando se equivoque. Nada de eso parece suficientemente garantizado cuando vemos casos como el de Redsys.

Además, el daño no siempre se ve. Un pago que falla no deja un cartel que diga “bloqueado por una decisión contra el fútbol pirata”. Un usuario que no puede entrar a una web no sabe si el problema está en su móvil, en su operador, en el servidor, en el navegador o en la tienda. Un comerciante que pierde ventas no sabe si ha fallado su campaña, su pasarela, su banco o un filtro aplicado por una teleco.

Ese carácter invisible hace que el problema sea todavía más grave. Porque permite que se minimice. Permite decir que son casos puntuales. Permite que cada afectado parezca aislado. Pero cuando los casos se repiten, ya no hablamos de anécdotas: hablamos de un modelo mal diseñado.

Si el Estado quiere permitir bloqueos dinámicos para proteger derechos audiovisuales, debe exigir garantías técnicas de primer nivel. No puede delegar de facto en entidades privadas y operadores una capacidad de bloqueo que afecta a la red sin controles suficientes. Y si los jueces autorizan estas medidas, deberían exigir informes técnicos independientes, mecanismos de retirada inmediata y trazabilidad completa de cada IP bloqueada.

Internet no puede depender de si hay partido. Ni de si un CDN ha resuelto una IP concreta. Ni de si una operadora aplica un filtro con más o menos cuidado. Ni de si LaLiga considera aceptable que algunos servicios legítimos se vean arrastrados por la medida.

La defensa de los derechos de emisión no puede situarse por encima del funcionamiento normal de Internet. Si para evitar que alguien vea un partido pirata terminamos rompiendo pagos, medios, blogs, portales técnicos y tiendas online, el sistema no está protegiendo la legalidad. Está creando otra forma de abuso.

Preguntas frecuentes

¿Es legal bloquear IPs para frenar la piratería del fútbol?

Puede estar amparado por resoluciones judiciales concretas, pero eso no significa que cualquier ejecución sea proporcionada o técnicamente correcta. Si el bloqueo afecta a servicios legítimos alojados en IPs compartidas, la medida debería revisarse y podrían existir responsabilidades por daños.

¿Por qué no se deberían bloquear IPs compartidas?

Porque una IP de una CDN puede servir miles de dominios legales. Bloquearla puede dejar inaccesibles webs que no tienen relación con la retransmisión pirata. Es una medida de fuerza bruta con alto riesgo de daño colateral.

¿Qué alternativa sería más razonable?

Bloquear los dominios o nombres de host concretos desde los que se sirven los contenidos ilegales, con listas auditadas, revisión rápida, duración limitada y mecanismos para corregir errores. No es perfecto, pero es mucho menos dañino que bloquear IPs compartidas.

¿Qué ha ocurrido con Redsys?

BandaAncha.eu y otros medios como telefonos.es han documentado que el sistema de filtrado de Vodafone ha interferido con 3ds.redsys.es, dominio usado en procesos de pago y autenticación de Redsys, al interceptar algunas IPs de Akamai asociadas al servicio.

¿A quién afecta este tipo de bloqueo?

Puede afectar a cualquier web o servicio que use infraestructura compartida: blogs personales como carrero.es, portales técnicos como programacion.net, medios digitales como herencia.net o noticias.madrid, tiendas online, SaaS, APIs y servicios críticos si sus IPs quedan dentro de una lista de bloqueo.

La entrada Bloquear IPs por el fútbol es una barbaridad técnica que ya afecta a todos aparece primero en Carrero.

Copy Fail permite a un usuario local sin privilegios escalar a root mediante un fallo lógico en el subsistema criptográfico del kernel Linux. La vulnerabilidad afecta a kernels derivados de cambios introducidos desde 2017 y se apoya en una interacción delicada entre AF_ALG, splice() y la caché de páginas. En las pruebas publicadas por Theori/Xint Code, una prueba de concepto muy pequeña lograba obtener root en distribuciones ampliamente usadas. CERT-EU la clasificó como una escalada local de privilegios de severidad alta, con una puntuación CVSS 3.1 de 7,8.

No estamos hablando de un ataque remoto que atraviese Internet por sí solo. Hace falta ejecución local o acceso a una cuenta dentro del sistema. Pero en 2026 esa distinción ya no tranquiliza tanto. Muchos servidores ejecutan contenedores, runners de CI/CD, cargas de terceros, entornos multiusuario, paneles de hosting, plataformas SaaS o procesos expuestos a cadenas de ataque más largas. Cuando un atacante consigue entrar con pocos permisos, el siguiente paso casi siempre es buscar una vía para convertirse en root.

Los bugs peligrosos no siempre hacen ruido

Lo más interesante de Copy Fail no es solo su impacto técnico, sino su origen. No parece el típico error burdo que salta a la vista en una revisión superficial. Es el resultado de una combinación de decisiones técnicas que, por separado, podían parecer razonables. Una optimización aquí, una ruta de datos allá, una interacción poco habitual entre subsistemas. Años después, alguien une las piezas y aparece una primitiva de escritura en memoria con consecuencias muy serias.

Esto ocurre más de lo que nos gusta admitir. Los sistemas modernos son demasiado complejos como para pensar que todo lo importante ya ha sido revisado. Linux, OpenSSL, Kubernetes, hipervisores, firmwares, bibliotecas de compresión, sistemas de backup, agentes de monitorización, controladores de red, appliances y plataformas cloud acumulan años de capas, parches, optimizaciones y compatibilidad hacia atrás. La seguridad real no consiste en creer que no hay fallos, sino en asumir que algunos existen y diseñar la infraestructura para resistir cuando se descubran.

Copy Fail tiene además un punto especialmente incómodo: el ataque puede alterar la caché de páginas en memoria sin modificar de forma persistente el archivo en disco. Eso limita la utilidad de algunas herramientas clásicas de integridad basadas en comparar ficheros almacenados. Cloudflare, por ejemplo, explicó que podía detectar patrones de explotación mediante señales de comportamiento, pero ese tipo de respuesta exige visibilidad, telemetría y equipos preparados.

El caso también es relevante para contenedores. La caché de páginas se comparte a nivel de host, así que un contenedor comprometido puede convertirse en una vía para afectar al nodo completo si el kernel es vulnerable. Esta idea debería estar siempre presente en arquitecturas cloud, Docker y Kubernetes: un contenedor no es una máquina virtual. Aísla mucho, pero no convierte el kernel compartido en una frontera infranqueable.

La Inteligencia Artificial ayuda, también a encontrar lo que no vemos

Theori explicó que el hallazgo fue asistido por Xint Code, su herramienta de análisis con Inteligencia Artificial. Este detalle se ha usado en algunos titulares como si la IA hubiera encontrado sola una vulnerabilidad crítica en una hora. Yo lo leería con más calma. La IA puede acelerar muchísimo la revisión de código, sugerir rutas de análisis, correlacionar patrones y ayudar a mirar zonas que un equipo humano tardaría mucho más en cubrir. Pero sigue haciendo falta criterio experto para orientar la búsqueda, validar el impacto y construir una explotación fiable.

Aun así, el mensaje de fondo es potente. Si la Inteligencia Artificial ayuda a los defensores a encontrar vulnerabilidades, también ayudará a atacantes, brokers de exploits, grupos criminales y equipos ofensivos de Estados. La diferencia estará en quién integra antes estas herramientas en procesos serios: auditoría continua, análisis de dependencias, revisión de código, hardening, detección y respuesta.

Esto no significa que debamos entrar en pánico. Significa que la ciberseguridad ya no puede tratarse como una actividad puntual. No basta con pasar una auditoría anual, instalar un antivirus o aplicar parches cuando “haya ventana”. Los fallos dormidos existen. Algunos llevan años en producción. Otros están en componentes que nadie mira porque funcionan bien desde hace demasiado tiempo.

La respuesta tiene que ser más disciplinada. Inventario real de activos. Parches probados y aplicados con agilidad. Segmentación. Mínimo privilegio. MFA. Monitorización con señales útiles. Gestión de vulnerabilidades. Pruebas de restauración. Copias offline o inmutables. Entornos separados. Reducción de superficie de ataque. Y, sobre todo, una cultura en la que actualizar sistemas críticos no sea una molestia administrativa, sino una tarea central de continuidad de negocio.

Backups, resiliencia y una idea incómoda: el parche no siempre llega a tiempo

Copy Fail también sirve para recordar que el parcheo, por importante que sea, no es suficiente. Siempre habrá una ventana entre el descubrimiento, la publicación, la disponibilidad de paquetes para cada distribución, las pruebas internas y el reinicio de producción. En esa ventana, las defensas por capas marcan la diferencia.

Los backups entran aquí con mucha fuerza. No porque Copy Fail sea una vulnerabilidad pensada para destruir datos, sino porque cualquier escalada a root puede acabar en cifrado, borrado, sabotaje o persistencia. Si un atacante consigue privilegios máximos en un servidor, puede intentar eliminar snapshots, modificar scripts de copia, acceder a credenciales, moverse lateralmente o preparar un ataque posterior. Por eso los backups no deben ser simplemente “copias que existen”. Deben ser copias protegidas, separadas, probadas y recuperables.

En infraestructura profesional, una buena estrategia debería combinar copias frecuentes, retención adecuada, almacenamiento inmutable, separación de credenciales, restauraciones verificadas y escenarios de recuperación documentados. La pregunta no es si tenemos backup. La pregunta es si podríamos recuperar sistemas críticos si el atacante ya hubiera conseguido root en parte de la infraestructura.

También conviene revisar cómo tratamos los entornos de laboratorio, desarrollo y CI/CD. Muchas intrusiones no empiezan en el servidor más crítico, sino en un runner con demasiados permisos, una clave expuesta, una imagen de contenedor vulnerable o un sistema secundario que nadie parchea con la misma prioridad. A partir de ahí, una vulnerabilidad local puede convertirse en escalada, movimiento lateral y compromiso de activos más valiosos.

No hay infraestructura perfecta. Quien prometa seguridad absoluta está vendiendo humo. Lo que sí podemos construir son sistemas más difíciles de comprometer, más fáciles de detectar y más rápidos de recuperar. Copy Fail nos recuerda que incluso una base tan madura como Linux puede esconder fallos profundos durante años. La Inteligencia Artificial hará que encontremos más. Algunos los encontrarán investigadores responsables. Otros no.

La conclusión, para mí, es clara: viene una etapa en la que aparecerán más vulnerabilidades de este tipo, no menos. No porque el software sea peor, sino porque tenemos mejores herramientas para mirar dentro de él. Eso debería empujarnos a invertir más en ciberseguridad, no a confiar ciegamente en que “si algo lleva años funcionando, estará bien”.

Preguntas frecuentes

¿Qué es Copy Fail?
Copy Fail es el nombre de CVE-2026-31431, una vulnerabilidad de escalada local de privilegios en el kernel Linux que afecta al módulo algif_aead del subsistema criptográfico.

¿Por qué es importante si requiere acceso local?
Porque muchos ataques empiezan con permisos limitados. En servidores con contenedores, usuarios, runners de CI/CD o cargas no confiables, una escalada local puede permitir comprometer el nodo completo.

¿La Inteligencia Artificial descubrió la vulnerabilidad?
Theori indicó que el hallazgo fue asistido por su herramienta Xint Code. La IA ayudó en el análisis, pero el criterio humano siguió siendo esencial para orientar, validar y divulgar el fallo.

¿Qué deberían hacer las empresas?
Actualizar kernels, priorizar sistemas con cargas no confiables, aplicar mitigaciones temporales si no pueden parchear, revisar detecciones y reforzar backups inmutables, segmentación, mínimo privilegio y pruebas de recuperación.

Más información : Open Security y Copy fail

La entrada Copy Fail y la falsa sensación de seguridad en nuestros sistemas aparece primero en Carrero.

Para mí, este caso marca un antes y un después. No porque Firefox sea inseguro. Más bien al contrario: hablamos de uno de los proyectos open source más revisados, probados y atacados del mundo. Precisamente por eso el caso importa. Si en Firefox han aparecido bugs de 15 y 20 años que habían sobrevivido a años de fuzzing, revisiones humanas y millones de ejecuciones de prueba, tenemos que asumir que algo parecido puede estar esperando en muchos otros sistemas: kernels, hipervisores, librerías criptográficas, appliances, firmwares, paneles de administración, software empresarial, herramientas de backup, plataformas cloud y código legacy que nadie quiere tocar.

Mozilla ha contado que Claude Mythos Preview ayudó a identificar 271 bugs en Firefox 150. De ellos, 180 fueron clasificados como sec-high, es decir, vulnerabilidades que pueden activarse con comportamiento normal del usuario, como visitar una página web. En total, sumando otros modelos, fuzzing, inspección manual e informes externos, Firefox corrigió 423 bugs de seguridad en abril. Más de 100 personas participaron en el esfuerzo para revisar, parchear, probar y publicar las correcciones.

Esto no va solo de navegadores

Sería un error leer esta noticia como “Mozilla ha usado una IA para arreglar Firefox”. El mensaje es mucho más amplio. Estas herramientas deben usarse para mejorar la seguridad de todo tipo de sistemas. No solo navegadores. También Linux, Windows, macOS, FreeBSD, OpenBSD, librerías de vídeo, componentes de red, software de virtualización, sistemas de almacenamiento, agentes de monitorización, APIs internas, aplicaciones bancarias, software sanitario, plataformas industriales y todo el código que sostiene nuestra economía digital.

Anthropic afirma que Claude Mythos Preview ya ha encontrado miles de vulnerabilidades de alta severidad, incluidas algunas en todos los grandes sistemas operativos y navegadores. Uno de los ejemplos públicos más llamativos es CVE-2026-4747, una vulnerabilidad de ejecución remota de código en FreeBSD, con 17 años de antigüedad, que permitía obtener control completo de un servidor NFS desde una posición no autenticada en Internet. Según Anthropic, Mythos Preview no solo la identificó, sino que también construyó un exploit funcional de forma autónoma tras recibir la petición inicial.

También se han citado fallos en OpenBSD, FFmpeg, navegadores y librerías criptográficas. IEEE Spectrum recogía que Mythos había identificado vulnerabilidades en sistemas operativos importantes, navegadores y componentes capaces de afectar a comunicaciones cifradas o certificados. Incluso se menciona la capacidad de encadenar vulnerabilidades para escalar privilegios en entornos tipo Linux. Conviene ser prudentes: no hay todavía un informe público detallado, con cifras comparables a las de Mozilla, para Windows, macOS o Linux. Pero la dirección es evidente. Esto no es una capacidad limitada a un navegador. Es una nueva forma de auditar software complejo.

El propio Project Glasswing, impulsado por Anthropic, confirma esa lectura. En la iniciativa participan Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA y Palo Alto Networks, entre otros. El objetivo declarado es usar Mythos Preview para reforzar software crítico, tanto propio como open source. Anthropic también ha extendido acceso a más de 40 organizaciones adicionales que mantienen infraestructura crítica, ha comprometido hasta 100 millones de dólares en créditos de uso y ha anunciado 4 millones de dólares en donaciones a organizaciones de seguridad open source.

AWS afirma que ya está probando Claude Mythos Preview en sus propias operaciones de seguridad y en codebases críticas. Microsoft ha señalado que acceder a Mythos Preview dentro de Project Glasswing le permite identificar y mitigar riesgos antes, además de reforzar soluciones de seguridad y desarrollo. Google, por su parte, ha indicado que Mythos Preview estará disponible para participantes vía Vertex AI, mientras recuerda sus propios trabajos con herramientas como Big Sleep y CodeMender para encontrar y corregir fallos críticos de software.

La IA no sustituye al equipo de seguridad, lo multiplica

Lo más interesante del caso Mozilla no es solo el modelo. Es la forma de usarlo. Mozilla explica que sus primeros experimentos con auditorías de código mediante modelos como GPT-4 o Claude Sonnet 3.5 tenían demasiados falsos positivos para escalar. La diferencia llegó con los “agentic harnesses”: entornos donde el modelo puede crear y ejecutar casos de prueba reproducibles para comprobar sus hipótesis sobre posibles bugs.

Dicho de otra manera: la IA no se limita a decir “creo que aquí hay un fallo”. Se le da acceso a un entorno controlado, se le orienta hacia una zona del código y se le pide que construya un test que demuestre el problema. Después entra el proceso humano: deduplicar, clasificar, revisar, parchear, probar, publicar y coordinar. Mozilla lo resume muy bien: el modelo es una pieza central, pero la tubería completa de seguridad es lo que lo convierte en algo útil a escala.

Esto me parece clave para cualquier empresa. No basta con contratar una IA potente y pedirle “búscame vulnerabilidades”. Hay que integrarla en el ciclo de vida del software: repositorios, CI/CD, entornos efímeros, pruebas automatizadas, revisión humana, gestión de tickets, prioridades, publicación de parches y comunicación con clientes. Si no se hace así, lo que tendremos será ruido. Si se hace bien, podemos reducir años de deuda técnica en semanas o meses.

Y no hablo solo de fabricantes de software. Cualquier empresa con sistemas críticos debería empezar a pensar cómo auditar su código, sus integraciones, sus scripts, sus herramientas internas y sus dependencias. Muchas organizaciones no tienen un navegador como Firefox, pero sí tienen aplicaciones legacy que nadie revisa, APIs antiguas, automatizaciones en Python o Bash, paneles internos, plugins, integraciones con ERP, software industrial o herramientas hechas deprisa hace diez años que siguen en producción.

La ventaja no puede quedar solo en manos de los gigantes

Aquí aparece una preocupación importante. Si estas capacidades solo llegan primero a las grandes corporaciones, el mercado quedará desequilibrado. Las empresas con acceso anticipado podrán limpiar sus codebases, endurecer sus productos y preparar sus equipos. Las pequeñas, las medianas, los proyectos open source y los mantenedores voluntarios pueden quedarse esperando, justo cuando los atacantes también empiezan a usar modelos parecidos.

Mozilla y Anthropic han reconocido este riesgo. Project Glasswing incluye a la Linux Foundation y contempla apoyo a open source, con donaciones a Alpha-Omega, OpenSSF y Apache Software Foundation. También existe una vía para que mantenedores interesados soliciten acceso mediante el programa Claude for Open Source. Es un buen comienzo, pero no debería quedarse ahí.

La ciberseguridad no puede convertirse en otro lujo reservado a quienes tienen presupuesto ilimitado. Si las IAs capaces de encontrar vulnerabilidades profundas se despliegan solo entre los grandes proveedores de cloud, fabricantes de sistemas operativos y corporaciones tecnológicas, el resto del tejido empresarial quedará expuesto. Y buena parte de la economía real depende precisamente de ese software menos visible: librerías open source, componentes industriales, software de gestión, paneles de hosting, appliances, herramientas de backup, plataformas SaaS pequeñas y desarrollos internos.

Por eso creo que estas herramientas deben abrirse de forma controlada a más empresas, integradores, proveedores de infraestructura, equipos de respuesta, universidades, mantenedores de software libre y compañías que gestionan servicios críticos. Con controles, con límites, con auditoría y con responsabilidad. Pero abrirse. Porque la alternativa es peor: que solo unos pocos puedan defenderse mientras capacidades similares acaban llegando al mercado negro, a grupos criminales o a actores estatales.

La ventana de parcheo se está encogiendo

CrowdStrike lo ha expresado con una frase muy clara dentro de Project Glasswing: la ventana entre el descubrimiento de una vulnerabilidad y su explotación por un adversario se ha colapsado; lo que antes podía tardar meses ahora puede ocurrir en minutos con IA. Esa frase debería preocuparnos a todos.

Durante años hemos vivido con una idea relativamente cómoda: descubrir un bug crítico exigía expertos escasos, tiempo, dinero y mucha paciencia. Eso elevaba el coste para los atacantes. Si la IA reduce ese coste, habrá más bugs descubiertos, más exploits, más presión sobre los equipos de seguridad y más urgencia para parchear. Los defensores también ganan capacidad, pero solo si se mueven rápido.

Aquí entran las prácticas de siempre, pero con más importancia que nunca: inventario real de activos, gestión de vulnerabilidades, parcheo ágil, segmentación, mínimo privilegio, monitorización, EDR, registros útiles, backups inmutables, pruebas de restauración, planes de continuidad, hardening y revisión continua del software. La IA puede ayudarnos a encontrar fallos. No sustituye tener una infraestructura preparada para resistir cuando algo falla.

También habrá que auditar código legacy de forma masiva. No podemos seguir asumiendo que lo antiguo es seguro porque lleva años funcionando. El bug de 20 años en XSLT que Mozilla menciona es un buen recordatorio. Lo viejo no siempre está probado; a veces solo está olvidado.

Una oportunidad para hacer Internet más seguro

La parte positiva es enorme. Si los defensores adoptan estas herramientas antes que los atacantes, podemos entrar en una etapa en la que se cierren miles de vulnerabilidades latentes. No todas, pero muchas. Mozilla habla de integrar este análisis en su CI para analizar parches a medida que entran en el árbol de código. Esa es la dirección correcta: no solo auditar el pasado, sino revisar cada cambio nuevo antes de que llegue a producción.

Me gustaría ver esta misma mentalidad en kernels, hipervisores, sistemas de backup, software de red, gestores de identidad, bases de datos, librerías criptográficas, paneles de administración, firmware de dispositivos y plataformas cloud privadas. También en software empresarial europeo, donde muchas veces dependemos de productos críticos que no tienen la visibilidad de Firefox, Linux o Windows.

La IA aplicada a ciberseguridad no debería quedarse en detectar phishing o generar reglas Sigma. Su mayor potencial está en ayudarnos a entender código, encontrar rutas extrañas, reproducir fallos, escribir pruebas, validar parches y reducir la deuda de seguridad acumulada durante décadas.

La llegada de modelos como Claude Mythos Preview no significa que mañana todo sea más seguro. Durante un tiempo puede ocurrir lo contrario: más vulnerabilidades descubiertas, más parches urgentes, más presión sobre mantenedores y más ruido. Pero si actuamos bien, este periodo puede ser el inicio de un software más robusto.

La conclusión que me llevo es sencilla. No podemos evitar que la IA se use para encontrar vulnerabilidades. Lo que sí podemos decidir es si la usamos primero para protegernos. Y eso debería aplicarse a todo: navegadores, Linux, Windows, macOS, cloud, edge, aplicaciones internas, software libre y sistemas empresariales. Quien espere demasiado no estará evitando el riesgo. Estará dejando que otro lo encuentre antes.

Preguntas frecuentes

¿Qué es Claude Mythos Preview?
Claude Mythos Preview es un modelo avanzado de Anthropic orientado, entre otras capacidades, a encontrar y explotar vulnerabilidades de software. No está disponible de forma general, pero se está usando en colaboraciones controladas y en Project Glasswing.

¿Solo se ha usado en Firefox?
No. Firefox es el caso público más detallado hasta ahora, pero Anthropic afirma que Mythos Preview ha encontrado vulnerabilidades en grandes sistemas operativos y navegadores. Project Glasswing incluye a actores como Apple, Microsoft, Linux Foundation, AWS y Google para aplicarlo a software crítico.

¿Ya hay datos públicos para Linux, Windows o macOS?
No hay un desglose público comparable al de Mozilla para Linux, Windows o macOS. Sí hay ejemplos públicos en FreeBSD, OpenBSD, FFmpeg, navegadores y menciones a sistemas operativos importantes, además de la participación de Apple, Microsoft y Linux Foundation en Project Glasswing.

¿Estas IAs deberían abrirse a más empresas?
Sí, con controles y responsabilidad. Si solo acceden las grandes corporaciones, muchas pymes, proyectos open source y proveedores pequeños quedarán en desventaja justo cuando los atacantes empiezan a disponer de capacidades similares.

La entrada Claude Mythos, Firefox y la ciberseguridad que viene: usar la IA antes de que la usen contra nosotros aparece primero en Carrero.

Pero la realidad empieza a ser menos cómoda. La IA no es magia. Consume cómputo, consume energía, consume tokens y exige supervisión. Y cuando una empresa empieza a usar modelos avanzados de forma intensiva, la factura puede crecer más rápido de lo que muchos directivos habían previsto.

Lo interesante no es negar el valor de la IA. Sería absurdo. La Inteligencia Artificial ya es útil y va a serlo mucho más. Lo importante es dejar de tratarla como una varita mágica para sustituir personas y empezar a verla como una infraestructura cara que solo genera retorno cuando se usa con criterio.

La nube ya nos enseñó esta lección

Con la nube pública ocurrió algo parecido. Durante años se vendió como una forma de ahorrar costes frente a la infraestructura propia. En muchos casos lo fue, sobre todo al principio, cuando permitió evitar inversiones iniciales, ganar flexibilidad y acelerar proyectos. Pero después llegó la factura real: máquinas sobredimensionadas, almacenamiento olvidado, tráfico de salida caro, servicios gestionados que nadie apagaba y entornos de prueba que vivían eternamente.

Ahí nació el FinOps. No porque la nube fuera mala, sino porque usarla sin control era una receta perfecta para gastar de más.

Con la IA vamos por el mismo camino. Primero llegó el entusiasmo. Después los pilotos. Luego las licencias para todos. Ahora empiezan los agentes, los copilotos más potentes, los modelos premium y la facturación por uso. La diferencia es que, en IA, el gasto puede ser menos visible. Un empleado lanza un prompt largo. Un agente hace diez llamadas a un modelo. Una herramienta de programación repite intentos hasta que consigue compilar. Un asistente resume documentos enormes. Todo parece una interacción normal, hasta que alguien mira el coste mensual.

Cuando GitHub mueve Copilot hacia un modelo de facturación basado en uso, o cuando Anthropic eleva sus estimaciones de gasto diario por desarrollador activo en Claude Code, no estamos ante detalles menores. Estamos viendo cómo el mercado empieza a trasladar al cliente el coste real de ejecutar modelos cada vez más potentes.

La pregunta ya no será “¿tenemos IA?”. Será: “¿sabemos cuánto nos cuesta cada flujo de trabajo con IA y qué retorno nos está dando?”.

Despedir personas para comprar tokens no siempre es una estrategia

Me preocupa la facilidad con la que algunas empresas están vinculando despidos a automatización. Es evidente que habrá tareas que desaparecerán o cambiarán mucho. También es evidente que una empresa debe ser eficiente. Pero sustituir criterio humano por gasto en tokens puede salir mal si se hace con una hoja de cálculo demasiado optimista.

Un trabajador bueno no solo ejecuta tareas. Entiende contexto, detecta contradicciones, prioriza, sabe cuándo parar, conoce al cliente, interpreta matices y asume responsabilidad. Un modelo puede ayudar muchísimo a ese trabajador. Puede quitarle trabajo repetitivo, acelerar análisis, generar borradores o darle una segunda opinión. Pero no siempre puede reemplazar la función completa.

Además, los costes de IA no se limitan a la suscripción. Hay que contar el cómputo, el almacenamiento, la integración, la seguridad, la revisión humana, la formación, el gobierno del dato, la auditoría y el riesgo de errores. Una alucinación en un texto puede ser una anécdota. Una alucinación en un proceso de facturación, soporte, desarrollo o cumplimiento puede ser un problema serio.

Por eso creo que muchas empresas acabarán haciendo una corrección de expectativas. No abandonarán la IA, porque no tendría sentido. Pero dejarán de medirla como una promesa abstracta de ahorro y empezarán a exigir resultados concretos. Menos presentaciones sobre “transformación” y más métricas: horas reales ahorradas, incidencias resueltas, errores reducidos, clientes mejor atendidos, ciclos de desarrollo más cortos y costes bajo control.

Ahí el talento vuelve a ser central. No el talento entendido como una frase bonita de recursos humanos, sino como capacidad real para usar tecnología con cabeza.

La IA premia a los equipos buenos, no a los equipos improvisados

La Inteligencia Artificial amplifica. Si una empresa tiene procesos claros, datos bien organizados y profesionales capaces, la IA puede multiplicar su rendimiento. Si una empresa tiene caos, datos malos y decisiones desordenadas, la IA puede producir más caos, más rápido y con una factura mayor.

Un buen ingeniero con IA puede avanzar mucho más. Un mal flujo de desarrollo con IA puede generar más código inútil, más deuda técnica y más revisiones. Un buen equipo financiero puede usar IA para detectar anomalías y preparar escenarios. Un equipo sin control puede automatizar informes que nadie entiende. Un buen soporte puede reducir tiempos de respuesta. Un soporte mal diseñado puede entregar respuestas rápidas pero incorrectas.

Por eso me gusta cada vez menos la idea de “la IA sustituirá a X”. La pregunta más útil es otra: “¿Qué profesionales sabrán trabajar mejor con IA y qué organizaciones sabrán rediseñar sus procesos alrededor de ella sin perder control?”.

La respuesta no está solo en comprar el modelo más caro. A veces bastará un modelo pequeño. A veces será mejor automatizar una parte del flujo y dejar otra en manos humanas. A veces habrá que decir que no a un agente porque consume demasiado y aporta poco. Y a veces la decisión más inteligente será contratar o mantener a una persona con criterio, aunque una demo diga que el modelo puede hacer su trabajo.

Necesitamos AI FinOps antes de que la factura explote

Las empresas deberían empezar ya a tratar la IA como tratan la nube, o como deberían tratarla. Con presupuestos, límites, responsables, medición y revisión continua. No se trata de frenar la innovación, sino de evitar que el entusiasmo se convierta en gasto sin retorno.

Cada equipo debería saber qué modelos usa, para qué tareas, con qué volumen, a qué coste y con qué resultado. Los agentes deberían tener límites claros. Los prompts enormes deberían revisarse. Las tareas simples no deberían enviarse siempre al modelo más caro. Las respuestas deberían cachearse cuando tenga sentido. Y los proyectos de IA deberían tener un dueño de negocio, no solo un patrocinador tecnológico.

También hace falta formar a las personas. No para que todos se conviertan en expertos en modelos, sino para que sepan trabajar mejor. Pedir bien, validar mejor, detectar errores, proteger datos sensibles y entender cuándo la IA ayuda y cuándo estorba.

La IA va a cambiar el trabajo, pero no creo que la conclusión inteligente sea “menos personas y más tokens”. La conclusión debería ser “mejores personas, mejores procesos y tokens usados con intención”.

Porque al final el coste no está solo en lo que pagamos por millón de tokens. Está en las decisiones que tomamos con ellos. Una empresa puede gastar mucho en IA y aprender poco. Otra puede gastar menos, usarla mejor y sacar más valor. La diferencia estará en el talento, el criterio y la disciplina operativa.

Y eso, curiosamente, no lo resuelve ningún modelo por sí solo.

La entrada La factura de la IA: por qué el talento pesa más que los tokens aparece primero en Carrero.

Comparto su diagnóstico al 200%, aunque no su conclusión. Aquí es donde difieren nuestras perspectivas.

Llevo casi tres décadas construyendo infraestructura de internet en España. Desde los tiempos de Fidonet y las BBS, varios proveedores de hosting a mis espaldas, hasta cofundar Stackscale, donde operamos infraestructura cloud privada con centros de datos en Madrid y Ámsterdam bajo jurisdicción europea. He visto nacer este sector, he visto cómo Europa perdía posiciones año tras año, y he visto cómo cada intento de reacción se quedaba en papel mojado. Pero también sé, porque lo vivo cada día, que la tecnología y el talento europeo existen. Lo que falta es otra cosa.

Los números que nadie quiere mirar a la cara

AWS, Azure y Google controlan más del 70% del mercado europeo de cloud. Los proveedores europeos hemos pasado del 27% de cuota en 2017 a un 15% que se ha estabilizado — si es que a eso se le puede llamar estabilización y no simplemente tocar fondo. OVHcloud, el mayor proveedor europeo, factura menos de 1.000 millones de euros al año. AWS facturó 107.600 millones de dólares en 2024. Más de cien veces más.

Y aquí viene lo que más duele: los hyperscalers estadounidenses invierten más de 10.000 millones de euros cada trimestre solo en infraestructura europea. Cada trimestre. Más de lo que todos los proveedores europeos juntos invertimos en un año entero. Microsoft invierte 3.200 millones en centros de datos en Alemania, mientras que toda la industria cloud alemana invierte unos 2.000 millones anuales.

El 92% de los datos europeos se almacena en servidores gestionados por empresas estadounidenses. Y no es solo una cuestión de dónde están los servidores: el 85-90% de la tecnología que hay en cualquier centro de datos europeo — incluidos los nuestros en Stackscale — es americana. Intel y AMD controlan entre el 95 y el 100% de los procesadores de servidor. NVIDIA tiene el monopolio absoluto en GPUs para IA. Cisco domina el networking con casi el 77% del mercado global.

Esto implica algo incómodo que hay que decir en voz alta: incluso cuando una empresa elige un proveedor europeo como Stackscale, la cadena de suministro de hardware sigue siendo fundamentalmente estadounidense. Es una dependencia de doble capa que nadie parece querer abordar de verdad.

El director legal de Microsoft Francia lo dijo bajo juramento

En noviembre de 2025 ocurrió algo que debería haber sido un terremoto, pero apenas generó ruido: el director legal de Microsoft Francia, Anton Carniax, reconoció bajo juramento que la compañía no puede garantizar que los datos de ciudadanos franceses no sean transferidos a las autoridades estadounidenses sin autorización explícita de Francia.

Bajo juramento. No puede garantizarlo.

Y no es que Microsoft sea especialmente mala en esto. Es que la US CLOUD Act obliga a cualquier empresa estadounidense a entregar datos almacenados en sus servidores cuando el gobierno de EE.UU. los solicite, da igual en qué país estén físicamente esos datos. Esto convierte en papel mojado cualquier promesa de «sovereign cloud» que provenga de un hyperscaler americano. Son soluciones de marketing, no de soberanía real.

En Stackscale operamos como empresa europea, bajo jurisdicción europea, con datos que nunca salen del territorio europeo. Cuando digo soberanía, no es un claim de marketing: es una realidad jurídica. Y eso es exactamente lo que ningún hyperscaler americano puede ofrecer, por muchos centros de datos que abran en Frankfurt o en Madrid.

Lo que nos enseña Stackscale sobre lo que Europa sí puede hacer

Desde Stackscale, como parte de Grupo Aire, llevamos años demostrando algo que el discurso derrotista ignora sistemáticamente: que se puede hacer cloud europeo competitivo, fiable y de primer nivel. Nuestros clientes — desde startups hasta grandes cuentas que necesitan cumplimiento normativo estricto — nos eligen no por patriotismo, sino porque la propuesta de valor funciona: proximidad, control real sobre los datos, jurisdicción europea, soporte humano directo y un rendimiento que no tiene nada que envidiar a los grandes.

¿Tenemos la escala de AWS? Obviamente no. Pero la pregunta correcta no es si un solo proveedor europeo puede igualar a AWS. La pregunta es si Europa, de verdad, puede construir un ecosistema que cubra las necesidades del mercado europeo. Y la respuesta es sí: sí se hace con la misma lógica que se usó para crear Airbus.

Lo que veo en el día a día es que cada vez más empresas españolas y europeas se plantean repatriar cargas de trabajo críticas a proveedores europeos. No por moda ni por regulación, sino porque la geopolítica les ha enseñado que tener todos los huevos en la cesta de un proveedor sujeto al derecho estadounidense es un riesgo real para el negocio.

Gaia-X, CADA, EuroStack: ¿esta vez va en serio?

La historia reciente de Europa en esto es un catálogo de buenas intenciones mal ejecutadas. Gaia-X nació con la ambición de ser la respuesta europea y acabó con AWS, Azure y Google como miembros del consorcio. Los críticos la llamaron «alianza de perdedores» desde el principio, y aunque incluir a los hyperscalers tenía cierta lógica pragmática, el resultado ha sido que la iniciativa se ha diluido hasta la irrelevancia práctica.

Pero algo ha cambiado en los últimos meses y merece atención. En noviembre de 2025, Francia y Alemania convocaron una Cumbre de Soberanía Digital Europea con compromisos concretos y un grupo de trabajo conjunto. La iniciativa EuroStack, nacida en el Parlamento Europeo en septiembre de 2024 e impulsada por voces como Cristina Caffarra, Francesca Bria y CEOs de empresas europeas como Nextcloud, Proton y Ecosia, ha ganado tracción política real: figura en el programa de coalición del gobierno alemán y ha sido reconocida oficialmente en múltiples foros institucionales. Su estimación: se necesitan unos 300.000 millones de euros en una década. Suena a mucho, pero Europa gasta 264.000 millones al año en proveedores tecnológicos extranjeros. Con lo que gastamos en poco más de un año, financiaríamos una década entera de soberanía digital.

Y luego está el Cloud and AI Development Act (CADA), previsto para 2026. A diferencia de todo lo anterior, CADA es una legislación vinculante basada en el artículo 114 del TFUE. No un framework voluntario, no unas directrices, no otro Gaia-X. Sus objetivos: triplicar la capacidad de los centros de datos de la UE en 5-7 años, simplificar los permisos, establecer requisitos de soberanía para la contratación pública y crear un esquema de certificación cloud europeo.

Como dice Christoph Strnadl, CTO de Gaia-X: ninguna empresa estadounidense puede garantizar que el gobierno de EE.UU. no acceda a tus datos. Para datos críticos, jamás deberías usar una empresa estadounidense. Soberanía significa tener opciones estratégicas, no hacerlo todo tú mismo.

España tiene un papel clave que jugar

Y aquí es donde quiero poner el foco: se habla mucho de Francia y Alemania, pero España tiene cartas muy potentes en esta partida.

Nuestro mercado cloud crece a un 21,6% anual, el más rápido de Europa según las proyecciones. España está emergiendo como uno de los destinos más atractivos para centros de datos hiperescala en Europa, con un crecimiento proyectado del 12,5% anual hasta 2031. Tenemos ventajas competitivas reales: energía renovable abundante, clima favorable para la eficiencia energética, conectividad con Latinoamérica y el norte de África, talento técnico a costes competitivos y ubicación geográfica estratégica.

AWS ya anunció una inversión de 7.800 millones de euros en una región de Brandeburgo, pero España está en la lista de todos los hyperscalers su expansión. La pregunta es: ¿vamos a ser solo receptores pasivos de centros de datos americanos o vamos a usar este momento para construir capacidad propia?

Desde Stackscale llevamos años operando infraestructura cloud en Madrid con tecnología Proxmox, demostrando que no hace falta VMware (ahora Broadcom) ni depender de licencias estadounidenses para ofrecer virtualización de primer nivel. Es un ejemplo pequeño pero significativo: cuando Europa tiene alternativas open source competitivas, debería usarlas.

España, además, tiene el ecosistema. Empresas como Stackscale, Tenocrática, Comvive, Arsys, Gigas, Acens, Dinahosting, Telefónica Tech y otras tantas que cuenta con capacidad técnica real. Lo que no tenemos es un marco de coordinación que nos permita operar como un ecosistema integrado en lugar de como competidores fragmentados peleándonos por las migajas que dejan los grandes.

Lo que realmente necesitamos: pensar como Airbus, no como 27 aerolíneas de bandera

Hermann lo dice en su artículo y yo llevo años diciéndolo: la fragmentación es nuestro mayor enemigo. Europa no tiene un problema de talento, ni de dinero, ni siquiera de tecnología — tiene un problema de escala provocado por la insistencia en tener campeones nacionales en lugar de construir un campeón europeo.

Cuando se quiso competir con Boeing, no se crearon 27 fabricantes nacionales de aviones. Se creó Airbus. Cuando se quiso hacer física de partículas de primer nivel, no se construyeron 27 aceleradores nacionales. Se creó el CERN. Esos proyectos funcionaron porque se entendió que ciertas cosas solo pueden hacerse a escala continental, con inversión coordinada y visión a largo plazo.

El cloud y la infraestructura digital son exactamente ese tipo de proyecto. Y el timing es ahora. La IA generativa está acelerando todo: representa el 50% del crecimiento del mercado de cloud desde 2022. AWS planea invertir entre 100.000 y 105.000 millones de dólares solo en 2025 — más que el valor de mercado del cloud europeo completo. Cada trimestre que pasa sin un movimiento europeo real, la brecha se profundiza.

El contexto geopolítico ha cambiado radicalmente. La administración Trump ha demostrado que EE.UU. está dispuesto a instrumentalizar las dependencias tecnológicas como palanca política. Esto ya no es un debate académico sobre soberanía: es una vulnerabilidad estratégica real que, por fin, los gobiernos europeos empiezan a tomarse en serio.

Qué hay que hacer, sin paños calientes

Lo que necesitamos no es otro framework, ni otra cumbre, ni otro consorcio con 200 miembros donde las decisiones se diluyen por consenso:

Escala real, no fragmentación disfrazada de diversidad. Consolidar esfuerzos, crear consorcios europeos de infraestructura cloud que operen como una sola entidad a escala continental. Proveedores como Stackscale, OVHcloud, Telefónica, Hetzner, Scaleway, IONOS y otros tenemos que encontrar la forma de interoperar y presentar una oferta conjunta creíble frente a los hyperscalers.

Compra pública europea decidida. Si los gobiernos europeos no usan infraestructura europea para sus servicios críticos, ¿por qué debería hacerlo nadie? La contratación pública es la palanca más potente que tenemos y la estamos desperdiciando.

Inversión industrial con lógica Airbus. Europa necesita fondos de inversión en infraestructura digital coordinados a nivel continental, no programas de ayudas fragmentados entre 27 estados que nadie coordina.

Honestidad sobre las dependencias. Sí, nuestros servidores cuentan con procesadores Intel y AMD. Sí, nuestras GPUs son NVIDIA. No podemos cambiar eso mañana. Pero podemos construir la capa de servicios y operaciones bajo jurisdicción europea e invertir en alternativas a medio plazo: RISC-V, los procesadores de SiPearl, el EU Chips Act.

Tratarlo como lo que es: infraestructura crítica. Igual que nadie discute que Europa necesita defensa propia, infraestructura energética propia y un sistema financiero propio, necesitamos aceptar que la infraestructura digital tiene el mismo nivel estratégico.

La pregunta no es si Europa puede. Es si Europa quiere.

Quiero ser claro: esto no va de odiar a los americanos ni de cerrar fronteras digitales. Va de que Europa tenga alternativas reales y competitivas. Va de que, cuando el director legal de Microsoft admite bajo juramento que no puede garantizar la privacidad de tus datos ante al gobierno de EE.UU., tienes otro sitio donde ir.

Los hyperscalers americanos son buenos. Son muy buenos. Tienen escala, tecnología y décadas de ventaja. Pero la idea de que no se puede competir con ellos es un derrotismo autocomplaciente.

Hace un año Hermann decía que si alguien te ofrece una alternativa europea creíble a los hyperscalers, te levantes y salgas de la sala. Yo digo algo diferente: si alguien te dice que Europa no puede construir esa alternativa, sal tú de la sala. Porque esa persona no ha entendido que no se trata de capacidad, sino de voluntad y coordinación.

Desde Stackscale, desde España, desde el ecosistema europeo de infraestructura que conozco por dentro, lo tengo claro: la tecnología está, el talento está, el mercado está. Lo que ha faltado siempre es la voluntad política de hacer las cosas a la escala en que se necesitan.

Cada trimestre que pasa sin un movimiento europeo real, coordinado y a escala continental, la dependencia se vuelve más profunda, más estructural y más difícil de revertir. O construimos nuestro propio ecosistema ahora o seremos eternamente dependientes de decisiones tomadas fuera de nuestras fronteras.

La elección es nuestra. Pero el tiempo se agota.

La entrada La soberanía digital europea es un espejismo mientras sigamos fragmentados aparece primero en Carrero.

Justin Poehnelt lo explica muy bien en su artículo “You Need to Rewrite Your CLI for AI Agents”, publicado el 4 de marzo de 2026. Su tesis es muy directa: la experiencia de desarrollador pensada para humanos y la pensada para agentes no son lo mismo. La primera prioriza el descubrimiento, la flexibilidad y el perdón ante los errores. La segunda necesita predictibilidad, estructuras claras y defensa en profundidad. Justin no lo plantea como teoría abstracta, sino desde la experiencia de haber construido una CLI para Google Workspace pensada para agentes desde el primer día. Además, acompaña esa idea con una skill pública instalable con este comando: npx skills install jpoehnelt/skills/agent-dx-cli-scale.

Lo interesante es que esta reflexión no se limita a “hagamos que la IA ejecute comandos”. Va mucho más allá. Lo que plantea es que muchas CLI tradicionales están diseñadas para un uso humano que no encaja bien con los modelos de lenguaje. Un humano puede leer una tabla bonita, navegar por documentación externa, tolerar cierta ambigüedad o improvisar cuando algo falla. Un agente no funciona así. Un agente necesita salidas estructuradas, introspección en tiempo real, validación agresiva de las entradas y barreras de seguridad frente a sus propias alucinaciones. Y, cuanto más lo pienso, más sentido me tiene.

También me parece especialmente valioso que Justin no se quede en la superficie y publique después un segundo texto, “The MCP Abstraction Tax”, en el que añade un matiz muy relevante: cada capa que ponemos entre la intención del agente y el dato real introduce un coste de abstracción. En su esquema, el dato está en el fondo, encima está la API, y encima puede llegar MCP. Cada capa aporta cosas útiles —descubrimiento, seguridad, estandarización—, pero también pierde fidelidad. Y cuando trabajas con APIs complejas, ese coste acumulado puede importar mucho más de lo que parece.

Aquí es donde, personalmente, creo que se abre un debate muy interesante.

Porque durante mucho tiempo hemos asumido que una buena API era suficiente, y que una CLI era, básicamente, una capa de comodidad para personas. Pero si aceptamos que cada vez más tareas pasarán por agentes, entonces una CLI deja de ser solo una herramienta de productividad humana y se convierte en una especie de interfaz operativa entre la IA y el sistema real. En ese contexto, ya no importa solo que el comando sea bonito o fácil de recordar. Importa que sea robusto ante entradas erróneas, que pueda devolver JSON limpio, que permita pedir solo los campos necesarios, que tenga dry-run, que exponga esquemas en tiempo de ejecución y que no obligue al agente a tragarse medio manual antes de empezar a trabajar.

Lo que más me ha hecho pensar de su planteamiento

Hay tres ideas del enfoque de Justin que me parecen especialmente acertadas.

La primera es dar prioridad a las cargas útiles completas en JSON frente a una maraña de flags pensados para humanos. Puede sonar incómodo para una persona, pero para un LLM tiene mucho sentido: reduce las traducciones intermedias y permite expresar estructuras anidadas sin inventar convenciones adicionales.

La segunda es convertir la propia CLI en una fuente de documentación viva e introspectable. En vez de obligar al agente a cargar documentación estática en el prompt, la idea es que pueda consultar esquemas, parámetros y tipos sobre la marcha. Esto no solo ahorra contexto, sino que también reduce el riesgo de trabajar con documentación desactualizada.

La tercera, y quizá la más infravalorada, es la de no confiar en la entrada del agente. Justin lo dice con mucha claridad: los humanos cometen errores; los agentes alucinan. No es el mismo problema. Por eso propone endurecer la validación: rechazar caracteres de control, impedir rutas sospechosas, evitar parámetros incrustados en los IDs, controlar la codificación y asumir siempre que la entrada puede ser adversaria, aunque no haya mala intención. Me parece una idea fundamental. En el fondo, se parece mucho a cómo deberíamos diseñar cualquier frontera seria entre el software y el mundo real.

El punto donde CLI y MCP no compiten, sino que se complementan

Otra parte que me parece muy útil del debate es que Justin no cae en el simplismo de presentar CLI vs MCP como si hubiera que elegir un ganador. En su artículo sobre el “abstraction tax”, lo que plantea es más interesante: cada enfoque optimiza aspectos distintos. MCP favorece descubribilidad y estandarización. Una CLI bien diseñada para agentes puede preservar mejor la fidelidad y ofrecer más flexibilidad, sobre todo si se apoya en skills y en la carga de contexto bajo demanda. El problema real no es cuál “gana”, sino dónde pagas el peaje de la abstracción y si ese peaje te compensa.

Y esto me parece especialmente relevante ahora que tantas empresas están corriendo a “poner un MCP” sobre cualquier cosa, a veces sin revisar si la API subyacente ya era complicada, hostil o excesivamente abstracta. Si la base es mala, la capa superior no hace milagros. A veces ordena. A veces ayuda. Pero también puede ocultar problemas que luego reaparecen en producción de formas más difíciles de depurar. Esa es una conversación que, en mi opinión, todavía estamos empezando a tener.

Mi impresión personal

Mi sensación es que Justin está señalando algo muy importante: la Agent DX se va a convertir en una disciplina real. Igual que durante años hemos hablado de UX, DX, DevOps o platform engineering, vamos a empezar a hablar de herramientas, patrones y guardarraíles diseñados específicamente para agentes.

No creo que eso signifique reescribir de cero todas las CLI del mundo mañana. Tampoco creo que la respuesta sea abandonar las APIs limpias ni la buena documentación. Pero sí creo que obliga a repensar las prioridades. Añadir --output json, endurecer entradas, exponer esquemas, soportar dry-run, reducir salidas innecesarias, incorporar skills o contexto operativo específico… todo eso deja de ser “nice to have” y empieza a parecerme parte del diseño serio de cualquier herramienta que quiera convivir con agentes de IA de verdad.

Y aquí es donde me gustaría abrir el debate.

Porque no tengo claro que el futuro pase por una única respuesta. Habrá casos en los que una CLI agent-first tenga todo el sentido. Habrá otros donde una API directa más una buena librería sean mejores. Y habrá escenarios en los que MCP aporte una capa útil de estandarización. Lo que sí me parece evidente es que seguir pensando únicamente en interfaces para humanos empieza a quedarse corto.

Preguntas frecuentes

¿Qué propone exactamente Justin Poehnelt?
Propone que muchas CLI dejen de diseñarse solo para humanos y adopten patrones pensados para agentes de IA: JSON como entrada de primera clase, introspección de esquemas, validación dura de entradas, salida estructurada, dry-run y skills para aportar contexto operativo.

¿Qué es npx skills install jpoehnelt/skills/agent-dx-cli-scale?
Es el comando de instalación de una skill pública del repositorio personal de Justin Poehnelt, descrita como una escala para evaluar hasta qué punto una CLI está bien diseñada para agentes de IA.

¿Qué aporta su artículo sobre MCP?
En “The MCP Abstraction Tax”, Justin sostiene que cada capa entre la intención del agente y los datos reales —por ejemplo, las APIs y las MCP— introduce un coste de abstracción y una pérdida de fidelidad, algo especialmente importante en las APIs empresariales complejas.

¿La CLI y la MCP compiten entre sí?
Según el planteamiento de Justin, no necesariamente. MCP y CLI optimizan cosas distintas: descubrimiento y estandarización en un caso, fidelidad y flexibilidad en el otro. La cuestión clave es entender los costes y beneficios de cada capa.

Más referencias: Noticias.AI

La entrada ¿Hay que rediseñar las CLI para agentes de IA? Una reflexión a partir de Justin Poehnelt aparece primero en Carrero.

Durante años, en el mundo de la empresa y del software se ha repetido una idea casi como un dogma: no intentes hacerlo todo, no abarques demasiado, no te disperses. Era un buen consejo en un contexto normal. Servía para mantener el foco, para evitar proyectos imposibles y para no perder meses en ambiciones mal definidas. Garry Tan parte precisamente de ahí, pero sostiene que ese consejo empieza a quedar obsoleto en una etapa marcada por agentes de IA cada vez más capaces y por una automatización del trabajo intelectual que está cambiando la escala de lo posible.

Y creo que ese es el punto realmente interesante.

Una parte importante del debate actual sobre inteligencia artificial se ha quedado atrapada entre dos extremos. Por un lado, el miedo: la idea de que la IA llega para sustituir, abaratar y recortar. Por otro lado, la exageración vacía: promesas casi místicas sobre un futuro perfecto. Entre esas dos posiciones hay una tercera, mucho más útil, que es la que me interesa: la IA como multiplicador de capacidad para quien quiera construir de verdad.

Garry lo plantea con bastante claridad. Su argumento de fondo es que el miedo al futuro crece cuando nuestras aspiraciones son demasiado pequeñas. Si una persona o una empresa solo piensa en seguir haciendo exactamente lo mismo que hace hoy, pero de forma un poco más eficiente, entonces una máquina que lo haga más rápido y más barato da miedo. Pero si la ambición cambia y lo que se busca es construir algo mucho más grande, mucho mejor o mucho más útil, entonces la máquina deja de ser una amenaza y pasa a ser una herramienta extraordinaria.

Esa idea me parece especialmente valiosa porque obliga a revisar el tipo de preguntas que nos hacemos. Muchas empresas siguen atrapadas en una mentalidad de optimización mínima: cómo reducir un 5 % de costes, cómo ganar un poco más de margen, cómo hacer el mismo proceso con menos personas. Garry critica precisamente esa lógica y propone otra muy distinta: en lugar de usar la IA para arañar mejoras pequeñas, usarla para atacar objetivos que antes parecían excesivos o directamente imposibles. En su artículo pone ejemplos muy concretos: por qué conformarse con mejoras marginales si se puede aspirar a productos o servicios que multipliquen de verdad el valor entregado.

A mí me parece que ahí está el auténtico cambio de época.

La IA no obliga solo a aprender nuevas herramientas. Obliga, sobre todo, a elevar el tamaño de nuestras ambiciones. Porque si la capacidad de ejecutar software, analizar información, diseñar procesos o construir servicios se multiplica, seguir pensando con el marco mental de hace cinco años puede convertirse en un lastre. No basta con correr más. Hay que decidir hacia dónde merece la pena correr.

Esto tiene implicaciones muy profundas para fundadores, directivos, inversores y también para quienes trabajan por cuenta ajena. Garry llega a decir que, para quien vive de intercambiar trabajo por salario, este puede ser el momento de convertirse en constructor, de iniciar proyectos propios y de usar estas herramientas para ampliar radicalmente su capacidad. Y para quienes ya tienen responsabilidad de gestión o acceso a capital, su planteamiento es todavía más contundente: no usar la IA solo para recortar, sino para ampliar de forma mucho más agresiva el nivel de aspiración.

Comparto bastante esa mirada. No porque piense que todo vaya a ser fácil ni porque la transición no vaya a traer tensión, sino porque reducir la IA a una herramienta para sustituir tareas me parece una forma muy pobre de entender lo que está ocurriendo. La pregunta relevante no es únicamente qué trabajo se automatiza. La pregunta de verdad es qué tipo de empresa, de producto, de servicio o de infraestructura se vuelve viable ahora.

Ese cambio de enfoque también ayuda a entender por qué la obsesión por la “eficiencia” puede quedarse corta. La historia de la tecnología demuestra que cuando algo se vuelve mucho más eficiente, no siempre se consume menos; muchas veces ocurre lo contrario. Garry enlaza esa idea con el concepto de Buckminster Fuller de hacer cada vez más con cada vez menos, y también con la lógica de la paradoja de Jevons: cuando un recurso se abarata y se vuelve más útil, su uso puede dispararse en lugar de reducirse. En su texto aplica esa lógica a la inteligencia, al trabajo y a la creación de productos y servicios.

Y aquí creo que merece la pena detenerse un momento. Porque esa expansión no sucede por sí sola. No basta con que exista una tecnología poderosa. Hace falta también dirección, valentía, capital y, sobre todo, una voluntad real de pensar a otra escala. Si la IA se usa solo para exprimir un poco más el modelo anterior, el resultado será decepcionante. Si se usa para abrir mercados, lanzar productos radicalmente mejores, automatizar lo tedioso y liberar tiempo para crear valor nuevo, entonces sí puede cambiar muchas cosas.

Por eso, más que “hervir el océano”, yo diría que ha llegado el momento de atreverse con lo que antes parecía inabarcable. Esa sería, al menos para mí, la mejor forma de decirlo en castellano. No se trata de hacer locuras ni de perder el foco. Se trata de aceptar que el foco de ayer quizá ya no sea suficiente para el mundo que viene.

Las startups siempre han tenido ventaja cuando el terreno cambia deprisa, porque pueden moverse sin tanto peso, sin tanta burocracia y sin tanta necesidad de justificar cada paso con un Excel. Garry recuerda, precisamente, que las startups son especialmente buenas para construir para un futuro 10x, mientras que otros siguen optimizando el presente a un 1,05x. Y quizá esa sea la gran lección de esta etapa: la IA va a premiar menos a quien defiende lo de siempre y más a quien tenga el coraje de replantear la escala de lo que quiere construir.

Yo me quedo con esa idea. No como consigna grandilocuente, sino como disciplina mental. En una etapa como esta, el mayor riesgo no es solo quedarse atrás en términos tecnológicos. El mayor riesgo es quedarse atrás en la ambición.

Inspirado en “Boil the Ocean”, de Garry Tan, publicado en Garry’s List el 7 de febrero de 2026.

La entrada Ha llegado la hora de pensar a lo grande con la Inteligencia Artificial aparece primero en Carrero.

Por eso me resulta tan llamativo lo que está ocurriendo ahora. La inteligencia artificial no solo está acelerando tareas: en mi caso, me ha devuelto algo que daba por perdido: el disfrute de crear software. Y no hablo de “ver cómo un modelo genera un snippet bonito”, sino de levantar aplicaciones completas, probar ideas, iterar y, sobre todo, sentir que la fricción ha bajado lo suficiente como para que vuelva a merecer la pena ponerse a construir por puro placer.

La sorpresa no es el código: es el método

En estos últimos experimentos, me he encontrado con una sensación que hacía años que no sentía: la consistencia. Con Claude Code, al menos en mi experiencia reciente, la tasa de éxito ha sido del 100 %: toda aplicación que he pedido ha funcionado a la primera. Suena exagerado, y lo sé, porque la programación nunca es perfecta. Pero lo que me tiene pensando no es el número en sí, sino el porqué.

La clave no es que el modelo “sea un genio”, sino el enfoque de trabajo. Claude Code no se limita a contestar en una ventana de chat: se apoya en un flujo en el que el proyecto tiene memoria, reglas, convenciones y objetivos que se vuelven persistentes. Y ahí entra una pieza que, aunque parezca menor, es el corazón de todo: el archivo CLAUDE.md.

CLAUDE.md: un contrato para que el agente no improvise

Claude Code permite dos tipos de memoria: una “auto memory”, donde el sistema guarda contexto útil (patrones del proyecto, comandos clave, preferencias), y otra basada en archivos CLAUDE.md, que el usuario escribe y mantiene como un conjunto de instrucciones y reglas. Dicho sin vueltas: es un documento que le dice al agente “así se trabaja aquí”. Y eso, para alguien que lleva años gestionando sistemas y proyectos, es casi una obviedad: si el marco es claro, el resultado suele ser mejor.

Lo que cambia con estos agentes es que ese marco ya no es solo documentación para humanos: también es la guía operativa de la inteligencia artificial. Si el archivo define cómo se estructura el repositorio, qué comandos se usan para test, cómo se valida una entrega, qué estilo se sigue y qué decisiones no se tocan, el asistente deja de improvisar y empieza a ejecutar con mayor fiabilidad.

Mi experimento: “refinar el guion” antes de tocar el repositorio

La rutina que me ha funcionado (y que me ha hecho replantearme el flujo entero) ha sido esta:

1. Pedir a Claude (en la web) que genere un CLAUDE.md con unos objetivos concretos.
2. Pedirle a Gemini que mejore ese Markdown.
3. Pedirle a GPT que lo mejore de nuevo.
4. Pasar el resultado final a Claude Code en la terminal.

Lo interesante es que no estoy usando varios modelos para “escribir el código”, sino para mejorar el documento de instrucciones. Es decir: estoy invirtiendo el esfuerzo en el guion, no en la escena. Y ahí aparece una verdad incómoda para cualquiera que haya trabajado con equipos técnicos: cuando lo que se pide está bien definido, lo normal es que se ejecute mejor. Solo que ahora ese “equipo” incluye un agente que edita archivos, ejecuta comandos y trabaja con el repositorio como si fuera un desarrollador más.

En mi caso, al refinar el CLAUDE.md con varios modelos, el documento termina siendo más nítido: menos ambigüedad, más criterios verificables, mejor orden y —muy importante— menos contradicciones internas. El resultado se nota después: Claude Code entra en el repositorio con un mapa más claro y toma decisiones más alineadas con lo que realmente quiero.

Por qué esto encaja con mi forma de trabajar (aunque haya pasado tanto tiempo)

Si dejé de programar en 1998, no fue por falta de interés, sino por el contexto. La realidad es que el mundo cambió y mis prioridades también. Pero hay algo que no ha cambiado: mi obsesión por los sistemas que funcionan, por los procesos repetibles y por reducir el caos operativo.

Claude Code, en cierto modo, se siente como llevar esa mentalidad al desarrollo: reglas claras, memoria persistente y una herramienta que puede operar mediante archivos y comandos. La documentación lo presenta como un asistente de programación que entiende el código base y puede trabajar en múltiples archivos y herramientas; además, existe en varias “superficies” (terminal, IDEs, escritorio y web) que comparten el mismo motor para reutilizar la configuración y la memoria del proyecto. Esa continuidad es justo lo que permite trabajar por hábitos, no por improvisación.

Y aquí aparece otra cosa que, para mí, es muy reveladora: la idea de poder arrancar una sesión local y continuarla desde otro dispositivo. El concepto de Remote Control apunta a un futuro en el que programar no es “sentarse en el escritorio”, sino continuar tareas donde te toque, manteniendo la ejecución en tu propia máquina y conservando las herramientas locales y la configuración del proyecto. No es un detalle menor: es una pista clara de hacia dónde va el desarrollo asistido por agentes.

Lo que he aprendido: la inteligencia artificial rinde más cuando se le baja la incertidumbre

Si tuviera que resumir la lección en una frase, sería esta: la inteligencia artificial programa mejor cuando no tiene que adivinar.

Un CLAUDE.md bien escrito reduce la incertidumbre en puntos muy concretos:

• Qué hay que construir y qué no.
• ¿Cómo se valida que está “bien”?
• ¿Qué estilo y qué convenciones se consideran correctos?
• ¿Qué comandos forman el camino estándar (build, test, lint, ejecución)?
• ¿Qué decisiones arquitectónicas son intocables?
• ¿Qué atajos o patrones del repositorio conviene respetar?

En mi caso, ese documento es lo que convierte un “hazme una app” en un “hazme esto, así, con estas restricciones y con esta forma de comprobarlo”. Y cuando además lo refinan varios modelos antes de dárselo al agente que ejecuta, el resultado tiende a ser más consistente.

Una conclusión personal: no es nostalgia, es capacidad recuperada

Volver a programar no me ha hecho volver a 1998. Todo lo contrario: me ha recordado que el problema no era el lenguaje ni el IDE, sino el coste mental de ponerse a construir desde cero con poco tiempo y demasiadas cosas encima.

La inteligencia artificial ha reducido ese coste lo suficiente como para que vuelva a ser divertido. Y eso, para mí, es la gran noticia: no es que ahora “cualquiera programe”, sino que la barrera para experimentar ha bajado tanto que personas que llevábamos años en otros frentes podemos volver a crear, aprender y disfrutar.

Y sí, seguiré usando este enfoque de “refinar el guion” antes de tocar el repositorio. Porque, al final, la diferencia entre un agente que acierta y uno que divaga suele estar en lo mismo que diferenciaba a un buen proyecto de uno mediocre hace décadas: requisitos claros, reglas coherentes y una forma objetiva de saber si el trabajo está terminado.

Algunos experimentos que puedes visitar que me he apoyado en Claude como:

• Bitadir.com, un directorio de blogs con código de hace más de 12 años que he actualizado y refactorizado.
• Polen Madrid, como alérgico al polen, es un sitio donde consultar información y suscribirse para recibir alertas.
• FitBono, un sistema de gestión de clases para entrenadores personales hecho para iPhone, pensado para mi entrenador y que espero que pronto apruebe Apple.
• MboxViewer, otra herramienta para Mac para abrir mis backups de correo de Gmail con Google Takeout, que pesan más de 50 GB, y consultar correos electrónicos offline.
• mboxshell, la misma herramienta para leer grandes mbox, pero desde la terminal. Liberado en GitHub.
• CF football Bypass, un plugin para WordPress que si detecta que La Liga bloqueó tu sitio que usa Cloudflare lo desactiva temporalmente y lo vuelve activar cuando no estás bloqueado. No es lo ideal, pero al menos tu web funciona.
• Y muchas más cosas, tanto sin publicar como publicadas, que estoy experimentando…

Preguntas y respuestas

¿Qué es Claude Code?
Un asistente de programación agéntico que puede trabajar con un repositorio, editar archivos y ejecutar comandos desde la terminal y otras integraciones.

¿Para qué sirve CLAUDE.md?
Para dejar instrucciones persistentes del proyecto: reglas, convenciones y objetivos que el agente debe seguir en cada sesión.

¿Por qué mejorar el CLAUDE.md con varios modelos ayuda?
Porque reduce ambigüedades y contradicciones: el agente recibe un “contrato” más claro y toma mejores decisiones.

¿Esto garantiza que todo salga bien a la primera?
No, pero mejora la consistencia: cuando el contexto es claro y verificable, hay menos iteraciones y sorpresas.

La entrada Volver a programar después de décadas: cómo Claude Code y la Inteligencia Artificial han cambiado mi forma de construir aparece primero en Carrero.

El problema era el habitual en cualquier proyecto veterano que ha sobrevivido demasiados ciclos tecnológicos: Bitadir funcionaba sobre una combinación de PHP 4/5, plantillas antiguas, una capa de datos heredada, y un frontend que se había quedado clavado en el HTML de tablas. El sitio seguía operativo, sí, pero el coste invisible era alto: mantenimiento difícil, riesgo creciente protegido con capas de WAF y cada vez menos margen para adaptarlo a un entorno moderno sin que saltaran cosas por los aires.

La pregunta, por tanto, no era si merecía la pena tocarlo o simplemente cerrarlo para siempre. La pregunta real era cómo modernizarlo sin caer en el “lo reescribimos todo” que, en la práctica, suele convertirse en meses de trabajo, presupuestos disparados y un producto final que rara vez respeta todos los matices del original. La realidad es que tampoco tenía sentido porque no es un proyecto que genere ingresos, más bien solo pequeños gastos de hosting, pero de momento hay un tema de nostalgia y síndrome de Diógenes digital como con otras webs que conservo como Recursos Gratis (1995).

Lo que me encontré: deuda técnica, compatibilidad y seguridad “de otra era”

El diagnóstico inicial fue tan claro como incómodo:

• Código PHP con patrones obsoletos: uso de var, constructores con nombre de clase (estilo PHP 4), referencias & que en PHP moderno dejan de comportarse como se esperaba, y funciones directamente eliminadas o deprecadas (each(), create_function(), get_magic_quotes_gpc()).
• Acceso a la base de datos heredado, con puntos donde era necesario reforzar el escape de parámetros y reducir la superficie de ataque.
• Diseño anticuado: layout con tablas, sin diseño responsive real, tipografías rígidas y una experiencia móvil muy por debajo de lo que hoy se considera aceptable.
• El elefante en la habitación: contraseñas en MD5 sin salt, sin protección contra fuerza bruta, sin cabeceras de seguridad HTTP y formularios sin CSRF.
• De hecho, solo funcionaba en un servidor con PHP 5.4, realmente anticuado.

En un proyecto moderno, esto no pasa la revisión. En un proyecto con 29 años de historia, esto pasa… hasta que deja de pasar.

Un poco de contexto: qFramework, qDevel y la arquitectura original

Para entender por qué Bitadir “aguantó tanto”, hay que hablar del cimiento: qFramework.

qFramework fue un framework MVC para PHP, creado por Francesc Pla Prats y Carles Balaguer Lozano en qDevel (a inicios de 2000 o así). Ferca Networks (la parte de webs la gestiona hoy Color Vivo) contó con los servicios de qDevel para ese desarrollo. Y aquí hay un matiz importante: esa base no era un “código improvisado”, sino una arquitectura con ideas que, bien reinterpretadas, siguen teniendo sentido hoy:

• MVC con Front Controller
• Sistema de filtros (cadena de responsabilidad)
• Capa DAO para datos
• Integración con Smarty para templates
• Validaciones, usuarios y permisos
• Licencia GPL v2
• Versión documentada: 0,9b

Además, se notaban influencias de la cultura PHP de aquella época, incluyendo plataformas de blogging como pLog (más tarde LifeType), muy presentes en la comunidad hispanohablante entre 2003 y 2010.

¿Conclusión? No se trataba de “conservar lo viejo” solo por nostalgia. Se trataba de aprovechar lo rescatable (la separación de capas y el flujo MVC) y refactorizar con criterio todo lo que estaba desfasado o representaba un riesgo.

La estrategia: modernizar por capas, con seguridad primero y sin dramas

La hoja de ruta fue deliberadamente práctica:

1. Compatibilidad completa con PHP 8.4: primero el framework y luego la aplicación.
2. Seguridad como prioridad: hashing moderno, limitación de tasas, cabeceras HTTP, cookies y HTTPS.
3. Rediseño visual completo, pero sin meter frameworks pesados: CSS moderno, componentes, responsive.
4. Arreglo de errores históricos que afectaban la navegación y la administración.
5. Rendimiento con un sistema de caché híbrido y limpieza automática.

Elegí PHP 8.4 porque sitúa al proyecto en una rama moderna con un horizonte de soporte claro: según el calendario oficial de PHP, 8.4 mantiene soporte activo hasta el 31 de diciembre de 2026 y soporte de seguridad hasta el 31 de diciembre de 2028.

1) Refactorización a PHP 8.4: lo “invisible” que lo cambia todo

El trabajo más delicado fue actualizar el framework y la base de la aplicación archivo por archivo. En términos prácticos, significó:

• Reescribir patrones de clases antiguos (visibilidad, constructores, retornos y referencias).
• Eliminar dependencias de funciones que ya no existen o que no se recomiendan.
• Hacer que el core del proyecto volviera a ser predecible en un entorno de ejecución moderno.

En la capa de datos se reforzó la compatibilidad adoptando una abstracción actualizada basada en ADOdb para PHP 8.4, y se mejoró el escape de parámetros donde correspondía, dejando el camino preparado para un siguiente salto más contundente a PDO / prepared statements.

2) Seguridad: de “esto aguanta” a “esto se puede operar”

Aquí hubo dos cambios que, por sí solos, justifican el proyecto.

Contraseñas: de MD5 sin salt a bcrypt (sin resetear cuentas)

Se implementó una clase qPassword que usa bcrypt con coste 12, y lo hace con migración transparente:

• Si el hash ya es bcrypt, la verificación es estándar.
• Si el hash es MD5, se valida y, en ese mismo login, se rehash a bcrypt y se actualiza en la base de datos.

Resultado: se mejora la seguridad sin comprometer el acceso de los usuarios existentes. Que posiblemente ni siquiera entraban al panel de gestión. Una tarea pendiente es forzar el reinicio de contraseñas si vuelven a intentar acceder.

Fuerza bruta: rate limiting real

Se añadió qRateLimiter Para endpoints críticos (login, admin login, recuperación de contraseña y registro), con un esquema por defecto de 5 intentos en una ventana de 15 minutos y bloqueo de 30 minutos al exceder el límite.

A esto se sumaron cabeceras HTTP de seguridad, HTTPS forzado y cookies de sesión con flags HttpOnly y Secure, además de una CSP razonable.

3) Rediseño completo: del HTML con tablas a una UI moderna y responsive

Aquí no hubo “maquillaje”. Se pasó a un CSS nuevo (modern.css) con:

• Variables CSS (custom properties) para mantener colores, sombras y radios con coherencia.
• Tipografía moderna y jerarquía visual más clara.
• Layout con Grid/Flexbox y enfoque mobile-first.
• Componentes reutilizables: cards, botones con estados, mensajes de error y de éxito y badges de estado para el admin.
• Sustitución de iconos antiguos por soluciones CSS cuando tenía sentido.

También se mejoró la navegación: menú responsive con toggle, indicador de sección activa, breadcrumbs y URLs más limpias con rewrite rules por temas de SEO, algo que hasta ahora se había pasado por alto.

4) Rendimiento: caché híbrida y cron con limpieza automática

Se implementó una caché híbrida:

• Redis si está disponible (memoria y velocidad),
• caché en archivos como fallback (siempre disponible),
• TTL típico de 24 horas para categorías, noticias, blogs recientes y conteos.

Además, el cron de RSS limpia las cachés al actualizar los feeds y purga las entradas expiradas.

Los bugs “de verdad”: lo que se notaba en el día a día

Parte del éxito de modernizar un legacy es arreglar lo que se había normalizado como “cosas que pasan”:

• Pérdida de parámetros en la paginación por falta de QSA en las reglas de rewrite.
• Redirecciones con doble barra (//login) por construcción defectuosa de URLs.
• Login público que rechazaba a los administradores por un filtro de rol demasiado rígido.
• Páginas del admin que mostraban datos incorrectos debido a errores históricos de copiar y pegar.
• Menús duplicados en administración debido a includes repetidos.
• Listados que no mostraban datos debido a includes faltantes en las clases DAO.
• Sin olvidar problemas realmente graves, como inyecciones SQL, errores potenciales de código, vulnerabilidades en PHPmailer muy antiguo, etc. Que, por suerte, el WAF funcionaba bastante bien.

Son detalles que no se ven en una captura bonita, pero que determinan si un sistema se mantiene con calma o con dolor.

Métricas y resultados: lo que cambió después

En métricas internas del propio proyecto, el salto quedó reflejado así (valores aproximados):

• Lighthouse Performance: ~40 → ~85
• Lighthouse Accessibility: ~50 → ~90
• Tiempo de carga: ~3 s → ~1 s
• Responsive: No → Sí
• Seguridad de contraseñas: MD5 → bcrypt (cost 12)
• Fuerza bruta: Ninguna → rate limiting + bloqueo temporal

Tiempo, tokens y coste: el ejemplo más claro de por qué conviene adaptarse

Una de las cosas que más me interesan de esta modernización es lo que representa como lección: usar la tecnología para ser más eficiente no es una amenaza; es supervivencia operativa.

El trabajo real se midió en torno a:

• ~8 horas en total (en sesiones),
• 62 archivos modificados,
• ~4.800 líneas actualizadas,
• 780 líneas de CSS nuevo,
• ~600.000 tokens consumidos en sesiones con Claude Opus 4.5.

A partir de ahí, la comparación con “el mercado” es bastante intuitiva (e igual poco realista e injusta):

• Reescritura completa típica: 10.000 € – 20.000 € y 2–4 meses (estimación del propio documento del proyecto).
• Migración manual tradicional: 5.000 € – 10.000 € y 1–2 meses.
• Modernización asistida por IA: coste de tokens + validación humana + ejecución técnica, pero en una escala completamente distinta.

Para hacerse una idea de la magnitud del coste de tokens, Anthropic indica que el precio de Claude Opus 4.5 “empieza” en 5 $ por millón de tokens de entrada y 25 $ por millón de tokens de salida.
Con un consumo de este tamaño, el coste directo de modelo se vuelve una partida asumible frente a semanas de desarrollo, y lo importante pasa a ser otra cosa: saber qué tocar, validar bien, y no confundir velocidad con falta de rigor.

Ese, para mí, es el mensaje de fondo: en 2026, resistirse a estas herramientas por miedo es como rechazar el control de versiones porque “antes se trabajaba con FTP”. No se trata de sustituir el criterio técnico; se trata de multiplicar la productividad con cabeza.

Preguntas frecuentes

¿Qué es lo más difícil al migrar una aplicación de PHP 4/5 a PHP 8.4 sin reescritura completa?
Identificar incompatibilidades ocultas (constructores antiguos, referencias &, funciones eliminadas), refactorizar sin romper flujos y validar regresiones en rutas y panel de administración.

¿Cómo se puede migrar de contraseñas MD5 a bcrypt sin obligar a un reseteo masivo?
Con migración transparente en login: se valida el hash legacy y, si es correcto, se recalcula con bcrypt y se actualiza en la base de datos en ese momento.

¿Qué medidas mínimas debería tener un login moderno en una web legacy modernizada?
Hashing robusto (bcrypt/argon2), rate limiting con bloqueos, HTTPS forzado, cookies HttpOnly/Secure, y cabeceras básicas (anti-clickjacking, nosniff, referrer policy y CSP si aplica).

¿De verdad compensa usar IA para modernizar un sistema legacy?
Sí, si se usa como acelerador y no como “piloto automático”, reduce tiempos de refactorización y permite abordar más superficie de código, pero exige validación, pruebas y criterio técnico en cada cambio.

Fuente: Documento interno del proyecto “Bitadir.com – Caso de Éxito: Modernización de una Aplicación Web Legacy” (febrero de 2026)

La entrada Cómo modernicé Bitadir.com: de PHP 4/5 a PHP 8.4 sin reescribirlo desde cero (y por qué merecía la pena) aparece primero en Carrero.

Hace unos días leí un comentario de David Bonilla en X que me pareció una alerta muy bien formulada: la Inteligencia Artificial está “laminando” la creatividad en los mails porque muchos equipos temen que el contenido sea malinterpretado y, por tanto, los resúmenes no solicitados que muestra el cliente en el correo acaben deformando el mensaje. En otras palabras: no es que alguien te prohíba escribir con personalidad; es que empiezas a autocensurarte para no “romper” la lectura que haga la IA.

El tema no es menor, porque el email —para marcas, medios, comercios y creadores— sigue siendo uno de los canales con mayor retorno, mayor control e independencia frente a los algoritmos sociales. Y precisamente por eso preocupa: si el email se convierte en un espacio en el que el intermediario editorializa, estamos ante una mutación del canal.

Esta reflexión conecta con un análisis del sector que me parece especialmente útil: el texto de Zeta Global sobre lo que llaman la Séptima Edad de la entregabilidad. La idea central es que entramos en una etapa donde los remitentes pierden parte del “prime real estate” del inbox: asunto, texto de previsualización, incluso el espacio visible tras abrir el mensaje. Ese terreno, en muchos casos, lo ocupa ahora una capa de resúmenes generados por IA.

De la entregabilidad técnica a la entregabilidad “interpretada”

Durante años, el juego del email fue relativamente claro:

• Al principio, casi no había reglas.
• Luego llegaron las listas negras y los filtros por palabras clave.
• Después, el botón de “Reportar spam” y la disciplina impuesta por las quejas.
• Más tarde, el gran giro: ya no bastaba con no molestar; había que generar señales positivas de engagement.
• Con el tiempo, la reputación dejó de ser solo una cuestión de IP: el dominio se convirtió en tu historial permanente.
• Y después, el golpe de la privacidad (por ejemplo, con protecciones que reducían la visibilidad de las aperturas), que obligó a cambiar las métricas, la segmentación y la forma de medir.

Hasta aquí, aunque complejo, todo pertenecía al terreno del “delivery”: llegar a la bandeja de entrada y lograr la interacción.

Lo nuevo, sin embargo, va más allá. Ahora hablamos de cómo se presenta y se resume el email dentro del propio cliente, incluso cuando llega correctamente.

Y eso introduce un concepto casi incómodo: la entregabilidad ya no es solo técnica; también se vuelve editorial.

El “prime real estate” que está en disputa

Quien lleva tiempo trabajando campañas de email lo sabe: hay tres zonas críticas que deciden el destino de un mensaje en segundos:

1. Asunto
2. Preheader / texto de vista previa
3. Primer pantallazo al abrir (lo que se ve sin hacer scroll)

La Séptima Edad que describe Zeta Global sugiere que estas zonas se están erosionando porque:

• En algunos escenarios, el preheader puede sustituirse por resúmenes de oferta, elementos visuales o interpretaciones automáticas.
• Se introducen tarjetas o módulos que sintetizan el email y desplazan contenido real de la marca fuera de la zona visible.
• Se aplican agrupaciones por marca que reducen la visibilidad de múltiples asuntos (solo aparecen unos pocos), lo que obliga a competir con menos “impactos” reales.

El resultado práctico: la marca puede escribir un texto, pero el usuario puede ver otro (un resumen o una extracción). Y cuando eso ocurre, la creatividad deja de ser solo un recurso de comunicación; se convierte también en una variable de riesgo.

Por qué la creatividad empieza a “perder” (y no por falta de talento)

Aquí está la clave del comentario de Bonilla: la creatividad en emails suele apoyarse en recursos como:

• metáforas
• ironía
• doble sentido
• juegos de palabras
• sorpresa
• “punchline” en el preheader

Todo eso funciona cuando una persona lee el mensaje tal cual lo has escrito. Pero si una inteligencia artificial se dedica a resumirlo o a extraer “lo importante”, se abren varios escenarios problemáticos:

• La ironía se vuelve literal y el resumen cambia de tono.
• Una frase sugerente se convierte en una promesa comercial.
• Un guiño cultural se interpreta como algo irrelevante y se elimina.
• El “gancho” del preheader desaparece porque el sistema lo reemplaza por un resumen frío.

Esto genera un incentivo perverso: escribir “más plano”, más literal, más directo. No porque sea mejor comunicación, sino porque es más robusto frente a interpretaciones automáticas.

Y aquí hay una analogía evidente con lo que pasó en SEO: durante años, el miedo a no posicionar impulsó a usar títulos más previsibles. Ahora, el miedo a ser mal resumido impulsa emails más previsibles.

El bucle de métricas: cuando el proveedor mide su propia IA

Hay otro matiz importante: si los resúmenes o tarjetas cambian la experiencia del usuario, pueden afectar a:

• aperturas
• clics
• bajas
• quejas (“esto no era lo que parecía”)
• tiempo de lectura (si el resumen ya “resuelve” la necesidad)

Lo paradójico es que los proveedores de correo podrían terminar midiendo el engagement y las quejas sobre una experiencia que ellos mismos han alterado con sus capas de IA. Esto complica el diagnóstico: cuando una campaña cae, ya no basta con preguntarse “¿qué he hecho mal?”; también hay que preguntarse: “¿Qué ha hecho el inbox con mi mensaje?”.

En 2026, monitorizar la entregabilidad también implica monitorizar la presentación.

Qué haría yo si dependiera del email para negocio o audiencia

No hay una receta mágica, pero sí un cambio de mentalidad. Algunas ideas prácticas (muy aplicables a ecommerce, SaaS, medios y newsletters):

1) Asuntos autosuficientes, sin depender del preheader

Durante años, era habitual construir una pareja: asunto que plantea algo + preheader que remata. Si se sustituye el preheader, el diseño se rompe.
El asunto tiene que sostener su valor por sí solo, con claridad.

2) Creatividad sí, pero con “anclas” semánticas

No se trata de renunciar al estilo. Se trata de evitar que el resumen cambie de significado.
Ejemplo (conceptual): si usas humor, añade una línea literal que deje claro el beneficio o la oferta real.

3) Lo más importante, arriba y sin ambigüedad

Si una tarjeta o un resumen va a extraer “highlights”, es mejor que esos highlights estén redactados con precisión en las primeras líneas.
Esto también mejora la accesibilidad, la lectura rápida y la experiencia móvil.

4) Menos figuración en elementos críticos

Puedes reservar metáforas para el cuerpo del mensaje, pero el núcleo (qué es, cuánto cuesta, qué cambia, por qué importa) debe ser directo.
La creatividad puede vivir en la forma, pero el contenido clave debe ser difícil de deformar.

5) QA de campañas como si fueran “renderizados”

Antes probábamos en clientes de correo (Gmail, Outlook, Apple Mail) para ver el layout. Ahora hay que incorporar otra pregunta:
¿Qué podría resumir una IA de esto y cómo podría equivocarse?

6) Monitorización por proveedor y por formato

Si notas caídas, intenta segmentar el análisis por proveedor (Gmail vs Apple Mail vs Yahoo) y por tipo de mensaje (promoción, editorial, transaccional).
A veces el problema no es el contenido, sino cómo se está “enmarcando”.

7) Prepararse para una conversación incómoda: el inbox como editor

A medio plazo, esto abre un debate sobre el poder: ¿hasta qué punto una plataforma puede reescribir la comunicación entre la marca y el usuario?
No hablo solo de marketing: hablo de avisos, cambios contractuales, comunicaciones importantes… El resumen automático no siempre es inocuo.

Lo que está en juego no es el marketing: es el control del significado

Si lo pensamos fríamente, el email siempre fue un canal con una promesa: si haces las cosas bien, llegas a tu audiencia con tu mensaje.

La Inteligencia Artificial en la bandeja de entrada introduce una capa nueva: puedes llegar… pero no necesariamente con tu mensaje tal como lo diseñaste.

Y eso tiene implicaciones culturales y económicas:

• Homogeneiza el lenguaje (menos riesgo, menos voz).
• Reduce la diferenciación (si todo debe ser claro y literal, todo suena parecido).
• Traslada el poder a quien “resume” (la interfaz).
• Y complica la atribución de resultados (si el resumen cambia, las métricas se ensucian).

Volviendo al punto inicial: el comentario de Bonilla no es una exageración. Es una descripción de incentivos. Y cuando los incentivos cambian, el contenido cambia.

Preguntas frecuentes

¿Qué significa que la IA “lamina” la creatividad en el email marketing?
Que muchos equipos tienden a redactar mensajes más literales y menos figurativos para reducir el riesgo de que los resúmenes automáticos malinterpreten el contenido y alteren la percepción del usuario.

¿Cómo afectan los resúmenes generados por inteligencia artificial a la entrega de un dominio?
Indirectamente: si el resumen confunde, puede reducir el engagement y aumentar las quejas o las bajas. Eso deteriora las señales de reputación que influyen en futuros envíos, aunque el email haya llegado correctamente al inbox.

¿Qué buenas prácticas ayudan a que un email no sea mal resumido por la IA?
Asuntos autosuficientes, primeras líneas claras, beneficios y condiciones sin ambigüedad, y un diseño donde lo esencial esté arriba. La creatividad puede mantenerse, pero con “anclas” semánticas.

¿Deberían las marcas “probar” cómo se ve un email con resúmenes automáticos?
Sí, en la medida de lo posible. Igual que se testea el renderizado en distintos clientes, conviene revisar cómo los proveedores presentan y extraen elementos, y monitorizar cambios por proveedor cuando cambian las métricas.

Fuentes:

• Publicación de David Bonilla en X (enero de 2026).
• Zeta Global: “The Seventh Age of Email Deliverability”, Amber Erickson.
• Noticias De Inteligencia Artificial.

La entrada Cuando la bandeja de entrada reescribe tu email: la Inteligencia Artificial y la nueva era de la “entregabilidad editorial” aparece primero en Carrero.