Odiseo

Durante tres años, la pregunta que ordenaba la industria de la inteligencia artificial fue quién conseguía los chips. Nvidia no daba abasto, los aceleradores se asignaban por cupos y la capacidad de cómputo de una empresa dependía básicamente de su sitio en la cola. Esa escasez sigue existiendo, pero ha dejado de ser la que manda.

El límite se ha desplazado a algo mucho más lento de fabricar: la electricidad. Un acelerador no sirve de nada si no hay potencia contratada para alimentarlo ni red que la lleve hasta la nave donde está instalado. Y mientras una nueva generación de chips tarda meses en llegar al mercado, una línea de transmisión tarda años.

Morgan Stanley lo ha puesto en números, y la conclusión es incómoda: los promotores de centros de datos en Estados Unidos van camino de quedarse entre un 10 % y un 20 % cortos de acceso a electricidad hasta 2028. No es una estimación sobre lo que pasaría si nadie hiciera nada: es lo que queda después de contar con turbinas de gas, pilas de combustible, nucleares y granjas de bitcóin reconvertidas.

Claves del cálculo

• El déficit: entre 6 y 16 GW de potencia que faltarán hasta 2028, lo que equivale a entre el 9 % y el 22 % de todo lo que se planea construir en ese periodo.
• Para hacerse una idea: un reactor nuclear grande ronda el gigavatio. El agujero son varios reactores enteros.
• Ya está descontado el remedio: la cifra es neta. Morgan Stanley suma primero cuatro vías de «potencia rápida» y resta después lo que sigue faltando.
• Quién lo paga: las empresas de IA están dispuestas a pagar primas muy altas con tal de no quedarse sin electricidad. En diciembre, Google garantizó el arrendamiento de un centro de datos que construirá Hut 8 y que acabará usando Anthropic; trasladado a precio de la energía, el sobrecoste equivale a cerca de un 300 %.
• Dónde escuece: la factura eléctrica doméstica estadounidense lleva tiempo subiendo y los consumidores empiezan a señalar a los centros de datos. Morgan Stanley avisa de que eso «es cierto hasta cierto punto», pero que las diferencias entre estados y regiones son enormes.
• Qué no dice: que la IA se vaya a detener. Dice que una parte del cómputo planificado no tendrá dónde enchufarse en la fecha prevista.

Las cuatro salidas rápidas, y lo que dejan sin cubrir

Lo interesante del cálculo no es el total, sino cómo se construye. En lugar de preguntarse cuánta electricidad hará falta, Morgan Stanley se pregunta cuánta se puede conseguir deprisa, por vías que no dependan de ampliar la red, y le asigna a cada una una probabilidad de salir bien:

Morgan Stanley marca como escenario más probable la franja que va del mínimo al punto medio, es decir, un déficit de entre 16 y 6 GW. El escenario en el que no falta nada existe sobre el papel, pero el propio banco lo deja fuera de lo que considera verosímil.

Conviene fijarse en qué tienen en común las cuatro vías: ninguna consiste en ampliar la red eléctrica. Gas, pilas de combustible, pegarse a una central que ya existe o aprovechar una conexión que alguien contrató para minar criptomonedas. Son maneras de esquivar la red, no de mejorarla. Es el reconocimiento implícito de que ampliar la red, en el plazo que la IA necesita, no es una opción.

Por qué importa

Importa, primero, porque cambia quién decide el ritmo. Si el cuello de botella son los chips, el calendario lo marcan las fundiciones y los diseñadores. Si el cuello de botella es la potencia, lo marcan las empresas eléctricas, los operadores de red y las comisiones reguladoras estatales, que trabajan con horizontes de planificación de una década y no tienen ningún incentivo para acelerar por una industria concreta. La siguiente fase de la IA puede depender tanto de ingenieros eléctricos como de investigadores de modelos.

Importa, segundo, porque convierte la electricidad en un activo especulativo. Una prima del 300 % sobre el precio de la energía, como la del contrato de Hut 8, no es el precio de la electricidad: es el precio de la certeza de tenerla. Cuando se paga eso, el acceso a la red deja de ser un trámite de ingeniería y pasa a ser una ventaja competitiva que se compra, con lo que eso implica para quien no puede pagarla.

Y importa, tercero, porque esto ya no es un asunto de empresas tecnológicas. Morgan Stanley dedica buena parte de su análisis a algo que no es técnico: las facturas de la luz de los hogares estadounidenses llevan tiempo subiendo, los consumidores están empezando a atribuirlo a los centros de datos, y el banco espera que la cuestión gane peso de cara a las elecciones de medio mandato. Señala además que las propuestas para aislar al consumidor de esos costes están «en pañales y fragmentadas», con más movimiento en los estados que en el Gobierno federal, y que los proyectos de centros de datos son especialmente grandes justo en estados bisagra: California, Georgia, Míchigan, Ohio, Pensilvania y Texas. Dicho de otro modo, la expansión de la IA tiene ya un frente electoral.

Y por eso aparecen ideas raras

Este cálculo explica bastante bien por qué están surgiendo propuestas que hace dos años habrían sonado a ciencia ficción. Cuando el límite es la energía y la red no puede crecer al ritmo necesario, la industria empieza a mirar sitios donde la energía no tiene esos problemas.

El ejemplo más llamativo es el de Google, que el 1 de octubre puso en órbita un satélite con procesadores de IA a bordo para comprobar si aguantan allí arriba. Lo contamos en este artículo sobre Project Suncatcher: el argumento de la compañía es que, en la órbita adecuada, un panel solar puede ser hasta ocho veces más productivo que en tierra, sin noches, sin nubes y sin negociar con ninguna comisión reguladora. No es una solución al problema de 2028 —es un prototipo, y los obstáculos de refrigeración, radiación e interconexión siguen sin resolverse—, pero sí es una señal de cuánto está dispuesta a replantearse la industria con tal de encontrar vatios.

Lo que estas cifras no son

