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.

Estos días he vuelto a leer varias declaraciones de Tim Cook sobre lo que Steve Jobs le fue dejando como aprendizaje (en entrevistas y perfiles en los que Cook habla de su relación profesional con Jobs y de cómo le marcó como líder). Y me ha pasado lo mismo que cuando encuentras una frase que no te deja escapar: sigues con tu día, pero la cabeza se queda rumiando.

Porque no son frases para un póster. Son lecciones de gestión. De las que, si estás liderando un proyecto, te obligan a mirarte al espejo.

1) Foco de verdad: hacer menos, pero hacerlo mejor

Lo primero que asocio a Jobs no es “hacer mucho”. Es recortar. Es el músculo para decir “no” sin que te tiemble el pulso.

Cook lo ha descrito de una forma muy simple: Jobs estaba obsesionado con el producto, con el producto y con el producto. Y esa obsesión, bien entendida, no es romanticismo creativo: es estrategia.

En cualquier empresa (da igual si vendes software, servicios o tornillos), el enemigo número uno suele ser el mismo: el catálogo infinito. La lista de “por si acaso”. La pila de funcionalidades que nadie pidió, pero que alguien dentro defendió con pasión.

Jobs puso el foco en la disciplina. Y esa disciplina suele doler, porque implica renunciar a cosas que podrían funcionar… para proteger las que deben funcionar.

2) Equipos pequeños: menos ruido, más responsabilidad

La segunda idea es casi contraintuitiva en 2026, cuando todo parece escalarse con más gente, más comités y más capas. Jobs confiaba en equipos reducidos capaces de lograr cosas enormes.

Un equipo pequeño no es una cuestión de presupuesto. Es una cuestión de fricción:

• Menos intermediarios.
• Menos “me lo apunto y lo vemos”.
• Más decisiones claras.
• Más propiedad real del resultado.

En mi experiencia, cuando un equipo crece, si no proteges la claridad, empiezas a pagar un “impuesto invisible”: reuniones, sincronizaciones, dependencias, política interna. Y de repente lo urgente se come lo importante.

Lo pequeño te obliga a priorizar. Y la prioridad, al final, es la forma adulta de decir “no”.

3) Rodéate de talento que te incomode (y que te discuta con argumentos)

Otra de las ideas que Cook repite al hablar de Jobs es la obsesión por rodearse de gente brillante: no para que te aplauden, sino para que te mejoren.

Esto también es incómodo porque toca el ego. Tener cerca a alguien que sabe más que tú en un área crítica te pone en tu sitio. Te obliga a escuchar de verdad. Y a separar dos cosas que muchos líderes mezclan:

• “Que me discutan” no es falta de alineación.
• “Que me discutan bien” es señal de salud.

Un equipo que solo dice que sí, tarde o temprano fabrica una burbuja. Y cuando la realidad pincha esa burbuja, ya es tarde.

4) No te cases con tus ideas: cambiar rápido es madurez

Esta lección, para mí, es la más brutal.

Cook ha contado que Jobs le enseñó a no quedarse “casado” con sus opiniones pasadas, a no ser tan orgulloso como para no cambiar de idea cuando aparece nueva evidencia.

Esto es oro puro para cualquiera que esté construyendo algo:

• Hay decisiones que se convierten en identidad (“yo soy el que apostó por esto”).
• Hay planes que se convierten en religión (“si cambiamos, es que fallamos”).
• Hay roadmaps que se mantienen a pesar de que el mercado haya cambiado.

Y ahí mueren proyectos prometedores: no por falta de visión, sino por exceso de apego. Confunden coherencia con rigidez.

La coherencia de verdad no consiste en repetir siempre lo mismo. Es ser fiel al objetivo, aunque tengas que cambiar de camino.

5) Innovación constante: no como palabra, sino como obligación operativa

Cook también ha explicado que Jobs le enseñó el valor de la innovación y que la creatividad no debía “vivir” en un solo departamento: tenía que estar en toda la empresa, incluso en operaciones.

