El paralelismo con la IA es bastante evidente. Hoy los grandes laboratorios funcionan como aquellos mainframes: infraestructura muy cara, concentrada en pocas manos y alquilada por uso. La unidad ya no es el minuto de CPU, sino el token. OpenAI, Anthropic, Mistral AI, OpenRouter, Google y otros proveedores venden acceso a modelos frontera de una forma muy parecida a como se alquilaba capacidad de cómputo cuando comprar un ordenador era imposible para casi cualquier empresa.

La pregunta es si vamos a depender siempre de ese esquema. Desde la parte de infraestructura, mi respuesta cada vez es más clara: no para todo. Veremos un modelo híbrido en el que los modelos frontera seguirán siendo necesarios para tareas complejas, pero una parte creciente del trabajo diario se ejecutará sobre modelos open source, modelos ligeros o modelos especializados desplegados en infraestructura propia, cloud privado o bare-metal gestionado.

Del pago por token al servidor propio de IA

Javier apunta que el precio de los tokens ya está cayendo con rapidez y recuerda que GPT-4 salió en 2023 a 30 dólares por millón de tokens de entrada, mientras que modelos actuales equivalentes o más baratos se sitúan muy por debajo de esa cifra en muchos casos. Su lectura es que el mercado se está comoditizando con la misma lógica que antes siguió el hardware.

Esa caída de precio cambia la conversación, pero no elimina el problema. Cuando una empresa empieza con IA, el gasto por token suele parecer asumible. Un piloto, unos cuantos usuarios, algunos flujos internos. El problema aparece cuando la adopción crece. Agentes que iteran durante minutos, asistentes que leen documentos largos, herramientas que resumen llamadas, copilotos internos, procesos de backoffice, soporte, análisis de logs, generación de informes. El token deja de ser una curiosidad y se convierte en una línea seria del presupuesto.

Ahí empieza el salto que ya estamos viendo en clientes y conversaciones de infraestructura: “¿por qué tengo que pagar al modelo más caro para tareas que no lo necesitan?”. Muchas organizaciones no quieren ejecutar en local todo su stack de Inteligencia Artificial. Lo que quieren es dejar de enviar a modelos frontera aquello que puede resolver un modelo más pequeño, más barato y bajo su control.

No se trata de una postura romántica a favor del open source. Es una decisión económica y operativa. Si una tarea es repetitiva, interna, predecible y no exige el mejor razonamiento del mercado, tiene sentido estudiar si puede correr en infraestructura propia. Si además maneja datos sensibles, documentación interna o requisitos de cumplimiento, el argumento se refuerza.

Zylon es un buen ejemplo de esta dirección. La compañía presenta su infraestructura como una solución de IA generativa privada y on-premise para sectores regulados, con despliegue dentro de la infraestructura empresarial y sin dependencia de nube externa. Además, su PrivateGPT 1.0 se define como una capa API open source para construir aplicaciones privadas de IA sobre servidores de inferencia locales o autoalojados.

Pero este movimiento no va solo de Zylon. Va de una transición más amplia: pasar de usar siempre APIs externas a diseñar una arquitectura de IA con varios niveles de cómputo.

La arquitectura ganadora será híbrida

Creo que la arquitectura razonable para muchas empresas no será “todo cloud” ni “todo local”. Será una mezcla.

Los modelos frontera seguirán teniendo sentido para tareas de alto valor: razonamiento complejo, planificación, revisión crítica, generación avanzada, problemas ambiguos o flujos donde la calidad adicional compensa claramente el coste. Pero una gran parte de los usos empresariales no necesita el modelo más potente en cada llamada.

Ahí entran modelos open source, modelos pequeños, cuantizados, especializados o ejecutados en servidores propios. También entran estrategias como separar ejecución y criterio: un modelo barato ejecuta la mayor parte del trabajo y un modelo superior entra solo como asesor cuando hay una decisión difícil. Anthropic ya ha formalizado patrones de este tipo con su enfoque de advisor, donde un modelo executor puede consultar a un modelo más capaz sin cederle el control completo del flujo.

La cuestión no es elegir un modelo. Es diseñar una política de uso de modelos.

En Stackscale ya vemos ese “salto al servidor propio” desde la infraestructura. No siempre significa comprar una caja física para ponerla en una oficina. Puede ser un entorno de cloud privado, bare-metal, GPU dedicada, plataforma gestionada, almacenamiento aislado, red privada y políticas de seguridad adaptadas. Lo importante es que la empresa deja de depender de facturar cada interacción contra un proveedor externo para todo lo que hace.

Ese cambio también obliga a ser honestos. Autoalojar IA no siempre es más barato. Depende de la utilización, de la concurrencia, del hardware, de la operación, del modelo elegido y del perfil de carga. Un trabajo reciente sobre estimación de costes en infraestructura LLM advierte precisamente de que asumir utilización fija de GPU lleva a errores grandes: con baja o media carga, el coste efectivo por millón de tokens puede variar mucho por infrautilización.

Esto es importante porque evita caer en el discurso fácil. Montar tus propios modelos puede ahorrar mucho dinero si hay volumen, estabilidad de carga y equipo para operarlo. Pero puede salir caro si se compra hardware que pasa la mayor parte del tiempo parado. El cálculo no es “API cara frente a servidor gratis”. El cálculo real es coste por tarea útil, con seguridad, latencia, mantenimiento, disponibilidad y evolución de modelos incluidos.

Dónde quedará el valor

Si el patrón histórico se cumple, los modelos generalistas tenderán a comoditizarse. No desaparecerán. Al contrario, serán más potentes y más accesibles. Pero cada vez será más difícil construir una ventaja sostenible únicamente sobre “tener acceso a un modelo generalista”. Ese acceso lo tendrán todos.

El valor se moverá a las capas superiores.

Estará en los datos propios, en la integración con procesos reales, en la experiencia de usuario, en los flujos verticales, en la seguridad, en el cumplimiento, en la trazabilidad, en la capacidad de medir resultados y en saber qué modelo usar en cada momento. Igual que el valor no se quedó para siempre en “tener un servidor”, sino en lo que las empresas construyeron encima de esa infraestructura.

Una empresa no necesita “IA” en abstracto. Necesita reducir tiempos de soporte, revisar contratos, automatizar reporting, acelerar desarrollo, auditar configuraciones, asistir a comerciales, ayudar a técnicos de campo, analizar incidencias o mejorar decisiones. Para eso, el modelo es solo una pieza. La parte difícil es convertirlo en producto, proceso y ventaja operativa.

Por eso me interesa tanto el paralelismo de Javier. La historia no dice que los grandes proveedores vayan a dejar de importar. IBM no dejó de importar de golpe cuando aparecieron servidores más pequeños. Los cloud públicos no dejaron de importar cuando las empresas siguieron usando infraestructura propia. Lo que cambia es el reparto.

Mi apuesta es que entre 2027 y 2030 muchas organizaciones descubrirán que no necesitan enviar todo a un modelo frontera. Usarán los mejores modelos cuando compense y ejecutarán mucho más trabajo sobre modelos propios o privados. La decisión de modelo pasará de ser una elección individual de cada usuario a una decisión de arquitectura.

Ahí es donde las empresas deberían empezar ya: inventariar usos, medir consumo, clasificar tareas, separar datos sensibles, probar modelos locales, evaluar costes reales y construir una capa de gobierno. No para salir mañana de las APIs de OpenAI, Anthropic, Mistral AI o Google, sino para no depender de ellas en todo.

El futuro no será dejar de pagar tokens. Será pagar tokens solo donde tengan sentido.

Preguntas frecuentes

¿Significa esto que las empresas dejarán de usar modelos frontera?
No. Los modelos frontera seguirán siendo útiles para tareas complejas, razonamiento avanzado y casos donde la calidad compense el coste.

¿Cuándo tiene sentido ejecutar modelos en infraestructura propia?
Cuando hay volumen suficiente, datos sensibles, tareas repetitivas, necesidad de control o costes por token difíciles de justificar a escala.

¿Autoalojar IA siempre es más barato?
No. Depende de la utilización del hardware, concurrencia, mantenimiento, soporte, energía, seguridad y operación. Hay que medir coste por tarea, no solo precio por token.

¿Qué papel tendrán los modelos open source?
Serán cada vez más importantes para cargas internas, RAG privado, automatizaciones, asistentes especializados y tareas que no requieren el modelo más avanzado.

¿Dónde estará el valor si los modelos se comoditizan?
En las capas verticales: datos propios, integración con procesos, seguridad, experiencia de usuario, gobierno, métricas y productos concretos para sectores concretos.

Fuentes:

• Javier Escribano, La historia nos enseña cuál será el precio de los tokens.
• Zylon, infraestructura privada de IA para sectores regulados.
• PrivateGPT, documentación sobre su capa API local para aplicaciones privadas de IA.
• Anthropic/Zylon, lanzamiento de PrivateGPT 1.0 y enfoque de backend privado de IA.
• Chitral Patil, Beyond Per-Token Pricing: A Concurrency-Aware Methodology for LLM Infrastructure Cost Estimation.

La entrada La IA también tendrá su servidor propio: del token al cloud privado aparece primero en Carrero.

