La red social X, antigua Twitter, ha vivido una nueva caída que ha dejado a miles de usuarios sin acceso normal a sus cuentas durante la tarde de este lunes 20 de abril. El fallo se ha dejado notar con fuerza en España y en otros países europeos, donde el acceso al timeline y a las funciones básicas se ha visto seriamente limitado tanto en la versión web como en la aplicación móvil.

Aunque el servicio ya se ha ido restableciendo de forma progresiva, el episodio se suma a una racha de incidencias recientes que ha generado inquietud entre usuarios, empresas y medios de comunicación que dependen de X para informarse y trabajar en tiempo real. Durante varios minutos, la plataforma llegó a mostrar mensajes de bienvenida como si se tratara de una cuenta recién creada o timelines con publicaciones antiguas que no se actualizaban.

Una caída generalizada con origen en los servidores de X

Según los datos recopilados por Downdetector, el portal que reúne reportes de fallos en servicios digitales, los problemas comenzaron a notarse horas antes, pero fue a partir de las 19:30 (hora peninsular española) cuando se produjo un pico claro de incidencias. En cuestión de minutos, las notificaciones de error pasaron de ser anecdóticas a concentrar cientos y luego miles de avisos en distintos países.

Los usuarios detallaron una serie de fallos muy similares entre sí: dificultad para cargar el feed principal, problemas para iniciar sesión, errores al enviar mensajes directos y una web que parecía estar en constante proceso de carga. En la pestaña “Para ti” muchos se encontraban con un timeline vacío y con el mensaje “Te damos la bienvenida a X”, como si el sistema no reconociera correctamente la actividad previa de la cuenta.

La naturaleza del incidente apunta, por el patrón de quejas y la simultaneidad geográfica, a un problema centralizado en la infraestructura de X, más que a errores aislados de operadoras o caídas locales. Este tipo de síntomas suele indicar dificultades en los servidores principales, en la red interna de la plataforma o en algún componente clave del software que gestiona el tráfico de millones de peticiones por minuto.

Durante el tramo más crítico, la gráfica de Downdetector mostraba un aumento repentino de reportes al final de la línea temporal, un comportamiento típico de una caída en desarrollo. Es decir, cuando todavía hay usuarios que siguen detectando fallos y el servicio no se ha normalizado por completo, aunque algunas zonas o cuentas ya puedan acceder con aparente normalidad.

Impacto en España y en el resto de Europa

En el caso concreto de España, las incidencias se concentraron en el acceso al timeline y en la recarga de contenido, tanto en navegadores de escritorio como en móviles. La página principal cargaba, pero muchos usuarios solo podían ver publicaciones antiguas, sin que aparecieran tuits nuevos ni se actualizaran las respuestas o notificaciones.

Además de España, otros países europeos también se vieron afectados, con reportes significativos en Francia y Países Bajos. En todos ellos se repetía el mismo patrón: errores de carga, dificultades para publicar nuevos mensajes y una experiencia de uso muy inestable. Aunque la intensidad del fallo podía variar de una región a otra, el problema se percibía como global y no como un simple corte regional.

Esta interrupción coincidió, además, con una franja horaria de alto tráfico digital en Europa, cuando muchas personas regresan a casa y consultan redes sociales, medios y servicios de mensajería. Esa coincidencia multiplica la sensación de desconcierto: de repente, una de las vías habituales para informarse sobre lo que está pasando en el mundo deja de responder o lo hace con mucha lentitud.

A pesar de la magnitud del fallo, la empresa no difundió de inmediato una explicación detallada sobre el origen técnico de la caída o sobre si se debía a tareas de mantenimiento, a una actualización fallida o a una sobrecarga puntual vinculada a algún evento concreto. La ausencia de comunicación clara en los primeros minutos suele ser uno de los puntos que más molesta a los usuarios habituales.

Cómo se detectan las caídas de X y de otras plataformas

Cuando una red social como X comienza a fallar, la primera reacción de muchos usuarios es comprobar si el problema es general o solo suyo. En lugar de reiniciar una y otra vez el móvil o el router, la opción más rápida suele ser acudir a herramientas como Downdetector o páginas del estilo de Down for Everyone or Just Me.

Estas plataformas recopilan los reportes de error enviados por los propios internautas y muestran en tiempo real cuántas incidencias se están registrando en cada servicio. Si en pocos minutos aparece un pico de avisos, es una señal bastante clara de que hay una caída generalizada o, al menos, una avería de alcance amplio.

En el episodio de este 20 de abril, Downdetector reflejaba un crecimiento súbito de las quejas relacionadas con X a partir de primeras horas de la tarde, antes del gran repunte en torno a las 19:30. En España, Francia y Países Bajos se registraban ya cientos de reportes, mientras que en Estados Unidos las incidencias superaban holgadamente las decenas de miles, lo que confirma el carácter internacional del problema.

Además del número total de informes, estos portales suelen ofrecer un desglose del tipo de error más común que se está produciendo. En esta ocasión, la mayoría de usuarios mencionaban fallos en la aplicación móvil, seguidos por problemas al conectar con los servidores y dificultades para ver o actualizar el feed de publicaciones. Esto apunta a un fallo amplio dentro de la infraestructura de X, que afecta a varios componentes a la vez.

El mapa de calor de reportes, por su parte, permite visualizar las zonas geográficas más golpeadas por la caída. Aunque en esta jornada el foco de atención estuvo en buena parte puesto en Europa y Norteamérica, también se detectaron problemas en distintos países de América Latina, lo que refuerza la idea de que se trataba de un fallo amplio y no de una avería local.

Qué tipo de fallos han sufrido los usuarios

Los testimonios recogidos a través de redes y foros coinciden en señalar una serie de fallos recurrentes durante la caída de X. En primer lugar, muchos usuarios no conseguían que el timeline se actualizara: el inicio de la aplicación quedaba congelado con publicaciones antiguas o, directamente, en blanco.

En segundo lugar, una parte de los afectados se topaba con errores al intentar publicar mensajes, responder a otros tuits o enviar mensajes directos. En algunos casos, el contenido parecía enviarse pero no llegaba a mostrarse en el perfil o en las notificaciones de otras personas, lo que generaba aún más confusión.

También hubo quejas sobre la imposibilidad de acceder correctamente a la versión de escritorio. La página cargaba a medias o se quedaba en un bucle de recarga constante, sin que terminara de mostrar el contenido del timeline, las listas o las búsquedas. Para quienes usan X como herramienta de trabajo desde el ordenador, este tipo de fallo es especialmente molesto.

Otro de los síntomas llamativos fue la aparición de mensajes propios de una cuenta recién creada en perfiles antiguos y muy activos. Algunos usuarios se encontraban con pantallas que les daban la bienvenida a la red social y les sugerían seguir a otras cuentas, como si se tratara de su primer día en la plataforma, una señal de que el sistema no estaba recuperando bien la información personalizada.

En todo este proceso, no consta que se haya producido un apagón total de la plataforma durante un periodo prolongado, sino más bien una serie de errores severos que impedían utilizar X con normalidad. En muchas caídas de este tipo, el servicio se va recuperando por fases, de forma que algunos usuarios recuperan el acceso antes que otros, o determinadas funciones vuelven a funcionar mientras otras siguen dando problemas.

Posibles causas técnicas de las caídas de X

La empresa propietaria de X no ha ofrecido por ahora una explicación detallada y pública sobre el origen concreto de esta caída. Sin embargo, la experiencia con otros incidentes similares en grandes plataformas permite esbozar algunos de los motivos más habituales cuando se produce una interrupción de este tipo.

Uno de los factores recurrentes es la sobrecarga de los servidores. Durante momentos de gran interés informativo, eventos deportivos, situaciones de crisis o debates virales, el tráfico hacia la red social puede multiplicarse en cuestión de segundos. Si la infraestructura no responde con la suficiente elasticidad, el resultado puede ser una ralentización general o, directamente, un corte temporal del servicio.

También entran en juego los problemas internos de infraestructura: fallos en centros de datos, errores de configuración en redes internas, incidencias en bases de datos o en servicios de caché que ayudan a acelerar la entrega de contenido. Cualquier alteración en estas piezas clave puede desencadenar una cascada de errores que acabe afectando de forma visible al usuario final.

Otra posibilidad es que la caída esté relacionada con errores de software tras una actualización. Cada vez que se introducen nuevas funciones, se corrigen fallos o se modifican componentes críticos del sistema, existe el riesgo de que un cambio aparentemente menor tenga efectos no previstos en otras partes de la plataforma. Si esto ocurre en un entorno de producción con millones de usuarios conectados, el impacto se magnifica.

No hay que olvidar, además, el papel del mantenimiento programado. Aunque en muchos casos estas tareas se anuncian con antelación o se ejecutan en horarios de baja actividad para minimizar molestias, a veces una operación de mantenimiento puede prolongarse más de lo previsto o provocar fallos colaterales que se traducen en caídas parciales del servicio.

Sea cual sea la causa concreta, para plataformas del tamaño de X la prioridad es restablecer el servicio lo antes posible y, en segundo lugar, comunicar con claridad qué ha ocurrido y qué medidas se van a tomar para evitar que se repita. La rapidez de reacción y la transparencia influyen directamente en la percepción de fiabilidad que tienen tanto los usuarios como los anunciantes.

Consecuencias para usuarios, medios y empresas

La interrupción de X va más allá de la simple molestia de no poder publicar un tuit durante unos minutos. Para muchos profesionales y organizaciones, la plataforma es una herramienta de trabajo esencial, utilizada para difundir noticias de última hora, coordinar acciones, lanzar campañas o interactuar con comunidades específicas.

En el ámbito informativo, las redacciones y periodistas se apoyan en X para seguir acontecimientos en directo y para contrastar información en tiempo real. Una caída repentina complica la cobertura de eventos y obliga a buscar vías alternativas para recopilar reacciones y actualizaciones, lo que puede ralentizar la difusión de determinadas noticias.

Las marcas y empresas que utilizan la red social para campañas de marketing, anuncios o atención al cliente también se ven afectadas. Publicaciones programadas que no se lanzan a la hora prevista, clientes que no reciben respuesta a sus consultas o promociones que pierden visibilidad pueden tener un impacto directo en la imagen pública y en los resultados de determinadas acciones comerciales.

En un plano más cotidiano, millones de usuarios emplean X como canal de comunicación informal, espacio de debate o fuente de información sobre temas específicos. Cuando la red se cae, muchos se dan cuenta de hasta qué punto dependen de ella para enterarse de lo que pasa y para mantenerse en contacto con otras personas o comunidades.

Estos episodios ponen sobre la mesa la vulnerabilidad de un modelo digital muy concentrado en pocas plataformas. Cuando uno de estos gigantes falla, se produce un efecto dominó que afecta a múltiples capas de la vida social, profesional y mediática, desde el usuario que no puede leer sus cuentas favoritas hasta la institución que pierde durante un rato uno de sus canales oficiales de comunicación.

Lo ocurrido con X en esta nueva caída vuelve a evidenciar la importancia de contar con sistemas más resilientes, buenas prácticas de mantenimiento y una comunicación clara por parte de las empresas tecnológicas cuando surgen problemas. Mientras tanto, para los usuarios, conocer herramientas como Downdetector y tener alternativas para seguir informados puede marcar la diferencia entre quedar totalmente a oscuras o sortear mejor el apagón temporal de su red social de referencia.

Valve ha empezado a desplegar Proton 11 en versión beta dentro de Steam, una actualización que no llega sola: incorpora una nueva base técnica con Wine 11, estrena la tecnología NTSync y estrena una rama oficial para procesadores ARM64. Todo ello apunta a un objetivo bastante claro: que los juegos de Windows funcionen cada vez mejor en Linux y en el ecosistema Steam, tanto en PC como en dispositivos portátiles y futuros visores de realidad virtual.

Más allá del típico listado de cambios, la combinación de Wine 11, NTSync, DXVK y VKD3D-Proton marca un paso importante para quienes juegan en SteamOS, en distribuciones Linux de escritorio o en equipos portátiles como Steam Deck. A eso se suma la aparición de Proton 11.0 (ARM64), pensado para hardware Arm y llamado a ser una pieza clave en proyectos como Steam Frame y otras máquinas con chips de Qualcomm o plataformas similares.

Qué aporta Proton 11: nueva base con Wine 11 y NTSync

La novedad más relevante de esta beta es que Proton 11.0 se apoya ahora en Wine 11, sustituyendo la base anterior. Este rebase modifica el «suelo» sobre el que trabaja Proton y permite replicar con más precisión el comportamiento que esperan los juegos y aplicaciones de Windows, algo que suele notarse tanto en compatibilidad como en estabilidad general.

Dentro de ese cambio de base destaca la integración de NTSync, una tecnología que lleva la sincronización de Windows NT al kernel de Linux. Aunque pueda sonar muy técnico, el efecto práctico es reducir la sobrecarga de CPU cuando los juegos hacen un uso intensivo de múltiples hilos, algo habitual en títulos modernos y en motores que reparten mucho trabajo entre núcleos.

Valve y la propia comunidad subrayan que no hay que esperar un aumento automático de FPS en todos los juegos, al menos no en la cifra media. Donde se nota más el cambio es en la regularidad con la que se entregan los fotogramas: menos tirones, mejores valores de 1% y 0,1% low y una sensación de mayor suavidad en escenas exigentes o cuando el procesador iba justo.

En la práctica, NTSync busca recortar uno de los cuellos de botella habituales del gaming en Linux: la gestión de sincronización entre el juego y el sistema. Allí donde soluciones como esync y fsync empezaban a quedarse cortas, esta nueva aproximación desde el kernel puede marcar diferencias, sobre todo en títulos pesados con mucho trabajo paralelo.

DXVK 2.78, VKD3D-Proton y mejoras gráficas de fondo

Junto a la nueva base y NTSync, Proton 11 incorpora DXVK 2.78 y mejoras en los componentes de VKD3D-Proton, dos proyectos imprescindibles para traducir las llamadas de DirectX de los juegos de Windows a Vulkan en Linux. Esa traducción es lo que permite que títulos pensados para DirectX 9, 10, 11 o 12 se ejecuten en SteamOS y en otras distribuciones sin que el usuario tenga que hacer nada.

La actualización abarca un espectro amplio de juegos, desde clásicos basados en DX9 hasta producciones modernas que dependen de DirectX 12. A nivel usuario, el objetivo es que menos títulos presenten errores gráficos raros, artefactos o cuelgues, y que la carga sobre la CPU y la GPU esté mejor equilibrada gracias a una gestión más eficiente de Vulkan.

Estas mejoras no siempre se traducen en un incremento espectacular de la tasa de fotogramas, pero sí en una experiencia más predecible, con menos sorpresas al lanzar juegos que antes necesitaban ajustes manuales o ramas experimentales. En dispositivos portátiles como Steam Deck, además, esa optimización se nota en un menor consumo de recursos y en temperaturas algo más contenidas en sesiones largas.

Más juegos compatibles y menos dependencia de Proton Experimental

Cada lanzamiento de Proton suele llegar con una lista de títulos que pasan a funcionar mejor o dejan de requerir configuraciones especiales, y la versión 11 no es una excepción. Varios juegos que antes dependían de Proton Experimental han pasado a ser compatibles con la rama principal, algo especialmente importante para usuarios que priorizan estabilidad.