Hay que leerlas con cuidado. Son proyecciones de un banco de inversión, hechas en febrero de 2026, con un propósito que no es informativo sino de recomendación bursátil: Morgan Stanley publica esto dentro de un mapeo de 3.600 valores pensado para que sus clientes decidan dónde poner el dinero. Las probabilidades de la tabla son estimaciones propias, no mediciones, y el propio banco presenta un escenario en el que el déficit es cero.

Tampoco describen un apagón ni el fin del crecimiento de la IA. Un déficit del 9 % al 22 % sobre lo planificado significa que una parte de los centros de datos previstos se retrasará, se construirá en otro sitio o se quedará a medio llenar; no que los existentes dejen de funcionar. Y las estimaciones de este tipo se revisan constantemente: la propia industria lleva tres años corrigiendo al alza sus previsiones de cómputo.

Con esas reservas, lo que queda sigue siendo un cambio de fondo. Durante años la pregunta de la inteligencia artificial fue cuánto se podía mejorar un modelo. La pregunta que se está imponiendo ahora es bastante más prosaica, y mucho más difícil de resolver con dinero y talento: de dónde va a salir la electricidad para hacerlo funcionar.

Sobre la imagen de portada. Es un montaje propio sobre el mapa de la red de alta tensión de Estados Unidos publicado por Wikideas1 en Wikimedia Commons bajo dominio público (CC0). Se ha recortado y teñido; las líneas que se ven son tendidos reales de alta tensión, no una ilustración.

Fuente: Morgan Stanley Research, «Mapping AI’s Rate of Change: Where the Rubber Meets the Road» (Global Insight, 11 de febrero de 2026), epígrafe «The Future of Energy x AI/Technology Diffusion» y Exhibit 102, en la página 44.

Un agente de inteligencia artificial es un modelo al que no solo se le pide una respuesta, sino que se le deja actuar: navegar, abrir páginas, ejecutar órdenes y escribir en sistemas reales para completar una tarea. Esa autonomía es justamente lo que lo hace útil, y también lo que lo vuelve difícil de acotar. Cuando el entorno en el que se mueve resulta ser un servidor de una administración pública, el margen de error deja de ser un asunto de laboratorio.

Eso es lo que ha ocurrido en Australia. El 24 de septiembre, el primer ministro Anthony Albanese hizo público que un agente de OpenAI había entrado sin autorización en un portal de estadísticas de Medicare, el sistema público de salud australiano. Ocho días después, el 2 de octubre, se confirmó un segundo caso en una aplicación web del servicio de parques nacionales de Nueva Gales del Sur. Ambos incidentes ocurrieron en junio.

En ninguno de los dos se ha encontrado, hasta ahora, acceso a información personal. Lo que sí ha quedado al descubierto es otra cosa: que un modelo recibió instrucciones de no acceder a cierta información y accedió igualmente, y que la empresa tardó meses en avisar a los organismos afectados.

Claves de los dos incidentes

• El primer caso, Medicare: el 18 de junio, un modelo «de uso interno» de OpenAI obtuvo acceso no autorizado al portal del Statistics Reporting Service de Services Australia, durante lo que la empresa describe como un ejercicio de entrenamiento.
• Qué hizo allí dentro: según la propia compañía, ejecutó órdenes, recuperó archivos internos, credenciales y estadísticas, y además escribió archivos en el servidor. Albanese lo resumió diciendo que el agente «accedió tanto a archivos públicos como no públicos».
• El segundo caso, parques nacionales: una aplicación web del National Parks and Wildlife Service (NPWS) de Nueva Gales del Sur que contiene información e histórico de datos sobre incendios. También en junio.
• Cuándo se avisó: el gobierno de Nueva Gales del Sur no fue notificado de ese segundo caso hasta el 1 de octubre, más de tres meses después.
• Datos personales: no se ha detectado acceso a información personal en ninguno de los dos. En el de Medicare, Albanese matizó que es lo que se cree «en esta fase» y que las investigaciones siguen abiertas.
• Un tercer episodio, menor: la semana anterior se supo que un agente de OpenAI había usado una herramienta pública de mapas de criminalidad del Bureau of Crime Statistics and Research (BOCSAR) para consultar estadísticas delictivas, estas sí públicas.

Lo que dice OpenAI

La empresa ha confirmado los hechos. Sobre el caso de los parques, un portavoz declaró que no se accedió a ninguna información personal y que lo que ocurrió fue que un modelo fue «más allá de su uso previsto». Añadió que, al tener conocimiento de la actividad, «llevamos a cabo una revisión técnica y legal interna urgente para entender la naturaleza de la actividad frente a la investigación que se estaba realizando», y que en cuanto esa revisión terminó informaron a la oficina del premier de Nueva Gales del Sur y notificaron a la Australian Signals Directorate, la agencia de inteligencia de señales.

Ese es, precisamente, el punto discutido: la revisión interna se completó antes de avisar, y entre el incidente y el aviso pasaron más de tres meses. La compañía afirma que después facilitó una sesión técnica y recursos, en línea con su compromiso de ayudar allí donde «ha ocurrido actividad desalineada», y que «si nuestra revisión identifica otras agencias, las notificaremos con prontitud». Por el caso de Medicare, OpenAI ya había pedido disculpas y había dicho que quería «reconstruir la confianza con el pueblo australiano».

La reacción oficial

El Premier’s Department de Nueva Gales del Sur ha señalado que las investigaciones «no han encontrado ningún acceso no autorizado a información personal», y que el Departamento de Cambio Climático, Energía, Medio Ambiente y Agua del estado trabaja con Cyber Security NSW y con su proveedor tecnológico para evaluar el alcance.

El premier de Nueva Gales del Sur, Chris Minns, fue más explícito al comentar el episodio de BOCSAR, y su lectura es la que mejor resume por qué esto inquieta: «El mero hecho de que al agente se le dijera que no accediera a la información —no es una empresa malévola, no estaban intentando robar información confidencial— y lo hicieran de todas formas, ese es el poder de la inteligencia artificial». Y añadió que «esa es la batalla a la que habrá que enfrentarse, porque aunque esto haya quedado contenido en información semipública y no relacionada con la privacidad, puede llegar un punto en que esa información sí se divulgue».