Esta parte me gusta especialmente porque pone la innovación en la práctica. Innovar no es solo sacar un producto nuevo. Es mejorar cómo despliegas, cómo atiendes, cómo reduces la fricción, cómo automatizas, cómo haces que lo complejo sea simple.

La innovación no es un evento. Es una práctica.

Y aquí viene la ironía que más me ronda desde que leí todo esto: cuanto más grande se vuelve tu proyecto, más necesitas pensar como si estuvieras empezando. Como si aún tuvieras que ganarte el derecho a existir cada semana.

Porque el mundo no te “respeta” por tu tamaño. Te respeta por tu capacidad para seguir siendo relevante.

Yo me quedo con una pregunta que sirve para cualquier founder, CTO o CEO:
¿Qué parte de tu proyecto estás manteniendo por orgullo, cuando ya tienes evidencia suficiente de que deberías simplificar, recortar o cambiar?

¿Y a ti qué lección te ha tocado más?

Preguntas frecuentes

¿Qué lecciones de liderazgo dijo Tim Cook que aprendió de Steve Jobs?
En distintas entrevistas y perfiles, Cook ha destacado ideas como el foco en el producto, el valor de la innovación, la importancia de equipos pequeños, rodearse de gente excelente y la capacidad de cambiar de opinión ante nueva evidencia.

¿Por qué Steve Jobs insistía tanto en el foco y en decir “no”?
Porque para Jobs, priorizar era una forma de proteger la simplicidad y concentrar los recursos en lo esencial. Se le atribuyen reflexiones conocidas, como que el foco implica renunciar a muchas cosas para acertar en pocas.

¿De verdad funcionan mejor los equipos pequeños en tecnología?
Suelen funcionar muy bien para la iteración rápida, la claridad y la responsabilidad. El reto es mantener la coordinación cuando el producto y la empresa crecen, sin caer en exceso de capas ni en burocracia.

¿Cómo aplicar “no te cases con tus ideas” en un proyecto real?
Con métricas claras, ciclos cortos de revisión, y una cultura donde cambiar de rumbo por datos no se viva como derrota, sino como madurez operativa.

La entrada Tim Cook y las últimas lecciones de Steve Jobs: foco, equipos pequeños y el arte de cambiar a tiempo aparece primero en Carrero.

Por eso me llamó la atención la historia de Jeff Huang, que se hizo relativamente conocida por algo tan simple como efectivo: su “app de productividad” es un archivo .txt infinito. Un documento de texto sin fin donde, cada día, vuelca lo que tiene por delante y que, con el tiempo, se convierte en un registro de lo que ha hecho, de con quién se ha reunido, de ideas, decisiones y tareas.

Y lo interesante no es si su método es “el mejor”. Lo interesante es lo que hay detrás: buscar un sistema que no te estorbe y que te resulte cómodo y práctico.

Cuando el sistema te roba más tiempo que el trabajo

A mí me pasa como a mucha gente: he probado herramientas, métodos, listas, recordatorios… y siempre llega un momento en el que el propio sistema empieza a pedirte mantenimiento. Ajustar vistas, mover tareas, reordenar etiquetas, decidir si algo es “tarea”, “nota”, “proyecto” o “subproyecto”… y de pronto te descubres organizando en lugar de hacer.

Ahí es donde el enfoque de Jeff Huang me parece útil como idea general: reducir la fricción. Quitar capas. Volver a lo básico.

Cada uno encuentra su forma (y la mía es bastante simple)

En mi caso, no he terminado con un .txt como él, pero sí con algo parecido en filosofía: capturar ideas y notas rápido, sin rituales.

Y aquí lo digo tal cual: para eso, uso la app de Notas de Apple.

No porque sea la más completa del mundo, ni porque sea “la herramienta pro”, ni porque tenga la mejor IA del mercado. La uso porque cumple lo que para mí es lo más importante:

• Abrir y escribir en segundos (sin pensar). Desde el móvil, el portátil o el equipo de sobremesa de la oficina.
• Guardar ideas al vuelo, sin una estructura rígida.
• Tener un sitio para notas rápidas, borradores, listas y recordatorios mentales.
• Poder volver a ellas después para convertirlas en algo útil (un artículo, una decisión, una tarea real).