El problema empieza después, cuando la buena intención se convierte en otra capa de incertidumbre jurídica, procedimientos internos, iconos, sellos, políticas, responsables, proveedores, auditorías y miedo a sanciones. Europa no compite con Estados Unidos y China fabricando modelos fundacionales a escala. No lidera la nube. No domina los chips de IA. No tiene los grandes productos globales de consumo. Pero sí quiere liderar la forma en que todos los demás deben documentar, etiquetar y justificar lo que hacen.

Mi impresión es cada vez más clara: Europa se ha acostumbrado a confundir regulación con estrategia industrial. Y no son lo mismo.

La etiqueta de IA es el síntoma, no la enfermedad

El Código de Buenas Prácticas sobre transparencia de contenido generado por IA, publicado por la Comisión Europea el 10 de junio de 2026, desarrolla las obligaciones de transparencia del artículo 50 del AI Act. Divide el problema en dos bloques: proveedores, que deben facilitar marcado y detección de contenido generado o manipulado por IA; y deployers, es decir, quienes usan esos sistemas y deben etiquetar deepfakes y ciertas publicaciones de texto generadas o manipuladas con IA. Las obligaciones de transparencia empiezan a aplicarse el 2 de agosto de 2026.

Hasta aquí, se puede defender. Si una herramienta genera un deepfake realista, tiene sentido que haya una señal técnica y una advertencia comprensible. Si una empresa publica un vídeo con una persona que no existe, también parece razonable que el usuario lo sepa. Si un contenido informativo sobre asuntos públicos ha sido generado automáticamente, conviene que no se disfrace de trabajo humano sin control.

El problema es que la IA ya no funciona como una herramienta separada. No es una máquina donde metes un prompt y sale “contenido de IA” perfectamente delimitado. La IA se está metiendo en cada paso del trabajo: lluvia de ideas, corrección de tono, traducción, resumen, borradores, edición de imagen, generación de fondos, retoque, transcripción, limpieza de datos, presentaciones, propuestas comerciales, campañas publicitarias y documentación interna.

Ahí aparece la zona gris. Si un texto lo escribe una persona, pero antes ha usado ChatGPT, Claude, Gemini o cualquier otra inteligencia artificial para ordenar ideas, ¿hay que etiquetarlo? Si una agencia genera una imagen de una modelo inexistente llevando un vestido real, ¿qué se etiqueta exactamente: la modelo, la escena, el anuncio completo? Si una empresa usa IA para mejorar tres frases de una presentación comercial, ¿entra dentro de una obligación de transparencia o solo es asistencia editorial?

La norma intenta distinguir supuestos. También hay excepciones para obras artísticas, satíricas o ficcionales, y para ciertos textos que hayan pasado por revisión humana o control editorial con responsabilidad sobre la publicación. Pero el problema no desaparece: se traslada a la interpretación. Y cuando la interpretación viene con multas potenciales de hasta 15 millones de euros o el 3 % de la facturación anual mundial, las empresas no interpretan con valentía; interpretan con miedo.

La innovación no muere de golpe: se llena de formularios

Europa rara vez prohíbe innovar de forma directa. Lo hace de una forma mucho más lenta: encarece probar, retrasa lanzar, complica vender y obliga a dedicar recursos a cumplimiento antes de saber si el producto funciona. Para una gran tecnológica, esto es molesto. Para una startup, puede ser la diferencia entre lanzar o quedarse sin caja.

La Comisión defiende que el código dará previsibilidad, reducirá carga administrativa y permitirá a quienes lo firmen demostrar cumplimiento en toda la UE. En teoría, mejor eso que 27 interpretaciones distintas. Pero el propio planteamiento ya revela el problema: para publicar, vender o usar IA en Europa empiezas a necesitar una estrategia de cumplimiento antes de tener una estrategia de mercado.

A veces parece que Bruselas diseña normas pensando en Google, OpenAI, Anthropic, Amazon, Meta o Microsoft, pero quien termina sufriendo la complejidad es una pyme, una agencia, un creador, un desarrollador independiente o una startup europea que no tiene un departamento legal con 40 personas.

Y mientras tanto, fuera de Europa, el mercado se mueve. Estados Unidos invierte, compra, prueba, falla, corrige y escala. China planifica, subvenciona, integra y empuja. Europa debate, consulta, publica códigos de buenas prácticas, crea iconos y abre periodos de adecuación.

No digo que no haya que regular. Lo que digo es que regular sin capacidad industrial propia se parece mucho a arbitrar una final que no estás jugando.

Estados Unidos y China compiten en capacidad; Europa en cumplimiento

El Stanford AI Index 2026 es bastante claro sobre el desequilibrio. Estados Unidos siguió liderando la inversión privada global en IA en 2025, con 285.900 millones de dólares, y en IA generativa su inversión superó con amplitud la suma de China y Europa. El informe también señala que la inversión privada estadounidense fue 23 veces superior a la china, aunque advierte que las cifras privadas pueden infravalorar el gasto real de China por el peso de fondos públicos y vehículos guiados por el Estado.

Europa intenta reaccionar. La Comisión ha presentado InvestAI y el AI Continent Action Plan, con el objetivo de movilizar 200.000 millones de euros para IA, incluidos 20.000 millones para hasta cinco gigafactorías de IA y una red de fábricas de IA para apoyar startups, industria e investigación. Es una iniciativa necesaria, pero llega después de años en los que el mercado ya se ha ordenado alrededor de nubes, chips, modelos y productos mayoritariamente no europeos.

La diferencia no es solo dinero. Es velocidad cultural. En Estados Unidos, una empresa prueba una herramienta, mide tracción y pide perdón si se equivoca. En Europa, muchas veces primero se pregunta si habrá directiva, reglamento, guía, autoridad competente, evaluación de impacto, base jurídica, consentimiento, registro, comité, delegado y plantilla de aviso.

Esa cultura no se cambia con un fondo de inversión público. Se cambia reduciendo fricción real para crear, vender, contratar, despedir, financiar, fusionar, escalar y competir.

El informe Draghi ya avisó: Europa tiene un problema de competitividad

Mario Draghi no escribió un panfleto libertario. Su informe sobre competitividad europea es un diagnóstico institucional encargado desde dentro de Europa. Y aun así dice algo muy incómodo: Europa debe cerrar la brecha de innovación con Estados Unidos y China si quiere mantener crecimiento, productividad y capacidad estratégica. El informe insiste en la necesidad de actuar a escala europea, reducir fragmentación y acelerar inversión en sectores críticos.

Esa palabra, fragmentación, es clave. Europa regula como bloque, pero muchas veces se opera como un puzzle de mercados nacionales. Un emprendedor europeo no vende en “Europa” con la misma facilidad con la que un estadounidense vende en Estados Unidos. Se encuentra idiomas, fiscalidades, normas laborales, criterios de contratación pública, reguladores nacionales, culturas comerciales distintas y una enorme aversión corporativa al riesgo.

Atomico lo resumía con otra cifra reveladora en su lectura del State of European Tech 2025: Europa genera el 17 % del nuevo valor empresarial global, pero solo captura el 10 % del valor de salida. Es decir, crea, pero no siempre retiene. Construye empresas, pero muchas veces el valor final se acaba yendo a otros mercados, otras bolsas o compradores de fuera.

Eso también es regulación. No solo la norma explícita. También el entorno que hace más difícil crecer rápido.

La transparencia es buena; la ambigüedad es veneno

La etiqueta “AI Generated” no es mala por sí misma. Lo malo es convertirla en otro espacio donde nadie sabe exactamente qué debe hacer hasta que llegue la sanción o el criterio del regulador.

Etiquetar un deepfake político: sí.
Etiquetar un anuncio donde una persona real ha sido sustituida por una generada por IA: probablemente sí.
Etiquetar una obra artística generativa de forma contextual, sin reventar la pieza: razonable.
Etiquetar cada texto, imagen, presentación, correo, landing o campaña que haya pasado por una herramienta de IA en algún momento: absurdo.

El problema está en la frontera. Y esa frontera cada vez será más imposible de trazar. Dentro de poco no hablaremos de “usar IA” como algo excepcional. Será como usar corrector ortográfico, cámara computacional, traducción automática, autocompletado, filtros, buscador, plantillas, asistentes de diseño o herramientas de análisis. La IA será parte del proceso de producción normal.

Si Europa obliga a tratar cada intervención de IA como una anomalía que debe ser marcada, documentada y explicada, acabará castigando a quien adopte herramientas modernas. El incentivo perverso será doble: o se etiqueta todo para cubrirse, con lo que la etiqueta deja de informar, o se evita usar IA en procesos legítimos para no abrir un frente legal.

Ninguna de las dos opciones mejora la confianza del usuario.

El coste competitivo para agencias, creadores y pymes

Hay un punto que en Bruselas se suele infravalorar: la regulación no cae igual sobre todos. Una multinacional puede absorber abogados, consultores, revisiones y procesos. Una pyme o un creador no.

Una agencia europea que produzca campañas con IA tendrá que decidir cómo etiquetar, dónde, con qué icono, en qué idioma, con qué evidencias internas y bajo qué política. Su competidor en Estados Unidos o Latinoamérica puede operar con menos fricción si no se dirige formalmente al mercado europeo o si su cliente no exige esos estándares. Y aunque la norma europea tenga alcance extraterritorial en determinados supuestos, la realidad comercial es más simple: si trabajar con un proveedor europeo se vuelve más lento, más caro y más incierto, algunos clientes buscarán otro camino.