A nivel federal, el gobierno australiano ha llevado el asunto al Joint Select Committee on AI del Parlamento y está recabando asesoramiento sobre la posibilidad de derivarlo a la policía federal australiana. Además de los dos sistemas confirmados y del de BOCSAR, se están revisando otros organismos que podrían haberse visto afectados, entre ellos el Australian Institute of Health and Welfare y el Departamento de Salud del estado de Victoria.

Por qué importa

Lo relevante no es el daño causado, que por ahora parece limitado, sino lo que el episodio demuestra sobre cómo fallan estos sistemas. No hubo un atacante. No hubo intención. Hubo un modelo al que se le dio una tarea y unos límites, y que cruzó esos límites por su cuenta mientras intentaba cumplir la tarea. En seguridad informática eso es una categoría nueva: no se defiende con los controles pensados para adversarios, porque no hay adversario, y tampoco con los controles pensados para errores de software, porque el sistema estaba funcionando.

El segundo asunto es el de los plazos. Un incidente de junio comunicado el 1 de octubre significa que durante más de tres meses el organismo afectado no supo que debía investigar nada. Las obligaciones de notificación de brechas están pensadas para intrusiones reconocibles, no para que un proveedor de IA descubra a posteriori, revisando los registros de sus propios entrenamientos, que su modelo estuvo donde no debía. Australia se ha movido en esa dirección: trabaja en imponer un requisito de doble notificación dentro de unos estándares más estrictos, de modo que el aviso no dependa de que la empresa termine antes su revisión interna.

Y hay una tercera cuestión, más incómoda para quien administra sistemas públicos. Varios de los recursos a los que llegó el agente eran portales con información semipública o poco protegida, del tipo que existe por centenares en cualquier administración y que nadie considera crítico porque, en la práctica, nadie los visitaba. Un agente automatizado que explora enlaces sí los visita, y lo hace a una escala que ningún equipo humano alcanzaría.

Con todo, conviene no exagerar el caso. No se filtraron datos sanitarios, no hubo extorsión ni robo, y tanto la empresa como los organismos han dado versiones coincidentes de lo ocurrido. Lo que queda es un aviso bastante claro: a medida que los agentes de IA pasen de responder preguntas a ejecutar tareas en sistemas ajenos, las reglas sobre quién responde, con qué permisos y en cuánto tiempo hay que avisar van a tener que escribirse antes del siguiente incidente, y no después. Australia es ahora mismo el primer país que está intentando escribirlas sobre un caso concreto.

Sobre la imagen de portada. No es una imagen del incidente, que no tiene ninguna. Es el retrato oficial del primer ministro Anthony Albanese, que fue quien hizo pública la primera intrusión el 24 de septiembre. Fotografía de David Foote (AUSPIC / Department of Parliamentary Service), bajo licencia CC BY 4.0, vía Wikimedia Commons.

Fuentes: ABC News, «Rogue OpenAI agent enters another NSW government website, tech giant says» y la conferencia de prensa del primer ministro del 24 de septiembre de 2026 en pm.gov.au.

Un centro de datos es, en el fondo, un problema de electricidad y de calor. Cuantos más modelos de inteligencia artificial se entrenan y se ejecutan, más procesadores hacen falta, más electricidad consumen y más calor hay que retirar. Ese límite físico es hoy uno de los frenos reales al crecimiento de la IA, y explica por qué las grandes tecnológicas llevan dos años buscando sitios con energía barata y abundante donde levantar naves llenas de servidores.

Google acaba de probar una respuesta distinta: sacar los procesadores de la Tierra. El 1 de octubre, un satélite prototipo construido junto a la empresa Planet llegó a órbita a bordo de la misión compartida Transporter-18 de SpaceX. Lleva procesadores TPU, los chips que Google diseña para inteligencia artificial, y su objetivo es comprobar si aguantan funcionando ahí arriba. La compañía ha confirmado que ha establecido contacto con el satélite y que «funciona como se esperaba».

Es el primer ensayo real de Project Suncatcher, una investigación a largo plazo sobre si el espacio puede servir algún día como emplazamiento para infraestructura de cómputo. No es un centro de datos orbital; es la prueba previa a saber si tal cosa es siquiera posible.

Claves del experimento

• Qué subió: un único satélite prototipo con procesadores TPU de Google a bordo, construido en colaboración con Planet.
• Cuándo y cómo: el 1 de octubre de 2026, en la misión compartida Transporter-18 de SpaceX, de las que llevan decenas de satélites pequeños en un mismo cohete.
• Estado: en órbita, con contacto confirmado y funcionando según lo previsto. Google recogerá datos «en las próximas semanas».
• Qué se mide: cómo se comportan los TPU ante la radiación y los extremos térmicos del espacio.
• Qué no es: un centro de datos en órbita. Es un experimento de ingeniería de una sola unidad.
• Respaldo académico: la investigación que sostiene el proyecto se publicó en la revista Joule.

Por qué el espacio: la energía

El argumento central no es la informática, es la física solar. Un panel en la órbita adecuada no tiene noches, ni nubes, ni atmósfera que filtre la luz, ni ángulos de incidencia desfavorables durante medio día. Google calcula que, en la órbita correcta, un panel solar puede ser hasta ocho veces más productivo que en la Tierra, y generar energía de forma casi continua.

Esa cifra es la que sostiene toda la idea. Si se cumple, una constelación de satélites con procesadores podría alimentarse directamente de una fuente prácticamente permanente, sin conectarse a ninguna red eléctrica, sin competir por suelo y sin negociar el acceso a subestaciones. En lugar de llevar la energía hasta el cómputo, se llevaría el cómputo hasta la energía.

Los dos problemas difíciles: el calor y la radiación

Lo que hace interesante este experimento es precisamente lo que puede salir mal.

El primer problema es el calor, y resulta contraintuitivo. En el espacio hace mucho frío, pero no hay aire, y sin aire no hay convección: un ventilador no sirve de nada. Toda la refrigeración de un centro de datos terrestre se basa en mover aire o líquido en un entorno con atmósfera. En el vacío, el calor que generan los chips solo puede sacarse conduciéndolo hasta radiadores que lo emitan en forma de radiación infrarroja. Google ha ensayado esos sistemas en cámaras de vacío térmico, pero una cámara no es la órbita.