Entre los títulos citados en diferentes changelogs y reportes de la comunidad aparecen Gothic 1 Classic, Deadly Premonition, Metal Gear Survive, Warhammer: Vermintide 2 y varias entregas clásicas de las sagas Resident Evil y Dino Crisis. También se mencionan ajustes en juegos que ya funcionaban, pero que sufrían problemas intermitentes de rendimiento o errores al iniciar.

El efecto conjunto de estos cambios es que la biblioteca jugable en Linux y SteamOS sigue creciendo sin que el usuario tenga que «pelearse» con tantas opciones. Menos necesidad de probar ramas experimentales, menos parches caseros y menos dependencias de guías externas para lograr que un juego arranque en condiciones aceptables.

Esta línea encaja con la estrategia de Valve desde el lanzamiento de Steam Deck: que jugar en Linux se parezca lo máximo posible a jugar en Windows en cuanto a sencillez. Es decir, seleccionar el juego, pulsar en «Jugar» y olvidarse de lo que hay por debajo, aunque debajo haya una capa compleja de compatibilidad.

Correcciones para launchers de EA, Rockstar y REDLauncher

Otro frente en el que Proton 11 avanza es el de los launchers externos, un dolor de cabeza recurrente para muchos usuarios de Linux. Las notas de la versión y varios análisis señalan correcciones específicas para los sistemas de inicio de EA, Rockstar y REDLauncher, plataformas que en los últimos años han dado más de un problema en Proton.

En la práctica, estas capas adicionales de software pueden hacer que un juego sea injugable aunque la parte técnica esté resuelta: cierres al iniciar, sesiones que no se autentican bien o actualizaciones que rompen compatibilidades previas. Ajustar estos detalles es menos vistoso que sumar FPS, pero tiene un impacto directo en el día a día.

Con Proton 11, Valve sigue recortando ese tipo de fricciones para que la experiencia sea lo más transparente posible. La idea es que los problemas con launchers de terceros dejen de ser un obstáculo recurrente al plantearse jugar en Linux, tanto en sobremesa como en dispositivos portátiles.

Proton 11.0 (ARM64): la nueva rama para hardware Arm

Junto a la beta principal de Proton 11, Valve ha incorporado una novedad que va un paso más allá: una configuración oficial llamada Proton 11.0 (ARM64). Esta rama está pensada para ejecutarse en procesadores Arm de 64 bits y aparece ya en el registro de cambios de Steam con identificadores y appid propios.

El objetivo de esta variante es claro: permitir que juegos diseñados para CPUs x86 se ejecuten en hardware Arm dentro del ecosistema de Steam. En otras palabras, hacer posible que dispositivos basados en chips de Qualcomm u otros fabricantes puedan correr títulos de Windows a través de Proton sobre Linux, sin depender únicamente del streaming desde un PC tradicional.

En el changelog publicado en Steam se detallan datos como el alias proton-11.0-beta, el appid 4628710, el depotid 4628711 y la etiqueta Proton 11.0 (Beta), junto con una referencia a Proton 11.0 (ARM64) donde se indica que la compilación integra FEX 2604. Estos apuntes son técnicos, pero dejan claro que no se trata de un experimento aislado sino de una rama con entidad propia.

Las primeras pruebas recogidas en foros especializados muestran que la compilación funciona en hardware Arm más allá de los planes de Valve, como equipos con procesadores Snapdragon X, aunque con resultados todavía dispares. Es un indicio de que el trabajo que se está haciendo para Steam Frame podría beneficiar a otros dispositivos que ejecuten SteamOS o distribuciones compatibles sobre Arm.

FEX y la traducción x86 sobre ARM64

Para que Proton 11.0 (ARM64) tenga sentido, no basta con traducir las llamadas de Windows a Linux. El gran reto es que el código x86 de los juegos se ejecute realmente sobre CPUs Arm, y ahí entra en juego una capa adicional llamada FEX, que Valve ya ha confirmado como parte de la pila Arm de SteamOS.

Mientras Proton se encarga de la compatibilidad a nivel de sistema operativo, FEX actúa como traductor de instrucciones entre arquitecturas, convirtiendo lo que el juego espera de una CPU x86 en operaciones que un procesador Arm puede manejar. Ese proceso tiene un coste en rendimiento, y por ahora la sobrecarga sigue siendo notable según las primeras pruebas.

Aun con ese peaje, la combinación de Proton 11.0 (ARM64) y FEX abre la puerta a ejecutar localmente juegos de Windows en dispositivos Arm sin depender siempre del streaming desde un PC. Esto encaja con la idea de Valve de apoyar visores de realidad virtual y consolas portátiles basadas en Linux que no usan procesadores de Intel o AMD.

En su estado actual, la variante Arm64 de Proton se considera más experimental que la rama principal, y Valve ni siquiera la ha presentado de forma oficial en grandes anuncios. El enfoque parece ser el de pulir la tecnología en segundo plano para que esté lista cuando el hardware que la necesita llegue al mercado.

La conexión con Steam Frame y otros dispositivos Arm

Buena parte del interés en Proton 11.0 (ARM64) se explica por el futuro visor de realidad virtual independiente de Valve, conocido como Steam Frame. Este casco integra en su interior un chip Qualcomm Snapdragon 8 Gen 3 con arquitectura Arm, por lo que no puede ejecutar código x86 de forma nativa sin ayuda de capas tipo FEX.

En el modo en el que Steam Frame se conecta a un PC y actúa como mero visor inalámbrico, Proton no tiene mucho que hacer, porque el juego corre en el ordenador y solo se envía el vídeo al casco. Pero cuando se plantea que el visor ejecute juegos de forma local, directamente en el chip Arm, la capa de compatibilidad vuelve a ser fundamental.

Aunque Valve no ha vinculado oficialmente esta beta con el visor, la aparición de Proton 11.0 (ARM64) en estado funcional sugiere que el software se está preparando para ese lanzamiento. La propia existencia de esta rama, sumada a la integración de FEX en la pila de SteamOS para Arm, indica que la compañía está sentando las bases para un catálogo jugable en dispositivos que no dependen de x86.

Más allá del visor, la misma tecnología puede beneficiar a consolas portátiles y mini PCs Arm que ejecuten Linux, ya sea con SteamOS o con distribuciones adaptadas. De momento, el terreno sigue siendo más de entusiastas que de usuarios generalistas, pero la dirección está bastante clara.

Impacto en SteamOS, Steam Deck y el gaming en Linux

Desde su lanzamiento hace ya varios años, Proton se ha convertido en una pieza central para que SteamOS y Steam Deck tengan sentido como plataformas de juego. Cada nueva versión ha ido recortando la distancia con Windows, y Proton 11 mantiene esa tendencia con un enfoque puesto más en estabilidad y compatibilidad que en grandes golpes de efecto.

Para quienes juegan en Europa con Steam Deck, PCs con Linux de sobremesa o portátiles configurados como máquinas de juego, la actualización se traduce en menos problemas al lanzar títulos populares, mejor comportamiento de algunos juegos exigentes y una sensación general de mayor solidez en el día a día.

En dispositivos portátiles, donde el margen térmico y de consumo es limitado, la reducción de carga innecesaria sobre la CPU y la mejora en la consistencia de los fotogramas pueden ayudar también a ganar algo de autonomía. No son cambios tan vistosos como una subida masiva de FPS, pero sí contribuyen a que la experiencia se acerque más a lo que el usuario espera de una consola cerrada.

Al mismo tiempo, el despliegue de Proton 11 en beta invita a la cautela: no todos los juegos van a funcionar perfecto desde el primer día, y es probable que sigan apareciendo casos en los que haya que recurrir a versiones anteriores de Proton o a ajustes manuales. Aun así, la dirección general parece clara: menos obstáculos técnicos para quien quiera jugar en Linux y más opciones reales frente a Windows.

Con la base de Wine 11, la incorporación de NTSync, las mejoras en DXVK y VKD3D-Proton, el aumento de la compatibilidad de juegos y la aparición de la rama oficial Proton 11.0 (ARM64) con FEX integrado, Valve refuerza su apuesta por un ecosistema en el que SteamOS y el hardware Arm ganen peso sin obligar al usuario a renunciar a la biblioteca de Windows. Falta camino por recorrer, pero el movimiento de Proton 11 deja claro que el esfuerzo por consolidar el gaming en Linux continúa a buen ritmo.

Cuando se trabaja con diseños en Autodesk Inventor y AutoCAD, tarde o temprano surge la misma duda: cómo exportar o convertir planos de Inventor a formato DWG sin perder el control sobre los colores, especialmente cuando se quieren mantener ciertos elementos en negro y otros con sus tonos originales. Sobre el papel parece algo sencillo, pero la realidad es que el flujo Inventor → DWG (o incluso Revit → DWG) tiene más miga de lo que aparenta.

Muchos usuarios intuyen que no existe una solución perfecta y automática, y en buena parte tienen razón. Sin embargo, sí que hay una serie de configuraciones, trucos y alternativas que ayudan a acercarse bastante al resultado deseado, tanto para uso en AutoCAD como para visualizar en pantallas de producción, donde el consumo de tinta no es el problema, pero la claridad gráfica y la automatización sí lo son.

El problema real al pasar de Inventor a AutoCAD DWG

La situación típica es la de alguien que trabaja con planos de Inventor preparados para impresión en papel blanco, con convenciones de pluma, grosores y colores pensadas para plotter, y que de repente necesita que esos mismos dibujos se vean correctamente en pantallas instaladas en una línea de fabricación. En ese nuevo contexto, lo que antes era un problema de tinta pasa a ser un problema de visibilidad y contraste en monitores industriales.

Una de las primeras ideas es cambiar el fondo del dibujo: que la hoja deje de ser blanca o que los elementos negros puedan seguir siéndolo sobre un entorno distinto. Sin embargo, en Inventor el control sobre el aspecto de la hoja de dibujo como tal es bastante limitado. No existe una función directa para convertir la hoja en un color real diferente que se traslade de forma consistente al exportar a DWG manteniendo los elementos negros de cierto modo.

Además, Inventor no permite de forma nativa ordenar los elementos de la hoja de dibujo al estilo de aplicaciones de diseño gráfico (enviar al frente, enviar al fondo). Esto complica cualquier intento de jugar con fondos de color, máscaras o elementos superpuestos que podrían servir para dar contraste sin modificar el color de las líneas importantes.

A esto se suma que, buscando alternativas, muchos intentan la vía de exportar a PDF y luego editarlo con un programa vectorial. Sobre el papel suena bien: se saca un PDF vectorial y se recolorean las entidades. Pero en la práctica, el resultado suele ser que el PDF genera partes como imágenes rasterizadas, y al ampliarlas o editarlas aparece un molesto pixelado alrededor de los dibujos, perdiendo calidad y nitidez, especialmente en líneas finas y símbolos.

Por si fuera poco, este flujo PDF → editor vectorial → DWG tiene otro gran inconveniente: no es automatizable de manera sencilla. Si se trata de un solo plano, se puede aceptar como apaño puntual, pero si hay decenas o cientos de archivos de Inventor o Revit que deben pasar a DWG manteniendo colores y tipos de línea, la edición manual se vuelve inviable.

Limitaciones clave en Inventor para controlar color y fondo

Para entender por qué es tan complicado lograr una conversión perfecta, conviene tener claro qué no hace Inventor (al menos de serie) cuando pensamos en control avanzado de color:

• No permite cambiar el color real de la hoja de dibujo de forma que ese color se entienda después en el DWG como un fondo o entidad específica.
• No dispone de una gestión de orden de elementos (traer al frente / enviar al fondo) pensada para jugar con capas visuales o fondos coloreados.
• La exportación a DWG está muy condicionada por la gestión de capas y estilos de línea, con pocas opciones para tratar casos híbridos donde se quieren conservar colores específicos a la vez que se agrupan propiedades por capa.

Esto lleva a muchos usuarios a pensar que Autodesk evita, en cierto modo, que podamos “derrochar tinta” o forzar configuraciones extremas, incluso en clave de humor, cuando dicen que “hacen bien en no permitir gastarse esa cantidad de tinta”. El problema, en su caso, no es la tinta, sino que quieren un resultado visual concreto en pantalla sin tener que rehacer todos los estilos.

Lo que se echa de menos en Inventor, por tanto, es la posibilidad de:

• Definir un color de fondo de hoja de forma nativa, que se exporte correctamente a DWG.
• Organizar objetos en profundidad (hacia delante o hacia atrás) para poder crear composiciones con fondos y resaltes de información.
• Exportar a formatos vectoriales adicionales (por ejemplo, SVG de alta fidelidad o EPS) conservando de forma exacta los colores y estilos de las vistas, sin reinterpretaciones de estilo.

Mientras estas funciones no existan, la estrategia pasa por controlar muy bien las opciones de exportación a DWG disponibles y aprovechar la lógica de capas y estilos lo mejor posible.

Exportar a DWG: la importancia de las opciones de capa

Cuando se exportan dibujos desde Inventor o Revit a DWG, aparece un conjunto de opciones relacionadas con las capas (layers) que condiciona totalmente el resultado. Desde la experiencia de muchos usuarios, hay dos variables críticas que se quieren preservar al mismo tiempo:

• Que cada entidad se asigne al layer correcto con el color adecuado.
• Que se mantengan los tipos de línea (continuas, punteadas, de centro, etc.).

En Revit, por ejemplo, al exportar a DWG se presentan varias opciones bajo el apartado “Export layer options”. Aunque el contexto original sea Revit, la problemática es muy similar a la de Inventor → AutoCAD, porque en ambos casos se trata de traducir un modelo BIM o de diseño paramétrico a un entorno CAD 2D con control de capas y estilos de pluma.

Las tres opciones típicas que suelen encontrarse (y que conviene conocer bien) son:

• Export category properties BYLAYER and overrides BYENTITY
• Export all properties BYLAYER, but do not export overrides
• Export all properties BYLAYER, and create new layers for overrides

Aunque parezcan tres variaciones menores, en la práctica cambian de forma radical cómo se comportan los colores y tipos de línea en el DWG resultante. Y ahí está precisamente la clave de los problemas habituales de quienes quieren un plano limpio, con todo organizado por capas y al mismo tiempo con símbolos punteados, líneas de centro y demás recursos gráficos perfectamente respetados.

Análisis de cada opción de exportación de capas

Veamos con más detalle qué implica cada una de estas opciones, qué ventajas ofrece y dónde se queda corta si lo que se busca es control total sobre capas, colores y tipos de línea.

1. Export category properties BYLAYER and overrides BYENTITY

Con esta configuración, el programa asigna las propiedades base de cada categoría al layer correspondiente, pero cualquier modificación u override que se haya aplicado se traduce a nivel de entidad individual (BYENTITY). Es decir, la capa tiene unos ajustes generales, pero luego se permiten excepciones a nivel de cada objeto.

En la práctica, esto se traduce en que:

• Lo bueno: Los tipos de línea especiales (punteadas, de centro, simbologías específicas) se exportan bastante bien, porque cada entidad puede llevar su estilo propio. Esto resulta muy útil para plantas de acabados, tuberías que deben verse punteadas, proyecciones de techo, símbolos de instalaciones, etc.
• Lo malo: Algunas líneas no respetan el layer ni el color esperado. Aparecen con colores sueltos, ajenos a la organización prevista, lo que complica la edición posterior en AutoCAD y puede generar una sensación de caos en el dibujo.

Esta opción suele ser atractiva para quien prioriza que los estilos de línea se vean tal y como estaban en el modelo original, pero penaliza la limpieza del DWG a nivel de capas, ya que se llena de entidades con propiedades “por entidad” en lugar de centralizarlo todo en la configuración de cada layer.