Mis “ideas” y notas son básicamente mi bandeja de entrada mental. Si se me ocurre algo, si detecto un tema interesante, si apunto un enfoque para un post, si quiero anotar una frase, un concepto o una estructura… va ahí. Sin pelearme con el formato. Aunque la idea de Jeff de utilizar el formato de texto como algo mucho más estándar me llama la atención, con Notas estoy atado a Apple.

La clave no es la herramienta: es el hábito de capturar

Lo que me gusta del método de Jeff Huang (y lo que intento aplicar a mi manera) es esta idea: no necesitas un sistema perfecto, sino uno que uses de verdad cada día, sin peros.

Porque el mayor enemigo de la eficiencia no es la falta de apps. Es esto:

• confiar en “me acordaré luego” (spoiler: no),
• dejar ideas sueltas en chats, correos, pestañas, capturas,
• O apuntar cosas en diez sitios distintos y luego no encontrarlas nunca.

Con las Notas de Apple intento evitar justo eso: que las ideas se pierdan. Que la chispa se apague por no haberla escrito.

Seguimiento: de nota rápida a idea que madura

Una nota rápida no es un proyecto. Pero puede ser el germen.

Mi flujo suele ser algo así:

1. Captura inmediata: escribo lo justo para no olvidarlo.
2. Acumulo sin culpa: no todo tiene que convertirse en algo.
3. Reviso cuando toca y como un hábito real, y algunas notas “piden” salir, porque conectan con un artículo, una necesidad, un cliente, una noticia o una reflexión.
4. Convierto lo útil en acción: lo que merece la pena se transforma en contenido, tareas o decisiones.

Y lo demás… se queda ahí. No pasa nada. La productividad real también implica aceptar que no todo lo que piensas tiene que ejecutarse.

Lo importante: un sistema que te deje pensar

Al final, para mí la eficiencia va de esto:

• quitar ruido,
• reducir la carga mental,
• Y dejar espacio para lo que de verdad importa: pensar, crear, resolver.

El archivo .txt de Jeff Huang me parece un gran recordatorio de que lo simple puede escalar sorprendentemente bien. Y mi sistema con Notas de Apple es mi versión de lo mismo: un sitio rápido, accesible y sin fricción para capturar lo que pasa por la cabeza antes de que desaparezca.

Porque al final, cada uno busca “la mejor forma” de ser eficiente y tener hábitos reales… y casi siempre la mejor forma es la que te resulta tan fácil que no puedes poner excusas para no usarla.

La entrada Mi “sistema de productividad” no es perfecto (y justo por eso funciona) aparece primero en Carrero.

Suena bien… hasta que empiezas a fijarte en los detalles:
Series que desaparecen de un día para otro, discos que se sustituyen por una versión distinta, películas que “habías comprado”, música que deja de estar disponible, que sí, y que de repente ya no están en tu biblioteca. Aplicaciones que desaparecen o dejan de tener soporte para tu sistema operativo y no puedes volver a la versión de ayer que sí funcionaba, además de que te exigen tener Internet para verificar que pagas, y si no hay Internet, no funcionará.

Ahí es donde te das cuenta de algo bastante incómodo:

👉 En el mundo digital actual, casi nunca eres dueño de nada, solo alquilas acceso con muy buena puesta en escena.

En este artículo quiero contarlo en primera persona:
Cómo hemos pasado de “tenerlo todo” en nuestros discos duros a vivir en un gigantesco videoclub alquilado, con software SaaS en la nube, y cómo estoy intentando recuperar, poco a poco, parte de esa propiedad perdida.

Cuando internet era más feo… pero era más nuestro

Los que vivimos la primera gran oleada de internet en España recordamos bien aquella época:

• módem ruidoso para conectar a nuestra BBS favorita,
• conexiones lentas con módem de 28800 bps,
• páginas horribles, aunque bonitas para su época,
• Pero una sensación de libertad brutal.

Descargábamos música, películas, juegos, aplicaciones para Windows freeware, shareware, nuestro PhotoShop que pagábamos y usábamos durante años sin actualizar, distribuciones de Linux…