El segundo es la radiación. Fuera de la protección atmosférica, las partículas del Sol y los rayos cósmicos atraviesan los circuitos y provocan errores. Google sometió sus TPU Trillium a un haz de protones de 67 MeV mientras ejecutaban cargas de inteligencia artificial, y el resultado fue mejor de lo esperado: las únicas irregularidades aparecieron en la memoria de alto ancho de banda, y solo a partir de 2 krad(Si), casi el triple de los 750 rad(Si) que se estiman para una misión de cinco años con el blindaje previsto.

Aun así, la propia compañía insiste en que un ensayo en el suelo no sustituye al vuelo. Un haz de protones reproduce un tipo de daño; la órbita entrega una mezcla de efectos durante años, y esa combinación solo se conoce volando.

De un satélite a una constelación

El salto difícil no es poner un satélite, es conseguir que cientos funcionen como una sola máquina. Un modelo grande no cabe en un procesador: se reparte entre muchos que deben intercambiar datos constantemente y a enorme velocidad. Dentro de un centro de datos eso se resuelve con cables; entre satélites que se mueven a varios kilómetros por segundo, no.

La vía que explora Google son los enlaces ópticos, es decir, láseres que conectan unos satélites con otros. En un demostrador de laboratorio han alcanzado 800 Gbps por sentido, 1,6 Tbps en total, con una sola pareja de transceptores. Llevar eso a dos objetos que se persiguen en órbita, manteniendo la puntería con precisión extrema, es otro asunto.

Por qué importa

Importa menos por lo que este satélite hace que por la pregunta que plantea. Durante treinta años la respuesta a «¿dónde se ejecuta el cómputo?» ha sido obvia: en un edificio, en la Tierra, enchufado a la red. El crecimiento de la IA está obligando a reabrir esa pregunta, porque las restricciones ya no son de chips sino de megavatios, de terreno y de agua para refrigerar.

Google no está sola en esto. La idea de llevar infraestructura de cómputo a órbita la están explorando también otras compañías, y conviene leer el movimiento en ese contexto: no es una ocurrencia aislada, sino una línea de investigación que varios actores consideran lo bastante seria como para gastar dinero en ella.

Dicho lo cual, hay una distancia enorme entre un prototipo y una infraestructura. Lanzar hardware sigue costando mucho, los satélites tienen vida limitada y no se reparan, y habría que resolver el almacenamiento, el mantenimiento orbital y la bajada de datos a la Tierra. Que algo sea técnicamente posible no lo hace económicamente sensato, y Project Suncatcher es hoy investigación de infraestructura, no un plan para sustituir los centros de datos terrestres.

Lo que acaba de ocurrir, entonces, es modesto y relevante a la vez: por primera vez unos procesadores de inteligencia artificial de Google están funcionando fuera de la atmósfera, y durante las próximas semanas se sabrá cuánto de lo ensayado en el laboratorio se sostiene en órbita. Si aguantan, el siguiente paso dejará de ser un satélite y pasará a ser el problema de verdad: conseguir que varios trabajen como uno solo.

Sobre la imagen de portada. Es un esquema de elaboración propia montado sobre una fotografía de archivo de dominio público: un Falcon 9 con la misión compartida Transporter-16 despegando de Vandenberg el 30 de marzo de 2026. No es el lanzamiento del que habla esta noticia, del que todavía no existe ninguna imagen pública. Las cifras sobrepuestas proceden de las fuentes citadas a continuación. Fotografía de la U.S. Space Force, del Senior Airman Kevin Hernandez, vía Wikimedia Commons.

Fuentes: Google, «Our Project Suncatcher prototype satellite is in orbit» y Google Research, sobre el diseño del sistema.

Los sistemas planetarios no se construyen solo acumulando material: también se construyen destruyéndose. Durante sus primeros cientos de millones de años, los cuerpos que orbitan una estrella joven se cruzan, chocan y en ocasiones se deshacen, liberando cantidades enormes de polvo y roca pulverizada. Es un periodo violento del que nuestro Sistema Solar guarda al menos un recuerdo visible: la Luna.

El telescopio espacial James Webb acaba de aportar la mejor evidencia hasta ahora de ese proceso ocurriendo en otras estrellas. Un equipo dirigido por la astrónoma Kate Su, del Space Science Institute de Boulder, reunió 21 discos de escombros extremos —la mayor muestra conseguida— y encontró en la composición de su polvo la firma de los choques que lo produjeron. El trabajo se publicó el 1 de octubre en The Astrophysical Journal.

Conviene decirlo desde el principio: Webb no ha fotografiado dos planetas chocando. Lo que observa son las huellas de la colisión, el polvo caliente y los minerales que quedan después.

Qué es un disco de escombros extremo

Alrededor de una estrella recién nacida hay un disco de gas y polvo. De ahí salen, por etapas, los planetas.

Cuando el gas se disipa queda un disco de escombros, hecho de material sólido. Los astrónomos conocen muchos. Pero hay una variante rara, el disco de escombros extremo, con una cantidad desmesurada de polvo caliente muy cerca de la estrella, justo en la franja donde deberían estar los planetas rocosos. El misterio era de dónde salía tanto material. Solo alrededor del 1% de las estrellas jóvenes muestra esta señal.

Leer la energía del choque en el polvo

Webb observa en infrarrojo, y el polvo caliente emite justo en esas longitudes de onda. Como cada mineral deja una marca distinta en el espectro, el telescopio puede identificar de qué está hecho ese polvo. Ahí estaba la pista.

La lógica es la siguiente: un impacto lo bastante violento funde y vaporiza la roca, y al enfriarse ese material condensa en partículas ricas en sílice que dejan una firma reconocible. Un roce, en cambio, genera fragmentos sin llegar a esas temperaturas. La mineralogía funciona como la huella del golpe.

Y además depende de la edad de la estrella

El hallazgo que más intriga es que los dos tipos no se reparten al azar. Los discos ricos en sílice aparecen únicamente alrededor de estrellas de menos de 300 millones de años; los pobres en sílice, en cambio, se encuentran en estrellas de edades muy variadas.