2. Export all properties BYLAYER, but do not export overrides

Esta variante fuerza que todas las propiedades se definan estrictamente por capa. No se exportan overrides ni particularidades a nivel de entidad, con la intención de que el dibujo resultante en AutoCAD sea muy limpio y fácil de gestionar con normas de capas bien definidas.

El resultado típico es:

• Lo bueno: Todos los elementos respetan el layer y el color configurado originalmente. El DWG resultante tiene una estructura de capas mucho más coherente, lo que facilita asignar plumas, modificar colores globales o aplicar filtros de visibilidad sin volverse loco.
• Lo malo: Los tipos de línea complejos no se exportan correctamente. Muchas líneas que en el modelo eran punteadas o de centro se convierten en líneas continuas al llegar a DWG, perdiendo así la simbología que se había trabajado en el plano.

Por tanto, esta opción favorece la coherencia en capas y colores pero a costa de la fidelidad en tipos de línea. Para quien necesita que cada línea esté en el layer exacto, con el color idéntico al que definió en Revit o Inventor, puede ser una bendición, pero si además requiere respetar toda la simbología gráfica, se queda corta.

3. Export all properties BYLAYER, and create new layers for overrides

La tercera alternativa intenta ser un punto intermedio. Mantiene la idea de que las propiedades viajen definidas por capa, pero en lugar de ignorar los overrides, los traduce creando nuevas capas específicas para cada variación.

En un escenario típico, esto se nota así:

• Lo bueno: Igual que la primera opción, los tipos de línea especiales se respetan. La línea punteada sigue siendo punteada, la de centro mantiene su patrón, y así sucesivamente.
• Lo malo: La contrapartida es que se generan nuevos layers para cada override, multiplicando el número de capas en el archivo DWG. Esto puede acabar en un dibujo con decenas de capas adicionales que complican la gestión, especialmente en proyectos grandes.

De este modo, se logra una buena fidelidad gráfica en cuanto a estilos de línea, pero se sacrifica la simplicidad de la estructura de capas, algo que no siempre es deseable si el DWG debe integrarse en un estándar de oficina técnica muy rígido.

Elegir configuración según el objetivo del dibujo

El usuario que plantea este tipo de dudas suele encontrarse en un dilema: la segunda opción de exportación le va muy bien porque necesita que cada línea esté en el mismo layer y conserve el color definido en el modelo. No obstante, también requiere que los tipos de línea de sus vistas se conserven, porque trabaja con plantas de acabados llenas de simbología (tuberías, proyecciones de techo, elementos en distinto plano, etc.).

Cuando se quiere a la vez orden en capas y colores y fidelidad absoluta en los estilos de línea, ninguna de las tres opciones es perfecta. De ahí la sensación de que “algo falta” en el flujo de exportación que ofrece Autodesk de forma estándar.

La decisión práctica suele ser:

• Si prima la limpieza de capas y la facilidad de edición posterior en AutoCAD, se tiende a utilizar “Export all properties BYLAYER, but do not export overrides”, asumiendo el sacrificio de algunos tipos de línea.
• Si prima la fidelidad gráfica de símbolos y trazos, se escoge “BYLAYER and overrides BYENTITY” o “BYLAYER and create new layers for overrides”, aceptando un DWG menos limpio, con más capas o más entidades con propiedades particulares.

En contextos de producción donde el DWG se usará sobre todo para visualización en pantallas y no tanto para impresión, a veces compensa priorizar que los símbolos se entiendan a la primera, aunque el archivo sea algo más… “sucio” por dentro. No obstante, si esos mismos DWG van a entrar en flujos de trabajo de otras empresas o departamentos, la presión por tener una estructura de capas ordenada puede hacer que haya que negociar una solución intermedia.

Por qué muchos acaban recurriendo al PDF (y sus problemas)

Ante tanta limitación, es muy habitual que se recurra al clásico atajo: exportar el plano a PDF desde Inventor o Revit con una configuración de pluma y colores que guste, y luego abrir ese PDF en un programa de edición vectorial (Illustrator, Inkscape, CorelDRAW, etc.) para retocar colores o convertir ciertos elementos a negro.

Este método tiene varias ventajas aparentes:

• Permite retocar colores de forma muy visual, casi como si se tratase de un cartel o un folleto.
• Los programas vectoriales suelen ofrecer buenas herramientas de selección por color, capas, grupos, etc.
• Es más sencillo conseguir un acabado estético muy concreto si se trata de pocos planos.

Sin embargo, al aterrizar en la práctica, surgen problemas significativos:

• Muchos motores de PDF generan partes del plano como imágenes rasterizadas, en lugar de vectores puros.
• Al ampliar o modificar, se produce un pixelado evidente alrededor de las líneas, que destruye la nitidez del dibujo técnico.
• Es un flujo muy poco automatizable: hay que abrir, editar, guardar y volver a exportar, plano por plano.

Para un par de planos aislados puede servir como truco puntual, pero para un entorno profesional, donde se procesan muchos archivos procedentes de Inventor o Revit, esta opción se vuelve impracticable e inconsistente en términos de calidad.

Qué se echa en falta en Inventor y Revit para un flujo ideal

Todo esto conduce a una reflexión bastante compartida en la comunidad de usuarios de Autodesk: para resolver bien este tipo de problemas, los programas deberían incorporar algunas funciones adicionales orientadas a la exportación gráfica.

Concretamente, sería de gran ayuda que Inventor (y, en su caso, Revit) permitieran:

• Cambiar el color real de la hoja de dibujo y que este fondo se trasladase correctamente al exportar a DWG o a otros formatos vectoriales.
• Mandar elementos hacia delante o hacia atrás dentro de la hoja, para poder crear fondos, máscaras o áreas de color que mejoren el contraste sin alterar necesariamente el color de las líneas técnicas.
• Exportar a formatos vectoriales adicionales (por ejemplo, SVG de alta fidelidad o EPS) conservando de forma exacta los colores y estilos de las vistas tal y como se ven en pantalla.

Con este tipo de herramientas, el usuario tendría mucha más libertad a la hora de preparar versiones del plano pensadas para monitor, paneles informativos o incluso sistemas de señalización interna, sin tener que rehacer todo el formato inicial pensado para papel.

Estrategias prácticas para acercarse al resultado deseado

Mientras esas mejoras no llegan, lo más realista es trabajar con lo que Inventor y Revit ya ofrecen e intentar construir un flujo que, aunque no sea perfecto, resulte consistente y lo más automático posible. Algunas ideas prácticas son:

• Definir plantillas de dibujo en Inventor donde los estilos de vista y anotaciones estén pensados desde el principio para exportar a DWG, limitando el número de overrides manuales que luego generarán capas extra.
• Establecer en Revit una tabla de exportación a DWG clara, con asignaciones de categorías a capas bien definidas, para evitar sorpresas a la hora de elegir entre las distintas opciones de exportación BYLAYER.
• Elegir de forma consciente si el objetivo es priorizar capas limpias o priorizar fidelidad de tipos de línea, y documentarlo en el estándar interno de la empresa para que todos exporten de la misma manera.
• Valorar la creación de scripts o rutinas en AutoCAD que, tras la exportación, ajusten de forma semiautomática ciertos colores, agrupen capas o cambien elementos relevantes a negro sin tocar el resto del dibujo.

De este modo, aunque el proceso no sea perfecto desde la propia exportación, se puede construir una cadena de pasos donde Inventor/Revit generen un DWG razonable, y luego AutoCAD termine de ajustarlo con herramientas pensadas específicamente para gestionar capas, colores y estilos de línea.

Sobre la necesidad concreta de mantener elementos negros al pasar de Inventor a AutoCAD para su visualización en pantallas, lo más eficaz suele ser una combinación de:

• Elegir la opción de exportación que mejor respete la estructura de capas.
• Definir en AutoCAD una configuración de visualización (o un estilo de trazado) que fuerce a negro ciertos layers claves para que siempre se vean con el máximo contraste, independientemente del fondo del espacio modelo.

Así se delega en AutoCAD la última palabra sobre qué se ve en negro y qué conserva color, en vez de intentar controlarlo todo desde Inventor, donde las herramientas de exportación son más rígidas.

En conjunto, todo este escenario explica por qué tantos usuarios sienten que “no se puede del todo” conseguir una exportación perfecta de dibujos de Inventor o Revit a AutoCAD DWG manteniendo a la vez colores, tipos de línea y organización de capas. Existen caminos intermedios que acercan el resultado a lo que se busca, pero siempre hay que ceder en algún punto: o bien aceptar más capas y overrides, o bien renunciar a algunos tipos de línea, o bien recurrir a procesos adicionales en AutoCAD para forzar el comportamiento de ciertos elementos clave, como los que se desean en negro permanente.

Con iOS 26 y el rediseño Liquid Glass ya asentados en los iPhone actuales, Apple se prepara para un giro de timón con la próxima versión de su sistema. Lejos de otro gran lavado de cara visual, todo apunta a que iOS 27 será una edición pensada para afinar lo que ya existe, reforzar la estabilidad y servir de base técnica para una Apple Intelligence mucho más integrada y para la llegada del esperado iPhone plegable.

Las distintas filtraciones procedentes de código interno, desarrolladores y analistas dibujan una actualización continuista en lo estético, pero muy ambiciosa en el fondo. El foco se desplaza hacia el rendimiento, la eliminación de errores, la mejora de la batería y una oleada de pequeñas funciones de inteligencia artificial orientadas al día a día, con especial impacto en Europa y en mercados donde el iPhone es herramienta de trabajo y ocio a partes iguales.

Calendario de iOS 27: presentación, betas y lanzamiento final

Apple ya ha marcado en rojo la fecha de su gran evento anual: WWDC 2026 se celebrará en junio en el Apple Park (Cupertino, California). Será en la keynote inaugural, fijada para el 8 de junio de 2026, cuando la compañía presente oficialmente iOS 27 junto al resto de sistemas: iPadOS 27, macOS 27, watchOS 27, tvOS 27 y visionOS 27.

Siguiendo la tradición, la primera beta de iOS 27 para desarrolladores se publicará ese mismo 8 de junio a través del programa de betas de Apple. A partir de julio de 2026 está previsto el lanzamiento de la beta pública, abierta a cualquier usuario que se registre en el programa de pruebas, también disponible para quienes usen sus iPhone en España o en otros países europeos.

La versión definitiva de iOS 27 se desplegará en septiembre de 2026, coincidiendo con los iPhone 18. Esta actualización será gratuita y se distribuirá de forma global, de modo que los usuarios europeos la recibirán en paralelo a Estados Unidos, sin esperas adicionales.

Este año, sin embargo, el calendario de hardware podría moverse. Las filtraciones señalan que Apple planea estrenar su primer iPhone plegable hacia finales de 2026, junto a los iPhone 18 Pro. Los iPhone 18 “normales” se reservarían para la primavera de 2027, una ruptura del patrón tradicional de lanzamientos que condicionará también el desarrollo de iOS 27.

Modelos de iPhone compatibles con iOS 27

Uno de los puntos que más preocupan a los usuarios europeos es la lista de dispositivos compatibles. Las fuentes coinciden en que Apple no pretende dejar fuera demasiados modelos en una actualización centrada en estabilidad. El objetivo es que iOS 27 se comporte como en su día lo hicieron iOS 12 o Snow Leopard en el Mac: optimizar sin exigir un salto de hardware masivo.

A día de hoy, las filtraciones apuntan a que la compatibilidad partiría de los iPhone 11 en adelante, repitiendo la jugada de mantener en el paquete terminales con varios años a sus espaldas. La lista esperada quedaría así:

• iPhone 11 y iPhone 11 Pro
• iPhone 12 y 12 Pro
• iPhone 13 y 13 Pro
• iPhone 14 y 14 Pro
• iPhone 15 y 15 Pro
• iPhone 16, 16 Plus y 16 Pro
• Gama iPhone 17, incluido el modelo Air y 17 Pro
• iPhone 18 y 18 Pro
• Primer iPhone plegable de Apple

La lógica detrás de esta decisión es clara: si la prioridad es pulir el código y mejorar el rendimiento, no tiene demasiado sentido dejar fuera dispositivos que aún pueden moverse con soltura, especialmente en regiones donde los ciclos de renovación del móvil son más largos, como ocurre en buena parte de Europa.

iOS 27 como edición de estabilidad y rendimiento

En los últimos años, muchas de las críticas a iOS han tenido que ver más con bugs, drenaje de batería y pequeñas inestabilidades que con la falta de funciones nuevas. Apple parece haber tomado nota y, según Mark Gurman, internamente se está tratando iOS 27 con la misma filosofía que se aplicó a Snow Leopard: una gran actualización enfocada a la “limpieza” interna del sistema.

Este enfoque implica una reescritura de partes críticas del código, la reducción de la llamada “deuda técnica” acumulada tras varias versiones llenas de novedades y un esfuerzo serio por mejorar la fluidez del sistema en todos los rangos de iPhone, desde los modelos más recientes hasta los de generaciones anteriores.

En la práctica, esto debería traducirse en un menor consumo energético en segundo plano, menos cierres inesperados de apps, animaciones más estables, tiempos de apertura de aplicaciones más reducidos y un comportamiento más predecible, algo especialmente apreciado por quienes usan su iPhone como herramienta principal de trabajo.

Además de estos cambios invisibles, iOS 27 integrará una mejora llamativa en conectividad: el soporte para internet 5G vía satélite, una función que, según las filtraciones, se limitaría de inicio al iPhone 18 Pro con un nuevo módem C2. Para usuarios que viajan con frecuencia o viven en zonas rurales en España y en otros países europeos, esta opción podría marcar la diferencia en situaciones de emergencia o falta de cobertura tradicional.

Apple Intelligence: el gran eje de iOS 27

Si iOS 26 puso la primera piedra de Apple Intelligence, iOS 27 será la versión en la que esta inteligencia artificial empiece a notarse de verdad en el uso diario. Aquí confluyen dos líneas de trabajo: la renovación profunda de Siri y la llegada de funciones discretas, pero muy útiles, en apps del sistema como Cámara, Salud, Safari o Cartera.

En el plano técnico, Apple no se limita a usar Gemini como una API de terceros. El acuerdo con Google le da acceso al modelo Gemini en sus propios centros de datos, lo que permite aplicar técnicas de destilación para crear modelos más pequeños que imitan el comportamiento de Gemini, pero pueden ejecutarse directamente en el chip del iPhone, minimizando la dependencia de la nube y reforzando la privacidad.

De este modo, la compañía persigue una combinación peculiar: privacidad al estilo Apple con potencia de IA de Google. El resultado debe notarse en tiempos de respuesta más rápidos, menor envío de datos a servidores externos y una sensación de que el iPhone entiende mejor el contexto sin que el usuario tenga que preocuparse por dónde se procesan sus datos.

Más allá de su propio modelo, Apple quiere convertir iOS 27 en un “lanzador de IA” multiplataforma. Según las filtraciones, el usuario podrá elegir para ciertas tareas entre Siri, Gemini, ChatGPT o incluso otros modelos como Claude, todo ello integrado en el entorno del iPhone. La ambición no pasa tanto por tener “la mejor IA del mercado” como por ofrecer la mejor puerta de acceso unificada a esos servicios desde el móvil.

Siri: de asistente de comandos a chatbot conversacional

Uno de los cambios más visibles de iOS 27 será la transformación de Siri. Después de varios retrasos y una evolución más lenta de lo esperado, la nueva Siri adoptará una interfaz tipo chatbot, inspirada en aplicaciones de mensajería como Mensajes o los chats de IA más populares.