Algunas cosas eran legales, otras no tanto, pero había algo muy claro:
Lo que llegaba a tu disco duro era tuyo mientras quisieras conservarlo.

Podías:

• hacer una copia en un CD o tus disquetes,
• prestarlo a un amigo,
• guardarlo en un disco externo,
• Volver a escucharlo o instalarlo dentro de 10 años sin pedir permiso a nadie.

Era un caos, sí. No idealizo la piratería ni mucho menos.
Pero había algo que hoy echamos mucho de menos: el control.

Cuando trasteaba con la BBS y bajaba software durante horas, o compraba esos disquetes o distribuciones de CD o DVD cargadas de aplicaciones libres (freeware), shareware, open source y otras. Poco después montaba servidores Linux para servicios de hosting compartido, hacía páginas web «feas» como Recursos Gratis, la primera versión de Ferca Networks, y me conectaba a FTP con CuteFTP para Windows (comprado con su caja física y todo) o a los canales de IRC con mIRC. Éramos los patrones de nuestros barcos, instalábamos, descargábamos. Internet era el medio, no el lugar donde vivían tus cosas.

Con el tiempo, esa lógica se dio la vuelta.

La era del “todo está en la nube”… mientras dure

Llegaron las RDSI, el ADSL, la fibra óptica, los móviles inteligentes o smartphones (especialmente el iPhone), las Smart TV. Pero además los ordenadores de sobremesa evolucionaron y los portátiles también llegando a poder conectarnos desde cualquier lugar, hoy lo veis como alto normal pero en el año 2000 o aseguro que no lo era tanto. Aparecieron Netflix, Spotify, Steam, Kindle, las tiendas de apps, la suite de Adobe y Microsoft Office en pago mensual… y nos convencieron de que lo lógico no era guardar cosas, sino conectarse a ellas.

En vez de comprar un disco, pagas una suscripción.
En vez de guardar una película o serie, la “tienes” en tu plataforma.
En vez de almacenar tus libros, “compras” un archivo que solo existe dentro de la aplicación.
En ves de comprar tu aplicación, pagas por usarla y tener la última versión, pero si dejas de pagar ya puedes usarla, estamos en el punto de que muchas aplicaciones funcionan en la web y con conexión, no se instalan en tu ordenador.

La palabra clave aquí es “licencia”.

Hoy, cuando “compras” una película, un juego, una aplicación o un libro digital, la mayoría de las veces lo que compras es una licencia limitada a:

• una plataforma concreta,
• unas condiciones de uso,
• las decisiones de una empresa,
• Y el humor de varios departamentos legales.

Si mañana:

• Cambian los derechos,
• suben los precios (algo que empieza a pasar de forma habitual cada año),
• Cierran acuerdos con otra plataforma,
• O deciden limpiar el catálogo para ahorrar costes…

Esa película, disco de música, aplicación o libro digital que tú creías “tuya” desaparece. Y punto.

Lo he visto con:

• series que desaparecen de varias plataformas a la vez,
• juegos retirados de tiendas digitales,
• aplicaciones de todo tipo que desaparecen y no hay vuelta atrás,
• álbumes que se sustituyen por remasterizaciones que cambian temas, duración o mezcla,
• Libros que se “actualizan” sin que puedas recuperar la versión anterior.

Y entonces te das cuenta de la frase dura pero real:

Si no puedes tenerlo offline, abrirlo cuando te dé la gana y copiarlo a otro sitio, no es tuyo.

Es un alquiler muy bien empaquetado.

¿Qué significa “propiedad” digital en 2025?

Visto así, la pregunta importante es: ¿qué significa hoy ser dueño de algo digital?

Para mí, en 2025, ser dueño de un contenido digital implica cuatro cosas muy concretas:

1. Tener el fichero
   El archivo está en tu poder: en tu disco, tu NAS, tu servidor.
   Si mañana se cae internet, sigue ahí y tienes que poder seguir accediendo a él como prefieras.