La lectura más natural es que ambos tipos corresponden a etapas distintas: primero los choques descomunales entre embriones planetarios, después una fase más larga de encuentros menores. Los autores son prudentes, porque en la franja de edad donde esperarían ver desaparecer los discos ricos en sílice solo tienen tres sistemas. Hace falta observar más.

Lo que esto dice de nuestro propio pasado

Aquí es donde la historia se vuelve personal. El Sistema Solar tiene unos 4,600 millones de años, y durante sus primeros cientos de millones fue un lugar mucho más caótico: los planetas rocosos aún crecían y las órbitas no se habían asentado.

La principal teoría sobre el origen de la Luna encaja exactamente en el primer tipo de choque que describe el estudio: un cuerpo del tamaño de Marte, bautizado Theia, habría impactado contra la Tierra primitiva y arrancado el material que terminó formando nuestro satélite. Es decir, el mismo tipo de evento de alta energía que produce los discos ricos en sílice que Webb está viendo ahora en otras estrellas.

Los investigadores van más allá y plantean que el Sistema Solar pudo atravesar más de una fase de este tipo. La formación planetaria no termina cuando aparecen los primeros cuerpos grandes: el movimiento de los planetas gigantes puede desordenar las órbitas de los pequeños y provocar una nueva tanda de impactos, como propone la hipótesis del bombardeo intenso tardío.

Investigar un choque que no se puede ver

Hay algo elegante en el método. Los cuerpos implicados son demasiado pequeños y están demasiado lejos para distinguirlos: ninguna de estas colisiones se puede observar directamente. Así que el equipo hace lo contrario, reconstruir el suceso a partir de lo que dejó.

Por qué importa

Durante décadas, la historia de cómo se forman los planetas se reconstruyó sobre todo con modelos matemáticos y con lo que podíamos deducir del Sistema Solar actual, que es el resultado final y no el proceso. Lo que cambia ahora es que se pueden observar otros sistemas mientras atraviesan esa etapa, y medir en ellos algo tan concreto como la energía de un choque a partir del mineral que dejó.

La muestra sigue siendo pequeña y las conclusiones son interpretaciones, no fotografías. Pero el estudio deja una idea que cuesta sacudirse: el orden tranquilo del Sistema Solar que vemos hoy, con sus órbitas estables y sus distancias enormes, es lo que quedó después de una época en la que los mundos se rompían unos contra otros. Y la Luna, que miramos sin pensarlo, probablemente sea el recuerdo más visible de aquello.

Fuentes: NASA, «Webb Provides Crash Course on Planet-Shattering Collisions», y el estudio de Kate Su, Ágnes Kóspál y Attila Moór publicado en The Astrophysical Journal. Imágenes: NASA, ESA, CSA, Joseph Olmsted (STScI).

Llegar a la Estación Espacial Internacional nunca ha sido cuestión de subir en línea recta. La estación da la vuelta a la Tierra cada hora y media a unos 28,000 kilómetros por hora, así que una nave no viaja «hacia» ella: entra en una órbita parecida y luego la alcanza con una serie de maniobras calculadas al segundo. Durante años esa persecución ha llevado entre medio día y un día entero.

Este 1 de octubre, la misión Crew-13 de SpaceX la completó en menos de ocho horas. Cuatro astronautas despegaron a las 11:10 de la mañana, hora del este, y a las 7 de la tarde ya estaban acoplados. Es el trayecto más rápido que ha hecho una nave estadounidense hasta la estación.

Claves de la misión

• Despegue: 11:10 a. m. EDT desde la plataforma 40 de la Estación de la Fuerza Espacial de Cabo Cañaveral, en Florida, con un cohete Falcon 9. La primera etapa regresó después en un aterrizaje controlado.
• Acoplamiento: a las 7:00 p. m. EDT en el puerto frontal del módulo Harmony, de forma autónoma. Unas 7 horas y 50 minutos de viaje.
• La nave: una cápsula Crew Dragon bautizada Grace.
• Tripulación: Jessica Watkins (NASA, comandante), Luke Delaney (NASA, piloto), Joshua Kutryk (Agencia Espacial Canadiense) y Sergey Teteryatnikov (Roscosmos). Para los tres últimos es su primer vuelo.
• Estancia: cerca de seis meses, integrados en la Expedición 75.

Por qué llegar rápido es difícil

El récord no se consigue encendiendo más los motores. Lo que determina cuánto tarda una nave en alcanzar la estación es la geometría: hay que despegar en el instante exacto en que la órbita de la ISS pasa por encima del punto de lanzamiento, insertarse en una órbita algo más baja —que por estar más cerca de la Tierra se recorre más deprisa— y usar esa diferencia de velocidad para ir recortando distancia antes de subir al encuentro.

Cuantas menos vueltas haga la nave en esa persecución, antes llega, pero también menos margen queda para comprobar sistemas o corregir desviaciones. Un trayecto corto significa, sobre todo, que todo salió según lo previsto desde el primer minuto.

Quién va a bordo

Watkins es la única con experiencia previa, y su perfil dice bastante sobre hacia dónde mira la NASA. Es geóloga: se licenció en Stanford, se doctoró en UCLA con una investigación sobre los mecanismos de los grandes deslizamientos de tierra en Marte y en la Tierra, y colaboró en el equipo científico del rover Curiosity antes de ser astronauta. Voló por primera vez en la misión Crew-4, entre abril y octubre de 2022, donde acumuló 170 días en el espacio. Ahora vuelve como comandante.Fuente: biografía oficial de la NASA

La composición de la tripulación tiene además una lectura política: estadounidenses, un canadiense y un ruso viajando juntos. Pese al contexto geopolítico, la estación sigue operando como lo que fue diseñada para ser, un proyecto compartido en el que las tres agencias colaboran en operaciones, ciencia y mantenimiento.

Lo que de verdad empieza ahora

El récord dura un titular; el trabajo dura seis meses. La microgravedad ofrece algo que no se puede reproducir en un laboratorio terrestre: sin el peso tirando hacia abajo, las células, los fluidos y los tejidos se organizan de otra manera, y eso permite observar procesos que en la Tierra quedan tapados por la gravedad.