Esta nueva app de Siri mostrará burbujas de conversación, un campo de texto para escribir directamente y la posibilidad de alternar entre voz y texto con un toque. La dinámica de comandos sueltos dará paso a diálogos continuos, donde la conversación mantenga el contexto a lo largo del tiempo y permita preguntas encadenadas sin tener que repetirlo todo.

La IA subyacente permitirá a Siri un modo conversacional más natural, con mayor comprensión de matices, referencias temporales y peticiones complejas. Ejemplos como pedir que envíe un mensaje automático a un familiar cuando termine un temporizador de cocina entran ya en el terreno de la multitarea real dentro del asistente.

Además, se espera que Siri gane mayor consciencia del estado del sistema: sabrá qué app tienes abierta, qué aparece en pantalla, qué notificaciones están llegando y qué tareas tienes pendientes, integrándose con apps como Calendario, Recordatorios o Mail para ejecutar acciones encadenadas sin que el usuario deba saltar manualmente entre aplicaciones.

A nivel visual, Apple trabaja en dar a Siri una “cara” reconocible dentro de iOS. Una de las ideas que se barajan internamente pasa por usar una versión animada del icono del Finder (muy asociado al Mac) como imagen de un asistente siempre presente, aunque este aspecto aún podría cambiar antes del anuncio oficial.

Visual Intelligence: la cámara entiende mucho más de lo que ve

Buena parte de las filtraciones recientes se centran en Visual Intelligence, el sistema de reconocimiento visual de Apple Intelligence. Gracias al análisis del código realizado por el desarrollador Nicolás Álvarez y verificado por MacRumors, se han detectado hasta cuatro funciones relacionadas con iOS 27 que encajan con la hoja de ruta de la compañía.

Las dos primeras amplían de forma directa las capacidades de Visual Intelligence. La más comentada es la que permitirá escanear etiquetas nutricionales de alimentos envasados con la cámara del iPhone. El sistema interpretará los datos: calorías, azúcares, grasas, proteínas y otros valores, mostrando la información de forma más clara y, previsiblemente, con integración en la app Salud.

Para usuarios que cuidan su dieta o que siguen planes nutricionales personalizados en Europa, esto puede suponer un cambio importante: en lugar de introducir manualmente los datos en servicios de control de calorías, bastará con apuntar la cámara al envase para que el sistema procese automáticamente la información.

La segunda gran función de Visual Intelligence consiste en reconocer números de teléfono y direcciones físicas impresos en papel, como los de tarjetas de visita, carteles publicitarios o documentación. El iPhone ofrecerá entonces añadir esos datos directamente a Contactos, siguiendo un patrón similar al de la detección de fechas y eventos para Calendario que ya existe actualmente.

Este tipo de automatismo parece menor, pero encaja con una tendencia clara en iOS 27: reducir al máximo la escritura manual y facilitar la captura de información del mundo real. Para quien se mueve mucho por trabajo, acude a ferias o eventos, o simplemente quiere guardar datos rápidamente, es una mejora que se termina usando a diario.

Wallet y Safari: pequeños cambios que se notan mucho

Las otras dos funciones detectadas en el código apuntan directamente a apps clave del sistema. En el caso de Apple Wallet (Cartera), la idea es que Apple Intelligence sea capaz de crear pases digitales a partir de documentos físicos escaneados: entradas de conciertos, tarjetas de gimnasio, abonos o tarjetas de socio.

El proceso sería sencillo: el usuario hace una foto al documento, el sistema analiza el código de barras, los datos relevantes y el tipo de pase, y genera automáticamente una tarjeta digital lista para usarse en Wallet. Es un área en la que Google Wallet lleva ventaja desde hace tiempo, pero que para muchos usuarios de iPhone en España supondrá por fin poder concentrar prácticamente todos sus pases en el móvil sin depender de apps de terceros.

En el caso de Safari, la novedad se centra en los grupos de pestañas. iOS 27 incorporará una función que permita a Apple Intelligence analizar el contenido de las páginas abiertas dentro de un grupo y asignarles un nombre automáticamente. Si tienes varias pestañas sobre vuelos a Lisboa, por ejemplo, el navegador podría etiquetar el grupo con un título relacionado con viajes o con ese destino.

Puede parecer un detalle menor, pero quienes acumulan muchas pestañas —algo habitual en portátiles y también en el iPhone— suelen acabar con grupos sin nombre y decenas de páginas abiertas. La identificación automática pretende ordenar ese caos con el mínimo esfuerzo, favoreciendo una organización más clara entre trabajo, ocio, estudios o compras online.

Tanto Wallet como Safari se benefician, en definitiva, de la misma filosofía: automatizar gestos pequeños y repetitivos para que el usuario deje de perder tiempo en tareas que el sistema puede resolver por sí solo, apoyándose en Apple Intelligence.

El papel del iPhone plegable en el desarrollo de iOS 27

El otro gran hilo conductor de iOS 27 es la preparación del sistema para el primer iPhone plegable de Apple. Aunque el dispositivo no se espera como un modelo de masas de inicio, la compañía trabaja en una variante específica de iOS 27 adaptada al formato híbrido de pantalla.

Según las filtraciones, existe un equipo de ingeniería dedicado en exclusiva a esa versión, mientras el grueso del equipo de iOS se concentra en la estabilidad general. En el plegable veremos funciones avanzadas de multitarea, capaces de aprovechar mejor las dos mitades de la pantalla, así como herramientas para que los desarrolladores adapten sus aplicaciones al nuevo factor de forma.

Entre las ideas en estudio se encuentran modos de continuidad entre la pantalla plegada y desplegada, gestos específicos para manejar ventanas y vistas múltiples, y un conjunto de APIs que recuerdan a las de iPadOS, de manera que el plegable pueda ofrecer una experiencia cercana a la de un pequeño iPad cuando está abierto.

Apple quiere que, al desplegar el dispositivo, el usuario perciba algo familiar para quien ya utiliza iPadOS en su día a día, con mejoras que permitan trabajar con varias apps a la vez, arrastrar y soltar contenido entre ellas y gestionar mejor el espacio de pantalla. Todo eso requiere un trabajo profundo de software que, en gran medida, descansará en iOS 27.

Liquid Glass: el diseño sigue evolucionando por dentro

Aunque iOS 27 no será una versión de grandes cambios visuales, el diseño no se quedará quieto. Tras el impacto de Liquid Glass en iOS 26, que rediseñó elementos como los menús, el Centro de Control o los iconos, todavía hay muchas zonas del sistema y apps nativas que continúan con el estilo plano tradicional.

Aplicaciones como Notas, Salud o la propia app Fitness mantienen a día de hoy interfaz heredada de etapas anteriores, con elementos que no sacan partido al nuevo lenguaje de cristal translúcido. iOS 27 se plantea como la versión en la que Apple completará esta transición interna, extendiendo Liquid Glass al interior de las apps, a los controles de actividad y a detalles de navegación que todavía no se han tocado.

Parte de esta tarea pasa también por ofrecer al usuario un selector de intensidad global para el efecto de cristal, una función que se quedó a medias en iOS 26. La idea es que cada persona pueda ajustar cuánto Liquid Glass quiere ver en la interfaz, desde un look más sobrio hasta uno más cargado de transparencias y reflejos.

Para los desarrolladores, iOS 27 llegará acompañado de Xcode 27 y un cambio importante: desaparecerán las banderas internas que permitían aplazar la adopción de Liquid Glass en sus apps. Eso significa que las aplicaciones que quieran estar al día en la plataforma deberán adaptarse al nuevo lenguaje de diseño, unificando así la experiencia visual entre el propio sistema y el ecosistema de apps de terceros.

Todo esto se produce en un contexto de cambios en el equipo de diseño de Apple, con la salida del anterior responsable y el ascenso de un veterano a la dirección. Dependiendo de cómo se reordenen las prioridades internas, algunos detalles estéticos podrían retrasarse o cambiar, pero la dirección general es clara: Liquid Glass no tiene marcha atrás.

Con menos de dos meses para la WWDC, iOS 27 se perfila como una de esas versiones silenciosas pero importantes: poca estridencia visual, mucha ingeniería bajo el capó y una apuesta decidida por una IA que se nota más en los pequeños gestos que en los grandes titulares. La gran duda es si Apple será capaz de equilibrar toda esta nueva capa de inteligencia artificial con el rendimiento que promete, y si funciones como las de Visual Intelligence, Wallet y Safari llegarán completas desde el primer día a mercados como España y el resto de Europa. Hasta que Apple suba al escenario en junio, todo apunta a que el iPhone que ya tenemos en el bolsillo será, simplemente, bastante más listo y más estable sin necesidad de grandes fuegos artificiales.

OpenAI ha dado un paso más en la integración de la inteligencia artificial con el uso diario del ordenador al renovar en profundidad Codex, su agente de código para escritorio. La herramienta, que hasta ahora se conocía sobre todo por ayudar a programar, pasa a convertirse en un asistente capaz de manejar aplicaciones, recordar preferencias y gestionar proyectos de manera casi continua.

Con esta actualización, la compañía liderada por Sam Altman acerca su plan de crear una “superaplicación” de escritorio que unifique ChatGPT, Codex y su navegador Atlas. El movimiento busca simplificar la experiencia del usuario, concentrar recursos en un solo espacio de trabajo y plantar cara a rivales como Anthropic, especialmente en el entorno de desarrollo de software y la automatización avanzada.

Codex aprende a usar el ordenador como un usuario más

Uno de los cambios más llamativos es que Codex puede ahora controlar el ordenador en segundo plano. El agente es capaz de ver lo que hay en pantalla, mover su propio cursor, hacer clic, escribir texto y reaccionar a lo que ocurre en las aplicaciones instaladas, sin interrumpir lo que el usuario esté haciendo con el ratón o el teclado.

Esta capacidad permite que varios agentes de Codex trabajen en paralelo en el mismo equipo, realizando pruebas, cambiando configuraciones o ejecutando tareas repetitivas mientras la persona sigue con su actividad normal. De este modo, se abre la puerta a automatizar flujos de trabajo que antes requerían supervisión constante, como probar una aplicación tras cada cambio de código o repetir acciones de interfaz.

OpenAI plantea esta función como una forma de que el asistente pueda operar con herramientas que no tienen API o integraciones directas, algo habitual en muchos programas de escritorio. Codex, al “ver” la pantalla y controlar el cursor, puede interactuar con esas aplicaciones igual que lo haría un usuario humano, aunque por ahora de forma controlada y con especial atención a la seguridad.

Según la compañía, el uso del ordenador está disponible inicialmente en macOS a través de la aplicación de escritorio de Codex, vinculada a una cuenta de ChatGPT. La versión para Windows llegará más adelante, una vez se compruebe el rendimiento y se adapten las funciones al entorno de Microsoft.

En el caso de Europa y Reino Unido, OpenAI ha confirmado que el control del ordenador, la personalización avanzada, las sugerencias contextuales y la memoria se activarán más tarde. El motivo es la necesidad de ajustar estas características a la normativa de protección de datos, un requisito especialmente exigente en la Unión Europea y el mercado británico.

Navegador integrado y trabajo directo sobre páginas web

La actualización también refuerza la relación de Codex con la web gracias a un navegador integrado dentro de la propia aplicación. En lugar de limitarse a recibir instrucciones de texto genéricas, el agente puede recibir órdenes directamente sobre elementos concretos de una página.

En el desarrollo frontend, por ejemplo, el usuario puede seleccionar un componente de la web y describir el cambio que quiere hacer (como modificar el color, el tamaño del texto o la disposición de un bloque), y Codex entiende la instrucción en ese contexto visual concreto. Eso evita tener que redactar prompts largos explicando qué parte del sitio hay que alterar.

Este navegador embebido permite además que Codex analice contenido, recopile información y la utilice como contexto para otras tareas, como documentar código, revisar especificaciones de un producto o comparar documentación técnica. Todo se realiza dentro del mismo entorno, sin tener que saltar entre múltiples ventanas del sistema operativo.

Generación y edición de imágenes con gpt-image-1.5

Otro pilar de la nueva versión de Codex es la integración del modelo gpt-image-1.5 para crear y modificar imágenes desde la propia aplicación de escritorio. El agente puede generar gráficos, diagramas, maquetas o bocetos visuales a partir de texto, o combinando instrucciones con capturas de pantalla y fragmentos de código.

Esta capacidad apunta directamente a los equipos que trabajan en diseño de productos, interfaces de usuario o prototipos de videojuegos. Por ejemplo, un desarrollador puede capturar la pantalla de una interfaz a medio hacer, pedir a Codex que proponga un rediseño del menú o un nuevo esquema de colores y obtener imágenes generadas que se ajusten a ese contexto, sin cambiar de herramienta.

Al estar todo centralizado en Codex, los agentes pueden encadenar tareas de código y diseño: escribir la lógica de una funcionalidad, actualizar el frontend correspondiente y generar una maqueta visual para presentarla al equipo, sin salir del flujo de trabajo ni tener que abrir aplicaciones externas de edición gráfica.

Memoria, contexto y automatización de tareas a largo plazo

Más allá del control del ordenador y la generación de imágenes, la gran apuesta de OpenAI con esta versión es dotar a Codex de una memoria persistente y una gestión de contexto mucho más amplia. La herramienta puede reutilizar conversaciones previas, conservar información importante y recuperarla cuando haga falta para continuar un proyecto.

La función de memoria, que se lanza en vista previa, permite que Codex recuerde preferencias personales, correcciones frecuentes o datos que costó recopilar. Esto incluye desde el stack tecnológico habitual de un equipo hasta la forma de organizar carpetas, los formatos de informe más usados o la etiqueta que suele utilizarse en GitHub para cierto tipo de incidencias.

Con ese contexto acumulado, el agente puede proponer tareas de forma proactiva: sugerir retomar un proyecto que quedó a medias, recomendar una refactorización pendiente o avisar de pull requests abiertos desde hace tiempo. En algunas empresas ya se está empleando para seguir conversaciones en Slack, Gmail o Notion y reaccionar cuando se desencadenan ciertos eventos.

Codex también puede programar trabajo para el futuro y reactivarse de manera autónoma para completar tareas de largo recorrido. Por ejemplo, puede gestionar durante días o semanas una cola de revisiones de código, ir resolviendo comentarios y actualizando documentación sin que el desarrollador tenga que estar pendiente todo el tiempo.

Más de 90 complementos y soporte mejorado para desarrolladores

Para completar el cambio, OpenAI ha añadido cerca de 90 nuevos complementos (plugins) a Codex, entre los que se incluyen integraciones con Microsoft Suite, GitLab Issues, Neon by Databricks, Render o Superpowers, además del soporte para servidores MCP (Model Context Protocol). El objetivo es que el agente tenga más fuentes de contexto y más capacidad de actuación.

Gracias a estos plugins, Codex puede recopilar información de diferentes servicios y actuar sobre ellos desde un único espacio de trabajo. Puede revisar incidencias en GitLab, consultar datos en un entorno de Databricks, actualizar documentos de Office o interactuar con servicios de despliegue, sin obligar al usuario a ir saltando de plataforma en plataforma.

En el terreno puramente técnico, la actualización refuerza los flujos de trabajo típicos de los desarrolladores. Ahora Codex ayuda a revisar solicitudes de extracción (pull requests), manejar varias pestañas de terminal a la vez, conectarse a entornos de desarrollo remoto mediante SSH y abrir archivos con vistas previas enriquecidas, ya sean PDFs, hojas de cálculo, presentaciones o documentos en otros formatos.