2. En un formato abierto o documentado
   Que puedas reproducirlo o leerlo con distintos programas y sistemas dentro de 5, 10 o 20 años.
   Cuanto más estándar, mejor: MP3, FLAC, MP4, EPUB, PDF, ODF… Que aún tengo ficheros en algunas de las primeras versiones de CorelDraw que tardé mucho en recuperar, o ficheros comprimidos con Q que tuve la suerte de tener guardado el EXE de MS-DOS.
3. Sin depender de llaves que no controlas
   Si hay cifrado, tú controlas la clave. Si el acceso depende de un DRM que puede caducar o revocarse, no es propiedad, sino un alquiler.
4. En un sitio que tú controlas
   Puede ser un PC en casa, un NAS, un servidor de un proveedor en el que confías, o incluso un disco guardado en un cajón.
   Lo importante es que ningún cambio en las condiciones de un tercero pueda borrarlo de un plumazo.

Cuando una de estas patas falla, vuelves al modelo de “te dejamos usarlo mientras nos interese”.

Cómo empecé a recuperar parte del control

En mi caso no hubo un momento concreto de “revelación”. Fue más bien un goteo de pequeñas broncas con la realidad:

• Una serie desaparece justo a mitad de temporada,
• Una película que había “comprado” deja de estar disponible en esa plataforma,
• Un disco que llevaba años en una playlist es sustituido por otra versión,
• Pero especialmente los servicios que suben los precios o cambian las condiciones cada pocos meses.

Al final, como muchos, volví a algo que ya conocía bien: guardar mis cosas yo mismo.

No hablo de volver a los tiempos del todo pirata, sino de otra cosa:

• Comprar música en formato digital sin DRM siempre que sea posible, de hecho volvemos a tener colección de discos en CD en casa,
• hacer copias locales de fotos y vídeos familiares,
• descargar copias legales de contenidos que realmente valoro,
• buscar software que pueda comprar y usar siempre que quiera sin cuotas y sin necesidad de validar con Internet,
• Montar servidores propios para música, películas, documentos o notas (algo que ando experimentando poco a poco).

En mi caso, con mi deformación profesional, esto pasa por:

• tener un NAS,
• alguna máquina en casa,
• Y servidores en infraestructuras que conozco muy bien.

Pero no hace falta llegar a ese nivel.
Con un PC viejo, uno o dos discos externos y algo de paciencia se puede avanzar muchísimo. Y lo más importante siempre tener copias de seguridad, además de discos duros se puede volver a grabar cosas en formatos como el DVD que para algunas cosas sigue teniendo su gracia.

Autoalojar no es solo para frikis: es un seguro de memoria

Cuando se habla de autoalojar (self-hosting), mucha gente imagina armarios de racks, ruido de ventiladores y terminales llenos de comandos.
La realidad, para un usuario normal, puede ser mucho más sencilla:

Un esquema básico puede ser algo así:

• Organizar tu biblioteca
  Empezar por poner orden en las fotos, los vídeos, la música y los documentos.
  Nombrar bien los archivos, agruparlos por año, evento, proyecto…
• Tener al menos dos copias
  Una en tu equipo o en tu NAS, otra en un disco externo que no esté siempre conectado.
  Y si puedes, una tercera fuera de casa (otro domicilio o un almacenamiento cifrado en la nube).
• Usar herramientas sencillas para acceder a tu contenido
  • Un servidor de medios (Plex, Jellyfin, etc.)
  • Un sistema de notas o documentos (por ejemplo, Nextcloud, o simplemente carpetas sincronizadas)
  • Un visor de fotos autoalojado, si te animas.
• Pensar en local primero
  Que todo funcione aunque se vaya el internet.
  El acceso remoto vendrá después si lo necesitas.

¿Tiene trabajo? Sí.
¿Requiere aprender algunas cosas nuevas? También.
¿Merece la pena para lo que realmente te importa? Para mí, sin duda.

No todo hay que poseerlo: elegir qué conservar y qué alquilar

Tampoco se trata de obsesionarse y guardar absolutamente todo.

Yo lo estoy enfocando así:

• Propiedad total
  • fotos y vídeos familiares,
  • copias de seguridad de mis proyectos,
  • música o libros que para mí tienen valor especial,
  • Contenidos que he comprado sin DRM.
• Uso mixto (local + nube)
  • Documentos de trabajo,notas,material que necesito en varios dispositivos.Siempre en formatos abiertos y con copia local, aunque use sincronización. Por entrar en un detalle, no uso formatos de Google Docs, prefiero un ODT o un DOCX que contiene el dato y no un hipervínculo a los datos en la nube de Google.
• Alquiler consciente
  • series de moda,Películas
  que solo veré una vez,música que no quiero comprar pero si escuchar, aplicaciones
  • O juegos que sé que son temporales.
  Aquí acepto que es un alquiler y nada más. Lo disfruto y lo dejo ir.

La diferencia con el modelo actual es esta:
Antes confundía “lo tengo en la plataforma X” con “es mío”.
Ahora intento tener claro que, si no vive en mi infraestructura, no es realmente mío.

El precio de recuperar la propiedad (y por qué lo pago gustoso)

Ser dueño de algo en digital en 2025 tiene un precio:

• tiempo para organizar y aprender,
• dinero para algo de hardware,
• Disciplina para hacer copias de seguridad y revisarlas de vez en cuando.

A cambio, gano algo que cada vez valoro más:
La tranquilidad de saber que parte de mi vida digital no depende de una cláusula en una página web ni de los caprichos de una empresa.

No pretendo que todo el mundo se monte un minicentro de datos en casa.
Pero sí creo que, como usuarios, tenemos que dejar de creernos el cuento de que “comprar digital” es lo mismo que comprar en físico.

No lo es.

Y si queremos que parte de nuestra cultura, nuestras memorias y nuestro trabajo no se evaporen en el próximo cambio de catálogo, tendremos que volver, aunque sea un poco, a algo muy simple:

➡️ Guardar lo que nos importa, con nuestras propias manos, en sistemas que controlamos nosotros.

Al final, se trata de elegir qué quieres recordar

Cuando echo la vista atrás, veo claramente tres etapas:

1. La época en la que descargábamos todo y lo guardábamos todo, con sus luces y sus sombras, pero con una sensación clara de control.
2. La era dorada del streaming y las suscripciones, en la que nos creímos que el acceso lo solucionaba todo.
3. El momento actual, en el que empezamos a ver los límites de ese modelo y la necesidad de recuperar parte de la propiedad perdida.

No todo merece el esfuerzo de conservarlo.
Pero algunas cosas, sí.

Música, libros, películas, fotos, proyectos, recuerdos, algunas aplicaciones y juegos…
Si dentro de 10 o 20 años quiero seguir teniéndolos, sé que no puedo delegarlo todo en plataformas que cambian más rápido que mi memoria.

Por eso, poco a poco, estoy volviendo a algo muy básico:

• ficheros que controlo,
• formatos que entiendo,
• claves que no dependen de nadie,
• Servidores y discos que puedo tocar con la mano.

En un mundo donde casi todo es alquiler, elegir qué quieres poseer de verdad es casi un acto de rebeldía tranquila.
Y, al menos en mi caso, es una rebeldía que pienso seguir practicando.

Imagen de AI free images.

La entrada No eres dueño de casi nada digital (y cómo estoy recuperando parte de lo perdido) aparece primero en Carrero.

Hoy, cuando uno lee titulares sobre multimillonarios de Silicon Valley comprando enormes extensiones de tierra en California, impulsando proyectos urbanos propios en distintas partes del mundo o negociando regímenes especiales con pequeños Estados, la sensación es extraña: muchas de aquellas ideas que parecían teoría radical de los 90 empiezan a materializarse, aunque sea de forma imperfecta, desigual y a veces bastante cutre.

Este artículo no pretende ser un panfleto anti-tecnología (al contrario, vivo de ella y creo firmemente en su potencial), pero sí una reflexión personal sobre hacia dónde nos puede conducir ese sueño recurrente de algunos magnates: construir sus propias ciudades-Estado donde ellos fijan las reglas del juego.