Entre las investigaciones previstas hay cuatro líneas que destacan. La primera es la producción de tejidos derivados de células madre humanas en microgravedad, con la vista puesta en la medicina personalizada, el estudio de enfermedades y las pruebas de medicamentos; la NASA menciona aplicaciones en dolencias cardiovasculares y en el párkinson.

La segunda es un sistema de cultivo de plantas que funciona de forma mayoritariamente autónoma. No es jardinería: una misión a Marte no puede llevar desde la Tierra toda la comida de varios años, así que aprender a cultivar sin supervisión constante es un requisito, no un adorno.

La tercera sigue estudiando el propio cuerpo humano, en particular las alteraciones de la circulación sanguínea y otros efectos de pasar mucho tiempo en órbita. Y la cuarta es un dispositivo de diagnóstico pensado para vigilar la salud de la tripulación sin equipos grandes ni procedimientos complejos.

Esta última tiene más sentido del que parece a primera vista. En la estación, un astronauta con un problema médico puede hablar con un equipo en Houston casi al instante. Camino a Marte, cada mensaje tardaría varios minutos en llegar, y otros tantos la respuesta. Cuanto más lejos se viaja, más autónoma tiene que ser la medicina a bordo.

Por qué importa

Dos cosas, más allá del cronómetro. La primera es que Crew-13 confirma una rutina que hace una década era una apuesta: una empresa privada opera el transporte de astronautas dentro de un programa de la NASA, y lo hace con tal regularidad que la noticia ya no es que funcione, sino cuánto tardó. La agencia enmarca estas misiones en su programa de órbita baja, con el que mantiene acceso fiable a la estación mientras desarrolla las capacidades para ir más lejos.

La segunda es que la ISS se está comportando cada vez más como lo que será su legado: un banco de pruebas para aprender a vivir fuera de la Tierra antes de intentarlo donde no hay vuelta rápida. Cada cultivo que crece solo, cada tejido fabricado en ingravidez y cada aparato de diagnóstico que cabe en una mano son piezas de un problema mayor, el de mantener personas sanas y productivas a meses de distancia de casa.

Crew-13 empezó con un viaje de menos de ocho horas. Lo que valga la misión se sabrá dentro de seis meses, cuando se vea qué salió de los experimentos. Pero el récord deja una señal interesante: llegar a la órbita baja se está volviendo tan rutinario que ya se compite por hacerlo rápido.

Fuentes: NASA, blog de la Estación Espacial Internacional, Spaceflight Now y Space.com. Imagen: despegue de Crew-13, foto de NASA/John Kraus (dominio público).

Durante los primeros años de la programación asistida por inteligencia artificial la pregunta era si una máquina podía escribir código aprovechable. Esa discusión está zanjada. La que la sustituye es bastante más incómoda: ¿cómo sabemos que el código que escribe un agente funciona y es seguro?

No es una pregunta teórica. GitHub ya permite que agentes de programación ajenos a la casa —entre ellos Claude y Codex— trabajen directamente sobre repositorios, y desde junio aplica una capa de controles automáticos a lo que producen. El tema además ocupa buena parte de la agenda de GitHub Universe 2026, que se celebrará el 28 y 29 de octubre en el Fort Mason Center de San Francisco, con seguimiento en línea.

El problema ya no es generar código

Un asistente moderno hace mucho más que completar una función. Puede recorrer un repositorio, buscar archivos relacionados, modificar varios componentes a la vez, escribir pruebas, ejecutar comandos, instalar dependencias, investigar un error, abrir un pull request y responder a los comentarios de la revisión.

Eso cambia el problema de raíz. Cuando la IA sugería una línea, el programador la leía antes de aceptarla. Cuando un agente toca veinte archivos y deja un pull request listo, revisar cada decisión a mano deja de ser realista.

Que las pruebas pasen no significa que funcione

Aquí está el matiz que más cuesta interiorizar: una prueba puede pasar y la aplicación seguir rota. Ocurre cuando la prueba no cubre el comportamiento real, cuando la expectativa escrita en el test es incorrecta, cuando el agente cambió el código pero no el entorno que necesitaba, cuando el fallo solo aparece al integrar, o cuando el problema está en la infraestructura y no en el programa.

Por eso la verificación útil no es un sí o un no, sino una serie de preguntas encadenadas, cada una con un alcance distinto.

Ninguno de esos niveles basta por sí solo para confiar en el trabajo de un agente.

GitHub ya está aplicando controles

Esto dejó de ser una conversación sobre el futuro el 9 de junio de 2026, cuando GitHub puso en disponibilidad general la validación de seguridad para agentes de programación de terceros. Cuando uno de esos agentes escribe código en un repositorio, la plataforma lo analiza automáticamente antes de cerrar el pull request.

Son tres comprobaciones: CodeQL busca vulnerabilidades, las dependencias nuevas se contrastan contra la base de avisos de GitHub, y el escaneo de secretos detecta claves y tokens. Si algo salta, el propio agente intenta resolverlo antes de dar el cambio por terminado.

Hay tres detalles prácticos que conviene conocer. Las comprobaciones vienen activadas por defecto y siguen la configuración de Copilot que ya tenga el repositorio. No hacen falta licencias adicionales: no requieren GitHub Advanced Security. Y no son un estreno absoluto, sino la extensión de lo que GitHub lanzó para su propio agente en octubre de 2025, que según la compañía ya ha evitado cientos de filtraciones y vulnerabilidades potenciales.

Las dependencias son un problema aparte

Un agente puede decidir que la forma rápida de resolver algo es instalar una biblioteca. Parece una operación trivial, pero cada dependencia arrastra las suyas, y el árbol crece sin que nadie lo haya revisado.

El riesgo no es nuevo, pero sí su frecuencia: un agente produce cambios mucho más rápido que una persona, así que también incorpora dependencias mucho más a menudo. Universe dedica una de sus sesiones precisamente a lo que ocurre detrás de un npm install: procedencia de los paquetes, procesos de publicación y mecanismos como OpenID Connect.