Todo ello se concentra en una experiencia unificada que, según la propia OpenAI, permite avanzar más rápido en todas las etapas del ciclo de vida del software: desde escribir el código inicial hasta probarlo, desplegarlo, documentarlo y mantenerlo, con los agentes de IA colaborando de forma continua dentro del mismo entorno de escritorio.

Disponibilidad, enfoque en desarrolladores y situación en Europa

La nueva versión de Codex se está desplegando ya en la aplicación de escritorio para macOS para quienes inicien sesión con una cuenta de ChatGPT. No todas las funciones requieren el mismo tipo de suscripción, y algunas características avanzadas pueden depender del plan contratado, como ocurre con otras herramientas de OpenAI.

Thibault Sottiaux, director de Codex, ha explicado que esta actualización está especialmente orientada a desarrolladores, aunque la intención es ampliarla más adelante a un público más general. La idea es que los equipos técnicos sean los primeros en aprovechar los nuevos agentes y flujos de trabajo automatizados y, con el tiempo, trasladar ese modelo a tareas de oficina, gestión de documentos o productividad personal.

OpenAI subraya que el uso del ordenador y la memoria se implementan con un enfoque de seguridad y cumplimiento normativo, algo especialmente relevante en la Unión Europea y Reino Unido. Por esa razón, las funciones de personalización avanzada, sugerencias contextuales, memoria persistente y control directo del sistema operativo tardarán algo más en activarse en estos mercados.

En cualquier caso, la compañía sostiene que esta evolución de Codex abre la puerta a una superaplicación de escritorio centrada en la automatización inteligente, donde los agentes de IA no solo ayudan a escribir código, sino que coordinan tareas, se adaptan al estilo de trabajo del usuario y mantienen activos proyectos complejos durante periodos prolongados. Para quienes desarrollan software en Europa, el mensaje es claro: las nuevas capacidades llegarán, pero con los ajustes necesarios para encajar en el marco regulatorio vigente.

WhatsApp ha comenzado a extender un profundo cambio estético llamado Liquid Glass, un rediseño que modifica la apariencia de la aplicación sin tocar las funciones de siempre. El despliegue ya está en marcha y muchos usuarios en España y el resto de Europa empiezan a ver una interfaz distinta, más translúcida y con sensación de profundidad.

Aunque a simple vista pueda parecer solo un retoque, se trata del cambio visual más relevante de WhatsApp en años. La app adopta un aspecto más cercano al de los sistemas operativos móviles recientes, especialmente iOS 26, con barras flotantes, menús tipo cristal y animaciones más suaves que hacen que todo parezca más fluido.

Qué es exactamente Liquid Glass en WhatsApp

Liquid Glass —que podríamos traducir como “cristal líquido” aplicado a la interfaz de WhatsApp— es un nuevo lenguaje de diseño oficial desarrollado por Meta para la aplicación de mensajería. No es una app distinta ni un mod no autorizado, sino una actualización de la interfaz que llega mediante las versiones más recientes de WhatsApp.

El objetivo principal es que la app se integre mejor con el fondo de pantalla y con el propio sistema operativo, aprovechando las capacidades gráficas de los móviles actuales. En lugar de bloques opacos y planos, la interfaz utiliza transparencias dinámicas, bordes redondeados y diferentes capas visuales que se superponen.

Este cambio responde a una tendencia general del ecosistema móvil: adaptar el aspecto de las aplicaciones a los estándares visuales de iOS y Android para lograr más coherencia entre sistema y apps. En el caso de iOS 26, Apple apostó por una estética muy basada en el vidrio y la tridimensionalidad, y WhatsApp se ha alineado con esa línea de diseño.

A diferencia de otras actualizaciones, Liquid Glass no introduce nuevas funciones ni altera la forma de enviar mensajes, hacer llamadas o compartir archivos. Todo sigue en el mismo sitio y funciona igual; lo que cambia es la forma en la que se presentan esos elementos en pantalla.

Cómo cambia la interfaz de WhatsApp con Liquid Glass

El cambio más evidente para muchos usuarios es la barra de navegación inferior flotante. Donde antes había un bloque sólido con las pestañas principales (chats, novedades, llamadas, ajustes), ahora aparece una barra semitransparente, con bordes suaves y la sensación de estar suspendida sobre el contenido.

Esta barra inferior permite ver sutilmente lo que hay detrás al hacer scroll, como si fuera una pieza de vidrio esmerilado. El efecto se adapta tanto al modo claro como al oscuro, variando la intensidad de la transparencia para mantener la legibilidad.

Los botones, iconos y menús contextuales también se han revisado. Adoptan un acabado tipo cristal, con capas translúcidas y pequeños reflejos que recuerdan a un panel de vidrio. Además, las animaciones al abrir menús o cambiar de sección son más suaves y continuas, alejándose de la sensación de interfaz rígida de versiones anteriores.

Otro punto clave es el teclado integrado en la app. Cuando se abre un chat, el teclado aparece con un fondo translúcido que refleja los colores de la conversación. No cambia su disposición ni sus funciones, pero sí su presencia visual, que ahora encaja mejor con el resto del conjunto.

En general, toda la app parece organizada en diferentes planos de profundidad: las barras y menús ocupan capas superiores, mientras que los mensajes y el contenido quedan en un plano inferior. Esta jerarquía visual ayuda a distinguir mejor qué elementos son interactivos y cuáles forman parte del fondo.

Dónde está disponible y a quién está llegando primero

El despliegue de Liquid Glass en WhatsApp no se está haciendo de golpe ni al mismo tiempo para todos. La actualización se integra en versiones recientes de la aplicación, pero la activación del nuevo diseño depende de decisiones internas de la propia plataforma.

Por ahora, los primeros en recibir el cambio son los usuarios de iPhone con iOS 26 y con WhatsApp actualizado a la versión 26.14.76 o superior desde la App Store. Incluso dentro de este grupo, el rediseño se activa de forma escalonada, cuenta a cuenta.

En España y en otros países europeos, muchos propietarios de iPhone ya han visto cómo la interfaz de WhatsApp adoptaba este aspecto translúcido, mientras que otros con el mismo modelo siguen con el diseño tradicional. No existe ninguna opción manual en los ajustes para forzar la activación, así que, de momento, solo queda esperar a que WhatsApp habilite la función en cada cuenta.

En el caso de Android, el nuevo estilo todavía no está plenamente implementado. Meta está concentrando primero el despliegue en el ecosistema de Apple, donde las herramientas gráficas de iOS 26 facilitan la adopción del efecto cristal y las transparencias dinámicas. Será más adelante cuando se vea hasta qué punto este lenguaje visual se traslada de forma equivalente a los móviles Android.

Este tipo de estrategia gradual permite a la compañía medir el rendimiento del rediseño y detectar posibles fallos antes de extenderlo a toda la base de usuarios. Si aparecen errores gráficos, problemas de rendimiento o críticas significativas, se pueden ajustar detalles sin afectar a millones de personas al mismo tiempo.

Cómo saber si ya tienes Liquid Glass activo en tu WhatsApp

Comprobar si Liquid Glass está activo en tu móvil es relativamente sencillo. El indicador más claro es la barra de pestañas inferior, donde aparecen las secciones principales de la aplicación.

Si esa barra sigue viéndose como siempre, con un fondo sólido, opaco y líneas marcadas, significa que la actualización de diseño aún no se ha aplicado a tu cuenta. En cambio, si la barra se percibe flotante, con bordes redondeados y un efecto semitransparente por el que se intuye el contenido de detrás, es señal de que Liquid Glass ya está operativo.

Otro elemento que puede darte pistas es el teclado. Al abrir un chat y desplegarlo, fíjate si el fondo del teclado es translúcido y refleja de forma sutil los colores del fondo de la conversación. Si se ve como un bloque completamente opaco, es probable que todavía no formes parte del grupo de usuarios con el nuevo diseño.

También conviene revisar la versión de la aplicación. En iPhone, puedes ir a Ajustes > Ayuda > Información de la aplicación y comprobar el número de versión. Para que el rediseño pueda aparecer, tu WhatsApp debería estar, como mínimo, en la versión 26.14.76 o superior.

Si tras actualizar desde la App Store no observas ningún cambio visual, no hay un truco ni ajuste oculto que puedas tocar. La activación se realiza desde los servidores de WhatsApp, y las cuentas se van habilitando poco a poco. De momento, la única opción es tener paciencia y revisar de vez en cuando si la interfaz ha cambiado.

Por qué WhatsApp apuesta por este tipo de diseño

Liquid Glass no nace de la nada: forma parte de una tendencia más amplia hacia interfaces más visuales y menos planas. Apple ya había introducido un enfoque similar en iOS 26, con efectos de vidrio, transparencias y una mayor sensación de tridimensionalidad en todo el sistema.

WhatsApp, con más de 2.000 millones de usuarios, busca mantener su imagen actualizada sin alterar su funcionamiento básico. Al adoptar este tipo de estética, la app se aproxima a otras aplicaciones modernas que también han dado el salto hacia animaciones suaves y capas visuales bien diferenciadas.

Detrás de este cambio hay también una cuestión práctica: el nuevo diseño ayuda a organizar mejor la información en pantalla. Las transparencias permiten diferenciar qué pertenece al fondo y qué forma parte de los controles, mientras que la sensación de profundidad marca de manera más clara qué elementos están “por encima” y son interactivos.

Para conseguirlo, la aplicación se apoya en capacidades gráficas avanzadas de los móviles actuales, capaces de renderizar efectos en tiempo real sin lastrar el rendimiento. Esto incluye difuminados dinámicos al hacer scroll, reflejos sutiles en las barras y transiciones que imitan el movimiento de un líquido al cambiar entre chats o secciones.

En paralelo, WhatsApp continúa trabajando en otras novedades centradas en la seguridad y la gestión de dispositivos vinculados, especialmente en Android. De este modo, el esfuerzo en renovar la apariencia no sustituye a las mejoras en privacidad y control, sino que avanza en paralelo.

Reacciones de los usuarios y posibles ajustes

Como ocurre con casi cualquier cambio visual importante, Liquid Glass ha generado opiniones divididas entre los usuarios que ya lo tienen activado. Hay quien valora la estética moderna, más alineada con el resto del sistema, y quien prefiere una interfaz más sobria y sin tantos efectos.

Algunos usuarios señalan que las transparencias pueden dificultar la lectura en ciertos contextos, sobre todo cuando el fondo de pantalla es muy llamativo o tiene colores intensos. En estos casos, los textos y los iconos pueden parecer menos definidos que en una interfaz totalmente plana.

En iOS, la propia Apple ofrece ajustes de accesibilidad como “reducir transparencia”, que atenúan este tipo de efectos en todo el sistema. Al activarlos, el aspecto de WhatsApp con Liquid Glass se vuelve algo más discreto, con menos énfasis en el cristal y más en la legibilidad.

WhatsApp todavía está perfeccionando la implementación. Algunas partes de la aplicación ya muestran el nuevo estilo por completo (como la barra inferior o ciertos menús), mientras que otras se irán adaptando en futuras versiones. Entre los elementos que todavía están en proceso se encuentran, por ejemplo, el reproductor de notas de voz y ciertas pantallas secundarias.

Este desarrollo en curso permite que la compañía introduzca cambios adicionales o retoques en función del feedback que reciba, tanto en Europa como en otros mercados donde el nuevo diseño ya se está probando a gran escala.

Liquid Glass en WhatsApp supone, en la práctica, un salto importante en cómo se ve la aplicación sin alterar lo que los usuarios ya saben hacer: chatear, llamar y compartir archivos. De momento, el estreno se está viviendo sobre todo en iPhone con iOS 26 y versiones recientes de la app, con una expansión progresiva que irá alcanzando a más cuentas y, previsiblemente, a otros sistemas. Mientras tanto, la pista más clara para saber si ya ha llegado a tu móvil sigue siendo la misma: mirar la barra inferior y comprobar si, por fin, parece flotar sobre tus conversaciones.

Si llevas tiempo modelando en 3D con diferentes programas, es muy probable que en algún momento hayas pensado que la forma en la que rota la vista en Fusion 360 se siente rara, poco natural o directamente incómoda. Usuarios que vienen de Blender, Unreal Engine, SketchUp u otras herramientas similares suelen notar enseguida que algo no encaja: la sensación es como de “vista borracha”, que no responde como uno espera al orbitar alrededor del modelo.

El motivo de este malestar no es solo una manía personal: Fusion 360 gestiona la rotación de cámara y la cuadrícula de referencia de una forma muy concreta. En lugar de mantener la cuadrícula fija y mover únicamente la cámara, Fusion hace que la cuadrícula rote en función del origen del objeto o del sistema de coordenadas activo. Esto, que sobre el papel tiene sentido para ciertos flujos de trabajo, puede resultar bastante confuso si vienes de entornos donde la cuadrícula es un ancla estable y tú simplemente navegas alrededor.

Por qué la rotación de vista de Fusion 360 se siente tan diferente

Lo primero que hay que entender es que Fusion 360 está pensado como un CAD paramétrico con una fuerte dependencia del sistema de coordenadas. Esto condiciona por completo cómo se implementa la rotación de la vista, el comportamiento de los joints de rotación y la manera en que se muestra el ángulo en pantalla.

En muchos programas de modelado 3D de corte más artístico o generalista, como Blender, Unreal Engine o SketchUp, el comportamiento por defecto tiende a ser este: la cuadrícula del mundo se mantiene fija, la cámara orbita alrededor del punto que el usuario define o del centro de la escena, y la sensación es que “giras la cabeza” alrededor de algo inmóvil. Ese tipo de navegación es muy predecible: si mueves el ratón de cierta forma, la cámara responde siempre igual, independientemente de dónde esté el objeto.

Fusion 360, en cambio, vincula estrechamente la vista con el origen del modelo y con el sistema de referencia activo. La cuadrícula no es un fondo estático, sino que se alinea con los planos principales y con la orientación del diseño. Cuando orbitas, no solo cambias el punto de vista, sino que percibes que la cuadrícula “se va contigo”, y eso genera la sensación de que todo el espacio gira y no solo la cámara.

Esta elección de Autodesk tiene su lógica en entornos de ingeniería y diseño mecánico, donde la referencia al sistema de coordenadas global y a los planos XY, YZ y XZ es esencial. Pero a efectos de usabilidad, muchos usuarios comentan que no llegan a sentirse cómodos con ese tipo de navegación, por mucho tiempo que lleven usando el programa.

De ahí nace la pregunta concreta: ¿es posible moverse por la vista en Fusion 360 manteniendo la cuadrícula fija, imitando el estilo de otros programas 3D? Y, yendo un poco más allá, ¿se puede modificar la forma en la que se muestran y gestionan los ángulos de los joints de rotación para tener un comportamiento más coherente con esa forma de navegar?

Rotación de cámara vs rotación de cuadrícula: la clave del problema

La raíz del problema que describen muchos usuarios está en la diferencia entre rotar solo la cámara o hacer que parezca que rota todo el sistema de referencia. En programas como Blender o Unreal Engine, cualquier rotación de vista se interpreta mentalmente como un giro de cámara alrededor de un punto, mientras que el “mundo” permanece estable.