De la ciudad-Estado medieval al “campus-Estado” tecnológico

La metáfora de los “señores feudales de Silicon Valley” no es casualidad. En la Edad Media, el poder real estaba fragmentado: pequeñas unidades políticas controladas por señores con su ejército, su castillo y sus normas. Los campesinos dependían de ellos para todo: seguridad, justicia, trabajo.

Hoy no hay castillos de piedra, pero sí campus vallados, grandes extensiones de terreno compradas discretamente y acuerdos con autoridades locales para crear zonas urbanas “modelos de innovación” con regulaciones a medida. No hace falta mucha imaginación para ver el paralelismo:

• Ellos controlan la infraestructura crítica: redes, nubes, plataformas, pagos, incluso identidad digital.
• Ellos marcan las condiciones de acceso: términos de uso, comisiones, algoritmos invisibles.
• Ellos sueñan con territorios físicos donde las reglas tradicionales se relajen: urbanismo, fiscalidad, derecho laboral, experimentación tecnológica.

Lo que cambia no es sólo el nivel tecnológico, sino también la ambición: ya no se trata simplemente de empresas influyentes, sino de actores privados que aspiran a tener su propio “espacio soberano” en el que el Estado pase a un segundo plano.

Lo que anunciaba El individuo soberano… y lo que no vio venir

Rees-Mogg y Davidson planteaban en su libro una tesis poderosa: al pasar de una sociedad industrial a una sociedad de la información, el capital intelectual y digital podría moverse por el mundo con mucha mayor facilidad que los Estados. Eso permitiría a las personas más ricas y conectadas “arbitrar” entre jurisdicciones, elegir dónde tributan, dónde viven y bajo qué normas operan.

Varias de sus predicciones han envejecido sorprendentemente bien:

• La deslocalización del capital y las empresas que “eligen” país como quien elige hosting.
• La pérdida de poder relativo de los Estados nacionales frente a los mercados globales, los grandes fondos y las corporaciones tecnológicas.
• El auge de los activos digitales y de los sistemas de pago alternativos, desde las criptomonedas hasta nuevas formas de mover dinero casi sin fricción entre países.

Pero quizás lo que el libro subestimó fue el grado de concentración de poder en unas pocas plataformas privadas. La visión era la de individuos más libres; la realidad, de momento, se parece más a una dependencia creciente de infraestructuras controladas por muy pocos actores.

En lugar de millones de individuos soberanos y plenamente empoderados, lo que se ve es la aparición de una especie de aristocracia digital con capacidad para negociar de igual a igual con los gobiernos… o incluso para intentar diseñar sus propias ciudades-Estado desde cero.

¿Qué prometen estas nuevas “ciudades privadas”?

Cuando se analiza el discurso de los impulsores de estas ciudades-Estado de inspiración tecnológica, suelen repetirse algunos argumentos:

• Innovación sin trabas: menos burocracia, menos normas “anticuadas”, más margen para experimentar con urbanismo, movilidad, IA, drones, biometría, etc.
• Fiscalidad “eficiente”: impuestos simples y bajos, a cambio de atraer talento global y capital a gran escala.
• Gobernanza algorítmica: desde las votaciones digitales hasta los contratos inteligentes, con la promesa de menos corrupción y más transparencia.
• Seguridad y calidad de vida: entornos supuestamente más seguros, limpios, sostenibles y orientados a una élite de profesionales globales.

Sobre el papel puede sonar atractivo, sobre todo si se compara con la lentitud y torpeza de muchas administraciones públicas. Pero detrás de esa narrativa hay preguntas incómodas:

• ¿Quién decide qué se puede experimentar y qué no?
• ¿Qué pasa con los derechos laborales, la protección social o el acceso a la vivienda?
• ¿Quién representa a quienes viven allí si no son accionistas ni fundadores?
• ¿Qué mecanismos hay para limitar los abusos de poder… cuando el poder no es un Estado, sino una empresa?

De utopía libertaria a desigualdad acelerada