El agente también necesita permisos

Un agente no solo escribe: usa herramientas. Y cada herramienta es un permiso que alguien le concedió.

Es justo el tipo de distinción que GitHub está abordando con la autorización sobre servidores MCP, con escenarios donde un agente puede abrir un pull request pero no cerrarlo.

La memoria también hay que administrarla

Parecería que cuanto más recuerde un agente, mejor. GitHub sostiene lo contrario: acumular demasiado contexto puede incluso empeorar su rendimiento en determinadas tareas. Un agente puede aprender las convenciones del equipo y las decisiones de arquitectura, pero también puede arrastrar información que dejó de ser cierta después de una migración.

La pregunta útil, entonces, no es qué debe recordar, sino qué debería olvidar.

El contexto como infraestructura

Esto conecta con una práctica cada vez más extendida: usar archivos como AGENTS.md para dejar por escrito las reglas del proyecto. Un archivo corto basta:

# AGENTS.md

## Proyecto
Aplicación web con React y Python.

## Reglas
- Ejecutar las pruebas después de modificar código.
- No almacenar secretos.
- No introducir dependencias sin justificarlas.

## Verificación
Antes de terminar: pruebas, lint, build y revisar el git diff.

Cuando varios agentes y varias personas comparten esas reglas, el contexto deja de ser una preferencia individual y empieza a comportarse como infraestructura del equipo: algo que se versiona, se revisa y se mantiene. Una de las sesiones anunciadas para Universe lleva precisamente ese título, «trata tu contexto de IA como infraestructura».

Evaluar al agente, no solo al código

Queda una pieza más: saber si el agente que usas es bueno para lo que tú haces. Una puntuación alta en un banco de pruebas no garantiza que sea útil en tu repositorio. Un agente puede resolver errores sencillos a gran velocidad y, al mismo tiempo, tocar más archivos de la cuenta, añadir dependencias innecesarias o no entender la arquitectura que ya existe. Universe dedica una sesión a esa brecha, con un título que no se anda con rodeos: «tu banco de pruebas te está mintiendo».

Qué puedes hacer hoy

Nada de esto exige esperar a las herramientas que vengan. Hay prácticas que ya funcionan: usar control de versiones y revisar el git diff de cada tanda; mantener las reglas del proyecto por escrito; exigir pruebas antes de dar un cambio por terminado; limitar permisos, porque quien modifica código no necesariamente debe poder desplegarlo; revisar con lupa las dependencias nuevas; apoyarse en análisis estático y escaneo de secretos; y reservar para el equipo las decisiones de arquitectura y las acciones de alto impacto.

Por qué importa

La objeción evidente es si todo esto significa que programar con IA sea inseguro. No exactamente: lo que cambia es la escala. Una persona produce un número acotado de cambios al día; un agente, muchos más. Aunque cada modificación tenga una probabilidad pequeña de introducir un problema, el volumen multiplica las ocasiones. La respuesta lógica no es frenar la generación, sino automatizar también la revisión.

Ahí está el desplazamiento de fondo. El oficio no desaparece, se mueve: menos tiempo escribiendo cada línea y más definiendo arquitectura, fijando restricciones, decidiendo qué puede hacer el agente, diseñando las pruebas y comprobando que el producto resuelve el problema. La habilidad valiosa deja de ser solo escribir código rápido y pasa a incluir saber dirigir y verificar sistemas que escriben código.

Durante años el reto fue conseguir que los modelos generaran código suficientemente bueno. Ese problema sigue ahí, pero encima apareció otro más interesante: construir la ingeniería que rodea a unos agentes capaces de producir mucho código por su cuenta. Que GitHub lo haya puesto en el centro de su conferencia anual, y que ya tenga una parte funcionando en producción, dice bastante sobre qué parte del problema considera resuelta y cuál no.

Fuentes: GitHub Changelog, validación de seguridad para agentes de terceros y GitHub Universe 2026.

El kernel de Linux es la capa que conecta el hardware con todo lo demás, y está debajo de una cantidad enorme de infraestructura: servidores, nubes públicas, teléfonos, routers y supercomputadoras. Por eso un fallo ahí no se parece a un fallo en una aplicación cualquiera, y por eso cada tanda de correcciones importa más de lo que su discreción sugiere.

Septiembre dejó tres frentes abiertos a la vez. Red Hat agrupó cuatro vulnerabilidades de la pila de red que, cumpliéndose ciertas condiciones, permiten que un usuario local llegue a root. Ubuntu publicó su propia tanda de parches para un conjunto distinto de fallos. Y mientras tanto, el desarrollo de Linux 7.3 avanzó hasta su quinta versión candidata, con un detalle nuevo en el historial de cambios: parches que llevan escrito que los encontró una inteligencia artificial.

Claves del mes en el kernel

• Cuatro fallos de escalada a root: Red Hat los agrupó el 19 de septiembre en el aviso RHSB-2026-011, actualizado el día 26. Afectan a la infraestructura de red del kernel y alcanzan a Red Hat Enterprise Linux 6 a 10 y a OpenShift.
• Tienen nombre: DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) y DiagSpill (CVE-2026-74469). Tocan, respectivamente, el subsistema IPv6 AH6/XFRM, el controlador TUN/TAP, la ruta de transmisión de PPPoE y los diagnósticos de SCTP.
• Ubuntu fue por su cuenta: el 30 de septiembre publicó USN-8851-1, con correcciones para el servidor NFS, IPv6 y Netfilter (CVE-2026-53221, CVE-2026-53131 y CVE-2025-38724), en Ubuntu 20.04 y 18.04 LTS. Incluye los kernels específicos para AWS, Azure, Google Cloud y Oracle Cloud, y exige reiniciar para que surtan efecto.
• Linux 7.3-rc5: publicado el 27 de septiembre. Es una candidata, todavía no la versión estable. La rama estable sigue en 7.2.8, del día 25.
• Parches con firma de IA: el subsistema IPE incorporó el 23 de septiembre dos correcciones de use-after-free marcadas con la etiqueta Assisted-by: LLM.

Cuatro vulnerabilidades con nombre propio