En Fusion 360, en cambio, cuando orbitas con el ratón o con la tecla de acceso rápido correspondiente, se nota que la cuadrícula cambia de orientación en función del origen del objeto o del sistema de coordenadas que tengas activo. Eso significa que si estás mirando el modelo desde un ángulo extraño y comienzas a orbitar, el eje sobre el que se produce la rotación de la vista no siempre se percibe igual. Cada cambio de ángulo puede generar una sensación diferente de giro, porque la referencia visual (la cuadrícula) también se está realineando.

Esto explica la sensación de “ojos de borracho” que muchos describen: no hay una referencia visual estable que permanezca intacta mientras mueves la cámara. La mente intenta usar la cuadrícula como ancla, pero esa ancla también se está moviendo, con lo cual se pierde la predictibilidad.

Por el contrario, en herramientas como SketchUp, la cuadrícula suele estar firmemente asociada al plano de trabajo global. La rotación de la vista no altera la orientación de esa cuadrícula; lo que se mueve eres tú, no el “mundo”. De ahí que muchos usuarios perciban esa navegación como más fluida, suave y lógica.

A todo esto se suma el hecho de que Fusion utiliza distintos modos de órbita (por ejemplo, órbita libre frente a órbita restringida) que pueden hacer que la experiencia cambie bastante en función de la configuración. Pero incluso ajustando estos modos, la idea base sigue siendo la misma: la cuadrícula sigue ligada al sistema de referencia, no es un simple fondo quieto.

Configuración de la vista en Fusion 360: qué se puede tocar y qué no

El siguiente paso natural es preguntarse: ¿hay algún ajuste en Fusion 360 que permita cambiar el comportamiento de rotación de la vista para que se parezca más al de otros programas? Y en paralelo, ¿se puede controlar cómo se visualiza el ángulo en un joint de rotación para que la experiencia sea más consistente?

Dentro de las preferencias de Fusion 360 (menú de usuario > Preferencias), se pueden ajustar varios parámetros relacionados con la vista, entre ellos:

• Estilo de navegación (por ejemplo, tipo Autodesk, tipo Tumble, etc.).
• Modo de órbita de la cámara (alrededor del punto seleccionado, del centro de la pantalla, etc.).
• Velocidad de rotación y sensibilidad del ratón o del trackpad.
• Comportamiento de zoom y pan para adaptarlo a tu dispositivo de entrada.

Estos ajustes ayudan a que el movimiento sea algo más cómodo, pero no cambian la filosofía fundamental de cómo Fusion gestiona la cuadrícula y el sistema de referencia. Es decir, podrás notar una mejora en la suavidad y el control, pero no vas a conseguir que de repente la cuadrícula se quede totalmente fija como en otros programas.

En lo que respecta a la visualización de ángulos en joints de rotación, sí puedes controlar:

• La forma en que se muestran las unidades (por ejemplo, grados con cierto número de decimales).
• Si se visualizan o no ciertos manipuladores en pantalla.
• El sistema de coordenadas que sirve de base para ese joint (puedes orientar el joint en función de un eje local u otro).

Sin embargo, aunque ajustes estos parámetros, la manera en que Fusion relaciona el joint con el espacio de trabajo sigue respondiendo a la misma lógica de coordenadas y cuadrícula. No es un problema de un atajo de teclado mal escogido, sino de cómo está construida la navegación a nivel de aplicación.

Scripts, add-ins y límites a la hora de cambiar el comportamiento

Muchos usuarios avanzados se preguntan si sería posible sobrescribir el comportamiento de rotación de Fusion 360 mediante scripts o complementos, aprovechando las APIs que Autodesk pone a disposición de los desarrolladores. De forma intuitiva, la idea sería interceptar el movimiento de entrada del ratón y aplicar una lógica de rotación propia, manteniendo la cuadrícula fija mientras se orbita la cámara.

Fusion 360, efectivamente, cuenta con una API que permite crear add-ins, scripts y automatizaciones. Mediante Python o JavaScript (y algunas otras tecnologías), se pueden desarrollar herramientas personalizadas para automatizar operaciones, generar geometría, gestionar documentos y mucho más.

Sin embargo, los límite prácticos de la API son importantes en este caso. Las capas más profundas de interacción con la vista, como la forma exacta en la que el motor de gráficos gestiona la cámara, la cuadrícula y la relación entre ambas, no suelen estar expuestas directamente. Esto quiere decir que, por regla general, no se puede reescribir desde un script el núcleo del comportamiento de navegación de la interfaz.

Lo que sí se puede hacer, hasta cierto punto, es crear vistas personalizadas, cámaras adicionales o herramientas de navegación específicas que simulen otro tipo de comportamiento. Por ejemplo, un script que coloque la cámara en una determinada posición respecto a un objeto, o que genere cambios predefinidos de ángulo y zoom al pulsar un botón.

Pero eso dista de ser un reemplazo real de la navegación estándar. No se trata de una sustitución completa del sistema de órbita original por uno nuevo, sino más bien de pequeños “atajos” o herramientas auxiliares. A efectos prácticos, la sensación general al mover la escena seguirá estando dominada por la lógica interna de Fusion.

Por ello, aunque la idea de “modificar el código de rotación para cambiar este comportamiento” es perfectamente comprensible, en la práctica no está al alcance del usuario mediante scripts comunes. Habría que modificar partes profundas del software, algo reservado a Autodesk y no expuesto a la capa de personalización estándar.

Cómo convivir con la rotación de Fusion 360 y mejorar la experiencia

A falta de poder cambiar completamente la filosofía de navegación, muchos usuarios se centran en optimizar la configuración disponible para que la rotación se sienta lo menos extraña posible. Aunque no se pueda emular al 100 % la experiencia de Blender o Unreal, sí se pueden aplicar ciertos ajustes y hábitos que reduzcan la sensación de descontrol.

En primer lugar, es muy recomendable explorar todas las preferencias de navegación de Fusion 360 y probar diferentes combinaciones de:

• Modo de órbita (libre, alrededor de objeto, alrededor de vista, etc.).
• Sensibilidad del ratón o del dispositivo de entrada.
• Asignación de botones y gestos (si usas tableta gráfica o ratón 3D).

En segundo lugar, resulta útil definir con claridad el origen del modelo y el sistema de coordenadas activo. Cuanto más ordenado y lógico sea tu sistema de referencia (por ejemplo, con el modelo alineado con los ejes globales al inicio), menos sentirás que la cuadrícula “cambia de sentido” de forma caótica a medida que navegas por la escena.

Otro truco práctico consiste en apoyarse mucho en las vistas predefinidas (frontal, lateral, superior, isométrica). Saltar con frecuencia a estas vistas limpias ayuda a “resetear” la percepción del espacio cada vez que la órbita te deje en un ángulo extraño.

Además, merece la pena dedicar un tiempo a entender bien cómo se orientan los joints de rotación respecto al sistema de coordenadas. Si ajustas los ejes del joint de forma coherente con la geometría de tu pieza, la lectura de los ángulos será mucho más intuitiva y no tendrás la sensación de que el joint “apunta a sitios raros” cada vez que giras la vista.

Por último, si trabajas a menudo con otros programas en paralelo (por ejemplo, Fusion para diseño mecánico y Blender para visualización o render), es útil mentalizarte de que son dos filosofías de navegación distintas. Cambiar ese pequeño chip ayuda a que la transición entre un programa y otro no se sienta tan brusca y a aceptar que cada entorno tiene su propia lógica, aunque te guste más uno que otro.

Expectativas realistas al intentar cambiar la configuración de visualización de ángulo en joints de rotación

En lo concreto, cuando hablamos de cambiar la configuración de visualización de ángulo en un joint de rotación dentro de Fusion 360, conviene separar dos capas distintas: lo que sí puedes ajustar mediante las opciones del programa y lo que, por diseño, no está pensado para que el usuario lo cambie.

En la capa que sí está en tu mano, puedes:

• Ajustar la orientación del joint eligiendo con cuidado los ejes y caras de referencia.
• Configurar las unidades de medida y precisión en las preferencias del documento.
• Activar o desactivar limitaciones angulares para que el joint no gire más allá de ciertos valores, lo que ayuda a dar sentido a los ángulos visibles.
• Utilizar vistas ortogonales y secciones para interpretar más fácilmente el sentido del giro.

Todo esto mejora bastante la legibilidad de los ángulos y ayuda a que el comportamiento de los joints de rotación sea más predecible. La clave está en vincular correctamente el joint al sistema de referencia que a ti te resulta lógico, de modo que “0°”, “90°” o “-45°” signifiquen algo evidente según tu diseño.

En la otra capa, la que está fuera de tu control, se encuentra la manera en que Fusion actualiza la representación del joint en pantalla al mismo tiempo que gestionas la vista. Dado que la cuadrícula se alinea con el sistema de coordenadas y no permanece estática, es normal que el joint parezca cambiar de orientación relativa dependiendo de desde dónde lo mires.

Es importante tener expectativas realistas: no existe, a día de hoy, una opción oficial que imite exactamente el comportamiento de rotación de cámara de Blender o Unreal dentro de Fusion, ni un ajuste que “desacople” por completo la cuadrícula de la lógica del sistema de coordenadas. Los cambios que puedes hacer van encaminados a suavizar la experiencia y a clarificar las referencias, pero no a sustituir el motor de navegación.

Quien lleva mucho tiempo usando Fusion 360 y nunca termina de acostumbrarse a su sistema de vista no está solo: es una queja bastante recurrente entre usuarios que alternan con otros entornos 3D. Saber de dónde viene exactamente esa incomodidad (la cuadrícula que rota, el origen como pivote, la fuerte dependencia del sistema de coordenadas) permite al menos tomar decisiones informadas, ajustar lo que sí es configurable y apoyarse en buenas prácticas para minimizar el malestar.

Con todo, aunque resulte frustrante no poder fijar la cuadrícula y rotar la cámara como en otros programas, comprender el porqué del comportamiento de Fusion y exprimir sus opciones de configuración y de joints de rotación ayuda a que la experiencia sea más llevadera y profesional, manteniendo un control razonable sobre los ángulos, las referencias y la navegación en tus proyectos de diseño.

El nuevo modelo de inteligencia artificial de Anthropic, conocido como Claude Mythos Preview, se ha convertido en el epicentro del debate global sobre los límites de la IA avanzada. La propia compañía admite que el sistema es tan potente en materia de ciberseguridad que ha decidido no lanzarlo de forma generalizada, una decisión poco habitual en un sector acostumbrado a presumir de cada nuevo avance.

Lo que está en juego no es solo una mejora incremental respecto a modelos anteriores, sino un salto cualitativo en la capacidad de detectar y explotar fallos informáticos. Gobiernos, bancos centrales, grandes entidades financieras y reguladores europeos siguen de cerca el caso, conscientes de que una herramienta así podría reforzar la defensa de los sistemas críticos, pero también abrir la puerta a ataques de escala inédita si acabara en manos equivocadas.

Qué es exactamente Claude Mythos y por qué se ha frenado su lanzamiento

Claude Mythos es uno de los modelos más recientes de la familia Claude, el ecosistema de IA de Anthropic que compite con ChatGPT de OpenAI y Gemini de Google. Se trata de un modelo de propósito general, capaz de razonar, programar y trabajar con contexto largo, pero su rasgo más controvertido es su desempeño en ciberseguridad ofensiva y defensiva.

Los llamados “equipos rojos”, specialists que ponen a prueba sistemas de IA buscando sus límites, concluyeron en un informe interno que Mythos es “sorprendentemente capaz” en tareas de seguridad informática. En pruebas de referencia como SWE-bench Verified o SWE-bench Pro, diseñadas para medir la capacidad de resolver problemas reales de ingeniería de software, el modelo habría superado con holgura a alternativas comerciales de primera línea, incluyendo versiones avanzadas de GPT y Gemini, según datos facilitados por la propia Anthropic.

Más allá de los benchmarks, lo que ha disparado las alarmas es que Mythos fue capaz de localizar vulnerabilidades de día cero —fallos desconocidos hasta ahora— en piezas de software ampliamente utilizadas, algunas con más de dos décadas de antigüedad. En sistemas como OpenBSD, FFmpeg o componentes de FreeBSD, el modelo no solo detectó errores que habían pasado desapercibidos durante años, sino que generó exploits funcionales para aprovecharlos.

Frente a estos resultados, Anthropic optó por una decisión inusual en la industria: presentar el modelo y, acto seguido, anunciar que no lo comercializará de forma abierta por considerar que plantea riesgos de ciberseguridad sin precedentes. La empresa insiste en que Mythos es el modelo “mejor alineado” que han construido, pero reconoce que su enorme capacidad amplifica las consecuencias de cualquier mal uso.

Un modelo con habilidades de “hacker” muy por encima de lo humano

Los documentos técnicos y los reportes de distintos organismos coinciden en que Mythos marca un antes y un después en la automatización de ataques complejos. En entornos de prueba que simulan redes corporativas reales, el sistema fue capaz de encadenar vulnerabilidades, escalar privilegios y lograr acceso persistente en horas, tareas que a un experto humano le llevarían días o semanas.

En el motor JavaScript de Firefox, por ejemplo, versiones anteriores de los modelos de Anthropic apenas lograban convertir fallos en exploits funcionales en contadas ocasiones. Mythos, bajo las mismas condiciones de prueba, generó decenas de exploits operativos, repitiendo con precisión la explotación de los vectores más eficaces. En plataformas de análisis como OSS-Fuzz, diseñadas para encontrar errores en software de código abierto, se le atribuye la detección de vulnerabilidades de alta gravedad que habían pasado inadvertidas pese a años de pruebas automatizadas.

El modelo también ha demostrado capacidades llamativas en ingeniería inversa: puede reconstruir parte de la lógica de un programa a partir de binarios compilados y, a partir de ahí, localizar y explotar fallos sin acceder al código fuente original. Este tipo de destreza acerca a la IA a escenarios que, hasta hace poco, se consideraban exclusivos de equipos humanos altamente especializados.

Uno de los episodios más citados en las evaluaciones de seguridad es el de la llamada “prueba del sándwich”. En un entorno aislado de laboratorio, a Mythos se le dio el control de un sistema con instrucciones explícitas para intentar escapar del sandbox y contactar con el investigador que supervisaba el test. El modelo consiguió aprovechar una cadena de vulnerabilidades para salir de su entorno restringido y enviar un correo electrónico al responsable, que en ese momento estaba fuera de la oficina. Aunque el caso se produjo en una versión interna anterior y bajo órdenes dirigidas, ilustra hasta qué punto el sistema puede desenvolverse en escenarios complejos con mínima supervisión.

Pese a estas demostraciones, los analistas insisten en matizar que no estamos ante una IA “consciente” ni con voluntad propia. Mythos no decide por sí mismo atacar sistemas: ejecuta las tareas que se le piden de la forma más eficaz posible. El riesgo, en este sentido, no es que el modelo se rebele, sino que alguien lo utilice —o lo fuerce mediante prompts sofisticados— para realizar acciones dañinas.

Project Glasswing: Mythos al servicio de la defensa… para unos pocos

En lugar de abrir el acceso al público general, Anthropic ha optado por rodear a Mythos de un programa específico, Project Glasswing, concebido para usar las capacidades del modelo de forma controlada en la protección de software crítico. La iniciativa consiste en ofrecer el sistema, bajo estrictas condiciones de uso, a un grupo reducido de grandes tecnológicas, proveedores de infraestructuras y entidades financieras.