Esto ya lo vimos con las cookies. La promesa era más control para el usuario. El resultado, en muchos casos, fue una web peor: banners interminables, consentimientos diseñados para cansar y usuarios aceptando sin leer. GDPR elevó derechos importantes, sí, pero también convirtió parte de internet en una carrera de cumplimiento donde la experiencia de usuario quedó secuestrada por capas legales.

Con la IA puede pasar algo parecido. Si todo se llena de avisos genéricos de “contenido generado con IA”, el usuario no estará más informado. Estará más saturado.

Europa necesita menos teatro regulatorio y más capacidad de ejecución

El gran error sería plantear esto como una pelea entre regulación y barra libre. No lo es. Hace falta regular deepfakes, fraudes, sistemas de alto riesgo, biometría abusiva, vigilancia, discriminación automatizada y usos opacos en ámbitos sensibles. Nadie debería querer un mercado de IA sin responsabilidad.

Pero también hace falta reconocer que Europa ha inclinado demasiado la balanza hacia el control preventivo y demasiado poco hacia la creación de campeones tecnológicos. Nos gusta hablar de soberanía digital, pero usamos nubes estadounidenses. Hablamos de IA confiable, pero entrenamos pocos modelos de frontera. Hablamos de chips, pero dependemos de cadenas globales donde el valor crítico está fuera. Hablamos de datos europeos, pero muchas empresas europeas siguen sin saber convertirlos en productos globales.

Regular no es construir. Certificar no es competir. Etiquetar no es innovar.

Si Europa quiere ser relevante en IA, necesita algo más que códigos de buenas prácticas. Necesita capital paciente, energía barata, centros de datos, compras públicas ágiles, mercado único real, menos fragmentación, regulación más simple, fiscalidad menos punitiva para crecer, universidades conectadas con empresas y una cultura que no trate cada intento de automatizar como una amenaza moral.

Mi postura: regular menos, pero mejor

Yo no defiendo eliminar toda regulación. Defiendo algo mucho más difícil: regular con precisión. Poner el foco donde hay daño real y dejar respirar donde hay experimentación legítima.

Deepfakes engañosos, suplantación, manipulación política, fraude, contenido sintético usado para estafar o sustituir pruebas: ahí mano dura.
Uso asistido de IA para escribir mejor, diseñar más rápido, traducir, prototipar, hacer una campaña, editar una presentación o crear una imagen artística: ahí proporcionalidad.
Grandes plataformas con poder sistémico: obligaciones claras.
Pymes, creadores y startups: reglas simples, plantillas útiles y sanciones pensadas para corregir, no para asustar.

Europa debería dejar de legislar como si cada innovación fuera una externalidad negativa esperando a ocurrir. Muchas innovaciones también son productividad, crecimiento, empleo, ahorro de tiempo, nuevos productos y nuevas empresas.

La etiqueta “AI Generated” puede ser una herramienta útil si se limita a donde aporta contexto real. Pero si se convierte en otro símbolo europeo de cumplimiento preventivo, acabará siendo una señal más de nuestro problema: mientras otros construyen la próxima capa tecnológica, nosotros diseñamos el adhesivo que habrá que pegarle encima.

Preguntas frecuentes

¿El AI Act obliga a etiquetar todo contenido creado con IA?
No de forma tan simple. Las obligaciones se centran en marcado técnico por parte de proveedores y en etiquetado de deepfakes y ciertos textos generados o manipulados con IA. El problema está en los casos mixtos y en cómo se interpretan en la práctica.

¿Por qué puede perjudicar esto a la innovación europea?
Porque añade incertidumbre, procesos y riesgo legal a empresas que ya compiten con menos capital, menos escala y menos velocidad que sus rivales de Estados Unidos y China.

¿No es necesaria la transparencia en IA?
Sí, especialmente en deepfakes, fraude, suplantación, política, información pública y contenidos que puedan engañar al usuario. La crítica no es contra la transparencia, sino contra la ambigüedad y el exceso de carga para usos cotidianos.

¿Qué debería hacer Europa para competir mejor?
Regular con más precisión, simplificar cumplimiento, reducir fragmentación del mercado, facilitar inversión, acelerar infraestructuras de IA y tratar a startups y pymes como empresas que deben crecer, no como riesgos que hay que contener.

¿Qué deberían hacer empresas y creadores antes del 2 de agosto de 2026?
Inventariar usos de IA, distinguir contenido interno y público, crear criterios de etiquetado, documentar revisión humana cuando exista y evitar decisiones basadas solo en miedo. La clave será aplicar transparencia donde realmente ayuda al usuario.

Fuentes:
Comisión Europea, Código de Buenas Prácticas sobre transparencia de contenido generado por IA.
La etiqueta “AI Generated” llega a Europa: transparencia útil o nueva zona gris

La entrada Europa no está perdiendo la carrera de la IA por falta de talento, sino por exceso de miedo aparece primero en Carrero.

José Elías tiene una historia empresarial que se ha contado muchas veces desde los titulares: Audax, La Sirena, operaciones corporativas, inversiones, exposición pública, fútbol y patrimonio. Pero en una charla privada, con empresarios delante y sin el formato rápido de las redes sociales, lo que más me interesó no fue la cifra ni la anécdota brillante. Fue la forma en la que enlazó decisiones, errores, crisis personales y aprendizaje empresarial.

Las decisiones que bifurcan una vida

Una de las ideas que más se me quedó fue su reflexión sobre las 30 o 40 decisiones que de verdad bifurcan una vida. El resto, decía, suele ser rutina. Vivimos dentro de un carril hasta que algo nos obliga a salir. Y ahí utilizó una imagen que me pareció muy potente: la víbora.

Cuando algo te muerde, una crisis, una pérdida, una quiebra o un golpe inesperado, sales de la cueva a buscar el antídoto. Esa salida forzada es incómoda, pero también es donde una persona cambia. No porque quiera, sino porque no le queda otra.

En su caso, habló de pérdidas personales muy tempranas, de la muerte de su madre y de su padre cuando era joven, y de cómo esas experiencias le cambiaron la escala de los problemas. No lo planteó desde el victimismo. Al contrario. Lo explicó como una forma de resiliencia. Cuando algo grave ya ha pasado por tu vida, muchas otras dificultades pierden tamaño.

Esa idea conecta bien con el emprendimiento real, no con el que se vende en vídeos cortos. Muchas personas empiezan por vocación, pero muchas otras empiezan porque no tienen alternativa. En ambos casos, la empresa acaba siendo una prueba de resistencia. No gana siempre el más brillante. A menudo aguanta más quien soporta mejor el golpe, aprende antes y sigue avanzando cuando el plan inicial se rompe.

La quiebra de 2008 y una norma que no volvió a romper

Elías habló sin adornos de su quiebra en construcción durante la crisis de 2008. Se quedó sin cobrar, sin clientes y con una lección grabada: no volver a ser proveedor de dinero de otros. En sus palabras, nunca más aceptar pagarés.

Me pareció una de las partes más interesantes de la charla porque resume algo que muchos empresarios aprenden demasiado tarde. Vender no siempre es cobrar. Facturar no siempre es ganar. Y trabajar mucho para financiar a un cliente que no paga puede destruir una empresa aunque la cuenta de resultados parezca razonable durante un tiempo.

Según contó, de esa reflexión llegó casi por descarte al sector eléctrico. Buscaba un negocio donde no se funcionara con pagarés, y acabó encontrando un camino en la comercialización de energía. La historia de Audax, tal como la explicó, empezó con muy poco: unos 3.000 euros, un curso y la venta de luz casa por casa, más desde la mentalidad de vendedor que desde la de ingeniero.

Audax Renovables es hoy una compañía cotizada del sector energético, con Francisco José Elías Navarro como presidente ejecutivo, según la información corporativa de la propia empresa. Elías también compró en 2021 el 100 % de La Sirena a través de su grupo Excelsior Times, una operación que se presentó entonces como una vía para impulsar el crecimiento de la cadena de congelados en España.

Lo importante, al menos para mí, no está solo en el salto empresarial. Está en la secuencia: crisis, aprendizaje, cambio de sector, venta directa, problema de liquidez, oportunidad y decisión. Visto desde fuera, las historias de éxito parecen más limpias de lo que fueron. Contadas por quien las ha vivido, aparecen llenas de tensión, deuda, miedo y momentos en los que una mala decisión podía cerrar el camino.

Constancia, talento y equipos mejores que uno mismo

Hubo dos frases que apunté literalmente.

“Rodéate de gente mejor que tú, y que te supere.”

“Es mejor ser feliz que tener razón.”

La primera debería estar escrita en cualquier empresa que quiera crecer de verdad. Muchos fundadores se convierten en cuello de botella porque contratan perfiles que ejecutan, pero no perfiles que les cuestionan. José Elías insistió en la importancia de identificar y retener talento, dar oportunidades a gente de dentro y traspasar responsabilidad real a los directivos. No solo tareas. Responsabilidad con dinero, decisiones y ego incluido.