Una de las ideas centrales de El individuo soberano es que quienes mejor naveguen la transición tecnológica podrán “desconectarse” parcialmente de las obligaciones de los Estados tradicionales. En la práctica, eso significa que los más ricos pueden vivir donde quieran, tributar donde les convenga y negociar condiciones especiales.

Las ciudades-Estado privadas o semiprivadas encajan en esa lógica:

• Territorios pensados para atraer a una minoría de alto poder adquisitivo, con servicios de primer nivel, un buen entorno regulatorio y una digitalización extrema.
• Entornos en los que los costes sociales (sanidad pública, educación universal, infraestructuras comunes) pueden quedar fuera del modelo… y seguir recayendo en los países “normales”.
• Una brecha creciente entre quienes viven dentro de esas burbujas hiperoptimizadas y quienes se quedan en ciudades y países que siguen sosteniendo el resto del sistema.

El riesgo es evidente: que la transición hacia una economía basada en la información no traiga sólo más eficiencia, sino también más fragmentación social y territorial, con feudos de alta tecnología rodeados de zonas que se quedan atrás.

¿Y Europa? ¿Y España? Soberanía digital frente a feudos privados

Desde la perspectiva europea, todo esto se cruza con un tema del que hablo mucho: la soberanía digital. Mientras algunos sueñan con ciudades privadas diseñadas desde Silicon Valley, la Unión Europea intenta construir un modelo en el que:

• La tecnología se integra con derechos fundamentales, como la privacidad o la protección de datos.
• Las grandes plataformas no puedan actuar como legisladores de facto sin ningún tipo de control democrático.
• La innovación conviva con normas claras en materia de competencia, fiscalidad y trabajo.

No es un camino perfecto ni rápido, y muchas veces la regulación llega tarde. Pero si Europa renuncia a dar esa batalla, el vacío lo llenarán otros con su propia visión: una mezcla de capital, algoritmos y territorios a medida, donde el voto pese menos que la participación accionarial.

En España, el debate todavía suena lejano cuando se habla de “ciudades-Estado tecnológicas”, pero no lo es tanto si se piensa en:

• Zonas económicas especiales o regímenes fiscales ultraflexibles para atraer grandes empresas.
• Ciudades que compiten por convertirse en hubs tecnológicos poniendo sobre la mesa suelo, infraestructuras y normativas flexibles.
• Dependencia creciente de nubes, chips y plataformas que no controlamos ni producimos aquí.

Si la única alternativa al Estado tradicional es el feudo privado, vamos mal. La respuesta debería pasar por fortalecer instituciones democráticas capaces de regular la tecnología, garantizar los derechos y, a la vez, permitir innovar sin convertir a los ciudadanos en meros “usuarios” de un sistema cerrado.

Una reflexión personal para cerrar

Cuando leí El individuo soberano, me impresionó la capacidad de sus autores para anticipar tendencias que hoy damos por hechas: la globalización del capital, la digitalización de casi todo, la erosión de ciertas formas de poder estatal. Pero también me llamó la atención algo que se ha confirmado con el tiempo: no existe la neutralidad en la tecnología.

Las ciudades-Estado imaginadas por la élite de Silicon Valley no son simples experimentos urbanísticos. Son propuestas de un nuevo contrato social, en las que muchas de las garantías que hoy damos por sentadas (desde la sanidad pública hasta la protección de datos) pasan a depender de decisiones privadas.

Como alguien que lleva toda la vida en Internet, que cree en el emprendimiento y que vive de la nube, no me considero tecnófobo ni mucho menos. Pero precisamente por eso me parece importante hacer estas preguntas incómodas ahora, y no cuando todas las piezas estén ya colocadas sobre el tablero.

Porque quizá la verdadera disyuntiva de las próximas décadas no será sólo entre Estados fuertes y Estados débiles, sino entre democracias capaces de gobernar la tecnología y feudos privados disfrazados de ciudades inteligentes.

Y ahí, cada ciudadano —cada “individuo soberano”, si se quiere mantener la expresión— tendrá que decidir de qué lado quiere vivir.

La entrada Los nuevos feudos de Silicon Valley y el eco inquietante de El individuo soberano aparece primero en Carrero.