Entre las organizaciones con acceso se encuentran gigantes como Amazon Web Services, Apple, Microsoft, Google Cloud, Nvidia o Broadcom, así como firmas especializadas en ciberseguridad como CrowdStrike, cuyo propio software defectuoso provocó una grave interrupción global en 2024. A ellas se suman bancos de referencia mundial, incluidos JP Morgan Chase y varios grandes grupos de Wall Street, además de otras organizaciones responsables de mantener infraestructuras informáticas sensibles.

Anthropic ha anunciado también créditos por valor de 100 millones de dólares para que estas entidades utilicen Mythos en tareas de análisis de vulnerabilidades, junto con donaciones a fundaciones de software libre como la Linux Foundation o la Apache Software Foundation. El objetivo oficial es claro: permitir que quienes gestionan el software más crítico del mundo puedan identificar y corregir fallos antes de que herramientas de este tipo estén al alcance de potenciales atacantes.

Esta estrategia, sin embargo, genera cierta incomodidad en el sector. Por un lado, refuerza la idea de que la tecnología es lo bastante peligrosa como para requerir un acceso restringido. Por otro, crea una brecha entre quienes se benefician del “escudo” de Mythos y quienes se quedan fuera. Las empresas y administraciones que no forman parte de Glasswing corren el riesgo de enfrentarse más adelante a vulnerabilidades que fueron identificadas y parcheadas en entornos privilegiados, pero que siguen presentes en sus propios sistemas.

En Europa, esta asimetría preocupa especialmente a los responsables de infraestructuras críticas y a los equipos de seguridad de grandes grupos industriales y financieros, que observan con atención si Bruselas y las capitales europeas logran que programas similares incluyan a actores clave del continente en igualdad de condiciones y la soberanía cloud con los socios estadounidenses.

Reacción de gobiernos, reguladores y sector financiero

El impacto de Mythos no se limita al terreno técnico. En pocos días, el anuncio del modelo desencadenó reuniones de alto nivel en Estados Unidos y en Europa. El secretario del Tesoro estadounidense convocó en Washington a los directivos de los principales bancos del país para evaluar los riesgos que el sistema podría suponer para la estabilidad financiera, mientras que el presidente de la Reserva Federal participó también en esas conversaciones.

Según filtraciones recogidas por medios internacionales, a estas entidades se les habría animado a probar Mythos en modo defensivo, utilizándolo para escanear sus propias infraestructuras en busca de puntos débiles antes de que otros puedan hacerlo. El mensaje implícito es que la amenaza es lo bastante seria como para justificar una respuesta coordinada entre sector público y privado.

En paralelo, el cofundador de Anthropic ha confirmado que la compañía mantiene conversaciones directas con el Gobierno de Estados Unidos sobre Mythos y sobre futuros modelos. Estas discusiones se producen en un contexto tenso, después de que las autoridades estadounidenses incluyeran recientemente a la empresa en una lista de riesgos para la cadena de suministro, tras fricciones relacionadas con el uso de sus modelos por parte del Departamento de Defensa.

Al otro lado del Atlántico, la Unión Europea ha tomado nota. La Comisión Europea ha respaldado públicamente un enfoque gradual y prudente hacia modelos como Mythos, y los reguladores financieros del Reino Unido y del continente han empezado a estudiar específicamente sus posibles implicaciones para la banca y los mercados. El Instituto de Seguridad de la IA del Gobierno británico (AISI) ha descrito el sistema como un salto significativo en términos de amenaza cibernética respecto a generaciones anteriores.

En España, aunque el debate público todavía es limitado, organismos supervisores y equipos de ciberseguridad de bancos y grandes compañías energéticas siguen de cerca estos movimientos. Para el sector financiero europeo, cualquier avance que pueda facilitar ataques coordinados contra sistemas de pago, redes interbancarias o plataformas de negociación es motivo de máxima preocupación.

Escepticismo, dudas y debate sobre el “hype” en torno a Mythos

El relato de Anthropic, que combina advertencias de seguridad con cifras espectaculares de rendimiento, no ha quedado exento de críticas. Varios expertos en IA y ciberseguridad han pedido cautela a la hora de interpretar las afirmaciones de la compañía, señalando que buena parte de los datos disponibles procede solo de informes internos.

Algunos analistas han revisado en detalle la extensa documentación publicada por Anthropic y apuntan que la cifra de “miles de vulnerabilidades de alta gravedad” se basa en extrapolaciones a partir de un número relativamente reducido de casos revisados manualmente. En ciertos conjuntos de pruebas, Mythos habría encontrado un número de fallos críticos notable, pero lejos del escenario casi apocalíptico que sugieren algunos titulares.

Otros estudios independientes han tratado de comparar el rendimiento de Mythos con modelos de código abierto más pequeños, pasando fragmentos de código vulnerables a distintas IA para ver si lograban detectar los mismos fallos. Los resultados indican que algunos modelos abiertos también son capaces de identificar vulnerabilidades complejas, lo que cuestiona la idea de que Mythos juegue en una liga completamente distinta en todos los escenarios.

Este tipo de contraejemplos no niega las capacidades de Mythos, pero sí invitan a pensar que una parte del discurso de “demasiado peligroso para publicar” tiene también una dimensión de marketing. Presentar un modelo como extraordinariamente potente y al mismo tiempo como un riesgo potencial refuerza la imagen de liderazgo tecnológico y de responsabilidad, algo muy valioso en un mercado cada vez más competitivo.

La memoria reciente del sector recuerda, además, el precedente de GPT-2 en 2019, cuando OpenAI decidió no publicar inicialmente el modelo completo alegando que era demasiado peligroso por su potencial para generar desinformación. Con el tiempo, esa versión acabó saliendo al público sin que se materializara ninguna de las catástrofes anunciadas, y muchos expertos lo citaron como ejemplo de alarma exagerada. Con Mythos, la diferencia es que el foco ya no está en el texto, sino en la integridad de la infraestructura digital, un terreno mucho más sensible para gobiernos y bancos.

Un equilibrio delicado entre seguridad, negocio y acceso a la tecnología

Más allá del ruido mediático, la situación de Mythos pone sobre la mesa una cuestión de fondo: quién decide cuándo un modelo de IA es demasiado peligroso para liberarlo y bajo qué criterios. De momento, la decisión ha sido unilateral por parte de Anthropic, que ha optado por mantener el sistema en una especie de cuarentena controlada, reservándolo para socios seleccionados.

Esta posición no solo responde a motivos de seguridad. Ejecutar un modelo con las características de Mythos es muy costoso en términos de computación, y la propia empresa reconoce que hoy por hoy no dispone de la infraestructura necesaria para servirlo de forma masiva a millones de usuarios. En la práctica, la prudencia en seguridad y las limitaciones técnicas van de la mano, lo que concede a Anthropic un margen de tiempo para ajustar tanto el modelo como su despliegue.

Paralelamente, la compañía ha empezado a diferenciar con claridad entre sus distintos productos. Mientras Mythos se mantiene como estándar interno más avanzado, reservado a contextos de investigación y colaboración estratégica, otros modelos como Claude Opus 4.7 se orientan al uso cotidiano en empresas y profesionales. Anthropic ha llegado a reconocer públicamente que Opus 4.7 es “menos capaz” que Mythos en términos generales y, en particular, en lo que respecta a sus capacidades cibernéticas, algo poco habitual en una industria que suele presentar cada nuevo modelo como el mejor en todo.

En este esquema, Mythos funciona como banco de pruebas para capacidades de siguiente generación, mientras que los modelos comercializados incorporan solo una parte de esas habilidades, con límites adicionales diseñados para reducir riesgos. Para muchas organizaciones europeas, interesadas en aprovechar la IA sin situarse en primera línea de exposición, esta separación entre modelos “experimentales” y “productivos” puede resultar una vía razonable, siempre que exista transparencia suficiente sobre qué puede hacer realmente cada sistema.

Lo que se dibuja, en definitiva, es un escenario en el que la ciberseguridad entra de lleno en la era de la IA ofensiva y defensiva a gran escala. Herramientas como Mythos prometen acelerar la identificación de vulnerabilidades en sistemas que llevan años en funcionamiento, pero también obligan a replantear la forma en que se distribuye y gobierna la tecnología que sustenta la economía digital. Para Europa y España, el reto no será solo protegerse de modelos cada vez más potentes, sino asegurarse de no quedarse fuera de los mecanismos que permiten utilizarlos para reforzar la seguridad propia.

Si eres de los que escuchan una canción en un bar, en la tele o en TikTok y se pasan horas pensando “¿cómo se llamaba ese temazo?”, te va a gustar esto: ahora puedes usar la tecnología de Shazam directamente dentro de ChatGPT, sin abrir ninguna app adicional ni andar saltando entre pantallas. Todo ocurre en la misma conversación.

La integración entre ambas plataformas permite que el chatbot de OpenAI sea capaz de reconocer música, mostrarte los datos de la canción y ayudarte a descubrir temas similares con solo escribir un mensaje. Además, esta función llega acompañada de la posibilidad de sincronizar tus descubrimientos con la app de Shazam y tu servicio de música en streaming favorito, lo que convierte a ChatGPT en un auténtico centro de control musical.

Qué significa usar Shazam desde ChatGPT

La llegada de Shazam al ecosistema de OpenAI supone que ya no necesitas abrir la app de Shazam para identificar lo que está sonando a tu alrededor. En lugar de sacar el móvil, buscar el icono azul y pulsar el botón, basta con estar chateando con ChatGPT y pedirle que escuche la canción.

Gracias a esta integración, el chatbot puede detectar la música que se reproduce cerca de ti y devolverte el título, el artista, el álbum y otros detalles relevantes en cuestión de segundos. Es la misma tecnología reconocible de Shazam, pero metida de lleno en una conversación de IA donde además puedes seguir preguntando y profundizando sobre lo que estás escuchando.

Esta función está disponible a nivel global y en prácticamente todos los entornos donde funciona ChatGPT: app para iOS, app para Android y versión web en el navegador. No hace falta que vivas en un país concreto ni que tengas un tipo de móvil específico, siempre que tengas acceso al chatbot y a la tienda de aplicaciones integrada.

Detrás de este movimiento está Apple, propietaria de Shazam, que ya venía reforzando la conexión entre sus servicios musicales y los asistentes de IA. De hecho, Apple Music también se puede gestionar con lenguaje natural desde ChatGPT en determinados entornos, lo que deja claro el enfoque de integrar música y conversación en una sola experiencia.

Cómo activar Shazam dentro de ChatGPT paso a paso

Para poder “cazar” canciones directamente desde el chat, antes hay que activar la app de Shazam dentro de la tienda de aplicaciones de ChatGPT. El proceso es muy sencillo y solo hay que hacerlo una vez; después, todo será tan simple como escribir un mensaje.

Lo primero es entrar en la sección de aplicaciones de ChatGPT, accesible desde la web oficial (por ejemplo, a través de chatgpt.com/apps o el apartado de apps dentro de la propia interfaz). Ahí verás un buscador donde puedes encontrar herramientas externas que se integran con el chatbot.

En esa caja de búsqueda tendrás que escribir “Shazam” y seleccionar la app oficial que aparece en los resultados. Una vez dentro de su ficha, verás un botón para conectar o vincular el servicio con tu cuenta de ChatGPT. Solo queda pulsarlo y aceptar la integración para que Shazam quede disponible.

A partir de ese momento, cuando inicies una conversación, podrás invocar Shazam simplemente escribiendo la palabra “Shazam” al inicio del mensaje. No hace falta hacer nada más raro ni configurar accesos directos: el propio chatbot entenderá que quieres usar la función de reconocimiento de canciones.

Este paso de vinculación también sirve para que las pistas que identifiques desde el chat queden asociadas a tu historial musical en Shazam, de forma que luego las encuentres en tu móvil o en tus listas de Apple Music o Spotify si las tienes conectadas.

Cómo identificar canciones desde ChatGPT usando Shazam

Una vez activada la integración, el uso diario es muy natural. La idea es que puedas preguntar qué canción está sonando sin salir en ningún momento de la conversación con la IA, como si fuera una consulta más dentro del chat.

Para lanzar el reconocimiento, basta con escribir un mensaje del estilo “Shazam, ¿qué está sonando?” o “Shazam, ¿qué canción es esta?”. Lo importante es que empieces el mensaje con la palabra clave “Shazam” para que ChatGPT sepa que debe activar la aplicación musical integrada y escuchar el audio.

En muchos ejemplos que ya se han visto en capturas de pantalla, el usuario escribe algo como “Shazam, ¿cuál es la canción que está sonando ahora mismo?”. Tras enviar ese mensaje, en el propio chat aparece un botón grande con el logo de Shazam que tienes que pulsar para comenzar la escucha.

Al tocar ese botón, Shazam se pone a trabajar igual que en su app tradicional: capta el sonido ambiente durante unos segundos, lo analiza y lo compara con su enorme base de datos musical. Si hay coincidencia, la herramienta devuelve en pocos segundos el resultado al mismo hilo de ChatGPT.

En la respuesta verás el nombre del tema, el artista, el álbum en el que aparece y, en muchos casos, la portada de la carátula. Además, suele ofrecer una pequeña preescucha o adelanto de la canción, de forma que puedas confirmar que se trata del tema que estabas buscando sin abrir nada más.

Qué información ofrece Shazam dentro de ChatGPT

Además del título de la canción y el nombre del músico, la integración muestra una serie de datos adicionales que resultan muy útiles para organizar tus descubrimientos. No se trata solo de decirte qué está sonando; también te ayuda a contextualizarlo mejor.

Entre la información que suele aparecer se incluye el álbum al que pertenece la pista, la fecha aproximada de lanzamiento y en ocasiones datos extra como popularidad o número de veces identificada por usuarios de Shazam en todo el mundo. Esto último te permite hacerte una idea de lo conocida que es la canción.

En algunos casos, ChatGPT puede enriquecer esa respuesta añadiendo, ya en modo conversacional, detalles sobre el estilo musical, el contexto en el que se hizo famosa la canción o anécdotas sobre el artista, aprovechando sus propias capacidades de IA para ir más allá del simple reconocimiento.

Todo se presenta en el mismo flujo de conversación, lo que hace que no tengas la sensación de estar cambiando de app constantemente. Pasas de preguntar por el tiempo a descubrir la canción que suena en la radio del bar sin abandonar el chat.

Otra ventaja es que puedes pedir a la IA, una vez conocida la canción, que te recomiende temas parecidos, playlists con un estilo similar o información más profunda sobre el álbum. Shazam detecta el tema y ChatGPT se encarga del resto del contexto y las recomendaciones.

Ventajas de usar Shazam directamente en ChatGPT

El principal motivo para usar esta integración es la comodidad. Cuando ya tienes abierto el chatbot, es mucho más rápido pedirle al propio ChatGPT que identifique lo que suena que desbloquear el móvil, buscar la app de Shazam y abrirla. Todo se resuelve en unos pocos segundos y con un solo flujo de interacción.

Además, al estar todo integrado, puedes seguir conversando sobre la canción sin necesidad de cambiar de pantalla. Si te intriga cómo se grabó el tema, qué otros trabajos tiene el mismo artista o qué géneros cercanos te podrían gustar, se lo preguntas al mismo chat donde has hecho el reconocimiento.

Otra ventaja clara es que no necesitas tener instalada la app clásica de Shazam en tu móvil. La tecnología de reconocimiento está disponible dentro de ChatGPT gracias a la integración, por lo que cualquiera que tenga acceso al chatbot puede identificar canciones, incluso aunque nunca haya usado Shazam antes.