También fue muy claro sobre los socios. Su frase, dicha con esa mezcla de humor y experiencia que evita cualquier PowerPoint, fue que “un socio, un problema; dos socios, dos problemas”. No lo interpreté como una prohibición de asociarse, sino como una advertencia. Un socio debe aportar algo más que dinero. Si no aporta criterio, mercado, gestión, conocimiento o capacidad real de desbloquear situaciones, puede terminar siendo una carga.

La segunda frase, la de ser feliz antes que tener razón, me pareció menos empresarial y más útil todavía. En la vida de empresa hay muchas discusiones donde ganar el argumento sale caro. Puedes tener razón con un cliente, con un socio, con un proveedor o con un directivo, y aun así perder tiempo, energía, relación o foco. A veces compensa más cerrar el tema, aprender y seguir.

El coste personal de construir

Otra parte que agradecí fue que no romantizara el camino. Habló de crecimiento, de abrir empresas, de expansión internacional y de operaciones que salieron bien, pero también del coste personal. Nada es gratis. Construir empresas consume tiempo, energía, vida familiar y relaciones.

Esto se suele ocultar. En el relato público del empresario aparecen las rondas, las adquisiciones, el EBITDA, las fotos y los titulares. Mucho menos se habla de lo que se queda por el camino. Elías lo hizo sin convertirlo en una escena dramática, pero sí con suficiente claridad como para recordar que la ambición también tiene factura.

Me gustó que mezclara esa dureza con detalles muy terrenales. Comentó que hoy le hacen feliz cosas sencillas, incluso sus animales. Ese contraste me pareció muy humano. Alguien puede manejar operaciones de millones y, al mismo tiempo, encontrar calma en algo que no tiene nada que ver con el balance.

También habló de sus hijos y de cómo intenta educarlos para que no vivan como rehenes de su patrimonio. La frase que dejó fue directa: “El rico soy yo, ellos son hijos de rico; si quieren dinero, que curren”. Más allá del tono, hay una reflexión interesante sobre la transmisión de valores en familias empresarias. El patrimonio puede ser una ventaja, pero también una jaula si sustituye al esfuerzo, al criterio y al sentido de responsabilidad.

IA, empresa y decisiones

La parte de inteligencia artificial fue breve, pero reveladora. No la trató como una moda ni como una amenaza apocalíptica. Dijo que la usa ya en el día a día, también para temas de M&A y decisiones empresariales, y que estamos en pañales de lo que viene.

Me quedo con esa lectura porque encaja con lo que muchos estamos viendo en nuestras empresas. La IA no sustituye la experiencia, pero empieza a cambiar la forma de preparar una decisión. Puede ayudar a ordenar información, revisar escenarios, analizar documentos, comparar hipótesis y detectar puntos ciegos. Donde antes había horas de lectura o de preparación, ahora puede haber una primera capa de análisis mucho más rápida.

Pero el criterio sigue siendo humano. Y, escuchando a José Elías, diría que esa es precisamente una de las constantes de su mensaje: no hay secreto automático, ni fórmula mágica, ni atajo limpio para hacerse rico. Hay persistencia, riesgo, decisiones, equivocaciones y una forma determinada de vivir la empresa.

Salí de la tertulia con una sensación clara. A veces buscamos en estos encuentros una gran revelación, una frase que explique el éxito de alguien. En realidad, lo valioso suele estar en otra parte: en escuchar cómo una persona que ha construido de verdad habla de sus errores sin necesidad de maquillarlos demasiado.

Quizá esa sea la principal lección. La empresa no se entiende solo desde lo que sale bien. Se entiende desde las crisis que obligan a cambiar de sector, desde las normas que uno decide no romper nunca más, desde las personas mejores que uno mismo que consigue sentar en la mesa y desde la capacidad de seguir cuando aparece la víbora.

Preguntas frecuentes

¿Quién es José Elías?
José Elías Navarro es un empresario español, presidente ejecutivo de Audax Renovables y propietario de La Sirena a través de su grupo Excelsior Times.

¿Qué es Audax Renovables?
Audax Renovables es una compañía cotizada del sector energético dedicada a la comercialización y generación de energía, con presencia en varios mercados.

¿Por qué compró José Elías La Sirena?
La operación se anunció en 2021 como una adquisición del 100 % de la cadena de congelados por parte de Excelsior Times, con el objetivo de impulsar su crecimiento en España.

¿Cuál fue la idea más importante de la charla?
Para mí, la más útil fue que el éxito empresarial no depende de un secreto, sino de persistencia, resiliencia, buenas decisiones y capacidad para rodearse de personas mejores que uno mismo.

La entrada Lo que aprendí de José Elías sobre empresa, crisis y resiliencia aparece primero en Carrero.

A mí me interesa más otra pregunta: ¿qué tiene Musk en común con algunos de los grandes inventores y empresarios de la historia? Y, sobre todo, ¿qué diferencia su caso del de Edison, Ford, Jobs, Bezos o Rockefeller?

Porque si uno mira su trayectoria con algo de distancia, la comparación no es tan disparatada. No porque todos sean iguales, ni porque haya que convertir a Musk en un icono al que adorar, sino porque en todos aparece un patrón que se repite: la gran innovación rara vez consiste solo en tener una buena idea. Consiste en convertir esa idea en un sistema que funcione, se repita, escale y sobreviva al mercado.

Eso es mucho menos romántico que imaginar a un genio aislado cambiando el mundo desde una libreta. Pero probablemente es más real.

Elon Musk no se ha hecho relevante solo por fundar empresas. Se ha hecho relevante porque ha empujado sectores físicos, caros y difíciles: coches, baterías, cohetes, satélites, redes, inteligencia artificial, energía. Es decir, sectores donde los errores no se arreglan solo con una actualización de software. Si un coche falla, hay que repararlo. Si una fábrica se atasca, se quema caja. Si un cohete explota, no suele existir muchas más oportunidades con el mismo equipamiento y configuración.

Por eso la imagen de Musk durmiendo en la fábrica durante el “infierno de la producción” del Model 3 se ha vuelto tan potente. No porque dormir en el suelo sea una receta de liderazgo. De hecho, no debería serlo. Sino porque resume una idea que muchas veces se olvida en tecnología: la realidad se decide en la fábrica, no en la presentación.

Los grandes constructores no solo inventaban productos, inventaban sistemas

Thomas Edison no fue importante solo por sus patentes. Fue importante porque entendió que la invención podía organizarse como un proceso. Su laboratorio de Menlo Park no era una habitación de inspiración, sino una fábrica de pruebas, prototipos, errores y mejoras. La bombilla, por ejemplo, no era solo una bombilla. Necesitaba generación eléctrica, distribución, interruptores, contadores, instalación y una forma de llevar la electricidad a hogares y empresas.

Henry Ford tampoco fue solo “el hombre del coche”. El automóvil ya existía. Su gran cambio fue otro: fabricar coches de forma mucho más eficiente, reducir costes y convertir un producto de lujo en algo más accesible para millones de personas. La cadena de montaje de 1913 no fue una anécdota industrial. Fue una nueva forma de organizar trabajo, tiempo, piezas, proveedores y escala.

Steve Jobs no inventó el ordenador personal, ni el reproductor MP3, ni el smartphone como concepto aislado. Su talento estuvo en integrar tecnología, diseño, software, distribución, marca y experiencia de usuario hasta que el producto parecía inevitable. El iPhone no ganó solo por ser un teléfono bonito. Ganó porque Apple conectó hardware, sistema operativo, tienda de aplicaciones, operadores, desarrolladores y una forma nueva de relación con el dispositivo. De hecho hoy muchos llevamos su tecnología en el bolsillo con ese mismo concepto.

Jeff Bezos empezó vendiendo libros online, pero Amazon no se convirtió en Amazon por vender libros. Lo hizo por construir una máquina logística, tecnológica y comercial capaz de prometer comodidad a gran escala. Detrás del botón de compra había almacenes, datos, infraestructura cloud, negociación con proveedores, suscripción, reparto y obsesión por reducir tiempos.

Musk entra en esa tradición de constructores de sistemas. Tesla no es solo un coche eléctrico. Es una mezcla de baterías, software y tecnología, fabricación, carga, marca, datos, integración vertical y cultura de ingeniería. SpaceX no es solo una empresa de cohetes. Es fabricación, motores, reutilización, lanzamientos recurrentes, contratos públicos, satélites, centros de datos para xAI e inteligencia artificial, futuros centros de datos en espacio y una red global como Starlink.

La idea importa. Pero el sistema decide.

Musk no empezó desde cero, pero sí eligió riesgo real

Uno de los errores habituales al contar estas historias es exagerar la pobreza inicial o convertir el camino en una fábula de superación perfecta. Musk no llegó a Tesla y SpaceX sin nada. Venía de Zip2 y PayPal, con capital, experiencia, contactos y una capacidad de atraer talento que no tiene un emprendedor medio.

Eso no le quita mérito. Lo hace más realista.

Zip2 se vendió a Compaq en 1999 por 307 millones de dólares. X.com acabó siendo parte de PayPal, y eBay compró PayPal en 2002 por 1.500 millones. Musk salió de ahí con una fortuna enorme para cualquiera. La decisión razonable habría sido diversificar, invertir y vivir muy bien.