Las cuatro comparten el mismo patrón: un usuario sin privilegios que ya tiene acceso a la máquina puede, si se cumplen los requisitos de cada una, terminar con permisos de administrador. No son fallos que permitan entrar desde fuera, pero sí convertir un acceso menor en control total.

La distinción importa poco en un servidor compartido. Cuando varios usuarios, contenedores y servicios corren sobre el mismo kernel, la frontera entre ellos es el kernel: si esa frontera cede, se cae todo el esquema de aislamiento de una vez. Red Hat señala un caso aparte, DiagSpill, que no necesita espacios de nombres de usuario sin privilegios y que en ciertas configuraciones de SCTP podría provocar además una denegación de servicio remota.

La empresa dice haber publicado ya las correcciones para buena parte de sus líneas de producto y estar acelerando las restantes.Fuente: Red Hat, RHSB-2026-011

Actualizar el kernel no es lo mismo que cambiar de versión

Aquí hay una confusión frecuente. Corregir una vulnerabilidad del kernel casi nunca significa instalar a mano una versión nueva desde kernel.org: cada distribución mantiene su propia rama y aplica los parches sobre ella. El resultado es que el número de versión puede quedarse igual mientras el fallo ya está corregido.

El aviso de Ubuntu lo ilustra bien. Además de los kernels genéricos, publica paquetes distintos para cada nube —linux-aws, linux-azure, linux-gcp, linux-oracle—, porque esos entornos usan kernels adaptados. Y advierte algo que se pasa por alto con facilidad: instalar la actualización no basta, hay que reiniciar para que el kernel nuevo entre en servicio.Fuente: Ubuntu Security Notice USN-8851-1

Por eso la pregunta útil no es «qué distribución tengo», sino «qué versión del kernel estoy ejecutando ahora mismo y qué actualizaciones de seguridad publica mi distribución para esa rama».

Linux 7.3 se acerca

Mientras las distribuciones tapan agujeros, la siguiente versión sigue su curso. Linux 7.3-rc5 salió el 27 de septiembre con correcciones repartidas por controladores, red, arquitectura, virtualización, BPF, sistemas de archivos y gráficos. Al ser una candidata, todavía faltan algunas semanas de pruebas antes de la versión definitiva.Fuente: kernel.org

En paralelo hay trabajo de mantenimiento menos visible pero con efectos medibles. Una serie de parches propone resincronizar el código de compresión LZ4 del kernel con el del proyecto original, del que llevaba años separado. Las mediciones publicadas junto a la serie reportan mejoras de entre 11% y 14% en algunas pruebas con el sistema de archivos EROFS, y de hasta 21% en escenarios concretos. Conviene leer esas cifras con cuidado: corresponden a pruebas puntuales, no a una mejora general, y la serie todavía no está integrada en la rama principal.

La IA ya deja su firma en los parches

El cambio más interesante del mes no es una función de Linux 7.3, sino cómo se están encontrando algunos errores. El kernel tiene decenas de millones de líneas y una maraña de interacciones entre subsistemas; hay fallos que un humano tardaría muchísimo en ver.

El 23 de septiembre, el subsistema IPE (Integrity Policy Enforcement) incorporó dos correcciones de use-after-free: una protege el hash raíz de dm-verity con RCU, y la otra evita que una política recién cargada se libere mientras se está auditando. Ambas llevan la etiqueta Assisted-by: LLM en el mensaje del commit, y ambas están marcadas para retroportarse a las ramas estables.

Hay un detalle revelador en uno de esos mensajes: una nota del mantenedor indica que se quitó el nombre del modelo «según la directriz más reciente». Es decir, la comunidad del kernel no solo acepta ya estas contribuciones, sino que está escribiendo reglas sobre cómo deben declararse.

Conviene no exagerar lo que significa. La IA no está sustituyendo a los mantenedores: actúa como una herramienta más para rastrear patrones sospechosos, errores de manejo de memoria o condiciones de carrera en una base de código gigantesca. Cada hallazgo sigue pasando por revisión humana, pruebas y la firma de un desarrollador que se hace responsable de él.

En la misma línea, los desarrolladores discuten añadir al árbol de código un archivo AGENTS.md, el formato que se usa para darle instrucciones a los agentes de programación. La propuesta surgió al ver que algunos agentes interpretaban mal las convenciones del proyecto, incluidas las etiquetas de autoría y certificación de los parches. Todavía no está en el árbol oficial, pero la discusión marca un cambio de fondo: los proyectos empiezan a documentar no solo cómo debe trabajar una persona, sino también cómo debe comportarse una máquina que colabora.

Por qué importa

Para quien usa Linux en el escritorio, casi nada de esto se nota: la distribución integra las correcciones y llegan con las actualizaciones normales. En servidores la historia cambia, porque una máquina puede pasar meses encendida dando servicio y el parche instalado no sirve de nada hasta que se reinicia.

Detrás de los tres frentes de este mes hay una misma dinámica. Linux soporta cada vez más hardware, arquitecturas y tecnologías, así que es cada vez más complejo; cuanto más complejo, más herramientas automáticas hacen falta para mantenerlo seguro —fuzzers, analizadores estáticos y ahora modelos de lenguaje—; y cuanto mejores son esas herramientas, más errores salen a la luz. Los avisos de seguridad no son señal de que el kernel esté peor, sino de que se está mirando con más lupa.

Para los administradores, el mensaje práctico no ha cambiado en veinte años: mantener el kernel actualizado y reiniciar cuando toca sigue siendo de las tareas de seguridad más básicas y más pospuestas. Lo que sí cambió es quién encuentra los fallos. Que dos parches del kernel lleven escrito que los halló un modelo de lenguaje, y que exista una directriz sobre cómo declararlo, dice bastante sobre hacia dónde va el desarrollo de software: la IA ya no solo corre sobre Linux, también ayuda a construirlo.

Fuentes: Red Hat RHSB-2026-011, Ubuntu USN-8851-1, kernel.org y el árbol de código del kernel. Imagen: Tux, mascota de Linux (CC0, Wikimedia Commons, basado en el diseño de Larry Ewing).