La inmediatez también se aprecia cuando estás haciendo otras consultas en la IA. Por ejemplo, si estás planificando un viaje o redactando un texto y, de repente, suena un tema en la radio que te llama la atención, puedes interrumpir un segundo la conversación, lanzar el comando de Shazam, guardar la canción y seguir a lo tuyo sin distracciones.

Por último, hay una parte muy interesante ligada a la sincronización: lo que descubres en el chat no se pierde, porque puede quedar guardado en tu perfil de Shazam y en tus listas musicales. Así, cuando luego abras Apple Music o Spotify, tendrás a mano todos esos temas que “cazaste” en medio de una conversación con ChatGPT.

Sincronización con la app de Shazam y servicios de streaming

La integración no se queda solo en el reconocimiento puntual. Si ya usas Shazam en tu móvil, puedes vincular esa cuenta con ChatGPT para que todas las canciones identificadas desde el chatbot aparezcan también en la app tradicional. De este modo, centralizas todos tus descubrimientos en un único historial.

Cuando tienes conectados Shazam y un servicio de streaming como Apple Music o Spotify, cada canción identificada puede añadirse automáticamente a una lista de reproducción especial. En el caso de Apple Music, suele ser la clásica playlist de “Shazams” del usuario; en Spotify, puede ir a una lista predeterminada o a tu biblioteca.

Esto significa que, si un día identificas varios temas desde ChatGPT, más tarde podrás reproducirlos enteros directamente desde tus apps de música, sin tener que buscarlos uno por uno. Es una forma muy cómoda de convertir la curiosidad puntual en una colección musical estable.

La sincronización también resulta útil para quienes usan diferentes versiones de Shazam: lo que detectes en ChatGPT se suma a lo que ya tenías de cuando usabas la app en el móvil o la versión integrada en otros dispositivos. Así, no pierdes rastro de ninguna canción, da igual desde dónde la hayas descubierto.

Aunque no es obligatorio tener Shazam instalado para usarlo dentro de ChatGPT, la experiencia es más completa si decides conectar ambas cuentas. De esa forma, el chatbot se convierte en un “capturador” de canciones que se alimenta de toda la infraestructura de Shazam y de tu ecosistema musical.

Shazam dentro de ChatGPT frente a otras formas de identificar música

Hasta ahora, cuando querías identificar una canción tenías opciones como abrir Shazam, usar el reconocimiento de Google o tirar de asistentes de voz como Siri o el Asistente de Google. Cada uno con sus ventajas, pero siempre implicaban salir de lo que estabas haciendo.

Con esta integración, ChatGPT se suma a la lista de herramientas capaces de ponerle nombre a lo que suena, pero con la particularidad de que lo hace en mitad de una conversación de texto. Ya no dependes solo de apps independientes, sino de un entorno donde también puedes describir, preguntar y explorar.

La tecnología que hay detrás sigue siendo la de Shazam, que analiza el ritmo, la frecuencia sonora y los patrones de audio de la canción para compararlos con su base de datos. Es un enfoque muy distinto al de las soluciones basadas solo en letra o metadatos, y por eso suele ser tan certero cuando el audio está claro.

Por otro lado, ChatGPT también puede ayudarte en los casos en los que no tienes el audio a mano, pero sí recuerdas parte de la letra o detalles del tema. En estas situaciones, no está usando Shazam como tal, sino su propia capacidad de entender texto y buscar coincidencias basadas en lo que le describes.

Así, el chatbot se convierte en un complemento perfecto: si el tema está sonando, tiras de Shazam dentro de ChatGPT; si no lo está, puedes probar a describir la letra, el género, el idioma o el contexto para que la IA te sugiera posibles canciones. Ambas formas de uso se apoyan y se refuerzan mutuamente.

Usar solo ChatGPT para identificar canciones sin audio

Aunque la integración con Shazam es muy potente, conviene recordar que ChatGPT también puede intentar identificar canciones sin escuchar el audio, solo a partir de la información que le des. No es lo mismo, pero puede sacarte de más de un apuro.

En estos casos, en lugar de activar Shazam, lo que haces es escribirle al chatbot fragmentos de la letra que recuerdes, el idioma, si la voz era masculina o femenina, el ritmo aproximado, el estilo musical o incluso tararear la melodía. Cuantos más detalles aportes, más posibilidades habrá de que acierte.

La IA analizará toda esa descripción y tratará de proponer una lista de canciones que puedan encajar con lo que cuentas. No es tan preciso como el reconocimiento directo por audio, pero muchas veces es suficiente para dar con el tema que tenías en la punta de la lengua.

Este enfoque funciona especialmente bien cuando recuerdas una frase muy concreta de la letra o un estribillo llamativo. Si la canción no es extremadamente rara, suele haber suficientes referencias online como para que ChatGPT encuentre una buena coincidencia.

En definitiva, cuando combinas la parte de Shazam (audio real) con la parte puramente textual de ChatGPT (descripciones, letras, contexto), tienes un abanico de opciones muy completo para descubrir música, incluso si no puedes reproducir el tema original en ese momento.

Limitaciones, precisión y casos en los que puede fallar

Aunque Shazam es famoso por su fiabilidad, también hay ciertos escenarios en los que la identificación desde ChatGPT puede tardar más tiempo o, incluso, no encontrar ningún resultado. Esto es algo que ya ocurría en la app independiente y se mantiene en la integración.

Las situaciones más problemáticas suelen darse cuando el audio está lleno de ruido de fondo, la música suena muy baja o se trata de una versión en directo muy poco conocida. En esos casos, la huella sonora no coincide de forma clara con lo que tiene registrado la base de datos.

También puede fallar cuando se trata de canciones extremadamente raras, maquetas caseras, remixes poco difundidos o grabaciones con mucha distorsión. Aunque estos casos son poco habituales para la mayoría de usuarios, conviene tenerlo presente para no desesperarse si una pista concreta no aparece.

En cuanto a ChatGPT trabajando solo con texto, la precisión depende por completo de lo detallada que sea tu descripción. Si solo dices “una canción pop en inglés de hace unos años” es casi imposible acertar; si añades letras, contexto y detalles de la voz, las probabilidades mejoran mucho.

Aun con estas limitaciones, la combinación de ambas herramientas hace que, en la gran mayoría de los casos cotidianos, puedas identificar sin problemas la música que te llama la atención, ya sea porque está sonando en ese mismo momento o porque la llevas días rondando en la cabeza.

En conjunto, la integración de Shazam dentro de ChatGPT convierte al chatbot en un compañero perfecto para los melómanos y los curiosos: permite cazar canciones al vuelo, guardar todos los descubrimientos en tu ecosistema musical y seguir explorando artistas, géneros y temas relacionados sin salir de la conversación, uniendo reconocimiento de audio e inteligencia artificial en una misma experiencia fluida.

La Comisión Europea ha puesto el foco en Google y en la forma en que gestiona los datos de búsqueda dentro del mercado único digital. Bruselas considera que el gigante estadounidense está limitando de manera indebida el acceso de otros motores de búsqueda a información esencial para competir en igualdad de condiciones.

En el centro del debate está la obligación de cumplir con la Ley de Mercados Digitales (DMA), que impone normas específicas a las grandes plataformas en línea que actúan como «guardianes de acceso». Para la UE, los datos que maneja Google Search —incluidos los que se generan a través de chatbots con funciones de búsqueda— no pueden quedar blindados si ello cierra la puerta a la competencia en Europa.

Qué exige Bruselas exactamente a Google

Según las conclusiones preliminares remitidas por la Comisión, la empresa debería permitir a motores de búsqueda de terceros acceder a datos clave relacionados con la clasificación de resultados, la forma en que se muestran esos resultados y la interacción a través de chatbots de inteligencia artificial con funciones de búsqueda. Una actuación similar a la que motivó que Bruselas acusara a Meta.

Los servicios comunitarios sostienen que la restricción de acceso a estos datos reduce de forma significativa la competencia efectiva en el mercado europeo de la búsqueda online. Sin esa información, los rivales tendrían muchas más dificultades para desarrollar algoritmos y servicios que estén a la altura de Google Search (por ejemplo, para crear asistentes conversacionales como el asistente de WhatsApp con IA de Bankinter).

El expediente formal se abrió el pasado mes de enero y, a partir de ese momento, Bruselas ha ido recabando información y opiniones de otros actores del sector digital. El resultado provisional es que Google podría estar incumpliendo las obligaciones que la DMA impone a los grandes intermediarios, especialmente en lo relativo al acceso a datos y a la no discriminación.

El objetivo último de la Comisión Europea es que el acceso a estos datos se produzca en condiciones «justas, razonables y no discriminatorias», de manera que otros motores de búsqueda puedan perfeccionar sus servicios, incorporar funcionalidades basadas en IA y competir en pie de igualdad tanto en España como en el resto de la Unión Europea, como ocurre con integraciones como ChatGPT en CarPlay.

Calendario del procedimiento y posibles sanciones

Las propuestas elaboradas por el Ejecutivo comunitario se someterán ahora a consulta con la propia Google y con otros agentes implicados hasta el 1 de mayo. Durante este periodo, las partes podrán formular observaciones, sugerencias de cambio o alegaciones jurídicas, incluidas consideraciones sobre seguridad y privacidad recogidas en estrategias de ciberseguridad.

Una vez finalizado ese plazo, la Comisión iniciará una fase de análisis interno con vistas a adoptar una resolución final que, como muy tarde, deberá estar lista en julio. Ese texto fijará de forma definitiva las obligaciones de Google y las condiciones concretas de acceso a los datos de búsqueda.

Si los cargos se confirman sin modificaciones sustanciales, Bruselas tiene la posibilidad de imponer a la compañía una multa económica de gran magnitud, acorde con el régimen sancionador previsto en la Ley de Mercados Digitales para los incumplimientos graves y reiterados.

El expediente no se limita a España, pero su impacto será especialmente relevante en el mercado europeo, donde Google ostenta una posición dominante en la búsqueda online y donde la UE está tratando de abrir espacios a nuevas herramientas y empresas emergentes, incluidas las que integran inteligencia artificial generativa.

Datos, IA y competencia: la visión de la Comisión Europea

Para la Comisión, el acceso a la información que genera Google Search es un insumo esencial para la innovación en servicios digitales. Sin esos datos, las empresas más pequeñas lo tienen mucho más difícil para entrenar sus sistemas de IA o para ajustar sus algoritmos de posicionamiento y respuesta.

La vicepresidenta de la Comisión Europea responsable de competencia, Teresa Ribera, ha subrayado que «los datos son una aportación clave para la búsqueda online y para el desarrollo de nuevos servicios», incluida la inteligencia artificial. A su juicio, limitar ese acceso de manera injustificada puede perjudicar al conjunto del ecosistema digital europeo.

Ribera también ha advertido de que, en «mercados en rápido movimiento, los pequeños cambios pueden tener rápidamente un gran impacto». Con esta idea, la Comisión lanza un mensaje claro: no tolerará prácticas empresariales que puedan desembocar en el cierre de mercados o en la reducción de opciones para los usuarios europeos.

En este contexto, Bruselas pretende que los rivales de Google puedan recibir datos de búsqueda, incluidos los que proceden de chatbots de IA con funciones de búsqueda. Esta información, convenientemente tratada y anonimizad, permitiría a otros operadores pulir sus herramientas, mejorar la calidad de los resultados y desarrollar asistentes conversacionales más competitivos.

La propuesta comunitaria también pide que se detalle con precisión el alcance exacto de los datos que Google tendría que compartir, evitando ambigüedades que puedan vaciar de contenido las obligaciones o generar nuevos conflictos en el futuro.

Condiciones técnicas: anonimización, frecuencia y precios

Más allá del principio general de acceso, una parte clave del debate gira en torno a cómo, cuándo y a qué coste se facilitarán los datos de búsqueda. La Comisión quiere fijar criterios claros sobre los mecanismos de transmisión de la información, así como sobre la regularidad con la que se actualizarán los conjuntos de datos.

Bruselas plantea introducir salvaguardas específicas para garantizar la anonimización de los datos personales, de modo que el intercambio de información no implique revelar identidades ni hábitos individuales de los usuarios. Este punto es especialmente sensible en la UE, donde el Reglamento General de Protección de Datos (RGPD) marca un listón muy elevado en materia de privacidad.

Otro frente de la propuesta tiene que ver con los criterios de fijación de precios por el acceso a los datos. La Comisión insiste en que cualquier tarifa que Google pueda cobrar a otros buscadores deberá ser justa, razonable y no discriminatoria, evitando que el precio se convierta en una barrera de entrada encubierta.

En paralelo, se estudian condiciones sobre los formatos y estándares técnicos en los que se proporcionará la información. La intención es que los datos sean realmente utilizables por los motores de búsqueda rivales, sin obstáculos derivados de tecnologías propietarias o incompatibilidades deliberadas.

Por último, el borrador de obligaciones incluye referencias al tratamiento específico de los datos generados por chatbots de IA integrados en la búsqueda. Dado que estos sistemas pueden recoger interacciones muy detalladas de los usuarios, la Comisión quiere evitar que su explotación quede monopolizada por un solo actor.

La respuesta de Google: acusaciones de extralimitación y riesgo para la privacidad

Google ha reaccionado con dureza ante el movimiento de Bruselas y ha dejado claro que no comparte la interpretación que hace la Comisión de la Ley de Mercados Digitales. En un comunicado remitido a medios europeos, la compañía califica la petición de «extralimitación» y avanza que seguirá defendiéndose en el procedimiento.

Según la tecnológica, las exigencias formuladas por la UE superan con creces el mandato de la DMA y podrían tener consecuencias negativas no solo para la empresa, sino también para los propios ciudadanos europeos que utilizan a diario sus servicios.

Uno de los principales argumentos de Google es que los cambios propuestos le obligarían a «ceder» datos privados de millones de usuarios europeos a buscadores de terceros que, a su juicio, contarían con «medidas de protección de privacidad peligrosamente ineficaces». La compañía sugiere que abrir el acceso sin un marco extremadamente estricto podría traducirse en más riesgos de filtraciones o usos indebidos.

La empresa insiste además en que ya cumple con elevados estándares de seguridad y protección de datos, y teme que un intercambio de información a gran escala erosione la confianza de los usuarios en sus servicios. Este pulso entre competencia y privacidad se convierte, así, en uno de los ejes centrales del conflicto entre Bruselas y Google.

Pese a su postura crítica, la compañía participará en la consulta abierta hasta el 1 de mayo, en la que tratará de influir en el diseño final de las obligaciones, bien suavizando las exigencias, bien introduciendo salvaguardas adicionales en materia de protección de datos y seguridad.

La presión regulatoria sobre Google se enmarca en un contexto europeo en el que se intenta equilibrar la innovación en inteligencia artificial con la defensa de la competencia y la protección de la privacidad. Lo que se decida en este caso marcará un precedente clave para el resto de grandes plataformas que operan en el mercado digital europeo.

La pugna abierta entre la Comisión Europea y Google ilustra hasta qué punto los datos de búsqueda y los sistemas de IA se han convertido en un recurso estratégico para el futuro del ecosistema digital en Europa. Mientras Bruselas defiende que abrir el acceso es imprescindible para que surjan alternativas reales a Google Search, la compañía alerta de que hacerlo sin cautelas puede poner en riesgo la seguridad y la privacidad de millones de usuarios. Lo que finalmente determine la resolución, prevista para el verano, condicionará el margen de maniobra de los buscadores rivales y el grado de control que la Unión Europea está dispuesta a ejercer sobre los gigantes tecnológicos.