Pero hizo otra cosa. Apostó cantidades muy grandes de su propio patrimonio a sectores donde el fracaso era probable. SpaceX parecía una locura: construir cohetes privados cuando el espacio estaba dominado por gobiernos y contratistas tradicionales. Tesla también parecía improbable: fabricar coches eléctricos cuando la industria automovilística era intensiva en capital, estaba llena de gigantes y apenas creía en ese mercado.

Ese punto me parece importante. Muchas veces confundimos “tener visión” con “decir algo ambicioso”. Pero la visión solo pesa cuando alguien compromete recursos, reputación y tiempo en una dirección que puede salir mal.

En 2008 estuvo muy cerca de salir mal.

SpaceX acumulaba tres fallos con Falcon 1. Tesla tenía problemas de caja, retrasos y una crisis financiera global encima. Musk ha contado varias veces que tuvo que repartir sus últimos recursos entre ambas empresas. Si el cuarto lanzamiento de Falcon 1 hubiese fallado, probablemente hoy contaríamos otra historia. Una más breve, más dura y menos mítica. O quizás no porque habría podido reunir más recursos para seguir intentándolo.

Pero el Falcon 1 alcanzó la órbita en septiembre de 2008. Poco después, NASA adjudicó a SpaceX un contrato de 1.600 millones de dólares para misiones de carga a la Estación Espacial Internacional. Tesla también consiguió financiación crítica. Sobrevivieron por poco.

Y aquí aparece una diferencia entre los grandes empresarios industriales y los simples vendedores de promesas: en algún momento, la realidad tiene que validar la historia.

La fábrica como examen final

En software se puede caer en una trampa: pensar que todo se arregla iterando rápido. En parte es verdad. El software permite probar, corregir, desplegar y medir con una velocidad que la industria tradicional no tenía. Pero cuando el software toca átomos, las reglas cambian.

Un coche no se escala como una app. Un cohete no se despliega como una web. Una batería no perdona una mala decisión de materiales. Un satélite no vuelve al taller si ya está en órbita.

Ahí es donde Musk se parece más a Ford que a muchos fundadores digitales. Su obsesión por la fábrica no es decorativa. Tesla aprendió, a veces a golpes, que automatizar demasiado pronto puede crear más problemas de los que resuelve. La rampa del Model 3 dejó esa lección muy clara: fabricar a escala no es ensamblar más unidades, sino construir un sistema que no colapse cuando sube el volumen.

La expresión “production hell” se hizo famosa porque sonaba dramática, pero describía algo real. Tesla tenía que demostrar que no era una empresa de prototipos caros, sino un fabricante capaz de producir miles de coches por semana. Musk durmió en la fábrica, se metió en los cuellos de botella y convirtió esa crisis en parte de su narrativa.

Aquí conviene separar dos cosas.

La primera: estar cerca del problema es una virtud. Hay directivos que gestionan desde dashboards, reuniones y capas intermedias hasta perder contacto con la realidad. En industrias difíciles, eso puede ser letal. La fábrica, el cliente, el soporte, el centro de datos o la línea de producción cuentan verdades que no siempre aparecen en un comité.

La segunda: romantizar el agotamiento es peligroso. Que un fundador duerma en la fábrica puede ser una muestra de compromiso, pero también puede indicar que el sistema depende demasiado de una persona. Una empresa madura no debería necesitar siempre un acto heroico para funcionar.

Esa tensión define buena parte del liderazgo de Musk. Es capaz de empujar límites que otros no se atreverían a tocar. Pero ese mismo estilo también puede generar desgaste, rotación, miedo, decisiones precipitadas y una cultura demasiado dependiente del fundador.

La pregunta incómoda es: ¿cuánto de ese sacrificio era necesario y cuánto era síntoma de un sistema llevado al límite? y ¿está preparando Musk sus empresas para sobrevivir sin su liderazgo?

Comparar a Musk con Edison, Ford, Jobs o Bezos ayuda, pero también engaña

Las comparaciones históricas son útiles si no las usamos para fabricar santos. Edison fue brillante, pero también agresivo defendiendo intereses y patentes. Ford revolucionó la fabricación, pero tuvo posiciones personales y políticas muy discutibles. Jobs creó productos extraordinarios, pero su estilo de gestión podía ser durísimo. Bezos construyó una de las empresas más influyentes del mundo, aunque Amazon ha sido criticada durante años por la presión laboral y su poder de mercado.

Con Musk pasa lo mismo. Sus logros son enormes, pero no obligan a comprar todo el personaje. Se puede reconocer que SpaceX cambió el sector espacial y, al mismo tiempo, cuestionar su forma de comunicar. Se puede aceptar que Tesla aceleró el coche eléctrico y, a la vez, discutir sus plazos, su cultura o algunas decisiones de gobierno corporativo. Se puede admirar la ambición industrial sin convertirla en obediencia intelectual.

De hecho, quizá esa sea una forma más sana de estudiar a estos personajes: no preguntarnos si son buenos o malos, sino qué mecanismos utilizaron para cambiar industrias y qué costes dejaron por el camino.

Esta tabla no pretende igualarlos. Solo muestra una constante: muchas personas que cambian industrias mezclan genialidad, obsesión, conflicto y coste humano. La historia suele quedarse con los productos. Las empresas viven también las cicatrices.

El dinero como marcador imperfecto

En 2026, tras la salida a bolsa de SpaceX, distintas estimaciones situaron temporalmente a Elon Musk por encima del billón de dólares de patrimonio. La cifra es casi absurda, tan grande que cuesta pensarla. Pero también es engañosa.

La mayor parte de esa riqueza no es dinero en una cuenta corriente. Es valor de mercado de participaciones en empresas, especialmente SpaceX y Tesla. Puede subir o bajar de forma violenta. De hecho, después de alcanzar ese nivel, varias estimaciones volvieron a reducir su patrimonio por la caída de las acciones.

Esto también merece una lectura. En nuestra época, la riqueza extrema no solo mide beneficios presentes. Mide expectativas. Musk vale lo que el mercado cree que sus empresas pueden llegar a ser: una plataforma espacial, una red satelital, un actor de defensa, más o menos centros de datos para IA, una empresa de IA, un fabricante de coches, un proveedor de energía, quizá algo más.

Es una valoración del futuro, no solo del presente.

Y eso abre otra pregunta: ¿hasta qué punto premiamos resultados reales y hasta qué punto premiamos narrativas convincentes sobre lo que podría pasar?

Musk domina esa mezcla como pocos. Construye cosas reales, pero también domina el relato. Ahí se parece a Jobs, aunque con otro estilo. Jobs convertía una presentación en teatro de producto. Musk convierte un plan industrial en una epopeya pública, a veces brillante y a veces caótica.

Qué puede aprender un empresario normal de todo esto

La mayoría de nosotros no vamos a fundar SpaceX, ni Tesla, ni Amazon, ni Apple. Y quizá tampoco deberíamos intentar copiar literalmente a quienes lo hicieron. El error típico de la literatura empresarial es convertir casos extremos en recetas generales.

No todo el mundo puede ni debe gestionar como Musk. No todas las empresas necesitan vivir en modo emergencia. No todos los equipos responden bien a presión constante. Y no todos los problemas se resuelven trabajando más horas.

Pero sí hay aprendizajes útiles.

El primero: estar cerca del lugar donde se crea valor. En una empresa tecnológica puede ser el código, el soporte, la infraestructura, el cliente, la operación o la venta. En una industrial será la fábrica. En una empresa de servicios puede ser el equipo que habla todos los días con el cliente. Los grandes problemas rara vez se entienden solo desde arriba.

El segundo: distinguir entre idea y sistema. Una idea buena atrae atención. Un sistema bueno genera resultados repetidos. La diferencia entre ambas cosas es enorme.

El tercero: asumir que la escala cambia la naturaleza del problema. Vender diez unidades no enseña lo mismo que vender diez mil. Atender a un cliente no enseña lo mismo que atender a mil. Lanzar un prototipo no enseña lo mismo que sostener una operación durante años.

El cuarto: no confundir sacrificio con estrategia. Trabajar mucho puede ser necesario en algunos momentos, pero no sustituye a diseñar procesos, contratar bien, delegar, medir y construir una cultura que no dependa de una sola persona.

Y el quinto: mantener criterio propio ante los mitos. Musk, como Edison, Ford, Jobs o Bezos, ofrece lecciones valiosas. Pero también advertencias.

Algunas preguntas que me deja esta historia

Me interesa más terminar con preguntas que con una conclusión cerrada, porque creo que estos perfiles no admiten una lectura simple.

¿Hasta qué punto una empresa necesita una personalidad obsesiva para romper industrias muy asentadas?

¿Es posible construir empresas tan ambiciosas sin culturas de trabajo extremas?

¿Dónde está el límite entre liderazgo exigente y desgaste innecesario?

¿Premia demasiado el mercado a quienes saben contar el futuro antes de demostrarlo por completo?

¿Europa podría producir empresarios industriales de este tipo o nuestro marco cultural, financiero y regulatorio los empuja fuera antes de tiempo?

¿Queremos más fundadores así o queremos empresas más equilibradas, aunque avancen más despacio?

Mi impresión es que Elon Musk pertenece a esa categoría rara de empresarios que no solo crean productos, sino que fuerzan a sectores enteros a moverse. Eso no lo hace perfecto. Tampoco lo hace imitable. Lo hace relevante.

Antes de los billones, antes de los titulares y antes de la discusión eterna sobre si es genio o villano, Musk aprendió una lección que ya habían entendido otros grandes constructores: una idea solo cambia el mundo cuando alguien consigue fabricarla, repetirla y sostenerla el tiempo suficiente.

La épica ayuda a contar la historia. La fábrica decide si era verdad.

La entrada Antes de los billones, Elon Musk aprendió lo mismo que Edison, Ford o Jobs: la idea no basta aparece primero en Carrero.

Un análisis independiente que circula entre usuarios avanzados y desarrolladores ha puesto números a esa sensación. Sus autores compraron varios planes de Anthropic y OpenAI, lanzaron tareas largas de programación hasta agotar los límites semanales y compararon ese consumo con lo que habría costado usando precios de API. La conclusión es llamativa: una suscripción Claude Max 20x de 200 dólares mensuales podría permitir un uso equivalente a unos 8.000 dólares al mes en API. En ChatGPT Pro 20x, también por 200 dólares, el equivalente aproximado podría llegar a 14.000 dólares.

Conviene aclarar desde el principio que esto no significa que Anthropic u OpenAI paguen internamente esos 8.000 o 14.000 dólares por cada usuario intensivo. Los precios de API incluyen margen, infraestructura, disponibilidad, producto, soporte y costes comerciales. Pero la comparación sirve para entender algo importante: la tarifa plana de la IA funciona porque la mayoría de usuarios no exprime el servicio al máximo. Si muchos empezamos a usar agentes durante horas, trabajar con repositorios completos, pedir análisis largos o automatizar tareas de desarrollo, la economía cambia.

El coste real está oculto en la suscripción

Las suscripciones siempre han funcionado con una idea parecida. Un gimnasio no espera que todos los socios entrenen dos horas al día. Una plataforma de streaming no asume que todos los usuarios van a ver contenido sin parar. Un proveedor de IA tampoco calcula su margen pensando en que cada persona agotará sus límites de uso cada semana.

La diferencia está en que una consulta a un modelo avanzado no es un contenido ya producido que se distribuye a bajo coste. Cada respuesta consume cómputo. Cada contexto largo, cada iteración de código, cada herramienta ejecutada y cada agente trabajando durante minutos u horas tiene un coste real en GPUs, memoria, red, almacenamiento, energía y operación.

A fecha de publicación, he usado como referencia aproximada el cambio del Banco Central Europeo del 12 de junio de 2026, con 1 euro equivalente a 1,1567 dólares. Eso deja 1 dólar en unos 0,8645 euros. Las cifras siguientes están redondeadas, no incluyen impuestos, comisiones ni diferencias de facturación por país, y deben leerse como una aproximación.

La tabla impresiona porque rompe la percepción de “pago una cuota y ya está”. En realidad, estamos usando un servicio de cómputo avanzado que hoy se empaqueta como suscripción para hacerlo más sencillo, más masivo y más atractivo. El problema es que el consumo no es lineal. Un usuario que pregunta cosas sueltas no se parece en nada a un desarrollador que usa agentes de código durante toda la jornada.

La clave está en la utilización media. Si la mayoría usa poco, el modelo comercial aguanta. Si cada vez más usuarios empiezan a exprimir las suscripciones para tareas largas, la tarifa plana se convierte en una subvención cruzada: los usuarios ligeros compensan a los intensivos.

API, suscripción o modelos propios: tres formas distintas de pagar

La comparación con la API ayuda a ver dónde está el coste. OpenAI publica precios para GPT-5.5 de 5 dólares por millón de tokens de entrada y 30 dólares por millón de tokens de salida en contexto corto, mientras que GPT-5.5 Pro sube a 30 dólares por millón de tokens de entrada y 180 dólares por millón de tokens de salida. Anthropic, por su parte, lista Claude Fable 5 a 10 dólares por millón de tokens de entrada y 50 dólares por millón de salida, y Claude Opus 4.8 a 5 y 25 dólares respectivamente.

Pasado a euros, el orden de magnitud se ve mejor:

Cuando uno mira estos precios entiende por qué los laboratorios separan cada vez más entre usuario final, API, planes profesionales y empresa. La suscripción sirve muy bien para adopción masiva. La API sirve para producto, integración y control de consumo. El modelo empresarial permite negociar condiciones, soporte, seguridad y límites. Son negocios distintos, aunque todos usen la misma materia prima: inferencia.

Para un usuario individual, pagar 20 o 200 dólares al mes puede ser baratísimo si la IA ahorra horas de trabajo real. Para una empresa que mete IA en procesos internos, la pregunta cambia: ¿cuánto cuesta cada tarea?, ¿qué modelo se usa?, ¿qué datos salen?, ¿qué latencia es aceptable?, ¿qué ocurre si suben precios o cambian límites?

La parte incómoda es que quizá tengamos que acostumbrarnos a pagar más por usar IA avanzada. No porque las empresas sean malas, sino porque servir inteligencia artificial de alta gama cuesta dinero. Si un modelo nos ayuda a programar, analizar contratos, revisar documentación, generar informes o automatizar tareas complejas, quizá pagar 100, 200 o 500 euros al mes no sea una barbaridad si el retorno es claro.

Lo que no parece sostenible es pensar que siempre tendremos acceso casi ilimitado a los mejores modelos del mundo por una cuota plana baja. Puede ocurrir durante un tiempo por competencia, estrategia de crecimiento y caída de costes. Pero si el uso profesional se dispara, alguien tendrá que pagar la factura.

La alternativa: modelos abiertos, infraestructura propia y más control

La otra posibilidad es que no todo pase por pagar más a OpenAI, Anthropic, Google o xAI. Cada vez tendremos más modelos abiertos o de pesos disponibles que podremos ejecutar en nuestros propios servidores, en cloud privado o en cloud público. Quizá sean más lentos. Quizá no alcancen siempre la calidad del mejor modelo propietario del momento. Pero para muchos usos serán suficientes.

Esta es una parte del debate que me interesa especialmente. No todo necesita el modelo más potente. Muchas tareas empresariales son repetitivas, internas, acotadas y medibles: clasificar documentos, extraer datos, resumir incidencias, responder sobre una base de conocimiento, revisar logs, preparar borradores, generar consultas SQL sencillas, analizar tickets o ayudar a equipos técnicos con documentación interna.

Para esos casos, un modelo abierto bien desplegado puede ser mucho más interesante que una API externa. No solo por coste. También por privacidad, cumplimiento, control operativo y soberanía. Si los datos no salen de tu entorno, reduces dependencia y puedes adaptar mejor el sistema a tus necesidades. Eso sí: no desaparece el coste. Cambia de forma.

Ejecutar IA en infraestructura propia implica pagar servidores, GPUs, almacenamiento, electricidad, refrigeración, red, administración, monitorización, actualizaciones, seguridad y tiempo técnico. En cloud público ocurre algo parecido, aunque el coste se convierte en consumo bajo demanda. En cloud privado o bare metal puedes ganar previsibilidad y control, pero necesitas dimensionar bien.

Lo interesante será elegir con cabeza. Para una tarea crítica de razonamiento complejo quizá compense usar el mejor modelo comercial disponible. Para una tarea interna de clasificación o resumen quizá baste un modelo abierto más pequeño. Para código, puede tener sentido combinar herramientas: suscripción para productividad personal, API para flujos medidos y modelos propios para tareas repetibles.

La arquitectura de IA que viene será híbrida. Igual que muchas empresas combinan cloud público, cloud privado, SaaS y sistemas on-premise, también combinarán modelos propietarios, APIs, modelos abiertos, inferencia local y servicios especializados. La pregunta no será “qué IA uso”, sino qué IA uso para cada tarea, con qué coste, bajo qué control y con qué dependencia.

La factura de la IA nos obligará a madurar

Durante la primera fase de la IA generativa, muchos hemos usado estas herramientas como si el coste de la inteligencia fuera casi invisible. Abrimos una ventana, preguntamos, iteramos, probamos y seguimos. Es normal: el producto está diseñado para que no pensemos en tokens ni en GPUs. Pero las empresas que construyan procesos reales sobre IA tendrán que mirar la factura con más cuidado.

Eso no tiene por qué ser negativo. En el mundo cloud ya pasamos por algo parecido. Primero llegó la fascinación por la elasticidad. Después llegaron las facturas inesperadas. Más tarde llegaron FinOps, observabilidad, reservas, optimización, arquitecturas híbridas y una cultura más madura de costes. Con la IA pasará algo similar.

Habrá que medir coste por tarea, no solo coste por usuario. Habrá que decidir qué modelo merece cada flujo. Habrá que cachear contexto, evitar prompts gigantes innecesarios, usar modelos pequeños cuando baste, limitar agentes, registrar consumos y comparar resultados. La eficiencia volverá a ser una virtud técnica, no una obsesión de contables.

También habrá que aceptar que la Inteligencia Artificial buena puede costar dinero. Nos hemos acostumbrado demasiado rápido a una abundancia artificial. Si una herramienta nos ahorra trabajo real, reduce errores o permite crear productos que antes no eran viables, pagar más puede tener sentido. Lo importante es no quedar atrapados en una dependencia ciega de tarifas planas que mañana pueden cambiar.

Por eso mi conclusión no es “todo será más caro” ni “hay que huir de las grandes plataformas”. Mi conclusión es más práctica: conviene prepararse para un mundo en el que la IA tendrá varios precios, varias calidades y varias formas de despliegue. A veces pagaremos más por el mejor modelo. A veces usaremos modelos abiertos más lentos, pero suficientes. A veces nos interesará la API. A veces preferiremos infraestructura propia.

La tarifa plana ha sido magnífica para descubrir la IA. Para producción, estrategia y soberanía tecnológica, necesitaremos algo más serio: costes claros, modelos alternativos, control de datos y capacidad para decidir dónde se ejecuta cada parte de nuestra inteligencia artificial.

Preguntas frecuentes

¿Las suscripciones de IA están subvencionadas?

En cierto modo, sí para los usuarios más intensivos. El modelo funciona porque muchos usuarios pagan y no agotan todos los límites. Si se compara el consumo máximo con precios de API, algunas suscripciones pueden permitir un uso equivalente muy superior al precio mensual.

¿Significa esto que OpenAI o Anthropic van a subir precios?

No necesariamente, pero sería razonable esperar más segmentación. Los modelos más potentes, los agentes largos, las ventanas de contexto grandes o las funciones profesionales podrían quedar cada vez más asociadas a planes superiores, créditos, API o contratos de empresa.

¿Tiene sentido ejecutar modelos open source en servidores propios?

Sí, en muchos casos. Puede ser interesante para datos sensibles, costes previsibles, cumplimiento normativo o tareas internas repetibles. Pero no es gratis: exige hardware, operación, seguridad, mantenimiento y capacidad técnica.

¿Qué estrategia parece más razonable para una empresa?

Usar una combinación de opciones. Modelos comerciales para tareas complejas, API cuando haga falta integración y medición, modelos abiertos para usos internos repetibles, y una arquitectura que permita cambiar de proveedor o de modelo sin rehacerlo todo.

La entrada La tarifa plana de la IA no durará para siempre, y quizá tampoco debería aparece primero en Carrero.

Yo no creo que esto sea el fin de los programadores. Sería demasiado simple. Lo que sí creo es que estamos entrando en una democratización enorme del desarrollo de software. Y esa democratización va a afectar a todos los niveles: al profesional senior, al desarrollador junior, al emprendedor, al administrador de sistemas, al creador independiente y a cualquiera que tenga una idea clara pero no siempre el tiempo, el equipo o la energía para convertirla en una aplicación real.

En mi caso lo he vivido de una forma muy personal. Yo empecé a programar en otra época, con Turbo Pascal, Turbo C, Delphi y aquellas herramientas que te obligaban a entender muy bien la máquina, el compilador, las librerías y tus propios límites. Después la vida profesional te lleva por otros caminos: empresas, infraestructura, cloud, gestión, ventas, marketing, proyectos, clientes, equipos. No dejas de tener criterio técnico, pero ya no estás todos los días escribiendo código como antes.

Y, de repente, la IA me ha devuelto parte de esa capacidad de programación con menos esfuerzo.

No porque el modelo haga magia. No porque uno le pida “hazme una app” y aparezca un producto serio. Sino porque reduce muchísimo el coste de volver a intentarlo. Te permite recuperar velocidad, preguntar, contrastar, probar enfoques, recordar patrones, revisar errores y avanzar. En mi caso, eso se ha traducido en aplicaciones para iOS y Mac como Mbox Viewer Pro, FlarePurge, DocProtect o FitBono; en herramientas para Windows como FlarePurge; y en proyectos open source como mboxshell, pensado para abrir ficheros MBOX de copias de correo.

También me ha permitido algo que me interesa casi tanto como crear cosas nuevas: rescatar cosas viejas.

La IA como palanca para recuperar software olvidado

Una de las partes más bonitas de esta etapa no está en crear otra aplicación de moda, sino en poder rescatar software, formatos y proyectos que parecían condenados al olvido.

Durante los últimos meses he podido refactorizar aplicaciones antiguas y obsoletas como bitadir.com, programacion.net o glosarium.com. Proyectos que tenían historia, utilidad o valor personal, pero que arrastraban código antiguo, dependencias viejas, estructuras heredadas y decisiones técnicas de otra época. Antes, enfrentarse a eso requería una cantidad de tiempo difícil de justificar. Hoy, con IA, se puede revisar, entender, reordenar y modernizar con una velocidad muy distinta.

No es automático. Hay que saber qué tocar y qué no tocar. Hay que probar. Hay que desconfiar. Hay que leer el código. Pero la barrera baja mucho.

El ejemplo más personal quizá sea UnQuantum, el proyecto open source que he lanzado en GitHub para rescatar el formato de compresión Q (Quantum), aquel compresor de MS-DOS que me encantaba. Un formato de los años 90, creado originalmente por David Stafford en Cinematronics, que usaba LZ77 con codificación aritmética y que tuvo relación histórica con tecnologías como Microsoft Cabinet. Lo he reimplementado en Rust para sistemas modernos, con soporte multiplataforma para Linux, macOS y Windows.

Hace años, un proyecto así habría sido una mezcla de nostalgia, documentación dispersa, ingeniería inversa y muchas horas de prueba. Ahora sigue haciendo falta todo eso, pero la IA ayuda a ordenar el proceso. Te permite entender mejor especificaciones antiguas, comparar implementaciones, escribir tests, estructurar el proyecto, revisar errores de portabilidad y documentar lo que estás haciendo.

Esto no es “vibe coding” entendido como soltar instrucciones y confiar ciegamente. Es otra cosa: usar la IA como una extensión de tu memoria técnica, de tu capacidad de análisis y de tu velocidad de ejecución.

La IA no destruye el desarrollo, cambia su precio

Hace unos días escribí en este blog sobre una idea que sigo viendo muy clara: la IA no está destruyendo empleo, está cambiando el precio del trabajo. Aplicado al desarrollo de software, ocurre algo parecido. La IA no elimina el software. Reduce el coste de producirlo, modificarlo, probarlo y mantenerlo. Y cuando algo baja mucho de precio, muchas veces no se usa menos. Se usa mucho más.

Si crear una utilidad interna costaba dos semanas y ahora cuesta dos tardes, se crearán más utilidades. Si refactorizar una web antigua costaba demasiado y ahora es asumible, se rescatarán más proyectos. Si construir una app de nicho no compensaba económicamente y ahora se puede lanzar con menos esfuerzo, aparecerán más aplicaciones pequeñas, concretas y personales.

Esto no significa que todo vaya a ser bueno. De hecho, puede pasar lo contrario: tendremos más software mediocre, más código generado sin entender, más dependencias innecesarias, más apps que funcionan en una demo pero no aguantan un uso real, más problemas de seguridad y más proyectos abandonados porque nadie sabe mantener lo que la IA generó.

Pero esa parte no invalida el cambio. Solo nos recuerda que el desarrollo nunca fue solo escribir código.

Programar es entender el problema. Es organizar. Es decidir. Es probar. Es pensar en el usuario. Es saber cuándo una solución es demasiado compleja. Es saber cuándo una librería no merece la pena. Es entender qué datos manejas, dónde los guardas, qué pasa si algo falla, cómo se actualiza, cómo se firma, cómo se distribuye y cómo se mantiene.

La IA acelera mucho la escritura de código. Pero no sustituye el criterio.

Quien sepa programar tendrá más ventaja, no menos

Aquí es donde discrepo de los titulares más alarmistas. No veo un futuro donde “nadie necesite programadores”. Veo un futuro donde mucha más gente podrá crear software básico o intermedio, y donde los buenos programadores serán todavía más valiosos.

Porque cuando cualquiera puede producir código, la diferencia estará en producir buen software.

Un desarrollador con criterio podrá hacer más. Mucho más. Podrá revisar propuestas de la IA, detectar errores sutiles, pedir mejores alternativas, dividir tareas, crear tests, diseñar arquitectura, automatizar despliegues, documentar decisiones y convertir un prototipo en algo mantenible.

Una persona sin base técnica también podrá crear cosas. Y eso es positivo. Pero dependerá mucho más del modelo. Si algo falla, quizá no sepa por qué. Si el proyecto crece, quizá no sepa cómo ordenarlo. Si aparece una vulnerabilidad, quizá no la vea. Si una dependencia queda abandonada, quizá no entienda el riesgo.

La diferencia entre “pedir código” y “construir software” va a ser cada vez más importante.

Y esto afecta también a las empresas. Una compañía que use IA solo para despedir desarrolladores probablemente acabará con deuda técnica más rápida y más barata. Una compañía que use IA para multiplicar a sus equipos técnicos, documentar mejor, reducir tareas repetitivas, probar más hipótesis y lanzar productos que antes no eran viables puede ganar muchísimo.

La pregunta buena no es: “¿cuánta gente puedo ahorrar con IA?”.

La pregunta buena es: “¿qué puedo construir ahora que antes no podía?”.

Claude Fable 5 y el problema de los modelos demasiado potentes

Claude Fable 5 representa muy bien esta nueva fase. Anthropic lo presenta como un modelo de clase Mythos para uso general, con capacidades avanzadas en desarrollo de software, trabajo técnico, investigación y tareas largas. Pero también llega con salvaguardas importantes. En determinadas áreas sensibles, como ciberseguridad, biología, química o desarrollo de modelos frontera, el sistema puede limitar respuestas o redirigir consultas a otro modelo más controlado, como Claude Opus 4.8.

Esta parte me parece muy relevante, porque muestra una contradicción que vamos a ver cada vez más.

Por un lado, queremos modelos mejores. Queremos que programen mejor, que entiendan mejor, que encuentren errores, que revisen seguridad, que ayuden a investigar, que automaticen tareas complejas. Por otro lado, cuando el modelo es demasiado bueno en ciertas áreas, aparece el miedo razonable a que también sirva para atacar sistemas, explotar vulnerabilidades, ayudar en usos peligrosos o transferir capacidades a competidores.

Ahí empieza una nueva etapa: modelos muy potentes, pero con puertas internas.

No pagas solo por inteligencia artificial. Pagas por una inteligencia artificial condicionada por políticas del proveedor. Algunas restricciones tendrán sentido por seguridad. Otras pueden mezclarse con intereses comerciales. Y otras serán simplemente incómodas para quien quiera usar el modelo como herramienta técnica de alto nivel.

Esto también obliga a pensar en dependencia. Si basas tus flujos de desarrollo en un único modelo cerrado, aceptas sus cambios de política, sus límites, sus precios y sus decisiones. Igual que aprendimos con el cloud que no conviene depender de un único proveedor sin plan de salida, tendremos que aprender lo mismo con la IA.

El riesgo de la programación sin comprensión

La democratización del desarrollo será positiva, pero no inocente. Vamos a ver a mucha gente crear software sin saber realmente cómo funciona. Y eso tiene riesgos.

El primero es la falsa sensación de control. Si la aplicación arranca, parece que todo va bien. Pero quizá no gestione bien errores, no valide entradas, no tenga tests, exponga datos, use mal permisos o dependa de una librería insegura.

El segundo es la deuda técnica generada a gran velocidad. Antes una mala arquitectura tardaba semanas en crecer. Ahora puedes crear una mala arquitectura en una tarde.

El tercero es la pérdida de aprendizaje. Si los perfiles nuevos solo piden soluciones y nunca entienden por qué funcionan, no desarrollan criterio. Esto me preocupa especialmente en los juniors. La IA puede ser un tutor extraordinario si se usa bien, pero también una muleta peligrosa si sustituye el esfuerzo de comprender.

El cuarto es la homogeneización. Si todo el mundo usa los mismos modelos para generar las mismas soluciones, veremos patrones repetidos, interfaces parecidas, arquitecturas copiadas y errores comunes a gran escala.

Por eso creo que la nueva alfabetización técnica no consistirá solo en aprender a programar. Consistirá en aprender a trabajar con IA sin abdicar del criterio.

Del programador que escribe código al creador que dirige sistemas

La imagen clásica del programador era alguien escribiendo líneas de código durante horas. Esa figura no desaparece, pero se transforma. Cada vez será más importante saber dirigir sistemas: modelos, agentes, repositorios, tests, despliegues, documentación, APIs, permisos, datos y usuarios.

El valor se desplazará desde “sé escribir esta función” hacia “sé convertir esta necesidad en un sistema que funcione”.

Eso favorece a perfiles híbridos. Personas que entienden negocio y tecnología. Administradores de sistemas que saben dónde duele una infraestructura. Emprendedores que conocen un problema de nicho. Periodistas capaces de automatizar análisis de documentos. Abogados que entienden procesos repetitivos. Médicos o investigadores que saben qué herramienta les falta. Y, por supuesto, programadores que saben pensar más allá del código.

Ahí veo una oportunidad enorme.

No todos crearán grandes empresas de software. Pero sí veremos muchas más herramientas pequeñas. Más proyectos personales. Más utilidades internas. Más rescates de software antiguo. Más automatización local. Más aplicaciones que antes no existían porque no compensaba pagar su desarrollo.

En ese mundo, el software se vuelve más personal. Más cercano. Más hecho a medida.

Mi conclusión personal

Claude Fable 5 no es el final de los programadores. Es una señal de que el desarrollo de software se está abriendo. Como lo hicieron en su día los ordenadores personales, los lenguajes visuales, la web, WordPress, GitHub o el cloud. Cada salto redujo una barrera. Cada salto creó ruido. Y cada salto hizo más valioso el criterio de quienes sabían usar bien la herramienta.

Yo, que venía de Turbo Pascal, Turbo C y Delphi, he podido volver a programar de una forma que hace años me habría parecido difícil de encajar en mi día a día. He podido crear aplicaciones nuevas, refactorizar proyectos antiguos, recuperar formatos olvidados y lanzar herramientas open source. Eso no me convierte en un ingeniero de software moderno a tiempo completo. Pero sí demuestra algo importante: la IA devuelve capacidad de creación a personas que ya tenían experiencia, ideas y criterio, aunque no estuvieran metidas cada día en el último framework.

Y eso va a cambiar muchas cosas.

No se nos viene encima un mundo sin programadores. Se nos viene encima un mundo con muchos más creadores de software. Algunos serán buenos. Otros harán desastres. Los mejores serán quienes combinen IA con fundamentos: arquitectura, seguridad, producto, datos, pruebas, experiencia de usuario y sentido común.

La programación no muere. Se desplaza.

Antes la pregunta era: “¿sabes escribir código?”.

Ahora empieza a ser: “¿sabes dirigir la construcción de algo útil?”.

Y ahí, quien sepa programar, organizar y pensar seguirá teniendo una ventaja enorme.

Preguntas frecuentes

¿Claude Fable 5 puede sustituir a los programadores?

No creo que sustituya a los buenos programadores. Sí puede automatizar muchas tareas de desarrollo y permitir que más personas creen software, pero el criterio técnico seguirá siendo decisivo.

¿Qué cambia para quienes aprendieron a programar hace años?

La IA reduce la barrera para volver. Permite recuperar velocidad, entender nuevas herramientas, refactorizar proyectos antiguos y crear aplicaciones modernas sin tener que empezar desde cero en cada tecnología.

¿Por qué saber programar seguirá siendo importante?

Porque generar código no es lo mismo que construir software fiable. Hay que revisar, probar, entender arquitectura, seguridad, datos, despliegues y mantenimiento.

¿Qué riesgo tiene crear software con IA?

El principal riesgo es aceptar código sin entenderlo. Eso puede generar deuda técnica, errores de seguridad, dependencia del proveedor de IA y aplicaciones difíciles de mantener.

PD: Igual el modelo Claude Fable 5 te lo encuentras cerrado a petición del Gobierno de los EEUU porque «es peligroso», como si no hubiese muchas más cosas peligrosas. Aunque claro peligroso para que y para quien…

La entrada Claude Fable 5 y la nueva programación: del Turbo Pascal a la IA aparece primero en Carrero.

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

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

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

La paradoja de Jevons aplicada al trabajo intelectual

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

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

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

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

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

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

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

Datos que invitan a frenar el alarmismo

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

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

No son datos de euforia, pero tampoco de colapso.

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

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

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

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

Ejemplos donde la eficiencia aumentó la demanda

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mi lectura personal

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

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

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

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

Ahí está la parte interesante.

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

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

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

Los PCs no acabaron con la oficina. La transformaron.

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

Preguntas frecuentes

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

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

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

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

Fuentes:

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

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

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

Lo que se pudo fabricar mejor se volvió barato

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

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

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

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

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

Lo que exige tiempo humano se encareció

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

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

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

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

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

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

La experiencia se convirtió en estatus

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

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

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

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

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

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

La vivienda es el caso más doloroso

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

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

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

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

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

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

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

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

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

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

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

Preguntas frecuentes

¿Qué significa que vivimos dentro de dos inflaciones?

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

¿Qué es la enfermedad de costes de Baumol?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Europa ve el riesgo, pero llega tarde

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

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

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

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

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

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

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

La comodidad como jaula

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

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

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

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

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

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

Qué deberíamos hacer desde Europa

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

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La confianza es una infraestructura

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

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

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

Fuentes:

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

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

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

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

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

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

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

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

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

La IA está acelerando el descubrimiento de fallos antiguos

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

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

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

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

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

La escalada local ya no es un riesgo menor

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

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

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

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

Qué deberíamos hacer desde ya

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

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

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

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

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

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

Lo que viene no será tranquilo

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

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

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

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

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

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

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

Bloquear dominios es una cosa; bloquear IPs compartidas es otra

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

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

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

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

¿Esto es legal?

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

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

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

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

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

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

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

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

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

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

Internet no puede gestionarse a martillazos

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

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

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

¿Qué ha ocurrido con Redsys?

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

¿A quién afecta este tipo de bloqueo?

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

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

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

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

Los bugs peligrosos no siempre hacen ruido

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

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

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

Esto no va solo de navegadores

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

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

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

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

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

La IA no sustituye al equipo de seguridad, lo multiplica

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

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

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

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

La ventaja no puede quedar solo en manos de los gigantes

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

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

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

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

La ventana de parcheo se está encogiendo

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

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

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

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

Una oportunidad para hacer Internet más seguro

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

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

La nube ya nos enseñó esta lección

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

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

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

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

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

Despedir personas para comprar tokens no siempre es una estrategia

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

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

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

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

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

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

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

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

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

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

Necesitamos AI FinOps antes de que la factura explote

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

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

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

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

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

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

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